標準的な操作手順

1） SOPとは何か、なぜ必要なのか

SOP （Standard Operating Procedure）は、入力/出力、ロール、品質基準を理解した、再現可能な操作のための手順の形式化された検証されたシーケンスです。

• 実行の可変性とリスクを低減します。
• 既製のアクションを使用してMTTA/MTTRを削減します。
• コンプライアンスと監査：再現性、トレーサビリティ。
• オンボーディング：学習と影の加速→ソロ。

SOP ≠ playbook： playbook-decision tree with forks、 SOP-特定のシナリオ（またはplaybookブランチ）の線形規則。

2）よいSOPの原則

成果主導：ステップだけでなく、結果（SLO/ビジネス基準）に焦点を当てます。
Unambiguity：コマンド、パラメータ、期待される効果と制御点。
デフォルトでセキュリティ：ゲート、制限、バックアウト/ロールバックが登録されています。
最小コンテキスト：ショートノート+詳細なランブック/診断へのリンク。
関連：レビュー日、所有者、バージョン、有効期限。
実行可能性：JIT/JEAアクセス、前提条件チェック、アーティファクトテンプレート。

3） SOP標準構造（スケルトン）

ID/Version/Review Date
Name and short purpose (what and why)
Scope (Services/Regions/Tenants, SEV/Risk)
Roles and Responsibilities (RACI: R/A/C/I)
Preconditions (accesses, windows, stage, reserve, artifacts)
Materials/tools (dashboards, feature flags, repos, keys)
Quality gates (SLO-gardrails, quorum of probes, alerts)
Step-by-step instruction (step → command → expected result → verification)
Branches (if X - perform Y) [minimum]
Backout/Rollback (start conditions, steps, verification)
Communications (who, when, where; message templates)
Evidence (what to save: screenshots, logs, chexums, links)
Completion (success criteria, watching who closes the ticket)
Change History (What, By Whom, and Why)

4） SOPディレクトリと所有権

タグ付きの単一のリポジトリ（Docs-as-Code）： 'domain/ops'、 'service/checkout'、 'risk/high'、 'provider/psp-a'。
所有者カード：チーム、デューティ連絡先、バックアップ所有者。
SLA関連性（例：≤ 90日ごとまたはインシデント/リリース後にレビュー）。
Linter/SOPバリデータ（CI）：構造、リンク、所有者、レビュー期間の検証。

5） SOPライフサイクル

1.開始（インシデント/ドリル/新しいプロセスの後）。
2.Draft （author=service/process owner）。
3.レビュー（SRE/Security/Legal/Comms-ドメイン別）。
4.パイロット（卓上/ゲームの日）：測定時間、検索→編集。
5.発行（CMDB/サービスカタログのバージョン、日付、番号、テンプレート）。
6.運用アプリケーション（チケット/チャットの注釈、証拠収集）。
7.更新（RCA/CAPA、レビュー期限、アーキテクチャ変更による）。
8.アーカイブ/枯渇（新しいSOP/プレイブックに置き換えられます）。

6）隣接するアーティファクトとの接続

プレイブック：SOP-プレイブック内の「リニアブランチ」；ステップから参照してください。
Runbook'と：技術的な詳細/スクリプトはrunbookに配置され、SOPは参照します。
ポリシー（Policy-as-Code）：アクセスゲート、アクセス許可、RBAC-必須リンク。
SLO/SLI：成功基準とガードレール。
エスカレーションマトリックス：SOP実行に失敗したロール/タイミング。
メンテナンスウィンドウ：高リスクSOPのためのスロット/コンマ要件。

7） SOPパフォーマンス指標

Time-to-Execute（中央値/p95）-プロシージャにかかる時間。
成功率-エスカレーション/ロールバックなしの成功率。
証拠の完全性-アーティファクトの充実。
SLOインパクト-ステップ中またはステップ後に劣化がある場合（燃焼分）。
欠陥密度-10 SOPでのレビュー/練習ノート。
鮮度は、≤ 90日のレビューでSOPの割合です。
採用-実際にSOPに関連付けられているアラート/ウィンドウの数。

8） SOP作成者チェックリスト

• 定義された目的とアプリケーションの境界。
• ロール、アクセス、ウィンドウ-説明。
• 質のゲートおよびSLOは測定可能、信号源があります。
• ステップ実行可能ファイル：コマンド/スクリプト、期待される結果、検証。
• バックアウト/ロールバックと起動条件-クリア。
• Commテンプレートが添付されています。
• 証拠リストは構造化されている。
• バージョン/日付/所有者/レビューが指定されています。

9） SOPチェックリスト

• JIT/JEAの前提条件とアクセスを確認しました。
• チケット/ウォールルームはオープンで、注釈が含まれています。
• 可視性：必要なダッシュボード/アラートが開いています。
• 私は順番に手順に従ってください。各後-検証。
• ガードレール違反の場合-即時のバックアウトとエスカレーション。
• 証拠はいっぱいです。最終的なSLO/ビジネスSLIチェック。
• チケットは終了しました、ステータスページ/commsが更新されました。

10） SOP例（フラグメント）

10.1 SOP：カナリアリリースロールバック（REL-ROLLBACK-01）

The goal: to return the stable version when the burn-rate is exceeded or the p99 grows.
Scope: checkout-api service (prod, EU).
Roles: Release (R), IC (A in SEV-1), P1 (R), Comms (I).
Preconditions: feature flags are ready; JEA accesses; release-annotations included.
Gates: slo. payment_success, http_p99; quorum synthetic EU/US + RUM.
Steps:
1) Freeze unrelated depleys.
2) rollback to tag v2. 3. 7 (command...) → waiting 5 minutes.
I expect: p99↓, error_rate↓, burn-rate <threshold.
3) Business SLI check (payment success, conversion) 10 min.
4) Remove the suppression of alerts; update release annotation.
Backout: if rollback does not help - escalate to IC, enable degrade-UX, consider failover.
Comms: "Rolled back; metrics stabilize; next update in 15 minutes."
Evidence: before/after screenshots, link to dashboards, command and output.
Completion: 30 min green SLOs; close the ticket; assign an RCA (if SEV-1).
Version: 1. 6 (2025-10-28)

10.2 SOP：スケジュールされたDBアップグレード（MW-DB-UPGRADE-02）

Purpose: update PostgreSQL minor without data loss.
Area: payments-db (prod EU), 02: 00-04: 00 Europe/Kyiv.
Roles: DB Lead (R), SRE (C), Service Owner (A), Comms (R clients).
Preconditions: OK backups; replica in sync; Test upgrade passed.
Gates: lag≤30s, error_rate<0. 5%, p99 <400ms, SLO green 30m.
Steps:
1) Transfer traffic to canary replica 1%→5%→25%; SLI monitoring.
2) Consistently upgrade secondary nodes → switch over → upgrade of the former primary.
3) Restore replication, check consistency.
Backout: promote stable replica; return writer; rolling back packets.
Comms: T-7/-2 days and T-60/-15 min alert; updates q = 30m during the window.
Evidence: migration logs, checksums, p95/p99 graphs.
Completion: observation 60m without burn; MW report with evidence.
Version: 2. 1 (2025-09-12)

10.3 SOP： PSPプロバイダスイッチング（PROV-PSP-SWITCH-01）

Objective: to maintain payment success_ratio in case of PSP-A degradation.
Trigger: PSP-A red/partial status + success_ratio% ≥2 drop.
Steps:
1) Install weights: PSP-A 30%, PSP-B 70%.
2) Turn on the degrade_payments_ux; enhance retrays (within SLA).
3) Monitor fraud_rate/chargeback-risk 30m.
Backout: Regain weights at green SLI 60m.
Comms: status page (first ≤15m, cadence 30m).

10.4 SOP：バックアップ・リカバリ・チェック（DATA-BACKUP-RESTORE-CHECK-03）

Objective: weekly verification of recoverability.
Steps: lift from backup in isolation → hash control → consistency requests → report.
Success criterion: time-to-restore ≤ 45 min; 100% integrity.

11） SOP周辺の自動化

SOPテンプレート：RACI/gates/conmaブロックを使用したスケルトン生成。
ボットパフォーマー：チェックボックス、タイマー、ケイデンスリマインダー、証拠自動コレクションのステップ。
CMDB/Catalog-Serviceとの統合には、関連するSOPのリストがあります。
テレメトリー注釈：「SOP-RUN： <ID> ステップN」→クイックパース。
入場ポリシー：デプロイメント/ウィンドウは緑のSOPゲートでのみ開始されます。

12）アンチパターン

所有者/日付レビューなしのSOP-「死んだ」ドキュメント。
成功基準とバックアウトのない膨らんだ指示。
一貫性のないコマンド/キー-エラーやリークのリスク。
Wikiとリポジトリの異なるバージョンは、真実のソースの発散です。
証拠なし-品質/コンプライアンスを確認するものは何もありません。
「すべてのケースに1つのSOP」-実行可能性が失われます。

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

1.ネッド。1： SOPの型板、リンターおよびカタログを承認して下さい；トップ10のシナリオを選択します。
2.ネッド。2：リリース/ロールバック/プロバイダ/バックアップのSOPを作成する。卓上パイロット。
3.ネッド。3： ChatOpsボットとテレメトリー注釈を接続する。SOPにアラートを関連付けます。
4.ネッド。4：四半期ごとのレビュースケジュール；Freshness/Success Rateメトリックを入力します。
5.ネッド。5-6：重要な操作の90％をカバーして下さい；DR/Security-SOP；証拠収集を自動化します。

14）ボトムライン

SOPは、一様な品質ゲート、詳細なステップ、明示的な役割、可逆性などの操作を予測可能かつ検証可能にします。プレイブック、政治家、SLO、オートメーションと連携して、これは操作を信頼できる生産ラインに変えます。迅速な反応、最小限のリスク、理解可能な責任。