Конфігурація як дані

(Розділ: Архітектура та протоколи)

1) Ідея та відмінність від «конфігурації як код»

Конфігурація як дані (Configuration as Data, CaD) - це представлення конфігурації як типізованої, декларативної, валідованої моделі, незалежної від виконуваного коду і керованої як бізнес-дані: з версіями, схемами, міграціями, аудитом і тестами.
На відміну від «конфігурації як код», де логіка генерації конфігів живе в шаблонах/скриптах, CaD виключає імперативність з джерела істини: ніяких циклів, умов і прихованої логіки всередині конфігів. Всі - чисті дані + сувора схема + політики.

Ключові цілі: передбачуваність, диф-здатність, безпека змін, швидкі відкати, можливість прогресивної доставки і автоматичного контролю відповідності.

2) Принципи «конфіг як дані»

1. Декларативність та однозначність: описуємо бажаний стан, а не кроки досягнення.
2. Типобезпека і схеми: JSON Schema/Protobuf/Avro/OpenAPI для суворих контрактів.
3. Іммутабельність артефакту: конфіг-знімки версуються і підписуються (provenance).
4. Валідація і політика: в пайплайні - синтаксис → семантика → policy-as-code (OPA, правила).
5. Спостережуваність конфігів: відбиток версії в логах/метриках/трасуваннях.
6. Поділ відповідальності: дані (конфіг), схема (контракт), політика (обмеження), контролер (реалізація).
7. Модульність та шари: глобальні, регіональні, tenant-, продуктові, фіче-рівні, з передбачуваним мерджем і пріоритетами.

3) Моделювання конфігурації: схема як контракт

Сімейства сутностей: маршрутизація, ліміти, фічефлаги, тарифи, AB-сегменти, квоти, ризикові правила, фіннабудови тощо.
Типи: явні enum/oneOf, діапазони, regex, посилальна цілісність (ref/ID).
Версіонування схем: 'v1 → v1beta2 → v2'( deprecation-план, міграції).
Defaulting/Mutation: безпечні замовчування на етапі валідації; детермінований порядок застосування.
Constraint-ы: бізнес-обмеження (наприклад,'rateLimit <= 2000 rps'на tenant).

yaml apiVersion: config. example. io/v1 kind: RateLimitPolicy metadata:
scope: tenant:acme spec:
targets:
- service: checkout endpoint: /api/pay method: POST limit:
unit: second value: 500 burst: 200 strategy: tokenBucket

4) Шари, успадкування і вирішення конфліктів

Ієрархія: `global → region → environment → tenant → product → cohort → user`.
Правила мерджа: декларативні - «останній переміг» (override) або стратегічні (merge/patch/replace per field).
Валідація на перетинах: забороняємо конфліктуючі ключі, вимагаємо явний override.
Візуалізація підсумкового effective-конфіга - обов'язкова (детерміновані диффи).

5) Життєвий цикл конфігурації (GitOps-парадигма)

1. Джерело істини: репозиторій з даними + схемами + політиками.

• синтаксична перевірка (lint),
• валідація за схемою,
• семантичні перевірки/тести,
• policy-as-code (наприклад, OPA/Rego),
• безпечні міграції (див. § 7),
• підпис і публікація снапшота.
• 3. Промоція: PR-ами між каталогами'dev/qa/staging/prod'або кільцями'ring-0/.../ring-N'.
• 4. Доставка: контролери/оператори підтягують свіжі снапшоти, застосовують через reconcile-цикл.
• 5. Аудит і оборотність: всі зміни трасуються; відкат - revert commit/rollback snapshot.

6) Доставка і поширення конфігів

Статична (pull-on-start): вантажимо снапшот на старті, перезапуск для оновлення.
Динамічна (watch/stream): etcd/Consul/ZooKeeper, Kubernetes API/CRD, власний Config Service.
Протоколи: gRPC/REST з ETag/If-None-Match, long-poll/watch, снапшоти + інкрементальні диффи.
Кешування: локальні снапшоти з TTL і підписом; атомарна зміна (подвійна буферизація).
Послідовність: strong (лідер/кворум) vs eventual (edge/IoT). Для критичних систем - кворум + RA.
Глобальні розкатки: по регіонах/колечках (ring-deploy), з лімітом одночасних зонів.

7) Міграції конфігураційних даних

• Expand: вводимо нові поля з замовчуваннями, не ламаючи споживачів.
• Migrate: бекфіли/конвертори (скрипти-провайдери міграцій, ідемпотентність).
• Contract: прибираємо застаріле, коли всі контролери на новій версії схеми.
• Правило сумісності: стара логіка розуміє нове, нова - старе в перехідний період.

8) Політика, відповідність і безпека

Policy-as-code: Rego/Conftest/OPA Gatekeeper - заборони небезпечних значень (наприклад,'timeout = 0', відключення TLS, необмежені квоти).
RBAC/ABAC: хто може змінювати які секції і на яких шарах.
Багатостороннє твердження (four-eyes) для чутливих сегментів (платежі/ліміти).
Секрети: зберігаємо поза загальними конфігами (KMS, Vault, SOPS), в конфігу - тільки посилання/референси.
Підписи та довіра: верифікація поставок (attestations), заборона непідписаних снапшотів.
Санітайзинг: захист від injection в шаблонах і при рендері.

9) Спостережуваність, SLO і управління ризиком

Конфіг-мітки в телеметрії: '{config _ digest, config_version, ring, scope}'в логах/метриках/трейсах.
Golden-метрики конфіг-пушей: час застосування, відсоток успіху, число відкатів, час консистентності.
Гейти при розкочуванні конфігів: як для коду - канарські кроки і авто-стоп по деградації SLO.
Dogfooding: спочатку internal/beta-кохорта.

10) Hot-reload, транзакційність і безпека застосування

Atomic switch: нова конфігурація готується в пам'яті → єдине атомарне перемикання.
Dry-run: валідуємо і симулюємо застосування (в тому числі конфлікт полів/політик).
Partial failure: стратегія - «все або нічого» для пов'язаних компонентів або чіткий опис деградацій.
Backoff/Retry: при помилці застосування - безпечний відкат і повтор з експоненціальною затримкою.

11) Фічефлаги як підмножина конфігів

Фічефлаги - це конфіг-дані з особливими політиками: таргетинг за сегментами, обмеження на радіус включення, kill-switch.
Вимоги: детермінована семантика таргетингу, аудит, безпечні дефолти, сумісність версій клієнта/сервера.

12) Інструменти та носії

Носії: JSON/YAML/TOML/Protobuf/Avro (для мережевої доставки - частіше Protobuf/JSON).
Рендер/композиція: Kustomize/Helm/Jsonnet (як генератори, але підсумок - чисті дані).
Сховища/шини: Git, OCI-реєстри (як артефакти), S3-сумісні сховища, etcd/Consul/KV.
Контролери: власні оператори, GitOps-агенти, Sidecar-конфіг-провайдери.
Policy: OPA/Rego, Kyverno-подібні механізми.

13) Чек-листи

Проектування

• Схема на першому місці (JSON Schema/Proto), описані типи/обмеження/дефолти.
• Версіонування та міграції схем задокументовані.
• Ієрархія шарів і стратегія мерджа визначені і протестовані.

Пайплайн

• Lint → schema-validate → semantic tests → policy-check → sign → publish.
• Dry-run і візуалізація effective-конфіга для рецензентів.
• Канаркова розкачка конфігів з авто-гейтами по SLO.

Прод

• У логах/метриках є'config _ digest'.
• Відкат конфігурації - тією ж кнопкою, що і деплою коду.
• Снапшоти/бекапи конфігів і історія аудиту доступні і перевірені.

14) Часті анти-патерни

Імператив у конфігу: умови/скрипти/шаблони з логікою - невалідовані і непередбачувані.
Змішування секретів і загальних налаштувань в одному файлі/репозиторії.
Непрозорий мердж: неясно, звідки взялося підсумкове значення.
Відсутність схеми: «валідно все» ⇒ баги на проді.
Глобальні правки без кілець/канарок: миттєва деградація для всіх.
Дрейф оточень: ручні правки в рантаймі повз джерело істини.
Довгі TTL в конфіг-кеші без механізму примусового інваліда.

15) Сценарії (ескізи)

A. Тонке налаштування лімітів трафіку по регіонах

1. PR зі змінами'RateLimitPolicy'на'ring-0'( внутрішні клієнти).
2. Автоперевірки: схема/політика (ліміт ≤ 2k rps).
3. Промоція на'ring-1'( 5% користувачів), моніторинг p95/error rate.
4. Розширення до'ring-N', фіксація снапшота, закриття завдання.

B. актуалізація тарифної сітки (фіннабудови)

сильна семантика і бізнес-політики: подвійний огляд, двоетапна промоція, час-вікно вступу, аудит і можливість миттєвого відкату.

C. глобальний фічефлаг платежів конфіг-прапор з kill-switch: таргетинг «employees → beta → 10% → 100%», автоматична зупинка при падінні successful payment rate нижче порога.

16) Інтеграція з Zero-Downtime і прогресивною доставкою

Конфіг-канарки синхронізовані з релізними кільцями.
Сумісність версій: спочатку розширюють поля, потім код, потім посилення.
Shadow-конфіги: паралельний розрахунок рішень (наприклад, лімітингу) для порівняння з бойовим.

17) Резюме

Підхід «конфігурація як дані» перетворює налаштування з крихких файлів в надійні доменні моделі з чіткими контрактами, валідацією і політиками. Це основа передбачуваних розкаток, безпечних експериментів і швидкої реакції на інциденти. Формалізуйте схеми, відокремте секрети, впровадьте GitOps і канарські конфіг-пуши - і конфігурація перестане бути ризиком, ставши керованим активом платформи.