信頼性

アーキテクチャ フレームワークのこのセクションでは、技術上および手������上の要���を適用して、Google Cloud で信頼性の高いサービスを設計、運用する方法について説明します。

このフレームワークは、次の一連のドキュメントで構成されています。

信頼性は、アプリケーションの最も重要な機能です。アプリケーションの信���性が低いと、最終的にはユーザーが離れてしまい、他の機能はすべて意味をなさなくなります。

  • アプリケーションには測定可能な信頼性の目標が必要であり、目標とのギャップは迅速に修正する必要があります。
  • アプリケーションは、スケーラビリティ、高可用性、自動化された変更管理を考慮して設計されている必要があります。
  • アプリケーションは可能な限り自己修復する必要があり、オブザーバビリティのためにインストゥルメント化する必要があります。
  • アプリケーションの実行に使用される操作手順では、障害を迅速に軽減しつつ、オペレーターの手動による作業と認知的負荷を最小限に抑える必要があります。

戦略

以下の戦略で信頼性を実現します。

信頼性はユーザーにより定義される。ユーザー向けのワークロードの場合は、CPU 使用率などのサーバー指標ではなく、クエリの成功率などのユーザー エクスペリエンスを測定します。バッチおよびストリーミングのワークロードでは、ディスク使用量などのサーバー指標だけではなく、四半期ごとのレポートが期日どおりに完了するように、時間枠ごとにスキャンされる行などの KPI（主要業績評価指標）を測定する必要がある場合があります。

十分な信頼性を確保する。システムは、ユーザーが満足できるほど十分に信頼できるものでなければなりませんが、投資が正当化されないほど高い信頼性は必要ありません。信頼性のしきい値を設定するサービスレベル目標（SLO）を定義し、エラー バジェットを使用して変化率度を管理します。SLO によりコストが正当化される場合にのみ、以下に示す追加の原則を適用します。

冗長性を組み込む。信頼性の高いシステムには単一障害点がなく、リソースは複数の障害発生ドメイン間で複製される必要があります。障害発生ドメインとは、VM、ゾーン、リージョンなど、独立して障害が発生する可能性のあるリソースのプールです。

水平方向のスケーラビリティを含める。リソースを追加して、システムのすべてのコンポーネントがトラフィックやデータの増加に対応できるようにします。

過負荷耐性を確保する。負荷がかかったときにサービスレベルを適切に下げられるように設計します。

ロールバック機能を含める。オペレーターによりサービスに加えられた変更を元に戻すための、明確に定義された方法（つまり、変更をロールバックするための方法）が必要です。

トラフィックの急増を防ぐ。クライアント間でリクエストを同期しないでください。同じタイミングでトラフィックを送信するクライアントの数が多すぎると、トラフィックが急増し、最悪の場合カスケード障害が発生する可能性があります。

障害復旧をテストする。直近で障害復旧の運用手順をテストしていない場合、必要なときに機能しない可能性が高くなります。定期的にテストする項目には、リージョン フェイルオーバー、リリースのロールバック、バックアップからのデータの復元などを含めます。

エラーを検出する。アラートが早すぎるとオペレーション チームの負担が増加し、遅すぎるとサービスの停止期間が長くなるというトレードオフがあります。停止についてオペレーターに通知する前の遅延（検出時間、TTD とも呼ばれます）を、このトレードオフのために調整する必要があります。

増分変更を行う。サービスのバイナリや構成を一度にグローバルに変更することには、本質的に危険が伴います。「カナリアテスト」を使用して変更を段階的にロールアウトし、ユーザーへの影響が最小限であるロールアウトの初期段階でバグを検出することを推奨します。

緊急時の対応を調整する。ユーザー エクスペリエンスとオペレーターの��康状態を考慮しつつ、停止期間（軽減時間、TTM とも呼ばれます）を最小限に抑えるオペレーション プラクティスを設計します。このアプローチでは、明確に定義されたロールとコミュニケーション チャネルを定めた対応手続きを事前に形式化する必要があります。

オブザーバビリティのための計測システム。十分かつ適切にインストゥルメント化を行い、問題の迅速なトリアージ、トラブルシューティング、診断を可能にし、TTM を最小化します。

緊急時の対応を文書化して自動化する。緊急時に、何をすべきかを定義することや、複雑なタスクを実行することは困難です。そのため、緊急時の対応を事前に計画して文書化し、可能であれば自動化します。

容量管理を行う。トラフィックが急増するイベントが発生する前にトラフィックを予測し、リソースをプロビジョニングします。

作業負担を軽減する。手動による繰り返し作業には永続的価値はなく、サービスの拡大に伴い増加します。継続的に作業負荷の削減、排除を行います。そうしなければ、最終的にオペレーターの作業負担が大きくなり、成長の余地がほとんどなくなります。

ベスト プラクティス

信頼性を実現するために、以下のベスト プラクティスに従ってください。

  • サービスレベル目標（SLO）とエラー バジェットを使用して、信頼性の目標を定義します。
  • インフラストラクチャとアプリケーションにオブザーバビリティを組み込みます。
  • 拡張性と高可用性を考慮して設計します。
  • 柔軟で自動化されたデプロイ機能を構築します。
  • 効率的なアラートを作成します。
  • インシデント管理のための共同プロセスを構築します。

信頼性の目標を定義する

これらのイベントに基づいて信頼性の目標を設定するとともに、既存のカスタマー エクスペリエンスおよびエラーや失敗に対する許容度を測定することをおすすめします。たとえば、システム全体の稼働時間を無期限に 100% にするという目標は達成できません。また、ユーザーが期待するデータが存在しない場合、この目標には意味がありません。

ユーザー エクスペリエンスに基づいて SLO を設定します。できる限りユーザーに近い信頼性の指標を測定します。可能であれば、モバイルまたはウェブ クライアントを計測します。それができない場合は、ロードバランサを計測します。サーバーで信頼性を測定することは最後の手段です。SLO はユーザーが満足するよう高く設定しますが、それ以上には引き上げません。

ネットワーク接続やその他の一時的なクライアント側の問題のために、アプリケーションによって引き起こされるいくつかの信頼性の問題について、ユーザーがしばらくの間気付かない場合があります。

稼働時間やその他の重要な指標については、100% 未満であるもの��それに近い目標を設定することを強く推奨します。これにより、ソフトウェアを迅速かつ高品質で配信できます。また、適切に設計されたシステムでは、多くの場合、変更のペースと量を減らすことで可用性を高めることができます。

つまり、ユーザー エクスペリエンスに合わせて調整された達成可能な信頼性の目標が、ユーザーが許容できる変更の最大速度と範囲（機能の速度）を定義する際に役立つ場合があります。

既存のカスタマー エクスペリエンスを測定して目標を定義できない場合は、競合するベンチマークの分析をおすすめします。比較できる競合がない場合は、目標をまだ定義できていない場合でも、カスタマー エクスペリエンスを測定します。たとえば、システムの可用性やユーザーにとって意味のある成功したトランザクションの割合などです。これは、注文量（小売）、カスタマー サポートの通話数、サポート チケットとその重要度など、ビジネス指標や KPI と関連付けることができます。後ほど、このような相関関係を考慮して、ユーザーの満足度に関する妥当なしきい値、つまり SLO を特定できます。

SLI、SLO、SLA

サービスレベル指標（SLI）は、提供されるサービスレベルのいくつかの要素に関する定量的尺度です。これは指標であり、目標ではありません。

サービスレベル目標（SLO）は、サービスの信頼性の目標レベルを指定します。SLO は、信頼性に関するデータドリブンの意思決定を行うための鍵であり、SRE プラクティスの中心になります。SLO は SLI の値です。SLI が SLO を上回る場合、サービスは「十分に信頼できる」とみなされます。

エラー バジェットは、一定期間における 100% から SLO を引いた値として計算されます。特定の時間枠での信頼性が必要とされる値よりもどの程度高いか（または低いか）を示します。通常は、30 日のローリング ウィンドウを使用することを推奨します。

サービスレベル契約（SLA）とは、ユーザーとの明示的または暗黙的な契約であり、SLO を上回る（あるいは下回る）場合の結果が記載されます。

外部 SLA よりも厳格な内部 SLO を使用することをおすすめします。これは、SLA 違反により返金や顧客への払い戻しが発生することが多く、経済的影響が発生する前に対処する必要があるためです。インシデントのレビューを含む、責任を追及しない事後分析プロセスに、より厳密な内部 SLO を加えることをおすすめします。

アプリケーションにマルチテナント アーキテクチャ（複数の独立したユーザーが使用する SaaS アプリケーションが典型）がある場合は、必ずテナントごとのレベルで SLI をキャプチャしてください。SLI をグローバルな集計レベルでのみ測定する場合、モニタリングでは個々��ユーザーや少数のユーザーに影響する重大な問題を報告できません。各ユーザー リクエストにテナント ID を含めて、その ID がスタックの各レイヤに伝播するようにアプリケーションを設計します。この ID が伝播されると、モニタリング システムは、リクエストパスに沿ったすべてのレイヤまたはマイクロサービスで、テナントレベルの統計情報を集計できるようになります。

エラー バジェット

エラー バジェットを使用して開発速度を管理します。エラー バジェットがまだ消費されていない場合は、引き続き新機能をリリースします。エラー バジェットがゼロに近い場合は、サービスの変更を停止または抑制し、エンジニアリング リソースを信頼性に関する機能に投資します。

Google Cloud は、Service Monitoring によって SLO とエラー バジェットを設定する手間を最小限に抑えます。このプロダクトには、SLO を手動で構成するための UI、SLO をプログラムで設定できる API、エラー バジェットのバーンレートをトラッキングするための組み込みダッシュボードが含まれています。

SLI の例

サービス提供システムの場合、一般的な SLI は次のとおりです。

  • 可用性は、サービスが使用可能な時間の割合を示します。多くの場合、成功した正しい形式のリクエストの割合（99% など）で定義されます。
  • レイテンシは、一定割合のリクエストが処理される速さを示します。多くの場合、50 以外のパーセンタイル（300 ミリ秒の 99 パーセンタイルなど）で定義されます。
  • 品質は、特定のレスポンスの品質を示します。多くの場合、品質の定義はサービス別であり、リクエストに対するレスポンスのコンテンツが理想的なレスポンスのコンテンツとどの程度異なるかを示します。バイナリ（良好または不良）または 0～100% のスケールで表すことができます。

データ処理システムの場合、一般的な SLI は次のとおりです。

  • カバレッジは、処理されたデータの割合（99.9% など）を示します。
  • 正確性は、正しいとみなされるレスポンスの割合（99.99% など）を示します。
  • 鮮度は、ソースデータまたは集計されたレスポンスがどれくらい新しいかを示します（20 分など）。鮮度が新しいほど良いとされています。
  • スループットは、処理中のデータ量を示します（500 MiB/秒、1,000 RPS など）。

ストレージ システムの場合、一般的な SLI は次のとおりです。

  • 耐久性は、システムに書き込まれたデータを将来取得できる可能性を示します（99.9999% など）。永続的なデータ損失インシデントは耐久性指標を低下させます。
  • スループットとレイテンシ（前述の通り）。

設計に関する質問

  • アプリケーションの信頼性に関するユーザー エクスペリエンスを測定していますか？
  • クライアント アプリケーションは、信頼性に関する指標を取得して報告するように設計されていますか？
  • システム アーキテクチャは、信頼性とスケーラビ��ティに関する具体的な目標を考慮して設計されていますか？
  • マルチテナント システムの場合、ユーザー リクエストにはテナント ID が含まれますか？その ID はソフトウェア スタックの各レイヤに伝播されますか？

推奨事項

  • 顧客を中心とした SLI を定義して測定します。
  • 違反による結果（本番環境でのフリーズなど）を伴う、外部 SLA よりも厳しい顧客中心のエラー バジェットを定義します。
  • レイテンシ SLI を設定して外れ値（90 パーセンタイルまたは 99 パーセンタイル）をキャプチャし、最も遅いレスポンスを検出します。
  • 少なくとも年に 1 回は SLO を確認します。

リソース

インフラストラクチャとアプリケーションにオブザーバビリティを組み込む

オブザーバビリティには、モニタリング、ロギング、トレース、プロファイリング、デバッグなどのシステムがあります。

コードをインストゥルメント化してオブザーバビリティを最大化します。システムの最も可能性の高い、または頻繁な障害モードを優先して、ログエントリとトレース エントリを書き込み、デバッグとトラブルシューティングを考慮してモニタリング指標をエクスポートします。モニタリングを定期的に監査およびプルーニングし、使用されていない、または役に立たないダッシュボード、アラート、トレース、ログを削除して、不要なものを排除します。

モニタリングは、サービスの信頼性の階層における基盤です。適切なモニタリングがなければ、アプリケーションがそもそも動作しているかどうかすら判断できません。

適切に設計されたシステムは、その開発段階から適当なオブザーバビリティを持っています。アプリケーションが本番環境になるまでモニタリングを行わないことのないようにしてください。

Google Cloud のオペレーション スイートでは、Google Cloud と AWS 全体でのリアルタイムのモニタリング、ロギング、トレース、プロファイリング、デバッグが提供されます。また、Istio と App Engine サービス（Cloud Monitoring）を使用してサービス メッシュをモニタリングすることもできます。

オーバー エンジニアリングのモニタリングとオーバー アラートは、よくあるアンチパターンです。これら��アンチパターンは、最初の外部リリース段階で確認されない、またはめったに発生しない時系列、ダッシュボード、アラートを事前に削除することで回避できます。これは、まれにしかスキャンされないログエントリにも有効です。

アプリケーション イベントのすべてまたはサンプル��� BigQuery などのクラウド データウェア ハウスへの送信を評価します。これは、モニタリングを直接設計するのではなく、低コストで任意のクエリを実行できる点で便利です。また、レポーティングとモニタリングが分離されます。レポートは、Google データポータルまたは Looker を使用するすべての人が作成できます。

設計に関する質問

  • 設計レビュー プロセスに、設計レビューとコードレビューの指針となるオブザーバビリティの基準がありますか？
  • アプリケーションによってエクスポートされた指標は、サービス停止のトラブルシューティングに適していますか？
  • アプリケーションのログエントリは、デバッグに役立つほど詳細で関連性がありますか？

推奨事項

  • 移行を開始する前に、または最初の本番環境デプロイの前に新しいアプリケーションを構築する間にモニタリングを実装します。
  • アプリケーションに問題があるのか、それとも基盤となるクラウドに問題があるのかを明確にします。たとえば、透過的 SLI と Google Cloud ステータス ダッシュボードを使用します。
  • プロファイリング以外にも、トレース、プロファイリング、デバッグなどのオブザーバビリティ戦略を定義します。
  • 実行不可能なアラートなど、使用されていない、または役に立たないオブザーバビリティ アーティファクトを定期的にクリーンアップします。
  • アプリケーション イベント（カーディナリティの高い指標）を BigQuery などのデータ ウェアハウス システムに送信します。

拡張性と高可用性を実現する設計

フェイルオーバーを使用したマルチリージョン アーキテクチャを設計する

リージョン全体がダウンしている場合でもサービスを稼働させる必要がある場合は、リージョンがダウンしたときに自動フェイルオーバーを使用して、さまざまなリージョンに分散したコンピューティング リソースのプールを使用するようにサービスを設計します。単一リージョンのマスター データベースなど、アクセスできないときにグローバルな停止を引き起こす可能性がある単一障害点を排除します。

スケーラビリティのボトルネックを排除する

単一の VM または単一のゾーンのリソース制限を超えて拡張できないシステム コンポーネントを特定します。一部のアプリケーションは垂直方向のスケーリングを想定して設計されており、より多くの負荷を処理するためにはより多くの CPU コア、メモリ、ネットワーク帯域幅が単一の VM で必要になります。このようなアプリケーションはスケーラビリティに厳しい制限があり、多くの場合、負荷の���加に対応するために手動で再構成する必要があります。これらのコンポーネントをシャーディング（VM またはゾーン間でのパーティショニング）して、水平方向に拡張できるように再設計します。これにより、トラフィックや使用量の増加を、シャードを追加することで簡単に処理できるようになります。シャードは、自動的に追加できる標準の VM タイプを使用して、シャードごとの負荷の増加分を処理します。再設計する代わりの方法として、これらのコンポーネントを、ユーザーの操作なしで水平方向に拡張するように設計されたマネージド サービスに置き換えることも検討してください。

サービスレベルを適切に下げる

過負荷を検出してサービスレベルを下げてレスポンスをユーザーに返すか、一部のトラフィックをドロップするように設計し、過負荷状態で完全に機能しなくなることを回避します。たとえば、よりコストのかかる動的な動作を一時的に無効にしつつ、静的なウェブページではユーザー リクエストに対応できます。あるいは、データ更新を一時的に無効にしつつ、読み取り操作のみを許可することもできます。

ジッターを伴う指数バックオフを実装する

モバイル クライアントがサービスからエラー レスポンスを受け取った場合には、ランダムな遅延の後に再試行する必要があります。エラーが繰り返し発生する場合には、各再試行操作にランダムなタイム オフセット（ジッター）を追加することに加え、指数関数的に待機時間を長くする必要があります。これにより、モバイル ネットワークに障害が発生した後、大規模なクライアント グループにより瞬間的なトラフィックの急増が発生するのを防止できます（このような急増は、サーバーをクラッシュさせる可能性があります）。

ピーク時のトラフィック イベントを予測して計画する

小売業者のブラック フライデーなど、トラフィックのピーク期間がわかっている場合は、トラフィックや収益の大幅な損失を防ぐための準備を行います。トラフィック急増の程度を予測し、バッファを追加して、急増に対処するのに十分なコンピューティング能力を確保します。予想されるユーザー リクエストの組み合わせでシステムを負荷テストを行い、推定される負荷処理能力が実際の能力と一致することを確認します。オペレーション チームでシミュレーションの停止訓練を行い、対応手順をリハーサルし、以下で説明する、チームをまたいだ共同インシデント管理手順を実施します。

障害復旧テストを実施する

障害復旧の手順とプロセスは定期的にテストして検証します。障害が発生するまで待たないでください。高可用性（HA）を確保するためのアーキテクチャの計画も必要になる場合があります。障害復旧（DR）と完全に重複することはありませんが、リカバリ時間目標（RTO）とリカバリ ポイント目標（RPO）の値を検討する際は、高可用性を考慮する必要があります。HA を実現することで、平常時よりも多くの処理が発生した場合でも運用パフォーマンス（通常は稼働時間の長さ）の合意レベルを維持できます。Google Cloud で本番環境のワークロードを実行する場合、グローバル分散システムを使用することで、1 つのリージョンで障害が発生しても、アプリケーションによるサービス提供は継続されます（サービスが提供されるリージョンは限定される場合があります）。要するに、そのアプリケーションによってそれ自体の DR 計画が開始されます。

設計に関する質問

  • アーキテクチャを変更せずに VM を追加することで、アプリケーションをスケールアップできますか？
  • アーキテクチャ内の各コンポーネントは、シャーディングなどによって水平方向に拡張できますか？
  • クライアント アプリケーションは、クライアント間の同期リクエストを回避するように設計されていますか？
  • アプリケーションがグローバルに停止することなく、クラウド リージョン全体の障害に対処できますか？
  • ユーザー リクエストはシャードとリージョンに均等に分散されていますか？
  • アプリケーションは、過負荷になったことを検出し、動作を変更して停止を防ぐことができますか？

推奨事項

  • クライアント アプリケーションのエラー再試行ロジックで、ランダム化を使用して指数バックオフを実装します。
  • 高可用性を実現する自動フェイルオーバーを備えたマルチリージョン アーキテクチャを実装します。
  • 負荷分散を使用して、シャードとリージョンにユーザー リクエストを分散します。
  • アプリケーションのサービスレベルが過負荷状態で適切に下がるように設計して、レスポンスを部分的に提供するか機能を制限し、完全に機能しなくなることを回避します。
  • 負荷テストとトラフィック予測を使用してリソースのプロビジョニングを促進し、容量計画のための定期的なデータドリブン プロセスを確立します。
  • 障害復旧手順を確立し、定期的にテストします。

柔軟で自動化されたデプロイ機能を構築する

すべての変更をロールバックできるようにする

特定の種類の変更を元に戻す明確に定義された方法がない場合は、ロールバックをサポートするようにサービスの設計を変更し、定期的にロールバック プロセスをテストします。これは、モバイル アプリケーションで実装する場合にコストがかかる可能性があります。Firebase Remote Config を適用して機能のロールバックを容易にすることをおすすめします。

期間限定のプロモーションやリリースのトラフィックを分散させる

深夜 0 時などの正確な時間に始まり、多くのユーザーに同時にサービスに接続するように働きかける販売などのプロモーション イベントの場合、リクエストを開始する前にランダムな遅延を追加してトラフィックを数秒に分散するようにクライアント コードを設計します。これにより、スケジュールされた開始時刻にサーバーをクラッシュさせる可能性がある瞬間的なトラフィックの急増を防止できます。

カナリアテストによる漸進型ロールアウトを実装する

実行可能ファイルの新しいバージョンと構成の変更を段階的にロールアウトします。ゾーン内のいくつかの VM など、小さな範囲から始めます。目標は、変更をグローバルにロールアウトする前に、ごく一部のユーザー トラフィックにのみ影響が及ぶ段階でバグを検出することです。変更を認識し、変更されたサーバーとそれ以外のサーバーの指標の A / B 比較を行う「カナリアテスト」システムをセットアップして、異常な動作にフラグを立てます。カナリア システムがオペレーターに問題をアラートで通知します。ロールアウトを自動的に停止することもあります。変更がカナリアテストに合格したら、次にゾーン全体、続いて 2 番目のゾーンといったように、より大きな範囲に少しずつ拡大します。変更したシステムが徐々に大量のユーザー トラフィックを処理するようになり、潜在的なバグを発見できるようになるまでの時間を見越しておきます。

ビルド、テスト、デプロイを自動化する

CI / CD パイプラインを使用してリリースに自動テストを組み込むことで、リリース作業を排除します。自動化された統合テストとデプロイを実行します。

自動化は便利ですが、万能薬ではありません。初期の開発コストや設定コストに加え、かなりのメンテナンス コストと信頼性のリスクが伴います。

最初に、システムを管理するチームの作業内容のリストアップと評価から始めることをおすすめします。これを、Google Cloud サービスとパートナーによってすでに提供されている自動化をカスタムして拡張することに投資する前に、継続的なプロセスとして行います。多くの場合、Google Cloud の自動化（Compute Engine の自動スケーリング アルゴリズムなど）を微調整できます。

Google は、作業負担を永続的価値を欠く傾向のある、手動の反復的で自動化可能な反応的作業と考えており、少なくともそのソースと同じ速度で拡大するものと考えています。詳しくは、SRE Book の作業の排除の章をご覧ください。

以下は、Google が提供する構成可能な自動化、またはお客様を支援するカスタムの自動化による作業負担の排除の主な領域の一部です。

  • ID 管理（Cloud Identity や Google IAM など）。
  • 「独自の���ータベースの構築」ではなく、Google Cloud がホストするソリューション。たとえば、クラスタ管理（Google Kubernetes Engine）、リレーショナル データベース（Cloud SQL）、データ ウェアハウス（BigQuery）、API 管理（Apigee）など。
  • Google Cloud サービスとテナント プロビジョニング（Cloud Deployment Manager、Terraform、Cloud Foundation Toolkit など）。
  • 追加の容量プロビジョニング。たとえば、一部の Google Cloud プロダクトでは構成可能な自動スケーリングが提供されています。
  • 自動デプロイを備えた CI / CD パイプライン（Cloud Build など）。
  • デプロイを検証するためのカナリア分析（Kayenta など）。
  • （機械学習用の）自動モデル トレーニング（AutoML など）。

自動化の前に、まずは作業負担の排除を優先することをおすすめします。Google が提供する構成可能な自動化を可能な限り活用して、次のステップとして残りの作業負担を低減します。3 番目のステップとして、まだかなりの作業負担がある場合（たとえば、本番環境システムを管理するチームの時間の 50% 以上など）に、他のソリューションの構築または購入を評価します。このステップは、1 番目と 2 番目のステップと並行して行えます。ソリューションを構築または購入する際は、統合、セキュリティ、プライバシー、コンプライアンスの費用を考慮してください。

手動ワークフローを自動化または排除する技術的ニーズを部分的にのみ満たす Google Cloud プロダクトまたはサービスを見つけた場合は、Google Cloud アカウント担当者に機能リクエストを提出することを検討してください。これが、より多くのお客様にとっての優先事項である可能性もあり、すでに Google のロードマップの一部となっている場合もあります。そのような場合、機能の優先度とタイムラインを知ることで、独自のソリューションを構築することと、Google Cloud 機能として使用できるようになるのを待つことのトレードオフをより正確に評価できるようになります。

設計に関する質問

  • 実行可能ファイルと構成の変更プロセスは自動化されていますか？
  • 変更の自動化は、考えられるすべての変更を迅速にロールバックできるように設計されていますか？
  • スキーマの変更など、ロールバックできない変更の場合に、現在または以前のバイナリ バージョンとデータスキーマの間の上位互換性と下位互換性を確保するための設計レビュー プロセスはありますか？
  • システム構成ファイルがシャーディングされていて、構成の変更をグローバルではなく段階的にロールアウトできますか？

推奨事項

  • 新しいリリースと構成のカナリアテストを設定します。
  • チームの作業内容を定義し、定期的にコストを評価します。
  • カスタムの自動化を開発する前に、不要な作業やワークフローを排除します。
  • デフォルトの構成を微調整するか、デフォルトが提供されていない場合は構成を作成し、Google Cloud サービスですでに利用可能な自動化を使用します。
  • メンテナンス費用とサービスの信頼性 / セキュリティに関するリスクに見合うだけの価値がある場合は、カスタムの自動化の構築（または購入）を検討よく保守されたオープンソース ソフトウェアを評価することもおすすめします。

効率的なアラートを作成する

アラートの遅延を最適化する

モニタリング システムで問題を人員に通知する前に、構成された遅延を調整して、信号対雑音を最大化しつつ TTD を最小化します。エラー バジェットの消費率から、最適なアラート構成を導き出します。

原因ではなく症状をアラート対象にする

ユーザー エクスペリエンスへの直接的な影響（グローバル SLO または顧客ごとの SLO に関する違反）に基づいてアラートをトリガーします。特に影響が単一のレプリカに限定されている場合は、障害の根本的な原因をすべてアラート対象にしないでください。適切に設計された分散システムは、単一レプリカの障害からシームレスに回復します。

共同インシデント管理プロセスを構築する

適切に設計されたシステムでも、いつかは SLO を下回ることになります。SLO がない場合でも、ユーザーにより過去の経験に基づいて許容可能なサービスレベルが大まかに定義され、SLA の内容に関係なく、テクニカル サポートや同様のグループにエスカレーションされることに注意してください。

ユーザーに適切なサービスを提供するために、インシデント管理計画を確立し、定期的に実装することを強くおすすめします。計画は、10 項目程度の単一ページのチェックリストとして作成できます。このプロセスは、平均検出時間（MTTD）と平均軽減時間（MTTM）を短縮するのに役立ちます（MTTR はあいまいなため、MTTR ではなく MTTM を使用します）。R は「修復」や「回復」という意味でよく使用��れ、「軽減」ではなく「完全な修正」を意味します。MTTM は、完全な修正ではなく軽減であることを明示的に示します。

優れた操作性を備えたシステムを設計すれば、平均故障間隔（MTBF）が長くなります。詳細については、「システム設計とオペレーショナル エクセレンス」セクションをご覧ください。

また、ブレームレス ポストモータムの文化とインシデントのレビュー プロセスの両方を確立することも重要です。「ブレームレス」とは、犯人捜しをせず、問題点を客観的に評価および文書化することがチームに求められるということを意味します。失敗は学習の機会とみなされ、批判の対象にはなりません。システムの復元力を高めて、人為的ミスから迅速に回復できるようにするか、さらには人為的ミスを検出して防止できるようにします。

MTTD を短縮する

MTTD を短縮するための前提条件は、「オブザーバビリティ」と「モニタリングの目標を定義する」セクションで説明した推奨事項を実装することです。たとえば、アプリケーションの問題であるのか、それとも基盤となるクラウドの問題であるのかを明確に切り分けます。

適切に調整された一連の SLI は、アラートの過負荷を発生させることなく、適切なタイミングでチームに通知します。詳しくは、SLI 指標の調整: CRE ライフレッスンをご覧ください。

MTTM を短縮する

MTTM を短縮するには、適切に文書化され、十分に実施されたインシデント管理計画を用意します。また、変更内容に関するデータをすぐに利用できるようにします。

インシデント管理計画の例

  • 本番環境の問題（アラート、ページ）が検出されたか、エスカレーションされました。
  • そもそも委任する必要はありますか？自分たちで解決できない場合は、「はい」。
  • これはプライバシーやセキュリティの侵害ですか？「はい」の場合、プライバシー チームまたはセキュリティ チームに委任します。
  • これは緊急事態ですか、あるいは SLO が達成できなくなる恐れがありますか？疑わしい場合は、緊急事態として処理します。
  • 人員を増やす必要がありますか？顧客の X% 以上に影響が及ぶ場合、あるいは解決に Y 分以上かかる場合は、「はい」。疑わしい場合は、（特に営業時間中には）より多くの人員で取り組みます。
    • メインの通信チャネル（IRC、Hangouts Chat、Slack など）を定義します。
    • 事前定���ロールを委任します。以下はその例です。
      • インシデント コマンダー - 全体的な調整を担当します。
      • コミュニケーション リーダー - 社内外の連絡を担当します。
      • ��ペレーション リーダー - 問題の軽減を担当します。
    • インシデントがいつ終了するかを定義します。サポート担当者からの承認が必要になる場合があります。
  • 事後調査を共同で行います。
  • 定期的な事後調査インシデント レビュー会議に参加して話し合い、タスクの割り当てを行います。

グラフ

考慮すべきグラフの例を以下に示します。インシデント対応者は、単一のビューから以下を一目で確認できる必要があります。

  • サービスレベル指標（成功したリクエストを合計で割った値など）。
  • 構成やバイナリのロールアウト。
  • システムへの 1 秒あたりのリクエスト数。
  • システムから返される 1 秒あたりのエラー数。
  • システムからその依存関係への 1 秒あたりのリクエスト数。
  • システムからその依存関係への 1 秒あたりのエラー数。

また、リクエストとレスポンスのサイズ、クエリの費用、スレッドプール（プールの不足による回帰を探すため）、グラフ化された JVM 指標（該当する場合）などもあります。

これらのグラフの配置に関して、いくつかのシナリオをテストします。機械学習を適用して、これらのグラフの適切なサブセットを検出（異常検出）することもできます。

また前述のように、迅速な軽減策として、簡単にロールバックできるシステムと変更を設計することもできます。

推奨事項

  • インシデント管理計画についてチームを確立してトレーニングします。
  • 「オブザーバビリティ」セクションの推奨事項を実装して MTTD を短縮します。
  • 「変更内容」ダッシュボードを作成して、インシデントの発生時に一目で確認できるようにします。
  • クエリ スニペットを文書化するか、データポータルのダッシュボードを作成します。
  • Firebase Remote Config を評価して、モバイル アプリケーションに関連するロールアウトの問題を軽減します。
  • 「障害復旧」の推奨事項を実装して、インシデントのサブセットの MTTM を短縮します。
  • 構成とバイナリのロールバックを設計してテストします。
  • 「システム設計」と「障害復旧」（テスト）セクションの推奨事項を実装して、MTBF を長期化します。

リソース