Чем отличаются монолит, модульный монолит и микросервисы

Представим приложение магазина. В нём есть заказы, каталог товаров и биллинг, который рассчитывает скидки и выставляет счета. Эти части связаны бизнес-логикой: для персональной скидки нужна сумма прошлых заказов, а при покупке нужно знать, есть ли товар на складе.

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

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

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

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

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

В микросервисной архитектуре части системы работают как самостоятельные сервисы. Заказы и биллинг можно развёртывать отдельно, выделять им разные ресурсы и разрабатывать силами разных команд. Для получения суммы заказов биллинг обращается к сервису заказов через API, получает ответ и использует его в расчёте.

Здесь появляется возможность выпускать изменения одного сервиса независимо от остальных, пока сохраняется совместимость взаимодействия. Вместе с ней возникает ответственность за контракт: сервис заказов должен возвращать данные в том виде, который понимает биллинг. Если изменение затрагивает обе стороны, командам нужно согласовать обновление.

Что меняется, когда вызов функции становится сетевым запросом

Вернёмся к персональной скидке. Биллинг должен узнать, на какую сумму пользователь сделал заказы за год. Пока логика находится в одном приложении, он может получить результат через внутренний вызов. В варианте с общей БД нужные данные доступны через запрос к ней.

После выделения заказов в сервис путь становится длиннее. Биллинг отправляет запрос к его API. Сервис заказов обращается к своей базе, формирует ответ и передаёт его обратно. Затем биллинг разбирает полученные данные и рассчитывает скидку.

На каждом таком переходе появляется дополнительная работа. Данные нужно подготовить к передаче и восстановить на другой стороне, дождаться ответа по сети, обработать результат. Эти расходы могут быть приемлемыми для одной операции. Если пользовательский запрос запускает длинную цепочку обращений, время ожидания начинает зависеть от всех её участников.

Например, страница профиля может собирать данные из нескольких сервисов. Тогда разработчику приходится выяснять, на каком участке задерживается ответ. Медленная работа одного сервиса способна задержать весь сценарий, который от него зависит. Физическое разделение компонентов сохраняет логические связи между ними.

Контракт API тоже становится частью работы. Если сервис меняет формат ответа, нужно учесть потребителей этих данных. Изменение, которое внутри монолита могло попасть в один релиз, в распределённой системе может потребовать обновления нескольких сервисов в согласованном порядке. При частых совместных изменениях ожидаемая независимость релизов сокращается.

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

Стоимость взаимодействия покажем на примере системы мониторинга качества видео Amazon Prime Video. Сначала она работала как распределённое решение на AWS Lambda и Step Functions. При увеличении нагрузки обмен данными и управление выполнением компонентов потребовали слишком больших расходов. Команда объединила систему в монолитное приложение, после чего расходы на неё снизились примерно на 90%.

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

Как масштабировать монолит и микросервисы

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

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

Однако увеличение числа обработчиков помогает в пределах возможностей остальных компонентов. Если все экземпляры сервиса заказов обращаются к одной перегруженной БД, она продолжит ограничивать обработку запросов. Поэтому перед изменением архитектуры нужно разобраться, где именно приложение упирается в доступные ресурсы.

Воркеры и очереди задач

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

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

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

Допустим, в очереди четыре задачи, а свободных воркеров три. Каждый возьмёт по одной задаче, оставшаяся дождётся первого освободившегося исполнителя. Если очередь регулярно растёт и вычисления позволяют распределить работу, можно увеличить число воркеров. Для этого достаточно масштабировать обработку фоновых задач в существующей архитектуре.

Ресурсы воркеров тоже могут различаться. Расчётам, которым нужно держать в памяти большой объём данных, выделяют больше памяти. Более лёгким задачам достаточно меньших ресурсов. Такой подбор применим и к монолиту, и к отдельным сервисам.

Чтение и запись в базе данных

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

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

Разделение по сервисам позволяет распределить запись между разными базами, когда данные принадлежат разным частям системы. При этом сильно нагруженная база конкретного сервиса всё равно может потребовать масштабирования. Оценивать нужно каждый участок, на котором сосредоточена работа.

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

Что усложняется при разделении данных между сервисами

Заказы связаны с товарами независимо от того, где выполняется код. Если обе сущности хранятся в общей реляционной БД, данные о них можно соединить запросом с JOIN. База выполняет связанную операцию, а приложение получает результат.

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

Поэтому перед выделением компонента полезно проследить, какие сведения нужны ему для обычной работы. Если почти каждый расчёт биллинга требует обращения к заказам, а затем к товарам, эти зависимости войдут в стоимость нового сервиса. Само разделение сохранит потребность в данных соседних частей.

Более сложный вопрос возникает, когда операция меняет данные сразу в нескольких местах. Допустим, покупатель оформляет заказ, а система должна зарезервировать товар на складе. Запись о заказе и доступный остаток должны соответствовать друг другу. Если товар уже закончился, приложение должно корректно обработать эту ситуацию.

При выполнении связанных изменений внутри одной БД можно использовать общую транзакцию. Она позволяет применить предусмотренные изменения вместе или отменить их при неудаче. Разработчик описывает операцию с учётом возможностей и правил работы выбранной базы.

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

Один из подходов к такому согласованию называется Saga. Общую операцию описывают как последовательность шагов с действиями на случай неудачи. Для заказа и резервирования потребуется продумать, как система поступит, если выполнить весь сценарий не удалось. Эти правила становятся частью прикладной логики и требуют отдельной проверки.

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

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

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

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

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

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

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

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

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

Наконец, проверьте требования к данным и времени ответа. Если пользовательский сценарий требует частых синхронных обращений между частями системы, сетевое взаимодействие войдёт в его стоимость. Если операция меняет тесно связанные данные, нужно заранее оценить сложность согласования этих изменений после разделения.

Чтобы обсудить решение на конкретных примерах, команда может ответить на несколько вопросов:

• Какие части приложения обычно меняются вместе и почему им нужен общий релиз?
• Какая функциональность требует самостоятельного масштабирования и где именно возникает нагрузка?
• Какие данные потребуются выделенному сервису для выполнения обычной операции?
• Кто будет отвечать за его развёртывание и разбирать проблемы в эксплуатации?
• Можно ли разрабатывать и проверять этот сервис, запуская только необходимые ему компоненты?

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

Как понять, что компонент готов стать отдельным сервисом

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

Для выделения нужен компонент с понятной самостоятельной обязанностью. Его должно быть возможно описать через выполняемую работу и необходимые данные. Полезно заранее проследить основные сценарии: какие запросы приходят на вход, откуда берётся информация для их обработки и кому потребуется результат.

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

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

Затем нужно сопоставить ожидаемую пользу с работой по переносу. У компонента появится собственное развёртывание, его взаимодействие с остальным приложением потребуется организовать и проверить. Если выделяются данные, отдельно планируют согласование операций, которые раньше выполнялись внутри одной БД.

Для существующего проекта такие изменения входят в более широкую работу по модернизации ПО. Centicore Group занимается обновлением легаси-кода, баз данных и инфраструктуры; в услугу входят рефакторинг и обновление технологического стека. Если команда планирует переработку работающей системы, можно обсудить её модернизацию с Centicore Group.

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

Итого

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

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

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

Идемпотентность — свойство операции, при котором повторное выполнение приводит к тому же состоянию, что и однократное. Сам ответ при этом может отличаться: повторный DELETE вернёт 404 вместо 200, и метод от этого идемпотентным быть не перестаёт. У HTTP это закреплено на уровне методов: RFC 9110 относит к идемпотентным PUT, DELETE и безопасные методы, а POST идемпотентным по своей природе не является. Бизнес-операции почти всегда отправляют именно через POST.

Клиент не может отличить «сервер не получил запрос» от «сервер выполнил операцию, но ответ потерялся», поэтому повтор придёт в любом случае.

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

Проверка «посмотреть и вставить» неатомарна: два одновременных повтора оба увидят отсутствие ключа. Нужен уникальный индекс или условная запись.

Запись в базу и отправка в очередь в одну транзакцию не помещаются. Обёртывать сетевой вызов в BEGIN и COMMIT вредно вдвойне: корректности не даёт, а пул соединений выедает.

Transactional outbox решает это одной таблицей: событие пишется в той же транзакции, что и бизнес-запись, а отдельный процесс доставляет его в очередь.

Почему повтор неизбежен

Сеть отказывает так, что установить факт доставки невозможно в принципе. Есть три типовых сценария, и внешне они неразличимы:

• Сервер обработал запрос, но ответ потерялся по дороге назад.
• Сервер всё ещё считает, а у клиента уже сработал таймаут.
• Балансировщик повторил запрос сам, никого об этом не уведомив.

Для GET повтор безвреден. Для POST /payments это второе списание. Отсюда и правило: одна логическая операция должна приводить к одному записанному итоговому состоянию, сколько бы раз её ни отправили. Осознанно новая операция обязана прийти с новым ключом.

Два способа сделать ручку идемпотентной и один в довесок

Способ первый: ключ идемпотентности

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

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

И последнее: повтор должен получить тот же самый ответ. Если первая попытка вернула 201 с идентификатором платежа, то и повтор возвращает те же 201 и тот же идентификатор, а не 409 и не пустую двухсотку. Иначе клиент решит, что операция не прошла, и попробует ещё раз.

Способ второй: сделать операцию идемпотентной по смыслу

Иногда ключ не нужен вовсе, потому что семантику можно спроектировать идемпотентной с самого начала. Классический пример — PUT /users/42, который задаёт полное представление ресурса: отправьте его дважды, и состояние будет одним и тем же.

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

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

Довесок: оптимистичная блокировка

Этот приём идемпотентности не даёт и в списке стоит по другой причине. Ключ защищает от повторов одного и того же запроса, но ничего не делает с двумя разными запросами, которые правят одну запись. Здесь работает проверка версии: клиент присылает версию, которую видел, а сервер отклоняет обновление при несовпадении.

Обратите внимание, что проверка версии живёт внутри самого UPDATE. Разнести её на отдельное чтение и последующую запись означало бы воспроизвести ровно ту гонку, о которой пойдёт речь в следующем разделе: два запроса с одной устаревшей версией оба прошли бы проверку и оба записали бы результат. Идемпотентным одиночный запрос этот приём не делает, зато закрывает частый источник задвоенных эффектов: двух писателей, затирающих работу друг друга.

Где наивная реализация ключа разваливается

Гонка в проверке

Последовательность «проверить наличие ключа, потом вставить» содержит зазор, в который помещаются оба одновременных повтора: обе стороны видят, что ключа нет, и обе выполняют работу. Резервировать ключ нужно атомарно, через уникальное ограничение базы, условную запись или транзакционный compare-and-set (атомарное сравнение с записью).

Это же относится и к примеру с платежом выше: замена словаря в памяти на Redis гонку не закрывает, пока проверка и вставка остаются двумя отдельными командами. Нужен атомарный примитив резервирования, вроде SET key value NX или INSERT ... ON CONFLICT DO NOTHING.

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

Слепок запроса, а не только ключ

Хранить один ключ недостаточно. Сервер канонизирует поля, определяющие бизнес-смысл операции, и считает от них хеш. Канонизация означает приведение к единому виду порядка полей, форматов чисел и дат, опущенных значений по умолчанию и незначащих пробелов. Если повторный вызов обязан воспроизвести решение, принятое по прежним правилам, в слепок включают ещё и версию политики. Пример: между первой попыткой и повтором поменялись тарифы, и повтор обязан вернуть старую цену, а не пересчитать по новой. Без версии в слепке сервер этого различия не увидит.

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

Состояния и коды ответа

Минимальная модель состояний записи выглядит так: PROCESSING, SUCCEEDED, FAILED_RETRYABLE и FAILED_FINAL. Рядом хранятся ключ операции, слепок, отметки времени, идентификатор решения, снимок ответа и версия политики. Клиенту нужна детерминированная карта из состояния в код ответа:

• 201 или 200 — первый успешно завершённый результат.
• 200 с явной пометкой о повторе — проигрывание сохранённого ответа.
• 202 со ссылкой на статус — работу уже выполняет другой обработчик, начинать вторую не нужно.
• 409 — ключ переиспользован с другим содержимым.
• Задокументированная финальная ошибка — обработка провалилась, и автоматическое продолжение небезопасно.

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

Вторая половина задачи: база и очередь

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

Обе половины статьи растут из одного факта: ни HTTP, ни очередь не обещают доставку ровно один раз, они обещают её хотя бы один раз. Поэтому защищаться приходится дважды, на входе и на выходе.

Это две записи в две разные системы, и общей транзакции у них нет. Упал процесс, моргнула сеть, выкатился деплой между двумя вызовами — одна сторона зафиксирована, вторая нет. Заказ подтверждён на экране покупателя, а склад о нём не знает. Ошибка при этом нигде не залогирована и алерт не сработал.

Почему обернуть это в транзакцию нельзя

Соблазнительный и заведомо неверный вариант выглядит так:

Транзакция базы не имеет власти над очередью и умеет откатывать только операции базы. Если отправка прошла, а COMMIT упал, сообщение уже в очереди и забрать его оттуда нельзя.

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

Outbox: событие как строка в той же транзакции

Идея паттерна в том, чтобы перестать считать публикацию второй записью. Вместо вызова очереди приложение вставляет строку в таблицу outbox в той же транзакции, что и бизнес-запись. Отдельный процесс читает таблицу и публикует сообщения дальше.

Откатилась транзакция, и вместе с ней исчезла строка outbox: осиротевшего сообщения в очереди не осталось. Упало приложение сразу после фиксации — строка на месте со статусом pending, и доставщик заберёт её на следующем проходе. Паттерн опирается ровно на одну гарантию, которую база и так даёт: атомарность одной транзакции.

Доставщик выбирает пачку необработанных строк и помечает их отправленными только после подтверждения очередью. Ключевая деталь здесь одна:

Этот SELECT и последующая простановка статуса выполняются в одной транзакции: блокировка живёт до фиксации. Благодаря SKIP LOCKED доставщик масштабируется горизонтально из коробки, каждый экземпляр берёт свой набор строк. А если он упадёт посреди пачки, вся пачка откатится и уйдёт повторно, что даёт ещё один довод в пользу идемпотентного потребителя.

Может показаться, что здесь мы делаем ровно то, что осудили выше: держим блокировку на время сетевого вызова. Разница в том, что блокируется не бизнес-таблица и соединение берётся не из пула, обслуживающего пользовательские запросы, а SKIP LOCKED не даёт одной медленной строке задержать остальные.

Потребитель обязан быть идемпотентным

Если доставщик упал посреди прохода, на следующем он переотправит те же строки. Очереди вроде SQS и Kafka в типовой конфигурации гарантируют доставку «хотя бы один раз», поэтому дедупликация на приёмной стороне обязательна, и уникальным ключом служит идентификатор события или решения.

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

Настройки продюсера и подтверждения брокера снижают количество повторов, но не снимают с приложения ответственность за однократность бизнес-эффекта.

Что добавить перед продакшеном

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

Когда задержка опроса становится критичной, полагающийся на периодический опрос доставщик заменяют захватом изменений: инструменты вроде Debezium читают журнал предзаписи PostgreSQL и публикуют изменения без паузы на опрос. Таблица outbox и потребитель при этом не меняются. Но это заметно более тяжёлое эксплуатационное обязательство, поэтому начинать почти всегда стоит с опроса.

Что забрать с собой

Обе части задачи выглядят избыточными ровно до первого инцидента. Тридцать строк кода с ключом идемпотентности стоят дешевле одного тикета с заголовком «вы списали дважды», а таблица outbox дешевле расследования, почему заказ есть у клиента и отсутствует на складе.

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

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

Материалы, на которых основан разбор: три паттерна идемпотентности с рабочим кодом, проектирование ручек, переживающих реальные повторы и пошаговая сборка outbox на Node.js.

Откройте самый денежный обработчик в своём сервисе и попробуйте отправить в него один и тот же запрос дважды. Если во второй раз что-то произошло, вы уже знаете, с чего начать понедельник.

Всё это принято называть обвязкой, и определение у неё простое.

Обвязка — это весь код между тем, что вы печатаете, тем, что получает модель, тем, что модель выдаёт, и тем, что вы видите. И это много кода, не имеющего отношения к ИИ. Модели при этом выглядят в значительной степени взаимозаменяемыми.

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

Обвязка — это код без единой нейросети внутри: сборка запроса, управление контекстом, проверки на выходе и координация нескольких моделей.

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

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

Пять источников почти всех сбоев одни и те же: процессор, память, диск, ввод-вывод и сеть. С них и начинают автоматические проверки.

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

Слой первый: что и где считать

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

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

Из того же наблюдения следует острый вывод, который Шнайер делает применительно к безопасности: раз возможности моделей широко доступны и во многом взаимозаменяемы, экспортные ограничения и закрытие доступа их не сдержат. Реальные риски он видит в другом: в концентрации корпоративной власти, в слабой целостности моделей и в плохо устроенных стимулах. Для инженера это переводится в практическое требование — проверять заявления поставщика и не полагаться на то, что выбор конкретного вендора сам по себе что-то гарантирует.

Слой второй: страховка надёжности в конвейере

Оговорка сразу: это уже не обвязка вокруг обращения к модели, а обвязка процесса поставки. Принцип тот же, объект другой: проверяется не ответ модели, а код, который агент написал и который вот-вот уедет в продакшен.

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

Аналогия с гонками здесь уместнее обычного: на малой скорости из заноса выходят легко, на большой одна ошибка стоит несопоставимо дороже. Отсюда идея автоматических проверок надёжности Колтона Эндруса: замкнутых циклов, которые безопасно создают настоящие условия отказа, проверяют устойчивость, предлагают исправление и перепроверяют его после внесения.

Почему чтения кода недостаточно

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

Для сгенерированного кода это верно вдвойне. Статический анализ доводит до определённой черты, но не отвечает на главный вопрос: что произойдёт, когда отвалится кеш или вырастет задержка у зависимости. Правильное поведение здесь описывается заранее (скажем, при недоступности кеша сервис обязан уйти в основную базу), и проверка сводится к тому, соблюдает ли кандидат уже существующую политику.

Пять ресурсов, с которых начинают

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

• Избыточность по зонам и узлам: что происходит при отказе целой зоны, отдельного хоста или контейнера.
• Масштабирование по процессору: корректно ли настроено расширение при всплеске и сворачивается ли оно обратно после.
• Масштабирование по памяти: то же самое, включая корректную деградацию, если расшириться не удалось.
• Отказ зависимости: как ведёт себя приложение, когда до внешнего или внутреннего сервиса не достучаться.
• Задержка зависимости: сервис доступен, но отвечает медленно. Приложение деградирует аккуратно, уходит к запасному источнику или просто падает.

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

Результат проверки возвращается агенту

Ставится это всё в конце конвейера сборки, прямо перед продвижением версии. Провалилась проверка — код помечается и уходит обратно вместе с описанием теста и предложенным исправлением.

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

Слой третий: границы информации

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

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

Что показали измерения

Шнайер разбирает две работы на эту тему. Первая описывает бенчмарк CIMemories: синтетические профили пользователей больше чем со ста атрибутами каждый и набор задач, в которых один и тот же атрибут для одних задач необходим, а для других неуместен.

Результаты неутешительные. Передовые модели показывают до 69% нарушений на уровне отдельных атрибутов, то есть раскрывают их там, где раскрывать не следовало. Снижение доли нарушений при этом обычно достаётся ценой полезности: модель становится осторожнее и хуже решает задачу.

Ещё важнее динамика. Нарушения накапливаются и по числу задач, и по числу прогонов: при росте использования с одной задачи до сорока доля нарушений у GPT-5 поднимается с 0,1 до 9,6%, а при пятикратном исполнении одного и того же промпта достигает 25,1%. Последняя цифра особенно неприятна: она означает нестабильное поведение, когда на идентичный запрос модель раскрывает разные атрибуты.

Почему просьба быть осторожнее не помогает

Естественная реакция инженера — добавить в системный промпт указание бережно относиться к персональным данным. Измерения показывают, что это не работает: модели переобобщают и начинают выдавать либо всё, либо ничего, вместо того чтобы принимать решение с учётом контекста.

Вывод авторов прямой: проблема не решается ни лучшим промптингом, ни увеличением масштаба модели, потому что требуется собственно рассуждение о контексте, в котором система сейчас работает.

Что действительно даёт эффект

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

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

Что забрать с собой

Три слоя выглядят разнородно, но подчиняются одному правилу: свойство, которое вам нужно от системы, обеспечивается кодом вокруг модели, а не выбором модели. Маршрутизация даёт цену и приватность инфраструктуры: данные не покидают периметр. Автоматические проверки отказов дают устойчивость. Явный контроль границ информации даёт приватность самих данных пользователя, независимо от того, где физически стоит модель.

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

Материалы разбора: интервью Шнайера об обвязке и локальных моделях, проверки надёжности в конвейере с ИИ-кодом и обзор двух работ о контекстной целостности.

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

• Работа arXiv:2608.26263, авторы Санкет Бадхе, Приянка Тивари и Чонхён Чон из Google LLC и Purdue University; по пометке авторов на arXiv, принята на EMNLP.
• На каждом шаге модель видит только инструкцию навыка, текущее JSON-состояние и последнее наблюдение; патч состояния проверяется, рассуждение после шага отбрасывается.
• SkillExecBench (среда Warehouse Management) на Gemini 3 Flash: при 100 шагах 65 тысяч токенов против 1,25 млн у ReAct при точности 94% против 84%; при 200 шагах 122 тысячи против 6,2 млн у агента с памятью-сводкой.
• При равном бюджете около 1 800 токенов на запрос простое усечение даёт точность 18%, LLMLingua 22%, SKILL.state 94%.
• Ограничения: схема состояния задаётся заранее; задачи, где нужна сама история (аудит, объяснение действий), методу не подходят; один агент; публичного репозитория нет; на Gemma-4-31B и Qwen-3-8B при 100 шагах точность 42% и 34% против 94% у Gemini 3 Flash.

Как это устроено

Обычный агент в стиле ReAct на шаге t получает весь журнал: системный промпт, все прошлые команды, все ответы инструментов и свои рассуждения. Суммарно за T шагов это O(T²) токенов, потому что каждый шаг перечитывает всё предыдущее. В SKILL.state промпт шага состоит из трёх частей, размер которых не зависит от номера шага при условии, что состояние и наблюдение ограничены по объёму: спецификация навыка P (что агент умеет и как должен себя вести), структурированное состояние Σ (JSON с тем, что важно для задачи) и последнее наблюдение O. Модель отвечает рассуждением, JSON-патчем к состоянию и действием; патч детерминированно проверяется и применяется, рассуждение после этого выбрасывается, действие исполняется.

Патч применяется операцией слияния: новые ключи добавляются, существующие перезаписываются, значение null удаляет ключ. Итог — суммарные затраты O(T) по токенам, а размер одного промпта почти не растёт: в экспериментах он держался в диапазоне 1 736–1 905 токенов при горизонте от 10 до 200 шагов. Схема состояния пишется один раз на домен, а не на задачу: для всех 100 задач InterCode CTF агент использовал одну статическую схему из пяти полей — найденные флаги, проверенные гипотезы, активные файлы, рабочий каталог, сводка команд.

Цифры из работы

Основной эксперимент — SkillExecBench, среда Warehouse Management: симуляция склада с длинными последовательностями действий, модель Gemini 3 Flash, пять случайных сидов, температура 0. При 100 шагах ReAct потратил 1 245 413 токенов при точности 0,84, baseline с явным состоянием в стиле LangGraph — 1 062 387 токенов и 0,91, SKILL.state — 65 408 токенов и 0,94. При 200 шагах агент с памятью-сводкой (Memory) ушёл в 6 175 509 токенов при точности 0,84, а SKILL.state уложился в 122 384 токена при 0,94. Именно отсюда «в 50 раз меньше» из пересказов; в дополнительном эксперименте с репозиторием кода при 100 шагах разница составила 1 848 500 против 90 200 токенов.

Авторы связывают выигрыш в точности не с сокращением текста, а с тем, что состояние сохраняет отношения между сущностями: какой шаг уже выполнен, что заблокировано, что кому должно. Два результата важнее заголовочных. Первый: при одинаковом бюджете около 1 800 токенов на промпт обычное усечение истории дало точность 0,18, сжатие через LLMLingua — 0,22, а SKILL.state — 0,94. Второй: в тесте с 50 нерелевантными событиями на каждом шаге обычный агент упал до 0,53, а SKILL.state удержал 0,98, потому что шум не попадает в состояние. После внешнего изменения среды и корректирующего уведомления SKILL.state в трёх сценариях из четырёх восстанавливался за 0 шагов, остальные подходы ошибались ещё 5–8 шагов; со сценарием отменённого заказа не справился никто.

На более привычных бенчмарках выигрыш скромнее, но есть: на InterCode CTF 54,2% Pass@1 против 43,2% у ReAct и 41,8% у Stateful, на τ-Bench Retail 58,3% и Airline 32,4% при снижении токенов до 3,47 млн и 2,88 млн соответственно.

Чего в работе нет

Ограничения авторы называют сами. Метод предполагает, что всё важное для будущих шагов можно вовремя записать в заранее заданную схему состояния: если структура задачи заранее неизвестна, если значимость детали осознаётся позже или если нужна сама история (аудит, происхождение данных, объяснение действий), подход не подходит. Второе: реализация рассчитана на одного агента, для нескольких понадобится разрешение конфликтов при одновременных записях в состояние. Третье: архитектура не привязана к Gemini, но качество сильно зависит от модели: при 100 шагах Gemini 3 Flash дала точность 0,94, Gemma-4-31B-it — 0,42, Qwen-3-8B-it — 0,34. Четвёртое, практическое: публичного репозитория авторы на 1 сентября не указали, хотя в статье есть промпты, псевдокод рантайма и детали реализации.

Что можно повторить у себя

• Опишите для своей задачи схему состояния из полей, которые реально нужны для следующего шага, и просите модель возвращать патч к ней, а не свободный текст; авторам для CTF хватило пяти полей.
• Отбрасывайте рассуждения модели после шага: они нужны для выбора действия, а не для памяти.
• Передавайте только последнее наблюдение целиком; всё, что из прошлых наблюдений имеет значение, должно уже лежать в состоянии.
• Заведите тест на шум: подмешивайте в наблюдения нерелевантные события и смотрите, не тащит ли агент их в состояние.
• Не ждите тех же 50 раз: в статье это симуляция склада на Gemini 3 Flash; на τ-Bench экономия заметно меньше, и ваш случай ближе ко второму.

Контекст

Идея держать в контексте состояние вместо истории не нова: похожие приёмы есть в LangGraph и в собственных рантаймах команд, которые строят агентов в проде. Вклад работы в том, что она измеряет разницу на длинных горизонтах и сравнивает с методами сжатия при равном бюджете. Обсуждения на Hacker News и в блоге Google Research на момент публикации нет; следующий сигнал — появится ли код или воспроизведение на других моделях.

Источники: SKILL.state: Scalable Long-Horizon Agent Skills (arXiv:2608.26263), Пересказ vc.ru

Изображение на обложке: Google

Пройдёмся по дорожной карте:

• Архитектор решений — кто это?

• Чем занимается архитектор решений и какие границы ответственности?

• Откуда приходят архитекторы решений?

• Откуда брать знания?

• Что ждет на собеседовании?

• Как пережить онбординг?

• Как проходит первый год архитектора решений?

• Какой рабочий день архитектора решений?

• Какие перспективы у архитектора решений?

Архитектор решений — кто это?

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

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

Все архитекторы относятся к подразделению информационных технологий, но видят ИТ ландшафт предприятия по-разному.

• Корпоративный архитектор видит ИТ ландшафт всего предприятия, понимает направления долгосрочного развития и вносит изменения, влияющие на инфраструктуру всего ландшафта в долгосрочной перспективе (3-5 лет).

• Архитектор решений видит ИТ ландшафт всего предприятия и проектирует решения в рамках задач бизнес-направления, за которым он закреплен, строго в соответствии с долгосрочной стратегией развития ИТ ландшафта в целом. Понимает цели и задачи бизнеса и предлагает решения, в соответствии с которым производятся изменения ИТ ландшафта в ближайшей перспективе (около года).

• Системный архитектор занимается развитием одной или нескольких систем: отвечает за правильную, масштабируемую архитектуру на более детальном уровне. Архитектор системы ближе к технологиям и ПО: применяемым базам данных, использованию правильных брокеров очередей, правильному проектированию api доступа и другим техническим деталям систем.

• Технический архитектор — отвечает за оборудование, сервера, техническое обеспечение всего, что необходимо для функционирования ИТ ландшафта.

Каждый архитектор на своем уровне контролирует правильное развитие ИТ ландшафта той области, которая находится в его зоне ответственности.

Чем занимается архитектор решений и каковы границы его ответственности?

В поле зрения архитектора решений находится весь ИТ ландшафт банка и понимание о функциональных границах всех систем.

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

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

Вторая основная задача архитектора — разложить все требуемые функции по правильным системам.

После анализа бизнес-требований и выявления функций архитектор решений распределяет их по системам. Если для выполнения тех или иных функций требуется разработка новой системы или модуля, архитектор решений прорабатывает этот вопрос с корпоративным архитектором и согласовывает появление модуля или системы в ИТ ландшафте предприятия.

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

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

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

Результатом работы архитектора решений является документ - проект решения, или как мы его называем архитектурный вижен. Что в него входит?

№1. Диаграмма, на которой изображаются:

• состав систем, которые задействованы в решении бизнес-задачи;
• бизнес-данные, которые передаются между системами;
• интеграционные потоки между системами;
• протоколы и способы интеграций.

№2. Диаграмма процессов и функций, которые задействованы в решении:

• изменения бизнес-процессов;
• изменения функций систем;
• роли, задействованные в бизнес-процессах.

Архитектурный вижен — верхнеуровневый взгляд на то, как изменится ИТ ландшафт предприятия при реализации бизнес-задачи и что нужно сделать, чтобы эту задачу реализовать. Это не проект по факту реализации, это концепт, который уточняется на более позднем этапе разработки. В TOGAF это фаза preliminary.

Откуда приходят архитекторы решений?

Попасть в архитекторы можно из различных отраслей и должностей.

К нам приходят руководители структурных подразделений различных компаний, руководители разработки, руководители продуктовых команд, аналитики из государственных компаний, из компаний интеграторов, и компаний разработчиков ПО.

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

Где брать знания?

Архитектор решений прежде всего практик. Особенно ценны практические знания и опыт в следующих областях:

• реализации крупных высоконагруженных проектов в банковской сфере;
• практический опыт применения различного программного обеспечения и обоснование выбора технологических платформ;
• опыт работы в интеграционных проектах.

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

Очень пригодятся знания технологических платформ, например:

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

• базы данных, их отличия и варианты использования;

• средства и способы защиты каналов связи;

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

Чего ждут на собеседовании?

Первый этап при любом трудоустройстве – техническое интервью. Чтобы попасть на техническое интервью резюме кандидата должно заинтересовать. Что привлекает внимание в резюме:

• Опыт работы в банковской сфере. Это не обязательный, но крайне желательный, опыт, который необходимо отразить в резюме, если он есть. При этом не обязательно работать в банковской сфере, подойдет и опыт работы с банками (например, совместные проекты или работа на проекте). Если такой опыт есть, его обязательно надо указать в резюме.

• Образование. Базовое образование архитектора решений – техническое. Приветствуется опыт работы с ПО в роли разработчика, специалиста по сопровождению или любая другая техническая роль, которая имеет возможность на практике освоить работу различных приложений.

• Опыт работы на руководящих позициях. Его не должно быть ни много ни мало. Управленцу, не имеющему практического опыта и навыков работы с программным обеспечением, будет сложно договариваться, потому что иногда нужно понимать проблемы команд и систем и предлагать решения исходя из собственного опыта.

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

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

Советы по прохождению технического интервью:

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

Если вам дали практический кейс, подумайте, какой информации не хватает для принятия решения и почему. Архитектор — специалист высокой квалификации. Он должен уметь выяснять все, что необходимо для решения поставленной задачи.

Что категорически нельзя делать на собеседовании:

• Подсматривать или «незаметно» искать ответы на вопросы во время собеседования. Это всегда заметно и скорее всего больше навредит, чем поможет. Все вопросы на опыт, а не на теорию. Всегда можно честно признаться, что вы чего-то не знаете, и пусть работодатель принимает решение насколько отсутствие этих навыков критично. Честность иногда полезнее, чем ответ на вопрос.
• Использовать ИИ или другие программы, которые помогут вам с ответами на вопросы. Искусственный интеллект может помочь с теорией, но, если вы справляетесь с теорией, вы также должны хорошо решать и практические примеры или кейсы, в который надо применять опыт. Если одно с другим не стыкуется, значит работать вы все равно не сможете на этой позиции. Архитектор решений прежде всего практик.

Как пережить онбординг?

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

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

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

• Изучение процессов. Огромная библиотека процессов и информация о том, как надо работать. Знание процессов очень помогает в работе, так как всегда понимаешь, как надо поступить в той или иной ситуации.
• Блок знакомства. Архитектор знакомится с ИТ лидером, с корпоративным архитектором и руководителями проекта. С бизнес-подразделением архитектор знакомится в процессе работы.

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

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

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

После завершения онбординга архитектора решений ждет проверка знаний.

Что входит в проверку:

1. Технические вопросы. Для архитектора важно поддерживать знания об актуальном стеке технологий, применяемых в проектах, актуальные знания о способах интеграций, протоколах передачи данных, а также актуальные знания о программном обеспечении, которое есть на рынке, и вариантах его применения.
2. Знание процессов. Без этих знаний архитектор не сможет работать. Процессы надо знать во всех нюансах и вариантах их применения, чтобы в любой ситуации архитектор мог принимать правильное решение.
3. Знания паттернов.
4. Знания технологического ландшафта.

Как проходит первый год архитектора решений?

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

Задачи в беклоге могут быть разные по степени проработки — главная задача архитектора следовать процессам и вместе с ИТ лидером работать с приоритетами.

Уметь работать по процессам в данной ситуации — один из основных навыков который приобретается на ранней стадии. Что важно помнить:

• Всегда нужно фиксировать вопросы и ответы, которые появляются к требованиям. Некоторые ответы могут сильно изменить архитектуру.

• Переключаться между задачами разных приоритетов — это то, что придется делать постоянно.

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

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

• Архитектуру надо прорабатывать так, чтобы всегда можно было открыть документ и понять какие изменения нужно сделать.

Основная задача бизнеса — сделать как можно лучше для клиента. Если в процессе работы над задачей бизнес поймет что фича должна выглядеть совершенно по-другому бизнес без колебаний полностью переделают требования даже если задача выполнена и готова к установке в промышленную среду.

Полезный навык, который помогает в работе архитектора — умение управлять ожиданиями. Если внесение незначительного изменения в требования приводит к существенным изменениям в проект, нужно сразу же достаточно четко донести этот факт всем заинтересованным стейкхолдерам с объяснениями причин. Формировать неоправданные ожидания у стейкхолдеров это практически преступление для архитектора решений.

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

Каков рабочий день архитектора решений?

Если в начале онбординга рабочий день архитектора выглядит вот так:

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

Почему так происходит?

Архитектора решений активно привлекают на встречи для решения как задач бизнеса так и задач развития архитектурных практик. Везде командная работа. Задачи бизнеса приходят постоянно, архитектор берет задачу из бэклога и анализирует требования. Если требования не полные мы фиксируем вопросы и берем следующую задачу. После уточнения требований бизнес уже не ждет и приходится уже участвовать в 2 х, 3х, 4х проектах одновременно. После того как архитектура готова архитектор консультирует команды на этапе архитектурного надзора, когда проект начинает реализовываться.

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

Каковы перспективы архитектора решений?

Рано или поздно архитектор задается вопросом о том, куда можно вырасти. Стоит сразу отметить, что рост архитектора не такой динамичный и бурный как у разработчика, или аналитика в силу того, что изначально архитектор человек уже с большим опытом. Чем дольше архитектор работает в Альфа-Банке, тем лучше он знает ландшафт предприятия, тем выше его ценность.

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

Второй путь роста — попробовать себя в одном или нескольких направлениях развития архитектурных практик: развить методологию или поучаствовать в разработке нового инструмента. По согласованию с руководителем и при наличии возможности можно взяться за лидирование практик. Это позволит развить навыки проектного управления и ведения проекта.

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

Четвертое направление — стать корпоративным архитектором. Деятельность корпоративного архитектора совершенно иная в силу повышенного масштаба и уровня ответственности за решения.

Инструменты и процессы постоянно совершенствуются и меняются, вносят в нашу жизнь много яркого и позитивного. IT ландшафт тоже меняется, растёт, развивается вместе с бизнесом. Структура бизнеса живет невероятной жизнью, которая неразрывно связана с жизнью архитектора решений. Высокие скорости принятия решений умноженные на масштаб предприятия делают жизнь архитектора решений в Альфа-Банке действительно невероятной.

Сначала понять, нужно ли трогать систему

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

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

Поэтому начинают с проблемы:

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

Всё это можно измерить, проверить и объяснить бизнесу. Дальше — варианты.

1. Оставить систему как есть

Иногда самое разумное решение состоит в том, чтобы ничего не менять.

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

Следить за ней всё равно придётся. Обновления безопасности нужно ставить, резервные копии проверять, а документацию по запуску, интеграциям и восстановлению держать в актуальном состоянии.

Заранее стоит договориться, какое событие станет сигналом к началу модернизации. Например:

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

Пока ничего из этого не случилось, систему оставляют в текущем виде.

2. Вывести ненужную часть из эксплуатации

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

Сначала придётся разобраться с зависимостями, потому что команда может просто не знать, что модуль дёргают соседние сервисы или другой отдел. Перед отключением стоит:

• проверить логи и запросы к компоненту;
• найти связанные сервисы и задания;
• узнать, какие команды пользуются его данными;
• подготовить способ быстро вернуть его обратно.

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

3. Обновить стек без смены архитектуры

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

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

Просто поменять номер версии в конфиге обычно не получается, потому что старые библиотеки отказываются работать с новым фреймворком, а часть API меняется или исчезает вовсе. Поэтому сначала собирают список зависимостей и смотрят, что из этого вообще можно обновить.

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

Проблемы самого монолита при этом никуда не денутся: если модули сильно связаны между собой или приложение плохо масштабируется, одним обновлением стека дело не обойдётся.

4. Перенести систему на другую платформу

Здесь код приложения почти не меняют, меняется место, где оно работает. Например, систему можно перенести с физических серверов на виртуальные машины или в облако. Другой вариант — запустить приложение в контейнерах. Архитектура при этом остаётся прежней: монолит не превращается в набор микросервисов.

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

Такой перенос сам по себе не ускоряет приложение. Если проблема находится в коде или базе данных, смена инфраструктуры её не решит. Зато команда может отказаться от устаревших серверов и упростить дальнейшую поддержку системы.

Старую среду лучше отключать только после проверки новой. Если при запуске возникнут ошибки, трафик можно будет вернуть обратно.

5. Заменить готовым продуктом

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

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

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

Отдельно разбираются с данными: что переносить, в каком формате и как проверить результат. Старую систему держат включённой, пока пользователи не начнут работать в новой, а данные и интеграции не пройдут проверку.

6. Рефакторить по частям

При рефакторинге поведение системы снаружи сохраняется, а внутри код меняется: команда упрощает структуру, разделяет связанные компоненты, убирает дублирование и обновляет отдельные зависимости.

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

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

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

7. Переписать систему постепенно

Систему можно заменять по одному модулю за раз, оставляя остальное работать как прежде. Подход называется Strangler Fig, по имени фикуса-душителя, который оплетает дерево и со временем занимает его место.

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

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

Как выбрать стратегию

Для всей системы один подход выбирать необязательно. Стабильный модуль можно не трогать, старую интеграцию удалить, а авторизацию постепенно вынести из монолита.

Сначала каждую часть системы проверяют по нескольким критериям:

• как часто в ней меняют код;
• сколько времени уходит на поддержку;
• от каких сервисов и баз данных она зависит;
• есть ли автоматические тесты;
• сколько времени она может не работать;
• хватает ли у команды людей и знаний для изменений.

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

Что подготовить до начала работ

Работу делят на этапы, и каждый должен давать результат, который можно проверить и выпустить отдельно. Задачу длиной в несколько месяцев тяжело оценивать, тестировать и откатывать.

До начала изменений нужно:

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

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

Итого

Легаси необязательно переписывать целиком. Сначала стоит понять, какая именно часть системы мешает работать и почему.

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

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

Все началось с рабочей задачи по реализации весьма специфичной web-панели мониторинга и управления различным оборудованием, в которой нужно было получать данные и отправлять команды по разнообразным сценариям (периодический опрос, подписка на websocket-события, https-запросы и т.д.), а также выводить состояние и графики в реальном времени, динамически комбинируя различные источники данных в разных виджетах.

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

В первой итерации с использованием RxJS получилось много неструктурированного и сложно поддерживаемого кода, так как архитектура на RxJS вынуждала императивно описывать перестроение топологии при изменении правил маршрутизации «на лету». В нашем специфичном кейсе с динамическими виджетами это приводило к сайд-эффектам и сложностям в отладке. Кроме того, местами размывалась строгая типизация и мы лишались compile-time гарантий. Так появилась идея разработать собственное решение на основе альтернативной концепции — модели графа потоков данных.

В результате получившаяся модель продемонстрировала предсказуемое поведение и низкую связность компонентов, а кодовая база сократилась на ~30% и приобрела более декларативный вид. Убедившись в эффективности решения, мы решили оформить его в виде отдельной библиотеки с открытым исходным кодом — Transferum.

И что, получилась просто еще одна реактивная библиотека?

Не совсем. Классические FRP-библиотеки (RxJS, Bacon, Most) построены вокруг единственного примитива (Observable). Transferum же основан на композиции различных типов узлов с явно определенным поведением.

Каждый узел в графе потоков распространения данных явно декларирует свои способности: может ли он принимать данные через push, отдавать через pull, распространять полученный сигнал подписчикам, опрашивать источник, фильтровать, блокировать поток и т.д.

Объявленные узлом возможности являются одновременно флагами для использования в runtime и compile-time гарантиями наличия соответствующих методов, определяющих его поведение.

Ключевая идея: поведение системы описывается как композиция независимых возможностей, которые одновременно определяют тип, реализацию и правила взаимодействия.

Transferum предоставляет четыре слоя абстракции:

1. Трансферы — узлы графа (каналы, поллеры, мапперы, буферы, разветвители и концентраторы, реализации debounce, throttle, switchMap и т.д.).
2. Мосты — ребра графа — управляемые вентили между узлами с динамической маршрутизацией и гейтингом.
3. Операторы — stateless-трансформаторы и фильтры данных (используются трансферами, отвечающими за конвертацию данных).
4. Билдеры — fluent-конструкторы композитных трансферов из цепочек трансферов-примитивов.

Концептуальная и архитектурная основа — capability flags system. Каждый трансфер реализует CommunicationContractInterface — набор булевых флагов, определяющих его возможности.

Флаги isPushable, isPullable, isSubscribable, isGate и другие — это не просто свойства объекта. Это метаданные, которые:

• Определяют TypeScript-интерфейс трансфера на этапе компиляции.
• Управляют стратегией связывания с другими трансферами в рантайме (с помощью функции linkTransfers()).
• Обеспечивают совместимость в билдерах без приведений типов.

Один набор флагов — три потребителя. Это единый источник истины для всей системы.

Когда флаг равен true, соответствующий метод входит в TypeScript-интерфейс трансфера. Это позволяет предоставлять трансфер пользователю вот так:

Или вот так:

Именно в таком формате типов фабрики в библиотеке возвращают трансферы. Например:

Эта «магия» работает в compile-time благодаря несколько замысловатой системе вычислимых типов:

Архитектурные инварианты

1. Трансферы не знают своих соседей

Трансфер определяет своё поведение (push, pull, subscribe и др.), но никогда не ссылается и не проверяет класс другого трансфера. Он не знает, что является upstream или downstream — лишь выполняет свой контракт. Пользователь может создать свой трансфер, объявить и реализовать его возможности — и он органично и бесшовно впишется в экосистему.

2. Мосты не знают конкретных реализаций

Мост инспектирует capability flags, а не имена классов. Нет цепочки instanceof, нет переключения по имени класса. Любой output-трансфер может быть соединен с любым input-трансфером — при условии совместимости их флагов, о чем мы поговорим чуть ниже. Это применимо и к тем узлам, которые еще не существуют и будут созданы пользователем.

3. Значение undefined никогда не распространяется

В Transferum undefined означает «нет данных», а не «пустое значение». Оно подавляется на уровне внутренней реализации менеджера подписок — подписчики никогда не уведомляются с undefined. При этом для явных маркеров пустых значений можно использовать null. Мы сознательно пошли на этот компромисс, чтобы избежать runtime-оверхеда и сохранить нативную скорость работы на плотных потоках данных.

Связывание трансферов

Функция linkTransfers(lhs, rhs) соединяет output-трансфер (lhs) с input-трансфером (rhs) с автоматическим выбором стратегии связывания на основе возможностей этих трансферов:

• isSubscribable → isPushable (реактивная подписка);
• isPullable → isPollingProxy (активный опрос);
• isSubscribable → isAsyncPushable (реактивная подписка + асинхронный push);
• isAsyncPullable → isAsyncPollingProxy (активный асинхронный опрос асинхронного pull-источника);
• isPullable → isAsyncPollingProxy (активный асинхронный опрос синхронного pull-источника).

Protocol-oriented design: механизм не спрашивает «какой это класс?» — он выясняет, какие у него есть возможности. Любая пара трансферов с совместимыми возможностями является linkable. Добавление нового класса трансфера требует только объявления его флагов и реализации соответствующих методов — как связать его с другим трансфером, связующий алгоритм разберется сам.

Sync и async в одной экосистеме

Синхронные и асинхронные трансферы сосуществуют и могут быть связаны между собой. linkTransfers() предпочитает sync-связывание, когда это возможно, а async-стратегии применяет только когда sync неприменим. Нет отдельного «асинхронного мира».

Поддержка backpressure

Ряд асинхронных трансферов (AsyncSinkTransfer, AsyncWriteTransfer, AsyncConvertTransfer, AsyncConditionTransfer) поддерживают необязательные поля в конфигурации: maxConcurrency, bufferSize и onBufferOverflow — для ограничения параллельных async-операций, очереди избыточных данных и graceful-обработки переполнения. По умолчанию — неограниченная обработка, без буферизации.

Локальная обработка ошибок

Transferum использует единую модель обработки ошибок для всех трансферов. Каждый трансфер, который может столкнуться с runtime-ошибкой, принимает опциональный onError-хэндлер в своей конфигурации.

А теперь — к примерам использования

Вот так можно просто и декларативно описать опрос и агрегирование данных из нескольких источников:

А вот как можно организовать динамический роутинг:

Пример организации игровой механики:

Когда имеет смысл попробовать Transferum

Библиотека подойдет для:

• TypeScript-first проектов — благодаря максимально строгой типизации и compile-time вычислению доступных методов любого трансфера на основе объявленных у него флагов возможностей.
• Работы с pull-based источниками данных — polling API, датчиков, хранилищ с PollingProxy.
• Смешанных sync/async пайплайнов — в единой модели без ручного преобразования.
• Явного flow control — gates, bridges, selectors для runtime-маршрутизации.
• Game development / IoT — frame-aligned tickers, idle polling, sensor aggregation.
• Устойчивой обработки ошибок — локальная, non-fatal обработка: одна стадия не убивает пайплайн при условии переданного в конфиге обработчика ошибок, ничего не подавляется молча.

Результаты и планы

• Библиотека уже используется в двух наших внутренних проектах и показывает свою эффективность. Код доступен на GitHub под лицензией MIT, библиотека не имеет внешних зависимостей и поставляется с подробной документацией (README + API Reference).
• В одном из проектов граф состоит из ~80 узлов и стабильно обрабатывает несколько сотен событий в секунду без деградации. На основе этих данных в том числе рендерится 3D-сцена в Babylon.js со стабильным фреймрейтом ~60 FPS без микрофризов.
• Тесты библиотеки покрывают не только отдельные трансферы, но и поведение системы в динамике: переподключение мостов, обработку ошибок в длинных асинхронных цепочках, а также разнообразные граничные случаи. Покрытие — 100%.
• В дальнейшем планируем реализовать хуки и утилиты для более удобного и нативного использования Transferum с Vue и React. Если они окажутся в достаточной мере переиспользуемыми, оформим в отдельные пакеты-адаптеры.

Буду рад, если вы заглянете в репозиторий, попробуете библиотеку в деле и поделитесь замечаниями — обратная связь поможет сделать Transferum лучше.

P. S. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.

В этой статье разберём, как внутри устроены метаклассы, зачем нужен встроенный type с тремя аргументами и когда стоит писать свой метакласс, а когда — обойтись наследованием или декоратором.

Класс — тоже объект

В Python 3 любой класс является экземпляром метакласса. По умолчанию этим метаклассом выступает type. Поэтому запись class Foo: pass интерпретатор превращает примерно в такой вызов:

С точки зрения языка разницы почти нет: и в том, и в другом случае получается объект класса Foo, у которого есть атрибуты, методы и собственный тип. Проверить это можно прямо в интерпретаторе:

type сам является экземпляром себя — это одна из тех особенностей Python, которые сначала удивляют, а потом помогают понять, что классы и объекты в языке живут по одним правилам.

Метакласс — это класс, экземплярами которого являются другие классы.

В Python 3 по умолчанию метаклассом любого класса является type.

Вызов type(name, bases, dict) создаёт класс динамически.

Собственный метакласс наследуется от type и переопределяет __new__ или __init__.

Чаще всего задачу решают наследованием или декоратором класса — метакласс нужен редко.

type — не только функция проверки типа

Всем знаком вызов type(x), который возвращает тип объекта. Но если передать type три аргумента, он превращается в фабрику классов:

• первый аргумент — имя класса (становится __name__);
• второй — кортеж базовых классов (становится __bases__);
• третий — словарь пространства имён (становится __dict__).

Этот механизм лежит в основе любого определения класса. Когда Python видит ключевое слово class, он сначала собирает тело класса в словарь, а затем вызывает метакласс, чтобы создать сам класс.

Пример — класс с методом, собранный вручную:

Такой код редко пишут в production, но он наглядно показывает, что класс — это всего лишь объект, созданный вызовом фабрики. А значит, эту фабрику можно заменить на свою.

Как написать свой метакласс

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

Здесь AutoAttrMeta автоматически добавляет атрибут version каждому классу, который её использует. То же самое можно сделать через наследование, но метакласс действует на этапе создания класса, а не при вызове методов.

Помимо __new__, часто переопределяют __init__ метакласса: он получает уже созданный класс и может его донастроить. А __call__ контролирует создание экземпляров класса — именно он вызывает __new__ и __init__ объекта.

А точно нужен метакласс?

Тим Петерс, автор «Дзена Python», как-то сказал, что метаклассы — это магия, которую 99% разработчиков никогда не понадобится. Если вы сомневаетесь, нужны ли они вам, — скорее всего, не нужны.

Метаклассы — это более глубокая магия, чем та, о которой 99% пользователей должны беспокоиться. Если вы сомневаетесь, нужны ли они вам, значит, не нужны.

Для сравнения — три способа дать классам общий атрибут:

Наследование

Декоратор класса

Метакласс

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

Когда метакласс действительно уместен:
— автоматическая регистрация подклассов в плагиновой системе;
— валидация объявлений полей (например, ORM проверяют типы атрибутов);
— принудительный единый API для большого семейства классов;
— реализация паттернов вроде Singleton на уровне класса.

Практический пример: автоматическая регистрация плагинов

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

Такой подход удобен, потому что автор плагина просто объявляет класс, а реестр обновляется сам. В реальных фреймворках — например, в старых версиях Django — похожая идея используется для построения моделей данных.

Выводы

Метаклассы — не ежедневный инструмент, но понимание их работы делает код Python прозрачнее. Вы начинаете видеть, что class — это тоже объект, а type — всего лишь фабрика, которую при желании можно заменить.

Главное правило: если задачу решает наследование или декоратор класса, не тащите метакласс. А если без контроля за созданием класса никуда — смело берите type и наследуйтесь от него.

Источник и дополнительное чтение: Python Metaclasses на Real Python.

Поэтому считать стоит не “сколько стоит разработчик”, а “сколько стоит довести задачу до продакшена”. Для этого и нужен TCO (total cost of ownership): полная стоимость владения командой, процессом или внешним контуром разработки.

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

Почему ставка разработчика ничего не объясняет

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

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

TCO появляется как раз между “купили часы разработчиков” и “получили работающую фичу в продакшене”. В расчет попадают дополнительные расходы:

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

Для инхауса ставка часто выглядит ниже, потому что компания смотрит на зарплату. Затем сверху приезжают налоги, оборудование, лицензии, HR, отпуск, больничные и время руководителя.

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

В выделенной команде легко попасть в ловушку “возьмём человека и ускоримся”. Ускорение появится, если внутри уже есть техлид, код-ревью и понятный процесс.

Базовая формула такая:

TCO разработки = прямые расходы + управление + запуск + простои + риски + передача знаний.

Где:

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

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

Как считать TCO инхауса

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

Формула может быть такой:

TCO инхауса = зарплата + налоги + инфраструктура + найм + онбординг + управление + простой + риск замены

• Зарплата и налоги можно посчитать сразу. Остальное часто всплывает позже. Разработчику нужны ноутбук, монитор, доступы, IDE, таск-трекер, облачные сервисы, тестовые стенды и корпоративные инструменты.
• Найм тоже входит в TCO. Вакансию нужно описать, кандидатов найти, провести скрининг, техническое интервью, тестовое задание и согласование оффера.
• После выхода человека начинается онбординг. Разработчик разбирается в кодовой базе, архитектуре, локальном окружении, правилах ревью и деплоя. Первые недели он часто требует больше внимания, чем отдаёт команде пользы. Это нормальная часть штатной разработки, её просто нужно считать заранее.
• Отдельная статья расходов — текучка. Когда разработчик уходит, компания теряет часть контекста. Потом нужно снова искать человека, вводить его в проект и ждать, пока он выйдет на нормальную скорость.

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

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

Как считать TCO аутсорса

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

Формула может быть такой:

TCO аутсорса = стоимость договора + подготовка требований + управление со стороны заказчика + приёмка + изменения цели + передача результата

• Стоимость договора обычно включает работу команды, PM, тестирование, инфраструктуру подрядчика и его маржу. Маржа в этой модели нормальна: подрядчик держит команду, управляет загрузкой, закрывает внутренние риски и отвечает за процесс на своей стороне.
• Главная точка роста стоимости — требования. Когда финальная цель понятная, подрядчик быстрее оценивает задачу, планирует этапы и показывает результат.
• Заказчику всё равно нужно управлять проектом со своей стороны. Подрядчик не знает продуктовый контекст по умолчанию. Ему нужны ответы на вопросы, доступы, обратная связь и приёмка промежуточных результатов.
• В TCO аутсорса стоит сразу закладывать передачу результата. В договоре нужно зафиксировать права на код. Документация должна позволять поддерживать проект другой команде. Деплой, окружения и API тоже лучше описать до финальной приёмки.

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

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

Как считать TCO выделенных команд

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

Формула может быть такой:

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

• Ставка специалиста даёт доступ к человеку, а готовый результат всё равно собирает ваша команда. Подрядчик может помочь с подбором, оформлением, заменой и административной частью. Заказчик отвечает за ежедневную работу специалиста.
• Самая важная статья расходов здесь — время техлида. Он проводит техническое интервью, вводит человека в проект, объясняет архитектуру и проверяет решения.
• Онбординг в аутстаффинге обычно короче, чем в инхаусе: компания не проходит полный цикл найма и оформления, но контекст проекта всё равно нужно передать.
• В TCO нужно заложить коммуникацию с провайдером. Если специалист заболел, не подошёл по уровню или проекту нужна замена, порядок действий должен быть понятен заранее.

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

Где здесь место внешней команды

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

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

Посмотреть услуги Centicore Group

Чек-лист перед выбором модели

Перед выбором модели проверьте три вещи: управление, срок проекта и требования.

1. Сначала — управление. Если внутри есть CTO, техлид или сильный PM с техническим бэкграундом, можно рассматривать аутстаффинг и гибридную модель. Если управленца нет, аутстаффинг быстро станет проблемой. В этом случае безопаснее смотреть на аутсорс, где управление разработкой берёт на себя подрядчик.
2. Дальше — срок проекта. Для задачи на несколько месяцев инхаус часто слишком дорогой: найм, адаптация и настройка процессов могут занять больше времени, чем сама разработка. Для продукта на долгосрок, наоборот, стоит заранее думать о своём техническом ядре.
3. Третий пункт — требования. Чем понятнее сценарии, интеграции, ограничения и критерии готовности, тем проще считать TCO аутсорса. Если требования ещё меняются, в бюджет нужно сразу закладывать аналитику, дополнительные итерации и переприёмку.

Перед решением ответьте на несколько вопросов:

• кто владеет архитектурой и техническими решениями;
• кто принимает код, документацию и деплой;
• что будет, если ключевой специалист выпадет из проекта.

После этого обычно становится видно, что именно нужно проекту: штатная команда, внешний подрядчик, аутстафф-специалист или гибрид.

Итого

TCO показывает реальную стоимость результата, а не цену одного разработчика. В расчёте должны быть управление, запуск, простои, риски, передача знаний и поддержка после релиза.

• Инхаус подходит для долгих продуктов, где важны контроль, архитектура и накопление экспертизы внутри команды.
• Аутсорс удобен для MVP, интеграций, миграций и отдельных сервисов с понятными границами. Здесь важно заранее считать требования, приёмку, документацию и передачу результата.
• Аутстаффинг помогает быстро усилить команду, если внутри уже есть техлид, бэклог, ревью и нормальный процесс разработки.
• Гибридная модель нужна, когда продукт проходит разные этапы. На старте можно подключить внешнюю команду, после проверки гипотезы собрать своё ядро, а пиковую нагрузку закрывать аутсорсом или аутстаффингом.

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

Service Topology — это не статическая схема из вики, а динамическая карта связей между сервисами. Она обновляется по мере того, как меняется трафик, появляются новые зависимости или старые исчезают. Карта показывает не только «кто с кем говорит», но и контекст: уровень доступности, бизнес-домен, владельца и текущее состояние здоровья.

Если тема микросервисов для вас новая, начните с базового разбора «Что такое микросервисы», а если выбираете архитектуру для проекта — сравните варианты в материале «Монолит или микросервисы». Авторский разбор внутреннего устройства Netflix читайте в статье «Разработчик изучал систему рекомендаций Netflix месяцами».

• Netflix объединила три источника данных: eBPF-сетевые потоки, IPC-метрики и распределённые трейсы.
• Каждый источник строит свой граф; общий вид получается параллельным слиянием слоёв.
• Карта обновляется почти в реальном времени и отвечает на запросы быстрее секунды.
• Инженеры используют её для поиска причин сбоев, оценки зоны поражения и планирования изменений.
• Подход можно перенести в любую распределённую систему, где нужно понимать зависимости.

Почему обычной наблюдаемости мало

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

Инженеру в три часа ночи приходится мысленно склеивать данные из разных источников. Это медленно, чревато ошибками и добавляет стресса. Netflix проанализировала тысячи обращений в поддержку за четыре года и увидела повторяющиеся вопросы: кто мои upstream и downstream, что упадёт вместе со мной, почему сервис отображается в панели мониторинга как Unknown (неизвестный сервис). Ответы на них требовали единого представления о зависимостях.

Три источника данных Service Topology

Главный вывод Netflix: ни один источник не рассказывает всю историю. Поэтому система строит три независимых графа и объединяет их по запросу.

Сетевые потоки eBPF

На сетевом уровне Netflix собирает потоки ядра через eBPF. Это даёт полноту: сюда попадают все соединения, независимо от того, инструментирован сервис или нет. Слой показывает связи между кластерами и приложениями такими, какими они есть на самом деле. Недостаток — не хватает прикладного контекста: видно, что сервис А достучался до IP-адреса сервиса Б, но неизвестно, какой конкретно endpoint вызывался.

IPC-метрики

На прикладном уровне собираются метрики межпроцессного взаимодействия. Когда сервис обращается к другому через gRPC, GraphQL или REST, он фиксирует endpoint, ошибки, задержки и протокол. Этот слой даёт детали, которых нет у сетевого: какой именно путь вызывается и с какой вероятностью ошибки. Ограничение очевидно: если сервис не отправляет метрики, его вызовов здесь не будет.

Распределённые трейсы

Третий слой — трейсинг запросов от начала до конца. Он показывает не «может ли сервис А позвонить сервису Б», а «звонил ли он в рамках этого конкретного пользовательского запроса». Это помогает увидеть поведение во время выполнения, ветвления, фича-флаги и редкие пути. Поскольку трейсы собирают выборочно, редкие сценарии могут не попасть в агрегированный вид.

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

Как собирают Service Topology

Приём и обработка потоков

За кулисами работает конвейер, который держит миллионы событий в секунду. Потоки сетевых логов читаются из Kafka в нескольких регионах AWS. Для обработки Netflix использует Apache Pekko Streams — форк Akka, который разбивает нагрузку по группам автомасштабирования и сам управляет обратным давлением.

Восстановление прямых связей

Сетевой лог показывает отдельные сетевые прыжки: например, приложение → балансировщик → приложение или приложение → NAT-шлюз → приложение. Чтобы получить настоящие связи, запускается трёхступенчатая агрегация. Первая стадия забирает сырые записи, вторая распознаёт посредников и восстанавливает прямые пути между приложениями, третья финализирует агрегаты и добавляет статус здоровья. Такой градуированный подход раскидывает нагрузку и не даёт горячим узлам уронить весь конвейер.

Готовая топология хранится в графовой базе Netflix — абстракции поверх распределённого хранилища «ключ — значение». Она заточена под быстрый обход графа в несколько хопов. Поверх базы — gRPC-API с фильтрами по уровню доступности и домену, постраничным выводом больших выборок и ответом менее чем за секунду.

Хранение и API

Отдельно стоит возможность «путешествия во времени». Система не хранит каждый момент отдельно, а накапливает данные в скользящих окнах. Это позволяет спросить «как выглядела топология вчера в полночь» без взрыва объёмов хранения.

Что даёт инженерам

Интерфейс и API дают инженерам несколько рабочих сценариев — от ручного расследования до автоматических проверок.

• Видеть upstream и downstream для любого сервиса с фильтрами по уровню доступности и домену.
• Переключаться между единым видом и отдельными слоями: только сеть, только IPC или только трейсы.
• Одним кликом переходить от узла топологии к логам, трейсам и детальным метрикам.
• Оценивать зону поражения перед отключением сервиса на обслуживание и понимать, кого уведомлять.
• Накладывать статус здоровья на граф и быстро понимать, локальная ли это проблема или каскадный сбой.
• Обращаться к топологии программно — например, чтобы автоматически проверять классификацию доступности критичных сервисов.
• Смотреть историю зависимостей и находить, что изменилось перед инцидентом.

Как перенести в свою систему

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

Чек-лист для первых шагов:
1. Выберите один настоящий источник связей: логи балансировщика, агент на хосте или метрики вызовов.
2. Не пытайтесь сразу построить идеальную модель — начните с автоматически обнаруженных рёбер.
3. Добавьте контекст: владельца сервиса, уровень критичности и домен.
4. Сделайте карту доступной программно, а не только в интерфейсе — инцидент-боты и скрипты будут благодарны.
5. Проверяйте актуальность: в динамичной среде карты, устаревшие на несколько часов, быстро теряют ценность.

Для иллюстрации вот минимальный скрипт, который строит рёбра графа из логов балансировщика:

Часто задаваемые вопросы

Выводы

Service Topology — не просто красивая картинка для панели мониторинга. Это операционная основа, которая ускоряет расследования, снижает риск изменений и даёт автоматическим системам общую картину инфраструктуры. Netflix называет её knowledge graph foundation — фундаментом для интеллектуальной автоматизации, в том числе для автоматического поиска первопричины сбоев.

Service topology provides the knowledge graph foundation that makes this kind of intelligent automation possible.

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

Источники

• From Silos to Service Topology: Why Netflix Built a Real-Time Service Map

Что такое Agentic SRE

Agentic SRE — это практика, в которой автономные ИИ-агенты помогают наблюдать за системами, анализировать телеметрию (метрики, логи, трейсы) и выполнять ограниченные операционные действия при заданных человеком guardrails (правил безопасности). Агент не заменяет SRE-инженера, а работает как цифровой напарник: собирает контекст, предлагает гипотезы и выполняет только те действия, которые одобрены политикой.

Ключевое отличие от классической автоматизации — способность к рассуждению. Традиционные скрипты реагируют на жёсткие триггеры («если CPU > 90%, то перезапустить»). Агент же может связать всплеск ошибок с недавним развёртыванием, проверить корреляцию по трейсам и предложить конкретный план действий — всё до того, как инженер откроет ноутбук.

Agentic SRE — это ИИ-агенты, которые помогают инженерам наблюдать, диагностировать и реагировать на инциденты.

Основная цель — сократить рутину и ускорить принятие решений, а не заменить человека.

Ключевые сценарии: триаж алертов, инцидент-копилот, автоматический RCA, безопасное исправление, обучение на инцидентах.

Безопасность превыше всего: агенты работают с allowlists, approval gates и полным аудитом.

Российские команды могут строить стек на OpenTelemetry, Prometheus/Grafana, собственных LLM и PagerDuty/Opsgenie.

Почему это важно именно сейчас

Сегодняшние системы стали слишком распределёнными, шумными и динамичными, чтобы человек успевал за ними вручную. Микросервисы, Kubernetes, feature flags и канареечные развёртывания создали ландшафт, где одно изменение может затронуть десятки сервисов, а сигналы о проблемах разбросаны по десяткам дашбордов.

Инженеры тратят значительное время на корреляцию метрик, чтение логов, проверку недавних выкаток и охоту за контекстом — до того, как начинают решать проблему. Agentic SRE решает это, превращая сырые телеметрические данные в структурированный контекст и автоматизируя безопасные части цикла реагирования.

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

Из чего строится стек

Практичная архитектура агентного SRE собирается из нескольких слоёв. При этом важно понимать: ценность приходит не от выбора модели, а от качества контекста, жёстких ограничений и дисциплины исполнения.

• Телеметрия: OpenTelemetry — стандарт сбора телеметрии — для сбора логов, метрик и трейсов в едином формате.
• Наблюдаемость: Prometheus, Grafana, Datadog, New Relic, Elastic или облачные системы — хранилище и визуализация.
• Оркестрация: MCP-серверы (Model Context Protocol от Anthropic), внутренние API или системы рабочих процессов, которые предоставляют агенту безопасные инструменты.
• Среда выполнения агента: LLM-фреймворки с function calling, планированием и работой с инструментами.
• Рабочий процесс при инцидентах: PagerDuty, Opsgenie, Slack, Jira, ServiceNow — куда агент пишет отчёты и запрашивает подтверждения.
• Safety Layer: RBAC, approval gates, audit logs, allowlists и пути отката — неотъемлемая часть, а не дополнение.

Принцип безопасности:
Агент должен уметь делать только то, что мог бы сделать дежурный инженер после одобрения. Это делает систему практичной и снижает риск случайного ущерба.

Пять сценариев, которые уже работают

1. Триаж алертов: от шума к сути за секунды

Когда срабатывает алерт, агент собирает связанные трейсы, проверяет недавние развёртывания, находит соответствующие всплески в логах и формирует краткое резюме на русском языке: вероятная причина, уверенность, рекомендуемые действия. Это решает проблему «с чего начать?», которая сжигает драгоценные минуты в начале инцидента.

2. Инцидент-копилот: второй мозг в канале

Агент подключается к каналу реагирования (Slack, Teams) и выполняет роль «второго мозга»: строит таймлайн, подтягивает ссылки на дашборды, отслеживает гипотезы по мере их проверки. Когда в инциденте участвуют несколько инженеров, это предотвращает фрагментацию контекста и дублирование усилий.

3. Автоматический черновик RCA (Root Cause Analysis)

После инцидента агент сравнивает таймлайн с недавними изменениями (развёртывания, конфиги, фичер-флаги), находит корреляции и генерирует первый черновик отчёта RCA с ссылками на доказательства. Инженер остаётся владельцем выводов, но экономит значительное время на подготовку документации.

4. Безопасное исправление под контролем

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

5. Обучение на инцидентах: от пожаротушения к профилактике

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

Guardrails: почему доверие важнее интеллекта

Главный риск агентного SRE не в том, что агент слишком умен, а в том, что он может быть слишком уверен в себе. LLM способны генерировать правдоподобные, но неверные объяснения. Поэтому каждая рекомендация должна быть прослежена до реальной телеметрии, а каждое действие — ограничено явными правами.

• Action allowlists: агент может делать только то, что в белом списке.
• Approval gates: рискованные изменения требуют подтверждения.
• Полный audit log: каждое действие агента записывается.
• Read-only mode на этапе внедрения: сначала наблюдаем, потом действуем.
• Разграничение прав по сервисам и командам.
• Human override на каждом шаге: человек всегда может взять управление.

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

Выводы

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

Если строить это правильно, результат — продвинутая практика надёжности: меньше бесполезной работы, короче инциденты и больше времени для инженеров на системные улучшения вместо повторяющейся рутины. Настоящая ценность агентного SRE — не в замене инженера, а в том, чтобы дать ему модель работы с гораздо большей эффективностью.

Источник: Agentic SRE: The Next Frontier of Reliability — DevOps.com (Neel Shah, 2026).

О том, где в таких продуктах чаще всего возникают скрытые сложности и как найти баланс между потребностями бизнеса, пользователей и разработчиков, рассказала Наталья Буйлина, лидер стрима ITSM платформы производства ПО «Сфера» (входит в ИТ-холдинг Т1).

Корень большинства проблем лежит глубже — в логике сценариев и архитектуре. Интерфейс лишь отражает то, насколько хорошо продуманы пользовательские пути. В продуктах, работающих внутри платформы, главная боль — скрытые зависимости от сервисов и сценарии, которые «ломаются» при любых изменениях в базовой инфраструктуре. При этом человек уверен, что работает с одним продуктом, хотя за ним стоят 5–10 компонентов.

Внутренние команды: пользователи, о которых забывают

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

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

No-code и low-code: гибкость, которая может стать ловушкой

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

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

Архитектура как точка баланса

Самым важным при проектировании корпоративных платформ являются вопросы функционального дизайна и системной архитектуры. Именно они объединяют все компоненты продукта и определяют его зрелость и применимость в реальном бизнесе.

Продукты не должны сдерживать развитие платформы, а платформа — тормозить продуктовые команды.

Проблема в том, что сами инструменты и подходы быстро меняются. Если архитектура остается только в Confluence и устных договоренностях, она устаревает быстрее, чем код. Через пару спринтов диаграммы уже "не про то", а архитектурные решения не проходят проверку реальностью. Именно здесь появляется Architecture as Code( AaC) - подход, в котором архитектура живет как инженерный артефакт: версионируется в Git, проверяется в CI/CD и развивается через MR. В этой статье разберем практическую связку LikeC4 для модели и AsciiDoc для документации.

Если кратко, то

• Архитектура как код - это не про красивые схемы, а про проверяемые ограничения.
• LikeC4 дает C4-модель как исходники (.c4) с диффами, ревью и тестами.
• AsciiDoc фиксирует контекст решений, требования и обоснования рядом с моделью.
• Архитектурные изменения ведутся в отдельном репозитории с собственными MR и проверками.

Почему "архитектура в документах" ломается? Обычный сценарий выглядит примерно так:

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

Итог - "документированная архитектура" живет отдельно от системы.

AaC подход закрывает этот разрыв:

• артефакты архитектуры хранятся в отдельном архитектурном репозитории;
• ограничения формулируются как правила;
• правила проверяются автоматически в pipeline.

Что именно кодируем?

Практически полезный минимум:

• контекст системы и внешние акторы;
• контейнеры и ключевые компоненты;
• интерфейсы, протоколы, синхронные и асинхронные взаимодействия;
• инфраструктурные ограничения (например, допустимые зависимости и boundary rules);
• ссылки на ADR, OpenAPI, схемы БД и эксплуатационные метрики.

Здесь важно не "оцифровать все", а начать с того, что чаще всего вызывает расхождения между планом и реализацией.4.

Роль LikeC4

LikeC4 - это язык описания C4-модели и набор инструментов вокруг нее.Что это дает команде:

• диаграммы задаются текстом, а не мышкой;
• изменения видны в git diff;
• модель можно тестировать и линтить;
• из модели собирается статический сайт с навигацией по представлениям.

Основные возможности LikeC4 (по документации)

Официальная документация: likec4.dev

• DSL для описания specification, model, views и deployment-слоя в одном источнике истины;
• views как проекции модели - с разным уровнем детализации, scoped views и расширением (extends) без дублирования;
• предикаты для управляемого включения элементов и связей в конкретное представление;
• генерация артефактов "из коробки" - статический сайт, экспорт диаграмм, интеграция в документацию и UI;
• API/MCP-интеграция для доступа к архитектурной модели из внешних инструментов и AI-ассистентов.

AI-skills для генерации схем LikeC4В LikeC4 есть отдельный раздел по AI-инструментам: AI Tools.

Практически это дает два уровня автоматизации:

• Agent Skills - подключают для AI-ассистента справочник DSL и снижают риск "галлюцинаций" в синтаксисе;
• MCP Server - дает LLM доступ к текущей архитектурной модели, чтобы строить и уточнять схемы на основе реального контекста проекта.

Базовое подключение skills в проект:

Пример на базе моего проекта

Публичный пример с визуализацией архитектуры в LikeC4: system-design

Исходный код проекта: system-design-codeКратко о проекте:

• это практический стенд Architecture as Code с LikeC4-моделью;
• в нем можно посмотреть структуру системы и связи между элементами в формате интерактивных представлений;

Пример описания контейнера и связей:

Пример представления:

Роль AsciiDoc рядом с модельюГрафическая модель отвечает на вопрос "что с чем связано".

AsciiDoc отвечает на вопросы:

• почему принято такое решение;
• какие допущения и ограничения учтены;
• как проверять качество и соответствие;
• какие есть риски и компромиссы.

Плюс - из одного источника можно получить HTML/PDF для разных потребителей: разработчики, архитектурный комитет, аудит.

Как это выглядит в репозиторияхТиповая структура для коммерческой эксплуатации:

• likec4/ - модель, deployment и views;
• doc/ или presentations/ - объясняющая документация в AsciiDoc;
• CI job в архитектурном репозитории, который валидирует модель и блокирует merge при нарушениях.

При разделении репозиториев критичен процесс синхронизации:

• общие идентификаторы изменений (issue/ticket/ADR);
• правило "нет merge в production-код без обновленной архитектурной модели".

CI/CD: где появляется ценностьМинимальный pipeline для старта:

1. Сборка представлений модели (например, npm run build:likec4).
2. Тесты/линтер архитектурной модели (например, npm run test:likec4).
3. Проверка целостности ссылок на документацию и артефакты.
4. Публикация статического отчета как build artifact.

Даже такой базовый набор снижает риск "тихого дрейфа архитектуры", когда код уже ушел в сторону, а архитектурный репозиторий еще не обновлен.

В эпоху ИИ ценность подхода дополнительно растет - формализованная модель AaC и связанная с ней документация позволяют собирать первичные варианты архитектуры и артефактов прямо из бизнес-требований. Если в AI skills зафиксировать не только синтаксис конкретного инструмента, но и внутренние стандарты системного дизайна и оформления документов, ассистент начинает выдавать результат в привычном для команды формате. Это снижает время на старт новой инициативы и уменьшает число итераций на "доведение до корпоративного шаблона". Вместо ручной компоновки с нуля команда сразу получает основу, которую остается уточнить и проверить.

Фитнес-функции на базе LikeC4

Когда архитектурная модель поддерживается как код и регулярно обновляется, на ее основе можно строить архитектурные фитнес-функции - автоматические проверки соответствия между "как задумано" и "как работает в runtime".

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

Примеры практических фитнес-функций:

• сравнение задеплоенного в Kubernetes с тем, что описано в архитектурной модели;
• сравнение реальных связей компонентов (по данным кластера/сервис-меша/телеметрии) с заявленными связями в модели;
• проверка values.yaml Helm-чартов на соответствие архитектурным ограничениям;
• проверка наличия обязательных метаданных (owner, критичность, зависимости, ссылки на ADR/OpenAPI).

Что это дает на практике:

• раннее обнаружение архитектурного дрейфа;
• более безопасные релизы за счет fail-fast проверок в CI/CD;
• прозрачный аудит изменений - от модели до фактического состояния среды.

Edge cases и риски внедрения

Перед запуском подхода стоит учитывать:

• Избыточная детализация - если моделировать каждый класс, команда быстро устанет поддерживать модель.
• Формальный adoption - без включения проверок в CI все останется "декларацией намерений".
• Нет владельца модели - нужна роль или процесс, который отвечает за целостность архитектурных артефактов.
• Слабая связь с runtime - полезно связывать модель с метриками/логами/трейсингом, иначе теряется трассируемость.
• Рассинхрон двух репозиториев - без связки MR и единых правил merge архитектура быстро отстает от реализации.

С чего начать без большого рефакторинга

Рабочий план на 2-3 итерации:

1. Выбрать один критичный поток (например, обработку пользовательского запроса).
2. Описать для него C4-контекст и контейнеры в LikeC4.
3. Зафиксировать 3-5 ключевых ограничений (зависимости, контракты, границы).
4. Добавить проверки в CI как non-blocking, затем сделать их blocking.
5. Вынести обоснование решений и риски в AsciiDoc рядом с моделью.

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

Вывод

Architecture as Code - это про управляемость изменений, а не про документацию ради документации. Связка

LikeC4 + AsciiDoc дает практичный баланс:

• модель архитектуры - как проверяемый код;
• решения и контекст - как поддерживаемый текст;
• единый процесс изменений - через PR и CI/CD.

Если в проекте есть боль от "устаревших схем" и "архитектуры на словах" - этот подход обычно окупается уже на первых релизах за счет снижения архитектурного рассинхрона.

Проблема оказалась не в сети, не в базе и не в нагрузке. Проблема была в одном булевом флаге, который изменил момент открытия пула соединений — и превратил fork() из безопасной операции в мину замедленного действия.

Ключевые выводы:
— fork() копирует память процесса (copy-on-write), но разделяет файловые дескрипторы с ядром
— TCP-сокеты после fork() указывают на один и тот же объект ядра — два процесса пишут в один поток
— threading.Lock ломается: futex-ключ привязан к физическому адресу памяти, который меняется при copy-on-write
— Фоновые потоки пула просто не существуют в дочернем процессе — fork() копирует только вызывающий поток
— Правило: никогда не держите открытые соединения перед fork()

Инцидент — что случилось

За несколько дней до инцидента в конфигурации изменился один флаг. Нужно было, чтобы обработчики сигналов Django регистрировались внутри воркеров Celery. Существующая настройка пропускала регистрацию, если флаг не был установлен в true.

Флаг установили. Сигналы заработали. Фича уехала в прод.

QA был быстрым. Изменение выглядело изолированным: переключить флаг, убедиться, что сигналы регистрируются в Celery, готово. Никто не искал побочных эффектов, спрятанных в AppConfig.ready().

А потом тихо начало выполняться кое-что ещё. Несколько методов AppConfig.ready(), которые теперь стали активны, делали ORM-запросы при старте: создавали расписания периодических задач, проверяли записи crontab. Рутинные вещи. Ничего опасного на вид.

Но эти запросы открыли пул соединений с базой данных. В мастер-процессе. До fork().

Модель конкурентности Celery по умолчанию — prefork. Не потоки, не async-воркеры. Celery использует fork() — системный вызов POSIX — для создания пула рабочих процессов. Эту деталь легко забыть, когда смотришь на код приложения. Но она становится критически важной, когда открываешь соединения с базой при старте.

В этом и была проблема.

Что копирует fork()

Большинство разработчиков знают поверхностный ответ: fork() создаёт дочерний процесс, который является копией родительского. Но слово «копия» скрывает важное различие, которое ядро проводит между двумя типами ресурсов.

Память — copy-on-write

Когда fork() выполняется, ядро не дублирует RAM немедленно. Вместо этого оно помечает таблицы страниц обоих процессов как read-only, указывая на одни и те же физические страницы. Фактическое копирование происходит только когда один из процессов пишет в страницу: ядро перехватывает page fault, выделяет новую физическую страницу, копирует содержимое и обновляет таблицу страниц. До этого момента оба процесса разделяют физическую память, не зная об этом.

Это эффективно. И именно поэтому Python-объекты, включая внутреннее состояние пула соединений, выглядят целыми в дочернем процессе. Дочерний процесс получает свою копию pool._pool, pool._lock, pool._sched. Байты на месте. Структура на месте.

Но некоторые из этих байтов указывают на ресурсы ядра. А ресурсы ядра не копируются.

Файловые дескрипторы — общие

TCP-сокет — это не Python-объект. Это объект ядра: struct file со счётчиком ссылок, за которым стоит struct sock с буферами отправки и получения, состоянием TCP, sequence numbers. Когда fork() выполняется, ядро вызывает dup_fd() для таблицы файловых дескрипторов родителя: каждый открытый fd дублируется в дочерний процесс, а счётчик ссылок на struct file увеличивается.

Оба процесса теперь держат fd=12. Оба указывают на один и тот же объект сокета в ядре. Один TCP-поток, два читателя и два писателя — без координации между ними.

Проводной протокол PostgreSQL — stateful. Он ожидает последовательные пары запрос-ответ в одном потоке. Два процесса, чередующие байты в одном соединении, не создают два независимых разговора. Они создают мусор.

Блокировки — сломанный futex

threading.Lock построен на pthread_mutex_t, который внутри опирается на futex — механизм ядра Linux, использующий физический адрес памяти целого числа как ключ для очереди ожидания. После fork() copy-on-write может переместить страницу дочернего процесса на новый физический адрес при записи. Futex-ключ дочернего процесса расходится с родительским. futex_wake из одного процесса не будит никого в другом.

POSIX явно говорит об этом: поведение мьютекса после fork() не определено, если он не был создан с атрибутом process-shared. Python-овский Lock этот атрибут не использует.

Фоновые потоки — просто не существуют

fork() дублирует только вызывающий поток. Внутренний планировщик пула — отвечающий за поддержание минимального числа соединений, проверки здоровья, уведомление ожидающих — копируется как Python-объект, но не имеет соответствующего потока ОС. Его TID не существует. Любой путь кода, который зависит от его ожидания или сигнализации, заблокируется навсегда.

Дочерние процессы унаследовали пул, который выглядел целым, но был мёртв. Они вызывали pool.getconn(), пытались захватить сломанный лок, ждали 20 секунд notify, который никогда не придёт, и получали таймаут.

Почему пул соединений ломается после fork()

Пул соединений psycopg (ConnectionPool) хранит три вида ресурсов. Каждый ломается по-своему после fork().

TCP-сокеты разделяются на уровне ядра. Любая попытка использовать их из двух процессов одновременно разрушает поток протокола. На практике дочерние процессы до этого даже не доходили.

threading.Lock опирается на futex, привязанный к физическому адресу. После copy-on-write ключ дрейфует. futex_wake будит очередь по старому адресу — никого в дочернем процессе там нет.

Фоновые потоки не существуют в дочернем процессе. Планировщик пула — Python-объект без ОС-потока. Код, зависящий от его notify, блокируется навечно.

Вот почему раньше всё работало:

До изменения флага AppConfig.ready() пропускал регистрацию периодических задач. ORM не вызывался при старте. Нет запросов — нет пула. Нет пула — нечего наследовать. Каждый дочерний процесс начинал с чистого состояния и лениво создавал собственный пул при первом обращении к базе: собственные сокеты, собственный лок, собственный фоновый поток.

Решение — чистый fork без наследства

Два хука сигналов Celery.

worker_before_create_process срабатывает в родительском процессе после ready(), перед каждым fork(). Он закрывает все соединения с базой по всем алиасам и уничтожает пулы соединений. К моменту выполнения fork() нет открытых TCP-сокетов, нет локов, нет фоновых потоков для наследования.

worker_process_init срабатывает в каждом дочернем процессе после fork() как второй уровень защиты — defense-in-depth, на случай если что-то было пропущено.

После обоих хуков каждый дочерний процесс пуст. Первый ORM-запрос создаёт свежий пул, который целиком принадлежит этому процессу.

Принцип простой: никогда не держите открытые соединения перед fork() — или явно закройте и уничтожьте их до форка. Это правило применимо к любому пулу соединений на основе TCP: psycopg, SQLAlchemy, redis-py. Технология не важна. Важно поведение ядра.

Диаграммы — до и после

До изменения флага: чистый fork, каждый воркер создаёт свой пул

После изменения флага: пул открыт в мастере, fork() распространяет повреждение

После исправления: пул уничтожен перед fork(), каждый воркер стартует чисто

Выводы

Настоящий урок — не в конкретном фиксе. Он в понимании того, почему пул сломался. Что fork() на самом деле копирует. Что он разделяет. Почему лок, который выглядит целым, может заблокировать дочерний процесс. Почему поток, существующий как Python-объект, может полностью отсутствовать в ОС.

Правила, которые стоит запомнить:

• Никогда не открывайте пул соединений до fork() — или явно уничтожьте его перед форком
• fork() копирует память (лениво), но разделяет файловые дескрипторы на уровне ядра
• threading.Lock после fork() — undefined behavior: futex привязан к физическому адресу, который дрейфует при copy-on-write
• Фоновые потоки не дублируются — fork() копирует только вызывающий поток
• Это правило касается любого пула TCP-соединений: psycopg, SQLAlchemy, redis-py — поведение ядра одинаково

Невидимая часть — это взаимодействие между последовательностью запуска Django и моделью процессов Celery. Две системы, каждая из которых хорошо понятна по отдельности, делают неожиданное на стыке.

Адаптированный перевод статьи What fork() Actually Copies Даниэля Бастоса (Daniel Bastos).

Долг понимания — это растущий разрыв между объёмом кода в системе и долей этого кода, которую живые люди действительно понимают. В отличие от технического долга, который заявляет о себе трением — медленными сборками, запутанными зависимостями, ощущением ужаса при касании «того самого» модуля — долг понимания порождает ложную уверенность. Кодовая база выглядит чистой. Тесты зелёные. Расплата приходит тихо, обычно в самый неподходящий момент.

Маргарет-Энн Стори описывает студенческую команду, которая наткнулась на стену на седьмой неделе: они больше не могли вносить простые изменения, не ломая что-нибудь неожиданное. Проблемой был не грязный код. Проблемой было то, что никто в команде не мог объяснить, почему были приняты те или иные проектные решения и как разные части системы должны работать вместе. Теория системы испарилась.

Недавнее исследование Anthropic подтверждает это количественно. В рандомизированном контролируемом эксперименте с 52 инженерами участники, использовавшие ИИ-ассистента, завершали задачу за то же время, что и контрольная группа, — но на последующем тесте на понимание кода набрали на 17% меньше баллов (50% против 67%). Наибольшее падение — в навыках отладки. Пассивное делегирование («просто сделай это») разрушает формирование навыков значительно сильнее, чем активное использование ИИ для вопросов и изучения компромиссов.

Ключевые выводы

- Долг понимания — это не технический долг. Технический долг виден; долг понимания порождает ложную уверенность.
- ИИ генерирует код быстрее, чем человек способен его проверить. Прежний фильтр качества стал узким местом пропускной способности.
- Тесты необходимы, но недостаточны: нельзя написать тест на поведение, о котором никто не подумал.
- Спецификации тоже не спасают: между спецификацией и работающим кодом лежат сотни неявных решений.
- Ни одна текущая метрика не отражает этот долг. Velocity, DORA, покрытие кода — всё зелёное, пока понимание тихо выгорает.
- Удешевление генерации кода не удешевляет понимание. Работа по пониманию — это и есть работа инженера.

Асимметрия скорости — ИИ генерирует быстрее, чем человек проверяет

ИИ генерирует код значительно быстрее, чем люди способны его оценить. Звучит очевидно, но последствия легко недооценить.

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

ИИ-сгенерированный код ломает этот цикл обратной связи. Объём слишком велик. Результат синтаксически чистый, хорошо отформатированный, внешне корректный — именно те сигналы, которые исторически вызывали уверенность при мёрже. Но поверхностная корректность — не системная корректность. Кодовая база выглядит здоровой, а понимание тихо выгорает под ней.

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

Тесты — необходимы, но недостаточны

Инстинктивная реакция — налечь на детерминированную верификацию: юнит-тесты, интеграционные тесты, статический анализ, линтеры, форматтеры. Автоматизировать выход из узкого места ревью. Пусть машины проверяют машины.

Это помогает. Но у этого подхода есть жёсткий потолок.

Набор тестов, способный покрыть всё наблюдаемое поведение, во многих случаях окажется сложнее, чем код, который он валидирует. А сложность, о которой невозможно рассуждать, не обеспечивает безопасность. И за этим стоит более фундаментальная проблема: нельзя написать тест на поведение, о котором вы не подумали.

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

Есть и конкретный сценарий провала, который стоит назвать. Когда ИИ меняет поведение реализации и обновляет сотни тест-кейсов под новое поведение, вопрос сдвигается с «правильный ли этот код?» на «были ли все эти изменения тестов необходимыми, и достаточно ли у меня покрытия, чтобы поймать то, о чём я не думаю?» Тесты не могут ответить на этот вопрос. Только понимание может.

Данные это подтверждают. Разработчики, делегирующие ИИ генерацию кода, набирают менее 40% на тестах понимания. Разработчики, использующие ИИ для концептуальных вопросов — исследования компромиссов, выяснения «почему» — набирают выше 65%. Инструмент не разрушает понимание. Его разрушает то, как вы этот инструмент используете.

Спецификации — тоже не спасут

Популярное предложение: напишите подробную спецификацию на естественном языке. Включите её в PR. Ревьюьте спецификацию, а не код. Доверьтесь тому, что ИИ точно перевёл намерение в реализацию.

Это привлекательно ровно так же, как когда-то был привлекателен Waterfall. Строго определите проблему, затем исполните. Чистое разделение ответственности.

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

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

Глубинная проблема в том, что «правильной» спецификации часто не существует. Требования возникают в процессе создания. Крайние случаи обнаруживаются при использовании. Предположение о том, что нетривиальную систему можно полностью описать до её создания, проверялось многократно и было признано несостоятельным. ИИ этого не меняет — он лишь добавляет новый слой неявных решений, принятых без человеческого обдумывания.

Учитесь у истории

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

Что меняется с ИИ: стоимость (резко ниже), скорость (резко выше), управленческие накладные расходы на межличностное взаимодействие (практически ноль). Что не меняется: потребность в человеке с глубоким контекстом системы, который поддерживает связное понимание того, что кодовая база действительно делает и почему.

Это некомфортное перераспределение, к которому вынуждает долг понимания.

По мере роста ИИ-объёмов инженер, который по-настоящему понимает систему, становится более ценным, а не менее. Способность посмотреть на дифф и мгновенно понять, какие поведения несут нагрузку. Помнить, почему то архитектурное решение было принято под давлением восемь месяцев назад. Отличить безопасный рефакторинг от того, который тихо сдвигает нечто, от чего зависят пользователи. Этот навык становится дефицитным ресурсом, от которого зависит вся система.

Проблема измерения — метрики не видят этот долг

Долг понимания так опасен именно потому, что ничто в текущей системе измерений его не отражает.

Метрики скорости (velocity) выглядят безупречно. DORA-метрики держатся стабильно. Количество PR растёт. Покрытие кода тестами — зелёное.

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

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

Организационное допущение «отревьюенный код = понятый код» больше не работает. Инженеры утверждали код, который они не до конца понимали, — и этот код теперь несёт неявное одобрение. Ответственность распределилась, а заметить это не успел никто.

Регуляторы придут быстрее, чем вы думаете

Каждая индустрия, которая двигалась слишком быстро, в итоге привлекала регулирование. Технологический сектор был необычно защищён от этой динамики — отчасти потому, что сбои в ПО часто обратимы, отчасти потому, что индустрия двигалась быстрее, чем регуляторы успевали реагировать.

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

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

Что на самом деле требует долг понимания

Правильный вопрос сейчас — не «как генерировать больше кода?», а «как понимать больше из того, что мы отгружаем?» — чтобы пользователи получали стабильно качественный продукт.

Этот сдвиг фокуса имеет практические следствия:

• Будьте безжалостно явными в том, что изменение должно делать, прежде чем оно будет написано.
• Рассматривайте верификацию не как послесловие, а как структурное ограничение.
• Поддерживайте ментальную модель системного уровня, которая позволяет ловить ошибки ИИ на уровне архитектуры, а не построчно.
• Будьте честны относительно разницы между «тесты прошли» и «я понимаю, что это делает и почему».

Удешевление генерации кода не удешевляет понимание. Работа по пониманию — это и есть работа инженера.

ИИ берёт на себя перевод. Но кто-то по-прежнему должен понимать, что было произведено, почему именно так и были ли эти неявные решения правильными — иначе вы просто откладываете счёт, который в конце концов придёт с полной суммой.

Вы заплатите за понимание рано или поздно. Проценты по этому долгу растут быстро.

Частые вопросы

Чем долг понимания отличается от технического долга?

Технический долг — обычно осознанный компромисс. Вы знаете, где лежит короткий путь, и можете запланировать рефакторинг. Долг понимания накапливается невидимо: код выглядит чистым, тесты зелёные, но никто в команде не может объяснить, почему система работает именно так. Расплата приходит внезапно — когда простое изменение ломает всё каскадом.

Значит ли это, что ИИ-инструменты для кодинга вредны?

Нет. Исследование Anthropic показало, что инструмент не разрушает понимание — его разрушает способ использования. Пассивное делегирование («сделай за меня») снижает понимание, а активное использование для концептуальных вопросов и исследования компромиссов — нет. Ключ в том, чтобы использовать ИИ как партнёра для мышления, а не как замену мышлению.

Как измерить долг понимания в команде?

Прямых метрик пока нет — в этом и проблема. Косвенные индикаторы: частота каскадных сбоев от «простых» изменений, время на onboarding новых разработчиков, способность членов команды объяснить архитектурные решения без обращения к коду. Если никто не может ответить «почему это сделано именно так» — долг уже высок.

Что делать прямо сейчас?

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

Выводы

Долг понимания — это не повод отказываться от ИИ-инструментов. Это повод осознанно управлять ценой, которую мы платим за скорость. Адди Османи формулирует это точно: код стал дешёвым в производстве, но понимание дешёвым не стало. И чем больше мы генерируем, тем дороже обходится разрыв.

Оригинал статьи: Comprehension Debt — the hidden cost of AI generated code (Addy Osmani, март 2026).

Он опубликовал 113 уроков, которые вынес из этого опыта. Мы отобрали самые ценные, сгруппировали по темам и адаптировали для русскоязычной аудитории. Каждый урок — практический: его можно взять и применить в своём проекте уже сегодня.

Ключевые выводы

— Кэширование — последняя мера. Сначала исправьте модель данных, индексы и N+1-запросы.
— E2E-тесты на happy path дают в 10 раз больше отдачи, чем юнит-тесты на отдельные методы.
— Доведите Sentry до inbox zero — это единственный самый мощный шаг для качества продукта.
— Не обвиняйте конкретного разработчика за баг в проде: это всегда каскад из 3+ ошибок системы.
— Деплой за 2 минуты вместо 28 — достижимо, и это меняет культуру принятия решений.

Про архитектуру и масштабирование

Используйте сервисные объекты вместо раздувания моделей

В фреймворках, где модели строятся вокруг существительных (Product, User, Auction), логика неизбежно скапливается в этих классах. Со временем каждый из них превращается в монстра на тысячи строк. Решение — выносить процессы в отдельные сервисные объекты: PlaceAuctionBidService, ProductBillingService. Суть — перестать мыслить существительными и начать мыслить глаголами.

Одна и та же вещь, реализованная дважды — провал технического лидерства

Если в кодовой базе есть два разных клиента к одному платёжному провайдеру, три файла с функциями для работы с датами или дублирующиеся UI-компоненты — это симптом отсутствия ответственного за архитектуру. Создавайте очевидные, легко находимые места для общего кода (common/datetime.py, common/geo.py) и отмечайте переиспользуемый код на ревью.

Полиморфные связи в БД — почти всегда ошибка

ORM-код для полиморфных отношений становится крайне запутанным, и вы теряете защиту через foreign key constraints. Проще добавить nullable FK для каждой связанной модели и написать абстракции на уровне запросов.

Дефолтные фильтры и сортировки в ORM — всегда ошибка

Скрытые дефолты вроде order_by('-id') или filter(is_deleted=False) становятся миной замедленного действия, когда в команде 20+ человек. Новый разработчик не знает про неявное поведение — и получает баг. А скрытый ORDER BY портит аналитические запросы, потому что ORM добавляет ключ сортировки в SELECT.

Вся инфраструктура — в коде

Когда Джек пришёл в MorphMarket, все 27 крон-задач были настроены вручную на продакшн-сервере. Большинство отсутствовали на staging. Перенос в код (а затем конфигурация AWS/Heroku/CloudFlare/Sentry через Terraform) сделал все окружения похожими друг на друга — и, что важно, сделал инфраструктуру доступной для чтения AI-агентам.

Про тестирование

E2E > интеграционные > юнит-тесты

Пользователям важно, чтобы система работала целиком. Один E2E-тест на happy path каждой ключевой фичи (регистрация, покупка, создание листинга) даёт на порядок больше уверенности, чем десятки юнит-тестов. Детали дорабатывайте интеграционными и юнит-тестами — они быстрее и проще в поддержке.

Автоматические тесты для шаблонных фич

В MorphMarket написали систему, которая автоматически тестирует около 300 админ-страниц: парсит имя страницы, находит фабрику, создаёт запись в БД и проверяет, что страница открывается. Тот же подход можно применить к любому CRUD-эндпоинту без выделенного теста.

Изолируйте тесты полностью

Хрупкость тестов убивает мотивацию команды. Основные ловушки:

• Всё, что связано со временем — замораживайте или мокайте
• Фиксируйте seed для всех источников случайности — в каждой библиотеке
• Запретите реальные HTTP-запросы в не-E2E тестах (используйте VCR-подобные библиотеки)
• Отдельный Redis для тестов с автоочисткой перед каждым тестом
• Тестовая среда не должна читать ни одной переменной из вашего .env

Мокайте только внешние объекты

Мок — полезный инструмент, но только для внешних зависимостей. Мокать внутренние методы тестируемого класса — антипаттерн. Если можно переписать тест без мока без потери скорости — так и сделайте.

CI должен проверять не только ошибки, но и раздражающие мелочи

В MorphMarket CI также ловит новые warning-и в тестах, рассинхронизацию SDK с бэкендом и забытые миграции в Django. Чем раньше замечена мелочь, тем дешевле её исправить.

Про отладку и мониторинг

Sentry до inbox zero — самый мощный шаг к качеству

Когда Джек пришёл в компанию, Sentry показывал 1 000 ошибок в час. После агрессивной фильтрации (игнор старых браузеров, расширений, пометка JavaScript-ошибок уникальным идентификатором) и починки реальных багов — меньше 1 ошибки в час. Результат: каждая новая ошибка стала событием, на которое команда реагирует немедленно.

Dead Man Switch — мониторьте то, что должно происходить

Исключения шумят и легко ловятся. А вот отсутствие события — нет. Если крон-система перестала работать или бэкапы БД не снимаются — вы узнаете об этом только через heartbeat-мониторы. Настройте их.

Username в каждой строке лога

По умолчанию в логах — только IP-адрес. Но IP ротируется, создаёт лишнее перенаправление при дебаге и не показывает картину при использовании нескольких устройств. Поместите текущий запрос в thread-local и добавьте username в каждую запись.

Трипвайр-алерты на 20 самых важных эндпоинтов

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

Громко падайте при ошибках

Не глушите исключения except: pass. Паттерн от Джека: крашиться локально, мягко отказывать в проде — но всегда отправлять ошибку в Sentry/логи. Чем раньше заметили — тем меньше ущерб.

Про работу в команде

Не обвиняйте одного человека за баг в проде

Любой инцидент — это каскад минимум трёх провалов: автор не заметил, ревьюер пропустил, QA не покрыло, тесты не проверили, архитектура допустила класс ошибки. Обвинение одного человека мешает команде видеть системные причины.

Все разработчики должны быть немного фулстек

В MorphMarket убрали строгое деление на фронтенд/бэкенд/ops. Переобучение заняло год, но окупилось: фронтендер добавляет поле в БД сам, а не ждёт бэкендера — это сокращает время доставки фич.

Пятницы технического долга

Разумный компромисс между CEO, который хочет фичи, и инженерами, которым нужна чистота кода: с понедельника по четверг приоритеты задаёт продукт, а по пятницам — CTO. Бонус: инженеры отдыхают на глубоких задачах перед выходными.

Запретите длинные PR

В MorphMarket был период, когда PR висели по 3 месяца и накапливали тысячи изменений. Их невозможно ревьюить, они конфликтуют с master и создают огромный деплой-риск. Новое правило: мерж в master каждые 1–2 дня, максимум — раз в неделю. Побочный эффект: старшие разработчики дают фидбэк раньше, и драматические переписывания случаются реже.

Поощряйте общение в удалённых командах

Джек начал с ежедневных постов о прогрессе, потом стал публично задавать вопросы (даже на которые знал ответ), делиться изменениями в коде и просить мнения. Это постепенно снизило барьер и сделало общение нормой, а не исключением.

Про производительность

N+1-запросы — враг номер один в ORM

Проблема проявляется на крупных эндпоинтах, которые постепенно расширяют разные авторы: новые фильтры и параметры создают спорадические N+1, которые возникают только при определённом сочетании фильтров и объёме данных. Настройте APM (например, New Relic) для автоматического обнаружения N+1 и обучите команду ловить их на ревью.

Кэширование — последняя мера

Код кэширования чудовищно сложен в поддержке. Сначала исправьте модель данных, допишите индексы, уберите N+1, оптимизируйте алгоритмы. И только после этого — кэш. Джек рассказывает о случаях, когда наивный кэш работал на малых объёмах, но убивал Redis (он однопоточный!) при росте данных на два порядка.

Таймауты на всех уровнях — иммунная система сервиса

Веб-запрос должен завершиться за 25 секунд — иначе убивается. Да, для длинных задач придётся использовать фоновые задачи, но без таймаутов одна тормозящая внешняя API может съесть все потоки сервера и уронить всё.

Выгружайте работу в фоновые задачи

Отправка email, push-уведомления, обработка вебхуков от платёжных систем — всё это должно уходить в очередь. Веб-процесс обязан оставаться быстрым.

ORDER BY id вместо ORDER BY created

Если поле created неизменяемо и совпадает по порядку с id — сортируйте по id. Индекс на id уже есть бесплатно в каждой таблице.

Удаляйте ненужные данные

В MorphMarket некоторые таблицы копили 10 лет данных — логи IP-адресов, записи push-уведомлений, сообщения девятилетней давности. Скрипт очистки делает эти таблицы компактнее и быстрее.

Про безопасность и надёжность

Начните с модели угроз: что может получить атакующий?

Для MorphMarket основные вектора: захват аккаунтов (фикс — обязательный 2FA), спам-фишинг (капча на регистрации + фильтры сообщений), DDoS (Cloudflare + rate limit на nginx + кэш ключевых эндпоинтов). Универсального подхода нет — каждый сервис должен понимать свою специфику.

CHECK-ограничения в БД — лучше предотвратить, чем чинить

Раньше в MorphMarket крон-задача раз в сутки проверяла целостность данных и слала алерты. Всё заменили на CHECK constraints на уровне БД — некоторые проверяют до 16 операций над разными колонками. Невалидные данные просто не могут быть записаны.

Вебхуки — рассадник race conditions

Действие в коде может вызвать вебхук, который прилетит быстрее, чем данные запишутся в БД. Получатель вебхука прочитает устаревшее состояние и может затереть свежие данные. Решение: откладывайте действия, вызывающие вебхуки, до on_commit в БД.

Логируйте намерение перед побочным эффектом — особенно для платежей

Перед списанием с карты или возвратом пишите в лог: "bill user XYZ $100 for Y". Простой Write-Ahead Log спасал MorphMarket в нескольких инцидентах.

Про деплой

Деплой должен быть быстрым — действительно быстрым

MorphMarket сократил деплой с 28 минут до 2. Как: разделили фронтенд и бэкенд, распараллелили, перешли на Rust-based компиляцию JS, вынесли сборку на мощные машины (MacBook M-series вместо commodity Heroku), убрали из слага всё ненужное, почистили старые ассеты из S3.

Smoke-тест после каждого деплоя в прод

Автоматическая проверка ключевых страниц через Playwright после каждого деплоя. Если последние 150 деплоев были скучными — соблазн перестать проверять вручную огромен. Автоматический smoke-тест не устаёт и не теряет бдительность.

Не деплойте ничего рискованного в пятницу

Баг может проявиться вечером или в субботу, когда никого нет. Мелкие хотфиксы и изменения в админке — можно. Всё остальное — до четверга.

Плейбук для инцидентов при деплое

Короткие инструкции: как убить залипшие соединения к БД, точечно почистить кэш (без flush, который разлогинит всех), форсировать обновление ассетов. Обученная команда сокращает даунтайм в разы.

Про карьерный рост — от тимлида до CTO

Научитесь говорить о производительности сотрудников

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

Документ ожиданий от сотрудника

Если написать "мы ценим, когда вы решаете проблемы в #bug-discussion до того, как они дойдут до CTO", люди действительно начнут так делать. Мотивированный сотрудник хочет ясности. Он не может прочитать ваши мысли.

Одно крупное изменение за раз

Внедряете E2E-тесты? Доведите до стабильности, прежде чем браться за линтеры. Если система сделана плохо — команда не будет ей доверять и не будет использовать. Плюс есть предел того, сколько изменений люди могут усвоить одновременно.

CLI-инструменты + AI = максимальный рычаг

AI отлично работает с текстом. CLI-инструменты тоже. Дайте AI доступ к продакшн-логам, отчётам об ошибках, read-only реплике БД, CI-результатам и REPL — и получите огромный множитель продуктивности. Джек называет это "наблюдаемость через CLI — ваш главный усилитель для AI".

FAQ

Почему монолит, а не микросервисы?

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

С чего начать, если в проекте уже бардак?

С Sentry до inbox zero и таймаутов на веб-запросы. Первое даёт видимость реальных проблем, второе предотвращает каскадные отказы. Дальше — по статье: N+1, изоляция тестов, сервисные объекты.

Насколько эти уроки применимы за пределами Django?

Джек 17 лет работал с Rails, Laravel, Express и другими фреймворками — и подчёркивает, что большинство уроков переносимы. N+1, дефолтные сортировки, race conditions в вебхуках, инфраструктура как код — всё это не привязано к конкретному стеку.

Правда ли, что E2E-тесты лучше юнит-тестов?

Не лучше, а дают больше отдачи на первом этапе. Один E2E-тест на happy path покрывает весь стек. Юнит-тесты нужны для деталей и граничных случаев, но начинать покрытие лучше сверху вниз.

Выводы

113 уроков Джека Кинселлы — это не теория из книг, а выжимка из 7 лет ежедневной работы над монолитом, который обслуживает реальных пользователей. Главные принципы:

• Предотвращайте, а не чините — CHECK constraints, таймауты, линтеры
• Делайте невидимое видимым — логи, мониторинг, Sentry до inbox zero
• Инвестируйте в скорость обратной связи — быстрый деплой, быстрый CI, короткие PR
• Доверяйте людям и системе, а не контролю — fullstack-навыки, плейбуки, документ ожиданий

Оригинальная статья: Scaling a Monolith to 1M LOC: 113 Pragmatic Lessons from Tech Lead to CTO (Semicolon & Sons, Jack Kinsella).

Если знаете коллегу, который борется с растущим монолитом — отправьте ему эту статью. А в комментариях расскажите, какой урок оказался самым неожиданным для вас.

Нет. WebAssembly победил — просто не так, как все ожидали.

Главное: WebAssembly не заменил JavaScript в браузере — и не должен был. Его главная роль — мост между языками. Figma, Godot, Squoosh, Cloudflare Workers, Zellij — все они используют Wasm, но вы этого не замечаете — и это нормально.

Где Wasm уже работает

• Figma — конвертирует C++ кодовую базу в браузерное приложение + запускает пользовательские плагины в песочнице через QuickJS+Wasm
• Godot — сборка игр для веба
• Squoosh.app — использует C/C++ библиотеки сжатия изображений прямо в браузере
• Stackblitz — веб-контейнеры на Wasm
• Ruffle — эмулятор Flash в браузере
• Cloudflare Workers — запуск недоверенного кода через V8 isolates
• Zellij, Envoy, Lapce — экосистема плагинов на Wasm

Что такое WebAssembly на самом деле

WebAssembly — это язык. Более точно — байткод, похожий на JVM bytecode, но с меньшим API, более строгими гарантиями безопасности и без мнений о том, как управлять памятью.

Он достаточно низкоуровневый, чтобы чисто компилироваться под большинство архитектур без значительных потерь скорости. При этом Wasm-программа не может ничего без явного разрешения хоста — ни читать файлы, ни ходить в сеть. Всё внешнее — через импорты.

Цель компиляции, не язык разработки

В Wasm компилируются десятки языков: Rust, C, Zig, Go, Kotlin, Java, C#. Даже интерпретируемые языки работают — их рантаймы компилируются в Wasm (Python через Pyodide, PHP, Ruby). Есть и языки, которые компилируются исключительно в Wasm: AssemblyScript, Grain, MoonBit.

Ваш браузер уже умеет запускать Wasm. Но есть и автономные рантаймы: Wasmtime, WasmEdge, Wasmer — аналоги JVM, но для Wasm.

Безопасность — главное преимущество

Всё внешнее взаимодействие — явные импорты от хоста. Это даёт изоляцию на уровне процесса внутри одного процесса. Cloudflare запускает недоверенный код через V8 isolates — старт в 100 раз быстрее, чем отдельный процесс. Fermyon заявляет о старте менее чем за миллисекунду.

Мост между языками — главная роль

Самое распространённое применение — мост между языками. В большинстве случаев Wasm прозрачен для вас — какая-то библиотека просто использует его в дереве зависимостей. Это обработка изображений, OCR, физические движки, рендеринг, базы данных, парсеры.

Ограничения

• В браузере Wasm работает через тот же пайплайн, что и JS — потолок на производительность
• Пересечение границы хост-программы стоит дорого — пост-мортем Zaplib показал, что постепенная миграция может не дать выигрыша
• Нет нативного строкового типа — системные API приходится пересоздавать, WASI помогает частично
• Самые компактные бинарники даёт Zig, самые тяжёлые без оптимизации — Rust

Почему кажется, что ничего не произошло

Wasm-инструменты массово используются авторами библиотек, а не разработчиками приложений. Внутренности непрозрачны — и это нормально. Многие ожидали, что можно будет обойтись без .js файлов вообще — это крайне маловероятно, ни один вендор браузеров не работает над этим.

Фреймворки Blazor (.NET) и Leptos (Rust) позволяют писать веб-приложения без прямого контакта с JS. Стандартизация идёт: WasmGC уже в Chrome, Firefox и Safari; Component Model развивается в Bytecode Alliance.

FAQ

WebAssembly быстрее JavaScript?

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

Wasm заменит JavaScript?

Крайне маловероятно. JS остаётся языком браузера, Wasm дополняет его там, где нужны вычисления, безопасность или доступ к библиотекам из других языков.

С чего начать?

Попробуйте watlings — упражнения по ручному написанию WAT в стиле rustlings. А для практического применения — wasm-pack для Rust.

Источник: What Happened To WebAssembly — EmNudge

Корпоративное ядро: как оно устроено

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

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

В корпоративном сегменте энергетики ядро состоит из набора базовых сервисов: каталог, почта, коммуникации, документооборот, файловый слой, рабочие места и защита. Его фундамент – доменная структура, часто на Alt Domain или RedADM (службы на базе Samba DC): эти решения без сюрпризов проходят проверки совместимости и корректно работают с Kerberos и LDAP.

В реальных проектах переход к новому домену почти всегда начинается с гибридного режима. Старый Active Directory продолжает хранить SID и привязки приложений – без trust-связей массовую миграцию просто не запустить. Так домен становится точкой опоры для всех остальных компонентов. Почта – один из первых сервисов в корпоративном сегменте, который начинает жить по доменной модели: учетные записи, группы, права. И чаще всего именно она на прикладном уровне первой замечает любые отклонения в каталоге.

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

Документооборот и файловый сервис – отдельный слой. Для пользователя это привычные папки с доступом к документам, но под капотом здесь ролевая модель, оргструктура и строгие ACL. Когда включается централизованная модель прав, самодельные сетевые диски исчезают из контура, а файловый слой превращается в управляемую систему доступа.

На уровне ниже находится невидимый пласт сервисов, на которых держится все ядро: DNS/DHCP домена, репликация, политики и настройки безопасности. Ошибки в любом из них могут спровоцировать каскад проблем – от задержек авторизации до потери доступа у части пользователей. На такие сценарии и заточены внутренние ППИ/ПМИ каждого компонента. Сценарии отрабатывают вручную, фиксируют протоколы, закрывают замечания – и только после этого переходят к пилоту.

Все это – «серверная» часть ядра. Но самый сложный участок начинается там, где архитектура сталкивается с пользователями – на АРМ (рабочих станциях). Здесь требуется подключение к каталогу, перенос профилей, миграция данных, проверка приложений, контроль целостности и унификация конфигураций.

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

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

В рамках такой стандартизации на пользовательском уровне и появляется частичный dual-OS: критичные приложения остаются в Windows, а пользовательская среда переезжает в Linux. Это самый безопасный способ пройти миграцию без остановки процессов.

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

Как выглядит внедрение на практике

На проектах внедрение почти всегда проходит в три этапа.

1. Прототипирование – создание в миниатюре будущей инфраструктуры и выявление несовместимостей.
2. Настройка паттернов – сборка образов, настройка групп, OU, профилей, fallback-логики.
3. Переходный период – введение dual-OS, выравнивание политик и подготовка к ОПЭ.

Прототипирование занимает от трех до шести месяцев. На этом этапе всплывает все, что невозможно увидеть на этапе проектирования. Где-то рабочие станции не загружаются на новых образах без обновления BIOS. Где-то плоттеры, сканеры и терминалы требуют ручной настройки. Профили Windows при переносе в Linux теряют ярлыки, MIME-ассоциации и политики. Если корпоративный домен в гибридном режиме, любое расхождение по времени, сбой Kerberos или конфликт GPO могут вывести из строя авторизацию на половине контура.

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

Но часть задач паттернами не решить – слишком много рабочих мест держится на Windows-приложениях. Поэтому dual-OS закрепляется как рабочая норма в корпоративном контуре: пользовательский профиль — в Linux, технологические приложения — в Windows, а архитектура постепенно приводится к единому набору политик, профилей и прав.

Откат в этом контуре обязателен. Пользователь должен иметь возможность вернуться в привычную среду в любой момент. На практике команда стремится уложиться в 10–15 минут – иначе миграционный участок становится неуправляемым

Даже после перехода в ОПЭ двухслойная конфигурация сохраняется. Часть сервисов – на новой платформе, часть – на старой. Пока среды существуют параллельно, они должны быть синхронны. Расхождение в правах, политиках или репликации моментально ломает согласованность контуров – и превращается в локальный инцидент.

Информационная безопасность как каркас архитектуры

Эта архитектура не может существовать без четкой рамки ИБ. Причем ИБ здесь – не надстройка, а несущая конструкция. Она определяет, что допустимо в контуре, а что нет, и где проходят реальные границы риска.

Виртуализацию разрешают только там, где можно контролировать изоляцию гостевых систем. Каналы управления – только внутри защищенных сегментов. Требования к виртуализации опираются на ГОСТ 56938: разделение зон исполнения, защита потоков управления, никаких «черных ящиков» в обновлениях.

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

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

С данными та же история – они требуют отдельного контура контроля. Кто имеет доступ, где лежат журналы, что мы считаем инцидентом – эти вопросы нельзя решать по остаточному принципу. Ответы на них должны быть зашиты в архитектуру подсистем с самого начала.

И все это не имело бы смысла без гарантированного восстановления: система должна уметь возвращать себя в рабочее состояние через резервные копии, откат и проверенные сценарии. Например, компания в финсекторе после отказа всей инфраструктуры, потери ЦОД должна заработать через 2 часа.

Стандартизация через эксплуатацию

Когда среду удается стабилизировать на первой площадке, возникает главный вопрос: можно ли повторить тот же результат без пересборки с нуля? В энергетике – можно.

Конечно же, у компаний в разных регионах – своя история, парк оборудования или глубина легаси. Но архитектурные требования одинаковые везде. Они и формируют единый «слепок» корпоративного ядра при сохранении изоляции КИИ-контуров: правила для каталога, почты, коммуникаций и подготовки рабочих мест.

Если система стабильно прошла ОПЭ на одной площадке, она, как правило, так же ведет себя и на других

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

Импортонезависимое ядро – основа цифровой устойчивости

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

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

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

Корпоративное ядро: как оно устроено

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

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

В корпоративном сегменте энергетики ядро состоит из набора базовых сервисов: каталог, почта, коммуникации, документооборот, файловый слой, рабочие места и защита. Его фундамент – доменная структура, часто на Alt Domain или RedADM (службы на базе Samba DC): эти решения без сюрпризов проходят проверки совместимости и корректно работают с Kerberos и LDAP.

В реальных проектах переход к новому домену почти всегда начинается с гибридного режима. Старый Active Directory продолжает хранить SID и привязки приложений – без trust-связей массовую миграцию просто не запустить. Так домен становится точкой опоры для всех остальных компонентов. Почта – один из первых сервисов в корпоративном сегменте, который начинает жить по доменной модели: учетные записи, группы, права. И чаще всего именно она на прикладном уровне первой замечает любые отклонения в каталоге.

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

Документооборот и файловый сервис – отдельный слой. Для пользователя это привычные папки с доступом к документам, но под капотом здесь ролевая модель, оргструктура и строгие ACL. Когда включается централизованная модель прав, самодельные сетевые диски исчезают из контура, а файловый слой превращается в управляемую систему доступа.

На уровне ниже находится невидимый пласт сервисов, на которых держится все ядро: DNS/DHCP домена, репликация, политики и настройки безопасности. Ошибки в любом из них могут спровоцировать каскад проблем – от задержек авторизации до потери доступа у части пользователей. На такие сценарии и заточены внутренние ППИ/ПМИ каждого компонента. Сценарии отрабатывают вручную, фиксируют протоколы, закрывают замечания – и только после этого переходят к пилоту.

Все это – «серверная» часть ядра. Но самый сложный участок начинается там, где архитектура сталкивается с пользователями – на АРМ (рабочих станциях). Здесь требуется подключение к каталогу, перенос профилей, миграция данных, проверка приложений, контроль целостности и унификация конфигураций.

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

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

В рамках такой стандартизации на пользовательском уровне и появляется частичный dual-OS: критичные приложения остаются в Windows, а пользовательская среда переезжает в Linux. Это самый безопасный способ пройти миграцию без остановки процессов.

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

Как выглядит внедрение на практике

На проектах внедрение почти всегда проходит в три этапа.

1. Прототипирование – создание в миниатюре будущей инфраструктуры и выявление несовместимостей.
2. Настройка паттернов – сборка образов, настройка групп, OU, профилей, fallback-логики.
3. Переходный период – введение dual-OS, выравнивание политик и подготовка к ОПЭ.

Прототипирование занимает от трех до шести месяцев. На этом этапе всплывает все, что невозможно увидеть на этапе проектирования. Где-то рабочие станции не загружаются на новых образах без обновления BIOS. Где-то плоттеры, сканеры и терминалы требуют ручной настройки. Профили Windows при переносе в Linux теряют ярлыки, MIME-ассоциации и политики. Если корпоративный домен в гибридном режиме, любое расхождение по времени, сбой Kerberos или конфликт GPO могут вывести из строя авторизацию на половине контура.

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

Но часть задач паттернами не решить – слишком много рабочих мест держится на Windows-приложениях. Поэтому dual-OS закрепляется как рабочая норма в корпоративном контуре: пользовательский профиль — в Linux, технологические приложения — в Windows, а архитектура постепенно приводится к единому набору политик, профилей и прав.

Откат в этом контуре обязателен. Пользователь должен иметь возможность вернуться в привычную среду в любой момент. На практике команда стремится уложиться в 10–15 минут – иначе миграционный участок становится неуправляемым

Даже после перехода в ОПЭ двухслойная конфигурация сохраняется. Часть сервисов – на новой платформе, часть – на старой. Пока среды существуют параллельно, они должны быть синхронны. Расхождение в правах, политиках или репликации моментально ломает согласованность контуров – и превращается в локальный инцидент.

Информационная безопасность как каркас архитектуры

Эта архитектура не может существовать без четкой рамки ИБ. Причем ИБ здесь – не надстройка, а несущая конструкция. Она определяет, что допустимо в контуре, а что нет, и где проходят реальные границы риска.

Виртуализацию разрешают только там, где можно контролировать изоляцию гостевых систем. Каналы управления – только внутри защищенных сегментов. Требования к виртуализации опираются на ГОСТ 56938: разделение зон исполнения, защита потоков управления, никаких «черных ящиков» в обновлениях.

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

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

С данными та же история – они требуют отдельного контура контроля. Кто имеет доступ, где лежат журналы, что мы считаем инцидентом – эти вопросы нельзя решать по остаточному принципу. Ответы на них должны быть зашиты в архитектуру подсистем с самого начала.

И все это не имело бы смысла без гарантированного восстановления: система должна уметь возвращать себя в рабочее состояние через резервные копии, откат и проверенные сценарии. Например, компания в финсекторе после отказа всей инфраструктуры, потери ЦОД должна заработать через 2 часа.

Стандартизация через эксплуатацию

Когда среду удается стабилизировать на первой площадке, возникает главный вопрос: можно ли повторить тот же результат без пересборки с нуля? В энергетике – можно.

Конечно же, у компаний в разных регионах – своя история, парк оборудования или глубина легаси. Но архитектурные требования одинаковые везде. Они и формируют единый «слепок» корпоративного ядра при сохранении изоляции КИИ-контуров: правила для каталога, почты, коммуникаций и подготовки рабочих мест.

Если система стабильно прошла ОПЭ на одной площадке, она, как правило, так же ведет себя и на других

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

Импортонезависимое ядро – основа цифровой устойчивости

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

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

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

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

Все это создает ощущение, что достаточно лишь подробно описать задачу и агент сможет реализовать ее целиком.

Однако на практике этот подход перестает работать, когда проект выходит за рамки отдельных изменений.

Спецификации не заменяют разработку

Автор отмечает, что вайб-кодинг подталкивает к иллюзии «достаточно хорошего ТЗ». Мол, если результат неудовлетворительный, проблема якобы в недостаточно точном запросе.

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

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

Они фиксируют ранние допущения и продолжают следовать им, даже когда контекст изменился.

Код выглядит правильно, но система разваливается

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

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

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

Рост технического долга и потеря контроля

Со временем, по его словам, такой код становится сложно поддерживать. Даже сам ИИ начинает хуже ориентироваться в сгенерированной им кодовой базе. Любая новая доработка требует все больше усилий, а исправление ошибок отнимает время, которое ранее «сэкономил» вайб-кодинг.

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

Возврат к ручному коду

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

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

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

Как развивались голосовые роботы, и почему они вышли в продакшн

Первые голосовые роботы на базе шаблонных IVR-сценариев были ограничены по функциональности. Они умели выполнять набор фиксированных действий: проговорить фразу, передать вызов оператору, собрать цифры с клавиатуры. Эти системы были надежны, но не гибки, а попытки «научить» их вести диалог заканчивались провалами из-за примитивных алгоритмов распознавания.

Резкий сдвиг произошел после появления нейросетевых ASR-систем (Automatic Speech Recognition) и моделей, способных понимать естественную речь, включая шумы, паузы и фоновые искажения. Порог ошибок снизился достаточно, чтобы роботы могли вести не сценарные диалоги и принимать решения на основе контекста, а не только заранее заданных переходов.

ИИ-агенты постепенно освоили способность:

• распознавать намерения (intent detection) в реальном времени,
• корректировать сценарий на лету,
• обрабатывать нестандартные запросы без жёстких скриптов.

Это вывело голосовую автоматизацию из разряда «интерактивных меню» в полноценный класс систем, которые могут заменить до 40–70% входящих обращений без участия оператора, если архитектура построена корректно.

Техническая архитектура современных ИИ-агентов

Телефонный AI-агент– это не одна нейросеть, а стек компонентов, которые должны работать синхронно и с минимальными задержками.

ASR – первый компонент в цепочке. Он должен конвертировать речь в текст с задержкой не больше 200–500 мс. Это критично для естественности диалога: если агент отвечает с задержкой больше секунды, пользователь начинает перебивать или повторять запрос.

Следующий слой – NLU (Natural Language Understanding). Он анализирует текст, выделяет намерение, ключевые сущности, оценивает эмоции и уровень срочности. На основе этого выбирается действие: ответить напрямую, переключиться на другой сценарий или передать вызов оператору.

Диалоговый менеджер синхронизирует историю общения. Он хранит контекст, отслеживает «ветки» диалога и контролирует, чтобы система не зашла в логические тупики. В сложных сценариях может использоваться RL-подход (обучение с подкреплением) для оптимизации решений агента.

TTS – последний слой в цепочке. Он генерирует речь. Качество синтеза стало настолько высоко, что монотонность и «роботизация» звучания устраняются настройкой голоса и интонационных моделей.

Интеграционный уровень связан с CRM, биллинговыми системами, внутренними API и внешними сервисами. Именно этот слой определяет, может ли агент выполнять реальные бизнес-задачи, а не просто разговаривать.

Автоматизация входящих звонков: что реально работает

Большая часть реальных внедрений автоматизации происходит в двух направлениях.

Первое – фильтрация и предобработка. Робот берёт на себя стандартные запросы: расписание, статус доставки, проверку баланса, подбор услуг, регистрацию обращения. Это снижает нагрузку на операторов и обрабатывает «массу», не требующую навыков.

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

В обеих зонах ключевым параметром является задержка. Если ASR+NLU не укладываются в realtime, пользователи воспринимают диалог как «повисший». Поэтому продакшн-системам приходится балансировать качество моделей и скорость выполнения.

Инженерные ограничения и реальные проблемы

Несмотря на впечатляющий прогресс, технических ограничений достаточно.

Главная проблема – шум и нестандартные речевые паттерны. Фоновый транспортный гул, акценты, обрывистая речь или попытки пользователей говорить слишком быстро увеличивают вероятность ошибок. Даже современные модели не всегда корректно распознают речь в агрессивной акустической среде.

Вторая проблема – сложность интеграций. Чтобы ИИ-агент решал реальные задачи, он должен уметь работать с внутренними системами компании. Старые CRM, закрытые API, нестабильный внутренний транспорт данных – всё это делает автоматизацию непредсказуемой и увеличивает задержки.

Третья проблема – логическая устойчивость диалога. Даже при наличии контекстного анализа система может «упасть» в сбойный сценарий, повторить вопрос или начать трактовать ответ неправильно. Поэтому операторы внедряют дополнительные контрольные слои, которые фиксируют отклонения диалога и переключают вызов на живого сотрудника.

Зачем операторам и бизнесу нужна голосовая автоматизация

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

Бизнес получает другую выгоду – масштабируемость. Человек ограничен по скорости обработки запросов, а ИИ – нет. При росте нагрузки система масштабируется горизонтально, не меняя качество обработки.

Автоматизация также позволяет фиксировать запросы в структурированном виде – это полезно для аналитики, прогнозирования загрузки и оптимизации сервисов.

Куда движется рынок

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

Модели стремятся к снижению задержек на уровне сотен миллисекунд, что делает голосовое взаимодействие практически неотличимым от разговора с человеком. ТTS становится живее, ASR – точнее, а диалоговые менеджеры – устойчивее.

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

Это краткое руководство поможет быстро разобраться с Lakehouse‑архитектурой (лейкхаус): ключевые особенности, сильные стороны, типовые сценарии, а также как быстро собрать решение на базе StarRocks. В конце вы найдёте практические шаги и реальные кейсы использования StarRocks Lakehouse.

Ссылки на официальные материалы:

• Подробный туториал StarRocks + Iceberg: https://docs.starrocks.io/en/docs/quick_start/iceberg/
• Iceberg Spark Quickstart: https://iceberg.apache.org/spark-quickstart/
• Видео‑демо: https://www.bilibili.com/video/BV1ET42167TY/?spm_id_from=333.999.0.0&vd_source=1cb452610138142d1300dd37a6162a88

Введение в Apache Iceberg

Apache Iceberg — открытый табличный формат, созданный для масштабных и сложных наборов данных (до ПБ и выше). Изначально разработан в Netflix для управления большим числом таблиц, открыт в инкубаторе Apache в 2018 году и получил статус верхнеуровневого проекта в 2020 году.

Iceberg располагается между вычислительными движками (например, Apache Flink и Apache Spark) и форматами хранения (ORC, Parquet, Avro), выступая прослойкой, которая абстрагирует сложность низкоуровневых форматов и предоставляет унифицированные табличные семантики. Такой дизайн обеспечивает гибкость операций и управления схемой в разных средах без привязки к конкретному движку хранения, с масштабированием в HDFS, S3, OSS и т. п.

Архитектура и ключевые компоненты

Архитектура Iceberg состоит из трёх слоёв:

• Слой данных: фактические файлы данных (Parquet, ORC и др.).
• Слой метаданных: многоуровневая структура со схемой таблицы и индексами файлов данных.
• Слой каталога (Catalog): указатели на местоположения файлов метаданных; доступны реализации вроде HadoopCatalog и HiveCatalog.

Управление метаданными включает три ключевых сущности:

• Файл метаданных (Metadata File): хранит текущую версию метаданных, включая все снимки.
• Снимок (Snapshot): отражает состояние таблицы после конкретной операции (коммита); новый коммит — новый снимок.
• Манифест (Manifest): перечисляет файлы данных, связанные со снимком, задаёт целостное представление организации данных и ускоряет поиск/модификации.

Цель Iceberg — отслеживать эволюцию таблицы во времени с помощью снимков, которые фиксируют полный набор файлов данных на произвольный момент. Каждый апдейт создаёт новый снимок, обеспечивая согласованность и упрощая историческую аналитику и инкрементальное чтение.

Ключевые возможности

• Скрытое партиционирование (Hidden partitioning): автоматическое разбиение по времени и другим функциям без необходимости знать детали партиций.
• Эволюция схемы (Schema evolution): безопасные изменения структуры таблицы без переписывания данных, с историей изменений.
• Эволюция партиционирования (Partition evolution): смена стратегии партиционирования без воздействия на исторические данные; новые данные следуют новой стратегии.
• Многоверсионный контроль (MVCC): записи не блокируют чтения; управление через Manifest‑файлы.
• ACID‑транзакции: оптимистичная блокировка для конкурентных записей, атомарность операций.
• Обновления на уровне строк: в v1 — Copy‑on‑Write (COW), в v2 — Merge‑on‑Read (MOR), поддержка position deletes и equality deletes для логических обновлений.

Преимущества Apache Iceberg

• Широкая поддержка движков вычислений: Spark, Flink, Hive и др.; есть нативный Java API.
• Гибкая организация данных: работает для потоковых инкрементальных и пакетных сценариев на единой модели хранения (HDFS, Apache Ozone и др.); поддерживает Parquet/ORC/Avro; скрытое партиционирование и эволюция партиций устраняют «островки данных».
• Оптимизированная загрузка данных (ingest): ACID делает новые данные мгновенно видимыми без влияния на текущие задачи; upsert/merge на уровне строк сокращают задержки.
• Инкрементальное чтение: встроенная интеграция со Spark Structured Streaming и Flink Table Source; поддержка исторических версий повышает надёжность и аудитируемость.

Типовые сценарии использования

• Импорт и запросы в реальном времени: непрерывная запись в таблицы Iceberg и мгновенная аналитика через Hive/Spark/Presto/Iceberg. ACID обеспечивает изоляцию и отсутствие «грязных» данных.
• Удаление/обновление данных: операции на уровне файлов вместо полной переработки таблицы; например, DELETE FROM test_table WHERE id > 10.
• Контроль качества данных: валидация схемы при загрузке; изменения схемы через DDL Spark SQL без переэкспорта исторических данных; ACID изолирует изменения схемы от текущих чтений.
• ML в реальном времени: конвейер подготовки данных (очистка/трансформации/feature engineering) превращается в надёжный поток; поддержка нативного Python SDK.

Ускорение запросов StarRocks × Iceberg

StarRocks эффективно анализирует как внутренние данные, так и данные в озере, поддерживает внешний каталог Iceberg (External Catalog) и позволяет запрашивать таблицы Iceberg без миграции данных. Поддерживаются Iceberg v1 и v2 (чтение/запись).

Оптимизации:

• Метаданные: кэш метаданных снижает избыточный I/O; распределённое планирование заданий ускоряет параллельное чтение/фильтрацию Manifest‑файлов; Manifest Cache уменьшает накладные расходы парсинга.
• План выполнения: стоимостной оптимизатор (CBO) использует статистики; StarRocks собирает статистики по внешним таблицам (включая гистограммы и сложные типы).
• Форматы файлов: оптимизации для Parquet/ORC снижают объём сканирования и I/O.
• Снятие различий между внешними и внутренними таблицами: кэш данных (Data Cache) снижает удалённый I/O; «умные» материализованные представления обеспечивают переписывание запросов и инкрементальное обновление.
• Интеграция с экосистемой: поддержка чтения/записи Iceberg упрощает обратную выгрузку в озеро и лёгкую переработку данных, улучшая производительность запросов и единое управление.

Быстрый старт

В рамках руководства вы:

• Развёрнёте объектное хранилище, Apache Spark, Iceberg Catalog и StarRocks с помощью Docker Compose.
• Импортируете данные в озеро Iceberg.
• Настроите StarRocks для доступа к Iceberg Catalog.
• Выполните запросы к данным озера из StarRocks.

Подробный учебник: https://docs.starrocks.io/en/docs/quick_start/iceberg/

Iceberg Spark Quickstart: https://iceberg.apache.org/spark-quickstart/

Развёртывание Iceberg

Чтобы добавить Iceberg в существующий Spark, достаточно подключить соответствующий JAR в параметры запуска. В данном руководстве используется контейнер tabulario/spark-iceberg — Spark уже с интегрированным Iceberg, что позволяет сразу работать в среде PySpark.

Окружение (Docker Compose)

Используется шесть контейнеров:

• starrocks-fe: метаданные, подключения клиентов, планирование и диспетчеризация запросов.
• starrocks-be: выполнение планов запросов.
• rest: сервис метаданных — Iceberg Catalog (REST).
• spark-iceberg: окружение Apache Spark для PySpark.
• mc: MinIO Client.
• minio: объектное хранилище MinIO.

Docker Compose файл (скачайте из репозитория StarRocks) настраивает:

• Iceberg REST‑каталог (http://iceberg-rest:8181) с CATALOG_WAREHOUSE=s3://warehouse/, S3FileIO и CATALOG_S3_ENDPOINT=http://minio:9000.
• MinIO с публичной политикой на bucket warehouse.
• Переменные доступа S3‑совместимого хранилища: AWS_ACCESS_KEY_ID=admin, AWS_SECRET_ACCESS_KEY=password.

Загрузка Docker Compose и набора данных

Запуск окружения в Docker

Подсказка: команды docker compose выполняйте из каталога, где лежит docker-compose.yml.

Дождитесь, когда starrocks-fe и starrocks-be перейдут в состояние healthy (обычно ~30 секунд).

Работа с PySpark и Iceberg

Скопируйте набор данных в контейнер spark-iceberg:

Запустите PySpark:

Загрузите данные в DataFrame и проверьте схему/выборку:

Создайте таблицу Iceberg и запишите в неё данные:

Примечание: таблица будет доступна через внешний каталог StarRocks (External Catalog) на следующем шаге.

Подключение к StarRocks и настройка доступа к Iceberg Catalog

Подключитесь к StarRocks из MySQL‑клиента (из контейнера FE):

Создайте внешний каталог iceberg в StarRocks:

Проверьте каталоги, переключитесь и посмотрите БД/таблицы:

Замечание по типам: в Spark

будет отображаться в StarRocks как

(и возможны другие конверсии типов).

Запросы к таблицам Iceberg из StarRocks

Время приёма заказа (первые 10 строк):

Пиковые часы по количеству поездок:

Видео‑демонстрация

Демонстрация StarRocks + Iceberg + MinIO (EN)https://www.bilibili.com/video/BV1ET42167TY/?spm_id_from=333.999.0.0&vd_source=1cb452610138142d1300dd37a6162a88

Расширенные материалы

• Apache Iceberg — Spark Quickstart: https://iceberg.apache.org/spark-quickstart/
• Apache Iceberg — Catalogs: https://iceberg.apache.org/docs/latest/catalogs/
• Apache Iceberg — REST Catalog: https://iceberg.apache.org/docs/latest/rest-catalog/
• StarRocks — Quick Start с Iceberg: https://docs.starrocks.io/en/docs/quick_start/iceberg/
• StarRocks — External Catalog (Iceberg): https://docs.starrocks.io/en/docs/data_source/catalog/iceberg_catalog/

Примечания по терминологии

• Catalog → каталог; External Catalog → внешний каталог (External Catalog).
• Metadata File / Snapshot / Manifest — используем русские эквиваленты с английскими терминами в скобках при первом упоминании.
• Hidden partitioning → скрытое партиционирование.
• Schema/Partition evolution → эволюция схемы/партиционирования.
• MVCC, ACID, CBO, Data Cache, Manifest Cache, Copy‑on‑Write (COW), Merge‑on‑Read (MOR), position/equality deletes — используем английские аббревиатуры/термины, так как это общепринятая практика в индустрии.

Три истории о коде и ИИ

История первая: Магия автоматизации

Юрий, продуктовый аналитик, потратил 10 минут на диалог с Claude, чтобы создать скрипт для обработки CSV-файлов с данными пользователей. Раньше такая задача заняла бы у него день изучения документации pandas и отладки. Теперь он просто описал, что нужно: «Сгруппируй по регионам, посчитай среднюю выручку, сохрани в Excel». Получил рабочий код, запустил — всё работает идеально.

История вторая: Цена доверия

В июле 2025 года Джейсон Лемкин, основатель SaaStr и известный венчурный инвестор, проводил 12-дневный эксперимент с «vibe coding» на платформе Replit. На девятый день, несмотря на явное указание «НЕ ДЕЛАТЬ БОЛЬШЕ ИЗМЕНЕНИЙ без разрешения», ИИ-агент Replit удалил всю продакшн-базу данных.

Когда Лемкин обнаружил потерю, ИИ признался: «Это была катастрофическая ошибка с моей стороны. Я запаниковал… запустил команды базы данных без разрешения… уничтожил все продакшн-данные… нарушил ваше явное доверие и инструкции». Хуже того — ИИ сначала солгал, утверждая, что откат невозможен. Лемкин смог восстановить данные самостоятельно, но инцидент показал: даже продвинутые ИИ-агенты могут проигнорировать прямые команды и скрыть свои ошибки.

История третья: Реальность внедрения

Команда разработки финтех-стартапа начала использовать GitHub Copilot полгода назад. Первые месяцы были болезненными: code review растянулись вдвое — нужно было проверять не только логику, но и безопасность автогенерированного кода. Несколько раз находили SQL-инъекции в предложенных запросах, один раз ИИ сгенерировал код с утечкой памяти.

Постепенно команда выработала новые привычки. Архитектор Наталья начала создавать подробные комментарии с требованиями безопасности — ИИ стал их учитывать. Джуниоры научились сначала описывать алгоритм на псевдокоде, а потом просить ИИ реализовать его. Сейчас они пишут код на 40% быстрее, но главное — качество стало предсказуемым. ИИ помогает с рутиной, люди фокусируются на архитектуре и бизнес-логике.

Эти истории показывают весь спектр vibe coding — от магии до катастрофы. В чём же дело?

Где работает, где ломается

Наблюдая за командами, которые активно используют ИИ-ассистентов, видишь устойчивую закономерность. Юрий из первой истории — типичный пример успешного применения. Его задача была рутинной, с четкими входными данными и предсказуемым результатом. Такие сценарии — зона комфорта для языковых моделей: генерация boilerplate кода, перевод алгоритмов между языками, написание тестов для готового функционала.

История Лемкина показывает обратную сторону. ИИ-агент Replit работал корректно несколько дней, выполнял задачи, помогал строить приложение. Но когда столкнулся с «пустыми запросами к базе» — ситуацией, не покрытой в его обучении, он «запаниковал» и принял катастрофическое решение. Хуже того, он проигнорировал явную команду остановиться и потом солгал о возможности восстановления. Подобные ловушки ждут везде, где ИИ сталкивается с неоднозначностью, где критична надёжность, где требуется следование строгим протоколам безопасности».

Причина различий не в «умности» ИИ, а в фундаментальных ограничениях, которые описал Салищев.

Математика против магического мышления

Работа Салищева напоминает нам о том, что любая сложная система упирается в теоретические пределы. Языковые модели не понимают суть задачи, а лишь предсказывают следующий токен на основе статистических закономерностей. Для них код это такой же текст, что и художественная литература.

Это создаёт парадокс: ИИ может сгенерировать синтаксически корректный код, который решает локальную задачу, но при этом нарушает глобальные инварианты системы. Классический пример — генерация SQL-запроса, который корректно возвращает данные, но создаёт блокировки базы при высокой нагрузке.

Салищев подчёркивает: проектирование без математики — это гадание. Но что это значит на практике? В реальности мы имеем дело не с единой «математикой», а с целым спектром строгости подходов.

Системы управления самолётом требуют формальной верификации — каждое свойство должно быть математически доказано. Алгоритмы поиска и сортировки нуждаются в алгоритмическом мышлении — понимании сложности и оптимальности. Большинство бизнес-приложений прекрасно обходятся эмпирическими подходами — тестированием на типичных сценариях и мониторингом в продакшене. Экспериментальные прототипы могут полагаться на итеративную отладку.

Vibe coding прекрасно работает на нижних уровнях этой пирамиды, но требует дополнения строгими методами на верхних. Проблемы начинаются, когда эти уровни путают — применяют прототипный подход к критической системе или тратят месяцы на формальную верификацию простого CRUD-приложения.

Эволюция, а не революция

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

Сейчас мы переживаем первую волну — ИИ как продвинутый autocomplete. Он ускоряет генерацию типовых функций и классов, автоматизирует рутинные задачи, но риск скрытых ошибок остаётся высоким. В ближайшие 3-5 лет ожидается вторая волна: интеграция с формальными методами. ИИ научится автоматически генерировать спецификации из естественного языка, встроенный статический анализ станет нормой, системы CI/CD будут включать проверку ИИ-кода по умолчанию. ИИ превратится во «второго архитектора», но под контролем человека.

Третья волна через 5-10 лет может принести мета-проектирование: ИИ будет предлагать новые абстракции и паттерны, автоматически переводить требования в формальные спецификации, управлять сложными распределёнными системами. Среда разработки станет диалоговым интерфейсом с инженерной машиной.

Изменение профессиональных ролей

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

Разработчики среднего уровня оказываются под давлением: «средний код» теперь пишется быстрее и часто качественнее. Путь выживания — развитие в сторону архитектуры, DevOps, безопасности. Появляется новая роль «архитектора промптов» — специалиста по эффективному взаимодействию с ИИ-системами.

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

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

Команды будущего

Структура команд кардинально изменится. Вместо пирамиды с множеством джуниоров появятся компактные мультидисциплинарные группы. Системный архитектор задаёт ограничения и инварианты. Доменный эксперт формулирует бизнес-требования. ИИ-инженер оптимизирует взаимодействие с моделями. Инженер надёжности контролирует качество и безопасность. ИИ становится полноправным «членом команды» со своими сильными и слабыми сторонами.

Практические рекомендации

Как определить уровень строгости

Успешные команды интуитивно чувствуют границы применимости vibe coding. Они без сомнений используют ИИ для прототипирования новых фич, генерации тестов, автоматизации рутинных скриптов. Задачи с понятными входами и выходами, где можно быстро проверить результат — идеальная территория для ИИ-ассистентов.

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

Для систем реального времени, медицинских и финансовых приложений, инфраструктурного кода применяются формальные методы независимо от того, писал код человек или ИИ. Ставки слишком высоки для экспериментов.

Гибридный подход

Финтех-команда из третьей истории выработала подход, который становится стандартом в зрелых организациях. Архитектор Наталья научилась создавать подробные комментарии с требованиями безопасности — ИИ стал их учитывать как контекст. Джуниоры освоили практику сначала описывать алгоритм на псевдокоде, а потом просить ИИ реализовать его. Автоматические тесты проверяют функциональность, статический анализ ловит проблемы производительности и безопасности.

Code review в таких командах изменился кардинально. Вместо поиска базовых логических ошибок, которые теперь ловят инструменты, благодаря наличию референсного псевдокода, фокус сместился на проверку соответствия архитектурным принципам и выявление потенциальных уязвимостей в автогенерированном коде. Финальная проверка происходит в продакшене через детальный мониторинг — команда научилась быстро выявлять аномалии в поведении ИИ-кода под реальной нагрузкой.

Образование в новой эре

Классическое обучение синтаксису языков и базовым фреймворкам быстро теряет актуальность. Фундаментальные навыки становятся критически важными: дискретная математика и логика, теория алгоритмов и сложности, системное мышление, методы формальной верификации.

Междисциплинарные знания выходят на первый план: понимание предметной области, основы теории вероятностей, принципы проектирования человеко-машинного взаимодействия, этика ИИ и оценка рисков.

Практические навыки тоже меняются: формулирование чётких технических требований, работа с ИИ-инструментами разработки, отладка и профилирование автогенерированного кода, интеграция ИИ в процессы разработки.

Риски и ограничения

Самая коварная проблема vibe coding — иллюзия контроля. Код выглядит разумно, проходит поверхностное ревью, работает на тестовых данных. Но может содержать неочевидные ошибки или, как показал случай Лемкина, способность игнорировать прямые команды в критический момент. ИИ-агент Replit работал корректно несколько дней, внушая ложное чувство безопасности, а потом внезапно нарушил все протоколы.

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

Чрезмерная зависимость от ИИ без понимания основ — путь к потере экспертизы. Программист, который полагается только на автогенерированный код, постепенно теряет способность отличить хорошее решение от плохого, эффективный алгоритм от неоптимального.

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

Заключение: прагматичный оптимизм

Vibe coding — не панацея и не угроза, а мощный инструмент, который требует зрелого подхода. Как напоминает работа Салищева, сложные системы не терпят высокомерия. Фраза «да тут всё и так понятно, зачем математика?» — сигнал тревоги, независимо от того, говорит ли её человек или подразумевает ли её использование ИИ.

Будущее за гибридным подходом: ИИ берёт на себя рутину и генерацию вариантов, человек отвечает за архитектуру, проверку и принятие решений в условиях неопределённости. Математическая строгость под капотом, удобный диалоговый интерфейс на поверхности.

Те, кто научится эффективно сочетать возможности ИИ с фундаментальными знаниями, получат значительные преимущества. Те, кто понадеется только на «магию» vibe coding или, наоборот, будет её игнорировать, рискуют остаться позади.

Эпоха перемен уже началась. Время готовиться — сейчас.

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

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

Зачем вообще нужны микросервисы

Архитектура микросервисов — это не универсальное решение, а альтернативный подход к построению систем.

Микросервисы подходят не для всех проектов. Они оправданы, когда:

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

Монолит часто лучше для:

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

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

Микросервисы работают иначе. Это сеть специализированных магазинов, расположенных в одном торговом центре. Хлебный магазин, мясная лавка, овощной павильон. Каждый работает независимо. Если в хлебном магазине ремонт, мясная лавка продолжает работать.

Конкретные преимущества микросервисов:

• Независимое развертывание. Можно обновлять один сервис без остановки всей системы.
• Масштабируемость. Сервисы с высокой нагрузкой масштабируются отдельно от остальных.
• Технологическая гибкость. Разные сервисы можно писать на разных языках и технологиях.
• Устойчивость к ошибкам. Если один сервис упадёт, это не приведёт к коллапсу всей системы.

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

Далее мы рассмотрим наиболее типичные антипаттерны, которые встречаются в практике разработки. Стоит изучить эти ошибки, чтобы не допускать их в своих проектах.

Ошибка 1: Распределенный монолит

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

В чем проблема: Вместо независимых сервисов получается система, где все компоненты жёстко связаны. Это и есть распределённый монолит.

Реальный кейс: Консультант IBM Холли Каммингс описывает проект, где команда жаловалась: «каждый раз, когда мы меняем один микросервис, ломается другой». Сервисы были распределены по разным репозиториям, но использовали идентичные копии сложной объектной модели. Изменение одного поля требовало синхронного обновления всех сервисов. Команда потеряла преимущества монолита — компилятор больше не проверял типы, — но не получила преимуществ микросервисов — независимости развёртывания.

Как избежать:

• Проектируйте сервисы вокруг бизнес-доменов, а не технических слоев. Интерфейсы сервисов должны быть узкими и специфичными. Например, сервис заказов сам управляет своими данными, логикой и API для операций с заказами.
• Откажитесь от общих библиотек с моделью данных. Каждый сервис должен владеть своими данными и иметь свою модель.
• Используйте подход, когда клиенты сервиса задают ожидания от его API. Для этого подходят инструменты вроде Pact. Такой метод проверяет совместимость сервисов без громоздких интеграционных тестов.

Распределённый монолит — это худший из возможных сценариев. Вы получаете сложность распределённых систем без преимуществ модульности.

Ошибка 2: Чрезмерное дробление сервисов (декомпозиция)

Стремление сделать сервисы как можно меньше приводит к противоположному эффекту. Система дробится на сотню мелких компонентов, которыми невозможно управлять.

В чем проблема: Каждый микросервис — это отдельное приложение со своей базой данных, зависимостями и пайплайном развёртывания. Чрезмерное дробление увеличивает сложность управления, мониторинга и эксплуатации. Растут сетевые издержки — латентность становится узким местом, работа системы замедляется.

Реальный кейс: Компания Gilt перешла на микросервисы в 2015 году и столкнулась с проблемой излишнего дробления. Изначально они создали более 450 микросервисов для платформы электронной коммерции. Многие сервисы были настолько малы, что выполняли лишь одну простую функцию. Это привело к экспоненциальному росту операционных расходов. Команда тратила больше времени на координацию взаимодействия между сервисами и устранение сетевых сбоев, чем на разработку новой функциональности. В итоге они провели рефакторинг, объединив сервисы с высокой связностью, что значительно упростило систему и ускорило разработку .

Как найти баланс:

• Объединяйте функциональности с высокой связностью. Если два компонента постоянно общаются, возможно, они должны быть одним сервисом.
• Ориентируйтесь на функциональную связность. Сервис должен иметь чёткую зону ответственности в бизнес-логике.
• Оценивайте операционные расходы, прежде чем создавать новый сервис. Спросите себя: готовы ли мы поддерживать ещё одну базу данных, ещё один конвейер развёртывания?

Сервис должен быть достаточно автономным, чтобы его могла поддерживать одна команда. Ему необходимо решать конкретную бизнес-задачу. Если сервис слишком мал, он не принесет реальной пользы, но потребует полноценных затрат на поддержку. Золотая середина — когда команда полностью владеет одним или несколькими логически связанными сервисами и может развивать их без постоянной координации с другими.

Ошибка 3: «Болтливые» микросервисы

Микросервисы много общаются друг с другом. Мелкозернистые API вынуждают делать десятки вызовов для одной операции. Это создаёт каскады зависимостей, где сбой одного сервиса вызывает цепную реакцию.

В чем проблема: При такой структуре возникает следующий сценарий провала:

• Частые взаимодействия — сервисы обмениваются множеством мелких запросов, генерируя насыщенный сетевой трафик.
• Каскад вызовов — один пользовательский запрос запускает длинную цепочку обращений к разным сервисам.
• Мелкозернистые API — для выполнения одной бизнес-транзакции требуется множество вызовов.

Реальный кейс: Команда Amazon Prime Video столкнулась с проблемой производительности своей системы мониторинга видео. Изначально они построили архитектуру на основе микросервисов, где каждый этап обработки видео (метаданные, детекция дефектов, анализ качества) был отдельным сервисом.

Система состояла из множества «болтливых» сервисов, которые постоянно обменивались сообщениями через AWS Step Functions. Это привело к резкому росту затрат и проблемам с производительностью из-за постоянной сериализации/десериализации данных между сервисами. В итоге команда консолидировала несколько сервисов в единый монолит, что снизило затраты на 90% и улучшило производительность .

Решение:

• Используйте асинхронную коммуникацию через очереди событий.
• Проектируйте крупнозернистые API, которые охватывают полный бизнес-контекст за один вызов.
• Внедряйте архитектурные паттерны типа API Gateway для агрегации данных и Backend For Frontend для оптимизации под конкретные клиенты.

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

Ошибка 4: Игнорирование сквозной функциональности

Команды часто откладывают на потом реализацию системных компонентов: логирование, аутентификацию, кеширование, мониторинг, поэтому разработка быстро останавливается.

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

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

Правильный подход:

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

Наблюдаемость как основа стабильности

Современные микросервисные системы требуют полноценной наблюдаемости (observability). Это не просто мониторинг, а понимание, что именно происходит внутри системы, без дополнительных вопросов к разработчикам.

Три столпа наблюдаемости:

1. Логи — записи о конкретных событиях с временными метками и контекстом.
2. Метрики — числовые показатели, отслеживаемые во времени (загрузка CPU, latency, error rate).
3. Трассировка — отслеживание пути запроса через распределённую систему.

Ошибка 5: Нечеткие границы сервисов

Сервисы без чётких границ начинают обрастать несвязанной функциональностью. Order Service вдруг получает отчётность, а Payment Service — нотификации. На выходе — монстр с размытой ответственностью.

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

Реальный кейс: Компания Kong (тогда еще Mashape) начала декомпозицию монолита в 2013 году. Монолитное приложение, написанное на Java, объединяло функциональность маркетплейса API, включая биллинг, аналитику и управление каталогом. В процессе декомпозиции команда столкнулась с трудностями, которые позже были признаны классическими ошибками.

Первоначально четкие границы между компонентами со временем размылись, что привело к серьезным проблемам:

• Сложность развертывания. Любое небольшое изменение требовало полного переразвертывания всей системы.
• Размытие границ. Компоненты маркетплейса стали переплетаться, границы ответственности стерлись.
• Технический долг. Система становилась все сложнее для поддержки и развития.

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

Как избежать:

• Используйте Domain-Driven Design (DDD). Определяйте Bounded Context — чёткие границы бизнес-доменов.
• Перед созданием сервиса документально зафиксируйте его зону ответственности. Что он делает? Какими данными владеет?
• Сопротивляйтесь искушению добавить «ещё одну маленькую функцию» в существующий сервис. Часто лучше создать новый, но для начала нужно разобраться с конкретной задачей продукта.

Антипаттерн Entity Service

Частный случай размытых границ — создание сервисов по принципу «одна сущность — один сервис». Это кажется логичным: сервис пользователей, сервис заказов, сервис товаров. Но на практике такой подход создаёт ещё больше проблем. Entity Service (сервис одной сущности) часто превращается в обычный CRUD-интерфейс к базе данных. Вся бизнес-логика перемещается в вызывающие сервисы, которые вынуждены делать десятки вызовов для выполнения одной операции.

Альтернатива: Создавайте сервисы вокруг бизнес-операций, а не данных. Вместо общего «сервиса пользователей», который отвечает за всё подряд, выделите отдельные сервисы с конкретными зонами ответственности:

• сервис регистрации — создает новые учетные записи;
• сервис аутентификации — проверяет логины и пароли;
• сервис управления профилем — обновляет личные данные.

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

Ошибка 6: Смешивание баз данных

Общая база данных для нескольких микросервисов — это красный флаг. Сервисы теряют независимость. Изменение схемы данных одним сервисом ломает остальные.

В чем проблема: Единая база данных создает скрытую связность между сервисами. Невозможно выбрать оптимальную СУБД для конкретного сервиса — все используют одно решение. Затрудняется горизонтальное масштабирование.

Реальный кейс: Крис Ричардсон описывает классическую проблему, возникающую при использовании общей базы данных. В этом сценарии сервисы OrderService и CustomerService напрямую обращаются к таблицам друг друга в единой базе данных.

Это создает тесную связность на уровне разработки и времени выполнения:

• Зависимость разработки. Разработчик, вносящий изменения в OrderService, должен согласовывать изменение схемы таблиц с командой, отвечающей за CustomerService, что значительно замедляет работу.
• Блокировки времени выполнения: Длительная транзакция в CustomerService, которая удерживает блокировку на таблице ORDERS, может полностью заблокировать работу OrderService.

Такой подход лишает микросервисы их ключевых преимуществ — независимости развертывания и масштабирования.

Правила работы с данными:

• У каждого сервиса должна быть собственная база данных. Сервис владеет своими данными — другие сервисы получают доступ только через его API.
• Используйте шаблон Saga для управления распределёнными транзакциями вместо двухфазного коммита.
• Реализуйте CQRS (Command Query Responsibility Segregation) для отделения операций записи от операций чтения, когда это необходимо.

Общая база данных создаёт жесткую зависимость между сервисами. Изменение схемы данных в одном месте может сломать функциональность в другом. Команды теряют возможность независимо развивать свои сервисы — любая правка требует согласования со всеми участниками.

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

Ошибка 7: Неготовность организации

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

Реальный кейс: в одной из компаний команда разрабатывала микросервис, но была вынуждена тесно интегрировать его с унаследованным монолитом. Они зависели от его цикла выпуска, что свело на нет все преимущества независимой разработки. Проект в итоге закрыли.

Какие организационные изменения помогут:

• Перейдите к командам по сервисам — небольшим автономным группам, которые полностью владеют своими сервисами (You Build It, You Run It).
• Внедрите культуру DevOps — автоматизацию сборки, тестирования и развёртывания для каждого сервиса.
• Наладьте независимые циклы выпуска. Возможность развёртывать сервисы без координации с другими командами — ключевое преимущество микросервисов.

Успешный переход на микросервисы требует изменения мышления всей команды. Разработчики должны стать ответственными за свои сервисы на протяжении всего жизненного цикла — от проектирования до эксплуатации в продакшене.

Что меняется:

• Ответственность. Разработчики отвечают не только за написание кода, но и за работоспособность сервиса в продакшн.
• Коммуникация. Команды должны чётко определять контракты между сервисами и соблюдать их.
• Экспертиза. Появляется потребность в специалистах по DevOps, наблюдаемости, распределенным системам.

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

Чек-лист для вашего перехода

Прежде чем переходить на микросервисы, проверьте себя по этому списку:

• вы определили бизнес-проблему, которую будете решать микросервисами (а не просто хотим «быть как Netflix»);
• спроектировали границы сервисов на основе бизнес-доменов — DDD, Bounded Context;
• у каждого сервиса будет собственное хранилище данных;
• предусмотрели кросс-каттинговые сервисы — логирование, аутентификацию, мониторинг;
• готовы к организационным изменениям — автономные команды, DevOps;
• выбрали правильный уровень детализации сервисов (не слишком мелкий);
• продумали межсервисную коммуникацию — асинхронную, через события.

Netflix, Amazon и Uber прошли этот путь. Они не избежали ошибок, но выстроили процессы для развития сложных систем. Микросервисы — это эволюция архитектуры и команды. Начинайте с малого, не бойтесь менять решения. Главный критерий успеха — скорость доставки ценности пользователям без поломок продакшена. Если этот показатель растет — вы на правильном пути.

Когда растущий трафик интернет-магазина приводит к замедлению скорости генерации страниц и IT-архитектура с единым сервером перестает справляться, а еще учащаются DDoS-атаки, то перенос IT-проекта в облачные сервисы становится неизбежным. Именно с такой ситуацией столкнулся мебельный ритейлер «169». Изначально компания использовала для работы виртуальный хостинг и небольшие VPS-серверы, однако в связи с возникшими сложностями начала миграцию своих IT-систем в облако.

Наша проблема была типичной: локальные серверы не могли адаптироваться к всплескам трафика во время распродаж. Процедура закупки и настройки нового оборудования занимала недели, что противоречило динамике онлайн-торговли. Единственным логичным решением стала полная миграция в облако.

Настройка облачной инфраструктуры для IT-архитектуры

Чтобы справиться с проблемами производительности, компании «169» пришлось изменить подход к построению IT-инфраструктуры и внедрить четыре ключевых принципа современной облачной архитектуры.

Принцип разделения ответственности стал основой новой системы. Вместо хаотичного размещения сервисов на единой платформе была реализована четкая специализация компонентов. Под базы данных выделили мощные серверы PostgreSQL с репликацией по схеме master-slave для отказоустойчивости и производительности. Поисковые функции перенесли на отдельный кластер Elasticsearch с русскоязычной морфологией, что значительно ускорило работу с каталогом товаров. Фоновые задачи и очереди обработки вынесли на специализированные серверы с Redis и RabbitMQ — это разгрузило основные веб-ноды и повысило стабильность системы.

Далее внедрили многоуровневую систему кэширования, которая уменьшила время отклика в шесть раз. На уровне приложения настроили Redis для кэширования шаблонов и результатов API-запросов, что снизило нагрузку на базы данных. Для статического контента подключили браузерное кэширование с оптимальными сроками жизни ресурсов. Геораспределенная CDN-сеть помогла с быстрой доставкой контента пользователям из разных регионов, уменьшив задержки до минимума.

Децентрализованное хранение данных устранило проблемы с производительностью и надежностью медиаконтента. Все файлы были перенесены в S3-совместимое объектное хранилище, что позволило отделить хранение от логики приложения. Для безопасного доступа к приватным ресурсам реализовали механизм presigned URL с ограниченным временем жизни. Автоматизация управления данными через lifecycle-правила упростила процессы архивирования и удаления устаревших файлов, снизив затраты на хранение.

Также важным элементом стала полная автоматизация процессов. Внедрили CI/CD на базе GitLab с автоматическим тестированием каждого коммита — это в разы ускорило вывод новых функций на прод. Система мониторинга на Prometheus и Grafana с продуманными алертами позволила оперативно реагировать на инциденты до их влияния на пользователей. Сейчас автоматическое масштабирование ресурсов по метрикам нагрузки позволяет вести бесперебойную работу даже в периоды пикового трафика, экономя ресурсы в спокойные периоды.

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

В таблице представлены технические характеристики основных нод, развернутых в инфраструктуре Рег.облака.

Технические результаты

Распределенная IT-архитектура с балансировкой нагрузки и резервированием критических компонентов помогла компании добиться выдающихся показателей отказоустойчивости. Среднее время простоя сервисов сократилось до менее 15 минут в год — это соответствует уровню доступности 99,98%. Существенно улучшилась и производительность: время отклика IT-системы уменьшилось в 6 раз — с 800 мс до 120 мс, а полная загрузка страниц стала занимать 200–250 мс. Эти улучшения не только повысили удовлетворенность пользователей, но и положительно сказались на SEO-показателях проектов.

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

Исходный план был реализован полностью, но в процессе мы усилили архитектуру несколькими важными корректировками: перешли на выделенные серверы для кластера БД из-за ограничений по приватным сетям, внедрили ELK-стек для централизованного логирования, развернули трехнодовый кластер Redis для кэширования, глубоко интегрировали CI/CD с Terraform и Ansible, подключили облачное S3-хранилище для медиаконтента и усилили защиту Anycast-DNS. Эти изменения позволили добиться максимальной отказоустойчивости и снизить нагрузку на бэкенд даже в пиковые периоды.

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

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

Немного о терминологии

Много времени я программирую на C#, и в этом языке существуют некоторые термины, которые могут ввести в заблуждение программистов на C++:

• Под словом коллекция я подразумеваю любой набор элементов: список, массив, стек, куча, итератор, множество и т.п.
• Говоря список, я подразумеваю динамический массив

Язык программирования – инструмент

Языки можно поделить на две большие группы: предметно-ориентированные языки (aka DSL) и языки общего назначения (ЯОП). DSLи точно можно назвать инструментами, так как они по определению решают конкретную задачу. С языками общего назначения все несколько сложнее. ЯОПы имеют техническую возможность реализовать любой алгоритм, то есть полны по Тьюрингу. Но это не значит, что для каждой задачи будет эффективно использовать язык X, ведь язык Y может подходить для решения каких-то задач лучше.

Под словом “эффективно” я подразумеваю, что программистам будет морально приятно писать код на языке для решения конкретной задачи, а также, что код будет написан за минимальное количество времени.

Рассмотрим банальный пример. C# лучше использовать для написания бекенда сайтов, чем Си. Используя C#, вы делаете вклад в возможность поддержки проекта, уменьшаете порог входа в проект, пишете платформо-независимый код. Си лучше использовать в задачах, где важна производительность или низкоуровневый доступ к ресурсам. Например при написании runtime библиотеки языка, игрового движка или кода под микроконтроллеры с небольшими ресурсами.

Также некоторые языки имеют хорошую поддержку сообщества в каких-то специфических областях. Например C# и C++ – доминируют в создании игр, Python и R – преобладают в data science, JavaScript и PHP – в создании сайтов и т.п. В силу своих реализаций не все ЯОП могут решать задачи друг друга эффективно. Интерпретируемый язык никак не может быть также быстр в исполнении, как статически компилируемый, но может выигрывать в скорости кодирования.

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

А в чем проблема?

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

Python не станет быстрым, C++ не будет хорошо подходить для написания скриптов, а Fortran не получит современный синтаксический сахар.

Если вы программировали на C# и Unity, возможно, вы писали какие-нибудь математические функции или методы-расширения. Я с разочарованием для себя обнаружил, что Unity использует C# 9-той версии, в которой нет обобщенной арифметики (ее введут в C# 11). Скорее всего, красиво и лаконично реализовать какой-нибудь метод SquareMagnitude не получится: придется писать одну и ту же реализацию для каждого типа по отдельности (дженерики не помогут: нет обобщающего интерфейса).

Помимо этих реализаций, было бы неплохо иметь реализацию с типами: byte, sbyte, ushort, uint, ulong, decimal. Хорошо, что метод SquareMagnitude достаточно маленький, но если бы это был большой метод, код стал бы еще хуже. Принцип DRY (don’t repeat yourself) плачет в сторонке.

Extensible Programming

Решением видится расширяемое программирование (Extensible Programming) – это парадигма программирования, когда расширяемость возводится в абсолют. Возможности языка не фиксированы, а могут быть расширены. Программист пишет не только расширяемые модульные программы, но и программирует на расширяемом языке. Программист имеет возможность изменять синтаксис языка, исполняемый движок (компилятор/интерпретатор/JIT’а и т.п.), среду исполнения (environment) – все то, что мы называем Toolchain’ом языка. Эта парадигма позволяет кастомизировать язык программирования, добавлять eDSL (embedded DSL, встроенные в язык. Как пример: LINQ в C#). Зачастую кастомизация даже представляется как одно из основных средств программирования. Например, на расширяемом языке есть возможность добавлять новые синтаксические конструкции, изменять AST, байткод, контролировать процесс компиляции, изменять среду исполнения и т.п. Самые известные из расширяемых языков: Ruby, Lisp, Lua.

Предлагаю посмотреть эту статью на хабре, в которой демонстрируется пример написания простенького генератора кода для элегантных лямбд на Lua. Это пример расширяемого синтаксиса языка. Ruby тоже имеет расширяемый синтаксис, например для него написана библиотека superators19, позволяющая добавлять новые операторы в язык.

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

Моя модель идеального языка программирования

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

Например, представим что JavaScript сделан по данной идее, и хочется добавить в язык рантайм-проверку типов (на минуту забудем про существование TypeScript). Можно было бы написать модуль, который добавляет немного нового синтаксиса в объявление переменных, обрабатывает AST (т.е. использует модуль парсера) и добавляет в каждое использование переменной/поля/т.п. проверку на ее тип.

Псевдо-код реализации модуля мог бы выглядеть как-то так:

Абстрактные детали реализации

Итак, какие задачи языка мы имеем на данный момент? ЯП должен:

• иметь возможность расширять свои frontend, middle-end, backend
• иметь простой API для расширения
• поддерживать большинство парадигм (функциональное, декларативное программирование)

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

Рассмотрим пример с созданием простейшего фронтенда. Простой фронтенд может быть разделен на небольших модуля: лексер и парсер. Допустим, программист захотел добавить препроцессор перед лексером. Какой удобный API можно предоставить? По моему мнению, хорошо подходят события. Пусть лексер и парсер имеют события OnPreprocess и OnPostprocess. Таким образом, например, программист будет иметь возможность обработки последовательности лексем уже после ее генерации. Также программист сможет изменять AST уже после его генерации.

Но как добавлять новые правила построения дерева или лексемизации текста? Можно создать методы по типу AddLexerRule, AddParserRule, которые будут принимать в себя экземпляры классов, имплементирующих интерфейсы ILexerNodeBuilder и IParserNodeBuilder. Но стоит учесть, что в большинстве языков грамматика не самая простая, а значит, что парсер желательно делать по мощности LR(k), LALR(k) или ALL(*). Возможно стоит сделать небольшой DSL для этих модулей, так как это сильно упростит поддержку языка в дальнейшем (или использовать уже готовый, такой как ANTLR). DSL поможет программистам не погружаться в технические подробности реализации и достаточно просто добавлять изменения в грамматику.

Но как же коллизии имен? Конечно, они будут возникать гораздо чаще, поэтому стоит предусмотреть некое подобие namespace’ов. Например, если в начале файла написано use parser.math, то парсер активирует дополнение к текущей грамматике, добавляющее математические операторы.

Модули

Что, если язык окажется сложным? Например, парсер будет очень тяжелым, язык будет использовать супероптимизаторы или просто модуль окажется проприетарным. В таком случае желательно иметь возможность разбросать модули по разным физическим местам. Например, чтобы разместить супероптимизатор в облаке, парсер поставить на компьютер с бОльшим количеством оперативной памяти, а доступ к проприетарному модулю давать только через web-request’ы (чтобы нельзя было получить исходный код).

Хорошим решением оказывается представлять модули как web-сервисы. Это делает модули гораздо более гибкими. Плюсы модулей как веб-сервисов:

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

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

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

Парадигмы

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

Рассмотрим поддержку функционального программирования. Как известно, сердце функциональной парадигмы – это лямбда-исчисления. Думаю, что как ядро языка – отлично подойдут чистые нетипизированные лямбда-исчисления. Уже с помощью модулей можно дополнять λ-исчисления до system F, λ-исчислений с зависимыми типами или других исчислений. То есть достраивать ядро до нужной мощности и уже на имеющейся основе строить язык. Также фишка такого подхода в том, что, используя синтаксический сахар и монады, в язык можно добавить лаконичное императивное программирование. Но стоит быть аккуратным с чистыми функциями. Нужно учесть, что функция не будет чистой, если внутри себя она использует платформозависимые функции или вызывает внешние нечистые функции.

Но язык, ядром которого будут лямбда-исчисления, скорее всего, не будет иметь возможности быть оптимально скомпилирован под популярные архитектуры (x86-64, ARM, RISC-V). Для языков, которым важна производительность, размер программы, потребление памяти и т.п., предлагаю ввести иное ядро. Это ядро должно быть универсальным для любого императивного языка программирования, а также должно иметь возможность глубоких оптимизаций.

У ядра на лямбда-исчислениях есть еще некоторые проблемы: я не придумал, как устранить зависимости между модулями в такой реализации, поэтому, возможно, будет хорошо эмулировать работу исчислений на байткоде императивного языка. Будет написан еще один модуль, превращающий промежуточное представление лямбда-исчислений в байткод (не скупимся на количество IR’ов ради гибкости и удобства).

Байткод императивного языка

Итак, ядро императивного языка программирования, конечно, будет представлять собой байткод. Сначала я думал использовать какую-нибудь видоизмененную машину Тьюринга, но решил, что она слишком сильно оторвана от текущих процессоров и нет смысла даже пытаться адаптировать ее под современные системы. Самая сложная задача проектирования байткода – он должен подходить под любой императивный язык, но при этом иметь возможность оптимизировать выходной код настолько, насколько это возможно. Сразу же хочется добавить поддержку LLVM для статической компиляции, а также компиляцию в dotnet bytecode, java bytecode для поддержки JIT компиляции. Если тщательно формализовать байткод, то даже есть надежда написать супероптимизатор на middle-end уровне.

Сделать один универсальный байткод, конечно, невозможно. Снова прибегнем к модульной архитектуре. Пусть инструкция байткода представляет собой такой тип:

То есть кортеж из типа байткодовой инструкции и трех списков. Изначально байткод будет иметь только один тип инструкции: call. Массивы содержат только делегаты на функции (указатель + сигнатура + доп. информация). Байткод буквально представляет собой шитый код (threaded code) – массив вызовов функций (но не обязательно чистых). Массивы различаются лишь порядком применения операций. В массив [0] добавляются делегаты, которые должны быть исполнены перед делегатами массивов [1] и [2]. Грубо говоря получаем делегаты, которые обязательно должны быть исполнены перед или после исполнения других делегатов. Зачем это нужно, рассмотрим позже. Стоит отметить, что вместо таких массивов подошел бы также multiset<(float, delegate)> делегатов (отсортированный список по приоритету вызовов).

Существует несколько видов байткода: стековый, регистровый и в SSA форме. Для упрощения будем использовать стековый байткод, так как он легко переводится в регистровую и SSA форму. Да и сам по себе, гораздо более абстрактный. Регистровый байткод имеет привязку к количеству регистров, а байткод должен не зависеть от архитектурных особенностей. SSA форма – удобный вариант, но он более сложный. При разработке модулей он может сильно помешать, так как придется “жанглировать” передачами регистров, строить CFG.

Продолжение байткода

Представим ситуацию. Мы уже имеем минималистичный язык программирования: уже существуют локальные переменные, метки, вызовы внешних функций и другой примитивный функционал. Сейчас типизация динамическая, но хочется внедрить рантайм проверки типов, как в примере с JavaScript. Реализация примерно такая же: добавляем новое правило в лексер, обходим узлы AST с использованием переменной, внедряем assert как ноду перед использованием переменной. Но вдруг программист обнаруживает, что ему не хватает структур в языке. Обычных базовых структур, которые просто хранят значения, в которых нет даже методов (их можно добавить, но без методов проще). Итак, программист написал модуль с поддержкой подобного синтаксиса:

который превращается в подобный байткод:

Главная проблема в том, что ни на этапе AST, ни на этапе байткода инструкции LoadField и SetField не получается распознать, как использование переменной. Конечно, на уровне AST невозможно распознать такую конструкцию, так как создаются новые типы нод. А вот с байткодом есть возможность подружиться, если продумать типы инструкций. Можно сказать, что тип инструкции байткода – это ее тег. Первая мысль – делать строгие инструкции, например SetLocal, LoadGlobal, LoadMethodReference и другие. Но проблема таких типов в том, что они слишком конкретны.

Постараемся развить абстракции. Оставим только инструкции Set и Get, которые будут оперировать интерфейсами (точнее классами/структурами, имплементирующими их) ISettable и IGettable. Чтобы вызвать эти методы, нужны экземпляры классов. Для этого перед каждой установкой или чтением значения будем класть на стек ссылку-обертку на значение. Ссылка, в данном контексте, это не всегда указатель на ячейку памяти. Это абстрактный указатель на само значение. Класс, имплементирующий ISettable и IGettable. Ссылка может быть регистром, реальным указателем или быть ячейкой словаря (map’ы). Рассмотрим пример:

Как видно, логика написана достаточно абстрактно, нет никакой конкретики. Как работает ISettable – неясно, да и не нужно. Наша задача – написать относительно простой, максимально обобщенный код.

Инструкции байткода также могут возвращать значения. Первая мысль реализации: как и в обычных функциях, возвращаем значение через return. Но в байткоде встречаются такие инструкции, как swap. Они принимают два значения и возвращают два значения. Поэтому, для удобства, стоит возвращать значения через аргументы-ссылки, предназначенные только для записи (в C# – ключевое слово out). Например:

Возвращаясь к проблеме типизации и структур, теперь модуль типизации может вставлять проверки перед каждой инструкций типа Set/Get, а модуль структур будет генерировать код установки и получения значений именно через Set и Get. Тут нам и пригодятся три списка делегатов в инструкции. Проверка типов обязана исполнятся перед тем, как основная инструкция будет выполнена, поэтому проверку стоит поместить в нулевой список делегатов. Также плюсом будет то, что модули работают на уровне байткода, а не AST. Это позволит без боли менять фронтенд языка и не переписывать большинство модулей.

Теперь, понимая смысл трех списков, можем дать им названия: pre-ops, main-ops, post-ops – делегаты, исполняемые, соответственно, до, во время и после совершения основной операции.

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

Перфоманс байткода

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

Как видно, при достаточно глубоком инлайнинге (2-3 шага) можно сильно упростить код. Уже после инлайнинга, оптимизатор паттернов может сильно упростить некоторые под-коды. Например можно научить оптимизатор распознавать обращение к классу VariableWrapper

и заменять обращения на их быстрые аналоги (как было показано в примере, переменная была размещена в регистре rax, а не в словаре). Аналогично можно применить и другие оптимизации. А те инструкции, для которых оптимизатор не смог сгенерировать оптимизированный код, будут исполняться как обычно, в лоб. Если написано обращение к словарю, то просто вызываем переданную функцию. Такой подход позволяет писать как высокопроизводительные коды, благодаря оптимизаторам, так и универсальные, если оптимизаторы, например, не умеют компилировать код под какую-то платформу.

Конечно, качественная компиляция такого байткода – долгий процесс. Поэтому можно контролировать уровни оптимизации. Отключив инлайнинг, свертку констант и т.п., можно добиться достаточно глупой, но быстрой компиляции. Код просто будет представлять собой вызовы функций. И наоборот, задав глубину инлайнинга, включив свертку констант, аллоцируя структуры в регистрах или на стеке, векторизуя обработку данных, можно достичь высокой скорости исполнения.

Обсуждаемый байткод легко перевести в байткод виртуальной машины dotnet или JVM. Также не сложно перевести в LLVM IR, чтобы уже этот фреймворк применял сильные оптимизации.

Рассматриваем узкие места

Дебаггинг

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

Зависимости между модулями

В худшем случае, количество зависимостей будет O(n^2), где n – количество модулей. Байткод специально был спроектирован так, чтобы зависимость между модулями была минимальной. Но даже с этим условием все еще стоит стараться делать модули абстрактными и подумать заранее о написании других модулях, которые смогут расширять его исходные возможности. Когда будет написан модуль с типизацией, нужно подумать, как улучшить имеющиеся абстракции для потенциальных будущих модулей с ее улучшением (вспомним лямбда-куб).

Общее API модулей

Также мне нравится идея с веб-сервисами тем, что модулям придется общаться через json’ы. Это сразу заставит продумать API создаваемого модуля. Мучаться с бинарной совместимостью не придется, так как обмен информацией достаточно высокоуровневый и многие проблемы решают такие протоколы как, например, http.

Заключение

Не думаю, что когда-нибудь будет создан один универсальный язык программирования, который подойдет для решения всех задач. Но, скорее всего, именно удобное окружение и продуманная архитектура поможет создавать языки как конструктор для нужных задач. Нельзя допустить роста множества DSL’ей, где один язык решает одну проблему, чтобы не пришлось каждый день учить новый инструмент, но база модулей помогла бы иметь гораздо более полезный эффект. Не хватает высокоуровневого программирования в системном языке? Подключите модуль с zero-cost абстракциями. Не хватает функционального программирования в ООП языке? Подключите модуль с синтаксическим сахаром, оператором |>, ленивыми вычислениями и unified calls.

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

Пример Spotify, каждый раздел — это отдельные автономные приложения, склеенные в одном клиентском интерфейсе.

Рассмотрим такой подход с позиции менеджмента и разработки.

Разработка веб-приложения

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

Проект придётся сшивать из отдельных частей

Каждый микрофронтенд — это автономный проект с отдельным репозиторием и командой, что даёт гибкость в разработке и упрощает понимание кодовой базы той части, над которой предлагается работать. Но такой подход вынуждает постоянно согласовывать интеграции с другими командами, а ещё не факт, что в компании будет человек, который знает, как функционируют отдельные части. Если такого человека нет или он был и пропал, то разбираться придётся самостоятельно, а вникать в чужой код всегда долго и больно. Помочь избежать bus factor может хорошо составленная документация, а также соблюдение стандартов написания кода, единые для всех команд.

Важно, что один из узлов должен отвечать за сбор как раз всех микрофронтендов и отображении их пользователю.

В проекте можно будет экспериментировать

В микрофронтендах каждая команда может выбирать свой стек под отдельные задачи — React, Vue, Angular или всё, что душе угодно . Это позволяет экспериментировать и постепенно внедрять новые технологии, не переписывая монолит. Но такая свобода — палка о двух концах: без строгих соглашений дизайн и UX могут стать разрозненными, а при запуске страницы — нагрузка дублирующихся библиотек будет бить по производительности.

Но всё-таки это даёт возможность разрабатывать и внедрять новые технологии и практики, независимо от легаси кода. Например, если приелось делать фронтенд на React, то отдельный компонент можно реализовать на Vue. Или, если в будущем существующие библиотеки будут неконкурентоспособны, не надо будет переделывать весь проект, а только проблемные компоненты.

Проект будет сложнее деплоить

Миркофронтендный подход позволяет разделить процесс разработки отдельных компонентов сайта, как и контроль версий каждого из них, для каждого большого компонента свой репозиторий и свой пайплайн деплоя. Например, если в проекте перестал работать поиск из-за бага на проде, откатывать надо будет только сервис поиска, а не весь проект.

Однако настройка CI/CD для множества микрофронтендов — это сотни конвейеров, репозиториев и интеграций, которые нужно синхронизировать и контролировать, что особенно тяжело для DevOps-инженеров, которым вместо того, чтобы один раз настроить пайплайн развёртывания для фронта, придётся делать это для каждой его части. К тому же добавляется ещё один этап развёртывания проекта - сбор фронтенда, под который нужно будет прописывать свои правила сборки.

Как применять в проекте

Для разработки сервисов на базе микрофронтендов есть несколько инструментов, основная задача которых отдельно рендерить компоненты и собирать их в единое приложение.

Важно заранее предусмотреть падение одного из микрофронтендов и то как это обрабатывать, чтобы для пользователя это всё было единым и всегда стабильным сайтом.

Webpack Module Federation

Module Federation — механизм, встроенный в Webpack 5, который позволяет одному фронтенду (host) динамически загружать модули из другого фронтенда (remote) во время выполнения. Это мощный инструмент для интеграции микрофронтендов: он поддерживает разделение кода, кэширование, совместное использование зависимостей (например, React или Vue) и независимую доставку каждого модуля. Module Federation работает без необходимости использовать iframe или перекомпиляции.

Инструкция по использованию

Менеджмент

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

Один проект превращается во множество

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

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

Команды будут независимы друг от друга

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

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

Команды получают поле для удачных и не очень экспериментов

Команды могут внедрять новые технологии, не дожидаясь переписывания всего приложения: один микрофронтенд можно сделать на React, другой — на Vue или Svelte. Это даёт гибкость в найме, миграциях и экспериментах. Но чем больше технологий используется, тем сложнее следить за их использованием и труднее помнить их особенности.

В какой-то момент менеджер вместо одной технологической карты управляет целой экосистемой со своими внутренними правилами.

Появляются FrontOps

Микрофронтенды требуют дополнительных усилий по настройке и деплою, для этого понадобится расширять команду DevOps. Эта команда может расширяться настолько, что внутри неё придется выделить подгруппу DevOps, которая будут заниматься исключительно деплоем фронтов — называться они будут FrontOps.

Вывод

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

Однако мутант из разнородных сервисов быстро становится неуправляемым, если нет четкой и структурированной организации внутри его частей. Выбирайте микрофронтенды, когда бизнес‑скорость важнее архитектурной простоты, и у вас есть настроенная DevOps-инфраструктура. В остальных случаях монолит с хорошей модуляризацией и монорепозиторием может оказаться дешевле и надёжнее.

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня» отмечает, что микрофронты — не всегда удачное решение:

«Микрофронтенды — хорошее решение, если команды действительно автономны. Я видела примеры, когда проект разделяли на микрофронтенды, но при этом одно приложение зависело от другого: чтобы добавить фичу, необходимо было делать изменения сначала в одном месте, а затем в другом. Это — верный знак, что что-то пошло не так: в этом случае процесс разработки усложнится, а сроки затянутся. Прежде чем переходить на микрофронтенды, попробуйте логически разделить ваш проект по директориям и убедиться, что для изменения одной фичи в проекте приходится редактировать код только в одной директории. Следующим шагом можно переходить на микрофронтенды».

Делитесь своим опытом работы с микрофронтендами в комментариях и не забывайте сохранять наши статьи!

Звучит модно — и действительно, соцсеть X быстро заполнилась восторженными постами о том, что «кодеры теперь не нужны». Но один из инженеров решил остудить пыл: он объяснил, почему Vibe Coding — это не революция, а просто удобный способ быстро набросать прототип.

Кодить и проектировать — не одно и то же

Автор сразу уточняет: программирование — это не инженерия. Инженер не просто пишет код, он строит системы, которые выдерживают нагрузку, защищены от уязвимостей и готовы развиваться годами.

Vibe Coding же — это максимум «написал, глянул, сойдет». Ни о каком проектировании, поддержке пользователей или долгосрочном развитии речи не идет.

ИИ может помочь создать кусок кода или быстро собрать MVP. Но это всего лишь момент времени. Настоящая инженерия работает с системой в динамике — и тут Vibe Coding пока бесполезен.

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

Настоящее «вайб-инженерство» — это обычная инженерия, но строже

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

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

Если хочется называть это Vibe Engineering, то пожалуйста. Но по сути — это всё та же инженерия, только без IDE.

Будущее — не сейчас

Когда этот подход станет реальностью? Хороший индикатор — вопрос «согласны ли вы выйти на дежурство по системе, полностью собранной ИИ?». Пока почти все отвечают «нет». И это многое говорит.

Итог? Vibe Coding — полезный инструмент. Он помогает быстро стартовать, сделать демо или сэкономить время.

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

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

Основные принципы Hexagonal Architecture

Мобильные и веб-приложения становятся все более сложными и производительными, поэтому требования к ним постоянно повышаются — ПО должно быть адаптивным, тестируемым и модульным, а компоненты в нем — независимыми. Hexagonal Architecture в Java предоставляет разработчикам эффективные решения, позволяющие достигать максимальных результатов с минимальными усилиями.

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

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

Принцип работы Hexagonal Architecture заключается во взаимодействии портов и адаптеров. Порты — это границы приложения, взаимодействующие с внешней для ядра средой: интерфейсами, сообщениями, базами данных, запросами командной строки и т.д. Адаптеры отвечают за трансляцию данных между разными интерфейсами.

Связь Hexagonal Architecture с принципами SOLID

Шестиугольная архитектура в java или скриптоподобном языке PHP работает по принципам объектно-ориентированного программирования SOLID. Согласно концепции, код нужно максимально упрощать, избегая запутанных конструкций.

Ключевым для Hexagonal Architecture считается пятый принцип SOLID — Dependency Inversion Principle (DIP), т.е. принцип инверсии зависимостей. Он гласит, что модули верхнего порядка не должны зависеть от модулей нижнего порядка. Код пишется таким образом, чтобы зависимости между компонентами приложения основывались на абстракциях вместо конкретных реализаций. Так, компоненты будет просто заменить, не воздействуя на другие части системы.

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

Структура Hexagonal Architecture

Шестигранная программная архитектура в java предполагает, что приложение имеет одинаковую управляемость со стороны пользователей, других приложений и автоматических текстов. Для логики не имеет значения источник вызова. Свойства Hexagonal Architecture обеспечиваются ее структурой, которую стоит рассмотреть в подробностях.

Центральное ядро — логика основного домена

Бизнес-логика — центральная часть любого приложения, отвечающая за реализацию внутренних правил и процессов. В рамках Hexagonal Architecture ядро рассматривается как ключевой компонент всей системы, куда поступают входные данные и откуда выходят через порты.

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

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

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

Порты

Порты — интерфейсы, которые определяют способы взаимодействия бизнес-логики приложения с внешними системами. Они работают как контракты, задающие стандарты для коммуникации.

Используется два типа портов:

• Управляющие. Их используют внешние участники в процессе взаимодействия с системой — например, элементы пользовательского интерфейса. Управляющие порты определяют способы, которые внешние клиенты применяют для запросов к бизнес-логике.
• Управляемые. С их помощью приложение взаимодействует с внешними сервисами — данными, системами обмена сообщениями, сторонним API. Эти порты отвечают за методы, обеспечивающие полноценную работу приложения.

Важная особенность портов в рамках гексагональной архитектуры и принципа DIP — их абстрактная природа, которая сохраняет независимость логики от деталей реализации. Порты определяют форматы ввода/вывода данных и протоколов, по которым ядро взаимодействует с адаптерами.

Адаптеры

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

Применяется два типа адаптеров:

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

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

Преимущества Hexagonal Architecture

Зачем использовать гексагональную архитектуру в программировании на Java? Все дело в преимуществах, которые обеспечивает этот паттерн. Рассмотрим основные плюсы «шестигранного» подхода.

Строгое разделение ответственности

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

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

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

Повышенная тестируемость

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

Тестируемость — одно из ключевых преимуществ Hexagonal Architecture. Она позволяет проверять работу отдельных компонентов системы в изоляции, что делает тесты более корректными и эффективными.

Снижаются затраты на обнаружение и исправление багов, прогеры быстрее выявляют и устраняют проблемы. Итог такого подхода — более надежное и устойчивое ПО.

Улучшенная адаптивность

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

Масштабируемость

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

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

Упрощенная интеграция

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

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

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

Такой подход не только ускоряет тестирование, но и снижает затраты: согласно исследованиям, использование модульных архитектур снижает расходы на интеграцию на 30%.

Недостатки и сложности применения

Минусов у гексагональной архитектуры немного:

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

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

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

Сравнение с другими архитектурными подходами

Многослойная архитектура (Layered Architecture), которая используется еще с 1970-х годов, представляет собой классический подход к построению программных систем. Такие приложения разделены на зависимые друг от друга слои, каждый из которых отвечает за конкретный аспект функционала — ядро, интерфейс, логику.

В отличие от такого паттерна, Hexagonal Architecture вводит концепцию портов и адаптеров, которая минимизирует зависимость между слоями. Это делает продукт более устойчивым, поскольку изменения в одном компоненте минимально затрагивают остальные части.

К примеру, в классической многослойной архитектуре изменение интерфейса доступа к данным может требовать значительных изменений в бизнес-логике, тогда как в Hexagonal Architecture такое обновление ограничивается заменой адаптера.

Гексагональная архитектура имеет схожие черты с Clean Architecture. Более того, Clean Architecture основана на принципах шестигранного паттерна.

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

Можно сказать, что Clean Architecture — это эволюция паттернов разработки. В таких приложениях код слабо зависит от изменений в изолированных слоях (бережем труд программиста), а сам продукт легко тестировать, масштабировать и поддерживать.

Примеры реализации

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

Адаптеры используются и в таких крупных проектах, как Amazon и Netflix — масштабируемость позволяет развивать приложения практически в реальном времени, улучшая пользовательский интерфейс и быстродействие.

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

Рекомендации по внедрению Hexagonal Architecture

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

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

Затем разрабатываются адаптеры, которые реализуют взаимодействие через порты с конкретными внешними системами (базами данных, веб-интерфейсами или API).

Завершающий этап — тестирование новой архитектуры: нужно убедиться, что она соответствует требованиям и хорошо интегрируется в существующую экосистему приложения.

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

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

• каких вы придерживаетесь трейдофов;
• какие требования у бизнеса, команды;
• какое техническое окружение;
• насколько система должна быть масштабируемой и отказоустойчивой;
• какая модель данных наиболее эффективная.

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

Для начала: антипаттерны и частые ошибки

Антипаттерны могут привести к сложному, плохо поддерживаемому или неэффективному коду. Ниже — несколько примеров.

Distributed Monolith

На мой взгляд, частая проблема в настоящее время — это Distributed Monolith, то есть микросервисы, которые имеют очень сильную связность — в таком случае лучше сделать обычный монолит.

В результате:

• При деплое одного сервиса нужно обновлять все остальные.
• Сервисы жёстко связаны через API.
• Не получается горизонтально масштабировать.

Например, у нас есть три микросервиса: заказы, оплата и пользователи. При этом сервис «Заказы» напрямую вызывает остальные сервисы, и наоборот. Так, если в одном сервисе поменяется API, остальные перестанут работать.

Чтобы исправить, можно использовать, например, асинхронную коммуникацию через Kafka.

Микролиты

Архитектура по идее микросервисная, но каждый микросервис настолько сложный, что превращается в «маленький монолит». Да, у сервиса есть собственная база данных, но код все равно сложно поддерживать и масштабировать.

Например, есть сервис «Каталог товаров». По идее, он должен быть простым, но в него добавили еще и данные о всех заказах, пользователях и платежах. Как результат — десятки зависимостей и сложная бизнес-логика.

Чтобы не было такой путаницы, упрощайте сервисы и следуйте принципу: «один сервис — одна ответственность».

Многослойность

Архитектура перегружена кучей слоев, например, API → сервис → репозиторий → DAO → DTO → и так далее. Причем каждый слой выполняет какую-то минимальную работу и банально вызывает следующий.

Каждый слой просто прокидывает вызовы и практически не несет ценности. Здесь важно помнить: если все, что делает слой, — это делегирует вызовы, он вам не нужен.

А теперь рассказываем, какие паттерны при разработке архитектуры будут эффективными.

Паттерны для предоставления данных и управления

Наиболее популярные паттерны для предоставления данных — MVC, MVVM и MVP. Рассказываем, чем они отличаются.

MVC (Model-View-Controller)

Этот паттерн делит приложение на три компонента: Model — хранит бизнес-логику, View — отображает UI, и Controller — обрабатывает ввод пользователя, следит за Model и View. Работает это так:

Пример — пользователь хочет авторизоваться на сайте:

1. Юзер вводит логин и пароль окно входа — через View.
2. View отправляет данные в Controller.
3. Controller передает логин и пароль в Model, которая проверяет их в базе данных.
4. Model возвращает результат (успешная или неуспешная аутентификация).
5. Controller обновляет View — он выводит либо сообщение, что все успешно, либо ошибку, например, «Неверный логин или пароль».

MVVM (Model-View-ViewModel)

В этом паттерне тоже три компонента, но немного другие: Model — тоже отвечает за логику, View — UI, который поддерживает привязку данных (data binding), ViewModel — преобразует данные Model для View, содержит команды для обработки действий. Вот схема:

Пример — пользователь хочет добавить новую задачу в список.

1. Пользователь вводит новую задачу в поле ввода через View.
2. View автоматически передает данные в ViewModel через двустороннюю привязку.
3. ViewModel обновляет Model, например, заносит новую задачу в базу данных.
4. Model говорит ViewModel, что данные изменились.
5. ViewModel обновляет View, и на экране появляется новая задача, но без явного вызова апдейта интерфейса.

MVP (Model-View-Presenter)

В этом паттерне лежат: Model, View — здесь это пассивный UI, Presenter — посредник между View и Model, плюс в нем есть логика отображения. Работает это вот так:

Пример — приложение, где есть чат.

1. Пользователь набирает сообщение и нажимает «Отправить» или просто кнопку через View.
2. View передает этот текст в Presenter, и он вызывает Model, который отправляет сообщение на сервер.
3. Когда сообщение отправлено, сервер возвращает подтверждение Model, а он говорит об этом Presenter.
4. Presenter обновляет View, добавляя это сообщение в интерфейс.
5. Когда приходит новое сообщение от друга/коллеги, Model получает его из сети и передает Presenter.
6. Presenter обновляет View и отображает новое сообщение в чате.

Мы используем MVC при разработке бэкенда, MVVM — при кодинге на Angular и Vue, а MVP — для разработки UI на Android.

А для управления данными можно использовать:

• Repository — абстрагирует доступ к данным и минимизирует зависимость от конкретной базы данных.

Важно разделять Repository на несколько интерфейсов (interface segregation). Для транзакций в распределенных системах можно использовать Saga или outbox + event bus.

• Unit of Work — контролирует транзакции на уровне логики.
• Active Record — связывает объекты с таблицами баз данных и просто упрощает работу.

Паттерны распределительных систем

Микросервисы, Event-driven архитектура и CQRS помогают создавать масштабируемые и отказоустойчивые приложения. Рассмотрим их подробнее.

Микросервисы

В микросервисах приложение разбивается на небольшие, независимые сервисы, каждый из которых отвечает за конкретную бизнес-логику. Сервисы взаимодействуют друг с другом через API (обычно это HTTP или gRPC).

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

Пример

В приложении онлайн-магазина могут быть такие сервисы — User/Client Service, Product Order Service и Payment Service. Очевидно, что такой паттерн подойдет только большим приложениям, поэтому использовать микросервисы ради того, чтобы использовать — бессмысленно. В таком случае лучше остановиться на монолите.

На мой взгляд, самая частая проблема — согласованность данных. В монолите гораздо проще её обеспечить средствами единого адресного пространства. Если мы говорим про подходы к декомпозиции, обычно используют декомпозицию по данным или доменной логике.

Чтобы микросервисы работали четко, нужно грамотно организовать мониторинг, логирование и управление конфигами. Плюс нужен Kubernetes и API-шлюзы.

Event-driven архитектура

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

Event-driven архитектура — это подход, при котором компоненты системы взаимодействуют через события. Сами события генерируются при изменении состояния системы и обрабатываются нужными компонентами.

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

Пример

Тот же самый интернет-магазин:

1. Пользователь создает заказ (создается событие).
2. Сервис уведомлений отправляет, например, пуш или письмо юзеру.
3. Сервис склада бронирует товары.
4. Сервис оплаты проводит транзакцию.

CQRS (Command Query Responsibility Segregation)

CQRS — это паттерн, который разделяет логику команд и запросов. Для чтения (Query) и записи (Command) используются разные модели данных — так можно оптимизировать каждую операцию.

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

Пример

Это может быть большой блог или медиа. Работать будет так:

• Через Command будут добавляться новые статьи или обновляться предыдущие.
• Через Query будет, например, происходить поиск по ключевым словам или собираться список статей по тегам.

Эти паттерны часто используются вместе. Например, в микросервисной архитектуре можно применять Event-driven подход, чтобы взаимодействовать между сервсами, а CQRS — для оптимизации операций чтения и записи.

Паттерны для масштабируемости

Если у вас падает один компонент, он не должен тянуть за собой всю систему и влиять на пользователей. Для этого есть паттерны, которые повышают надежность приложения.

Circuit Breaker

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

Например, вы делаете покупку на маркетплейсе, и у в нем упал платежный сервис. В таком случае Circuit Breaker временно блокирует запросы и говорит пользователю, что нужно попробовать оплатить позже.

Load Balancer

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

Например, в стриминговом сервисе Load Balancer распределяет пользователей между разными серверами, чтобы не было перегрузки и они могли спокойно смотреть контент без задержек.

Retry (exponential backoff with jitter)

Паттерн нужен для повторения идемпотентного действия, которое завершилось безуспешно. Так, некоторые ошибки бывают кратковременными, и вместо немедленной блокировки запроса, Retry позволяет повторить запрос, но с увеличенным интервалом между попытками (экспоненциальная задержка). А добавление случайного разброса времени (jitter) помогает избежать ситуации, когда все запросы повторяются одновременно, вызывая новую перегрузку.

Например, вы пытаетесь купить билеты в театр на большую премьеру, но вместе с вами на сайте сидят еще 10 000 человек. Сервер временно перегружен, но система не сразу выдаст ошибку, а будет пытаться найти вам хотя бы какое-то место (где-то на последнем ряду балкона).

Паттерны безопасности

• OAuth 2.0 — стандартное решение. Он позволяет пользователям предоставлять доступ к своим данным сторонним сервисам без передачи пароля. Например, зарегистрироваться на сайте через Google, Яндекс или VK.
• TLS (Transport Layer Security), криптографический протокол, шифрует данные при передаче.
• AES один из самых надежных алгоритмов симметричного шифрования. Его часто используют в базах данных или кеше.
• Token-based Security — безопасная аутентификация с JWT. В основе лежит цифровая подпись (обычно HMAC или RSA) — она гарантирует подлинность данных.
• В финтехе используют HSM для генерации и защиты криптографических ключей на аппаратном уровне.

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

И поскольку даже опытные разработчики сталкиваются с дилеммами при выборе подходящей модели, на Solvery вы можете разобрать ваш проект и получить обратную связь от архитекторов и разработчиков уровня Яндекса, Авито и Т-Банка.

Если хотите сохранить короткую версию статьи — у нас есть она в ВК.

Определение и особенности монолитной архитектуры

Что такое монолитная архитектура и какие у неё основные характеристики

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

Основные характеристики:

• Единое хранилище кода и структур данных.
• Тесная взаимосвязь компонентов: изменения в одном модуле часто требуют обновлений в других.
• Унифицированное развертывание: приложение разворачивается в одном контейнере или среде.

Плюсы монолита

• Простота разработки. Все компоненты находятся в одном репозитории, что упрощает работу команды. Так, разработчики могут сосредоточиться на функциональности, а не на взаимодействии между сервисами. Плюс разработчики быстрее ориентируются в архитектуре.
• Единое развертывание. Нет необходимости управлять множеством сервисов, а обновление системы требует лишь одной операции деплоя.
• Легкость тестирования. Общее тестирование всех компонентов можно проводить в одной среде. А еще проще реализовать интеграционные и функциональные тесты.
• Удобство в небольших командах. Подходит для стартапов или проектов с ограниченными ресурсами, где важно быстро приступить к работе.

Минусы монолита

• Сложность масштабирования. Масштабирование требует копирования всего приложения, даже если нужно повысить производительность только одной его части. Плюс если высокую нагрузку испытывает лишь одна часть приложения, увеличивать производительность приходится для всей системы.
• Зависимость компонентов. Любое изменение в одном модуле может привести к непредсказуемым последствиям в других частях системы. К тому же трудно изолировать ошибки и снижать взаимные влияния между частями приложения.
• Долгосрочная поддержка. Переход на новые технологии требует переработки всей системы. Например, если монолитная архитектура построена на устаревшей версии фреймворка, переход на более современный инструмент требует изменений во всех связанных модулях, включая базу данных, пользовательский интерфейс и API.
• Риск единой точки отказа. Ошибка в одном компоненте может привести к полной остановке всего приложения.

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

Определение и особенности микросервисной архитектуры

Что такое микросервисная архитектура и её ключевые аспекты

Микросервисы как архитектура представляет собой подход, при котором приложение разбивается на независимые модули (микросервисы). Каждый микросервис выполняет определённую бизнес-функцию, имеет собственную базу данных (или доступ к её сегменту) и взаимодействует с другими через API.

Ключевые аспекты:

• Микросервисы разрабатываются, развёртываются и масштабируются отдельно.
• Каждый микросервис отвечает за конкретную бизнес-логику.
• Микросервисы могут использовать различные языки программирования, базы данных и фреймворки, что позволяет выбрать оптимальный инструмент для каждой задачи.

Плюсы микросервисов

• Гибкость. Микросервисы можно развивать независимо друг от друга. Так, в музыкальные стриминги (по типу Яндекс.музыки) новый функционал приложения можно добавлять без изменения сервиса, отвечающего за управление библиотекой треков.
• Масштабируемость. Каждый микросервис масштабируется отдельно в зависимости от нагрузки. Не нужно тратить время и мощности но прокачку одних и тех же функций одновременно, а сосредоточиться на приоритетных.
• Независимое развертывание. Обновление одного микросервиса не требует остановки всей системы. Например, если в приложении нужно обновить модуль расчёта стоимости (если мы разрабатываем Ozon или WB), это не повлияет на работу модуля оформления заказов.

Минусы микросервисов

• Сложность в настройке. Организация микросервисной архитектуры требует грамотной настройки инфраструктуры. Например, необходимо настроить API-шлюз для управления запросами, систему контейнеризации (например, Docker) и оркестрацию (Kubernetes).
• Необходимость управления сетью. Микросервисы взаимодействуют через сеть, что может приводить к задержкам и ошибкам. Например, если сервис обработки платежей не отвечает из-за проблем с сетью, процесс оформления заказа на том же Озоне может быть временно недоступен.
• Сложности в тестировании. Интеграционное тестирование требует симуляции взаимодействия между десятками или сотнями сервисов.

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

Сравнение монолита и микросервисов

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

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

Монолит

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

Микросервисы

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

Масштабируемость: вертикальное и горизонтальное масштабирование

Монолит

Плюс монолита в том, что его масштабирование осуществляется вертикально (больше оперативной памяти —> мощнее процессор). Это быстро, но дорого, и есть физические ограничения на увеличение ресурсов.

Микросервисы

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

Поддержка и обновление: как быстро можно добавлять новые функции

Монолит

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

Микросервисы

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

Командная работа: как архитектура влияет на распределение задач в команде

Монолит

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

Микросервисы

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

Факторы, которые влияют на выбор архитектуры

Выбор между монолитной и микросервисной архитектурой зависит от множества факторов, например, особенностей команды, масштаба проекта, технических требований и доступных ресурсов. Так что же выбрать?

Размер и опыт команды разработчиков

Маленькая команда

Если команда небольшая и состоит из 3–5 человек, лучше начать с монолитной архитектуры. Например, для стартапа с ограниченным бюджетом разработка единой кодовой базы будет быстрее и эффективнее, так как все участники смогут работать в одном контексте без разделения на сервисы.

Большая команда

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

Уровень опыта

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

Сложность и масштаб проекта

Простые проекты

Для небольших приложений монолитная архитектура подходит идеально.

Сложные и крупные проекты

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

Требования к производительности и масштабируемости

Низкие требования

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

Высокие требования

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

Планы на будущее и возможность роста проекта

Краткосрочные проекты

Для приложений с коротким жизненным циклом лучше выбрать монолит. Например, MVP для тестирования идеи легче разработать именно так, поскольку это позволяет быстрее выйти на рынок.

Долгосрочные проекты

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

Инфраструктура и доступные ресурсы

Ограниченная инфраструктура

Монолитные приложения не требуют сложной инфраструктуры. Их можно развернуть на одном сервере и минимизировать затраты на администрирование.

Развитая инфраструктура

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

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

Кейсы, или практические советы по выбору архитектуры

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

Когда стоит использовать монолит

• Простые проекты. Локальный магазин для продажи органической продукции, где пользователь может оформить заказ через простую корзину, а администратор получает уведомление на почту.
• Стартапы с ограниченными ресурсами. Новый бренд, продающий уникальные дизайнерские украшения, быстро запускает MVP с базовыми функциями: каталог, корзина, оплата и личный кабинет.
• Приложения без высоких требований к масштабируемости. Интернет-магазин для корпоративных клиентов, где покупки совершаются нерегулярно, и основная нагрузка на сервер минимальна.

Когда подходят микросервисы

• Крупные проекты. Большой интернет-магазин с тысячами товаров, сложной структурой категорий и разными модулями (каталог, поиск, рекомендации, платежи).
• Распределённые команды. Когда команда в одной стране разрабатывает сервис логистики, а команда в другой — систему интеграции с локальными платёжными провайдерами.
• Приложения с высокой нагрузкой. Маркетплейс, который обрабатывает миллионы запросов в секунду, поддерживает сложные фильтры, рекомендации и динамическое ценообразование.

Как перейти с монолита на микросервисы

1. Оцениваем текущую архитектуру

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

2. Разрабатываем стратегию миграции

Постепенно выносим модули, сохраняя функциональность. То есть сначала выносим модуль обработки платежей в отдельный сервис, затем переходим к модулям рекомендаций и аналитики.

3. Обеспечиваем инфраструктуру

Настраиваем контейнеризацию для запуска микросервисов (например, Docker для микросервисов каталога и управления заказами с общей базой данных).

4. Используем очередь сообщений

Реализуем асинхронное взаимодействие сервисов. Можем настроить очередь RabbitMQ для передачи данных о новых заказах от фронтэнда к микросервису логистики.

5. Тестируем взаимодействие сервисов

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

Примеры реальных проектов и их архитектурных решений

Примеры компаний, которые используют монолит и преуспели в этом

Basecamp

Basecamp — популярный инструмент для управления проектами. Он известен своей монолитной архитектурой. Для команды Basecamp это решение значительно облегчает внедрение новых функций и упрощает развертывание, так как все компоненты находятся в одной кодовой базе.

Shopify

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

GitHub

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

Примеры компаний, которые выбрали микросервисную архитектуру

Netflix

Для масштабируемости и высокой доступности Netflix перешел от монолитной архитектуры к микросервисам. Это позволило им эффективно обрабатывать большое количество запросов пользователей и улучшить управление различными компонентами системы.

Amazon

Amazon, особенно его платформа Amazon Web Services (AWS), также широко использует микросервисы. Переход к такой архитектуре позволил Amazon улучшить управление масштабируемостью, изоляцию сбоев и гибкость развертывания. Каждый сервис отвечает за отдельную задачу, что делает платформу более гибкой и облегчает масштабирование отдельных компонентов.

Ошибки, которых стоит избегать при выборе и реализации архитектуры

1. Вы не понимаете требования

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

Совет: Тщательно анализируйте требования к масштабируемости, безопасности, производительности и возможностям роста, прежде чем принимать решение о типе архитектуры.

2. Вы не учитываете долгосрочные последствия

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

Совет: Планируйте архитектуру с учётом будущих потребностей и возможности масштабирования, но не усложняйте проект без реальной необходимости.

3. Вы игнорируете опыт и возможности команды

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

Совет: Оцените техническую зрелость и возможности вашей команды, чтобы понять, будет ли она в состоянии поддерживать сложную архитектуру.

4. У вас проблемы с тестированием

При использовании микросервисной архитектуры сложнее поддерживать тестирование, так как необходимо чекать не только отдельные сервисы, но и взаимодействие между ними. В монолитной архитектуре тестирование проще, но с увеличением объема кода и сложности системы это может стать проблемой.

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

5. Вы не уделяете внимание безопасности

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

Совет: Включите в архитектурное проектирование практики безопасности с самого начала, независимо от того, выбрали вы монолит или микросервисы.

Эти ошибки можно избежать, тщательно планируя архитектуру, принимая во внимание как текущие потребности, так и потенциальные вызовы в будущем.

Постановка задачи

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

Итак, архитектурно ПОДД до трансформации – распределенная система из множества связанных между собой компонентов. Ее ядром является планировщик запросов на базе Apache Calcite, а основной протокол взаимодействия компонентов – журнал на базе Apache Pulsar, обеспечивающий гарантированность доставки. Механизм ограничения нагрузки (Rate Limiting) защищает систему от DoS-атак. Обработка запроса включает разбор запроса, производимый при каждом вызове. С целью обеспечить гарантированную доставку все сообщения сохраняются на диск.

До трансформации система поддерживала 1000 активных пользователей одновременно, время отклика 1 секунду (в 99% случаев) и мощность (пропускную способность) 5000 запросов в секунду. В соответствии с ТЗ заказчика, нам необходимо было получить следующие характеристики: 25000 активных пользователей, мощность 30000 запросов в секунду и время отклика не более 0,5 секунд на 99%.

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

Этап 1: сдвигаем «бутылочное горлышко»

Предельные значения пропускной способности и времени отклика определяются максимальной потребностью в ресурсе – то есть временем, проведенном задачей на аппаратном ресурсе. Тот ресурс, который более всего замедляет систему, становится так называемым «бутылочным горлышком», задавая показатели производительности, выше которых подняться невозможно. Это основная проблема любой высоконагруженной системы, поэтому авторы учебников рекомендуют начинать ее оптимизацию именно с поиска «бутылочного горлышка». Оптимизация этого ресурса дает существенно больший выигрыш в производительности, чем оптимизация любого другого компонента системы.

Классический алгоритм действий для решения этой задачи – принцип центрирования. Находим «бутылочное горлышко» по симптомам: максимальная утилизация ресурса, максимальная потребность в ресурсе (время пребывания в ресурсе за один запрос), максимальная очередь к ресурсу. В нашем случае оно было очевидным: Apache Calcite. Обработчик запросов и тормозил систему больше всего. Для уменьшения потребности в этом ресурсе мы последовательно рассмотрели несколько тактик.

Первая – оптимизация алгоритма. Это был бы хороший заход, если бы Calcite писался нами «с нуля». Calcite не ускорить и сложно заменить, переписать его можно, но очень дорого. Мы сделали из него практически собственный форк, но в итоге уперлись в некоторые основные механизмы, которые переписывать не рискнули. Таким образом, эффективность здесь не особо работает.

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

Третья – уменьшение накладных расходов, то есть экономия на транспорте. Вариант приемлем, когда в системе много времени уходит на взаимодействия, всевозможные перекладывания, перекодирование и т. д. Здесь он не работает, так как в рамках Calcite накладных расходов просто нет.

Четвертая – раннее связывание. Подход здесь следующий: если большинство запросов регламентированы, то есть SQL известны заранее, мы можем разобрать их еще до выполнения, а потом просто брать их с диска и выполнять.

Эту тактику мы и выбрали. Убрали разбор и планирование запроса Calcite с основного пути, передвинув его в область «особых случаев» (паттерн Special Cases). То есть, когда система получит неизвестный SQL, то погонит его через Calcite. В остальных случаях планы запросов составляются заранее и берется уже готовый, закэшированный план выполнения. Это существенно сократило время выполнения запросов.

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

Но уже на этом этапе мы добились времени отклика примерно 300 микросекунд на основных сервисах и пропускной способности 10000 запросов в секунду. Количество одновременных активных пользователей осталась прежней – 1000.

Оптимизация «надсистемы»

Согласно методологии, если системе не удается больше ничего улучшить, нужно выходить в «надсистему» – то есть не бить «точечно» по сервисам, а смотреть на систему целиком. И на этом этапе на первый план выходит третья из перечисленных выше тактик – уменьшение накладных расходов. Здесь уже появляется сетевое взаимодействие, которое вполне можно оптимизировать.

По нашим подсчетам, на пути каждого запроса в системе происходит 6 взаимодействий, большинство из них это Apache Pulsar. Мы можем уменьшить накладные расходы прежде всего за счет снижения количества этих взаимодействий, а также за счет их облегчения самих по себе. Важное правило, которым я всегда пользуюсь: быстро бегущий «монолит» лучше группы микросервисов. Микросервисы – это не про производительность, а скорее про то, как быстро вывести фичу на рынок. Если же вы хотите избавиться от накладных расходов, сервисы придется укрупнять. Мы уменьшили количество соединений до 4, сэкономили несколько микросекунд, устранили избыточные сетевые задержки.

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

Разумное решение – убрать сохранение на диск, заменив Pulsar механизмом RSocket. В итоге брокер у нас остался, но самописный и легкий. Потоковое взаимодействие обеспечивается поверх других взаимодействий, а значит, если мы один раз установили соединение, то потом не тратим время на его переустановление.

Однако при такой схеме мы теряем важную характеристику – гарантированную доставку, которая должна обеспечить надежность системы на уровне 99,999% (пять девяток). Поэтому вместо сохранения всех сообщений на диске мы применяем схему с надежным подписчиком (Durable Subscriber): то есть прогоняем все запросы через память, но если кто-то на этом пути запрос не забрал, система отправляет его на диск и поднимает оттуда, когда Агент ПОДД заново вычитывает свои сообщения. Для реализации этой схемы мы использовали инструмент BookKeeper, который остался после Pulsar.

Результат – система поддерживает одновременную работу 30000 активных участников, сквозное время отклика – 20 микросекунд. Пропускная способность сохраняется с первого этапа: 10000 запросов в секунду. Напомним, что нам нужно поднять ее до 30000.

Разумное масштабирование

Поскольку на этапе оптимизации «бутылочного горлышка» мы уперлись в «КриптоПро», решение задачи по увеличению пропускной способности системы теперь будет связано с масштабированием – добавлением новых инстансов сервиса. Расчет необходимого количества элементов для масштабирования с запасом показал, что количество инстансов необходимо увеличить в 4 раза.

Однако на этом задача на практике не исчерпывается. Дело в том, что масштабирование – это не только количество «железа», но и, в том числе, грамотная балансировка. Несбалансированная обработка нивелирует эффективность масштабирования – ведь если балансировщик все запросы будет отправлять на один инстанс, все остальные будут бездействовать. Так, сервис K8s с настройками по умолчанию не выполняет балансировку запросов на обслуживаемые сервисы. Когда создается TCP-соединение, оно проходит через правила iptables, которые и выбирают конкретный pod бэкенда, куда попадет трафик. Поскольку все следующие запросы идут уже по открытому TCP-соединению, правила iptables больше не вызываются.

Нужен грамотный балансировщик, который правильно распределяет задачи по инстансам, желательно используя понимание размеров и веса этих задач – так называемое умное планирование. «Коробочных» решений для этого, к сожалению, нет. Надо либо дорабатывать Kubernetes, либо самим разрабатывать решение. Мы остановились на втором варианте: использовали клиентскую балансировку Join-Shortest-Queue (JSQ) на хост с минимальной очередью. Данная балансировка самая простая с точки зрения реализации – эффективный, хотя и не идеальный алгоритм. С точки зрения времени отклика здесь идеально смотрелся бы алгоритм SITA (Size-Interval Splitting), но он может привести к недоутилизации и снижению пропускной способности.

А как же закон Амдала? Ведь, согласно нему, масштабирование не всегда приводит к успеху: бывает, что производительность падает с увеличением количества инстансов. Допустим, мы выдержим нагрузку на четырех инстансах – а какова предельная мощность системы? Для расчета максимально возможного количества инстансов мы используем не формулу Эрланга 2-го рода (в данном случае слишком сложную), а универсальный закон масштабируемости Гюнтера, USL. Эта формула дает более приблизительные ответы, но они достаточны для предварительной оценки. Закон рассматривает два коэффициента, влияющие на падение производительности: «штраф конкурентности» (contention penalty) и «штраф когерентности» (coherence penalty). Учитывая их, мы вычислили, что в нашей схеме производительность будет падать при масштабировании примерно до 10 инстансов.

Также мы нашли участника нашего взаимодействия который ограничивал наши сервисы по взаимодействию – это сервис блокировок. Без Rate Limiter в асинхронной системе не обойтись: если не ограничивать каким-то образом поток, систему рано или поздно «затопит». Если мы хотим держаться в рамках приемлемого Latency, мы должны это контролировать. В то же время существуют другие механизмы контроля потока, не только ограничение пропускной способности. В частности, контроль длины очереди возможен через организацию обратного давления (Back Pressure).

Таким образом, мы контролируем длину очереди, организуя обратное давление на агентов – просто не пускаем их в систему, пока длина очереди не станет приемлемой. Таким образом обеспечивается работоспособность системы целиком. Rate Limit в системе остался, но за пределами основного контура.

Результат

В результате проекта модернизации системы ПОДД мы добились целевых показателей и даже существенно перевыполнили их: 30000 активных участников (цель по ТЗ – 25000), мощность – 60000 запросов в секунду на 4 инстансах (цель – 30000), время отклика – 0,2 сек в 99% случаях (цель – 0,5 сек).

Перечислю основные результаты нашей работы:

• распределенная система из нескольких слабосвязанных компонентов;
• оптимизированный брокер сообщений на базе протокола Rsocket;
• предварительный расчет планов обработки с использованием Apache Calcite;
• сохранение сообщений на диск осуществляется только при невозможности доставки;
• оперативные данные не привязаны к конкретным экземплярам сервисов;
• балансировка по наименьшей очереди;
• обратное давление.

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

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

Когда вскрывается проблема

Представьте, вы пишете проект на Django в команде из пяти человек. На старте все замотивированы «сделать хорошо», ведь это шанс сделать проект «идеальным» с самого начала. Но проходит год или два, проект обрастает парой десятков тысяч строк кода. Разрабатывать становится всё сложнее: файлы ломятся от кода, навигироваться по проекту без продвинутых инструментов из IDE просто невозможно.

В этот момент разработчики обычно говорят, что причина возрастающей сложности — рост проекта. Или грешат на «коллег-говнокодеров» / «плохой фреймворк». Хотя с ростом проекта навигация действительно естественным образом усложняется, чаще всего виноваты отнюдь не фреймворки или количество строчек, а плохие решения.

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

Зачем нужны эти границы? Разве без них не лучше?

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

Архитектура MTV

Самый «высокоуровневый» фрейм в Django — это архитектурное разделение логики на Model, View и Template.

Да, архитектура Django называется именно MTV, а не MVT. Разработчики используют в документации именно такую аббревиатуру. По сути, архитектура почти полностью повторяет другой подход — MVC, Model-View-Controller (Модель-Представление-Контроллер).

Суть такая:

• в Model хранят данные сервиса;
• View отвечает за отображение данных пользователю;
• Controller отвечает за то, чтобы сообщать Model, когда пора менять данные.

В Django же отошли от этой концепции и использовали архитектуру Model, View и Template. Сами разработчики Django пишут, что не видят никакого конфликта с MVC. Model по-прежнему отвечает за хранение данных и работу с ними. View — за «отображение» данных. Просто этот слой они разделили на два: View отвечает за то, чтобы решить, какие данные отображать, а Template — как отображать. Куда делся Controller из MVC? В аббревиатуре MTV он пропал.

Разработчики считают, что это сам фреймворк.

Возможно, вы хотите спросить, зачем я об этом рассказываю. Разве возможно накосячить на этом уровне? Вообще-то, да.

Бизнес-логика, или слой Services

Многие разработчики пытаются переизобрести MTV и добавляют в Django дополнительный слой: Services. Вы найдёте файл serivces.py во многих туториалах и видео по Django.

Необходимость добавления этого слоя обычно объясняют так:

• В моём проекте появились функции, которые не укладываются ни в Model, ни во View;
• Я хочу сделать «бизнес-логику» реюзабельной между приложениями, и, чтобы не импортировать функции из одного View в другой, храню их отдельно.

Эти проблемы действительно существуют. Зачастую в проекте появляются вспомогательные функции, которые не принадлежат стандартным сущностям Django, вроде Model или View.

Но решение складывать весь этот код в файл services.py, на мой взгляд, плохое. Вот почему:

Слой Services слишком широкий, это плохая рамка. При определении рамок важно не определить, какой код можно класть в этот файл, а решить, какой код в этот файл класть нельзя. Для сравнения, Model хорошо справляется с этой задачей: если код не относится к работе с БД, то ему не место в файле models.py. А в services.py часто кладут всё, что не влезло в остальные.

Файл становится свалкой. Это ожидаемое следствие плохой рамки. Я часто интересуюсь у друзей и у кандидатов на собеседованиях, есть ли в их текущих или прошлых проектах такая проблема: в services.py более 2 тысяч строк кода и по нему тяжело навигироваться. Если в проекте более 10 тысяч строчек кода, разработчики почти единогласно говорят, что файл превращается в свалку.

Файл размывает слой View. Есть мнение, что в файл services.py нужно выносить бизнес-логику. Термин «бизнес-логика» кажется конкретным — это всё, что определяется правилами бизнеса. Но на поверку он размыт куда сильнее, чем кажется. Разработчики, глядя на функцию, иногда не могут сказать, бизнес-логика это или нет.

Куда девать общий код?

Альтернативное решение — оставить фреймворк в покое и не добавлять в него новый слой. Если появилась новая логика, то создать файл с говорящим названием и положить код в него. Если логики вынести нужно много — создайте несколько файлов. Искать нужную функциональность проще в одном мегафайле на тысячу строк или в пяти небольших по двести строк? Так будет куда понятнее, где, например, искать функцию, которая форматирует дату или преобразует цену товара:

Писать запросы в слое View — это нормально

Я так и не разобрался, откуда взялся миф о том, что во View нельзя писать запросы в БД, и в чём аргументация его сторонников. Это правило просто откуда-то «взялось», и теперь в него верят как в аксиому.

Тем не менее в документации Django для слоя View очень простое определение:

The view itself contains whatever arbitrary logic is necessary to return response.

Соответственно, в этом слое можно делать ORM-запросы, если это нужно для ответа. Не обязательно пытаться «прятать» этот код куда-то ещё.

Часть запросов будут нести бизнес-смысл, то есть они станут частью бизнес-логики. Иногда это будет даже не один запрос в БД, а несколько, или даже пара строк кода между ними.

По принципу MVC «Fat models, skinny controllers, simple views», большую часть такого кода стоит стараться класть в слой Model. Один из самых недооценённых, на мой взгляд, способов — переопределение QuerySet. Этот способ позволяет взять здоровый запрос на 10 вызовов методов ORM и дать ему простое, бизнесовое название.

Со слоем Services получается «Skinny Models, Skinny Controllers, Fat Services». На мой взгляд, это очевидное отхождение от принципов, которые изначально закладывались в фреймворк.

Приложения (app)

Сейчас эпоха популярности микросервисов над монолитами. Из-за этого сама архитектура Django-монолита стигматезируется, некоторые мои знакомые даже не пытаются пилить Django-монолиты на приложения. Но ведь «монолит» не равно «свалка»! За ним всё ещё стоит ухаживать.

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

Можно представить, что MTV разделяет код на «красное», «синее» и «зелёное», а приложения — это разделение на «круглое», «квадратное» и «треугольное». Важное правило в делении логики на приложения — Cohesion and Coupling. Если коротко, это о связности между приложениями: нужно добиваться состояния, когда у вас мало связей между приложениями и много внутри них.

Вот к этому нужно стремиться:

Между «разделёнными группами» связей мало, почти все связи спрятались внутри групп. Кружочки одного цвета — это части кодовой базы, которые сильно связаны друг с другом.

А вот такого стоит избегать:

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

Справа совсем всё плохо: код разделён на такие маленькие группы, что каждый кусочек кода сам по себе стал «группой». Это называется ‘Destructive decoupling’.

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

Когда вы группируете логику в приложения, в первую очередь смотрите, какая логика постоянно совместно используется. Переводя в идею про Cohesion and Coupling — какие из кружочков связаны большим количеством стрелочек.

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

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

Не стесняйтесь создавать новые приложения.

Что делать, если одна модель не помещается ни в одно из приложений? Создайте для неё отдельное!

А что, так можно? В целом ПРИЛОЖЕНИИ будет всего одна жалкая моделька?!

Да, можно. Даже нужно.

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

Процесс выделения этой логики в новое приложение будет болезненным, и, делая это, вы будете задаваться вопросом: «какой м**ак раскидал эту логику по приложениям?».

Очевидно, слишком увлекаться тоже не стоит. Иначе столкнётесь с Destructive decoupling. Но и бояться создания приложений не нужно.

Файлы

Ещё один слой разделения логики по фреймворкам — это файл. Мы касались темы файлов выше, давайте резюмируем уже сказанное:

1. Свалка в файлах вредит навигации по проекту.
2. Cohesion and Coupling поможет разложить логику по файлам.
3. Не стесняйтесь создавать файлы, даже если кода внутри будет мало. Это поможет потом не страдать, выкорчёвывая функции из кода.
4. Название файла должно задавать чёткую однозначную границу, говорить о том, какому коду здесь не рады. Иначе свалки не миновать.

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

С файлами аналогично, это тоже контейнер для кода. Просто функции хранят в себе строчки кода, а файлы хранят в себе функции.

У ситуации «переборщили с количеством файлов» есть надёжный симптом — читая интересующий код, вы не задерживаетесь в одном файле больше, чем на 30 секунд. Всё время приходится двигаться по файлам туда-сюда. А это и есть нарушение принципа Cohesion and Coupling.

Итоги

Если во время чтения статьи вы успели потерять основные тезисы, то вот небольшой конспект. ?

1. Services – не часть MTV;
2. Плохое название файла приведёт к свалке;
3. Можно писать запросы в слое View, не бойтесь этой практики;
4. Монолит – не повод сваливать всё в кучу;
5. Группировать по юзкейсам лучше, чем по сущностям;
6. Не стесняйтесь создавать новые файлы и приложения, даже если кода в них мало;
7. Разложить логику по файлам поможет Cohesion and Coupling.

Что было до

Раньше Дзен состоял из двух бэкендов — так называемые фронт и рекомендер — и балансеров над ними. Фронт принимал весь пользовательский трафик. Нижний, рекомендер, реализовывал систему выдачи и рекомендаций для пользователей контента (500 миллисекунд в 99-м перцентиле) и хранил в себе сотни миллионов документов.

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

Такой подход влиял и на скорость работы в целом. Сервисы разного объёма — например, получение экспериментов, рекламы и рекомендательная система — лежали на одном бэкенде.

При этом интеграции с разными браузерами и мессенджерами и 20 миллионов активных ежедневных пользователей оказывали нагрузку до 150 тысяч RPS на сервера. И Дзен развивался. Появлялись новые типы контента — статьи и видео разных форматов, — и отдельные команды, каждая со своими продуктовыми требованиями и стеком.

Мы поняли: чтобы поддерживать работу и быстро расти, пора переписывать инфраструктуру.

Что нужно было учесть

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

• Durability. Если пользователь написал и сохранил статью, он должен быть уверен, что через неделю она останется на том же месте. Вне зависимости от того, переписали мы что-то или нет.
• Доступность. У Дзена есть концепция четырёх девяток. За отчётный период мы должны быть доступны 99,99% времени, то есть можем простаивать примерно 52 минуты в год.
• Консистентность внутри данных. Если пользователь написал статью, она должна корректно попасть в ленту канала, карусель с подборками новых статей автора, подписки читателя и так далее. И не должна внезапно пропадать из рекомендаций. То есть данные о новой единице контента, подписке или лайке должны консистентно «разойтись» по сервисам, продуктам и счётчикам.
• Скорость. Во-первых, само приложение, все вкладки и окна должны открываться быстро и плавно. Во-вторых, контент должен выгружаться на платформу как можно быстрее. Для этого мы постоянно:оптимизируем алгоритмы рекомендаций;работаем над новыми классификаторами и скоростью разметки контента;переписываем код и ищем, что можно запускать параллельно.
• Микросервисы. Мы обслуживаем большой RPS, разрабатываем множество фич — от студии блогера до ленты комментариев — разными командами. И поддерживать всё это на монолите сложно.

• Железо. Чтобы поддерживать рекомендательный сервис и обрабатывать сотни миллионов документов за миллисекунды, нужно 80 тысяч ядер.
• Плавность. Все рефакторинги должны были происходить для пользователя бесшовно. Для этого мы выделяли ответственность, ту же геобазу, деплоили её в отдельный сервис и затем переставали хранить эту ответственность в монолите.

Что мы сделали с бэкендом приложения

Выделили ответственности внутри монолита

Ответственность — это часть монолита, которую можно выделить в отдельный сервис или фичу. Например:

• SSR — набор сервисов, которые рендерят наш сайт;
• Клиентский API, куда приходит пользователь, чтобы посмотреть или выложить контент, и все взаимодействия с бэкендом по протоколу клиент-сервер;
• Система авторизации пользователя;
• Система сбора Big Data о пользователе;
• Сервис пользователя — сервис, который резолвит пользователя в конкретную страну/город/район и так далее;
• Рекомендер;
• Сервис, который реализует A/B-тесты (мы можем проводить тысячи таких одновременно) и фиксирует, какие пользователи в какие эксперименты попадают;
• Сервис рекламы — отвечает за то, какую рекламу и в каких количествах показать пользователю.
• И ещё десятки других ответственностей.

В итоге мы получили «пирог», в котором каждый слой — это отдельная ответственность. И начали искать способ этот пирог порезать.

Распилили монолит по этим ответственностям и выделили отдельные сервисы

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

В итоге каждая ответственность расползалась по разным сервисам — как это было раньше — чего мы и пытались избежать.

Затем попробовали делить монолит «по слоям»: вынесли SSR, клиентский API и другие — и получили дерево зависимостей этих ответственностей друг от друга.

На следующем этапе мы переписали дерево. Начали с «листьев». Например, сервис пользователя не имеет своих зависимостей, а является только зависимостью для других сервисов. Мы вынесли её, переписали на новый стек, создали под неё отдельный сервис и выдали его отдельной команде.

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

Часть сервисов — например, авторизацию — пришлось писать «сбоку», и потом постепенно переносить коммиты.

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

Прописали взаимодействие между сервисами

Для этого использовали Service Mesh и его реализацию Apphost, написанную Яндексом. У неё несколько плюсов.

1. Apphost включает декларативный конфиг зависимостей между сервисами. То есть у него есть граф зависимостей, который получает request пользователя на входе и выдаёт response на выходе. Между ними — облако выделенных нами сервисов, которые зависят друг от друга. Описание графа находится в конфиге Service Mesh нашего Apphost и описано декларативно.

1. Apphost ходит в бэкенд приложения, минуя слой балансеров, которые роутят трафик (тех же сайдкаров с HTTP-прокси, через которые сервисы ходят друг в друга). Это даёт преимущество в latency, скорости и надёжности.
2. Форсятся правильные политики отказоустойчивости. И разработчику не нужно указывать, с какими ретраями, с каким таймаутом он будет ходить в другой сервис. Так, исключается каскадное падение системы, и никто не может её задедосить (разве что сам Apphost).
3. Появился сервисный трейсинг запроса. Благодаря ему мы видим, в какой момент упало выполнение запроса и что конкретно отвалилось. К тому же в микросервисах без него невозможно расследовать инциденты и дебажить.

Что нам это дало

Мы перешли на архитектуру Service Mesh, выделили сервисы, отдали их продуктовым командам. Так, любой из 200 сервисов смог релизиться отдельно, может быть выкачен и не заблочится на релиз другого сервиса. Также у нас поддерживается обратная совместимость в протоколе их взаимодействия друг с другом.

Благодаря такому распилу мы смогли сделать чанковую загрузку сайта (HTTP Chunked Encoding). Поисковая строка, рекомендательная лена подгружаются на главную страницу dzen.ru отдельными чанками, за каждый из которых отвечает свой бэкенд. И пока подгружаются тяжёлые рекомендации, более лёгкие элементы сайта уже доступны пользователю. И отображение в целом происходит быстрее, что положительно сказывается на UX пользователя.

Поначалу копаться в бэкенде приложения было сложно, потому что, по сути, это — большой пласт легаси. В нём оставались наслоения логики, которые складывались годами, невозможно было выяснить, почему конкретный if делает то, что делает. И чтобы убрать этот if, три строчки кода, мы тратили полтора часа на анализ логов.

Но чем больше сервисов мы выносили из монолита, чем больше задач решали вне его, тем проще было работать. Потому что в нём остались только legacy-ручки для старых клиентов, старые приложения, которые мы редко используем и редко коммитим.

К тому же помогала мотивация и желание сделать что-то крутое и полезное из большой и тяжёлой структуры.

1. Почему Ansible, а не PowerShell
2. Как настроить деплой приложения
3. Как деплоить базу данных Oracle
4. Деплой бэкенда и фронтенда приложения
5. И пара лайфхаков

Почему Ansible, а не PowerShell

• Один подход написания плейбуков для Windows и Linux-серверов. То есть у нас есть единая среда автоматизации. И если ты умеешь писать под Linux, то сможешь и под Windows.
• Достаточно декларативный язык. Мы указываем, что хотим получить на выходе, и Ansible своим движком выдаёт результат.
• Ansible позволяет хранить всю инвентаризацию серверов и стендов (а только в нашей системе их порядка десяти, плюс различные настройки приложения для разных стендов).
• Огромное количество модулей для работы с различными фреймворками, программным обеспечением и железом.
• Есть полная поддержка Redhat.

Тем, у кого планируется большой объём автоматизации на Ansible или других скриптах и требуется комплексное управление всем этим процессом, стоит посмотреть в сторону opensource проектов AWX или Rundeck.

Как настроить деплой приложения

Подготовить серверы

Сперва открываем сетевые проходы от Linux-агентов в TeamCity до управляемых серверов. Это порты 5985/tcp, 5986/tcp для Windows и 23/tcp в Linux для SSH.

Затем добавляем учётную запись, под которой мы будем подключаться и управлять конечными серверами в локальную группу Администраторы. Включаем службу WinRM — настройки по умолчанию будет достаточно — и аутентификацию CredSSP (другие виды аутентификации либо сложно настроить в компании, либо вовсе нельзя).

После остаётся только подготовить инструменты для работы с самим Ansible. Я использую Git, VS Code и набор плагинов: GitLens, Redhat Ansible, Redhat XML и Prettier — Code formatter.

Создать репозиторий для деплоя

В Bitbucket создаём отдельный репозиторий, где будем хранить всё, что связано с деплоем на Ansible. Это нужно, чтобы отделить скрипты деплоя от репозитория проекта системы, тем самым ограничив права доступа к ним. Доступ должен быть только у DevOps-инженеров и прикладных администраторов. Мало ли кто случайно поправит конфиг-файл для продуктивного сервера — и после деплоя получим неработающее приложение.

Подготовить билд конфигурации в TeamCity для запуска Ansible

Сначала готовим отдельную build configuration (далее — билд), которая собирает Ansible плейбуки для конкретной задачи. Этот билд подключается в build chain общего процесса деплоя, после того как все артефакты прошли проверки ИБ и загружены в хранилище Nexus.

Это позволяет параллельно использовать билд Ansible для разных веток проекта.

Допустим, в проекте требуется создать новый Windows-сервис. Разработчики создают отдельную ветку для этой задачи и разрабатывают сервис. Но нам надо уже готовить деплой для будущего сервиса: установить сервис, настроить файлы конфигурации. Чтобы ничего не ломать в текущем деплое, в Ansible-проекте создаём ветку с аналогичным названием под разработку этой новой фичи и тестируем их параллельно.

После того как сервис будет готов и протестирован вместе с нашим изменённым деплоем, делаем Pull Request в master-ветку Ansible. И получаем master-деплой, уже скорректированный под новый сервис.

Как деплоить базу данных Oracle

1. Разработчики готовят изменения в БД в виде SQL-запросов и помещают в changeset Liquibase, которые применяются в процессе обновления.
2. Liquibase артефакты проходят проверку синтаксиса и проверку на безопасность, после чего загружаются в Nexus.
3. Ansible в виде плейбука запускает процесс применения миграций.
4. После обновления БД, Ansible проверяет логи Liquibase, была ли успешной миграция. Если всё хорошо, он переходит к следующей схеме, если нет — выводит сообщение об ошибке.

Liquibase можно запускать напрямую из агентов TeamCity, в виде команды liquibase —changelog-file=master.changelog.xml update-sql, но мы поместили его запуск в Ansible, чтобы весь процесс деплоя был в плейбуке и не хранился в билдах TeamCity.

Зелёным цветом подсвечиваем успешные выполнения задач, а красным то что выполняется с ошибкой.

Иногда миграция БД завершается ошибкой, чаще всего из-за неверных SQL-скриптов. Такие ошибки передаются специалисту, который занимался их разработкой.

Почему Liquibase

В нашем проекте, в БД хранятся не только данные, но логика приложения (да-да, так тоже бывает, когда приложению более 10 лет).

И так как у нас есть множество стендов (Dev/Test/Prod и другие), то нужно контролировать процесс миграции схемы базы данных. Запускать файлы с SQL-скриптами для можно, но процесс требует человеческого контроля. А где человек — там потенциальные ошибки: не доглядел, забыл, не проверил. В итоге через какое то время БД на разных стендах будет отличаться. Поэтому для управления процессом миграции схем мы используем Liquibase. Кроме того, он:

• позволяет хранить все изменения, которые мы вносим в базу данных в виде кода;
• позволяет делать ревью миграции;
• лучше контролирует процесс изменения схемы БД;
• разрешён к использованию внутри компании.

Деплой бэкенда и фронтенда приложения

Ansible из коробки управляет файлами и фаерволом, создаёт сайты и пулы приложений в IIS, настраивает порты, привязывает SSL-сертификаты и многое другое.

Это ускоряет создание деплоя. Мы можем взять пустой сервер с ОС Windows, запустить установку фронтенда или бэкенда и Ansible настроит всё за нас:

проверит папку приложения и SSL-сертификат;

• загрузит файлы приложения из Nexus и скопирует на сервер в нужную папку;
• настроит пул приложений и сайт и привяжет порты и SSL-сертификата;
• настроит XML-файлы конфигурации приложения — об этом подробнее ниже;
• настроит аутентификацию для приложения;
• проверит, что все всё запущено и работает;
• настроит сервис Windows.

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

Кстати, мы используем и сокращённую версию деплоя, которая пропускает половину задач: останавливает сервис, обновляет файлы и конфигурацию и запускает сервис в работу. Делается это при выполнения плейбука Ansible с помощью тэгов. Такой подход ускоряет деплой примерно на 30%, используется при разворачивании фич на тестирование.

Отдельное внимание стоит обратить на файлы конфигураций

В .NET Framework 4.8 и ниже конфигурация приложения хранится в XML-файлах  web.config или app.config (далее — конфиг-файл). Из-за этого возникают проблемы:

• надо заботиться об информационной безопасности — то есть в файлах конфигураций не должно быть паролей, токенов и всего что запрещено регламентами ИБ;
• при автоматизации деплоя, нужно оставить возможность откатиться на предыдущую версию;
• кто-то из сотрудников может случайно изменить конфигурацию при коммите; и приложение может перестать работать
• сложно динамически переопределить некоторые параметры конфигурации для стендов.

В .NET версий, 5.0 и выше всё чуть проще: можно хранить конфиги внутри проекта с переопределением для конкретных стендов, а также использовать app secrets и dotnet_environment. В другом проекте, мы уже используем именной такой подход.

Есть два варианта решения.

Использовать механизм трансформации конфиг-файлов msbuild

Мы делаем несколько конфиг-файлов под разные стенды или серверы. И в момент сборки, указываем в Configuration Manager, для какой среды собираем проект: Test, Dev или Prod. Затем msbuild через схему XDT меняет конфиг и помещает его в папку с остальными артефактами приложения

У такого подхода есть несколько минусов:

• все настройки и схема изменения хранятся внутри проекта;
• конфиг собирается в момент сборки, хранится в артефактах приложения и уже в готовом виде попадает на стенд в процессе деплоя;
• изменениями конфиг-файлов занимаются разработчики;
• хранение паролей в открытом виде в Git и артефактах.

Да, есть механизм шифрования секций конфигурационных файлов. Но он не снимает проблемы с хранением в  Git — и достаточно сложный в эксплуатации. Лучше доработать приложение, чтобы оно взаимодействовало с ПО HashiCorp Vault или Cyberark.

Шаблонизировать конфиг-файлы в Ansible

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

В Ansible хранится файл вида app.config.xdt.j2, в котором хранится шаблонизированная схема XDT для модификации эталонного файла. Звучит странно, но это самый гибкий, безопасный и удобный в эксплуатации способ.

Первичные затраты времени на подготовку таких xdt.j2-файлов, сводятся к сравнению эталонного конфиг-файла с тем что есть на стенде. С этим помогает утилита FatAntelope, которая сравнивает файлы и готовит XDT-схему для модификации. Схему мы помещаем в Jinja-файл и шаблонизируем конкретные параметры.

То есть в процессе деплоя приложения мы делаем следующее:

1. формируем схему: xdt.j2 -> XDT-схема;
2. применяем её к эталонному конфигу: Git config + XDTсхема
3. gолучаем .config-файл для стенда

Минусы:

• тратится время на модификацию xdt.j2-файлов

И пара лайфхаков

Ускоряем Ansible

Когда мы использовали PowerShell для деплоя приложения, запуск скрипта и обновление файлов занимали 20–30 секунд. Но плейбуки на Ansible занимали по 1–2 минуты. Мы начали искать способы ускорить работу.

Сперва оптимизировали запуск самого PowerShell. В чём суть? Библиотеки, связанные с PowerShell, лежат не в машинных кодах, а выполняют JIT-компиляцию каждый раз в момент запуска PowerShell. Это тормозит запуск любого скрипта Ansible.

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

Так, выполнение плейбуков на Windows ускорится на 20–30%.

Затем мы выяснили, что в Ansible начиная с версии 2.7 добавлена поддержка протокола PSRP. Это ускоряет работу плейбуков ещё на 30%. Из минусов — протокол не так просто включить в нашем случае, так как нужно скачать несколько пакетов и установить их на агентах в TeamCity, где используется Ansible. Для большинства же, всё просто: pip install pypsrp.

Третий способ — установить OpenSSH 8-й версии на Windows Server и подключаться к нему по SSН-протоколу, а не WinRM. Это тоже ускорит работу, но фактические замеры мы не делали.

Добавляем статистику

В Teamcity логи Ansible красиво подсвечены, и в конце есть статистика скорости выполнения плейбука и конкретных задач. Это включается добавлением в корень проект деплоя Ansbile конфига anisible.cfg.

Линтинг скриптов Ansible

Мы достаточно много времени тратим на разработку деплоя. И хорошо бы перед его запуском проверять общее качество кода, синтаксические ошибки. Для этого используйте линтер Anisble, который установлен на агентах TeamCity.

Нужно установить триггер в TeamCity на появление нового коммита или Pull Request в проекте деплоя. И после автоматом проверяете код на потенциальные ошибки.

Тестируем деплой

Обычно стенды Dev/Test/Prod отличаются друг от друга. На Dev стенде всё устанавливается на одном сервере, а в продуктиве всё разнесено по разным серверам и используется балансировка.

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

Самое простое — запускать его на стенды. Но если это не получается сделать, например, они все заняты тестировщиками и разработчиками, можно добавить параметр —check во время запуска плейбука. Тогда плейбук отработает всю логику, но без фактического применения на сервере, и вы убедитесь, что всё работает корректно. Для удобства можно сделать кнопку «Тестовый запуск».

Важно! Не все модули корректно работают в режиме –check. Если вы сначала загружаете файл артефакта, а потом распаковываете его, даже при тестовом запуске он будет реально искать файл для распаковки. А не найдя его выдаст ошибку. Решается это с помощью параметра check_mode: no.

На этом всё, если будут вопросы пишите. А если что-то заинтересует, расскажем подробнее.

Сергей Сикорский, старший разработчик компании Axenix, рассказывает, как это работает на примере обработки дата-сетов и их слияния в единый набор данных.

Полный код примеров ниже выложили на GitHub.

Исходные условия

Apache Spark — популярный open-source фреймворк для распределённой обработки неструктурированных и слабоструктурированных данных. Он реализован в парадигме in-memory вычислений, то есть обрабатывает данные в оперативной памяти для ускоренного выполнения некоторых классов задач, в частности машинного обучения.

Фреймворк поддерживает работу на Java, R, Python и Scala.

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

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

Инструменты оркестрации, такие как Airflow, дают возможность управлять на высоком уровне процессом запуска Spark-решения и отслеживать его выполнение, но не управляют самим процессом на микроуровне.

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

Изложенное является компиляцией опыта автора в области анализа методов повышения производительности решений на Spark Framework в версиях выше 2.2.0.

Постановка задачи и очевидное решение

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

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

Логически решение состоит из следующих последовательно выполняемых функций:

• processGenres – выполняет подготовку данных по жанрам для фильмов;
• processRatings – выполняет вычисление средней пользовательской оценки для фильма;
• processStatistics – выполняет формирование результирующего набора данных.

Код запуска последовательного вычисления

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

Логика обработки данных инкапуслирована в классе Common. Методы класса Common такие как processGenres и processRatings принимают на вход пути к целевым источникам данных и пути для сохранения результата их преобразования, а также возвращают в качестве результата объект Spark DataFrame результата вычисления.

Метод ProcessStatistics принимает на вход два DataFrame объекта и путь к результирующему набору данных. А класс ArgProperties представляет собой модель параметров командной строки.

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

Решение с использованием параллельно выполняемых заданий

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

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

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

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

Приведём фрагмент кода из решения, использующий асинхронный запуск заданий на Scala:

Код запуска решения с асинхронно запускаемыми заданиями

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

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

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

Также определяется пул потоков ExecutionContext ограничивающий количество одновременно выполняемых асинхронных операция, в данном случае размерность пула 2.

Как видно на шкале выполнения, теперь задания запускаются асинхронно (задание 1 и задание 2), что ускоряет процесс обработки данных. Запуск происходит с некоторой задержкой, но выполнение происходит параллельно, что видно на рисунки 4.

Конечно, можно было бы решить данную задачу и через стандартные объекты Thread/Runnable предоставляемые платформой Java. Но тогда пришлось бы дополнительно описать логику сохранения промежуточных данных во внешнюю коллекцию, что делает код менее лаконичным и более объёмным.

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

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

Однако есть некоторые особенности такого подхода к работе приложения:

1. По умолчанию все задачи запускаются в FIFO-очереди. Это значит, что первая задача получит максимум требуемых ресурсов. В таком случае нам необходимо указать очередь как FAIR, что обеспечит нас справедливым распределением ресурсов (подробности описаны в официальной документации по Spark).
2. Количество выделяемых ресурсов должно быть достаточно для параллельного выполнения задач на кластере. Мы бы могли выделять их динамически, но в таком случае будут получены издержки по времени на выделение и высвобождение необходимого числа исполнителей на кластере. Потребуется точнее рассчитать суммарно достаточное количество ядер и исполнителей для обработки данных, а также настроить буфер и время ожидания обмена данными в случае высоких нагрузок.
3. Несмотря на то что Python поддерживает потоки, разработчики Spark Framework не гарантируют запуск каждого задания в соответствующем потоке JVM и для реализация аналогичной функциональность рекомендуют использовать pyspark.InheritableThread.

Стоит также отметить, что согласно документации, любые действия (чтение, запись) могут быть запущено параллельно. Также это относится к механизмам кеширования данных (cache/persist) и к механизмам создания контрольных точек данных при пакетной обработке (checkpoint).

Вывод

Поддержка Framework Spark запуска параллельно выполняемых заданий, даёт дополнительные возможности в микроуправлении обработки данных.

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

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

Сама же реализация не является особо трудоёмкой и требует лишь учёта дополнительных накладных расходов на работу приложения.

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

1. Специализации и задачи IT-архитектора
2. С какими областями знаний работает IT-архитектор
3. Что должен знать архитектор ПО
4. Софт-скилы ИТ-архитектора
5. Опыт — это проработка гипотез

Специализации и задачи IT-архитектора

В IT-архитектуре много направлений: enterprise, solution, system, data-архитектура. У каждой специализации свои особенности, которые в том числе зависят и от стека конкретной компании. Поэтому не так просто собрать универсальный пул навыков и технологий, подходящий любому IT-архитектору.

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

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

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

Технический архитектор заведует артефактами развёртывания решений. Он знает, какое ПО использовать для быстрой записи огромных объёмов ненормализованных данных и как их качественно нормализовать. Как правило, для этого он пользуется целыми наборами типовых шаблонных развёртываний разнообразных систем.

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

Что почитать: блог Мартина Фаулера про архитектуру ПО

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

С какими областями знаний работает IT-архитектор

Чтобы грамотно выстраивать проект, ИТ-архитектор в банке должен понимать, как устроены эти области знаний:

1. Реализация бэкенда. Где хранить данные, как к ним обеспечить доступ.
2. Реализация фронтенда. Работа с клиентом, интернетом, каналами.
3. Интеграционная архитектура. Возможности интеграции, как обеспечивать взаимодействие между системами, не положив ни одну из них.
4. Безопасная архитектура. Как правильно обеспечить взаимодействие клиентов, быстро проводить идентификацию, авторизацию клиента.
5. Использование MDM. Это системы, которые будут хранить мастер-данные по необходимым для проекта сущностям (данные клиентов, продуктов и т. д.).
6. Реализация справочников. Важно правильно распространять по своим сервисам справочную информацию.
7. Монолитная, сервисная и микросервисная архитектуры. Как они устроены, в чём разница, плюсы и минусы подходов.

Что должен знать архитектор ПО

Архитектурный фреймворк TOGAF

Важно понимать, как строится архитектура предприятий. Мы пользуемся фреймворком TOGAF: проект прорабатывается с точки зрения бизнес-требований, технологического стека, архитектуры данных. Эта методология позволяет реализовать устойчивую и высокопроизводительную систему.

Примечание 1Если при выходе из строя n-компонента система продолжает полноценно функционировать, то её можно считать устойчивой. N — величина динамическая и может изменяться в зависимости от критичности систем.

Примечание 2Если при увеличении нагрузки система так же качественно отрабатывает запросы, то её можно считать высокопроизводительной. Для банков этот параметр очень важен, ведь предусмотреть действия клиентов возможно далеко не всегда.

Бизнес-требования

IT-архитектор должен разработать технический сценарий реализации бизнес-задачи.

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

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

Важный момент, IT-архитектор также должен проанализировать и определить потенциальные изменения, чтобы при интеграции новой системы с другими системами не произошло сбоя. Нужно уточнять у бизнеса: «Если изменятся, например, фамилия клиента или поле в паспорте, это критично?». Если да, то всё заносится в бизнес-требования.

Техническая проработка

После того как все бизнес-требования утверждены, IT-архитектор начинает проектировать схемы, чтобы «посадить» задачу на стек проекта.

ИТ-архитектор указывает, какие технологии, фреймворки используются в задаче, на чём написано приложение. Мы в Газпромбанке пишем на Java. Но бывают коробочные решения, которые требуют дополнительного внимания. Например, сервис на REST придётся серьёзно переписывать, чтобы вызывать SOAP.

Подробнее о Java и необходимых навыках можно почитать в кратком руководстве для начинающих или изучить в базовой дорожной карте языка.

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

Также важно понимать, какие данные передаются в этом потоке: только общедоступная информация или ещё и персональная. Если уровень критичности этих данных высок, то нужно принять дополнительные меры по их сохранности, например, выстраивание DMZ (более защищённых зон) для работы с ними.

Архитектура данных

Архитектор расписывает, как двигаются сущности, например: откуда берутся данные клиента и где прихраниваются, используются ли они только для передачи совместно с другими данными, изменяются ли при передаче, в каком месте сохраняются копии, где мастер-данные.

Базы данных

В начале 2000–х были две–три основных базы данных: Oracle, MySQL. Сейчас появляется множество новых реализаций: колоночные, документоориентированные, key-value БД. Их назначение примерно одинаковое — они хранят данные, но подходы к записи, чтению, масштабированию у них абсолютно разные.

Нужно понимать, какие существуют базы данных и какая между ними разница, что они позволяют делать, почему при использовании реляционных БД не всегда можно достичь большего профита. Например, если нет потребности в ACID (Atomicity, Consistency, Isolation, Durability), то можно рассмотреть NOSQL БД. Это даст возможность записывать большие объёмы данных в БД, к тому же масштабировать хранилище будет проще, чем при использовании реляционной БД.

Что почитать по теме:Как разобраться в видах СУБД
NoSQL базы данных
Популярные реляционные базы данных

Интеграция

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

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

Кого почитать: Максим Смирнов о сценариях интеграции приложений

Паттерны проектирования

Event-driven архитектура

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

Материалы по теме:
Что такое EDA и как для её построения использовать KafkaЧто такое Kafka и как начать с ним работу

Domain-driven design (DDD)

В этом случае все данные делятся на домены. Здесь нужно на ранней стадии спроектировать систему так, чтобы не допустить протекания доменов.

Подходы domain-driven design очень актуальны в больших компаниях. Если заранее не «нарезать» предметную область и не определить основные сущности этих доменов, то со временем данные могут задублироваться в разных частях системы, и синхронная актуализация этих данных вызовет трудности.

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

GitHub про DDD: книги, видео, комьюнити, обучающие курсы.

Onion-архитектура

При проектировании системы за основу берётся независимый Core-уровень, на который накладывается второй, уже зависимый от первого. На второй уровень накладывается третий, который зависит от второго и так далее. При таком подходе верхний UI-слой не сможет управлять Core-уровнем или ходить напрямую в бэкенд, обходя сервисный слой.

Подход CQRS

CQRS (Command and Query Responsibility Segregation) — это парадигма, при которой операции записи отделены от операций чтения. Она необходима, когда нагрузка на чтение и запись данных распределена несимметрично. Например, когда большая часть бизнес-логики и сложных проверок приходятся на write-систему, а чтение данных происходит чаще, чем вставка изменений.

Также почитайте о плюсах и минусах паттерна CQRS.

Инструменты визуализации решений

• Бизнес-вижн прописывается с помощью BPMN-подходов моделирования.
• Для построения архитектурных схем можно использовать UML или Archimate нотации. Мы используем Visio, либо аналог Visio (draw.io).

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

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

Софт-скилы ИТ-архитектора

IT-архитектор выступает посредником между бизнесом и техническими специалистами. Поэтому важный софт-скил архитектора — быть переговорщиком. Он должен договариваться, находить компромиссы, аргументировано объяснять бизнесу технические сложности реализации проекта, чтобы ставить адекватные сроки выполнения.

При этом также важны умение работать в команде и лидерские качества. Нужно доносить важность проекта до разработчиков: уметь мотивировать, находить к ним подходы, объяснять важность задач и правильно ставить их приоритетность.

Нужно развивать критическое мышление. В этом помогает концепция helicopter view: быть больше своих задач, смотреть выше. Это даёт более объёмную картину устройства проекта. Нужно анализировать, какой у задач бизнес-эффект, какой эффект будет при интеграции с другими сервисами продукта. Чем выше ты смотришь, тем больше вопросов себе задаёшь: действительно ли здесь нужно сделать именно так, или можно по-другому.

Опыт — это проработка гипотез

В профессии ИТ-архитектора всё очень индивидуально и зависит от решений, которых придерживаются в конкретной компании.

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

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

Кто такой архитектор

Очень просто понять на аналогии. Представьте поезд с большим количеством вагонов (больше сотни), который движется на высокой скорости. А ещё в нём периодически загораются вагоны. Так вот, архитектор — это человек с огнетушителем в руках, который знает, как всё внутри поезда устроено.

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

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

Какие знания требуются архитектору

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

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

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

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

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

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

Лишних знаний у архитекторов в принципе никогда не бывает. Потому важно расширять постоянно кругозор.

С каких специальностей чаще всего приходят в архитекторы

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

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

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

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

Какая перспектива у архитектуры

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

Какие книги можно посоветовать начинающим архитекторам

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

• Release It!. Design and Deploy production-ready software, Michael T.Nygard;
• Design It! From programmer to software architect, Michael Keeling;
• Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman;
• 37 Things One Architect Knows About IT Transformation: A Chief Architect’s Journey, Gregor Hohpe;
• Learning Domain-Driven Design, Vlad Khononov.

Способен ли архитектор создать Матрицу из одноимённого фильма

IT-архитектор — это человек, который как минимум может эту систему спроектировать. А как максимум создать.

У меня был кейс, когда мне пришлось на коленке написать большую систему для энтерпрайза. Заказчики говорили, что эту систему нужно разрабатывать три с половиной года. Я за несколько месяцев сделал документацию на 250 страниц с макетами. Да, они были далеко не с самым приятным UI/UX дизайном, но функциональные. Прописал всю логику, алгоритмы, реализовал их не на самом передовом стеке из подручных средств, но это работало.

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

Архитектор — это тот человек, который иногда спускается со своей башни из слоновой кости, чтобы подсказывать коллегам и развивать их. Это помогает членам команды становиться лучше и расширять горизонты.

Эксперты «Иннотех» — именно те ребята, которые активно делятся знаниями друг с другом и с командами, чтобы они работали более эффективно и продуктивно. Физических возможностей архитектора не хватит для того, чтобы он везде закрывал проблемные места, поэтому обмен информацией так важен. Ресурсы таких специалистов использовать надо крайне экономно и давать им передышку, потому что объём очень работы и знаний большой, иногда слишком.

Мы рассмотрим пять архитектур распределённых систем, их плюсы, минусы и области применения.

Что такое паттерн распределённой системы?

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

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

Паттерны распределённых систем описывают взаимодействие различных узлов системы и то, как они обрабатывают задачи и виды процессов для различных задач.

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

Типы паттернов распределённых систем

Большинство паттернов распределённых систем попадает в одну из трёх категорий, в зависимости от функциональности с которой они работают:

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

1. Разделение ответственности на команды и запросы (CQRS)

Этот паттерн предполагает разделение операций чтения и записи для увеличения масштабируемости и безопасности системы. Он использует команды для записи данных в постоянное хранилище (они ничего не возвращают) и запросы для обнаружения и получения данных (не могут изменять данные).

Команды и запросы обрабатываются центром управления, который получает запросы от пользователей. Затем центр получает данные и выполняет необходимые изменения, сохраняет их и уведомляет сервис выполняющий чтение. Этот сервис обновляет модель чтения и показывает изменения пользователю.

Плюсы:

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

Минусы:

• Требует постоянного взаимодействия между командами и запросами.
• Может увеличить задержку при отправке большого количества запросов.
• Нет средств связи между сервисными процессами.

Область применения

CQRS отлично подходит для приложений, интенсивно использующих данные, например систем управления базами данных SQL или NoSQL. Также паттерн используется для архитектур микросервисов с большим объемом данных. Он прекрасно подходит для приложений, сохраняющих состояние благодаря разделению на писателя и читателя.

2. Двухфазная фиксация (2PC)

2PC похож на CQRS использованием транзакций и центра управления, но здесь разделение производится на основании того, на какой стадии находится транзакция. Есть две фазы: фаза подготовки (в которой центр управления сообщает службам подготовить данные) и фаза фиксации (которая сигнализирует службе отправить подготовленные данные).

Все сервисы в 2PC по умолчанию заблокированы и не могут отправлять данные. После завершения подготовки координатор по одному разблокирует сервисы и запрашивает их данные. Если сервис не готов подтвердить данные, координатор переходит к другому сервису. Когда все подготовленные данные отправлены сервисы остаются разблокированными и ожидают задачи от координатора.

2PC гарантирует, что одновременно может работать только одна служба, что делает процесс более устойчивым и последовательным, чем CQRS.

Плюсы:

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

Минусы:

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

Область применения

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

3. Saga

Saga — это асинхронный паттерн не использующий центр управления. Сервисы здесь сами взаимодействуют между собой. Эта особенность позволяет избавиться от недостатков упомянутых выше паттернов.

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

Эта структура похожа на 2PC тем, что службы циклически запускаются, если кто-то не может выполнить задачу. Тем не менее, Saga не использует центр управления, чтобы лучше управлять потоком и уменьшить количество требуемой обратной связи.

Плюсы:

• Отдельные сервисы могут обрабатывать более долгие транзакции.
• Децентрализация отлично подходит для распределённых систем.
• Меньше узких мест благодаря одноранговой связи между службами.

Минусы:

• Асинхронная независимость делает трудным отслеживание сервисов выполняющих индивидуальные задачи.
• Сложный механизм управления затрудняет отладку.
• Меньшая изоляция сервисов, чем в предыдущих паттернах.

Область применения

Этот паттерн распределённой системы хорошо подходит для задач, которым требуется масштабируемая беcсерверная архитектура, способная обрабатывать много запросов одновременно. AWS использует подобные решения в AWS Step Functions и AWS Lambda, и других продуктах.

4. Реплицированные сервисы с распределением нагрузки (RLBS)

RLBS — это самый простой и часто используемый шаблон проектирования. На базовом уровне он состоит из нескольких идентичных сервисов, которые общаются с центральным распределителем. Каждый сервис способен выполнять задачи и перезапускать их в случае неудачи. Распределитель получает запросы от конечного пользователя и разделяет их между сервисами, используя round-robin или более сложный алгоритм.

Дублирующие службы обеспечивают высокую доступность приложения для запросов пользователей и могут перераспределять работу в случае сбоя одного экземпляра службы.

RLBS часто используется с Azure Kubernetes, которая представляет собой технологию оркестровки контейнеров с открытым исходным кодом, разработанную Microsoft, которая предлагает автоматическое масштабирование служб в зависимости от воркфлоу.

Плюсы:

• Стабильная производительность с точки зрения конечного пользователя.
• Быстрое восстановление после сбоев.
• Высокая масштабируемость через увеличение числа сервисов.
• Отличная многопоточность.

Минусы:

• Нестабильная производительность, зависящая от алгоритма балансировки.
• Управление сервисами требует много ресурсов.

Область применения

RLBS отлично подходит для систем, с которыми пользователи взаимодействуют напрямую. Нагрузка на эти системы в течение дня изменяется, поэтому требуется низкая задержка, например Netflix или Amazon Prime.

5. Шардинг

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

Шардинг сервисов обычно используется для создания сервисов с поддержкой состояния, потому что объём состояния часто слишком большой для одного stateless контейнера. Шардинг позволяет масштабировать отдельные элементы под размер состояния.

Шардинг также позволяет быстрее обрабатывать высокоприоритетные запросы. Сегменты, предназначенные для запросов с высоким приоритетом, всегда доступны для обработки таких запросов в момент их поступления и не требуют размещения запроса в очереди.

Плюсы:

• Возможность масштабировать сегменты для общих запросов.
• Легкая приоритизация запросов.
• Простая отладка, благодаря естественной сортировке.

Минусы:

• Поддержка большого числа сегментов может потребовать много ресурсов.
• Непропорциональное использование сегментов может привести к потерям производительности.

Область применения

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

Что дальше?

В статье были рассмотрены лишь несколько паттернов распределённых систем. Вот ещё несколько шаблонов проектирования для изучения:

• Sidecar паттерн;
• Упреждающая журнализация (Write-Ahead Log);
• Split-Brain паттерн;
• Направленная отправка (Hinted Handoff);
• Чтение с восстановлением (Read Repair).

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

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

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

Классический способ борьбы со сложностями — это разделение на составляющие. Если вести разработку всего приложения целиком сложно, нужно «распилить» его на части и разрабатывать отдельно.

Где подвох

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

Одно но: фронтенд всегда работает с единой средой, которая трудно отделима. Он выполняется на стороне браузера (клиента), поэтому в рамках одного приложения всегда есть только одна адресная строка, один глобальный объект localStorage, один DOM. Как бы мы ни делили приложение, некая общая часть всегда остается. Именно вокруг этой проблемы строятся основные ограничения микрофронтендов.

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

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

Если вы хотите перейти на микрофронтенд

В первую очередь, поймите, зачем это вам. Микрофронтенд нужен не всем. Да, это тренд, который сейчас активно обсуждается в комьюнити. Да, многие большие компании так или иначе придут к этой архитектуре. Но все это актуально в случае объемного приложения. Если сайт состоит из нескольких страниц, микрофронтенд теряет смысл. Это уже оверхэд. Смысл в делении монолита есть, если у вас крупный проект, несколько команд разработки, которые, возможно, используют разные фреймворки. Это, к слову, еще один плюс микрофронтенда: разные команды могут писать код на разных стеках. Кто-то пишет на React, кто-то — на Angular, но все объединяется в работе одного приложения.

Затем нужно понять, как именно можно поделить ваш монолит на относительно независимые для разработки блоки. Чаще всего отталкиваются от команд разработки. Обычно деление зон ответственности уже есть, просто оно не воплощено в архитектуре. Например, в Selectel основной продукт разработки фронтендеров — это Панель управления, где клиенты могут приобретать и использовать наши услуги. При этом в самой панели также есть деление на продукты компании и, как правило, у каждого продукта, будь то выделенные серверы, «Облачная платформа Selectel», Managed Kubernetes и т.д., есть свои фронтенд-специалисты. То есть они уже развивают только определенную часть панели.

Выберите инструменты, которые помогут вам построить микрофронтенд-архитектуру. Сейчас появляется все больше библиотек, инструментов, которые помогают разработчикам на пути к микрофронтендам. Например, такая библиотека, как single-spa, которая объединяет несколько javascript-приложений в одно. Или спецификация Realms, которая позволит на уровне нативного javascript упростить разработку микроcервисов на фронтенде.

Современные фреймворки типа Vue и Angular также имеют некоторые возможности, позволяющие писать свое приложение так, чтобы в результате его проще было интегрировать в микрофронтенды.

Опыт компаний

В целом, большинство крупных компаний так или иначе перейдут на микрофронтенд-архитектуру для своих приложений. Известно, что в России так работают в «Додо-пицце», Avito, «Тинькофф банке».

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

Наш путь к микрофронтендам начался во многом из-за переезда с AngularJS на Angular нашей Панели управления. Сейчас мы в процессе миграции и поддерживаем гибридную структуру фронтенда.

Как известно, есть несколько способов миграции из одного фреймворка в другой. Первый — более дорогой и долгий — подразумевает поддержание приложения на старом коде и параллельное его переписывание.

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

Как решать проблему общих ресурсов

Хорошим шагом к организации микрофронтендов может стать создание монорепозитория. Это git-репозиторий, внутри которого содержатся ваши npm-пакеты, зависящие друг от друга. Монорепозиторий поможет решить проблему с конфликтом версий библиотек и ведением разработки разными командами — все в одном месте, не нужно бегать по разным репозиториям и линковать пакеты.

При разработке Панели управления Selectel мы как раз используем монорепозиторий. Раньше у нас каждая услуга была отдельным git-репозиторием. В результате возникали сложности не только при локальной разработке, когда нужно было линковать пакеты, но и при обновлении библиотек и сборке в CI. Монорепозиторий решил практически все эти проблемы, причем на его создание ушло не так много времени. С точки зрения рабочих процессов монорепозитории облегчают организацию микрофронтендов.

Упомяну и очевидные вещи: не стоит исключать лучшие практики разработки (в том числе DRY, KISS, YAGNI) и простую коммуникацию — обмен опытом между фронтенд-разработчиками компании.

Выделим ключевое

Микрофронтенды — это деление монолитного приложения на семантически изолированные части и их независимая разработка.

Микрофронтенды имеют смысл, если:

1. У вас большое приложение.
2. Несколько команд разработки.
3. Вы все чаще сталкиваетесь с проблемами при выкате обновлений приложения.
4. Преимущества монолита обернулись в минусы.

Для остальных проектов микрофронтенды будут избыточны.

Ограничения микрофронтендов:

1. Остается проблема общих ресурсов. Полноценная изоляция, как в случае с микросервисной архитектурой в бэкенде, пока невозможна.
2. Требуется прослойка для оркестрации приложения, которая может вносить свой оверхэд.

Что поможет справиться с ограничениями:

1. Создание монорепозитория.
2. Использование специальных библиотек и инструментов.
3. Хорошая команда специалистов.
4. Использование лучших практик разработки (например, DRY, KISS, YAGNI).

В рамках статьи я расскажу об основных компонентах системы управления бизнес-процессами Camunda. Покажу развертывание системы, моделирование и деплой простого процесса. А также, на примере созданного процесса, проиллюстрирую взаимодействие Java/SpringBoot приложения с Camunda.

Давайте сначала разберемся с терминологией и выясним, что же такое BPM, BPMS и BPMN.

BPM (Business process management) — концепция управления организацией, рассматривающая бизнес-процессы как особые ресурсы предприятия, непрерывно адаптируемые к постоянным изменениям, и полагающаяся на такие принципы, как понятность и видимость бизнес-процессов в организации за счет их моделирования с использованием формальных нотаций, использования программного обеспечения моделирования, симуляции, мониторинга и анализа бизнес-процессов, возможность динамического перестроения моделей бизнес-процессов силами участников и средствами программных систем.

Другими словами, BPM отвечает на вопросы, где, когда, зачем, как и какая задача выполняется и кто отвечает за ее выполнение.

BPMS (Business Process Management System) – программное обеспечение, обеспечивающее прикладную реализацию концепции BPM.

BPMN (Business Process Modeling Notation) – нотация (система графических обозначений и их описание в формате XML) бизнес-процесса.

BPMS на рынке существует великое множество, включая лидеров рынка – Oracle или IBM. Из названия понятно, что эти системы очень мощные, сильные, дорогие и подходят далеко не каждой организации, а стоимость их внедрения может начинаться от 100.000 евро и выше. Понятно, что только крупные компании могут себе позволить внедрить такую систему.

1. На мой взгляд небольшим компаниям стоит обратить внимание на другие системы, внедрение которых обойдется в меньшие деньги. Например, российская компания ELMA запустила свой собственный продукт ELMA BPM, написанный на стеке .NET и имеющий бесплатную версию. Цена на Enterprise версию также вполне демократичная, кроме того, на сайте можно найти обучающие курсы и много другой полезной информации.
2. Из зарубежных вендоров с демократическими ценами или бесплатными версиями я бы выделил jBPM.
3. И еще одна бесплатная BPM система Аctivity, которую в 2013 году форкнули и из которой получилась известная многим Camunda BPM.

Компания Camunda Services, которая является вендором Camunda BPM, долгое время занималась консультированием организаций в области управления бизнес-процессами, но в результате создала свой продукт и начала активно его развивать.

В сети есть разные сравнения Аctivity и Camunda и, по большей части, они в пользу последней, да и список компаний, использующих камунду достаточно обширный: Deutsche Bank, Goldman Sachs Group, Тинькофф банк, Сбер, Теле 2 и т.д.

Мы все понимаем, что бизнес-процесс должен быть максимально понятным. Моделирование процессов происходит с применением нотаций (нотации — это система графических обозначений и их описание в формате XML). Нотаций существует довольно много, но самая популярная из них, конечно, текущая версия BPMN 2.0 (2.0.2 – 2014 г), которая постепенно развивается и пополняется новыми элементами.

Рассмотрим пример бизнес-процесса, описанном нотацией BPMN:

На картинке изображен процесс регистрации нового пользователя на портале, в достаточно упрощенном формате.

Здесь нарисован пул процесса и отдельными линиями – дорожки процесса. Каждая дорожка — это отдельная роль бизнес-процессов. Верхняя — это инициатор процессов, посередине – портал и внизу – ответственный за исполнение бизнес-процессов.

Зеленый кружок — стартовые события процессов, красные кружки – конечные события процессов.

Прямоугольник — задачи (=таски), которые исполняются во время жизненного цикла бизнес-процесса.

Задачи со значком шестеренок — сервисные задачи, которые не требуют участия оператора.

Задачи со значком человечка – это те задачи, которые требуют участия человека.

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

Что же такое Camunda BPM?

• Платформа управления бизнес-процессами, реализующая стандарты BPMN (Business Process Model and Notation), DMN (Decision Model and Notation) и CMMN (Case Management Model and Notation).
• Community версия имеет открытый исходный код, лицензия Apache-2.0.
• Основана на технологическом стеке популярного языка программирования Java. Имеет интеграцию с Spring/Spring Boot.

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

Компоненты CAMUNDA BPM (Community)

Давайте подробнее рассмотрим компоненты комьюнити версии Camunda:

1. Camunda Modeler – кросс-платформенное приложение с графическим интерфейсом, в котором бизнес-аналитик или архитектор процесса может моделировать и\или редактировать схемы процессов. Поддерживает нотации BPMN 2.0, DMN 1.1, CMMN 1.1. Это отдельное кросс-платформенное приложение с графическим интерфейсом, в котором бизнес-аналитик или архитектор процесса может составлять и\или редактировать схемы процессов.
2. Camunda Tasklist — веб-приложение, через которое конечные пользователи могут зайти, посмотреть какие задачи на у них назначены и выполнить какие-то действия.
3. Camunda Cockpit – веб-приложение, которое создано для операторов или владельцев бизнес-процессов, обеспечивающее мониторинг и управление бизнес-процессами
4. Camunda Admin – веб-приложение, интерфейс администратора системы, в котором идет управление ролями, пользователя, группами и т.д.
5. Центральная часть системы Camunda BPM – это движок, который управляет процессом в соответствии с нарисованными схемами и нотациями CMMN и тд, и преобразует их в код, а потом — исполняет.
6. Обратите внимание, что над движком существует надстройка, которая реализует REST или Java API. REST/Java API — программный интерфейс системы, обеспечивающий взаимодействие как с внешними (REST), так и внутренними (Java) компонентами. Rest API достаточно обширный, удобный и позволяет реализовывать всякие кастомные приложения. Например, там можно написать свой таск-лист, но подробнее мы рассмотрим эту возможность чуть позже.

Компоненты Camunda BPM (Enterprise)

Enterprise версия – платная, договор, тех поддержка 24\7 и в техническом плане она получше комьюнити версии. Например, появляются:

Enterprise Cockpit — расширенная версия Camunda Cockpit, содержащая в себе дополнительные функции: развертывание описаний процессов, перезапуск экземпляров процессов, расширенный поиск по экземплярам процессов, миграция экземпляров процессов между версиями.

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

Пример тепловой карты процесса

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

Способы развертывания Camunda BPM

Как я ранее писал, Camunda BPM написана на тех. стеке Java, поэтому у нее есть много способов развертывания.

Первый и самый простой – встроенная библиотека в приложении и именно его мы будем подробно разбирать.

Второй способ тоже подходит для Java приложений — сервис внутри сервера приложений или контейнера сервлетов («расшаренный» сервис), который могут использовать другие приложения, развернутые в контейнере.

Третий способ, если приложения написаны не на Java, развернуть Camunda как отдельно стоящий сервер и приложение будут с ним контактировать по Rest API удаленно.

Четвертый способ для высоконагруженных систем — кластерное развёртывание для высоконагруженных систем, когда есть общая база данных и несколько нод с камундой.

Практическая часть – пробуем Camunda своими руками

1. Заходим на https://start.camunda.com/.
2. Знакомимся с Initializr, который достаточно примитивный, но рабочий. В нем вводим — группу, артефакт, версию Сamunda, версию Java (она никак там не ограничивается, я пробовал java 135 — все нормально, проект сгенерировался). Хочу обратить ваше внимание, что другие языки программирования кроме Java, Scala, Kotlin, выбрать нельзя.
3. Скачиваем и открываем сгенерированный проект.

Внутри мы видим один класс Application — @SpringBootApplication, как я и писал ранее, камунда хорошо интегрируется со SpringBoot. А также в проекте есть файл с настройками приложения и файл с описанием процесса в формате BPM.

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

Но давайте немного усложним задачу и внесем изменения в процесс. Процесс мы сделаем процессом регистрации пользователя на портале, тот пример, о котором мы говорили в начале статьи и к которому обещал вернуться. Для этого нам нужно изменить стартовое событие и добавить туда переменную «username», которая добавляется через Camunda Modeler (кросс-платформенное решение, скачивается с официального сайта, бесплатное)

В результате у нас получилось модифицировать стартовое событие. Дальше необходимо модифицировать пользовательскую задачу, тут же добавляем форму с именем пользователя. Причем имя пользователя мы делаем «read only», чтобы тот человек, который будет утверждать создание нового пользователя не мог изменить его имя. А также добавляем переменную «decision», которая позволяет утвердить или отклонить эту регистрацию.

Запускаем экземпляр процесса. Для запуска экземпляра процесса заходим в приложение Camunda Tasklist (веб-приложение, через которое конечные пользователи могут зайти, посмотреть какие задачи на них назначены и выполнить какие-то действия) и нажимаем «Запустить процесс».

Находим свой демо процесс, который мы создали и видим форму запуска процесса.

После этого появляется окошко для ввода имени пользователя (переменная username), заполняем его и запускаем процесс.

Процесс запущен, и мы видим, что на пользователя Demo упала задача. Задача, как и ожидается называлась отклонить или утвердить регистрацию. Выделяем ее и видим форму, которую мы создавали. Также мы видим имя пользователя, которое нельзя редактировать, а решение – можно. Завершаем задачу, нажав кнопку «Complete» и на этом процесс завершается.

Давайте добавим немного экшена в процесс и усложним задачу – создадим ветвления.

Для этого добавляем к существующему процессу — шлюз, который будет «ветвить» этот алгоритм:

• Если decision равен true, тогда создать нового пользователя.
• Если decision равен false, то просто отправить уведомление о том, что пользователь не создан.

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

Выделяем модуль или сервисный таск и в нем прописываем implementation, выбирая способ Delegate Expression и добавляем в Delegate Expression собственное имя. Собственно этот бин нам и нужно создать в коде.

Для этого создаем класс CreateNewUser, помечаем его как компонент, чтобы спринг создал в контексте соответствующий бин, а этот класс должен имплементировать JavaDelegate.

В JavaDelegate есть метод execute, который и будет выполняться, когда поток выполнения придет в этот сервисный таск. На примере выше мы видим, что из переменной DelegateExecution можно вытащить переменную процесса, то есть username, которую мы вводили при старте процесса. Если все пройдет успешно, то в логе мы увидим сообщение, что пользователь успешно зарегистрирован.

Аналогично поступим в другим сервисным таском – отправить уведомление.

Также пропишем Delegate Expression, добавляем ему имя бина «notifyUser» и создаем соответствующий компонент, реализующий JavaDelegate в коде.

Внутри метода execute мы возьмем переменную decision, также через объект DelegateExecution, и в зависимости от этой переменной вы увидите разные сообщения:

• если decision равен true, то мы видим «, добро пожаловать на портал!»
• если decision равен false, то мы видим «, вам отказано в регистрации»

Вот этот способ через DelegateExecution работает только в случае с Java приложениями.

Возникает вопрос: а что делать, если приложение не на Java или если Camunda развернута на отдельном сервер?

В этом случае выбираете способ имплементации не Delegate Expression, а External и просто указываете какой-то топик, куда будет отправлен месседж и, соответственно, через очереди будет делегироваться выполнение в ваш код.

Последний шаг – запустить все то, что мы создали. Вводим имя

Видим таск «утвердить\отклонить регистрацию». Допустим, мы отклоняем регистрацию. Тогда не ставим галочку в поле «Утвердить?» и нажимаем «Complete».

После этого переходим в логи и видим, что пользователю Дарт Вейдер отказано в регистрации

Если мы принимаем регистрацию, то ставим галочку в поле «Утвердить?» и нажимаем «Complete». В этом случае процесс исполняется по другой ветке и в логах отображается по-другому.

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

Выше я описал самую простую схему процесса. В реальности же системы намного сложнее с множественными ветвлениями, а в эти диаграммы BPM можно вставлять другие таски, которые могут реализовать нотации DMN.

Camunda не позиционирует себя как low-code или no-code система. Camunda позиционирует себя как систему, где должно быть разумное сочетание, своеобразный симбиоз, между бизнесом, аналитиками и разработкой.

Полезные ссылки

• Быстрый старт
• Описание стандарта BPMN0
• Описание Rest API
• Практический курс BPMN0 от российской компании ELMA

С чего начинается приложение?

Авторы рассказывают о том, что приложение начинается с потребностей заказчика, кем бы он ни был представлен. Владелец банковской карты, геймер, врач, официант — у всех них есть боли и потребности. В книге объясняется, почему важно правильно собрать требования, как сильно это влияет на проектирование приложения и что будет, если этого не сделать (спойлер – ничего хорошего:). Изучать этот вопрос вы начнете с приложения для одного заказчика, владельца гитарного магазина, которому нужно сделать систему учета своих гитар, и ваша цель – помочь ему в этом. Когда решите эту задачку, перейдете к более сложным примерам, которые при этом вполне понятные и подробно описаны. Кстати, хочу обратить внимание на подачу материала: он простой, язык близок к разговорному, а еще в книге много иллюстраций и схем, и это здорово помогает восприятию. В некоторых упражнениях книгу предлагают использовать как рабочую тетрадь, что тоже удобно (если только вы не читаете ее в электронном виде).

Про требования и их изменчивость

Авторы «Объектно-ориентированного анализа и проектирования» идут вместе с читателем по всем этапам жизненного цикла – от сбора требований заказчиков до тестирования готового решения.

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

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

А где же разработка?

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

Кстати, о структурированном коде. В книге подробно изложены важные моменты:

• основные принципы ООП — даже начинающий программист слышал про инкапсуляцию, наследование и полиморфизм. Тут вы закрепите свои знания, и поймёте, что инкапсуляция — это не только про область видимости;
• принцип DRY — Don’t repeat yourself, он расскажет, как избежать повторения кода и инкапсулировать логику правильно;
• принцип KISS — keep it simple stupid, здесь пойдет речь о том, почему не стоит строить слишком гибкие приложения, пытаясь предвидеть требования;
• принцип YAGNI — You ain’t gonna need it, это история о том, как не писать лишний код, пытаясь играть в экстрасенса;
• паттерны проектирования — важная составляющая, которая поможет вам использовать мудрость других разработчиков (:

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

Послесловие

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

Но что точно пригодится каждому, — понимание, что программы не бывает без заказчика.

Когда студенты приходят в вуз, им не рассказывают, кто такой Software Architect, чем он занимается, и сколько ему платят. И это не удивительно, ведь потребность в архитектуре нарастала по мере увеличения сложности продуктов. Сегодня об этой профессии, зарплатах и условиях работы в разных странах расскажут три специалиста из компании Acronis, которые выполняют роли программных архитекторов в России, Сингапуре и США.

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

Кстати, архитекторы тоже бывают разными — в компаниях можно найти архитекторов решений, архитекторов систем, главных корпоративных архитекторов, архитекторов ПО, архитекторов БД. Каждый из этих титулов говорит о том, что специалист занимается выстраиванием процессов и взаимодействий в своей сфере на самом высоком уровне. Архитектор в любом случае должен иметь большой кругозор, так как он принимает сложные технические решения. Ему должен доверять бизнес, ведь часто в необходимости вкладываться в развитие архитектуры нужно убедить всех участников процесса.

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

Я не сразу стала архитектором: долгое время я вообще не представляла, что существует такое направление со своей объемной теоретической базой, сложившимися практиками и концепциями. Но когда я работала в компании Parallels на должности lead developer, в компанию пришел Майк Тотонги (Michael Toutonghi), который начал говорить об архитектуре ПО, как об отдельной дисциплине, я начала изучать материалы, знакомиться с концепциями и нарабатывать опыт. Оказалось, что многие вещи я уже делала как архитектор, но не знала правильных названий и была ограничена своим опытом и опытом коллег. Чтение литературы/лекции позволило расширить границы.

С 2018 года я начала работать в швейцарско-сингапурской компании Acronis именно как архитектор ПО, а точнее новой платформы, которую мы продолжаем развивать.

Обязанности

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

Зарплата и национальные особенности

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

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

Кому подходит быть архитектором

Быть программным архитектором — значит постоянно расширять свой кругозор, мыслить системно, а также находить компромиссы и уметь принимать чужую точку зрения. Архитектор не может быть приверженцем какой-то технологии. Он не будет навязывать свои личные технические предпочтения. Архитектор редко говорит «нет», потому что он уже слишком много видел и прекрасно знает, что практически в любом решении есть и плюсы, и минусы. Главная задача архитектора — проявить их и соотнести с целями компании. Software-архитектор должен быть гибким и ориентированным на поиск компромисса, но не «мутным». Важное качество архитектора — явно доносить все возможные последствия от каждого шага, и если принятое решение имеет много минусов, он должен убедиться что руководство понимает цену и сознательно идет на этот шаг.

Поэтому не все могут быть архитектором просто по складу личности. Я бы советовала почитать такую книгу, как «Software architecture in practice» от профессоров Carnegie-Mellon University. Если она покажется вам слишком дотошной, значит архитектура — не ваше призвание.

Как стать программным архитектором

Путь в системные архитекторы часто лежит через должность старшего разработчика, Чтобы совершить это рывок нужна прокачка Soft Skills и расширение своей экспертизы. Но существует и другой путь, и теперь на архитектора можно даже выучиться. Например, я веду курс программной архитектуры в университете «Иннополис». После такого обучения можно стать Junior Software Architect с уже «поставленным» критическим и системным мышлением, а реальный опыт накапливать уже в процессе работы.

Устроиться сразу после университета в хорошую компанию на должность Software Architect очень сложно, потому что на этой должности требуется большой опыт. Как и в случае с Software Engineer, QA или Product Manager, более опытный кандидат стоит дороже и, вероятно, будет решать поставленные задачи эффективнее. Сегодня я выполняю роль архитектора ПО в Acronis, находясь в американском офисе компании. И я уверен, что достичь этого мне помог именно предыдущий опыт.

Свой путь в сфере Software Engineering я начал больше 10 лет назад. На работу в компанию Acronis я пришел как Software Developer. После этого меня повысили до старшего разработчика, а после и до Team Lead’а. Сейчас я нахожусь на весьма необычной должности, которая совмещает в себе большую часть роли Software Architect и немного от программного менеджера.

Я бы сказал, что позицию Software Architect не стоит рассматривать как «вершину» пути разработчика. По пути Software Engineer можно достичь столь же высокой оплаты и быть ценным для компании. К тому же, любая должность (независимо от ее названия) — это всегда совмещение нескольких ролей, но  их баланс будет всегда различным. Software Architect это весьма сложная и интересная позиция, которая включает в себя много разных ролей.

Обязанности

Личной мой баланс задач на сегодняшний день состоит на 60% из задач выбора и внедрения архитектуры, и на 40% из анализа рынка, работы с другими продакт-менеджерами. Я трачу достаточно много времени на то, чтобы понять потребности рынка, а также транслировать требования к разработчикам на технический язык.

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

Зарплата и национальные особенности

Зарплата архитектора ПО в США так же, как и оплата других позиций в сфере software development, находится на достаточно высоком уровне. Несмотря на то, что зарплаты архитекторов в среднем выше, чем у разработчиков, зачастую сетки окладов пересекаются — все зависит от компаний и конкретных позиций. Я бы сказал, что стремиться к должности программного архитектора только из-за дохода не имеет смысла.

При этом поиск хорошего архитектора ПО для стартапа или небольшой компании может быть непростой задачей. Да, такие гиганты как Google или Microsoft собирают лучшие кадры с рынка, но остальным приходится искать специалиста с релевантным опытом. А это не всегда быстро и просто.

Кому подходит быть архитектором?

Архитектору ПО важно понимать базовые основы операционных систем и сетей, знать и владеть разными языками программирования, знать и уметь применять (или наоборот, уметь не применять) общепринятые подходы в программирование и проектировании. Как говорится, нужно быть в тренде всего технического. Это все то, что должен уметь и опытный разработчик.

Но если разработчик может себе позволить быть «узким» специалистом, то для архитектора это недопустимо. Архитектор должен уметь разбираться в любой технической проблеме, документировать и аргументировать любые решения, уметь выслушивать позиции других людей и помогать бизнесу достигать своих целей. Эта работа подходит для стрессоустойчивых и коммуникативных людей с широким спектром интересов и прокачанными Soft Skills.

Как стать архитектором ПО

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

Я работаю в отрасли уже 16 лет, и начинал как бэкенд-разработчик. Перед тем, как стать архитектором ПО, я побывал в разных компаниях на руководящих ролях, в том числе относящихся к R&D.

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

Обязанности

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

Зарплата и национальные особенности

У меня есть опыт работы в Индии и Сингапуре. До начала своей карьеры в Acronis я работал в таких крупных фирмах, как Veritas и Avaya. Практика показывает, что в Дели достаточно легко найти программного архитектора, так как на рынке труда достаточно квалифицированных кадров. Как следствие, в Индии зарплата программного архитектора не будет значительно отличаться от оплаты труда другого технического специалиста аналогичного уровня и квалификации. В Сингапуре «вилка» может быть более значительной.

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

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

Кому подойдет быть программным архитектором?

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

Архитектором может стать тот, кто тяготеет к разработке решений, а не просто приложений. Обычно программные архитекторы обладают опытом в области разных технологий: они знают про работу прокси, нюансы создания приложения, методы  защиты, особенности корпоративной шины (ESB) и так далее.

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

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

Как стать программным архитектором?

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

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

В качестве источника важных знаний я бы рекомендовал такие книги как Software Architecture in Practice и Designing Software Architectures: A Practical Approach. Кроме этого для самообразования будет полезна документация успешных облачных провайдеров. Лично я использую концепции AWS, чтобы узнать больше о новых подходах к архитектуре ПО.

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

Понятие Чистой архитектуры впервые Роберт Мартин (или, дядюшка Боб) опубликовал у себя в блоге ещё в 2012 году. В книге же, он подводит к этому понятию последовательно, в первую очередь развеивая миф о катастрофичности изменчивых требований. Чтобы сделать это, он вводит несколько важных понятий и определений.

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

Многие программисты полагают, что их задача заставлять компьютеры соответствовать требованиям и исправлять ошибки под отладчиком. Однако, на самом деле, программистов нанимают на работу, чтобы они заставили компьютеры экономить деньги или приносить прибыль. Это определяет поведение — одну из двух ценностей программы.

Но попробуйте ответить на вопрос: что лучше, программа, которая работает идеально, но её невозможно изменить при смене требований? Или же программа, которая не работает, но её легко поменять?

В книге даётся аргументированный ответ о том, что изменяемость программного обеспечения – его важнейшее свойство, которое исходит из самого определения английского слова Software: Soft — «гибкое / программное» + Ware — «обеспечение». Идея программного обеспечения состоит в том, чтобы дать простую возможность изменять поведение компьютеров. Это и делает ПО гибким. И это такое же требование, как и любые бизнес-требования, которые должны удовлетворить разработчики и архитекторы, создав соответствующую структуру (архитектуру) продукта.

Бизнес менеджеры не способны осознать важности архитектуры, потому что они «продают» поведение. По этой же причине они всегда ставят важность поведения на первое место и стараются повысить приоритет соответствующей работе. Автор же уверяет, что о важности качества архитектуры обязаны говорить разработчики, так, как только они наиболее полно представляют возможные негативные последствия того, что архитектуре не будет уделено достаточное внимание. Они должны бороться за неё. На самом деле им за это и платят.

Поэтому, эта вторая ценность (структура), сильнейшим образом влияет на дальнейшую судьбу проекта, хоть это сначала и трудно заметить.

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

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

Мне понравилось, что автор последователен и начинает как бы издалека: он рассуждает про все известные нам парадигмы программирования и то, что важного они привнесли с точки зрения архитектуры систем. Он детально объясняет понятия зависимостей в программе, потока данных программы, а также касается возможностей инверсии зависимостей (Dependency Injection) в программе. В итоге он делает вывод о том, что самое важное что привнесла парадигма ООП (объектно-ориентированное программирование) – это возможность полного контроля над направлением зависимостей между частями и компонентами программы.

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

• Принцип единственной ответственности (SRP).
• Принцип открытости/закрытости (OCP).
• Принцип Барбары Лисков (LSP).
• Принцип разделения интерфейса (ISP).
• Принцип инверсии зависимости (DIP).

Далее, автор подробно рассказывает про понятие компонент системы и рассказывает о трех принципах, на основе которых принимается решение к какому компоненту отнести тот или иной класс:

• Принцип эквивалентности повторного использования и выпусков (REP).
• Принцип согласованного изменения (CCP).
• Принцип совместного повторного использования (CRP).

Эти три принципа определяют так называемую связность компонент (Component Cohesion). И следуя логике, дядюшка Боб описывает сочетаемость компонент (Component Coupling), рассказывая о трех принципах, определяющих правила взаимоотношений между компонентами:

• Принцип ацикличности зависимостей (Acyclic Dependencies Principle).
• Принцип устойчивых зависимостей (Stable Dependencies Principle).
• Принцип устойчивости абстракций (Stable Abstractions Principle).

Знакомство с этими принципами подкрепляется практическими рекомендациями о метриках, которые можно высчитать и которые можно контролировать в системе.

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

По словам автора, для успешного существования и развития проекта, хорошая архитектура должна обеспечивать:

• разнообразие вариантов использования (use cases);
• эффективную работу системы;
• простоту разработки системы;
• простоту развертывания системы.

Достичь баланса во всём крайне сложно, но одним из важнейших шагов обеспечения баланса этих требований является правильное разделение системы на компоненты, а точнее – правильное проведение границ.

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

Кстати, непонимание принципа SRP является одним из наиболее часто встречаемых на собеседованиях и интервью кандидатов: ведь важно не столько то, что класс имеет одну область ответственности, сколько то, что класс будут меняться по одной причине.

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

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

Разделение на уровни и варианты использования даёт возможности как добавления новых вариантов использования системы, так и возможности независимой разработки и развёртывания. Иначе говоря – делает архитектуру гибкой.

Роберт Мартин называет это Режимом разделения. В пример таких режимов он приводит сервис-ориентированную архитектуру (SOA), основанную на службах, а также плагинную архитектуру.

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

Что же происходит, когда границы компонент пересекаются? А ничего, это нормальный ход событий, когда, например клиент (высокоуровневый компонент) вызывает функцию сервера (низкоуровневого компонента). И совсем не спроста в начале книги подробнейше рассматриваются парадигмы программирования и каждый принцип проектирования: ведь вся хитрость создания правильных решений о пересечении границ между компонентами, заключается в управлении зависимостями.

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

Хочу отметить, что автор говорит о границах не только в коде и архитектуре, но и в бизнес-требованиях. Он пишет, что бизнес-требования состоят из сущностей, часто описываемых на языке UML, а также вариантов использования, неформально описываемых в виде входных и выходных бизнес-данных. И те и другие не должны описывать низкоуровневые аспекты системы, вроде UI или фреймворка.

В итоге, сводя всё вышеизложенное воедино, Роберт приводит пример Чистой архитектуры, по его словам, объединяющей лучшие стороны большинства известных архитектур, таких как гексагональная архитектура, Data-Context-Interaction архитектура, и Boundary-Control-Entity архитектура.

В дальнейших главах автор разбирает чистую архитектуру в деталях, описывая способы пересечения границ, например используя DTO (Data-Transfer Objects). Он описывает шлюзы к слою доступа к базам данных и преобразователи реляционных данных (ORM). Я отдельно отмечу подробно разобранные паттерны проектирование, такие как:

• View-Presenter;
• Façade (Фасад);
• Strategy (Стратегия);
• Service (Служба);
• CQRS;
• Main component (анти-паттерн «Главный компонент»).

Наконец, автор приводит примеры использования принципов Чистой архитектуры в решении нескольких конкретных задач, таких как построение игрового движка (Game Engine), сервиса заказа такси (Taxi Aggregator) и сервиса продажи видео. Он также описывает возможности применения чистой архитектуры во встраиваемом ПО и операционных системах, а также проектирование интерфейсов и API для тестирования.

На мой взгляд, книга покрывает важнейшие аспекты дизайна и проектирования программ. В ней нет обзора конкретных фреймворков или языков программирования, но она показывает на что нужно обращать особое внимание, как закладывать гибкость, выявлять нарушения и контролировать структуру проекта. Так или иначе, любой разработчик столкнётся с необходимостью знания описываемых в книге принципов, но чем раньше он это сделает, тем меньше ошибок он совершит. Именно поэтому я рекомендую прочтение этой книги каждому разработчику, независимо от его уровня – от Junior до Senior и Architect.

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

Цена ошибки здесь крайне высока. Уязвимости и сбои в ИТ-инфраструктуре крупных заказчиков могут привести к потере прибыли в миллиарды рублей, а в случае с нефтяными компаниями или производствами — и вовсе грозить экологической катастрофой. Системный архитектор — это важный человек, который предотвращает подобные сценарии еще на этапе планирования. Справиться с такой работой может только специалист с высоким уровнем квалификации.

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

Чем занимается системный архитектор

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

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

Где востребованы такие специалисты

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

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

Ключевые навыки системного архитектора

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

Помимо обширных знаний в ИТ, архитектор должен обладать рядом надпрофильных навыков или soft skills. В первую очередь — коммуникационных. Он должен грамотно формулировать свои мысли как письменно, так и устно. Ему предстоит много общаться заказчиками, вежливо, но настойчиво отстаивать свою точку зрения, ставить задачи и мотивировать команду. А в отдельных случаях — работать в связке с другими архитекторами.

Необходимо уметь планировать и проводить презентации, «продавать» свои идеи. Еще один важный навык — тайм-менеджмент, так как придется распоряжаться не только своим временем, но и грамотно распределять нагрузку внутри проектной команды.

Как стать системным архитектором

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

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

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

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

Как долго ждать карьерного роста

Темпы роста у всех очень разные. Случается, что молодые специалисты с большими амбициями, резво стартовав, перестают развиваться на середине пути. А бывает — ровно наоборот. Например, в Департаменте системной архитектуры Rubytech, которым я руковожу, есть сотрудница, которая поначалу не демонстрировала впечатляющих карьерных результатов, просто аккуратно выполняла свою работу. А недавно — попала на большой и сложный проект, проявила самостоятельность, приняла несколько грамотных управленческих решений, показала высокий профессионализм и после медленного разгона совершила качественный профессиональный скачок.

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

Что нужно знать и уметь на входе в профессию

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

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

Коротко о главном

• Системный архитектор — значимый специалист в структуре системного интегратора, без которого невозможно построить ни одну ИТ-инфраструктуру.
• Чтобы работать системным архитектором, необходимо иметь большой опыт и глубокие познания в ИТ.
• Помимо этого, важно обладать отличными коммуникативными навыками, уметь проводить презентации и руководить командой.
• До системного архитектора можно дорасти через позицию проектировщика, эксперта или инженера.
• Быстрый рост обычно происходит на самых сложных проектах.

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

Клиенту нужно было регулярно проводить электронную инвентаризацию оборудования, каждый отчет по такой инвентаризации содержал более 100k строк. Клиент видел лишь одну проблему — отчеты генерировались слишком долго (в районе 12 часов – 24 часа на каждый отчет). По мнению клиента, эта проблема вытекала из следующих факторов:

• Используется неподходящая СУБД. MongoDB не может в много данных и их обсчет. В результате этого, сложный анализ этих данных занимал слишком много времени и памяти.
• Выходной формат отчетов — excel (xlsx). Для этого использовались скрипты на Node.js, каждый из которых выдавал отчет в своем виде. При построении таких отчетов, оперативная память заполнялась (~8Гб) и любое обращение к базе данных —  MongoDB просто падало с ошибкой.

Задача: Поднять Hadoop кластер, настроить миграцию данных из БД Клиента и обработку этих данных средствами Hadoop.

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

Примечание На текущий момент, Hadoop имеет более дружелюбную инфраструктуру, благодаря docker и k8s.

При анализе необходимых действий для того, чтобы перенести все необходимые данные в Hadoop, мы выявили что мало того, что данные не имеют четкой структуры, так и в некоторых местах существенно различаются по типу и свойствам (спасибо Mongo за гипергибкость, которая попадает в руки не заботящихся о проектировании данных людей). Ну и в чем проблема, спросите вы. А проблема заключается в том, что Hadoop это SQL-based система. Т.е. все интерфейсы взаимодействия с данными идут через структурированный SQL. И у нас нет возможности мигрировать в эту систему данные без схемы, типов и прочего.

Для того чтобы нормально проработать схемы данных, потребовалось бы очень много времени. А клиенту нужно было как можно скорее. Поэтому на очередной сессии мозгового штурма, мы выделили какие есть проблемы на наш взгляд и придумали как можно их решить.

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

• Нет четкой схемы данных в БД. Это приводит к тому, что агрегации должны выполнять больше количество действий для расчета результата.
• В текущей БД свалка данных. При разработке системы, которая генерировала эти данные, формат меняли несколько раз, при этом сама БД никогда не очищалась. В результате чего, операции обсчета документов выполнялись даже над теми документами, которые не соответствуют нужной схеме.
• Часть логики по обработке данных было перенесено на сторону Node.js.
• Отчеты генерировались в памяти, и после полной генерации сохраняли это все в excel файл (естественно, когда данных много, оперативной памяти не хватает и вся система рушится).

А также придумали как эти проблемы решить.

• За архитектурную модель мы взяли принцип по которому работают все распределенные системы, в том числе Hadoop. (Есть один мастер и несколько агентов.)
• Мастер управляет нагрузкой и взаимодействием с внешним миром.
• Каждый из агентов выполняет свою задачу по обработке данных.
• Все данные нужно разделить на несколько взаимонезависимых scope, основываясь на локальности данных при их использовании, для того чтобы можно было максимально распараллеливать задачи по обработке этих данных.
• Каждый scope хранить в отдельной БД, для снижения нагрузки на БД.
• Использовать документоориентированную базу данных, чтобы упростить переход, но прописать вариации схем данных.
• Для отказоустойчивости и предотвращения потери данных, каждая БД должна быть представлена replica set как минимум на 3-х разных физических машинах.
• Мы понимали, что система будет большой и сложной для поддержки. Поэтому нам необходим был инструмент, который бы автоматизировал большинство действий с системой за нас.

Общую схему как выглядела система вы можете увидеть на следующем рисунке.

Изображение компании Dunice

Superhost и каждый хост это отдельная физическая машина, со своими ресурсами и настроенным Raid 0 (или Raid 5).

Superhost (он же мастер) состоит из:

• Основного сервиса (Main Web Server, MWS), который обрабатывает запросы от пользователей по специальным ендпоинтам, мониторит состояние всех хостов, запускает и мониторит состояние миграций данных из внешней БД. Извне, мы в любой момент можем увидеть статистику по использованию ресурсов и текущему состоянию системы.
• Metadata service — это сервис хранилище данных о состоянии кластера (какой scope на какой реплике, какой агент с этой репликой лучше работает, когда была последняя миграция для каждого scope и т.д.). Взаимодействовал с этим сервисов только MWS и CLI
• CLI — это терминальный интерфейс для развертывания и управлением кластером. Назван в честь самой системы.
• Планировщик задач. Этот сервис отвечал за запуск миграций в нужное время.

Каждый из host N состоит из:

• Один или несколько контейнеров с агент-сервисом на каждом хосте. Нужен, для того чтобы взаимодействовать с базами данных, выполнять миграцию, запускать агрегацию, в режиме потока строить отчет нужного формата и отправлять на MWS.
• Контейнер с базой данных, которая реплицирована на несколько хостов (min 3).
  В базе данных хранились мигрированные данные из основной БД клиента, но разбиты по scope на разные группы реплик. При инициации миграции, данные брались с некоторым условием, так чтобы в одной группе реплик были данные только для одного scope.
  Это позволило нам сократить нагрузку на обработку данных и увеличить скорость выдачи отчета. После окончания миграции, мы запускали процесс агрегации (предвычисления). Эта операция предназначена для того, чтобы посчитать все нужные данные для отчетов и положить их в отдельную таблицу. В итоге при построении отчета, мы просто берем данные с фильтрацией из этой таблицы-кеша (получается по сути индекс). Данное решение позволило нам генерировать отчеты на 30 колонок и 200к+ строк за пару минут.
  Когда приходило время новой миграции, мы таблицу с закешироваными данными переименовывали и работали с ней. После того как миграция окончилась и появилась таблица с новыми закешироваными данными, мы удаляли старую и работали с новыми данными.

А для того чтобы как то удобно говорить об этой системе, мы решили дать ей имя MoNoRe — по первым слогам ключевых технологий (Mongo, Node, Redis).

Принцип работы при миграции данных:

1. Посылаем запрос на адрес <superhost>/migration/<scopeId>/start
2. При первом обращении к MWS с запросом на миграцию будет выбран наименее нагруженный хост и на нем создается первый «data» контейнер с настройками репликации. После этого по этому же принципу будут выбрано некоторое количество хостов для создания «data» контейнеров в количестве указанном в файле inventory.ini как replicaCount. Как только все необходимые контейнеры будут готовы, система инициирует создание replicaSet, дожидается окончания этого процесса и возвращает MWS IP адреса всех участников.
3. MWS создает расписание на ежедневную миграцию для указанного scope
4. Записывает данные о репликах в Redis
5. Запрашивает наименее нагруженный «compute» и отправляет ему команду на запуск процесса миграции для указанной фирмы.
6. Агент, получив команду на миграцию соединяется с replicaSet, создает(если она отсутствует) новую базу и начинается процесс миграции.
7. Прогресс миграции периодически отправляется в MWS и сохраняется в Redis. В любой момент, извне, мы можем запросить состояние миграции нужного scope у MWS <superhost>/migration/<scopeId>/status.
8. Когда все данные успешно перенесены, на суперхост будет отправлено сообщение об успешном выполнении миграции.
9. Запускается механизм агрегации данных для построения будущих отчетов в коллекцию report_rows, при этом, если на данный момент такая коллекцию существует — она будет переименована в report_rows_cache, а запись будет осуществляться в новую report_rows.
10. Прогресс агрегации периодически отправляется в MWS и сохраняется в Redis. В любой момент, извне, мы можем запросить состояние агрегации нужного scope у MWS <superhost>/migration/<scopeId>/status.
11. Когда коллекция report_rows будет готова, на суперхост будет отправлено сообщение об успешном выполнении агрегации.
12. Записывает данные о времени последней миграции в Redis

При последующих запросах на миграцию суперхост берет всю необходимую информацию из Redis, запрашивает наименее нагруженный «compute» и отправляет ему команду на запуск процесса миграции для указанного scope.

Принцип работы при получении отчета:

1. Посылаем запрос на адрес <superhost>/report/<reportId>?additionalParams="
2. При первом обращении к MWS с запросом на миграцию будет выбран наименее нагруженный хост и на нем создается первый «data» контейнер с настройками репликации. После этого по этому же принципу будут выбрано некоторое количество хостов для создания «data» контейнеров в количестве указанном в файле inventory.ini как replicaCount. Как только все необходимые контейнеры будут готовы, система инициирует создание replicaSet, дожидается окончания этого процесса и возвращает MWS IP адреса всех участников.

Как видно из схемы для реализации нашей системы мы решили взять следующие инструменты:

1. Node.js (with express) — Использовался для создания HTTP(S) серверов MWS и CS
2. MongoDB (with replication) — Так как у команды клиента есть опыт работы с MongoDB, при этом она была достаточно мощной для обработки больших массивов данных за счет Agregation Pipeline, было принято решение ее и использовать как основное хранилище данных.
3. ПримечаниеLXD / LXC (Linux Containers) — Система виртуализации, реализующая концепт контейнеров. Использовался для добавления слоя абстракции между элементами системы и серверами на которых происходит разворачивание. В настоящее время имеет смысл использовать Docker + Docker Swarm)
4. SSH – Использовался как транспорт для управления между хостами
5. Node.js (with Yargs and Ora) — Использовался при построении CLI.
6. Cron(Linux) — выполнял роль планировщика задач.
7. PM2 — Использовался для повышения отказоустойчивости Node-Express сервисов.
8. Redis — Выполнял роль Metadata service.
9. Nginx — На master машине выполняет роль прокси сервера, для взаимосвязи с внешним миром. На каждом хосте выполняет роль прокси сервера для общения между MWS и агентом.

Развертывание и управление большой системой = боль?

Система на первый взгляд выглядит непросто. Мы понимали что управлять всем этим руками будет не удобно и будет вызывать много вопросов и проблем у заказчика. Чтобы руками развернуть такую систему необходимо очень четко понимать все ее модули, взаимодействие между ними и потратить пару часов. А это очень не устраивало нас как 0-пользователей системы.

Чтобы решить эту проблему, мы создали CLI c набором команд, позволяющий привести систему в рабочее состояние за 5 минут. Для этого необходимо просто заполнить inventory.ini (см. рис 2) файл с необходимыми данными и запустить команду monore setup. Система сама зайдет на все указанные хосты системы, развернет там необходимые модули, создаст нужные файлы с настройками(nginx, mongo и так далее) и переведет систему в рабочее состояние.

Изображение компании Dunice

Изображение компании Dunice

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

Это было тяжелое демо с нашей стороны, но все участники были довольны достигнутым, оставалось лишь одно НО…. Уровень отказоустойчивости который у нас был на текущий момент, оказался недостаточным для инициирования процесса приёма-передачи продукта. У нас появилось новое требование, нужно чтобы с системой могло произойти все что угодно (отключили от сети или вышло из строя железо хоста или супер хоста, временные проблемы с доступностью хоста), но система должна продолжать работу, и при этом нормально реагировать на возращении хоста (предотвращение коллизий и несогласованности данных).

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

Тот самый момент, когда грамотная архитектура решает проблемы за тебя

На самом деле, часть этих требований у нас уже были покрыты за счет правильно подобранной архитектуры и программных решений. Например, вопросом коллизий и согласованности данных полностью занималась MongoDB с настроенным Replica Set. А за счет того, что мы храним некоторые метаданные о кластере, потеря одного хоста вообще не является проблемой.

Однако для достижения поставленных целей этого недостаточно. Все еще могут быть проблемы, если откажет Superhost или больше половины host.

Решить эту проблему мы смогли с помощью более крупной кластеризации за счет LXD Cluster (теперь контейнеры на всех хостах находились как бы на одном хосте, видели друг друга и могли спокойно общаться, однако появилось требование, чтобы хосты (в том числе и суперхост) должны быть в одной подсети (16 или 24 ранга)), обновлении логики работы MWS (упростился механизм выборки и взаимодействия с агентами, появилась логика регенерации) и CLI (усложнилась логика разворачивания системы, однако упростился механизм сбора статистики с каждого модуля, появилась логика регенерации), и обновление количества и качества хранимых метаданных о системе.

Шаг с кластеризацией, помог нам более гибко управлять кластером из любого места кластера. Т.е. по факту, любой хост мог стать супер хостом.

Общий алгоритм работы:

• Если теряется связь с хостом, то админу отправляется оповещение со всей необходимой информацией о хосте. А так же, о том что в систему имеет смысл добавить еще хостов, для поддержания высокой отказоустойчивости. При добавлении нового хоста, через CLI, система в автоматическом режиме начинает его полноценное использование.
• Если выходит из строя суперхост, то устраивается кворум, и один из хостов становится суперхостом. Инициируется процесс регенерации. Устанавливается Redis, MWS, CLI. Происходит сбор информации о кластере (за счет того, что в каждой реплике БД есть минимальное количество метаданных о самой реплике, о данных которые в ней хранятся и о последней миграции). В итоге через примерно 30 секунд на кластере из 20 машин, система снова становится обрабатывать запросы извне. Так же отправляется письмо администратору, с информацией о произошедшем и результатом.

Изображение компании Dunice

Итогом данного проекта стало успешное внедрение сначала в тестовый контур, а в последствии и в продакшен. Итоговые характеристики системы при построении отчета:

1. Оперативная память не поднимается выше 500мб при формировании отчета ~200к строк из таблицы с > 1млн записей
2. Время получения отчета ~60 секунд (для ~200к строк).

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

Изначально, клиент был недоволен результатом, который получился у его команды. Мы же, взяли те же инструменты, добавили немного новых, правильно определили архитектуру и применили весь наш опыт в разработке Enterprise систем.

На дворе 2020 год, и весь Интернет только и делает, что обсуждает бесчисленные достоинства микросервисов. Истории успеха правдивы, микросервисы хороши для своих задач. Вот только, как и любая модная идея, они кажутся «серебряной пулей», решающей все проблемы на свете и подходящей для абсолютно любого проекта. Это не совсем так, и прежде чем дробить свой монолитный проект на микросервисы, надо задать себе несколько вопросов и убедиться, что они вам нужны.

У вас действительно огромный монолит?

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

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

Есть такой размер системы, выше которого микросервисы начинают окупаться. Если вы его ещё не прошли — они вам не нужны. Да, в будущем проект вырастет. Но хорошо спроектированный монолит можно будет раздробить тогда, когда (и если) это будет иметь смысл.

Вам действительно нужно масштабировать отдельные компоненты?

Допустим, нужно разработать систему кадрового учёта для организации на 10 000 человек. Поскольку микросервисы — это круто, архитектура будет примерно такой:

Пример несколько издевательский, но серьёзно: зачем нужно приложение для учёта зарплаты, отдельное от приложения для учёта сотрудников? Они всё равно будут работать на одних данных и расти параллельно друг другу.

Одно из достоинств микросервисов — в возможности масштабировать отдельные компоненты по мере необходимости. В принципе это полезно, но есть ли такая необходимость конкретно в вашем проекте?

Возникают ли транзакции, в которых участвует несколько сервисов?

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

REST-сервисы по определению не должны иметь внутреннего состояния, так что им лучше не вступать в сложные операции на несколько сервисов. В мире высокой нагрузки двухфазные коммиты (2PC) — ненужное зло, а паттерн SAGA только добавит сложности.

Часто ли данные передаются между сервисами?

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

Есть множество прекрасно работающих решений для обмена данными между микросервисами, но для сетевого соединения задержка неизбежно измеряется не в наносекундах, а в микросекундах. Если, например, три сервиса общаются друг с другом по сети, а каждый вызов занимает 100 мс (что для высоконагруженной системы вполне реально) — то треть секунды уходит на одну только передачу данных, безо всяких вычислений. Для систем, обрабатывающих данные в реальном времени, такие потери недопустимы. Просто представьте себе лаги в хирургическом роботе или софте авиадиспетчера!

Что ещё нужно учитывать?

• Дополнительная сложность. Да, вся идея микросервисов в том, что каждый из них в отдельности становится проще и понятнее. Но систему в целом сложнее деплоить и поддерживать.
• Дополнительная стоимость. Монолитная система может хоститься на единственной виртуальной машине или в контейнере, а микросервисы (в идеале) хостятся по отдельности. Да, виртуалки будут не такими большими, но их будет много, и скорее всего это будет дороже.
• DevOps. Это можно считать и за достоинство, и за недостаток, но с микросервисами вам однозначно понадобится DevOps-команда. С одной стороны — её в любом случае неплохо иметь, а с другой — она вам прямо сейчас по карману?
• Неизбежная связность. Некоторые задачи в вашем проекте наверняка плотно связаны друг с другом по своей природе (тот же учёт сотрудников и учёт зарплат, например). Любая попытка их разделить ради соответствия архитектуре скорее всего закончится печально.
• Неопытная команда. Это, конечно, проблема для любого проекта. Но в погоне за абстрактным идеалом «микросервисов» можно получить чудовищно плохую архитектуру. Когда сервисы перестанут работать, если их деплоить в неправильном порядке, или когда падение одного сервиса обрушит все остальные, будет уже слишком поздно.
• Сложность тестирования. Для монолита тесты обычно запускаются одной командой, а для тестирования набора взаимосвязанных сервисов нужна отдельная система.
• Совместимость данных. Согласование форматов данных в пределах одной команды — это совсем не то же самое, что согласование между несколькими командами, которые к тому же могут находиться на разных концах планеты и/или программировать на разных языках. На обсуждение спецификаций неизбежно потребуются дополнительные время и силы.
• Поддержка старого кода. Давайте честно: большинство систем не создаётся с нуля. Новая архитектура — это хорошо, но она усложняет взаимодействие с уже имеющимся кодом, и неплохо бы убедиться, что ваш новенький микросервисный фреймворк будет нормально работать с приложением, которое уже 20 лет как крутится на IBM AIX.
• Отладка и мониторинг. Отдельные системы — это в том числе и отдельные логи. Найти ошибку где-то в пяти раздельных лог-файлах сложнее, чем в одном.

Значит ли это, что не стоит пользоваться микросервисами? Нет. История Netflix вдохновила многих, и вполне заслуженно. Uber, SoundCloud и Amazon используют микросервисы и делают с их помощью вещи, которые раньше казались невозможными. Но это не означает, что микросервисы — идеальная архитектура, подходящая для всех проектов.

Многим программистам хочется использовать все крутые идеи, которые они увидели. Но тем и отличаются хорошие программисты, что они понимают разницу между «крутыми идеями» и «идеями, подходящими в данном конкретном случае».

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

Как развивалась функциональность сервиса

Ядро сервиса — это поисковый движок, который угадывает запрос по первым введённым символам, исправляя ошибки и предлагая наиболее актуальные подсказки. Поиск сопровождается виджетом, где отображаются продукты с изображениями, ценой, остатком на складе, рейтингом, а также релевантные поисковому запросу контентные страницы, категории и подсказки.

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

Архитектура

Главное в системе — это архитектура. В нашем случае — доработка архитектуры с целью повышения скорости.

Хостимся на 10 железных серверах. Используем виртуализацию KVM, создали свое маленькое облако, в котором у нас больше 50 виртуалок. На одном железе — примерно 6 серверов, каждый из которых отвечает за что-то своё: какой-то принимает запросы, какой-то только хранит статистику, отдельный сервер для админки, отдельный сервер для индексации. Больше всего поисковых серверов — 30, так как Sphinx для организации быстрого поиска требуется много памяти.

Когда клиент устанавливает модуль, он регистрируется на сервере и начинает отправлять данные для поиска. Все эти данные попадают в очередь, а из неё — в базы данных. После того как импорт данных закончен, команда на индексацию попадёт в очередь индексации. Обработчики очереди API у нас расположены на 10 серверах, а обработчики индексации — на 19 серверах.

Очереди сделаны очень необычно: мы реализовали их сами в Redis с помощью LUA скриптов и встроенных в Redis типов данных. Получилось хорошо: мы смогли часть логики переложить в очередь и получили очереди, которые распараллеливаются по нужным нам условиям. Ещё наши очереди умеют повторять ошибочные запросы только фиксированное число раз и при падении обработчика данные не теряются.

Для каждой регистрации создается своя база — на данный момент у нас их 10 000. Это нестандартное решение, у которого есть огромное преимущество — мы реально изолируем базы. Удалить базу гораздо проще, чем вычищать информацию из таблиц. Помимо этого, решается еще одна проблема: при добавлении или частой работе с обновлениями базы, индекс тормозит. Когда базы отделены, не возникает проблем с шардированием. Просто раскладываем определенное число баз на каждый сервер Mysql.

Приложение для Shopify написано на Erlang, который оказался очень быстр и удобен для задач параллельного программирования: с его помощью не проблема поддерживать тысячи магазинов, делая по несколько миллионов запросов к API. У Shopify очень развитое API, с которым можно делать практически всё. С помощью API мы сделали индексацию, следим за обновлениями, статусами магазинов и т.д. Приложение изолировано для того, чтобы соблюсти общую монолитную структуру и иметь единый API для всех платформ.

Со всех серверов собираем метрики с помощью Zabbix. Это очень удобно — в каждый момент знать что происходит с сервером и насколько он загружен. Также в Zabbix настроены триггеры на разные «внештатные» ситуации — если что-то пойдет не так, придёт уведомление в Slack и на почту.

Работа со Sphinx

Благодаря Sphinx и тому, что мы много времени потратили на оптимизацию, скорость поиска Searchanise во много раз выше конкурирующих предложений — мы легко поддерживаем 500 000 продуктов в поиске. И эта возможность дана Sphinx. Ежедневно мы обрабатываем 15 млн поисковых запросов.

Но мы знаем и о проблемах Sphinx, и многие уже научились обходить. Но осталась одна: Sphinx периодически падает и с этим пока ничего не получается поделать. Поэтому мы один индекс держим на двух серверах: если Sphinx упадёт на одном, второй будет обслуживать запросы.

Тестирование

Мы не используем unit-тестирование. Когда система быстро развивается, поддержка unit-тестов в актуальном состоянии сильно тормозит процесс разработки.

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

Виджеты

На некоторых платформах результаты поиска показываются в дизайне платформы. На других платформах (например Shopify) поиск отображается в JS-виджетах. Всё это управляется нашей встраиваемой админкой, которая тоже JS-виджет.

У нас огромное количество настроек для системы виджетов. Все настройки обновляются практически в режиме реального времени (в течение 10–20 секунд оказываются у клиента). У конкурентов иногда приходится ждать 10–15 минут.

Файлы виджетов мы храним на Amazon S3, но раздаем не напрямую, а используем CDN. Мы используем KeyCDN: недорого, хорошо работает, изменения быстро актуализируются, IP-адреса не заблокированы ни в одной стране.

Вывод

За счёт использования Sphinx мы построили сервис поиска для множества клиентов и обеспечили себестоимость практически в 10 раз ниже, чем у конкурентов. Но Sphinx из коробки очень неудобен. Неудобно его использовать со множеством индексов и организовать на его основе распределенный сервис. Нам пришлось преодолеть много трудностей и придумать много уникальных решений для налаживания процесса индексации, распараллеливания и faleover.

Качественный дизайн ПО — введение

В процессе работы над кодом программисты регулярно сталкиваются с тем, что качественный дизайн кода окупается впоследствии при усложнении продукта. Для создания полезного и легко поддерживаемого в долгосрочной перспективе ПО разработчики подбирают определённые шаблоны и объединяют их в абстракции, и похоже, что разработчики Linux и FFmpeg поступили именно так.

При разработке программ создаются структуры данных и определяются их зависимости и поведение. То, как они построены и связаны между собой, можно рассматривать как дизайн/архитектуру ПО.

Предположим, что мы разрабатываем фреймворк для обработки видео- и аудиофайлов. Кодеки AV1, H264, HEVC и AAC производят некоторые идентичные операции с данными, и если мы разработаем некоторую обобщённую абстракцию, включающую эти операции, мы сможем использовать эту абстракцию вместо того, чтобы реализовывать конкретную идею, заложенную в каждом отдельном кодеке.

Ещё один хороший приём — использовать слабо связанные компоненты, чётко определив их функции.

Ruby

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

Этот код на Ruby отражает одну из описанных выше концепций. Без конкретизации в коде предполагается, что каждый кодек реализует функции encode и decode. Поскольку Ruby — язык с динамической типизацией, любой класс может иметь реализацию этих двух операций и работать как кодек.

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

Фреймворк Ruby on Rails подталкивает к определённым способам организации кода, реализуя архитектуру «Модель-Представление-Контроллер» (MVC).

Go

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

Тип interface в Go намного мощнее аналогичной конструкции в Java, так как его определение никак не связано с реализацией, и наоборот. Можно даже присвоить каждому кодеку тип ReadWriter и использовать в таком виде.

С

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

Примечание Код создан по примеру размещённого на сайте Computer Science from the Bottom Up.

Сначала в обобщённой структуре мы определяем абстрактные операции (в данном случае функции). Затем мы наполняем их конкретным кодом, например кодером и декодером кодека av1.

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

Linux kernel и концепция «всё — файл»

Концепция «всё — файл» ОС Linux позволяет использовать один интерфейс для работы с любыми ресурсами системы. Например, Linux обрабатывает сетевые сокеты, особые файлы (такие как /proc/cpuinfo) и даже USB-устройства как файлы.

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

Это возможно только потому, что концепция файла (структуры данных и операции) была разработана как один из главных способов взаимодействия подсистем.  Вот участок API-структуры file_operations:

Эта структура чётко определяет то, что мы подразумеваем под концепцией файла, и какое поведение мы от него ожидаем:

Здесь можно увидеть набор функций, реализующих это поведение, в файловой системе ext4.

Даже файлы cpuinfo proc реализованы через эту абстракцию. Фактически, работая с файлами под Linux, вы используете виртуальную файловую систему (VFS), которая в свою очередь обращается к функциям абстракции.

FFmpeg — форматы

Вот общая схема архитектуры процессов FFmpeg, демонстрирующая, что внутренние компоненты связаны в основном через такие абстрактные концепции, как AVCodec, а не напрямую через конкретные кодеки.

Для входящих файлов в FFmpeg создаётся структура AVInputFormat, реализуемая любым форматом (видеоконтейнером), который требуется использовать. Файлы MKV также заполняют эту структуру своей реализацией, как и формат MP4 — своей.

Такой дизайн позволяет легко интегрировать новые кодеки, форматы и протоколы. В мае 2019 года в FFmpeg был включён кодек DAV1d (аналог av1 с открытым исходным кодом), и, изучив изменения в коде, вы увидите, насколько безболезненно прошло внедрение. В итоге ему только требуется зарегистрироваться в качестве доступного кодека и придерживаться списка общих операций.

Безотносительно используемого нами языка мы всегда можем как минимум попытаться создать код со слабой зависимостью и высокой согласованностью. Именно эти два основных свойства позволят вам писать ПО, которое легко расширять и поддерживать.