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」を使うことで、その日のインシデント対応者の確認が行えたり、自分のシフトなどを確認することもできます。
Opsgenieのセットアップ
サインアップとドメインを準備する
まずはOpsgenieのアカウントをアクティベーションしましょう。OpsgenieへアクセスしてSign-Upに遷移します。メールアドレス、パスワード、名前を記入します。ここの情報がOpsgenieのオーナー情報になります。その後、ドメインを入力すればトライアルが開始できます。
ドメインが準備できた後、ログインするとクイックスタートガイド（Quick Start Guide）が開始されます。初期設定に関して必要なことは、このスタートガイドですべて網羅されており、記載されているとおりに設定すると初期設定は完了です。
プロフィールを設定する
まずは、メールアドレスのアクティベーションと、SMS通知のテストを実施します。
これも登録したメールアドレス宛にメールが届いているので、クリックするだけです。SMSの方は携帯電話番号を入力すれば完了です。
チームの設定を行う
アラートを受ける単位で定義していきます。例えば、サーバーサイドチーム、インフラチーム、iOSやAndroidなどのネイティブアプリの単位でチームを定義し、チームごとにメンバーを追加していきます。
チームを定義すると以下のカスタマイズを行うことができます。
- オンコールの時間帯の設定
- エスカレーションポリシー
- アラート登録に関する設定
また、インテグレーションを設定する単位もチームごとに登録することができます。これはチームごとにサービスを継続的に安定して運用するためのモニタリングツールは異なる、という思想から来ているものと思います。
続いてインテグレーションの設定を行う
チームで利用しているモニタリングツールをインテグレーションしたり、チケット管理システム（Jira Softwareや、Jira Serivice Deskなど）と連携することで、社内のステークホルダーとチケットでコミュニケーションした内容がOpsgenieに記録されるようになります（※チケット管理システムとの連携は、スタンダードプラン以上から可能です）。
このスクリーンショットはStatuspageのインテグレーションの設定箇所ですが、Opsgenieの素晴らしいところとして、手順が表示されるので、何も迷わず設定が完了できるようになっています。
最後にコミュニケーション・チャンネルの設定を行う
Opsgenieは、SlackやMicrosoft Teamなどと連携することができます。
Slackと連携してみる
こちらもStatuspageの設定箇所と同様に、手順が記載されているので、特に迷うことなく設定を完了できます。手順に沿って、Slackに通知されるアクションを設定すると完了です。
Slackに通知される内容は、下のスクリーンショットのとおりです。その場でアクションできるインテグレーション内容になっていて、これはとても便利ですね。
連携するツールが多ければ、初期設定の手間はありますが、セットアップの難易度としてはそこまで難しくないと思います。
Opsgenieをチームに適用することのメリット
一般的なアラート通知のよくあるパターンとして、例えばSlackの特定チャンネルにメンションをつけて一斉通知するケースです。もちろんチームの外のステークホルダーにも何かが起きてることを知らせるために、見えるところにアラートを飛ばすことは重要です。ただし、担当でない人にとっては業務の妨げになることがあります。
そこで、インシデント対応のシフトを組んでいる現場では、シフトに合わせてOpsgenieでエスカレーションルールを定義してあげることで、主担当者が拾って対応し、他の人が他の業務に集中できる環境を作ることができます（もちろんサポート体制は相互に実施する前提ですが）。
また、担当者ごとにアラート通知を受け取りやすい方法を、担当者自身で選択することができます。
このようにOpsgenieでは、スケジューリング設定と合わせて、ビジネスタイムはSlackへの通知で認知を促し、N分以上Ackされなかったら、モバイルアプリに通知する、など柔軟な設定が可能です。
アラートを受け取るエンジニアとして、インシデント対応はストレスがかかるものなので、これらの機能を使って、うまく負荷を軽減してあげたいですね。
最後に
今回の記事では、Opsgenieの特徴と機能の紹介、セットアップ方法の勘所について紹介させていただきました。このプロダクトはまだ日本語化されたドキュメントもないので、手を出しにくいかもしれませんが、ユーザーが迷わないためのUIが洗練されているので、直感的に操作することで習得できます。またチャット・サポートの質がとても良いので、分からないことがあれば直接問い合わせして、すぐに回答を得ることができます。
Atlassianツールを利用しているユーザーが集まり、ノウハウや事例を共有する目的で、定期的にユーザーグループを開催しています。Opsgeineを紹介するセッションも予定されているので、ユーザーグループの開催をチェックいただけると嬉しいです。
また、Opsgenieは機能無制限で14日間のトライアルをすることができるので、まずは試してみてください。
