Флаг-фича в GitHub тихо отписал Slack- и Teams-каналы на два часа

Два часа, когда GitHub сообщал, что вы «больше не авторизованы»

Страница инцидента GitHub фиксирует это сухо: «Проблема с авторизацией, повлиявшая на API, включая некоторые подписки Slack и Teams.» На практике это выглядело острее. Инженер описал момент в треде:

«Коллега написал, что получил сообщение: сообщения его репозитория не могут быть отправлены, потому что пользователь больше не авторизован. Коллега испугался, что его увольняют.» — C++-инженер, увидевший, как это затронуло его команду

Что именно сломалось — по таймлайну

Отчёт об инциденте конкретен по причине и масштабу. Недавно включённый флаг-фича вызвал отклонение легитимных авторизованных запросов как неавторизованных в период с 14:49 до 16:45 UTC. Chat-интеграции восприняли эти ложные ошибки авторизации как сигнал к удалению подписок — так Slack- и Teams-каналы тихо отписались от своих репозиториев. Цифры GitHub по масштабу были невелики: «небольшой, но повышенный процент» авторизованных запросов завершался ошибкой, что дало рост 4xx-ошибок на 1–2% на конкретных эндпоинтах, при этом подавляющее большинство трафика не пострадало.

Последовательность устранения:

• 17:20 UTC — GitHub начинает расследование нарушения производительности.
• 18:04 UTC — установлена первопричина (флаг-фича); флаг отключён; пользователям предложено «переподписать репозитории вручную».
• 18:05 UTC — деградация устранена.
• 20:34 UTC — масштаб инцидента уточнён (рост 4xx на 1–2%, окно 14:49–16:45 UTC).
• 22:21 UTC — «Затронутые подписки Slack и Teams восстановлены».

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

Тред: «это вообще инцидент?"

Реакция devops-сообщества была не сочувствием, а узнаванием. Несколько человек сказали, что интеграция ломается тихо на регулярной основе и без всякой страницы статуса:

«Наш github->slack хук ломается каждые несколько месяцев, раньше они это никогда не признавали. В какой-то момент мы сделали документ со списком репозиториев и настроек… просто проходимся по нему и переподписываемся.» — инженер, ведущий runbook для переподписки

Другой читатель понял это лишь задним числом:

«Я думал, зачем у меня истекла авторизация и пришлось переподписываться в одном из каналов… Решил, что просто пропустил напоминание по электронной почте.» — комментатор, молча наткнувшийся на тот же баг

С точки зрения надёжности был отмечен системный характер проблемы:

«Значит, они продержались 9 дней до следующего инцидента… Репутация GitHub давно переоценена, и вам лучше хостить самим — аптайм будет выше.» — комментатор, сославшийся на предыдущий инцидент девятидневной давности

А платформенный инженер привёл долгосрочный аргумент в пользу владения стеком:

«Я запускаю GitLab внутри на k8s уже 6 лет… Ежемесячные обновления проходят без боли… Не вижу ни одной области, где [GitHub] лучше.» — платформенный инженер из Бостона, запускающий self-hosted GitLab

Маленький флаг, нагруженный дефолт

Технический урок узкий, но реальный: ошибка авторизации и намеренная отписка никогда не должны делить один путь в коде. Временная 4xx-ошибка от сработавшего не так флага была повышена до деструктивного, постоянного изменения состояния — удаления подписок, — тогда как безопасным дефолтом был бы retry или удержание. GitHub поступил правильно, восстановив потерянные подписки, а не пожав плечами и предложив всем пересоздавать их самостоятельно. Но то, что всплеск ошибок на 1–2% мог тихо разорвать интеграции на два часа, — именно это ведущие runbook-записи в треде уже давно научились ожидать.