"Governance"
- Tagging 規範與 Secrets 不進 code
tag 讓資源可盤點、可清理、可歸屬；密鑰存在專用服務裡而非 code 或 state，兩者都屬於 day-1 就該立的治理地基
- 成本可見性與最小可行治理節奏
用 tag 驅動的成本分攤讓帳單有人負責，以及判斷什麼治理該 day-1 就立、什麼等規模逼出來再加
- 職務交接與存取撤銷設計
人員異動時的存取撤銷順序、credential rotation、最小交接清單，以及讓交接成本結構性降低的 infra 設計原則
- Flaky test 團隊治理
flaky test 累積到讓團隊開始 skip 或 ignore 時，從個案修復升級到團隊層的治理策略：quarantine 政策、retry 預算、信任修復的可視化與行動閾值
- 11.10 API 規範治理
設計規範怎麼讓幾十個團隊持續遵守 — 提案制、Guild 制、分軌制的治理模式比較、linting 進 CI、規範失敗的成因
- Quarantine（隔離）
把已知 flaky 的測試從主要執行路徑移開、保留修復壓力的治理機制；與 skip 的語意差異在於 quarantine 有負責人和回收期限
- Kafka Multi-tenant 治理：quota 限流、ACL 授權與 topic 生命週期
單一 Kafka 叢集承載多團隊時、quota 把頻寬與 request 容量切給每個租戶、ACL 把寫入與讀取權限綁到 principal、topic 命名規範劃出 ownership 邊界、生命週期治理回收死 topic 釋放 metadata 壓力。本文涵蓋 producer_byte_rate / consumer_byte_rate / request_percentage 三類 quota 與 user / client-id / 組合三種套用層級、StandardAuthorizer 的 principal × resource × operation × host 授權模型、prefixed ACL 的 tenant 隔離、TopicGC 式的死 topic 回收、以及四個 production 故障演練（單租戶暴衝吃滿頻寬、ACL 過鬆過緊、topic 數量爆炸壓垮 controller、unused topic 未回收）
- Flaky test 治理
說明 CI/CD 如何把 flaky test 從重跑雜訊轉成可分類、可隔離、可修復的 gate 信任度問題
- 11.C46 Google AIP：規範即提案系統的治理模式
編號提案制、狀態機、簽核門檻把 IETF RFC 流程內化到單一組織；中心化治理、社群貢獻是輸入
- 11.C47 Zalando API-first：Guidelines、Guild、Zally、Portal 四件套
規範存活靠配套組織機制：文件、人的治理、自動化、可發現性缺一環就退化成書架文件
- 11.C48 Microsoft REST Guidelines：單一 repo 內的分軌治理
規範沿組織邊界分化的實況：Core / Azure / Graph 三軌並存、跟「像同一團隊設計」理想的張力
- 11.C49 Spectral 與 Zally：guidelines 變成可執行檢查
治理成本從人工 review 前移到 CI；通用 linter 加組織 ruleset 比單一組織專用 linter 更能存活
- 11.C54 White House API Standards：規範制定後棄置（反例）
反例：文件品質不差、但沒有 Guild / linter / review 等執行機制與持續 ownership、34 commits 後封存
- 7.25 資安成熟度的組織節奏
成熟度提升排不進日程、或指標有在收而能力沒有前進時，判斷回顧節奏的下限、每個動作的 owner 與指標的分母
- Coverage vs Completion Rate（覆蓋率與完成率）
說明同一個百分比的分母由誰列舉，決定它衡量的是全體的覆蓋率還是管理範圍內的完成率
- Security Control Domain（資安控制面）
說明一條資安風險的防守責任歸給哪一類控制，以及這個「控制面」與基礎設施的 control plane 同名不同義