
В субботу 13 сентября 2026 года, с 09:16 до 10:44 UTC, у GitHub случилось то, что его страница состояния отнесла к критическим инцидентам: запросы к API, Issues, Pull Requests, Actions и Pages работали с перебоями восемьдесят девять минут. К середине утра по Европе, ещё до того как проснулась большая часть Соединённых Штатов, всё было восстановлено, а подробный разбор причин обещан. Это не тот разбор, и здесь нет попыток угадать, что в нём будет.
Речь здесь об одной фразе, которую GitHub опубликовал через двадцать минут после начала инцидента, потому что эта фраза - учебный пример получше большинства постмортемов.
Строка, которую стоит прочитать дважды
В 09:36 UTC на странице состояния появилось:
We’re seeing increased database replication delays on collab which is causing increased error rates in authorization endpoints and follow-on increased error rates across the system.
Прочитайте это как цепочку. Один кластер базы данных отстал в репликации. Из-за этого начали сбоить эндпоинты, решающие, разрешено ли вам что-то делать. А поскольку почти всё задаёт этот вопрос, прежде чем что-либо сделать, сбоить начало почти всё.
Три слоя: причина, то, что причина сломала, и то, что сломалось из-за этого. Снаружи GitHub был виден только последний слой.
Как это выглядело с вашего места
Если вы работали в субботу утром, вы не видели задержки репликации. Вы видели одно из этого:
-
403от API на запрос, который вчера работал. - Страницу pull request, которая не грузилась или грузилась без своих проверок.
- Прогон Actions, упавший с ошибкой о правах или ни о чём конкретном.
- Pages, которые не публиковались.
Ничто из этого не говорит “база данных отстала”. Каждое говорит скорее “ваш аккаунт, ваш токен или ваш код неправильны”. Ошибка 403 в особенности - это та ошибка, которая говорит, что знает, кто вы, и всё равно отвечает “нет”, и получать такое очень конкретно звучащее сообщение из-за того, что где-то реплика отстала на несколько секунд, - странно.
Такова общая форма, и ей стоит дать имя: ошибка, которую вы видите, - это симптом, и симптом может отстоять от причины на несколько слоёв. Слои - не обман. Каждая система в цепочке честно сообщила то, что видела. Эндпоинт авторизации действительно не мог подтвердить, что вам разрешено; API действительно был обязан отказать. Сообщение было правдиво на каждом шаге и бесполезно на последнем.
Почему это важнее самого сбоя
Восемьдесят девять минут в субботу - это небольшой инцидент, и GitHub справился с ним хорошо: запись о состоянии за минуты, названная причина в пределах двадцати, сброс нагрузки для восстановления вместо ожидания, пока реплика догонит сама, и обещание полного разбора. Так выглядит хорошая работа, и об этом стоит сказать.
Причина писать об этом в том, что та же трёхслойная форма лежит под большинством плохо описанных багов, а суббота - необычно чистый её образец.
Когда кто-то говорит “я получил 403”, он сообщает о третьем слое. Когда разработчик читает “403” и начинает проверять права этого человека, он отлаживает второй слой. Причина была в первом слое, в месте, которого ни один из них не видел, и ни отчёт, ни расследование до неё не доберутся, рассуждая от сообщения. Сообщение - это категория. Это не случай. Так устроено всё семейство ошибок HTTP: каждая называет вид сбоя и умалчивает о конкретном.
Разрыв закрывает не более точное толкование кода. Его закрывают окружающие факты: какой запрос, в какое время, рядом с чем ещё. В субботу окружающим фактом было то, что это видели все сразу, и именно на этом вопросе построена прошлая статья о том, как отличить свой баг от их аварии, повторять её здесь незачем.
Что записывать, когда это не у всех
Трудный случай - тот, которого нет ни на чьей странице состояния. У вашей собственной системы те же слои: медленный запрос роняет сервис по таймауту, а тот роняет страницу. Человек, который на это наткнулся, получает третий слой, и то, что он запишет, решает, сможет ли кто-нибудь дойти обратно до первого.
Поэтому полезный отчёт - не диагноз. Это точно сформулированный симптом с его временем и
контекстом, без приложенной теории. “403 с /repos/x/y/pulls в 09:41 UTC, три повтора, тот же
вызов прошёл в 08:50” - отчёт, который можно сопоставить с графиком репликации. “Кажется, у меня
истёк токен” - теория, отправляющая не на тот слой.
Session Replay
Бесплатное расширение Chrome. Один клик на странице, которая ведёт себя неправильно, захватывает снимок экрана, консоль и сетевой журнал, и даёт вам ссылку для вставки в задачу.
Сетевой журнал - это точный запрос, точный статус и точная минута, захваченные без того, чтобы кому-то приходилось решать, на какой слой он, по его мнению, смотрит. Именно из этого материала строится разбор причин, будь то у GitHub или у вас.
В одном абзаце
13 сентября 2026 года GitHub работал с перебоями восемьдесят девять минут, и его собственная страница состояния назвала форму случившегося одной фразой: задержка репликации базы данных в одном кластере вызвала сбои в эндпоинтах авторизации, а те - сбои по всей системе. Три слоя, и снаружи был виден только последний - как ошибки 403 и страницы, которые не грузились. Урок не про GitHub, который справился хорошо и никому ничего не должен. Урок в том, что видимая вами ошибка - симптом, который может отстоять от причины на несколько слоёв, и потому помогает отчёт с точно сформулированным симптомом, временем и контекстом, а не теория о том, что он означает.