アラートと障害応答
（セクション： 技術とインフラ）
概要
強力なアラートは、単なる「レッドメトリック」ではなく、ユーザー価値の侵害のシグナルです。"iGaming、 SLOゲート（レイテンシー、可用性、支払い変換、タイムツーウォレット）、マルチバーンルール、クリアオンコール、エスカレーション、ChatOps、ランブックの役割が重要です。目標は、すばやく偏差を確認し、修正できる人に通知し、次回より速く、より安価に反応するために知識を修正することです。
1）基本： メトリックからアクションまで
SLI→SLO→アラート-測定品質→目標レベル→「予算はオン」状態。
重症度（SEV）： SEV1-クリティカル（リスク時の収益/GGR）、 SEV2-深刻、SEV3-中程度、SEV4-マイナー。
影響/緊急性：誰が苦しんでいるのか（すべて/地域/テナント/チャネル）とどのように緊急（TTW#、p99#、エラー-レート#）。
Actionability：アラームごとに-特定のアクション（runbook+owner）。
2）シグナルタクソノミ
ТехSLO： p95/p99レイテンシAPI、エラーレート、彩度（CPU/IO/GPU）、キューラグ。
BusinessSLO：支払いコンバージョン（試み→成功）、Time-to-Wallet （TTW）、賭け成功、ゲームの立ち上げ。
支払ルート：PSP固有の指標（タイムアウト/降格スパイク）。
フロント/モバイル：RUMメトリクス（LCP/INP）、クラッシュレート、シナリオ合成（ログイン/デポジット/レート/出力）。
3）警告ポリシー： SLOとバーンレート
SLI/SLOの例
Payments-apiの可用性≥ 99。9 ％/30d p95 '/deposit '≤ 250 ms/30d
'payments_attempt→success ≥ baseline − 0の変換。3 ％/24h
TTW p95 ≤ 3 分/24h
マルチ・ウィンドウ/マルチ・バーンPromQL)
Fast burn： SLO違反5-10 ×通常よりも速い（5-15分でアラートページ）。
スローバーン：低速予算バーンアウト（チケット+分析1〜3時間）。
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }4）騒音低減と信号品質
真実の正しいソース：重い「生」式ではなく、集計（レコーディングルール）によって変更します。
重複排除-'service/region/severity'によるAlertmanagerグループ。
階層：ビジネス/SLIへの最初のアラート、以下-診断としてのテクニカルメトリック。
抑制：計画メンテナンス/リリース中（注釈）、アップストリームインシデント中。
Cardinality：アラートラベルで'user_id/session_id'を使用しないでください。
テストアラート：通常の「トレーニング」トリガー（チャンネル、ロール、runabookリンクのチェック）。
5） Alertmanagerのルーティングとエスカレーション
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]アイデア：SEV=page→PagerDuty/SMS；残りはSlack/ticketです。抑制は、上記のアクティブなSEVで下位レベルの「誇大宣伝」を抑制します。
6）グラファナ警報（付加的な層として）
ダッシュボード（Prometheus/Loki/Cloud）の一元化されたアラート規則。
コンタクトポイント：PagerDuty/Slack/Email、フォルダごとの通知ポリシー。
サイレンス：計画された作品、移行、リリース。
チケットにパネルの自動スクリーンショットがあるスナップショット。
7）オンコールおよびライブプロセス
回転：第1ライン（SRE/platform）、第2ライン（サービス所有者）、第3 （DB/Payments/Sec）。
SLA反応：認識≤ 5分（SEV1）、診断≤ 15分、通信15-30分毎。
デューティチャンネル：'#incident-warroom'、'#status-updates'（事実のみ）。
Runbooks：各アラートのリンク+ChatOpsクイックコマンド（'/rollback'、'/freeze'、 '/scale'）。
訓練警報：毎月（人々、チャネル、runabookの関連性を点検すること）。
8）インシデント： ライフサイクル
1.検知（アラート/レポート/合成）→通話を承認します。
2.トリアージ：SEV/影響を受けた/仮説、オープン戦争部屋を決定します。
3.安定：ロール/ロールバック/スケーリング/phicheflags。
4.コミュニケーション：ステータステンプレート（下記参照）、ETA/次のステップ。
5.閉じる：SLO回復の確認。
6.事後レビュー（RCA）： 24-72時間後、料金はかかりません、アクション項目。
- 壊れたもの/影響を受けるもの（地域/テナント/チャネル）
- 開始時/SEV
- 一時的な対策（緩和）
- N分の次のステータス更新
- コンタクト（インシデントマネージャー）
9） iGamingの詳細： 「痛み」ゾーンとアラート
支払い/TTW： PSPタイムアウトのシェア、コード障害の増加、TTW p95> 3m。
トーナメントのピーク：p99 API/ゲームの開始時間/キューラグ；限界/自動スケールの促進。
資金の結論：バックホー/マニュアルチェックのSLA、国による制限。
ゲームプロバイダ：スタジオによる可用性、セッションの初期化時間、ローンチドロップ。
RG/コンプライアンス：長いセッションのバースト/」ドゴン」、しきい値を超える-ページではなく、RGチームへのチケット+通知。
10）ルール例（オプション）
高遅延P95 （API）
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"リードキュー「on」
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"お支払いコンバージョン
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"11） ChatOpsとオートメーション
アクションボタンによる自動投稿アラート：カナリア、ロールバック、スケール+Nを停止します。
コマンドの略語： '/incident start'、'/status update'、 '/call
ボットはコンテキストを引き締めます：最新のデプロイ、依存関係グラフ、例、関連するチケット。
12）事件後の作業（RCA）
Factbox：タイムライン、見たもの/試したもの、働いたもの。
根本原因：技術的および組織的な理由。
検出と防御：どの信号が役に立ったか、失敗したか。
アクションアイテム：特定のタスク（SLO/alerts/codes/limits/tests/runabook）。
期日と所有者：利用規約と責任；2-4週のフォローアップセッション。
13）実装チェックリスト
1.キーストリーム（API/Payments/Games/TTW）のSLI/SLOを定義します。
2.録音ルールとマルチ書き込みアラート+Alertmanagerルーティングを設定します。
3.回転、反応SLO、エスカレーションでオンコールを入力します。
4.アラートをrunbooksコマンドとChatOpsコマンドにリンクします。
5.抑制/静かなウィンドウ、リリース/作業アノテーションを構成します。
6.学習アラームとゲームデイシナリオ（PSPドロップ、p99上昇、キューラグ上昇）を作成します。
7.アラート品質を測定：MTTA/MTTR、％ noisy/false、 SLOによるカバレッジ。
8.通常のRCAと閾値/プロセスの改訂。
9.ビジネス/サポートの通信状況（テンプレート）を入力します。
10.すべてをコードとして文書化する：ルール、ルート、runabookリンク。
14）アンチパターン
「every metric→」alert-fetigで警告し、無視します。
SLOがない→何が「普通」で、何が「炎上」であるかは明らかではない。
抑制/抑制→雪崩の重複はありません。
夜のマイナーイベントのページ（SEVはImpactに匹敵しません）。
runbook/ownerなしのアラート。
ChatOps/監査のない「手動」アクション。
RCA/アクションアイテムなし→リピートインシデント。
概要
アラートと応答はプロセスであり、ルールのセットではありません。SLOとマルチバーンアラートをリンクし、明確なオンコールのエスカレーションを構築し、ChatOpsとライブrunabookを追加し、定期的にRCAとトレーニングセッションを実施します。その後、インシデントはそれほど頻繁ではなく、短くて安くなり、iGamingの暑い時間でもリリースはより予測可能になります。