Connectの処理終了を正しくお知らせしよう〜SalesforceのAPIタイムアウトをのりこえる〜
さて、先日ConnectでSalesforceからデータを取得する際に、APIタイムアウトを乗り越える記事を書きました。
この記事で一点だけ書いていなかったことがあります。
それはETLでは必ずある、夜間連携の報告です。
メジャーなのはエラーが発生したら、関係者にメールを送るタイプですね。
深夜に気づいた時にはヘコむものです、いやまぁ朝でもヘコみますが。
でもエラーがほったらかしになるよりは何倍もマシです。
エラー復旧までの時間が長く取れますしね。
今回は正常でも異常でも処理結果をメールする仕組みを考えました。
何を送るかと言うと、メール＆添付ファイルです。
さて、この添付ファイルの意味とつくり方について、解説をしていきましょう。
この添付ファイルの意味
夜間連携の報告を毎日受ける人にとって、大事な要素が何個かあります。
① ひと目で正常か異常かわかること
② どんな過程をたどって成功にたどり着いたかわかること
③ その他の情報が付加されていること
大事な順番は①→②→③です。
このダッシュボードは必要最低限で装飾もしていませんが、最低情報は抑えています。
左上が①、正常終了したか否かを伝えています。まず最初に目線はここに行きます。
左下が②、タイムアウトをどれくらいしたかが各オブジェクトごとにあらわされています。
右側が③、過去のタイムアウトの履歴を表示しています。
③は今後の傾向分析で役立つことになります。今はデータが溜まっていないので、まだ価値が出ていませんね。
このような情報が毎日届けば、管理者にとって親切な情報となるでしょう。
それではつくり方を解説していきます。
メールを送るのはMotionBoard
雑な絵を書いてしまいましたが、関連図はこんな感じです。
A.ConnectがSalesforceのデータをDr.Sumに取り込みます。
B.このとき正常終了、異常終了のログ情報も追記型でDr.Sumに書き込みます。
C.MotionBoardでログ情報を参照し、先程の画像のようなダッシュボードを作成します。
D.MotionBoardのタスク配信機能でメールを送ります。
MotionBoard Cloudであれば、wingarc.comからメール送信ができます。オンプレであるとメールサーバーを指定する必要があります。
ありがとうクラウド、便利です。
ログは２パターン用意する
追記型ログと更新型ログの２パターンを用意することをオススメします。
追記型ログはMotionBoardに読み込ませる専用のテーブルです。
人間が見るとわかりにくいです。
だいたいログは いざというときに見るものなのです。 人間に見やすい形というのも設計しておきましょう。いざというときに慌てないで済みます。
人間が見るときはこっちです。
最新情報だけピックアップしています。
ちなみに、どっちが重要だと言われると、前者になります。
前者はデータが貯まるごとにエラーの傾向がわかるようになります。
新しい発見は、データが蓄積されることで生まれていきます。
傾向を可視化せよ
追記型ログのメリットは画面右側の傾向の可視化です。
今回のようなSalesforce側のタイムアウトエラー、エラーを受け入れて処理を作りましたが、釈然とはしません。
何か法則があるはず。
調査の一歩目はエラータイミングの調査です。
右上は曜日ごと、オブジェクト別のヒートマップ。
右下はオブジェクトごとのタイムアウト回数の日別推移です。
まずはこの形で傾向を探り、気になったところはMotionBoardで深掘りしていきます。
こんな情報が毎日届くだけで、何かしらのきっかけを生み出せそうですよね。
タスク処理でメールを送る
MotionBoardのすばらしいところは、わざわざダッシュボードを見にいかなくても良いこと。
定期的に画面を共有してくれます。
こちらのダッシュボードは毎日7:00にメールしてくれるようにしています。
ぼくは毎日、メールを見て昨日の状況を確認しています。
追記型ログを作らなかった頃は、毎日Dr.Sumを開いてログ情報を直接確認していました。
ログ情報を取り込まなかったときは、Connectのトリガーログを確認していました。
今はメールを見るだけ、3秒で確認できるようになりました。
日々のこうしたルーティンワークの改善は、人生を楽するための方法となるでしょう。
さいごに
今回は技術的な情報というよりは、保守を行うときのうまーい手の抜き方についての解説でした。
なるべく、なるべく自動化をするべきです、そこに神経を注ぐべきなのです。
ぼくはこれからもルーティンとなる思考は仕組みで排除できるようにしていこうと思います。
Discussion