Googleで Site Reliability Engineering（SRE）から20年間で得た教訓

サイト信頼性エンジニアリング（SRE）で得た20年の教訓

YouTubeから学んだ信頼性エンジニアリングの教訓

• リスク緩和策の選択

  • 重大な障害が発生した際には、その障害の深刻度に見合ったリスク緩和策を選ぶべきである。
  • 過剰な緩和策は副作用を招く可能性があり、標準手順を迂回するのは正当な理由がある場合に限る。

• 緊急事態に備えた復旧メカニズムのテスト

  • 復旧メカニズムと緩和策は事前に十分に訓練・テストしておくことで、緊急時にも効果的に対処できる。
  • テストによって将来のリスクを減らし、対応能力を向上させる。

• 変更を段階的に導入する（カナリアテストを適用）

  • 変更を全面展開する前に段階的に導入し、問題が発生してもシステム全体に影響しないようにする。
  • YouTubeのキャッシュ構成変更の事例を通じて、小さな変更であっても体系的な導入が重要であることが認識された。

Google Calendarから学んだ教訓

• 緊急停止機能の重要性

  • 潜在的なリスクを持つ変更に対して、迅速に対応できる「大きな赤いボタン」のような機能が必要である。
  • サービス依存関係に備えて緊急停止機能を用意しておくべきである。

• 統合テストの必要性

  • 単体テストは限られた範囲では有用だが、統合テストによって実環境と連携させ、システムの適合性を検証する必要がある。
  • Google Calendarの障害事例から、実際の利用経路に沿ったテストの重要性が認識された。

2017年のGoogleの教訓

• 緊急時に備えた通信チャネルの重要性

  • 通信チャネルおよびバックアップチャネルの準備が必要である。
  • サービス停止時には、依存関係のない複数の通信手段を用意し、その有効性をテストすべきである。

• 性能低下時にも最小限の機能を維持する

  • サービスが完全に停止しないよう、性能低下状態でも基本機能を提供できるように設計すべきである。

災害レジリエンスに関するテスト

• 災害レジリエンスと復元力のテスト
  • サービスやシステムの復元力をテストし、災害時にも継続可能性を確保する必要がある。
  • 復旧テストを通じて、システムが停止後に正常状態へ戻れるかを確認すべきである。

自動化された緩和策の重要性

• 緩和策の自動化
  • 複数のネットワーク障害発生時に手動で対処するのではなく、自動化された緩和策によって問題解決時間を短縮すべきである。

デプロイ間隔の短縮

• 頻繁なロールアウトの実施

  • ロールアウト間の長い時間的遅延は、システムの安全性を判断するうえで不利になる。

• 単一のグローバルなハードウェアバージョンは単一障害点である

  • 特定の1モデルのみに依存することは運用を単純化できるが、そのモデルに問題が発生すると重要な機能の実行が停止する可能性がある。
  • 多様なネットワークバックボーンの存在は、全面的な停止を防ぎ、優先度の高いトラフィックを引き続き稼働している代替経路へルーティングできるようにする。