Контроль версий конфигураций

1) Зачем версионировать конфигурации

Конфигурация — это исполняемая политика: она определяет маршрутизацию, лимиты, фич-флаги, доступы, схемы данных. Контроль версий делает изменения повторяемыми, обозримыми и обратимыми: сокращает MTTR и change-failure rate, избавляет от “магии в проде”, дает аудит для безопасности и комплаенса.

2) Таксономия конфигураций

Инфраструктурная (IaC): кластеры, сети, LB, БД, очереди.
Сервисная: параметры приложений, ресурсы, лимиты, таймауты, ретраи.
Продуктовая/бизнес-логика: тарифы, AB-эксперименты, контент-правила.
Данные/DataOps: контракты схем, SLA свежести, трансформации.
Безопасность: политики доступа, роли, ключи/сертификаты (сами секреты — вне репо).
Наблюдаемость: SLI/SLO, алерты, дашборды.

Правило: все, что влияет на поведение системы, — конфигурация и должно жить под версионированием.

3) Принципы управления версиями

1. GitOps: единственный источник истины — репозиторий; изменения через PR и автоматические пайплайны.
2. Декларативность: описание целевого состояния, а не скрипты шагов.
3. Иммутабельность артефактов: конфиг → однозначно материализуемый снапшот.
4. Схемы и валидация: JSON/YAML-schema, строгое приведение типов, обязательные поля.
5. Среды как код: `env` — папки/оверлеи (dev/stage/prod), разницы минимальны и явны.
6. Идемпотентность и откаты: любой релиз конфигурации обратим (revert/rollback).
7. Аудит и трассируемость: автор, причина, тикет/RFC, подписи изменений.

4) Стратегии версионирования

• MAJOR — несовместимые изменения схем/политик.
• MINOR — новые поля/правила, обратная совместимость.
• PATCH — исправления значений без изменения схем.
• Tag-релизы и release notes: что изменено, как откатиться, контрольные точки.
• Pinning/lock-файлы: фиксируем версии зависимостей (модули, чарты).
• Matrix версий: артефакт приложения X совместим с конфигом Y (матрица в каталоге сервиса).

5) Организация репозитория

config-repo/
policies/     # общие политики (RBAC, SLO, алерты)
services/
checkout/
schema/    # JSON/YAML схемы конфигов base/     # дефолтные значения overlays/
dev/
stage/
prod/
data-contracts/  # схемы данных, SLA свежести releases/     # теги, changelog, артефакты валидации tools/      # линтеры, генераторы, тесты

Ветка: trunk-based (main) + короткие feature-ветки. Мерж — только через PR с обязательным CI.

6) Валидация и тестирование

Схема: каждое изменение проходит проверку схемы (required, enum, ranges).
Статические линтеры: формат, ключи, дубли, запрещенные поля.
Тесты совместимости: конфиг + версия сервиса/чарта поднимаются в песочнице.
Контрольные прогонки: dry-run применений, “what-if” дифф целевого состояния.
Политики-as-code: правила допуска (Rego/CEL) — кто и что может менять.

7) Раскат и откат конфигураций

Progressive delivery: канарейка 1%→5%→25% с SLO-гардрейлами.
Гейт деплоя: нет активных SEV-1, алерты зеленые, подписи валидны, откат готов.
Откат: `revert tag vX.Y.Z` или переключение на предыдущий снапшот; команды отката документированы в runbook.
Аннотации релиза: версия конфига публикуется в метриках/логах, чтобы быстро коррелировать с инцидентами.

8) Динамическая и удаленная конфигурация

Remote config/feature flags: изменяем параметры без рестартов; все флаги — тоже под GitOps.
Границы: какие параметры разрешено менять динамически (перечень белых списков).
Кэш и консистентность: TTL, версии, атомарная замена наборов (двухфазная публикация).
Безопасные перила: лимиты и диапазоны для runtime-изменений, авто-rollback при выходе за SLO.

9) Секреты и чувствительные данные

Никогда не храним секреты в репо. В конфигурациях — только ссылки/плейсхолдеры.
Шифрование файлов конфигов при необходимости: интеграция с менеджером секретов/ключей.
Ротация и JIT: доступы выдаются на время операций; след действий неизменяем.
Полевая маскировка: валидация запрещает попадание PII/секретов в конфиг.

10) Управление окружениями

Base + overlays: различия между dev/stage/prod минимальны и прозрачны.
Promotion по артефактам: тот же снапшот, который прошел stage, продвигается в prod.
Временные окна: изменения конфигов не происходят в момент смены дежурства; для risk-high — RFC и окно обслуживания.

11) Обнаружение и устранение дрейфа

Контроллер сравнивает целевое состояние с фактическим и репортит дифф.
Drift-алерты: Page только при критических расхождениях; остальные — Ticket.
Авто-ремедиация: при разрешении — возврат к целевому состоянию.
Аудит ручных правок: любые “kubectl edit/ssh” → инцидент процесса и CAPA.

12) Каталог конфигураций и владение

Каталог сервиса: владелец, SLO, связанные политики, схемы, версии, совместимость.
RACI: кто предлагает, кто ревьюит, кто одобряет; CAB для high-risk.
Прозрачность: каждая запись имеет историю версий и ссылки на PR/тикеты/AAR.

13) Метрики зрелости

Coverage: % сервисов/политик под GitOps (цель ≥ 95%).
Lead time конфиг-изменений: медиана от PR до прод.
Change failure rate: доля конфиг-релизов с откатом/инцидентом.
Drift rate: количество расхождений/неделя и время устранения.
Rollback time: медиана восстановления к предыдущей версии.
Audit completeness: доля изменений с полным evidence (валидаторы, dry-run, отзывы).

14) Чек-листы

Перед изменением конфигурации

• Есть тикет/RFC и владелец изменения.
• Пройдена валидация схем и линтеров.
• Есть план отката и команды в runbook.
• Гейт: тесты зеленые, подписи валидны, нет активных SEV-1.
• Для high-risk — назначено окно обслуживания.

Во время раската

• Канарейка и SLO-гардрейлы активны.
• Публикуются аннотации версии.
• Есть эхо-сообщения в канал; алерт-шум подавлен по правилам MW.

После

• Observation window пройден, SLO зеленый.
• Итоги и evidence (графики до/после, dry-run отчеты) приложены к тикету.
• Обновлены схемы/документация при необходимости.

15) Мини-шаблоны

15.1 Схема конфигурации (YAML-schema, фрагмент)

yaml type: object required: [service, timeouts, retries]
properties:
service: { type: string, pattern: "^[a-z0-9-]+$" }
timeouts:
type: object properties:
connect_ms: { type: integer, minimum: 50, maximum: 5000 }
request_ms: { type: integer, minimum: 100, maximum: 20000 }
retries:
type: object properties:
attempts: { type: integer, minimum: 0, maximum: 10 }
backoff_ms: { type: integer, minimum: 0, maximum: 5000 }

15.2 Базовый конфиг + оверлей prod

yaml services/checkout/base/config.yaml service: checkout timeouts: { connect_ms: 200, request_ms: 1500 }
retries: { attempts: 2, backoff_ms: 200 }
limits:  { rps: 500 }
features:
degrade_search: false psp_a_weight: 80 psp_b_weight: 20

yaml services/checkout/overlays/prod/config.yaml limits:  { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 30

15.3 Политика допуска (идея)

yaml allow_change_when:
tests: passed schema_validation: passed active_incidents: none_of [SEV-0, SEV-1]
rollback_plan: present signed_by: ["owner:team-checkout","platform-sre"]

15.4 Карточка релиза конфига

Release: checkout-config v2.3.1
Scope: prod EU
Changes: psp_b_weight 20→30, request_ms 1500→1300
Risk: Medium (маршрутизация платежей)
Canary: 1%→5%→25% (30/30/30 мин), guardrails: success_ratio, p95
Rollback: tag v2.3.0

16) Анти-паттерны

Правки в проде мимо GitOps (“быстро подкрутил”).
Секреты/PII в репозитории конфигов.
Отсутствие схем и статических проверок.
Сильное расхождение окружений (base≠prod).
“Живые” фич-флаги без версий и истории.
Игнорирование дрейфа и ручных правок на серверах.
Теги без release notes и плана отката.

17) Дорожная карта внедрения (4–6 недель)

1. Нед. 1: инвентаризация конфигов; раздельные каталоги, схемы для топ-10 сервисов.
2. Нед. 2: включить линтеры/валидацию и dry-run в CI; запрет мержа без зеленых чеков.
3. Нед. 3: GitOps раскат + канарейки; аннотации версий в телеметрии.
4. Нед. 4: ввод политики допуска (policy-as-code) и rollback-шаблонов; алерты на дрейф.
5. Нед. 5–6: покрыть 90% сервисов; свести различия env к overlays; добавить метрики зрелости и еженедельный review конфиг-изменений.

18) Итог

Контроль версий конфигураций — это система, а не просто Git. Схемы и валидация, GitOps и политики доступа, канарейки и откаты, обнаружение дрейфа и полный аудит превращают конфиг в управляемый артефакт. Результат — быстрые и безопасные изменения, предсказуемость SLO и уверенность команды в каждом релизе.