変更とインシデントの管理

アジャイル文化の構築がほとんどの組織にとってどのように必要になっているのか、そしてソリューションの運用準備を評価することの重要性について説明しました。変更管理とインシデント管理は、IT運用管理の基礎です。変更が頻繁に発生するアジャイル環境では、これらは組織の重要なコンポーネントです。

変更管理とインシデント管理は、ITILフレームワークに含まれている明確に定義されたITサービス管理（ITSM）プラクティスです。

これらの2つのトピックは本質的に関連していない可能性がありますが、相互に関連しているため、同じ前提に根ざしている必要があると思います。

インシデント管理とは、イベントや停止に対応する際の構造化された明確なプロセスを持つことであり、変更管理とは、インシデントを引き起こす可能性のある環境に変更を加えるリスクを評価するプロセスを持つことです。停止が環境に与える影響を適切に評価する手段がない場合、特定の変更のリスクを適切に評価するにはどうすればよいでしょうか。

そのために、参考のために以下のフレームワーク/ワークフローを提案します。最初は少し複雑に見えるかもしれませんが、このモデルの目標は、影響を評価するプロセスを芸術ではなく科学で行い、停止時に邪魔になる可能性のある主観性の一部を取り除くことです。発生し、判断は瞬間の緊急性によって曇っています。

確立された十分に公表されたプロセスを持っていること、そしてそれに従うことであなたを責めることは決してありません。彼らは詳細の一部に同意しないかもしれませんが、将来の変更に影響を与えるためにいつでも議論に招待することができます。

以下に表示されているワークシートは、共有のGoogleスプレッドシートとして利用できます。

停止の影響評価

停止の結果を評価することは、一般的に非常に主観的です。たとえば、シングルユーザーのコンピュータシステムが完全に停止した場合、そのシングルユーザーが新しいインターンまたは会社のCEOである場合、ITスタッフの対応は大きく異なると申し訳ありません。 。開発システムは、開発者がそのシステムなしで仕事をすることができない場合、開発者にとって本番システムであると見なされる可能性があります。しかし、おそらく彼らは彼らのローカルシステムで開発することができますか？それは本当にあなたの状況に依存します、そしてあなたは今日真実であることが明日もはや真実ではないかもしれないことを心に留めておくべきです、あなたは定期的にそのシステムの重要性を再評価しなければなりません。

繰り返しになりますが、明確さと透明性が重要です。これらの話し合いを行い、サービスのユーザーと利害関係者との結果について、おそらく明確に定義されたサービスレベル目標（SLO）ドキュメントで合意する必要があります。必要に応じて、このシステムの価値に関する正確な情報をチームに提供して維持するようにユーザーにインセンティブを与えます。本番システムではバックアップの頻度が高くなりますが、1か月あたりのコストが高くなる可能性があります。

各サービスの重要度の評価は企業レベルで実行する必要があり、誰もが自分の部門が他の部門よりも重要であると考えており、評価は相対的であり、かなり客観的である必要があります。

特にマイクロサービスでは、環境内の依存関係を理解して文書化することも重要です。たぶんあなたのPoCサービスは本番システムのアップストリーム依存関係ですか？ C4の方法論（テキストから図を作成するを参照）は非常に便利で、ドキュメントは重要です。システムの設計者が1日中Visioの図を作成する必要はありません。「きれいな」図よりも、大雑把で正確な図を使用します。日。

可用性

利用可能にするには、システムがアクセス可能で使用可能である必要があります。ユーザーがシステムにアクセスできない場合、またはシステムが遅いか応答しない場合、ユーザーの観点からは利用できません。一般に、ダウンタイムという用語は、システムが利用できない期間を指すために使用されます。

インシデントの重大度

重大度は、ユーザーから見た、問題がシステムの可用性にもたらした損害または危害の量です。

成功または失敗の観点から測定された経験。

インシデントの重大度を判断するには、最も関連性の高いカテゴリを選択します。

インシデントインパクトタイプ

問題が発生する頻度で測定されるインシデントの影響の種類と、問題が発生したユーザーが今後問題を回避または克服する方法を学習できるかどうかを観察することで測定される問題の持続性。 。

タイプは次のとおりです。

• 持続的-この問題は、すべてのユーザーにとって不確定な期間一定です
• 一時的-問題はすべてのユーザーに対して一定ですが、短時間で事前に決定された期間のみです
• 散発的-問題は「1回限り」または一部のユーザーにのみ発生します

インシデントの重大度は、影響の種類と組み合わせて、影響の種類の乗数を選択するために使用されます。

最も関連性の高いカテゴリを選択してください：

影響を受けるシステムの重みとインシデントカテゴリの評価

システムには、組織に対する重要度の相対レベルに基づいて、任意のシステムの重みが割り当てられます。

この重みは、 Impact Type乗数と組み合わされて、 Impactスコアを決定するために使用されます。

スコアが最も高い影響を受けるシステムを選択してください。

事故管理

完全な停止が特定のシステムに与える影響を明確に理解し、それを定量化する方法がわかったら、インシデント管理プロセスの定義を開始できます。

範囲

インシデント管理プロセスは、報告された停止の実際の原因に関係なく、内部データセンターの問題が原因であるか、クラウドプロバイダーまたはISPの問題が原因であるかに関係なく、従う必要があります。

インシデント管理プロセスは、ユーザーの要求や、ユーザーのシステムまたはローカル構成の問題の追跡には適していません。共有の組織システムの問題を追跡することを目的としています。また、ユーザーが変更や新しいアプリケーションを要求することも適切ではありません。そのために、サービス要求プロセスを実装する必要があります。

ゴール

インシデント管理の目標は、影響を受けた1つまたは複数のサービスを迅速に復元することです。停止の重大度と影響によっては、1つまたは一連の関連するインシデントの根本原因を特定するために、問題管理プロセスが必要になる場合があります。どちらも、関連するが明確な目標を果たします。

手順

1. 探知
2. 応答
3. 回復
4. 学び
5. 向上

特定のインシデントまたは潜在的なインシデントのカテゴリ評価は、インシデントの重大度と、影響を受けるシステムに与える影響のタイプの要因として計算されます。この評価は、インシデント管理（3ページを参照）で停止の程度を判断するために使用され、変更管理2で実行されるアクションの潜在的なリスクを判断するために使用されます。

最も重大な影響を受けるシステムの影響スコアは、インシデントカテゴリの評価を決定するために使用されます。これには、状況に最も適切なアクションとコミュニケーション計画が含まれます。

インシデントカテゴリの評価とコミュニケーション計画

影響スコアの評価により、インシデントカテゴリと、イベントを適切に伝達および記録するために従う必要のある手順が決まります。

これらのアクションは例として提供されていることに注意してください。含める追加の手順があると確信しています。

変更管理

変更管理プロセスでは、上記で説明したのとまったく同じ影響を受けるシステムの重みとインシデントカテゴリの評価を使用する必要があります。組織の停止の測定値は変更されていません。唯一の違いは、停止中に発生する可能性を含める必要があることです。変化する。以下で詳しく説明します。まず、用語を定義しましょう。

範囲

変更管理は、オンプレミスまたはクラウドで、会社のITシステムに加えられたすべての変更に適用されます。

ゴール

変更管理プロセスは、インシデント管理プロセスと同じ影響評価を使用します。変更管理の目標は、組織のサービスに加えられた変更のリスクのレベルを適切に評価して、適切な通信チャネルと承認に従うことができるようにすることです。さらに、目標は次のとおりです。

1. ITに必要な変更のタイムリーで効果的な実装をサポートする
2. 組織に対するリスクを適切に管理する
3. 組織への/組織のための変更の悪影響を最小限に抑える
4. 変更によって望ましいビジネス成果が達成されるようにする
5. ガバナンスとコンプライアンスの期待が満たされていることを確認します
   

特定のインシデントまたは潜在的なインシデントのカテゴリ評価は、インシデントの重大度と、影響を受けるシステムに与える影響のタイプの要因として計算されます。

可能性

可能性は、危険が発生する確率であり、多くの場合、5段階でランク付けされます。

• 特定-80〜100％-変更中または変更後に問題が発生する可能性が非常に高い
• 可能性が高い-60〜80％-変更中または変更後に問題が発生する可能性があります
• 可能性-40〜60％-変更中または変更後に問題が発生する可能性がありますが、発生しない可能性があります
• 可能性は低い-20〜40％-変更中または変更後に問題が発生する可能性はほとんどありません
• まれ-0〜20％-変更中または変更後に問題が発生する可能性はほとんどありません

提案された変更のリスクファクターは、可能な限り最高のインシデントカテゴリ評価に、この危険が発生する可能性が最も高いことを掛けることによって測定されます。
リスク=可能性x重大度

組織のシステムとサポートインフラストラクチャに変更を適用する場合、ITチームは、次のリスク評価マトリックスに基づいて、変更の潜在的な影響を評価します。

リスク評価とコミュニケーション計画の変更

リスク要因と変更の緊急性に応じて、ITチームは次のことを行います

ユーザーに変更を通知する手順：