25 августа 2021 года команда Skyscanner внесла неверные изменения в шаблон системы конфигурирования инфраструктуры. Это привело к удалению всех микросервисов, которые обслуживали skyscanner.net, а также отвечали за данные мобильного приложения. К старту курса по DevOps делимся подробностями от Skyscanner.

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

Начало

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

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

Что такое «архитектура ячеек»?

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

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

• Сервисы внутри ячейки развёртываются в конфигурации «n+2» — это даёт возможность обслуживания 100 % трафика с одним упавшим из-за сбоя кластером и одним кластером, отключённом в целях обслуживания.

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

Что же произошло?

25 августа около 15:30 по Гринвичу в рамках подготовки к более широким изменениям инженер изменил шаблон системы. Это изменение не должно было повлиять на поведение.

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

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

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

Мы понимаем, что эта ошибка негативно сказалась на наших клиентах и партнёрах по всему миру, и срочно исправили её.

Как всё разрешилось?

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

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

Примерно к 20:30 по Гринвичу skyscanner.net снова обслуживал клиентов, работая со всем трафиком одного региона. К этому времени технический персонал отправили отдыхать домой, чтобы утром продолжить работу.

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

Чему это научило нас?

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

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

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

3. Исследуем полученные данные и записываем выводы в документе «Итоги изучения инцидента». Ряд команд для выявления первопричин произошедшего использует диаграмму Исикавы.

4. Разбираем «Итоги изучения инцидентов» с привлечением стороннего координатора (обычно старшего инженера из другой сферы), чтобы рассмотреть возможные решения этих проблем и определить их масштаб.

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

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

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

• Планируйте наихудший аварийный сценарий: наши сценарии и перечни рутинных задач просто не были достаточно агрессивными, чтобы соответствовать объёмам и масштабам сбоев. Отработка взаимодействий в более радикальных учебных ситуациях дала бы возможность разобрать варианты развития событий в стиле «А что, если?» и принять меры по снижению рисков. Но нельзя предусмотреть всё — не думаем, что были недостаточно пессимистичны.

• Проводите проверку процессов резервного копирования и восстановления: хороший администратор скажет, что резервная копия ещё не резервная копия, пока из неё не восстановлена система. К счастью, наши резервные копии были готовы, но изменение политики IAM затруднило их получение в критический момент. Когда вы в последний раз восстанавливали сервис из резервной копии? И что, если какой-то регион «упадёт»?

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

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

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

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

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

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

Продолжить изучение DevOps и научиться предупреждать подобные ситуации при помощи тестирования вы сможете на наших курсах:

• Курс по DevOps (6 месяцев)

• Профессия «Тестировщик-автоматизатор на Python» (8 месяцев)

Узнайте подробности акции.