QCon New York 2015にて、Nori Heikkinen氏がGoogleとHealthCare.govで、サイト信頼性エンジニア(SRE)として働いた経験から得られた失敗や教訓について紹介した。大規模障害を管理することについて、推奨される準備や返答、分析や回避について説明をした。また、定期的に失敗検知やリカバリシナリオを行うことで災害を防ぐことを推奨している。
始めに、Heikkinen氏は、タイタニック号の作者たちが処女航海の前に持っていた確信について言及し、避けがたい災難への対処計画を練っておくことの重要性を説明した。そして、聴衆に、“沈まないものが沈んだらどうするか?”と問いかけ、トラフィックSREとしてGoogleで働いた経験、そして、HealthCare.govで修正系の仕事をするチームとして働いた経験から得られた教訓を話した。
まず始めに、“都市の消滅: ふたつのルータベンダの物語”という物語を紹介した。これは、Googleでアトランタをベースとする‘metro’ アクセスポイント (PoP)リージョン全体がGoogleのネットワークから消滅した事件を巡る物語だ。究極的には、新しいルータのバグが原因だった。SNMPで未知のデータ片を問い合わせると、クラッシュしてしまうのだ。氏は、この物語(とGoogleのSREチームの対応)を失敗を扱うには準備が重要だということを示すために使った。
事前にモデリングをすることが重要だ。負荷テスト、キャパシティのプランニング、回帰分析のような方法によって、ある条件下でSREチームはシステムがどのように振る舞うべきかを理解することができた。システムと関連するデータをリアルタイムで視覚化することで、オペレータはリアルタイムで対応でき、“Xはどんな影響を持っているのか”といった質問にも回答できる。
ふたつ目の“Satpocalypse”は、Googleのすべての“サテライト”エッジウェブサーバが同時に障害を起こした、という物語だ。サテライトサーバはGoogleのネットワークの末端に配置されている短命のサーバであり、‘コア’ウェブサーバを使っているユーザの遅延を削減するためにトラフィックの終端となる。すべてのサテライトサーバが同時におかしくなったのは、サーバを引退させる処理のバグであり、サーバ全体のストレージデバイスを消去してしまったのだ。しかし、実装されていた拡張自動化のおかげで、トラフィックの終端という役割はコアのウェブサーバ側へフェールバックし、エンドユーザーには目に見える障害はなかった。
Heikkinen氏はこの物語の教訓を“効果的なパニック状態になる方法を学ぶ”ことだったと紹介した。多くの救急サービスで使われているインシデント・コマンド・システム (ICS)は反応を効果的に集約し、部門をまたぐ協力を有効にし、インシデントの要求に応じてスケールできる。Googleは従来のICSを自分たちの文化に合うように変更し、官僚的でない軽量なプロセスを作成し、組織の階層構造の必要性を排除していた。
3つ目の物語、“呼び出しは家の中からやってくる”では、HealthCare.govで働いた経験から生まれた。HealthCare.govの登録期間の最終週にログインシステムが障害を起こした。スパゲッティなアーキテクチャが原因で、アプリケーション全体がクラッシュしてしまったのだ。究極的な原因はある契約者が、マネージャに要求されたレポートを作成しようとして、スーパユーザとして、プライマリのデータベースであるOracleに対して複雑なクエリを実行したからだ。このスーパユーザのクエリは、ほかのすべてのデータベースに対するクエリを遅くしてしまった。責任者はこの問題が発生しているのを把握していたが、労働環境の有害な文化のせいで何も言わなかった。声を上げると仕事を失うのではないか、と恐れるような文化だ。
人はシステム可用性の‘5番目の9’なのです。
Heikkinen氏は人はシステム可用性の‘5番目の9’であるという(可用性のナインファイブの原則を踏まえて)。反応の文化を作るのは致命的に重要であり、チームのメンバは状況をしっかりを把握し反応する必要がある。エンジニアが引き受ける仕事はボトムラインに結びついている必要がある。組織を通じて正確なインセンティブを生成するからだ。責任の文化も重要だ。非難なしの振り返りは問題がどのように生まれ、どのように対処されたのかを振り返るのに価値がある。Heikkinen氏は運用経験は未来のシステムのデザインにとって示唆的だという。
氏は企業は定期的に障害の検知とリカバリのシナリオを実践することで、障害対策をするべきだという。例えば、‘disaster in recovery training (DiRT)’セッションを実施することで、統合的な障害のシナリオを設計し、実行することができる。
積極的に障害に関わることが障害を防ぐ最も良い方法だということがわかりました。
GoogleはDiRTを定期的に実施しており、本番のシステムに障害を起こして、現実的な状況でチームがトレーニングできるようにしている(ユーザに見つかったらテストは中断される)。また、氏のプレゼンでは、“wheel of misfortune”というロールプレイゲームが紹介された。チームのメンバがランダムに選択され、過去の障害や潜在的な‘未来の問題’のシナリオを演じる。氏にこの方法でいくつかの本物のバグを見つけたことがあるという。
Heikkinen氏は最後に、Mikey Dickerson氏の“信頼性のヒエラルキー”を紹介した。これには、HealthCare.govでの教訓が盛り込まれており、マズローの欲求階層説に影響を受けている。
“信頼性のヒエラルキー”には紹介した物語のテーマに関連するニーズが含まれている、というのが氏の結論だ。反応(下層のふたつのニーズ)、分析(振り返り)、準備(その上のふたつのニーズ)。このヒエラルキーは予防が含まれていない。100%の動作保証は不可能であり、下層の3つのニーズは予防を探るよりも前の段階で組織として取り組まなければならないからだ。
QCon New York 2015での氏の講演“Too Big To Fail”の詳しい内容はカンファレンスのサイトで確認できる。