Opsgenieの概要と特長
Opsgenieとは
Opsgenieは、昨年9月にアトラシアンに買収されAtlassianファミリーの仲間入りを果たしました。Opsgenieは、Datadog、 AWS CloudWatchやUptimeなどから検知したアラートを集約し、発生したインシデントに対して誰が、いつ、どういった対応をしたのかを管理します。
そしてチーム外のステークホルダーへの通知として、Slack、Statuspageなどのコミュニケーション・ツールと連携して情報の共有を行います。
豊富なインテグレーション
Opsgenieは、インシデントに対応するためのモニタリング・ロギングのサービス、コミュニケーションツールとのインテグレーション機能が豊富に揃えられており、200のサービスと連携できます。
すでに皆さんは、サービスを正常稼働するための監視ツールやサービスを利用されていると思います。そのほとんどのサービスで利用可能になっています（参考：「Opsgenie - Integrations | Atlassian」）。
- モニタリング＆ロギング (130)
- 自動化 (15)
- チャット & コラボレーション (21)
- API (6)
- ITSM & チケットシステム (26)
- おすすめ(14)
- 開発ツール (10)
また、WebhookやAPIでの連携もできるので、サービスを監視するためのスクリプトや社内ツールからのインテグレーションも可能です。
特に、自動化のインテグレーションは嬉しいですね。AWSだけでなく、Azureでもオートスケーリングの自動化をOpsgenieで検知して、そのトリガーも実行してくれます。
開発ツールは、GitHubやCircleCIなどと連携できます。GitHubのPull Requestがマージされたタイミングで、Opsgenie側のアラートを自動でCloseに変更することが可能です。
開発者の自然な活動が、自動的に時系列にアラート対応として記録されていくので、経緯を集約する必要がなくなり、開発者はインシデント対応のみに集中すれば良い環境を作ることができます。
インシデント対応者に「認知」させるまでがアラートの役割
Opsgenieの通知機能の特徴として、一定時間内に反応がなければリマインドやイスカレーションをして、しかるべき担当者に確実に認知させる点が挙げられます。例えば、インシデントがサービスダウンなどの重大な内容の場合は、アラート検知後、直ちに対応に取り掛からなければいけません。そこで夜間は、担当者へ確実に認知させるべく、直接電話をかける、といった通知を行うこともできます。
エスカレーション設定
あらかじめ設定したオンコールスケジュールに沿って、まずは担当者に通知されます。
スクリーンショットの例では、インシデント対応者に10分以上「認知」されない場合、チーム全員にエスカーレションするように設定されています。そのため、システムで検知されたアラートについて、確実にオペレーターがインシデントを認知できるようになります。
Opsgenieにアラートを集約することで通知設定が標準化される
サービスを継続的に安定して運用するために、目的別にいくつかのモニタリングツールを組み合わせて利用します。オールインワン的なサービスもありますが、例として、以下のような観点での監視が必要になります。
- サーバーリソースのメトリクス収集
- アプリケーションのログ監視
- 外形監視ツール
- APMツールなどによる、アプリケーションの性能監視
モニタリングツールによっては、リマインド機能を豊富に実装していたり、単にWebhookを一度送信するような少し物足りない機能であったり、自社で作った監視スクリプトから通知したい場合は初めから実装が必要だったりします。
また、アラートは、モニタリングツールによる検知以外にも、ユーザーからの問い合わせや、社内での動作検証実施時に発覚しインシデントに発展するケースもあります。
どのようなケースでも、Opsgenieがコミュニケーションのハブになって、各モニタリングツールごとの通知機能の差異を埋めて、Slackへの通知、必要に応じたエスカレーションなど、通知機能や通知手順を標準化し、最も重要な「担当者に認知させる」ことを確実に行います。
アラートの対応を集約して、タイムライン化する
すべてのアラートはこのように時系列で一覧で把握できます。アラートについては、ルール化することで対応すべきチームを自動的にアサインできるようになります。
Opsgenieでは、以下のステータスが割り振られています。
- Open（アラートが作成されて手付かずの状態）
- Ack（アラートが担当者によって認知された状態）
- Close（アラートの対処が終わって、クローズされた状態。静観も含む）
このステータスについては、チームの中でどういう状態だとAckなのかを会話して、各ステータスの意味についてすり合わせをしておくと良いでしょう。
アラート作成時のルールポリシーを適宜設定しておくことによって、アサインの自動化や通知先のカスマイズなどができるようになります。
よくある使い方としては、「Opsgenieにアラートが登録されると同時にSlackで通知しチームで共有する」、「アラート種別によってタグを自動で付記し、対応するチームのアサインを変更する」など、こうすることで人手を介してエスカレーションする必要がなくなり、対処できる人へ直接アサインができるようになります。
例えば「DatadogやUptimeなどのインフラ的なアラートであればインフラチームへ」、「Sentryなどアプリケーションログからのアラートであればサーバーサイドエンジニアへ」アサインするといった形です。また、タグを正しく整理して付記することで、過去の類似インシデントを検索できるようになるメリットもあります。
各アラートの詳細のアクティビティログを確認することで、作業内容を時系列で確認することができます。
また、モニタリングツールからアラートが作成されている場合、初動に必要な情報がOpsgenieに記載されていれば、元情報であるモニタリングツール側の閲覧は必須ではありません。
インシデントの対応を行う過程でアラート検知から対応者が認知するまでの時間などが自動的に記録されます。GitHubやBitbucketなどとOpsgenieを連携している場合は、対応の一環でコード修正を行った時間なども自動的に追加されます。さらに、StatuspageやJira Service Deskなどと連携することで、チームの外のステークホルダーともシームレスに連携することも可能です。
なお、エンタープライズプランにすると、Opsgenie Timeline機能を利用でき、インシデントのステータスはもちろん、関連するアラート、アップデート、担当者のやりとりなど、細かい情報がタイムライン形式で表示されます。これにより、関係者が迅速に対応でき、そしてインシデントのポストモーテム（ふりかえり）を行う際に必要な情報が、すべてまとまっている状態になります。
出先でも最低限の対応が可能
こちらのスクリーンショットは、Opsgenieのモバイルアプリのスクリーンショットです。アラートの一覧を確認することができます。Ack（アラートを認知した）、Close（静観して良いアラート）などの初期トリアージを行えるようになっています。
チームでインシデント対応をしている場合に、サービス運用上、チームで合意したルールに沿って、シフトでインシデント対応の順番などを決めているケースがあると思います。その場合に、アプリ上で [Menu] > [See Schedule] で表示できる「My Schedule」を使うことで、その日のインシデント対応者の確認が行えたり、自分のシフトなどを確認することもできます。
