Контроль версій конфігурацій
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) Стратегії версіонування
SemVer для пакетів конфігів ('MAJOR. MINOR. PATCH`):- 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: 20yaml services/checkout/overlays/prod/config.yaml limits: { rps: 1200 }
features:
psp_a_weight: 70 psp_b_weight: 3015. 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.016) Анти-патерни
Правки в проді повз 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 і впевненість команди в кожному релізі.