SOP：<クイックアクション/ゴール>
運用手順の標準化
1）なぜそれを必要とします
SOPは同社の「オペレーティングOS」です。標準化は、混乱と「個別スタイル」を除去し、MTTRを削減し、ノイズとインシデントのリスクを警告し、オンボーディングを加速し、結果を再現可能にします。
目的：- インシデントやルーチンのアクションの変動を減らします。
- トレーニングを加速し、ハンドオーバーの品質を向上させます。
- プロセスを監査可能にする：監査、指標、データの改善。
- 規制および社内要件の遵守を確保します。
2）標準化原則
1.均一なフォーマットと用語。1つの表記法、1つの定義（SLO、 ETA、 Owner）。
2.実用的な百科事典ではない。検証可能なステップ、成功基準、およびロールバックのみ。
3.最小限の分岐。フリーヒーリングの代わりに、ソリューションをクリアします。
4.バージョン管理と所有権。各SOPにはオーナー、バージョン、リビジョンの日付があります。
5.ツールとの統合。ダッシュボード、チケット、フィッシュフラグ、CLIコマンドへのリンク。
6.通話中の空き状況。すぐに検索、読み取り、1つのリンクで実行します。
7.継続的な改善。死後→SOPアップデートタスク。
3） SOPフレームワーク（テンプレート）
4) SOP classification
Incident: P1/P2 (critical), P3 (important).
Operational routines: releases, feature flags, database migrations, provider failover.
DR/BCP: disabling the region, restoring from backup, working offline.
Quality control/audit: revisions, readiness questionnaires, access.
Security/compliance: KYC/AML checks, log storage, privacy.
5) RACI: Ownership and Responsibility
Process R (performer) A (responsible) C (consultant) I (notify)
------------------------ --------------- ----------------- --------------- -------------
Create/Update SOP Domain Owner Head of Ops SRE/Compliance Teams
SLA Revision Ops Enablement Head of Ops Domain leads All
Use in an incident On-call Incident Manager Domain Owner Stakeholders
6) SOP lifecycle
1. Initiation: need from post-mortem/incident/audit.
2. Draft: by template, with specific artifacts and commands.
3. Review: Domain Owner + Head of Ops + specialized consultants.
4. Publishing: to portal/repository; annotations on dashboards.
5. Training: short training/screencast, knowledge test.
6. Application: recorded in ticket/incident.
7. Audit: by SLA revision or after a significant event.
8. Archiving: mark 'deprecated', indicate replacement.
7) Documentation as code (minimum standard)
We store SOP in Git (Markdown + YAML metadata), PR review, CI-lint.
Required fields are 'owner', 'version', 'last _ review', 'sla _ review'.
Link checker and structure validator in CI; auto-release portal after merge.
Significant changes - through changelog and notifications in the # ops channel.
8) SOP integrations
Incident Manager: Open SOP button when creating/escalating an incident.
Grafana/Observability: references from panels to relevant SOPs; release annotations.
Feature Flags/Release: canary step templates, SLO gates, rollback.
AI assistant: RAG search by SOP, TL; DR and proposals for action.
BCP/DR: DR-playbook automatically loaded by trigger.
9) SOP quality check (KPI and review)
KPI:
Coverage ≥ 90% of critical scenarios are closed by SOP.
Review SLA ≤ 180 days (share of overdue - 0).
Usage Rate ≥ 70% of overt SOP incidents.
DoD Pass Rate ≥ 90% of steps are closed with success criteria.
Broken Links = 0 (по CI).
Weekly monitoring:
Top 5 used and top 5 obsolete SOPs.
SOP communication ↔ postmortems: whether Preventive Actions have been performed.
Noisy SOPs (frequent rollback returns) are candidates for recycling.
10) Containment standards
Steps → specifics: commands/queries/parameters + expected effect in metric.
Time requirements: ETA for updates/next steps.
Escalation: clear matrix, contacts, backup channels.
Security: warnings, restrictions, PII/secrets - via vault/links.
Localization: in the on-call language (critical for distributed commands).
11) SOP examples (fragments)
SOP: Canary pause in SLO degradation
トリガー： error_budget_burn> 4x 10m、 api_p99> 1。3 ×ベースライン10m
ステップ：- 1）リリースツールでカナリアを一時停止する
- 2）チェックパネル「Change Safety」と「API p99」
- 3）チケットREG-
を作成し、ベースライン/ウィンドウを指定する - DoD： p99 ≤ 1。1 ×ベースライン15m、<ベースライン× 1エラー。2
- ロールバック：フラグを完全に無効にする、死後≤ 72ch
SOP: PSP Provider Feilover
トリガー： quota_usage>0。9またはoutbound_error_rate>2×baseline 5m
ステップ：- 1） PSP-Yルーティングを有効にする（config/button）
- 2）チェックデポジット変換とp95 PSP-Y
- 3）グラフ上の注釈、#incident-channelの更新
- DoD： success_rate ≥ 99。5％、 p95 ≤ 300ms 10m
- ロールバック：PSP-X安定化でトラフィックの20％部分的なリターン
12）チェックリスト
SOP準備チェックリスト：
［］目的とトリガーは明確で測定可能です。
［］コマンド/リンクの手順があります。
［］DoD/ロールバック処方。
［］エスカレーションと連絡先が関連しています。
［］メタデータが入力されます（オーナー、バージョンlast_review)。
［］リンクチェッカーとCIバリデータパス。
SOPアプリケーションチェックリスト（インシデント）：
［］インシデントマネージャ/パネルリンクからSOPが開きました。
［］手順が完了し、結果が記録されます。
［］DoD Reacted/Not-Checked。
［］チケットにアクション/不整合が記録されます。
［］タスクによって作成されたSOPの更新/強化（必要に応じて）。
13）トレーニングとオンボーディング
主要なSOP（支払い/賭け/ゲーム/KYC）のミニコース。
トレーニングでのSOPの必須の使用と影の義務。
毎週の「SOPクリニック」：30分の分析/改善。
シミュレーション（ゲームデイ）：DRとインシデントSOPの開発。
14） SOP変更管理
PRによるRFC、タグ'minor/major/breaking'。
変更を破る-必須のトレーニングと発表。
ドメイン所有者およびオンコールへの自動通知。
「SOP-Release Notes」を毎週の終わりに分離します。
15）アンチパターン
「それが判明したように」フリーフォームとコマンドによって異なるパターン。
所有者/リビジョン/リビジョン日なしのSOP。
ステップバイステップのアクションの代わりに「百科事典」テキスト。
ロールバック/DoDなし-成功を確認するものはありません。
壊れたリンク、「チャットからマニュアル」コマンド、プライベート「秘密」ステップ。
録音やトレーニングなしで見えないSOPが変更されます。
16） 30/60/90-実装計画
30日：
SOPテンプレートと最低基準を承認します。
リポジトリ'ops-sop/' （docs-as-code）を作成し、CI linterを有効にします。
10-15の重要なSOP（インシデント/リリース/プロバイダ）をデジタル化します。
Incident ManagerとvisibilityパネルをSOPリンクに接続します。
60日：
Reach Coverage ≥重要なシナリオでは70％です。
毎週「SOPクリニック」とオンコールトレーニングを開始します。
SOPとTLによるAI検索（RAG）を追加します。DRカードだ。
レビューSLA （180日）を入力し、期日前のSOPをレポートします。
90日：
カバレッジ≥ 90％、使用率≥インシデントの70％です。
すべてのSOPにDoD/ロールバックを埋め込み、壊れたリンクを閉じます（0）。
SOP KPIをコマンドOKR （MTTR、 Change Failure Rate）にバインドします。
レトロと次の四半期の改善を記録します。
17） FAQ
Q： SOPはrunbookとどう違うのですか？
A： SOP-標準化された手順（規制「方法」）。Runbook-特定のケース/サービスの詳細な手順。多くの場合、SOPは1つ以上のランブックを指します。
Q： SOPにはいくつの詳細がありますか？
A：オペレータがチャットに「掘り下げる」ことなくアクションを実行するのに十分です。アクションに影響を与えないものは、すべて別々の参照マテリアルにあります。
Q：関連性を維持する方法か？
A： SLAリビジョン（≤ 180日）、自動リマインダー、CIリンタ、使用法/DoDメトリック。任意の偏差インシデント→SOP更新タスク。