Zenn
🤑

僕たちはアラートを管理できない

2021/01/24に公開
ポエム
tech

アラート管理がうまくできない。
だから私の頭の整理のために私がアラート管理について理解していることについて一度まとめようと思う。

なぜアラート管理が必要なのか

アラートを管理する目的はシステム（サービス）の信頼性を保つためになる。

ここでいう信頼性とはSRE用語での信頼性と同義になる。 [1]
この信頼性というものはシステムを利用するユーザーが期待する信頼性への要求[2]と、乖離しはじめたときにシステムへの登録率、アクティブ率、退会率、評判や満足度[3]に影響を与える。 [4] [5]

システムにおいてユーザー数やアクティブ率はKPIによく使われる重要指標（もしくはKPIになる指標の計算に使われる指標）であるため、この指標に関連するアラート管理は重要なものになる。

アラート管理における問題

アラート管理におけるよくある問題には下記になる。

  • オンコール担当者の疲弊
  • オンコールチームの人員増加
  • 開発者 vs オンコール担当者

24/365[6]を求めるシステムでは夜間や休日でもオンコール担当者は待機してすぐに対応することを求められる。
そのため飲酒や外出などアラートの対応に弊害がでるようなことは制限されるため、私生活に弊害がでる。

また、よくある問題としてアラートが異常ではないオオカミ少年の問題だ。
これはアラートではないことに対して動かされることへの不満と、本当に問題だったときに見逃したさいの自責と他者からの叱責になどによって疲弊に繋がる。 [7]
新しく入った人員はこのアラートが異常かどうか判別することができず疲弊してしまい、人員増加の弊害にもつながる。

こういったオンコール担当者の疲弊はオンコール体制の崩壊につながってしまう。

オンコールでは異常の判別、異常の解決[8]を求められるため異常に関する知識が求められる。
これは管理するシステムにもよるが複雑なシステムや、高難易度のシステムを運用しているとオンコールチームの人員増加に弊害がでる。

チームの人員を増加できないと属人性へつながり、その人員がいなくなったさいにオンコール体制が崩壊するリスクにつながる。
また、ある一定の人数がいないとオンコール体制を維持することができない。
少人数ではオンコール担当者の疲弊が加速してしまうため一定の人数を維持し続けなければいけない。

開発者 = オンコール担当者であれば問題ないが、違う場合にはここで対立が起きるときもある。
よくあるケースでは開発者の変更が伝わってなくオンコール担当者が適切に判断できないケースだ。 [9]
特にこういったときに夜間などに起こされるとかなり疲弊する。

対立が深まり官僚的に申請の要求や、強権による横槍などが発生するようになると末期だ。
こうなると最終的にオンコール担当者だけではなく開発者までもが疲弊する。

アラート管理の構成要素

アラート管理における構成要素を抜き出して整理した結果、下記のような構成になる。

一般的にアラート管理と呼ばれるものは構成図でいうAlert Management、Incident Management、Problem Managementの複合であるものになる。 [10]
そのためアクターのOn-Call Team、Incident Team、Dev Teamも兼任している可能性が高い。

本記事ではわかりやすくするために責務を分離して話をすすめる。

Alert ManagementとOn-Call Team

まずアラートとは何かを定義する。 [11]

  • アラートとはシステムが異常[12]な状態になったというイベントである
  • アラートとはシステムが将来的に異常な状態になるというイベントである

このイベントを定義して、イベントの発生と解決を管理するのがアラート管理になる。

アラートはイベントになるため問題が解決するまでは何度も発生する。
問題の解決は後続でするため、それまでは何度も発生することを前提にフローを構築する必要がある。

オンコールチームはこのイベントを受けて、下記のフローに沿って対応をする。

  1. 異常が問題であるのか確認 [13]
    2. 問題でない場合はアラートの定義を直す
    3. 問題だがすでにProblem Managementに登録済みの場合はIssueに追記
  2. 問題の影響を判別
    • ユーザーに影響がある場合
      4. Incident Managementに登録
      5. 以降はIncident Teamで問題を解決する
    • ユーザーに影響がない場合
      7. Problem Managementに登録
      8. 以降はDev Teamで問題を解決する

例えばOn-Call TeamとIncident Team、Dev Teamを兼任していて、問題の優先順位が高い場合はオンコール担当者が問題の解決を即座にするケースもある。
しかし、これは2以降の対応を1人で問題を解決したケースになるため、構成とは矛盾しない。

このフローに則るには下記の情報が必要になる。

  • 問題を判別するための情報
  • Incident Managementに登録するための情報
  • Problem Managementに登録するための情報

これをアラートに記載するか、アラートに関連するナレッジとして溜める必要がある。
構成の中には含めていないがこのナレッジは重要な構成の一つになる。
ナレッジを適切に溜めれればアラート管理における弊害で書いたオンコールチームの人員増加の解決策になる。[14]

このアラート管理を評価する指標は下記になる。

  • MTTD (平均検知時間)
    • 異常が起きてから異常を検知する時間
  • MTTA (平均確認時間)
    • 異常が起きてからオンコール担当者が確認するまでの時間
  • MTTT (平均判別時間) [15]
    • 異常が起きてからIcident Management、Problem Managementに移す時間
  • オンコール担当者別のアラートの対応数
  • システム別のアラートの対応数

ここではMTTR（平均復旧時間）を伸ばしている要因の特定、オンコール担当者の疲弊、システムの品質を見るのが目的になる。 [16]

このアラート管理はある程度自動化できる。
例えばアラートの定義によって自動でProblem Managementへの登録、Incident Managementへの登録を自動にすることでオンコール担当者への負担を減らせる。
しかし、異常が問題であるのか人が確認しなければいけないため、うかつな自動化では後続での負担になる。 [17]
特にIncident Managementでは複数の人がかかわるためここの自動化は慎重になる必要がある。

注意点としてアラートの自動化では後続を自動で解決するべきかはよく考える必要がある。
Problem Managementでは問題の根本解決を求められるため自動で解決してはいけない。

Incident ManagementとIncident Team

まずはインシデントを定義する。 [18]

  • インシデントとはユーザーが期待したことをできなかったという出来事である

このインシデントの発生と解決をするのがインシデント管理になる。
そのためインシデントについて話すときはシステムを利用するユーザー目線に話す必要がある。 [19]

インシデント管理の目的はユーザーが期待する操作をできるようにすることになる。
再発を防ぐ根本的な問題の解決は後続のProblem Managementで解決する。 [20]

インシデントは2つの経路から発生する。

  • Alert Managementからユーザーに影響を与えている問題
  • Support Deskからユーザーの操作で解決できないと判断された問題

ドッグフーディングしていればそこからインシデントが発生する経路もあるが本記事では割愛する。

インシデントチームはインシデントを受けて、下記のフローに沿って対応する。 [21]

  1. インシデントのレベルを判別
    • すぐに解決する必要がない場合はProblem Managementに登録
    • なるべく早く解決する必要がある場合はProblem Managemntに優先度をあげて登録
    • すぐに対応する必要がある場合はフローを続行
  2. インシデントチームを招集
    • レベルに応じてインシデントに関連するメンバー（開発者、経営陣、サポート、営業、広報など）を招集
    • チームのリーダーや記録を残す書記の任命
    • チームへ状況の共有
  3. 問題の特定と解決、ユーザーへの広報や連絡
  4. 問題の解決後に事後検証 [22]
    • 根本原因が残る場合はProblem Managementに登録

中には事後検証の読み合わせ会や、一定周期でのインシデントの分析をして改善するケースもある。 [23]

このインシデント管理を評価する指標は下記になる。

  • MTTI (平均識別時間）
    • 問題が発生してから問題の原因を特定するまでの時間
  • MTTR (平均復旧時間)
    • 問題が発生してから問題を復旧するまでの時間
  • SLI、SLO、SLA
  • システム別のインシデントの発生数

ここではシステムの信頼性を見ることが目的になる。 [24]

インシデント管理では複数の職種のメンバーが参加するためコミュニケーションに問題がおきやすい。
システムの規模が大きくなるほど関連するメンバーが増えるため、このコミュニーケーションフローの整備や自動化などがMTTRの改善に直結する。

Problem ManagementとDev Team

まずは問題を定義する。

  • 問題とはアラートやインシデントを引き起こす原因である
  • 問題とはアラートやインシデントを将来的に引き起こす原因である

この問題の登録して優先度にあわせて解決するのが問題管理となる。

問題を解決する方法はいくつかある。

  • 問題を発生させない
  • 問題の影響範囲を極小化する [25]
  • 問題が起きても自動で解決できるようにする [26]

この対応によってアラートの定義が変わるときにはあわせて定義を変更する必要がある。
例えば自動で解決できるようにした場合にその解決するまでは正常な挙動になるため、検知する時間を変更するなどだ。 [27]

開発者のチームは他の機能開発などのタスクと合わせてこの問題を管理する。
問題の優先順位の考え方としては下記になる。

  • すべてのタスクを止めて最優先で対応する
  • 通常のタスクより優先度を高く対応する [28]
  • 通常のタスクと同じ優先度で対応する

スクラムやアジャイルなど開発者のチームで採用している手法にあわせて問題の解決の優先度を決める。
優先度によってはすべてのタスクを止めて最優先で対応しなければいけないため、この差し込みを許容した手法を採用しなければならない。
もし、期日までに対応しなければアラートやインシデントに繋がるならその期日までに対応できるように調整する。 [29]

この問題管理を評価する指標は思いついていない。 [30]
採用している手法にあわせて指標を定義して、改善できるようにする必要がある。

アラート管理の難しさ

構成要素を洗い出したことでどのような形になるべきか見えるようになった。

しかし、なぜ私はアラートを管理できないのか。
ここは自分の主観であり、整理、分析できていないことになるため箇条書きになる。 [31]

  • 人員が足りず兼務になっている
  • 人員が足りずフローを回しきれないためある程度簡略化したフローが必要になる
    • 今いる人数での回しきるための落とし所はどこなのか
    • サービスや自動化
      • 複雑化するとそれ自体がネックになる
  • 不満を抱えても改善するさいにステークホルダーが多くなる
  • 登場する各チームの目的、目標が違う
    • その中でアラート対応を改善しようという労力の高さ
    • 改善し続けることが難しくなる
    • 対立構造の加速
  • 構成要素が多く全体最適、部分最適の話がある
  • 各種指標が曖昧で決定しづらい、指標を機械的にだしづらい
    • 曖昧な概念の指標はどのように正しさを求めればよいのか
    • 間違った指標をどのように考えて変えればいいのか
    • 人力で面倒な指標ををだす仕事は不毛すぎる
    • よって指標がなく漠然とアラート対応をしている
      • 現在のアラート対応に問題があるのかわからない状態になっている
      • アラートが日常になるとそれが普通になり問題に気づけなくなる
  • アラート管理は機械を相手に黙々とする必要がある [32]
    • 知性を感じない奴隷のような仕事
    • 金で殴るか、AIが仕事を奪うか、諦めて奴隷になるか
  • アラートの定義の難しさ
    • 人の書いたアラートはわからない
      • なぜ、それを異常としているのか
      • アラートに対する考え方が違う
  • ナレッジの蓄積が難しい
    • 人間にナレッジを溜めるのは無理
      • 探せない
      • 司書を作るか、AIが仕事を奪えば可能性あるのか
    • 全体最適として必要なこと、個人としてやりたいことが一致しないことによるモチベーションの定価
  • 問題管理が難しい
    • 手法が多い
    • 問題管理の手法だけで本になるレベルの難しさがある
  • システムの品質をあげることが難しい
    • 品質をあげるためにシステムのアーキテクチャを抜本的に変えるという大きなコストがかかるケース
    • 品質という曖昧なものをどう共有して、なぜ改善しなければいけないのか
  • 心理的安全性の確保
    • 他責の人間がいるときのプレッシャー
      • 疲弊が加速する
    • 個々人によって安全性のラインが違う

ここまで書いてわかったのが私の考え方の前提として人間には完璧なものを作れない。だから改善し続ける形にするべきだというのがある。
それに対して前に進んでいる感触が持てていないからアラートを管理できていないと感じていると思う。 [33]

つまり個人の感情の問題である。
ではなぜ前に進んでいるように感じれないのかといえば、このアラート管理における各種指標を適切に見えていないからだ。

この各種指標が見えないというのはチームや会社として問題にはならないのか。
見えないということはユーザーの期待する信頼性への要求と実際の信頼性が乖離しても気づけないということだ。
気づくためには各種KPIが伸びない、下がってしまったときに分析してようやく気づけるか、肌感としてまずいという曖昧な共通認識を作るしかない。

こう考えると問題はありそうだが、問題を解決するべきかは優先度が関わってくる。
リソースは有限であるためシステムを運用するチームや会社として今は他のことを優先すべきという判断は間違いではない。 [34]

また私の中で進む道が見えていないから、前に進むための働きかけができていないというのもある。
これは主に各種指標が曖昧であり、指標の決定と指標の計測方法が明確になっていないためだ。
わからないものに対して大勢を巻き込んで進むのは難しい。

少しだけ私がアラート対応をできない理由が見えてきた気がする。

参考資料について

本記事を書くにあたっていろいろな資料を読んで、それらの良いところをまとめた形になる。
SRE本や入門監視など書籍、各種アラート管理系のSaaSやインシデント管理系のSaaSのドキュメント、いろんな会社の登壇や事例などになる。
いろいろ読みすぎて何が有益な情報だったか思い出せないので、申し訳ないが参考資料としてだすことはできない。

また、そういった状況であるため本記事における根拠が弱く私はこう考えているというだけの話になっている。

ここまで読んだ暇な人がいれば誰かこういった話に関する資料をまとめてほしい。

脚注

  1. 信頼性とはかなり曖昧な用語でSREがこれを追い求める正しさについては議論が必要。ケースバイケース過ぎて誰もこのシステムに必要な信頼性を定義できない ↩︎

  2. 例えば業務システムでは業務時間内に利用できなくなることは許されないなど。期待値のコントロールとしてエラーバジェットという考えもある ↩︎

  3. とても曖昧なものだが評判や満足度をシステマチックに可視化することはできるのだろうか ↩︎

  4. 問題のあるシステムは利用しない。評判をみて選択しない、退会して別のツールを使う・・・と考えているが、これが正しいかは不明。信頼性を損ねるとどのような指標に影響を与えるのか議論が必要 ↩︎

  5. 書いてて思ったのがとても信頼性とはとても感情的なもので、人によって違うから難しいのかもしれない ↩︎

  6. 24時間365日動くことを求められる ↩︎

  7. だいたい前者。夜中に起こされて異常じゃないとか◯すぞ ↩︎

  8. 解決までするかはオンコールチームの責務がどこまでかによる ↩︎

  9. 大人だから言わないけど◯すぞって思う ↩︎

  10. 会社によって全てだったり、このうちの一部だったりする ↩︎

  11. 一般的な定義ではなく本記事における定義。という予防線だけど一般的にもこれだと思ってる。反論あればコメント欲しい ↩︎

  12. 異常であることを正しく定義できる人は少ない。事前に過不足なく正しく異常を定義できるという考えより、一定のサイクルでアラートを整えていくという考え方が好き ↩︎

  13. これをフローに組み込まなかればいけないのが間違っている気がする。型安全のようにコンパイルすればそれは正しい異常であると確認できる世界はまだこないのか ↩︎

  14. ナレッジを溜めるという行為は難しい。少量のナレッジは問題ないが数が増えると破綻する。またナレッジに書く文章の書き方なんて教わったことないのに誰もが読んだ人に伝わる文章を書けると思わないでもらいたい。コンパイラをもってこい。あとナレッジ書いて維持するのがくっそ苦痛なので私にやらせるな ↩︎

  15. Mean time to triage。造語。通常は構成が複合するので見ないが、分割すると見た方がよい。ここに時間がかかる場合は教育不足、ナレッジの不足などの可能性がある ↩︎

  16. 他にもこういう指標を見ると良さそうという情報があればぜひ ↩︎

  17. 早くここをうまく検知するAIがきてほしい ↩︎

  18. アラートと同様に一般的な定義ではなく本記事における定義。という予防線 ↩︎

  19. アラートとの最大の違い。ここが混在するとアラート管理で考える必要が増えて面倒臭くなる ↩︎

  20. なのでインシデントにおいては運用でカバーとか、一時的に雑な対応は許容される。大事なのはどれだけ早くユーザーが期待することをできるようにするのか ↩︎

  21. 最近の流行によるとこんな感じ？CircleCIとかPagerDutyの事例を読んでるとこういう多い（読んだの前だから企業名は違うかも ↩︎

  22. いわゆるポストモーテム。インシデントのフローや原因の改善が目的 ↩︎

  23. たぶんSRE本にそんな話あったと思う。入門監視にもあったかは覚えてない ↩︎

  24. 他にもこういう指標を見ると良さそうという情報があればぜひ ↩︎

  25. サーキットブレーカーやバルクヘッドとか ↩︎

  26. オートヒーリングやランブックによる復旧手順の自動化など ↩︎

  27. 逆に言えばどの時間までに復旧すべきか決めて、その時間までに復旧できるように決める必要がある ↩︎

  28. 俗に言うなるはや！ ↩︎

  29. 例えばディスクの使用量が100％になるなど。将来の問題に繋がるものはDatadogのMonitoring Modern Infrastructureでいうリソースメトリクスばかりだと思う ↩︎

  30. つまるところアジャイルやスクラムをどう評価するという話になる。この辺は興味の範囲外なのでわからん ↩︎

  31. なので人によって共感できる部分、できない部分は明確になると思う。もし共感できないと思ったらそこを深堀りして教えてほしい。そこにきっと私の問題の解決の糸口がありそう ↩︎

  32. サポートとの違いは人を相手にするか、機械を相手にするか。機械は喜ばない ↩︎

  33. 実際の話、構成要素の6、7割はできている ↩︎

  34. 指標がないと共通認識を形成しないと優先度をあげれないという悩ましさはある。必要なのは煽動力 ↩︎

Discussion