組織が一貫してオンコールレビューを行っていると、そのデータを使用して部門または部門レベルでサービスレビューを行 これらのレビューは、負の影響がより広範かつ潜在的により有害になる前に、傾向を発見し、必要なコースの修正を行うための経営陣のための機会です。
このレビューの目的は、どの技術サービスがビジネスに影響を与えているかを理解することです。 それは、影響がどこから来るのかだけでなく、ビジネスへの影響の種類と範囲も理解しようとしています。 その知識により、経営陣は技術サービスの信頼性とプロセスの改善に投資を集中させ、より良いビジネス成果を生み出すことができます。
Cadence#
オンコールレビューとは異なり、サービスレビュー会議を開催する論理的な機会を作り出す典型的なカレンダーイベントはありません。 しかし、ほとんどの組織は毎月のケイデンスでサービスレビューを実施しています。
毎月のケイデンスは、以前の会議で特定されたプロセスやツールの変更や改善が実装され、定量化可能な方法で有効になるのに十分な時間を可能にし そのケイデンスはまた、問題があまりにも深刻になる前に調整を行う機会を提供していますが、関係するすべての人々によって行われている時間投資
スコープ#
サービスレビューは、部門または部門全体に対して実施する必要があります。 大規模な組織の場合、これは特定の製品またはビジネスラインを担当するすべてのチームに対して1つのサービスレビューを意味する場合があります。 中規模の組織の場合、これは製品エンジニアリング部門、IT部門、および運用部門のための第三のレビューを意味する可能性があります。 小規模企業の場合、デジタル製品の開発と提供に関わる組織内のすべてのチームを単一のレビューでカバーすることができます。 組織の規模にかかわらず、サービスレビューの範囲は、複数のチームが所有するサービスの操作をカバーする必要があります。
会議での指標と議論には、レビュー会議を実行しているグループ（または部門または部門）にロールアップするチームが所有するすべての技術サービスを含 問題のチームが所有するサービスに下流の依存関係がある場合、それらのサービスもこの会議の範囲の一部である必要があります。
オンコールレビューと同様に、各サービスレビューは、最後の会議からの期間（理想的には一ヶ月）をカバーする必要があります。
会議の所有者と出席者#
このレビューは、通常、部門または部門のリーダー、通常はエンジニアリング、IT、または運用のディレクターまたは副社長によって組織され、 この会議を上級管理職レベルから推進することは、参加を保証するだけでなく、サービス運用への投資への変更を行動してフォロースルーするという上級管理職のコミットメントを提供します。
中小組織では、審査会は部門-部門長自身によって呼び出され、設置され、運営されています。 彼らは通常、彼らのプロジェクトに関連するデータアナリスト、プログラムマネージャー、または管理アシスタントによってサポートされています。 大規模な組織では、サービスレビューはCIOのオフィスまたはCTOのオフィスによって後援され、それらのオフィスのプログラムマネージャーが各部門または部門
会議には、会議でカバーするチームとサービスの範囲を所有する部門、部門、または組織リーダーのすべての機能リードおよび/または直接報告書が出席する必要があ これらは、通常、エンジニアリング、IT、および運用の他の副社長、取締役、および上級管理職です。 エンジニアリング、IT、および/または運用におけるリーダーシップの複数の層が存在しない組織を除いて、エンジニアリングマネージャーがこの会議に出席 オンコールレスポンダーは、この会議に参加する必要はありません。
Metrics#
名前が示すように、サービスレビューのために、主にサービスレンズを通してメトリックを見ていきます。 サービスのレンズを通じたインシデント指標に加えて、ここで使用する指標は、サービスの可用性を通じて顧客への影響をより直接的に指し始めます。
オンコールレビューと同様に、最初はこれらの指標をすべて簡単に引き出すことができない場合があり、貴重な指標が異なる場合があります。 あなたが持っているものを使用し、何を始めるための方法として収集することができます。 最も重要なことは、あなたが始めることです。
以下は、会議の有効性を最大限に高めるための推奨指標です:
- SLAに対するサービス可用性(合計およびビジネスサービス別)
- 重大なインシデントのない時間(合計、技術サービスおよびビジネスサービス別)
- 緊急性の高いインシデントのない時間(合計、技術サービスおよびビジネスサービス別)
- 重大なインシデントのない時間(合計、技術サービスおよびビジネスサービス別)
- 重大なインシデントのない時間(合計、技術サービスおよびビジネスサービス別)
- 大規模なインシデントの数(合計、技術サービスおよびビジネスサービス別)
- 高インシデントのない時間(合計、技術サービスおよびビジネスサービス別)
- 高インシデントのない時間(合計、技術サービスおよびビジネスサービス別)
- 高インシデントのない時間(合計、技術サービスおよびビジネスサービス別)緊急インシデント数(合計、技術サービス別、およびビジネスサービス別)
- 平均認識時間(合計、技術サービス別)
- 平均解決時間(合計、技術サービス別)
- インシデントの種類、問題のある技術サービス、影響を受けるビジネスサービス、期間、およびビジネスへの影響（重大度、顧客への影響数など）の詳細を含む、)
レビューの実施#
オンコールレビュー会議よりも長い間、サービスレビューは依然として非常に焦点を当てた活動です。 一般的に言えば、会議は議題のこのタイプに従うべきです:
- サービスレビューメトリックレポートをすべての出席者に事前に配布する(これにより、役立つ補足情報を事前に読み、収集する機会が提供されます)
- 部門
- ビジネスサービスの不採算性に最も影響を与えた技術サービスの指標とインシデント傾向を確認する メトリクス
- ビジネスサービスへの影響が最も大きかった技術サービスの主要インシデントのすべてを歩く
- 寄与要因、期間、死後、フォローアップ項目の
- 会議の残りの部分を使用して、ビジネスサービスの可用性の向上に焦点を当て、具体的な行動計画を立てます
成功したレビュー会議では、これらの質問のほ:
- その月の稼働時間と顧客の可用性は何でしたか？
- 私たちは何件の事件を持っていましたか？ 彼らは上または下に傾向がありますか？
- インシデントの影響を受けたビジネスサービスは、他のビジネスサービスよりも多かったですか？
- ビジネスサービスの信頼性に最大のマイナスの影響を与えた技術サービスはどれですか？
- ビジネスサービスにマイナスの影響を与えた技術サービスについて、その月に何件のインシデントが発生しましたか？ 傾向は上がっているか、下がっているか、または同じままですか？
- 私たちの主要な事件の主な要因は何でしたか？ 私たちの反応はどのように効果的でしたか？ これらの主要な事件は再び起こる可能性がありますか？
- 将来的に稼働時間と顧客の可用性を改善したい場合、より多くの人、プロセス、および/または技術リソースをどこに投資する必要がありますか？
行動を取る#
すべての運用レビューと同様に、取るべき適切な行動は、サービスレビューで学んだこと、組織文化、現在の焦点、現在の目標に大きく依存します。 しかし、いくつかの一般的なヒントとサービスレビューの後に行動を取るための焦点の共通領域があります。
最初に行うことは、行動に優先順位を付ける場所を理解することです。 ビジネスサービスに焦点を当てることで、投資の優先順位を簡単に設定できます。 優先順位付けは、インシデント数や期間だけに基づくべきではなく、むしろ、ビジネスサービスへの総影響は、その基礎となる技術サービスへの投資のレベ
次に、技術サービスが必要とする投資の種類を決定する必要があります。 サービスの可用性を向上させるための投資には、責任あるチームのための主要なインシデント対応トレーニングのトレーニング、アラートとのコンテキスト情報の共有、サービスコードのリファクタリング、技術的負債の返済、インフラストラクチャのアップグレードなどが含まれます。
必要なアクションが何であれ、デジタルサービスの顧客の可用性にどのように影響するかを明確にすることで、ビジネス成果の最適化に努力を結び
最終的な注意事項と考慮事項#
うまくいけば、毎月のサービスレビューと毎週のオンコールレビューが共生していることがわかり始めています。
あなたのチームがオンコールレビューを行っている場合、どのサービスが注意を必要としているかについて驚くべきことはありません。 サービスレビュー会議の参加者であれば、この会議の準備のために、過去1ヶ月間のチームのオンコール負荷/痛みの概要を読むことをお勧めします。 チームにオンコールレビューメトリクスを共有するように依頼します。
あなたのチームがオンコールレビューを実施し、特定されたアクションをフォローアップしている場合、毎月のサービスレビューでは、アクション不可能なイ そうでない場合は、たとえば、それはあなたの焦点は、それが次の毎月のサービスレビュー会議の時間だときに問題ではないように、アクション不可能なイ