この記事の対象読者
- エラー通知をSlackなどのチャットツールに流したい人
- 通知文に何を書けばよいか迷っている人
- 通知を見た人がすぐ動ける形にしたい人
本題に入る前に
この話は、エラー通知をSlackなどのチャットツールへ流す設定を担当する人を想定しています。通知を受け取るだけでなく、見た人がすぐ調査に入れる通知文を考える立場の人に向けた内容です。
最近の開発現場では、メールよりもSlackやGoogle Chat、Microsoft Teamsのようなチャットツールで気づく運用が増えていると思います。障害やエラーの通知も、チームのチャンネルに流れると早く共有できます。一方で、流し方を間違えると、ただのノイズにもなります。
Slackに通知が流れてきた瞬間、「で、これは誰が何を見ればいいんだっけ？」となったことはありませんか？チャンネルに流すだけなら簡単ですが、見た人が動ける通知にするには、少しだけ設計が必要です。
たとえば、通知文に「エラーが発生しました」だけ書かれていても、見た人は次に何をすればよいか分かりません。通知は、情報共有であると同時に、調査のスタート地点でもあります。この記事では、Slackに流す前提で通知文をどう作るかを考えます。
この記事では、Cloud MonitoringからSlackへ通知する場面を中心に書きます。Google ChatやMicrosoft Teamsでも考え方は近いですが、連携方法はWebhookや中継サービスを使うなど構成が変わることがあります。具体的な設定は使っているツールの公式ドキュメントを確認してください。
Slack通知は届いてからが大事
エラー通知は、届けば終わりではありません。
チャットに通知が来ても、「何が起きたか」「どこを見ればよいか」が分からなければ、結局そこから調査が始まります。
Cloud Monitoringの通知チャンネルでは、メール、Slack、Webhook、Pub/Subなどの通知先を設定できます。Slack連携はSlack MarketplaceのGoogle Cloud Monitoringアプリとしても案内されています。
ここでSlackを例にするのは、エラー通知が「その場でチームに共有され、誰かが反応する」使い方と相性がよいからです。メールは記録として残しやすく、PagerDutyのようなオンコール管理ツールは緊急呼び出しに向いています。WebhookやPub/Subは、人ではなく別システムへ連携したいときに使いやすいです。
通知文に入れたい情報
最低限、次の情報があると動きやすいです。
| 情報 | 理由 |
|---|---|
| 何の処理か | 担当者を判断しやすい |
| エラー種別 | 緊急度を見やすい |
| requestId | ログ検索につなげやすい |
| 確認先 | 次の行動が明確になる |
Slackチャンネルを分ける
通知は、全部同じチャンネルに流せばよいわけではありません。
たとえば、すぐ対応が必要なものと、翌営業日に見ればよいものが同じ場所に流れると、重要な通知が埋もれます。
最初は、次のように分けるだけでも十分です。
| Slackチャンネル | 流すもの |
|---|---|
| 緊急確認用 | ユーザー影響がありそうなエラー |
| 運用確認用 | 日次で見たい失敗や警告 |
| 開発チーム用 | リリース直後に見たいエラー |
チャンネルを増やしすぎる必要はありませんが、「誰が見る通知か」は決めておくと運用しやすくなります。
通知文の例
予約同期エラーを検知しました。
operation: reservation_sync
errorCode: EXTERNAL_API_TIMEOUT
requestId: req_001
確認:
Logs Explorerで requestId を検索してください。
まとめ
Slack通知は、ただ流すだけだとすぐ埋もれます。
見た人が次に何をすればよいか分かる通知文にしておくと、調査の初動がかなり楽になります。