ベロシティの高いチームのためのインシデント管理
インシデントの事後分析の公開と非公開の違い
公開のインシデントの事後分析の説明を共有する適切なタイミングについて
ほとんどすべての IT インシデントが、組織内の 4 つの壁の内側に閉じ込められていた時期がありました。しかし現在、Web サービスとクラウド インフラストラクチャでは、そのようなことはほとんどありません。技術インシデントは真の「1 対多」の問題であり、チームによるインシデントへの対応、学習、コミュニケーションの方法に大きな変化をもたらします。
インシデントの事後分析を検討します (「インシデント後レビュー」または「PIR」とも呼ばれます)。
インシデントの事後分析では、インシデントの詳細について話し合うために、インシデントが起こった理由、その影響、それを緩和して解決するために取られた措置、そしてその再発を防止する方法を話し合います。
インシデントの事後分析は、2 つの異なる成果物に分けられます。インシデントが議論される会議と、その会議の成果として作成された対応する事後分析レポートです。
これらの 2 つの活動、つまり会議と報告は、多くの場合、人々が「事後分析」を参照するときに同じ意味で使用されます。この用語を使うとき、どちらか、または両方を言及しています。
パートナー、顧客、エンド ユーザーは、エクスペリエンスの向上のために何が起こったのか、どのようなステップを踏んだかを知りたい場合があります。インシデントの事後分析を一般公開された Web サイトで公開することは、すべてのケースで適切とまでは言えません。しかしながら、マーケティング チームまたは広報チームが表現の調整を支援して、閲覧者が有益な形で情報を入手できるようにしてサービスに対する信頼を高められます。
インシデントの事後分析をいつ行うか
Atlassian では、重大度 1 および 2 (「重大」) インシデントについて、常に内部事後分析を実施しています。軽微なインシデントの場合は、任意です。当社では、それが有用であろうあらゆる状況のために、事後分析プロセスを使用することを奨励しています。
誰が事後分析を完了するのか？
通常、インシデントの原因をなったサービスを提供するチームは、関連する事後分析を実施する責任があります。チームは事後分析の実施に関する説明責任を負う 1 人の人を指名して、課題が割り当てられます。「事後分析担当者」は、起案や承認から事後分析が公開されるまでのすべての指揮をとります。インフラストラクチャおよびプラットフォーム レベル インシデントは、多くの場合、会社の部門の垣根を越えて影響を及ぼすため、事後分析はより複雑で労力を要します。そのため、専任のプログラム マネージャーをインフラストラクチャまたはプラットフォーム レベルの事後分析担当に割り当てることもあります。これらのスタッフは、グループ間をまたぐ作業に適しており、必要なレベルの作業を行えるからです。
内部の事後分析報告書の共有
事後分析が承認されると、学んだことを会社全体で共有することでその価値は何倍にも増えます。Atlassian ではこれを達成するために、事後分析チケットが承認されたときに Confluence にドラフト ブログ投稿を作成する、自動化アクションがあります。
公開インシデントの事後分析報告書の作成
あまり一般的ではないものの、インシデント発生後に事後分析の公開版を公開することをお勧めします。
これは、多くのユーザーに影響を与える停止が発生しうる大規模な消費者サービスで、特に一般的です。多くの場合、これらのチームは、内部の報告書全体ではなくその要約版を公開します。個人情報や機密情報を取り除くことが重要です。
公開インシデントの事後分析報告書の共有
公開事後分析を公開する正しいチャンネルを判断するのは、難しい場合があります。チームによっては、会社のブログや Web サイトに掲載する場合もあります。事後分析専用のエンジニアリング ブログを持っているチームもあります。
当社の製品 Statuspage では、インシデントが解決された後、ユーザーは公開事後分析をステータス ページに直接公開できます。
Statuspage でインシデント コミュニケーションを学ぶ
このチュートリアルでは、システム停止時にインシデント テンプレートを使用して効果的にコミュニケーションを取る方法について説明します。さまざまなサービス中断に適応可能です。
このチュートリアルを読むインシデントの事後分析プロセスの重要性
インシデント後レビューとも呼ばれるインシデントの事後分析レビューは、インシデント中に何が起こったかを調査して教訓を取り込むのに最適な方法です。
この記事を読む