概要
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で利用します。
7.FILTER: Only continue if...
対象APPは「Filter」
↓
↓
電話を通報するかどうかをチェックしています。（2回目）
- 設定値は必ずステップ6のフラグを設定してください。ステップ6が成功した時にのみ、フラグが存在しますので、ステップ5を同時通過した時でも、ここで1つに制限されるようにます。
※設定後の見た目では分かりにくいですが、他のステップの同名フラグでは結果が異なりますのでご注意ください。
※もしステップ6のフラグが設定できない（表示されない）場合は、サンプルデータによるテストがステップ6まで通過していないことになります。テスト用のトリガーメールを再送信して、ステップ6まで成功するサンプルデータを指定した後、ステップ6を再テストしてください。
8.ACTION: Call Phone
対象APPは「Twilio」
↓
↓
電話通報します。
電話の着信だけあればよかったので「メッセージ」は空欄にしたかったのですが、必須項目だったため、メッセージには適当な日本語を入力して、言語指定を空欄としています。そうすることで、デフォルトの英語でメッセージを解読しようするので、電話口では何も発声することなく、通話を終了するようになります。
★電話の音声内容を確認するのは時間がかかるし、留守番電話に残った場合にそれを削除する手間が地味に面倒だったので、電話では何も発声させないようにしています。
★音声で詳細を喋らせるよりも、Slackなどに通知されているテキスト情報のほうが情報量が多いためというのもあります。
もし、電話で日本語発声させる場合は、下記のように設定してください。
- Custom Value for Voice:
alice - Custom Value for Language:
ja-JP
※Twilioで日本語対応しているのがaliceだけのため（2018年9月23日現在）
9.ACTION: Send Channel Message
対象APPは「Slack」
↓
↓
Slackにトリガーとなったメールの件名を通知しています。
★電話をかけるということだけに着目すると不要なステップですが、電話がかかってきたトリガー要因を確認しやすくするためにSlack通知しています。Zapierのタスクヒストリーを見れば同じ情報は確認可能ですが、Zapierにログインしなくても確認しやすくするためのステップです。
10.ACTION: Delay For
対象APPは「Delay」
↓
↓
処理中のZapをここのステップで10分間遅延させています。
この間、フラグは【on】のままなので、仮に短時間で多数のトリガーメールを受信し続けたとしても、フラグが【off】になるまでの10分間は電話がかかってこないので、障害対応者は作業に集中できます。
11.ACTION: Set Value If
対象APPは「Storage」
↓
↓
すべての処理が終わったのでフラグの値を【on】だったら【off】にします。
以降は、トリガーメールが受信したら、電話通報可能な状態となります。
上記のZapを設定する際の注意点
全てのステップを順番にテストしている場合は問題ないですが、部分的にテストしている場合は、フラグの値を【on】にしたままにしてしまう場合があるので、別のZapにて、すべてのフラグの値を確認するZapとすべてのフラグを【off】にリセットするZapがあるといいかもしれません。（手動チェック用）
もっと厳密にする場合は、毎時スケジュール実行でフラグをチェックすると安心です。（自動チェック用）
上記のZapを実現するための費用
- ZapierはTeamプランに加入しています。年間契約なので、年間3000ドルです。
- Twilioは、発信元の固定電話番号代が月額108円／1つあたりです。加えて、携帯電話宛に発信するたびに16.2円/分かかっています。
→１か月あたり「250ドル＋108円」（固定）と「16.2円×電話通報数」（従量）となります。これが安いか高いかは現場によりけりだと思うので、ご判断はお任せします。
※Slackの料金は、主旨からそれるため割愛します。
残された課題
- 誰が電話に応答したかが確認できないので、仮に深夜に障害が発生して電話通報された際に、誰も応答できない可能性も想定されます。その際に、誰かが応答するまで電話をかけ続けるという仕組みを用意したかったのですが、今のところ解決策は見つかっていません。