この記事は「弁護士ドットコム Advent Calendar 2021」の 13日目の記事です。
昨日は @ubonsa さんでした🎄
はじめに
弁護士ドットコムでエンジニアをしています。
今回はサービス内のオオカミ少年アラート🐺に対応した話を書きます。
結論から言うと、「これで不要なアラート無くなったで」「みんなこうしたらええで」という銀の弾丸🔫は見つかりませんでした。
やはり日々の積み重ねや、えいやのお掃除は大事なんだなあ、と初心に返った気持ちでした。
結果
まずは結果から。
2週間単位で通知されたアラート数を計測しました。
| 2021/10/02〜2021/10/15 （対応前） | 2021/11/20〜2021/12/04 （対応後） |
|---|---|
| 85 | 37 |
**約57%**のアラート削減に成功しました 🎉
ここからは、弊社の取り組み、そして今回の課題設定と対応したことについてご紹介します。
TFD
弁護士ドットコムでは、毎週金曜日を「TFD/DFD（= Tech/Design Focus Day）」に設定しています。
この日のエンジニア/デザイナーは、普段所属しているプロジェクトのタスクではなく技術的負債の返済・改善等に時間を使います。
「弁護士ドットコムを作り続ける開発組織について」_about-bengo4com-development-organization
今回のアラート対応は、このTFD内で2人チーム体制で取り組みました。
課題
事前に上がっていた課題は以下の通りです。
- エラーが頻繁に通知される。
- 頻繁に通知されると、あまり気にしなくなる。
- 気にしなくなると、重要な障害を見過ごすリスクが高まる。
- また、エラー内容について、関心が薄くなる。
監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為である。
アラートは、この目的を達成するための 1 つの方法でしかないのです。 ...
アラートは人間に送られる場合が多い一方で、人間の注意力には限りがあることです。 ...
アラートを受け取るたびに、監視システムによって あなたの注意力は少しずつ削られていくのです。『入門 監視』より
監視のために導入したはずのアラートによって、逆にオオカミ少年に陥って障害を見逃してしまっては本末転倒ですね🐺
目指したこと
これを踏まえて現状を見直した結果、以下の目標を設定しました。
⭐ アラートによるストレスを減らす
- 見るべきアラートのみ通知される
- アラートのメッセージ内容が何を指しているのかわかる
- アラート発生時の調査・対応方法が誰でもできる
なぜこの状態に発展したのか
この辺は割とサービスあるあるかな…と思っています。
今回対応したのは、マイクロサービス化で切り出された一部サービス部分でした。
このサービスは普段はあまり開発で触れられることがなく、属人化が進んでいました。
- 仕様がわからないので、エラーメッセージを読んでもぴんとこない
- アラートのチューニング自体もどう行っていいのかわからない
という状態です。
よって、**「アラート削減」と同時に「属人化の脱却」**を裏目標に設定しました。
やったこと
アラート削減方法とその準備作業については、おそらくみなさま予想通りのことしかやっていません👿
むしろ見送ったタスクもあるのでそれより少ないかも。
前述の通り、銀の弾丸🔫など存在しないことが身に沁みました。
アラートの削減について
アラートの集計
直近約2週間で発生したアラートを集計し、抑制対象の優先度付を行いました。
地味に時間がかかる上、ログ出力状況によっては根気がいる作業です…。
だからこそオオカミ🐺が発生しがちなのでしょう。
が、可視化すると対応すべき部分が一目瞭然になったのでやった甲斐はありました。
（※7割を占めているエラーは既に対応済のものです😷）
ログと発生理由の一覧化
アプリケーションコードで出力されるログを吸い出し、「なぜこのログが出るのか」を整理して一覧化しました。
必然的にソースを読み解くことになるので、苦しみつつもいい経験になります👿（なったはず）
アラート通知のチューニング
上記の調査を踏まえて、通知の閾値を調整しました。
まずいちばんに思いつく手そのままですね👅
サービスのアラート通知の仕組みには、DatadogのMonitor Manageを利用しています。
対象のエラーログをログ検索で引っ掛け、抑制を入れているものは一定期間内に一定数以上が発生したらSlackに通知する仕組みです。
ここの抑制対象を精査し、チューニングすることで通知数を減らしました。
そしてお察しの通り、これは一時しのぎです😷
3.1.3 固定の閾値を決めることだけが方法ではない
『入門 監視』 より
とはいえ、「まずできること」でエンジニアの注意力やメンタル面に余裕を取り戻すため、これが最速の手段と判断しました。
結果として、アラート発生は減少し、また「これ大丈夫だよね」という確認作業に使われる時間も減っています。
属人化の脱却
ここからが属人化対策としてやったことです。
アラート通知のチューニング方法のフロー作成
何かができるようになっても属人化しては意味がありません。
アラート管理についても同じです。
しかし、たとえ新規参入者でもこれを見れば対応できる！というトリセツがあれば、作業ハードルや心理負担は格段に減るのではないでしょうか。
ということでフローを作成しました。
このアラート抑制していいの？という判断には、前に触れた「ログと発生理由の一覧化」したファイルを参考にしつつソースを読んでもらい、属人化を薄める狙いです。
アラート発生時の対応フロー作成
もちろん、インシデント発生時の対応フローなどは既に社内に存在し、周知も行われています。
しかし、慣れないコードでアラートが発生した場合、どこを見ればいいのか・どう判断すればいいのかと迷うことはコードを知り尽くしたベテランでない限り誰にでも起こり得ます。
ということで、これについても対象サービスのアラート発生時フローを作成しました。
とはいえ特別なことはなく、この辺見てね、というリンクをペタペタ貼ったぐらいです。
改めてフローを作成したというより、対応の解像度を上げたというイメージです。
資料リンクが集約されているだけで、わたわたしているときは割と助かるのが個人の所感です。
（ドキュメントを増やすと管理コストが増えるという問題は別途あります😢）
やらなかったこと
ログ自体の削減
本来は！やるべきです！
3.1.4 アラートを削除し、チューニングしよう
『入門 監視』
本来はやるべきです。すみません。
今回は以下を理由に一旦見送りました。
- サービス根幹部分に近く、不用意にログを削ると障害時の経緯が追えなくなる可能性がある
- まずはアラートのストレスを削減 = 通知数を減らすことに注力する
アプリケーションコードのリファクタリング
本来はry
これも上とほぼ同じ理由で見送りました。
リファクタリングを進めたい気持ちもありつつ、まずはアラートを減らし属人化拡大の防止を優先しました。
とはいえコードリーディングの最中に気になったことは随時メモし、また別のタイミングで取り組みたいなあという所存です📝
やってみて
全然目新しいことがなくて、「なんだよ」と思われてしまったかもしれません。
ここでちょっと計算をしてみます📝
削減前までアラートの影響確認に掛かっていた時間を、仮に3分/回とします。
２週間で85回のアラートだったので、85 * 3 = 255分をアラート確認に使っていました。
稼働日10日間で割ると1日のうち255 / 10 = 25.5分を割いていたわけです。
なお、人間が一度途切れた集中を取り戻すには23分かかるという研究結果もあるそうです。
そして、今回削減したアラートに掛かる時間を計算してみます。
37 * 3 / 10 = 11分/日です。
さらに、ログを整理して一覧化したのでソースを辿って原因を探る時間も短縮できます。
1分短縮できるとして、37 * 2 / 10 = 7.4分/日です🎉
状況は様々なので一概には言えませんが、超単純計算で1日のアラートに割く時間を25分→8分にカットできました。
まとめ
やはりアラートやログの調査・整理には時間がかかります。
日々の通常業務をこなしながら、隙間を縫ってやるには少し苦しいものがありますね。
だからこそ、まとめて時間をとって対応すべきかもしれません。
返せない負債はチリツモで膨らんでいき、本来優先したい通常業務の効率を落としていては元も子もないですよね。
弊社のTFDは良い機会を与えてくれたので、いい会社だなあと自慢しておきます。
ぜひ20%ルール取り入れてみてはいかがでしょうか。
そしてオオカミ少年🐺を密かに飼っている村の一助になれば幸いです。
明日の担当は @hide_shi_ さんです。
お楽しみに🎁