こんにちは。元々はフロントエンドをやっていましたが最近はSREの とよしー です。
読者のみなさんは物件をリリースした後ってログの監視をしていますでしょうか？
リリース直後のプロセスって具体的な他社事例をあまり聞いたことがないので気になっています。
プロダクトによって違うとは思いますが、今回は弊社のリリース直後のプロセスについて書いてみます。
弊社では週に1回のペースで開発/修正物件をリリースをしています。
そこでリリースした後に監視してみてはどうかと考え、まずは自分だけでもはじめてみました。
なぜやるか？(Why)
端的に言うと、エラーが発生したあとの初動を早くするためです。
「切り戻しが必要なのか / hotfixで修正する必要があるのか」といった判断を早くできるように障害検知までの時間を早くしたいのです。
このプロセスがうまくいけばMTTR（平均修復時間）を短くなることにつながるのではないかと考えています。
リリース後の監視って？
DatadogのAPMとRUM（Real User Monitoring）を用いてエラーの発生状況を監視することを指しています。
APMではLiveでエラーログを監視し、RUMではLiveの設定がないので直近5分のエラーログの発生状況を見るようにしています。
どのようにやるか？(How)
エンジニアが全員いるSlackチャンネルでDatadogのAPMとRUMのURLを共有
↓
監視する
（とはいえ常に凝視しているわけではなく検知できるようにページを常に開いているイメージです）
↓
見慣れないエラーログが出た場合はエンジニアに共有
↓
障害につながりそうな場合は切り戻し/hotfixで修正の判断をする
↓
おおよそリリースしてから30〜45分ほど見て影響がなければ監視は終了
やってみてどうだったか？
約2ヶ月ほどやってみて思ったことです。
-
浸透が今後の課題
リリース後の監視自体はとくに難しい要素はないので誰でもできると思います。
課題としては、リリース後の監視というプロセスをどう組織に浸透させるか。
浸透させるにはさまざまな乗り越えないといけない壁があります。
例えば、Datadogの使い方がわからないから監視を避けてる方がいるかもしれないし、そもそも監視に意味を見出せていない人もいるかもしれない。
それらを乗り越えていくにはDatadogの使い方をドキュメンテーションしたり、監視の意義やメリットを繰り返し伝えていく必要がありそうです。
まずは共感してくれる人を増やしながら、草の根活動のようにやっていこうと思っています。 -
エラーログのノイズが多いことがわかった
はじめたころは、RUMでものすごい量のconsole.errorが出ており、リリース起因のエラーが調べるのが大変でした。
しかも、そのものすごい量のconsole.errorを調べるとユーザー影響がないことがわかり、ロギングの仕方の問題であることがわかりました。
このままだとエラーログのノイズが多いので、監視のハードルがあがってしまいます。
まずは、ユーザー影響はないがロギングの仕方が問題となっている一番多いconsole.errorを修正することにしました。
監視をすることで、あるべきロギングのルールを考えることができたのは収穫でした。 -
アラートを出せばよいのでは...
一方でエラーログを検知したらアラートをSlackで通知すればよくね？と思う瞬間もあったのですが、
アラートを作れば自動的に解決するわけでもないのが難しいところだと思っています。
結局アラートが日常的に検知できる環境だと、開発者がアラート疲れ/アラート慣れ してしまうことも懸念していました。
やがてオオカミ少年のようなアラートになるのではないかと。
そのためリリース後の一定時間というタイミングのみ、エラーにフォーカスして監視したほうがMTTRの短縮に貢献できるのではないかと考えています。
（正直に言うと、いまだにアラートの扱い方には頭を悩ませています） -
エラーログとして出ない障害は検知しにくい
例えば、
「このデータってユーザーに見えていいんだっけ？ 制限がかかっていないとダメだよね？」
というエラーパターンは、エラーログを吐かせにくいので検知が難しいと感じました。
そもそも論としてこのようなエラーは設計や実装などのもっと早いフェーズで検知されるべきではあるのですが、
リリース後も見つけやすい仕組みを考えていけると良いなあと思いました。
以上、リリース後の監視についてでした！
読んでくださりありがとうございます。