控制配置版本

1）為什麼要驗證配置

配置是可執行的策略：它定義路由、限制、幻燈片、訪問、數據模式。版本控制使更改可重復，可預見和可逆性：減少MTTR和更改失敗率，消除「銷售中的魔力」，並進行安全性和合規性審核。

2）配置分類

基礎設施（IaC）：集群，網絡，LB，DB，隊列。
服務：應用參數、資源、限制、時間表、轉發。
產品/業務邏輯：關稅，AB實驗，內容規則。
數據/DataOps：電路合同,SLA新鮮,轉型。
安全：訪問策略、角色、密鑰/證書（秘密本身-回購之外）。
可觀察性：SLI/SLO，Alerts，dashbords。

規則：任何影響系統行為的都是配置，必須生活在轉換下。

3）版本控制原則

1.GitOps：真理的唯一來源是存儲庫；通過公關和自動管道進行更改。
2.聲明性：描述目標狀態，而不是步驟腳本。
3.文物的不可移動性：config →唯一可實現的狙擊手。
4.方案和驗證：JSON/YAML方案，嚴格的類型引導，強制性字段。
5.環境作為代碼：「env」-文件夾/覆蓋物（dev/stage/prod），差異最小且顯而易見。
6.等效性和回滾：任何配置版本都是可逆的（revert/rollback）。
7.審核和可跟蹤性：作者，原因，滴答聲/RFC，更改簽名。

4）考試策略

SemVer用於configs包（'MAJOR.MINOR.PATCH`):

MAJOR-不兼容的電路/策略更改。
MINOR-新字段/規則,向後兼容性。
PATCH-在不更改模式的情況下修復值。
標簽發行版和發行註釋：更改了什麼，如何回滾，檢查點。
Pinning/lock文件：捕獲相關性版本（模塊、圖表）。
Matrix版本：Application X工件與config Y（服務目錄中的矩陣）兼容。

5）存儲庫的組織

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

分支：基於trunk（主要）+短功能分支。Merge僅通過具有強制性CI的PR。

6）驗證和測試

方案：每個更改都經過方案驗證（required, enum, ranges）。
靜態林特：格式，鍵，雙打，禁區。
兼容性測試：config+版本的服務/圖表在沙箱中上升。
控制運行：dry-run應用，目標狀態的「what-if」 diff。
策略即代碼：接納規則（Rego/CEL）-誰可以更改以及可以更改什麼。

7）部署和回滾配置

漸進式交付：帶有SLO Gardreils的金絲雀1%→5%→25％。
登機口：沒有活躍的SEV-1，Alerta綠色，簽名真實，回滾準備就緒。
回滾：'revert tag vX。Y.Z'或切換到以前的狙擊手；回滾命令記錄在運行簿中。
發布註釋：config版本以度量/邏輯發布,以便與事件快速相關。

8）動態和遠程配置

Remote config/feature flags：更改參數而不重啟；所有標誌都在GitOps下。
邊界：允許動態更改哪些參數（白名單列表）。
緩存和一致性：TTL，版本，原子替換集（雙相發布）。
安全欄桿：runtime更改的極限和範圍，在SLO後面時自動滾回。

9）秘密和敏感數據

永遠不要在回購中存儲秘密。在配置中-僅參考/播放器。
在需要時加密config文件：與秘密/密鑰管理器集成。
輪換和JIT：在運營期間提供可用性；行動的足跡不變。
現場偽裝：驗證禁止PII/秘密進入 config。

10）環境管理

Base+overlays： dev/stage/prod之間的差異最小且透明。
通過人工制品的宣傳：通過舞臺的相同狙擊手在舞會上前進。
時間窗口：值班時不會發生變動；對於風險高-RFC和服務窗口。

11）檢測和消除漂移

控制器將目標狀態與實際狀態進行比較，然後進行報告。
漂移變量：僅在嚴重差異時才使用頁面；其余的是門票。
自動還原：在分辨率下-返回目標狀態。
手動編輯審核：任何「kubectl 編輯/ssh」 →過程和CAPA事件。

12）配置目錄和所有權

服務目錄：所有者,SLO,相關策略,方案,版本,兼容性。
RACI：誰建議，誰是嫉妒，誰贊成；高風險的CAB。
透明度：每個條目都有版本歷史記錄，並鏈接到PR/tiketa/AAR。

13）成熟度量

Coverage： GitOps之下的服務/策略百分比（目標≥ 95%）。
領導時間變化：中位數從PR到prod。
Change failure rate：回滾/事件的config發行比例。
漂移率：差異數/周數和消除時間。
滾回時間：恢復到先前版本的中位數。
審核完整性：完全驗證的更改比例（驗證器,dry-run,評論）。

14）支票單

在更改配置之前

• 有tiket/RFC和更改所有者。
• 已經通過了電路和linter的驗證。
• 有一個回滾計劃和運行手冊中的團隊。
• Gate：測試是綠色的，簽名是有效的，沒有主動SEV-1。
• 對於高風險-已分配服務窗口。

在分手期間

• 金絲雀和SLO Gardrails活躍。
• 發布版本註釋。
• 通道中有回聲消息；根據MW規則，警報噪音被抑制。

之後

• 觀察窗口已通過，SLO綠色。
• 結果和事件（之前/之後的圖形，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 Basic config+overles 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 Config發行卡

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（「快速分類」）上進行編輯。
Config 存儲庫中的秘密/PII。
沒有電路和靜態檢查。
周圍環境的強烈差異（base≠prod）。
沒有版本和故事的「現場」幻燈片標誌。
忽略服務器上的漂移和手動編輯。
沒有發布註釋和回滾計劃的標簽。

17）實施路線圖（4-6周）

1.奈德。1：核對清單；分開的目錄，前10名服務的模式。
2.奈德。2：在CI中包括林特/驗證和幹跑；禁止禁止使用綠色支票。
3.奈德。3：GitOps分開+金絲雀；遙測中的版本註釋。
4.奈德。4：輸入公差策略（策略即代碼）和滾回模式；漂移。
5.奈德。5-6：覆蓋90%的服務；將env的差異減少為過量；添加成熟度指標和每周config更改審查。

18）結果

配置版本控制是系統，而不僅僅是Git。方案和驗證，GitOps和訪問策略，金絲雀和回滾，漂移檢測和全面審核將config變成了受控的人工制品。結果是快速而安全的更改，SLO的可預測性以及團隊對每個版本的信心。