枠組みの変更

完了

このモジュールのすべてのユニットの中で、これは間違いなく最も重要なユニットの 1 つです。 このユニットでは、監視することが重要なものとその理由を理解する枠組みを変える可能性のあるいくつかの考え方について検討します。 一部の人にとって、これは、信頼性を向上させるための監視に関する考え方のすべてを根本的に変えてしまうことになるかもしれません。

Diagram with the word reliability in a circle in the middle connected to circles at the end of each spoke, each circle contains a word relating to reliability from a previous unit.

リフレーミング #1: 顧客の観点からのリフレーミング

前のユニットで、監視を検討する必要がある信頼性の側面について説明しましたが、それは、一連の監視対象を拡大したように思えるだけです。 信頼性を向上させるために何を監視する必要があるかを理解するのに役立つ 1 つの考え方を次に示します。

信頼性は、コンポーネントの観点ではなく、顧客の観点から測定する必要があります。

これは非常に重要です。 これは本当に重要であるため、もう一度お読みください。 以前は、"すべてのものを監視する" ことが提唱されていました。カウンターを読み取れるもの、統計をグラフ化できるもの、またはダッシュボードに表示できるものを監視する必要があると考えられていました。 "顧客の観点からの測定" は、より具体的な意見です。

要点を示し、それを理解するための簡単なシナリオを見てみましょう。

シナリオ

あなたは、会社の eコマース Web サイトの運営を担当しています。 Web ファームには、100 個のサーバー インスタンスがあります。 オペレーティング システムの障害、ソフトウェアの更新、電源変動、またはその他の予期しないイベントが原因で、これらの 100 個のインスタンスのうち 14 個が突然動作を停止します。 現在、これらの 14 個のインスタンスは完全に動作しなくなっています。

確認: 86 個のサーバー インスタンスは動作しており、14 個のサーバー インスタンスは動作していません。

次のうち、この状況で正しいのはどれですか?

A: これは、大したことではありません。 問題に取り組む時間ができたら、対処できます。

B: これは、深刻な問題です。 実行中の処理をすべて停止し、14 個のサーバー インスタンスの運用をできるだけ早く再開させる必要があります。

C: これは、ビジネスにとって実存的な危機です。 真夜中に寝ているところを起こすことになっても、経営幹部に通知し、できるだけ早く状況に対処するように全員に電話で連絡する必要がある。

答える前に、時間をとって、このシナリオを十分検討し、それから読み進めてください。 A、B、C のどれだと思いますか?

正解は、A、B、C のいずれでもありません。それは "状況次第" です。より正確に言えば、"顧客がこの停止をどのように経験しているかによって異なります"。

顧客がバックエンドのダウンに気付かず、他の 86 個のサーバー インスタンスが問題なく負荷を担うような方法でサイトを設計していれば、この場合、危機はありません。 これは、SEV-3 または SEV-4 のインシデントである可能性があり、サポート チケットだけで済む可能性もあります。

この停止によりビジネス全体が苦境に陥り、サーバーがダウンしている間ずっと多額の損失が発生している場合、非常ボタンを押して全員を緊急召集する十分な理由になるでしょう。 答えが "B" になる中間の状況も考えられます。

この場合も、信頼性は、コンポーネントの観点ではなく、顧客の観点から測定する必要があります。 このため、"100 台中ダウンしているのは 14 台のマシン" というコンポーネント数は完全に正確ではありますが、信頼性の観点からは、このシナリオで最も重要な情報ではありませんでした。

この考え方は、従来のコンポーネントベースの監視について説明する場合にも当てはまります。 データベース サーバーが 50% の CPU 負荷で実行されていることがわかった場合、それはよいことでしょうか、それとも悪いことでしょうか? 90% に達した場合、それはよりよいことでしょうか、それともよくないことでしょうか? サービスが正常に実行されており、ユーザーが満足している場合、90% は、リソースの使用率が大幅に向上したことを意味するため、非常によいことかもしれません。 しかし、50% の CPU 負荷で実行されているアプリケーションの速度が遅いとユーザーが不満を感じている場合は、90% が改善になる可能性は低くなります。

リフレーミング #2: 適切なレベルの信頼性

この考え方を正しく伝えるためには、その原点を簡単に説明しておく必要があります。 この考え方は、サイト信頼性エンジニアリング (SRE) に基づくものです。 SRE の定義を詳しく調べるだけで、(このセクションの考え方を含めて) いくつかの役立つ考え方を引き出すことができます。

Note

サイト信頼性エンジニアリングとは、組織がシステム、サービス、製品で適切なレベルの信頼性を持続的に達成できるようにすることを目的としたエンジニアリング分野です。

この定義には、3 つの重要な言葉があります。

  • 信頼性: 信頼性の重要性については、概要のユニットで詳細に説明したので、ここでは、この点について繰り返し説明しません。

  • 持続的に: この文脈での "持続的に" とは、このすべてにおける人々の役割に関連します。 持続可能な運用プラクティスを作成することが重要です。 信頼性の高いシステム、サービス、製品は担当者が構築するものです。 仕事を持続可能にするための対策が講じられない場合 (たとえば、毎晩午前 3:00 にポケットベルで起こされたり、家族との時間を与えられなかったり、自分の体を気遣う時間を持てなかったりする場合)、人々は信頼性の高いシステムを構築することはできません。 SRE では、人々が仕事に最善を尽くすためには、長期にわたって持続可能である運用方法を実装することが重要であると考えられています。

  • 適切な: これは、人によっては考え方を根本から変える言葉です。 かつて運用の世界では、すべてを 24 時間 365 日稼働できるようにすることが目標でした。 すべてを、1 日中、1 週間中、1 か月間中、1 年中稼働させ続けようとしました。 何かがダウンすることは決して受け入れられませんでした。 サイト信頼性エンジニアリングが運用に関する議論にもたらしたものの 1 つは、代わりに "適切な" レベルの信頼性を追求する必要があるという考えでした。

では、この考えについて詳しく見てみましょう。 ここで重要な点は、100% の信頼性が適切な目標になることはほとんどないということです。 実際、医療機器や航空などの特定の例外を除いて、100% 信頼できるものは必要ありません。そもそも、多くの場合、100% の信頼性を確保することは不可能です。

"絶対にあり得ない" の例を次に示します。最近は、実行されているすべてのシステムに、他のシステムとの依存関係があります。 おそらく、実行しているソフトウェアは、支払いプロセッサを呼び出す必要があるか、認証システムを呼び出す必要があります。 支払いプロセッサの信頼性が 100% ではない場合、または認証システムの信頼性が 100% ではない場合、システムの 100% の信頼性を確保するのは非常に困難です。

100% の信頼性という目標に関するもう 1 つの難しい点は、これがダウンタイムなしを意味するということです。 これは、ダウンタイムを引き起こす可能性があると思われる変更を加える可能性がゼロであることも意味します。 おそらく必要になるであろう、ヘッドルームはまったく得られません。

運用しようとしている特定のものについて、"信頼性の適切なレベルは何か" という観点から検討を始めることが有用です。 これを目下のトピックに還元するには、監視でこの目標をサポートする必要があります。

それでは、これら 2 つの枠組みを念頭に置いて、実用的な説明に移り、目標の達成に役立ついくつかのツールを見てみることにしましょう。

自分の知識をチェックする

1.

サービス、システム、製品で追求する必要がある信頼性のレベルはどのくらいですか?

2.

監視システムが、サービスの 1 つに電力を供給しているサーバーの半数がダウンしたことを検出した場合、問題の重大さはどの程度です?