17 августа 2026 года GitHub не работал семь часов сорок семь минут. Вместе с ним легли аутентификация, Actions, API, пул-реквесты, задачи и Copilot, и очень многие команды провели часть того дня, выясняя, не сломалась ли их собственная сборка.

Этот вопрос - это мы или это они - стоит уметь закрывать за две минуты, а не за два часа, и свидетельства, которые на него отвечают, исчезают вместе с концом инцидента.

Свидетельства, в том порядке, в каком они помогают

Какой хост отказывает. Откройте вкладку “Сеть” и посмотрите, куда уходят падающие запросы. 500 с вашего собственного домена - ваш. 503 от API, которую вы не держите, - не ваш, как бы ни казалось, что сломалась именно ваша функция. Звучит очевидно, и именно этот шаг пропускают: симптом виден в вашем интерфейсе, а на интерфейс и смотрят.

Что говорит код ответа. 401 или 403 во время чужого инцидента с аутентификацией - это не ошибка прав доступа в вашем коде, и именно её чаще всего заводят как такую ошибку. 429 - это ограничение частоты, и оно может быть следствием ваших же повторных запросов. Таймаут вообще без ответа чаще указывает наружу, чем внутрь.

Совпадает ли это с вашим деплоем. Первый вопрос в любом канале инцидентов - что изменилось. Если последний релиз был за три часа до появления симптомов, об этом стоит сказать в первом сообщении, а не в пятом.

Что написано на их странице статуса - смотреть туда стоит вторым делом, а не первым. Страницы статуса обновляют люди, которым сейчас некогда, и они отстают от отказа на несколько минут. Ваша собственная вкладка “Сеть” знает раньше, чем их страница статуса.

Ловушка: ваши повторы могут сделать хуже

Часть рассказа GitHub, которую стоит перечитать дважды, - это то, что происходило во время восстановления. Их разбор инцидента говорит:

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

То есть клиенты, которые сильнее всех пытались прорваться, сами были частью того, что держало дверь закрытой. Список мер GitHub называет решение в общих словах: “согласованные лимиты повторов, бюджеты повторов и переменные таймауты во всех межсервисных вызовах, чтобы не допускать штормов повторов и каскадной нагрузки”, - и эту фразу стоит приложить к собственному коду.

Логика повторов, написанная под один упавший запрос, ведёт себя иначе, когда падают все запросы. Без бюджета, без выдержки и без разброса сотня экземпляров, повторяющих по одному и тому же расписанию, превращается в синхронный нагрузочный тест, направленный на сервис, которому и так тяжело.

Стоит знать и то, что ни один из двух августовских инцидентов GitHub не был вызван изменением кода или конфигурации. Оба были отказами по ёмкости. Привычка искать деплой, который всё сломал, обычно верна и здесь была неверна.

Снимите это, пока оно сломано

Сбой - это единственный класс дефектов, который чинит себя сам, и свидетельства уходят вместе с ним. Через два часа запрос, отдававший 503, отдаёт 200, а в задаче до конца её жизни написано “плавающая ошибка, не воспроизводится”.

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

Session Replay

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

Установить расширение

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

Записать так, чтобы это не завели не туда

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

Если отказ чужой, скажите об этом в заголовке и напишите, что это значит для вас: какая функция затронута, есть ли обходной путь и чего вы ждёте. “Оформление заказа не работает - внешний платёжный провайдер отдаёт 503 с 14:10, обходного пути нет, их страница статуса это подтверждает” - это полный отчёт. Воспроизводить его никому не нужно, и пробовать не стоит.

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

А если вы честно ещё не знаете, так и напишите. “Непонятно, наше ли это - падающие запросы уходят на внешний хост, но наш релиз выехал в 13:30” полезнее уверенной догадки в любую из сторон.

Потом

Два вопроса, которые стоит задать после инцидента, пока люди ещё помнят.

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

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

Источники: собственный рассказ GitHub об инциденте лежит в The August 17 outage, and the work ahead, и он на удивление конкретен в том, что именно пошло не так. Опубликован к их чести и процитирован здесь потому, что разбор, который прямо называет шторм повторов, полезнее любых советов о нём.