Сбой Atlassian в апреле 2022 года: как скрипт за 23 минуты удалил 883 сайта и почему их восстанавливали до 14 дней

5 апреля 2022 года с 07:38 до 08:01 UTC скрипт обслуживания Atlassian удалил 883 облачных сайта 775 клиентов вместе с Jira, Confluence, Opsgenie, Statuspage и другими продуктами. Скрипту передали идентификаторы целых сайтов вместо идентификаторов устаревшего приложения, а API удаления принимал оба вида и считал ввод верным; часть клиентов ждала восстановления до 14 дней.

Бэкапы были, и данные потеряли максимум за пять минут до удаления. Но инструментов, чтобы разом вернуть сотни сайтов со всеми связанными продуктами, не было. Первые клиенты вернулись 8 апреля, последние — 18 апреля.

Главное о сбое в одной таблице

Хронология сбоя Atlassian

Что должен был сделать скрипт

Приложение Insight – Asset Management раньше было отдельным дополнением для Jira Service Management и Jira Software. Его функции встроили в сам Jira Service Management, и старое приложение надо было удалить с сайтов, где оно стояло. Для этого взяли существующий скрипт и существующий процесс.

Дальше сошлись три проблемы.

1. Разрыв между командами. Одна команда запрашивала удаление, другая его выполняла. Вместо ID приложения в списке оказались ID сайтов, на которых оно было установлено.
2. API не различал, что удаляет. Метод удаления принимал и ID сайтов, и ID приложений и считал, что ввод верный. Никакого предупреждения о том, что удаляется целый сайт, не было.
3. Опасный режим в том же скрипте. Скрипт умел и помечать данные на удаление — так делают в обычной работе, чтобы их можно было вернуть, — и удалять безвозвратно, что нужно для требований регуляторов. По словам технического директора Atlassian, его запустили с неверным режимом и неверным списком ID.

Скрипт прошёл по списку за 23 минуты. Первый тикет от клиента пришёл через восемь минут после старта, но связь тикета со скриптом подтвердили только в 08:53.

Почему бэкапы были, а восстановление заняло две недели

С бэкапами у Atlassian всё было в порядке. Базы копировались полными и инкрементальными бэкапами с восстановлением на любой момент в пределах 30 дней, были и неизменяемые копии на случай порчи данных. Цель по допустимой потере данных (RPO) в один час выдержали: потеряно не больше пяти минут.

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

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

Спешка тоже стоила данных. У 57 клиентов, которых восстанавливали первыми, из-за несогласованных правил и ручного извлечения снапшотов часть баз Confluence и Insight вернули на момент раньше, чем за пять минут до удаления.

Почему клиенты не могли даже написать в поддержку

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

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

Уроки для DevOps

1. Удаление по умолчанию должно быть обратимым

Первый вывод Atlassian — «мягкое удаление» везде. Удаление сайта целиком запретить, мягкое удаление защитить несколькими уровнями проверок, выкатывать поэтапно и иметь проверенный план отката. У себя это значит: корзина или версионирование для данных, защита от удаления для баз и дисков, а в Terraform — prevent_destroy для того, что нельзя потерять:

$ terraform plan
╷
│ Error: Instance cannot be destroyed
│
│   on main.tf line 31:
│   31: resource "aws_db_instance" "main" {
│
│ Resource aws_db_instance.main has lifecycle.prevent_destroy set, but the
│ plan calls for this resource to be destroyed. To avoid this error and
│ continue with the plan, either disable lifecycle.prevent_destroy or reduce
│ the scope of the plan using the -target flag.
╵

Учтите оговорку из документации: если удалить из кода сам блок ресурса вместе с lifecycle, Terraform удалит ресурс.

2. Инструмент проверяет, что именно он удаляет

API, который молча принимает ID сайта там, где ждёт ID приложения, — ловушка для любого, кто его вызовет. Тип объекта передают явно или делают его частью идентификатора, а скрипт перед удалением показывает, что и сколько удалит:

#!/usr/bin/env bash
set -euo pipefail
ids=$1
total=$(wc -l < "$ids")
foreign=$(grep -vc '^app-' "$ids" || true)   # строки, не похожие на ID приложения
echo "В списке $total ID, из них не app-: $foreign"
[ "$foreign" -eq 0 ] || { echo "Стоп: в списке ID другого типа" >&2; exit 1; }

Та же мысль в разборе сбоя AWS S3: после неверно введённого параметра AWS научила свой инструмент отказываться от операции, которая уводит систему ниже безопасного минимума.

3. Разрушительная операция идёт поэтапно

883 сайта удалились за 23 минуты подряд. Если бы скрипт сначала обработал один сайт и остановился до проверки, ущерб ограничился бы одним клиентом. Поэтапность нужна не только выкладке кода: удаление, миграции и массовые правки — такие же изменения прода. В сбое Knight Capital не хватило именно автоматического стоп-крана.

4. Бэкап — это RPO, а восстановление — RTO

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

5. Контакты и каналы связи храните отдельно

Atlassian потеряла контакты клиентов вместе с их сайтами. Теперь она обещает хранить контакты администраторов вне самого продукта. Проверьте, где у вас лежат контакты клиентов, дежурных и подрядчиков и сможете ли вы их достать, если основная система лежит.

Что проверить у себя завтра:

• какие скрипты и API умеют удалять безвозвратно и есть ли у них режим «показать, что будет удалено»;
• включена ли защита от удаления для баз, дисков и бакетов с важными данными;
• восстанавливали ли вы когда-нибудь много объектов сразу и сколько это заняло;
• как клиент сообщит о проблеме, если его аккаунт или сайт исчез.

Реши сам

Вопрос 1. Скрипт умел и помечать на удаление, и удалять навсегда. Какое устройство инструмента защитило бы лучше всего?

1. Один скрипт с флагом режима, как было
2. Безопасный режим по умолчанию, безвозвратное удаление — только отдельной операцией после срока хранения, с проверкой типа ID и поэтапным запуском
3. Запуск скрипта только ночью
4. Больше бэкапов

Вопрос 2. Бэкапы позволяли восстановиться на любой момент за 30 дней. Почему часть клиентов ждала две недели?

1. Бэкапы оказались повреждены
2. Не было автоматизации, чтобы вернуть сотни сайтов со всеми связанными продуктами разом: первый способ требовал около 70 шагов
3. Клиенты не давали согласия на восстановление
4. В облаке не хватило места

Частые вопросы

Сколько клиентов пострадало от сбоя Atlassian? По итоговому разбору — 775 клиентов и 883 сайта. Больше 99,6% клиентов и пользователей облачных продуктов Atlassian работали без перебоев.

Потеряли ли клиенты данные? Потеря ограничилась пятью минутами до удаления сайта. Исключение — 57 клиентов, восстановленных в самом начале: у части из них базы Confluence и Insight вернули на более ранний момент.

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

Что изменила Atlassian после сбоя? Выбрала четыре направления: мягкое удаление во всех системах, автоматическое восстановление многих сайтов и продуктов сразу, управление крупными инцидентами и коммуникации с клиентами, включая хранение контактов вне продукта.

Пройти похожий сбой самому

В симуляторе DevOps KAI Lab разбор Atlassian стоит в девятом месяце, посвящённом облаку и Terraform. Там же есть тикет «План, который удаляет базу»: вы ревьюите merge request, где коллега «для красоты» переименовал ресурс, и читаете, что на самом деле сделает terraform plan.

Начать можно бесплатно: тест навыков и первые задания первого месяца.

Источники

• Atlassian. Post-Incident Review on the Atlassian April 2022 outage, 29.04.2022 — хронология, причины, способы восстановления, RPO и RTO, выводы.
• Atlassian, Шри Висванатан (технический директор). April 2022 outage update, 12.04.2022 — режимы скрипта «mark for deletion» и «permanently delete».
• HashiCorp. The lifecycle meta-argument и Manage resource lifecycle — prevent_destroy и его ограничения.