概要

Zapierの「Email by Zapier」で生成したメールアドレス宛てにメールを送ると、Twilioで電話がかかってくるようになり、さらにおまけでSlack通知するZapについて記述しています。

これまでの背景と課題

システム監視でアラートが発生した際にメール通知は実施していたが、すぐに気付ける仕組みではなかった。
監視オペレータがクリティカルなアラートを確認した直後に、連絡網にそってシステム管理者に電話をかけるようになっていたが、1人ずつにしか電話をかけられないため、1人目に1回で電話がつながらない場合は、何人も何回も電話をかけなければならず、障害に対応着手できるまでのタイムラグが長かった。
アラート内容をSlackへ通知するようになってからは、すぐに情報を拾える仕組みはできたが、@channelメンションなどを用いても、すぐに気付ける仕組みにはならなかった。（業務時間中でSlackを常駐起動している場合は気付けるが、業務時間外の場合にモバイルのプッシュ通知では気づきにくい）
Twilioで電話通報の仕組みを用意しようとしたが、APIをキックして電話通報を実行させるための仕組みに悩んだ。監視システムは複数あり、それぞれの環境下の制約をクリアしていくのは現実的ではなかったため。
そこで、Slackに通知された内容をBotが拾って、TwilioのAPIを実行するようにしたが、通報先リストがワンパターンになってしまった。分岐させるにはBotを作り込めばよかったが、今後の保守が面倒で手がつかなかった。
また「監視システム　→　Slack　→　Bot　→　Twilio　→　電話通報」とフローが長くなり過ぎて、どこか一箇所で止まると動かなくなるので、シンプルな仕組みが欲しかった。

→そこで、費用面・保守性・拡張性を考慮して、Zapierを導入することにしました。

Zapier導入後の構成とメリット

構成：　監視システム　→（メール）→　Zapier　→　Twilio →（電話通報）

各監視システムは、これまでのメール通知と同じようにZapierに送信するメールアドレスが1つ増えるだけなので、特別な対応は不要。
個人のメールボックスをポーリングするZapierの標準のトリガー（5分間隔）ではなく、「Email by Zapier」はメールを受信したら即時トリガーが反応する「インスタントトリガー」なので、障害発生〜電話通報までの時間が圧倒的に短縮された。
トリガーのメールアドレスはいくつでも作成でき、メールアドレスも認識しやすいよう独自の文字列で作成できる。　※「自由文字列＋固定文字列＠Zapierドメイン」というメールアドレスになります。
Twilioの電話の通報先をZapier上で手軽に設定できるようになった。（一元管理）

ZapierのZap全体フロー

解説

1.TRIGGER: New Inbound Email
　トリガーとなるメールアドレスを設定する。
↓
2.ACTION: Date/Time
　メールの送信日時をUNIX時間に変換する。
↓
3.ACTION: Numbers
　（現在のUNIX時間）マイナス（2のUNIX時間）を算出する。
↓
4.SEARCH OR CREATE: Get or Set a Value
　ストレージに格納したフラグの値を取得する（なければ作成する）
↓
5.FILTER: Only continue if...
　4で取得したフラグ値が【off】であること（＝Twilio電話通報が実行中ではない＝多重実行を防止）
　3で算出した値が【600】未満であること（＝トリガーとなるメールは10分以内に送信された＝メール遅延による発動を抑止）
　※そのほかにも後続を実行するフィルタ条件を任意で追加。
↓
6.ACTION: Set Value If
　フラグ値が【off】だったら【on】で設定する（多重実行や同時実行を防止）
↓
7.FILTER: Only continue if...
　6で設定したフラグが存在していること（同時実行された場合でも、6の設定は1つしか通過しない）
↓
8.ACTION: Call Phone
　Twilioで電話をかける。
↓
9.ACTION: Send Channel Message
　Slackにトリガーとなったメールの件名を通知する。
↓
10.ACTION: Delay For
　10分間Zapを遅延させる（フラグを【on】にしたままなので、短時間のバースト実行を抑止）
↓
11.ACTION: Set Value If
　フラグが【on】だったら【off】に設定する。

各ステップごとの設定について

1.TRIGGER: New Inbound Email

対象APPは「Email」

↓

↓

ここで設定したメールアドレスは後からでも変更が可能ですが、メールアドレスを変更する都度、監視システムの通知先に設定しているメールアドレスも変更しなければいけないので、注意が必要です。

2.ACTION: Date/Time

対象APPは「Formatter」

↓

↓

メールの送信日時をUNIX時間に変換しています。変換した値は後続のステップ3で利用します。

3.ACTION: Numbers

対象APPは「Formatter」

↓

↓

{{zap_meta_timestamp}}は、UNIX時間で変換された現在時刻を表すZapierの定義変数です。（参考：Modifying Dates & Time）

現在時刻からメール送信日時をマイナスすることで、メールが送信されてからの経過秒数を算出しています。算出した値は後続のステップ5で利用します。

4.SEARCH OR CREATE: Get or Set a Value

対象APPは「Storage」

↓

↓

障害時にアラートメールが何通も飛ぶことはよくあります、その都度何回もトリガーが発動され電話がなり続けてしまうので、ストレージのkey&valueを活用して、フラグ制御しています。

トリガーとなるメールアドレス1つにつき、フラグを1つ用意しています。
初回だけストレージにまだkeyが存在しないので、初期値【off】で作成するようにしています。

5.FILTER: Only continue if...

対象APPは「Filter」

↓

↓

電話を通報するかどうかをチェックしています。（1回目）

4で取得したフラグ値が【off】であることをチェックすることにより、すでにTwilio電話通報が実行中ではないことを確認します。これにより多重実行を防止しています。
3で算出した値が【600】未満であることをチェックすることにより、トリガーとなるメールは10分以内に送信されたことを確認します。メール遅延によって数時間遅れたメールに対して電話通報されないように抑止しています。

※ 画像の真ん中の条件は、私の現場固有の条件なので無視していただいて大丈夫です。
Zabbixの場合、障害通知と回復通知を1つのアクション定義内で設定するため、回復メールが届いた際に電話通報されないように、メールの件名でフィルタをしています。

6.ACTION: Set Value If

対象APPは「Storage」

↓

↓

電話通報をする前にフラグの値を【off】だったら【on】にします。

同時に複数のトリガーメールを受信した際に、ステップ5のフィルタ条件を同時に通過することがまれにあります。
そのため、ただ値を設定するのではなく、「変更前の値が【off】だったら」という条件を加えることにより、仮にステップ5のフィルタを同時に通過したとしても、ここのアクションが成功するのは1つだけとなります。このアクションの結果はステップ7で利用します。