[セッションレポート] アマゾン・ビルダーズ・ライブラリー：アマゾン・オペレーション・エクセレンスの25年 (DOP301) #reInvent

AWS認定トレーニング講師の平野@おんせん県おおいたです。

今日は「The Amazon Builders’ Library: 25 yrs of Amazon operational excellence」というタイトルのセッションについてレポートします。

セッション紹介

Amazonは、DevOpsという名前がつく以前から、構築者がサービスのほぼすべての面を構築するだけでなく、テストや運用も行うという方法を実践してきました。このセッションでは、Amazonのプラクティスが時代とともにどのように変化し、改善されてきたか、そして私たちがビルダーとして、オペレーターとして何を学んできたかをお聞きください。アマゾンのオンコールはどのようなものだったのでしょうか。そして、アマゾンでコールをすることは、今どんな感じなのでしょうか？実体験と答えを共有します。

オンデマンド動画

概要

どのようなイベントか

オペレーション上のインシデントが発生した場合、舞台裏でそのイベントの調整と管理を支援する役割を担っています。 ちなみに、私たちはこのようなことをイベントと呼んでいます。

Amazonでは少なくとも25年間、何らかのイベント管理プロセスを持っています。それは、私たちがもっと小規模で、本を販売していた頃にさかのぼります。しかし、私たちのやり方は、主なコミュニケーション手段として音声会議を使用しています。私たちは、文字通り、音声電話でリアルタイムに会話し、チケットはトラッキングチケットと呼ばれるものです。そして、チケット、つまりトラッキング・チケットで、最新情報を投稿し、何をやっているのか、何を見ているのか、などをトラッキングします。 その多くは、事故後の分析を行う際に参照するためのものです。いつ何が起こったのか、どの程度うまくいったのか、次回に向けてどのように改善できるのか、などを確認できるようにしたいのです。 また、二次的なコミュニケーション手段として、チャットも活用しています。Slackやチャイムシステム、wickerなど、チームによって使い分けをしています。

私たちには、物事を煮詰めていくためのフレームワークがあり、それをトレーニングに盛り込むことで、このような通話でどうすれば効果的な対応ができるかを思い起こさせることができます。このフレームワークは、安全なフレームワークであり、最も重要なことは、緊急性を維持すること、これらの事象はできるだけ早く解決することが重要である、ということです。

• 冷静になる
  • 緊急性を維持しつつ、常に冷静さを保つ。パニックにならないように
  • コールには様々なイベント経験レベルがある
  • イベントは稀有なものであってほしい。経験が浅いことは良いことだ
  • 慎重かつ思慮深くあることが重要である
• 状況を把握する
  • イベントの参加者全員がアクティブであることが期待される
  • つまり、通話中のアップデートを追跡し、自分自身の要約を提供できることです
  • 未知のクストマーへの影響をスキャンすることは重要です
  • データによる改善の確認
• 軽減にフォーカスする
  • 多くのエンジニアは根本原因分析とデバッグに強いバイアスをもっている
  • 根本原因解析は緩和策よりも重要ではない
  • "まず、出血を止める"
  • ロールバック、プライマリ/セカンダリ間の反転などのオプションが出尽くすか、並列化できるようになるまで解析を避ける
• 早期にエスカレーションする
  • エスカレーションを行い、より経験豊富な人材を投入することで、修復時間を短縮できることが分かっています。
  • セカンダリ、マネージャ、上級者、または関連性の高い小人を引き込む
  • 可能な限り自動化する
  • エスカレーションに感謝する。エスカレーションはとても良いことです

ソフトウェアをデプロイする

• デプロイメントの安全対策
  • 段階的なデプロイメント
  • 徹底した事前チェック
  • 最初にロールバックし、後で質問する
  • 優れたモニタリング・アラーム

インフラストラクチャを変更する

• インフラ変更時の安全対策
  • ロールバックを先に行い、質問は後にする
  • 優れたモニタリング・アラーム
  • インクリメンタル・デプロイ
  • 徹底した事前チェック

壊せないものを壊す

• 壊せないものを壊す1
  • 時折、互換性のない方法で何かを変更する必要がある
  • そのような変更はすべて、AWSのリーダーシップチームによってレビューされる
  • 承認された変更はすべて、エグゼクティブスポンサーによって管理される
• 壊せないものを壊す2
  • EC2インスタンスの人気が高まり、63ビットのLongIDに移行
  • セキュリティの向上により旧バージョンのプロトコルが廃止されることがあり、コンプライアンスフレームワークでは旧バージョンのプロトコルをオフにするよう主張される
• 壊せないものを壊す3
  • 私たちは、非推奨を長期的な運用プロセスとして扱う
  • これらのプロセスは、複雑さに応じて1年から3年の範囲になる
  • まず、顧客に手段を与え、理想的には力を与える
  • 顧客との関わりを、簡単に行動できる通知に限定する
• 壊せないものを壊す4
  • リソース、アカウント、または組織レベルの可視性と制御を適切な形でお客様に提供する
  • 壊れる可能性のあるものに対して、事前にできるだけ簡単にフラグを立てられるようにする
  • 「本当の」期限の前に「偽の」期限を設ける
  • 将来のアジリティのために、できるだけ多くの教訓を学ぶ

まとめ

Amazonのオペレーションの進化についてのセッションを紹介しました。ご興味があれば上記のリンクよりセッション動画をご覧ください。