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

Трассировка через eBPF снимает налог на ручное инструментирование, но требует ядра не ниже 5.8, несрезанной таблицы символов и знания устройства планировщика Go.

При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов в ядро ежесекундно и потолок расхода в 200–600 мс процессорного времени на ядро.

Медленный запрос это не одна проблема, а пять разных: лишняя работа, борьба за ресурсы, давление среды, деградация плана и патологические шаблоны вроде N+1.

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

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

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

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

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

Почему с Go это сложнее, чем с C

Зонд работает так: в заданное смещение работающего бинарника ставится инструкция прерывания, при попадании в неё ядро останавливает поток, выполняет свою программу и возобновляет исполнение. Для C и Rust это ложится на прологи функций почти без остатка. Go добавляет три осложнения.

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

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

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

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

Главная нерешённая проблема: передача контекста между сервисами

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

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

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

Что ломается в продакшене

• Идентификаторы горутин переиспользуются. При высокой конкурентности номер может уйти на новую горутину раньше, чем потребитель разобрал события старой.
• Обновление бинарника сдвигает смещения символов. Зонды старого отображения ядро снимает само, и новый бинарник какое-то время работает без трассировки. Слежение за изменением файла сокращает разрыв до секунд, но не убирает его.
• Требования к ядру. Кольцевые буферы нужны ядру от 5.8, а переносимая компиляция зондов требует 5.4 с включённой отладочной информацией о типах. Матрицу ядер стоит проверить до внедрения, а не после.
• Срезанные бинарники. Сборка без таблицы символов и отладочной информации лишает трассировщик возможности сопоставить имена функций со смещениями. Компромисс: оставить хотя бы таблицу символов, заплатив примерно 10–15% размера бинарника.

Сколько это стоит в процессорном времени

Зонды не бесплатны: каждое срабатывание это программное прерывание с входом в ядро. При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов ежесекундно. Опубликованные замеры дают порядка 1–3 мкс на срабатывание на современном оборудовании, то есть верхняя оценка расхода составляет 200–600 мс процессорного времени в секунду на одно ядро.

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

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

Слой второй: превратить трассы в решения

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

«Медленный запрос» это пять разных диагнозов

Прежде чем что-то чинить, стоит понять, чем именно болен запрос. Разбор CNCF раскладывает медленные запросы к базе на пять непохожих причин:

• Лишняя работа. Обычно это полный перебор таблицы из-за отсутствующего или неприменимого индекса. Выборка по идентификатору клиента без индекса растёт с 20 мс на десяти тысячах строк до минут на десяти миллионах. Запрос не менялся, изменился объём данных.
• Борьба за ресурсы. Идеально оптимизированный запрос стоит в ожидании блокировок или свободного соединения. Запрос, проводящий 95% времени в ожидании блокировки, оптимизацией текста не лечится: ему нужна перекройка транзакций.
• Давление среды. Насыщение процессора, узкое место ввода-вывода и нехватка памяти замедляют любой запрос с любым планом: тот же текст запроса и тот же план на нагруженной машине отработает в разы дольше, чем на свободной, и оптимизировать тут нечего.
• Деградация плана. Данные и текст запроса те же, а план исполнения изменился. Устаревшая статистика после массовой загрузки заставляет планировщик выбрать заведомо плохую стратегию.
• Патологические шаблоны. Проблема N+1 выполняет сотню быстрых запросов по две миллисекунды последовательно, добавляя двести миллисекунд задержки на одно только выполнение, не считая сетевых издержек на каждый обмен с базой. Ни один запрос не является медленным, а шаблон катастрофичен и в журнал медленных запросов не попадает вовсе.

Чего не хватает встроенным инструментам базы

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

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

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

Слой третий: не принять смену измерения за изменение продукта

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

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

Общий тренд не объясняет вашу просадку

В июньском наборе данных о реальных пользователях Chrome, опубликованном в середине июля, доля источников с хорошей отрисовкой основного содержимого упала до 67,7%, с хорошей задержкой отклика на взаимодействие до 85,9%, а доля проходящих все три ключевых показателя до 55,3%. Исключением оказалась стабильность вёрстки, поднявшаяся до 81,4%.

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

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

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

Изменение методики выглядит как изменение продукта

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

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

Компенсация это не исправление

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

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

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

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

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

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

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

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

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

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

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

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

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

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

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

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

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

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

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

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

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

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

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

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

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

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

Пример: как команда переписала сервис документов и потеряла полгода

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

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

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

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

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

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

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

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

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

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

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

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

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

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

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

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

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

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

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

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

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

Что получает команда

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

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

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

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

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

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

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

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

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

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

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

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

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

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

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

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

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

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

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

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

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

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

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

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

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

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

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

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

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

1. 10-Страйк: Мониторинг Сети Pro

10-Страйк: Мониторинг Сети Pro — это российская программа для системных администраторов, которая позволяет контролировать состояние сетевых устройств, серверов, рабочих станций, коммутаторов, баз данных и других ресурсов инфраструктуры. Она отслеживает ключевые параметры — от свободного места на дисках и загрузки процессора до температуры оборудования — и в случае проблем отправляет уведомления по email, SMS или в мессенджеры. Система может не только сигнализировать о сбоях, но и автоматически устранять их, например, перезапуская службы или выполняя скрипты.

Технические возможности

Продукт поддерживает десятки видов сетевых проверок через ICMP, SNMP, HTTP, SQL, SSH и другие протоколы. Возможно мониторить серверы Windows и Linux, сетевые службы, видеокамеры, принтеры, СУБД и промышленное оборудование. Визуализация данных доступна на карте сети с графиками и индикаторами. В версии Pro предусмотрен распределённый мониторинг с несколькими серверами и аген­тами, а также веб-интерфейс для удалённого управления.

Сценарии использования

Для DevOps и системных администраторов 10-Страйк подходит как инструмент централизованного мониторинга с алертами и картой сети. IT-отделы предприятий используют его для контроля доступности каналов связи, серверов, баз данных и устройств. Руководители могут формировать отчёты по аптайму и SLA для анализа стабильности работы инфраструктуры.

Особенности

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

Тарифы и условия

Продукт распространяется по лицензии с ограничением на число сенсоров: версия Pro на 100 сенсоров стоит 40 000 рублей, стандартная версия — 20 000 рублей. Для корпоративных лицензий действует ограничение на количество серверов мониторинга.

2. Deckhouse Prom++

Deckhouse Prom++ — это Open Source-система мониторинга на базе Prometheus, которая потребляет до 10 раз меньше памяти. Она собирает метрики приложений, сервисов и инфраструктуры в реальном времени, хранит их во встроенной TSDB и поддерживает PromQL для анализа. Deckhouse Prom++ умеет формировать алерты и легко интегрируется с Grafana, оставаясь привычным для команд, которые уже работают с Prometheus.

Технические возможности

Deckhouse Prom++ может собирать любые инфраструктурные метрики напрямую или через экспортеры: состояние серверов, контейнеров, сетей, баз данных и приложений. Главная оптимизация по сравнению с «ванильным» Prometheus — переработка Write Ahead Log — позволяет снизить потребление памяти без ущерба производительности. Продукт полностью совместим с API и настройками Prometheus: дашборды, правила алертинга и интеграции продолжают работать без изменений. Prom++ уже используется на более чем 1000 кластеров и поддерживает до 10 млн активных метрик на кластер.

Сценарии использования

DevOps-инженеры и SRE могут использовать Deckhouse Prom++ для мониторинга Kubernetes и традиционной инфраструктуры. Архитекторы и CTO получают возможность сократить расходы на RAM без отказа от привычной экосистемы. Prom++ подходит и для on-prem, и для облачных окружений, а также уже встроен в Deckhouse Kubernetes Platform.

Особенности

Ключевое преимущество Deckhouse Prom++ — низкое потребление ресурсов: до 10 раз меньше памяти, чем у Prometheus, и до 3 раз меньше, чем у VictoriaMetrics. Сервис полностью совместим с экосистемой Prometheus, не создаёт вендорлока и распространяется под лицензией Apache 2.0. Поддержка осуществляется инженерами Deckhouse и сообществом через открытый Telegram-чат.

Тарифы и условия

Deckhouse Prom++ — полностью бесплатный Open Source-продукт. Ограничений по количеству пользователей или метрик нет.

Есть инструкция по миграции, потребуется только предварительная конвертация WAL-файлов. Вы также сможете без труда вернуться с Deckhouse Prom++ на Prometheus.

Инженеры Deckhouse и сообщество помогают пользователям в Telegram-чате Prom++ User Group.

3. GMONIT

GMONIT — российская платформа класса Observability, которая собирает и анализирует метрики, логи, трассировки и бизнес-показатели в едином интерфейсе. Она даёт ИТ-командам полный обзор цифрового контура: от сетей, серверов, баз данных и контейнеров до пользовательских действий и бизнес-метрик. GMONIT помогает перейти от «реактивного» реагирования на инциденты к проактивному управлению ИТ, сокращая время диагностики и повышая стабильность сервисов.

Технические возможности

GMONIT поддерживает мониторинг сетей, серверов, виртуальных машин, баз данных, контейнеров, API, реальных пользователей в браузере или мобильном приложении и бизнес-процессов. Система строится на микросервисной архитектуре, легко масштабируется и формирует дашборды для разных ролей — от инженеров до CIO. В одном интерфейсе доступны ключевые показатели доступности, SLA, конверсии, скорость обработки заказов и другие бизнес-метрики. Платформа обеспечивает предиктивную аналитику, раннее выявление аномалий и ускоренное RCA (Root Cause Analysis — анализ первопричин): TTD (Time To Detect — время до обнаружения) — менее 10 минут, RCA — около 15 минут.

Сценарии использования

• Разработчики используют GMONIT для отладки сервисов и мониторинга CI/CD, что ускоряет релизы и сокращает время устранения ошибок.
• QA-команды применяют платформу при нагрузочных тестах и фиксации ошибок в продакшене.
• DevOps и SRE получают централизованный мониторинг с алертами, предиктивной аналитикой и интеграцией в пайплайны.
• PM и CIO работают с визуальными панелями SLA, аптайма и бизнес-метрик, чтобы видеть реальное влияние инфраструктуры на продажи и пользовательский опыт.
• Поддержка сокращает время реакции на инциденты и устраняет сбои до того, как о них сообщают пользователи.

Особенности

GMONIT строится как масштабируемая система с единым «окном наблюдения»: метрики инфраструктуры, пользовательского опыта в браузере, приложений, API; а также вызовы во внешние сервисы и бизнес-процессы отображаются на одном дашборде. Архитектура ориентирована на работу с большими объёмами данных, а визуализация адаптирована как под инженеров, так и под управленцев. Сервис интегрируется с CI/CD, мессенджерами и сторонними системами через API. Поддерживаются как on-prem, так и облачные сценарии.

Тарифы и условия

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

Управление и поддержка

Управление осуществляется через веб-интерфейс и API. Поддержка организована через чат, систему тикетов, SLA и подробную документацию.

4. Zabbix

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

Технические возможности

Платформа поддерживает мониторинг серверов, приложений, облачных сервисов, сетевых устройств и IoT, включая многоуровневые среды. Важной функцией выступает вложенное низкоуровневое обнаружение, позволяющее автоматически создавать иерархические правила для хостов и сервисов. Zabbix предлагает мастер создания хостов, встроенную проверку форм для сокращения ошибок, расширенные сетевые карты и новый виджет карточки товара для детальной визуализации метрик. Платформа может быть развернута локально, в облаке Zabbix или в сторонних облаках (AWS, Azure, Google Cloud).

Сценарии использования

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

Особенности

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

Тарифы и условия

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

5. LibreNMS

LibreNMS — это система мониторинга сетевой инфраструктуры с автоматическим обнаружением устройств и сервисов. Она ориентирована прежде всего на мониторинг сетей по SNMP, но также поддерживает серверы на Windows, Linux и FreeBSD через собственные агенты. Решение работает на базе PHP и MySQL, имеет удобный веб-интерфейс, мобильные приложения и широкий набор встроенных метрик, которые не требуют ручной настройки.

Технические возможности

Система автоматически обнаруживает топологию сети с помощью протоколов CDP, FDP, LLDP, OSPF, BGP, SNMP и ARP. Поддерживается интеграция с NfSen, collectd, SmokePing, RANCID и Oxidized. Встроенный API позволяет управлять установкой, строить графики и выгружать данные. Реализована гибкая система оповещений с поддержкой email, IRC, Slack и других сервисов, а также встроенная биллинговая система для учета использования полосы пропускания. LibreNMS поддерживает различные методы аутентификации, включая LDAP, Radius и Active Directory, и обновляется автоматически.

Сценарии использования

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

Особенности

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

Тарифы и условия

LibreNMS распространяется как проект с открытым исходным кодом и бесплатен для использования. Доступна онлайн-демонстрация (https://demo.librenms.org, логин: demo, пароль: demouser).

Для этого нужны системы высокой доступности (High Availability, HA). Речь не о полном исключении ошибок, а о способности системы продолжать работу даже при сбоях.

Высокая доступность основывается на трёх ключевых элементах: архитектуре, культуре разработки и процессах. Вместе с Борисом Кузоваткиным, директором облачной платформы One-cloud в VK, рассказываем, как создавать такие системы и что лежит в их основе.

Архитектура

Архитектура строится на принципах горизонтального масштабирования, изоляции компонентов, многоуровневого кэширования, автоматического восстановления и мониторинга на основе SLO.

Разберем на нашем кейсе: сегодня в VK активно развивается облачная платформа One-cloud. Вместо того чтобы привязываться к конкретным серверам, мы используем внутреннее облако. Это даёт гибкость: если в «классических» системах ночью сервера простаивают, то у нас эти ресурсы перераспределяются на другие задачи.

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

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

Культура разработки

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

Инженер должен уметь сам замечать, что «что-то идёт не так». Бывает, метрики показывают, что всё нормально, а пользователи уже начинают массово жаловаться. Или, наоборот, система присылает тревоги, но причина совсем в другом. Здесь решающим становится опыт команды и отлаженные on-call процессы.

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

Чтобы её поддерживать, необходимо регулярно проводить ретроспективы, обучающие сессии и внутренние симуляции сбоев (chaos drills).

Процессы и мониторинг

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

• частоту ошибок,
• квантили длительности запросов,
• загрузку CPU, RAM и дисков,
• бизнес-метрики (например, количество видео, просмотренных за минуту).

Для сбора метрик — Prometheus, VictoriaMetrics, Forge, а для визуализации использовать Grafana. Падение бизнес-метрик может быть вызвано не только сбоями в системе, но и внешними факторами — например, перебоями связи в праздничный день.

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

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

После любого серьёзного сбоя обязательно проводится анализ:

• Что произошло?
• Как это починили?
• Что можно было сделать лучше?
• Как предотвратить повторение?
• Как система переживает сбои

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

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

На некоторых видеосервисах применяется load shedding: часть запросов сбрасывается, чтобы сохранить качество видео.

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

Уроки надёжности для любой команды

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

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

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

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

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

Микросервисы: зачем они нужны и в чем их плюсы

Архитектура приложений: немного базы

Под капотом современных приложений обычно скрываются три основные части:

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

Собрать это все можно по-разному. Можно сложить в монолит, а можно попробовать модульный подход.

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

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

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

Микросервисы — панацея? Не совсем

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

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

Распространение DevOps-культуры и инструменты оркестрации

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

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

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

Проектируем микросервисы без боли: от стандартов до DDD

Стандартизация — наше все

Если каждый микросервис пишет логи в своем формате и использует свои библиотеки, получается зоопарк. Нужно, чтобы были выровнены стек и CI/CD pipeline, существовали одинаковые библиотеки логирования и формат.Микросервисы дают свободу писать на разных языках, но с ней приходит и ответственность: под каждый язык придется придумывать и поддерживать разные инструменты. А это приведет к еще большему увеличению сложности. Так что с языком тоже лучше соблюдать стандартизацию: если пишете на Java, то и решать все проблемы стоит с помощью этого языка.

При этом иногда другой язык вполне оправдан. Например, просто потому, что Java не может работать с такой высокой скоростью, какая нужна. В некоторых случаях даже на Java приходится писать особым образом, либо можно использовать C++, Go или Rust. Но это скорее исключение из правила.

Инженеры — натуры увлекающиеся и любят паттерн CV driven development, когда хочется новую технологию потрогать и внедрить у себя. А потом похвастаться этим на каком-нибудь ивенте по принципу «just because I can» («просто потому что могу»). При этом может оказаться, что бизнесу технология особо и не была нужна. Чтобы избегать таких ситуаций, необходим технологический радар — список того, что можно использовать в компании, а что нет. И исключения из такого радара должны приниматься и допускаться очень взвешенно.

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

Одна из опасностей при проектировании микросервисов — скатиться в очень мелкую гранулярность, когда логика нарезается чуть ли не по отдельной функции на микросервис (на отдельный deployment unit). Это может привести к такой сложности, которой потом будет очень трудно управлять. Такая проблема была, например, у Uber в начале их пути, и им пришлось пересматривать свою архитектуру. Избежать этого помогает Domain-driven design (DDD) — предметно-ориентированное проектирование.

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

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

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

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

Два эмпирических правила, которые касаются размера сервисов и помогают понять, правильно ли они спроектированы:

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

Внедрение микросервисов: с чего начать?

С микросервисным подходом есть проблема — нет четкого ответа, куда идти и что делать, чтобы научиться его создавать. Это одна из главных сложностей микросервисной архитектуры, особенно когда только начинаешь с ней работать. Если хочется изучить Spring или Oracle, можно почитать официальную документацию. А к такой большой и необъятной теме, как микросервисы, даже и непонятно, с какой стороны подступиться. Туториала к ней нет, есть только куча статей, подходов и практик. Причем одни практики подойдут конкретной команде, а другие — нет.

И вот тут возникает реальная сложность, особенно когда вы только начинаете, — глаза разбегаются. Здесь Kubernetes, здесь ELK, здесь Grafana, здесь observability, здесь всякие паттерны отказоустойчивости, CAP-теорема и прочее. Непонятно, куда бежать. И каждый день появляются новые инструменты, которые так или иначе упрощают жизнь.

Совет: задавайте себе вопрос о каждом инструменте, который вы хотите внедрить (будь то Kubernetes, OpenTelemetry с Jaeger или любой другой) — какую проблему мы решаем, втаскивая его в свою инфраструктуру? Ответ на этот простой вопрос может дать много инсайтов и просветлений.

Чтобы в первом приближении ознакомиться с темой, можно почитать материалы SRE от Google, также будут полезны статьи и книги в блоге Мартина Фаулера, в том числе Microservices Guide. Если вам нужна практика, можно попробовать пойти на тот же Udemy, где есть множество курсов по микросервисной архитектуре с хорошими рейтингами и отзывами.

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

Поддержка микросервисной архитектуры

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

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

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

Паттерны отказоустойчивости

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

Еще один хороший вопрос: как мониторить аварии? Необходимо очень быстро находить точку отказа. Для этого, собственно, и нужен observability-подход, трейсинг. Нужно смотреть, где какой RPS (число запросов в секунду), не произошло ли резкого скачка трафика, важно следить за latency (задержками).

Бывали случаи, когда из-за бага в мобильном приложении трафик внезапно удваивался, и системы не выдерживали такой нагрузки. Любая малейшая задержка в самом незначительном компоненте может привести к тому, что по цепочке пойдет отказ, — будут копиться потоки, соединения, и рано или поздно упадет вообще все. Чтобы подготовиться к таким ситуациям, важно изучить хотя бы четыре «золотых сигнала» мониторинга из SRE от Google.

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

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

• Circuit Breaker — если сервис спамит ошибками, лучше временно прекратить попытки до него достучаться. Для клиента ничего не изменится, он как получал ошибки, так и будет получать. Но, по крайней мере, можно дать системе возможность восстановиться. А еще лучше — позволить ей переключиться на какой-то резервный канал, например сходить в кэш с неактуальными данными.
• Rate Limiter — абсолютно банальная, но необходимая вещь. Нужно ограничивать входящий поток на примерно максимальном уровне от того, который ожидается. Чтобы все не развалилось, если произойдет резкий скачок трафика.
• Blue-Green Deployment — значительно снижают на продакшене количество аварий и проблем, связанных с кривыми релизами. Можно не раскатывать новую фичу сразу на все 100 подов, а выкатить ее только на 1% трафика и проверить.

И это только малая часть паттернов.

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

Как эффективно работать с инцидентами

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

Первый уровень — это application-слой, сами сервисы, которые в подах крутятся в Kubernetes. Нужно проверить, все ли у них хорошо по точкам интеграции — нет ли тайм-аутов. Все ли в порядке у них по железу — по CPU, по памяти, по дискам.

Если на первом уровне все нормально, нужно опуститься на уровень ниже — либо на виртуалки, на которых Kubernetes развернут, либо на железки, если он развернут на Bare-metal. Недавно мы столкнулись с интересным случаем: виртуалка показывала нормальную загрузку CPU, но физический гипервизор, на котором она крутилась, был загружен на 99%. Естественно, виртуалка страдала, но уровнем выше этого не было видно.

Совет: если вы вдруг нашли что-то, что еще не мониторится, — это повод поскорее добавить эту метрику, начать ее мониторить и ретроспективно отслеживать.

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

Вообще, человеческий фактор — это отдельная боль. Все привыкли менять что-нибудь руками: заходить в виртуалки, поправлять конфиг. Чтобы такого было как можно меньше, важно вкладываться в infrastructure as a code и даже everything as a code. В идеале следует стремиться к zero access production — нулевому доступу к продакшену — и все раскатывать через Git, через конфигурации, включая политики безопасности.

Культура ответственности и изменение ролей в команде

Представим, что происходит инцидент — падают 15 микросервисов. Как должна быть устроена система, которая позволит оперативно справляться с авариями?

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

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

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

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

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

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

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

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

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

Будущее микросервисов: тренд на AI Ops

Разработчики уже используют AI как copilot — и это очень мощный инструмент в умелых руках. Он не заменяет инженера, но сильно экономит ему время. Эту помощь от нейросетей очень хочется растянуть и на инфраструктуру, и на эксплуатацию, чтобы получить крутой AI Ops.

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

Есть прототипы — например, Big Panda или Moocsoft (который был недавно куплен Dell), но пока это точечные решения. Возможно, на горизонте 5–7 лет (скорее 5, чем 10) они станут серьезной частью индустрии и очень мощным прорывом, который упростит разработчикам жизнь.Кроме того, важно, чтобы развивались и более «приземленные» технологии: инструменты контейнеризации, оркестрации, observability, а также APM — Application Performance Monitoring.

Инженер остается в центре всего

Никакие микросервисы, Kubernetes и AI Ops не спасут, если за системой не стоит инженер, который думает головой, правильно работает руками и отвечает за результат. Важны его навыки, кругозор и культура работы. Именно такие люди превращают набор сервисов в работающий продукт. Все остальное — только инструменты.

P. S. Если интересно, как мы решаем эти задачи на практике, слушайте (и смотрите) наш подкаст «Техно.Логично» — там регулярно обсуждаем самое актуальное в IT-сфере.

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

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

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

METEOR — мощный инструмент для автоматизации процессов, с триггерами, серверными функциями и ИИ-аналитикой. Он позволяет гибко настраивать сложные операции.

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

После внедрения METEOR команды замечают, что продуктивность их работы сильно повышается:

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

Помимо самого Gitlife, разработчики делают Gitlife AI, в котором есть доступ к топовым ИИ-моделям и инструментам, чтобы разрабатывать ИИ-решения.

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

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

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

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

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

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

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

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

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

Что такое pet-проект и зачем его защищать

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

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

Кроме того, защита pet-проекта — важный навык, который высоко ценится работодателями.

Рассмотрим основные правила кибербезопасности, которые нужно учитывать при работе над pet-проектом.

Безопасное управление секретами

Секреты — это чувствительные данные, такие как пароли, токены доступа, ключи API, SSH-ключи, сертификаты и другие данные, которые обеспечивают аутентификацию и шифрование. Если добавить секреты в код, злоумышленники могут получить полный контроль над вашей инфраструктурой.

Какие правила нужно соблюдать

• Не храните секреты в коде. Храните секреты в отдельных файлах env. и добавьте эти файлы в .gitignore, чтобы они не попадали в репозиторий.
• Придерживайтесь принципа минимальных привилегий. Каждый сервис должен иметь только те права, которые необходимы для выполнения своих задач.
• Регулярно обновляйте секреты. Меняйте токены и пароли периодически, особенно после обнаружения утечек или изменений в проекте.
• Используйте менеджеры секретов. Популярные сервисы: Doppler, HashiCorp Vault, AWS Secrets Manager, 1Password Developer Tools.
• Мониторьте утечки. Можно использовать такие инструменты, как GitGuardian, TruffleHog, Gitleaks.
• Шифруйте секреты. Используйте библиотеки типа cryptography в Python и подключайте шифрование на уровне операционной системы.

Безопасность CI/CD

Пайплайн CI/CD (Continuous Integration / Continuous Delivery) — автоматизированный процесс сборки, тестирования и развёртывания приложений. Он помогает автоматически интегрировать код и деплоить его на различные среды.

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

Способы защиты пайплайна

• Моделируйте угрозы. Оцените, какие угрозы наиболее вероятны на каждом этапе пайплайна: от коммита кода до деплоя на сервер.
• Проверяйте зафиксированный код. Используйте статический анализ кода для автоматического поиска уязвимостей.
• Защитите Git-репозитории. Настройте двухфакторную аутентификацию (2FA), ограничьте доступ к репозиториям, используйте обязательную проверку пул-реквестов двумя разработчиками.
• Изолируйте пайплайн. Не запускайте его на том же сервере, где крутится ваше продакшн-приложение.

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

Сервисы мониторинга и логирования

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

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

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

Примеры популярных сервисов

Logtail — простой инструмент для сбора и анализа логов, есть бесплатный тариф.

Papertrail — удобный сервис для быстрого поиска по логам, бесплатный план для небольших проектов (10 Мб в день).

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

BetterStack — мониторинг доступности сайтов и серверов с бесплатными уведомлениями об инцидентах по почте, через SMS и Slack.

Grafana Cloud Free — мониторинг с красивыми дашбордами, бесплатный лимит ресурсов до 10 тыс. серий данных, 50 ГБ трафика.

Prometheus и Grafana — Prometheus собирает метрики, Grafana их визуализирует.

UptimeRobot — проверка доступности вашего проекта каждые 5 минут, бесплатный тариф на 50 мониторингов.

Бэкап и восстановление данных

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

Как сделать бэкап пошагово

1. Определите данные, которые необходимо бэкапить: какие данные критически важны, какие можно восстановить вручную.
2. Выберите место хранения: облачные сервисы, собственные серверы, внешние носители, Git-репозиторий.
3. Выберите тип бэкапа: при полном копируются все данные целиком, при инкрементном — изменения с момента последнего копирования, при дифференциальном — изменения с момента последнего полного бэкапа.
4. Настройте автоматизацию, чтобы не забывать делать бэкапы вручную. Можно использовать скрипты, планировщики задач или бэкап-сервисы.
5. Проверьте бэкап. Проведите тестовое восстановление.
6. Определите частоту бэкапа. Например, можно проводить полный бэкап раз в неделю и инкрементные бэкапы каждый день.
7. Защитите чувствительные данные.

Локальные туннели

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

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

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

Трафик при этом шифруется и проходит через защищённый канал.

Примеры инструментов

Ngrok — самый известный инструмент для быстрого создания туннелей. Есть бесплатный тариф.

Порты от VSCode — отличное решение для пользователей Visual Studio Code, удобно для быстрой демонстрации.

VK Tunnel — российская альтернатива, подходит для работы через VK Cloud.

Tuna и xTunnel — простые в использовании решения, есть бесплатные тарифы.

Чек-лист по инфобезу для тех, кто делает pet-проект

1. Регулярно обновляйте зависимости. Используйте автоматические инструменты, например, Dependabot или npm audit.
2. Настройте базовые HTTP-заголовки безопасности. Добавьте заголовки Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, чтобы минимизировать риск XSS, Clickjacking и других атак.
3. Используйте бесплатные SSL-сертификаты. Подключите HTTPS через бесплатные сервисы, например, Let's Encrypt.
4. Очищайте и валидируйте ввод данных. Фильтрация и валидация данных защитит от SQL-инъекций и XSS.
5. Создайте отдельные учётные записи для разных сервисов. Не используйте одну и ту же учётную запись везде.
6. Минимизируйте доступы к базе данных. Если сервису нужно только читать, не давайте права на запись или удаление.
7. Используйте бесплатные инструменты для сканирования уязвимостей. Проверьте код через такие сканеры, как SonarQube Community Edition, Snyk, OWASP ZAP.
8. Делайте резервные копии. Настройте автоматические бэкапы базы данных и важных файлов.
9. Не храните секреты в коде. Используйте .env файлы и убедитесь, что они добавлены в .gitignore.
10. Включите двухфакторную аутентификацию (2FA). На всех сервисах, где это возможно, включите 2FA для дополнительной защиты.
    

А больше про разработку и все, что с ней связано, в нашем тг-канале!

Ошибка получила идентификатор CVE-2025-4123 и прозвище Grafana Ghost.

Что произошло

Уязвимость была найдена исследователем уязвимостей Альваро Балада и устранена в обновлении 21 мая 2025 года. Однако, как отмечают аналитики OX Security, около 36% всех инстансов Grafana в интернете до сих пор не обновлены и остаются открытыми для атак.

Исследователи проанализировали более 128 000 экземпляров Grafana, доступных через интернет, и обнаружили 46 506 инстансов, на которых всё ещё используются уязвимые версии платформы.

Как работает атака

Эксплуатация CVE-2025-4123 включает в себя:

• Open redirect + client-side path traversal, что позволяет загружать вредоносные плагины с сайта злоумышленника;
• Выполнение произвольного JavaScript-кода в браузере пользователя;
• Захват сессии, смена пароля и адреса почты — особенно опасно при активной авторизации;
• Возможность SSRF-атак (сервер подставляет себя как клиента), если установлен плагин Grafana Image Renderer.

Даже при включённой политике CSP (Content Security Policy) защита можно обойти, поскольку уязвимость использует маршрутизацию JavaScript, встроенную в Grafana.

Эксплойт не требует прав администратора и работает даже при активном анонимном доступе.

Насколько это опасно

Хотя атака требует участия пользователя (например, клик по ссылке), большой масштаб распространения и отсутствие необходимости в авторизации делают уязвимость особенно опасной для корпоративных и облачных инсталляций Grafana.

Что делать

Разработчики Grafana выпустили патчи для всех актуальных версий. Необходимо обновиться до одной из следующих версий:

• 10.4.18+security-01
• 11.2.9+security-01
• 11.3.6+security-01
• 11.4.4+security-01
• 11.5.4+security-01
• 11.6.1+security-01
• 12.0.0+security-01

Этап 1: Простой MVP за $0

Изначально нужно создать максимально простое приложение для управления задачами: веб-страница с несколькими категориями и возможностью добавлять таски. На фронте разработчик использует библиотеку Shad CN UI, а на бэке — Flask. Данные хранятся просто в словаре Python. Все приложение — это один файл. Оно запускается в Docker-контейнере через docker compose.

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

Этап 2: Инфраструктура на $30

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

• База данных: PostgreSQL.
• Веб-сервер: Nginx для проксирования запросов и избавления от портов.
• Аутентификация: авторизация через JWT и интерфейсы входа и регистрации на фронтенде.

Все эти компоненты подключаются к существующему приложению через docker-compose.yml. Благодаря этому теперь можно запускать приложение на localhost, а не по порту, и все будет работать как полноценное веб-приложение. Размещение такой системы на бесплатном облачном тарифе или VPS обойдётся в пределах 30 долларов.

Этап 3: Допиливание до $100

Разработчик добавляет допфункции:

• Уведомления по email: вместо стороннего API — система очередей с RabbitMQ и воркером, который отправляет письма.
• Обновления в реальном времени: WebSocket’ы для синхронизации задач на разных устройствах.
• Кэширование: Redis для хранения данных в памяти, что значительно ускоряет работу.

Также подключается Docker Build Cloud — сервис для параллельной сборки контейнеров и шаринга кеша между проектами. Это повышает производительность и ускоряет разработку.

Теперь в системе работает очередь заданий, кеш, WebSocket-сервер, SMTP и полноценная база данных. Все эти компоненты увеличивают инфраструктурные затраты до примерно $100 в месяц.

Этап 4: Мониторинг и масштабирование за $500

Разработчик внедряет:

• Логирование: стек ELK (Elasticsearch, Logstash, Kibana).
• Мониторинг: Prometheus и Grafana.
• Горизонтальное масштабирование: добавляются реплики некоторых сервисов и балансировка нагрузки через Nginx.

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

Этап 5: Целых $2000 долларов

Разработчик решает перейти на Kubernetes и развернуть приложение в разных дата-центрах по всему миру. Для управления трафиком используется глобальный балансировщик нагрузки (например, Cloudflare). А чтобы все работало стабильно, внедряются:

• Postgres с репликацией в реальном времени,
• Redis для быстрой отдачи данных.

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

Для мониторинга:

• Jaeger — для распределённой трассировки,
• ELK Stack — для логов,
• Grafana + PagerDuty — для алертов и инцидентов.

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

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

Когда бизнес затребовал систему для обработки транзакций в реальном времени с пиковой нагрузкой в 50 тысяч операций в секунду, я понял, что серые будни enterprise инженера наконец станут весельем. Наш сервис должен был не просто работать — он должен был дышать под давлением, сохраняя отклик в пределах 10 мс. Не все проблемы в мире можно решить горизонтальным масштабированием, и одним из камней преткновения стала Java, а точнее — её «мусор».

Выбор GC: G1, Shenandoah или ZGC?

Первое, с чем столкнулась наша команда, — продолжительные STW-прерывания при нагрузке. Изначально использовали G1GC как «дефолтный» выбор для баланса между latency и throughput. Но под нагрузкой 80% CPU даже G1 не справлялся: пиковые паузы достигали 400 мс, что для платежей было неприемлемо.

Мы устроили мозговой штурм с performance-инженерами. Варианты:

1. Shenandoah — низкие паузы, но требуется больше CPU.

2. ZGC — субмиллисекундные паузы даже на терабайтных хипах, но тогда (на старте проекта) он был экспериментальным в OpenJDK 11.

3. Ручная настройка G1 — максимизировать предсказуемость через MaxGCPauseMillis и InitiatingHeapOccupancyPercen.

После недели тестов на стенде с имитацией пиковой нагрузки (JMeter + Gatling) и профилирования через async-profiler, выбор пал на ZGC. Его паузы не превышали 2 мс даже при 32 ГБ куче, а алгоритм «цветных указателей» позволял масштабироваться без блокировок. Риск? Да. ZGC был новым, но его поддержка в последних LTS-версиях и тесты убедили нас.

Тонкая настройка и проклятие «тихих» утечек

С ZGC мы выставили:

1. -Xmx48g (с запасом для избежания частых аллокаций),

2. -XX:SoftMaxHeapSize=40g (чтобы ZGC активнее возвращал память ОС),

3. -XX:+UseLargePages (снижение overhead на page faults).

Но через месяц нагрузочного тестирования обнаружили «ползучее» увеличение потребления памяти. Performance-команда, анализируя дампы через Eclipse MAT, нашла проблему: кэш данных транзакций в Apache Ignite не учитывал soft-ссылки, накапливая объекты. Вместо ConcurrentHashMap перешли на `Caffeine` с политикой expiry после 10 секунд, что снизило давление на GC.

Команда performance-инженеров: алхимики метрик

Работа с perfomance-инженерами напоминала лабораторию безумных ученых. Каждый параметр JVM, каждый HTTP-эндпоинт тестировался через JMH, а Grafana-дашборды визуализировали следующее:

1. GC pauses (ZGC собирал статистику через -Xlog:gc*),

2. Allocation rate (до 1.5 ГБ/сек в пиках),

3. CPU utilization (наши самописные RateLimiter’ы съедали 15% ресурсов).

Совместно мы написали скрипты на Python, которые автоматически подбирали -XX:ConcGCThreads и -XX:ParallelGCThreads в зависимости от нагрузки на CI/CD стендах. Это сократило время настройки на 70%.

Продакшн: огненное крещение

После релиза первые дни мы мониторили всё: New Relic для трейсинга медленных методов, Prometheus для сбора JVM-метрик. ZGC не подвел — 99-й перцентиль отклика оставался на уровне 12 мс. Но однажды ночью мы получили алерты по потреблению CPU. Оказалось, фоновый процесс генерации отчетов создавал миллионы временных объектов. Решение: выделили его в отдельный микросервис с выделенным пулом памяти и CMS (ему хватало).

Итоги

Через полгода система обрабатывала 55k операций/сек с пиковыми паузами GC в 1.8 мс. Главные уроки:

1. GC — не серебряная пуля. Даже ZGC требует понимания аллокаций в коде.

2. Performance-инженеры — ваши лучшие союзники. Их взгляд со стороны JVM спас нас десятки раз.

3. Документировать всё. Наши конфиги и скрипты настройки GC стали стандартом для других команд банка.

Теперь, когда я вижу, как сервис работает без перебоев, вспоминаю те бессонные недели с дампами и тестами… и понимаю: это того стоило. Ведь в мире highload каждая миллисекунда — это деньги. Или, как говорят у нас в банке, «миллисекунда — миллион».

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

Топ-10 инструментов, которые упростят жизнь DevOps инженера

В нашем топе представлены все направления DevOps. Эти инструменты проверены на практике, сохраняют свою актуальность в 2025 году и с большой долей вероятности останутся востребованы в ближайшем будущем.

Prometheus + Grafana

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

Зачем это нужно:

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

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

Ключевые возможности:

• Prometheus собирает метрики, хранит их и умеет отправлять алерты.
• Grafana превращает сырые данные в красивые графики и дашборды.
• Гибкость: можно мониторить что угодно — от температуры сервера до количества заказов в интернет-магазине.
• Интеграции: куча готовых экспортеров для популярных сервисов (Docker, Kubernetes, PostgreSQL и т.д.).
• Бесплатно и open-source.
• Масштабируемость: работает как на одном сервере, так и в огромных кластерах.
• Гибкие алерты: можно настроить уведомления в Telegram или email.
• Поддержка сообщества: тысячи готовых дашбордов для Grafana.

Системе требуется время на настройку — чтобы все работало идеально, придется потрудиться. Кроме того, Prometheus не хранит данные вечно, но это решается.

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

PagerDuty

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

PagerDuty выступает централизованным оркестратором алертов, агрегируя данные из систем мониторинга (типа Prometheus), лог-менеджеров (Splunk) и других инструментов. Платформа анализирует поступающие уведомления, определяет их приоритет и инициирует цепочку оповещений через различные каналы — SMS-сообщения, email и мобильные push-уведомления.

Ключевые преимущества для DevOps-команд:

• Если специалист не подтвердил получение уведомления в заданный срок, оно переходит дальше по цепочке к другому ответственному лицу.
• Поддержка 600+ готовых подключений к облачным провайдерам (AWS, GCP, Azure), CI/CD-инструментам (Jenkins, GitLab) и платформам для совместной работы (Slack, Microsoft Teams).
• Формирование детализированных отчетов о времени реакции, эффективности обнаружения и частоте повторяющихся инцидентов.
• Гибкие схемы ротации с учетом временных зон, рабочих графиков и календарей отпусков сотрудников.

PagerDuty существенно сокращает среднее время восстановления системы за счет того, что исключает человеческий фактор при первичном оповещении.

StatusPal

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

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

Основные преимущества:

• автоматические интеграции с популярными системами мониторинга (PagerDuty, Datadog, New Relic);
• удобный и понятный интерфейс, который можно настроить под бренд компании;
• эффективная система уведомлений для пользователей (email, RSS, веб-хуки);
• полная история инцидентов с возможностью последующего анализа;
• мультиязычная поддержка для международных проектов;
• API для интеграции с внутренними системами компании.

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

Davis от Dynatrace

Это инструмент для мониторинга всей структуры данных в системе на базе ИИ. Предоставляет в режиме онлайн подробные сведения о пользовательском опыте и производительности программ. Davis помогает командам DevOps обнаруживать и устранять проблемы до того, как они повлияют на пользователей приложения.

Основные плюсы платформы:

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

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

Harness

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

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

Ключевые преимущества:

• Упрощает сложные процессы. Это высвобождает ресурсы и время команды DevOps.
• Интегрируется с сервисами. Платформа поддерживает все популярные облачные провайдеры (AWS, GCP, Azure), легко взаимодействует с Kubernetes, GitHub, GitLab и другими инструментами разработки.
• Осуществляет мониторинг процессов. Платформа позволяет отслеживать состояние приложений после деплоя, а система автоматически обнаруживает аномалии и может откатить изменения без участия инженера. Благодаря детальным отчетам и аналитике, девопсы всегда видят, какие изменения привели к проблемам, и могут быстро их исправить.
• Взаимодействует с микросервисами. Harness особенно полезен для команд, работающих с микросервисными архитектурами. Он умеет управлять множеством сервисов одновременно, обеспечивая согласованность релизов.

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

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

Nix

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

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

Преимущества Nix:

• Воспроизводимость — окружения остаются идентичными на любой системе.
• Изоляция зависимостей — снижает связанные риски выполнения кода.
• Декларативная конфигурация — инфраструктура как код, управление ИТ-окружением без ручных настроек.
• Кроссплатформенность — работает на Linux, macOS и даже Windows (через WSL).

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

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

Chef

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

Ключевые преимущества Chef:

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

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

Splunk Cloud

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

Splunk Cloud превращает сырые данные в ценные инсайты. Этот инструмент особенно востребован в DevOps-среде, где оперативный доступ к информации о работе систем критически важен для быстрого реагирования на инциденты.

Splunk Cloud помогает инженерам:

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

В числе главных преимуществ:

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

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

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

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

ServiceNow

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

ServiceNow — это не просто система учета инцидентов, а единая платформа для оркестрации CI/CD-процессов, а также центр управления изменениями инфраструктуры и автоматизации сквозных бизнес-процессов

Базовые преимущества для DevOps:

• глубокая интеграция с инструментами разработки (GitHub, GitLab, Jenkins);
• виртуальные агенты для автоматического разрешения типовых инцидентов;
• AI-алгоритмы для прогнозирования сбоев на основе исторических данных;
• среда для настройки рабочих процессов без программирования;
• единый журнал изменений для аудита и соответствия требованиям;
• возможность управления гибридными и мультиоблачными средами.

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

Sysdig

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

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

В списке основных преимущества Sysdig:

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

Почему DevOps-инженеры выбирают Sysdig? Когда в кластере Kubernetes одновременно работают сотни объектов, традиционные инструменты мониторинга часто показывают только симптомы проблем. Sysdig позволяет увидеть, какой именно процесс внутри контейнера потребляет ресурсы и выявить подозрительную активность на уровне системных вызовов.

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

Итоги

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

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

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

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами.

Меня зовут Вадим Ваганов, я руководитель разработки и Head of Profession Backend в Газпромбанке. Я люблю делиться опытом, а также обучать и приносить пользу другим. Все свои статьи я строю на личных историях, так что эта будет такой же. Она для тех, кто только начинает свой путь в бэкенд-разработке и еще не вник в вопросы визуализации своей работы. Расскажу, почему стоит инвестировать время в эти направления и как благодаря им вы станете более крутым инженером с первых шагов в профессии.

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

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

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

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

Начинаем с простого: получаем данные о состоянии приложения

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

Подготовка окружения

Для примера нам понадобятся:

• Docker
• JDK 17

Все придумано до нас, поэтому воспользуемся готовыми инструментами — например, micrometer (документация тут) или аналог, если у вас не Java/Kotlin. Интегрируем его с /actuator.

В build.gradle нужно добавить следующее:

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

и смотрим на метрики:

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

У нас есть заготовленный конфиг, чтобы поднять Grafana и Prometheus:

Открываем UI Prometheus, пробуем найти demo_requests_total, нажимаем Execute, проверяем историчность — она есть!

Теперь можно визуализировать данные. Открываем Grafana, вводим admin/admin и создаем дашборд:

1. Dashboards -> Create Dashboard -> Add visualization
2. Конфигурируем Data Source: Configure a new data source -> Prometheus -> Connection = http://prometheus:9090 -> Save & test
3. Возвращаемся к меню Create Dashboard -> Add visualization, выбираем Data Source prometheus
4. Настраиваем дашборд: выбираем Code вместо Builder, пишем sum (rate(demo_requests_total[1m]))

Отлично! Давайте накидаем еще запросов, чтобы посмотреть, как это будет выглядеть:

Теперь у нас на графике видна динамика запросов. Инструментарий готов! Теперь мы можем:

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

Что отслеживать в бэкенд-приложениях

У вас когда-нибудь было состояние, когда вам плохо, болит голова, першит горло, и вы думаете, что все — у вас 38 °C, и вы жутко простудились. Берете градусник, измеряете температуру... А у вас 36.6 °C. Не полагайтесь на ощущения — смотрите в мониторинг!

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

• Загруженность CPU и памяти серверов.
• Загруженность дисков.
• Мониторинг сети.
• И другие инфраструктурные метрики.

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

Метрики производительности приложения

В SRE Google выделяют 4 золотых сигнала:

1. Latency (задержка) — время, необходимое для обработки запроса;
2. Traffic (трафик) — количество запросов к системе;
3. Errors (ошибки) — процент запросов, которые заканчиваются ошибкой;
4. Saturation (насыщение) — насколько система загружена.

ВАЖНО: иногда ваше приложение начинает работать медленно из-за интеграций, поэтому их тоже просто необходимо отслеживать. Если провайдер данных отвечает за 1 с, а у вас в SLA — 250 мс, то как бы производительно и надежно ни было ваше приложение — у вас уже проблемы.

Бизнес-метрики

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

Если вы проверяете гипотезы или проводите a/b-тестирование — собирать и визуализировать метрики просто обязательно.

Красиво — это не только про визуал. Получать обратную связь и взаимодействовать с системой/продуктом — тоже красиво!

Почему мониторинг — это навык, который стоит прокачать любому инженеру

Мониторинг как важная составляющая DevOps- и SRE-практик

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

Взаимодействие мониторинга с процессами CI/CD

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

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

Универсальный и вечнозеленый навык

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

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

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

Возможность предвидеть и предотвращать проблемы

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

Подведение итогов

Метрики — это то, что ты хочешь смотреть не только когда плохо, но и когда хорошо.

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

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

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

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

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

Так что если вы еще не начали заниматься мониторингом, самое время начать. У вас есть все инструменты и все возможности — вы можете скачать наш репозиторий и начать вникать прямо сейчас.

Полезные источники

• Официальная документация Micrometer
• Официальная документация Prometheus
• Официальная документация Grafana
• 4 золотых сигнала
• Книга об SRE

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

Что вообще такое context collapse

Есть вероятность, что вы слышите этот термин в первый раз. Немного лирики: в мире микросервисов есть два понятия: технический контекст и доменный контекст (Bounded Context).

Технический контекст

Технический контекст — это информация, которая передается между микросервисами для выполнения запросов или операций. В нем лежит большое количество данных: идентификаторы запросов (например, TraceID в трассировке), пользовательские сессии, метаданные или параметры аутентификации.

Без технического контекста микросервисы не могут:

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

Доменный контекст (Bounded Context)

Доменный контекст происходит из методологии Domain-Driven Design (DDD) — это про четкое разделение бизнес-логики между микросервисами. У каждого сервиса должна быть своя «ограниченная область» (Bounded Context), где термины, данные и правила имеют уникальное значение.

Например, в интернет-магазине слово «заказ» может означать разные вещи для сервиса оплаты (финансовая транзакция) и сервиса доставки (отправка покупателю). Если границы контекста не определены четко, возникает путаница: сервисы начинают дублировать логику или интерпретировать данные по-разному.

Без доменного контекста:

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

Вернемся к коллапсу контекста

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

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

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

Что на самом деле происходит

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

Сервис теряет важное состояние, например:

• «Это корзина Пети»
• "Этот платеж уже прошел"

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

В 2025 году появляется все больше слишком фрагментированных архитектур и гипермасштабируемых систем. Ваши запросы могут проходить через 10, 20 и даже 30 сервисов, но если на каком-то этапе отвалился контекст, то это конец.

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

Как понять, что контекст вот-вот может «коллапснуться»

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

• Всплеск пинга: сервисы запрашивают данные, которые должны бы уже знать, создавая огромное количество лишних вызовов и перегружая API.
• Дублирующиеся действия: повторные списания, задвоенные отправки писем, неожиданные повторные заказы. Пользователи возмущены, рейтинг падает.
• Мистические баги: логи говорят «всё в порядке», но результат явно неверный. Код не видит проблему, а отладка превращается в кошмар.

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

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

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

Опрос CNCF за 2024 год показал, что 68% команд, которые используют микросервисы, сталкиваются с необъяснимыми проблемами производительности. И всему виной в том числе контекстный коллапс.

5 решений, как бороться с контекстным коллапсом

Да, контекстный коллапс — крайне неприятный баг. Главное — чтобы все сервисы работали слаженно и «знали» друг друга.

1. Правильно передавайте контекст

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

Вот пример реализации middleware автором на Go:

2. Кэшируйте с умом

Нет смысла заставлять сервисы угадывать, если они просто могут запомнить. Быстрый кэш, например, с Redis, может хранить временный контекст — например, токены сеанса или состояния запросов, — поэтому сервисы не будут постоянно спрашивать «кто это?» Вот фрагмент кода на Питоне, где используется Redis для хранения и извлечения контекста:

Это позволяет поддерживать контекст во всех вызовах, не перегружая вашу базу данных. А еще TTL (time-to-live) Redis сам за собой убирает — устаревшие данные не скрываются.

3. Используйте Event-Driven Architecture

Микросервисы без сохранения состояния выглядят отлично, пока не контекст не коллапснется. Событийная архитектура идет от обратного: вместо того чтобы надеяться, что службы все запомнят, регистрируйте каждый шаг как событие. Если служба все-таки забудет, воспроизведите поток. Вот пример на Node.js с Kafka:

Здесь также можно использовать RabbitMQ. В общем, больше никаких отговорок со стороны сервиса из разряда «я забыл».

4. Проверяйте логи

Когда контекст теряется, логи — ваше место преступления. Настройте Grafana Loki или Datadog для поиска «потерянных контекстов». Вот пример с Grafana:

Тэгните логи с помощью request_id или user_id, а затем вызовите Loki:

5. Тестируйте на коллапсы

Профилактика лучше, чем лечение. Добавьте хаос-тестирование с помощью, например, Chaos Mesh, чтобы моделировать потери контекста.

Хаос-тестирование — это метод преднамеренного введения сбоев в систему, чтобы проверить, насколько она устойчива и надежна. Обычное тестирование и мониторинг могут выявить проблемы, но хаос-тестирование (Chaos Engineering) помогает увидеть, как система поведет себя в случае неожиданных отказов.

Прервите mid-requests к сервисам — сможет ли система восстановится в таком случае? Если нет, значит, ваша передача контекста недостаточно надежна.

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

Компания Elastic объявила о добавлении лицензии AGPL в качестве опции наряду с существующими ELv2 и SSPL.

Этот шаг позволяет использовать термин «Open Source» в соответствии с определением OSI (Open Source Initiative), что вызвало большую радость как минимум у самой команды Elastic.

История изменений лицензии

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

Это изменение вызвало значительные дискуссии в сообществе и многие обвинили Elastic в отходе от принципов Open Source.

Однако, по словам представителей компании, это решение помогло устранить путаницу на рынке и укрепило партнерские отношения с AWS.

Возвращение к истокам

Теперь, когда ситуация на рынке стабилизировалась, Elastic решила вернуть Elasticsearch статус Open Source, добавив AGPL в качестве одной из лицензий.

AGPL — это лицензия, одобренная OSI и широко используемая в таких проектах, как MongoDB и Grafana.

Что дальше?

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

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

В этой статье мы расскажем, что такое Grafana, каковы возможности этой платформы, как установить и как использовать Grafana в различных проектах.

Grafana полезнее всего воспринимать не отдельно, а как часть общего DevOps-пути. Если нужен полный контекст — от первого деплоя до наблюдаемости и инцидентов, посмотрите Roadmap DevOps-инженера в 2026 году: что учить и в каком порядке.

Grafana — open-source платформа для визуализации данных и мониторинга: превращает метрики из любых источников в интерактивные дашборды.

Поддерживает сотни источников данных — Prometheus, PostgreSQL, MySQL, Graphite, облачные сервисы и многое другое.

Есть бесплатная облачная версия (Grafana Cloud) и self-hosted вариант без ограничений по числу пользователей.

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

Grafana vs Kibana: Grafana лучше для метрик и дашбордов, Kibana — для анализа логов в стеке Elastic.

Что такое Grafana

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

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

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

В числе ключевых характеристик платформы:

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

Grafana можно установить на все распространенные операционные системы, включая Windows и Linux во всех модификациях.

С чем взаимодействует Grafana

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

Перечислим наиболее популярные источники, с которыми взаимодействует платформа:

• Базы данных. Сюда входят все популярные базы данных, в том числе PostgreSQL, MySQL, SQLite. Сервис анализирует информацию, хранящуюся на этих площадках и визуализирует ее в виде диаграмм различного типа, графиков, таблиц.
• Сервисы мониторинга. Grafana легко интегрируется с широко известными системами мониторинга, в том числе с Prometheus и Graphite. Благодаря интеграции на дашбордах можно наглядно отследить статус системы с помощью различных метрик и данных.
• Временные ряды (статистика) и интерфейсы API. На платформе можно работать со статистическими материалами любого типа — например, данными о производственных процессах, сведениями о температуре в помещениях, сетевом трафике.
• Плагины. Инструмент работает со множеством плагинов, которые существенно расширяют его функции. Эти программные модули применяются для подключения новых источников информации и интеграции с разными сервисами и системами.

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

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

Визуализация на платформе Grafana

Визуализация в Grafana — ключевая опция проекта. Система отображает сведения различного характера в наглядном и понятном виде. Визуализация нужна для мониторинга, анализа и управления данными.

Рассмотрим рабочие элементы платформы.

Панель

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

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

Дашборд

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

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

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

Аннотации

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

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

Дополнительные функции

Сообщество разработчиков на Github создает дополнительные возможности для удобной работы с инструментами.

К ним относятся:

• Шаблоны. Пользователи создают шаблоны дашбордов, чтобы использовать нужные конфигурации и параметры панелей. Это ускоряет и облегчает процесс создания дашбордов. Настройки можно использовать для других типов данных.
• Автоматизация. Работу Grafana можно автоматизировать с помощью программных интерфейсов, плагинов и интеграций с другими продуктами. Таким способом можно автоматически создавать панели, настраивать уведомления, обновлять конфигурации дашбордов.
• Экспорт данных. На платформе можно экспортировать информацию в любые форматы включая PNG, PDF, CSV. Такая опция нужна для сохранения результатов мониторинга или формирования аналитических отчетов.
• API. Grafana предоставляет интерфейс для управления и точной настройки. С помощью API пользователи создают, видоизменяют и удаляют дашборды, настраивают уведомления, запрашивают данные и т.д.
• Оповещения и уведомления. На платформе есть настройки оповещений, которые срабатывают при наступлении заданных условий. Опция нужна для оперативного реагирования на события и результаты.
• Ограничение прав. Опция позволяет управлять доступом и разграничивать права пользователей в зависимости от их статуса и выполняемых обязанностей.

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

Как установить

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

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

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

Практическое применение инструмента Grafana

Существует множество способов использования Grafana в различных проектах.

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

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

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

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

Практикуется интеграция с сервисом Google Analytics или Яндекс Метрика. С помощью аналитики предприниматели проводят мониторинг клиентских запросов, оптимизируют цикл взаимодействия аудитории, вносят своевременные изменения в ассортимент.

Итоги

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

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