操作のプレイブック

1） PlaybookとRunbookの違い

Runbookは、典型的な操作/アラート（「do one、 two、 three」）のための線形ステップバイステップの命令です。
Playbookは、フォークのシナリオのための決定ツリーです：異なる症状→異なる仮説→行動の異なる枝。選択基準、ゲート条件、フォールバックブランチが含まれています。
プレイブックの目的は、MTTA/MTTRと不確実性の下で即興のレベルを減らすことです。

2） Playbookが最初に必要とされるところ

インシデント：SLOドロップ（可用性/レイテンシ/成功）、ビジネスSLI障害（コンバージョン/支払いの成功）。
変更：リリース、マイグレーション、フィーチャーフラグ、configs（カナリア/ロールバック）。
メンテナンスウィンドウ：データベース/ブローカーアップグレード、証明書の回転。
プロバイダ：PSP/KYC/CDN/IDP-劣化とスイングオーバー。
セキュリティ：危険な鍵、疑わしい活動。
DataOps：遅延鮮度、回路のドリフト、パイプラインの劣化。

3） Playbookの標準（最低の構成）

1.カード：ID、バージョン/日付、所有者（チーム/ロール）、サービス/地域/テナント、関連ポリシー/基準。
2.目的と打ち上げ条件：どのSLO/SLIを保護するか、どのアラート/トリガーが適用されます。
3.仮説↔症状：対応表、誤った仮説をすばやく断ち切る方法。
4.意思決定ツリー：フォーク、セキュリティゲート、停止/継続基準。
5.アクション：コマンド/runbookへのリンクを持つステップブロック'と。
6.コミュニケーション：更新テンプレート（Impakt→Diagnostika→Deystviya→Sled。更新）、チャネルおよび頻度。
7.ロールバック/フォールバック：明確なバックアウトプラン、制限、UXの劣化フラグ。
8.完了基準：メトリクス、オブザベーション時間ウィンドウ。
9.証拠：保存するもの（ログ、グラフ、スクリーンショット、チケットID）。
10.変更履歴：changelog、既知の制限。

4） Playbook分類（カタログ例）

インシデント（SLO/SLI、プロバイダ、インフラストラクチャ）。
REL--リリース、ロールバック、configs/flags。
MW--メンテナンスウィンドウ（DB/queue/cert/OS）。
SEC--セキュリティ（アクセス、キー、疑わしいアクション）。
DATA--新鮮さ/品質/スキーム。
PROV--外部プロバイダ（PSP/KYC/CDN/Email/SMS）。

5）ライフサイクルと所有権

1.開始：インシデント/シミュレーション/変更に基づいています。
2.ドラフト：author=service owner；レビュー：SRE/セキュリティ/データ（ドメイン別）。
3.パイロット：卓上/ゲームデー；通過時間と欠陥の記録。
4.パブリケーション：リポジトリ（Docs-as-Code）、バージョン、タグ、ダッシュボードへのリンク。
5.更新：RCA/CAPAに従って、少なくとも四半期に一度；SLAの新鮮さ。
6.アーカイブ/枯渇：交換/関連性の喪失の場合。

6）ツールとの統合

Alert→Playbook：各ページルールは1つの基本的なPlaybookを参照します。
ChatOps： '/play start <id>'はカードを開き、証拠を修正し、更新タイマーを設定します。
CMDB/カタログ：サービスには、関連するプレイブック、所有者、SLO、ダッシュボードのリストがあります。
GitOps： PlaybookとRunbooksはGitに住んでいて、PRレビューとLinterを持っています。

7） Playbookの質のメトリック

実行可能性：実行の90％を≥すると、無意識のうちにエスカレートすることなく特定のアクションが発生します。
最初のアクションに時間：最初の意味のあるステップにページから1分または2。
カバレッジ：％バインドされたプレイブック（100％ターゲット）を持つページアラート。
新鮮さ：プレイブックの割合は90日より新鮮です。
欠陥レート：100プレイブックのレビュー/シミュレーションに関するコメント。
再利用：Playbookが実際に適用された回数（およびそれがどのような結果につながったか）。

8）アンチパターン

決定ツリーなしで20ページの「Playbook Encyclopedia」。
結果を期待しないコマンド（「execute X」-何を変更すべきか？）。
バックアウトプランと制限はありません-問題をエスカレートするリスク。
コミュニケーションチャネル/間隔は示されていません-PRリスクの増加。
所有者/更新日なしのPlaybook-誰もその関連性を信じていません。
1つのパラメータ化可能ではなく、数十の類似のプレイブック。

9） Playbookミニテンプレート（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）支払い： 「プロバイダーが1つの地域で劣化する」

症状：TRコホートのsuccess_ratioが減少し、PSP-Aタイムアウトが増加しました。
ソリューション：TR用PSP-Aの重量を減らし、UXの劣化を可能にし、予算≤ SLAでリトレイを強化し、クライアントのアップデートを準備します。
バックアウト：60分の緑のSLIで重量を取り戻します。

B） DB： 「成長p99と接続エラー」

症状：p99→、接続リセットエラー、成長待ちイベント。

ソリューション： 読み取り専用スクリプトの有効化、書き込み負荷の制限、スケールプール/レプリカ（必要に応じてホットフェイルオーバー）

バックアウト：パラメータロールバック、replica-prime。

C）キャッシュ： 「Miss rate→database load」

症状：ミス率>40％、 CPU DBの成長。
ソリューション：バランス回避ポリシー、メモリ/シャーディングを増やし、一時的に読み取りスルーを有効にし、ホットキーのRPSを制限します。
バックアウト：ポリシーを返し、問題のあるシャードを再作成します。

D） CDN： 「地域のコンテンツ劣化」

症状：1つの国でレイテンシ/タイムアウトの増加、RUMの苦情。
ソリューション：ルーティングマップ/GSLBを変更し、問題のあるPOPをバイパスし、TTLを削減し、オリジンシールドを有効にします。
Comms：影響の地理とステータスの更新。

E） KYC： 「識別に失敗しました」

症状：ドロップ承認率、vendor_error成長。
ソリューション：トラフィックの一部を代替プロバイダに切り替え、ルールの重大性を（ポリシーの枠組みの中で）軽減し、VIPの手動レビューを開始します。
コンプライアンス：すべての変更のログ、必要に応じてリスク/法的通知。

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およびトリガー。
• テーブル「仮説↔症状」と意思決定ツリーがあります。
• 期待される結果とセキュリティゲートを持つ実行可能なステップ。
• バックアウト/フォールバックとリターンの条件が明記されています。
• コミュニケーションテンプレートと更新頻度。
• ダッシュボード/アラート/ログ検索/トレイルへのリンク。
• 必要な証拠セクションと完了基準。
• バージョン、日付、SLAの鮮度、履歴の変更。

13）レビューチェックリスト

• Playbookは卓上/ゲームデーで再生可能です。
• ステップは安全です（制限/カナリア/自動ロールバック）、秘密は開示されません。
• 役割とエスカレーションは明確です。IC/Commsが表示されます。
• 隣接するプレイブックとの重複はありません。パラメータは削除されます。
• いつ停止してフォールバック/ロールバックに行くかは明らかです。
• ドキュメントは1クリックでアラートから利用できます。

14）パラメータ化と再利用

変数（region、 provider、 thresholds）をvaluesで実行します。'.

一般的な手順（たとえば「、プロバイダの重量を減らす」「、degrade-UXを有効にする」など）は、別のランブックで発行する必要があります。

テンプレートからジェネレータをサポート： 'plb new --type=INC --service=payments'

15）導入ロードマップ（4〜6週間）

1.ページアラート→各基本的なプレイブックへのマップのインベントリ。
2.テンプレート：YAML/Markdown構造、チェックリスト、およびリンタを承認します。
3.トップ5シナリオ（支払い/DB/CDN/KYC/キャッシュ）→書き込み/ロールバック。
4.統合：アラートからのリンク、ChatOpsコマンド、証拠ボット。
5.ドリル：毎週ミニドリル1つのプレイブックを一度に；AAR→uluchsheniya。
6.新鮮なSLAと四半期ごとのレビュー；質のメトリックレポート。

16）ボトムライン

Playbookは「、何をすべきか」の混乱を予測可能な一連の決定に変換するフォークと手すりを備えた運用シナリオです。プレイブックが標準化され、アラートと統合され、定期的に訓練されると、チームはより迅速に対応し、リスクは制御され、ビジネスは搾取の安定性と成熟度を見ます。