システムモニタリングを最大化していくために
はじめに
このnoteは IVRy Advent Calendar 2022 の6日目の記事として記載しています。
こんにちは。IVRyでエンジニアとしてお手伝いさせてもらっていますk.kです。
システムがどのように機能し、どの程度価値を提供できているかを定量的に把握することはとても重要だと考えています。
以前の記事でDatadogを導入してモニタリング整備を行ったことを紹介させていただきました。
現状、モニタリングによってシステムの安定運用を行っているのですが、まだまだ伸びしろがあると思っています。
そんな中、以下の書籍に出会い、今回はそこからさらにモニタリングを最大化していくために実施したいと考えていることを綴りたいと思います。
ダッシュボードの利用促進
まだまだダッシュボードが浸透していないと感じています。
場合によってはAWSコンソールにログインしてCloudWatchを確認したり、メールで通知されるエラーログを属人的に判断することがしばしばあります。
以下の要因が考えられます。
情報が集約されていない。
まずは優先度の高く比較的容易に収集できるメトリクスのみがDatadogにある状況であり、必要とされる情報が集約されていない。今後はアプリケーションログなど必要なログが集約されるよう改善する。
また、直接集約できない情報についてはノートにメモやリンクを設置することによって読み手を導くことも実施予定。ダッシュボードに文脈がない。
現在は1つのダッシュボードに可能な限り全ての情報を集約してしまっていて、いつ誰がどんな時に見るものなのかといった文脈がない。
ダッシュボードの数が多くなることを恐れず文脈に沿ったダッシュボードを作成していく。
アラートの改善
monitorを使ってslackに通知を行っているが、一旦気づけるにとどまっていて改善の余地ありです。
アクション可能になっていない。
本来アラートをトリガする際にはそのメッセージから調査が可能でどういった手順で何を行うべきかが記載されたものがあるべき。整備が必要。
適切な優先順位付。
アラートは緊急対応するべきなのか自動復旧するのか、など基準が設けられていない。適切な閾値の設定。
一定運用を重ねてきた過去のメトリクスから正常な範囲を定めていく。異常検知の活用。
Anomalyを利用した異常検知の利用は一部のみでまだまだ活用しきれていないため、拡大していく。
ユーザビリティーの観測
以下の観点でメトリクスが整理できていない部分があるので、ユーザーがどのようにアプリケーションを使っているのかを測定し非機能要件をしっかり定めていきたい。
可用性
アップタイム
ページ応答速度
信頼性
MTBF
エラー率
保守性
MTTR
その先へ
エンジニアだけでなくプロダクトに関わる人たちが定量的に観測し、もっと効率を高めることができるかを定期的に振り返る文化を醸成していきたいと考えています。
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。
最後に
一緒に成長していくプロダクトを支えていくエンジニア募集中です！
この記事が気に入ったらサポートをしてみませんか？