DECISION INTELLIGENCE FOR OPERATIONS

3ヶ月後、
あの判断は
再現できますか？

Decision Log は、運用現場で行われた 「判断・背景・捨てた選択肢」を記録し、 次のエスカレーションや障害対応で再利用できる形にします。

15分だけ話してみるSlackログ1件を無料でDecision Log化
#incident-db
監視オペ：「db-prod timeout alert 増えてます」
オンコール担当：「先週と同傾向かも。まず replica latency 確認して」
監視オペ：「replication lag 上がってます」
オンコール担当：「RDS再起動は最後。connection pool 確認を優先」
→ この判断文脈を Decision Log として構造化
The Gap

Runbook と
Postmortem の間にあるもの

Runbook

手順は残る。
しかし「どの観点を優先したか」は残りにくい。

Decision Log

判断・背景・捨てた選択肢を構造化し、 次の確認やエスカレーションで再利用する。

Postmortem

障害後の振り返りは残る。
しかし対応中の判断文脈は流れていく。

Reusable Escalation

繰り返される確認は、
判断が残っていないサインです。

同じエスカレーションが繰り返されるのは、 知識不足だけが原因ではありません。 過去に「何を優先して確認し、なぜその判断をしたのか」が 再利用可能な形で残っていないからです。

Before

「これ、前回もエスカレした気がするんですが…」

↓

After

「類似ケース確認済みです。前回と同じ観点で切り分けています」

REAL DECISION LOG

実際の判断ログは、
こう残る。

手順ではなく、「なぜその順序で確認したか」を構造化する。

# incident-db-timeout

Issue

db-prod の timeout alert が増加

Context

先週も類似アラートあり。CPUは正常、replica latency が上昇。

Rejected

・RDS再起動
・即時フェイルオーバー

Decision

connection pool と replica latency を先に確認

Reason

前回障害ではDB本体ではなく replica 側の遅延が原因だったため。

Result

設計担当への確認前に、前回と同じ観点で一次切り分けが完了。

SLACK TO DECISION LOG

今あるSlack運用を、
変える必要はありません。

新しい入力文化を作るのではなく、 既存のエスカレーションや相談の中から判断文脈を抽出する。

STEP 1

Slackで相談・エスカレーション

→

STEP 2

🧠 スタンプで保存候補化

→

STEP 3

Decision Log化

BEFORE / AFTER

属人化した運用を、
再利用可能な判断へ。

Before

・同じ確認が繰り返される

・Slackに判断文脈が流れる

・特定担当者に判断が集中

・エスカレーション時の確認観点が毎回ばらつく

After

・過去判断を検索・再利用

・背景ごと構造化

・判断の共有資産化

・過去ログを踏まえたエスカレーションが可能に

EARLY STAGE RESEARCH

運用現場向けに、
ヒアリングを実施しています。

現在、障害対応・エスカレーション・ 運用判断の再利用に関する 仮説検証を進めています。

15分だけ話してみるSlackログ1件を無料でDecision Log化