GitHub падает — и по всему миру затихают конвейеры сборки. Не проходят тесты, не деплоится код, npm не отдаёт пакеты, IDE не пускают в репозитории. Платформа, задуманная как простой хостинг git-репозиториев, давно работает как операционная система разработки: CI, пакеты, ревью, релизы и ИИ-помощники — всё в одном флаконе. Удобно? Очень. Но удобство такого масштаба оборачивается концентрацией риска: авария одного вендора останавливает десятки тысяч команд одновременно. Как мы до этого докатились, чем грозит долгий простой и какие запасные пути уже существуют — обо всём по порядку.
В 2008 году GitHub открылся как витрина для git-репозиториев — не более того. А ведь сам git Линус Торвальдс задумывал ровно наоборот: распределённой системой, где полная история проекта лежит на ноутбуке у любого разработчика. GitHub не спорил с философией — он добавил то, чего у чистого git не было: pull request'ы, issues, звёзды, социальный слой. Open source переехал туда всем миром, за ним подтянулись компании, следом — их инструменты. Покупка платформы Microsoft в 2018-м лишь закрепила статус-кво.
А дальше платформа начала есть весь цикл разработки, кусок за куском. Actions забрал себе CI/CD, Packages — хранилище артефактов, Dependabot — обновление зависимостей, Codespaces — облачные среды, Copilot — ИИ-ассистента прямо в редакторе. Под капотом — ещё и реестр npm, купленный вместе с одноимённой компанией: установка любой JavaScript-зависимости на планете идёт через гитхабовскую инфраструктуру. Зачем держать отдельно Jenkins, Gerrit и Artifactory, когда всё интегрировано из коробки? Скучно и дорого. Вот только миграция теперь — не копирование репозиториев: уходя, тянешь за собой историю ревью, настройки конвейеров, релизы и права доступа.
Картина типового инцидента знакома каждому, кто хоть раз заглядывал на статус-страницу GitHub: ложатся Actions, подвисают pull request'ы, веб-интерфейс не пускает внутрь. И на каждом таком эпизоде отлично видно, как работает механика каскада. Отказала аутентификация — IDE и CI-агенты не могут склонировать код, хотя git-серверы формально живы. Встал Actions — замерли сборки, тесты и деплои; команды, живущие релизными поездами, пропускают окна поставки. Лёг npm — посыпались сборки у тысяч проектов, где не изменилось ни строчки: реестру просто не до вас. Останавливаются даже патчи безопасности — Dependabot не откроет pull request, пока платформа лежит.
Совсем плохой сценарий уже случался. В 2018 году после аварии сетевой инфраструктуры GitHub больше суток провёл в деградировавшем режиме — инцидент теперь разбирают в учебниках девопса. Арифметика отсюда неутешительная. Короткий сбой — потерянные часы. Многодневный — замороженные релизы, несобранные исправления уязвимостей и сорванные обязательства сразу у десятков тысяч компаний.
Смешно, но сам git к такому сценарию готов идеально: git clone --mirror снимает полную копию репозитория со всей историей, а bundle-файл и вовсе уезжает на флешке. Проблема — во всём, что вокруг кода: issues, ревью, история конвейеров и кеши пакетов сами никуда не переедут. Поэтому рабочие запасные пути складываются в три уровня. Первый — банальная гигиена: регулярные зеркала и экспорт метаданных, чтобы код не существовал в единственном экземпляре. Второй — self-hosted альтернативы: GitLab, Gitea или Forgejo на собственных серверах, куда CI уходит, когда внешняя витрина недоступна; ядро Linux и GNOME свою инфраструктуру держат давно и, судя по всему, не жалеют. Третий — распределённые модели: Radicle устраивает p2p-совместную работу поверх git вовсе без центрального сервера, а ForgeFed пытается подружить форжи между собой — чтобы общались, как почтовые серверы.
Ни одна из этих схем не заменит экосистему GitHub целиком — но и не надо. Достаточно, чтобы сборка и деплой умели прожить без неё хотя бы сутки. Проверяется всё «пожарной тренировкой»: раз в квартал гонять критичный конвейер с зеркала и смотреть, занимает ли переключение минуты. Если дни — вы уже не репетируете, вы надеетесь.
В России тема централизации ощущается острее, чем где-либо. Крупные технологические компании и банки годами держат собственные инсталляции GitLab и Bitbucket — традиция on-premise-разработки здесь заметно крепче западной. А с учётом возможных ограничений на зарубежных сервисах миграция на свои платформы из осторожной меры превращается в обязательную программу. Выросли и отечественные публичные витрины: GitFlic с поддержкой CI и приватных репозиториев, GitVerse, который позиционируют как российскую альтернативу GitHub. Корпоративный сегмент по-прежнему закрывают сборки GitLab и лёгкие self-hosted решения вроде Gitea.
Свои ограничения никуда не денешь. Код-то переедет, а мировое open source-комьюнити — нет: ключевые проекты по-прежнему живут на GitHub, и отключаться от него целиком никто не торопится. Зависимость уходит вглубь цепочки поставок: npm, PyPI и Maven Central остаются зарубежными, поэтому компании ставят проксирующие хранилища артефактов, кеширующие пакеты внутри своего периметра. Итоговая модель — «свой форж плюс свой CI плюс локальное зеркало пакетов» — GitHub не отменяет, но превращает его из единственной точки входа в один из источников. К этой модели, кстати, через опыт сбоев приходит вся индустрия.
Концентрация мировой разработки на одной платформе — не заговор, а побочный эффект удобства. Всё в одном месте, интегрировано из коробки, open source ничего не платит. Но за удобство кто-то платит, и красный баннер на статус-странице показывает счёт нагляднее любой аналитики. Короткий сбой — лёгкий испуг. А многодневный простой всерьёз не репетировал никто. Между тем минимальная гигиена по силам любой команде уже сейчас: зеркала репозиториев, экспорт issues и настроек, независимый канал сборки, отработанный план переключения. Git когда-то спас сам код, сделав его распределённым. Задача следующего десятилетия — сделать точно так же устойчивым всё, что вокруг кода. Сбои GitHub — бесплатные учения. Ходить на них стоит, пока учения не превратились в настоящую тревогу.