11 июня GitHub опубликовал отчёт о доступности за май — и это редкий случай, когда корпоративный post-mortem читается как учебник по эксплуатации. Девять инцидентов за месяц, и почти каждый бил по CI/CD, то есть по тому, без чего у команд просто останавливается работа.
Хронология примерно такая. 4 мая: рутинная онлайн-миграция схемы на высоконагруженной таблице выжрала пул соединений к базе, пиковая доля 5xx дошла до 1,3%, легли pull request'ы, issues, Actions и вебхуки. 5 мая: при масштабировании виртуалок для hosted runners в регионе East US упёрлись в рейт-лимит — почти четыре часа деградации, около 13,5% задач на стандартных раннерах не стартовали, ещё 8500 запросов на код-ревью в Copilot отвалились по таймауту. 6 мая вышло три инцидента подряд: конфигурационное изменение снесло ingress-путь к API сессий Copilot (100% отказов, 38 минут); затем 32-битный целочисленный ключ в lookup-таблице Vitess упёрся в максимум — и создание новых тредов ревью в pull request'ах перестало работать почти полностью на 3,5 часа; следом остаточные проблемы с раннерами уронили ещё 17,1% задач. 15 мая: обновление service discovery не разъехалось при failover — 42% запусков Actions упали за 35 минут. 26 мая: автоматика ошибочно заблокировала служебный аккаунт GitHub Actions, и новые воркфлоу перестали запускаться вовсе. 28 мая: сбой на стороне внешнего провайдера моделей деградировал Copilot.
Сам GitHub объясняет происходящее прямо: трафик растёт стремительно, и растёт он в первую очередь за счёт AI-ассистированной и агентной разработки. Ответ компании — переезд на Azure ради эластичной ёмкости, распил монолита на изолированные сервисы и устранение общих точек отказа. Звучит разумно; проблема в том, что перестройка идёт под нагрузкой, а счёт за неё в мае оплатили пользователи.
Что делать практикующему разработчику. Первое и главное — перестать считать GitHub Actions чем-то с гарантией. Если у вас деплой в прод идёт единственным воркфлоу на hosted runner в одном регионе, у вас нет CD, у вас есть надежда. Минимальная страховка: держите self-hosted-раннер или второй пул как запасной путь для релизных джобов, кэшируйте зависимости в собственном registry (в мае падали именно скачивания actions), проставьте разумные retry с бэкоффом на шаги, которые дёргают внешние API, и складывайте релизные артефакты в своё хранилище, а не только в GitHub Releases. Второе — вынесите из отчёта урок для себя: инцидент 6 мая с исчерпанием 32-битного ключа случается ровно так же в любом проекте, где первичный ключ до сих пор int4. Сходите в свою базу и посчитайте запас: SELECT max(id)::float / 2147483647 FROM your_hot_table; — если получилось больше 0,5, планируйте миграцию на bigint заранее, а не в ночь инцидента. Заодно поставьте на этот показатель алерт: это буквально та проверка, отсутствие которой GitHub записал себе в список исправлений.
Комментарии