「深夜3時のアラートで叩き起こされ、原因もわからぬまま泥沼の調査を始める」。そんなエンジニアの悪夢を終わらせる時間です。
こんにちは。システム監視の深淵を覗き続けてきたオブザーバビリティ・アーキテクトです。今回は、PagerDutyのような高額なツールに依存せず、Grafana OnCallを使って「インシデント管理を自動化し、エンジニアを過労から守る」ための極意を伝授します。
これは単なるツールの導入手順ではありません。「アラート疲れ（Alert Fatigue）」を根絶するためのアーキテクチャ設計です。
—
1. なぜ「Grafana OnCall」なのか？
オブザーバビリティの世界では、「監視ツールがいくら優れていても、通知が適切でなければゴミ同然」という鉄則があります。
Grafana OnCallは、Grafanaエコシステムの一部でありながら、非常に軽量で強力です。
- コスト効率: OSS版をセルフホストすればコストはほぼゼロ。
- 文脈の保持: ダッシュボードとシームレスに連携し、アラート発生時のグラフを通知に添えられる。
- エンジニア体験: SlackやTelegramと統合し、ボタン一つで「ACK（確認）」「解決」を完結できる。
—
2. 最初のセットアップ：心臓部を作る
まずはGrafana Cloud、あるいはDocker環境でOnCallを立ち上げます。ここでは最も迅速に全体像を掴めるDocker構成の要点を解説します。
インストール（docker-composeの要点）
最小構成で動かす際は、以下のコンポーネントが重要です。
docker-compose.ymlの抜粋
services:
oncall:
image: grafana/oncall:latest
ports:
- “8080:8080”
environment:
- BASE_URL=http://localhost:8080
- SECRET_KEY=your_secure_random_key # 本番では必ず環境変数で管理すること
# メッセージキュー（RabbitMQ）やDBとの連携が必須となります
—
3. エスカレーションポリシー：深夜の「無駄な叩き起こし」を排除する
多くの現場が失敗するのは、「とりあえず全員に通知を送る」という設計です。これは最悪です。「適切なタイミングで、適切な人に、最小限のノイズで」届けるのがプロの流儀。
ステップ1: On-Callローテーション（誰が担当か）
「ユーザーグループ」を作成し、交代制（シフト）を組みます。
- 戦略: 1週間交代でプライマリ担当を決め、OnCallに自動的にスイッチングさせます。
ステップ2: エスカレーションポリシーの構築（神髄）
ここで「精度」が決まります。以下のような設計が理想的です。
1. Level 1 (0分後): Slackに通知。担当者がACKボタンを押すのを待つ。
2. Level 2 (10分後): 担当者が動かない場合、Telegramや電話へエスカレーション。
3. Level 3 (20分後): チーム全体、あるいはマネージャーへ通知。
現場の知見: 10分という猶予は「トイレに行っているかもしれない」「ちょっとした休憩」を考慮した人間的なバッファです。短すぎると「オオカミ少年」になり、長すぎると障害対応が遅れます。
—
4. HelloWorld: 最初の通知を飛ばす
ツールが導入できたら、まずは手動でテストしましょう。
1. Integrationの作成: Grafana Dashboardの「Alerting」から「OnCall」を選択し、Webhook URLを発行します。
2. Payloadを投げ込む: 以下は、GrafanaからOnCallへアラートを送る際のJSONイメージです。
{
“title”: “CPU使用率が80%を超過しました”,
“message”: “高負荷状態が5分継続しています。ダッシュボードを確認してください。”,
“image_url”: “https://your-grafana-url/render/d-solo/…”,
“severity”: “critical”
}
この通知がSlackに飛び、[Ack]ボタンを押してアラートが静まり返るのを確認してください。この瞬間、あなたの運用コストは劇的に下がります。
—
5. 伝説のエンジニアからのアドバイス：運用の美学
最後に、これから始める君たちへ。「アラートを減らすこと」こそが、最高のオブザーバビリティです。
- ノイズを捨てる: 全てのアラートをOnCallに流さないでください。「直ちに人間が行動すべきか？」を自問自答し、そうでないものはSlackのログチャンネルへ流すだけに留める。
- 事後分析（Post-Mortem）: OnCallが鳴るたびに、「なぜ鳴ったのか？」「次は自動復旧できないか？」を議論する。OnCallは障害を検知するためのものではなく、システムを自己修復させるためのトリガーであるべきです。
—
Grafana OnCallは単なる通知ツールではありません。君たちの「睡眠」と「精神的な余裕」を守るための盾です。まずは小さなチームで、一つのエスカレーションポリシーを作るところから始めてみてください。
さあ、退屈な監視業務を卒業して、よりクリエイティブな開発に没頭しましょう。応援しています！