В марте сервисы Datadog не работали более суток. Что пошло не так, как отреагировала команда инженеров, и что можно извлечь из этого инцидента? Это перевод эксклюзивного исследования, которое провел Гергели Орош (Gergely Orosz), консультант mobile.dev, автор нескольких книг по работе с инфраструктурой, в прошлом — инженер в Uber, Skype, Microsoft. 

Оригинал опубликован в рамках серии «Реальные инженерные кейсы», выпуск №8. Серия публикуется в информационном бюллетене Pragmatic Engineer. В каждом выпуске Гергели исследует интересные инциденты, которые происходили в Big Tech и стартапах.

Datadog предлагает решения для мониторинга сервисов и приложений, а также для оповещения команд при возникновении аномалий. Такие observability-услуги помогают отслеживать надежность работы сервисов, а их отказ обычно негативно влияет на бизнес. В среду, 8 марта 2023 года, подобный отказ произошел у Datadog — проблемы со стабильностью наблюдались более 24 часов. Инцидент обошелся компании недешево: по данным опубликованного позднее квартального отчета упущенная выгода составила $5 млн. Убыток равен приблизительно доходу компании за день. Причина убытков кроется в системе тарификации Datadog: компания берет деньги за объем переданных данных или количество логов, и, скорее всего, во время инцидента деньги с клиентов не взимали. 

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

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

«Мы поделились некоторой информацией о том, что произошло, и выпустили постмортем. Рекомендую всем с ним ознакомиться, потому что документ получился захватывающим».

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

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

Что будет в статье:

• Рассмотрим хронологию событий, концепции TTD, TTM, TTR, оценим работу Datadog по этим метрикам.

• Совершим глубокое погружение в обновление ОС, вызвавшее сбой. Обсудим CVEs, переполнение буфера, поговорим о системном процессе и системных дампах. А еще о том, почему необходимо проверять changelog'и операционных систем. Возможно, компания Datadog упустила нечто критическое перед обновлением?

• Попытаемся понять, что на самом деле вызвало перебои в работе. Разберем тонкости работы systemd-networkd и попробуем представить, что происходит при одновременном создании десятков тысяч виртуальных машин.

• Разберемся, почему размещение инфраструктуры в 5 регионах у 3 разных облачных провайдеров не помогло. Вообще, перебои в работе сервисов вроде Datadog недопустимы, поэтому инфраструктура была диверсифицирована. Так как же вышло, что все регионы в AWS, GCP и Azure упали одновременно, хотя прямого соединения между ними не было?

• Обсудим меры, предпринятые компанией. Что сделала Datadog, чтобы избежать очередной волны обновлений?

• Поговорим о проблемах в коммуникациях во время падения. Datadog не сумела правильно выстроить общение с клиентами. С каким-то пользователями поддержка поработала отлично, другие же не получили ничего — ни постмортемов, ни рекомендаций. Как так вышло?

• Извлечем из всего этого урок. Какую пользу другие инженерные команды могут вынести из этой ситуации?

Примечание: через несколько часов после выхода этой статьи Datadog наконец-то опубликовала свой постмортем. Им оказался тот самый документ, который они разослали ряду своих клиентов 2 месяца назад — в районе 20–22 марта 2023 года. Это один из двух постмортемов, которые я использовал при подготовке материала. В нем можно узнать о конкретных шагах по восстановлению сервиса — в статье я не рассматриваю их ради экономии времени. Остается загадкой, почему компания два месяца ждала, прежде чем обнародовать постмортем, который был давно готов, и почему она пренебрегает культурой прозрачности.

1. Хронология событий и TTD, TTM, TTR

Я буду использовать центральноевропейское летнее время (CEST), так как основная часть инженеров Datadog находится в этом часовом поясе. Однако для удобства читателей в скобках я буду приводить и североамериканское восточное время (EST).

8 марта, 07:00 CEST (01:00 EST): На десятках тысяч виртуальных машин (ВМ) обновляется операционная система. Эти машины начинают таинственным образом исчезать из сети.

07:03, CEST (01:03 EST): Срабатывает первый внутренний алерт из-за аномалии с одной из метрик.

07:18 CEST (01:18 EST): Оперативная группа начинает выяснять ситуацию.

07:31 CEST (01:31 EST): Клиенты получают уведомление об инциденте:

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

Время до обнаружения (time to detect, TTD) — 31 минута. При инциденте TTD указывает, сколько времени прошло с его начала до того, как он подтвержден дежурной командой и объявлено о перебоях в работе.

В книге Seeking SRE Мартин Чек (Martin Check) описывает эту метрику следующим образом: 

«Время до обнаружения — время от начала инцидента до момента, когда его фиксирует оператор. Счетчик запускается, когда инцидент впервые становится заметен для клиента, даже если мониторинг его не обнаружил. Часто это время совпадает со временем нарушения соглашения об уровне обслуживания (SLA).

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

08:23 CEST (02:23 EST): Обнаружено потенциальное негативное влияние на ввод и мониторинг данных. Клиентам приходит сообщение от Datadog:

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

Напрашивается вопрос: не должен ли тогда ТТD составлять 1 час 23 минуты вместо 31 минуты? Datadog объявила об инциденте через 31 минуту после его начала, но о том, что основная функциональность по вводу и мониторингу данных нарушена, сообщила клиентам лишь спустя 1 час 23 минуты.

21:39 CEST (15:39 EST): Через 14 часов после начала инцидента в его хронологии появилось первое более подробное описание:

«Ожидаем возобновления работы с данными в течение нескольких часов (не минут и дней)».

9 марта 9:58 CEST (03:58 EST): Объявлено о возобновлении работы всех сервисов. При этом обработка данных по-прежнему ведется с задержками (это связано с большими объемами накопившейся информации).

10 марта 06:25 CEST (00:25 EST): Инцидент полностью устранен, все накопившиеся данные обработаны.

Время на устранение последствий (TTM) — период времени с начала инцидента до перехода сервисов в статус healthy. В случае с Datadog восстановление работоспособности сервисов заняло 1 сутки 2 часа 58 минут, а полное устранение инцидента — 1 сутки 23 часа 25 минут. В Seeking SRE схема метрики TTM выглядит так:

«Время на устранение последствий включает в себя время до обнаружения (TTD), время на привлечение инженера или инженерной группы (time to engage, TTE) и время на починку (time to fix, TTF). Определить TTE обычно сложно, поэтому в большинстве инцидентов эта информация не фиксируется. Отслеживать TTE полезно, чтобы выявить, в каких случаях трудно оперативно привлечь инженеров, отвечающих за конкретную систему». 

Источник: Seeking SRE

Время на восстановление (time to remediate, TTR): пока неясно. После устранения последствий инцидента инженерным группам часто приходится решать один или несколько вопросов:

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

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

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

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

2. Разбираемся с обновлением ОС, вызвавшим сбой

Причиной сбоя в работе Datadog стало обновление операционной системы. На виртуальных машинах работает Ubuntu Linux, дистрибутив которой регулярно обновляется до последней версии. Проблема возникла во время обновления до версии 22.04, которое включало обновление безопасности systemd.

systemd отвечает за запуск сервисов в Linux и управление ими. Это первый процесс, который выполняется после загрузки ядра Linux, ему присваивается ID 1. systemd запускает инициализацию пользовательского пространства, а также сервисы во время работы Linux. То есть он является основой всех операционных систем на базе Linux.

Ниже вы видите примечания к обновлению от 2 марта 2023 года. Именно это обновление ОС — и одно из двух изменений в systemd — вызвало проблемы у Datadog несколько дней спустя:

    “SECURITY UPDATE: buffer overrun vulnerability in format_timespan()
    - debian/patches/CVE-2022-3821.patch: time-util: fix buffer-over-run
    - CVE-2022-3821

    SECURITY UPDATE: information leak vulnerability in systemd-coredump
    - debian/patches/CVE-2022-4415.patch: do not allow user to access coredumps with changed uid/gid/capabilities
    - CVE-2022-4415”

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

Что такое CVE? Common Vulnerabilities and Exposures (CVE) — обнародованный список уязвимостей в системе безопасности. Программа CVE реализуется корпорацией MITRE при финансовой поддержке Министерства внутренней безопасности США. Идентификаторы CVE — надежный способ распознавания уязвимостей и координации исправлений между вендорами. В случае с Linux, учитывая количество ее разновидностей вроде Red Hat, Ubuntu или Debian, CVE помогают определить, какой дистрибутив устранил определенные уязвимости. Просмотреть все CVE можно на домашней странице списка, есть даже аккаунт в Twitter с перечнем последних обнаруженных CVE. Список длинный и пополняется ежечасно.

Исправление переполнения буфера

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

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

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

В случае systemd злоумышленник может «скормить» определенные значения времени и степени точности, которые приведут к выходу за пределы буфера в format_timespan() и последующему аварийному завершению работы systemd. Поскольку systemd управляет всеми процессами, его выход из строя означает падение всей операционной системы (kernel panic). Злоумышленник может вставить определенные даты во входные данные, парсируемые методом format_timespan() в systemd, и вызвать отказ в обслуживании и системный сбой.

Вот фикс для этой уязвимости:

Хотя изменения коснулись всего одной строки (и трех строк в тестах), нужно приложить немало усилий, чтобы понять, что тут происходит. Отчасти это связано с тем, что метод format_timespan занимает сотню строк, а задействованные в нем переменные типа i, j, k, l, m, n плохо документированы. В результате трудно понять, что именно они делают. К счастью, соответствующий issue ставит все на свои места:

«Проблема с кодом выше в том, что n = MIN((size_t) k, l) может присвоить n размер буфера l. Тогда p += n; это приведет к тому, что p будет указывать на байт после буфера buf, что приведет к перезаписи буфера в *p=0 (ошибка на единицу)».

Этот CVE — еще одно свидетельство того, как трудно писать безопасный код: классическая ошибка на единицу обнаруживается спустя годы после ее появления!

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

Исправление уязвимости, связанной с утечкой информации

Второе исправление касалось CVE-2022-4415 — уязвимости, при которой systemd-coredump не соблюдал параметр ядра fs.suid_dumpable.

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

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

• 1 (default): процессы, которые изменили уровни привилегий или являются execute-only, не будут выгружаться в дамп.

• 2 (debug): все процессы выгружают данные в дамп при первой возможности. Это небезопасно, так как позволяет обычным пользователям изучать содержимое памяти привилегированных процессов.

• 3 (suidsafe): применяется, когда администраторы пытаются отладить проблемы в нормальной среде.

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

Могло ли устранение уязвимости, которая потенциально приводила к утечке информации, вызвать проблемы у Datadog? Вряд ли. Сложности могли бы возникнуть, если бы некие процессы анализировали дампы ядра упавших процессов. Они бы просто лишились доступа к подробностям об использовании памяти root-процессами.

3. Что на самом деле вызвало перебои в работе

Обновления systemd были относительно безобидными в контексте работы тысяч виртуальных машин. Они лишь делали дистрибутив Linux более безопасным. И, как оказалось, ни одно из обновлений systemd не было непосредственной причиной сбоя.

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

Именно здесь и проявилась проблема:

1. Обновление безопасности внесло изменения в процесс systemd, который является главным в Linux.

2. Когда systemd перезапустился, все его подпроцессы, включая systemd-networkd, также перезапустились.

3. systemd-networkd управляет сетевыми конфигурациями. Из-за перезапуска systemd был перезапущен systemd-networkd. В результате были непреднамеренно удалены сетевые маршруты.

4. Маршрутами, которые удалил systemd-network, управлял слой контейнерной маршрутизации Cilium на базе eBPF (extended Berkeley Packet Filter). Cilium обеспечивает связь между контейнерами. Сетевой слой Datadog управляет кластерами Kubernetes.

5. Из-за удаления маршрутов виртуальные машины (узлы) просто исчезли из сетевого управляющего слоя (network control plane) и перешли в офлайн.

6. Ранее удаления маршрутов при обновлении systemd не происходило. Это объясняется тем, что при запуске нового узла на нем не было сохраненных маршрутов. То есть запуск systemd-networkd с нуля ничего не стирал.

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

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

«Среди виртуальных машин, которые были выведены из строя этим багом, были те, что обеспечивают работу наших региональных управляющих слоев [на базе Cilium]. Это привело к тому, что большинство кластеров Kubernetes не могли планировать новые рабочие нагрузки, автоматически восстанавливаться и масштабироваться.

В результате мы постепенно начали лишаться мощностей. К [08.31 CEST] процесс приобрел такой масштаб, что стал заметен для [клиентов]».

Давайте наглядно представим, что произошло. Начальное состояние региона:

Первое обновление systemd; часть узлов стала недоступна:

Обновление продолжается; часть узлов управляющего слоя выведена из строя:

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

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

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

Можно ли было предсказать подобное развитие событий? Хотя произошедшее легко анализировать задним числом, все же стоит задаться вопросом: можно ли было спрогнозировать, что systemd и systemd-networkd способны поломать маршруты Cilium?

После публикации этой статьи инженер-программист Дуглас Камата (Douglas Camata) из Red Hat отметил, что Cilium и systemd известны своими сбоями при обновлении ОС. Например, issue, описывающий, как обновление systemd ломает сетевой трафик Cilium, оставался открытым с марта 2020 года по июнь 2022-го. 

Однако проблема, о которой идет речь, была исправлена в Cilium за 9 месяцев до сбоя Datadog (фикс вошел в релиз 1.10.13 Cilium). Инженер, знакомый с этим проблемами, мог бы насторожиться, узнав, что скоро выйдет обновление ОС, вносящее изменения в systemd. При этом не похоже, что кто-то мог предсказать, какое влияние окажет обновление systemd на пути в Cilium. Для этого описываемый сценарий обновления нужно было протестировать.

4. Почему не помогла работа в 5 регионах у 3 разных облачных провайдеров?

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

1. Запрет на одновременное применение патчей безопасности. Комментарий из постмортема:

«Выкат нового кода, исправлений безопасности или измененной конфигурации проходит последовательно регион за регионом, кластер за кластером, узел за узлом. Что касается процесса, мы не применяем изменения in situ (в месте нахождения); наоборот, узлы и контейнеры заменяются по принципу синих/зеленых развертываний. Для неудачных изменения происходит автоматический откат. Мы уверены в таком подходе, потому что он применяется десятки раз в день».

2. Распределение инфраструктуры по 5 регионам и 3 облачным провайдерам. Datadog не привязывает инфраструктуру к единственному провайдеру. Основываясь на этой информации, я провел обратный поиск IP-адресов центров обработки данных и облачных провайдеров, которых они, скорее всего, используют. Вот что получилось:

• AWS для US1 (Восточное побережье США; вероятно, используется дата-центр AWS us-east-1) и для AP1 (Япония; по всей видимости, используется дата-центр AWS ap-northeast-1 вблизи Токио);

• Google Cloud для EU1 и US5;

• Azure для US3 (западное побережье США; вероятно, задействован центр обработки данных Microsoft в Куинси).

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

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

Похоже, Datadog использует облачных провайдеров как Infrastructure as a Service для своих машин и запускает собственные виртуальные образы поверх одного и того же образа ОС у разных облачных провайдеров. И в этом есть корень проблемы. Из постмортема:

«В базовом образе ОС, который мы используем для запуска Kubernetes, был включен устаревший канал обновления безопасности, это привело к автоматическому применению обновления. Мы используем минималистичные базовые образы ОС, поэтому такие обновления происходят нечасто.

Ситуацию усугубило то, что время, в которое происходит автоматическое обновление, по умолчанию установлено в ОС на окно между 06:00 и 07:00 UTC (всемирное координированное время)».

В этом и заключалась проблема.

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

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

Последний раз обновление безопасности для systemd выходило более года назад, в январе 2022-го. Оно могло вызвать такую же проблему с перезапуском systemd-networkd и очисткой таблиц маршрутизации. Похоже, в январе 2022-го у Datadog была другая инфраструктура: например, использовалась другая ОС для Kubernetes-кластера.

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

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

Логика автоматического масштабирования других облачных провайдеров сразу заменяет нездоровый узел на новый. Данные на нездоровом узле теряются и их необходимо восстанавливать, что сильно усложняет задачу. Одновременная замена десятков тысяч узлов привела к возникновению «громогласного стада» (thundering herd), которое испытывало на прочность региональные ограничения скорости облачного провайдера различными способами, ни один из которых [на тот момент] не был очевиден заранее».

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

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

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

5. Предпринятые меры

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

1. Сделала образы ОС устойчивыми к обновлениям systemd. Одной из причин сбоя было то, что из-за обновления systemd были удалены таблицы маршрутизации. Datadog внесла изменение в конфигурацию systemd-networkd: после обновления systemd таблицы маршрутизации, необходимые для Cilium, больше не удаляются.

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

У тех, кто интересуется вопросами безопасности, второй пункт может вызвать закономерные вопросы. Не скажется ли он на безопасности? Учитывая, что Datadog уже изменила свой сервис, сделав его устойчивым к обновлениям ОС, не следует ли оставить автоматические обновления включенными?

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

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

6. Проблемы с коммуникацией во время сбоя

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

Коммуникацию можно назвать приемлемой. Datadog незамедлительно объявила об инциденте. Также компания публиковала обновленную информацию.

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

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

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

Первое значимое публичное сообщение команды Datadog появилось через 14 часов после инцидента. В нем было:

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

• Описан текущий статус: «Мы выявили и устранили первоначальную проблему и перестроили наши кластеры (...) Работа по восстановлению в настоящее время затруднена из-за огромного масштаба сбоя».

• Рассказано о том, чего ожидать дальше: «Рассчитываем восстановить работоспособность за несколько часов (не минут и дней)».

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

Для большинства клиентов работа Datadog была восстановлена в течение полутора дней. Все данные были загружены в течение двух дней (о потерях не сообщалось).

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

Но именно в этот момент история сбоя Datadog приняла странный оборот.

Некоторые клиенты получили двухстраничный предварительный постмортем через несколько дней после инцидента. В нем кратко описывались такие детали, как проблема с systemd-networkd, вызвавшая сбой, и действия, предпринятые Datadog, которые гарантируют, что подобные сбои в будущем не повторятся. Через две недели после инцидента часть клиентов получила четырехстраничный PDF с подробностями и детальным обзором сбоя.

Но некоторые клиенты не получили ни одного из этих документов. Кому-то постмортем не достался даже после явного запроса: я разговаривал с клиентом, который платит Datadog более $100 тысяч в год. Узнав о том, что другие получили постмортем, он дважды его запрашивал — 11 мая и 12 мая, но так и не получил ответа.

В чем причина столь разного отношения? Я пообщался с десятком пострадавших, но не обнаружил никакой взаимосвязи между тем, сколько они платят Datadog, и уровнем обслуживания. Некоторые мелкие ($50 тысяч в год) и крупные (более $1 миллиона в год) клиенты были полностью удовлетворены сервисом. Другие же клиенты разных масштабов после сбоя не получили ни одного постмортема от компании (в том числе те, кто тратит на Datadog более $1 миллиона в год).

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

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

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

Однако Datadog прежде всего предлагает инструментарий для разработчиков. Клиентами компании являются инженеры-программисты — в отличие от Roblox, у которой это в основном юные геймеры. Datadog публично выступает за лучшие практики управления сбоями и заявляет, что ее инструментарий ускоряет написание постмортемов.

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

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

• Инцидент Cloudflare 24 января 2023 года — постмортем опубликован 25 января.

• Частичное отключение Cloudflare 25 октября 2022 года — постмортем опубликован 26 октября.

• Отключение Cloudflare 21 июня 2022 года — постмортем опубликован в тот же день, хотя сбой был сложным, глобальным и сильно повлиял на сервис.

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

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

7. Уроки

Какие уроки можно извлечь из сбоя в работе Datadog и как компания справилась с ситуацией?

Некоторые сервисы для клиентов важнее остальных. Всегда восстанавливайте их первыми. В постмортеме Datadog поделилась одним ключевым выводом:

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

Я рад, что Datadog осознала это и сосредоточилась на восстановлении работы с live-данными и алертами, прежде чем приступить к заполнению пробелов (backfilling).

Сравните это с инцидентом Atlassian, у которой восстановление ключевой функциональности растянулось на 2 недели. Тогда упали все продукты Atlassian: сервис мониторинга и оповещения OpsGenie, система управления тикетами JIRA и система для создания базы знаний Confluence. По какой-то причине Atlassian не придала первостепенного значения восстановлению системы мониторинга и оповещения, хотя она гораздо важнее, чем тикеты или вики. В результате клиенты переключились с OpsGenie на продукт конкурента. Лояльные к провайдеру компании вполне могут прожить 2 недели без JIRA и Confluence, но инструмент оповещения об инцидентах им просто необходим для надежной работы.

Трудно протестировать обновление всей системы. Datadog часто проводит хаос-тесты, имитирующие сбои, путем простого отключения машин или сервисов. Но проблемы с systemd-networkd выявлены не были, как и последствия одновременного обновления десятков тысяч виртуальных машин.

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

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

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

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

Выводы

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

В целом, считаю, что реакция Datadog на инцидент была во многом правильной. Кое-что было сделано хорошо:

• Публично и достаточно быстро объявили об инциденте.

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

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

Однако с коммуникацией был ряд проблем:

• Выходили частые, но поверхностные апдейты без какой-либо новой информации в течение первых ~14 часов после отключения.

• После устранения последствий компания избирательно делилась с клиентами предварительным и полным постмортемами.

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

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

Datadog не стала искать виноватого, несмотря на финансовые потери. Хочу подчеркнуть, насколько зрело компания подошла к инциденту, хотя и не досчиталась около 1% квартальной выручки.

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

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

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