目次 非表示
はじめに
過去のBlogでシステム監視の有用性についてご紹介させて頂きましたが、監視システムにより検知した障害はどのようにシステム担当へエスカレーションしていますか？
弊社でも複数のシステムを日々監視していますが、NOCへ配備しているエンジニアは障害検知とともにけたたましく鳴る警報音に呼び出され、難解なsyslogから障害の発生しているシステムを特定し、更にホワイトボードへ貼り付けられた待機当番表からエスカレーション先のシステム担当者を特定、「夜間作業明けなのに申し訳ない」と感じつつも心を鬼にしてシステム担当者へ電話、ようやく電話がつながったと思ったら「それ担当俺じゃないっすね、Aさんすね」などと電話を切られ、無力感を味わう日々が続いていました。
そんな中、事故が起きます。
とあるシステムがメンテナンスウィンドウで保守作業を行うにあたり「アラート静観」の指示が出る中、これとは異なるシステムで障害が起きます。しかし、NOCのエンジニアは同時に発生した全てのアラートを静観と判断してしまいます。
我々は、エスカレーションの自動化を行うために、監視システムからTwilloを介して電話でのエスカレーションを行うインテグレーションを試みますが、なかなか人の手で回していた全てのオペレーションを自動化するまでには至りませんでした。当番表に合わせて、エスカレーション先を動的に変化させることが難しかったためです。
しかし、ある日、エスカレーション自動化を諦めていなかったNOCエンジニアの一人がPagerDutyやOpsGenieを見つけ、「オンコール管理ツール」というジャンルが存在することに気づきます。
ここからはトントン拍子にコトが運びました。我々に必要な最低限の機能を具備し、カスタマイズが可能かつ安価なサービスとして白羽の矢を立てたのがSquadcastです。
この数か月後にはいくつかの監視システムとのインテグレーションを終え、現在はアラート検知からのエスカレーションを完全自動化するに至っています。
Squadcastとは？
Squadcastは、Squadcast, Inc.社がSaaS形態で提供するインシデント管理およびオンコール(アラートエスカレーション)管理ツールです。
2023年現在、インシデント管理ツールやインシデント管理機能を備えた監視システムは多数ありますが、Squadcastは以下のような長所があり、安価でシンプルなツールをDIYで使い倒してゆくコンセプトに向いています。
- 無償プランでもエスカレーション機能をフルに使えるため、PoCから入りやすい(ただし、チームの人数、コール回数に制限あり)
- 有償プランでも1ユーザあたり9USD/mon～と低価格であり、Proプラン(19USD/mon)へグレードアップすれば従量で請求される要素がなく明朗会計
- インシデント管理、オンコール管理に特化しておりシンプル(裏を返すと、監視システムと連携するためのインテグレーションは必要になる)
- 一方で、最低限の重複除去(de-dupe)やキーワード指定によるインシデントの抑制機能は具備しており、エスカレーション頻度を低減できる
- Android、iOS用のネイティブアプリケーションがリリースされている
- 一通りの操作はREST API経由で操作可能なため、不足する機能は外部から補うこともできる
- Terraform Providerも提供されており、Terraformを介したコンフィグレーションも可能
また、Squadcast, Inc.社はISO 27001認証を受けており、オペレーションもSOC2 Type2に準拠しているため、データ保護の観点で一定の品質を担保できている点も選定理由として大きいでしょう。
Squadcastでできること
※Squadcastにおいてはアラートを「インシデント」として管理するため、以降「インシデント」と呼びます
「インシデントの管理」は、検知したインシデントがどのような状態にあるかを管理するものであり、エスカレーションと切り離せない関係にあります。
Squadcastにおいては4つのステータス(Triggered、Acknowledged、Resolved、Suppressed)と3つのアクション(Acknowledge、Resolve、Reassign)によりインシデントのライフサイクルが定義されており、インシデントが「Triggered」状態にあるとき、インシデントは未対応であると判断されエスカレーションが発生する仕組みになっています。
SquadcastのWebダッシュボードでは、これらのインシデントの一覧を参照することができます。
一次エスカレーション担当に電話がつながらない！そんなときでも二次～三次エスカレーション先へ電話をかけねばならない、というケースはしばしばあると思います。
Squadcastにおいては、エスカレーションポリシーを定義することでインシデント発生からの経過時間を指定しエスカレーション先を変化させることが可能です。
また、エスカレーションを行う媒体についてもEメール、SMS、電話、スマホアプリへのPUSHの4種類から選択できます。
エスカレーションスケジュールは、日時や曜日を指定してエスカレーション先を変化させることができます。
一般的な予定表アプリと同様に繰り返しのスケジュール入力にも対応しており、一定の規則性を持つ輪番シフト程度であればWebダッシュボードから容易に設定することが可能です。更に、急な出張などスポットのエスカレーション先変更にも対応できる仕組み(Override)を具備しています。
また、対応時間が8×5となるSLA下のサービスでは、意図的に時間外のエスカレーション先を設定しないことで時間外のエスカレーションを抑止することも可能です。
インシデントに含まれるキーワードを元に、エスカレーションポリシーの紐づけを動的に変更することが可能です。
Zabbixでエスカレーション先のチームごとにホストグループを構成しておき、ホストグループをインシデントのメタデータに含むことでエスカレーション先の振り分けを実現できます(サーバとNW機器はそれぞれ別のチームへエスカレーションする等)。
一定期間内に同一とみなせるインシデントが複数回発生した場合に2回目以降のインシデントを無視(de-dupe)したり、指定したキーワードを含むインシデントのエスカレーションを抑止(Suppress)する仕組みが具備されています。
de-dupeはAIやML等を用いず、キーワードによるマッチングを行うだけのシンプルな実装です。
インシデントの発生やステータスの変化をSlackへ通知するだけではなく、Slack側からAcknowledge、Resolveといったアクションを起こすことも可能です。
Squadcastには多数のコネクタが用意されており、ZabbixやAWS CloudWatch等の監視システムと容易にインテグレーションを構築することができますが、汎用的なメールフックやWebフックも用意されています。
これらを利用することでWebフォームからの問い合わせやサポート依頼をSquadcast上インシデントとして管理し、エスカレーションポリシーに定義された担当へエスカレーションを行うような運用も容易に実現できます。
Squadcast側でインシデントのステータスが変化した場合に外部サービスのWebフックをトリガできます。
これを利用することでSlack以外のコミュニケーションツールや外部のチケット管理システムへインシデントの発生を通知するような仕組みを構築することも可能です。
おわりに
今回紹介させていただいた機能、事例は代表的なごく一部です。
Squadcastも日々進化しており使いやすくなっていますので、ぜひ活用をご検討ください。
