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

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

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

Как и многие другие компании, Airbnb изначально передала свои потребности в наблюдаемости внешним вендорам. Но по мере развития компании наши потребности стали отличаться от типичных стимулов вендоров. Вендоры взимают плату за объем обрабатываемых данных, поэтому затраты Airbnb росли, но большее количество данных не приводит автоматически к более быстрому получению аналитических данных или сокращению среднего времени обнаружения (MTTD) или устранения (MTTR). Кроме того, из-за отсутствия обратной связи в процессе использования данных наблюдаемости, наша способность улучшать рабочие процессы мониторинга наших клиентов или оптимизировать затраты на наблюдаемость была существенно ограничена.

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

Этот переход позволил нам получить полный контроль над сбором, хранением и запросами метрик. В рамках этого проекта мы успешно использовали наши инструменты автоматизации для миграции огромного объема данных через 1 000 сервисов: 300 миллионов временных рядов, 3 100 дашбордов и более 300 000 алертов. Хотя проект такого масштаба не реализуется без серьезных оснований, ограничения на то, что мы могли делать с нашими собственными данными, практически не оставили нам альтернативы.

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

Миграция v1

Восхождение на Эверест в первый день

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

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

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

Тот же багаж, но воздух разреженный.

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

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

Документация объясняет все — для тех, кто готов ее изучать

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

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

Миграция v2

Начинайте с достижимой цели.

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

Это позволит вашей команде:

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

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

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

Мигрируйте смысл запроса

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

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

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

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

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

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

Освоение нового языка запросов может быть непростой задачей.

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

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

Используя PromQL в качестве языка запросов для нашей новой системы, мы получаем преимущества зрелой экосистемы и хорошо документированного языка запросов, понятного как людям, так и современным LLM.

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

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

Сейчас самое время исправить устаревшие паттерны

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

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

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

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

Заключение

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

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

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

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

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

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

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