После нескольких дней разговоров о возможной недоступности GitHub в России депутат Антон Горелкин был вынужден уточнить позицию: платформу он не считает вредительской, а наоборот называет «чрезвычайно ценной» для IT. Для российской индустрии это важная оговорка: когда спор идет вокруг инфраструктуры, от которой зависят код, сборки и поставка релизов, любые политические формулировки быстро превращаются в операционный риск, и именно поэтому вопрос о ценности GitHub звучит не как риторика, а как сигнал рынку.
Первый заместитель председателя комитета Госдумы по информационной политике, информационным технологиям и связи объяснил в своем Telegram-канале, что не призывал к блокировке GitHub и что часть медиа, по его версии, неверно интерпретировала его прежние слова, сообщает Habr / Новости. По словам Горелкина, он лишь указал на дискриминацию российских пользователей со стороны владельцев платформы и на риск того, что ограничения могут расшириться, если Microsoft продолжит текущую политику. Ключевая деталь здесь именно в смене акцента: вместо оценки сервиса как проблемы он публично признает ценность GitHub для отрасли и фактически подтверждает очевидное для любой команды разработки — GitHub давно перестал быть просто удобным хостингом репозиториев.
Повод для новой реплики понятен. Ранее в публичном поле разошлась более жесткая формулировка о том, что GitHub в России может стать недоступен на 100%. На этом фоне обсуждение быстро ушло из технической плоскости в политическую: одни увидели намек на внутренние ограничения, другие — предупреждение о внешнем давлении со стороны американского владельца платформы. Затем 8 мая 2026 года Роскомнадзор отдельно заявил, что не ограничивает доступ к ресурсам GitHub. Это был важный момент, потому что для рынка принципиально понимать источник риска: одно дело, когда проблемы связаны с сетевой деградацией или политикой зарубежного сервиса, и совсем другое — когда речь идет о решениях российского регулятора.
Технический фон у этой истории тоже есть, и он не выглядит выдуманным. В последние дни российские пользователи жаловались прежде всего не на сам сайт GitHub, а на конкретные домены инфраструктуры, включая raw.githubusercontent.com и release-assets.githubusercontent.com. Это уже не абстрактный спор о свободе доступа, а вполне прикладная проблема: первый домен нужен для загрузки файлов из репозиториев, второй — для получения release-артефактов. Если такие узлы работают с задержками или частично отваливаются, страдают CI/CD-цепочки, сборка зависимостей, доставка бинарников и внутренняя разработка. По данным OONI, сервис отслеживания интернет-цензуры зафиксировал аномалию, а на пике 6 мая доля неудачных соединений достигала 16%. Для платформы масштаба GitHub это уже не шум на графике, а показатель, который разработчики замечают в ежедневной работе.
Сам GitHub в начале мая объяснял два последних инцидента с доступностью процессами по наращиванию мощностей и повышению отказоустойчивости платформы. Формально это техническое объяснение, и оно выглядит правдоподобно: крупные облачные сервисы действительно периодически перестраивают инфраструктуру, а такие изменения иногда бьют по отдельным регионам или по пограничным узлам доставки контента. Но для российских команд этого уже недостаточно. Когда доступ к ключевой платформе становится нестабильным, бизнес редко интересует, произошло это из-за апгрейда мощностей, маршрутизации трафика или политических решений владельца. Для CTO, DevOps-инженера или продакта итог один: растет зависимость от внешнего сервиса, чье поведение компания не контролирует.
Отсюда и нервозность вокруг слов Горелкина. С одной стороны, он прямо указывает на опасения, что Microsoft может усилить ограничения для пользователей из России. В подтверждение приводит и соседний кейс: массовые блокировки российских аккаунтов в Claude, из-за которых, по его словам, многие разработчики потеряли доступ к своим проектам. С другой стороны, даже в этом комментарии чувствуется двойственность позиции. Государство признает ценность GitHub, но обсуждение идет в логике «слишком важная внешняя платформа, чтобы ей доверять без оговорок». Для рынка это не новая мысль, но сейчас она стала особенно практичной: чем критичнее роль GitHub в процессах компании, тем дороже обходится любая неопределенность вокруг доступа.
Именно поэтому ценность GitHub для российских разработчиков имеет обратную сторону. Платформа стала отраслевым стандартом не только как место хранения кода, но и как единая точка интеграции для pull request, code review, release management, DevSecOps-проверок, automation-сценариев и open source-экосистемы. Замена такого сервиса не сводится к переносу репозиториев в другое хранилище. Нужно пересобирать процессы, права доступа, пайплайны, интеграции с внешними сервисами, внутреннюю документацию и привычки команд. Для стартапа это болезненно, для крупной компании — дорого, для распределенной инженерной организации — еще и медленно. Поэтому признание ценности GitHub на официальном уровне, пусть и в оборонительной форме, звучит как запоздалое напоминание: речь идет не о сайте, а о слое инфраструктуры.
Для бизнеса из этой истории следует довольно прозаичный вывод. Даже если текущие проблемы с доступом действительно вызваны техническими работами на стороне GitHub, а не прямыми ограничениями, компании уже получили повод проверить свою устойчивость. Есть ли зеркала критичных репозиториев, локальные хранилища зависимостей, резервные каналы доставки релизов, запасной сценарий для CI и понятный план миграции хотя бы на уровне учений? Пока GitHub работает, такие вопросы обычно откладывают. Как только raw- и release-домены начинают отвечать с задержкой, выясняется, что запасного плана у многих нет, хотя разговоры о технологическом суверенитете идут не первый год.
История с пояснением Горелкина интересна не тем, что политик неожиданно полюбил GitHub, а тем, что публичная дискуссия впервые за долгое время приблизилась к реальности инженерных команд. Ценность GitHub уже никто особенно не оспаривает. Открытым остается другой вопрос: сумеет ли российский IT-рынок снизить зависимость от платформы без административной суеты и показательных лозунгов, то есть нормальным инженерным способом — через дублирование критичных процессов, резервирование и скучную, но полезную подготовку к сбоям.