ステージ 4: 運用

回復力のあるアプリケーションを構築し、テストしました。現在、日常の現実はそれを実行し続けています。しかし、スタートアップでは、すべてのオペレーションをモニタリングすることはできず、試すべきではありません。重要なのは、あまりにも多くのメトリクスを提供したり、チームに負担をかけたりすることなく、重要なことに注意し続けることです。

顧客の視点から始めます。Amazon CloudWatch Synthetics Canary は自動化された顧客として機能します。重要なユーザージャーニーを継続的にテストします。特に繁忙期には、ログイン、テストアカウントを使用した購入のシミュレート、主要な機能へのアクセスを行います。これにより、カスタマーエクスペリエンスを理解し、実際のユーザーが問題を検出する前に問題を見つけることができます。Canary が失敗すると、顧客の観点から何かが間違っていることがすぐにわかります。

サポートインフラストラクチャを集中的にモニタリングして、この基盤を構築します。問題があることを示すシグナルは何ですか? Amazon CloudWatch は、これらのサインを追跡するダッシュボードの構築に役立ちます。技術的なメトリクスをモニタリングするだけでなく、ビジネスへの影響に結び付けます。たとえば、CPU 使用率が高いことは重要ですが、Canary で追跡しているカスタマーエクスペリエンスが低下する可能性があるためです。

実用的なアプローチとして、モニタリングをカスタマージャーニーにマッピングします。Software as a Service (SaaS) プラットフォームを実行している場合は、API の応答時間、認証の成功率、コア機能の可用性を重視している可能性があります。これらのメトリクスがドリフトしたときに通知するアラートを設定します。ただし、選択する必要があります。すべてのアラートはアクションを要求する必要があります。「おそらく何もない」ためにチームがアラートを無視し始めた場合、設定が多すぎるか、間違ったメトリクスを追跡しています。

チームが既に使用しているツールを使用して、これらのアラートをルーティングします。エンジニアが特定のメッセージングアプリケーションに住んでいる場合は、そこでアラートを送信します。目標は、新しいプロセスを作成せずに迅速に認識することです。アラートが発生すると、チームはアラートの意味と対処方法を正確に把握する必要があります。

運用ドキュメントを無駄なく実用的なものにします。コードを含むランブックをバージョン管理で保存しますが、これらは小説ではないことに注意してください。何かが壊れた場合、チームには明確で実用的なステップが必要です。各アラートは対応するランブックにリンクされ、各ランブックは 3 つの質問に答える必要があります。

シンプルなインシデント管理プロセスを実装します。複雑なフレームワークは必要なく、インシデントを構成するものと、事態がエスカレートしたときに誰を呼び出すかを明確に定義します。インシデントログは、アプリケーションの耐障害性の向上に役立つため、保持します。

重要なのは、警戒とオーバーヘッドの間の甘い場所を見つけることです。 AWS ツールを使用して、できることを自動化し、顧客に影響を与えるメトリクスのモニタリングに集中し、成長に合わせて進化するのに十分な軽量なプロセスを維持します。

次の章では、スタートアップを特別なものにするスピードとイノベーションを犠牲にすることなく、レジリエンスの考え方を育む方法について説明します。結局のところ、レジリエンスはテクノロジーに関するものと同じくらい人々に関するものです。