Реплика отстала — и пострадала продакшн-среда
В январе 2017 года GitLab.com полагался на основной сервер PostgreSQL, db1.cluster.gitlab.com, и активную реплику, db2.cluster.gitlab.com, для обеспечения отказоустойчивости. Эта архитектура, типичная для систем с высокой доступностью, была призвана поддерживать db2 в синхронизированном состоянии для переключения при сбоях — критически важная, но зачастую хрупкая защита.
В тот вечер скачок нагрузки привел к тому, что db2 настолько отстала, что репликация прекратилась. Стандартное решение: переинициализировать db2, очистив ее папку с данными и скопировав все с db1. В теории — простая процедура.
Однако во время этой переинициализации инженер по ошибке выполнил команду rm -rf не на db2, а на db1, основном продакшн-сервере. Команда проработала всего секунду или две, прежде чем ее остановили, но ущерб был нанесен: было удалено около 300 ГБ данных. Это не было медленным повреждением; это было внезапное, катастрофическое стирание рабочих данных. Последствия этой одной ошибочной команды вскоре проявились, обнажив гораздо более глубокую проблему.
Каждая резервная копия казалась надежнее, чем была на самом деле
Катастрофа GitLab развернулась не только из-за одной ошибки, но и из-за карточного домика, построенного на непроверенных предположениях. Организация считала, что у нее надежная стратегия резервного копирования, однако каждый уровень оказался фатально дефектным, доказав, что непроверенная резервная копия — это лишь гипотеза, а не защита.
Уверенность в ежедневном экспорте pg_dump в Amazon S3 была ошибочной. Задача, предназначенная для защиты базы данных PostgreSQL 9.6, по странному стечению обстоятельств использовала инструмент pg_dump от гораздо более старой версии PostgreSQL 9.2. Это несоответствие приводило к тому, что экспорт завершался с ошибкой без уведомлений, оставляя бакет S3 пустым.
Что особенно важно, никто не заметил системного сбоя. Уведомления по электронной почте, призванные сигнализировать о неудачном выполнении резервного копирования, отклонялись почтовым сервером из-за проблем с аутентификацией. Ситуацию усугубляло то, что снимки (снапшоты) базы данных продакшн-среды, фундаментальный уровень устойчивости, никогда не были включены. LVM-снимки существовали только для стейджинга, а снимки Azure Cloud покрывали диски ОС, но не критические тома базы данных.
Поскольку основная база данных была скомпрометирована, а реплика уже стерта во время попытки восстановления, GitLab столкнулся с ужасающей реальностью: жизнеспособной недавней резервной копии не существовало. Единственным путем назад был ручной снимок примерно шестичасовой давности, сделанный инженером для теста нагрузки, не связанного с этим процессом. Эта удача, а не какое-либо инженерное решение, подчеркнула шаткость всей их философии резервного копирования. Копирование этого снимка с медленных дисков заняло около 18 часов, что отразило общую продолжительность простоя и подчеркнуло истинную цену пренебрежения подготовкой к восстановлению данных.
Исправление происходило на глазах у 5000 зрителей
Кризисное управление GitLab стало мастер-классом по радикальной прозрачности. Инженеры делились обновлениями в реальном времени и процессом устранения неполадок публично через Google Doc, социальные сети и YouTube-трансляцию. Это решение превратило катастрофический технический сбой в крайне заметную проверку доверия, за которой на пике наблюдали более 5000 человек.
Исправление, мучительно медленное, опиралось на созданный вручную снимок шестичасовой давности, находившийся на медленных дисках. Восстановление этого снимка заняло около 18 часов, что составило продолжительность всего периода простоя. Это медленное восстановление означало, что GitLab.com был недоступен в течение значительного времени.
В конечном итоге GitLab потерял около шести часов записей базы данных. Это включало примерно:
- 5000 проектов
- 5000 комментариев
- 700 учетных записей пользователей
К счастью, данные репозитория остались нетронутыми на отдельном хранилище. Хотя результат был болезненным, публичная демонстрация стойкости и честности вызвала значительное уважение. Для более глубокого изучения деталей ознакомьтесь с Postmortem of database outage of January 31 - GitLab. Этот инцидент фундаментально изменил то, как многие в индустрии смотрят на реагирование на инциденты и радикальную прозрачность.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Урок заключался в ответственности, а не в поиске виноватых
Postmortem GitLab не был направлен на поиск «козла отпущения»; он диагностировал системный недостаток ответственности. Главная проблема заключалась не в ошибке инженера, а в отсутствии выделенной роли для обеспечения надежности резервного копирования и регулярной проверки восстановления. Никто не нес ответственности, поэтому критически важные механизмы защиты пришли в упадок.
Инцидент послужил катализатором значительных внутренних реформ. GitLab внедрила автоматизированные тесты восстановления, гарантируя, что резервные копии не просто существуют, но и функциональны. Они также усилили меры защиты доступа к production, усложнив случайное выполнение деструктивных действий, и закрепили явную ответственность за надежность базы данных за выделенной командой.
Для любой инженерной организации урок ясен: назначьте конкретного ответственного за целостность резервных копий. Установите проверенные каналы оповещения о сбоях резервного копирования — не полагайтесь на электронные письма, которые могут остаться незамеченными. Что крайне важно, регулярно тестируйте восстановление, чтобы подтвердить свою стратегию восстановления, и внедряйте надежные меры защиты для предотвращения случайной потери данных. Ваши резервные копии хороши ровно настолько, насколько успешно прошло ваше последнее проверенное восстановление.
Часто задаваемые вопросы
Что стало причиной сбоя базы данных GitLab в 2017 году?
Во время исправления реплики, которая отставала от основной базы, инженер случайно удалил данные из production-базы данных вместо реплики.
Почему GitLab не смог восстановиться из своих резервных копий?
Ежедневный экспорт не удался, так как использовалась несовместимая версия инструмента Postgres, а письма об ошибках были отклонены. Снимки (snapshots) production также были недоступны.
Как долго GitLab был недоступен?
Восстановление заняло около 18 часов, в основном потому, что восстановление вручную созданного снимка из медленного хранилища потребовало времени.
Сколько данных потерял GitLab?
GitLab потерял около шести часов данных базы данных, включая примерно 5000 проектов, 5000 комментариев и 700 учетных записей пользователей.
Какой главный урок можно извлечь из этого инцидента?
Резервная копия заслуживает доверия только тогда, когда команды регулярно тестируют возможность восстановления из нее, и кто-то несет ответственность за этот процесс.