概要
エキサイトの川崎です。
弊社の一部のサービスには通話機能があり、 その通話機能(以降 call systemと呼びます)をTwilioを使って作っています。
call systemを作成運用する上で、困ったこと/悩んだこと はいろいろあるのですが、 今回はcall systemのアラートについて書きます。
call systemをリリースしてからアラートにはたくさん助けられてありがたみも感じていますが、 どんな時にどんなものをアラート対象とすべきで、どのように通知すべきなのか今も迷走しています。 (本記事における「アラート対象」というのは、発生した際にメールやslackなど何らかの形で関係者に通知を送る事象のことです)
「やばそうなもの」はどこかに通知する or 出来るだけ自動化して対処すればいい程度の認識でいましたが、 唐突に、監視について教科書的な知識がない(っていうか監視の定義って何？アラートってそもそも何？な状態)のはまずいな、と感じて下記の本を読み始めました。 www.oreilly.co.jp
主にアラートメインの話が書いてある3章を読んでみた上で、学んだことや、その上でどんな対応したかを できる限り自分の言葉にして書いていきます。
当たり前だろな内容の予感もしますが、 あー確かにねと認識をお手伝いできたり、新しい視点や違う視点を提供できたらいいなと思います。
監視とは
あるものについて、その振る舞いや出力を確認し続けること。
本を読むまでは「悪いものを見つけること」だと思っていました。 「悪いものを見つけること」でも間違ってないとは思うのですが、 個人的にはこんな感じで捉えることでなぜかしっくり来ました。(字面のまんまじゃん)
監視している中で「やばい、動いてない」とはどういう状態か
ユーザがサービスを使った時に困る状態。
たまに、「問題がある」とか「やばい、動いてない」の定義が分からなくなることがあります。もしかして私だけでしょうか( ；∀；) そんな時上記の言葉を読むと頭を整理できて、 本当に問題があるのかを判定できるようになります。 これだけが定義じゃないと思うのですが、サービスはユーザが使うものなのでまずはこれ中心に考えることにしました。
例えば、「ユーザに電話をかけた」という出来事の記録に失敗することはぱっと見良くなさそうで、誰かに言いたくなりますが、 ユーザにとっては通話ができれば問題ないかもしれません。 (アラート対象とはせずにログに残す程度でいい)
アラートとは
監視してて、何かあった時に誰かに警告してくれる(いまだに不明瞭で草生えない)
アラート対象の種類
1. 緊急性が高くすぐに対処すべき事象
2. 確認はすべきだけど、緊急性が低くすぐに対処しなくてもいい事象
本で上記のような2種類が書かれていました。 この2つ+「何かあったら確認したいけど誰かに通知するほどでもない事象」の3つを明確に分けられていなかった私は、 このいずれかに意識的に分類してみることで、頭の中で整理がしやすくなりました。
例えば、通話できることで成り立っているサービスにおいて、 「通話ができない状態」は、大事故なのでアラート対象(すぐに関係者に通知すべき)、というのはすぐにわかりますが、 「原因不明の通話作成の失敗1回(もちろんユーザには適切な画面表示をしています)」はどうでしょうか。なんらかの問題に気がつけるきっかけなので、詳細確認はしたいですが、サービス全体において致命的ではありません、何これアラート対象？どうすべきなの？っていうかアラートってなんだっけ？と、こういうパターンでは毎回頭の中がごちゃごちゃになっていました。
「原因不明の通話作成の失敗1回」は「2. 緊急性は低い事象」と認識し、原因はよく調べたところいくつかのパターンを含んでいたので、一部のパターンはシステム改修で対応し、どうしようもないものは、ログに残すだけにして、関係者への通知は行わないようにしました。(場合によっては緊急性が低い用の通知場所に通知してもいいと思います)
もはや気持ちの問題ですね。その時に応じて頭を使うのは変わらないのですが、アラート対象の分類のしかたを1つ知っておくだけで頭の中の整理のしやすさがかなり変わりました。
アラートの精査
迷うならとりあえず入れておいて、現状をみて減らしていくのもアリ
(本に書いてあったかは謎。。。)
実際にやる前はそんな雑なことしていいかな、定期的に担当者(自分)Twilioのデバッガー見にいけばいいのでは？とモヤモヤソワソワしていて、 実際にやってみて「アリ！」って思えたので書いておきます。
call systemを使用しているサービスのことを考えると、call systemが安定した稼働をすることはかなり重要だったので、 何か問題があった時にすぐ気がつけるようにしています。
call systemリリース時には、
- 「アプリケーションがあげるエラー」
- 「サーバー自体のエラー」
の中で重要なものは当然アラート対象としつつ、何が起こるか未知数だった
- 「TwilioのDebuggerが上げてくれるエラー(これらのうちのいくつか)」
については全てアラート対象としました。 (とはいえ、大量に来たら迷惑すぎるので初期だけは1時間に1回まとめて通知にしていました。)
しばらく運用していると「TwilioのDebuggerが上げてくれるエラー」について、下記のようにいい感じに間引くことができました。
call systemを使っているサービスに害がない→アラート対象から外す
例) Warning 32015 - Twilioユーザの環境依存で一時的に起こってしまうがcall systemとしては対処できない→call systemを使っているサービス側で対策を考えた上でアラート対象から外す
例) Warning 32014 - Twilio、Error 52103 - Twilio
現状を知りながら適切なアラート設定ができたので、一旦アラート対象にして順番に対処する形にしてよかったです。 (いつ起こるかわからないものを、定期的確認しに行くのはしんどかったと思う)
おわり。
