1.MTTRとは何ですか?

システムでシステム障害が発生した場合、障害の重大度と範囲を測定するためにいくつかの指標を使用する必要があります。その中でも、MTTR (平均修復時間)は、システムの修復に必要な平均時間を把握するのに役立つ非常に重要な指標です。システムの修復に時間がかかりすぎることは、特に JD.com のような企業にとってはお勧めできません。MTTR が長すぎると、ユーザーのカード請求の決済や会社の収益の損失などの重大な結果につながる可能性があります。したがって、システムの安定性と信頼性を確保するには、MTTR を可能な限り短縮する必要があります。

MTTR を計算するには、合計メンテナンス時間を特定の期間内のメンテナンス操作の合計数で割ります。MTTR の計算式は次のとおりです。

2.MTTRを短縮する方法

MTTR を理解することは、本番環境での問題へのより適切な対応と修正に役立つため、どの組織にとっても非常に重要なツールです。ほとんどの場合、組織は社内のメンテナンスチームを通じて MTTR を削減することを望んでいますが、それには必要なリソース、ツール、ソフトウェアサポートが必要です。

では、組織の MTTR を短縮するにはどのような手順を実行できるでしょうか? まずは MTTR の各フェーズを理解し、各フェーズにかかる時間を短縮するための措置を講じることから始めるのが最適です。具体的には、次の側面を考慮できます。

1. 問題発見時間: 障害を特定するための監視と警報

障害発生後、技術者が問題を特定するまでの時間については、警報システムを確立することでMTTRの特定時間を短縮できます。システムの動作をリアルタイムで監視し、警報メカニズムを迅速に発見して作動させることにより、可能な限り最短時間で問題を特定し、適切な修復措置を講じることができます。

適切なしきい値とルールを設定することで不要なアラーム情報を除外できるため、アラームノイズによる開発チームと運用チームの干渉が回避され、実際の問題に集中できるようになります。

1.1. UMP監視

UMPにより3つの黄金監視指標（稼働率、通話量、TP99）を実現。

アラームメカニズムを構成する際には、可用性、TP99、コール量などの要素を総合的に考慮して評価できます。これらの指標を総合的に評価することで、システム運用をより包括的に理解できるようになり、潜在的な問題をタイムリーに発見し、対応する措置を講じることができます。

アラームを設定するときは、まずより厳密な戦略を採用することをお勧めします。つまり、最初に締めてから緩め、徐々に最適な状態に調整します。これにより、問題が初期段階で検出され、重大な障害が回避されます。ただし、システムが徐々に安定するにつれて、実際の状況に応じてアラームしきい値を適切に緩和して、システムの可用性と効率を向上させることもできます。

アラームを構成するときは、特定のビジネスシナリオとシステム特性に基づいて調整と最適化を行う必要があることに注意してください。システムが異なればリスクポイントやボトルネックも異なる可能性があるため、システムの安定性と信頼性を確保するには、実際の状況に基づいて対応するアラーム戦略を策定する必要があります。

critical告警方式：咚咚、邮件、即时消息(京ME)、语音
可用率：（分钟级）可用率 < 99.9% 连续 3 次超过阈值则报警，且在 3 分钟内报一次警。
性能：（分钟级）TP99 >= 200.0ms 连续 3 次超过阈值则报警，且在 3 分钟内只报一次警。
调用次数：当方法调用次数在 1 分钟的总和，连续 3 次大于 5000000 则报警，且在 3分钟内只报一次警

warning告警方式：咚咚、邮件、即时消息
可用率：（分钟级）可用率 < 99.95% 连续 3 次超过阈值则报警，且在 30 分钟内报一次警。
性能：（分钟级）TP99 >= 100.ms 连续 3 次超过阈值则报警，且在 30 分钟内只报一次警。
调用次数：当方法调用次数在 1 分钟的总和，连续 3 次大于 2000000 则报警，且在 3 分钟内只报一次警

UMP がスケジュールされたタスクである場合、最も重要な点は監視期間を決定することです。監視期間を正しく設定することによってのみ、UMP が予想される期間内に正常に実行されることを保証できます。このようにして、UMP が予想される期間内に実行されなかった場合、アラームメカニズムが自動的にトリガーされ、検出および解決されます。時間の問題。

1.2. 警報呼び出しは、迅速、正確、そして頻度を低くして行う必要があります。

警報情報を処理する際に重要なのは、情報の量ではなく、情報の正確性と完全性です。私たちのチームは毎日何百ものアラームメッセージを受け取りますが、それぞれを確認するのに十分なエネルギーと時間はありますか? 一人一人に注目を集めることができますか?

したがって、ビジネスへの影響を評価し、状況に応じて適切なアラーム頻度を設定する必要があります。特に「キーボイス」とされる警報メッセージについては、できるだけ早く発見し、対処する必要があります。この方法によってのみ、緊急事態に直面したときに迅速かつ正確に対応し、起こり得る影響を最小限に抑えることができます。

1.3. 詳細が成功か失敗かを決定します。

1. アラーム情報への応答時間が長い場合、チームの勤務中の応答メカニズムが正常であるかどうかを確認する必要があります。問題をタイムリーに解決できるように、アラーム情報が適切な担当者に効果的に伝達されるようにする必要があります。

2. 警報情報の日常的な決済については、それぞれの警報情報を適切に取り扱うことができるよう、対応する処理機構を確立する必要がある。毎日の清算と日次締めが達成できない場合は、その原因を深く分析し、それに対応した改善策を講じる必要があります。

3. アラーム情報を処理する際には、その根本原因を深く分析する必要があります。問題の根本を見つけてのみ、問題を根本的に解決することができます。

4. アラームが頻繁に発生しているにもかかわらず対処されていない場合は、アラームが必要かどうかを真剣に検討する必要があります。場合によっては、誤ったアラームや無関係な問題によってアラームが発生する場合がありますが、現時点では、これらのアラームを選別して排除する必要があります。

5. 問題が発生し、UMP または他のリンクの対応するアラーム情報が追加されていない場合は、他のコアリンクも欠落しているかどうかを注意深く確認する必要があります。不足している追加がある場合は、ツールスキャンを使用して見つけることができます。

6. 以前に表示されたアラーム情報については、経験に基づいて特定の理由によって発生すると結論付けることはできません。歴史的な経験は必ずしも正確で信頼できるものではなく、本当の結論は関連するログの調査と分析を通じてのみ導き出すことができます。

7. アラーム情報を設定する場合は、その合理性を十分に考慮する必要があります。最初は締めてから緩めるなど、徐々にベストな状態に調整することをお勧めします。これにより、最初からアラームメッセージが多すぎたり少なすぎたりすることがなくなり、作業の効率と精度が向上します。

2. システムの問題を軽減する時間: 障害対応メカニズム、迅速な止血

システムの問題をただ特定するのではなく、軽減する必要があるのはなぜでしょうか? システムの問題に対処する場合、単に問題を特定するだけでは解決策の一部にすぎないからです。さらに重要なのは、ビジネスへのさらなる影響を避けるために、システムの問題をできるだけ早く軽減する必要があるということです。

問題処理の効率を向上させるには、次の 3 つの側面から始める必要があります。

1. 指揮系統と役割分担の改善：完全な指揮体系と明確な役割分担により、障害処理の効率を効果的に向上させることができます。問題に対処するときは、それぞれの役割と責任を明確にし、協力して問題を解決する必要があります。

2. 完全な技術的障害分離手段: 技術レベルでは、過剰なコードのロールバックを避けるために、DUCC スイッチなどによる何らかの障害分離手段を採用する必要があります。これにより、出血をより早く止めることができます (DUCC は数秒で切り替わりますが、マシンが複数回ロールバックする場合は 5 ～ 10 分かかります)。

3. 十分に練られた障害処理メカニズムの保証: 最後に、UAT 環境テスト、トラブルシューティング訓練、緊急計画 SOP などを含む、十分に練られた障害処理メカニズムの保証を確立する必要があります。これにより、問題が発生した場合に迅速な対応と効果的な問題解決が可能になります。

つまり、問題処理の効率を向上させるには、単に問題を特定するだけでなく、システムの問題の時間を短縮するための一連の措置を講じる必要があります。この方法によってのみ、システムの安定性と信頼性を真に保証することができます。

2.1. 障害緊急対応メカニズムの実装

組織の規模に関わらず、最も重要な特徴の 1 つは緊急事態への対応能力です。緊急事態に直面した場合、さまざまな緊急事態に迅速かつ効果的に対応できるように、完全な緊急計画と実践的な訓練メカニズムが必要です。この目標を達成するには、次の側面から始める必要があります。

1. 完全なトレーニングと運動のプロセスを確立する: 完全なトレーニングと運動のプロセスを確立し、維持することが非常に重要です。これには、ビジネスに精通し、関連する計画の策定と実行の責任を専任する人々のグループが必要です。同時に、緊急時計画の有効性と運用性を確保するために、実際の状況に基づいた定期的な訓練やシミュレーションテストを実施する必要があります。

2. 問題を最初にグループに報告し、チームの力を発揮する: 緊急事態に対処するときは、まず問題をグループに報告し、チームの力を最大限に発揮する必要があります。ブレーンストーミングを行うことで、問題の根本原因をより迅速に特定し、それを解決するために対応する措置を講じることができます。

3. 問題の重大度を合理的に判断する: 問題の重大度を判断するときは、エンジニアリング上の優れた判断力を持ち、ある程度の冷静さを保つ必要があります。

つまり、緊急事態に対応する組織の能力を向上させるには、完全な訓練と演習のプロセスを確立し、チームの力を最大限に発揮し、問題の深刻度を合理的に判断する必要があります。この方法によってのみ、組織の安定性と信頼性を真に保証することができます。

主な役割分担

1. フォルトコマンダー。この役割は指揮系統全体の中核であり、責任者、チームリーダー、アーキテクトなど、実行ではなく組織と調整が最も重要な役割となります。

2. コミュニケーションと指導。社内外の情報収集と報告を担当しますが、プロダクトマネージャーなど、優れたコミュニケーション能力と表現力が求められます。

3. 執行者。チームの中核となる研究開発や運用保守の同僚など、障害処理に関与するあらゆる種類の担当者が、実際の障害位置の特定とビジネスの回復に責任を負います。

プロセスメカニズム

1. 障害が発見された後、オンコールの同僚またはチームリーダーは、対応するビジネス開発またはその他の必要なリソースを呼び出して、会議を迅速に開催する権利を有します。

2. 問題が難しく、影響が大きい場合は、部門長などの上位レベルの介入を求めることができます。

フィードバック機構

現在の処理の進捗状況と次のアクションをフィードバックする早急に実行する必要がある操作がある場合は、事前に報告する報告が必要な内容には、業務やシステムへの影響も含まれる最後に、障害司令官は、多忙を避けるため、実行する前に決定を下しました。何か問題が発生しました。進歩がないことは依然として進歩であり、タイムリーなフィードバックが必要です。カスタマーサービスなど、技術者以外の担当者からのフィードバック 専門用語ではなく、できるだけビジネスライクな言葉で説明し、自分たちが何をしているのか、復旧までにどのくらい時間がかかるのか、復旧できない場合はどうなるのかなど、大まかな予想を相手に伝えなければなりません。復旧するか、折り返しの電話がかかるまでにどれくらい時間がかかりますか? フィードバックなど。

2.2. 迅速な止血緊急計画

基本原則: 障害処理プロセスで取られるすべての手段と行動において、事業の復旧が最優先であり、障害の原因を特定することよりも現場の止血ソリューションを復旧することが優先されます。

1. 問題に直面したとき、最初の反応は、すぐにトラブルシューティングプロセスを開始し、できるだけ早く問題の根本原因を見つけようとするかもしれませんが、これは間違いです。こんなことしないで。正しいアプローチは、システムの問題を軽減することが最優先であり、システムをサービスに復元するために可能な限りのことを行うことです。

2. 根本原因の調査ではなく、すぐに出血を止めます。まず必要なのは、問題の大まかな位置を特定し、その後、いくつかの緊急計画措置 (DUCC スイッチのダウングレード、電流制限、ロールバックなど) を通じてシーンを復元することだけです。

3. オンライン上の問題については、まずオンライン化や事業構成の変更などの変化、情報の整理が原因なのかを考えます。

4. リリース中にエラーが発生し始めましたが、リリース前はすべて正常でしたか? 何も心配せず、最初はロールバックし、正常に戻ってからゆっくり調査してください。

5. アプリケーションは長い間安定して動作していましたが、突然プロセスが終了し始めましたか? メモリリークである可能性が高いため、サイレントにメソッドを再起動します。

6. オンラインで紹介された問題かどうかを確認するにはどうすればよいですか? オンラインになる前 (昨日や先週など) に、前年比ベースで同じ問題が存在しますか? それも存在する場合、それはオンライン化とは何の関係もないことを意味します。昨日のログを見てください。ログが最も信頼できます。可用性率は誰もを欺きます (今日は可用性率を管理しているかもしれませんが、以前は可用性率が 100% でしたが、必ずしも 100% であるとは限りません)。

7. 事業、製品、研究開発は並行して実行されます

8. 問題を迅速に特定する場合は、問題の場面を時間内に保存する必要があります。たとえば、最初に JSF サービスを削除しますが、1 台のマシンを保持し (再起動しないでください)、その後の根本原因分析のために JVM スタック情報を保持します。

2.3. 既存のツールを最大限に活用して位置決めの問題をインテリジェントに分析する

2.2.1. 高くて位置決めが難しい TP99 の場合:

呼び出し関係は複雑なので、パフォーマンスのボトルネックをすぐに特定することが困難です。ツールを使用すると、問題が発生した場合にのみリンクを整理するのではなく、サービス間の複雑な依存関係を事前に整理し、ボトルネックサービスの中核的な問題に焦点を当てることができます。

• Taishan フェイルオーバーなど: このアラームがどの要因に最も関連しているかをインテリジェントに通知します。機能は試用中です。

• UMP 収集ポイントを統合したグローバルサイネージにより、TP99 が高いリンクを迅速に特定できます。

• ロングリンクアプリケーション、泰山レーダーチャートを設定します。

• 分析の基礎としての Pfinder 分散呼び出しリンク

2.2.2. 突然の通話量の増加への対応

[JSF] > [トラフィック保護] > [アプリケーションとインターフェイス] > [エイリアスとメソッド名] を使用して、アップストリームアプリケーションの呼び出し量を特定し、アップストリーム通信、電流制限戦略などの対応する措置を講じることができます。

2.2.3. スレッド解析、JVM、フレームグラフCPUサンプリングなど

Taishan Platform》障害診断》オンライン診断

2.2.4. ビジネス上の問題

航海日誌検索によれば、これについては何も述べられていない。

標準化された手順に従って技術者を指導およびトレーニングすることで、問題解決にかかる時間を短縮できます。同じ障害が発生した場合でも、適切な文書と緊急対応計画 (SOP) があれば、障害を引き起こした可能性のあるすべての原因を迅速に調査できます。

3. まとめ

オンラインの問題が解決された後、COE (Center of Excellence) レビューレポートを作成することは非常に重要なステップです。このレポートでは、問題処理プロセス全体をレビューし、当時そうしていれば MTTR (平均修復時間) をより速く短縮するために何ができたのかを考えることができます。

具体的には、次のような側面から始めることができます。

1.問題の原因を分析する: まず、 問題の根本原因を見つけるために、問題 を詳細に分析する必要があります。問題の根本原因を特定することによってのみ、問題を解決し MTTR を短縮するための的を絞った対策を講じることができます。

2. 経験と教訓を要約する: 問題を分析する過程で、経験と教訓を要約し、改善のための提案を行う必要があります。これらの提案には、プロセスの最適化、効率の向上、トレーニングの強化などが含まれますが、アクションをたくさん列挙する必要はありません。2/8 ルールに従って重要なポイントに焦点を当てるだけです。

3. 次回同様の問題が発生するのを防ぐために、1 つの例から推論を導きます。同様の問題が再び発生するのを避けるために、この問題から学んだ経験と教訓を他の同様の問題に適用する必要があります。

つまり、問題を徹底的に分析し、根本原因を特定し、経験と教訓を要約し、1 つの例から推論することで、MTTR を効果的に短縮し、システムの安定性と信頼性を確保することができます。

参考：

SRE Google の運用とメンテナンスの復号化

継続的デリバリー 2.0

著者: JD Logistics Feng Zhiwen

出典：JD Cloud Developer Community Ziyuanqishuo Tech 転載の際は出典を明記してください

【安定性】MTTR短縮の模索 | JDロジスティクス技術チーム