Azure での SaaS ワークロードのインシデント管理

サービスとしてのソフトウェア (SaaS) ソリューションの独立系ソフトウェア ベンダー (ISV) は、顧客のためにソリューションを運用する必要があります。 これを行うには、予期しない運用環境の状況をスムーズに処理する組織の体制と文化が必要です。 アーキテクトは、それに応じて管理プロセスとツールを設計する必要があります。

この記事では、運用環境の SaaS ソリューションのインシデント管理をサポートするために、組織の文化、プロセス、およびツールを調整する方法について説明します。

サービス プロバイダーとしての責任を理解する

SaaS ソリューションを運用することは、顧客の 24 時間 365 日の IT および運用部門となることを意味します。 適切な人材、文化、プロセス、ツールを備える必要があります。

設計上の考慮事項

• 24 時間 365 日のサポートに責任を持ちます。 SaaS ソリューションを運用するには、組織が常にインシデント応答に備える必要があります。 インシデントは業務時間外に発生する可能性があるため、常にチーム メンバーが稼働できるようにしておくことも、この準備に含まれます。

  "ライブサイト サポート" には、システムの可用性、セキュリティ、パフォーマンス、デプロイに影響を与えるインシデントへのリアルタイムの監視と応答が含まれます。 そのようなインシデントは、ユーザーまたは顧客が検出できます。 このようなインシデントを処理するには、プレッシャーのある状況で問題を分析して解決する能力など、特定のスキルが必要です。

  ライブサイト サポートはストレスを受ける可能性があるため、チーム メンバーをサポートすることが重要です。 チームがこの責任を受けて間もないときは、移行を慎重に計画してください。 インシデント発生時のオンコール業務、報酬、および不在状況の管理に関する懸念に対処しましょう。

  リスク: スキルと期待管理。すべてのエンジニアが 24 時間 365 日のサポート ロールに適しているわけではありません。 SaaS ソリューションをサポートするために既存のチームを移行する場合は、適切な期待が設定され、教育の機会が提供されるようにしてください。

• ライブサイトの文化を策定しましょう。 サポート ケースとインシデントの管理方法、およびエスカレーション方法を検討してください。 チーム メンバーが自分の責任を理解し、インシデントを処理するために必要なスキルとツールを備えることが目標です。

  スタートアップ企業や小規模な組織では、ライブサイトの問題に対する簡単な計画が用意されている可能性があります。 エンジニアは、最初にカスタマー サポートのケースに応答することで、フロントライン サポートを行う場合があります。 成熟した組織、またはエンタープライズ顧客を抱える SaaS プロバイダーには、より構造化されたサポートと専用のチームが必要です。

  トレードオフ: オペレーショナル エクセレンスとコスト。ライブサイト イベントを管理することで、新機能やバグ修正の開発時間を損なう可能性があります。 開発速度が懸念される場合は、ライブサイト専用のリソースを採用することを検討してください。

設計の推奨事項

応答計画を定義する

インシデントは避けられないものであることを認め、インシデント応答計画を定義して準備しましょう。 このプロアクティブなアプローチにより、最初のインシデント時に応答戦略を考える必要がなくなります。

一般的に顧客のサービス利用能力に影響する、大規模なインシデントを事前に計画してください。 この準備が、インシデントの発生時の管理のストレスと複雑さを最小限に抑えるのに役立ちます。

設計上の考慮事項

• エスカレーション パスを定義しましょう。 サポート タスクのエスカレーション プロセスをチームが理解していることを確認します。 多くの SaaS ソリューションでは、顧客がフロントライン サポート チームに連絡し、そこからエンジニアリング チームに伝わります。 誰と話すべきなのか、そしてそのプロセスを省略すべきではない理由を顧客が把握できるようにしてください。 また、Microsoft のサポート チームを含め、ベンダーに支援を求めるタイミングとその方法をエンジニアリング チームが把握できるようにしてください。

• 重大度レベルを定義しましょう。 インシデントによって、ユーザーと顧客に対する重要度が異なります。 大規模な運用停止への対処方法は、軽微なバグへの対処方法とは違います。 顧客への影響に基づいて重大度レベルを定義し、各レベルに適した期待とタイムラインを設定しましょう。

• トリアージに必要な情報を文書化しましょう。 効果的なインシデント応答には、ドキュメントを最新の状態に保つことが不可欠です。 このドキュメントには、システムのアーキテクチャのレイアウト、コンポーネントレベルの詳細、所有者、および主要な連絡先が含まれます。 不正確な情報や古い情報により、インシデント応答チームが、システムの運用、責任、およびインシデントの潜在的な影響を把握するために貴重な時間を無駄にする可能性があります。

• 顧客への効果的なコミュニケーションを計画しましょう。 インシデント管理では、最新の状況を提供することが重要です。 最新の状況を提供することで、顧客がインシデントの性質を理解でき、さらには同様の問題が発生した顧客からのサポート ケースの量を減らすのにも役立ちます。

設計の推奨事項

インシデントを体系的に管理する

応答時間中に場当たり的な対応を回避するには、定義された計画に従うことが重要です。 このアプローチで、このような状況を管理する際のストレスと複雑さを最小限に抑えることができます。

設計上の考慮事項

• インシデントの重大度を割り当てましょう。 インシデント応答計画を使用して、インシデントの重大度を判断します。 多くの場合、顧客はインシデント中に不満を感じています。 優先順位を付けられるように、彼らに発生している影響を理解することが重要です。 顧客が現実的な期待を持てるように、インシデントの重大度は明確に伝えましょう。

• 落ち着いて、かつ明確に考えましょう。 インシデントはストレスを受ける可能性が高く、あいまいな場合があり、複数の利害関係者が注意を求めています。 インシデント内で誰がリードするのかについて、明確なプロセスを設けましょう。 不完全な情報の中で運用する必要があることを認めながら、可能な限り最善の形でインシデントをトリアージします。 状況を制御し続けるように努めてください。

  組織のリーダーは、インシデントを積極的に調査または軽減しているチーム メンバーを守ることで支援できます。

• 状況を顧客に伝えましょう。 十分な情報だけが公開されるように状態ページを更新します。 コミュニケーションは迅速に行い、推定解決時間などの必要な情報を提供してください。 信頼を維持するために、顧客には頻繁に最新情報を提供しましょう。

設計の推奨事項

インシデントの事後レビューを実施する

インシデントから復旧したら、インシデントから学習するために何が起こったかを確認して分析してください。 修復アクションを実装しましょう。これには、技術的な変更、プロセスの調整、その他のトレーニングを含めることができます。

設計上の考慮事項

• インシデントから学習しましょう。 停止は貴重な学習の機会を提供します。 インシデントの後に徹底的なレビューを実施して、教訓を特定し、改善を実施します。 重大なインシデントには、多くの場合、複数の原因があります。 ソリューションの他のレイヤー (運用プロセスなど) で、問題が悪化する前に防止または検出できるかどうかを評価します。 また、ソリューション内の他の場所で、同じ問題が発生する可能性がある同様のパターンがないかを探します。

• 顧客とコミュニケーションしましょう。 多くの ISV (特に、高品質の更新プログラムを期待するエンタープライズ顧客の場合) は、インシデント後にコミュニケーションを行います。 透明性を保ち、顧客が問題と軽減の手順を理解するのに十分な情報を提供してください。 ただし、セキュリティと整合性を維持するため、ソリューションのアーキテクチャまたはコンポーネントに関する過度な内部情報は共有しないようにしてください。

設計の推奨事項

次のステップ

設計領域を確認したら、評価ツールに進み、設計を評価します。