Лекция «Инфраструктура как код — описание, дрейф и цена ручной правки»

Около 70 минут на 17 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 49 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Семнадцать тем про то, как изменение попадает в инфраструктуру. Дрейф конфигурации по определению Фаулера — это не расхождение сред, а разовые изменения, которые нигде не записаны; источников у него два, и автоматический труднее обнаружить, потому что у изменения нет ни автора, ни задачи, ни момента решения. Обещать полное устранение дрейфа нельзя: Моррис пишет, что полная согласованность существующими средствами недостижима, Фаулер — что неизменяемый сервер оставляет простор для дрейфа, DORA — что идеальной воспроизводимости у сложной системы не бывает, потому что у любой реальной системы есть состояние. Три публичных разбора показывают обе стороны: Salesforce 11.05.2021 — пятичасовой отказ после экстренной ручной правки DNS, где ступенчатость осталась на усмотрение исполнителя; Datadog 08.03.2023 — пять регионов у трёх провайдеров и 50–60% боевых узлов Kubernetes, потерявших связность из-за оставшегося включённым канала обновлений в базовом образе с окном 06:00–07:00 UTC; Atlassian 05.04.2022 — скрипт с ревью и успешным прогоном на 30 сайтах, удаливший 883 сайта 775 клиентов за 23 минуты, причём безвозвратно и вместе с контактными данными. Отсюда честная формулировка: автоматизация не уменьшает вероятность ошибки, она уменьшает разброс и ускоряет последствия, а платят за это предохранителями — мягким удалением, ограниченным прогоном и проверенным откатом. Ревью инфраструктурной правки читает план, а не намерение: спор идёт о списке «уничтожить» и «уничтожить и создать заново», флаг отключения синхронизации состояния делает дрейф невидимым, а prevent_destroy исчезает вместе с удалённым блоком ресурса, потому что в состоянии это правило не хранится. Файл состояния и сохранённый план — секреты: документация требует держать состояние вне Git, а пометка sensitive скрывает значение из вывода, но не шифрует его в состоянии. Российский слой: пункт 18.4 приказа ФСТЭК № 17 требует перечня объектов, анализа воздействия, санкционирования, документирования и контроля — ровно того, что делает конвейер; аттестат с 27.09.2019 выдаётся на весь срок эксплуатации, а не на три года; УКФ.1 в приказе № 21 и в приказе № 239 — разные меры под одним шифром. Заканчивается лекция списком формулировок, которые повторять нельзя, — от «код предотвращает аварии» до вендорских процентов, выданных за отраслевой замер.

Нет, и это не придирка к формулировке. Киф Моррис в заметке 2013 года описывает механику честно: инструмент периодически переприменяет описание, и изменение, сделанное мимо него, откатывается к централизованно заданной конфигурации. А следующим абзацем — ограничение: «In practice, however, it isn't feasible to keep servers completely consistent using current automated configuration management tools, so over time configuration synchronization leads to inconsistency». Причины названы конкретно: каждый управляемый элемент требует написать, протестировать и поддерживать рецепт; элементов на типовом сервере слишком много; трудоёмкость растёт нелинейно из-за зависимостей; пакетные менеджеры сами дотягивают зависимости, поэтому большая часть пакетов управляется лишь неявно и может измениться без предупреждения. Фаулер добавляет то же самое про неизменяемые серверы: полностью управлять конфигурацией на практике невозможно, простор для дрейфа остаётся. DORA формулирует предел общей фразой: «impossible to achieve perfect reproducibility and traceability for a complex enterprise system (at a minimum, every real system has state)». Корректный доклад звучит иначе: доля неописанных элементов сокращена до такой-то, расхождение с описанием стало обнаруживаемым, сверка идёт с такой-то периодичностью. Это проверяемые утверждения, а «дрейф устранён» — нет.

План, и в нём — строки со знаком «уничтожить» и «уничтожить и создать заново». Дифф описания показывает намерение автора, план показывает последствия, и расходятся они чаще всего именно на удалениях. Отдельно проверьте, не был ли у удалённого ресурса защитный мета-аргумент: правило prevent_destroy отвергает планы, уничтожающие объект, но документация HashiCorp прямо оговаривает — «This rule doesn't prevent Terraform from destroying a resource if you remove its configuration». Правило не записывается в состояние (кроме create_before_destroy), поэтому вместе с удалённым блоком исчезает и защита, а план покажет уничтожение и не возразит. Ещё две вещи, которые видно только в плане и не видно в диффе: флаг отключения синхронизации состояния, при котором Terraform игнорирует внешние изменения и план может оказаться неполным или неверным, и возраст самого плана — документация требует перед применением заново проверить окончательный, не спекулятивный план, потому что за время согласования систему мог изменить кто-то ещё.