Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Миссия выполнима: глобальный продукт без простых задач

Меня зовут Евгений Моспан, и я в IT с 2003 года. Начинал стажером в продуктовой компании, и за время работы там прошел путь от интерна до исполнительного директора. Когда челленджи в компании закончились, я перешел в ЕРАМ, чтобы разрабатывать продукты для заказчиков из крупного международного бизнеса. Моя роль роль — Solution Architect — как нельзя лучше подходит для инженера. Сегодня я расскажу о своем опыте работы над одним из таких продуктов.

Один из крупных клиентов ЕРАМ — логистическая компания, функционирующая в более чем 220 странах и территорий по всему миру. End-to-end продукт, над которым мы работаем, должен заменить все ее многочисленные front-office системы на одну современную, быструю и понятную пользователям. Система включает несколько тысяч полноценных Use Cases и при этом должна быть гибкой как в плане статического контента, так и бизнес-правил, которые сильно отличаются в зависимости от стран. Более 10 команд были распределены по ряду локаций.

Глобальный проект — это огромная ответственность

В нашем случае он покрывает бизнес по доставке посылок и фактически адресует все возможные способы отправления с учетом всех разнообразных региональных особенностей. Решение состоит из девяти функциональных компонентов, которые должны быть развернуты в соответствующем окружении и взаимодействовать между собой.

Компоненты имплементированы с помощью Play! Framework, Spring MVC, Adobe Experience Manager (AEM), есть компонент на слое баз данных, компонент для логирования и так далее. Front-end инженеры работают в основном с Angular JS; Back-end — помимо Spring, Play, AEM — должны ориентироваться в Quartz Scheduler, Terracotta; DBA-инженеры работают с базами данных Oracle. Есть также DevOps-ы, которые автоматизируют деплоймент с помощью Ansible.

На проекте с таким широким спектром технологий успешно работать могут только подготовленные и технически подкованные Solution Architects (SA) и Delivery Managers (DM). Архитектор должен понимать, куда какая функциональность будет добавлена и как это повлияет на систему в глобальном контексте. Delivery Manager, в свою очередь, должен правильно организовать работу распределенных команд и не допустить, чтобы они блокировали друг друга. Вообще, связка SA-DM на этом проекте очень плотная, так как надо постоянно быть on the same page и следить, чтобы все компоненты были развернуты в нужном объеме, нормально масштабировались и так далее.

С точки зрения архитектуры на проекте есть много quality-атрибутов, которые наш заказчик попросил учесть. Задача непростая, так как их сложно даже увязать между собой из-за возникающих противоречий. Например, клиент просит, чтобы перформанс приложения был end-to-end не более трех секунд. Это означает, что вся сложная функциональность и ее конфигурация должна быть уложена в эти три секунды. При этом, помимо системы, которую разрабатывает ЕРАМ, у заказчика есть еще множество других систем, с которыми интегрируется наш проект и с которыми надо считаться.

Или есть еще один quality-атрибут — доступность приложения по всему миру 24/7 и определенные ограничения по развертыванию. У клиента есть собственные data-центры, в которых и должны деплоиться приложения, а между ними должна быть реализована active-active репликация для обеспечения failover. Чтобы удовлетворить это требование, нам надо реплицировать огромные объемы данных фактически в режиме реального времени, что накладывает свои ограничения на базу данных и на то, как она должна быть спроектирована.

Вызовы мотивируют нас

Например, Play! Framework, который мы используем в одном из компонентов, не только дает реактивный подход к написанию бизнес-логики «из коробки», но и вносит сложности в имплементацию функциональности. Логика у нас последовательная, так как бизнес интересует end-to-end транзакция, а реактивный подход как раз предполагает событийную модель, поэтому инженерам и архитекторам пришлось придумывать способы, которые позволяли бы использовать преимущества реактивного подхода и в тоже время адресовать бизнес-цели, которые ставятся перед той или иной транзакцией. Отдельным вызовом было свести воедино Play-фреймворк и Spring Security, Spring Integration, Spring Cashable, Spring Data и другие фреймворки этой экосистемы, которые мы активно используем на проекте.

Что касается интерфейса пользователя, то мы довольно долго искали золотую середину между тем, что должно покрываться непосредственно платформой по управлению контентом (AEM), а что должно было быть бизнес-кодом самого front-end приложения, которое имплементируется на AngularJS и изменяется исключительно FE-разработчиками. Такой баланс был достигнут за счет того, что страница была разделена на CMS-компоненты, которые получили названия «транзакционные» и «статические». В итоге контент-авторам был предоставлен доступ только к компонентам последнего типа для управления контентом, который отображался конечному пользователю. Эти требования были довольно жесткими, ведь для разных стран нужен был контент разного формата и направленности. Транзакционные компоненты стали source-кодом самой системы.

В этом продукте нет простых задач в принципе

Любая, на первый взгляд, простая задача становится крайне сложной в глобальном контексте. Например, кэширование первичных ключей в Нibernate — распространенная фича «из коробки», которую многие используют для улучшения перформанса, однако в условиях active-active репликации все не так просто. Она вносит свои требования к формированию первичных ключей, Нibernate — свои и все это надо знать, понимать и кому-то адресовать.

Нам необходима экспертиза во многих областях: человек, который управляет процессом разработки фичи, должен понимать АЕМ и AngularJS, все тонкости и специфику Java и его фреймворков, Нibernate, слой базы данных Oracle... Уложить это в голове одного инженера практически невозможно. Для справки: самый большой use case на этом проекте касался процесса отправки посылки и был описан клиентом на 90 страницах, разбит на почти столько же подкейсов, которые декомпозировали на порядка 1000 stories. За простой, на первый взгляд, работой лежит колоссальный объем функциональности, которая должна чем-то конфигурироваться.

Поэтому был спроектирован и разработан с нуля еще один специальный компонент для управления конфигурацией для каждой страны и каждого пользователя отдельно (клиенту критически важна возможность предоставлять индивидуальные условия каждому юзеру). В условиях, когда речь идет о 2 миллионах пользователей, задача перестает быть тривиальной.

Задачи Solution Architect

В таких условиях вовлеченность Solution Architect-а и его тесное взаимодействие с Delivery Manager-ами необходимо на протяжении всего проекта. Архитектура была сформулирована на high level летом 2015 года и с тех пор претерпевала лишь итерационные изменения. В ходе такого огромного проекта оказалось, что не всегда low level дизайн можно поручить тимлидам. Они руководят десяткой команд, в которых разработчики параллельно делают разный функционал и разные бизнес-задачи.

Вопрос: а все ли ребята понимают, что происходит в глобальном масштабе? Ясно, что «сторю» они сделают, а вот как она повлияет на другие stories и наши quality-атрибуты — это понятно далеко не всем.

На все подобные вопросы должен кто-то отвечать. За это взялась группа Solution Architecture, которая, помимо дизайна, сложных функциональных задач, адресования quality-атрибутов, несет своеобразную просветительскую миссию, объясняя, как нужно имплементировать задачи с точки зрения большой и требовательной экосистемы. В группу вошли техлиды, присоединившиеся к компании с рынка, и ребята, которые выросли на этом проекте. Некоторые инженеры решили, что им интересно развиваться в направление архитектуры, и я стал их ментором в рамках программ SA Mentoring и SA School. Постепенно наша команда стала мостом между бизнесом и имплементацией, конвертируя бизнес-требования в технические. Теперь и заказчик интересуется у нас, как любая новая функция повлияет на систему в целом.

С точки зрения масштабов проекта обеспечивать CI/CD довольно сложно, потому SA и DM-ы создали прозрачный процесс, по которому происходит delivery. Любое изменение кода проходит долгий путь от разработки на локальной машине до развертывания в окружении: после разработки девелопер должен покрыть свой код unit интеграционными тестами, чтобы убедиться, что он не сломает процесс CI (разработчиков много, и мы пытаемся минимизировать количество коммитов, которые будут ломать билд). Код также проходит статистический анализ с помощью Sonar, ревью в Gerrit, куда интегрированы чеки от Sonar, запуск unit-тестов и сборка билда, чтобы обойтись без рутины и отсекать явные gap-ы. После того, как код попадает на CI, проходит билд всех артефактов и развертывание системы в целом. На этой системе запускается весь набор интеграционных тестов и Smoke end-to-end тестов от наших автоматизаторов. Если артефакт успешно проходит все quality gates (в которые входят также и требования quality-атрибутов, security, performance issues), а SonarQube не показывает новых issues, то этот артефакт считается зеленым и попадет к QA-инженерам, которые проводят мануальное тестирование фичи и дают рекомендации по автоматизации ее регрессии. Только после этого артефакт готов к развертыванию на следующих энвайронментах. На окружение заказчика мы деплоим его еще во время первой итерации, чтобы убедиться, что ничего не ломаем, а в конце каждого раунда формируем релиз-кандидат по каждой итерации. Важным quality gate является отсутствие critical, blocker и major issues в рамках того кода, что написан. Таким образом, для девелоперов у нас условия достаточно суровые, но это сделано именно из-за осознания масштабности системы.

Мы долго работали над построением коммуникаций с бизнесом. В силу большого количества stakeholder-ов и требований, этого клиента удовлетворяет только идеальное решение. Сперва заказчики не хотели никаких компромиссов, им нужно было получить в системе все. Но постепенно мы пришли к приоритизации требований и получили стабильное работающее решение.

Преодоление сложностей

В процессе разработки нам пришлось преодолеть проблемы с точки зрения архитектуры/delivery и критично важного улучшения скорости работы системы, без которого проект не был бы успешен.

Основное время работы над системой ушло на core-функциональность, в которую входила возможность отправки посылок для частных лиц. Все основные элементы и интеграции мы сделали в рамках этой работы. Заходя в систему, пользователь создавал на сайте кабинет и работал со своими данными, ни с кем ими не делясь. Но компания заказчика сотрудничает не только с частными лицами, но и с корпоративными клиентами. У последних возникают совершенно другие требования: они хотят работать с данными совместно.

Так появилась задача расширить базовую функциональность таким образом, чтобы позволить многим пользователям одной компании-клиента работать в рамках общего кабинета. Требования для этого у заказчика были широкими, потому его клиенты-юрлица находятся по всему миру. Одной из основных была возможность распределения ролей пользователей и доступа в зависимости от их должностей. Ограничений по отправке посылок у заказчика получилось около 200: от суммы, потраченной на доставку, до веса посылки.

Чтобы только собрать все ограничения и проработать то, как они будут интегрироваться в существующую функциональность, архитектурная команда вместе с аналитиками потратила около четырех-пяти месяцев. За это время мы проводили регулярные воркшопы с заказчиком, привлекали стейкхолдеров, систематизировали все, делали дизайн, показывали его драфты заказчику.

После основательной подготовки всю команду нужно было переключить с core-функциональности на работу над новой. Здесь мы столкнулись с серьезным вызовом.

Все команды писали свои конкретные модули. Поэтому нам пришлось готовить базу под то, чтобы мы могли легко пересаживать людей из одного модуля в другой, обеспечив тем самым нужный масштаб для реализации новых требований. Заказчик поставил задачу привлечь всех людей с первого дня. Это примерно так же, как на новом проекте сразу стартовать со 100 человек.

Чтобы подготовиться к этому, мы выделили нескольких сотрудников, которые в течение месяца сделали скелет того, что мы собирались изменить. Это были опытные специалисты, которые могли работать в условиях неопределенности. Они реализовали основные флоу, в которые нужно было вводить функции, которые хотел заказчик.

Когда мы показывали первое демо с результатами работы за месяц, произошла небольшая коллизия. Вечером мы подготовили environment, на котором все уже было настроено и работало, хотя в этот же момент еще идет активная разработка. За 20 минут до начала нужно убедиться, что все готово к презентации, но заготовленная среда не работала. Я понимал, что демо показать не смогу, а со стороны заказчика присутствуют топ-менеджеры и перенести ничего нельзя. Оказывается, что среда, в которую мы установили наше приложение, перезагружается, и когда процесс закончится — непонятно. За пять минут до демо мы смогли локально поднять нужную среду на двух ноутбуках. Новая идея презентации заключалась в том, что мы разделили проект на две части: функциональность — в одной системе, ее настройки — в другой.

Демо прошло успешно. А уже вечером того же дня мы объяснили всем командам, что они должны делать. За день мы вовлекли все команды — более 100 человек. В первый же день они приступили к разработке.

В конце разработки команду ждал еще один вызов

Изначально клиент ставил задачу, чтобы перформанс приложения был end-to-end не более трех секунд. В процессе работы над функциональностью системы, многими вещами жертвовали из-за сроков. Когда же она была закончена, пришло время уделить внимание скорости работы. С точки зрения архитектуры она должна работать быстро, но имплементация некоторых в местах могла ситуацию портить. Когда решение было установлено на предпродакшн-среде, оказалось, что наши основные флоу работали примерно по три минуты.

Никто не понимал в чем было дело. Чтобы найти причину, пришлось вовлечь шесть инженеров, провести множество экспериментов и ввести процесс обработки таких issues.

Нам нужно было установить, как мы можем мониторить среду, договориться с командой поддержки заказчика, их инженерами, отвечающими за performance-тестирование, наладить проведение экспериментов. Благодаря тому, что инженеры заказчика находились в часовом поясе впереди нашего, пока мы работали — они спали, а затем тестировали систему с нашими обновлениями. Это позволило за три дня стабилизировать проведение экспериментов.

Эта работа была критично важна, потому что многие системы, которые заказчик делал ранее, не могли пройти этап performance-тестирования. Из-за их медлительности бизнес-клиенты не позволяли вводить их в эксплуатацию.

После долгих экспериментов и настроек нам удалось систематизировать проблему. Вовлечение многих людей обеспечило решение проблемы, которая на первый взгляд казалась нерешаемой. Мы смогли обнаружить и локализовать причину, устранить ее и двигаться к решению следующих проблем быстродействия. На данном этапе этот процесс уже носит системный характер: мы понимаем, что происходит, отслеживаем эксперименты, результаты, все проблемы.

Вместо вывода

Хотелось бы обратить внимание на несколько, казалось бы, простых, но, исходя из собственного опыта, очень важных моментов. Когда вы беретесь за большой и сложный продукт, первое, что нужно досконально продумать — как вы будете координировать большое количество людей. Вам нужно всеми силами стремиться к прозрачности информации. Вся она должна находиться в системе контроля версий. Не распространяйте важную информацию и документы по почте, не позволяйте принимать важные решения в чатах и во время отдельных звонков.

Четкая документация и зафиксированные решения дают возможность контролировать версионность и в случае пополнения в команде — давать новым людям не историю чата, а ссылку на конкретный документ. Заведите себе правило: если вы не можете отправить ссылку на артефакт с запрашиваемой информацией, создайте его!

В больших проектах нет простых требований. Всегда нужно прояснять самые мелкие детали: чем лучше они проговорены и описаны, тем меньше шансов на переделку всей работы или значительной ее части. Старайтесь согласовать достаточно четко и критерии «приемки» работы: все участники должны понимать, что означает «задача сделана и проверена стейкхолдерами». Тогда любой продукт будет не только интересен в разработке, но и эффективен после релиза, в реальной жизни.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn

Схожі статті




48 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Забавно видеть как большинство начало растаскивать на цитаты и тешить эго фразами «как вы могли сделать ХХХ, вот я бы взял YYY и всё заработало как часы» — без понимания ни задания, ни условий. Хотя, по факту, команда в срок(sic!) закончила проект с приемлимыми значениями метрик. Деталей в статье маловато, но это другая проблема, уж всяк не техническая.

без понимания ни задания, ни условий.

Потому что в статье эти самые задания и условия НЕ были озвучены.

«как вы могли сделать ХХХ, вот я бы взял YYY и всё заработало как часы»

Хм, че-то я такого не видел. Я увидел «нафика вы взяли Х, если сами же говорите что он не соответсвовал требованиям».

Хотя, по факту, команда в срок(sic!) закончила проект с приемлимыми значениями метрик.

Деградация в 60 раз — это приемлимые значения метрик?
Сугубо по информации из статьи: с инженерной стороны проект провален (не выволнены изначальные требования по производительности, процесс тестирования не позволил поймать проблему с перформансом, не было прозрачного и надежного способа развернуть систему). Это все риски, иработа технаря устранить/минимизировать эти риски. Например, для этого и CI, а не для того чтобы можно было написать статью на ДОУ в котору включить термин «CI/CD». Кстати по коственным признакам в статье, CD там даже близко не было.
То что «бизнесс-люди» не допустили залета ЕПАМа на бабки (что кстати не факт) — это отдельная история.

Вроде как по тексту статьи производительность пофиксили к финальному релизу, не знаю, свечку не держал.
Я не говорю, что в данной истории комар носа не подточит, очевидно, что можно советовать «по верхам» пост-фактум много чего, но когда приходит клиент с бюджетом Х, а на идеальный процесс, с анализом, валидацией предположений и т.д. нужно 2Х (что есть примерно в каждом случае на рынке аутсорса) — приходится импровизировать на ходу. На ДОУ все как один максималисты и знают, что делать получше чем таксисты в политике, но я сужу по себе, я бы вряд-ли довёл такую махину до финала при всех описанных условиях. Для кого-то это плёвое дело, возможно, ну что же, по доброму завидую.

На ДОУ все как один максималисты и знают, что делать получше чем таксисты в политике

На ДОУ много инжененров, которые представляют что делать с __технической__ частью проекта. Снова же, я как-то не заметил советов, в основном __вопросы__, на которые пока никто не ответил.

но я сужу по себе, я бы вряд-ли довёл такую махину до финала при всех описанных условиях.

Круто. То есть вы поняли какие были входные условия. Опишите пожалуйста короткий список, пунктами менее 10 слов.
Я, например, не увидел вызовов: фроу описанный на 90 страниц — никто не засталяет садить за его реализацию 1 человека, декомпозируем и пришем тесты; 2 млн — делаем кеш, та и что-то мне подсказывает что это не 2 млн конкурентных пользователей и далеко не все из них буду кастамизировать (при том много атребутов).
Но это то что __описанно__ в статье, возможно в реальности и были сложности, но о них в статье нет ни слова.

Мало того, что ни на один технический вопрос не было ответа. Еще смущает факт требований кастомера, чтобы все 100 человек с первого дня уже работали на проекте. Выглядит так, как будто у кастомера уже подгорало по срокам и деваться ему было особо некуда. А суть разработки таких систем как раз и сводится к декомпозиции, разбивке на домены, написание контрактов и карт коммуникации, а дальше работа уже может выполняться в командах. Возможно так и пытались сделать, но опять же об этом ничего не написано.

Хм, «пунктами менее 10 слов» :) но зачем? Не думаю, что я могу добавить что-то к тому что описал автор.
Чтобы написать «high-level» декомпозицию на 5 человеко-лет для проекта без мудрёных атрибутов качества, нужно минимум неделю времени сферического архитектора в вакууме и ему сочувствующих экспертов, данный проект навскидку, по описанию, не меньше чем 50-100 человеко-лет. Чтобы подписать контракт, нужно дать оценку команды, чтобы дать оценку команды, нужно иметь примерный WBS, а как я уже прикинул WBS на такой проект это минимум месяц, а то и два минимум, просто чтобы понимать объём работы и подписать хотябы контракт на дискавери. Собственно, всё просто — начальные ожидания и предположения иногда не срабатывают, требования уточняются, меняются (никто не скажет клиенту — «уходи Клиент, с которым у нас контракт на выделенную команду в 100 человек — ты изменил требование») и т.д. «Делаем кеш» звучит как «пишем идеальную систему без багов» — способов десятки, нюансов сотни, не все известны архитектору, не всё он учёл сразу, где-то ошибся, где-то делегировал реализацию, а её сделали не так как нужно. Есть ли методы убрать эти риски — есть конечно, можно написать сотни способов как избежать А, Б, В, Г, Д.

Хм, «пунктами менее 10 слов» :) но зачем?

Для того чтобы:
1) обсятнить вашим оппонентам что именно они НЕ увидели;
2) продемонстрировать ваше понимание ситуации;
3) не палить свою некомпетентность :)

Не думаю, что я могу добавить что-то к тому что описал автор.
То есть вы поняли какие были входные условия. Опишите пожалуйста короткий список, пунктами менее 10 слов.

Я вас просил не дополнять, а сделать выжимку. Тот факт что вы этого не поняли или поняли и не смогли сделать, снова же говорит совсем не в вашу пользу.

Чтобы написать «high-level» ... изменил требование«) и т.д.

Прекрасная водичка. :)

«Делаем кеш» звучит как «пишем идеальную систему без багов» — способов десятки, нюансов сотни, не все известны архитектору, не всё он учёл сразу, где-то ошибся, где-то делегировал реализацию, а её сделали не так как нужно.

1) Аналогия — это признак того что человек не разбирается в том что пытается объяснить.
2) В вашем случае все еще хуже: вы не смогли подобрать аналогию :) Поскольку «делаем кеш» — это задача значительно меньше чем «пишем идеальную систему без багов», и является стандартным решение (в случает спринга с небольшим числом стандартных имплементаций) при необходимости иметь быстрый доступ к некоторым данным.
Но нюансов много, от только ни автор, ни вы не привели каких бы то значемых уточнений :)

Есть ли методы убрать эти риски — есть конечно, можно написать сотни способов как избежать А, Б, В, Г, Д.

Снова же хотелось бы услышать (от автора) какую-то конкретику. Конкретные проблемы с конкретными решениями и ценой этих решений.

Какие оппоненты? Может сразу «врагам» или ещё чего-то похлеще придумать :)
Честно говоря, я не понимаю, что вы ждёте от этой беседы со мной и зачем вам вообще конкретика от автора, с таким настроем :)

Для справки: самый большой use case на этом проекте касался процесса отправки посылки и был описан клиентом на 90 страницах, разбит на почти столько же подкейсов, которые декомпозировали на порядка 1000 stories. За простой, на первый взгляд, работой лежит колоссальный объем функциональности, которая должна чем-то конфигурироваться.

как такое вообще возможно, кислое в желтое?

use case не должен превышать одной страницы alistair.cockburn.us/Use cases or Writing effective use cases by A. Cockburn or Software Requirements Engineering by K. Wiegers

Use case is a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system, to achieve a goal. The actor can be a human or other external system) 

Можно ли поинтересоваться что такое подкейсы и как Вы от Варианта использования перешли к декомпозиции на 1 000 user stories?
User story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.

После прочтения ... вот верите или нет — Тацит вспомнился
Который четко показал как описаниями подвигов скрывают провалы.
Не знаю как кому, но надо больше тех. подробностей, ровного и спокойного анализа решений, успехов и неудач.

Итак, основные факапы:
1) Использование реактивной модели там где она не подходит
2) Не настроили мониторинг производительности, учитывая, что 3 секунды изначально ставились как ключевое и почти бескомпромиссное требование
3) Отсутствие всегда рабочего окружения для тестов или демо
...которые привели, например, к потерянным 4-5 месяцам просто на то, чтобы внести ограничения на размер посылки и сумму доставки.

Я старался не передергивать, но именно так вы все и описали, пытаясь завуалировать разными «вдруг появилась проблема, мы начали её решать и таки выкрутились».

Чисто из интереса посмотрел в профиль линкедина автора-солюшен-архитекта и увидел вот такую картину: storage1.static.itmages.com/...​8_4259873_98afe122e7.jpeg. Два года после университета джава девом — и на всю последующую жизнь в тимлиды, СТО и архитекторы. Я не сторонник наездов на людей и конечно же могу ошибаться, но выглядит это как минимум подозрительно.

Думал не комментировать профиль автора, но раз уж пошла такая гречка). На сколько я знаю, то в Епаме не принято поднимать позицию в первый год работы в компании. Раньше это делалось по результатам ассестмента раз в полгода, теперь вроде как раз в год ну или в результате торга в формате: «А я вот сейчас уйду и у вас все поламается ну или кастомер сильно обидится» Обычно раньше поднимают под проект и если больше совсем никого другого нет. Есть конечно и другие кейсы, но мне кажется, что был именно такой. Вообщем история попахивает, собственно как и биография автора

Александр, вы не против вернуться к технологиям? Вас интересно читать, когда вы пишете именно о них.

nice try) если уж Вы занимаетесь маркетингом в Епаме, то попытайтесь донести до сотрудников, что если они упоминают имя компании в своих постах, то нужно пять раз подумать а потом еще раз подумать и дать кому-нибудь перечитать. А то собственно такие посты и портят имидж компании. Только люди начали забывать про клипы, так теперь все будут понимать какой уровень у архитекторов. Это еще хорошо, что клиенты такое не прочитают. А то тут и до веселенького.it недалеко

Архитектор поделился опытом и кейсом из реальной работы. Вы — сарказмом. Каждый делится тем, чем может.

Архитектор поделился опытом и кейсом из реальной работы.

Нет, «архитектор» набросал базвордов. При том скорее всего для ПиаРа себя и/или конторы.
Реальные кейсы не описаны, при том на просьбы уточнить автор не отвечает, а «белый рыцарь СТО» так же смог только водицы подлить вмето указания реальных проблем.

Вы — сарказмом.

Сраказ сарказмом. Но после прочтения статьи и некоторых людей сложилось впечатление что проблемы на проекте появились по вине сотрудников компании.
Подобные «водянистые статейки» заставляют __опытных специалистов__ с опаской смотреть на компанию, ибо демонстрируют низкие технические навыки людей которые рулили проектом.
Я не знаю как было в реальности, но у меня __сложилось впечатление__ что проект делали заленые «23-летние синьоры».

Я бы, на вашем месте, требовал проводить вычитку статей. Это сейчас не сарказм если что.

скорее всего для ПиаРа себя и/или конторы

Какой ужас! Разве так можно??? Нееет, себя надо всегда только ругать!

смог только водицы подлить вмето указания реальных проблем

В тюрьму неохота, наверное. Разглашение NDA наказуемо.

демонстрируют низкие технические навыки людей которые рулили проектом

Но заказ, и работу, и оплату в итоге получил ЕПАМ, а не ваши опытные специалисты с опаской.

Я этот проект видел в самом начале. Там очень сильные организационные проблемы. Просто из-за масштабов. Например хранение ПД по законам 200+ стран. (А если у юзера разные гражданства?) Локальные бизнес-процессы с локальными документами. Разные топы.
Уж вы-то конечно, левой ногой продавили бы сразу и готовую спеку на 1000 человеко-лет, и 10 датацентров, и хотелки заказчика бы зарубили.

Люди там были разные, в том числе и с 20-30 летним опытом.

Я что-то слышал про какие-то странные обычаи в российской тюрьме, но вашу мысль не понял. Вы хотите задать мне какой-то вопрос?

Какой ужас! Разве так можно??? Нееет, себя надо всегда только ругать!

Замечательно! Первая же фраза демонстрирует вас как демагога :)

В тюрьму неохота, наверное. Разглашение NDA наказуемо.

Если умному человеку нечего сказать, то он молчит. С другими людим не всегда так.

Но заказ, и работу, и оплату в итоге получил ЕПАМ, а не ваши опытные специалисты с опаской.

А у вас есть понимание того что ЕПАМ и «мои опытные специалисты» — это не конкуренты?
«Опытные специалисты» — это ресурс, который нужен ЕПАМу, чтобы после очередного «получения работы» не получит судовой иск.

Уж вы-то конечно, левой ногой продавили бы сразу и готовую спеку на 1000 человеко-лет, и 10 датацентров, и хотелки заказчика бы зарубили.

Наверное статью стоило писать вам. Вы явно не так боитесь попасть в тюрьму, как автор. :)
К слову, а у нас за розглашение НДА уголовная ответственность?

Ах да, только сейчас перечитал дисклеймер. Это ООО ПрофИТСофт значит продуктовая компания?) А путь от стажера до исполнительного директора значит длился аж джва года :)

Вечером мы подготовили environment, на котором все уже было настроено и работало, хотя в этот же момент еще идет активная разработка. За 20 минут до начала нужно убедиться, что все готово к презентации, но заготовленная среда не работала.

С тех пор вы используете контейнеры, правда?

Например, Play! Framework, который мы используем в одном из компонентов, не только дает реактивный подход к написанию бизнес-логики «из коробки», но и вносит сложности в имплементацию функциональности. Логика у нас последовательная, так как бизнес интересует end-to-end транзакция, а реактивный подход как раз предполагает событийную модель, поэтому инженерам и архитекторам пришлось придумывать способы

Звучит так, будто Вы использовали Play! только потому что это было модно и баззворд.

Тоже не понял, зачем использовать плей и именно его реактивный подход, если явно видите что это не подходит.

скорее всего чтобы быстрее наклепать mvp

Открою тайну всё даже проще не mvp а arf (Architectural and Requirements Framework). Это дока такая. С картинками. Вроде той которая «platforms/solutions».

Вовлечение многих людей обеспечило решение проблемы, которая на первый взгляд казалась нерешаемой.

В общем суть статьи: У нас были проблемы, мы их решали.
Ни капли конкретики. Одно что точно можна определить по статье — это то что у вас было много факапов, при том по информации в статье складывается впечатление, что по вине тех самых архитектора и ДМа.

Например:

Например, Play! Framework, который мы используем в одном из компонентов, не только дает реактивный подход к написанию бизнес-логики «из коробки», но и вносит сложности в имплементацию функциональности. Логика у нас последовательная,

Почему архитектор допустил использование Плея?
Если его использование было оправдано, то куда интереснее было бы почитать статью о юзкейсах которые он помог решить, чем про то «как космические корабли бороздят Большой Театр».

Почему архитектор допустил использование Плея?

Потому что архитектора не было был Solution Architect.

Который

... про то «как космические корабли бороздят Большой Театр».

Причем все проблемы создали сами сразу же на этапе планирования

Спасибо за рассказ. С удовольствием бы послушал в деталях, как вы решали те или иные проблемы. Мастеркласс не планируете ? )

А смысл, если по факту проект чуть не завалили))

@В конце разработки команду ждал еще один вызов

Ну, вам, наверное, смысла нет )

Так самый цимес и есть «систематическая ошибка выжившего».

поржал про 100 человек ввели в курс дела вечером и на следующий день все начали работать. Как это все в стиле Епама. Больше выглядит так, заказчик показал, что у него есть деньги, и это была его самая большая ошибка.)) Перформанс 3 секунды и 3 минуты, are you seriously? Угадайте кого нужно было гнать с проекта ссаной тряпкой. Выглядит так, что на перформанс изначально забили и собвстенно как и на интерграцию модулей. А потом получился «Ой, у нас тут падение скорости в 60 раз». Я так понимаю опытные специалисты это те, которые немного разбирались в Spring Integration? Почему выбрали Integration, а не скажем тот же Camel? Планировалось использовать SMB?

отвечу по существу: если вам интересно, что мы делаем на spring-integration, то можете почитать github.com/...​spring-integration-ftp.md.
Camel vs Spring Integration, имхо, можно холиварить бесконечно.
Последний вопрос я не понял.

опечатался, имел ввиду ESB в полном наборе (messaging + service orchestration). В Spring Integration это все быстрее настраивается. Поэтому и задаю вопрос почему выбрали Spring Integration. Я не думаю, что на внутреннем портале с рекомендуемыми технологиями Camel был ниже в рейтинге. Тут вопрос не холивара, а по каким параметрам отбирали? И в каком все таки месте потеряли с быстродействием?

Угадайте кого нужно было гнать с проекта ссаной тряпкой

Ну и технологии у вас в компании. Боюсь даже представить как вы поддерживаете рабочее состояние инструмента.

Просто автор так пишет, что такая классная связка вышла работы архитекторов и деливери менеджеров, что про управление рисками случайно забыли. Все так было классно, что интеграцию и performace check оставили на потом. Я конечно понимаю, что Епам нужно рекламировать, как там все классно. Но вот только лапшу на уши нет смысла вешать. Тут же все таки не совсем дети собрались.

И в чем был затык с перформансом?

больше всего премени мы потратили как раз на мониторинг, но сама проблема описана в соседней статье dou.ua/...​lumns/netty-optimization в рекомендации 2

То есть все таки зафакапили на интеграции модулей и оставили ее на потом. Все равно как-то странно, в соседней статье прирост производительности составил 15%, сколько тогда он составил у вас после фикса? Я так понимаю, что к требуемым 3 сек вы так и не приблизились?

Ну у вас и стиль общения :)

больше всего премени мы потратили как раз на мониторинг, но сама проблема описана в соседней статье dou.ua/...​lumns/netty-optimization в рекомендации 2

То есть вы утверждаете что ОпенССЛ повлек деградацию с 3 секунды в 3 минуты?
Очень интересно было бы послушать более подробный рассказ.
Ибо я, с ходу, могу придумать только один реалистичный сценарий (плюс пару фантастических) когда такое возможно — большое количество сетевых вызовов.
Но если это так, то проблема не описана в статье по ссылке, а проблема в архитектуре.

Во второй статье которая «технические детали оптимизации» они (они? непонятно но ссылаются) как раз пишут (т.е. дают данные но видимо не осознают) что с сетевой архитектурой у них там были огромные проблемы если исходить из факта что:

Первая и самая мощная оптимизация — это переключение на нативный epoll транспорт под Linux вместо Java реализации. В нашем случае мы получили прирост в 30 % сразу после переключения.

Конечно из контекста не вполне понятно «прирост 30%» относится ко всему приложению или только к транспортному сетевому стеку но если уж они взялись за такие оптимизации предположительно немаленького общего бизнес приложения (много юз-кейзов бла-бла-бла) то там уже изначально с ходу стало видно что есть так плохо что бросились «оптимизировать как могли».

Будучи «чуть чуть экспертом» (к) (тм) в вещах об которых речь могу подтвердить что «давайте используем boringssl» это сегодня одна из классических «припарок» аля «оптимизации х.вой реализации» чего-либо связанного с сетевым стеком.

ЗЫ: таки да «давайте добавим базвордов оптимизации». (к) (тм)

Знакомая картина. Масштаб только поменьше, но остальное — да. Аналогичные проблемы для выбора архитектурных решений. Ориентация на транзакции, события, машина состояний, куда все же бизнес логику привязать(отделить). Связка SA+DM. Автору — Hold Fast

Підписатись на коментарі