ブログ エンジニアリング経済学

本番環境のバグを待つコスト

コンテキストが衰退し、ロードコンパウンドがサポートされ、リリースがフリーズし、修正のレビューが難しくなるにつれて、本番環境のバグのコストはさらに高くなります。

本番環境のバグエンジニアリングコストMTTRインシデント対応信頼性
A teal and orange Prilog graphic showing the cost of waiting while a production bug stays live.
運用上の問題が未解決のままになるほど、より多くのチームがコード変更から回復しなければならなくなります。

チームは、本番環境のバグについて、あたかも欠陥の中にコストが含まれているかのように話すことがよくあります。悪い条件で出荷されました。移行でエッジケースが見逃されました。キュー コンシューマがあまりにも積極的に再試行しました。コードを修正すればコストはかかりません。

その視点は小さすぎます。

本番環境のバグの代償は、それを引き起こしたコード行だけではありません。それは、組織がその周囲で生活するのに費やす時間です。

待つことで事件の形が変わる

5 分以内に修正されるバグは通常、コードの問題です。 1 時間待機するバグは調整の問題になります。 1 日待つバグは信頼の問題になります。

同じ根本的な欠陥でも、その欠陥が存続する期間に応じて、まったく異なる損害を引き起こす可能性があります。

  • 顧客は同じ壊れた道に何度もぶつかります。
  • サポート チームは、自信のある答えがないままチケットを収集します。
  • 営業チームまたは成功チームは、一時的な説明を書き始めます。
  • 何が安全なのかわからないため、エンジニアはデプロイの近くで一時停止します。
  • より多くのデータが、不良または部分的に処理された状態でシステムに入力されます。
  • 元のデプロイコンテキストは、それを持っていた人々から消え去ります。

これらのコストはいずれも特別なものではありません。これらは通常のプロダクションドラッグです。

MTTR は貴重な時間をいくつか逃しました

平均回復時間は役に立ちますが、最も無駄が生じる瞬間が隠れてしまう可能性があります。

通常、時計は問題が検出されたときに開始され、サービスが回復したとみなされるときに停止します。これは信頼性に関して重要なことを示しています。インシデントのうち、障害の理解、所有者の発見、証拠の収集、またはレビュー可能な変更の待機にどれだけの時間が費やされたかはわかりません。

修復ワークフローの場合、コストのかかるギャップは次のようになります。

alert -> evidence -> code path -> owner -> patch -> review -> deploy

チームが最初の 4 つのステップを圧縮できれば、コード レビューがより早く開始され、最終的な修正の評価が容易になります。

コンテキストの衰退は実際のコストです

最近のコードは推論が容易です。著者はなぜ変化が起こったのかを覚えている。査読者は議論を覚えています。機能フラグ、ロールアウト計画、テストの前提条件はまだ新しいものです。

時間が経つにつれて、捜査は厳しくなる。エンジニアは数時間前に下した決定を読み直します。デプロイ ウィンドウを再構築します。ダッシュボードを再度開きます。彼らは、その問題が別の事件に関連しているかどうかを尋ねます。修正はまだ小さいかもしれませんが、マージに必要な信頼を築くのはますます難しくなります。

迅速な修復はスピードだけではありません。それは、チームがコンテキストを保持している間にコンテキストを保持することです。

コストはエンジニアリング ダッシュボードに常に表示されるわけではありません

一部の生産上の問題は、テレメトリーでは控えめに見えても、依然としてビジネスに悪影響を及ぼします。

権限のバグは、少数の価値の高いアカウントに影響を与える可能性があります。請求状態のバグは、手動の財務作業を作成する際の少量のエッジケースとして発生する可能性があります。チェックアウトの問題は、1 つの地域の 1 つの支払い方法にのみ影響する可能性がありますが、サポートへの影響は即座に現れる可能性があります。

エンジニアリング ダッシュボードは必要ですが、復旧の負担全体を把握できることはほとんどありません。適切なインシデント概要には、顧客パス、アカウントまたはテナントへの影響 (利用可能な場合)、サポート シグナル、およびコードの所有権をトレースとログとともに含める必要があります。

待機コストを削減するもの

チームは調査とレビューを同じループで実行することで待機コストを削減します。

つまり:

  • アラートは関連するトレースとログに関連付けられています
  • 失敗ウィンドウはデプロイと比較されます
  • 疑わしいコードパスの名前は次のとおりです
  • 所有権は自動的に解決されます
  • 提案されたパッチはレビューできるほど小さい
  • 不確実性は自信に満ちた言葉遣いの陰に隠れるのではなく、目に見えるものになる

ここで AI 支援の修復が役立ちます。秘密裏に本番環境に変更を加えてはいけません。証拠を準備し、最も妥当な修正案を作成し、承認、編集、または拒否できるプル リクエストを所有者に渡す必要があります。

本当の指標は適切な決断を下すまでの時間です

ボットがすぐに差分を生成するため、チームが勝つわけではありません。適切なレビュー担当者がより早く適切な決定を下すことができれば、勝ちとなります。

場合によっては、その決定が「修正をマージする」ことになる場合があります。場合によっては「ロールバック」することもあります。 「これは上流の事件だ」ということもあります。 「パッチではなく人間による調査が必要だ」という場合もあります。

待つことはすべての決定を遅らせるため、コストがかかります。目標は、必死の自動化ではありません。目標は、生産シグナルから証拠に裏付けられたアクションまでの距離を短縮することです。

ループを実行

本番環境のシグナルをレビュー済みの修正に変える。

無料トライアルで、Prilog が実際のインシデントをコードレベルの Pull Request に結びつける方法をご確認ください。