ロールバック/ロールフォワードとMTTRメトリックの間の適切な関係は何ですか？

データをキャプチャして平均修復時間（MTTR）メトリックの測定を開始する最良の方法を理解しようとしています。「ロールバック」がMTTRにプラスまたはマイナスの影響を与える方法に頭を抱える必要があります。

シナリオ1

堅実な監視が行われていると仮定すると、インシデントを比較的迅速に検出する（MTTIが低い）コードがデプロイされます。識別の時点で、2つの主要な可能なパスがあります（そうです、私は議論の目的で過度に単純化しています）。

1. デプロイメントをロールバックし、安定性をすばやく戻しますが、本番環境では意図した機能はありません。

2. インシデントを解決し、意図された機能をライブに保つ追加の変更をロールフォワードします。

このscenaroでは、サイトの安定性がすぐに回復する可能性があるため、MTTRはかなり低くなっています。とはいえ、意図した変更の結果は有効ではないため、コード/機能/変更はまだ進行中です。目標が低いMTTRである場合、回復メカニズムとしてロールバックを奨励するように見えます。

シナリオ2

このシナリオでは、MTTRは、予想されるコード/機能/変更が本番環境で適切に機能するのにかかる時間によって厳密に測定されます。ロールバックしても、「修正済み」のコード変更が製品化されるまで、MTTRタイマーはまだ実行中です。この場合、MTTRは単なる「ちょっと、物事は安定している」のではなく、ビジネス結果の安定性に結びついているようです。

さて、答えはMTTRが真空での指標として使用されていないのと同じくらい簡単かもしれませんが、むしろ変更失敗率と組み合わせて-頻繁なロールバックによって引き起こされる超低MTTRは、非常に高い変更失敗率を指す可能性があります。とは言っても、MTTRの測定値をビジネスの成果から切り離すという考えでは、私には正しくないように思われることがあります。

私はこれをかなり考えすぎているかもしれませんが、他の人がどのようにMTTRを測定しているか、および「回復」の最終時点は何であるかについて知りたいです。それを単に安定性として使用していますか、それとも他の要因が「回復」の意味を決定するのに使用されていますか？

はい、MTTRは常にビジネスの結果に結び付けられている/すべきです。物事が安定していない場合、ビジネスそのものがリスクにさらされます。

シナリオ1で予期されるコード/機能/変更がまだプロセスでスタックしているという事実は関係ありません。機能は安定していないため、新しいビジネスをもたらさず、ロールバックはその時点でビジネスから実行できる最善の方法です見込み。

ロールフォワードはギャンブルです。実際には統計的に成功の変化が少ない潜在的な修正を待機するリスクにビジネスを保ちます（不安定性のために、最初から不安定さを引き起こした変化に比べて常に変化が急がれます。そのような圧力）。ロールフォワードは、まだチェックされていないコードのさらに別のバージョンです。

MTTRを低く保ちたい場合は、議論せずにすぐにロールバックします。これによりビジネスリスクが取り除かれ、展開を試みる前に修正が実際に機能していることを確認する機会が与えられます。私はそれをポリシーとして「はい」に設定することを強くお勧めします。ほとんどの場合、ロールバックの代わりに修正を要求し、それについて交渉/決定するために会議を呼び出す誰かがいます-すべてのビジネスが危険にさらされている間。

補足：高い変更失敗率が気になる場合は、実際のロールバック率を低いMTRRから導出するのではなく、確認することをお勧めします。最も頻繁に発生する障害について、展開前にゲートチェックを追加したい場合があります。そのようなチェックがすでに自動化されている場合-CI検証に含めてみませんか？あなたが持っていない場合-多分それについて考え始める時がきましたか？:)

回復するまでの平均時間には暗黙の主題があります-回復するまでの平均時間は何ですか？これを定義することは、メトリックを効果的に使用するための鍵です。

本番ウェブサイトの一般提供を回復していますか？バグのある特定の機能の機能を回復していますか？実際に何を測定しようとしているのかがわかれば、測定がはるかに簡単になります。

あなたの質問の一般的な推力は、実際には古くからの戦いである、出荷機能と信頼性の維持という競合する目標を取り巻いているようです。伝統的に、新しいものを実装するのは開発者の仕事であり、破壊を防ぐのはシステム管理者の仕事であり、これは変更が破損を引き起こす傾向があるため、部門間の対立につながります。DevOpsに関連する多くの哲学の1つは、この緊張を緩和するために、開発者と運用エンジニアが緊密に連携する必要があるという考えです。

また、その問題に対するGoogleのアプローチにも興味があるかもしれません。これは、開発チームが費やす「エラー予算」を持つことです。安定性に過度のペナルティを課した後は、残りの四半期を安定性にのみ取り組む必要があります。これに加えて、サイト信頼性エンジニアには利用可能な目標があり、オーバーシュートした場合は、より多くの変更を許可することをお勧めします。ここでの考え方は、彼らの目標は単に信頼性をできるだけ高く維持することではなく、あらゆる状況での変化と戦う意欲があるということです。