Разбираем постмортем GitHub: как точно не повторить их падения

Любой серьёзный бизнес-проект сталкивался со сбоями — но вот кризис миновал, мониторинг позеленел, команда выдохнула. Именно сейчас легко пропустить причину следующей аварии. При сопровождении серверов мы в Maxiplace сверяем логи, графики нагрузки и историю изменений, чтобы найти причину сбоя и проверить, устранена ли она. Разберём на реальном примере, почему именно так стоит действовать после восстановления сайта и как превратить ответы в проверяемые действия.

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

На следующий день нагрузка вернулась, а вместе с ней — проблемы. Затем произошли ещё сбои. История подробно описана самим GitHub: давайте используем её как публичный пример. Масштаб GitHub несравним с обычным интернет-магазином, зато ошибка в логике расследования знакома командам любого размера: «починили в моменте» приняли за «устранили причину сбоя».

Вот что известно из опубликованной GitHub хронологии. Время указано по UTC; длительность округлять не будем.

Нельзя утверждать, что все четыре эпизода вызвал один и тот же запрос. GitHub описывает общую проблему — конкуренцию за ресурсы в mysql1 во время пиков и недостаточный запас производительности. Часть эпизодов осложнили диагностические и восстановительные действия. Согласно последующему отчёту GitHub, между 14 и 28 марта команда уменьшила число запросов к этой базе более чем на 50%, а объём транзакций в пик — на 70%. Пороги предупреждений снизили, часть нагрузки стали ограничивать заранее, продолжили работу по разделению базы.

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

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

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

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

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

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

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

Минимальная проверка после восстановления: выполните реальное действие, ради которого существует сайт. Для магазина — сделайте тестовый заказ от помещения в корзину до подтверждения оплаты. Для корпоративного сайта — получите КП, свяжитесь с консультантом, заполните нужную форму.

Вам нужно представлять что произошло на 100% точно. Запишите все события:

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

Полезно будет разделить четыре вещи: условие, пусковой фактор, механизм отказа и пробел в защите.

В случае GitHub схема на уровне опубликованных фактов выглядит так:

Ограниченный запас базы при высокой общей нагрузке → очередной пик и дорогие запросы → конкуренция за ресурсы и проблемы с соединениями → операции записи не выполняются; прежние предупреждения и временные меры не обеспечили достаточный запас до следующего пика.

Это обобщение, а для проекта меньших масштабов цепочка может выглядеть иначе. Предположим, что во время акции оформление заказа отвечает с задержкой, а главная открывается. Проверка показывает, что запросы ждут базу; одновременно запущена тяжёлая обработка каталога. Остановка задачи возвращает заказы. Но до анализа её запросов и проверки при следующем пике рано объявлять корнем проблемы «слабый сервер». Эта же ошибка может возникнуть из-за релиза, внешнего сервиса или заполненного диска.

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

Если даже вы полностью поняли, что и почему произошло, это обретёт смысл только если вы выполните «работу над ошибками» — в трёх приближениях:

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

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

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

Инженер инфраструктуры должен проверять ресурсы, службы, серверные ошибки и мониторинг. Разработчик заказчика (если только специально не обговорено иное) разбирает запросы приложения, релизы, фоновые задачи и интеграции. Владелец проекта сообщает, какие операции критичны и каковы последствия сбоя. Конкретная граница ответственности зависит от SLA и доступов.

Если у вас с хостером хорошее взаимопонимание, то в результате кризиса вместо длинной переписки будет такой абзац:

«Во время пика оформление заказа отвечало с ошибками. Ожидание базы выросло одновременно с запуском фоновой задачи; после её остановки оформление восстановилось. Нужно подтвердить влияние задачи на тесте, изменить её работу и проверить заказы под нагрузкой. За измерения и серверные ограничения отвечает инженер сопровождения; за запросы и задачу — разработчик; дату проверки согласует владелец проекта».

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

Перед закрытием спросите команду:

Если ответ на последний вопрос — «посмотрим в следующую распродажу», разбор пока не завершён: эксперимент перенесён на реальных покупателей.

Сбой GitHub показывает привычку пересматривать выводы, когда инцидент повторяется. Небольшому сайту не требуется архитектура GitHub. Ему требуется честный ответ: что мы проверили после восстановления и чем докажем, что тот же сценарий не застигнет нас врасплох?

Если ваш сайт уже возвращали к жизни перезапуском, а причина сбоя осталась неясной, обратитесь в Maxiplace. Укажите время инцидента, пострадавший сценарий и то, что уже проверили. Инженеры смогут оценить доступные данные о серверной части и мониторинге и определить вместе с вашей командой следующие шаги расследования. Возможности сопровождения зависят от проекта и выбранной услуги.