Описание, которое исполняется
Есть сервер, который работает. Никто не помнит, почему на нём стоит именно эта версия пакета, кто открыл порт и откуда взялся файл в /etc с правкой от прошлого дежурства. Пока он работает, это не проблема. Проблема начинается в тот момент, когда его надо повторить: поднять такой же во втором регионе, восстановить после отказа железа, показать проверяющему, из чего он собран.
Эта лекция — про подход, в котором состояние инфраструктуры задаётся описанием в репозитории, а не последовательностью действий в консоли. Разбираются четыре вещи: чем описание отличается от документации, что такое дрейф конфигурации и почему его нельзя устранить полностью, как читается план изменения на ревью и почему файл состояния — секрет. Отдельно — российский регуляторный слой: приказы ФСТЭК требуют ровно того, что инженерная практика называет управлением конфигурацией.
Обещания, что описанная кодом инфраструктура избавит от аварий. Один из трёх разобранных кейсов — скрипт, прошедший ревью и успешный предыдущий прогон, который уничтожил данные 775 клиентов за 23 минуты. Подход меняет не вероятность ошибки, а её воспроизводимость, проверяемость до применения и скорость наступления последствий.
- Термины и их первоисточники: снежинка, феникс, дрейф, идемпотентность, GitOps.
- Три публичных разбора аварий: Salesforce (11.05.2021), Datadog (08.03.2023), Atlassian (05.04.2022).
- Ревью инфраструктурной правки: язык плана, флаг, которым дрейф делается невидимым, и самая опасная строка диффа.
- Состояние: что в нём лежит, почему пометка «чувствительное» его не защищает.
- Приказы ФСТЭК № 17, № 21 и № 239: требования к управлению конфигурацией и ловушка нумерации мер УКФ.
Уровень — advanced. Конвейер, репозиторий и инструменты автоматизации предполагаются знакомыми: объясняется не то, что такое ревью, а то, что именно в инфраструктурной правке подлежит проверке и чего в ней не видно глазами.
Снежинка, феникс и улица между ними
10 июля 2012 года Мартин Фаулер опубликовал в своём bliki две заметки в один день. Первая описывает то, что есть почти в каждой стойке, вторая — то, чем это лечится.
Сервер, который поддерживают «смесью команд в консоли, переходов по экранам графического интерфейса и правки текстовых файлов». Результат Фаулер называет дословно: «уникальная снежинка: хорошо для горнолыжного курорта, плохо для дата-центра».
Первая проблема снежинки названа прямо: её трудно воспроизвести.
- При отказе железа тяжело поднять такой же сервер.
- В кластере тяжело держать узлы синхронными.
- Нельзя повторить боевую среду для тестирования.
Вторая заметка — про феникс: «Сервер должен быть как феникс, регулярно восстающий из пепла». Термин придумал коллега Фаулера Корнелис Сицма во внутренней рассылке. Главное преимущество названо там же и оно одно: избежать дрейфа конфигурации.
Фаулер на странице PhoenixServer: дрейф это «ad hoc changes to a systems configuration that go unrecorded» — не записанные нигде разовые изменения конфигурации системы. И там же: «Drift is the name of a street that leads to SnowflakeServers» — дрейф это улица, ведущая к серверам-снежинкам.
Ключевое слово в определении — unrecorded, не записанные. Дрейф это не «конфигурация отличается от идеала» и не «стенд не похож на бой». Дрейф — это изменение, которого нет ни в одном описании, и потому оно не воспроизводится и не отменяется.
Ночью на дежурстве кто-то правит конфигурацию руками, чтобы поднять сервис. Утром правка остаётся на машине и нигде больше. У неё есть автор, время и, как правило, след в истории команд — обнаружить её можно.
Изменение приносит не человек, а механизм, о котором забыли: канал обновлений в базовом образе, пакетный менеджер, дотянувший зависимость, фоновая служба. Автора нет, задачи нет, времени принятия решения нет. Это труднее заметить именно потому, что искать некого.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.