Нас, признаться, удивило, что наш предыдущий рассказ — тот самый «больнючий» опыт про СТО — так неожиданно бодро набирает просмотры. Мы решили, что стоит продолжить про кейсы с разными «граблями» (и «успешными успехами», куда без них), которые помогли нам научиться и кодить лучше, и процессы строить грамотнее. Берите на вооружение полезное и не повторяйте наших ошибок. Поехали.
Предыстория: непростая ситуация
Наш заказчик — Департамент труда и социальной защиты населения Москвы (ДТСЗН), масштабная и живая структура. Его портал обслуживал две совершенно разные вселенные:
- с одной стороны — миллионы москвичей, ищущих информацию о социальных услугах,
- с другой — сотрудники более 300 подведомственных учреждений, для которых портал служил ежедневным рабочим инструментом.
Проблема назревала постепенно. Одним из ключевых сервисов для горожан был «Социальный навигатор» — интерактивная карта, встроенная в основной портал. К 2021 году на карте было отмечено свыше 935 адресов по 225 различных услуг, а общее число обращений к нему перевалило за 1,3 миллиона. Мы понимали, что рост нагрузки — дело времени, но настоящий вызов пришел с другой стороны.
На портале кипела жизнь: релизы требовались в среднем раз в три дня, а срочные правки с дедлайном «еще вчера» — и того чаще. И вот руководство заказчика ставит задачу: срочно доработать «Социальный навигатор», добавив к нему крупную фичу А для презентации к несдвигаемой дате в Департаменте. Мы успевали, но был нюанс.
Параллельно в том же монолитном проекте мы уже вели разработку другой, не менее масштабной фичи — подсистемы отчетности для тех самых 300+ организаций (фича Б). Код естественным образом смешался в общей dev-среде.
Ожидаемо мы получили классическую патовую ситуацию — полностью готовая и протестированная фича А оказалась намертво заблокирована. Выкатить ее в прод нельзя, потому что вместе с ней улетели бы сырые, всё ломающие изменения из фичи Б.
Боль управления зависимостями
Чтобы было понятнее, в чем суть затыка (см. рис. 1), поясню чуть глубже архитектуру. Точками соприкосновения «Навигатора» (фича А) и системы отчетов (фича Б) были общие сущности в базе данных: «подведомственные организации», «НКО», «бизнес», «услуги», а также «округА» и «районы». Сущность «подведомственная организация» была особенно объемной и тесно связанной с «услугами» — ключевой для «Навигатора». Эти «лёгкие» правки мы и не могли перенести в прод без незавершенных структурных изменений по отчетам.
Рис. 1. Схема противоречий.
Ситуацию усугубляли два фактора.
Во-первых, подсистема отчетности была критична для упомянутых выше сотен организаций, и ее деплой требовал долгих согласований и предупреждений всех пользователей (они должны были успеть сохранить данные и выйти из системы). Чаще всего это означало работу после конца рабочего дня. Срочные правки по навигатору просто «застревали» в ожидании окна.
Во-вторых, изменения были не косметическими, а архитектурными, затрагивающими таблицы БД. Изолировать их простым feature toggle было невозможно.
Оставался скользкий путь, знакомый каждому, кто работал с legacy-монолитами: ручные cherry-pick’и — то есть выборочные переносы коммитов из одной ветки в другую. Но чем больше таких манипуляций, тем выше энтропия и риск уронить прод. На практике попытки таких переноса регулярно вызывали конфликты в общих CSS и JS-файлах, «уезжала» верстка, появлялись трудноуловимые баги на фронтенде. Учитывая масштаб подсистемы отчетности — с объемом рисков был явный перебор.
Техническая проблема стремительно и ожидаемо переросла в коммуникационную: «Почему не выкатываете обновления? Мы заждались!».
Предложение
И вот в один прекрасный летний день мы пришли к заказчику с радикальным, но, на наш взгляд, неизбежным предложением: резать монолит «по-живому», а именно выделить «Социальный навигатор» в полностью независимый сервис на отдельном поддомене: https://nav.dszn.ru (см. рис. 2).
Рис. 2. Внешний вид навигатора как отдельного сервиса на своем поддомене.
Аргументы были просты и логичны:
- Это быстро и относительно недорого. Не надо переписывать всё с нуля — нужно просто «хирургически» отделить существующий, работающий функционал.
- Это развяжет руки всем:
- мы сможем оперативно поставлять фичи для «Навигатора», независимо от разработки других модулей;
- срочные доработки перестанут «томиться» в ожидании «окна».
- Кроме того, анализ метрик, в том числе из Яндекс.Вебмастера, показывал, что интерактивная карта сильно нагружала и без того тяжелый «монолит». Её вынос ее должен был стабилизировать работу основного портала.
Уговаривать не пришлось — нам дали «добро».
На реализацию ушло около 3 месяцев.
Технические компромиссы и бонусные решения
Выделить сервис — полдела. Надо было не создать на месте одной проблемы две новых. И мы пошли на некоторые технические компромиссы.
Первый и самый принципиальный выглядел еретически: мы не стали заводить отдельную БД. Зачем плодить сущности? Навигатору не нужно состояние — ему достаточно получать свежие данные по запросу. База осталась на основном портале.
Это решение одним махом сняло с нас пласт проблем:
- не потребовались дополнительные серверы СУБД (а с ними настройка бэкапов и репликации);
- не появилось новых точек отказа;
- плюс безопасность — нет локальной БД на публичном сервисе, значит, неоткуда случиться прямой утечке.
Данные в «Навигатор» поступают через API в формате JSON, по запросу (вручную, по кнопке в админке) или по расписанию (cron). Но источников данных стало два:
- администраторы портала, как и раньше, правят информацию в основной админке;
- ключевое архитектурное изменение — мы создали личные кабинеты для каждой из 300+ подведомственных организаций (рис. 3).
(А)
(Б)
Рис. 3. Внешний вид страницы подведомственной организации (А) и ее личный кабинет (Б)
Теперь каждый центр соцобслуживания или фонда сам, как ему надо, актуализирует информацию о себе: адреса, контакты, перечень услуг. Правки отправляются на модерацию и только после утверждения попадают в «Навигатор».
Иными словами, вся система теперь завязалась на трех ключевых приложениях (см. рис. 4):
- панели администрирования на основном портале;
- личные кабинеты для подведомственных организаций;
- сам «Навигатора».
Так мы решили две проблемы разом: избежали двойного ввода данных и переложили нагрузку по их наполнению на тех, кто знает эти данные лучше всех — на сами учреждения.
В навигаторе всегда хранится только одна, текущая версия данных из свежего JSON-файла. Никакого версионирования, никаких миграций — если на источнике менялась структура, мы просто корректировали логику обработки JSON.
Рис. 4. Три получившихся ключевых приложения системы.
Поскольку JSON-файлы объемны, их «наивная» обработка съедала бы много ресурсов. Поэтому мы задали легкий PHP-пакет, реализующий паттерн «Коллекция» (аналог Illuminate/Collections из Laravel). Вместо «прожорливых» циклов foreach разработчики получили возможность использовать декларативный код с цепочками методов map(), filter(), groupBy(), плюс «ленивые» вычисления дополнительно экономили память и процессорное время.
«Вишенка на торте» — помимо основного сервиса, мы сделали его облегченную версию в виде виджета (рис. 5). Это интерактивная карта в iframe, которую можно встроить куда угодно — мы встроили на главную страницу основного портала. Весь интерактив работает внутри фрейма, без всяких авторизаций и сложностей с CORS.
Рис. 5. Виджет навигатора на главной странице портала
Результаты и выводы
Что мы получили в сухом остатке?
Во-первых, достигли главной цели — ускорили выкатку фич. Мы перестали быть заложниками параллельных разработок, и обновления для «Социального навигатора» теперь выходят независимо от состояния других частей монолита.
Во-вторых, разработка стала безопаснее. Мы ушли от практики рисков с cherry-pick’ами, которая изрядно нервировала команду.
В-третьих, — и это весомо для заказчика, — прямая экономическая выгода. Создав личные кабинеты для подведомственных учреждений, мы перенесли на них основную нагрузку по управлению контентом. Профильные подразделения Департамента разгрузились.
Соответственно, и скорость обновления информации в Навигаторе увеличилась в разы, сделав его для москвичей значительно полезнее.
Но главный вывод лежит не в технической, а в управленческой плоскости. Мы делали декомпозицию не потому это стильно-модно, а потому что она развязывала конкретный узел бизнес-проблем. А это — аргумент.