Как построить единую платформу наблюдаемости: опыт Albert Heijn
Сложности децентрализованного подхода к мониторингу
В крупной продуктовой розничной сети Albert Heijn штат ИТ-департамента составляет от 1500 до 1800 инженеров, разделенных на 8 автономных подразделений (клиентский сервис, логистика, управление магазинами и другие). До 2021 года каждое подразделение развивало собственную ИТ-стратегию, включая уникальные структуры команд и независимые технологические стеки. Это привело к крайней фрагментации инструментов мониторинга и наблюдаемости (observability).
Внутри организации использовались сотни разрозненных решений. Одно из крупных подразделений содержало собственную команду мониторинга, поддерживающую дорогостоящие кластеры ELK (Elasticsearch, Logstash, Kibana). При этом разработчики не имели прямого доступа к настройкам и отправляли заявки на создание дашбордов через тикет-систему. Другое подразделение эксплуатировало устаревшую систему Nagios, требовавшую колоссальных усилий на поддержку. Третьи разворачивали локальные связки Grafana, ELK и Thanos, закрытые от остальных команд. Многие команды использовали встроенные облачные инструменты Azure Monitor или коммерческую платформу Dynatrace, а часть систем вообще не имела никакого мониторинга. Единого стандарта оповещений не существовало, а конфигурационные файлы Alertmanager у некоторых команд разрастались до тысяч строк. Такая разрозненность приводила к высоким расходам на лицензии и увеличивала время обнаружения и устранения аварий (MTTR), так как инженерам приходилось сопоставлять данные из разных источников вручную.
Создание единого центра компетенций
Для оптимизации инфраструктуры и повышения эффективности разработки компания приняла решение отказаться от локальных стратегий. В рамках реформы было создано централизованное подразделение Engineering Enablement Department (EEP), выполняющее роль платформенного отдела. Одной из ключевых команд внутри EEP стала группа по наблюдаемости (observability team), сформированная из инженеров, ранее поддерживавших разрозненные системы в продуктовых отделах.
Вместо точечной помощи отдельным командам новая группа сосредоточилась на создании единого масштабируемого решения, предоставляемого по модели самообслуживания (self-service). Основная идея платформенного подхода заключалась в четком разграничении зон ответственности:
- Платформенная команда отвечает за работоспособность, масштабирование, безопасность и обновление инфраструктуры мониторинга.
- Продуктовые команды разработки самостоятельно настраивают свои дашборды, правила оповещений и подключают библиотеки мониторинга к своим приложениям без необходимости отправки тикетов.
Выбор технологического стека: Grafana LGTM и OpenTelemetry
При проектировании централизованной платформы команда Albert Heijn сделала ставку на открытые стандарты и современный стек Grafana LGTM (Loki, Grafana, Tempo, Mimir), развернутый в облачной инфраструктуре Microsoft Azure.
Технологический выбор обоснован следующими факторами:
- Grafana служит единым интерфейсом для визуализации всех типов данных наблюдаемости. Интеграция с корпоративной системой управления доступом (IAM) позволяет инженерам использовать сквозную авторизацию.
- Grafana Mimir используется для долгосрочного хранения метрик, успешно заменив разрозненные инсталляции Thanos.
- Grafana Loki применяется для агрегации логов. Loki хранит логи в дешевом объектном хранилище и индексирует только метаданные, что позволило кардинально снизить затраты на диски по сравнению с классическим ELK-стеком.
- Grafana Tempo внедрена для сквозной трассировки запросов (distributed tracing), помогая отслеживать путь прохождения запросов между микросервисами.
- OpenTelemetry принят в качестве единого открытого стандарта сбора данных (вендор-нейтральный протокол). Использование агентов и библиотек OpenTelemetry гарантирует защиту от привязки к конкретному поставщику (vendor lock-in) и позволяет унифицировать код сбора метрик и трассировок для приложений на различных языках программирования.
Сложности внедрения непрерывной поставки (Continuous Delivery)
При переходе к платформенному подходу команда наблюдаемости столкнулась с организационными вызовами. Изначально большинство инженеров команды имели классический опыт системного администрирования и эксплуатации, но не были знакомы с современными практиками разработки ПО, такими как автоматизированное тестирование (TDD), trunk-based разработка, эфемерные окружения и непрерывное развертывание (CD).
Чтобы ускорить выпуск минимально жизнеспособного продукта (MVP) платформы, руководство решило возложить проектирование базовой архитектуры и инфраструктуры CI/CD на одного ведущего инженера (staff engineer). Остальные члены команды на первом этапе продолжали поддерживать старые локальные системы. Такое решение вызвало определенное недовольство внутри коллектива, желавшего сразу включиться в работу над новой платформой. Тем не менее, это позволило в кратчайшие сроки развернуть среду тестирования и автоматической доставки изменений. Когда MVP был готов, остальные инженеры быстро переняли новые практики. Возможность протестировать изменения локально, автоматически проверить их в пайплайне и выкатить в продакшн без ручного вмешательства убедила всю команду в преимуществах DevOps-подхода. Этот опыт показал, что для успешного создания платформы необходим сбалансированный состав команды из инженеров с опытом как разработки программного обеспечения, так и системного администрирования.
Внедрение идеологии "You build it, you run it"
Дополнительным барьером стали опасения со стороны продуктовых подразделений и руководства. Некоторые отделы не хотели терять контроль над собственными системами мониторинга, а разработчики опасались роста когнитивной нагрузки, связанной с необходимостью самостоятельно настраивать дашборды и отвечать за дежурства на поддержке.
Чтобы преодолеть сопротивление, платформенная команда сосредоточилась на создании качественной документации и оперативных каналов поддержки в корпоративном чате. Пилотные группы разработчиков, первыми опробовавшие self-service возможности платформы, быстро оценили удобство отсутствия очередей и стали главными сторонниками миграции в своих отделах. Интеграция с существующим сервисом Opsgenie позволила сохранить привычные схемы дежурств, сделав переход комфортным.
Ударная миграция и системный шок
Чтобы завершить затянувшуюся миграцию, руководство компании установило жесткий дедлайн для крупного департамента департамента численностью около 500 инженеров. Была организована двухдневная рабочая сессия, в рамках которой все продуктовые команды одновременно переносили мониторинг своих приложений на новую платформу. В соответствии с принципами платформенного проектирования, сама миграция выполнялась продуктовыми командами, а команда EEP оказывала лишь консультационную поддержку.
Этот шаг позволил быстро отключить старые кластеры Elastic и Thanos, однако вызвал временный системный шок:
- Разработчикам не хватило времени детально освоить новые инструменты, что привело к росту вопросов в чатах поддержки.
- Нагрузка на Loki и Mimir резко возросла, что негативно сказалось на скорости выполнения поисковых запросов в Grafana.
- Инженерам платформы пришлось в экстренном режиме оптимизировать кэширование, масштабировать дисковые массивы и настраивать параллельную обработку тяжелых запросов.
Креативное использование платформы (Serendipity)
Главным показателем успеха платформенного решения стало появление неожиданных сценариев использования, которые разработчики придумали самостоятельно:
- Мониторинг сетевого оборудования: Сетевые инженеры настроили сбор логов и метрик с физических и виртуальных маршрутизаторов через Syslog прямо в Loki.
- Аналитика без доработки приложений: Администраторы баз данных начали строить отчеты, опрашивая базы напрямую из Grafana без изменения кода систем.
- Мониторинг розничной инфраструктуры: Команды, отвечающие за физическое оборудование в супермаркетах, настроили отправку телеметрии с кассовых аппаратов, что позволило мгновенно выявлять сбои на кассах самообслуживания.
- Контроль файловых серверов: Разработчики автоматизировали проверку загрузки отчетов, настроив алерты на случай зависания фоновых процессов обмена файлами.
Достигнутые результаты
За один год промышленной эксплуатации единую платформу наблюдаемости внедрили 75% продуктовых команд компании. Решение позволило сократить расходы на инфраструктуру мониторинга на 70% и высвободить 25 инженеров от рутинной поддержки локальных серверов. Один из департаментов зафиксировал снижение среднего времени устранения инцидентов (MTTR) на 50% благодаря интеграции логов, метрик и трассировок в одном интерфейсе. На пике система обрабатывает до 8000 запросов и 300 МБ данных в секунду, а в базе данных Mimir хранится более 80 миллионов метрик, реплицируемых для обеспечения отказоустойчивости.