1. Инфраструктура как код для SRE: Декларативный подход к развертыванию мониторинга
В 03:00 ночи система мониторинга перестает отвечать. Основной сервер Prometheus недоступен из-за аппаратного сбоя в дата-центре. Дежурный SRE-инженер открывает документацию (Runbook), находит раздел «Восстановление мониторинга» и видит инструкцию: поднять новую виртуальную машину, склонировать репозиторий и запустить setup.sh. Скрипт падает на третьей минуте с ошибкой package libssl1.1 has no installation candidate. Выясняется, что полгода назад другой инженер обновил версию ОС на сервере мониторинга вручную, чтобы установить новый экспортер, но забыл обновить bash-скрипт в репозитории. Восстановление системы, которое должно было занять пять минут, превращается в многочасовое расследование и ручную сборку сервера по кускам.
Эта ситуация — классическое следствие управления инфраструктурой через ручные изменения и императивные скрипты. Переход к концепции Service-Oriented мониторинга, где надежность является главной фичей, невозможен, если сам инструмент контроля надежности (система мониторинга) разворачивается нестабильно.
Инфраструктура как код (Infrastructure as Code, IaC) решает проблему воспроизводимости, превращая серверы, сети, дашборды и правила алертинга в версионируемый текстовый код.
Проблема «Снежинок» и дрейф конфигурации
В традиционном системном администрировании серверы часто становятся «Снежинками» (Snowflake servers). Это серверы, которые настраивались вручную на протяжении долгого времени. Каждый такой сервер уникален: никто в компании точно не знает, какие пакеты на нем установлены, какие переменные окружения прописаны в /etc/profile и почему база данных работает только если запустить ее от имени конкретного пользователя.
В контексте стека мониторинга сервер-снежинка — это критическая уязвимость. Если конфигурация Prometheus (prometheus.yml) правится прямо на сервере через vim для быстрого добавления нового scrape-таргета, сервер теряет связь со своим эталонным состоянием.
Этот процесс называется дрейфом конфигурации (Configuration Drift).
!Дрейф конфигурации сервера мониторинга
Дрейф конфигурации — это постепенное расхождение между задокументированным (или заскриптованным) состоянием системы и ее реальным состоянием в production. Он возникает из-за:
chmod 777 на директорию с метриками TSDB).Когда происходит сбой, дрейф конфигурации делает невозможным быстрое восстановление. Инженер восстанавливает систему из кода, но она не работает так, как работала вчера, потому что код устарел на сотни невидимых ручных правок.
Императивный против декларативного подхода
Попытки автоматизировать настройку серверов часто начинаются с написания bash-скриптов. Это императивный подход. Императивный код описывает как достичь результата: шаг за шагом.
Пример императивной логики настройки Alertmanager:
alertmanager./usr/local/bin.Слабость императивного подхода в том, что он слеп к текущему состоянию системы. Что если скрипт запустить второй раз? Команда создания пользователя вернет ошибку user already exists, и скрипт прервется. Что если архив скачался наполовину из-за обрыва сети? Распаковка завершится сбоем. Чтобы сделать императивный скрипт надежным, инженеру приходится писать сотни проверок: if ! id -u alertmanager > /dev/null 2>&1; then useradd.... Скрипт разрастается, становится хрупким и нечитаемым.
Декларативный подход, лежащий в основе современных IaC-инструментов (Terraform, Ansible, Kubernetes), работает иначе. Он описывает конечное желаемое состояние (What), а не шаги по его достижению (How).
Декларативная логика выглядит так:
alertmanager./usr/local/bin должен лежать бинарный файл версии 0.25.0.IaC-инструмент сам опрашивает систему, вычисляет разницу (дельта) между текущим и желаемым состоянием, и выполняет только те действия, которые необходимы для устранения этой разницы. Если пользователь уже существует, инструмент просто перейдет к следующему пункту.
Идемпотентность: математика надежных деплоев
Фундаментальное свойство декларативного подхода, делающее его пригодным для SRE — это идемпотентность.
В математике операция идемпотентна, если многократное ее применение к объекту дает тот же результат, что и однократное: .
В контексте инфраструктуры идемпотентность означает, что вы можете применять один и тот же конфигурационный код к серверу 1, 10 или 100 раз подряд, и после первого успешного выполнения состояние системы не изменится. Никаких дубликатов данных, никаких ошибок «уже существует», никаких перезапусков служб без необходимости.
!Идемпотентность при сбоях в пайплайне
Почему это критически важно при развертывании мониторинга? Представьте развертывание сложного стека: создание VPC в облаке, поднятие трех виртуальных машин, установка Prometheus, настройка кластера Alertmanager и загрузка 50 дашбордов в Grafana.
Если на этапе загрузки 49-го дашборда отвалится сеть, пайплайн CI/CD упадет. В императивной парадигме перезапуск пайплайна — это катастрофа. Скрипт попытается заново создать уже существующие виртуальные машины (получив ошибку от облачного провайдера) или добавит дублирующие записи в конфигурационные файлы. Инженеру придется вручную «чистить» инфраструктуру перед повторным запуском.
В парадигме идемпотентного IaC вы просто нажимаете кнопку «Re-run». Инструмент проверит облако: «Машины есть, пропускаем. Prometheus установлен, пропускаем. Дашборды 1-48 на месте, пропускаем. Дашбордов 49-50 нет — загружаем». Идемпотентность превращает восстановление после частичных сбоев из сложной инженерной задачи в рутинную операцию.
Разделение зон ответственности: Terraform и Ansible
Для развертывания стека мониторинга редко используется только один инструмент. Отраслевой стандарт — это связка Terraform и Ansible. Они не заменяют, а органично дополняют друг друга, работая на разных уровнях абстракции.
Terraform: Управление неизменяемой инфраструктурой
Terraform — это инструмент для провижининга (создания) ресурсов. Он общается с API облачных провайдеров (AWS, GCP, Яндекс.Облако) или гипервизоров (VMware, Proxmox).
Его зона ответственности — «железо» (пусть и виртуальное) и сеть.
grafana.company.internal).Terraform использует концепцию состояния (State). Он хранит файл terraform.tfstate (обычно в удаленном хранилище, например S3), в котором записано соответствие между вашим кодом и реальными ID ресурсов в облаке. Когда вы меняете код (например, увеличиваете размер диска с 50 ГБ до 100 ГБ), Terraform сравнивает код со State-файлом, вычисляет план изменений (terraform plan) и показывает вам, что именно будет сделано, до фактического применения (terraform apply).
Terraform тяготеет к парадигме неизменяемой инфраструктуры (Immutable Infrastructure). Если базовый образ ОС (AMI) устарел, Terraform не будет подключаться к серверу и обновлять пакеты. Он уничтожит старую виртуальную машину и создаст новую из свежего образа, переподключив к ней диск с данными метрик.
Ansible: Управление конфигурациями внутри ОС
Если Terraform строит дом, то Ansible занимается внутренней отделкой. Ansible подключается к уже созданным виртуальным машинам по протоколу SSH и настраивает операционную систему и приложения.
Его зона ответственности — конфигурация ПО.
prometheus.yml, alertmanager.yml) на основе шаблонов (Jinja2).Ansible работает в парадигме изменяемой инфраструктуры (Mutable Infrastructure). Он не пересоздает сервер целиком, чтобы поменять одну строчку в конфиге. Он подключается по SSH, находит нужный файл, вносит изменения и отправляет команду systemctl reload prometheus.
| Характеристика | Terraform | Ansible | | :--- | :--- | :--- | | Основная задача | Создание ресурсов (Provisioning) | Настройка ПО (Configuration Management) | | Уровень работы | API облака / гипервизора | Внутри гостевой ОС (по SSH) | | Хранение состояния | Обязательно (State-файл) | Не требует State-файла (проверяет факты на лету) | | Язык описания | HCL (HashiCorp Configuration Language) | YAML | | В контексте мониторинга | Создает VM, диски для TSDB, балансировщики сети | Ставит Prometheus, шаблонизирует правила алертинга |
Синергия инструментов на практике
Процесс развертывания выглядит как эстафета. Сначала запускается Terraform. Он создает виртуальную машину и генерирует динамический файл инвентаризации (Inventory) — список IP-адресов созданных серверов.
Затем этот Inventory передается в Ansible. Ansible идет по этим IP-адресам и превращает «голые» Linux-машины в готовый к работе стек мониторинга.
Такое разделение защищает от катастрофических ошибок. Если бы мы пытались конфигурировать сложные правила маршрутизации метрик внутри Terraform (через remote-exec скрипты), мы бы потеряли идемпотентность и читаемость. Если бы мы пытались создавать облачные сети через Ansible (хотя у него есть такие модули), мы бы столкнулись с отсутствием State-файла, из-за чего Ansible не смог бы корректно удалять старые ресурсы при изменении архитектуры.
Monitoring as Code: Дашборды и алерты тоже код
Распространенная ошибка команд, начинающих внедрять IaC — автоматизировать только серверы, оставляя настройку самой логики мониторинга ручной.
Инженер разворачивает Grafana через Ansible, заходит в веб-интерфейс, вручную накликивает красивый дашборд с графиками задержки (Latency) и трафика (Traffic), сохраняет его и идет пить кофе. Через месяц кто-то случайно удаляет панель на дашборде. Вернуть ее невозможно — истории изменений нет.
Концепция IaC требует, чтобы всё было кодом. Это подход Monitoring as Code (MaC).
prometheus.yml с актуальным списком таргетов.prometheus.rules. Изменение порога проходит через обязательное ревью кода другим инженером (Code Review). Это исключает ситуацию, когда дежурный ночью «заглушил» раздражающий алерт, изменив порог в интерфейсе, и забыл вернуть его обратно, из-за чего на следующий день компания пропустила реальный инцидент.GitOps как эволюция IaC для SRE
Когда инфраструктура, конфигурация ОС и сама логика мониторинга описаны в виде идемпотентного кода, открывается путь к GitOps.
GitOps — это методология, при которой Git-репозиторий становится единственным источником истины (Single Source of Truth) для системы.
При традиционном подходе SRE-инженер запускает terraform apply или ansible-playbook со своего ноутбука. Это порождает проблему: версия кода на ноутбуке инженера может отличаться от версии в ветке main в репозитории.
В модели GitOps люди вообще не имеют доступа к серверам мониторинга и не запускают команды применения. Процесс выглядит так:
main, автоматизированный агент (CI/CD пайплайн или специализированный оператор) замечает изменение в Git.Если кто-то попытается зайти на сервер по SSH и вручную поменять конфигурацию (создав дрейф), при следующем запуске агент GitOps обнаружит расхождение между сервером и Git-репозиторием, и принудительно перезапишет ручные изменения, вернув систему к эталонному состоянию.
Внедрение декларативного подхода и идемпотентных инструментов полностью меняет фокус работы SRE. Инженеры перестают быть администраторами конкретных серверов, которые нужно чинить и поддерживать. Сервер мониторинга становится расходным материалом, эфемерной сущностью. Ценность переносится с физического или виртуального железа на код, который способен это железо воссоздать с нуля за считанные минуты в любой точке мира.