Есть вещи, которые в IT замечают не сразу. Не потому что они мелкие — наоборот, потому что слишком системные. Они не падают с громким хлопком, не выключают всё разом. Они начинают… мешать. Чуть-чуть. Потом сильнее.
Вот именно так, судя по всему, сейчас и происходит с российским технологическим сектором.
Сначала это выглядит как странная задержка при git pull. Потом — как нестабильный CI. Потом — как ночь, ушедшая на то, что раньше занимало десять минут. И в какой-то момент кто-то в команде говорит: «Подождите. Это уже не совпадение».
Неприятная правда про “невидимую” инфраструктуру
Разговоры про VPN в публичном поле обычно сводятся к политике, обходу блокировок и пользовательскому доступу к сервисам. Но это довольно поверхностный слой.
Для IT VPN — это не “обход”, а базовый инструмент. Иногда даже не осознаваемый как отдельная сущность.
- доступ к приватным репозиториям
- защищённые соединения между сервисами
- CI/CD, который тянет зависимости из внешних источников
- контейнерные registry
- доступ к staging/production-инфраструктуре
И всё это часто работает поверх тех самых туннелей, которые сейчас начали активно фильтроваться.
В какой-то момент регулятор пытается “выключить VPN как класс”. Но сеть — не выключатель. Она не понимает намерений. Она видит паттерны.
И вот здесь начинается самое интересное.
DPI не различает “хороший” и “плохой” VPN
Если упростить: системы фильтрации трафика (DPI) не обладают человеческим пониманием контекста. Они не знают, где разработчик синхронизирует репозиторий, а где пользователь открывает заблокированный сайт.
Они видят:
- зашифрованный трафик
- характерные сигнатуры протоколов
- подозрительные туннели
И начинают резать.
В результате корпоративные VPN, DevOps-инфраструктура и пользовательские обходы блокировок попадают под один и тот же нож. Без особых различий.
Один из инженеров, которого цитируют в отрасли, формулирует это почти буднично:
«Мы просто стали выглядеть для сети как любой другой VPN. И нас начали душить так же».
Звучит холодно. Но за этим — вполне конкретные последствия.
Когда “10 минут превращаются в часы” — это не преувеличение
Истории про деградацию процессов разработки выглядят пугающе правдоподобно. Не потому что они драматичны, а потому что слишком узнаваемы.
- операции синхронизации, которые зависают на случайных этапах
- падение скорости загрузки зависимостей
- обрывы SSH-сессий
- ошибки при работе с облачными сервисами
В нормальной среде всё это уже давно автоматизировано. Разработчик даже не думает о том, как именно происходит деплой или сборка.
А теперь внезапно думает. Потому что пайплайн “встал”.
И это, пожалуй, самая неприятная часть всей истории:
ломается не просто доступ к чему-то — ломается предсказуемость.
Open source как слабое место
Отдельная ирония ситуации — в том, что сильнее всего страдают проекты, максимально завязанные на open source.
Молодые компании, особенно те, что попали в реестр отечественного ПО, часто строят продукты почти полностью на открытых компонентах. Иногда до 80–90%.
Это нормально. Так работает весь мир.
Но у этого есть побочный эффект:
зависимости разбросаны по глобальной инфраструктуре.
- GitHub
- npm
- PyPI
- Docker Hub
- десятки CDN
И если доступ к этим узлам становится нестабильным, продукт начинает “сыпаться” не изнутри, а снаружи.
Никто не ломал ваш код. Просто вы больше не можете его собрать.
“Мы дадим доступ по заявке” — звучит лучше, чем работает
Официальная позиция регулятора, если упростить:
компании могут получать доступ к нужным ресурсам через технические заявки.
На бумаге это выглядит разумно. Даже логично.
На практике — возникает несколько проблем.
Во-первых, инфраструктура современного проекта — это не фиксированный список IP-адресов. Это постоянно меняющаяся экосистема.
Во-вторых, зависимостей слишком много. Их невозможно заранее перечислить все.
В-третьих, сама идея “разрешений по списку” плохо сочетается с динамикой разработки.
Один DevOps-инженер сформулировал это довольно жёстко:
«Мы не можем каждый npm-пакет согласовывать с государством».
И, честно говоря, в этом трудно найти изъян логики.
Системная проблема, которая выглядит как “мелкие баги”
Самое коварное здесь — отсутствие одного большого сбоя.
Нет дня, когда всё выключилось.
Есть:
- задержки
- нестабильность
- редкие, но регулярные ошибки
- падение скорости процессов
Именно поэтому проблему легко недооценить.
Она не кричит. Она раздражает.
Но в IT накопительный эффект — штука опасная.
Если каждая операция становится на 10–20% медленнее, это не просто “чуть хуже”. Это срыв сроков, выгорание команд, рост затрат.
И да, это уже экономика.
Что меня здесь больше всего цепляет
Не сами блокировки. Они ожидаемы.
Меня цепляет другое: попытка применить грубый инструмент к очень тонкой системе.
Интернет-инфраструктура разработки — это не телевизор, который можно включить или выключить. Это живая сеть зависимостей, где любое вмешательство даёт побочные эффекты.
Иногда не сразу. Но почти всегда.
И вот сейчас мы наблюдаем именно такой эффект.
Не катастрофу. Пока нет.
Но устойчивое “проседание” среды, в которой создаётся софт.
Это уже влияет на будущее, а не только на настоящее
Самый недооценённый аспект всей истории — долгосрочный.
Когда разработчику становится сложнее работать:
- он ищет обходные пути
- он оптимизирует процессы
- он… уходит туда, где этого нет
Последний пункт редко проговаривают вслух, но он висит в воздухе.
IT — мобильная отрасль. И если среда становится токсичной для разработки (в техническом смысле, не в эмоциональном), это рано или поздно начинает влиять на распределение талантов.
Не мгновенно. Но стабильно.
И всё-таки: это уже кризис или ещё нет?
Честный ответ — где-то посередине.
Это не выглядит как обрушение отрасли. Пока.
Но это точно не локальная проблема “у пары компаний”. Слишком много совпадающих сигналов, слишком похожие жалобы, слишком понятная техническая природа происходящего.
Скорее, это начало фазы, которую сложно зафиксировать в цифрах, но легко почувствовать внутри процессов.
Та самая стадия, когда система ещё работает…
но уже не так, как должна.
И, возможно, именно это самое тревожное.