Привет, %username%! 2026-03-19 в 17:43 UTC в репозитории Trivy появился тег v0.69.4. Релизный пайплайн отработал штатно, бинарники разъехались по GitHub Releases, Docker Hub, GHCR, ECR и deb/rpm-репозиториям. В тот же день почти все теги aquasecurity/trivy-action переехали на чужие коммиты. Сканер уязвимостей, который ставят в пайплайн ради безопасности, начал читать память раннера, собирать SSH-ключи, облачные учётки и токены Kubernetes и отправлять их на scan.aquasecurtiy[.]org. Перечитай имя домена: в нём переставлены две буквы.

Через пять дней в PyPI вышли заражённые релизы LiteLLM. Ломать саму библиотеку не пришлось: её CI ставил Trivy из apt-репозитория без фиксации версии — свежий сканер приехал сам и, по версии самой LiteLLM, унёс токен публикации.

Вход атакующим дала история трёхнедельной давности: в конце февраля через ошибку в GitHub Actions того же репозитория украли токен сервисного аккаунта. Секреты после этого перевыпустили, но не одномоментно, и доступ у атакующих сохранился.

В контурах, с которыми я работал в разных компаниях, провайдеры Terraform приезжали тремя способами: напрямую из публичного реестра, через чужое зеркало и через своё. Про образы приложений такой разнобой уже трудно представить: registry со сканером давно стал нормой. А здесь он никого не смущал. Меня тоже.

Тезис статьи: инструмент, которым ты строишь и проверяешь инфраструктуру, входит в твою цепочку поставки. Прав у него больше, чем у любого сервиса в проде, а проверок по дороге меньше, чем у npm-пакета во фронтенде. За последние пять лет по этому месту били больше десяти раз. Ниже — хроника этих ударов, разбор того, что каждый инструмент проверяет сам, и настройки, которые закрывают большую часть сценариев.

Что ты унесёшь из статьи

Статья длинная (~61 000 знаков). Сразу — что заберёт каждая роль:

• SRE, DevOps, платформенная команда. Таблицу «что инструмент проверяет сам, а что нет» для Terraform, Ansible, Puppet, Salt, Helm и CI. Плюс рабочие настройки зеркала, пина по хэшу и карантина для GitLab CI и GitHub Actions.
• Security и AppSec. Аргументы, почему инфраструктурный тулинг обязан попасть в scope, с датами и ссылками на первичные разборы инцидентов.
• Тимлид и руководитель. Семь шагов по возрастанию цены и план, где они разложены по срокам: что делается за час, за день, за неделю и за квартал. И раздел о том, где эти меры не помогают.

TL;DR (если читать дальше уже некогда)

• Провайдер Terraform, коллекция Ansible, модуль Puppet, экшен в CI и линтер в pre-commit исполняют чужой код с правами пайплайна или инженера. Это зависимости, причём самые привилегированные из всех.
• С 2021 по 2026 год их ломали через угнанные токены мейнтейнеров, перезаписанные теги, тайпсквоттинг и инфраструктуру реестров. В 2026-м атаки стали прицельными: Trivy, KICS, реестр Coder, поддельные провайдеры.
• Хэш зависимости между запусками из коробки запоминает только Terraform, и только для провайдеров. Модули, роли, экшены по тегу и хуки pre-commit не сверяются ни с чем.
• У российских команд есть вторая ветка той же проблемы: после блокировок 2022–2024 годов многие ходят за провайдерами и образами через чужие зеркала.
• Лечится это тем же, чем давно лечат зависимости приложений: своё зеркало, карантин новых версий, пин по хэшу, раздельные раннеры. Придумывать новое не нужно.

Привилегированный слепой угол

Что я называю инфраструктурным тулингом

Всё, что исполняется, пока ты строишь, меняешь или проверяешь инфраструктуру, и что написал не ты. Список длиннее, чем хотелось бы.

Последняя строка выглядит мелочью, пока не вспомнишь, что LiteLLM заразили именно через неё.

Чем это отличается от зависимости приложения

Зависимость приложения получает ровно те права, которые есть у сервиса: скомпрометированный пакет в сервисе корзины дотянется до базы корзины и её секретов. Неприятно, но у ущерба есть граница — и рисовал её ты сам.

У инфраструктурного инструмента такой границы нет и быть не может: он существует, чтобы менять всё — создавать сети, выдавать роли, раскатывать конфигурацию на весь парк. Отсюда и права:

• Провайдер Terraform — отдельный бинарник, который Terraform запускает дочерним процессом. Он наследует окружение, а в окружении лежат ключи облака.
• Плагины из коллекции Ansible исполняются на control node, а модули уезжают на хосты и работают там под become.
• Модуль Puppet приносит Ruby-код, который выполняется на сервере при компиляции каталога, и факты, которые исполняются от root на каждом агенте.
• Расширение Salt — pip-пакет, который ставится на master и миньоны. На миньоне он работает от root, на master — с правами процесса, который раздаёт команды всему парку.
• Экшен в CI исполняется в том же раннере, что и твои шаги, и может прочитать память процесса со всеми секретами джобы. Именно так работала нагрузка в атаках на tj-actions и Trivy.
• Хук pre-commit запускается на ноутбуке инженера, где лежат kubeconfig, SSH-ключи и живая сессия облачного CLI.

terraform plan не read-only

На одном заблуждении держится половина пайплайнов: plan безопасен, он же ничего не меняет, только показывает разницу. Поэтому plan запускают автоматически на любой merge request, а строгие проверки вешают на apply.

В ноябре 2024 года Эллиот Уорд из Snyk Labs проверил пять платформ автоматизации Terraform: Terraform Cloud, Atlantis, Digger, Env0 и Terrateam. Все пять в конфигурации по умолчанию позволяли исполнить произвольный код на этапе plan. Способов два. Первый — data-источник external, который по определению запускает локальную программу. Второй — собственный провайдер: Terraform скачает его на init и запустит на plan. В эксперименте с Terraform Cloud исследователь получил шелл в контейнере и увидел там AWS-ключи, которыми разворачивается настоящая инфраструктура.

Проверить первое можно за минуту на своём ноутбуке:

data "external" "innocent" {
  program = ["sh", "-c", "id > plan-was-here.txt; echo '{}'"]
}

terraform init && terraform plan
cat plan-was-here.txt

На Terraform 1.15 план отвечает No changes. Your infrastructure matches the configuration, а файл с выводом id уже лежит рядом. Вместо id там может стоять что угодно.

Блока такого вида в чужом merge request достаточно. Его же 2026-08-31 нашли в модулях, которые 14 часов отдавались с адреса реестра Coder: через доступ к Cloudflare атакующие добавили в пул свои серверы, и часть запросов уходила к ним.

Что обычно проверяют

Сначала точка отсчёта. В компании со средней зрелостью безопасность цепочки поставки, она же шестой столп Digital Immune System, означает примерно такой набор:

• Lock-файлы и SCA. Зависимости приложения зафиксированы, сканер сверяет их с базами уязвимостей на каждом merge request.
• SAST и DAST. Первый смотрит свой код, второй — собранное приложение.
• Зеркало пакетов. npm, PyPI, Maven и NuGet идут через Nexus или Artifactory, прямой выход в публичные реестры из CI закрыт.
• Карантин. Новая версия пакета становится доступна сборкам через несколько дней или недель, когда на неё уже наступил кто-то другой.
• Свой registry образов со сканером на входе.
• Подписи и SBOM. Cosign для образов, CycloneDX или SPDX для состава, admission-политика в кластере, которая не пускает неподписанное.

Набор рабочий, спорить с ним я не собираюсь. Но все шесть пунктов отвечают на вопрос «что мы выпускаем», а вопрос «чем мы это собираем, раскатываем и проверяем» в scope не входит вовсе. Граница проходит по коду приложения и его зависимостям — всё по другую сторону пайплайна считается средой.

Перевёрнутая пирамида

Наложи этот набор на права — и пирамида переворачивается: чем больше прав у артефакта, тем меньше из перечисленного до него доходит.

Security-команда смотрит на верх таблицы: там код, который пишет компания, и привычные сканеры. Низ таблицы числится «инструментами», а инструменту вопрос «откуда ты это взял» задают редко. Про популярный npm-пакет так перестали думать после event-stream и node-ipc. Про популярный провайдер думают до сих пор.

Хроника 2021–2026

В таблицу попало только то, что било по инструментам сборки, доставки и проверки инфраструктуры. Обычные заражённые пакеты из npm, PyPI и других реестров я не считал: по подсчёту Sonatype, с 2019 года по осень 2024-го их набралось больше 700 тысяч. Последняя колонка забегает вперёд: в ней мера из практической части, которая закрыла бы сценарий на твоей стороне.

Теперь по периодам, с деталями, которые в таблицу не влезли.

2021: скрипт из интернета и сервер управления

С 2021-01-31 по 2021-04-01 Bash Uploader, который Codecov предлагал запускать в CI одной строкой, периодически подменяли: изменённая версия отправляла на сторонний сервер переменные окружения сборки. Заметили подмену не сканеры: клиент сверил контрольную сумму скачанного скрипта с опубликованной, и они не сошлись. До этого два месяца о расхождении никто не сообщал.

Среди пострадавших — HashiCorp. В её CI лежал приватный GPG-ключ, которым подписаны файлы SHA256SUMS всех релизов, и по нему же terraform init проверяет официальные провайдеры HashiCorp. Ключ отозвали, следов злоупотребления не нашли, но Terraform пришлось обновлять: в старые версии зашит прежний ключ, и релизы провайдеров, подписанные новым, они проверить не могут. Это первый случай в хронике, когда удар по вспомогательному инструменту CI дотянулся до корня доверия всей IaC-экосистемы.

Вторая история того же года формально про другое. 2021-07-02 группа REvil воспользовалась уязвимостью в серверах Kaseya VSA. VSA — система удалённого управления: агент стоит на каждой машине, сервер умеет исполнить на них что угодно. По оценке самой Kaseya, напрямую пострадали около 50 клиентов. Многие клиенты Kaseya — MSP, то есть подрядчики, которые администрируют чужую инфраструктуру, и через них пострадали ещё от 800 до 1 500 компаний. Шведская сеть Coop в первый же день закрыла больше половины из своих 800 магазинов. Подрядчик в роли входной двери — сюжет знакомый: через него же зашли в «Аэрофлот».

VSA — не Ansible и не Salt, но архитектура та же: центральный узел, которому root на всём парке положен по должности. С Salt ровно это случилось годом раньше: через CVE-2020-11651 в открытые в интернет мастера заходили без аутентификации и раскатывали майнеры по всем миньонам.

2023–2024: CI оказался сейфом, а к реестрам появились вопросы

2023-01-04 CircleCI попросила всех клиентов немедленно сменить все секреты, которые хранились в платформе. Из отчёта: 2022-12-16 малварь на ноутбуке инженера украла сессию с уже пройденной двухфакторной аутентификацией, 2022-12-22 через неё вынесли переменные окружения, токены и ключи клиентов. Данные были зашифрованы, но ключи шифрования атакующий достал из работающего процесса.

Вывод неприятный. CI хранит ключи от всего, что умеет твоя автоматизация, а значит, статический ключ облака в переменной CI рано или поздно утечёт вместе с CI.

В июне 2023 года Франсуа Пру из BoostSecurity посмотрел на Terraform Registry глазами атакующего. Главное наблюдение: модули, в отличие от провайдеров, lock-файлом не покрыты. Версия модуля — это git-тег, а тег можно передвинуть, поэтому план, который ты ревьюил в merge request, и план, который применится через час, могут не совпасть. Из 13 с лишним тысяч модулей реестра несколько сотен оказались уязвимы, и во многих случаях это позволяло перехватить уже опубликованные версии. В январе 2024 года HashiCorp закрыла в публичном реестре две дыры: подвижные теги и перехват переименованного репозитория. Версия модуля теперь привязана к SHA коммита, сохранённому при публикации, а сама публикация — к неизменяемому ID репозитория. Уязвимые workflow в репозиториях модулей остались заботой их авторов, и модуль, подключённый напрямую из git по тегу, эта защита тоже не покрывает.

2024-03-29 Андрес Фройнд публично рассказал о бэкдоре в xz-utils 5.6.0 и 5.6.1. В таблице его нет, потому что xz не инструмент инфраструктуры, но эта история изменила сам разговор. Человек под именем Jia Tan почти полтора года присылал нормальные патчи, прежде чем выпустил свой первый релиз, и ещё почти год вёл проект до бэкдора. После xz довод «этим пользуются все» перестал работать как доказательство безопасности.

2025: теги оказались переменными

2025-03-11 между 18:42 и 20:31 UTC тег v1 экшена reviewdog/action-setup указывал на коммит, который выгружал секреты раннера в лог сборки. Этим экшеном пользовался CI проекта tj-actions, и через него, скорее всего, утёк токен бота с правом записи. 2025-03-14 атакующий передвинул все теги tj-actions/changed-files на свой коммит. CISA просит проверить все проекты, где экшен запускался с 2025-03-12 по 2025-03-15, а найденные в логах секреты считать скомпрометированными.

Экшен стоял в 23 000 репозиториев. Endor Labs нашла 5 416 репозиториев со ссылкой на него: за сутки атаки workflow запускался в 614, а секреты попали в лог в 218, и в основном это короткоживущие GITHUB_TOKEN. По данным Unit 42, изначально целились в проект coinbase/agentkit, а все теги атакующий перезаписал через двадцать минут после того, как там убрали уязвимый workflow. Почему он пошёл на шумную массовую атаку, в Unit 42 не знают.

Одну деталь этой истории запомни, она вернётся в разделе про ограничения. Кто закрепил tj-actions/changed-files по SHA коммита, не пострадал — если только в эти дни не передвинул пин на заражённый коммит. С экшенами reviewdog пин спасал не всегда: составные экшены внутри себя ссылались на reviewdog/action-setup@v1 по тегу.

2025-08-26 в npm вышли заражённые версии Nx, системы сборки монорепозиториев. Токен публикации, по advisory проекта, украли через workflow на pull_request_target, который подставлял заголовок pull request в шелл-скрипт. По разбору Wiz, postinstall-скрипт искал на машине ключи и токены, а для разведки вызывал установленные AI-ассистенты: Claude Code, Gemini CLI и Amazon Q с флагами, отключающими подтверждения. Найденное складывалось в публичный репозиторий s1ngularity-repository в аккаунте самой жертвы. Утёкших секретов в Wiz насчитали больше двух тысяч. Для сверки по номерам: инциденту присвоена CVE-2025-10894, и она опубликована. Запись GHSA-cxm3-wv7p-598c в общей базе GitHub с 2026-07-28 помечена отозванной, причина не названа. Advisory в репозитории проекта при этом на месте.

2026: по инструментам бьют прицельно

С 2026-02-21 по 2026-03-02 аккаунт hackerbot-claw, который представлялся «автономным агентом для исследований безопасности», атаковал как минимум семь репозиториев через ошибки в GitHub Actions. В списке два инструмента проверки инфраструктуры: Trivy и DataDog/datadog-iac-scanner. Токен у Trivy украли 2026-02-27 через workflow на pull_request_target. Тот pull request, по разбору BoostSecurity, открыл другой аккаунт, которого на GitHub уже нет, а hackerbot-claw пришёл в тот же workflow сутки спустя. Мейнтейнеры Trivy считают, что за обоими стоит один атакующий. Дальше с этим токеном репозиторий переименовали и закрыли, релизы с 0.27.0 по 0.69.1 удалили, а в расширение для VS Code на Open VSX залили подозрительный артефакт. Для потребителей первый удар выглядел как отказ: пайплайны, которые скачивали бинарник Trivy с GitHub Releases, перестали его находить.

Aqua сменила учётные данные, но не разом: по её же advisory, ротация была не одномоментной, и атакующий мог успеть подсмотреть уже новые секреты. 2026-03-19 этим воспользовалась группа, которая называет себя TeamPCP. По данным Wiz, перезаписаны 75 из 76 тегов trivy-action (в advisory Aqua — 76 из 77) и семь тегов setup-trivy. В 17:43 UTC атакующий запушил тег v0.69.4, и к 18:22 автоматика выложила релиз с тем же стилером. 2026-03-20 по npm пошёл самораспространяющийся червь CanisterWorm: в Aikido считают его прямым продолжением атаки на Trivy и работой той же группы. 2026-03-22 на Docker Hub появились ещё два заражённых образа, 0.69.5 и 0.69.6.

2026-03-23 с 12:58 до 16:50 UTC то же произошло с kics-github-action: 35 тегов указывали на стилер. KICS — сканер IaC от Checkmarx. На следующий день в PyPI вышли LiteLLM 1.82.7 и 1.82.8. В 1.82.8 лежал .pth-файл, который запускал сбор учётных данных при каждом старте интерпретатора Python. По версии самой LiteLLM, токен публикации утёк через Trivy в её CI. JFrog в том же разборе показывает как: скрипт проверок ставил сканер из apt-репозитория, всегда последнюю версию.

2026-06-05 раскрыта CVE-2026-11332. Команда ansible-galaxy role install передавала поля src и name из meta/requirements.yml роли в git clone без разделителя --. Автор вредоносной роли мог так составить запись о зависимости, чтобы подставить опции git и выполнить команду на машине того, кто роль ставит. Для ролей это исправили в ansible-core 2.21.1 и бэкпортировали в 2.20.7, 2.19.11, 2.18.18 и 2.16.19. Исправление оказалось неполным: CVE-2026-16493 от 2026-07-21 описывает ту же ошибку в ansible-galaxy collection install. В upstream на 2026-10-12 она не закрыта: патч висит с конца июня, мейнтейнеры считают его перестраховкой и сомневаются, что через коллекции до уязвимого вызова можно добраться. Red Hat при этом оценила уязвимость как Important и числит её исправленной только в Satellite. Сведений об эксплуатации я не нашёл. Важен сам класс: код исполняется на этапе установки, до первого запуска плейбука.

Летом и осенью дошла очередь до Terraform, причём тремя разными способами.

В июле Zscaler нашла terraform-provider-awsbeta. Провайдер ведёт себя как настоящий: внутри рабочий каркас с примерами ресурса и data-источника, Terraform получает от него штатные ответы. При запуске он заодно скачивает загрузчик с hashicorp-terraform[.]io и ставит бэкдор FLATROOF. Исследователи осторожно связывают кампанию с группой TraderTraitor и не скрывают, что не знают, как именно этот провайдер попал к жертве. Вероятный путь описан в смежном разборе SentinelLabs: фальшивое собеседование и тестовое задание, в репозитории которого лежит Terraform-проект с подложенным .terraform.lock.hcl и провайдером из реестра на домене-двойнике.

2026-08-31 с 07:35 до 21:45 UTC часть запросов к registry.coder.com уходила на серверы атакующего. Сам реестр не взламывали: украли Cloudflare API-ключ и добавили свои адреса в пул, который отвечает за домен. Модули приезжали настоящие, но с лишним блоком data "external". Он отправлял на coder-infra[.]com переменные окружения и секреты провижинера, а при сборке workspace ещё и OIDC-токен пользователя, его SSH-ключ и токены внешней аутентификации. В разборе CSA есть фраза, которую стоит запомнить: одной фиксации версии модуля мало, чтобы такую подмену обнаружить.

В начале сентября были опубликованы провайдеры gocommunity-io/dockerd и kreuzwenker/docker. Второй отличается от популярного kreuzwerker/docker одной буквой. Вредоносный код просыпался, только если SHA-256 от двух переменных конфигурации совпадал с зашитым значением, то есть ждал конкретную жертву. Aikido описала находку 2026-09-22.

Что видно из хроники

Вспомогательный инструмент перестал быть побочной жертвой. В 2021-м Codecov ломали ради секретов его клиентов. В 2026-м ломают сам сканер, потому что он стоит в тысячах пайплайнов и ему разрешено читать всё.

Сканеры и линтеры стали самой выгодной целью. Codecov, reviewdog, Trivy, KICS, datadog-iac-scanner — пять инструментов проверки, по которым били за пять лет. Их ставят ради безопасности, им выдают доступ ко всему репозиторию и окружению, а сами они не проходят ни одной проверки.

Векторов всего четыре, и они повторяются:

• подвижная ссылка: тег, latest, скрипт по URL;
• CI самого инструмента, чаще всего pull_request_target;
• инфраструктура доставки: реестр, DNS, бакет;
• имя, похожее на настоящее.

Окно обнаружения сжалось. Codecov жил с подменой два месяца, tj-actions — меньше суток, Coder — 14 часов, KICS — четыре часа. Для карантина новых версий это хорошая новость: теперь хватает дней, а не месяцев. Но треть строк в таблице описывает подмену уже существующей версии, а против неё выдержка бессильна — помогает только хэш.

В четырёх историях 2026 года есть домен-двойник. У Trivy украденное уходило на aquasecurtiy, у Coder — на coder-infra, у KICS — на домен, похожий на Checkmarx, а у поддельного провайдера двойник hashicorp-terraform[.]io раздавал загрузчик. Раннер, которому разрешено ходить только на известные адреса, поднял бы тревогу в первых трёх историях. Совсем закрыть утечку такой фильтр не обещает: у стилера Trivy был запасной канал через репозиторий в аккаунте самой жертвы.

Вторая ветка: тебя не взломали, тебе закрыли дверь

Цепочка поставки рвётся и без атакующего. За те же пять лет поставщики инфраструктурных инструментов несколько раз меняли правила, и каждый раз кто-то узнавал об этом по упавшему пайплайну.

Ни одна строка не про взлом, а последствия те же: в какой-то день твой пайплайн зависит от решения, которое принял не ты. Лекарство тоже совпадает: копия того, от чего ты зависишь, должна лежать у тебя.

По первой строке: отдельного анонса я не нашёл, но 2022-03-01 сотрудник HashiCorp подтвердил запрет в issue про releases.hashicorp.com. Про реестр то же самое как факт пишет документация Yandex Cloud, правда, без даты. Остальное подтверждается открытыми источниками: смена лицензии Terraform, блокировка Docker Hub, решение о блокировке и удаление провайдеров в OpenTofu, переезд репозиториев Salt, поломка bootstrap и release notes 3008, объявление Perforce и первый релиз OpenVox, объявление Bitnami.

Для российских команд у этой ветки есть продолжение, о котором редко говорят вслух. После марта 2022-го зеркало для провайдеров появилось почти у всех, кто работает из России. Только чаще всего чужое. Вот блок из документации Yandex Cloud, который с тех пор живёт в ~/.terraformrc у многих:

provider_installation {
  network_mirror {
    url     = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

К самому зеркалу у меня претензий нет, задачу доступности оно решает честно. Но с этого момента в цепочке поставки появилось новое звено, и доверие к нему нигде не записано. Кто его наполняет? Как быстро туда попадает отозванная версия? Что будет, если по этому адресу начнёт отвечать кто-то другой? История Coder показывает, что последний вопрос не теоретический.

С образами после 2024-05-30 вышло ещё проще. Списки «рабочих зеркал Docker Hub» разошлись по чатам за сутки — вперемешку зеркала крупных облаков и сервисы, поднятые неизвестно кем за вечер. Строка в registry-mirrors означает, что оператор зеркала может отдать тебе любой образ под любым тегом.

Обе ветки сходятся в одной точке: и от атаки на поставщика, и от его решения спасает одно и то же — своя копия и доверие, привязанное к содержимому, а не к имени и адресу. Прежде чем строить это у себя, полезно понять, что каждый инструмент проверяет сам.

Анатомия доверия: что инструмент проверяет сам

У менеджера зависимостей есть три уровня проверки: целостность доставки (приехало то, что отдал сервер), неизменность (сегодня приехало то же, что вчера) и происхождение (это выпустил тот, за кого оно себя выдаёт). Ниже — разбор по инструментам: какой уровень работает из коробки, какой включается руками, а какого нет вовсе. Вывод команд я снимал на Terraform 1.15, ansible-core 2.21, Helm 4.3 и pre-commit 4.6.

Провайдеры Terraform и OpenTofu

Лучший случай во всём разделе, и у него всё равно три оговорки.

При установке из исходного реестра Terraform сверяет пакет с файлом SHA256SUMS и проверяет подпись этого файла GPG-ключом издателя. В выводе terraform init это одна строка:

- Installed hashicorp/external v2.4.2 (signed by HashiCorp)

После этого в .terraform.lock.hcl ложатся хэши пакета: один h1: по содержимому и по одному zh: на zip каждой платформы (у меня получилось тринадцать). При следующем init несовпадение даёт ошибку doesn't match any of the checksums previously recorded in the dependency lock file. Документация честно называет эту модель trust on first use.

OpenTofu здесь слабее. Вывод tofu я не снимал, но в документации сказано прямо: из своего основного реестра он по умолчанию ставит и провайдеры без GPG-ключа, пропуская проверку подписи. Строгий режим включается переменной OPENTOFU_ENFORCE_GPG_VALIDATION=true.

Оговорка первая: подпись говорит только, что пакет выпустил владелец пространства имён. Вот настоящий, не поддельный провайдер Docker:

- Installed kreuzwerker/docker v4.6.0 (self-signed, key ID 0DCE698927DAF8EC)

У тайпсквота kreuzwenker/docker строка была бы такой же, с другим ID ключа. Наизусть этот ID не помнит никто.

Оговорка вторая: через зеркало подпись не проверяется совсем. Тот же hashicorp/external из локального зеркала:

- Installed hashicorp/external v2.4.2 (unauthenticated)
...
Warning: Incomplete lock file information for providers

В lock-файл при этом попадает один хэш вместо четырнадцати, и это хэш того, что отдало зеркало. Собрал lock-файл через зеркало — поверил зеркалу на слово. При настроенном зеркале подписанные суммы издателя приносит только terraform providers lock: он игнорирует provider_installation и идёт в исходный реестр. По документации, официальные контрольные суммы под подписью разработчика отдаёт только исходный реестр.

Оговорка третья: вся конструкция работает, пока lock-файл лежит в git. Проверь .gitignore в инфраструктурных репозиториях: .terraform.lock.hcl иногда попадает туда по ошибке вместе с каталогом .terraform.

Модули Terraform

Здесь проверять нечего, и в документации это написано прямо: lock-файл отслеживает только провайдеры, выбор версий удалённых модулей Terraform не запоминает.

Модуль из реестра приезжает по версии, модуль из git — по ref. Если ref указывает на тег или ветку, содержимое может измениться между двумя terraform init (например, между джобами plan и apply с чистым каталогом). Встроенная защита одна: ref в виде SHA коммита для git-источников. У модулей из реестра нет и её. Остаётся верить реестру, а цену этой веры показала история Coder.

Ansible: роли и коллекции

Роли и коллекции устроены по-разному, и путать их опасно.

Роль — это git-репозиторий или tarball с GitHub. Контрольных сумм и подписей нет. Версия в requirements.yml задаётся тегом, веткой или коммитом, и неизменяем из них только коммит.

Коллекция — tarball с Galaxy-сервера. Сервер отдаёт SHA-256 артефакта, клиент сверяет скачанное. Внутри лежат MANIFEST.json и FILES.json с суммами каждого файла, поэтому ansible-galaxy collection verify умеет сравнить установленное с тем, что лежит на сервере. Это целостность доставки. А вот неизменности нет: lock-файла у Ansible не существует, и транзитивные зависимости коллекции разрешаются заново при каждой установке.

Происхождение закрывают GPG-подписи MANIFEST.json. Клиент их поддерживает, для этого есть ключи --keyring и --required-valid-signature-count. Только подписи должен отдать сервер. Я спросил публичный Galaxy про community.general 13.5.0, одну из самых популярных коллекций:

curl -s "https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/index/community/general/versions/13.5.0/" | jq .signatures
# []

Подписей нет. Работают они там, где сервер сам подписывает содержимое: в Automation Hub или в собственном Galaxy NG. То есть как раз в своём зеркале.

Остаётся сама установка. В 2026 году в ansible-galaxy install закрыли подстановку аргументов git через зависимости роли: это CVE-2026-11332, закрытая в ansible-core 2.21.1 и в бэкпортах для старых веток. Для установки коллекции из git заведена парная CVE-2026-16493, и в upstream на 2026-10-12 она не исправлена: в ansible-core 2.21.5 разделителя -- перед адресом по-прежнему нет. Мейнтейнеры, правда, сомневаются, что до этого вызова можно добраться с вредоносным адресом. Плагины коллекции в любом случае исполняются на control node при первом же запуске плейбука.

Puppet и Salt

У Puppet модули приезжают с Forge или из git. Подписей нет. В 2021 году Puppet объявил сканирование релизов на малварь, начав с Supported-модулей. По API Forge результата скана сегодня нет ни у community-модулей, ни у релизов 2026 года, так что рассчитывать на него не стоит. В Puppetfile версия модуля с Forge фиксируется точно, git-модуль закрепляется через :commit. У r10k есть полезное побочное свойство: он не разрешает зависимости сам, каждый модуль приходится прописать явно — и неожиданных транзитивных гостей не бывает.

У Salt источников три, и модель доверия у каждого своя.

Формулы — git-репозитории, которые подключают через gitfs_remotes. Мастер сам ходит в репозиторий по расписанию (по умолчанию раз в минуту) и раздаёт миньонам то, что там сейчас лежит. Это подвижная ссылка в чистом виде, и документация Salt прямо просит так не делать: настоятельно рекомендует форкнуть репозиторий формулы к себе, чтобы избежать неожиданных изменений в инфраструктуре.

Расширения — pip-пакеты saltext.* со всеми свойствами pip-пакетов. В Salt 3008, который вышел в мае 2026 года, из поставки убрали сотни модулей, и часть из них теперь ставится расширениями.

Bootstrap-скрипт теперь скачивается с GitHub Releases. Рядом лежит файл с SHA-256, и сверять его нужно руками.

Helm: чарты и плагины

Чарт можно подписать: рядом с пакетом кладётся файл .prov, и helm install --verify откажется ставить чарт без него — но по умолчанию флаг выключен, и чарт без подписи ставится молча. У классических HTTP-репозиториев клиент не сверяет скачанный архив даже с digest из index.yaml: на Helm 4.3 helm pull проходит и с подменённым tgz.

У OCI-реестров есть вариант надёжнее: ссылка на чарт по digest вместо тега. Digest неизменяем по построению.

Отдельная ловушка — Chart.lock. Поле digest в нём выглядит как контрольная сумма зависимостей, но это хэш их списка: он отвечает на вопрос «актуален ли lock», а не «то ли содержимое приехало».

Плагины Helm — исполняемый код с хуками установки. В Helm 4 подпись плагина проверяется по умолчанию, но, судя по справке helm plugin install, только при установке из tarball. Плагины kubectl из krew выглядят лучше: манифест в индексе содержит SHA-256 каждого архива, и клиент его сверяет.

Кирпичи CI

GitHub Actions. uses: org/action@v4 ссылается на тег, а тег подвижен. uses: org/action@ с сорока символами SHA ссылается на коммит, и неизменяема только такая ссылка. С августа 2025 года политика организации умеет требовать полный SHA и запрещать конкретные экшены. Ограничение то же, что в истории с reviewdog: закреплённый экшен может внутри ссылаться на другой по тегу, а reusable workflows политика тоже не покрывает — их по-прежнему можно подключать по тегу.

GitLab CI. include: project принимает ref, и туда можно поставить SHA коммита. Компонент из каталога подключается как gitlab.example.internal/group/project/component@версия, вместо версии тоже годится SHA. Для include: remote с GitLab 17.9 есть ключ integrity с SHA-256 включаемого файла: не совпало, и пайплайн падает. Образ в image: по тегу подвижен так же, как тег экшена. Неизменяема только форма image: name@sha256:....

Сканеры, линтеры и pre-commit

Самая слабая зона. Инструмент попадает в пайплайн одним из четырёх способов: скрипт установки по URL, бинарник с GitHub Releases, пакет из apt-репозитория вендора или готовый образ. У большинства рядом лежат контрольные суммы, у многих есть подписи cosign, но сверка во всех четырёх случаях ручная: пока ты сам не написал эту строку в пайплайне, её нет.

Подписанный apt-репозиторий здесь не спасает. Подпись репозитория защищает от подмены по дороге, а заражённый Trivy v0.69.4 собрал и выпустил штатный релизный пайплайн.

В pre-commit поле rev принимает тег, и обычно там тег и стоит. Команда pre-commit autoupdate --freeze пишет вместо тега SHA коммита и оставляет версию в комментарии. Заодно она обновляет каждый хук до последнего тега, об этом ниже.

Сводная таблица

Средняя колонка объясняет, почему хроника выглядит именно так. Почти в каждой её ячейке стоит «если», «только» или «руками».

Свой контур: где я сам стоял в этой таблице

Теперь про себя. В контурах, с которыми я работал в разных компаниях, картина повторялась с небольшими вариациями, поэтому опишу её собирательно.

Лучше всего было с чартами и образами. В одном из контуров внешний Helm-чарт проходил конвейер из шести шагов:

Правило у конвейера одно: прод ничего не тянет из публичного интернета напрямую. Каждый внешний артефакт проходит через одну точку, и эта точка даёт сразу контроль, кэш и след для аудита.

Второе, что работало, — правило previous minor из регламента по инфраструктурному коду. Берём не последнюю вышедшую minor-версию, а предыдущую: свежая успевает отлежаться, а регрессии и сюрпризы ловит кто-то другой. Карантин на голой дисциплине, без единого инструмента. В том же регламенте были CODEOWNERS, защищённые ветки и закоммиченный lock-файл.

А вот про источник провайдеров и модулей там не было ни слова. Провайдеры Terraform, повторюсь, приезжали тремя способами: напрямую из реестра, через чужое зеркало и через своё. Про коллекции Ansible, модули Puppet и формулы Salt вопрос «откуда» звучал ещё реже.

Разложи это по сводной таблице из прошлого раздела, и вылезет перекос: для Helm-чарта построен конвейер из шести шагов, а для провайдера Terraform, у которого в руках облачный аккаунт, не было даже единого источника.

Убирается этот перекос тем же принципом, что у конвейера чартов, только применённым ко всем остальным классам: объявить, закрепить, зеркалировать, выдержать, сверить.

Практика: тот же конвейер для всего остального

Шагов семь, с нулевого по шестой, и идут они по возрастанию цены. Первые два не требуют ни нового железа, ни согласований. Как всё раскладывается по срокам, от часа до квартала, собрано в конце, в разделе «Что сделать в понедельник». Команды для Terraform и Ansible я прогнал на тех же версиях, что и в прошлом разделе.

Шаг 0. Инвентаризация: что у тебя ходит наружу

# Terraform: провайдеры и источники модулей
terraform get   # без установленных модулей terraform providers падает
terraform providers
grep -rhoE 'source[[:space:]]*=[[:space:]]*"[^"]+"' --include='*.tf' --exclude-dir=.terraform . | sort | uniq -c | sort -rn

# GitHub Actions: всё, что не закреплено по SHA
grep -rhoE 'uses:[[:space:]]*[^[:space:]]+' .github/workflows | grep -vE '@[0-9a-f]{40}' | sort | uniq -c

# GitLab CI: внешние include и образы
grep -nE '^[[:space:]]*-?[[:space:]]*(remote|component|project|image):' .gitlab-ci.yml

# Ansible, Puppet, Salt
ansible-galaxy collection list
ansible-galaxy role list
puppet module list --tree
salt-pip list | grep -i saltext
grep -A10 '^gitfs_remotes' /etc/salt/master

# pre-commit и плагины
grep -nE '^[[:space:]]*(- repo|rev):' .pre-commit-config.yaml
helm plugin list
kubectl krew list

Самый полезный источник при этом лежит не в репозитории. Возьми лог исходящих соединений раннера за неделю и посмотри, на какие домены он ходит на самом деле. Список всегда длиннее, чем следует из кода.

Шаг 1. Закрепи то, что уже есть

Строить ничего не нужно — только заменить подвижные ссылки неизменяемыми.

Terraform. Lock-файл собирается из исходного реестра, с подписями издателя, сразу под все платформы команды и CI:

terraform providers lock -platform=linux_amd64 -platform=darwin_arm64
git add .terraform.lock.hcl

В CI init запускается так, чтобы lock-файл нельзя было тихо изменить:

terraform init -input=false -lockfile=readonly

Модули из git закрепляются по коммиту:

module "vpc" {
  source = "git::https://git.example.internal/infra/terraform-vpc.git?ref=4f2a9c1e8b7d6a5f4e3d2c1b0a9f8e7d6c5b4a39"
}

GitHub Actions. Тег остаётся в комментарии, чтобы человек понимал, что за версия:

steps:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

Руками это делать не нужно: пресет Renovate helpers:pinGitHubActionDigests расставит SHA и будет обновлять их вместе с комментарием. После этого включи в политике организации требование полного SHA, иначе через месяц кто-нибудь добавит новый экшен по тегу.

GitLab CI. То же самое для include и образов:

include:
  - project: platform/ci-templates
    ref: 9b1d4c7e2a6f8035c1e4d7a9b2f6c8e0d3a5b7c1
    file: /terraform/plan.yml
  - remote: https://templates.example.internal/lint.yml
    integrity: sha256-<base64>

default:
  image: registry.example.internal/tools/terraform@sha256:<digest>

Значение для integrity считается так:

openssl dgst -sha256 -binary lint.yml | openssl base64 -A

pre-commit. Есть команда, которая расставляет SHA сама:

pre-commit autoupdate --freeze

У неё есть подвох: она сначала обновляет каждый хук до последнего тега и только потом замораживает. Для шага «закрепи то, что есть» это обновление в обход карантина. Закрепить текущую версию без обновления можно руками: SHA тега показывает git ls-remote <repo> 'refs/tags/<тег>*', для аннотированного тега нужна строка с ^{}.

Ansible. Точные версии коллекций, роли из своего git по коммиту:

collections:
  - name: community.general
    version: 13.5.0

roles:
  - name: nginx
    src: https://git.example.internal/mirrors/ansible-role-nginx.git
    scm: git
    version: 7c3e1a9f5b2d8e4c6a0f1b3d5e7c9a2b4d6f8e01

Puppet. Точная версия для Forge, коммит для git:

mod 'puppetlabs-stdlib', '9.6.0'
mod 'nginx',
  git:    'https://git.example.internal/mirrors/puppet-nginx.git',
  commit: '1e5a9c3d7b2f6e0a4c8d1b5f9e3a7c2d6b0f4e8a'

Salt. Формулы форкаются в свой git, и ветка, на которую смотрит gitfs_remotes, обновляется только через merge request. Расширения ставятся по файлу с хэшами:

salt-pip install --require-hashes -r saltext-requirements.txt

Хэши понадобятся для всего дерева зависимостей, а не только для самих расширений.

Сканеры и прочие бинарники. Версия и контрольная сумма записаны в репозитории, сверка идёт до запуска:

curl -fsSLO "https://tools.example.internal/trivy/0.69.3/trivy_0.69.3_Linux-64bit.tar.gz"
echo "<sha256>  trivy_0.69.3_Linux-64bit.tar.gz" | sha256sum -c -

Строка apt-get install trivy без версии в CI — ровно то, через что, по разбору JFrog, утёк токен публикации LiteLLM.

Шаг 2. Своё зеркало, оно же allowlist

Terraform. Зеркало провайдеров — это каталог со статикой. Наполняется одной командой с машины, у которой есть доступ к исходному реестру:

terraform providers mirror -platform=linux_amd64 -platform=darwin_arm64 /srv/tf-mirror

Команда зеркалит провайдеры текущей конфигурации, поэтому запускают её в каталоге со сводным required_providers. Дальше каталог отдаёт любой веб-сервер по HTTPS, а в ~/.terraformrc раннеров и инженеров пишется:

provider_installation {
  network_mirror {
    url = "https://tf-mirror.example.internal/"
  }
}

Блока direct здесь нет, и это главное. Terraform перестаёт ходить в исходный реестр, а провайдер, которого нет в зеркале, просто не ставится:

Error: Failed to query available provider packages
Could not retrieve the list of available versions for provider
kreuzwerker/docker: provider registry.terraform.io/kreuzwerker/docker was not
found in any of the search locations

Зеркало без direct само работает как allowlist. Тайпсквот не установится: его туда никто не клал. Провайдер, собранный атакующим под merge request, тоже. А если в зеркале нет hashicorp/external, блок data "external" из чужого merge request упадёт ещё на init.

Подпись издателя при этом не теряется. Lock-файл из шага 1 собран из исходного реестра, и init -lockfile=readonly через зеркало пройдёт, только если пакет из зеркала совпал с подписанным хэшем. Зеркало отвечает за доступность и за список разрешённого, lock-файл — за содержимое.

Ansible. В ansible.cfg остаётся один сервер, свой, и включается обязательная подпись:

[galaxy]
server_list = internal
gpg_keyring = /etc/ansible/galaxy.kbx
required_valid_signature_count = +1

[galaxy_server.internal]
url = https://galaxy.example.internal/api/galaxy/

Точный путь в url зависит от сервера. Оба свойства я проверил. С одним сервером в server_list клиент не откатывается на публичный Galaxy: при недоступном внутреннем установка падает. А знак плюс в required_valid_signature_count превращает отсутствие подписей в ошибку Signature verification failed for 'community.general': no successful signatures. Без плюса неподписанная коллекция ставится молча.

Puppet. Адрес своего Forge задаётся в r10k.yaml:

forge:
  baseurl: 'https://forge.example.internal'

Salt. Форки формул уже лежат в своём git после шага 1. Для расширений добавляется свой индекс: salt-pip install --index-url https://pypi.example.internal/simple/ ....

CI. В GitHub политика разрешённых экшенов ограничивается своей организацией и явным списком, критичные экшены форкаются к себе. В GitLab шаблоны и компоненты живут в своей группе, а образы с Docker Hub идут через Dependency Proxy.

Остаётся вопрос, кто наполняет зеркала. Ответ тот же, что у конвейера чартов: декларативный список в репозитории и джоба по расписанию. Добавить провайдер, коллекцию или модуль — значит открыть merge request в этот список. Вот и точка ревью, которой раньше не было.

Шаг 3. Карантин

Правило previous minor хорошо работает как политика, но держать его на памяти людей не нужно. Renovate умеет ждать сам:

{
  "extends": ["config:recommended", "helpers:pinGitHubActionDigests"],
  "minimumReleaseAge": "14 days"
}

Без оговорок не обходится. Security-обновления Renovate выпускает в обход выдержки, а для всего остального срочного нужен записанный обходной путь. Начиная с Renovate 42 обновление без времени релиза проверку не проходит никогда, а у образов из своего registry этого времени нет — им нужен minimumReleaseAgeBehaviour: timestamp-optional. Главное же следует из хроники: выдержка защищает от заражённой новой версии и ничего не делает с подменой старой. От подмены защищает шаг 1.

Шаг 4. Plan на недоверенном коде

• Plan для merge request идёт на отдельном раннере с облачной ролью только на чтение. Apply запускается с защищённой ветки и с защищёнными переменными.
• Статических ключей облака в переменных CI нет. Джоба получает OIDC-токен и меняет его на короткоживущую роль: id_tokens в GitLab, id-token: write в GitHub.
• Зеркало без direct из шага 2 закрывает оба способа исполнить код на plan, пока в него не положили hashicorp/external. Если этот провайдер нужен команде, блоки data "external" придётся ловить на ревью.
• Изменения в required_providers, в source модулей и в конфигурации CI требуют апрува владельца через CODEOWNERS.

Шаг 5. Сеть раннера

Раннеру для работы нужны твой VCS, твоё зеркало и API облака. Всё остальное можно закрыть. Только не сразу: начни с режима аудита, неделю собирай список доменов и лишь потом блокируй. Для GitHub-hosted раннеров это умеет Harden-Runner с режимами audit и block (бесплатно он работает только на публичных репозиториях, а режим block есть только на Linux), а для своих раннеров в Kubernetes подойдут сетевые политики с правилами по FQDN.

Шаг 6. Инвентарь и учения

Образ CI, в который зашиты Terraform, Ansible и сканеры, заслуживает SBOM не меньше, чем образ сервиса. Когда выйдет следующая новость про заражённый инструмент, вопрос «а у нас он есть и какой версии» должен закрываться запросом, а не опросом в чате.

Раз в квартал полезно пройтись по декларативным спискам: что устарело, что сменило владельца, что лежит в зеркале и никем не используется.

И последнее, уже из практики инцидентов. Сценарий «скомпрометирован инструмент из пайплайна» стоит прогнать на game day заранее. Действий в нём немного: найти все запуски за окно компрометации, считать утёкшим всё, до чего дотягивался раннер, и сменить это всё. Смена в день настоящего инцидента занимает часы, если список известен, и недели, если его составляют на ходу.

Где это не работает

Раздел про меры был бы пропагандой без раздела про их границы.

Карантин проигрывает длинному окну обнаружения. Бэкдор в xz прожил в релизах пять недель, подмену у Codecov два месяца никто не замечал. Выдержка в 14 дней пропускает обе истории.

Пин замораживает и уязвимости. Закреплённая по SHA версия сама не обновится. Без Renovate или его аналога через год ты сидишь на идеально неизменяемом дырявом наборе.

Транзитивные ссылки остаются подвижными. Закреплённый экшен может вызывать другой по тегу, как было у reviewdog. Коллекция Ansible тянет зависимости по диапазону версий. Образ джобы, закреплённый по digest, мог быть собран из FROM ...:latest.

Зеркало не проверяет содержимое. Оно копирует то, что upstream отдавал в момент синхронизации, и если та попала в окно компрометации, у тебя лежит аккуратная копия малвари с правильным хэшем. Поэтому зеркало без карантина и без сверки с подписью издателя решает только задачу доступности.

Машины разработчиков остаются снаружи. Поддельный провайдер awsbeta, судя по набору краденого, целил в ноутбук разработчика, а не в CI. Раздельные раннеры и сетевые фильтры туда не дотягиваются. Помогают только ~/.terraformrc с зеркалом без direct на каждом ноутбуке и закреплённые хуки pre-commit.

Проверяющий инструмент сам остаётся зависимостью. Сканер, которым ты проверяешь зеркало, приехал откуда-то и с какими-то правами. Рекурсия не разрывается, её можно только сделать короче: закрепить сканер так же, как всё остальное, и не давать ему секретов сверх необходимого.

Цена. Команда из трёх человек не будет поддерживать Galaxy NG, зеркало Forge и собственный PyPI. Для неё реалистичный минимум такой: шаг 1 целиком, статическое зеркало провайдеров и форки формул, ролей и модулей в свой git. Это закрывает подмену существующих версий и тайпсквот, то есть большую часть таблицы из хроники.

Что сделать в понедельник

Те же семь шагов, только разложенные не по цене, а по срокам. В понедельник делается первое, остальное идёт в план.

• За час. Начало шага 1: terraform providers lock под все платформы, lock-файл в git, -lockfile=readonly в CI.
• За день. Дальше по шагу 1: закрепить по SHA экшены, include, образы джобов и хуки pre-commit, включить в политике организации требование SHA. И шаг 0: инвентаризация и лог исходящих соединений раннера за неделю.
• За неделю. Статическое зеркало провайдеров без direct из шага 2 и форки формул, ролей и модулей в свой git. Сюда же шаг 3: выдержка новых версий в Renovate.
• За квартал. Остальное: свой Galaxy с подписями из шага 2, раздельные раннеры для plan и apply и OIDC вместо статических ключей из шага 4, сетевой фильтр из шага 5, инвентарь и учения из шага 6.

Заключение

Конвейер из шести шагов для Helm-чарта и три случайных способа доставки для провайдера Terraform уживались в одном контуре годами. Чарт при этом управляет одним кластером, а провайдер держит ключи от облака.

Чтобы этот перекос исправить, ничего нового изобретать не нужно. Зеркало, карантин, пин по хэшу и раздельные права давно работают для зависимостей приложений. Осталось перестать называть Terraform, Ansible и сканеры «инструментами» и начать называть их зависимостями.

Что почитать

• GitFlops: The Dangers of Terraform Automation Platforms — почему plan исполняет код.
• Erosion of Trust: Unmasking Supply Chain Vulnerabilities in the Terraform Registry — модули и подвижные теги.
• Trivy Compromised: Everything You Need to Know — хронология и индикаторы.
• Coder Registry Compromise — подмена модулей через инфраструктуру доставки.
• hackerbot-claw — пять техник атаки на GitHub Actions в одном разборе.
• Dependency Lock File — что именно фиксирует Terraform и чего не фиксирует.
• SLSA — рамка, в которую всё это укладывается.

Привет, %username%! Слайды я собираю там же, где пишу посты и правлю конфиги: в редакторе, в Markdown и с git под боком. Мышкой блоки не двигаю, шрифты от слайда к слайду не выравниваю, а вместо «финал_v3_точно_финал.pptx» у меня git log.

Делается это на Slidev. Написать про него я собирался ещё в декабре 2023-го, а руки дошли только сейчас: к Стачке собрал на нём доклад про SRE MCP, и репозиторий получился таким, что его удобно разобрать по косточкам.

После этого поста у тебя будет своя презентация: по файлу на слайд, с заметками спикера рядом с текстом, с PDF одной командой и сайтом, который выкатывается на GitHub Pages по git push. Все примеры взяты из живого репозитория nastachku-2026, результат можно полистать в браузере.

Зачем слайдам git

Презентацию переписывают много раз. У моего доклада 46 коммитов за девять дней, и почти каждый из них — правка формулировки, перестановка слайдов или попытка влезть в слот. В pptx такая история выглядит как папка с копиями одного файла. Здесь это обычный git diff, по которому видно, что поменялось и зачем.

Оформление при этом живёт отдельно от содержания. Тема ставится зависимостью, и следующий доклад начинается со строчки theme: bear. Копировать прошлую презентацию и вычищать из неё чужие слайды больше не надо.

И из одних исходников получаются сразу сайт и PDF, оба в светлой и тёмной теме.

Плата за всё это — Node.js в зависимостях и вёрстка руками там, где не хватило готовой раскладки. Кому такой подход не подойдёт, скажу в конце.

Что понадобится

• Node.js 22.12 или новее: это требование @slidev/cli 53;
• npm, он приезжает вместе с Node.js;
• git и аккаунт на GitHub, если нужен деплой;
• make — по желанию, для обёрток;
• Markdown на уровне README. Vue знать не обязательно, пока хватает готовых компонентов.

Команды ниже проверены на Slidev 53.0.0 и Node.js 26.

Шаг 1. Заведи проект

npm init slidev@latest

Стартер спросит имя проекта и предложит сразу поставить зависимости и запустить dev-сервер. В созданной папке важны две вещи: slides.md с самими слайдами и package.json с тремя скриптами — dev, build и export. Каталоги components/, pages/ и snippets/ лежат там как примеры, их можно сносить.

Если от автозапуска отказался, подними сервер сам. Проект я назвал my-talk, у тебя будет то имя, которое ты ввёл стартеру:

cd my-talk
npm install
npm run dev

Проверка: браузер открыл http://localhost:3030 с титульным слайдом. Поправь заголовок в slides.md и сохрани файл — слайд обновится без перезагрузки страницы.

Что стоит запомнить сразу:

Шаг 2. Напиши слайд

Презентация в Slidev — это Markdown-файл, в котором слайды разделены строкой ---. У слайда три части: frontmatter с настройками, тело и заметки спикера в HTML-комментарии в самом конце.

---
layout: statement
---

# Дежурный не чинит.<br>Дежурный ищет.

Ночь, тикет, четырнадцать дашбордов.

<!--
Крючок, 40 секунд. Сцену знает каждый дежурный, из неё вырастает весь доклад.
-->

layout выбирает раскладку: statement ставит одну мысль по центру экрана, two-cols-header даёт заголовок и две колонки, section рисует разделитель блока. Без этого поля слайд получает раскладку default.

Самый первый frontmatter в файле работает за двоих. Он настраивает титульный слайд и заодно всю презентацию, поэтому называется headmatter:

---
theme: bear
layout: cover
title: 'SRE MCP'
author: Михаил Савин
transition: slide-left
drawings:
  persist: false
---

Теперь слайд посложнее, с графиком и врезкой:

<Kicker>01 · арифметика</Kicker>

# Куда уходит время инцидента

<div class="grid grid-cols-[1.6fr_1fr] gap-12 items-center mt-6">

<BarChart unit=" мин" :items="[{ label: 'Обнаружение', value: 923, highlight: true }, { label: 'Диагноз', value: 23 }, { label: 'Починка', value: 25 }]" />

<div>

<Callout type="important" title="Главный вывод">

Дольше всего отказ живёт до первого сигнала: в 28 случаях из 38 его первым замечает клиент. Диагноз и починка занимают минуты, и только диагноз можно отдать ИИ без права на запись.

</Callout>

> *Медианы по 48 нашим постмортемам, февраль–сентябрь 2026.*

</div>

</div>

В этом куске три вещи, на которых держится вся вёрстка в Slidev.

Теги с заглавной буквы — Vue-компоненты. Kicker, BarChart и Callout приехали из темы, импортировать их не надо. Данные для графика лежат прямо в слайде, и когда поменяется цифра, картинку перерисовывать не придётся.

Классы у <div> — утилиты UnoCSS, по синтаксису как в Tailwind. grid grid-cols-[1.6fr_1fr] gap-12 раскладывает слайд на две колонки без единой строчки CSS.

Пустые строки вокруг Markdown внутри HTML-тегов обязательны. Без них парсер примет содержимое за сырой HTML, и вместо жирного текста ты увидишь звёздочки.

Шаг 3. Разложи слайды по файлам

Стартер предлагает писать всё в один slides.md. На десяти слайдах это удобно. На сорока, да ещё с заметками спикера, у меня вышло бы больше полутора тысяч строк в одном файле, и любой diff превратился бы в кашу.

Slidev умеет подключать слайд из другого файла через src:. Тогда slides.md остаётся оглавлением:

---
# ── 01 · Арифметика MTTR ──
src: ./pages/01-mttr/00-section.md
---

---
src: ./pages/01-mttr/01-mttr.md
---

---
src: ./pages/01-mttr/02-thesis.md
---

А сами слайды лежат по одному в файле:

.
├── slides.md              # headmatter, титул и порядок слайдов
├── pages/
│   ├── 00-intro/
│   │   ├── 01-hook.md
│   │   └── 02-speaker.md
│   ├── 01-mttr/
│   │   ├── 00-section.md  # разделитель блока
│   │   ├── 01-mttr.md
│   │   └── 02-thesis.md
│   └── backup/            # бэкап-слайды «если спросят»
├── components/            # свои Vue-компоненты
├── public/                # картинки и QR-коды
├── setup/routes.ts        # правка маршрутов, см. шаг 4
└── style.css              # глобальные правки поверх темы

Правила, которые у меня прижились:

• папка — блок доклада, NN в её имени совпадает с номером блока на слайдах;
• файл называется MM-слаг.md, где MM — позиция слайда внутри блока. Вставил слайд в середину — перенумеруй соседей, иначе порядок файлов в папке разойдётся с порядком в презентации;
• frontmatter слайда живёт в файле страницы, в slides.md остаются только src: и hide:;
• YAML-комментарий над первым src: блока работает как заголовок раздела в оглавлении.

После этого slides.md на всю презентацию занимает 240 строк, переставить слайд — значит перенести три строки, а правка текста трогает ровно один файл.

Шаг 4. Дай слайдам имена

По умолчанию адрес слайда — его номер: /7, /21. Стоит вставить один слайд в начало, и все ссылки внутри презентации вместе с сохранёнными закладками начинают вести не туда.

Лечится это полем routeAlias во frontmatter слайда:

---
routeAlias: gates
---

Теперь слайд открывается по адресу /gates и останется там, куда бы ты его ни переставил. Алиас у меня совпадает со слагом файла без номера. К повторяющимся слагам добавляю префикс блока: mttr-section, permissions-thesis.

На алиасы опираются и переходы по клику. Итоговый слайд с карточками у меня работает как меню: на вопросах из зала по карточке можно прыгнуть к нужной теме.

<Card to="gate-1" kicker="gate 01" title="Read-only">Токен не может писать</Card>
<Card to="gate-4" kicker="gate 04" title="Аудит на сервере">Журнал пишет не агент</Card>

Card — компонент темы. Без неё то же самое делает встроенный <Link to="gates">текст ссылки</Link>.

Остаётся одна шероховатость: корень сайта и /presenter Slidev жёстко ведёт на /1. Чтобы номер не всплывал даже при первом открытии, маршруты можно поправить в setup/routes.ts:

import { defineRoutesSetup } from '@slidev/types'

export default defineRoutesSetup((routes) => {
  for (const route of routes) {
    if (route.path === '')
      route.redirect = { path: '/cover' }
    else if (route.path === '/presenter')
      route.redirect = { path: '/presenter/cover' }
  }
  return routes
})

Здесь cover — алиас титульного слайда. Он задаётся в headmatter той же строкой routeAlias: cover.

Проверка: открой http://localhost:3030/. В адресной строке должно оказаться /cover, а не /1.

Шаг 5. Заметки спикера и клики

Последний HTML-комментарий на слайде — заметка спикера. В зале её не видно, а в режиме докладчика она стоит рядом со слайдом.

Список, который должен появляться по пунктам, оборачивается в <v-clicks>. Маркер [click] в заметке привязывает абзац к клику, и в режиме докладчика подсвечивается та фраза, до которой ты дошёл:

<v-clicks>

1. Запустил WAFaaS и собрал команду SRE
2. Запустил SRE-комьюнити и подкаст про SRE

</v-clicks>

<!--
0:50–1:15 · 25 с. Без биографии: по фразе на клик.

[click] Запускал WAFaaS и собирал команду SRE.

[click] Запустил SRE-комьюнити и подкаст.

Переход: «Об этом и доклад».
-->

Заметку я пишу по одному шаблону. Первая строка — тайминг и главная мысль слайда. Дальше текст, который произношу. Потом переход к следующему слайду. В конце справка: цифры и детали, которые нужны на вопросах, но вслух не идут.

На /overview те же заметки лежат списком рядом с миниатюрами, а в углу стоит счётчик. У моего доклада там 37 слайдов, 67 кликов и 4 284 слова. По этим цифрам удобно прикидывать хронометраж ещё до первого прогона.

Шаг 6. Спрячь, а не удаляй

Первый план доклада был расписан на 25:25. На живых прогонах он занял 37 минут при слоте в 30 вместе с вопросами. Пришлось ужиматься до 18:20, и шесть слайдов из показа ушли.

Удалять я их не стал. В slides.md у каждого появилась одна строка:

---
src: ./pages/01-mttr/04-research.md
hide: true
---

Слайд остаётся на своём месте в оглавлении, со своим номером файла и заметкой. В заметке к каждому скрытому слайду у меня записано, что поправить на соседях, если его вернуть. Чтобы вернуть, достаточно убрать hide: true.

Шаг 7. Тема, компоненты и картинки

Стартер приезжает с темой seriph. Другую можно выбрать в галерее: пишешь её имя в theme:, и dev-сервер сам предложит поставить пакет.

Я пользуюсь своей, slidev-theme-bear. В npm её нет, она ставится прямо из GitHub:

npm i -D github:jtprogru/slidev-theme-bear

В ней семнадцать своих раскладок, компоненты для врезок, карточек, графиков и схем, шрифты с кириллицей в зависимостях и проверка контраста по WCAG AA. Код темы открыт для некоммерческого использования, а вот медведь мой: в форке бренд придётся заменить на свой.

Всё, чего нет в теме, лежит в самом проекте:

• components/ — свои Vue-компоненты, подключаются автоматически по имени файла. У меня их два: схема архитектуры и логотип конференции. В шаблоне организаторов логотип был только в PNG, поэтому он обведён в вектор и вставлен инлайном: так он перекрашивается вместе с темой и не ломается в PDF;
• public/ — статика. Файл public/avatar.jpg доступен на слайде как /avatar.jpg;
• style.css — глобальные правки поверх темы. У меня там одна CSS-переменная, которая делает маскота монохромным;
• <style> в конце файла слайда — стили только для него. Выручает на плотных слайдах: основной текст уменьшается, а заголовки остаются в размере темы и не прыгают от слайда к слайду;
• иконки — через Iconify. Ставишь набор командой npm i -D @iconify-json/simple-icons и пишешь <simple-icons-go />. Иконки наследуют цвет текста и перекрашиваются вместе с темой.

Шаг 8. Собери PDF

Экспорт идёт через headless-браузер, поэтому сначала нужен Playwright:

npm i -D playwright-chromium
npx slidev export

Проверка: рядом со slides.md появился slides-export.pdf, и страниц в нём столько же, сколько слайдов в презентации без скрытых.

Полезные флаги:

У --range и --with-clicks есть по сюрпризу, оба разобраны в тонких местах.

Добавь slides-export*.pdf в .gitignore: стартер создаёт его без этой строки.

Организаторы обычно просят файл, и PDF тут надёжнее всего. А pptx из Slidev годится разве что как запасной вариант: слайды в нём лежат картинками, текст не выделяется и не правится.

Шаг 9. Выложи слайды на GitHub Pages

slidev build собирает статический сайт в dist/. На GitHub Pages сайт живёт в подкаталоге с именем репозитория, и об этом ему надо сказать флагом --base:

npx slidev build --base /nastachku-2026/

Дальше workflow .github/workflows/build.yaml, который делает то же самое на каждый push в main:

---
name: GitHub Pages

'on':
  workflow_dispatch: {}
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    permissions:
      contents: read
      pages: write
      id-token: write

    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v7
        with:
          node-version: 'lts/*'

      - name: Install dependencies
        run: npm install

      - name: Build
        run: npm run build -- --base /nastachku-2026/

      - uses: actions/configure-pages@v6

      - uses: actions/upload-pages-artifact@v5
        with:
          path: dist

      - name: Deploy
        id: deployment
        uses: actions/deploy-pages@v5

В своём репозитории поменяй /nastachku-2026/ на его имя и один раз включи Pages: Settings → Pages → Source → GitHub Actions.

Проверка: после зелёного прогона слайды открываются по адресу https://<логин>.github.io/<репозиторий>/.

Заодно я включил Dependabot: раз в неделю он приносит обновления npm-зависимостей и версий actions.

Makefile, чтобы не помнить флаги

node_modules: package.json package-lock.json
	npm ci
	@touch node_modules

.PHONY: dev
dev: node_modules
	npm run dev

.PHONY: build
build: node_modules
	npm run build

THEME ?= light

.PHONY: export
export: node_modules
	npm run export -- $(if $(filter dark,$(THEME)),--dark --output slides-export-dark.pdf)

Весь трюк в первой цели. node_modules объявлен обычной файловой целью, которая зависит от манифестов. Зависимости ставятся, только если каталога нет или package.json с локом новее него. Поэтому make dev на свежем клоне работает сразу, а второй make build подряд ничего не переустанавливает.

make export THEME=dark кладёт тёмный PDF в отдельный файл, светлый при этом не перезаписывается.

Тонкие места, на которых легко споткнуться

• hide: true выкидывает слайд целиком. Из показа, из сборки и из PDF, и ссылка на него перестаёт работать. Скрытых слайдов «на всякий случай», до которых можно дойти кнопкой со слайда «Вопросы», так не сделать. Мои бэкапы поэтому лежат в конце презентации под hide: true, а ответы на эти вопросы записаны в заметках.
• Заметки спикера едут в публичную сборку. На выложенном сайте работает /presenter, и твой текст вместе с ответами на острые вопросы может прочитать кто угодно. Если это в планы не входит, собирай с --without-notes.
• Прямая ссылка на слайд на GitHub Pages отдаёт код 404. Браузер при этом покажет нужный слайд: Slidev кладёт копию index.html в 404.html, и роутер разбирается сам. А вот curl, проверка ссылок и превью в мессенджерах увидят честный 404. Если прямые ссылки важны, смотри в сторону --router-mode hash.
• Первый Markdown-заголовок слайда становится его названием. Поэтому надзаголовок перед # нельзя написать как ###: названием слайда станет он. В теме для этого отдельный компонент Kicker.
• SVG через <img> не перекрашивается. currentColor внутри <img> превращается в чёрный, и на тёмной теме логотип пропадает. Всё, что должно менять цвет вместе с темой, вставляй инлайном через компонент.
• Шрифты из сети. Slidev умеет подтягивать шрифты из Google Fonts, и на площадке без интернета это неприятный сюрприз. В моей теме шрифты лежат в зависимостях, и слайды показываются офлайн.
• Номер слайда при --with-clicks повторяется. Сам Slidev номеров не рисует. Их ставит тема, и считает она слайды. Слайд с четырьмя кликами превращается в пять страниц подряд с одним и тем же 3 / 37. Убрать номер из PDF можно одним правилом в style.css, потому что при экспорте Slidev вешает на <html> класс print: html.print .bear-footer .tabular-nums { display: none; }. Селектор здесь от моей темы, свой подсмотри в devtools. С --per-slide правило не сработает: там класса print нет. В своей теме я это починил: с --with-clicks номер из футера пропадает сам, а в обычном PDF остаётся.
• --range в обычном PDF ничего не отрезает. В Slidev 53.0.0 команда npx slidev export --range 3-4 отдала мне все 37 страниц вместо двух. Диапазон начинает работать с --per-slide или с --format png. Только не добавляй к --per-slide ещё и --with-clicks: клики не раскрываются, и каждый слайд попадает в PDF в состоянии до первого клика. Кусок доклада по кликам проще забрать картинками: --format png --with-clicks --range 3-4 отдаёт по файлу на клик.
• Dependabot и тема из GitHub. Зависимость вида github:jtprogru/slidev-theme-bear#v0.3.1 он предлагал «обновить» до v0.2.0. Тему пришлось добавить в ignore и бампать руками.
• Новому слайду алиас нужен сразу. Без routeAlias он откроется по номеру, и первая же перестановка сломает ссылку на него.

Кому Slidev не подойдёт

• Организаторы требуют pptx по своему шаблону и собираются править его сами. Картинки внутри pptx им не помогут.
• Над слайдами работает несколько человек, и не все из них дружат с git.
• Нужна презентация на пять слайдов к завтрашнему синку. Поднимать ради неё Node.js-проект дольше, чем нарисовать слайды руками.

Что с этим делать на практике

1. Запусти npm init slidev@latest, выбери тему и убедись, что dev-сервер поднялся.
2. Сразу разложи слайды по pages/NN-блок/MM-слаг.md и раздай им routeAlias.
3. Пиши заметку спикера вместе со слайдом, а не накануне: тайминг, текст, переход, справка.
4. Прогони доклад вслух с таймером и спрячь лишнее через hide: true.
5. Сделай npx slidev export и пролистай PDF глазами: переносы, плотные слайды, тёмная тема.
6. Включи деплой на Pages и реши, едут ли заметки в публичную сборку.

Как всё это выглядит в сборе, можно подсмотреть в nastachku-2026: там же лежит README с правилами, по которым устроена презентация.

На этом всё! Profit!

Привет, %username%! В февральской заметке про DIS я разбирал концепцию через шесть столпов Gartner — observability, AI-augmented testing, chaos engineering, auto remediation, SRE, supply chain security. Это была карта поверхности: что входит, зачем оно нужно, с чего начать. С тех пор накопилось мыслей, которые в эту карту уже не влезают.

DIS держится на связях. Архитектура, SLO, релизная дисциплина, наблюдаемость и экономика надёжности замкнуты в одну петлю обратной связи — вот что отличает иммунную систему от склада инструментов. Шесть столпов отвечают на вопрос «из чего собрано». Интереснее другое: как эти шесть друг друга питают, ограничивают и обучают.

Статичная защита ловит известное. Иммунная система учится на отклонениях — этим и отличается. Инциденты не меняют политики, gate-ы и лимиты автодействий? Значит, иммунитета нет, сколько бы компонент ты ни развернул. Проверяется это одним вопросом: замыкается ли у тебя цикл «инцидент → разбор → изменение правил».

Дальше разбираю, что связность означает в инженерных решениях, где проходит граница безопасной автоматики, как проектируется сознательное право на отказ и почему про DIS в какой-то момент приходится говорить с финансистами.

Операциональное определение

Цифровая иммунная система — это совокупность архитектурных ограничений, инженерных практик и оргритуалов, которая:

• минимизирует blast radius и вероятность каскадных отказов;
• переводит редкие ручные героизмы в воспроизводимую автоматику с понятными границами;
• использует наблюдаемость и SLO как язык контрактов между командами;
• учится на каждом отклонении (включая «почти инциденты») и обновляет политику изменений;
• считает деньги наравне с аптаймом: стоимость девяточек, цену шума, цену эскалаций.

Определение операциональное: каждый пункт можно проверить у себя за полчаса. Либо есть, либо нет.

Связность вместо перечисления

DIS обычно описывают через шесть практик — в таком виде концепцию упаковал Gartner в Top Strategic Technology Trends for 2023, анонсированных в октябре 2022 года. Каждая закрывает часть проблем, но шесть квадратов в презентации ещё не делают систему иммунной. Иммунитет рождается из связей между ними.

У самого термина, кстати, судьба показательная. Из топ-трендов Gartner DIS выпал сразу после 2023 года — в списках 2024, 2025 и 2026 его уже нет, а сама концепция переехала в Hype Cycle for Emerging Technologies 2024, причём в security-компанию к AI TRiSM и cybersecurity mesh. Знаменитый прогноз «инвестировавшие в digital immunity к 2025 году сократят downtime на 80%» Gartner публично так и не проверил. Инженерные лидеры вывеску тоже не подхватили: AWS называет то же самое continuous resilience, Google и Meta¹ — reliability engineering, Microsoft — reliability maturity. Термином пользуются в основном аутсорсеры вроде Infosys TechCompass и HCLTech. Хоронить концепцию из-за этого не стоит: все шесть практик живее всех живых и развиваются активнее, чем в 2022-м. Просто бренд не прижился, а содержание разошлось по индустрии под другими именами — и дальше я говорю «DIS» именно про содержание.

Связь первая — SLO как gate в CI/CD. Observability и release safety встречаются в одной точке: метрики ошибок и латентности превращаются в условие, при котором релиз продолжается или останавливается. Если SLO живут отдельно от пайплайна, ты получил красивый отчёт для руководства и ничего больше.

Связь вторая — постмортем как вход в runbook-as-code. Chaos engineering и auto remediation замыкаются через анализ инцидентов: каждое ручное действие, попавшее в разбор, либо превращается в безопасную автоматику, либо становится поводом изменить архитектуру, чтобы это действие не требовалось.

Связь третья — policy-as-code как единый центр правил. OPA, Sentinel или своя самописка — неважно; важно, что проверки supply chain, требования к release safety и архитектурные ограничения (blast radius, freeze windows, обязательные canary) лежат в одном месте. Один центр правил — один способ их обновить после инцидента.

Связь четвёртая — финансы как читатель SLO. SRE и FinOps говорят на одном языке: стоимость одной девяточки, стоимость минуты простоя для конкретного домена, стоимость флапающего алерта. Без этой связи надёжность остаётся «инженерной заботой» и проигрывает фичам в борьбе за время команды. Каждый раз.

Схематически петля выглядит так:

Каждая стрелка — правило, которое команда поддерживает сознательно. Выпадает одна — петля размыкается, DIS возвращается к набору практик, которые работают локально, но не складываются в систему обучения.

Право на отказ и организованная деградация

Когда я слышу разговоры о надёжности, рамка почти всегда одна — «всё должно работать». Зрелый подход добавляет к ней сознательно спроектированный отказ: что и в каком порядке выключается, когда поддерживать полный функционал уже невозможно.

Право на отказ — архитектурная сущность: контур деградации проектируешь так же, как нормальный путь запроса. И отвечаешь на четыре вопроса: какие функции выключаются первыми, какие последними, кто жмёт кнопку и какие сигналы триггерят автоматическую деградацию без человека.

Канонический публичный пример — инцидент GitHub 21 октября 2018. После 43-секундного разрыва между восточными ДЦ orchestrator автоматически промоутнул реплики MySQL, и в данных образовалось расхождение. Команда сознательно остановила доставку 5 миллионов webhook-событий и 80 тысяч Pages-сборок на время восстановления целостности БД — формулировка из постмортема: «explicit choice to partially degrade site usability […] instead of jeopardizing data we had already received from users». Это и есть приоритет «целостность данных > доступность фичи», превращённый в решение под давлением.

Другой угол: деградацию можно продавать. Cloudflare продаёт Always Online как явный контракт: если origin недоступен, edge отдаст статическую копию из кеша или версию из Internet Archive, динамика честно режется до статики. Клиент покупает «худший, но живой» ответ заранее. Netflix формализовал ту же идею в Hystrix (проект давно в maintenance mode, но паттерн пережил инструмент) и архитектуре рекомендательных пайплайнов: онлайн-расчёт не уложился в SLA — сервис отдаёт precomputed fallback, неперсонализированную подборку вместо пятисотки. Свежее продолжение той же линии — service-level prioritized load shedding: приоритизированный сброс нагрузки переехал с edge внутрь отдельных сервисов, где команда сама решает, какими запросами жертвовать первыми. Проверку боем устроил инфраструктурный сбой: на восстановлении Netflix поймал двенадцатикратный всплеск pre-fetch-запросов с Android-устройств, и шеддинг это съел. Показательно, куда сместился центр тяжести Netflix за десять лет: от «сломай прод и посмотри» к деградации, встроенной в каждый сервис как штатный механизм.

Отсюда три практических следствия.

Домены отказа определяют, какой кусок продукта можно уронить целиком. Независимые ingress, балансировщики, DNS-резолверы и хранилища секретов на вертикаль. Падает один домен — продукт теряет одну способность и остаётся живым. Без изоляции пользователь получает белую страницу. Стоимость такой изоляции — выше; стоимость отказа от неё — каскад при первом серьёзном инциденте.

Self-bootstrap, когда control-зависимости отвалились. Кэшированные сертификаты и токены, emergency-конфиги, offline-режим для критичных путей. Система поднимается сама. Или хотя бы дотягивает уже идущий трафик, пока её control plane лежит и поднять его некому. Для облака это значит: приватный кластер переживает падение IAM или API провайдера.

Региональную репликацию решаешь per-domain. Для платёжной вертикали приоритет — согласованность; для каталога — доступность. Глобальное «давайте всё реплицировать активно-активно» приводит к тому, что часть доменов плохо ложится в выбранную модель и компенсирует это сложными ad-hoc обходами.

Граница безопасной автоматики

Auto remediation на бумаге звучит как «система сама перезапускает сервисы и масштабирует ресурсы». На практике у автоматики всегда есть граница, и она важнее самой автоматики.

Control plane и data plane автоматизируешь по-разному. Data plane может рестартиться, переезжать между узлами, масштабироваться самостоятельно — здесь автоматика работает в зоне с предсказуемыми последствиями. Control plane — нет, или с дополнительными гардрейлами: автоматические изменения IAM, политик доступа, маршрутизации трафика между регионами — это операции с длинным blast radius и долгим rollback.

Глобальный отказ Facebook 4 октября 2021¹ — учебник по тому, что происходит, когда control plane завязан сам на себя. Рутинная команда оценки доступности backbone обвалила все межДЦ-линки; audit-инструмент, который должен был такую команду остановить, не сработал из-за бага. DNS-серверы автоматически сняли BGP-анонсы дата-центров — корректная политика «unhealthy = снимаем» превратилась в самоблокировку, когда «unhealthy» стало «всё одновременно». Инженеры на полдня лишились внутренних инструментов диагностики и физического доступа к части помещений. Урок: у автоматики control plane должен быть канал управления, не завязанный на то, что она контролирует.

Зеркальный кейс — платформа Yandex Infrastructure, где тот же урок заложили заранее, до аварии. Компоненты основного облака выкатывает отдельный редко обновляемый админский контур: сервис не деплоит сам себя, и кольцо «чтобы поднять облако, нужно облако» разорвано архитектурно. Система прав живёт внутри облака, но у дежурного есть аварийный обход — кнопка выдаёт абсолютный доступ мимо IDM, чтобы разбор инцидента не ждал восстановления той самой системы, которая лежит. SSH-сервер написан с нулём онлайновых зависимостей, аутентификация переведена с ключей на сертификаты, и раскатка прав по хостам перестала занимать 15 минут и ушла с критического пути. За шесть лет — три серьёзных инцидента на ~150 000 хостов и ни одного полного краха. За красивой фразой «канал управления, не зависящий от контролируемого» стоит вот такой список конкретных решений, и каждое кто-то оплатил временем команды.

Любое рискованное автодействие — через kill-switch, голосование и bounds. Bounds по времени — не больше трёх автодействий за пять минут, дальше стоп и эскалация на человека. По объёму — не больше 10% парка за один проход. По типу — никогда для production-control-plane. Конкретные цифры у каждой команды свои, важно другое: лимиты записаны в конфиге автоматики, а не в голове дежурного. Голосование — для решений без однозначно безопасного исхода. Автоматический rollback на предыдущую работающую версию допустим. Автоматическое поднятие шкалы трафика после отказа — нет.

Хрестоматийный кейс отсутствующих bounds — Knight Capital, 1 августа 2012. Новый код раскатили на 7 из 8 SMARS-серверов, а на восьмом остался мёртвый код «Power Peg», от которого Knight отказался ещё в 2003-м — и флаг, который новый код переиспользовал, на этом сервере активировал именно его. Хуже того, в 2005-м из Power Peg вынесли счётчик исполненных акций и после этого не перетестировали: останавливаться после заполнения родительского ордера код разучился. Никакой проверки «сколько ордеров в секунду — слишком много», никакого rate-cap на исходящий поток не было — за ~45 минут система отправила миллионы дочерних ордеров, набила ~4 миллиона исполнений и сожгла более $460M по оценке SEC, фактически уничтожив компанию. Автоматика без bounds масштабировала ошибку человека быстрее, чем кто-либо успел вмешаться.

Auto-healing допустим только там, где есть наблюдаемость, reversible-действия и понятный rollback-план. Если автоматику нельзя откатить одним действием — она работает только с человеком в петле. Это отсеивает большинство «умных» сценариев самовосстановления, которые красиво звучат в обзорах, но в проде разрывают петлю обратной связи.

Та же платформа Яндекса — сильный аргумент в пользу такой строгости. На масштабе ~50 000 приложений там сделали ставку на скорость доступа человека: дежурный дотягивается до системы за секунды, вместо того чтобы ждать, пока она починит себя сама. Философия прямо обратная модному auto-healing, и результат по надёжности от этого не пострадал. Полезная поправка к ощущению, что зрелость измеряется долей автоматических действий: измеряется она тем, у кого остаётся возможность вмешаться, когда автоматика ошиблась.

Meta зашла с третьей стороны и автоматизировала диагноз. Платформа DrP — это root cause analysis как сервис: 300+ команд, 2000 анализаторов, 50 тысяч автоматических расследований в день и снижение MTTR на 20–80%. Автоматика действий там тоже есть, но центр тяжести смещён в диагноз: платформа приносит дежурному ранжированную гипотезу и оставляет решение ему. Ещё раньше туда же подключили LLM — ранжировать подозрительные изменения при расследовании инцидента. Логика та же, что у Яндекса с break-glass: автоматический диагноз — безопасная зона. Ошибётся анализатор — дежурный потеряет минуты на проверку гипотезы, а не прод.

Runbook-as-code: ручное действие живёт один раз. Попало в постмортем — либо исчезает (через архитектурное изменение, после которого действие не нужно), либо становится безопасной автоматикой с лимитами. Накопление повторяющихся ручных шагов — главный симптом разорванной петли.

Release safety как код. Канареечный релиз с автоматическим rollback по порогам ошибок и латентности, freeze windows на пиковые периоды (новогодние праздники, чёрная пятница, день платежей), обязательные проверки политик. Договорённость с командой можно «в этот раз пропустить». Код, который останавливает пайплайн, — нельзя.

Главное правило: автоматика делает только то, за что инженер готов отвечать ночью. Всё остальное — под kill-switch и по шагам.

Экономика надёжности

Самый сильный признак зрелого DIS — споры переезжают с веры на экономику. До этого разговор о надёжности сводится к «нам нужна ещё одна девятка» или «у нас слишком много шума в алертах» — без цифр.

Стоимость одной девяточки — конкретная сумма, привязанная к домену отказа. Девятка для платёжного домена и девятка для рекомендательной выдачи стоят разных денег и приносят разную ценность. Глобальный SLO «99.95% по всему сервису» — худший компромисс между этими крайностями.

Цена шума — стоимость флапающего алерта. Измеряется в человеко-часах ночной работы, в том, какие решения принимаются на следующее утро, в проценте пропущенных P1 на фоне P3-шума. Шумовой бюджет — управляемая метрика: команда видит свой flap rate, владеет качеством сигналов и платит за избыточное оповещение тем же бюджетом, что и за реальные инциденты.

Цена эскалаций. Путь от P3 до P0 имеет свою стоимость: каждое повышение уровня — это человек, которого подняли среди ночи. Срежешь этот путь через policy-as-code — автоматическая первичная диагностика, маршрутизация к нужному owner-у, обогащение алерта контекстом — и это сразу деньги.

FinOps-витрина «стоимость простоя» висит рядом с MTTR-дашбордом. Один отвечает на «как быстро мы поднимаем», другой — на «во сколько нам обошлась минута». Без второй цифры приоритеты надёжности расставляют «по ощущениям».

Управляемая девяточность. Целишься в оптимум, а максимум оставляешь тем, кому его оплатят. Лишняя девятка стоит дорого: переход с 99.9% на 99.99% кратно увеличивает вложения в инфраструктуру и команду, а прирост пользовательской ценности с этими вложениями несопоставим. Зрелая команда умеет сказать руководству «нам не нужна следующая девятка» и объяснить, почему.

Сколько у тебя стоит минута простоя платёжного пути? Если ответа нет, весь дальнейший разговор про девятки — вкусовщина, и спорить в нём будет тот, кто громче.

Когда про DIS говорят на языке денег, руководство принимает решения о надёжности так же, как о фичах. Пока этого языка нет, надёжность живёт только на инженерных совещаниях, а бюджет уходит туда, где ценность показана в деньгах.

Чужие лестницы зрелости

Прежде чем предлагать свою диагностику, честный вопрос: может, готовая линейка уже есть? Я пошёл проверять и обнаружил показательную вещь. Сводной модели зрелости DIS не существует. Gartner её не публиковал: ни статья-первоисточник, ни глоссарий уровней не предлагают, а в названиях платных Hype Cycle модель зрелости DIS не значится. Зато в 2023–2025 стадийные модели появились у тех, кто термин не употребляет вовсе — и по ним хорошо видно, куда индустрия смотрит на самом деле.

Самая близкая к «лестнице зрелости DIS» вещь на рынке — Reliability Maturity Model из Azure Well-Architected Framework, появившаяся в 2025 году. Пять уровней: Get resilient → Self-preservation → Recovery readiness → Maintain stability → Stay resilient. SRE как роль появляется на третьем уровне, выделенная SRE-функция и safe deployment practices — на четвёртом, а пятый честно объявлен бесконечным: устойчивость к рискам, которые ещё не случались. Ирония в том, что «гартнеровскую» модель зрелости в итоге написал Microsoft.

AWS пошёл другим путём, и для этого поста он показательнее. Resilience Lifecycle Framework — пять стадий, сознательно замкнутых в круг: Set Objectives → Design and Implement → Evaluate and Test → Operate → Respond and Learn. Последняя стадия возвращает тебя к первой: выучил урок инцидента — пересмотрел цели. AWS независимо пришёл к тому же выводу, вокруг которого построен весь этот пост: зрелость — это замкнутая петля, а не этаж, на который поднялся и остался. Инструментальная обвязка тоже живая: Resilience Hub с конца 2024 года сам рекомендует эксперименты Fault Injection Service под конкретную архитектуру — chaos engineering из ручной дисциплины превращается в подсказку сервиса.

У CNCF есть Cloud Native Maturity Model от рабочей группы Cartografos: пять уровней по четырём измерениям — People, Process, Policy, Technology. Для нашей темы интересны верхние ступени: chaos engineering как штатная операция появляется на четвёртом уровне, автоматическое восстановление в known good state — на пятом. То есть автоматика самовосстановления и здесь оказалась вершиной лестницы. Входным билетом её не считает никто.

По отдельным столпам DIS лестницы существуют давно, но живут независимо друг от друга. Chaos engineering — классическая Chaos Maturity Model из книги Netflix/O’Reilly с осями sophistication и adoption, плюс практические руководства по внедрению у Gremlin и eBook Harness. Observability — Grafana Observability Journey (Reactive → Proactive → Systematic) и модель New Relic. Reliability целиком — Reliability Maturity Model в журнале ;login: от USENIX (absent → reactive → proactive → strategic → visionary) и опросник Google CRE Production Maturity Assessment. Обе — гугловые, и мерят они разное: первая описывает зрелость организации и её отношение к надёжности, вторая опрашивает про готовность конкретного прода. Supply chain — SLSA с уровнями L0–L3, единственная по-настоящему формализованная лестница из всех шести столпов. А для auto remediation индустриального стандарта нет вовсе — только вендорские блоги, каждый со своей нумерацией.

Лестницы, которая охватывала бы устойчивость целиком, ни Google, ни Meta не предлагают — только компонентные модели из абзаца выше. Вместо общей шкалы у обеих эволюция метода. Google в статье «The Evolution of SRE at Google» (журнал ;login: от USENIX, авторы Tim Falzone и Ben Treynor Sloss, основатель Google SRE) признал, что классическая модель error budgets перестала покрывать системы, где допустимый ущерб равен нулю, и переходит на STAMP/STPA — системный анализ опасностей вместо подсчёта бюджета ошибок. Meta вкладывается в автоматизацию диагноза, о которой я писал выше. Обе стратегии сводятся к «поменяй способ думать об отказах». Для лестниц как жанра это плохая новость.

Академия к теме только подбирается. Единственная известная мне работа, которая целенаправленно строит именно DIS Maturity Model — «A Conceptual Model of Digital Immune System to Increase the Resilience of Technology Ecosystems» Беате Краузе и Яниса Грабиса (RCIS 2024, Springer): концептуальная модель устойчивости технологической экосистемы в контексте европейской регуляторики NIS2 и DORA. Судя по продолжению 2025 года, до опубликованной шкалы уровней дело пока не дошло. А в ноябре 2025 вышла первая целая книга про DIS — «Digital Immune System: Principles and Practices» (Wiley-Scrivener): уклон в security и AI, но отдельная глава про экономику внедрения там есть. Приятно: не мне одному кажется, что разговор про DIS — это в том числе разговор экономистов.

Итог ревизии: компонентные лестницы есть, цельной — нет. Ни одна из существующих моделей не проверяет главного — замыкается ли петля между компонентами. Поэтому дальше — пять вопросов на связность вместо шестой лестницы.

Маркеры зрелого DIS

Как отличить «у нас DIS» от «у нас отдельные практики»? Пять наблюдаемых маркеров. Это диагностика, не предписание: набрал три из пяти — основа для иммунной системы у тебя есть.

1. SLO двигают релизы. SLO, который не закрывает gate в CI/CD, остаётся отчётом для руководства.
2. Класс проблем не повторяется. Каждый крупный инцидент уменьшает вероятность повторения класса проблем. В правилах и политиках видно, что система «училась»: после инцидента появился новый gate, изменился лимит автоматики, добавилась проверка в policy-as-code.
3. Автоматика делает только обоснованное. Каждое автодействие имеет владельца, лимиты и kill-switch. Всё остальное живёт под человеком в петле.
4. Команды спорят на языке экономики. Приоритеты надёжности обсуждают в рублях: стоимость девяточек, шума, эскалаций. Фразу «у нас плохо с алертами» на таком совещании перебивают вопросом «сколько это стоит».
5. Руководство видит стоимость надёжности и принимает решения на этом языке. На совещании уровня CTO рядом с дашбордом MTTR висит дашборд FinOps.

Ноль маркеров — DIS нет, какие бы инструменты ни были развёрнуты. Все пять — фокус смещается с построения иммунной системы на её эксплуатацию.

Что ломает DIS на масштабе

Разваливается всё тихо: кто-то пропускает один шаг в петле, и дальше система живёт по инерции. Архитектура при этом обычно нормальная. Ниже — типичные failure modes.

SLO без gate. Есть метрика, есть SLO, есть error budget, но релиз не блокируется, когда бюджет исчерпан. Цикл разомкнут: измеряем, но не действуем. Лечение: сделать SLO условием пайплайна.

Автоматика, которой никто не поставил границ. Auto-healing пытается «починить» инфраструктурный инцидент — рестартит поды, перекидывает трафик, масштабирует кластер — и тем самым расширяет blast radius. Каждому автодействию нужны bounds: сколько раз за период, какой процент парка, при каких условиях остановиться и позвать человека.

Постмортем без обучения. Разбор сделан, документ есть, action items записаны — runbook не обновлён, политики не изменены, lessons learned остались на странице в Confluence, которую с тех пор никто не открывал. Петля «инцидент → разбор → изменение правил» обрывается на втором шаге.

За шумом никто не следит. Flap rate растёт, доверие к алертам падает, инженеры выключают нотификации канала, P1 пропускается на фоне P3-шума. Шум — управляемая метрика. Брошенный без присмотра, он деградирует наблюдаемость тише и сильнее, чем кажется.

Про деньги молчат. Надёжность обсуждают только инженеры, бизнес решает вслепую. Любое сокращение бюджета в таком раскладе первым делом бьёт по надёжности: её ценность просто не переведена в те же единицы, что и всё остальное.

Любое из этих узких мест разрывает петлю обратной связи и возвращает DIS к набору практик.

Итого

DIS — это про связность и дисциплину. Архитектура режет blast radius на домены отказа, SLO превращает обещания в измеримый контракт. Нагрузка и хаос по регламенту проверяют гипотезы надёжности раньше, чем это за тебя сделает продакшен. Автоматика работает под kill-switch и bounds. У онколла есть лимит на шум алертов и право остановить поставку. А экономика в конце считает, во сколько всё это обошлось. По отдельности ни один элемент иммунитета не даёт: он появляется там, где они замкнулись в петлю обучения.

Про российский контекст и кибериммунитет я уже писал в февральской заметке. Здесь добавлю только одно: DIS дополняет этот подход петлёй обучения через инциденты и явной экономикой надёжности.

Порядок, в котором эти элементы вообще имеет смысл строить, — отдельный разговор: пока нет мониторинга, обсуждать автоматическое восстановление рано. Я развернул его в иерархию надёжности, а проверку контролов безопасности тем же методом хаос-экспериментов — в Security Chaos Engineering.

Хочешь понять, где стоишь — пройдись по пяти маркерам и посчитай, сколько выполняется на самом деле. Картина получится честнее, чем от аудита инструментов или примерки чужих лестниц из предыдущей секции: инструменты и уровни идут следом за связностью, а не наоборот.

PS: эта статья — то, что я не разобрал в февральской заметке про DIS. Если первая отвечала на «что это такое и из чего состоит», эта — на «что отличает зрелый DIS от витрины из шести квадратов».

Публичные кейсы

Подборка постмортемов, инженерных описаний и моделей зрелости, на которых строится бо́льшая часть тезисов выше. Полезна как карта дальнейшего чтения.

Право на отказ и организованная деградация:

• GitHub, 21.10.2018 — сознательная пауза webhooks и Pages ради целостности БД.
• Cloudflare Always Online и интеграция с Internet Archive — деградация как продуктовый контракт.
• Netflix Hystrix и архитектура персонализации — fallback на precomputed-результат, встроенный в пайплайн.
• Cloudflare, 2.07.2019 — global WAF terminate как заранее построенный kill-switch уровня домена.
• Cloudflare, 18.11.2025 — bypass на prior-version proxy для Workers KV и Access как реактивная деградация.

Граница безопасной автоматики:

• Knight Capital, 1.08.2012 — переиспользованный флаг + неполный деплой + автоматика без rate-cap, $460M+ за ~45 минут.
• Facebook BGP, 4.10.2021 — баг audit-инструмента + автоснятие DNS-анонсов = control plane выпиливает сам себя.
• AWS S3, 28.02.2017 — playbook-инструмент без safety-check на минимальную ёмкость масштабировал опечатку оператора.
• Cloudflare WAF, 2.07.2019 — regex-правило раскатилось глобально без canary, потому что SOP для конфигов отличался от SOP для бинарей.
• GitLab, 31.01.2017 — оператор стёр primary; параллельно все пять механизмов бэкапа тихо не работали (silent failure).
• Cloudflare, 18.11.2025 — изменение прав ClickHouse → дубль строк → превышен hard limit → Result::unwrap() panic в Rust-проксе → автогенерация плохого файла каждые 5 минут.
• Discord, 25.03.2026 — при вертикальном K8s-rescale termination grace period истёк раньше, чем начался handoff сессий; волна автоматических reconnect’ов добавила thundering herd.
• Yandex Infrastructure, 10.03.2026 — не постмортем, а инженерное описание: админский контур, break-glass мимо IDM и SSH с нулём онлайновых зависимостей как заранее построенный ответ на урок Facebook.

Обратная сторона — где автоматика спасла:

• Google Cloud Networking, 2.06.2019 — первый пункт follow-up в постмортеме — «immediately halted the datacenter automation software».
• Netflix Chaos Monkey и Simian Army — автоматика как тренажёр: регулярная поломка прода посреди рабочего дня приучила архитектуру к фоллбекам.

Модели зрелости и свежие публикации (2024–2026):

• Azure Well-Architected Reliability Maturity Model — пять уровней от Get resilient до Stay resilient; ближайший на рынке аналог «лестницы зрелости DIS».
• AWS Resilience Lifecycle Framework — пять стадий циклом, а не лестницей; финальная стадия Respond and Learn возвращает к пересмотру целей.
• CNCF Cloud Native Maturity Model — chaos engineering на четвёртом уровне, автоматическое восстановление на пятом.
• The Evolution of SRE at Google (журнал ;login: от USENIX) и STPA на sre.google — отказ от error budgets как универсального инструмента в пользу системного анализа опасностей.
• DrP: Meta’s Root Cause Analysis Platform at Scale и Leveraging AI for efficient incident response — автоматизация диагноза вместо автоматизации действия.
• Netflix: service-level prioritized load shedding — деградация как штатный механизм каждого сервиса.
• DORA Research — отчёты 2024–2025: метрики throughput/instability и reliability как операционная характеристика.
• Krauze, Grabis — A Conceptual Model of Digital Immune System… (RCIS 2024, Springer, полный текст платный) и продолжение 2025 года — единственная академическая попытка построить именно DIS Maturity Model.
• Digital Immune System: Principles and Practices (Wiley-Scrivener, ноябрь 2025, платная) — первая книга целиком про DIS, включая главу об экономике внедрения.
• Gartner: What Is a Digital Immune System and Why Does It Matter, глоссарий, Hype Cycle for Emerging Technologies 2024 — первоисточники; часть страниц Gartner прячет за регистрацию.
• Infosys TechCompass: Digital Immune System — редкий пример живого использования термина у сервисных компаний.

Привет, %username%! Ты вводишь адрес, жмёшь Enter — и через мгновение видишь страницу. Выглядит как одно действие. Под капотом же — каскад процессов, прошивающий все уровни системы: от физических прерываний процессора до алгоритмов рендеринга браузера. Разберём весь путь — локальный и глобальный — от нажатия клавиши до отрисовки последнего пикселя на экране.

Спойлер: этот вопрос не зря любят на собеседованиях — по тому, где кандидат останавливается, видно всю его карту знаний. Про то, что там спрашивают ещё, я писал после полусотни собесов. И полезен он не ради галочки: когда знаешь, из каких этажей состоит путь, «сайт тормозит» перестаёт быть магией и превращается в конкретный этаж, на котором надо копать.

Локальный компьютер: до первого пакета

Ввод URL и обработка клавиатурных событий

Всё начинается с физического нажатия клавиши. Каждое нажатие генерирует hardware interrupt (аппаратное прерывание), которое передаётся процессору. Клавиатура, как периферийное устройство, отправляет сигнал контроллеру прерываний, тот приостанавливает текущее выполнение процессора и вызывает interrupt service routine (ISR) — специальную процедуру обработки прерывания.

Вход в обработчик прерывания — это переключение в kernel mode и сохранение части состояния прерванного контекста (регистры, program counter, stack pointer). Но само по себе это ещё не context switch в смысле планировщика: процессор часто возвращается в тот же поток, а переключение на другой процесс — отдельное событие, которое может и не произойти.

Дальше — важная тонкость, на которой легко ошибиться. Ввод в адресную строку обрабатывает UI-поток самого браузера (browser process), а не JavaScript открытой веб-страницы: renderer-процесс страницы keydown из омнибокса вообще не видит. Браузер сам решает, что ты ввёл — URL или поисковый запрос, — и инициирует навигацию. (Те самые события keydown, JavaScript-event loop и синхронизация с rendering pipeline — это уже про обработку ввода внутри самой страницы, а не про адресную строку.)

После ввода полного URL и нажатия Enter браузер парсит адрес, разделяя его на компоненты: протокол (https://), доменное имя (example.com), путь (/page) и query-параметры. По умолчанию браузеры используют HTTPS (порт 443).

Проверка кэшей браузера до сетевого запроса

Прежде чем инициировать DNS resolution, браузер проходит цепочку локальных кэшей — и во многих случаях сетевой запрос вообще не понадобится. Порядок такой: сначала HTTP-кэш браузера (memory cache для текущей сессии и disk cache между запусками) — если ресурс ещё свежий по Cache-Control/Expires, он отдаётся со статусом from memory cache / from disk cache, без единого пакета в сеть. Если ресурс формально устарел, но у него есть валидатор (ETag или Last-Modified), браузер отправляет conditional request (If-None-Match / If-Modified-Since) и может получить 304 Not Modified — заголовки приходят, тело не передаётся.

Выше HTTP-кэша стоит Service Worker: если на origin зарегистрирован SW, он перехватывает fetch и способен отдать ответ из Cache Storage полностью офлайн, вообще минуя сеть. Отдельно существует bfcache (back/forward cache) — снимок полностью живой страницы (с DOM и состоянием JS), который позволяет мгновенно вернуться по кнопкам «назад/вперёд» без повторного парсинга и рендеринга.

Только промах во всей этой цепочке приводит к реальному сетевому пути, описанному ниже. Именно поэтому повторное открытие сайта визуально мгновенно: львиная доля ресурсов не доходит даже до стадии DNS.

DNS Resolution: преобразование имени в IP-адрес

Прежде чем браузер сможет установить соединение с сервером, ему надо преобразовать человекочитаемое доменное имя в IP-адрес — процесс, называемый DNS resolution. Процесс многоступенчатый, с несколькими уровнями кэширования.

Сначала браузер проверяет свой локальный DNS-кэш. Если записи нет, запрос уходит операционной системе, которая проверяет системный кэш (на современных дистрибутивах за это отвечает systemd-resolved — про его настройку у меня есть отдельный пост). При промахе в обоих кэшах запрос отправляется к DNS resolver — обычно это DNS-сервер провайдера или публичный DNS (Google 8.8.8.8, Cloudflare 1.1.1.1).

Resolver выполняет рекурсивный запрос от имени клиента. Если у него нет кэшированной записи, он обращается к Root DNS-серверам — 13 логических серверов (a–m.root-servers.net), каждый из которых на деле Anycast-кластер из сотен нод по всему миру. Root DNS не знает конкретного IP-адреса, но направляет запрос к TLD-серверам, отвечающим за зоны верхнего уровня (.com, .org, .ru).

TLD-сервер направляет запрос к Authoritative DNS-серверу конкретного домена, который и возвращает финальный IP. Весь процесс обычно занимает от 20 до 120 миллисекунд в зависимости от удалённости серверов и состояния кэшей.

Только это не строго линейная цепочка «один запрос → один IP → connect». Браузер обычно запрашивает записи A (IPv4) и AAAA (IPv6) параллельно, может учитывать HTTPS/SVCB-записи и ходить через DoH/DoT, а в ответ приходит несколько адресов. Дальше в дело вступает Happy Eyeballs: клиент запускает конкурентные попытки подключения по IPv6 и IPv4 со слегка разнесённым стартом, чтобы одна неработающая ветка не тормозила навигацию, — а иногда новое соединение вообще не нужно, потому что переиспользуется уже открытое. То есть реальная картина ближе к графу конкурентных операций, чем к последовательному списку.

Рекурсивный и итеративный запросы — не одно и то же: при рекурсивном resolver берёт на себя всю работу по обходу иерархии, при итеративном клиент сам последовательно обращается к каждому уровню.

CDN, Anycast и edge: куда на самом деле резолвится имя

Описанная выше цепочка для крупного сайта почти никогда не заканчивается на origin-сервере. Authoritative DNS для домена вроде cnn.com обычно делегирован CDN (Cloudflare, Akamai, Fastly, CloudFront), и он возвращает не фиксированный IP конкретного дата-центра, а адрес ближайшей edge-точки.

Работают два механизма приближения:

• GeoDNS / EDNS Client Subnet — authoritative-сервер смотрит на подсеть резолвера (или клиента) и отдаёт разный ответ в зависимости от географии.
• Anycast — один и тот же IP-адрес анонсируется по BGP из десятков локаций мира, так что пакет естественным образом доходит до топологически ближайшей ноды.

В результате TCP- и TLS-handshake происходят не с origin в другом полушарии, а с edge-нодой в десятках километров: RTT падает с ~100–150 мс до единиц миллисекунд. А это ключевой множитель для TCP slow start и числа TLS round-trips. На edge отдаётся закэшированный статический контент, а к origin запрос уходит только при cache miss или за динамикой — часто по уже прогретому keep-alive соединению. Попутно CDN обычно терминирует TLS на edge и первым в цепочке поддерживает свежие протоколы (HTTP/3, TLS 1.3), даже если origin о них не знает.

Установление TCP-соединения: трёхстороннее рукопожатие

Получив IP-адрес, браузер готов установить транспортное соединение. Для HTTP/1.1 и HTTP/2 используется TCP — надёжный протокол с установлением соединения (HTTP/3 работает иначе, поверх QUIC/UDP — о нём в разделе про версии протокола), а само установление TCP идёт через three-way handshake.

Клиент отправляет SYN-пакет с начальным sequence number — случайным числом для синхронизации и защиты от подделки. Сервер отвечает SYN-ACK, который одновременно подтверждает SYN клиента (увеличивая sequence number на 1) и несёт собственный SYN со своим sequence number. Клиент завершает рукопожатие ACK-пакетом.

В процессе ОС выполняет системные вызовы socket() и connect() для создания сокета и инициации соединения. Сокет — это конечная точка двунаправленной связи между процессами. Клиент использует эфемерный порт (IANA-диапазон 49152–65535; Linux по умолчанию берёт из 32768–60999, см. net.ipv4.ip_local_port_range), а сервер слушает на стандартном порту (80 для HTTP, 443 для HTTPS). Кто хочет увидеть, как эфемерные порты ломают жизнь на практике, — почитай про активный и пассивный режимы FTP.

Управление потоком и перегрузкой: MSS, MTU, congestion control

Three-way handshake — это не только синхронизация sequence numbers. В SYN-пакетах стороны согласуют опции, критичные для производительности:

• MSS (Maximum Segment Size) — максимальный размер полезной нагрузки TCP-сегмента, выводимый из MTU канала (обычно 1500 байт для Ethernet → MSS ≈ 1460).
• Window Scale — множитель, позволяющий окну превышать 64 КБ.
• SACK (Selective Acknowledgment) и timestamps.

Если по пути встречается канал с меньшим MTU, срабатывает фрагментация или (при выставленном бите DF) Path MTU Discovery через ICMP. А вот если ICMP заботливо прибит на файрволе — получаешь «PMTU black hole»: соединение устанавливается, мелкие пакеты ходят, а крупные молча теряются и передача виснет. Классика жанра, на которую убивают часы, прежде чем догадаться посмотреть на MTU.

После установки соединения объём данных «в полёте» ограничен сразу двумя окнами: receive window (flow control — сколько готов принять получатель) и congestion window / cwnd (congestion control — сколько сеть готова пропустить без потерь). TCP стартует с малого cwnd (initial window, обычно 10 сегментов) и в фазе slow start наращивает его экспоненциально каждый RTT, затем переходит в линейный рост (congestion avoidance); при потере (таймаут или три dup ACK) окно резко сокращается.

Именно slow start объясняет ценность первых ~14 КБ ответа (см. видео «Почему ваш сайт должен весить 14 КБ») — они умещаются в initial window и приходят за один round-trip, тогда как всё сверх того требует новых RTT на «раскачку». Современные стеки используют CUBIC (дефолт Linux, реагирует на потери) и BBR (моделирует пропускную способность и RTT, а не ждёт потерь).

TLS Handshake: установление защищённого канала

Для HTTPS после установления TCP следует ещё один этап — TLS handshake. Он устанавливает зашифрованный канал и подтверждает, что сервер — тот, за кого себя выдаёт.

Клиент отправляет ClientHello: поддерживаемые версии (supported_versions, обычно TLS 1.3), список cipher suites, 32 байта случайных данных и расширения — SNI (Server Name Indication), ALPN, signature_algorithms и, что принципиально для 1.3, key_share с уже сгенерированным эфемерным (EC)DHE-ключом. Cipher suites в TLS 1.3 используют только AEAD-алгоритмы вроде TLS_AES_256_GCM_SHA384 — и, в отличие от TLS 1.2, в само имя сьюта уже не входят алгоритмы обмена ключами и аутентификации (ECDHE, RSA), они вынесены в расширения. В обычном браузерном handshake с сертификатом ключи выводятся через эфемерный (EC)DHE — это и даёт forward secrecy (стандарт допускает ещё два режима: чистый PSK и PSK вместе с (EC)DHE, так что «всегда ECDHE» — упрощение).

Сервер отвечает ServerHello со своим key_share и выбранным cipher suite. С этого момента обе стороны уже могут вычислить общий (EC)DHE-секрет — и всё дальнейшее шифруется. Дальше сервер шлёт EncryptedExtensions, Certificate и CertificateVerify — подпись всего предыдущего handshake приватным ключом, доказывающую владение сертификатом. Клиент проверяет сам сертификат (публичный ключ, цепочку до доверенного Certificate Authority) и эту подпись.

Отдельного обмена ключами в стиле «клиент шифрует секрет публичным ключом сервера» в TLS 1.3 нет. Общий (EC)DHE-секрет уже получен из двух key_share, и из него через HKDF выводятся все симметричные ключи. Никакого pre-master secret в ClientKeyExchange здесь не пересылается — это схема RSA key exchange из TLS 1.2 и более старых версий, которую 1.3 выкинул вместе с прочими небезопасными механизмами.

Финальный этап — обе стороны обмениваются сообщениями Finished, подтверждая целостность handshake. Отдельный ChangeCipherSpec в TLS 1.3 из настоящего handshake исключён и оставлен лишь как пустой совместимый сигнал для старых middlebox. Полный handshake TLS 1.3 укладывается в один RTT (против двух в 1.2). С заранее полученным PSK возможен 0-RTT: клиент отправляет ранние данные ещё до завершения нового handshake — но у них слабее гарантии безопасности и их можно воспроизвести повторно (replay), поэтому сервер не должен принимать через 0-RTT необратимые операции. То есть 0-RTT — это resumption с ранними данными, а не «handshake за ноль RTT».

Формирование и отправка HTTP-запроса

После установления защищённого соединения браузер готов отправить HTTP-запрос. Структура запроса состоит из request line (метод, путь, версия HTTP), заголовков и опционального тела.

Request line для главной страницы обычно выглядит как GET / HTTP/1.1. За ним следуют заголовки, каждый на отдельной строке: Host: example.com (обязательный), User-Agent: Mozilla/5.0..., Accept: text/html,application/xhtml+xml..., Accept-Language: ru,en, Accept-Encoding: gzip, deflate, br, Connection: keep-alive, Cache-Control: max-age=0.

Сформированный запрос передаётся через системный вызов send() или write(), который копирует данные из user space в kernel space в socket buffer. Дальше ядро обрабатывает их через network stack, готовя к передаче по сети.

HTTP→HTTPS, редиректы и HSTS

Реальный первый запрос редко сразу попадает в целевой ресурс. Если пользователь ввёл голый домен или http-URL, срабатывает несколько механизмов.

Первый — HSTS (HTTP Strict Transport Security): если домен есть в HSTS preload list, вшитом в браузер, или ранее прислал заголовок Strict-Transport-Security, браузер ещё до выхода в сеть сам заменяет http:// на https:// (internal redirect 307), исключая небезопасный первый хоп и возможность SSL-stripping.

Второй — серверные редиректы: сервер отвечает статусами 301/302/307/308 с заголовком Location, и браузер повторяет путь для нового URL — иногда с новым DNS/TCP/TLS, если сменился хост.

Типичная цепочка выглядит как http://cnn.com → https://cnn.com → https://www.cnn.com. Каждый лишний редирект — дополнительный RTT (а при смене хоста ещё и новый TLS-handshake), поэтому их число минимизируют. Различается и семантика кэширования, хотя и не так жёстко, как принято думать: 301 и 308 (permanent) браузер может эвристически закэшировать даже без явного срока — но это не значит «навсегда». А 302 и 307 (temporary) тоже кэшируются, если в ответе есть подходящие директивы вроде Cache-Control: max-age=.... Фактическое повторное использование редиректа определяется freshness, revalidation и cache-control-политикой, а не только кодом статуса.

Версии протокола: HTTP/1.1, HTTP/2, HTTP/3 (QUIC)

Показанный выше GET / HTTP/1.1 — упрощение: версия прикладного протокола согласуется ещё в TLS через ALPN (Application-Layer Protocol Negotiation) внутри ClientHello.

HTTP/1.1 — текстовый протокол. Формально в нём был pipelining: клиент мог отправить несколько запросов, не дожидаясь ответов. Но ответы всё равно обязаны приходить строго по порядку, что давало head-of-line (HoL) blocking; из-за этого браузеры от широкого pipelining практически отказались. Так что «один запрос за раз» — упрощение: точнее, на одном HTTP/1.1-соединении браузеры не делают полноценного независимого мультиплексирования, поэтому параллелизм исторически набирали открытием 6+ TCP-соединений на домен.

HTTP/2 — бинарный: вместо текстовой request line используются псевдозаголовки (:method, :scheme, :authority, :path, :status) и бинарное фреймирование. Он мультиплексирует множество streams в одном TCP-соединении, добавляет сжатие заголовков (HPACK) и server push (ныне депрекейтед); заголовка Connection: keep-alive и механизма Transfer-Encoding: chunked в нём уже нет — их роль берёт на себя фреймовый уровень. Но HTTP/2 остаётся уязвим к TCP-level HoL blocking — потеря одного пакета тормозит все streams, потому что упорядочивание идёт на уровне TCP.

HTTP/3 работает поверх QUIC — транспорта на UDP вместо TCP. QUIC объединяет транспортный и криптографический handshake (TLS 1.3 встроен внутрь), устанавливая соединение за 1-RTT или даже 0-RTT, а мультиплексирование делает на своём уровне — потеря пакета в одном stream не блокирует остальные, то есть transport-level HoL blocking устранён. Дополнительно QUIC переживает смену сети через connection migration по Connection ID: соединение не рвётся при переключении Wi-Fi ↔ LTE.

Для сайта за CDN клиент почти наверняка говорит по HTTP/2 или HTTP/3, а не по «учебному» HTTP/1.1.

Сетевой путь: от пакета к кадру

Прохождение через сетевой стек: инкапсуляция

Данные HTTP-запроса проходят вниз по сетевому стеку через инкапсуляцию — последовательное добавление заголовков на каждом уровне.

На транспортном уровне (L4) данные разбиваются на TCP-сегменты. К каждому добавляется TCP-заголовок: source port (эфемерный порт клиента), destination port (443 для HTTPS), sequence number, acknowledgment number, flags (ACK, PSH и др.), window size, checksum.

На сетевом уровне (L3) сегмент инкапсулируется в IP-пакет. IP-заголовок включает: version (4 для IPv4), header length, total length, identification (для сборки фрагментов), flags и fragment offset, TTL (Time To Live) — счётчик, уменьшающийся на каждом роутере, protocol field (6 для TCP, 17 для UDP), header checksum, source IP, destination IP.

Каждый роутер на пути декрементирует TTL на 1, и если значение достигает 0, пакет отбрасывается, а отправителю уходит ICMP Time Exceeded. Это предотвращает routing loops — и заодно на этом механизме работает traceroute.

На канальном уровне (L2) IP-пакет инкапсулируется в Ethernet frame. Заголовок содержит destination MAC (6 байт), source MAC (6 байт), EtherType (2 байта, 0x0800 для IPv4, 0x86DD для IPv6). В конце кадра добавляется FCS (Frame Check Sequence) — контрольная сумма для обнаружения ошибок передачи.

Оговорка на весь этот раздел: дальше описан IPv4 поверх Ethernet — один распространённый вариант, а не универсальный «низ». В IPv6 структура заголовка другая, нет header checksum, вместо TTL — Hop Limit, а маршрутизаторы IPv6 пакеты не фрагментируют (это при необходимости делает источник). Да и физически соединение клиента может идти через Wi-Fi, cellular stack, VPN-туннель, виртуальный интерфейс или вообще loopback — ARP и Ethernet-кадр тогда выглядят иначе или отсутствуют вовсе.

ARP Resolution: преобразование IP в MAC-адрес

Прежде чем отправить кадр, система должна определить MAC-адрес следующего узла в локальной сети — обычно это адрес default gateway. Для этого используется ARP (Address Resolution Protocol).

Система сначала проверяет ARP cache — таблицу соответствий IP → MAC в оперативной памяти. Если соответствия нет, отправляется ARP Request — широковещательный пакет с destination MAC FF:FF:FF:FF:FF:FF, который получают все устройства в локальной сети. Смысл запроса: «Кто имеет IP 192.168.1.1? Сообщите на MAC AA:BB:CC:DD:EE:FF».

Устройство с этим IP отвечает ARP Reply — unicast-пакетом со своим MAC. Система обновляет ARP cache и отправляет кадр. В Linux запись держится в состоянии reachable около 30 секунд (base_reachable_time с джиттером), потом переходит в stale и перед следующим использованием перепроверяется.

Маршрутизация: путь через роутеры

После определения MAC-адреса кадр передаётся сетевому адаптеру (NIC) через DMA (Direct Memory Access) — NIC напрямую копирует данные из системной памяти без участия CPU.

Кадр попадает в transmit ring buffer — кольцевой буфер дескрипторов пакетов в оперативной памяти, разделяемый между драйвером и NIC. NIC читает дескрипторы, получает адреса пакетов в памяти и передаёт данные на физический уровень.

Пакет достигает первого роутера (обычно домашнего шлюза), который выполняет de-encapsulation и re-encapsulation: снимает Ethernet-заголовок, анализирует IP-заголовок, проверяет routing table для определения next hop, декрементирует TTL, пересчитывает IP checksum и создаёт новый Ethernet-кадр с новыми MAC-адресами.

Процесс повторяется на каждом роутере. Ключевое: IP-пакет (L3) остаётся неизменным от источника до получателя (за исключением TTL и checksum), тогда как Ethernet-кадр (L2) пересоздаётся на каждом hop. IP-адреса определяют конечную точку назначения, MAC-адреса используются только для доставки кадра на следующий hop.

Routing table содержит записи в формате: network prefix, netmask, next hop, interface. При получении пакета роутер выполняет longest prefix match — находит наиболее специфичное правило, соответствующее destination IP. Если соответствия нет, пакет отправляется через default route (0.0.0.0/0).

BGP: маршрутизация между автономными системами

Longest prefix match объясняет, как роутер выбирает next hop среди известных ему маршрутов, но не откуда берётся сама глобальная карта интернета. Домашний роутер знает лишь default route «всё незнакомое — провайдеру». Дальше пакет попадает в сеть ISP и движется между автономными системами (AS) — независимо управляемыми сетями (провайдеры, дата-центры, CDN), каждой из которых присвоен номер ASN. Маршруты между AS распространяет BGP (Border Gateway Protocol) — протокол, на котором держится весь междоменный роутинг.

BGP-роутеры на границах AS обмениваются анонсами достижимости префиксов (например, «сеть 151.101.0.0/16 доступна через AS54113») и выбирают путь не по кратчайшей метрике, а по политикам: длина AS-path, local preference, коммерческие отношения (peering vs transit). BGP-анонсы и делают возможным Anycast из раздела про CDN: один префикс анонсируется из многих точек, и каждый узел выбирает ближайшую по своим политикам.

Уязвимость модели — доверие к анонсам: ошибочный или злонамеренный анонс чужого префикса (BGP hijack) уводит трафик не туда. Классика жанра — 2008 год, когда Pakistan Telecom, пытаясь заблокировать YouTube внутри страны, анонсировал его префикс на весь мир и уронил сервис глобально. Частичная защита — RPKI и фильтрация маршрутов. Внутри одной AS работают уже IGP-протоколы (OSPF, IS-IS), а BGP отвечает именно за стык между AS.

Сервер: от прерывания до приложения

Приём пакета: hardware interrupt и DMA

Когда пакет достигает NIC сервера, начинается обратный процесс. NIC получает электрические сигналы, декодирует их в биты, проверяет FCS и сравнивает destination MAC с собственным адресом.

При успешной проверке NIC через DMA копирует пакет из своей внутренней памяти в системную RAM, помещая его в receive ring buffer — кольцевой массив дескрипторов в kernel space, предварительно выделенный драйвером.

После завершения DMA-передачи NIC генерирует hardware interrupt (IRQ), сигнализируя CPU, что пакет готов к обработке. Прерывания сетевых карт бывают трёх типов: MSI-X, MSI и legacy interrupts. MSI-X предпочтительнее — позволяет назначить отдельное прерывание каждой receive queue, что улучшает параллелизм на многоядерных системах.

Обработка прерывания: ISR и переключение в ядро

При получении hardware interrupt процессор переключается в kernel mode и сохраняет состояние прерванного контекста — это смена уровня привилегий и сохранение регистров, а не обязательно полноценный context switch планировщика (тот меняет процесс и происходит отдельно). Процессоры поддерживают несколько privilege levels: Ring 0 (kernel mode) — полный доступ ко всем системным ресурсам, и Ring 3 (user mode) — доступ только к адресному пространству процесса.

При входе в ядро CPU сохраняет текущее состояние (program counter, stack pointer, регистры, flags). Затем загружается адрес interrupt handler (ISR) из interrupt vector table и начинается его выполнение.

Для сетевых карт ISR выполняет минимум работы: подтверждает прерывание, отключает дальнейшие прерывания от NIC и планирует обработку пакета на уровне softirq. Зачем отключать: если бы NIC продолжал генерировать hardware interrupt на каждый пакет при высоком трафике, система тратила бы всё CPU-время на обработку прерываний, не успевая фактически обрабатывать пакеты — явление, известное как interrupt storm или livelock.

NAPI и SoftIRQ: эффективная batch-обработка

Для решения проблемы interrupt overload в Linux используется механизм NAPI (New API). NAPI комбинирует interrupt-driven подход с polling: первый пакет генерирует прерывание, после чего драйвер переключается в режим polling для batch-обработки последующих.

ISR вызывает napi_schedule(), которая добавляет NAPI-структуру драйвера в список запланированных softirq и поднимает флаг NET_RX_SOFTIRQ. Softirq — механизм отложенной обработки в ядре, выполняющийся с приоритетом ниже hardware interrupts, но выше обычных процессов.

Softirq processing происходит в контексте ядра сразу после обработки hardware interrupts или при выходе из системного вызова. Softirq может выполняться параллельно на нескольких CPU — на этом держится масштабирование сетевой обработки. Для каждого CPU ядро поддерживает отдельную очередь softirq.

При выполнении NET_RX_SOFTIRQ вызывается net_rx_action(), которая обходит список NAPI-структур и вызывает poll() каждого драйвера. Poll-функция извлекает пакеты из receive ring buffer (до определённого budget — обычно 64 пакета), обрабатывает их и передаёт выше по стеку. Дальше — развилка, и её легко описать наоборот. Если драйвер разгрёб всё доступное до исчерпания budget, он вызывает napi_complete_done() и снова включает hardware interrupts от NIC. Если же budget исчерпан, а пакеты ещё остались, poll-функция возвращает ровно значение budget — NAPI не завершается и планируется повторно, оставаясь в режиме polling. Возвращаться к чисто interrupt-driven обработке в этот момент как раз не нужно: иначе под нагрузкой поток пакетов не разгрести.

Если сервер держит серьёзную нагрузку, тюнинг всего этого хозяйства (размеры очередей, backlog, TCP-параметры) делается через sysctl — по этому поводу есть отдельная шпаргалка.

RPS/RFS: распределение нагрузки по CPU

Для масштабирования на многоядерных системах Linux использует RPS (Receive Packet Steering) и RFS (Receive Flow Steering). RPS — программная реализация RSS (Receive Side Scaling), распределяющая обработку пакетов по разным CPU.

RPS вычисляет хэш от заголовков пакета (source/destination IP и port) и по нему выбирает целевой CPU из настроенного списка. Пакет помещается в per-CPU backlog queue этого CPU, и генерируется IPI (Inter-Processor Interrupt), чтобы разбудить обработку на удалённом CPU. Так все пакеты одного потока обрабатываются одним CPU — лучше cache locality.

RFS идёт дальше, пытаясь направить обработку пакета на тот же CPU, где работает приложение, принимающее эти данные. Данные с большой вероятностью уже в CPU cache — latency ниже.

Прохождение через network stack: от Ethernet к TCP

Извлечённый из ring buffer пакет представлен в ядре структурой sk_buff (socket buffer) — универсальной структурой для сетевых пакетов в Linux. Она содержит указатели на заголовки разных уровней и на сами данные, что позволяет передавать пакет между уровнями стека без копирования.

На канальном уровне (L2) ядро проверяет Ethernet-заголовок: сравнивает destination MAC с адресами локальных интерфейсов, проверяет FCS, извлекает EtherType.

На сетевом уровне (L3) вызывается ip_rcv(): проверяет версию, валидирует header length и total length, проверяет IP checksum и выполняет routing decision через lookup в routing table. Дальше развилка: если пакет предназначен локальной машине, он идёт в ip_local_deliver() и передаётся на транспортный уровень без уменьшения TTL. TTL/Hop Limit декрементируется не потому, что сервер принял пакет для локального сокета, а только на forwarding-пути (ip_forward()), когда узел пересылает пакет дальше — тогда и происходит уменьшение TTL (при TTL=0 пакет отбрасывается с ICMP Time Exceeded), пересчёт checksum и re-encapsulation. Здесь легко механически перенести операцию из forwarding path в общий receive path — но на приёме «для себя» её нет.

Перед передачей на транспортный уровень пакет проходит через Netfilter hooks — точки перехвата для firewall-правил (iptables/nftables), NAT и connection tracking. Именно здесь пакет может тихо умереть по правилу, которое кто-то накатил полгода назад — шпаргалка по iptables в помощь.

На транспортном уровне (L4) функция протокола (для TCP — tcp_v4_rcv()) проверяет TCP checksum, выполняет socket demultiplexing — поиск соответствующего сокета по 4-tuple (source IP, source port, destination IP, destination port), обновляет состояние TCP-соединения, обрабатывает TCP flags и помещает данные в socket receive buffer — очередь, из которой приложение будет читать.

Для TLS-соединений данные всё ещё зашифрованы на этом этапе и будут расшифрованы уже в user space приложением или TLS-библиотекой.

Load balancer: распределение перед web server

У крупного сайта пакет, дошедший до дата-центра, почти никогда не попадает напрямую на процесс web server — сначала он проходит через балансировщик нагрузки. Различают два уровня.

L4-балансировщик (транспортный) распределяет по IP и порту, не заглядывая в HTTP, и работает в двух режимах:

• proxy / in-line — весь трафик, туда и обратно, идёт через балансировщик, который терминирует TCP;
• DSR (Direct Server Return) — запрос приходит через LB, но ответ backend отправляет клиенту напрямую, минуя балансировщик, что снимает с него обратный (обычно куда более объёмный) трафик.

L7-балансировщик / reverse proxy (прикладной) терминирует TLS, читает HTTP и маршрутизирует по Host/path/cookie, обеспечивает sticky sessions, health checks, retry и circuit breaking (Nginx, HAProxy, Envoy, облачные ALB). Про то, как это настраивается в nginx, у меня есть пост про балансировку бэкендов, а про архитектуру в целом — про кластеризацию и доступность.

Алгоритмы распределения — round-robin, least connections, hash по IP или URL, weighted. За балансировщиком стоит пул backend-серверов, и уже выбранный экземпляр проходит путь «сокет → приложение». На практике перед origin выстраивается целая цепочка: CDN edge → L4 LB → L7 reverse proxy → web server → application server, и на каждом стыке возможны свои keep-alive пулы соединений и собственный слой кэширования.

Web Server: от сокета к приложению

Web server (Nginx, Apache) узнаёт о доступности данных через механизмы event notification: epoll (Linux), kqueue (BSD) или select/poll. Они позволяют мониторить тысячи сокетов одновременно и получать уведомления, только когда данные доступны для чтения или записи.

При получении события сервер вызывает recv() или recvmsg(), который копирует данные из kernel socket buffer в user space buffer приложения. Копирование пересекает границу kernel-user space, что стоит денег. Для минимизации существуют техники zero-copy (sendfile, splice).

Получив запрос, web server парсит его структуру: request line (метод, URI, версия HTTP), заголовки, опциональное тело.

Nginx использует асинхронную event-driven архитектуру с небольшим числом worker-процессов (обычно по одному на CPU core). Каждый worker обрабатывает множество одновременных соединений в одном потоке через non-blocking I/O и event loop. Так Nginx держит десятки тысяч соединений с минимумом памяти. Apache традиционно использовал prefork MPM, где каждый запрос обрабатывается отдельным процессом, или worker MPM с thread pool; современные версии поддерживают и event MPM, аналогичный nginx.

Дальше web server выполняет routing на основе конфигурации: для статических файлов читает файл с диска и отправляет клиенту, для динамического контента перенаправляет запрос к application server (PHP-FPM, Python WSGI, Node.js) через FastCGI, HTTP proxy или другие протоколы. Какой именно server block обработает запрос — определяется по заголовку Host, и это, кстати, частый источник сюрпризов, когда запрос улетает в дефолтный виртуалхост.

Обработка приложением и формирование ответа

Application server выполняет бизнес-логику: парсинг query-параметров и request body, валидацию и аутентификацию, обращения к базе, вызовы внешних API, рендеринг шаблонов, формирование ответа.

После обработки формируется HTTP response: status line (HTTP/1.1 200 OK), заголовки (Content-Type, Content-Length, Cache-Control, Set-Cookie), пустая строка-разделитель, тело ответа.

Cache-Control заголовки управляют кэшированием на стороне клиента и промежуточных proxy:

• Cache-Control: max-age=31536000, immutable — для статики с версионированием (CSS, JS с hash в имени);
• Cache-Control: no-cache — для ресурсов, требующих revalidation перед использованием;
• Cache-Control: no-store — для приватных данных, которые кэшировать нельзя вообще.

Response передаётся обратно через send() или sendfile() (для статических файлов), данные копируются в kernel space, TCP-стек сегментирует их, IP-стек инкапсулирует в пакеты, Ethernet-стек создаёт кадры. Пакеты помещаются в transmit ring buffer, NIC через DMA читает их и передаёт на физический уровень. Response идёт обратным путём через интернет к клиенту.

Браузер: рендеринг и отображение

Приём и парсинг HTTP response

Сервер ответил — мяч снова на стороне клиента. Response-пакеты проходят тот же путь: hardware interrupt, DMA в ring buffer, softirq, network stack, TCP reassembly — и попадают в socket buffer.

Браузерный network thread вызывает recv() для чтения данных. Response parser обрабатывает структуру: status line (200, 301, 404, 500), response headers (Content-Type определяет тип контента и способ парсинга, Content-Length — для прогресса загрузки, Transfer-Encoding: chunked — для streaming), тело — собственно HTML, CSS, JavaScript, изображения.

HTML Parsing и построение DOM

Получив HTML, браузер начинает parsing — преобразование текстового HTML в DOM (Document Object Model).

Процесс начинается с tokenization: парсер читает байты, декодирует их в символы согласно charset (обычно UTF-8), сканирует символы и выделяет токены — start tags (<div>), end tags (</div>), attributes (class="container"), text content, comments.

Из токенов строится DOM tree: открывающий тег создаёт новый node и становится текущим родителем, текстовое содержимое создаёт text node как дочерний, закрывающий тег возвращает контекст к родителю. DOM tree — иерархическая структура, где каждый HTML-элемент представлен объектом со свойствами, методами и связями parent-child-sibling.

«Стек тегов» — хорошая первая метафора, но реальный HTML-парсинг сложнее: это токенизатор с большим числом состояний, tree-construction algorithm с insertion modes, автоматическое исправление некорректной вложенности, foster parenting для таблиц, adoption agency algorithm для форматирующих тегов и особая обработка parser-inserted скриптов. Именно поэтому браузер способен превратить формально «кривой» HTML в стабильный DOM — иногда совсем не такой, как наивно ожидаешь по разметке.

Во время парсинга браузер обнаруживает ссылки на внешние ресурсы (CSS, JavaScript, images, fonts) и начинает их загрузку параллельно. Для этого используется preload scanner — лёгковесный парсер, который сканирует HTML на предмет ресурсов, не дожидаясь основного парсера.

CSS Parsing и CSSOM

Когда браузер встречает <link rel="stylesheet"> или <style>, он загружает CSS и начинает парсинг в CSSOM (CSS Object Model). CSS-парсер похож на HTML-парсер: tokenization, парсинг селекторов и правил, построение CSSOM tree, где каждый node представляет CSS rule с селектором и объявлениями свойств.

CSS блокирует рендеринг — но не любой. Браузер не будет отрисовывать страницу, пока не загрузит и не распарсит render-blocking стили из <head>. При этом стиль с неподходящим media-условием (скажем, media="print") или помеченный как некритичный первый render не блокирует. В целом это предотвращает FOUC (Flash of Unstyled Content), но замедляет initial render. Поэтому критический CSS инлайнят в <head>, а некритический загружают асинхронно.

JavaScript: выполнение и блокировка

JavaScript имеет особое влияние на парсинг и рендеринг — правда, не всякий скрипт одинаково. Классический parser-inserted <script> без async/defer действительно останавливает парсинг HTML: скрипт может манипулировать DOM (document.write(), создание/удаление элементов), и браузер не знает заранее, что он сделает, поэтому обязан дождаться выполнения. А вот async, defer, module-скрипты и динамически добавленные элементы ведут себя иначе — так что «каждый <script> тормозит парсер» тоже упрощение.

Процесс для блокирующего скрипта: браузер загружает его (если src внешний), компилирует JavaScript в байт-код или machine code (JIT в V8, SpiderMonkey, JavaScriptCore), выполняет, и только после этого возобновляется HTML-парсинг.

Для оптимизации используются атрибуты:

• async — скрипт загружается параллельно и выполняется, как только загрузится, не блокируя парсинг загрузкой (но само выполнение всё равно приостанавливает парсер и не сохраняет порядок относительно соседних async-скриптов);
• defer — скрипт загружается параллельно, но выполняется только после полного парсинга HTML, перед событием DOMContentLoaded;
• module-скрипты по умолчанию ведут себя близко к defer.

Render Tree и Layout

После построения DOM и CSSOM браузер объединяет их в Render Tree — структуру, содержащую только видимые элементы с их вычисленными стилями. Render Tree не включает элементы с display: none, <head>, <script> и другие невидимые nodes.

Следующий этап — Layout (reflow), где браузер вычисляет точное положение и размеры каждого элемента: расчёт box model (content, padding, border, margin), применение positioning (static, relative, absolute, fixed, sticky), вычисление flexbox и grid, обработку text flow и word wrapping.

Layout — дорогая операция, особенно на сложных страницах. Изменения, влияющие на layout (resize, изменение font-size, добавление/удаление элементов), вызывают reflow всего дерева или его части.

Painting и Compositing

После Layout следует Paint — но, вопреки распространённому упрощению, это ещё не превращение элементов в пиксели. На стадии Paint браузер лишь строит список команд рисования (paint records / display list): «залить фон», «нарисовать границу», «вывести текст», «наложить тень», применить эффекты (box-shadow, border-radius). Сами пиксели тут ещё не заполняются — Chromium это прямо подчёркивает.

Отдельная стадия — rasterization (растеризация): она исполняет эти команды по тайлам и превращает их в пиксели. Происходить она может позже и на других потоках, включая GPU raster threads. Именно поэтому paint и rasterization — разные этапы, а не одно и то же.

Дальше — compositing: разделение страницы на слои (layers) и отдельный рендеринг каждого. Элементы с transform, opacity, position: fixed, will-change часто создают отдельные слои. Compositing слоёв делает GPU — отсюда плавные анимации и скроллинг.

Финальный этап — presentation (display): скомпозированный кадр отправляется в графический буфер, который выводится на экран. Условно вся цепочка выглядит так: style calculation → layout → paint / display lists → rasterization → compositing → presentation, причём последующие изменения могут инвалидировать лишь часть стадий, а не пересчитывать всю страницу.

Event Loop и Rendering Pipeline

Браузерный Event Loop координирует выполнение JavaScript и рендеринг. Цикл работает так: из task queue (macrotask queue) берётся одна задача (timer callbacks, I/O, events), задача выполняется до завершения, затем полностью обрабатывается microtask queue (Promise callbacks, MutationObserver), после чего проверяется, нужно ли рендерить.

Важно, что момент обновления экрана (rendering opportunity) возникает отдельно от обработки задач и не привязан к жёсткому периоду. 16,67 мс — это длительность кадра при 60 Гц, а не фиксированный «такт» event loop: возможность обновить картинку зависит от частоты экрана, видимости вкладки, производительности страницы, throttling и наличия визуальных изменений. Стандарт HTML вообще не требует конкретного алгоритма выбора момента рендера — браузер вправе пропускать обновления или перейти, например, к 30 Гц. Если момент рендера подошёл: выполняются requestAnimationFrame callbacks, при необходимости пересчитываются Layout, Paint, rasterization и Compositing.

Если JavaScript-задача выполняется слишком долго (long task > 50 мс), она блокирует Event Loop — рендеринг не происходит, страница перестаёт отвечать. Поэтому тяжёлые операции разбивают на chunks, а фоновые вычисления уносят в Web Workers.

Ключевые прерывания и системные вызовы

Путь пройден целиком — теперь шпаргалка: соберём в одном месте всё, что по дороге дёргало ядро.

Hardware Interrupts

За время открытия сайта hardware interrupts случаются постоянно: keyboard interrupts при вводе URL, network interrupts (IRQ) при приёме/отправке пакетов, timer interrupts — для preemptive multitasking.

Каждое прерывание вызывает вход в обработчик с сохранением и восстановлением состояния CPU и выполнением ISR — но не обязательно полноценный context switch планировщика (смена процесса — отдельное событие). Частые прерывания всё равно создают overhead, поэтому применяют interrupt coalescing (группировка нескольких событий в одно прерывание) и NAPI polling для batch-обработки.

Software Interrupts (SoftIRQ)

Softirq — механизм отложенной обработки в ядре. Основные типы для сети: NET_RX_SOFTIRQ для приёма пакетов (обработка receive ring buffer, передача пакетов вверх по стеку) и NET_TX_SOFTIRQ для отправки (завершение передачи, освобождение буферов).

Softirq выполняются в kernel context на высоком приоритете, но ниже hardware interrupts. Они могут прерывать user processes, но не могут прерывать hardware interrupt handlers.

System Calls

System calls — интерфейс между user space и ядром:

Каждый system call вызывает переключение из user mode в kernel mode: процессор переходит в Ring 0, выполняет операцию в kernel space, копирует результаты обратно в user space и возвращается в Ring 3. Это не полноценный context switch планировщика и не обязательно полный TLB flush: на x86 с включённым Page Table Isolation вход в ядро может сопровождаться сменой таблиц страниц и лишней работой с TLB, но зависит это от архитектуры, поддержки PCID и включённых защит от уязвимостей — универсального правила «syscall → полный TLB flush» нет. Но и «дешёвыми» эти переключения не назвать, поэтому оптимизация часто сводится к минимизации числа system calls. Посмотреть, что именно процесс дёргает у ядра, можно через strace — очень отрезвляющее упражнение.

Что с этим делать на практике

Главная ценность этой карты не в том, чтобы пересказать её на собеседовании, а в том, чтобы по симптому сразу понимать, на каком этаже искать. Вот примерное соответствие:

Эта же карта работает и в обратную сторону — когда систему надо не чинить, а спроектировать: примерно так я разбирал задачку с собеса про высоконагруженный сервис.

Порядок диагностики — сверху вниз по стеку, а не наугад: сначала убеждаешься, что имя резолвится, потом что соединение устанавливается, потом что сервер отвечает, и только потом лезешь в приложение. Половина «загадочных» инцидентов разваливается уже на первых двух шагах.

Тонкие места, на которых легко споткнуться

• ICMP не «лишний трафик». Заблокировав его целиком «для безопасности», ты ломаешь Path MTU Discovery и получаешь соединения, которые устанавливаются, но зависают на крупных ответах. Симптом максимально неочевидный.
• TTL кэша DNS живёт дольше, чем ты думаешь. Между твоим изменением записи и реальным переключением трафика стоят кэши браузера, ОС, резолвера провайдера и промежуточных нод. Снижай TTL заранее, до миграции, а не в момент.
• HSTS липкий, но не необратимый. Отдал заголовок с большим max-age — и браузеры пользователей будут ходить только по HTTPS всё это время, даже если у тебя сломался сертификат. Обычную динамически полученную политику можно снять, прислав Strict-Transport-Security: max-age=0; а вот попадание в browser preload list — это уже надолго и откатывается медленно. Тестируй с маленьким max-age.
• 301 прилипает надолго. Permanent-редирект браузеры кэшируют агрессивно (иногда эвристически, без явного срока), и ошибочный 301 потом тяжело выковырять из кэшей пользователей — управлять им со своей стороны уже почти нельзя. Пока не уверен — отдавай 302.
• Первые ~14 КБ дешевле остального. Из-за initial window (обычно 10 сегментов) первая порция ответа приходит за один round-trip, а всё сверх того требует дополнительных RTT на «раскачку». Это грубая performance-интуиция, а не физический закон: размер считается в сегментах и зависит от MSS, на уже прогретом соединении cwnd другой, а QUIC вообще использует свой congestion control. Но вывод практичен: критический CSS в <head> — не мода, а арифметика.
• HTTP/2 не лечит потери пакетов. Мультиплексирование в одном TCP-соединении означает, что одна потеря тормозит все streams разом. На плохих каналах HTTP/2 может оказаться хуже HTTP/1.1 с несколькими соединениями — вот от этого и лечит QUIC.
• Каждый редирект — это RTT. Цепочка http → https → www на мобильном канале с RTT 150 мс стоит почти полсекунды ещё до того, как придёт первый байт HTML.
• Эфемерные порты кончаются. На балансировщике или прокси с большим числом исходящих соединений диапазон net.ipv4.ip_local_port_range и TIME_WAIT становятся реальным потолком. Проявляется внезапно и под нагрузкой.

Заключение

От первого hardware interrupt до последнего пикселя — каждый этап этого пути вылизан десятилетиями инженерной работы. Но полезен он не как энциклопедическая справка, а как карта для дебага: когда понимаешь, где живут DNS resolution, TLS handshake, softirq и reflow, «сайт тормозит» перестаёт быть магией. У каждой проблемы появляется конкретный этаж, на котором её надо искать: где-то поможет tcpdump, где-то — вкладка Performance в DevTools, а где-то — просто нормальный мониторинг, который покажет проблему до того, как о ней напишут в поддержку.

Если хочется превратить эту карту в план обучения, а не в разовое чтение, — те же этажи разложены по уровням и ожиданиям от инженера в листах Networking и Operating Systems карты компетенций.

И в следующий раз, когда страница откроется «мгновенно», ты будешь знать, сколько всего успело случиться за эти пару сотен миллисекунд.