Hideki Kinjyo

社内でのサービス監視についてのレベルアップを見据え、体制や利用ツールの見直し・社内への啓蒙を行う。 具体的には、「アプリケーションエラーの整理(割れ窓状態の解消)・対策」「モニタリングツールやアラートの見直し」「社内メンバーへの意義共有やトレーニング等の啓蒙」を3本柱として、SREチームやネイティブアプリケーションチームも巻き込んで活動をした。 当時の取り組み内容の一部は会社の技術ブログでも発信している。 https://tech.connehito.com/entry/practical-monitoring https://tech.connehito.com/entry/monitoring-at-ease 1. アプリケーションエラーの整理(割れ窓状態の解消)・対策 当初からエラー管理ツール(Sentry)は導入されていたものの、毎日のようにエラーが通知されるような状況にあった。これはメンバーの心理に割れ窓状態を生み出し、本当に対応すべきエラーやバグへの対応が遅くなる事は課題であると認識して解消を目指した。対応可能なエラーは対応すると同時にアプリケーション側のエラーハンドリングを再設計し、恒常的にエラー通知が起きる状態を回避できるようになった。 2. モニタリングツールやアラートの見直し インフラ側のモニタリングを見直して、それまではデータソースごとに種々のチャンネルに別々のフォーマットでアラートを飛ばしていたものを、致命度のレベルに応じて選り分けるようにデザインを行った。これにより、「サービスが危機的な状況にあり、今すぐ対応が必要であるもの」が一目瞭然になるようになった。 書籍「入門 監視」に書かれている内容を基礎とし、致命度の高いアラートについてはPagerDutyに集約管理するようにしたもの。 3. 社内メンバーへの意義共有やトレーニング等の啓蒙 アプリケーションエラーやインフラのアラートの見直しによりサービスの状況を理解しやすくすると同時に、各モニタリングツールの利用方法や対応フローについて形式知化・トレーニングをおこなった。例えば「アラートが飛んできたのはわかっても、メトリクスから実際に何が起こっているかを想像するのが難しい」といった問題を解消するもの。 具体的な取り組みは大まかに3つ。 1つ目は、AWS CloudWatchを始めとした各ツールの画面説明・操作方法、及びアラートの設定項目について意義や背景の共有を行った。2つ目は、インシデント発生時の対応フローの確立やコミュニケーション方法についてのガイドラインの策定、インシデント記録やポストモーテムの実施・管理のルール化。3つ目は、仮想的に用意した環境上でサービスパフォーマンスの低下した状況を発生させ、インシデント対応経験の浅いメンバーを中心として実際にインシデント解消に取り組む疑似演習の実施。 これらの包括的な施策により、監視やインシデント対応といった取り組みが特定のメンバーに依存せず「民主化」されていく事を目指したのが本PJ。チームやサービスのスケーラビリティを保ち続けるには、経験の深いメンバーによる対応力にのみ依存した状態では限界があるという考えをCTOに打診したのを起因とするもの。その後は部門の半期OKRとして取り上げられ、協力のもとでプロダクトチーム全体を巻き込みながら実施した。