GitHub становится недоступным для разработчиков в РФ
GitHub в России формально не объявлен заблокированным, но рост сбоев 5-7 мая уже выглядит не как шум, а как инфраструктурный риск для разработки и CI/CD.
Проверено 12 мая 2026 года. 5 мая доступность GitHub в России начала заметно проседать. По данным OONI, на которые 8 мая ссылались Meduza, «Вёрстка» и Computerra, доля неудачных подключений к сервису выросла до 10%, а 6 и 7 мая дошла до 16%. На этом фоне Роскомнадзор заявил, что доступ к ресурсам GitHub ведомством не ограничивается. Формально это не позволяет честно написать «GitHub заблокирован». Для команд важнее другое: если платформа с репозиториями, релизами, issue-трекером и CI открывается нестабильно, это уже не новостной шум, а инфраструктурный риск.
История неприятна ещё и потому, что в те же дни у самого GitHub были собственные глобальные инциденты. 5 мая платформа признала сбои SSH-операций, 6 мая — деградацию GitHub Actions, Pull Requests и части сервисов Copilot. В таком тексте нельзя сводить всё к одной причине. В начале мая российские разработчики увидели деградацию доступа к GitHub, а поверх этого наложились реальные сбои самой платформы. Для технической аудитории важен именно этот двойной сигнал.
| Дата | Что подтверждено | Почему это важно | Источник |
|---|---|---|---|
| 5 мая 2026 | По данным OONI, доля неудачных подключений к GitHub в России выросла до 10%. | Это первый день, когда проблема выходит за пределы фонового шума апреля. | Meduza / «Вёрстка» / Computerra |
| 6-7 мая 2026 | Показатель OONI вырос до 16% и держался на этом уровне. | Речь уже не о единичных жалобах, а о заметной деградации доступности. | Meduza / «Вёрстка» / Computerra |
| 5-6 мая 2026 | GitHub признал собственные инциденты: SSH-сбои с пиком 0,6% write-запросов и деградацию Actions, где не прошли 17,1% job на standard runner. | Это мешает свести всю картину к одной локальной причине и требует аккуратной интерпретации. | GitHub Status |
| 8 мая 2026 | Роскомнадзор публично заявил, что доступ к GitHub ведомством не ограничивается. | Юридический сигнал и фактическая доступность платформы разошлись. | Коммерсантъ / Интерфакс |
Что показывают данные OONI и жалобы пользователей
Ключевой факт этой истории пришёл не от самой платформы и не от регулятора, а из измерений OONI и пользовательских жалоб. Meduza со ссылкой на «Вёрстку» пишет, что доступность GitHub в России начала снижаться 5 мая: количество неудачных подключений в этот день достигло 10%, а 6 и 7 мая выросло до 16%. В предыдущие недели среднее значение аномалий не превышало 4%.
Важно не передёргивать смысл этих цифр. OONI измеряет сетевые аномалии через тесты Web Connectivity и сама предупреждает, что не всякая аномалия равна доказанной блокировке. Это сильный инструмент наблюдения, но не автоматический вывод о том, кто виноват. Поэтому корректнее писать так: в начале мая OONI и пользователи зафиксировали заметное ухудшение доступности GitHub в России. Этого уже достаточно, чтобы считать тему значимой для рынка, но недостаточно, чтобы без дополнительных доказательств объявлять тотальную блокировку.
Для Toolarium здесь важен именно инженерный смысл новости. GitHub давно перестал быть просто витриной с репозиториями. Мы уже разбирали это в материале GitHub RCE через git push: как сломался доверенный pipeline: платформа встроена в доверенный контур доставки кода, а не живёт где-то на периферии процесса. Поэтому даже частичная деградация доступа бьёт не только по чтению README, но и по рабочим цепочкам команды.
Что именно отрицает Роскомнадзор
8 мая Роскомнадзор через Интерфакс и Коммерсантъ заявил: «В связи с появившимися сообщениями информируем, что доступ к ресурсам GitHub ведомством не ограничивается». Это важная часть картины. Регулятор не признал блокировку, а значит, сильные заголовки в духе «GitHub официально заблокировали в России» на текущем наборе фактов не выдерживают проверки.
Но из этого не следует и обратное: будто проблемы можно списать на истерику пользователей. Когда у заметной доли аудитории платформа начинает открываться нестабильно, для инженерной команды практическая реальность важнее формулировки пресс-службы. Код либо доступен в нужный момент, либо нет. Деплой либо доезжает, либо встаёт. Поэтому статья и должна держать точную, но не наивную формулировку: формального объявления о блокировке нет, а фактическая стабильность доступа вызывает вопросы.
Это хорошо рифмуется и с более широким контекстом зависимости российских команд от зарубежной инфраструктуры. Мы уже смотрели на эту проблему в материале ИИ для российских компаний: что реально доступно в 2026 году. История с GitHub показывает, что уязвимость живёт не только в области моделей или SaaS-подписок. Риск лежит глубже: в базовом слое разработки, где платформа с кодом и автоматизацией становится единой точкой отказа.
Почему нельзя свести всё к одной причине
Проще всего было бы свести это к одной причине, но факты этому сопротивляются. У GitHub в те же дни были собственные глобальные инциденты, и они подтверждены не пересказами в Telegram, а официальной status-страницей платформы.
5 мая GitHub сообщила об Increased Latency and Failures for SSH Git Operations. Компания пишет, что между 14:00 и 16:10 UTC средняя доля ошибок SSH-операций составила 0,46%, а пик дошёл до 0,6% write-запросов. HTTP-операции, включая web UI и HTTPS clone, GitHub тогда считала незатронутыми. Уже 6 мая последовали новые проблемы: деградация GitHub Actions, где не прошли 17,1% job на standard Ubuntu runners, затем критический инцидент с Pull Requests и отдельная поломка Copilot Cloud Agent / remote sessions.
Эти инциденты не доказывают, что российские жалобы были ложными. Но они делают обязательной аккуратную развязку причин. Часть проблем могла идти от самой платформы, часть — от локальной сетевой среды, а часть — от наложения нескольких факторов сразу. Именно поэтому текст нельзя строить в режиме «всё уже ясно». Здесь честнее и полезнее для читателя показать, что даже в новостном цикле про доступность платформы нужны уровни неопределённости.
Заодно эта история показывает, насколько глубоко GitHub уже встроен в повседневную рабочую среду. Даже в новости о деньгах мы недавно писали об этом косвенно: GitHub Copilot переходит на usage-based billing с 1 июня 2026 именно потому, что GitHub всё сильнее превращается из набора отдельных функций в общий рабочий контур для разработчика. Когда такой контур даёт сбой, сбой затрагивает сразу несколько рабочих связок.
Почему даже неполная деградация GitHub уже стала инфраструктурным риском
Для технического менеджера или тимлида проблема GitHub важна не на уровне символической политики, а на уровне конкретных узких мест. Нестабильный доступ к платформе бьёт по разным слоям сразу. Репозитории перестают быть предсказуемой точкой входа для новых окружений. SSH push и pull начинают флапать в самый неудобный момент. CI/CD завязан на Actions, а релизные артефакты и issue-обсуждения живут там же, где исходный код.
Отсюда и более жёсткий вывод. Даже если сбои не выглядят как стопроцентная блокировка, для команды они уже превращаются в риск планирования. Если платформа нестабильна 10-16% времени для части аудитории, это не «немного медленнее открывается сайт». Это вероятность, что у разработчика не поднимется окружение, не дотянется submodule, не уйдёт push перед релизом, не стартует automation или зависнет ручная проверка pull request.
В этом смысле тема GitHub в России на неделе 5 мая интереснее, чем типичная история про очередной недоступный зарубежный сервис. GitHub для инженерных команд — не периферийный инструмент, а слой координации. Когда проблемы начинаются именно там, страдают не только разработчики, но и все зависимые процессы: ревью, релизы, автоматические проверки, внутренние интеграции, зеркала документации и цепочка поставки open-source-кода.
Что командам стоит проверить уже сейчас
- Отделите критические маршруты: clone, pull, push, Git LFS, release artifacts, Actions, package-fetch из GitHub Releases и зависимые интеграции.
- Проверьте, какие сценарии у вас жёстко завязаны на SSH. Если часть операций можно безопасно дублировать через HTTPS, это хотя бы снижает риск одного канала отказа.
- Поднимите или обновите read-only mirrors для критичных репозиториев и внешних зависимостей. Это дешевле, чем экстренно мигрировать в момент инцидента.
- Разведите код и автоматизацию. Если Actions недоступны, команда должна понимать, как выглядит ручной или альтернативный путь до релиза.
- Проверьте кэширование зависимостей и артефактов во внутреннем контуре. Чем меньше вы тянете с GitHub в реальном времени, тем ниже оперативный риск.
Важно, что это не призыв срочно «уезжать с GitHub любой ценой». На текущем наборе фактов разумнее не истерическая миграция, а снижение зависимости от единственного внешнего узла. Инфраструктурная зрелость здесь измеряется не лозунгами про импортозамещение, а способностью пережить нестабильность ключевой платформы без остановки команды.
Итог
История с GitHub в России на неделе 5 мая 2026 года важна не потому, что кто-то уже официально объявил блокировку. Она важна потому, что несколько источников одновременно показали неприятный для рынка сценарий: OONI и пользователи фиксируют деградацию доступа, Роскомнадзор её не признаёт, а сам GitHub в эти же дни переживает собственные глобальные сбои. Для разработчиков это означает простую вещь: дело уже не в статусе платформы на бумаге, а в надёжности доступа к ней в рабочем контуре.
Если у вас вся разработка, ревью, часть CI и релизная логистика живут на GitHub, майские сбои нужно читать не как очередную политическую новость, а как сигнал на ревизию зависимости от одной платформы. Именно в этом и есть главный сюжет: GitHub в России может быть формально «не заблокирован», но для части команд уже становится инфраструктурным риском.
Читайте также
- GitHub RCE через git push: как сломался доверенный pipeline
- GitHub Copilot переходит на usage-based billing с 1 июня 2026
- ИИ для российских компаний: что реально доступно в 2026 году
Источники и дата проверки
Факты в этом материале проверены 12 мая 2026 года. Для быстро меняющейся части сюжета важно различать три слоя: данные наблюдения OONI, заявления российских регуляторов и официальные incident reports самого GitHub.
