Sentry × Slack × GitHub：障害通知を「見た」で終わらせず、修正と再発防止まで閉じる

障害対応で一番危ないのは、通知が届かないことではない

監視を入れると、エラー通知は届くようになります。

しかし通知が届くだけでは、運用は完成していません。

実際には、

• 誰かが見た
• でも担当が決まっていない
• Slackで会話した
• 一時対応した
• Issueを作り忘れた
• 同じ障害が数日後に再発した

ということが起きます。

Sentry、Slack、GitHubを組み合わせるなら、価値は「通知を増やすこと」ではなく、検知から修正まで状態を途切れさせないことにあります。

役割を分ける

• Sentry：何が壊れたかを検知する
• Slack：人間が気付き、共有・判断する
• GitHub：修正作業と恒久対応を追跡する

この3つを混ぜると運用が曖昧になります。

Sentryはタスク管理ツールではなく、Slackは障害台帳ではなく、GitHubはリアルタイム通知画面ではありません。

それぞれの得意な場所へ状態を渡します。

通知は全部Slackへ流せばよいわけではない

エラーを全部流すと、数日で誰も見なくなります。

Slackへ出す対象は、たとえば次のように絞ります。

即時通知

• 本番500急増
• ログイン不能
• 決済失敗
• データ保存失敗
• エラー率が閾値超過

まとめ通知

• 単発例外
• 低頻度warning
• パフォーマンス劣化候補

通知不要

• 既知で無視すると決めたイベント
• bot由来のノイズ
• 開発環境だけのエラー

通知量を減らすことは、監視を弱くすることではありません。

本当に見るべき通知のS/Nを上げることです。

Slackへ出すメッセージに必要な情報

悪い通知はこうです。

Error occurred.

これでは何も判断できません。

最低限、

• 何が起きたか
• 影響環境
• 発生件数
• 最初の発生時刻
• 直近リリースとの関係
• Sentryへの参照
• 今すぐ見るべきか

が欲しいところです。

たとえば、

本番 /api/profile の500が10分で42件。v1.8.2以降に増加。ユーザープロフィール保存へ影響の可能性。

なら、優先度を判断できます。

「誰か見た」を状態として残す

Slackのリアクションだけでも、最低限のacknowledgeに使えます。

ただし、重大障害なら状態を明確にします。

detected → acknowledged → investigating → mitigated → fixed → verified → closed

このどこにいるか分かるだけで、二重対応や放置が減ります。

小規模チームでは専用インシデント管理製品を入れなくても、まずこの状態だけ決めればかなり違います。

恒久修正が必要ならGitHubへ移す

Slack上で「原因これっぽい」「とりあえず再起動した」で終わると、再発します。

恒久対応が必要ならGitHub Issueへ移します。

Issueには、

• 症状
• 影響
• 発生条件
• Sentry証拠
• 一時対応
• 原因候補
• 完了条件

を残します。

これで、リアルタイム会話と恒久対応を分離できます。

緊急対応と恒久対応を分ける

障害時には「今すぐ止血すること」と「根本原因を直すこと」が同じとは限りません。

たとえばDB接続数が枯渇した場合、

緊急対応

• 問題プロセスを再起動
• 同時実行数を一時制限

恒久対応

• connection leak修正
• pool設定見直し
• 回帰テスト追加
• alert閾値調整

に分かれます。

Slackでは緊急対応を共有し、GitHubでは恒久対応を追う、と分けると整理しやすいです。

PRで終わりにしない

コードをmergeしても、本番で直ったとは限りません。

完了条件には、

• deploy済み
• Sentryイベントが再発していない
• エラー率が正常化
• 影響機能を手動確認

まで含めます。

つまり、

PR merged ≠ incident closed

です。

本番で正常化したことを確認して初めて閉じる方が安全です。

再発防止では「なぜ検知できたか」も見る

障害後の振り返りでは原因だけでなく、

• 何分で検知できたか
• 何分で担当が気付いたか
• 何分で影響を止めたか
• 何分で恒久修正したか

を見ます。

代表的な指標は、

• MTTD：検知まで
• MTTA：認知まで
• MTTR：復旧まで

です。

小さなチームなら厳密なSRE制度を作らなくても、この3つだけ記録すると改善しやすくなります。

通知疲れをKPIに入れる

監視は、通知数が多いほど良いわけではありません。

たとえば1日100件通知が来て、重大通知が1件なら見落としやすい。

そのため、

• 1日あたり通知数
• acknowledgeされた割合
• 実際に対応が必要だった割合
• 同じ原因の重複通知数

を見ます。

不要通知を減らす作業も、障害対応力を上げる仕事です。

小規模チーム向けの最小運用

最初から大きなインシデント管理制度は不要です。

まずは、

1. Sentryで重大条件を決める
2. Slackの専用チャンネルへ通知
3. 誰かがacknowledge
4. 15分以上残る問題はGitHub Issue化
5. 修正PRへIssueを紐付け
6. deploy後にSentryで再発確認
7. close

だけでも十分です。

次の一手

直近の本番エラーを1件選び、過去の流れを逆算します。

• いつ検知したか
• 誰が気付いたか
• Slackで何を話したか
• 修正タスクは残ったか
• 本番で直った確認をしたか

どこか1か所でも記録が切れているなら、そこが改善点です。

Sentry × Slack × GitHubの価値は、ツールを3つ使うことではありません。

「壊れた」という事実が、誰かの記憶に依存せず、修正と確認まで流れ続けることにあります。