Теңшелім нұсқаларын бақылау

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-бұтақтар. Мерж - міндетті CI бар PR арқылы ғана.

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-өзгерістерге арналған лимиттер мен диапазондар, SLO-дан шығу кезінде авто-rollback.

9) Құпиялар және сезімтал деректер

Ешқашан репода құпияларды сақтамаймыз. Конфигурацияларда - тек сілтемелер/плейсхолдерлер.
Қажет болған жағдайда пішім файлдарын шифрлау: құпия/кілт менеджерімен біріктіру.
Ротация және JIT: қолжетімділік операциялар уақытына беріледі; іс-әрекеттің ізі өзгермейді.
Далалық бүркемелеу: валидация PII/құпиялардың қауiпсiздiкке түсуiне тыйым салады.

10) Қоршаған ортаны басқару

Base + overlays: dev/stage/prod арасындағы айырмашылықтар ең аз және мөлдір.
Артефакттар бойынша promotion: stage өткен сол снапшот prod-ға жылжиды.
Уақытша терезелер: кезекшілікті ауыстыру кезінде пішіндер өзгермейді; risk-high үшін - RFC және қызмет көрсету терезесі.

11) Дрейфті анықтау және жою

Бақылаушы мақсатты жағдайды нақты жағдаймен салыстырады және репортит дифф.
Drift-алерта: Page тек сыни айырмашылықтар кезінде; қалғандары - Ticket.
Авто-ремедиация: рұқсат беру кезінде - мақсатты күйге қайту.
Қолмен түзету аудиті: кез келген «kubectl edit/ssh» → процесс инциденті және CAPA.

12) Конфигурация каталогы және иелену

Сервис каталогы: иесі, SLO, байланысты саясаттары, схемалары, нұсқалары, үйлесімділігі.
RACI: кім ұсынады, кім ревьюит, кім мақұлдайды; high-risk үшін CAB.
Ашықтық: әрбір жазбада нұсқалар тарихы және 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-схема, фрагмент)

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 болжамдылығы және команданың әрбір шығарылымға сенімділігі.