この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。
セッション名 : Improving resiliency with the correction of error process
概要概要(機械翻訳) : AWS Well-Architected Frameworkの信頼性の柱は、COE（Correct of Error）プロセスに言及している。このセッションでは、COEプロセスがなぜレジリエンシーを向上させるのかについて学びます。サービスの中断は、ネガティブな顧客体験につながり、顧客の信頼とビジネス価値を損なう可能性があります。インシデント発生後にCOE分析を行い、再発を防止するAmazonのベストプラクティスを学びます。本セッションでは、AWS Systems Manager Incident Managerを使ったCOEの仕組みの実装デモを行います。
スピーカー :
Juan Ossa, Enterprise Support Lead, AWS
Johnny Hanley, Solutions Architect, Amazon Web Services
レポート
なぜ COE（Correct of Error）のプロセスが重要なのかを説明します。
COE とは何か、COE のすべての構成要素を分解し、シナリオ例を出して説明します。
COE のデモを行います。
Incident Manager という機能があり、AWS コンソールの中で COE を文書化し、組織内で COE 文化を醸成する方法についてお話します。
Werner Vogels は、「Everything fails, all the time.」とよく言います。
物事がうまくいかない、計画通りにいかないとわかっているのなら、私たちのアプリケーションが部品の故障によって影響を受けることがないようにする必要があります。
そこで、アプリケーション全体の信頼性を高めるために、アーキテクチャに弾力性を持たせるのです。
Jeff Bezos は「Good intentions never work, you need good mechanisms to make anything happen」とよく言います。
それが今日お話しすることです。
Amazon では、フライホイールについて話すのが好きですね？
このシナリオでは、右側の detect と書かれた部分から始めます。つまり、イベントが発生した場合です。
何かがうまくいかなかったことを検知することが最初です。
次に必要なことは、それに対応することです。
トラブルシューティングを行い、その問題を軽減することに努め、その後、そこから学ぶことになるのです。
左上にカップリングについて説明する小さなセクションがあります。
学習は実際のイベントから切り離されたものにしたいと考えています。
分析する時間は、顧客が苦痛を感じているときではありません。
まず、対処して良い状態に戻すために時間をかけたいのです。
その後、すべてが落ち着いてから何が起きたのかを正確に把握し、分析する時間をとりたいのです。
根本的な原因だけでなく、根本的な依存関係も把握し、その出来事からできるだけ多くのことを学びたいからです。
問題を発見し、きる限り迅速に対応し、お客様の苦痛を軽減させたいと思います。
学んだことを活かして、次回に備え、変更を加え、再びこのようなシナリオが現れたときに備えておくことができます。 準備ができるのです。今日はこのことについて、もっと深くお話ししましょう。
Why is the COE process important?
なぜこれが重要なのか？なぜ COE のプロセスにこだわる必要があるのでしょうか？
根本原因の特定と改善パス。
問題が発生したときには必ず、その原因を突き止めなければなりません。
知識を文書化し、共有化すること。
一人の人間、あるいは少人数のグループの中だけの知識では困ります。
そして、その人たちが休暇をとったり、会社を辞めたりすると、組織的な知識は外に出て行ってしまいます。
ですから、チーム全体で広く知識を共有し、誰もがその出来事から学ぶことができるようにしたいのです。
学びから得た行動に基づいて、改善を測定。
なぜなら、これらはすべて改善のサイクルだからです。
What is a COE?
私たちはメカニズムを作りたいのです。
問題を特定し、解決し、アクションアイタムのオーナーシップを持ちます。
すべてについてもっと深く掘り下げて、学んだ教訓を最大限に生かすのです。
何かが起こったとき、多くの場合、私たちは症状や根本的な原因と思われるものを排除します。
しかし、それを本当に分析し、根本的な課題をすべて知るためにできる限り深く掘り下げることはしていないのです。
その事象から学べば、最終的に問題の再発を防止することができるのです。
しかし、ここで注意しなければならないのは、これがうまく機能するためには、安全な環境を作らなければならないということです。
私たちは、これが非難や罰のためではないことを確認しなければならないのです。
これは簡単で当たり前のことのように聞こえるが、そうではありません。その文化が、このプロジェクトが成功するかどうかを決めるのです。
これは本当に重要なことなのです。この点については、何度か触れるつもりです。
When is a COE necessary?
では、どんな時に必要なのでしょうか？
顧客に影響を与えるイベント、これは当たり前のことです。
トリアージを行うとき、これもそうですが、もっと深いこともあります。
手続き上のミスがあります。テストケースのミスです。
ある手順があり、その手順を進めると、どこかで意図したとおりのことが行われないことがあります。そうすると、何が間違っていたのか、どうすれば改善できるのかを考えなければなりません。
少々異なるケースでプロセスミスやユースケースの見逃しがあります。
これは、実際に一連のステップを意図したとおりに行ったが、意図した結果にならなかったというシナリオです。
これらの学習の機会があります。そしてもちろん、改善の機会もあります。
改善の機会となるような出来事があれば、そこに飛び込んで、できる限りの学びを得ましょう。なぜなら、私たちは改善のライフサイクルを最大化しようとしているからです。
Who owns a COE?
さて、これは誰のものでしょう？
情報から実際に学び、それに基づいて改善を行うことができる人なら誰でもいいのです。
根本原因に関わるチーム、イベントに最も近いところにいる人たちもオーナーです。
そのチームは、再発防止に必要な隠れた情報をすべて持っているはずです。
COE プロセスを進めるために、彼らに詳しく深く質問をしてみてください。
深く掘り下げていくと、改善の余地がある根本的な他の領域や依存関係がたくさんあることが分かってくるでしょう。 そうすると、主な症状は1つでも、改善すべき点が複数あることが分かってきます。 改善すべき領域が複数あり、その領域はチーム横断的に存在するかもしれません。
イベントを解決するだけではなく、起こった他のすべての出来事から学ぶ機会を持つようにしたいのです。
General tips for wrinting a COE
COE を書くための一般的な Tips です。
まず第一に、データが残っている間に収集しなければなりません。
それはどういうことかというと時間が経つにつれて、人々の記憶は薄れ始めます。また、保持ポリシーに基づき、ログが消えてしまう可能性があります。
だから、私たちは緊急性をもってプロセスを進め、まだ新鮮で利用可能なうちに、すべての情報を入手するようにしたいのです。
根本的な原因を確実に捕捉します。教訓に基づいたアクションアイテムを記録し、文書化します。そして、標準化です。
タイムスタンプを標準化する必要があります。
これが重要なのは、私たちが作業を進めるにつれ、タイムスタンプが事実上の歴史となるからです。
これはどの時間帯の出来事なのか？どっちが先なんだ？ですから、標準化したいのです。
イベントの正確な順序を確認できるリンクを含めます。
ドキュメントを読んでいる人が、データ・ソースへのリンクがあれば、実際のデータ・ソースをもっと深く掘り下げることができるようになります。
COE components
それでは、COE の構成要素について説明します。
まずは要約から始めます。これはエレベーターピッチのようなものです。
次に影響です。これは後ほど深く掘り下げます。
そして、タイムラインとメトリクス。何がいつ起きたのかを正確に把握し、定量化するためにできることはたくさんあります。
5つ目は、イベントに関する質問、分析を開始することです。
そして、「5つのなぜ」です。
これは秘密のソースです。明らかな症状だけを見ているのではなく、より深いレベルで質問を続けます。
いくつかのアクションアイテムを取ります。
今後どうするか、ですね。これはすべて、改善のライフサイクルに関わることなのです。
最後は、関連するアイテムです。
「以前にも同じようなことがありましたか？これは断続的な問題なのか？これは私たちが認識しているよりも大規模な問題なのでしょうか？」
何が起きたのか、どのような範囲なのかを正確に理解するために、できる限りの情報を集めます。
要約
要約は最後に書くことにします。
ドキュメントの中では最初に読むことになりますが、それを書くためにはすべての情報が必要です。
だから、最後に書きます。
何が、どこで、なぜなのか、何が起こったのか、根本的な原因を参照し、すべての詳細を概説します。
これはエレベーターピッチのように、何が起こったかを簡潔に伝えるものです。
影響
影響については、その出来事による顧客への影響について、簡潔に説明します。
何が起こったのか。感じた痛みは何だったのか。誰が影響を受けたのか？顧客体験はどうだったんだろう？どのくらい続いたのでしょうか？
私たちは本当に理解したいのです。すべてを数値化して、その出来事の正確な詳細を理解したいのです。
私たちは、これらのイベントから得られる学びを最大化したいので、広い網を張りたいのです。
タイムライン
タイムラインの話をしましょう。
重要な出来事が起こっていた正確な時間を確認したいのです。
他のデータソースも含め、タイムゾーンは統一しておきたいものです。
重要な時間帯をハイライトすることで、イベントが発生したときに、その変曲点がいつであるかを正確に把握することができます。
そうすることで、将来的に傾向を把握し、同じようなことが起こった場合に対策を講じることができるようになります。
してはならないのが、責任を負わせたくないということです。個人名を使うつもりもなければ、チームのことを話すつもりもないのです。
個人を特定できるような情報を暴露しないように注意しなければなりません。
COE は組織全体の複数の人々が参照する文書になるため、適切なサニタイズ処理を行う必要があります。
冗長にならないように注意します。
非常に明瞭かつ簡潔で、それでいて説明不可能な大きなギャップがないようにしたいのです。
時間の空白をさけます。
文書を読む人が、「この時間帯には何があったのだろう」と思い込まないようにしたいのです。
だから、時間の空白がないことを確認するのです。
メトリクス
影響とその回復を示そうとしており、それを定量化可能なメトリクスで行います。
メトリクスが無いと傾向がつかめず痛みに繋がります。
常にメトリクスを取得します。情報を定量化します。
メトリクスをグラフ化するなら、繰り返しですが、一貫した時間軸を使います。
クリティカルイベントの特定と説明に役立ちます。
イベントに関する質問
今あるものを文書化することについてお話しました。
次は、どのような質問をすればよいのかについてお話します。
まず最初にやらなければならないのは、イベントを検出することです。
どうやってそれをするのでしょうか？最初に尋ねたいのは、顧客に影響があったことを知ったのはいつなのか、ということです。
この問題が起こったことをどうやって知ったか、ですね。
つまり、いつ起こったかだけでなく、どのようにして私たちの注意を引いたのか、そして、どうすれば検出時間を半分に短縮できるのか？
繰り返しになりますが、これはすべて改善のためです。そして、将来的には、より速く対応できるようにしたいのです。
次にやることは、何が起こったかを診断することです。
何らかの事象が発生したときに、私たちが最初に尋ねることは何でしょうか？
何が変わったのか、ですよね？
ですから、何かが変わる、あるいは可能性があることを前もって知っていれば、何か問題が発生したときに、より迅速に対応できるような人材を準備できます。
そして、緩和です。
影響はいつイベント前のレベルに戻ったのでしょうか？
システムオーナーはシステムがイベント前の状態に戻ったことをどのようにして知ることができるのでしょうか？
問題を軽減するために、すでにイベント中に何らかの学習プロセスを経ているのです。
私たちはすべての情報を収集し、緩和までの時間を半分に短縮する方法を考えています。
5つのなぜ
では、どうすれば次はもっと良くなるのでしょうか？どうすれば改善できるのか？
そこで、「5つの理由」、あるいは必要であればそれ以上の理由を考えることになります。
まず、根本的な原因を特定することから始めます。つまり、症状を改善するために、何を軽減することができたかです。 私たちは因果関係の連鎖を構築しようとしています。
何がこのような事態を招いたのかを正確に理解するために、さらに深く掘り下げているのです。 症状そのものだけでなく、連鎖の下にある他の依存関係まで掘り下げます。
アクションアイテム
アクションアイテムです。それで、誰がいつ修正を実行するのかです。
ここでの第一の目的は、再発を防止することです。
すべての関係者と調整し、アクションアイテムを設定します。そして、緊急性を維持します。
というのも、私たちの最終的な目的は、私たちが改善していることを確認し、もしまた何かが起こったときに、より良い準備ができるようにすることだからです。
行動を起こさないままだと、また同じことが起こるのです。
できるだけ早く結果を出すように、アクションアイテムのオーナーと納期を設定します。
それらは変更可能です。
もし、現実の問題として、オーナーを変更したり、期日を変更したりする必要があれば、それはそれで構わないのです。
しかし、私たちは、常にこの2つの条件を満たしていることを確認したいのです。
関連するアイテム
そして、関連するアイテムを探します。
このケースは他のケースに関連しているかどうかを見ています。他の学習領域から情報を得ることができますか？
私たちが情報を提供すべき他のチームがあり、彼らが集めようとしているものと情報を掛け合わせることができますか？
以前にも同じようなことが起きましたか？
我々はできる限りの情報を得ようとしたいのです。
COE scenario
では、Juan にこの話を引き継ぎます。
より現実的で意味のある話をしてくれるでしょう。
サンプルシナリオを紹介します。
ユーザーが JSON 形式のファイルを S3 バケットにアップロードするために作成したアプリケーションです。
S3 バケットが Lambda をトリガーして、Lambda が JSON ファイルを CSV 形式のファイルに変換します。
そして、それを別のバケットに再度アップロードして、DynamoDB の詳細に情報を送信します。
アプリケーションチームがいて、ワクワクしながら開発し、そして本番に投入してくれました。
本番稼動させた後、彼らはメトリクスをチェックしているようです。
しかし、突然、顧客からコンタクトセンターに電話がかかってきて、アプリケーションに問題があることを指摘されました。
アップロード後にファイルを取得して見ようとしたところ、アプリケーションは正常にアップロードされたと伝えたにもかかわらず、ターゲット S3 バケットにファイルが表示されないというのです。
Demo COE
上記サンプルを用いて COE のデモをします。デモは事実に基づいています。
サービスチームは問題を発見し、COE 文書を作成します。
デモ 影響度
10,000以上のファイルが処理されましたが、正常に変換されませんでした。
顧客は「アプリケーションは問題なく動作している」というメッセージを受け取りました。
しかし、変換されたファイルはどこにもありません。
イベントは AM9:38 から始まって、AM11:38 に解決したそうです。
デモ タイムライン
全部を読み上げるつもりはありません。
時間、タイムゾーン、日、月、年のフルタイムスタンプがあり、そこにある情報は事実に基づいています。
非難や所有権のある情報はありません。
そのタイムラインは、何が起こったかを物語っています。
デモ メトリクス
元々、処理すべき文書のキューの深さと処理すべき文書の割合の2つのメトリクスを取得していました。
追加で、変換用 Lambda 関数のエラー率と DynamoDB 更新数のメトリクスを追加取得するようにしました。
デモ イベントに関する質問
Q. 顧客に影響があったことを知ったのはいつですか？
A. グリニッジ標準時マイナス5で午前9時45分頃でした。
Q. 顧客への影響があったことを知ったのは？
A. コールセンターからサービスチームへ、顧客から苦情が来ているとの連絡が入り始めました。
Q. そして今、どうすれば検知までの時間を半分に短縮できるでしょうか？
A. より良い測定基準と分析があれば...
Q. なるほど。このインパクトの根本的原因は何だったのでしょうか。
A. アプリケーション内のデータ検証とエラー例外処理が不十分でした。
Q. この間、社内での活動、例えば保守作業は行われていましたか？
A. はい、新しいアプリケーションを本番稼動させました。
Q. では、どうすれば検出までの時間を半分に短縮できますか？
A. 繰り返しになりますが、アナリティクスでより良い測定基準があれば、トレンドの発生を確認することができたでしょう。
Q. では、顧客への影響がイベント前のレベルに戻ったのはいつですか？
A. 11時38分24秒、グリニッジ標準時マイナス5です。
Q. システム所有者は、システムが適切に復旧したことをどのように確認するのですか？
A. これは私たちが直面した課題の1つで、人々に尋ねながら、完全な情報が得られることを願うしかありませんでした。
そのため、新しい測定基準、つまり新しく作成した測定基準が必要です。
Lambda のエラー率や、期間ごとの DynamoDB の更新回数があれば、もっとよく理解できるのではないかと考えています。
Q. なるほど、どこでどのように問題を軽減するのか、どのように判断したのでしょうか？
A. すべてのログに目を通す必要がありました。文字通りすべてを関連付け、何が起こっているのかを突き止める必要があったためです。
Q. どうすれば解決までの時間を半分に短縮できるのでしょうか。
A. より良い測定基準と分析があれば。
同じ答えの繰り返しですが、この問題を解決するために本当に必要なのは、このようなことです。
デモ 5つのなぜ
Q. 確かに、アプリケーションはクラッシュしました。みんな知っていることですが、なぜアプリケーションがクラッシュしたのでしょうか？
A. アップロードされたファイルが表示されなかったんだ。
Q. なぜアップロードされたファイルが表示されないのでしょうか？
A. Lambda 関数が、データベースを更新しなかったからだ。
Q. なぜ Lambda 関数はデータベースを更新しなかったのでしょうか？
A. Lambda 関数は実行中にエラーが発生しました。
Q. では、なぜ Lambda 関数は実行エラーを返したのでしょうか？
A. 無効なデータ型があったのです。
Q. なぜアプリケーションは無効なデータ型をグレイスフルに扱わなかったのでしょうか？
A. エラーになることさえ知りませんでした。
Q. なぜアプリケーションにエラーがあることに気づかなかったのでしょうか？
A. それは、Lambda 関数の実行におけるエラーを捕捉するためのメトリクスがなかったからです。
さて、この6つの質問の後すぐに、私たちは根本的な原因を特定しました。
デモ アクションアイテムと関連するアイテム
このイベントの最初のアクションアイテムは、ランブックの更新です。エンジニアは何をすべきかを知っています。
このアクションアイテムのオーナーはサービスチームであり、期日が設定されています。
2つ目のアクションアイテムは、提案された新しいメトリックの実装です。
ここでもオーナーはサービスチームで、期日があります。
関連するアイテムは、アプリケーションにエラー処理を追加することと、アプリケーションに入力検証を追加することです。
cultivating the COE culture
COE 文化の育成についてお話します。
私たちはすでにこの COE プロセスを作成し、それを得意とする専門家を何人か抱えています。 これを組織内で拡大するにはどうしたらよいでしょうか。
実践のコミュニティを作ることから始めましょう。
専門知識をコミュニティに広める必要があるのです。大きな組織であれば、情報を必要とする人々の近くに専門家や仲介役を配置する必要があります。
最初にしたいことは、アーリーアダプターのためのコミュニティを設立することです。このプロセスに非常に情熱的で、すでに実践している人たちが、このコミュニティを形成します。
おそらくこれは、Slack チャンネルを立ち上げることであり、コミュニケーションのための他のメカニズムを立ち上げることでしょう。
そうすれば、これらの教訓を非公式に共有することが促進され始めるでしょう。ベストプラクティスが形成され情報すべてを文書化し、共有し始めるでしょう。
ベストプラクティスをすべて標準化したら、その学びを組織全体で共有し始めることができます。
まずすることは、チャンピオンを特定することです。
組織内のさまざまなチームにチャンピオンを配置し、COE についてもっと学び、組織に組み込まれたチャンピオンになるよう、ボランティアで参加してもらいます。
そして、トレーナーを養成するのです。
チャンピオンを訓練し、彼らはより多くの情報を得ることで、チームの人々により良いサービスを提供することができるようになるのです。
What have you learned?
さて、今日はどんなことを学んだのでしょうか。
COE とは何か、
なぜ改善のための文化を持つことが本当に重要なのか、
計画通りにいかないことがあればいつでもそこから学びたいと思うのか、
について話しました。
これは、私たちが常に良くなっていくことを促進するのに役立つと思います。
そのためには正しい文化が必要です。責任の所在を明らかにし、改善点を指摘すれば誰もが報われるようにしなければなりません。
どのようにするか、誰がそのプロセスの一部になるかを話し合いました。
以上、吉井 亮 がお届けしました。
0
