Observability-платформа Albert Heijn: путь за 2 года

Путь к новой системе

В конце 2023 года перед командой инженеров поставили задачу: решить проблемы наблюдаемости (observability) в Albert Heijn, Etos и Gall&Gall.

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

Немного истории

Albert Heijn — дочерняя компания Royal Ahold Delhaize — супермаркет с богатой историей: он был основан ещё в 1887 году. Сегодня это лидер рынка Нидерландов с долей 37,7% (данные за 2024 год), прошедший через периоды стремительного роста и насчитывающий сейчас около 1200 магазинов. Компания пережила несколько слияний и поглощений. Ретейлеры Etos и Gall&Gall входят в одну ИТ-организацию с Albert Heijn. Всё это привело к крайне разнородному ИТ-ландшафту.

В 2023 году в ИТ-организации Albert Heijn работало около 1500 человек (к 2025-му их стало 1800). Организация состоит из 8 департаментов: Customer, Data, Stores и других. Вплоть до 2021 года каждый департамент следовал собственной локальной ИТ-стратегии — со своей организационной структурой (с agile-лидами или без, с архитекторами и советами по согласованиям или без) и собственным технологическим стеком. Команды внутри одного департамента могли работать с совершенно разными инструментами и подходами.

Конец 2023 года совпал с финальной фазой миграции Albert Heijn в публичное облако (преимущественно Microsoft Azure): часть приложений прошла модернизацию, часть была перенесена по принципу lift-and-shift с физических или виртуальных серверов.

Локальный контекст

В 2021 году было принято решение отказаться от локальных ИТ-стратегий в пользу централизованной. Чтобы извлечь выгоду из эффекта масштаба, создали новый департамент — Engineering Enablement Department, или EEP. По сути, это платформенный департамент, включающий несколько платформенных команд. Их задача — создавать масштабируемые системы, которыми могут пользоваться другие команды организации.

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

ИТ-ландшафт по-прежнему оставался крайне разнородным. Например:

В одном департаменте, насчитывающем несколько сотен инженеров, работала выделенная команда мониторинга, которая поддерживала несколько сложных и дорогостоящих ELK-стеков. При этом именно эта команда создавала все дашборды и алерты для инженерных команд. Запросы на новую функциональность наблюдаемости поступали через систему тикетов.
Другой департамент опирался на Nagios, поддержка которого требовала значительных усилий.
Один департамент самостоятельно размещал собственный стек наблюдаемости на базе Grafana, ELK и Thanos. Доступа к этому инстансу Grafana у других департаментов не было. Стек находился в ведении команды SRE, а после её роспуска ответственность перешла к отдельным старшим инженерам.
Из-за отсутствия альтернатив многие команды начали использовать управляемые Azure-решения для наблюдаемости: Azure Data Explorer, Azure Monitor и Azure Log Analytics.
Часть команд использовала SaaS-решения, в частности Dynatrace.
У многих команд не было никакой наблюдаемости вовсе. Большинство воспринимало её как набор закладок на дашборды, когда-то созданные кем-то из коллег.
Помимо обязательного использования Opsgenie, общеорганизационной стратегии алертинга не существовало. Многие команды самостоятельно настраивали интеграции внутри Opsgenie и поддерживали собственные конфигурационные файлы Alertmanager. Самый крупный из них насчитывал несколько тысяч строк.
Как уже отмечалось, ИТ-ландшафт был и остаётся крайне фрагментированным: множество языков программирования и фреймворков, разнообразие баз данных, систем кеширования, механизмов очередей, сред выполнения приложений (виртуальные машины, Kubernetes, serverless, low-code и т.д.) и решений для наблюдаемости.
Уровень зрелости разработки у команд и департаментов существенно различался. Одни прошли DevOps-трансформацию и придерживались принципа «ты построил — ты и запускаешь». Другие полагались на архитекторов при проектировании, системных администраторов при эксплуатации и команды мониторинга при наблюдении.

Проблемы

Ситуация с наблюдаемостью в 2023 году поставила перед руководством две ключевые проблемы: операционные издержки и высокое среднее время восстановления (MTTR).

Операционные издержки

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

Высокое MTTR

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

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

Перестройка системы

Август 2023 года мы полностью посвятили анализу состояния наблюдаемости в Albert Heijn. Инженерным командам либо не хватало подходящих инструментов, либо они не могли перевести свою команду или приложения на существующую систему. У многих команд не было автономии для создания дашбордов, алертов и т.д. Прежняя стратегия команды наблюдаемости — предоставлять строительные блоки и локальную поддержку отдельным департаментам и командам — не давала результата.

Мы начали формировать видение платформы наблюдаемости, которой инженерные команды предпочли бы пользоваться вместо существующих решений. Опираясь на собственный опыт построения масштабируемых, самообслуживаемых (self-service) и мультиарендных (multi-tenant) платформ, мы также черпали вдохновение из работ других:

Accelerate и программа исследований DORA — исчерпывающий ресурс о том, как создавать более результативные инженерные организации
Team Topologies — как выстраивать организации для быстрого потока создания ценности
Труды Грегора Хопе (Gregor Hohpe) — как проектировать успешные платформы

В итоге мы поставили перед собой следующие цели:

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

Среди ключевых свойств платформы, к которым мы стремились, вместе с соответствующими компромиссами, были следующие:

Качество

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

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

Ради высокого качества нам предстояло изменить подход к работе внутри команды наблюдаемости: принять продуктовое мышление и практиковать TDD (разработку через тестирование) и непрерывную поставку (continuous delivery). Это означало необходимость обучать платформенных инженеров или нанимать новых.

Чёткие границы владения

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

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

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

Единый источник истины

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

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

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

Простота подключения (onboarding)

Пользователи должны автоматически получать доступ к платформе без необходимости создавать тикет или мёрдж-реквест.

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

Простота освоения (adoption)

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

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

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

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

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

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

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

Принятые решения

Для создания «SaaS»-подобного решения мы выбрали самохостируемый единый инстанс стека LGTM от Grafana Labs в качестве ядра платформы наблюдаемости:

Grafana — для графиков
Alertmanager и Opsgenie — для алертов
Loki — для логов
Tempo — для трейсов
Mimir — для метрик

Выбор в пользу Grafana был обусловлен следующим:

Многие команды уже работали с Grafana и были знакомы с её интерфейсом. Это также позволяло командам перенести существующие дашборды в новый инстанс, упрощая переход на платформу.
Grafana — проект с открытым исходным кодом, лидирующий в развитии Prometheus и OpenTelemetry. Вокруг этих технологий существует огромное количество готовых интеграций, что даёт командам множество вариантов использования платформы.
Возможность частичного перехода на новую платформу благодаря подходу «большого шатра» (big tent): Grafana поддерживает подключение почти ко всем имевшимся в Albert Heijn источникам данных. Команды могут продолжать опираться на существующие хранилища, внося при этом вклад в единый источник истины.
Автоматизация через API с помощью, например, Terraform или Kubernetes-операторов. Это позволяет платформенной команде автоматически подключать новых пользователей или создавать эфемерные среды для написания тестов.

Opsgenie был выбран по следующим причинам:

Opsgenie уже используется во всей организации для алертинга и интегрирован с ServiceNow.
Лицензия оставалась действующей ещё несколько лет.

Alertmanager был выбран потому, что:

Prometheus и Alertmanager уже применялись в большинстве департаментов.
Alertmanager интегрируется со всеми компонентами стека LGTM.

Преимущества Loki, Mimir и Tempo состояли в следующем:

Все три компонента нативно интегрируются с Grafana.
Экономичность: их вычислительные ресурсы могут работать преимущественно на spot/preemptive виртуальных машинах, а телеметрия хранится в дешёвом объектном хранилище.
Высокая масштабируемость. Поскольку мы стремимся создать единый источник истины, базы данных должны уметь обрабатывать огромные объёмы данных.
Перспективная поддержка OpenTelemetry. Мы хотели задействовать opentelemetry-collector — агент, независимый от конкретного вендора, для сбора, обработки и экспорта телеметрии. Команда, перешедшая на коллектор сейчас, не будет вынуждена менять агент даже при смене технологии за платформой наблюдаемости.
Loki не требует структурирования логов до их приёма. Вместо этого логи разбираются во время запроса. Это значит, что можно принимать любые логи вне зависимости от их формата. Платформенная команда задала минимальный набор обязательных метаданных, которому могут следовать все команды, что упрощает начало отправки логов.
Mimir — это база данных временных рядов на базе Prometheus, использующая язык запросов PromQL. Prometheus, Thanos и PromQL уже широко применялись в Albert Heijn, поэтому мы рассчитывали, что LogQL от Loki и TraceQL от Tempo покажутся инженерным командам знакомыми.

Дополнительно мы выбрали следующие приоритетные точки интеграции:

OpenTelemetry — OTEL становился протоколом по умолчанию для приёма данных. Это давало гарантию: если когда-либо придётся снова менять решение для наблюдаемости, инструментирование и сбор данных менять не придётся — достаточно будет указать новый эндпоинт.
Prometheus — широко используется в Kubernetes-среде, которая является стандартной средой выполнения приложений в Albert Heijn.
Microsoft Azure — Grafana нативно поддерживает Azure Monitor и ADX. Помимо этого, мы планировали разработать самообслуживаемое решение для перенаправления Azure Diagnostic Logs в Loki.
Syslog — многие сторонние устройства поддерживают только syslog для экспорта телеметрии. Мы планировали создать syslog-эндпоинт, сохраняющий логи в Loki.
Linux/Windows — мы планировали задокументировать оптимальные способы сбора телеметрии с виртуальных машин и запущенных приложений с отправкой на платформу наблюдаемости.

Хронология событий

Август 2023 — Руководство EEP поручает команде наблюдаемости найти решение проблем наблюдаемости. Нанят новый стафф-инженер для руководства инициативой. В течение августа команда собирает требования, беседует со стейкхолдерами существующих решений и получает обратную связь от инженерного руководства. По итогам исследования подготовлен первоначальный дизайн платформы на базе LGTM-стека и OpenTelemetry.

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

Октябрь 2023 — Платформа выходит в «альфа»-версию. Первые предоставляемые сервисы — мультиарендный инстанс Grafana с корпоративной лицензией и централизованный Alertmanager, подключённый к Opsgenie. Grafana интегрирована с существующими IAM-решениями, что обеспечивает автоматическое подключение всех инженеров. Команда наблюдаемости начинает добавлять существующие источники данных в Grafana. Другие команды EEP приступают к тестированию платформы. К этому времени CI/CD-примитивы работают ожидаемым образом: воспроизводимые эфемерные среды, набор тестов и конвейер непрерывной поставки. Остальные члены команды наблюдаемости начинают вносить вклад в новую платформу, изучая и применяя внедрённые практики современной разработки.

Декабрь 2023 — Платформа выходит в «бета»-версию. Запущены Loki, Mimir и Tempo. Инженеры за пределами команды наблюдаемости начинают добавлять источники данных в Grafana. Команда приступает к формализации режимов взаимодействия с платформой. Несколько каналов коммуникации объединяются в единый канал поддержки наблюдаемости в Microsoft Teams, с акцентом на качественное обслуживание. Плохо посещаемые общие встречи заменяются сессиями совместной работы по запросу. Команда начинает активно документировать платформу: всё больше вопросов в канале поддержки удаётся закрыть ссылкой на соответствующую документацию.

Q1 2024 — Вскоре после этого платформа выходит в «общую доступность» (GA). Команда наблюдаемости добавила все известные источники данных в Grafana. При участии других платформенных команд Kubernetes-кластеры настроены на автоматическую отправку логов, метрик и трейсов приложений на платформу. Разработан план по выводу из эксплуатации всех существующих инстансов Alertmanager. Команда помогает настроить инстансы Prometheus из кластеров под управлением EEP для отправки алертов в новый Alertmanager. Команды за пределами EEP начинают использовать платформу вместо собственных решений.

Q2 2024 — Инженерные команды получают запрос перенастроить свои дашборды на использование Mimir вместо отдельных инстансов Prometheus. Создан самообслуживаемый интерфейс для приёма Azure Diagnostic Logs в Loki. Для сетевых команд реализована интеграция с Syslog.

Q3 2024 — Руководство одного из департаментов (~500 инженеров) объявляет о стратегической миграции на новую платформу наблюдаемости, отказываясь от собственных Grafana, Thanos и нескольких кластеров Elastic. После нескольких недель подготовки со стороны инженерного руководства департамента большинство команд завершили миграцию в ходе двухдневного очного спринта совместно с командой наблюдаемости. В истинном духе платформенной инженерии миграции выполнялись самими инженерными командами, а не платформенной командой. Несколько недель после этого команда наблюдаемости сосредоточилась на улучшении производительности запросов в Loki и Mimir после столь масштабной миграции, значительно поработав над настройкой параллелизации запросов и кеширования.

Q4 2024 — Команде наблюдаемости поручено предоставить решение для мониторинга реальных пользователей (RUM — Real-User Monitoring). Начато создание proof-of-concept на базе Grafana Faro. Тем временем платформа продолжает расти: к этому моменту выделенный Kubernetes-кластер достигает примерно 700 узлов.

Q1–Q4 2025 — Отключены все старые инстансы Alertmanager. Отключены все старые инстансы Grafana. Поэтапно отключается всё больше кластеров Elastic.

Результаты

Оглядываясь назад, мы можем гордиться следующим:

Примерно 75% всех инженерных команд перешли на платформу уже через год после выхода в GA, согласно внутренним опросам по Developer Experience. Grafana сейчас насчитывает около 700 уникальных посетителей в месяц и более 200 уникальных посетителей в день.
Совокупные затраты на инфраструктуру и лицензии для наблюдаемости сократились примерно на 70%.
Около 25 инженеров за пределами команды наблюдаемости избавились от необходимости тратить время на поддержку собственных решений.
Один из департаментов зафиксировал снижение MTTR на 50% после перехода на платформу.
В пиковое время эндпоинты приёма данных Prometheus, Loki и OpenTelemetry суммарно обрабатывают 8 000 (восемь тысяч) запросов в секунду при пропускной способности 300 (триста) мегабайт в секунду.
Mimir управляет примерно 80 000 000 (восемьюдесятью миллионами) активных временных рядов, реплицированных троекратно для обеспечения высокой доступности.
Команда наблюдаемости продолжает развиваться как высокоэффективная команда, разделяющая ценности сотрудничества, непрерывной поставки, надёжности, документирования и поддержки.

Трудности на пути

Груз инерции команды

Чтобы обеспечить желаемое качество, мы с самого начала хотели выстроить непрерывную поставку и сопутствующие практики. Однако инженеры команды наблюдаемости не имели никакого опыта работы с эфемерными средами, trunk-based development, разработкой через тестирование или непрерывным развёртыванием — не говоря уже о значительной части новых технологий, лежащих в основе платформы. Опыт работы в предыдущих платформенных командах подсказывал нам: внедрять эти практики с нуля в команде, которая никогда с ними не работала, крайне сложно. Нужно не только научить людей применять их, но и убедить в их ценности — а это приходит, как правило, лишь из личного опыта. Как бы провокационно это ни звучало, мы в своих взглядах не одиноки. Поэтому мы решили, что команде наблюдаемости сначала лучше поработать в среде, где эти практики уже существуют. Но, как уже отмечалось, такой среды не было. Руководство приняло решение: стафф-инженер команды заложит основу подхода к работе и доставит первый MVP новой платформы наблюдаемости, пока остальные члены команды продолжают поддерживать существующие решения. Вскоре после появления MVP вся команда приступит к работе над новой платформой.

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

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

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

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

Превышение скорости

Как уже говорилось, до создания EEP каждый департамент следовал собственной локальной ИТ-стратегии. Неудивительно, что департаменты и их руководители с осторожностью относились к переходу на систему, находящуюся вне их контроля: прежде у них была полная власть над своими решениями для наблюдаемости (или их отсутствием). В каждом департаменте работали собственные комитеты по надзору, согласовывающие использование новых технологий. Несмотря на жёсткие процедуры управления внедрением технологий, мы демонстрировали ценность через небольшие инициативы, успех которых давал руководящим комитетам импульс для ускоренного согласования более широкого внедрения. Гибкий подход к выбору инструментов согласуется с выводами книги Accelerate, согласно которым инженерные команды работают результативнее, когда им предоставляется свобода в выборе инструментов.

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

«Вы построили — вы и запускаете»

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

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

Системный шок

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

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

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

Неожиданные эффекты

Неожиданное применение — ключевой признак успешной платформы. Успешная платформа позволяет пользователям творчески находить новые решения. Этому способствуют упомянутые ранее качества: прежде всего самообслуживание, низкий барьер подключения и ряд стандартизационных решений. Наша платформа стандартизировала Grafana для визуализации и запросов, а также несколько API и протоколов для приёма данных: OpenTelemetry, Prometheus, Syslog и другие. Нас очень радует, что инженерные команды нашли самые разнообразные нестандартные способы использовать платформу. Вот несколько примеров:

Сетевые команды собирают комбинацию сигналов OpenTelemetry и событий Syslog для мониторинга ландшафта виртуальных и физических устройств.
Функциональные администраторы приложений используют Grafana для запросов к базам данных своих приложений, чтобы формировать отчёты и получать аналитику без необходимости вносить изменения в сами приложения.
Мониторинг традиционных файловых рабочих процессов теперь можно автоматизировать: команды собирают сигналы о загрузках на файловые серверы и генерируют алерты при сбое процесса.
Распределительные центры собирают информацию из различных источников, чтобы убедиться, что операционные процессы продолжают соответствовать ожиданиям.
Инженерные команды, отвечающие за физические устройства в супермаркетах, собирают сигналы OpenTelemetry с кассовых терминалов — это позволяет мгновенно обнаруживать сбои, которые влияют на покупателей.
… и многое другое. Все инженерные команды, стремящиеся наблюдать за своими системами, стали воспринимать платформу наблюдаемости как первый выбор.

Платформы ускоряют разработку, снижая трение. […] Снижение трения — это не просто ускорение разработки, это изменение того, как работают команды.

— Gregor Hohpe
Platform Strategy

Следующие шаги

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

Добавить поддержку SNMP walks и трапов (traps)
Создать «проторенные пути» (paved roads) для наблюдения за системами администраторами баз данных (DBA)
Предложить более масштабируемое решение для мониторинга реальных пользователей (RUM)
Активнее продвигать использование SLI и SLO

Наблюдая за успехом новой платформы, другие команды за пределами Albert Heijn, Etos и Gall&Gall также проявили к ней интерес. Для платформенной команды может открыться возможность подключить эти команды к текущему инстансу или просто поделиться опытом своего пути.

Заключительное слово

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

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

Об авторах

Барт Рейндерс (Bart Rijnders) — стафф-инженер в Engineering Enablement Department (EEP) компании Albert Heijn. Присоединился к компании в 2017 году. Барт руководит платформенной командой Kubernetes.

Митч Хюлшер (Mitch Hulscher) — основатель Evil8.io, нанятый в августе 2023 года исполняющим обязанности стафф-инженера в команде наблюдаемости EEP. За время работы он возглавлял проектирование и разработку нового решения для наблюдаемости.