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 снова обслуживал клиентов, работая со всем трафиком одного региона. К этому времени технический персонал отправили отдыхать домой, чтобы утром продолжить работу.
В четверг и пятницу были возвращены и проверены остальные регионы, а также второстепенные по важности сервисы. Ниже вы видите график трафика одного из регионов со шкалой времени:
Чему это научило нас?
Вот что мы делаем, чтобы понять, что произошло и как предотвратить это в будущем:
Предоставляем очень краткое описание инцидента и его последствий для бизнеса, чтобы при необходимости взаимодействовать с заинтересованными сторонами.
Предоставляем временную шкалу с обозначением, что и когда произошло. Крайне важно сделать это сразу же, чтобы из-за автоматической очистки хранилища не потерять ключевые данные.
Исследуем полученные данные и записываем выводы в документе «Итоги изучения инцидента». Ряд команд для выявления первопричин произошедшего использует диаграмму Исикавы.
Разбираем «Итоги изучения инцидентов» с привлечением стороннего координатора (обычно старшего инженера из другой сферы), чтобы рассмотреть возможные решения этих проблем и определить их масштаб.
После написания «Итогов изучения инцидента» мы поделились выводами с широким бизнес-сообществом. Вот основные моменты, которые могут быть полезны вам и вашим системам:
Не выполняйте развёртывание глобальных конфигураций. Это не так очевидно, как кажется. k8s — сложная система с разными вариантами применения изменений в ней. Во многих случаях мы не вносим изменения в глобальную конфигурацию и потратили немало времени и усилий на предотвращение таких изменений, но конкретно этот сценарий не просчитывался: он весьма редкий.
Когда в конфигурации используются шаблоны и логика, она становится кодом: со временем конфигурация стала сложнее. Для упрощения мы ввели шаблоны и логику. Но не было введено тестирования (или даже статического анализа кода!): мы просто не думали об этих файлах конфигурации как о чём-то большем.
Планируйте наихудший аварийный сценарий: наши сценарии и перечни рутинных задач просто не были достаточно агрессивными, чтобы соответствовать объёмам и масштабам сбоев. Отработка взаимодействий в более радикальных учебных ситуациях дала бы возможность разобрать варианты развития событий в стиле «А что, если?» и принять меры по снижению рисков. Но нельзя предусмотреть всё — не думаем, что были недостаточно пессимистичны.
Проводите проверку процессов резервного копирования и восстановления: хороший администратор скажет, что резервная копия ещё не резервная копия, пока из неё не восстановлена система. К счастью, наши резервные копии были готовы, но изменение политики IAM затруднило их получение в критический момент. Когда вы в последний раз восстанавливали сервис из резервной копии? И что, если какой-то регион «упадёт»?
Проводите рефакторинг ваших сборников рутинных задач: перечни задач — это интерактивные документы, которые нуждаются в постоянном внимании и заботе наряду с кодом. А кроме того, подумайте об инженере, который будет читать эти документы ранним утром в атмосфере свалившейся на него нагрузки. Ясен ли контекст? Понятны ли этапы — даже идемпотент при необходимости?
С автоматизацией всё может зайти слишком далеко: нужно ли было шаблонизировать эту конфигурацию в регионах её развёртывания? Если нет, была бы вероятность дрейфа конфигурации, а если да — появлялась бы возможность автоматического выкатывания во многих регионах. Каков наилучший баланс? Как снизить риск?
Руководители по инцидентам: в случае инцидента кто-то должен возглавить оперативный штаб, но на момент конкретно этого сбоя у нас уже был опытный руководитель по работе с инцидентами, без которого нам не удалось бы так хорошо справиться с ситуацией. Вот слова одного из инженеров, дежуривших в тот вечер:
«Часто я циничен, но тот позитивный настрой и спокойствие, которые дают нам возможность расставлять приоритеты и восстанавливаться даже после таких катастрофических сбоев без малейших попыток возложить на кого-то вину, были реальным показателем культуры Skyscanner.
Думаю, что за всё время работы в Skyscanner величайшим поводом для гордости стало то, как мы сработали в ответ на произошедший в среду вечером инцидент и возобновили обслуживание клиентов».
Надеюсь, из этого краткого документа стало понятно, что произошло. Возможно, у вас появятся идеи о том, как подобного инцидента можно было избежать.
Продолжить изучение DevOps и научиться предупреждать подобные ситуации при помощи тестирования вы сможете на наших курсах:
Узнайте подробности акции.
Другие профессии и курсы
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также:
