花花公子操作

1）花花公子是什麼，與跑步簿有什麼不同

Runbook是用於類型操作/警報的線性分步指令（「動手，兩個，三個」）。
花花公子是叉子場景的決策樹：不同的癥狀→不同的假設→不同的動作分支。包括選擇條件、進站條件和fallback分支。
花花公子的目的是在不確定性下降低MTTA/MTTR和即興創作水平。

2）首先需要花花公子的地方

事件：SLO下降（可用性/可用性/成功性），業務SLI失敗（轉換/支付成功）。
更改：發布、遷移、幻燈片標誌、configi （canary/rollback）。
服務窗口：DB/經紀人升級，證書輪換。
提供者：PSP/KYC/CDN/IDP-降解和交換。
安全：受損鑰匙，可疑活動。
DataOps：新鮮度遲到、模式漂移、管道退化。

3）花花公子標準（最小陣容）

1.卡：ID,版本/日期,所有者（團隊/角色）,服務/地區/tenants,相關政策/標準。
2.啟動目標和條件：哪個SLO/SLI保護哪些變量/觸發器適用。
3.癥狀↔假設：對應表，如何迅速切斷錯誤的假設。
4.解決方案樹：分叉、安全門、停止/繼續標準。
5.操作：帶有命令/鏈接到運行手冊的回合制塊。
6.通訊：升級模板（Impakt→Diagnostika→Deystviya→Sled。更新），頻道和頻率。
7.回滾/倒退：明確的UX退化背面計劃、限制和標誌。
8.完成標準：度量，時間觀察窗口。
9.Evidence：保存的內容（日誌、圖形、截圖、ID字幕）。
10.更改歷史：changelog,已知的限制。

4）花花公子分類（目錄示例）

INC-事件（SLO/SLI，提供商，基礎設施）。
REL-版本，回滾，configi/標誌。
MW-服務窗口（DB/queue/cert/OS）。
SEC-安全（訪問、密鑰、可疑活動）。
DATA-新鮮/質量/方案。
PROV-外部提供商（PSP/KYC/CDN/電子郵件/SMS）。

5）生命周期和所有權

1.啟動：根據事件/模擬/更改的結果。
2.草稿：作者=服務的所有者；評論：SRE/安全/數據（按域）。
3.飛行員：平臺/遊戲日；固定通過時間和缺陷。
4.出版物：在回購中（Docs-as-Code），版本，標簽，指向行車記錄的鏈接。
5.更新：RCA/CAPA，至少每季度一次；SLA新鮮。
6.歸檔/解密：當替換/丟失相關性時。

6）與工具集成

警告→劇本：每個頁面規則都恰好引用了一個基本花花公子。
ChatOps： '/play start <id>"打開卡片,捕捉事件,設置升級計時器。
CMDB/目錄：服務中列出了相關的花花公子，所有者，SLO，行車記錄儀。
GitOps：Playbooks和runbook'，住在Git，經過PR review和linters。

7）花花公子質量指標

Actionability：≥ 90%的發射導致特定行動沒有「在不知不覺中」升級。
時間到第一動作：從頁面到第一個有意義的步驟一兩分鐘。
封面：具有綁定花花公子的Page Alert（目標100％）的百分比。
Freshness：花花公子的比例是新鮮的90天。
Defect rate：在100個花花公子上的評論/模擬。
Reuse：花花公子實際使用了多少次（以及結果導致了什麼）。

8）反模式

「花花公子百科全書」長達20頁，沒有決策樹。
沒有期望結果的命令（「執行X」-應該改變什麼？）。
沒有背景計劃和限制-問題升級的風險。
沒有指定鏈路/通信間隔-公關風險的增長。
沒有所有者/更新日期的花花公子-沒有人相信它的相關性。
數十個類似的花花公子代替一個參數化。

9）迷你花花公子模板（YAML想法）

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10）完成的示例（片段）

A）付款： 「提供商在一個地區退化」

癥狀：TR隊列success_ratio減少，PSP-A計時器生長。
解決方案：減輕TR的PSP-A重量，啟用degrade-UX，加強預算≤ SLA的撤退，準備客戶升級。
Backout：在綠色SLI 60分鐘內恢復重量。

B）DB： 「p99的增長和連接錯誤」

癥狀：p99↑、連接重置錯誤、等待事件上升。
解決方案：包括僅讀取腳本、限制寫入負載、縮放池/復制副本,如有必要,可進行熱捕獲。

Backout： 參數回滾,副本.

C） Cash： 「Rate小姐↑ → DB負載」

癥狀：miss rate> 40%, CPU DB升高。
解決方案：平衡事件策略,增加內存/緩存,暫時啟用讀取,限制熱鍵上的RPS。
Backout：帶回政治，重新解決問題。

D） CDN： 「區域內容退化」

癥狀：一個國家的滯後/定時上升，RUM投訴。
解決方案：更改路線圖/GSLB、繞過有問題的POP、降低TTL、啟用起源盾。
Comms：具有影響力地理位置的地位。

E）KYC： 「身份失敗」

癥狀：approve率下降，vendor_error上升。
解決方案：將部分流量切換到替代提供商,降低規則嚴格（作為策略的一部分）,為VIP啟動手動審查。
Compliance：生成所有更改的日誌,必要時發出風險通知/法律通知。

11）通訊（升級模板）

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12）花花公子作者的支票清單

• 指定了目標，所有者，SLO/SLI和觸發器。
• 有癥狀表↔假設和決策樹。
• 具有預期結果和安全門的可行步驟。
• 規定了背面/背面和退貨條件。
• 更新通信和頻率模板。
• 指向dashbords/alerta/log-search/traiss的鏈接。
• 強制性驗收科和完成標準。
• 版本、日期、SLA新鮮度、變更歷史。

13）審查員支票清單

• Playbook在tabletop/遊戲日播放。
• 步驟是安全的（限制/金絲雀/自動回滾），秘密沒有透露。
• 角色和升級是明確的；已指定IC/Comms。
• 與相鄰的花花公子沒有重復；給出了參數。
• 可以理解何時停止並切換到後衛/後衛。
• 該文檔可從Alert到1 Click訪問。

14）參數化和重新使用

將變量（區域、提供者、閾值）輸出到「values.」。
常見的步驟（例如「減輕提供商的重量」，「啟用degrade-UX」）設計單獨的運行手冊。
支持模板生成器：「plb new -type=INC -service=payments」。

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

1.頁面清單→匹配每個基本花花公子。
2.模板：批準YAML/Markdown結構，支票單和林特。
3.前5種方案（付款/DB/CDN/KYC/緩存）→寫入/回滾到tabletop。
4.集成：來自警報器的鏈接，團隊的ChatOps，evidence機器人。
5.教學：每周迷你演習一次花花公子；AAR→uluchsheniya。
6.SLA新鮮和季度咆哮；質量指標報告。

16）結果

花花公子是帶有叉子和欄桿的操作場景，可以將混亂「該怎麼辦？」轉換為可預測的決策順序。當花花公子標準化，與Alert集成並定期訓練時，團隊的反應更快，風險得到控制，業務看到運營的穩定性和成熟度。