じゃーん！ 午前3時に、素晴らしい夢を見て、突然-ベルが鳴ります。 今週あなたは勤務中で、どうやら何かが起こったようです。 自動化されたシステムが問題を把握するよう求めています。 これは最新のコンピューターシステムを管理する上で重要なポイントですが、通知をより便利にする方法を見てみましょう。
さまざまな監視チームでの数十年にわたる私の職務の中で生まれた監視哲学に精通してください。 これは、 Google SREの本に含まれているRob Evashchuk My Philosophy on Alertingの真の聖書と、John Alspoの著書 『 Alert Design for Alert Design』に大きく影響されました。
Kelly Dunn 、 Aridzhit Mukheryi 、 Maxim Petazzoni-投稿の編集にご協力いただきありがとうございます。
ケースとは何ですか？
Brendan GreggのUSE メソッドやTom WilkieのREDメソッド のような美しい頭字語を思いつくことにしました。 これをCASEメソッドと呼びます。 彼は、自動監視を使用する際に注意する必要がある4つのポイントについて説明しています。
- C ontext-heavy （コンテキストバインディング）
- 機能的（実用的価値）
- 症状ベース （症状の強調）
- E評価 （評価）
CASEを使用する場合、通知は健全な無関心で処理され、夜は目覚めません。 モニタリングは、有用性と有効性について定期的に評価する必要があります。 通知を受け取った人は、より良い精神モデルと自信を持つことができます。
覚えやすくするために、すべてのアラートを正当化するためにCASE [つまり、ケース、理由はインタープリターのコメント ]が必要だと想像してください。 ：サングラス：
そして、なぜそれだけですか？
義務は苦痛になる可能性があります 。 多くの理由で。 そして、CASEはそれらをすべて排除するわけではありません。 しかし、彼が夜になると、あなたはより良い通知から目覚めるでしょう。 この方法は、この問題にも役立つさまざまな組織プロセスを対象としています。
REDメソッドとUSEメソッドの利点は、それらの助けを借りて作業方法を知るだけでなく、互いに同じ言語を話すことです。 CASEメソッドを使用すると、システムを保護する通知を簡単に議論できますが、同僚に休息を与えないでください。
一番下の行は、通知が健全な無関心で扱われる組織の文化を作成する必要があるということです。 ケースで通知が作成される場合がありますが、後で価値が失われないという事実ではありません。 なぜこの通知を設定したのですか？ その基準はずっと前に改訂されましたか？ CASEを使用すると、これらの質問に答えることができます。
コンテキストヘビー-コンテキストバインディング
午前3時は、流行語が多いメッセージを読むのに最適な時期ではありません。 効果的に対応するには、情報が必要です。 理想的には、これはコンテキストがすぐに明確になる特定の問題に関する情報である必要があり、これが可能になるように通知を構成する必要があります。 これらはNORDサイクルからの 「観測」と「方向」です。 この設定に時間を費やすことは残念ではありません。常に人の注意をそらすのはさらに高価だからです。 お互いを尊重しましょう。
問題には多くの原因があります。 特に幽霊。
アテンダントを支援するには？ 職務官は通知を最初に見るため、それに基づいてすべての仮説を立てます。 次に、彼は指示とダッシュボードを見ますが、一般的な情報だけでなく、常に特定の通知に関する情報がありますか？ アルスポは、「通知の解釈方法またはそれに対応する方法について考える」ことを推奨しています（スライド29） 1 。 適切な通知は、しきい値だけで構成されているのではなく、アテンダントに焦点を合わせています。
したがって、通知コンテキストを改善するためのアイデアは次のとおりです。
- 通常の指示やダッシュボードだけでなく、有用で具体的に作成されたものをユーザーに表示します。 以前は、特定の通知用に構成されたダッシュボードを使用して調査しました。 これは、問題がわかっている場合に役立ち、他の場合にのみ混乱します。 ここでバランスを見つける必要があります。
- 通知履歴について教えてください：新しいですか？ よく機能しますか？ 季節ですか？
- システムステータスの最近の変更を表示します。 最近何か変わったことはありますか？ （たとえば、機能を展開または有効化/無効化します。）
- 関係を示し、メンタルモデルの情報を提供します。システムの依存関係は、できれば操作性の表示とともに、明確に表示される必要があります。
- ユーザーをチームにすばやく関連付けます。現在のインシデントが表示されますか、それとも社内の他の誰が通知を受信したかを見つけられますか？ インシデント管理プログラムはアクティブ化されていますか？
理想的には、インシデント管理プログラムは、インシデントを調査する際に通知コンテキストを改善する方法に関するヒントを提供します。 取り組むべきものが常にあります！
実用的-実用的な価値
アテンダントは、通知に応じて何かする必要がありますか？ 何もする必要がないか、何をすべきかが明確でない場合、なぜあなたは目覚めたのですか？ 義務を果たし、アクションを必要としない通知を避ける必要があります。
どうする？ 何が必要ですか？
以前は、システムが単純でチームが小さい場合、監視を設定して、すぐに把握できるようにしました。 ヒープの負荷が増加したという通知は、サービスが誤動作した場合にコンテキストを提供します。 私たちのシステムは常にさまざまな重大度の低下状態で動作するため、大規模では、このような通知は混乱するだけです。 これはすぐに通知による疲労につながり、もちろん感度の低下につながります。 したがって、アテンダントはそのような通知を無視するか、フィルタリングするだけでなく、必要に応じて常に応答するわけではありません。 このtrapに陥らないでください！ すべての通知を連続して設定しないでください。後でメールでgodforsakenフォルダーに送信できます。
実用的な価値のある通知は次のようになります。
- 通知には、ニュースの報告だけでなく、アクションが必要です。
- このアクションは自動化が困難または危険です。 アクションを自動化できる場合は、それを実行して自動化し、人々を悩ませることをやめます！
- 通知には、サービスレベル契約 （SLA）または目標復旧時間 （RTO）の形式の緊急の推奨事項が含まれています。 その後、アテンダントは組織内のインシデント管理プログラムを使用できます。
明確にしたい：通知がAPIの最も重要なSLO（サービスレベルの目標、サービスレベルの目標）にのみ来るべきだと言っているのではありません。 SLO監視は絶えず断片化および分割されており、すべてのサービスに対して同じアプローチが必要です。 支払った顧客にとって最も重要なSLOを追跡することは明らかです。 ただし、データベースなどのSLOインフラストラクチャも監視する必要があります。 すぐに内部顧客に対処し、それらをサポートする必要があります。 無限へと続きます。
症状ベース-症状に焦点を当てる
気に入っても気に入らなくても、分散システム（Kavaj） 2で作業します。 その結果、さまざまな戦術を使用してサービスを分離し、障害から保護します（Trainor et al。）3。 また、長期にわたるガベージコレクションまたはデータベースへの思慮深いクエリは問題を示しますが、近い将来ユーザーに問題がなければ、急いで修正する必要はありません。
これらは重要なシグナルであり、実用的な価値がある可能性がありますが、ユーザーに干渉しない場合は、アテンダントの気を散らすほど緊急ではありません。 原因ベースの通知は、システム障害のメンタルモデルのスナップショットです。 障害の考えられるすべての原因をリストしようとするよりも、重要な症状を追跡することをお勧めします。
実用的な価値のある通知を得るには、ユーザーにとって重要なパフォーマンス指標に注目してください。 Evashchukはこれを「ユーザーの監視」と呼びます。 この哲学は組織全体に適用する必要があることを忘れないでください。 サービスにインフラストラクチャの深部のどこかに緊急の問題がある場合、適切なチームがそれらに対処します。 このような障害からシステムを保護することは、完全に別の問題です（Trainer et al。、Aクリティカルな依存関係を最小化する戦略のセクション） 3 。
症状はそれほど不安定ではありません
リチャードクックは、複雑なシステムには多くの欠陥、弱点、問題があることを思い出します4 。 考えられるすべての原因をリストしようとする-Sisypheanの労働。 問題を説明しようとすると、それらは常に変化します。 Cindy Sridharanは、「システムは毎秒完全な状態である必要はない」と考えており、より人道的なアプローチを使用することをお勧めします（ 「Distributed Systems Observability」 、7） 5 。
インシデント通知を避ける
通常、理由の通知はインシデントを修正するように構成されています。 そして、システムが新しい破壊方法を思いつくたびに、何が起こったのかについてのこれらの限られた通知は、誤った自信を生み出します。
理由の通知にだまされないでください。 よりよく考える：
- 症状ベースの通知が問題に気付かなかったのはなぜですか？
- ユーザーのコンテキストを改善することは有用でしょうか？
- 迅速に診断し、何が起こったのかに関する通知を蓄積しないために、監視ツールを改善するにはどうすればよいですか？
診断用の監視ツールは、症状から解決策に移行する手段として使用する場合にのみ役立ちます。 このフィードバックがなければ、過去の失敗に関する遅れた通知や図表に圧倒されるだけであり、将来の失敗に関する言葉ではありません。 組織にとって、これは防御から攻撃に移行する絶好の機会です。 そして、開発者と製品マネージャーには、同じ期待と明確な目標があります。 ケース-ケース（：wink :)-各通知については明確です。
中程度の公差ベースの通知
私たちのシステムでは、理由に基づいた通知に関して選択の余地がほとんどない場合があります。 そして時々、アテンダントは、症状が必然的に誤動作を引き起こすことを十分に認識しており、それは実用的な価値が含まれていることを意味します。 何が起こっているのか分からず、再保険の通知を設定しているだけかもしれません。 パフォーマンスの低下の問題に対処するためにシステムを変更するまで、このアクションが一時的に必要になることを願っています。
そのような状況に対処するときは、他のCASEコンポーネントに注意してください。 これが一時的なものであれば、頭で考えることができないという意味ではありません。
評価済み-評価
システムの変更（新しいコード、新しいインフラストラクチャ、新しいもの）は、障害の範囲を広げます（Cook、3）。 4この通知は引き続き期待どおりに機能しますか？ 明確で関連性のある精神システムモデルと予防的アプローチをサポートするいくつかの通知への対応経験は、 学習指向の組織の重要な機能です。 システムの欠陥は絶えず進化しているため、それに対応する必要があります。
期待どおりに機能するように、各通知の品質を常に評価する必要があります。 親愛なるリーダー！ チームがこのプロセスをセットアップするのを手伝えば、チームにとってはるかに簡単になります！ 以下に評価のアイデアを示します。
- カオスエンジニアリング 、 ゲーミングデイ、またはその他の通知テスト方法を使用します。 チームは、重量級のインシデント管理システムを使用せずに、独自にこれを行うことができます！
- インシデント管理プログラムのすべてのインシデント通知に関するデータ収集を含めます。 有用、有害、不適切、理解不能などのマークを付けます。フィードバックとして使用します。
- 正しい通知はまれであり、慎重にチェックされます。 すべてのリンクが機能することを確認し、必要なコンテキストをポイントするなど。
- 通知が発生しないか、頻繁に発生する場合は、何か問題があります。 修復するか削除します。 過度の受動性または活動に注意してください！
- 通知の有効期限のタイムスタンプを設定します。 有効期限が過ぎている場合は、CASEメソッドを使用して通知を評価し、タイムスタンプを更新します。 食品と同様に、有効期限を定期的に確認してください。
- 通知を改善するプロセスを簡素化します。 コード監視を使用し、Gitリポジトリに通知を保存します。 プールリクエストはチームを引き付けるのに役立ち、過去の通知の履歴があります。 また、通知を変更したり、その責任者から許可を求めたりすることを恐れなくなります。
- 単なるGoogleフォームである場合でも、フィードバック通知を設定して、勤務中の人々が通知を役に立たないか邪魔なものとしてマークするようにします。 通知自体にリンクまたは行動を促すフレーズを埋め込み、フィードバックを定期的に確認します。
- チームにルールを設定します-作業がほとんどない場合は、アテンダントが作業を簡略化するようにします。 すべてがあなたの前よりも少し良くなるようにしましょう。
おわりに
CASEメソッドは、開発者や組織が自動通知の設定と送信について議論するのに役立つと思います。 1人の開発者がCASEメソッドを使用して通知の評価を開始すると、組織全体が通知を良好な状態に保つために他の開発者、管理、およびインシデント管理プログラムと一緒になります。 これには特別なツールや複雑なプロセスは必要ありません。
業界全体は、一流の顧客サービスを損なうことなく勤務中に人的要因について考える必要があります。 これらのツールとプラクティスはすべて、改善が可能であり、改善すべきです。 CASEメソッドがこれに役立つことを願っています。
強化された通知をお楽しみください！
