QCon New Yorkで、Ryan Kitchens氏が、"How Did Things Go Right? Learning More from Incidents"と題して講演した。主なポイントは次のとおりだ。リカバリは予防に優る； インシデントは"最悪の状況"が起きた時に発生するのであるから、根本原因(root cause)というものは存在しない; ユーザの幸福が何より重要である; システムが"正常"運用されている時に、うまくいっている理由を知ることには大きな価値がある。
NetflixのシニアSRE(Site Reliability Engineer)であるKitchens氏の講演は、SREの役割における重要な責任として、サービスレベル指標(SLI)とサービスレベル目標(SLO)の定義、エラーバジェット(Error Budget)の監視と管理の支援、インシデント時の"作戦司令室"の運用、インシデント後のレビューの実施があることの紹介から始まった。Netflixに見られるような複雑な分散システムの内部では、インシデントは通常状態である。Netflix SREチームはプラクティスやプロセスの整備を完了しているので、インシデントは重要だが"もはや興味の対象ではない"ものだ。
インシデントから得られる最も重要な教訓は、障害を克服するためのキャパシティをシステムに構築する方法である。効果的なリカバリ能力には、インシデントの防止よりもはるかに大きな価値があるのだ。とは言ってもNetflixチームは、カオスエンジニアリングやゲームディ、関連するプラクティスを用いることで、"非常に高いインシデント防止能力"を実現している。氏はCharity Majors氏のことばを引用して、"可用性は構築するものであり"、"ユーザが満足しなければ９をいくつ並べても意味はない"、と指摘した。成功とは、失敗がないということではない。ユーザが望む時にシステムが使用できなければ、99.999パーセントの可用性があっても、実質的な意味がないのだ。
続いて、"根本的原因は存在しない"という点が議論された。一般的にインシデントは、複数の要因が組み合わさった"最悪の状況"によって引き起こされるのだ。"誤謬の３つの柱" -- 理解力、分かりやすさ、予測可能性 -- は、いかに私たちがインシデントを正しく理解できていないか、ということを思い出させてくれる。例えば、インシデントを完全に理解することは、一般的には不可能である。さらに、修復した内容が次のインシデントの誘引となることも珍しくない。インシデントは原因から作られるのではない。それらを"見つける"のではなく、構築し、その物語を作り上げることによって、理解を深めることが可能になる。さらに、最新のインシデントから学んだとしても、次のインシデントを予測することはできない。複雑なシステムは決定論的ではないからだ。
"なぜ(why)"よりも"どのように(how)"を問うことで、インシデントからより多くを学ぶことができる、とKitchens氏は主張する。間違いを防ぐよりも、確実に正しく行なうことの方に大きな価値がある。これを理解するには、通常の作業がどのように行われているかを知らなければならない。従来のインシデント調査では、全体のエクスペリエンスのごく一部しか使用しない上、うまくいっている時間からのデータは無視されることが多い。"ごく普通の日々のパフォーマンスは、知られないまま無視されているのです。"
次に氏は、Netflixインシデントレポートから、一連の"コントリビュータとイネーブラ、軽減、リスク"に関する要因を公開した。これらの多くは、インシデントに対処した(またはインシデントに関わった)者ならば誰でも認識できるものだ。インシデントへの対処には、"知識の島(islands of knowledge)"による困難を伴う場合が少なくない。これらはJ. Paul Reed氏の論文“Maps, Context, and Tribal Knowledge: On the Structure and Use of Post-Incident Analysis Artifacts in Software Development and Operations"で論じられているように、フォローアップや報告書などの資料において特定されるべきである。インシデントのタイムラインを作成することも有効だ。ここではJohn Allspaw氏の著述、特に論文"Trade-Offs Under Pressure: Heuristics and Observations Of Teams Resolving Internet Service Outages"が推奨されている。
後半のセクションでは、"システムを健全に保つために人々がどれだけ懸命に働いているのか"、"組織内のマネジメントチェーンにこの情報をどのように伝えればよいのか"という問いかけが、聴衆に対してなされた。"すべてが正常"であるという理由から、この種のデータを共有しない組織もあるが、結果としてこれは、通常の運用状態を調査しないことになる、というのがKitchen氏の考えだ。この重要な情報を発見するには対話が必要だが、このコンテキストで人々の協力を得るのは"技術的に最も難しい問題"であるかも知れない。
エンジニアにインタビューして、"なぜうまくいかなかったのか？"から"どうやってうまくいっているのか？"に移行することは、困難だが価値のある訓練だ。意図せずにインタビュー対象者を圧迫したり、脅迫したりしないように注意して、効果的な自由回答形式の質問をすることが重要になる。"ここにたどり着いた方法"を構成する記述を引き出てし、彼らの視点から、世界がどのように見えているのかを伝えよう。
最後に、インシデント後の対応方法こそが極めて重要である。"もっと注意しよう"、"間違いをしないようにしよう"、"規律が必要だ"といったことばを使ってはならない。代わりに氏は、"Language Bias in Accident Investigation"、"Debriefing Facilitation Guide"、"The Field Guide to Understanding ‘Human Error'"、"Pre-Accident Investigations"など、このトピックに関して詳細な情報を提供する一連の書籍を推奨した。
Ryan Kitchens氏のプレゼンテーションのビデオは、今後数か月間、InfoQで見ることができる。講演に関するより詳しい情報は、QCon New York Webサイトにある。