SRE 関連の領域のことを知らないので、少し学習してみようと思い、関係していそうで、比較的薄い本であったO’Reilly Japan - 入門 監視を読みました。
第11章に、監視アセスメントの実行の章があり、内容が興味深かったので自分なりに理解をまとめてみます。

監視アセスメントとは

監視アセスメントとは何か、監視入門には以下のように記載されています。

  • 何を監視すべきか、なぜ監視すべきかを、システマチックに判断する方法。
  • 何が問題で何が問題でないのかを、考える出発点となる。

監視アセスメントの流れ

書籍の内容に、監視アセスメントは、以下の3フェーズに分けられると考えました。

  1. KPI、技術指標設定フェーズ
  2. 監視項目設定フェーズ
  3. アラート設定フェーズ

個人的に思ったところがあり、書籍の内容を正確に表す図ではありませんが、それぞれのフェーズについて説明します。

1. KPI、技術指標設定フェーズ

KPI、技術指標設定フェーズのフローは以下になります。

監視アセスメントフロー KPI、<wbr>技術指標設定フェーズ.png - Google ドライブ

ビジネスKPIの定義について

書籍では、Tater.ly というスタートアップ企業を例にビジネスKPIの例が記載されています。実際の仕事だと、KPIが定まっていない。定まってはいるが、開発チームに共有がなされておらず、良くわからない場合もありそうです。最近、Saas 関連の指標などは情報が出てきて知識体系の整備が進んでいるので、良くわからない場合は、書籍を参考に開発チームである程度設定してしまうのも良いかと思います。

ビジネスKPIと技術指標の中間指標作成

個人的な経験として、ビジネスKPIがそのままでは技術指標に落ちないケースもあり、ビジネスKPIに影響する中間指標を定める必要があるケースもあるかと思い、書籍にないですが、フローに追加しました。
サービスの役割や、担当機能でビジネスKPIが直接繋がらない等はありそうで、正直その辺りの明確な答えが浮かばないというのがあります。

  • 例
    企業としては、契約数をKPIと置いているが、支援部門向けの社内システムの保守メンテナンスをしている。

例のようなケースだと、会社のビジネスKPIに対しての技術指標の設定というより、支援部門のKPIに対しての技術指標の設定の方がうまくいきそうに思います。

また、以前NPSを中心とした品質測定量のマインドマップを作った | Monotalk という記事で中間指標になりそうなものをまとめていますので、興味ある方はご確認ください。

ビジネスKPIと技術指標の結び付け

中間指標の設定、ビジネスKPIのブレイクダウンがうまくいけば、結びつける作業自体は問題なくできそうです。
結び付けの結果のアウトプットは、スプレッドシート のような表形式でのアウトプットになります。

2. 監視項目設定フェーズ

監視項目設定フェーズのフローは以下になります。
書籍を読んで、印象深かったのが、フロントエンド監視については、インフラアーキテクチャ図をインプットにしなくても設定できることでした。
技術指標設定後は、その他監視項目と独立して、フロントエンド監視項目の設定は実行できます。

監視アセスメントフロー 監視項目設定フェーズ.png - Google ドライブ

フロントエンド監視

RUM の監視をまず行ったほうが良い旨の記載がありました。
書籍内で、RUM の測定ツールとして、Google Analytics がとりあげられています。
アクセス数などの基本指標をタグ設置で取得することができ、RUM については、サイトの速度という形式で記録され、JavaScriptのエラー発生数の記録も行うことができます。

個人的にセキュリティ監視 (HTTP headerのチェック) と、アクセシビリティ監視 (マークアップ、aXe のチェック項目をみる) 系のチェックも実施するのが良いかと思います。
この辺は、Google Analytics だと難しいので別のツールで監視していく形になるかと思います。

インフラアーキテクチャ図の作成

フロントエンド監視以外の、監視項目設定のインプットとなるインフラアーキテクチャ図を作成します。
アプリケーション開発チームだと、インフラチームに資料が存在有無を確認して、なければ作成する流れになるかと思います。

アプリケーションとサーバーの監視

メトリクスとログを技術指標として設定する旨が記載されています。
個人的なメトリクスと、ログの理解は以下になります。

  • メトリクス
    計測された数値項目、大抵時系列データベースに保存される。

  • ログ
    プログラムから出力される何が起きたかを示すテキスト出力。
    ログデータの収集基盤で保持されることもあるし、ログファイルに出力されて終わりのケースもある。

アプリケーションとサーバーの監視項目は、インフラアーキテクチャに大きく依存するところかと思います。

ネットワーク監視

書籍11章には登場しませんでしたが、必要かと思い追加しました。
9章で記載されている内容は、個人的には経験がない分野で難しい内容に思いました。
ネットワークフロー監視とを抑えられれば薄く全体がわかる気がしたので、その辺りは今後おさえておきたいです。

セキュリティ監視

書籍にはコンプライアンスや、規制の必要条件がない場合の監視項目の例が記載されています。

  • SSHログインの試行と失敗
  • syslogのログ
  • auditdのログ

実業務だと、内部統制上の理由からもっと項目が増えるえるように思いました。
書籍にはPCI-DSS の例が記載されており、法律上の規制についての説明があります。

3. アラート設定フェーズ

監視アセスメントフロー アラート設定フェーズ.png - Google ドライブ

監視項目のアラートレベル設定

各監視項目にアラートレベルを設定します。
書籍の3章にアラートには２種類のコンテキストがあると記載されています。

  • 誰かを叩き起こすためのアラート
    緊急の対応を求められるアラートです。

  • 参考情報(FYI)としてのアラート
    すぐに対応は必要はないですが、アラートが来たことは誰かが確認すべきものです。

個人的な経験をもとに、上記アラートをもう少し細分化してみます。

No大カテゴリ小カテゴリlog4jのエラーレベル運用時の対応
1-1誰かを叩き起こすためのアラートシステムエラーFATAL、又は出力されない即時対応
1-2誰かを叩き起こすためのアラートアプリケーションエラーFATAL即時対応
2-1参考情報(FYI)としてのアラート重要度(高)ERROR営業時間内のみ対応
2-2参考情報(FYI)としてのアラート重要度(小)WARN頻発する場合は要確認
  • 説明
    • 1-1 は、リクエストが到達しないケースです。例)WebサーバーのトラブルでAPサーバーにリクエストが送信されない。
    • 1-2 は、アプリケーションエラーで特に重要度の高いもの。例)使用しているユーザーが、エラーでオペレーションを進められない。
    • 2-2 よりも、重要度が低いエラーはアラートという形式ではなく、定期的なレポート出力での閲覧になるかと思われました。

アラート設定

アラートレベルに従って、監視ツールにアラートを設定します。
レベルは、運用しながら見直しが必要になるかと思います。

監視アセスメントをまとめて思ったこと

  • 監視と効果測定は、アウトプットの行動が違うだけで、インプットにするデータは同じケースがありそう。監視項目を考えることは効果測定の項目を考えることにもなる。
  • 3章のアラート、オンコール、インシデント管理は再読する。
  • セキュリティ監視項目は、セキュリティ要件から決まる部分がある。後は監視項目ではない、トレーサビリティのためのデータ記録は必要そうに思った。

参考

以下、参考にした記事になります。

以上です。

コメント

カテゴリー

最近の投稿