CASE手法：人道的なモニタリング

ヂィィィィーン！ 午前3時、素晴らしい夢を見ていると、突然電話がかかってきました。 今週は勤務中ですが、どうやら何かあったようです。 自動システムが呼び出して、何が問題なのかを調べます。 これは現代のコンピュータ システムを管理する上で重要な側面ですが、人々にとって通知をより適切なものにする方法を見てみましょう。

数十年にわたるさまざまな監視チームでの職務を通じて生まれた監視哲学を理解してください。 彼女はロブ・エヴァシュチュクの本物の聖書に大きな影響を受けました。 アラートに関する私の哲学 （私の通知哲学）の書籍に収録されています。 Google SRE、ジョン・アルスパウの本 アラート設計に関する考慮事項 (アラートの設定に関する注意)。

ケリー・ダン, アリジット・ムケリー и マキシム・ペタッツォーニ — 投稿編集にご協力いただきありがとうございます。

ケースとは何ですか?

次のような美しい略語を考え出すことにしました ブレンダン・グレッグのUSEメソッド または トム・ウィルキーのREDメソッド。 私はそれを呼びます CASEメソッド。 彼は、自動モニタリングを使用する際に注意すべき XNUMX つの点について説明します。

• Cテキストが多い (コンテキスト限定)
• A実行可能な (実用値)
• S症状に基づく （症状を重視）
• E大切にされている （学年）

CASE を使用すると、通知を健全な無関心で扱い、夜に人々を起こさないようにすることができます。 モニタリングは、有用性と有効性について定期的に評価する必要があります。 通知を受け取った人は、より良いメンタルモデルを持ち、より自信を持てるようになります。

覚えやすくするために、CASE [つまり、ケース、理由 - ] が必要であると想像してください。 翻訳者のメモ] を使用して各アラートを正当化します。 ：サングラス：

そして、なぜこんなことになったのでしょうか？

勤務中は苦痛になることがある。 理由はたくさんあります。 CASE によってそれらがすべて排除されるわけではありません。 しかし、これを使用すると、夜に目が覚めてより良い通知が得られるようになります。 この方法は、この問題にも役立つさまざまな組織プロセスをカバーしています。

RED メソッドと USE メソッドの利点は、その助けを借りて、作業方法を知るだけでなく、お互いに同じ言語を話せることです。 CASE 手法により、システムを保護しながら同僚を忙しくさせる通知についての議論が容易になることを願っています。

重要なのは、通知が健全な無関心で扱われる文化を組織内に作り出す必要があるということです。 通知は特定の目的のために作成できますが、後でその価値が失われるわけではありません。 なぜこの通知を設定したのでしょうか? その基準はどれくらい前に改訂されましたか? CASE を使用すると、これらの質問に答えることができます。

コンテキストヘビー - コンテキストバインディング

午前 3 時は、気の利いた言葉がたくさん含まれるメッセージを読むのに最適な時間帯ではありません。 効果的に対応するには、情報が必要です。 理想的には、これはコンテキストがすぐに明らかになる特定の問題に関する情報である必要があり、これが可能になるように通知を構成する必要があります。 これは「観察」と「見当識」です。 OODAループ。 常に人の注意をそらすことはさらにコストがかかるため、この設定に時間を費やすのは恥ずべきことではありません。 お互いを尊重しましょう。

問題には多くの原因があります。 特に幽霊。

どうすれば当番職員を助けることができますか? 当番職員が最初に目にするのは通知なので、それに基づいてすべての仮説を立てます。 次に、指示やダッシュボードを確認しますが、一般的な情報だけでなく、特定の通知に関するデータが常に存在するのでしょうか? Alspaugh 氏は、「通知をどのように解釈し、どのように対応するかを考えてください」とアドバイスしています (スライド 29)1。 適切な通知は、しきい値によって設定されたものだけではなく、勤務中の担当者に焦点を当てています。

そこで、通知コンテキストを改善する方法に関するアイデアをいくつか紹介します。

• 通常の説明やダッシュボードだけでなく、特別に作成された便利なものをユーザーに表示します。 以前は、私と彼らは特定の通知用に構成された調査ダッシュボードを使用していました。 これは問題がわかっている場合には役に立ちますが、他の人を混乱させるだけです。 ここでバランスを見つける必要があります。
• 通知の歴史について教えてください。それは新しいものですか? それは頻繁に機能しますか？ 季節限定ですか？
• システム状態に対する最近の変更を表示します。 最近何か変化はありましたか？ (たとえば、展開や機能の有効化/無効化など)。
• 関係を示し、メンタル モデルに情報を提供します。システムの依存関係は、できれば機能性を示すものとともに明確に表示される必要があります。
• ユーザーをチームにすばやく接続します。ユーザーは進行中のインシデントを確認できますか? あるいは、社内の他の誰が通知を受け取ったかを確認できますか? プログラム 事故管理 活性化された？

理想的には、インシデント管理プログラムは、インシデント調査の通知コンテキストを改善する方法についてのアドバイスを提供します。 取り組むべきことは常にあります。

実用的 - 実用的な価値

当直職員は通知に対して何か対応すべきでしょうか？ 何もする必要がない場合、または何をすればよいか不明な場合、なぜ彼を起こしたのですか? 勤務中の人を煩わせ、アクションを必要としない通知は避ける必要があります。

imgur.comの投稿を見ます

どうすればいいですか？ なんでしょう？

以前、システムがシンプルでチームが小規模だったとき、私たちは状況を常に把握するためだけに監視を設定していました。 ヒープの負荷が増加したという通知により、その後サービスが誤動作した場合のコンテキストが得られます。 私たちのシステムは常にさまざまな重大度の機能低下状態で動作しているため、大規模な場合、このような通知は混乱を引き起こすだけです。 これはすぐに次のことにつながります 通知による疲労感 そしてもちろん、感受性の喪失にもつながります。 したがって、当直職員はそのような通知を無視するかフィルタリングすることさえあり、必要に応じて常に応答するとは限りません。 この罠に落ちないでください。 すべての通知を連続して設定して、見捨てられたフォルダーに電子メールで送信しないでください。

実用的な価値のある通知は次のようになります。

• 通知には、単にニュースを報告するだけではなく、アクションが必要です。
• このアクションを自動化するのは困難または危険です。 アクションが自動化できるなら自動化して、人々に迷惑をかけるのはやめましょう。
• 通知には緊急の推奨事項が形式で含まれています サービスレベルアグリーメント (SLA) または 目標回復時間 (RTO)。 その後、当直担当者は組織のインシデント管理プログラムを起動できます。

明確にしておきたいのは、API の最も重要な SLO (サービス レベル目標) についてのみ通知を受け取るべきだと言っているわけではありません。 SLO モニタリングは常に断片化および分割されており、すべてのサービスに対して同じアプローチが必要です。 お金を払ってくれるクライアントにとって最も重要な SLO を追跡することになるのは明らかです。 ただし、データベースなどのインフラストラクチャの SLO も監視する必要があります。 すぐに、社内の顧客に対応し、サポートしなければならなくなります。 など、無限に続きます。

症状ベース - 症状に重点を置く

好むと好まざるにかかわらず、あなたは分散システムで作業しています (Kavaj)2。 その結果、サービスを分離し、障害から保護するためにさまざまな戦術を使用することになります (Trainor et al.)3。 また、ガベージ コレクションの遅延やデータベース クエリの停止は問題を示していますが、近い将来にユーザーに問題が発生しない場合は、急いで修正する必要はありません。

これらは重要な信号であり、実用的な価値があるかもしれませんが、ユーザーの邪魔にならないのであれば、係員の注意をそらすほど緊急ではありません。 原因ベースの通知は、システム障害に関するメンタル モデルのスナップショットです。 障害の考えられる原因をすべてリストアップしようとするよりも、重要な症状を追跡する方が良いでしょう。

通知を意味のあるものにするには、次の点に焦点を当てます。 パフォーマンス指標、ユーザーにとって重要です。 Evashchuk 氏はこれを「ユーザーの監視」と呼んでいます。 この哲学は組織全体に適用する必要があることを忘れないでください。 サービスのインフラストラクチャの深いところで緊急の問題が発生した場合、適切なチームが問題に対処します。 このような障害からシステムを保護することは、まったく別の問題です (Trainer et al.、重要な依存関係を最小限に抑えるための戦略に関するセクション)3.

症状はそれほど変わりません

リチャード・クックは、複雑なシステムには欠陥、欠点、問題がたくさんあることを思い出させます4。 考えられるすべての理由をリストアップしようとするのは、シシュフェの仕事です。 問題を説明しようとしますが、問題は常に変化します。 Cindy Sridharan 氏は、「システムは毎秒完璧な状態である必要はない」と考えており、より人間的なアプローチを使用する方が良いと考えています (「分散システムの可観測性」 (「分散システムの監視」)、7)5.

インシデント後の通知を避ける

通常、原因の通知はインシデントを修正するように構成されています。 そして、何が起きたのかについてのこうした限定的な通知は、誤った安心感を生み出します。なぜなら、システムは常に新しい突破方法を考え出すからです。

原因通知に騙されないでください。 次のように考えた方がよいでしょう。

• なぜ症状ベースの通知では問題に気づかなかったのでしょうか?
• ユーザーのコンテキストを改善すると役立つでしょうか?
• 何が起こったのかについての通知を蓄積するのではなく、より迅速に診断を行うために監視ツールをどのように改善できるでしょうか?

診断用の監視ツールは、症状から解決策に移行する方法として考えた場合にのみ役に立ちます。 このフィードバックがなければ、過去の失敗についての遅れた通知やグラフが大量に届くだけで、将来の失敗については何も言われないことになります。 これは組織にとって防御から攻撃へ移行する絶好の機会です。 そして開発者とプロダクトマネージャーは同じ期待と明確な目標を持つことになります。 ケース - CASE (:wink:) - は通知ごとに明確です。

理由に基づく通知は適度に許容される

私たちのシステムでは、原因に基づいた通知に関してほとんど選択肢が残されていないことがあります。 また、勤務中の担当者は、症状が間違いなく失敗につながるため、実際的な価値があることを完全に理解している場合もあります。 もしかしたら、何が起こっているのかよく分からず、安全のために通知を設定しているだけかもしれません。 このアクションは、システムを変更してパフォーマンスの問題を解決できるまでの一時的なものであることを願っています。
このような状況に対処するときは、CASE の他のコンポーネントを念頭に置いてください。 一時的なものだからと言って、頭で考えることをやめていいわけではありません。

評価済み - 評価

システムに変更を加えると (新しいコード、新しいインフラストラクチャなど、新しいものは何でも)、障害の範囲が拡大します (Cook、3)。4 この通知はまだ期待どおりに機能していますか? システムの明確かつ最新のメンタル モデルと一部のサポート通知への対応経験 予防的アプローチ - これらが主な機能です 学習指向の組織。 システムの欠陥は常に進化しており、私たちはそれに追いつく必要があります。

各通知が期待どおりに機能するようにするには、その品質を常に評価する必要があります。 親愛なるリーダーの皆さん！ このプロセスの確立を支援していただければ、チームにとってははるかに簡単になります。 評価のアイデアをいくつか示します。

• 使用 カオスエンジニアリング, 試合日 または他の通知テスト方法。 チームは、複雑なインシデント管理システムに依存することなく、自分たちでそれを行うことができます。
• すべてのインシデント関連通知の収集をインシデント管理プログラムに組み込みます。 有益、有害、不適切、不明瞭などにマークを付けて、フィードバックとして使用します。
• 適切な通知は頻繁にトリガーされず、慎重にテストされます。 すべてのリンクが機能していること、正しいコンテキストを指していることなどを確認してください。
• 通知がまったく起動されない場合、または通知が頻繁に起動される場合は、何か問題があります。 修正するか削除してください。 過度の受動性や活動性に注意してください。
• 通知のタイムスタンプに有効期限を設定します。 有効期限が切れている場合は、CASE メソッドを使用して通知を評価し、タイムスタンプを更新します。 食品と同じように、賞味期限も定期的に確認しましょう。
• 通知を改善するプロセスを簡素化します。 モニタリングをコードとして使用し、通知を Git リポジトリに保存します。 プル リクエストは、チームとの連携に役立ち、過去の通知の履歴を提供します。 また、通知を変更したり、通知の責任者に許可を求めたりすることを恐れることはなくなります。
• 簡単な場合でも通知のフィードバックを設定する Googleフォーム、そのため、当直職員は通知を役に立たない、または邪魔なものとしてマークします。 通知自体にリンクまたは行動喚起を埋め込み、定期的にフィードバックを確認してください。
• チーム内でルールを確立し、仕事が少ないときは当直者に業務を簡素化させます。 あなたの後のすべてが以前よりも少し良くなりますように。

まとめ

CASE メソッドは、開発者や組織が自動通知の設定と送信について話し合うのに役立つと思います。 XNUMX 人の開発者が CASE 手法を使用して通知の評価を開始すると、組織全体が他の開発者、管理者、インシデント管理プログラムと協力して通知を良好な状態に保つことができます。 これには特別なツールや複雑なプロセスは必要ありません。

業界全体が、一流の顧客サービスを犠牲にすることなく、勤務中の人的要因について考える必要があります。 これらすべてのツールと実践は改善可能であり、改善する必要があります。 CASEメソッドがこれに役立つことを願っています。

改善された通知をお楽しみください。

出所： habr.com