Datadog управляет примерно 6000 внутренних сервисов и в среднем добавляет по одному новому дата-центру в квартал. На протяжении большей части этого периода роста мы относились к сервисам одинаково при принятии решений о развертывании и обеспечении надежности. При нашем текущем масштабе такой подход стал затратным. Изменения, предназначенные для продакшена, развертываются в дата-центрах последовательно, поэтому время развертывания растет с каждым новым дата-центром. Применение единой строгой целевой задачи уровня обслуживания (SLO) ко всем сервисам может привести к избыточным инвестициям в одни и недостаточной защите других. Это также может привести к тому, что работа по обеспечению надежности будет распределяться равномерно, вместо того чтобы концентрироваться там, где сбой нанесет наибольший ущерб клиентам.
В этом контексте нам нужно было ответить на сложный вопрос: какие сервисы действительно являются критически важными? Знание этого помогло бы нам решить, как быстро развертывать конкретный сервис, где поддерживать строгие SLO и на чем сосредоточить работу по обеспечению надежности. Но не было очевидного способа прийти к единому определению «критичности», которое команды могли бы последовательно использовать. Не имея согласия о том, как их классифицировать, мы обратились к тому, где доказательства уже существовали: к нашей собственной истории инцидентов.
Чтобы внести ясность, речь идет о критичности надежности для клиентов, то есть о том, насколько сильно на клиентов влияет ситуация, когда сервис недоступен, работает медленно или возвращает некорректные результаты. Безопасность, соответствие требованиям и критичность данных являются важными аспектами, но они выходили за рамки нашего первоначального вопроса.
В этой статье мы расскажем, как мы использовали постмортемы для разработки нашего первого сигнала критичности, почему мы создали систему, объединяющую несколько сигналов, и как мы используем ее в продакшене.
Превращение многолетних постмортемов в сигнал критичности
В Datadog сильна культура постмортемов. За эти годы мы накопили тысячи постмортемов, написанных инженерами, в основном в виде свободного текста. Этот архив является одной из наших самых богатых записей о том, что ухудшало качество обслуживания клиентов, но мы никогда не структурировали его таким образом, чтобы можно было отвечать на вопросы о критичности сервисов.
Идея различать критически важные сервисы возникала и раньше, но из-за отсутствия практического способа анализа неструктурированного текста в масштабе она застопорилась. Недавние достижения в возможностях LLM сделали эту задачу актуальной.
Вместо того чтобы спорить, могут ли данные постмортемов подсказать нам, какие сервисы важны, мы провели быструю проверку концепции. Большая языковая модель (LLM) прочитала несколько сотен постмортемов SEV-1 и SEV-2 — подмножество архива с наивысшей степенью серьезности — и извлекла информацию о том, какие сервисы стали причиной инцидента, а какие пострадали. Весь процесс занял менее дня и стоил примерно 32 доллара.
Мы сверили извлеченные названия с Software Catalog, чтобы подтвердить, что они соответствуют реальным сервисам, а не являются галлюцинациями модели. Затем вторая модель проверила точность извлечения названий сервисов первой моделью, прежде чем мы доверились результатам.
Это оказалось сильным сигналом. Если сервис участвует в инциденте SEV-1 или SEV-2, он, вероятно, имеет историю влияния на клиентский опыт, что является настолько прямым индикатором критичности, насколько это возможно. Поскольку постмортемы уже существовали, мы смогли извлечь этот сигнал дешево и в масштабе.
Но у истории инцидентов есть и пробелы. Высоконадежный сервис, который никогда не вызывал инцидентов, невидим для этого сигнала, хотя он все равно может быть критически важным, даже если никогда не давал сбоев. Он также может фигурировать в нескольких инцидентах с высокой степенью серьезности, не являясь при этом компонентом, который привел к сбою продукта. Один сервис в наших данных фигурировал примерно в 10 инцидентах SEV-2, не вызвав ни одного полного сбоя. Именно из-за этого пробела постмортемы стали одним из нескольких сигналов, а не всей системой критичности.
Почему одного сигнала недостаточно
Критичность неоднозначна и зависит от точки зрения. Сервис с низким трафиком может находиться на критическом пути пользователя, в то время как сервис с высоким трафиком может деградировать плавно, не вызывая серьезных сбоев. Любая отдельная команда имеет лишь частичное представление, и любой отдельный сигнал фиксирует лишь часть картины, оставаясь слепым в других местах.
Поэтому система критичности сервисов должна объединять несколько сигналов и учитывать ограничения каждого из них. В Datadog некоторые сигналы могут повышать критичность сервиса, а один может только понижать ее:
- Инциденты: сигнал постмортема, описанный выше. Он повышает критичность для сервисов, которые были определены как первопричина или непосредственно участвовали в прошлых инцидентах SEV-1 или SEV-2.
Инциденты: сигнал постмортема, описанный выше. Он повышает критичность для сервисов, которые были определены как первопричина или непосредственно участвовали в прошлых инцидентах SEV-1 или SEV-2.
- Трассировки: полученный на основе трассировок ошибок Datadog Application Performance Monitoring (APM) и Real User Monitoring (RUM), сигнал трассировки идентифицирует сервисы, которые находятся на путях ошибок, и связывает точки входа с критическими путями пользователей. Это помогает выявить сервисы, которые замешаны в ошибочном трафике, включая те, которые никогда не приводили к зарегистрированным инцидентам.
Трассировки: полученный на основе трассировок ошибок Datadog Application Performance Monitoring (APM) и Real User Monitoring (RUM), сигнал трассировки идентифицирует сервисы, которые находятся на путях ошибок, и связывает точки входа с критическими путями пользователей. Это помогает выявить сервисы, которые замешаны в ошибочном трафике, включая те, которые никогда не приводили к зарегистрированным инцидентам.
- Трафик: измеряет объем производственного трафика в Software Catalog и помечает сервисы с околонулевым трафиком как низкокритичные. Сервисы со значимым трафиком не создают сигнала и оставляют решение за другими входными данными. Высокий трафик сам по себе не доказывает критичность, поэтому этот сигнал может только понижать критичность, а не повышать ее.
Трафик: измеряет объем производственного трафика в Software Catalog и помечает сервисы с околонулевым трафиком как низкокритичные. Сервисы со значимым трафиком не создают сигнала и оставляют решение за другими входными данными. Высокий трафик сам по себе не доказывает критичность, поэтому этот сигнал может только понижать критичность, а не повышать ее.
- Мониторы: анализирует мониторы, привязанные к сервису, и определяет, уведомляют ли они дежурную смену через Datadog On-Call. Пейджинговый монитор повышает критичность. Если у сервиса есть привязанные мониторы, но ни один из них не уведомляет дежурную смену, сигнал понижает критичность, причем уверенность возрастает в зависимости от количества мониторов. Для сервисов без привязанных мониторов сигнал не предоставляет данных о критичности.
Мониторы: анализирует мониторы, привязанные к сервису, и определяет, уведомляют ли они дежурную смену через Datadog On-Call. Пейджинговый монитор повышает критичность. Если у сервиса есть привязанные мониторы, но ни один из них не уведомляет дежурную смену, сигнал понижает критичность, причем уверенность возрастает в зависимости от количества мониторов. Для сервисов без привязанных мониторов сигнал не предоставляет данных о критичности.
Дополнительные сигналы, включая карту зависимостей, находятся в стадии разработки. Каждому сервису присваивается уровень критичности и общий показатель достоверности. Текущие уровни: высокий, низкий и неизвестный, причем «неизвестный» означает сервисы, для которых пока нет никаких данных. Мы планируем ввести средний уровень по мере подключения новых сигналов.
Показатель достоверности — это эвристика, объединяющая достоверность каждого отдельного сигнала. Он отражает объем доказательств, подтверждающих присвоенный уровень. Этот показатель в первую очередь предназначен для оценки производительности системы, но потребители также могут использовать его, чтобы избежать ложных срабатываний.
Когда два независимых сигнала совпадают, мы считаем это более веским доказательством, чем каждый из них по отдельности. Сигнал, указывающий в противоположном направлении, не может изменить присвоенный уровень, но он снижает нашу уверенность в классификации. Например, сервис с историей инцидентов, но практически без производственного трафика, представляет собой противоречие, которое стоит выявить.
Система намеренно сделана асимметричной. В худшем случае ложное срабатывание означает, что мы отнеслись к сервису более осторожно, чем требовалось. Ложноотрицательный результат означает, что мы посчитали критический сервис безопасным для быстрого внесения изменений. Мы настраиваем систему так, чтобы отдавать предпочтение менее затратной ошибке, сознательно допуская ложные срабатывания, чтобы избежать ложноотрицательных результатов, таких как инцидент у клиента, вызванный слишком быстрым развертыванием в критически важном API. Дополнительные сигналы и ручное переопределение помогут нам со временем сократить количество таких ошибок.
Внедрение критичности сервисов в эксплуатацию
Как только в систему поступает несколько сигналов, их нужно объединить в единый ответ, на основе которого команды смогут действовать. Раньше команды определяли критичность независимо друг от друга, и эти определения со временем естественным образом расходились. Теперь каждая внутренняя команда использует одну и ту же классификацию из централизованного API. Поддержание одного определения в одном месте превращает критичность из разрозненных знаний в инструмент, который команды могут использовать для построения автоматизации.
Внутри системы каждый сигнал записывает свой вердикт в общее хранилище, индексируемое по сервису и типу сигнала. Затем агрегатор объединяет эти вердикты в опубликованный уровень критичности и показатель достоверности.
Владельцы сервисов могут переопределить классификацию своего сервиса, указав причину, и полученный уровень будет отражен в API. Эти переопределения обеспечивают уровень ручной корректировки и фиксируют операционные знания, которые не кодируются ни одним автоматизированным сигналом. Переопределение меняет опубликованный уровень, но базовые сигналы продолжают работать, а их показатели остаются видимыми. Таким образом, мы можем видеть, в каких случаях система и владелец сервиса расходятся во мнениях.
Как команды используют критичность сервисов
Команды уже используют эти классификации для принятия различных типов решений. Что касается развертываний, система позволяет нам развертывать некритичные сервисы быстрее и поэтапно в разных центрах обработки данных, восстанавливая часть скорости, которую раньше приходилось жертвовать ради единообразного подхода.
Система критичности сервисов также влияет на решения об автоматическом слиянии (auto-merge) запросов на включение кода (pull requests). Автоматизированная система, которая поставляет обновления библиотек и зависимостей, использует критичность сервиса, чтобы определить, как быстро изменения могут быть одобрены и объединены. Изменения, затрагивающие критические сервисы, проходят дополнительную проверку или исключаются из автоматического слияния. Например, плановое обновление зависимости для сервиса с низкой критичностью может быть объединено автоматически, в то время как такое же обновление для сервиса, классифицированного как критический, сначала направляется на проверку человеку.
Поскольку каждая классификация включает показатель достоверности, потребители также могут решать, какой объем доказательств требуется перед автоматизацией действия. Потребитель, готовый к определенному риску, может действовать на основе классификаций с более низкой достоверностью, в то время как тот, кто хочет избежать ложных срабатываний, может потребовать высокой достоверности, прежде чем позволить автоматизации взять управление на себя.
Применение критичности сервисов в ваших системах
Знание того, какие сервисы являются критическими, дает инфраструктурным командам конкретную основу для действий. Данные не идеальны, поэтому мы продолжаем добавлять сигналы, которые устраняют пробелы в нашей системе критичности сервисов, в то время как ручные переопределения позволяют учесть то, что эти сигналы пока упускают.
Тот же подход может работать и для небольших организаций. Команда с меньшим количеством сервисов и несколькими разборами инцидентов может применять тот же принцип мультисигнального анализа, объединяя историю инцидентов, примерную карту зависимостей и знания владельцев сервисов, вместо того чтобы полагаться на единственное определение критичности.
Сигналы, лежащие в основе нашей системы, построены на инструментах, которые вы можете использовать прямо сейчас: Incident Management для разбора инцидентов, Software Catalog для учета владения сервисами и метаданных, а также APM и RUM для сигналов на уровне трассировки.
Если вы еще не являетесь клиентом Datadog, зарегистрируйтесь для получения бесплатной 14-дневной пробной версии.
