re:Invent 2025: AWSの運用の卓越性と信頼性を支えるCellular ArchitectureとSLOモニタリング
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Behind the scenes: How AWS drives operational excellence & reliability (COP415)
この動画では、AWSのsenior principal engineerであるMustafa TunとUmaya Majaganathanが、運用の卓越性(operational excellence)と信頼性について解説しています。perfectionではなくexcellenceを追求する理由として、AmazonのリーダーシッププリンシプルであるBias for ActionとInsist on Highest Standardsのバランスが重要であることを説明。cellular architectureやdependency isolationなどのアーキテクチャ選択、Operational Readiness ReviewやCorrection of Errorといったメカニズム、CloudWatch Application SignalsやCloudWatch Investigationsを活用したSLOベースのモニタリング、そしてゲームデイによる障害テストなど、AWSが実践する具体的な手法を紹介。善意ではなくメカニズムに頼り、AIを活用しながらインシデント対応とレビューを継続的に改善するフライホイールの考え方が示されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
コーヒーショップの例えで学ぶ運用の卓越性：完璧さではなくエクセレンスを目指す理由
皆さん、お集まりいただきありがとうございます。やあUmaya、調子はどう?やあMustafa、元気よ、でももう一杯コーヒーが欲しいわ、足りないの。もう一杯コーヒーが欲しいの?じゃあ今、Umaya、スマホを取り出して、近くのコーヒーショップを探すとするでしょ。そしてこのお店まで歩いて行ったら、メンテナンスで閉まってるのを見つけるわけ。それって最悪だよね?ええ、ええ、悲しい顔文字よね、本当に。
で、あなたも私みたいなコーヒーマニアなの?ええ、そうよ、Atlantaでもコーヒー売ってるわよ。あるよね、うん、うん。そうだね。つまり、Seattleでは法律なんだよ。コーヒーマニアでなきゃいけないんだ。地元のコーヒーショップをソーシャルメディアでフォローしてる?ええ、もちろんしてるわよ。うん、午前10時までに5杯くらいコーヒー飲むだけよ。ああ、中毒があるかどうかなんて聞いてないよ。コーヒーを飲むかって聞いたんだ。あるかもしれないわね。なるほど。
じゃあ、地元のコーヒーショップからこんな感じのソーシャルメディアでアップデートが来たとするでしょ。新しい機能があるって言ってる。選べる新しいシロップ、新しい焼き菓子があるって。それで行って確認するわけ、そしたら開いてる、これは良い兆候だよね。でもコーヒーマシンが壊れてるのを見つけるわけ。どう思う?ええ、泣きそう、いや実際泣くかも。なるほど。コーヒー中毒なのは確実だね。だからこういうコーヒーショップには運用の卓越性と信頼性が必要だと思うんだ、そしてそれが今日の私たちの会話のトピックなんだ。
私はMustafa Tunです。AWSのsenior principal engineerで、もう12年半この会社にいます、そしてその大部分の時間をCloudWatchや可観測性、モニタリングチームで過ごしてきました。そしてUmayaが私と一緒にステージに来てくれています。ええ、皆さん、私の名前はUmaya Majaganathanです。AWSのworldwide specialist solution architectureチームをリードしていて、私のチームはcloud operationsに焦点を当てています。AWSには8年近くいて、ほぼずっとCloudWatchと可観測性サービスに取り組んできました。
さて、この言葉そのもの、excellence、から始めたいと思います、perfectionではなく、excellenceです。私たちには理由があってこの言葉を使っているんですよね。この二つの言葉の違いは、Amazonの二つのリーダーシッププリンシプルでよく説明されます。二つ以上ありますが、ここではこの二つが当てはまります:bias for actionとinsist on highest standardsです。一つはスピードを求め、一つは計算されたリスクを取れと言っています。もう一つは時には不快かもしれないけど、最高の品質を追求すべきだと言っているんですよね。そして私がチームをこちら側に押し進めていた時期があって、その時は私たちはとても慎重だったけど、十分に速くシップできていなかったんです、よね。
つまり、この中心にあるのは、バランスを保つexcellence、卓越性です。完璧さではありません。完璧さは恐怖を植え付け、私たちの動きを遅くし、ミスを受け入れないでしょう、そうですよね？ですから、operational excellence、運用の卓越性においては、前に進まなければならないので時にはミスをすることを理解しています。しかし重要なのは、ミスから学ぶということです。
AWSのインフラストラクチャ設計：冗長性、依存関係の分離、セルラーアーキテクチャによる信頼性の実現
では、コーヒーショップに戻って、もしAWSがこのコーヒーショップを運営していたらどうなるか見てみましょう。インフラストラクチャレベルで冗長性を追加します。複数のサーバーでシステムを実行するのと同じように、店舗にもっと多くのコーヒーマシンを追加します。皆さんから預かったデータの複数のコピーを作成し、 そして、コーヒーショップを1つだけ運営するのではありません。ゾーン内に複数のデータセンターを配置するのと同じように、これらを複数運営します。そしてもちろん、 リージョンの異なる場所、都市の異なる場所に配置します。これはAvailability Zonesの配置方法と同じです。そしてもちろん、これらをリージョンの異なる場所、 世界の異なる場所に配置します。一部のサービスはゾーナル、一部のサービスはリージョナルで、これらすべてが障害分離境界を作り出しています。
そして、私たちのインフラストラクチャと障害分離についてもっと読みたい方のために、ウェブサイトに素晴らしいホワイトペーパーがあります。そして、このQRコードはこのトークのコンパニオンウェブサイトです。これから話の残りの部分で参照する外部リソースへのリンクがあります。では、 信頼性と運用の卓越性のために私たちが行うアーキテクチャ上の選択についてお話ししましょう。例えば、3つの依存関係を持つAWSサービスがあり、そのうちの1つが調子が悪い日だとしましょう。
私たちは、その依存関係に依存しているAPIだけが影響を受けるようにAPIサービスを設計しています。残りは機能し続けるべきです。 そして、これはdependency isolation、依存関係の分離によって実現されます。最もシンプルにできることは、各依存関係に対して異なるスレッドプールを作成することです。もちろん、より高度な方法もあります。 2つ目にお話しするのは、cellular architecture、セルラーアーキテクチャです。船が何かにぶつかったとき、大型船の船体が破られても、船は沈みません。なぜなら船体は異なるセルで構成されているからです。
同様の考え方で、スタックの複数のコピーを作成し、データプレーン内で互いに隣り合わせに配置し、 薄いレイヤーでルーティングします。このcellular architectureにより、blast radius、爆発半径を減らすことができます。これらのセルの1つが影響を受けても、残りのサービスは機能し続けることができます。
私たちのウェブサイト、Amazon Builders Libraryに記事が掲載されています。繰り返しになりますが、リンクはコンパニオンウェブサイトにありますので、私たちが行うアーキテクチャの選択について読んで、ご自身のシステムに適用していただけます。そしてまた、Well-Architected Frameworkも素晴らしいリソースです。インフラストラクチャ、アーキテクチャ、そしてオペレーショナルエクセレンスといったこれらすべてのトピックについて議論されています。
善意ではなくメカニズムに頼る：フライホイールで推進するオペレーショナルエクセレンスの好循環
さて、オペレーショナルエクセレンスについてです。これは私たちにとって機能の一つなんです。私たちは機能を追加し、AWSに新しいサービスを追加していますが、オペレーショナルエクセレンスにも同じように投資しています。AWSにとってオペレーショナルエクセレンスは後付けではありません。負担でもありません。私たちはそこに投資しています。意図的に取り組んでいます。皆さんが様々な理由でAWSを選んでくださることを知っていますが、その大きな理由の一つは、私たちがオペレーショナルエクセレンスに注意を払い、真剣に取り組んでいることです。
いくつかの学びを共有したいと思います。私はこの10年間、私たちのオペレーショナルエクセレンスの旅の最前線にいました。私たちが新しいことに挑戦するのを見てきましたし、うまくいったものもあれば、そうでないものもありました。ですので、これらの学びを共有しますが、一つ共通して見られることは、私たちは善意に頼らないということです。私たちはメカニズムに頼ります。そしてJeff Bezosの言葉を引用します。彼は2008年に私が入社する前の全社ミーティングで私たちにこう言いました。繰り返し起こる問題、何度も何度も起こることを見つけたとき、私たちはチームを集めて、もっと頑張れ、もっと良くやれと頼むことがよくある。本質的には善意を求めているわけです。そして彼は、これは本当にうまくいかないと言いました。なぜなら人々はすでに善意を持っているからです、よね?そして彼は、善意がうまくいかないなら、何がうまくいくのか?メカニズムだと言いました。誰も朝起きて、オペレーションを悪化させようとは思いませんし、インシデントの最中に、誰も事態を悪化させようとはしていませんよね?つまり、みんな最善を尽くしているわけです。
では、メカニズムとは何かについて話しましょう。それはシステムです。インプットがあり、アウトプットがあり、それはツールから始まります。掲げるマニフェストではなく、送って人々に読んでもらうことを期待するメールでもありません。ツールを作るんです。そしてそのツールが良ければ、採用を促進します。人々がそれを使い始め、より多くの人が使えば使うほど、より多くのフィードバックをあなたに与えてくれます。そしてその振り返りによって検証することができ、その検証によってツールを改善することができます。ご覧のように、これは好循環です。このようなものはフライホイールとも呼ばれ、もしあなたがジムに通う人で、エアロバイクを使うなら、あの大きな車輪がフライホイールです。これは機械工学から来ています。勢いを維持し続けます。エネルギーを蓄えます。私は知りませんけどね。ジムには行かないので。ジムに寄付する方が好きです。1月には、寄付しようと思っているジムがあります。
Amazonで最初の好循環フライホイールを導入したのはBezos自身と当時の彼のチームでした。彼らは成長をターゲットにしていました。カスタマーエクスペリエンスが彼らが注目したドライバーです。そしてカスタマーエクスペリエンスはトラフィックを促進しますよね?カスタマーエクスペリエンスを改善すれば、トラフィックはより多くの出品者を呼び込み、より多くの出品者はより多くの品揃えをもたらし、より多くの品揃えは私たちの顧客を幸せにします。そしてこれらのドライバーとともに成長するにつれて、より低いコスト構造を持つようになり、それが価格を下げます。そしてその低価格がカスタマーエクスペリエンス自体にフィードバックされるのです。
では、AWSにおいて運用エクセレンスを推進するドライバーについてお話ししました。なぜなら、この10年間で大幅に改善されてきたからです。そして私がこれを推進してきました。これは私の見解です。まず、オブザーバビリティから始まると考えています。サービスをオブザーバブルにすることで、より多くのインサイトを得られるようになります。インシデント対応をより良く行えるようになります。つまり、インシデント対応がその恩恵を受けるわけです。そして、インシデントが増えれば増えるほど、レビューして学ぶことが増えます。そのすべてのデータがレビュープロセスに反映されます。もちろん、インシデントが起こるのを待つだけではありません。システムを継続的にレビューしていますし、オブザーバビリティはそこでも役立ちます。そして、レビューすればするほど、アクションアイテムが増え、それがレディネスプロセスに反映されます。より準備が整うようになり、そして私たちが取るアクションアイテムのほとんどは、「この盲点を埋めよう」というもので、それがオブザーバビリティに反映されます。そして、これらのドライバーによって運用エクセレンスが成長し続けるにつれて、私たち自身がより良いレビュアーになり、それがレビュープロセスに反映されます。運用エクセレンスが向上するにつれて、より良い質問ができるようになります。そして私の意見では、運用エクセレンスはBezosの輪に反映されます。カスタマーエクスペリエンスは運用エクセレンスから恩恵を受けるのです。
レディネスプロセス：Operational Readiness ReviewとRelease Excellenceによる本番前の品質保証
では、このトークの残りの部分では、この輪に沿って進めていきます。見飽きるかもしれませんが、4つのセクションがあり、レディネスから始めて、これらのドライバーそれぞれに深く掘り下げていきます。このセクションでは5つのトピックについて議論します。そして最初のトピックは文字通りOperational Readiness Reviewと呼ばれるものです。
これは、サービスオーナーやオペレーターに記入を求めるメカニズムです。フォーム、チェックリストのようなもので、このような特定の質問をします。これらは新機能のOperational Readiness Reviewテンプレートからの逐語的な質問です。こう書かれています。「この機能には、カスタマーエクスペリエンスメトリクスに対してSLOが定義され、アラームが設定されていますか？」これは短い質問ですが、重要なことは、Service Level Objectives、つまりSLOを作成すること、つまりゴール指向の運用を行い、カスタマーエクスペリエンスメトリクスに焦点を当てることを求めているということです。多くのことに対してアラームを設定できますから、この質問は素晴らしいものです。
2つ目はテストについてです。この機能には、予期しないパフォーマンスの問題を発見し、対処するためのテストがありますか？単に発見することを求めているだけでなく、対処することを求めています。つまり、チームにメカニズムを求めているのです。これらのチェックリストは記入され、bar raiserによってbar raiseされ、サービスが本番稼働する前にディレクター以上の承認を得る必要があります。bar raiserやディレクターが満足しない場合、チームはサービスをオンラインにする前に、それらに対処しなければなりません。
テストといえば、もちろん私たちはソフトウェアを広範囲にテストします。ソフトウェアのテスト方法のすべての詳細には触れませんが、今日の議論に関連することは、障害に対するテストを行っているということです。デプロイメントパイプラインで継続的に障害シナリオを作成し、それに対してテストを行います。もちろん、負荷テストも行います。パイプラインでは、毎日チェックインするたびに、自動化された負荷テストを実行し、本番前環境でシステムに負荷をかけて、リグレッションを起こしていないかを確認します。通常見落とされがちなことの1つは、単一ユーザーからの負荷に対してもテストを行い、ノイジーネイバーがリグレッションを引き起こさないかどうかを確認していることです。
また、手動テストの日も実施しています。私たちはこれをゲームデイと呼んでいます。文字通り、これらのテストでシステムを壊すんです。ネットワーク障害を発生させたり、依存関係の障害を発生させたりします。これらをシミュレートすることで、2つのことをテストします。システムがどのように動作するか、そしてより重要なのは、オペレーターがどのように動作するかです。彼らは時間通りにページングされたか？時間通りに対応できたか？正しいランブックを見つけられたか？適切なダッシュボードを見つけられたか？問題の診断と緩和にどれくらい時間がかかったか？こうしたシミュレーションから学び、それに応じてシステムやプロセス、メカニズムを改善していきます。AWSにはFault Injection Serviceがあります。私たちはこれらの日にこれを自分たち自身で使用しています。皆さんも自分の組織でゲームデイを実施するために使うことができます。
私たちは人間にシステムを触らせたくありません。自動化と継続的デプロイメントを信じていますが、もし人間が触らなければならない時は、すべてのステップを詳細に書き記します。これをチェンジマネジメント、CMと呼んでいて、CMもbar raisedされ、bar raisedされたテンプレートから作成する必要があります。bar raiserがCMをレビューする際に注目するのは、チームが各ステップにロールバックステップを入れたかどうかです。何か問題が起きた時、チームが簡単にロールバックできるようにしたいのです。また、本番前環境でこれをテストしたかどうかもチェックします。サプライズは残したくないですからね。
Release Excellenceというチームがあります。こうした自動化はすばらしいですが、これらのパイプラインがちゃんと仕事をしているかどうか、どうやって知るのでしょうか？すべてのデプロイメントパイプラインを分析し、いくつかのルールに照らし合わせてチェックするシステムを導入しています。例えば、7つのルールがあって、このパイプラインはそのうち7つのルールに準拠していない、そしてこのパイプラインはブロックされました。つまり、CI/CDではあるものの、チームがこれらの期待事項に対処しなければデプロイできないということです。それらの期待事項とは何でしょうか？本番環境に到達する前のパイプラインの例を見てみましょう。
通常、AWSサービスでは本番前に3つのステージがあり、本番前の最後のステージであるgammaを本番環境のように扱い、そのステージでロードテストを含むあらゆる種類のテストを実行します。これが整っていない場合、例えばチームがベイキングタイムを逃した場合、それは不備となり、パイプラインはブロックされます。Clare Liguori、当社のもう一人のsenior Principal Engineerが、Automating Safe, Hands-Off Deploymentsという素晴らしい記事を書いていて、これもBuilders' Libraryにあります。では、私たちのホイールの2つ目のドライバー、observabilityに移りましょう。
オブザーバビリティの実現：標準化された計装とEmbedded Metric Formatによる測定可能なシステム構築
では、observabilityとは何でしょうか？これは測定値です。制御理論から来ています。システムを測定して、そのシステムはobservableが低い、あるいは高いと言うことができます。そして、observableであればあるほど、そこから多くのインサイトを得ることができます。
システムがより観測可能であればあるほど、自分が尋ねるべきだとさえ知らなかった質問をより多くすることができます。システムを観測可能にするために、私たちは基本的に2つのことを行います。システムを計装し、標準化するのです。もちろん、observabilityを実現するために優れたツールも使用します。
私たちはサービスを実行していますが、先ほど申し上げたように、運用に十分な投資を行い、observabilityの3つの柱であるメトリクス、ログ、そしてトレースのためのスパンを収集しています。Amazonが正しく行ったことの1つは、これを標準化したことだと思います。これを強調したいと思います。あなたがAWS開発者で、Javaを使って新しいAPIを構築しているとしましょう。私たちにはAPIサービスを構築するためのライブラリがあり、そのライブラリをインポートしてActivityというクラスをインポートし、APIのためにActivityを拡張することができます。この関数を実装する必要があり、この関数はこのAPIがこの特定のサーバーにヒットしたときに実行されます。
何もせずに文字通りこのコードをデプロイしても、すべてのリクエストでこのようなblobが得られます。これはもちろんデモンストレーション目的の簡略化された例ですが、多くのことを測定します。インフラストラクチャレベルとアプリケーションレベルの測定、例えば期間、CPU、使用メモリ、呼び出しが成功したかどうか、リクエストIDなどです。これはEmbedded Metric Formatと呼ばれ、利用可能です。これは外部フォーマットです。これをCloudWatch Logsに書き込むと、CloudWatch Logsがこのディレクティブを処理し、そこからメトリクスを出力します。このディレクティブは、durationフィールドを取得し、そのフィールドからメトリクスを出力するように指示しているわけです。
つまり、チームが何もしないこのコードをデプロイするだけで得られるのは、これらすべての測定値です。繰り返しますが、これは簡略化された例です。実際にはこれよりもはるかに多くのデータを収集しています。もちろん、開発者はmetricsオブジェクトを取得して独自のビジネス測定値を追加できます。カウントを追加したり、時間を追加したり、独自のキーバリューペアを持つことができ、それらすべてが異なるフィールドとして同じJSON blobにキャプチャされます。ここでのbean countとbrew timeは測定値なので、これらもEmbedded Metric Formatディレクティブに追加され、そこからメトリクスを取得できるようになります。
チームは、このソフトウェアをデプロイした後、メトリクスのためにこれらの新しいウィジェットを追加できるようになります。つまり、メトリクスを出力するのは非常に簡単です。トランスポートやフォーマットについて考える必要はありません。すべてアプリケーションを構築するために使用しているライブラリに実装されています。では、observabilityですよね？メトリクスは良いのですが、もっと深く掘り下げて分析を行いたい場合はどうでしょうか？この例ではCloudWatch Logsにcustomer nameを出力しているので、CloudWatch Logsクエリを実行でき、このようなクエリを実行できます。これが行うのは、平均brew timeを見つけてcustomerごとにグループ化することだけです。
すべてがログとして始まるので、こんなクールなことができるんです。すべてのリクエストはログの塊で、その中には集約されたメトリクスもあって、好きな分析を実行できます。Embedded Metric Formatについては外部でも利用可能です。私たちのコンパニオンウェブサイトで読むことができます。ツールに関しては、私たちはCloudWatchを使っています。AmazonとAWSはCloudWatchを好んで使います。一つの理由は、私たちが作ったからですよね。つまり、ドッグフーディングです。自分たちで製品を使うことで、お客様のために改善できるんです。
二つ目の理由は、私たちのスケールに対応できることです。AmazonとAWSは大量のデータを生成しますが、このスライドはおそらくもう古くなっています。CloudWatch Logsは月に13エクサバイトのログを受け入れています。これは1秒あたり5テラバイトのログです。そして、quadrillionは、確か10億の2乗だと思います。つまり、CloudWatch Metricsは毎月20 quadrillionのメトリクスデータポイントを受け入れているんです。このスライドを出してから、おそらくすでに100テラバイトのログを受け入れていますね。
CloudWatchが実現する顧客の期待：オープンスタンダード、簡単なセットアップ、SLOベースのモニタリング
もちろん、私たちには他の優先事項もありますし、皆さんがオブザーバビリティツールを選ぶ際にどんな優先事項があるかを教えていただきました。Imayaがそれについて説明します。どうぞ。はい、では私のチームと私は、毎年何百ものお客様と協力して、オブザーバビリティソリューションの選択に関してお客様が何をしたいのかについて、非常に深い会話を交わしています。皆さんは私たちにとても明確に伝えてくださいました。どのオブザーバビリティソリューションを使うか決定する際に、何が重要なのかというパターンが見えてきています。
これから、CloudWatchがソリューションとしてどのように皆さんのこれらの期待に応えているかを、私たちが社内で学んだことと、これまで議論してきたことに基づいて実演していきます。まず最初はオープンスタンダードです。Mustafaがインストルメンテーションの部分と、Amazon内で利用可能な標準インストルメンテーションライブラリがどのように、開発者が本当に心配する必要がないようにしているか、すべての重要なシグナルが自動的にキャプチャされることについて話しました。皆さんは、オープンスタンダードを使いたいと私たちに伝えてくださいました。それについては疑問の余地がありません。誰もがオープンスタンダードに準拠したいと思っていますし、それは明らかな理由で有益です。OpenTelemetryが進むべき道なので、だから私たちはAWS Distro for OpenTelemetry SDKを持っていますし、重要なメトリクスと業界標準のメトリクス、つまりREDメトリクス、別名REDメトリクスと呼ばれる、リクエストレート、エラー、デュレーションを自動的にキャプチャする自動インストルメンテーションエージェントも持っています。それに加えて、faultsもキャプチャします。CloudWatchにはOpenTelemetryエンドポイント、つまりOTLPエンドポイントもあり、ログとトレース用で、AWS、オンプレミス、ハイブリッド環境のどこからでもデータを送信できます。実際、どこでも構いません。認証用のAWS Signature Version 4さえあれば、OTLPエンドポイントは皆さんからシグナルを受け入れますし、その時点でOpenTelemetryを使っていることになります。
二つ目は、はい、これらすべての機能と能力があるのですが、もし実際にセットアップしてシグナルを収集するのが難しければ、ちょっと意味がないですよね。Amazon EKSを使っている場合は、このCloudWatch Observabilityアドオンがあり、CloudWatchエージェントを自動的にデプロイします。これもOpenTelemetry互換です。また、シンプルな設定に基づいて、自動インストルメンテーションエージェントをデプロイしたり、必要なポッドにコンテナをインジェクトしたりします。同様のものがAmazon ECSでも利用可能です。タスク定義でアプリケーションコンテナに自動インストルメンテーションコンテナをマウントするだけで、準備完了です。サーバーレスワークロード用のOpenTelemetryベースのLambdaレイヤーも用意されています。
それから3つ目は、そうですね、私たちはこれらすべてのデータを持っていて、本当に素早くセットアップできるんですが、今や大量のデータがあります。それをどう管理するのか？ダッシュボードを作成するビジネスに携わりたくはないですよね。シグナル間の手動相関を行うビジネスにも携わりたくない。シグナル間というのは、もちろん、アプリケーションからのログ、メトリクス、トレースのことですが、コンテナからのインフラストラクチャデータとマイクロサービスの相互作用やデータベース呼び出しのようなアプリケーションデータの間で手動で相関付けを行いたくもないですよね。そういったものすべてが最初から使える状態であってほしい、そしてそのメッセージもしっかり受け取りました。皆さんは、意見の強い、非常に意見の強い、そういった使い始めの体験を求めていました。もちろん、独自のダッシュボードを作成する機能も欲しいですが、同時に意見の強いやり方も求めていた、そしてそれがApplication Signalsで実現したものです。これはCloudWatch内のAPMソリューションです。アプリケーション中心のオブザーバビリティを持っていて、基本的にインフラストラクチャやマイクロサービスに焦点を当てるのではなく、アプリケーションの観点から見ていくもので、これは例えば社内の誰もが見る視点です。AI駆動の根本原因分析により、異なる環境から収集しているさまざまなシグナルから問題を見つけることがさらに簡単になります。
また、収集されるデータを削減したいとも考えていますよね。取り残される恐怖、いわゆるFOMOモードに陥って、すべてを収集したくはない。多くのお客様がそうなっているのを見ますが、そうするとコストが上がります。実際に根本原因を見つけるのに多くの時間がかかります。なぜなら、ノイズが多く、シグナル対ノイズ比が適切なバランスになっていないからです。より制御されたものを求めていたので、 お客様に推奨しているのはSLOベースのモニタリングでもあります。実際、Application SignalsはSLOを中心に構築されています。では、どうやってSLOを設定するのか？ビジネスSLAから始めます。アプリケーションが何をすべきかという点で、ビジネスが何を望んでいるかを尋ねることから始めます。例えば、このリクエストは200ミリ秒以内に応答すべきだ、というリクエストを受け取ります。しかし、その後、Service Level Objective、つまりSLOを構築して、基本的にアプリケーションが実際にそれを実行しているかどうかを追跡します。エラーバジェットがあるので、何か課題があった場合に調整する余地があり、それによって実際にどのようなメトリクスを収集する必要があるかが決まります。それを行うと、ビジネス要件と技術的なものの間に直接的な相関関係が生まれるので、その時点でオブザーバビリティはもはや技術的な懸念事項ではなくなります。ビジネス機能でもあるのです。それによって、お客様が収集するデータ量を実際に削減しているのを見てきましたし、Mean Time To Resolutionも本当に改善されます。
Application Signalsによるトラブルシューティング：SLOからログまでシームレスに追跡するデモンストレーション
では、 SLOベースのモニタリングを使用してトラブルシューティングを行うために、CloudWatch Application Signalsをどのように使用できるか見ていきましょう。
SLOベースのモニタリングを使用したトラブルシューティングをデモンストレーションしてみます。この例では、Application Signalsの画面のサービスにいます。それをクリックすると、サービス画面が表示されます。複数のマイクロサービスを持つサンプルアプリケーションをデプロイしています。そこに行くと、マイクロサービスビューが表示されます。すべて SLOステータスに基づいてリストされていて、概要では、実際に問題を抱えているアプリケーションやサービスがあるかどうかを確認できます。 この場合、SLOに基づいて不健全なアプリケーションがいくつかあります。SLOをクリックして、SLOのリストを見て、このマイクロサービスのすべてのSLOを表示をクリックできます。
それをクリックすると、SLOステータス、設定したSLOを満たしているかどうか、エラーバジェットを超えているかどうか、 そしてどのようなレイテンシがそれを引き起こしているかを確認できます。実際に興味があるのは、これらのSLOの1つ、そこにある可用性SLOです。クリックすると、明らかにウィジェットが自動的にそれに応じて変わります。やりたいことは、このSLOが何を意味するのかを調べることです。 この場合、このSLOは実際にvisitsという特定のオペレーションを測定しています。では、その特定のサービスでこれがどのように見えるか見てみましょう。
では、SLOを見て、何について話しているのか理解しましょう。私がやったことは、実際にこの環境にApplication Signalsをセットアップしたことです。これはEKS環境にデプロイされています。ここには複数のマイクロサービスがあり、このシグナルデータを自動的に収集します。先ほど述べたように、リクエストレート、エラー、期間など、すべての業界標準メトリクスが自動的に収集されます。今回は、実際にそれを利用しているのですが、それだけに限定されているわけではありません。実際には任意のCloudWatchメトリクスを選択できます。コンテナからのメトリクスでも、EC2でも構いません。実際に任意のメトリクスを選択して、そこにあるメトリクスに基づいてSLOを作成できます。もちろん、ログイベントからメトリクスを抽出することで、ログから独自のメトリクスを公開することもできます。
ここでは、このSLOがどのようなものかの説明だけです。可用性であり、またSLOは毎日測定されます。目標があり、エラーバジェットが50%を超えた場合、アラートを受け取りたいといった具合です。これはSLOの説明に過ぎません。ここで私ができることは、そうですね、SLOは、つまり今は健全ではありません。今、実際に何が起こっているのかオペレーションで確認できます。実際に問題の原因を突き止めることができます。
そのオペレーションをクリックすると、収集されているすべての実際のメトリクスが表示される画面に移動します。リクエストレート、エラー、フォルトなどです。ここで見ているものはすべてすぐに使えるものです。私が作成する必要があったものは何もありません。ここにはランタイムメトリクスもあります。Java、.NETなどの特定のワークロードについては、ランタイム環境メトリクスも収集します。ガベージコレクターなどに問題がある場合、それもすぐに使える状態で表示されるので、必要に応じて修正できます。
さらに上に行くと、このフォルトグラフがあり、ピークがあることがわかります。これを調査したいと思います。過去3時間ほどで284個のエラーが見られます。それをクリックすると、その時点で収集されたすべての異なるスパンが表示されます。はい、その特定のトレースを見て、すべてのスパンを見て、必要に応じて調査できますが、インフラストラクチャ情報をアプリケーションデータと相関させる機能が欲しいという話もしました。この場合、EKS環境にデプロイされているため、ノードも表示できます。明らかに他の環境であればそれを表示します。EC2インスタンスもです。しかしこの場合、その特定のインフラストラクチャで何が起こっているかを見るだけでなく、ポッドレベルの詳細に入って、そこで何が起こっているかを見つけることもできます。
ここからContainer Insightsを見ることができます。これを探し回る必要は本当にありません。直接のディープリンクです。そこに行って、Container Insightsを見て、すべてのコンテナ固有の情報を見ます。深く掘り下げて、その部分のすべての異なるデプロイメントを見て、すべてのインフラストラクチャ情報を見ることができます。ここに問題があった場合、ポッドがクラッシュしているか、クラッシュループが発生しているかを簡単に見つけられるでしょう。しかし、本当にやりたいことは、戻ってトレース自体を見ることです。これで、展開してそのトレースを調査すると、特定のトレースマップが表示されます。リクエスト自体が私の環境でどのように処理されたかです。
クライアントがあり、複数の、いくつかのサービスがあり、そしてDynamoDBがあります。右側に表示されているものはすべて、OpenTelemetryベースのデータで、抽出されてキャプチャされ、ここに表示されています。これらはすべてOpenTelemetryを通じてエンリッチされています。下にスクロールすると、実際にスパンタイムラインを見ることができ、リクエストがどのように処理されたか、そしてどの異なるサービスが影響を受けたかを本質的に示しています。DynamoDB自体を選択すると、実際にDynamoDBのスロットリングに問題があったことが表示されます。これはトレース自体にトレースイベントとしてキャプチャされたエラーです。
さらに下に行くと、この特定のトレースがキャプチャされた際に記録されたすべてのログイベントを見ることができます。もちろん、自分で分析したい場合は読み進めることもできますし、CloudWatch Logs Insightsを見に行くこともできます。中に入って自分で分析を行うことができます。自動的にロググループやクエリなどがすべて表示されます。run queryをクリックすると、すべての情報が得られます。
ここで私ができることは、分析を行うか、または実際に自分でパターン分析を行うことができます。例えば、600個または6,000個のログイベントがある場合、すべてのログイベントを一つ一つ見ていくのではなく、これらのログイベントにどのようなパターンが現れているかを見つけることが非常に有用です。patternsに行くと、ここでパターンに基づいてログを抽出してグループ化し、トークンを抽出したことがわかります。そして、エンドポイント用のトークンが表示されており、それはvisits APIです。さらに進むと、これは少し遅いですね。そこでは私のコンテナも表示されます。これにより、問題のトラブルシューティングを行い、根本原因を非常に迅速に見つけることが本当に簡単になります。
アプリケーション中心の部分についてお話ししました。私たちが見たのは、マイクロサービスから、SLOのステータスから、またはマイクロサービスから、トラブルシューティングを開始したということでした。しかし、アプリケーションの観点から見る方法についてもお話ししました。それがアプリケーションマップ機能が登場するところです。このアプリケーションマップ画面にいますので、お見せしたすべての異なるマイクロサービスは、これらのいくつかのアプリケーションの一部です。ここには5つのアプリケーションがあり、今できることは、それを見ることです。問題を抱えているアプリケーションが1つあります。そのアプリケーションに入ることができ、そのアプリケーションに入ると、移動するはずなんですが、なぜか移動しませんね。
さて、そこですべての依存するマイクロサービスを見ることができ、これらすべてのマイクロサービスは依存関係グラフなどとともに表示されます。しかし、すべてのログイベントも表示され、ログ監査も行って、明らかな問題が発生しているかどうかを見つけて表示してくれます。ここからもトラブルシューティングを行うことができます。ここからアプリケーションログを見つけることができます。ここからもトラブルシューティングができ、それで基本的にすべての詳細が得られるはずです。しかし、どのようにアプリケーションをグループ化しているのでしょうか？トポロジーグラフなどに基づいて推測されるものがあります。それはアプリケーションがどのように見えるかの自動的な理解ですが、それはあなたのコントロール下にもあります。つまり、本質的にAWSタグやOpenTelemetry属性に基づいて自分でアプリケーションを作成し、アプリケーションがどのように見えるべきかをグループ化し、環境やチーム名などに基づいてグループ化することができます。したがって、どのアプリケーションが壊れているかを見つけることが本当に簡単です。ここでは、SLIステータスやサーバーフォルトなどに基づいてフィルタリングすることもできます。これにより、実際の問題が何であるかを見つけるためにインターフェースが整理され、本当に便利になります。ありがとうございました。
インシデント対応の進化：標準運用手順書からAI支援、MCPサーバーとClaudeによる開発者支援まで
それでは、オペレーショナルエクセレンスのホイール、フライホイールにおける3つ目のドライバーについてお話ししましょう。皆さん、5つのトピックをカバーします。インシデントを報告する際、私たちは非常に慣れています。DevOpsモデルが大いに役立っています。DevOpsについて考えてみると、それはフライホイールそのものです。開発者として運用経験から学び、それに応じてサービスを設計し、実装し、デプロイします。
イベントに対応する際、私はサプライズを望みません。そのため、私たちは標準運用手順書とランブックの作成に非常に規律正しく取り組んでいます。ただ、これは徐々に、ますます遅くなってきています。なぜなら、Emayaがたった今お見せしたように、CloudWatchや他の運用オブザーバビリティツールが非常に優れたものになってきており、ダッシュボードから始めて、エラーから始めて、製品自体がガイドしてくれて、根本原因の特定を支援してくれるからです。しかし、まだ詳細にステップを書かなければならないシナリオがあります。理想的には、これらのSOPは自動化できるようになるため、なくなっていきます。SOPを作成する動機は、これは大胆な意見かもしれませんが、いつかゼロになるべきだと思います。
SOPを書かなければならない場合、私たちが注意を払うことがいくつかあります。例えば、ステップを書く際に曖昧にしません。このフロントエンドサービスのログを見つけてエラーを探してください、とは言いません。真夜中にオペレーターは何をするでしょうか？そのため、ディープリンクを提供したいのです。彼らがすぐに私たちが到達してほしい場所に行けるようにして、そこから解決できるようにしたいのです。
すべての標準運用手順書における最初の質問は、ロールバックできますか？であるべきです。たとえそれがデプロイメント関連でなかったとしても、オペレーターはデプロイメントがあったかどうかを確認すべきであり、不良なデプロイメントを修正しようとそこに座っているべきではありません。SOPを持っている場合、または作成する場合、生成AIの時代になぜこんなことをするのかと考えるかもしれません。まあ、それらを入力してナレッジベースを作成することができます。先ほど言ったように、理想的にはSOPは自動化されたランブックにつながります。
私たちにはエスカレーションルールがあります。チケットシステムがエスカレートします。私がページに応答しなければ、セカンダリーがページされ、彼らが応答しなければ、マネージャーオンコールがページされます。これが、チケットに時間通りに対応することを確実にするシステムですが、私は文化について話したいと思います。何年も前、何十年も前に初めてオンコールになったとき、マネージャーが私に言いました。直感的ではないかもしれませんが、カスタマーインパクトが見られたら私にページしてください。マネージャーオンコールにページしてください。怖がらないでください。私たちが来て助けますから、と。
AWSで障害が発生すると、通常、多くのリーダーたちがどこかで通話に参加しています。非常に大規模な障害の場合は、私たちのほとんどが通話に参加します。私たちはチームを支援しようとしています。ですから、私たちにはエスカレートして、知らせてくれれば、私が行って手伝うという文化があります。インシデント対応チームがあります。このチームは、誰も応答していない場合にページングされます。彼らはダッシュボードを持っていて、全員のKPI、すべてのサービスのKPIを把握しており、もしエンゲージメントがなければ、チケットを作成してあなたをエンゲージします。
彼らは大規模なイベントの際にも私たちを支援してくれます。集約されたチケットを作成します。エンゲージします。適切なチームを見つけるのを手伝ってくれます。なぜなら彼らは全員の電話帳を持っているからです。そして彼らはサービスを外部化したので、もしあなたが自社でこのようなものを実装したい場合は、彼らのサービスを購入することができます。もちろん、この2、3年でAIを私たちのオペレーションに組み込んできました。そして私たちがAIにアプローチする方法は、AIが私たちを支援するというものです。私たちはまだ運転席にいます。私たち人間が問題を解決していますが、ますますAIから支援を受けて、オペレーションを前進させています。
私たちはすでに行っていることの一部を外部化しました。CloudWatch InvestigationsとCloudWatch MCP Serversをローンチしました。そしてこれらの機能のデモをご紹介します。ですから、開発者に力を与えることが私たちにとって、皆さんにとって本当に重要です。先ほどアニメーションに問題があったので、また起こらないことを願っています。私たちが持っているのは、いくつかのMCPサーバーです。CloudWatch MCPサーバーとCloudWatch Application Signals MCPサーバーです。そして開発者がこれらすべてのツールを持つことは本当に強力なことです。そうすれば、アプリケーションに切り替えたり、ブラウザに移動したり、AWSコンソールにログインしたり、さまざまなものを見たりすることなく、そのアプリケーション内で何が起こっているかについての洞察を得ることができます。しかし、もし私たちが彼らのIDE自体にできる限りのパワーを与えたらどうでしょうか？
ここで私はClaudeを使っています。そしてもちろんお持ちの任意のIDEを使用できます。ここで私がやっているのは、実際にClaudeに私のAWSアカウント内のすべてのSLOをリストするよう依頼しています。そしてここで私のAWSアカウント内のすべてのSLOをリストしています。これは先ほど私が行ったのと同じことです。トラブルシューティングのメカニズムで、先ほどワークフローで手動で行ったのとまったく同じことを、Claude、MCPサーバーを使って見せようとしています。ここですべてのSLOがリストされました。次に、問題のあるSLOをすべてリストするよう依頼します。そして実際に問題があることをリストしました。違反している特定のSLOについて詳細を教えてくれるよう依頼しています。それは訪問スケジューリングの可用性です。
これによって、これらがこの問題の可能性のある原因であり、それが問題である可能性があるという理解が得られます。次に進みましょう。そして依頼しますが、うまくいくことを願っていますが、どうやら気に入らないようです。でも、とにかく、実際にはMCPサーバーを通じてCloudTrail APIコールを行う許可を求めてきて、それから正確に何が起こったかの理解を得ました。このケースでは、DynamoDBのスロットリング問題があったことも返してきて、AWSコンソールにログインしたり、そのプロセスを経たりすることなく、その問題を解決するために私が潜在的にできることについての提案までしてくれています。もちろん独自のモデルを使用できます。結局のところMCPサーバーを通じてAPIコールを行っているので、本当に問題ではありません。
CloudWatch Investigationsの実力：自動化された根本原因分析で90%の満足度を達成
次に、実際にAWSコンソールへのアクセス権があった場合はどうでしょうか？どのようにできるでしょうか？そこでCloudWatch Investigationsの出番となります。ここでは、調査を行う機能をデモンストレーションしようと思います。
SLOが正常でない場合、実際に調査する方法があります。それをクリックすると、investigateをクリックできます。これが調査を開始する唯一の方法ではありません。良くない状態のメトリクスを見ているときや、ログイベントであるログを作成しているときにも、調査を開始できます。CloudWatch Investigateに問題があるかどうか調査するよう依頼できますし、全体を自動化することもできます。CloudWatchアラームを作成して、アクションとしてアラームが発生したらすぐに調査を開始するよう依頼できます。つまり、アラームが発生してそこに行って確認する頃には、すでに問題を見つけている可能性があるということです。
では、ここでinvestigateをクリックします。名前を付けましたが、皆さんには見えませんでしたね。申し訳ありません。そしてstart investigationをクリックすると、基本的に一連のタスクが開始されます。このケースでは、CloudTrailログ、CloudWatchログ、メトリクスを見ていて、アクセスエントリを作成してEKSクラスターへのアクセスを与えることもできるので、リソースに入って何が起こっているか調べることができます。見つけたトレースデータに基づいてトポロジーマップを作成しますが、このコンソールにずっといる必要は全くありません。実際に離れて後で戻ってくることができます。なぜなら数分かかるからです。実際、このプロセスは早送りしています。これを完了するには実際には数分かかりますが、離れることができます。
できることは、より多くの情報を提供することもできます。つまり、調査を開始したとして、クエリを実行してから、ねえ、このデータもあるから、このデータも含めてとか、あるいは別のメトリクス、何らかのメトリクス情報を追加することもできます。つまり、トラブルシューティングのプロセスを実際に支援しているわけです。これを行うと、基本的にすべての分析を行い、今すぐにでも根本原因が何かを教えてくれます。基本的に仮説を持って戻ってきます。そして戻ってきてここで潜在的な問題が何であるかを教えてくれます。分析が完了し、調査が終了したと表示されています。
そしてここでこの仮説が出てきました。皆さんにお願いしたいのは、ここにあるこの仮説、主に3番目のwhat happenedセクションに注目していただきたいということです。明らかに見つかった根本原因は、Claude V2モデルが利用できなかったことで、それが問題でした。それをすべて見つけましたが、興味深いことに、Application Signals faultメトリクスは実際にはこの問題を見つけられなかったので、深く掘り下げてこの問題を見つけなければならなかったとまで言っています。そして一番下の方で、本当に注目すべき監視のギャップがあることを示していると分析まで提供してくれています。つまり、実行しなければならない作業があることがわかります。これは本当に、これがないと、おそらく先ほど行ったようなSLOに入るなどのすべてのステップを実行しなければならなかったでしょうし、それが難しいわけではありません。はい、これよりは難しいです。なぜなら、これは私の代わりに作業をしてくれているからです。私が行って根本原因が何かを見つける代わりにです。
そしてCloudWatch Investigationsをチケットシステムに接続することができます。私たちは自社のシステムに接続しているので、AWSのオペレーターがチケットを受け取るたびに、彼らが対応を始める頃にはすでにCloudWatch Investigationsが実行されていて、チケットに関する最新情報を提供してくれます。そして私たちはこれらのオペレーターからフィードバックを収集しています。最近読んだ数字では、満足度は約90%でした。つまりAWSのチームはCloudWatch Investigationsを気に入っているということです。そして先ほど申し上げたように、現在AWSには多くのサービスがあります。それらのスタック全てがネイティブAWSであり、エンドツーエンドでCloudWatchを使用しています。
レビュープロセスの実践：週次ダッシュボードレビューとCorrection of Errorによる継続的な学習
では、私たちのドライバーの4つ目、最後のドライバーであるレビューについてお話ししましょう。私たちはインシデントをレビューし、オペレーションをレビューします。ここでは3つのトピックをカバーします。まず、週次のダッシュボードレビューです。月曜日に小さなチームとして集まり、 ダッシュボードを確認して異常を探します。スパイクを探すのですが、正直に言うと、これはレトロスペクティブを行うための口実なんです。ダッシュボードから始めますが、その後チームメンバーと運用体制について率直な会話をし、その週に何かアクションアイテムを取るべきかどうかを話し合います。
そして これらのダッシュボードをレビューする際、私たちのウィジェットには通常2つのラインがあります。アラームのしきい値とインベスティゲーションのしきい値です。例えば、APIサービスの経時的なレイテンシーメトリクスを見ているとして、チームとしてこのようなウィジェットを見た場合、 私たちのインベスティゲーションラインがなぜこんなに高いのだろうかと考えるでしょう。それを下げて運用バーを上げることができないだろうかと。このようなスパイクが見えたら、もちろん調査しますが、 時にはこのように何も違反していないけれども疑わしいものもあるので、それらも調査します。そしてもちろん、機械学習とAIを使ってレポートを作成する手助けをしてもらっています。ですから、ミーティングを始める頃には、すでにどこに最も注意を払うべきかを教えてくれるレポートが用意されています。
もう一つの学びは、週次でこれを行う場合、先週だけを見ないでください、ということです。なぜなら、より長期的なトレンドを見逃してしまうからです。
ですから、それらの機械学習ツールの季節的傾向を使ってください。なぜなら、実際には悪化しているのに、 その週だけを見ると問題ないように見えるものを見逃してしまうからです。
私たちはこれらのダッシュボードを火曜日と水曜日にレビューしています。火曜日はより大きなグループで、そして水曜日は会社全体で行います。AWSではオペレーショナルエクセレンスミーティングというものがあり、すべてのシニアリーダーが参加して、特定の事項について確認していきます。その一部が週次ダッシュボードレビューで、ランダムにチームを選びます。何年も前に最初に始めたときは物理的なホイールだったんですが、もちろんスケールしなくなりました。それでソフトウェアのホイールにしました。これはGitHubにあります。ダウンロードして、自分たちの週次ダッシュボードレビュープロセスを作ることができます。
この目的は誰かにストレスを与えることではありません。そこに出てきてダッシュボードをプレゼンするときはストレスがかかります。私も何度も経験しています。もちろん冷や汗をかきますよね。でも目的はお互いから学ぶことであり、リーダーとして私たちが質問をするとき、ダイヤルインしている全員も聞いているので、彼らも同じようにアクションを取るわけです。これが私たちのオペレーショナルエクセレンスをスケールさせる方法なんです。同様に、私たちは毎週チケットをレビューしています。ダッシュボードをレビューしているのと同じミーティングで、受け取った高重要度のチケットについてもディスカッションを行います。
ポイントは、繰り返し発生する問題、何度も戻ってくるものを見つけようとしているということです。Bezosの言葉を思い出してください。彼はこう言っています、繰り返し発生する問題を見つけたとき、もし見なければ、どうやって繰り返し発生する問題を見つけられるでしょうか？目的は、チケットを解決し続けて先に進むという反応的なモードにいたくないということです。私たちは根本原因を特定しようとしています。そして想像できると思いますが、Gen AIはチケットを要約するのが得意です。ですから私たちは、何もないところからではなく、何かから始めるためにGen AIをますます使うようになっています。
最後にお話ししたいのはCorrection of Errorです。私たちはCorrection of Errorについて広範囲に議論してきました。これについて書いた記事はたくさんありますが、今日のディスカッションを完全なものにするために、説明していきます。顧客に影響を与えるイベントがあったとき、大規模なイベントがあったとき、イベントから学び、これをより広い会社と共有できると考えたとき、私たちは非常に詳細なレポートを書きます。これがCorrection of Error、略してCOEと呼ばれるものです。
これを書くとき、私たちはこれを非難のツールにしないよう非常に注意しています。COEを書いている人やチームが、非難されている、罰せられていると感じるべきではありません。これは、あなたの会社、あなたの組織のリーダーとして、これは学習ツールであるという文化を浸透させることが非常に重要です。私たちは悪意を想定せず、善意を想定し、失敗したメカニズムを探します。正しいCOEの正しいアウトプットは、どのメカニズムが失敗したのか、そしてそれを修正するために何を導入できるのか、ということであるべきです。
こちらがCorrection of Errorのセクションです。これはテンプレートです。メカニズムなのでツールでもあります。つまり、Correction of Errorを作成できるわけです。入力するためのテンプレートが提供され、それがbar raisedされてレビューされます。水曜日のオペレーショナルミーティングでもレビューされます。もし十分に広範囲に及ぶものであったり、大きな学びがあった場合は、それらをピックアップしてレビューします。まずサマリーを書き、関連するメトリクスとグラフを載せ、カスタマーインパクトを書きます。また、うまくいったことも共有します。チームが素晴らしいことをしたのであれば、それを共有したいですからね。
Incident response analysisは、インシデントにどう対応したかについてです。そして私のお気に入りの質問の一つがこれです。問題を検知するのにどれくらい時間がかかりましたか、そしてその時間を半分にするにはどうすればよかったでしょうか?この質問を繰り返し、時間をかけてアクションアイテムを取り続けることで、自然と改善していくことができます。Post-incident analysisは、問題の診断などをカバーします。そして同じ質問です。検知はできました、でも何が悪かったのかを理解するのに1時間も費やしましたか?そして再びチームに尋ねます。考える練習をしてください、その時間を半分にするにはどうすればよかったでしょうか?あるいは、このシナリオに対するテストはありましたか?pipelineルールやoperational readiness reviewでテストを求めるのと同様です。
非常に詳細なタイムラインを書きます。それによってタイムラインのギャップや改善できることが見えてくるからです。そしてこの5 Whysのセクション、5というのは厳格なルールではなく、経験則です。最初のwhyは症状です、なぜこのサービスが何かに影響を与えたのか、そして最後のwhy、最後のwhyへの答えが根本原因であるべきです。これはチームにとって玉ねぎの皮をむくような作業です。そしてもちろん、最後にはlessons learnedとアクションアイテムがあります。AWSやAmazonで働いていれば、読むすべてのCOEがこの構造を持っています。
AIが支援するIncident Report作成とフライホイールの完成：スタートアップから始められるオペレーショナルエクセレンスの旅
私たちはこれらのCorrection of Errorsを相互に参照して使っています。そして指摘したいのは、ご覧の通り、これは手間のかかるプロセスだということです。時間がかかりますよね?そこでAIを使って、何もないところからではなく、何かから始められるようなシステムを構築しました。例えば、タイムラインを自動的に作成できないでしょうか?過去のCorrection of Errorsを使って、その知識ベースを活用してチームにアクションアイテムなどのアイデアを提供できないでしょうか?そして私たちはすでにこれを外部化しています。CloudWatch Incident Reportと呼んでいて、簡単なデモがあります。
では、先ほどの続きをやっていきます。あの調査を見ていますね。すでに完了した調査の一つが下の方にあります。Appointment Scheduling Troubleshootingと呼ばれているものです。これをクリックすると、できれば、はい、実はIncident Reportというボタンがあって、本来は表示されるはずだったのですが、アニメーションでは表示されませんでした。でもそれをクリックすると、自動的にこのレポートが作成されます。何をするかというと、右側に表示されているすべてのもの、これらはすべて、実際に調査が行われたときに収集された事実で、必要に応じて編集することができます。更新したい場合や、実際にはもっと多くのカスタマーに影響があった、あるいは少なかった場合、必要に応じてそれを修正できます。
しかし、私が注目したいのは、レポート自体の左側に表示されているものです。ご覧のように、タイトルが表示され、インシデントの背景があり、素晴らしいサマリーが作成され、すべてのグラフを含む可視化も追加されています。そしてMustafaが言及したように、顧客への影響について語り、何がうまくいったか、そしてインシデントレポート分析全体などについても記載されています。それで私が本当にお見せしたいのはFive Whysです。Mustafaが話していたように、基本的には、ええと、そうですね、基本的にすべての適切な質問を投げかけ、すべてのFive Whysを文書化し、根本原因が何であるかを見つけ出します。すべてが完全に文書化されており、そして明らかにここに留まる必要はありません。実際にチームと共有すれば、より有用になります。エクスポートして、クリップボードにコピーしたり、共有したり、必要であればドキュメントリポジトリに入れたり、ダウンロードして他のチームメンバーと共有したりできますよね。
ええ、そうですね。つまり、技術的な問題がなければトークとは言えませんよね。でも私たちは完璧を目指しているわけではありません。皆さん、私たちは一周してきました。フライホイールについてカバーしましたが、先ほど言ったように、オペレーショナルエクセレンスが向上すればするほど、私たちはより良いレビュアーになります。そしてもちろん、言い忘れていたことがあります。最後に言及したのはレビューセクションのCorrection of Errorで、最初にカバーしたのはOperational Readiness Reviewでした。そしてこれは、Correction of ErrorがOperational Readiness Reviewに実際にフィードバックされている例です。私たちが書くすべてのCorrection of Errorは、最終的に質問になります。つまり、完全にではありませんが、すべての興味深いCorrection of Error、広く適用可能なすべてのCorrection of Errorは、Operational Readiness Reviewの質問になり、私たちのプロセスにフィードバックされます。そして繰り返しになりますが、オペレーショナルエクセレンスが私たちをより良いレビュアーにするのです。
これらのプロセス、これらのメカニズムは素晴らしいけれど、Amazonは大企業だからこういうことができるんだ、もしかしたらあなたはただのスタートアップかもしれない、と思っているかもしれません。覚えておいてください、Amazonもスタートアップだったんです。Operational Readiness Reviewが最初に始まったとき、それはただのWordドキュメントで、いくつかの質問が書かれていただけでした。それがツールになりました。今では、私たちは2,000のテンプレートがあります。誰でも自分のOperational Readiness Reviewテンプレートを作成できます。だからどこかから始めなければなりません。そこで、いくつかのステップを提案したいと思います。もしここで聞いた何か、どんなメカニズムでもインスピレーションを受けたなら、これを自分の会社でどのように実装できるか考え始めることをお勧めします。それはあなた自身のバージョンになるでしょう。同じものにはなりません。でもおそらく、それを検討し始めることができます。そして私は皆さんをぜひ助けたいと思っています。CloudWatchを使う必要はありません、何でも使えます。もしオペレーショナルエクセレンスの改善があり、それに投資したいのであれば、ぜひお話しして、アイデアを提供したり、例えば計画をレビューしたりしたいと思います。
Animayahも同じです。彼は毎日、お客様のオペレーショナルエクセレンスを向上させるお手伝いをしています。そして、すでに言及したオンラインの資料がたくさんあり、さらに多くのものがあります。AnimayahとチームがまとめたこのObservability Best Practices Guideを読むことができます。繰り返しになりますが、同じ会社のウェブサイトにあります。Observability Workshopもあります。Animayahが見せていたすべてのデモを、自分でデプロイして遊んだり、もっと学んだりすることができます。
そして、もっと軽い調子で終わりたいと思います。Animayahと一緒にこのデッキ、このスライドを最初にまとめたとき、私はBay Areaにいて、San Franciscoオフィスを訪問していました。私はSeattleから来ていて、少人数のグループにドライランをする予定でした。そしてSan Franciscoオフィスに行く前の朝にコーヒーを飲みたくて、すぐ向かいにコーヒーショップを見つけました。信じられますか、それはFlywheel Cafeという名前だったんです。これがその店で、中には上にフライホイールがあります。そして信じられますか、私の直前にSan Francisco Fire Departmentのファーストレスポンダーが注文していたんです。だから私は、このトークをするのは運命だったんだと思いました。
お時間をいただきありがとうございました。ご参加いただきありがとうございます。お役に立てたことを願っています。もし私やAnimayahと繋がりたい場合は、ソーシャルメディアでお待ちしています。そして、もし何かご質問があれば、この後5分から10分ほど外にいますので、ぜひ直接お話しできればと思います。ありがとうございました。皆さん、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion