インシデントボットおよびチャット操作
1)目的と価値
インシデントボットは、企業のチャット(Slack/Teams/Telegram)から直接インシデント管理インターフェイスです。彼は次のとおりです:- ルーチンを自動化することによってMTTA/MTTRを減らします;
- 事実(SoT)と通信の単一のループを作成します。
- provability(監査、タイムライン、SLA更新)を提供します。
- コンソールのオンコールと「埋葬」の負荷を軽減します。
2)チャット操作における役割とRACI
インシデントコマンダー(IC)-インシデントオーナー:開閉、優先度、ソリューション。
Comms Lead (CL)-更新のテキストとスケジュール(外部/内部)。
ドメインリード(支払い/ゲーム/コア/インフラ)-技術的な事実と修正。
Scribe-タイムライン、アクションログ。
ボット管理者-ボットの権利/ポリシー/統合。
ルール:1つのインシデントには1つのICと1つのCLがあります。role reversal-明示的なbotコマンドによる。
3)エンドツーエンドのシナリオ
1.インシデントの開始:alert→'/incident new p1 "Deposits EU down'→ボットはカードを作成し、var-room、 IC/CLを割り当て、最初の更新のタイマーを設定します。
2.その他:'/incident add-facts'、'/incident status set degraded'、 '/incident assign@payments-lead'、'/incident timer 20m'。
3.通信:'/incident publish status '(draft CL)、 '/incident partners notify'、 '/incident regulator draft'。
4.'/runbook psp-failover PSP1→PSP2'、'/feature toggle replay-center off 60m'、 '/traffic shift 30% eu→uk'。
5.クロージングとポストモーテム:'/incident resolve'、自動収集タイムライン、'/postmortem generate'。
4)ボットコマンド(コア)
作成/分類
'/incident new p{1|2|3|4} 「
'/incident severity set p2'、'/incident tag add payment、 psp'
所有権と役割
'/incident ic@user'、'/incident comms@user'、 '/incident assign@user [domain]'
タイマーとSLOの更新
'/incident next-update 15m'、'/incident remind' (bot pings CL)、 '/incident eta set 18: 30'
事実と状況
'/incident fact 'auth-success PSP1 -25% TR/EU'、 '/incident status{調査中'分解'monitoring 'resolved}'
Commパック
'/incident draft public 'partners' regulator'、'/incident publish'
インテグレーション
'/runbook
閉鎖/死後
'/incident resolve [reason=……]'、'/postmortem generate'、 '/postmortem assign@owner'
5)統合(最低必要)
監視:アラート、SLI/SLO(バーンレート)、ダッシュボードへのリンク。
インシデントマネージャ(ITSM):双方向ステータス/フィールド同期。
ステータスページ:CL (policy-gate)を介したドラフトとパブリッシング。
プロバイダ(PSP/KYC/Game Studios):連絡先ディレクトリ、クイックレター/チャンネル。
リリース/フィーチャーフラグ:カナリア停止/プルバック、リリースリンク。
ランブック/自動修復:ガードレール付きの安全アクションカタログ。
CMDB/オーナー:ドメインリードの自動割り当て、エスカレーション。
タイムラインストレージ:監査/死後のWORM/immutable。
6)ボットアーキテクチャ
ゲートウェイ(チャットアダプタ):Slack/Teams/Telegramインターフェイス。
Command Parser+Policy Engine:認可、検証、SoD、公差。
オーケストレータ:インシデントシナリオ、タイマー、リマインダー。
統合レイヤー:ITSM、監視、ステータスページ、リリース、ランブックへのクライアント。
証拠ストア:イベント、事実、メッセージ拡散、添付ファイル(WORM)。
指標と監査:品質指標、アクションログ、コマンドトレーシング。
7)ポリシー、権利およびセキュリティ
RBAC/ABAC:作成/クローズ、重大度の変更、外部公開を行うことができます。
SoD: Comms publishにはCLロールが必要です。ハイリスクなアクション(PSPルーティング、PIIエクスポート)-デュアルコントロール。
JITの権利:事件時にドメインリーダーへの一時的な発行。
署名と暗号化:システムへのwebhook/requests-HMAC/mTLS。
脂肪指の保護:アクションのための危険なコマンド、ドライランとTTLの確認。
PII衛生:下書き/ログでマスキング;オープンチャンネルでのPII阻害。
8)オートメーションフロー(例)
Alert P1→botはvar-room('#inc-2025-11-01-001')、 ping on duty (IC、 CL、 Payments/Infra)を作成します。
ダッシュボード/SLIをバインドし、ITSMでチケットを開き、最初の公開更新用のテンプレートを準備します。
タイマーを設定します:「15分で次の更新」、CLリマインダー。
runbooks: 「PSP reroute 30%→PSP2,」 「degrade replay-center」「、autoscale settle-workers」。
公開時-テキストのバージョンを修正し、ステータスページ/ソーシャルネットワーク(CL経由)に公開します。
閉じるとき-タイムライン、メトリクス、死後のドラフト、VIP/パートナーの郵送を収集します。
9)タイムラインと実証性
各イベントは'T+mm: description、 author/bot、 command、 result、 links'と記録されます。
メッセージの編集(diff)、リリース/フィーチャーフラグ/計画作業へのバインディングがサポートされています。
輸出:監査および規制当局のためのPDF/CSV。
10)メトリクス(KPI/KRI ChatOps)
MTTA (chat): alert to '/incident new'。
MTTS(セットアップ):varルームの準備が整い、ロールが割り当てられる前に。
Cadence adherence:公開更新間隔の遵守。
Runbook使用率:自動化された活動を伴うインシデントの割合。
一貫性スコア:チャネル間の不一致=0-ターゲット。
Pager fatigue: SLOと同じ/より良いマニュアルページャを削減しました。
Postmortem SLA: D+5 ≤収集された死後の割合。
11)テンプレートカタログ(フラグメント)
P1の作成:
/incident new p1 "Deposits EU down" components=payments,deposits regions=EU
最初の公開アップデート(CL経由):
/incident draft public
/incident publish public
PSPルーティングとフィーチャーの劣化:
/runbook psp-failover PSP1→PSP2 30%
/feature toggle replay-center off 45m
死後:
/postmortem generate
/postmortem assign @owner
12)プロセスに埋め込むこと
コミュニケーション:インシデント通信とシステムステータスページへのリンク。
観測性:SLO/SLIおよび合成への速いリンク;グラフの自動添付。
アラート:P1/P2中のインシデントの自動作成;一つの信号の流れです。
自動修正:ガードレールとロールバック付きのワンボタンランブック。
ワークフローエンジン:ヒューマンタスク(4眼)、エスカレーションタイマー、チェックリスト。
13)導入ロードマップ(4〜8週間)
ネッド。1-2: MVPチーム:'/incident new'、ロール(IC/CL)、 varルーム、更新タイマー、ITSMとの通信、監視。
ネッド。3-4:メッセージテンプレート(公共/パートナー/規制当局)、ステータスページ(chernovik→publikatsiya)、カタログ5-7ランブック。
ネッド。5-6:ポリシーアズコード(RBAC/SoD/JIT)、高リスクでのデュアルコントロール、WORMマガジン、ChatOps KPIダッシュボード。
ネッド。7-8:卓上P1/P2演習、リリース/フィーチャーフラグとの統合、死後の自動コレクション、ローカリゼーション。
14) Antipatterns
ガードレールなしの「すべてのボット」→ランダムな危険なアクション。
CL/Legal-reviewの役割を持たないステータスページへの投稿。
ログ/バージョンのないコマンド→提供不能。
チャットの複雑なフォーム(20+フィールド)-速度が低下します。より良い短いコマンド+リンク。
P1には更新タイマー→「沈黙」はありません。
CMDB/所有者の統合→割り当てカオスの欠如。
15)ボトムライン
Incident-botとChatOpsは「bot with commands」ではなく、オペレーティングプラットフォームです。インシデントの迅速な開始、規律の更新、安全な制限のある自動化されたアクション、エンドツーエンドの可視性、および証明性です。このような回路は予測的にMTTRを削減し、通信の品質を向上させ、ピーク時にiGamingビジネスの収益を保護します。