GitHub упал на 8 часов из-за нехватки ресурсов автоскейлинга
Опубликовано: · 585 слов
GitHub, крупнейшая платформа для разработки, 17 августа 2026 года на несколько часов вышла из строя из-за банальной нехватки вычислительных ресурсов. Для бизнеса, который строит или заказывает собственный веб-сервис, это хороший повод свериться с архитектурой на предмет узких мест.
Что случилось
С 17 на 18 августа 2026 года GitHub столкнулся с глобальным сбоем продолжительностью около 7 часов 47 минут. Инцидент затронул широкий спектр сервисов, включая GitHub.com, Actions, Copilot, Issues, Pull Requests и авторизацию, при этом пиковый процент ошибок достигал примерно 20% для веб- и API-трафика и около 50% для скачивания архивов и файлов репозиториев.
20 августа GitHub опубликовал результаты расследования, объяснив, что причиной стал сбой критической инфраструктуры дата-центра в США, которая не смогла автоматически масштабировать вычислительные мощности при рекордном трафике, что вызвало каскадный дефицит ресурсов. Технически проблема была точечной: на фоне рекордного трафика прокси-сайдкары Istio, отвечающие за обмен данными между сервисами, достигли предела обработки, но механизм автомасштабирования не учитывал ёмкость сайдкаров и поэтому не запустил расширение. Компания подчеркнула, что напрямую инцидент не вызвало никакое изменение кода или конфигурации, это была чистая проблема нехватки ресурсов.
Инженерам пришлось перенаправлять трафик, изолировать затронутую инфраструктуру и поэтапно восстанавливать сервисы. Это лишь один эпизод из целой серии похожих сбоев платформы летом 2026 года, что указывает на системную, а не разовую проблему.
Что это значит для бизнеса СНГ
Даже у компании с ресурсами уровня Microsoft система масштабирования может иметь слепую зону: автоскейлинг реагирует на одну метрику (CPU, память приложения), но не видит перегрузку промежуточного слоя, будь то прокси, шлюз, база данных или очередь сообщений. Аналитики, разбиравшие серию инцидентов GitHub, приходят к похожим выводам о причинах хронических сбоев: тесная связанность компонентов позволяет мелким сбоям распространяться дальше, защита от аномального трафика оказывается слабой, а эластичность не успевает за резкими скачками нагрузки, возникающими вне обычных циклов.
Для владельца интернет-магазина, SaaS-сервиса или личного кабинета вывод простой: рекламная кампания, распродажа, вирусный пост в соцсетях или массовая рассылка могут создать такой же локальный дефицит ресурсов, даже если общая инфраструктура выглядит достаточной "на бумаге". Если приложение не тестировалось под нагрузкой, узкое место найдётся не на этапе планирования, а в момент, когда трафик уже пошёл и каждая минута простоя стоит клиентов и денег.
Что делать
- Провести нагрузочное тестирование до пикового события (запуск рекламы, распродажа, сезонный спрос), а не после первого отказа. Тестировать нужно не только фронтенд, но и всю цепочку: API, очереди, базу данных, внешние интеграции с кассами и эквайрингом.
- Проверить, что автомасштабирование настроено по реальным узким местам сервиса, а не только по CPU основного контейнера. Часто перегружается конкретный компонент - шлюз, кэш, соединение с базой, а не всё приложение целиком.
- Разделить критичные и некритичные части системы (модульная архитектура, отдельные очереди для тяжёлых операций), чтобы сбой одного модуля не уронил весь сервис, как это произошло с GitHub, где проблема сайдкаров задела почти все продукты платформы.
- Настроить мониторинг с алертами по деградации, а не только по полному отказу: рост ошибок на 5-10% - это сигнал действовать, а не ждать падения.
- Заложить план деградации: если часть функций отказывает, основной сценарий покупки, заказа или входа должен продолжать работать в упрощённом режиме.
Если вы планируете запуск веб-приложения, CRM-системы или сервиса с ожидаемым ростом трафика и хотите заранее спроектировать архитектуру без риска отказа под нагрузкой, команда SOVREST берёт на себя проектирование, разработку и нагрузочное тестирование под задачу бизнеса. Подробнее об услугах - на странице /services.