フランスの現場で使う障害メモを日本語運用に寄せた話

フランスの小規模チーム（自分を含めて5人、パリとリヨンで2拠点）で、障害対応の記録を共有する運用を回している。ツールはSlackとNotionで、障害メモはNotionのデータベースに1件1ページで残す形にしている。対象は月に2〜4件程度の軽微な障害で、影響範囲は数百ユーザー規模。以前はSlackのスレッドに時系列で書き込んでいたが、翌週には「結局なにが原因だったか」を探すのに10分以上かかっていた。

やったことは3つ。まずNotionのデータベースに以下のプロパティを固定した。

事象: タイトル（現象を1行で）
発生日時: 日付（Europe/Paris）
検知: セレクト（監視/ユーザー報告/内部）
影響: セレクト（小/中/大）
原因: テキスト（1〜2文）
対応: テキスト（実施したこと）
再発防止: テキスト（未着手なら空）

次に、Slackの障害チャンネルに投稿するときの雛形を固定した。

【障害】<現象を1行>
検知: 監視 / ユーザー報告 / 内部
影響: 小 / 中 / 大（対象: 機能名）
初動: 誰が何をしたか
次アクション: 誰がいつまでに

最後に、対応が落ち着いた時点でNotionのページに転記する担当をローテーションにした。転記は5分以内で終わる粒度にしている。

なぜこうしたか。Slackのスレッドは時系列の会話としては優れているが、後から検索する用途には向かない。Notion側に「原因」と「再発防止」を必須に近い形で置くことで、次に同じ現象が起きたときに過去ページを開けば済む。代わりに、対応中はSlackとNotionの二重管理になる。転記を忘れると情報がSlackにしか残らないので、ローテーションの担当が翌営業日に確認する運用にした。

どこで失效するか。1つは、障害が長引いて対応が翌日以降にずれ込むケース。転記のタイミングが曖昧になり、結局Slackのままになる。もう1つは、原因が外部サービス側で「再発防止」が書けないケース。空欄を許す設計にしたが、空欄が続くと項目自体が見られなくなる。自分が踏んだのは、日時をParis時間で入れたつもりが一部UTCで混在していたこと。並べ替えが崩れて過去ページを探すときに混乱した。

いま気になっているのは、転記の負荷をどこまで下げられるか。Slackの投稿からNotionページを半自動で作る程度はできそうだが、原因と再発防止まで自動化するのは無理がある。手で書く項目を最小限に絞る方向と、転記自体をなくしてSlackを一次情報にする方向のどちらが現実的か、同じ規模で回している人の話を聞いてみたい。