原因ではなく症状に注目する理由

※この投稿は米国時間 2022 年 12 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

「ユーザーの関心は、動作していない理由ではなく、動作していないことにある。」

もしこれが真実だと考えるなら、なぜユーザーが関心を持っていることをモニタリングしないのでしょうか？どのような経緯で現状にたどり着いたのでしょうか？

まず、オペレーション担当者がインフラストラクチャに集中していて、問題が発生しているというお客様からの連絡を待つ従来のモデルを見ていきましょう。最初のうちは、合理的な推測と価値観によって、以下の考え方が直感的に理解できます。

• 確実さはあいまいさに勝るため、直接的に一番理解していること、つまりインフラストラクチャに焦点を当てたい。

• 目的は、問題の原因がオペレーション担当者の責任なのか、それとも他にあるのかを把握することである。

• インフラストラクチャに多くのアラートを設定することは、オペレーション担当者が自分に責任がある問題にのみ対応するための最善の方法である。

• 自動化は贅沢なもので、サイド プロジェクトである。オペレーション担当者は主にサポート チケットを切り、アラートに手動で対応するために時間を割くものである。

今後、優先順位が変わるかもしれませんが、この中には無視できないものもあります。まず、この従来の状態における最悪のシナリオを考えてみましょう。

ユーザーが問題に直面しています。企業がユーザーに約束をしたが、それが実現されないという問題です。しかし、インフラストラクチャには問題がありません。

もっとも、それはユーザーにとってどうでもいいことです。

オペレーション チームは狭く偏った見方しかできず、この偏った見方が別の潜在的な問題の発生につながります。

たとえば、ビジネスが順調に進み、より多くのユーザーが自社のサービスを利用し始めたとします。従来のオペレーション担当者は、ユーザーにとっては良いことが起きている場合でも、パニック状態になる可能性があります。そして、心配になるのには当然の理由があるのかもしれません。

オペレーションは、単なる技術的な問題ではなく、最終的にはビジネスの問題です。

私たちは、システムの異なるレイヤ間の因果連鎖を把握する必要があります。

また、明確な原因とあいまいな原因が混在しているため依存関係チェーンはさまざまな形で表面化することや、ユーザーに影響を与えることなくインフラストラクチャの障害を下位レベルに抑える冗長性のレイヤについても理解しています。この概念的な認識から離れることにより、異なる対象分野を特定し、測定する方法について考えることができます。それがユーザーにとってどの程度明白であるかに応じて、症状と原因に分類します。

因果的順序のモデルが得られたことで、オペレーション担当者は、他のビジネス部門と同じ関心分野であるユーザーに、より集中できるようになります。

問題が発生した際、まずいくつかの症状を確認することで、オペレーション担当者は以前よりも効率的に原因を突き止めることができます。しかし、原因があって症状が出ることがわかっているのであれば、原因に問題が起き始めるタイミングを事前に把握したいと思うのではないでしょうか。症状を優先するアプローチは、因果連鎖を理解しているかどうかにかかわらず、より事後対応的で予測性に欠けるものではないのでしょうか。

もし従来と同じように原因に影響力があり、システムの奥深くで発生した障害の影響を軽減するために、さらなる対策を講じる必要があるのであれば、こうした懸念は妥当なものです。

では、軽減策を取る代わりに、原因に対してアラートを出すと仮定してみましょう。原因によって引き起こされる障害に圧倒される危険性があります。アラート疲れと高いノイズ対シグナル比は、問題の迅速な解決には結びつきません。単に多くの火災に気づいているだけでは、消火活動がしやすくなるとは言えません。

この状況の改善策とは

理想的なのは、「原因ではなく、症状に対してのみアラートを出すために必要なものは何か」と問いかけることです。

Google は、アラートの必要性を排除する自動化のレイヤを構築します。

なぜでしょうか。アラートは実用的でなければならず、障害に対処できるシステムが必要だからです。

原因に対するアラートをオフにすることを最終目標とし、可能な限り自動化して、段階的に症状のみに焦点を移行します。特定の種類のアラートへの対応を自動化する方法の例として、Cloud Logging イベントをリアルタイムで検出し対応するためのリファレンス アーキテクチャをご覧ください。モニタリングをオフにすることはありません。また、アラートを完全に削除する方法よりも、アラートの音が鳴らないようにする方法のほうが数多くあります。Google Cloud Monitoring では、組織が自動化に慣れ、問題に対処できるようになると、アラートをスヌーズできる機能が提供されています。トラブルシューティングやコスト管理などのために原因をモニタリングする必要はあるものの、Google は、症状に対して重点的に焦点を当てる能力に自信を深めています。

自動化やモニタリングを導入したとしても、すべての技術システムには、ある程度の障害はつきものであることを、私たちは以前から承知していました。しかし、想定できる種類の障害だけでなく、まだ把握できていない潜在的な原因もあります。新たに発見された原因の対処法に関するパターンがあれば、そのような原因にこだわる必要はなくなります。少量のプロジェクト作業によって、その後の多くのトイルを削減できます。わずかな時間を割くことで、焦点をユーザーに戻すことができるのです。Google はそれを実行しながらも、障害は不可避であることを想定しており、将来の未知の原因を検出する準備ができています。

この視点を適用し、期待する改善点に関するディスカッションの方向性をオペレーションに向けてください。

IT 部門のリーダーが「完全なエンドツーエンドの可視性を実現したい」と言った場合を考えてみてください。

この場合の最優先事項は何でしょうか。

「何か問題が発生したときに認識できるようにしたい。」

障害に対処できるようにシステムを設計している場合、「問題が発生する」とは何を意味するのでしょうか。こうした問題について考えていただくための挑発的な方法があります。

「明日から、ユーザー向けの症状に関するアラート以外はすべてオフにしましょう。異議はありますか？」

すると、多くの依存関係、冗長性の欠如、モニタリングのギャップが明らかになるでしょう。もしこの行動を一度に起こすとしたら、あまりに唐突すぎます。

同様に、リソースが限られている場合、飽和状態のような一部の無症状の問題も極めて重要です。容量の上限や割り当ての上限に近づいている場合、チームは早期にアラートを受け取る必要があり、現時点では自動化が不可能なケースもあります。重要なのは、次のように尋ねることです。

「理想的な状態を目指す取り組みに必要なものは何ですか？」

まとめ

Google の信頼性に関するヘルプグループでは、成功と失敗について話し合い、ベストプラクティスを学び、同じように信頼性エンジニアリングのサステナブルな実践の導入に向けて取り組む仲間たちとのネットワークを構築しています。

その道のりはチームによって異なるかもしれませんが、視点の変化には重要な共通点が一つあります。たとえユーザーが気にしていなくても、オペレーション担当者は、機能していない理由に関心を持つべきです。ここでいう視点の変化とは、単にユーザーと同じことに他動的に関心を持つということではありません。

むしろ、ユーザー中心の視点がもたらすのは、次のような異なる一連の価値観です。

• あいまいさを受け入れ、最も関連性の高いものに焦点を当てる。システムには、チェスの指し手の数よりさらに多くの問題の原因が存在することを心に留めておいてください。

• 以前は認識していなかった新しい技術的な問題の検出は、「ビジネス上の懸念」に耳を傾けた結果である。

• アラートを少なくし、症状に対してのみアラートを出すことを目指すべきである。まず、ユーザーに目を向け、症状に対してオペレーション担当者にアラートを出すというのが、デバッグのアプローチとして最も健全な方法です。

• 自動化は、確実に目標を達成するための最良の手段である。自動化は、サイド プロジェクトでも贅沢なものでもありません。

依存関係のあるサービスに対する SLO の定義 - CRE が現場で学んだこと

CRE が現場で学んだことの前回のエピソードで、サービスレベル目標（SLO）がサービスの信頼性を定義し、測定するための重要なツールであることを説明しました。また、このトピックについては、SRE ブックでも章全体を通して取り上げています。このエピソードでは、依存関係のあるサービスの SLO を定義し、管理する方法について説明しています。各サービスには、独自の SLO がある場合とない場合があります。