Category
ベストプラクティス

Aditya Patil

January 3, 2019

デジタル運用の成熟度とは？

デジタル運用の成熟度は、リアルタイムの作業での組織の有効性と、その組織がインシデントへの対応に熟達するにつれて改善するパフォーマンス指標にフォーカスする能力として、定義されます。

PagerDutyは、複数の業界に渡る600名以上の回答者を対象にした調査を含む、広範囲な調査と9年間の業界のデータに基づいて、次の4つの運用成熟度レベルを特定するモデルを開発しました。

リアクティブな組織は、ほとんどの問題を顧客が報告したときに見つけることが多く、これらの問題に対処するためのプロセスを持っていません。第1線にいるレスポンダーが、サービスの問題を解決するためのスキル、知識、または権限を持っていないこともよくあります。 レスポンシブな組織は、顧客に影響が出る前にいくつかの問題に直面します。第一線のレスポンダーはスキルを持っていて問題を防ぐための権限を得始めています。しかし、その人々はまだ自分たちの仕事をするのに必要な情報を欠いています。 プロアクティブな組織は、顧客が影響を受けたり気付いたりする前に、ほとんどの問題をあぶり出して解決します。過去の問題から学んだことは自動的に文書化され、レスポンダーは現在の問題を解決し将来の問題を防ぐための知識と権限を与えられています。 プリベンティーティブな組織は、顧客に影響が及ぶ前に、ほとんどすべての問題をあぶり出して解決します。このレベルを達成するのは非常に困難であり、このレベルで活動している組織の特徴は継続的に学習する文化を持っていることです。この組織のレスポンダーは、現在の問題を解決し将来の問題を防ぐための知識と権限を十分に与えられています。これらの組織は、リアルタイムの対応プロセス全体にわたって自動化の仕組みを多用しています。

PagerDutyは、以下の図に示すように、組織の運用上の成熟度を決定する上で重要な5つの重点分野を特定しました。

5つの重点分野がビジネスの改善にどのように役立つかについて、さらに詳しく説明しましょう。

1.カスタマーエクスペリエンスを改善する

ビジネスを常に「顧客第一」と考えるように位置付けることは、今日の市場では重要です。これは、顧客にシームレスで中断のない経験を提供するために可能な限りのことを行うことを意味します。次のシナリオを検討してください。

あなたはサンフランシスコのサウス・オブ・マーケット地区にあるお気に入りのPhilz Coffeeに来て、ブリトーを欲しがっています。あなたは自分のスマホでライドシェア用のアプリAを開きますが、それがロードされません。それであなたは数秒待ちます。いや、まだロードされません。ついにあなたはあきらめてアプリを閉じて、競合他社のアプリBを開きます。これでは、Aの売り上げを失ったことになりますね。それだけじゃありません。

次回乗車が必要になったときには、前回のライドシェア会社Aでの体験を覚えている可能性があるので、まずB社のアプリを開きます。つまりそうした1つのちょっとした体験がA社の評判を損ない、将来的に売り上げをフイにさせる可能性があります。実際、Gartnerは、平均的な企業のダウンタイムコストは1分あたり5,600ドル、または1時間あたり約300,000ドルであると見積もっています。

潜在的なお金を失う可能性は大きいのです。顧客と収益を維持するために、企業は自社のデジタルビジネスがほぼ100％常に稼働している状態を確保する必要があります。しかし、当社の調査によると、回答者の50％以上が自社の組織がレスポンシブまたはリアクティブであり、顧客に損失を与え顧客との関係を壊すことにつながるダウンタイムを防止または削減するための適切な対策を講じていないことを示しています。

2. 従業員の健康と会社の文化を改善する

最も単純に言えば、企業は共通の目標に向かって努力する人間の集団に他なりません。 （そしてPagerDutyには最高の人間がいます。一緒にやりましょう！）

従業員は会社の最も貴重な資産でもあるので、燃え尽きを防ぐための対策を講じることはその人たちの幸せと生産性を維持するために不可欠で、結果的に離職率も低くなります。

なぜ組織が離職率を気にする必要があるのでしょう？貴重な蓄積された組織知を失うことは置いておいて、IT専門家に関するPagerDutyの最新の調査では、1人の経験を積んだレスポンダーを別の人に変えるには最大30万ドルものコストがかかることが分かりました。こうした種類の数字を検討すると、次のような質問をすることによって個人と全社の健康状態を追跡することが会社にとって最も重要です。

勤務時間後に従業員が呼ばれる頻度はどのくらいですか？ あなたのチームのIT担当者の年間離職率はどのくらいですか？

これらの指標にアクセスできることは有益で、対処不可能なアラートや繰り返し発生する対処不可能な量のインシデントが、仕事から離れた従業員をイライラさせることにつながることを理解できるようになります。また、アラートの数を減らすことによる影響はすぐには表に出ないものの、時間の経過とともに大きな違いが生じることも当社のデータから明らかになっています。

現実に、アラートを減らすための対策を講じた成熟した組織では、成熟していない同業者と比較して、オンコールする担当者（レスポンダー）の離職率が21％低くなっています。 50人のレスポンダーがいて、10％の離職率である会社の場合は、21％の削減は年間31万5000ドルの節約になります。

3. MTTRを削減するために各プロセスを最適化する

プロセスの最適化は組織がスケールするにつれて重要になります。しかし、それは単にベストプラクティスを見つけてそれに従えばよいというわけではありません。つまり、各企業は改善のための領域を特定するために既存のプロセスを評価する必要もあるのです。 例えば、インシデント対応中の利害関係者への通知は、ほとんどの組織で改善できるプロセスです。以前のブログで説明したように、中核の対応チームの外にいる人々に最新情報を提供するためのコミュニケーション戦略を構築することで、オンコールレスポンダーはインシデントの解決にもっと時間を費やすことができます。

さらに、インシデント対応プロセスは、インシデントが解決されたというだけでは完了しません。成熟した企業におけるデジタルオペレーションの要素には、チームが根本原因の分析を実行できるようにする、ブレームレスつまり個人の責任を問わない事後分析（ポストモーティム）プロセスが含まれます。これはパターンを解析し、類似のインシデントが再発するのを防ぐのに役立つ洞察を提供します。

4. 知識共有の実践を育てる

5. 正しい技術とツールを使う重要性

現代では組織がビジネスプロセスを最適化するのを支援するために豊富な技術とツールが利用できます。そして健全で成熟したデジタル運用のプラクティスを構築する場合でも同じです。オンコール中の従業員は、大量の通知や対処できない警告に溺れてはいけません。以下の表は、組織の成熟度に3つの重要な指標がどう対応しているかということに関するいくつかの重要な発見をまとめたものです。

注目すべき点は：

最も成熟した回答者は25％のアラートしか 対応不能（unactionable）なものはないと回答していますが、最も成熟していない回答者は28％のアラートがunactionableだったと回答しています。 最も成熟した回答者のインシデント対アラート比（incident-to-alert ratio。実際にインシデントになったアラートと全アラートの比 ）は約1：3でしたが、最も成熟していない回答者は約1：1でした。 最も成熟した回答者は自動化で問題の57％を解決しました**が、最も成熟していない回答者は自動化で問題の16％しか解決できませんでした。

成熟した組織によくある最も一般的な特徴は、過去のインシデントから学んで、それによって、顧客が影響を受けるようになる前にインシデントを解決する、またはアラートのノイズを減らす、どちらかのテクノロジーを利用していることです。 従業員が対応不能なアラートの確認と自動化で解決される可能性のあるインシデントの手動での解決に注力している場合は、て本来は業務の革新や他の問題解決にかけるべき数えられないほどの人・時が失われます。重要なのは、組織のデジタル 運用をReactiveからPreventativeに成長させ、そしてカスタマーエクスペリエンスを向上させるための革新の推進に集中するために、チームに適したツールを見つけることです。

組織の運用上の成熟度を向上させる方法についてもっと知りたい場合は、弊社までぜひお問い合わせください。

GET STARTED

この記事は、PagerDutyサイトに掲載されたブログをDigitalStacksが和訳・追記したものです。無断複製を禁じます。原文はこちらにあります。

今日のインフラストラクチャ はあなたの祖父母の時代のITインフラではなく、1世代前のインフラでもありません。 パンチカード、真空管、フェライトコアメモリー、フロッピー、ダイヤルアップインターネットの時代はもう終わりました。

そして今日のインフラは、5年前、あるいは1年前のITインフラでもありません。 現代のインフラは絶えず変化しています。この記事で私たちにできるのは、インフラのスナップショットを見せ、それが今度どうなるのかという一般的なイメージを伝えることです。

インフラの効果的な監視には、今日のインフラの様相とそれがどう変わっていくか、将来何がそこに含まれることになるのかを理解しておく必要があります。

ハードウェア：たぶんムーアの法則の予想を下回る

ハードウェアインフラは比較的安定しており（「相対的に」という言葉が強調されています）、数年間は半安定の状態にあります。 ムーアの法則が限界に達しつつあるという推測は時期尚早ですが、Mooreの法則が描く曲線は、少なくともプロセッサ速度とRAM容量（大容量ストレージは別の話かもしれない）に関しては、部分的に平準化しつつあるようです。

ソフトウェア：変化するのが自然

この平準化は、ITインフラの最も重要な変化がソフトウェア側で起きていることを意味します。これは驚くべきことではありません。なぜなら、現代のインフラはかなりの部分をソフトウェアに負っているからです。 SDN(Software-defined networking)、仮想マシン、コンテナなどは、今日のハードウェアとソフトウェアの間の線が事実上ひどくあいまいになっていることを示しています。

ソフトウェアとしてのITインフラが現代のコンピューティングの大事な要素だということは驚くべきことではありません。 結局のところ、ハードウェアは基本的にフレームワークであり、何かを可能にするために設計された構造です。 その可能性を利用できる人は、世界にあらゆる違いを生み出すことができます。

ハードウェアの遅れから解放される

ソフトウェアベースのインフラへの移行は、これまでのプラットフォームの変化をはるかに超えた意味を持ちます。一つは、ハードウェア自体の変更の速度に大きな遅れが見られることです。物理サーバー、ネットワーク、および周辺機器を交換またはアップグレードするには、費用がかかり、時間がかかるので。その必要性が明確になるまで（またはなった後まで）、多くの組織が長い時間待って、それからハードを更新していました。この遅れはほんの数年かもしれませんが、レガシーなハードウェアとそれに必要なレガシーなソフトウェアの両方を共存させることを要件としたために、ソフトウェアレベルにもインフラのハードウェア自体にも影響を与えました。

しかし、現代のソフトウェアベースのインフラでは、アプリケーションソフトウェアとインフラを構成する要素の両方が、基本的なハードウェア要素の大部分（全てではないにしても）から隔離されています。ハードウェアが抽象化レイヤーの要件をサポートできる限り、インフラ自体にはハードウェアの遅れの影響がほとんどありません。

「ソフト」要因

結果として、インフラソフトウェアとアプリケーションソフトウェアの両方の変化の速度は、現在の組織文化やソフトウェア設計と開発の速度に関する現実の制限などの他の要因に支配されています。 これらの要因は一般的に「ソフト」的であり、それが課す遅れははるかに短く、特定の組織内の一般的な状況により多く依存しするようになっています。

今日のインフラ

つまり、今のコンピューティングへの理解は、現代のITインフラの現状を今のこの時点でとらえたスナップショットに過ぎないことを意味します。 そのようなスナップショットには何が含まれているでしょうか？ 大事な要素は次のようになります。

クラウド。インフラが抽象化された複数の層の上に位置するソフトウェアである場合は、それが特定のサーバーまたはネットワークのセットに結び付けられる理由はありません。 クラウド（基本的に高レベルの抽象化レイヤー）は、開発者が相互作用する最も基本的なインフラになります。 開発者が作成し管理するインフラは、それがVM上で実行されているアプリケーションであっても、仮想化されたホストシステム上で実行されているコンテナで構成されているものであっても、実質的に完全に仮想化されています。 仮想化。 仮想化は既存のものとなっていて、私たちは今この事実の意味を理解し始めているだけです。 既存のオペレーティングシステムはもともとハードウェアによって課せられた制約を念頭に設計されていました。 ハードウェアに課せられた制限を参照することなく完全に設計されたシステムはまだありません。

しかし、現在のオペレーティングシステムの限界があっても、標準となった仮想化を使えば、アプリケーションだけでなく、それらが存在する環境も、伝統的なOSで実行された簡単なプロセスと同じくらい簡単に、作成、管理、 破壊できます。

パイプライン全体の自動化** インフラがソフトウェアの場合、他の種類のソフトウェアを管理するのと同じ方法で、インフラを管理するのが合理的です。 また、この自動化をソフトウェア配信パイプライン全体にわたって拡張することも合理的です。それがパイプラインの全プロセスを管理するための単一のシステムの形を取ったとしても、あるいは必要に応じてタスクを互いに引き離す一連のスクリプトの形になったとしてもです。

伝統的に、自動化はしばしばスケジュール駆動型でした。 しかし、現代のインフラストラクチャーでは、通常、イベント駆動型です。 これにより、より大きな柔軟性が得られ、不要な遅延が排除されます。

切れ目のない配送**。 そういうフレキシブルな応答駆動型の自動化は、当然、継続的な配信につながります。 手作業による介入や配送プロセスによる遅れがないのですから、連続してはならない理由はありません。

実際、配信が途切れ途切れになっていた理由は、通常、仮想化されていないインフラと配信パイプラインが自動化されていなかったからです。 仮想化されたソフトウェアベースのインフラを完全に自動化する機能と組み合わせることで、ハードウェアベースのインフラの制約に対応する必要性がなくなり、継続的な配信が可能になりました。インシデント管理で継続的な配信を最適化する方法については、こちらをクリックしてください。

https://www.pagerduty.com/resources/learn/continuous-delivery

では、今日私たちはどうにコンピュートするのでしょうか？ 私たちは仮想化され、抽象化の複数のレイヤーによってハードウェアレベルから隔離された環境でコンピュートしています。 当社の開発およびデプロイメントパイプラインは、イベント駆動型の自動化によって途切れることなく管理されています。 多くの点で、現代のIT環境は、従来のハードウェアベースのIT世界から隔離された仮想世界になっており、数年前にITを支配していた懸案の多くが無関係になっています。

バーチャルな明日？

以上が今日のスナップショットだとすれば、明日は、さらに5年先、10年先はどうなるのでしょうか？　もちろん、実際に知る方法はありません。今日の予測は、時間が経つにつれ、だんだんと的外れになる可能性があります。

しかし、ここにいくつかの他の予測があります。ハードウェアによって課せられた制約から仮想コンピューティング環境を解放する効果が見え始めたことがその1つにあげられます。また、仮想化されたコンピューティングと、バーチャルリアリティと、昔からの物理的な経験の区別が崩壊する可能性があります。多くの点で、今日のコンピューティングの変化の速度は、私たちの能力によって制限されています。つまり変化が発生したときにそれを私たちが吸収し、発達するにつれてその力をフルに活用する能力によって制限されています。しかし、自動化とインテリジェンス機能は、垂直でもドメインでもほぼ全ての機能を破壊的に変え、効率性の新たな可能性を広げ、人々の作業の焦点を劇的に変える可能性があります。

おそらくコンピューティングと日々の経験の両方の仮想化は、将来の変化を吸収する速度を早めます。私たちが未来のクリエーターになり、未来に参加する可能性が高いとしても、このような場合、もし今私たちがその一部を垣間見られたとしても、将来のコンピューティングと人間生活の両方が完全に理解不能になります。世界を変えるなら私たち自身も変えることになるのです。

あらゆるビジネスが デジタルビジネス に進化し、ほんの少しの停止時間でも、これまで以上に収益とブランド価値に深刻な影響を与えるようになり、危機に直面した際の効果的なコミュニケーションの必要性が増してきました。これによりサービスを開発・管理する技術チームにより高いプレッシャーがかかっているということですが、さらにデジタルトランスフォームは、ブランドの評判と顧客体験に責任を持つ他の事業部門にもプレッシャーをかけています。

製品やサービスから顧客が最大の価値を引き出せるようにする責任を負うコミュニケーション、マーケティング、とりわけサポートチームを見てみましょう。プレッシャーによって渉外機能に新しいワークフローとベストプラクティスが必要になっています。PagerDutyで私たちが学んだ実践から、これまでに磨いてきた4つのベストプラクティスを紹介します。

1. みんながオンコール担当

PagerDutyのコミュニケーションチームの一員として、私は技術担当の同僚や他の多くの人と一緒にオンコールの仕事に従事しています。受け取るインシデント通知のほんの一部を見ても、なぜ自動化とインシデント対応プロセスを持つことがスムースな運用に必要なのかを深く理解しています。それが今日のデジタルサービスをうまく稼働させているのです。何かが顧客にインパクトを与えるとき、コミュニケーションチームやサポート、営業、法務、そしてリーダーなど他の部門の関係者は、私たちが顧客と適切なコミュニケーション対応をプロアクティブに取れること、そして時が経つ間に自らのブランドと顧客の約束を守るために正しい対応を効果的にやれるのだということを、知っておく必要があります。

2.サポートと足並みをそろえる

受賞経験のある当社のサポートチームは重大インシデントに遭遇したときには顧客対応の最前線に立ちます。しかしコミュニケーションチームは次のことを理解するために整列して待機しています。

どんなインシデントでなぜそれが起きたのか？ どのくらい多くの顧客がどのくらい長く影響を受けているのか？ インシデント対応はどのくらい進んでいるのか（まだ調査中なのか解決に近づいているのか）？

インシデント対応プロセスの中では、チームは顧客との連絡窓口（注：カスタマーリエゾン）を必要とします。その窓口担当は、アプリやサービスに起きている障害がさらに悪くなりそうな時に外部と最善の方法でコミュニケーションをとれるよう訓練されている人たちです。

私たちのコミュニケーションチームは、今何が起きていてどんな影響があるのかを正確に理解するために、カスタマーリエゾンと一緒に作業をします。PagerDutyの中では、インシデントに関するSlackチャネルの一部に加え、Stakeholder Engagementという機能で情報の更新を自動化しています。我々は各チームからより抜かれた適切な人の間で協業が進むようタイトなラインを作り、顧客やより広い市場との有益なコミュニケーションが作れるように協力しています。

3.プロアクティブになろう

伝統的なチケットやITSMのワークフローを使っている場合、プロアクティブになる機会を失っているかもしれません。顧客は何か悪いことが起きるのをあなたより前に知ります。例えばソーシャルメディアなどの公開の場やニュースで彼らが気づく前にあなたが問題を修復する機会はないでしょう。コミュニケーション対応の観点からは、外向けに出すメッセージをより早く作れるよう行動するべきです。そうすれば不満のツイートや正しい情報を求める記者からの電話に対応できるようになります。インシデント対応コミュニケーションのこの段階では、傷ついた評判を修復する戦略を立てることが大事であり、理想的には事態を正常化するためにリアルタイムに起きていることを共有すべきです。プロアクティブなコミュニケーションを支援するため、我々は発生しうる危機のシナリオを特定してワークフローを作り、さらにこれまでの経験に基づいて、使うべき言葉を中心に、ベストプラクティスを作成しました。もちろん、危機シナリオは独自のものですが、平和な時に基礎を作っておけば、余裕がなくとストレスが高い戦闘中でも、素早く行動できます。

4.ブランドをリシェイプする

インシデントが解決してもコミュニケーションチームの仕事は終わりません。理想的なインシデント管理のライフサイクルの中で、重大インシデントは必ず事後検証を受けるのです。その中では関係者全員が、何が起こったのか、その対応がどう実行されたのか、今後どのように改善できるのかを議論します。これは学習と改善のための時間です。コミュニケーションチームにとしては、組織全体で協力し顧客や広範なコミュニティの信頼を回復する計画を策定し実行する必要があります。つまり当社のブランドが期待に応えられなかった部分を改善する戦略を実行するのだと考えてもらってよいでしょう。企業としての表明も改訂し、健全な判断を使い今後どうするのかを検討しないといけないでしょう。これはまた、あなたががビジネスに携わっている理由と言行一致を確約するための時間でもあります。ビジネス全体での行動が間違いを正すために必要かもしれません。

今日の、”マイクロ秒単位の時間”に支配され、常時オンが当たり前の世界で成功するためには、コミュニケーションチームは他のチームと一緒にデジタルオペレーションのエクセレンスの追及に”レーザーフォーカス”しなければなりません。これは、これまでと違う覚醒を意味するだけでなく、法外に優れた顧客体験を提供することを心の中の統一目標として、各機能部門を横串した新しい作業とコラボレーションのやり方を意味します。

運用面での成熟は、いくつかの新しい ツール を実装したからといって一晩で起こるものではありません。核となるのは、より良いソフトウェアを提供するためみんながコミュニケーションのサイロを壊せるよう一丸となって文化を変える努力です。個別にツールがあるだけでは十分ではありませんが、スピードと精度を向上させ、コラボレーションを促進するようなオートメーションを適用すれば、ツールが大きな利益をもたらすようになります。

環境に合ったDevOpsツールは、チームの規模やニーズに応じて大きく異なる場合があります。あなたのツールチェーンを構築する方法には正解はありません。現実に、まず私たちが学び、模倣しようとしたいくつかの最良のワークフローやツールはNetflix、Etsy、Dropboxなどの革新的なチームが社内に構築したものだということを告白しておきましょう。

このリストの目的は、ソフトウェア配信ライフサイクルの各段階で最も人気のあるツールをいくつか共有することです。その一部は社内でも使っています。自分のチームのために適切なツールを評価する際にご参考になることを願っています。

計画

何をどうビルドするのか

リリースのすべての単一の依存関係と作業を計画しておくというウォーターフォール型のアプローチはDevOpsに反します。代わりに、アジャイルアプローチでは、ソフトウェアを小さな塊で構築してテストし、顧客のフィードバックを反復することで、リスクを減らし、可視性を向上させることができます。それが私たちを含む多くのチームが約2〜4週間のスプリントでの私たちがリリースを繰り返している理由です。

チームが各スプリントの開始時にアイデアや計画を共有しているので、以前のスプリントの反省からのフィードバックを考慮に入れてチームとサービスが継続的に改善されるようにします。ツールは学習やアイデアを計画に集中させるのに役立ちます。ブレーンストーミングプロセスを開始する際は、顧客リサーチデータ、機能要求、およびバグレポートをそれぞれ対象となる個人を特定し、その人にマップできます。このプロセスでは、物理的またはデジタルの付箋を使用して、共通のテーマをまとめてグループ化し、バックログのユーザーストーリーを構築しやすくします。ユーザーストーリーを特定のペルソナにマッピングすることで、提供される顧客価値に重点を置くことができます。アイデア段階の後、プロジェクトのバーンダウンと毎日のスプリントの進行状況を追跡するツール内のタスクを整理し、優先順位を付けます。

私たちが使っているツール：Active Collab、Pivo​​tal Tracker、VersionOne、Jira、Trello、StoriesOnBoardなど。

コード

いくつかのコードを書いた後に、ステージングに入る前に済ませる必要があることがいくつかあります。 コードをレビューして承認し、バージョンコントロールリポジトリのマスターブランチにマージし、必要に応じてローカルテストを実行します。

トップツール：Github、Bitbucket、Gerrit、GitLab

テストとビルド

今度はコードのビルド、テスト、およびリリースに関連するタスクの実行を自動化する時です。 ビルドが展開される前に、単体テスト、統合テスト、機能テスト、受入れテストなど、生産過程に完璧に押し込めることを確認するために、多数のテストを行う必要があります。 テストは、新しい変更が導入されたときに、コードベースの既存の部分が期待どおり確実に機能し続けるようにするための素晴らしい方法です。 新しいプルリクエストがあるときには自動的にテストを実行することが重要です。 これにより、手動による監視のために見落とされるエラーを最小限に抑え、信頼性の高いテストを実行するコストを削減し、早期にバグを面に出せます。

また、テストが完了したら、マスターの変更を自動的にピックアップし、依存関係のあるものをリポジトリからプルダウンして新しいパッケージを構築するなど、便利な機能を果たす多数の優れたオープンソースツールと有償ツールもあります。

トップツール：Jenkins、GoCD、Maven、CruiseControl、TravisCI、CircleCI

コンテナとスケジューラ

Dockerとコンテナの登場により、チームは新しい仮想化オペレーティングシステムをスピンアップすることなく、軽量で一貫した使い捨てのステージング＆開発環境を簡単にプロビジョニングできます。

コンテナは、アプリケーションをパッケージ化する方法を標準化し、記憶容量と柔軟性を向上させ、変更をより簡単にすることを容易にします。 これにより、アプリケーションをどこでも実行することができます。 言い換えれば、物事は、あなたがラップトップで変更を加えたときとまったく同じように、魔法のようにプロダクションで行動します。

トップツール：Docker、Kubernetes、Mesos、Nomad

構成管理

構成管理を使用すると、インフラストラクチャの変更を追跡し、システム構成の単一ソースを維持できます。 バージョン管理とイメージの複製を簡単に実行できるツール、つまりシステム、クラウドインスタンス、コンテナなどのスナップショットを撮ることができるツールを探してください。 ここでの目標は、標準化された環境と一貫した製品パフォーマンスを保証することです。 構成管理は、変更に起因する問題の識別にも役立ち、さらに容量が必要な場合に既存のサーバーを自動的に再現することでオートスケーリングをシンプルにします。

トップツール：Chef、Ansible、Puppet、SaltStack

リリース リリースの自動化

リリース自動化ツールを使用すると、本番環境に自動的にデプロイできます。 自動ロールバック、展開を開始する前にホストに成果物をコピーする機能などを備えた製品を選ぶべきであり、特に大規模な組織の場合は、サーバーインスタンスのスケールに合わせて、エージェントを簡単にインストールし、ファイアウォールを簡単に構成できるエージェントレスアーキテクチャが必要です。

テストに合格したものは、自動的にデプロイされることに注意してください。 ベストプラクティスは、最初に「カナリヤ」デプロイメントとしてインフラのサブセットに展開してみて、エラーが起きなければ全体に展開することです。

多くのチームでは、ボットを使って簡単なコマンドでデプロイするチャットベースのデプロイメントワークフローも使っているため、誰もが簡単にデプロイメントの活動を見たり、一緒に学習することができます。

トップツール：Bamboo、Puppet

デプロイメントを監視する

リリース用のダッシュボードとモニタをセットアップすると、リリースの進捗状況と要件のステータスをハイレベルで視覚化するのに役立ちます。 サービスが健全かどうか、導入前、導入中、導入後に異常があるかどうかを理解することも重要です。継続稼働している統合サーバー上で発生する重要なイベント、例えば失敗したビルドがあるとか、デプロイメントを中止またはロールバックするといった重要なイベントがリアルタイムで通知されること確認しておくことです。

トップツール：Datadog、Elastic Stack、PagerDuty

モニター サーバーの監視

サーバーの監視では、インフラストラクチャレベルのビューが提供されます。 多くのチームでは、ログの統合機能を使い特定の問題をドリルダウンしています。 このタイプの監視をすると、メトリック（メモリ、CPU、システム負荷の平均など）を統合でき、サーバーの健康状態を常に把握でき、アプリケーションが影響を受ける前に（そしてお客様がそれに気がつく前に）に問題に対処できるようになります。

トップツール：Datadog、AWS Cloudwatch、Splunk、Nagios、Pingdom、Solarwinds、Sensu

アプリケーションパフォーマンスの監視

アプリケーションパフォーマンスの監視では、Webサイトなどのアプリケーションやビジネスサービスのパフォーマンスと可用性をコードレベルで把握できます。 これにより、パフォーマンスメトリックを迅速に理解し、サービスSLAを満たすことが容易になります。

トップツール：New Relic、Dynatrace、AppDynamics

対応と学習 インシデント解決

監視ツールは豊富なデータを提供しますが、リアルタイムで問題に対して正しい行動をとることができる適切な人物にルーティングされないならそのデータは無駄になります。ダウンタイムを最小限に抑えるには、問題が検出されたときに適切な情報が通知され、トリアージおよび優先順位付けに関する明確なプロセスが確立されていることが大事で、それらによってようやく効率的なコラボレーションと解決が可能になります。

1分に数千ドルのコストがかかるようなアプリケーションとパフォーマンスの問題が起きた場合、適切な対応を調整することはしばしば非常にストレスですが、混乱することはありません。火事の最中に、連絡先の住所録を取り出して、コンファレンスブリッジに適切な人を選ぶ方法を探すのに30分も無駄にするのは望ましくありません。

PagerDutyはエンドツーエンドのインシデント対応プロセスを自動化して、主要な顧客に影響を与えるインシデントや日々の運用上の問題の解決にかける時間を削減できます。 PagerDuty社内では、エンジニアリングチーム、サポートチーム、セキュリティチーム、エグゼクティブなどみんなが、自社製品を使い、ITやビジネスの中断への対応策を調整して準備しています。柔軟性を持って私たちはオンコールのリソースを管理したり、実行不可能なものを止めたり、関連するコンテキストを統合したり、適切な人やビジネスのステークホルダーを動員したり、自社が推奨するツールと協働で対応にしたりしています。自分が戦闘中に何をどうに見たいかを簡単に設計できるとしたら、あなたももっと安心できるでしょう。

私たちが使っているツール：PagerDuty、HipChat、Slack、Conferencing tools

学び、改善する

対応が終われば、インシデントはプロセスとシステムをより弾力性を持って改善する方法を理解する重要な学習機会を提供します。 DevOpssのCAMS（文化、オートメーション、測定、共有の頭文字）の支えによって、インシデント対応とシステム性能のメトリクスを理解し、継続的な改善の目標に向けて、成功と失敗を共有するオープンな対話を促進することが重要です。

ポストモーティム（事後検証）の手順を合理化でき、解決すべき事項に関するアクション項目の優先順位付けを目的にポストモーティム分析を実行できるソリューションを探してください。あなたはきっと製品の使用状況や顧客からのフィードバックを理解するのに役立つツールを使い、ビジネス目標と顧客経験のメトリクスに関連するサービスがどのくらい成功しているか測定したいと思うでしょう。より良い製品とより幸せな顧客のために、システムと機能の両方の改善を正確に計画して優先順位を付けられるよう、すべてが次のスプリントに組み込まれるのです。

私たちが使っているツール：PagerDuty、Looker、Pendo、SurveyMonkey

繰り返しますが、ツールに投資するだけでは、モノリシックアーキテクチャーからマイクロサービスアーキテクチャに移行することはできません。また、セルフサービスのデプロイメントを1日に何回も実行できるチームは幻のままになります。 しかし、適切なツールとプロセスで新しい文化へのシフトを強化することで、ソフトウェア配信を最適化し、継続的に改善し、それを担当するすべての人の間でシームレスなコラボレーションと信頼を実現することができます。

以上を参考に、あなたのための適切なツールを探究し、見つけることに成功してほしいです！全員参加の機運を最大限に高めるために社内で使用すべきツールや、DevOpsのベストプラクティスを加速する方法について詳しく知りたい場合は、これらのリソースをご覧ください。

「カオスエンジニアリング とは、本番環境の分散システム が混乱状態にさらされても耐え抜く能力を実証する実験」―カオスエンジニアリングの原則

Netflix、Dropbox、およびTwilioは、カオスエンジニアリングを実行している企業です。彼らには自社の大規模で堅牢な分散システムに自信を持つことが不可欠です。PagerDutyでは、数年間、本番環境にフォルトインジェクション（一部のサーバ、サービスを落としたり負荷をかけるなどしてシステム全体の堅牢性を確認する手法）を行ってきました。時が経つに連れインフラが成長し、私たちのカオスエンジニアリングの技術も進化しました。最近追加されたものの1つに、ChaosCatと呼ばれる自動フォルトインジェクタがあります。

バックグラウンド

当初、PagerDutyのSRE（Site Reliability Engineering）チームは、SSHを使用して各ホストでコマンドを実行するという、手動のフォルトインジェクションを行っていました。これにより、障害を正確に管理し、発生した問題をすばやく調査し、ツールへの大きな先行投資を避けることができました。これはしばらくの間うまくいっており、高ネットワーク遅延、高CPU使用率、ホストの再起動など、反復可能なカオス攻撃のライブラリを構築することができました。

私たちは手作業で行っていてはスケールしないと分かっていたので、時間の経過とともにプロセスの一部を自動化し始めました。まず、個々のコマンドはスクリプトに変換され、SSHの代わりにホストで自動的に実行するようにしました。それぞれのチームがPagerDutyで独自のサービスを開始した後にこのツールを使用することで、SREチームを必要とせずにフォルトインジェクションができるようになりました。

しかし早い段階で、各サービスの責任者が既知の障害を起こすプロセス作ることにしました。これは、毎週金曜日に責任者が何を調査すべきかを少なくともいくらかは認識していることを意味していました。それは、彼らが問題を解決するためのスタートでした。

現実の世界では障害の予兆が出ることはめったにないため、任意のホストでランダムに攻撃のサブセットを実行できるようにすることで、システムに偶然の要素を導入したいと考えていました。そのため、ツールを追加してランダムにホストを選択し、それらに対してカオス攻撃を実行しました。パズルの最後のピースは、すべて自動化されたスケジュールにまとめられていました。

実装

ChaosCatはScalaベースのSlackチャットボットです。分散型タスク実行エンジンなど、我々のインフラのいくつかの別コンポーネントの上に構築されています。Chaos Monkey（Netflixが開発、利用しているオープンソースのフォルトインジェクタ）の影響を強く受けていますが、我々のインフラにはさまざまなサービスタイプが存在するため、サービス実装には依存しない設計になっています。

ChaosCatは常時稼動のサービスとして動作しています。これは、許可されたチームがいつでも使用できることを意味します （「@chaoscat run-once」で実行） 。サービスがアイドルの間はスケジュールが1分ごとにチェックされ、オンコールエンジニアがいることが確実な営業時間中にランダムに障害を発生させます。

営業時間になったら、システムステータスがすべてクリアかどうかをチェックします。サービスの健康状態が100％でない場合には障害を発生させないためです。

次にインフラ内の無作為に抽出されたホストに対してランダムに選択されたカオス攻撃（異なる選択確率を持つ異なるアタック）を発生させます。現実世界では例外なくすべてのホストが同様に脆弱だからです。社内のジョブランナーを使用して、Blender実行フレームワークを介してカオス攻撃を実行するタスクを送信します。

10分待ってから、スケジュールされた営業時間の間に、2つ目と3つ目のステップを繰り返し実行します。問題が発生した場合、誰でも「@chaoscat stop」を送信することによって攻撃を停止することができます。

学習

いくつかのチームは、こうしてダッシュボードとログの準備が整った状態で座っている時と、モーニングコーヒーを飲んでいる間にトラブルが生じた時とでは何か違いがあることをすぐに知りました。これらのチームは、ランニングブックとオンコールローテーションのギャップを特定し修正しました。大成功！

もう1つの興味深いことは、チームが最初の苦労を乗り越えた後、以前に手作業で行われた修正を自動化し、バックログに不具合の優先順位付けしたことです。その結果、このチームはサービスの信頼性に自信を持ちました。

残念ながら、ChaosCatは社内のインフラストラクチャツールに大きく依存しており、現時点では、オープンソースではありません。しかし、私たちはあなたのフィードバックと質問をお待ちしています。

このような信頼性のためのエンジニアリング―カオスエンジニアリングを開始する企業が増えることを期待しています。それは複雑さと多様性が増すインフラの堅牢性と動作を検証するうえで素晴らしい方法です。

予防は最高の薬です

分散システムを構築する最善の方法は、 分散を避けることです。その理由は簡単で、分散コンピューティングの欠陥を迂回することができます（一部の楽観主義者の考えとは異なり、分散コンピューティングの欠陥はまだ残っています）。

私の個人用のラップトップにはSignalFXのステッカーが はってあります。これは、さまざまなトランスポートメカニズムの速度のリストです。そもそもこのステッカーは、特にデータセンター間を移動するときに、複数のディスクやネットワークを使うのを避けるようにと言っています。それに従い、機械的な共感を抱くならば、単一ノード上で毎秒何百万件ものトランザクションを実行できる取引プラットフォームをサポートできる、LMAXのように市場を破壊するような素晴らしいものを構築することができます。メモリや単一のマシン上で処理させるようにするとさらに多くの処理ができます。おそらく15秒分の作業をやり直しても問題ない場合は、メモリ内ですべての作業を行い、1分に4回チェックポイントをディスクに書き出すだけです。そのようなシステムは非常に高速に動作し、完全にスケールアウトするという問題を回避できます。

自分自身をだますことはできません – 分散システムは常に複雑さを増し、生産性を低下させます。もし誰かが別のことを言うのなら、その連中はおそらくいんちきなものを売っているのでしょう。

なぜそうしているのかを調べ、前提をすべて問い直してください

「高可用性」と呼ばれる要件のせいで、すべてのコードを1つのノードに置くことが不可能になります。この要件は、しばしば、複数のシステムが引き込まれるまで非常に高価なステップを引き起こします。ここでは、2つの要件、チャレンジの仮定とチャレンジの要件があります。この特定のシステムには本当にファイブナイン（訳注：99.999%）の可用性が必要ですか、それとももっと 緩い可用性を与えるレイヤーに移行できますか？特にあなたのソフトウェアがそれ自体を証明する必要や、HA（高可用性）やその他の鐘や笛を鳴らす必要があるのならば、成熟度の低い最適化を施してしまう可能性があります。そうではなく、今すぐにスキップして、市場投入を早め、後で追加する戦略を立ててください。ビジネスのステークホルダーが「はい」と言うなら、「HA」にする必要がありますが、トレードオフと、時間とお金を使う実際には使えないものに時間とお金を費やすことになるかもしてないことを相手が知っていることを確認する必要があります（顧客がその製品や機能を気に入らないようになるという結果も考えられます。顧客が好きになることを知っている製品や機能だけを作ってればリスクはなく、あなたが始めたベンチャーは退屈な雲の上に止まってしまいますが）。

CAPの定理を説明すると利害関係者に、可用性や一貫性を持たせられるということは言えますが、両立は無理です（もう一度言っておくと、楽観主義者の中にはそれは問題ないという人がいますが、間違っていると思います）。 たとえば、通知を送るシステムを構築した場合、たいていは、一貫して通知を送るシステム（一貫性がありますが可用性の低い通知）とか、ほとんど常に通知を送理続けるシステム（可用性はある一貫性が低い）を作ることはできます。 通常、最終的に一貫性のある（AP）システムは、調整が少なくてすむため、構築が楽で、拡張と操作が簡単です。可用性の要件を取り除けるかどうかを検討してみてください。 普通は、APソリューションで問題解決を図ることを検討することは価値がありますので。

忘れないで – 何かを避けられないなら、少なくとも単純にする方向で交渉してください。 複雑な分散システムを実装しないことが、分散システムを構築する最善の方法です。

人生をシンプルにする

複雑さは我々の商売の敵なので、どんなコードを書いていても、どのようなシステムを設計していても、この「複雑さが膨れ上がったらハンマーで叩き潰す」というモグラ叩きゲームをプレーする必要があります。 複数のシステムにまたがるソフトウェアを書いたらすぐにこれはさらに大事になります。分散システムは本質的に複雑なので、偶発的に複雑さが増すことには我慢しないようにしてください。分散システムの中には、他のものより実装が簡単なものがいくつかあります。単純なものに固執し続けることです。

HA用に配布する

可用性を向上させるにはいくつかの方法があります。ノードのクラスタを作り、すべてを調整できます（作業状態を常に保存しておくと、どのノードでもなんでも拾えるようになります）が、それには多くの調整が必要です。 調整はシステムを壊れやすくするので、おそらく維持できないのではないでしょうか。 コーディネーションを避けるためのさまざまな選択肢があり、依然として優れた可用性を保てます。

同じ作業を複数のシステムで並行処理させ、1つのシステムの出力のみを使うこと。 すべてがセカンダリノードにレプリケートされるため、プライマリノードに障害が発生すると、レプリケーションによってバックアップノードが確実に「ホット」になり、瞬間的に引き継ぐことができます。調整が必要なのは最初にどのノードを実行し、どのノードを2次バックアップにするかを決めることだけです。 予備の待機系を持つこと。 プライマリノードは定期的に共有ストレージ上で作業を継続し、作業が停止すると、セカンダリがそれを読み込んで引き継ぎます。 ここでの調整は、通常、テイクオーバーが必要かどうかを知るために、常にセカンダリがプライマリを監視するようにしておくことです。

どちらの場合も、調整の単位は「トランザクションごと」から「構成ごと」に移行します。分散した作業トランザクションの扱いは難しいので、構成レベルの調整を取り除くことができれば、そうしてください。しばしば、これにはいくつかの作業が含まれます。「正確に1つ」の作業プロセスは、マシンが死ななければ「ほとんど正確に１つ」のプロセスになり、何も見逃さなかったことを確実にするためには最後の1分まで再生してみる必要があります。場合によっては、重複したオペレーションが表示されるのを避けることはできませんし、要件に関してステークホルダーとチャットする必要があります。正直なリスクアセスメント（1年に何回くらいそのマシン群は死ぬのか）と、正直なインパクトアセスメント（どのくらい各要素が重複する作業をしたのかと、ユーザーにどのくらい不便を感じさせたのか）と正直な難易度アセスメント（ぜい弱性を生じさせ、これにより可用性が低下するような余分な作業と複雑さがどれくらい増えたか）を実施しましょう。

場合によっては、データセンターに障害が発生した場合にも可用性が必要になることがあります。そのような場合には注意が必要です。システムが脆く、早くなりすぎるので、最小限の調整で済むようにしたいと考えるようになるでしょう。

パフォーマンスのために分散させる

一つのノードだけですべての作業を完了させることはできない場合もあります。まず、そんなポジションをとらないようにしてください。目をしっかり開いて、サイクルを無駄に使っているところを探してください。LMAXの人々は、1台のマシンで1秒あたり7桁のトランザクションを実行できることを示しました。より大きなインスタンスが必要ならAmazonを使うべきでしょう。私はまともなソフトウェアとは、より速いハードウェアを手に入れれば迅速に修正できるようなマルチコア対応のものだと、今のところは思っています。より多くのコアでより速く実行できるようにコードを書けない場合は、たぶんノードを追加しても高速化は期待できないのではないでしょうか？ LMAXレベルのエンジニアリングがなくても、少なくとも1秒あたり5桁のビジネスオペレーションをソフトウェアが処理できると問題を解決するためにマシンを追加する必要がある場合（これは大きな問題です）、調整が最小限になるように計画してください。

想定してよいと思います。 1ノードでは1秒間に数百個も処理できないのでスケールアウトしたい、というのなら、最初の設計をしたボードに戻ってください。おそらく、あなたのコードには対処が必要な別の問題があるのです。

問題を解決するためにマシンを追加する必要がある場合（これは大きな問題です）、調整が最小限になるように計画してください。

トランザクションの調整ではなく構成の調整をする。さらなる協調の必要なしに各ノードがそれ自身のチャンクをプロセスに実行させるための調整スキームをノードに使わせます。あるノードが使えなくなったときに各ノードが再配布できるようにすれば、HAを非常に簡単に追加できます。 どんな調整も全く必要としないように、並行できる作業を見つけること。 ステートレスなWebサーバーが良い例としてここに挙げられますが、調整されていないノードの束を投入できるのはそこだけに限りません。

ストレージは安いのだから活用しよう

コマンド/クエリ分離やイベントソーシングなどのアーキテクチャパターンは、データストレージを複数の特殊なステージにデカップリングし、複製することがよくあります。これらの特殊なステージは、分散設計をサポートするためにはうまくいきます。ローカルに保存するものと分散するものを選択できるため、調整を最小限に抑えるハイブリッドソリューションになるからです。たとえば、アップデートコマンドを分散Kafkaクラスタに書き込むことはできますが、そこからの下流のすべてはローカルで操作できます（たとえば、コンシューマがアップデートコマンドを処理し、クエリに使用されるElasticSearchノードを個別に更新します）。 「実際の」データは、利用可能性が高く、メッセージストリームで調整されます。システムは、検索、分析などの特殊な処理のためにそのデータのビューを使用します。このようなシステムは、中央のデータベースシステムがすべての操作のネクサスであり、必然的にボトルネックになる古典的な構成（データベースシステムがスケーラビリティのために構築されたものであろうとなかろうと）よりも簡単に維持できます。

データを冗長に保存し、複数の独立したシステムがそれぞれ独自の最適化された形式のデータを使用するようにしてください。そうすれば調整の必要性が低くなり、最終的にはストレージコストは比較的小さな増加で済むようになります。

NIH症候群を避ける-車輪はすでに他の場所で再発明されている

Googleのスケールでシステムを運用するのでない限り、分散型であなたが実装しようと取り組んでいるシステムは、一から自分で構築する必要があるほど特別なものではないはずです。あなたが投資をしているのはビジネス上の問題を解決するためであって、ツールやインフラストラクチャを構築するためではないでしょうから、2017年の今、自分のための特別な何かを探す理由はないのです。分散システムを正しく実装するのは難しいので、失敗する可能性が高いのです（パーシステンスと暗号化についても同じアドバイスができます）。独自の問題を抱えていて自分自身で何かを発明する必要があると思っている場合は、実はちゃんとじっくり世間を見ていないか、何百ものオープンソースプロジェクトのどれかが使える形に、自分の問題を定義し直す努力をしていない可能性があります。あなたは「ビジネス」を推進しており、分散ソリューションをずっと簡単に、したがって信頼性を高める形で要件の形を変えるのを助けています。あなたが抱えている問題の、ユニークではない部分を解決するための、正しいソフトウェアを見つけましょう。そうすればあなたは自分の会社を特別なものにすることに集中できるようになります。

そう、ツールを作ること（tool-smithing）は楽しい – 私も大好きで、一日中やっていても飽きません。そして、確かに、独特の雪のかけらみたいに見えるような形であなたの問題をフレーミングすることは、自尊心のためには良いことです。でもそれは辞めて、ビジネスを成功に導くために本当の問題を解決してください。

DevOpsを知った時期によって、DevOpsの実装方法に関する認識は変わります。DevOpsはまず文化のみの動きとして始まり、成熟するにつれてますます戦術的になりました。

文化がDevOps環境の中心にあります。 多くの場合、文化はDevOpsにとって最も難しい部分です。また、DevOpsの文化を構築するための万能薬はありませんが、私が以下で説明するように、働いている組織の種類に無関係に、健全な文化を定着させるのに役立ついくつかのテクニックがあります。

なぜ文化が大事？

文化という言葉はお嫌いかもしれませんし、大好きかもしれませんが、それは問題ではありません。文化に関してそういうことは環境に関係なく常にあるものだからです。 文化が意識されていない開発環境では、それ自体が有機的に作成されますが、これは通常、あまり望ましくないシナリオになります。 それは独裁国家（fiefdoms）の文化、あるいはすべてが壊れやすく、すべての新機能はそれが書かれる前でさえ失敗とみなされる、恐怖の文化かも知れません。。

だから、どんな場合でも文化があります。 DevOpsの原則が作ろうとしているのは、意図的に作られた文化です。組織は、その目的を最もよく支える文化を事前に決定し、その枠組みを確立し、向上させ、維持するために必要なことを行います。

DevOpsの文化が悪い印象を持たれているのは、それはしばしばヒップスターやスタートアップに関連する言葉だからです。 しかし、これは正確ではありません。その文化の要素のいくらかはスタートアップのロビーに属するように見えますが、DevOpsを意図的に文化として広げようとする触媒はボトルネックを避けられるかもという希望でした。あらゆる種類のプロセスとツールを採用してより速く開発を進められるはずですが、意思決定に加わっていないユーザーにより速度が制限されると、高品質でより頻繁で高速なリリースは実現できません。

文化の問題のもう一つの理由は、DevOpsは単なるプロセスやツールではないからです。 これは、DevOpsに対応しないスタティックな環境にデリバリーチェーンがならないようにすることを目的に、作られています。プロセスとツールだけで開発運用を「実装する」場合、2年後にはその環境はウォーターフォールのようなルック＆フィールになり、現在の開発の標準に追いつけなくなります。

文化を快適にする

適切な文化を醸成することは、組織が、「より良いソフトウェアの品質とスピードを促進する文化をサポートし成長させる必要がある」と認めているほど簡単です。、いくつかの明確な目標を持ちどう行うべきかを意識し始めると、すべてのチームメンバーにとってその文化が最優先事項になります。 彼らは新しいツールを採用する際に、ツールがどのようにモジュール化でき、スクリプト化できるかを考えます。 あるいは、他のチームメンバーとのコミュニケーションについて考えるとき、彼らは簡潔に結果が得られることに重点を置くでしょう。チームがポジティブな文化を築くためにできることは、組織がより良いコードの文化に専念していることを明確にすることに加えて、他にもいくつかあります。

管理責任を持つこと(独裁ではなく)。 あなたが欲しい、または必要とする文化は、トップダウンでの導入を必要とします。でもそれは指示されるべきではありません。文化を支えるために、チームメンバー（リーダーシップとエグゼクティブの両方を含む）は、人々にどのように行動すべきかを伝えるのではなく、文化を積極的に実践してメリットを見せる必要があります。 あなたは誰かにチームプレーヤーであることを伝えることはできません。チームプレーヤーであるという利点を示す必要があります。 しかし、これは、誰かがその環境内に収まらない場合、彼らが歩き回っても良いようにするか、組織から去らせることで収拾する必要があることを意味します。 成功を分かち合うこと。 チームがそのメリットを理解するためには、リリース頻度の増加、欠陥の減少、人間の関与を必要としないタスクやリリースが増えるといった成功を共有する必要があります。チームの全員がより効率的な環境のメリットを享受できるわけではないので、そのメリット（革新的なビジネスの差別化要因の企画や繰り返しの少ないタスク、バーンアウトの削減などに専念する時間）を、常にチーム全体で話し合う必要があります。 チームを小さくする**。 強い文化を維持するには、より小さくて緊密なチームに保つことです。 これは階層の問題であり、リーダーシップは絶対に関与する必要があります。 アマゾンのようなハイテク企業の指針は、すべてのチームが「ピザ2枚で足りる」少人数のチームでなければならないということです。すべてのメンバーがチームへの貢献度を明確に把握し、作業の可視性を確認する必要があります。 これは、各チームが協力して文化を維持し、直接的な説明責任を持つようにするのに役立ちます。 目的をシェアする**。 組織がしばしば間違っている点は、競合する目標を設定することです。 チームメンバーが常にある測定方法で評価されながら作業するので、例えば開発者が発表した新機能の数で評価されているのに、運用チームは物事が中断しないことを基準に評価されている場合、これらの2つは直接衝突します。変化はOpsの心のリスクと等しいので、新しいものに対してサポートするのではなく、それをリリースをさせないように動機づけられるからです。経営陣は、同じ目標を達成するためには、全員を同じ基準で評価する必要があります。

階層やKPIのようなものは、常にあなたが制御できるとは限りません。もちろん開発者でもボトムアップで、共通の文化の価値を表現することができます。ある時点では、組織と管理者はその光を見る必要があります。 良いことは、すべての企業がある程度の能力を備えたハイテク企業になるにつれて、以前より高い品質なアプリケーションリリースを頻繁にサポートすることを支援する必要性は収益に影響します。 経営陣は数字以外を聞くことはありません。

文化をOKにする

文化はとても主観的なので、効率の環境を維持する原則とは対照的に、DevOpsの戦術にフォーカスするほうが簡単です。 文化エンジンを地面から降ろすのは難しいですが、良いニュースは、いったんそれが始まると非常に自立しているということです。 文化の鐘を鳴らすことは難しいです。これは、あなたがそれを作成することを熟考したとしても当てはまります。

上記のフレームワークとともに、ボールを投げて、結果が出るまで耐える自信を持つことが、成功への鍵です。 DevOps文化を受け入れる組織は、ソフトウェア配信をよりシームレスにして、最先端の開発の実践をより成功させるでしょう。

インシデントを経験した後 のポストモーティム（事後検証。post-mortem またはpostmortem と表記される）に 何をします？ 簡単な質問のように見えるかもしれません。 結局のところ、インシデントの処理の最後のステップとして事後検証を考えるのは簡単です。

しかし、そうではありません。 多くの点でインシデントのポストモーティムで何を検証するかは、ポストモーティムをすることと同じくらい大事なんです。以下、理由を説明し、事後検証が終わったあとに何をするべきか、そのヒントを提供します。

なぜポストモーティムするの？

しかし、この質問の意味を考える前に、より根本的な質問、つまりポストモーティムの機能とは何か、そしてそれには何を含めるべきかを検討する必要があります。

ポストモーティムは基本的に以下の役割を果たします:

インシデントとその原因および関連する兆候、解決策、将来の参考になる影響の記録を提供する。技術的問題を将来理解するためと、事件から生じる法的または行政上の懸念の解決の両方にとって重要になり得る。 事件を引き起こした基本的な技術的問題を分析し解決するための基礎として役立ちます。 インシデント対応プロセスを理解し改善するためのフレームワークを提供します 。

これらの基本的な役割をサポートするために、ポストモーティムにはインシデント、対応、解決の記録が含まれていなければなりません。 また、インシデントの根本原因の分析 、インシデントの範囲とその影響の説明、根本的な問題の解決、対応プロセスの改善、および/または将来のインシデントの影響の最小化のために適切な推奨事項も含める必要があります。

理解したあとに、責めないこと

大事な注意点ですが、ポストモーティムを責任追及の手段にしてはいけませんし、企業や組織のポリシーに点を付ける手段にならないように注意してください。必要ならば、事後検証から責任追及を分離するためにインシデント関連の問題を議論するために別のプロセス（すなわち、部門内での非公式で司会を立てた議論）を設定してください。

一方ポストモーティムでは、インシデントを起こす背景になった可能性のある、または対応中に明らかになった、技術的または組織的問題についての正直な議論が含まれるべきです。 技術や反応プロセスの改善に重点を置くべきであり、個人やチーム、あるいはその仕事の欠陥に置くべきではありません。

ポストモーティムはいつ必要?

すべてのインシデントでポストモーティムをする必要はありません。 軽度の運用上の問題や、よく原因が分かっており簡単な解決策があるインシデント、そしてダウンタイムやデータの消失が起きなかったインシデントには、ポストモーティムが必要ない場合があります。

ポストモーティムが必要な状況の例をいくつか示します。

データや生産性の低下、または顧客のアクセスにつながるインシデント シャットダウン、再ルーティング、以前のソフトウェアバージョンへのロールバック、および/または解決のための長期のアクションが必要だったインシデント 適切な監視やアラートシステムがあったのにうまく検出または処理されなかったインシデント 根本原因が不明、あるいは予想を超えていた、または今後も発生が疑われるインシデント システムの動作に広範囲の影響を及ぼす可能性のある、アプリケーションアーキテクチャや技術の根本を含むように見えるインシデント 回答や解決プロセスに深刻な問題や不備があったインシデント

ポストモーティムは学習を容易にする

ポストモーティムを価値あるものにするにはその書き方を、長期的な問題の分析、解決、防止を担当する人々が読みやすくかつ理解しやすくする必要があります。

これは、例えば、問題やその解決を抱えているチームや部署は、ポストモーティムの記録を読むことを読み、さらに結果として適切な次のステップを決定するために、できるだけ早く議論に参加することを要求されているからです。 どうポストモーティムの資料を流通させて、それらを読んだあとの行動にどう導くかという実際のプロセスは、もちろん、あなたの組織の構造と経営理念に依存します。

ポストモーティムの基本要素

ポストモーティムを書いたり読んだりするときには、次の3つの重要な分野があります。

根本的な原因

ポストモーティムは必ず根本原因の説明を含むべきです。根本的な理由が既に分かっていても、ささいなことであっても。ささいな原因ではない場合は、問題の実際の根本原因を正確に特定し、それを修正する必要があるかどうかを、原因の分析に含める必要があります。 根本原因を正確に特定できない場合は、将来の特定につながる可能性のある情報を含める必要があります。

例えば、インシデントの解決の過程で、その問題が多量のレガシーコードを含むモジュールで生じたことが明らかになったけれども、そのモジュールよりも下の部分にある根本原因を特定できなかったという場合でも、その事実を根本原因の分析に含めることが重要です。インシデントと関連してレガシーコードを特定したという事実の記録は、インシデントの解決だけでなく、後の調査で置き換える必要のあるコードを特定することにおいても価値があります。

対応

ポストモーティムには、対応プロセスの完全な技術的説明が含まれていなければなりません。 また、そのプロセスの相対的に見た成功または失敗の説明と分析も含める必要があります。 これは誰の責任も問うことなく実施されなければなりませんが、対応プロセスまたはそのプロセスの実施中の明らかな失敗や弱点を明確に示すべきです。 これには、対応チームメンバー間の責任分担、対応チーム内の連絡、または対応チームと他のステークホルダーとの間のやり取り、特定の対応プロセスの問題が含まれます。

対応プロセスの失敗は、技術的または組織的なものに及ぶ可能性があります。インシデントの解決中にシステムやアプリケーションが利用できないことを、その影響を受ける部門やユーザーに伝えられなかったというような、簡単なことが含まれます。 2つのチームのメンバーが協調せずに同じタスクを実行してしまったり、誰も必要なタスクを実行しなかったために、結果として解決に時間がかかりすぎた場合は、ポストモーティムの中にはチーム構成やコミュニケーションの潜在的な問題を示す注記を入れておく必要があります。

被害の影響範囲の確認と制御

ポストモーティムには、データの損失、生産性の低下、ユーザーアクセスの中断など、インシデントによって引き起こされた損害の程度を明確かつ正確に記述する必要があります。 この被害を限定あるいは緩和するために取られた措置についての説明と分析を含めることも同様に重要です。 ダメージコントロールは、技術的なインシデント解決とは別のプロセスとして考慮する必要があります。 インシデントの種類、被害の種類、および組織の構造によっては、カスタマーサービスの責任である場合や、ビジネス内の他の部門のアクションアイテムが必要な場合があります。

ダメージコントロールは、似たようなインシデントを将来どう処理すべきかに直接または間接に影響する可能性があるため、ポストモーティムの一部に入れておく必要があります。 例えば停電により航空会社のフライト予約システムが停止した場合、そのダウンタイム中に予約を処理するための代替システムを導入することを優先する必要があるかもしれません。

恥と思わず、金と思え

ポストモーティムを最大限に活用するための鍵は、これがアプリケーション、インフラストラクチャ、および対応プロセスの改善のためのロードマップであることを理解することにあります。 各ポストモーティムは、システムの動作方法とインシデントの処理方法を改善する可能性があります。 ポストモーティムを恥とか何らかの失敗の徴候として扱うのではなく、これは将来の金になる貴重な機会だと考えるべきです。

PageDutyは、業界のベストプラクティスを共有し、ポストモーティムのテンプレートを含む完全に無料のポストモーティムハンドブックを提供します。 あなたのチームが問題にできるだけ簡単に対応できるように、自分のポストモーティムプロセスを正式化するのに役立ちます。 PureDutyプラットフォームの一部であるポストモーティムは、自動化されたタイムライン構築、コラボレーティブな編集、実用的な洞察など、 14日間の無償体験版にサインアップし、ポストモーティムのプロセス全体を合理化します。

多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる時間を確保できることなどが期待されているからです。しかし、DevOpsの採用は万能薬ではありません。その代わり、DevOpsモデルが奨励するコミュニケーション、コラボレーション、批判しない前提での振り返りの考え方は、問題を解決するだけでなく、プロセスを改善してボトルネックを解決し、より無駄のないシステムを構築するのに役立ちます。

DevOpsを実装する組織にとって最大の課題の1つは、ワークフロー内の既存の問題を特定して削除し、より新しく、よりアジャイルな方法論に道を開くことです。ガートナー社は、システムが目標達成に近づくのを妨げる不便さ、挫折、その他の制限要因を意味する制約を取り除き、真の意味でDevOpsの速度を向上させるために組織が取ることができる6つのステップを以下にまとめました。

ステップ1：プロセスを定義する

プロセスを再構築する際には、DevOpsチームは、初期の構想から最終的な顧客価値に至るまでのワークフローをデザインし、プロセスを定義する必要があります。既存のプロセス内のすべてのステップを文書化することにより、プロセス全体に積極的に貢献していない可能性のある制約領域をより簡単に見つけ出し、改善できます。さらに、サイクルタイム、おおよその時間間隔、ハンドオフ、待機状態など、より価値の高い流れを明確に把握できます。これがすべて整理されたら、チームは最大のプロセス制約を簡単に特定し、プロセス全体を改善するための手順を開始し、プロセス文書化の効果を高めることができます。

ステップ2：最大の制約を特定する

典型的なDevOpsのワークフローでは、アイデアから価値へのプロセスを遅らせる段階が常に存在します。体系的な改善を推進するために、チームは進行を妨げている特定のフェーズを特定し、制約の原因を取り除く必要があります。

最大の制約を特定するには、「誰もが常に何を待っているのか」を問います。これを尋ねることで、チームは効率を高めるために特別な注意が必要なことを特定できます。責任追求をしない建設的な環境でこれを行うと、チームメンバーは発言しやすくなります。最大の制約を特定したら、プロジェクトの進行状況を監視して、ブロック要因が正しく特定されていることを確認します。

ステップ3：制約条件下での無駄を取り除く

制約が特定された場合、最も一般的な行動方針は、より多くのリソース（人、お金、新しいシステムなど）を投入することです。ただし、役に立たない可能性があるリソースを追加するのではなく、無駄な可能性のあるリソースを排除することがより効果的です。

ガートナーによると、クライアントが特定した上位3つの無駄の発生源は次のとおりです。

インシデント:** 新しい製品や機能の開発などの付加価値活動を犠牲にして、インシデント管理に貴重な時間が費やされています。このためのベストプラクティスは、チームメンバーを相互訓練してインシデント管理に習熟することです。将来のインシデントを防止する1つの方法は、責任追求をしない事後検証を実施して、インシデントの根本原因を解明し、将来それを防止することです。 待機:** 人、外部組織、その他のリソースを待つことは、常に課題です。これは、多様なスキルと知識を備えた従業員をトレーニングや雇用して、並行して作業できるようにすることで軽減できます。これにより、他の人の対応を待っている間に、プロジェクトの目標や他の割り当てられた仕事を達成することができるようになります。 人のポテンシャル:** データベースの更新であれ、インシデントのエスカレーションであれ、多くのIT専門家は多くの時間をかけて手動で作業しています。組織はできる限り自動化することでより多くの価値を実現し、人々はより価値の高いタスクに集中できるようになります。

ステップ4：制約を無視しない

制約を無視して新たに発生した問題に集中すると、元の問題に対処できなかったため、作業が遅くなり、将来さらに問題が発生します。たとえば、鎖について考えてみましょう。鎖の中の最も弱い環が強化されていない場合、鎖はある時点でその場所で切れてしまいます。

制約を無視することで、チームは次のようなさまざまな課題を経験することになります。

ミスや欠陥の増加 チームの効率と生産性への悪影響 変化率の高い状況での費用のかかるやり直し

ステップ5：容量を追加する

上記の手順は、スループットを少なくとも30％向上させるのに役立ち、問題を評価する能力と時間を利害関係者に与えるので、迅速な解決策を選択するのではなく、最善の解決策を慎重に検討できます。チームは専門サービスの契約であろうと追加のスタッフの採用であろうと、キャパシティを増やすことができる他の方法を見つけるためにこの時間を取るべきです。

ステップ6：次の最大の制約を見つける

リリース速度を向上させることは簡単なことではなく、プロセスを継続的に改善する必要があります。例えば、あるチームが制約を取り除くことに成功したとしても、ワークフローの別の部分で別の制約が取って代わることがあります。時間が経つにつれて、チームは高い開発スピードを達成するために、プロセスとプラクティスを適応させる必要があります。最後に、顧客のニーズを確実に満たすためには、開発サイクルのデューデリジェンスを実施し、必要に応じて改善する必要があります。

ガートナーの完全なレポートをお読みになりたい方は、「制約を削除してDevOpsのリリース速度を向上させる6つのステップ」をご覧ください。

本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

シャドーイング（ 訓練のためインシデント対応を見学すること ）中のコールエンジニアは、医師の肩越しに開腹手術を見ているような感じがします。精密さとスピードが最優先事項であり、間違いは深刻な結果につながります。私はPagerDutyエンジニアリングチームのオンコールローテーションにシャドーオブザーバーとして1週間参加しました。

オンコール中、私は同じエスカレーションポリシーで、他のすべての人たちと同じように通知を受けました。エンジニアが緊急でセンシティブな状況に立ち向かうため、Slackで起こされると私も起こされます。私はストレスが人々を悪い状況に追い込むと予想しました。ところが、驚いたことにそれは完全に間違っていました。

コールは睡眠、食事、シンプルな文章は、何時間ものストレスを乗り切れるようにします。

思考、そしてほかの多くのものを中断するために鳴り響き、チャットチャンネルは一晩中炎上と対応を知らせるメッセージを流し続けました。オンコールの責任とストレスに押しつぶされそうなのに、エンジニアが見せる優しさ、助け合い、ユーモアに私は驚かされました。

励まし

シンプルな文章は、何時間ものストレスを乗り切れるようにします。

初日のシャドーイングの午後遅くに、私は最初の通知を受けました。私はSlackのチャンネルを見て、問題の調査が完了したのを知りました。チームは直ちに新しいマシンを停止し、再配置をしました。トリアージと診断の混乱の中で、そのオンコール担当者が私と同じく新人だと知りました。私たちはどちらもまだ1カ月足らずの新米でした。彼はこれまで一度も遭遇したことのない問題を修正していました。

夕方までに事態は回復しました。長い1日を終え、人々は家に帰って行きました。それでも、ベテランのエンジニアPがチームメイトKの応援に入っていました。

6:14 PM　（P）すべて終わった？

6:15 PM　（K）まだ、ホストを再起動してるところです。すべてがスムーズに進んでます

6:18 PM　（P） その調子だ！ 俺達はこいつのために半日つぶしたんだ

このような仲間の励ましは、プロジェクトに新しく加わった人、新人社員、新人エンジニアに自信をもたせます。シニアエンジニアからの励ましは経験の少ないエンジニアに質問する勇気を与えます。質問は新人がエキスパートになるための第一歩です。「その調子だ！」の一言は人々に力を与えます。

謙虚さと感謝

この初心者オンコールエンジニアは、その励ましにすぐ反応しました。彼は自分を助けてくれたシニアエンジニアに短い言葉で謙虚さと感謝を示しました。

6:21 PM　（P）本当にあなたとMがいなければダメになるところでした。勉強になりました

Kが彼を助けた別のチームメイトの名前を挙げたのが嬉しかったです。DevOpsのエンジニアリングチームは、チームメイトを高く評価しています。彼らが今開発しているソフトウェアが明日、地獄のオンコール嵐を起こさないため、互いに頼り合っています。誰も常にすべてのことを知ることはできません。彼らは常に互いから学び、お互いに助け合わなければなりません。

上の例では、謙虚さと自己嫌悪の間の細い境界線が見えました。エンジニアは「学ぶことがとても大事」と述べています。この態度は「こんなことは絶対自分ではやりません」や「私にはこんなこと全部分かるわけないでしょう」とは異なります。謙虚で感謝の気持ちがあれば、チームメート同士の信頼を築けます。自己嫌悪は迷いと不安を引き起こすでしょう。

軽薄さとたくさんのGIFファイル

オンコール待機中は（幸せなことに）退屈でもあります。オンコールに入る予定が分かっていることはストレスを軽減してくれますが、それでも常に不安があります。幸運なことに、インターネット上のGIFファイルは、ストレスに満ちたオンコールシフトをユーモアで支えてくれます。

PagerDutyはユーモアの文化とカスタムGIFに特別な情熱を持っています。3つのタイムゾーンと2つの異なる国に分かれているこの楽しくてちょっとおバカなチームを観察するのが私は大好きです。オンコールでない人々がいつも明るいことに気づきました。

どうすればオンコールをよりポジティブにすることができるか

あなたがオンコールでない場合でも、チームと共にあれ 応援しよう。特に新人を 挑戦やリスク、時間のかかることを肯定する 感謝をもってあなたに直接影響を与えてくれた人々に接する。チームが将来どのような強みを持つか理解するのに役立つ ひょうきんに振る舞う。皆笑うのが大好き

たくさんの問題解決と心労を経験しましたし、他人が週末や夜にもオンコール待機をするところも見ました。そのまっただ中で、チームメイトが示す小さなジェスチャーが、あなたが1人ではないことを思い出させてくれます。

空が落ちてくると思うような時は、互いに品性ある振る舞いをすることが助けてくれるでしょう。

新型コロナウイルス（COVID-19）の報告例が世界中で増加し続けていることから、多くの企業では、従業員の感染を最小限に抑える方法として、リモートワークへのシフトが進んでいます。しかし、多くの企業は現在、業務を完全なリモートワークに移行するためにはどうすればよいのか、悩んでいるのが現状です。

企業が急速に分散型組織への移行を考えようとしている中、インシデント対応のパターンを見ることで、数多くの教訓を得ることができます。

リモートワークへの移行

企業がますますリモートワークを採用するようになってきている中で、ITとエンジニアリング職はこの変化の先頭に立ってきました。

20年前は、エンジニアリングチームが物理的に同じ場所にいて、オンプレミスのサーバルームで本番アプリケーションを実行し、プライベートなイントラネットですべての作業を行うのが一般的でした。IT チームとエンジニアリングチームは現場にいて、運用チームがサーバールームにクラッシュカートを走らせるころ、開発チームとマネージャーは、インシデント対応のための作戦室である会議室に集まり始めていました。重大なインシデントが発生した場合、マネージャーがネクステル社の携帯電話を使って、その日外出していたエンジニアに無線で連絡を取り、トラブルシューティングを支援できるようにVPN接続を指示することもありました。

この10年間で、クラウド環境とアプリケーションを使用するようになったことで、世界中のどこからでも本番用アプリケーションにアクセスできるようになりました。今日では、これらのチームが分散して活動することが一般的になっています。その結果、ITとエンジニアリングチームは、リモートで作業する際の効果的な方法を開発する最前線に立っています。

オンサイトサーバ、イントラネット、物理的なインシデント対策室の時代は、多くの組織では一般的に、より近代的なソリューションに取って代わられてきています。これらのソリューションとワークフローがどのように組み合わされているかを検証することは、分散型ワークへのシフトをどのように行うべきか悩んでいる組織に役立つでしょう。

10年間のリアルタイム運用管理の教訓

PagerDutyは10年以上にわたり、何千もの組織がリアルタイムのオペレーションを管理するのを支援してきました。私たちの生活は、デジタルファーストの体験にますます接続されるようになり、世界は常にオンになっていることを意味します。顧客は完璧さを求めており、問題が発生したときの解決までの時間は、数時間ではなく、ほんの数秒しかありません。リアルタイムオペレーションを効果的に管理することは、1秒1秒が重要な時に、適切な人員が適切なタイミングで対応し、コミュニケーションを調整することです。これは、世界中のどこにいようとも、すべてのチームやチームメンバー、部門、リーダーがリアルタイムで起こっているアクションに関与し、情報を得て、連携することを確実にすることを意味します。

PagerDutyは、インシデント対応のリーダーとして広く認識されています。そこで私たちは、リモートチームのための効果的なコミュニケーションを管理する方法について、私たちが教えることができる教訓を見てみることから始めるのが当然のことだと考えました。PagerDutyでは、私たちのチームがどこにいても、リアルタイムの仕事を効果的に管理するために、私たち自身のプラットフォームだけでなく、他のいくつかのリモート生産性ツール（PagerDutyではSlackとZoomを使用しています）を利用して、発生したインシデントに対応しています。

大規模なインシデントが発生した場合、当社の社員はPagerDutyのプラットフォームを使用して、解決に向けて作業を進める際に必要に応じて、様々なチームにまたがって適切なその分野の専門家に連絡を取ることができるようにしています。物理的な作戦室は、ビデオ会議ブリッジ（必要に応じて、バックアップの電話回線があります）と、すべての重要なコミュニケーションをキャプチャする専用のチャットルームの組み合わせに置き換えられました。

リモートで仕事をする際には、いくつかのコミュニケーション方法が鍵となります。

インフォーマルなコミュニケーションチャネルは、フォーマルなコミュニケーションチャネルに置き換えるべきです 口頭での説明に頼るのではなく、知識を書き留めて記録すべきです 必要に応じて情報を制限するのではなく、内部で情報を共有しましょう

インシデントが発生した際には、その場しのぎの通信チャネルを持つのではなく、私たちのチームは、よく知られた明文化された通信チャネルを使用します。インシデントが発生し彼らの参加が要求されたとき、彼らはすでにどの通信チャネルに参加すべきかを知っているはずです。しかし、万が一に備えて、PagerDutyプラットフォームは、ワンクリックでそれらのチャネルに参加するためのリンクが埋め込まれた通知を送信します。

インシデントの管理は、速いペースで行われるストレスの多い仕事です。その作業を調整するために必要なコミュニケーションの多くは、ビデオ会議で口頭で行われます。しかし、知識を確実に書き留めて記録するために、すべてのインシデントコールには、重要な事実と取られたアクションを記録し、対処すべきフォローアップ項目を追跡することで、インシデント中の重要なイベントのタイムラインを作成する記録係が割り当てられています。当社のビデオ会議ソリューションでは、通話の自動テープ起こしを作成することができます。しかし、記録係によって作成されたメモは、発生した出来事を迅速に把握したい場合の参考資料として活用することができます。

記録係は、専用のチャットチャネルでタイムラインを記録します。そうすることで、他の対応者は（対応者として、またはオブザーバーとして）参加したときに、タイムラインを参照して見逃したことをすぐにキャッチアップすることができます。オブザーバーは、状況をよりよく理解したい場合は、専用のチャットチャネルやビデオ通話（聴取専用モード）に参加することをお勧めします。

インシデントが発生している間、当社のチームは通常、社内外の利害関係者に更新情報を送信し、最新のイベントを知らせます。内部の利害関係者には経営幹部、ビジネスオーナー、顧客対応チームなどが含まれ、外部の利害関係者には顧客が含まれます。これらの通知はPagerDutyプラットフォームによって管理されています。しかし、その通知を送信するまでの意思決定は、何を伝えるかの合意を含めて、記録係のタイムラインの一部として記録され、専用のチャットチャネルにも記録されます。

このように口頭でのコミュニケーションと記録されたコミュニケーションのバランスが取れているため、分散したチームが迅速に作業し、より広い組織に効果的にコミュニケーションを取ることができます。記録係のタイムラインを専用のチャットチャネルに記録することで、既存のPagerDutyとのインテグレーション機能を使用して、インシデント後のレビューに自動的に組み込むことができるようになります。

ここでは、インシデントの解決に至るまでの出来事を要約し、原因となった要因を特定し、将来的にこの種のインシデントを軽減するのに役立つであろう 合意された行動項目を文書化しています。これらの事後検証は社内で共有され、物理的な場所に関係なく、どのチームでもイベントをよりよく理解できるようになります。

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。