Opsgenie を使って 障害対応の負担を軽くする取り組み

こんにちは、食べログSREチームの @yzusa です。

## この記事は ...

食べログでOpsgenieを導入した時に

* 何がしたかったのか？
* どんな機能が重要だったのか？
* 導入して良かったこと
* 今後やりたいこと

をまとめた記事です。
システム障害と日夜闘うみなさんのご参考になれば幸いです。

## そもそもOpsgenie ってなに？

> ・オンコール管理とアラート管理によりサービスを常に「利用可能」に。
> ・アラートを統合し、適切な人に適切なタイミングで通知

[公式サイト](https://www.atlassian.com/ja/software/opsgenie)のキャッチコピーは大きくこの２つですが、
つまり『そのインシデントに、いつ誰が対応するのか？』をより分かりやすく、そして確実に運用するためのサービスです（と解釈しています）。

## 導入の動機

今年で１５年目を迎える食べログですが、おかげさまでたくさんのユーザの皆様にご利用いただいています。その分、実装されている機能やバッチの本数も多くなるので、それぞれ担当チームが障害の定義を考え、アラートを出すようしているのですが、基本的には緊急度の高いアラートもメールで受け取っているため、

* 受け取るメンバーが必要以上に多い
* 対応がちゃんと進んでいるかが不明瞭

という課題がありました。

『対応しなくてよいアラートに、重要な通知が埋もれてしまう』『対応を始めたら、実は他の人も同じことをやっていた』などのちょっと残念なシチュエーションも散見されました（ある程度の規模の開発チームでは起こりがちですね）。

そこで、

* 不要な通知をなるべく少なくする
* 対応状況がすぐに分かる

を実現するために、Opsgenie を導入したいと考えました。

## 重視された機能

###  柔軟なオンコールスケジュール

すべてのエンジニアが緊急作業に備えて、緊張し続けている分けにはいきません（疲れ果ててしまう）。食べログでは２人ずつ交代でローテーションを運用しており、プライベートの都合や所属に応じてペアを調整する必要もあるので、スケジュールを柔軟に決められる必要がありました。

### 緊急時は対応が始まるまで、電話を何度でも鳴らし続けてくれる

サービス障害はすなわち事業にとっての機会損失なので、速やかに全力で復旧に取り組まなくてはなりません。メールやSMSの通知よりも、音声着信による鳴動の方が気付きやすく、障害が放置されるリスクが少ないと考えました。また、コロナ禍で在宅勤務となっているため『誰かが気付く』ということに期待することも難しいため、この機能も重要と考えました。

### 外からの音声着信も担当者につないでくれる

いくつかの連携先からは、電話によって緊急障害の連絡が入ることがあります。そのため、音声着信をそのまま担当者につないでくれる機能が必要でした。

また、Opsgenieでは案内が合成音声で作られるため、文章を自分で決められるところがお気に入りです（案内メッセージの短い文章にセンスが求められることが分かったことは、いい勉強でした。何度か修正して、うまくいくようになりました）。

## 通知のフロー

![OpsGenieQiita.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/959282/b19c6a76-48a1-090e-bfc8-d04148762834.png)

* サービス障害の通知も、電話での連絡も、オンコール担当が音声着信で受け取れる
* オンコール担当者以外も出勤後チェックできるよう、Teamsやメールにも通知がされます。

## 導入してよかった点

* 音声着信のおかげか、緊急通知の取りこぼしは発生していません
* Teamsにも連携されるので、営業時間中の障害にも気付きやすいです

## 課題の改善効果

### 課題『受け取るメンバーが必要以上に多い』の改善効果

重大な障害は必ず『Teamsの障害通知チャネル』に投稿されるようになっているので、基本的にはこのチャネルにだけ注意を払っておけば、サービス障害の対応ができるようになりました。

まだ一般的な通知（遅延など）がメールでそのまま残っている状況のため、『通知そのものが減った』という訳では無いので、一般的な通知のランク付けやルーティングの最適化が今後の課題です。

### 課題『対応がちゃんと進んでいるかが不明瞭』の改善効果

ステータスを対応中(Ack)にしないと電話が鳴り続けるため、着手するときはみんな必ずステータスを変更してくれています。また、ステータスの変更は即時でTeamsにも反映されるため、対応が開始されたことをみんなが把握できるようになりました。

## 今後やりたいこと、使っていきたい機能

### 通知の最適化

いま取り扱っているアラートはサービス障害だけなので、今後はパフォーマンス劣化やバッチのエラーなどもOpsgenieと連携して、現在の対応状況がすぐに分かるようにしたいです。

### AlertManager との連携

[AlertManagerが公式に対応している点](https://prometheus.io/docs/alerting/latest/configuration/#opsgenie_config)も選定条件としては大きかったです。Resolve通知を受けるとアラートを自動でクローズしてくれる仕様になっているので、Prometheusのメトリクスとうまく連動させて、システム改善を進められるようにしたいです。

### 関係者への周知・エスカレーションへの利用

「[インシデント](https://docs.opsgenie.com/docs/incidents)」と「[サービス](https://docs.opsgenie.com/docs/services)」の機能を組み合わせれば、インシデント発生時の関係各所への連絡にも使えそうです。障害が起きるとユーザからの問い合わせが増えるので、問い合わせを受ける人が障害のことを知らないと、適切な対応ができないことがあるので、速やかに関係各所への連絡を終わらせられるようにしたいです。

![OpsGenieIncident.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/959282/75eaf761-237e-0481-f03b-97953cfbe0ac.png)


### ポストモーテムへの活用や、今後の障害対応の参考にしたい

障害が発生した時のレポートをOpsgenieに残して、ポストモーテムの実施に利用したり、同じような障害が発生した時に参照できるようにすることで、システムの改善や障害復旧時間の短縮に活用したいです。

## 実験的だけど使ってみたい機能

### アクション

[アクション](https://docs.opsgenie.com/docs/opsgenie-actions)はAWSやRestAPIと連携して、独自に定義したシステムタスクを実行できる機能です。

* 障害を起こしたノードの自動的な切り離し
* 通知内容を分析して、参考情報を提供する

など、障害対応を自動化したり、負担を軽減することに使える可能性があると思っているので、ぜひ活用してみたいです。

### ChatOps（日本語への対応待ち）

Opsgenie は MS Teams 用のチャットボットを提供しています。この機能を使えば、MS Teams 上でやりとりした内容を手軽に Opsgenie側に保存することができるのですが、まだ日本語に対応していない（2020年12月現在）ようなので、今後の対応に期待しています。
（ポストモーテムの活用のためぜひ欲しい機能です）


明日は @tkyowa さんによるフィナーレです！お楽しみに！！