こんにちは。照井@雪降る街です。

通勤が無くなったので、その時間分ダイエットのために毎日朝と夕方にウォーキングをしてるんですが、雪が降ったり寒くなったりしてきて、心が折れそうになってきています。

弊社サーバーワークスは本日(2016年11月4日)、AWS環境における先進的なMSPシステムと体制を有する「次世代MSP」として認定され、MSPプログラムの最新3.0更新認定を取得したことを発表いたしました。
つまり、現時点でも高い品質が認められたわけではありますが、ここで満足せず、Datadogを始めとした様々なSaaSを活用し、さらなる品質の向上と効率化へ取り組んでおります。

今回はその一環として、VictorOpsというサービスを検証しましたので、ご紹介したいと思います。

VictorOpsとは

VictorOps | DevOps Alerting & Real-Time Incident Management

VictorOpsは、監視システムのアラートなどのインシデントを集約して管理し、インシデントのエスカレーションポリシーを設定することでそれに応じた通知やシステム連携を行ってくれるSaaSサービスです。

似たような領域をカバーするサービスにPagerDutyがあります。PagerDutyも検証したのですが、かなり違いは大きく、個人的にはVictorOpsがかなり良いように感じられたので、そのあたりの比較を交えながら進めていきたいと思います。

VictorOpsの特徴

豊富なインテグレーション

Is Your Network Monitoring Software Supported? - VictorOps

NagiosやZabbix,Sensuのような監視ツールからDatadogやNew Reric、Pingdomのような監視サービスはもちろんのこと、SalesforceやSplunk, Sumo LogicのようなSaaSサービスまで約50種(2016.10.31現在、PagerDutyも同じくらい)の通知の集約ができます。それ以外もEmail Endpointを使用すれば通知の集約が可能です。

ChatライクなTimeline

ユーザ同士がやり取りできるチャットのような Timeline と呼ばれる機能が付いてきます。インシデントの発生やステータス変化もこのTimelineに流れてくるため、インシデントに関するやり取りを全てここで集約することが可能です。
また、SlackのOutgoing Webhookの受け口も用意されていて、関連するSlackチャンネルの発言も集約できます。APIが公開されており、Hubotのコネクタも提供されていますので、この上でChatOps的に問題解決を進めていくことも可能です。

ただ、やはりChatとして使うと考えると、Slackと比べるとUIなどがだいぶ見劣りしてしまいます。まだ試していませんが、β機能としてVictorOpsのTimelineを外部へ流すOutgoing Webhookがあるので、これをSlackのIncoming Webhookに流し込んで、Slack上でやり取りする方が便利そうな気がします。試したらまたレポートしたいと思います。

Incident Routing

Getting Started: Routing Keys

個人的にはここがVictorOpsの一番の特徴だと思います。
一般的な通知順や通知方法を管理するだけのインシデントのエスカレーション設定とは違い、VictorOpsでは インシデントのRouting という概念が中心となっており、これによって柔軟かつ実践的なインシデントの管理やエスカレーションを実現できます。

まず、インシデントにはRoute Keyというものを設定することができ、これを使ったRouting Ruleを設定することで、チームごとのインシデント割り当てをコントロールすることができます。Aというキーや運用チーム、Bというキーは開発チーム、といった要領です。

方式は違いますが、ここまでは同じようなことがPagerDutyなどでも実現可能です。

VictorOpsが特徴的なのは、インシデントが割り当てられた後に新しいRoute Keyの再設定をして、Rerouteさせるということができるということです。
つまり、「運用チームが受けてアプリケーションが絡む場合、開発チームに渡す」というようなことが簡単にできます。
簡単にできますが、ただ他のチームに通知するだけの方法とは違い、通常の開発チーム向けのインシデントのエスカレーションと同じように扱われることがポイントです。
Route Keyで繋がる疎結合な関係であるため、チーム内でのエスカレーションポリシーは他チームを気にすることがなく自由に変更が可能です。また、適切なRoute Keyさえ知っていれば他のチームの連絡先を知っている必要はありません。

また、上記だけではなく一度特定のチームがインシデントを受信し、その重要度や内容に応じて適切なチームに振り分けるような運用にも非常に適していると感じました。

自動化が意識されたエスカレーションポリシー

Getting Started: Team Escalation Policy

これも、大きな特徴の一つです。エスカレーションポリシーの中にメールやSMS、電話などの通知の他に Webhook が設定できます。また、メール通知についてもユーザに紐付かない任意のメールアドレスに飛ばすことも可能です。
つまり、任意のタイミングでWebhookやメールを飛ばして自動化されたアクションを呼び出すことが可能です。PagerDutyではWebhookはインシデントのトラッキング用途として各イベント毎に送信させることは可能でしたが、任意のタイミングで発火させることはできませんでした（違ったらすいません。というか、もしやり方があるなら誰か教えてください！）

まとめ

VictorOpsはインシデントの集約からチーム間連携を促進し、通知・アクションへ繋ぐハブとして、とても良さそうな印象を受けました。
他のサイトでもPagerDutyとの比較記事などをいくつか見ましたが、VictorOpsは前述の通りハブとしての役割が強く、PagerDutyは集約してその中で管理することに特化している印象を持ったので、あまり真っ向でぶつかるものではなく、用途によって適切なものを選ぶことが必要があるように感じています。

VictorOps,PagerDutyを採用するかどうかは現段階では明言できませんが、より先進的で質の高いMSPサービスを提供すべく、これからも試行錯誤を続けていきたいと思います。