[レポート] 「タダでは転ばない」Amazonのアプローチ #DOP208 #reinvent

こんにちは。ちゃだいんです。

この記事は下記セッションについてのレポートです。

DOP208 - Amazon’s approach to failing successfully

Speaker

Becky Weiss - Senior Principal Engineer, Amazon Web Services

セッション概要

"物事が思い通りにいかない"現実の世界へようこそ。 システムは、可用性が高く、スケーラブルで、回復力があるように設計されているにもかかわらず、故障する可能性があります。 これらの障害は、正しく使用すれば、システムが実際にどのように機能するかを深く理解するための強力な手段になるだけでなく、将来の障害を回避する方法を学習するためのツールにもなります。 このセッションでは、メトリックスを定義およびレビューするためのAmazonならではのテクニック（障害が発生する前にシステムを監視する）と、学習と有意義な改善の両方を推進する効果的な事後分析を行う方法について説明します。

アジェンダ

1. 障害を無駄にしない -問題発生後のアマゾンのアプローチ-
2. 顧客がする前に、失敗を経験しておくこと
3. AWSはどのようにあなたに正しく失敗させることができるか

1. 障害を無駄にしない -問題発生後のアマゾンのアプローチ-

There is no compression algorithm for expreience.

COE（Correction of error）

• 顧客インパクトのあるイベントについての構造化された分析
• アマゾン独自のカルチャーを反映する
• 「どうすればもう２度と起きないようにできるか」を超越して良くする

COEs start with the customer and work backward

• 要約
  • 何が起きたかをストーリー立てて説明する
• メトリクスとグラフ
  • 主要なインパクトとそれを補助するグラフ
  • もしそれらが見つからなかったら、どこかを修正すべき
• 顧客インパクト
  • どれぐらいの顧客が影響を受けたか
  • 正常に機能しなかった経験はなんだったのか

フォーカスする範囲

根本原因：　Whyx５

トヨタWAY（５回のWHY）による根本原因へのアプローチ

Blast radius （爆発半径）

どうすれば被害の影響範囲を低減できるか、思考のエクササイズみたいに、似たようなイベントの時に爆発半径を半分にするにはどうすればいいか？と考えてみる

持続期間をコントロールする：　インシデントレスポンスを改善する

- どのようにイベントは検出されたのか？
- どうすれば検出時間を改善できるだろうか？思考の実験として、どうすれば半分の時間にできるだろう？

成功もまた失敗と同じくらい重要である

• 改善・成功した場合もなぜそうなったのかを考える

2. 顧客がする前に、失敗を見ておくこと

Health metrics and Diagnostic metrics

• ヘルスメトリクス
  • 正しい質問の答え「私は落ちましたか？」
  • 誤った質問の答え「なぜ私は落ちましたか？」
  • 常にそれらにアラームをセットしておくこと
  • 定義することに対して保守的であること
• 診断メトリクス
  • 正しい質問の答え：「計測しているこの物の価値はなんですか？」
  • 正しいかもしれない答え：「なぜ私のシステムは稼働していないのですか？」
  • 時々それらにアラームをセットしておくこと
  • 定義することに対してリベラルであること

平均より百分位数

3.AWSはどのようにあなたに正しく失敗させることができるか

Amazon CloudWatch

• 自動的に発行される基本メトリクス

• アプリケーションの詳細なログとメトリクス

Takeaways（持ち帰って欲しいこと）

• 失敗を無駄にしないこと: 効果的な事後処理
• 顧客がする前に失敗を掴むこと: 効果的なダッシュボードとメトリクスリーディング
• AWSのツールを使ってアプリケーションのインサイトと可視性を得ること

感想

所々で良くアマゾンカルチャーの有名な格言が登場する、ならではなセッションでした。