緩和と修正は別 — 原因の場所が分かれば止血できる

障害の最中、原因が分かるまで触らないほうが安全に思えます。SRE Workbook 第9章の事例の振り返りは、順番をはっきり書いています。

With mitigation as top priority, an active incident should be addressed as follows:

• Assess the impact of the incident.
• Mitigate the impact.
• Perform a root-cause analysis of the incident.
• After the incident is over, fix what caused the incident and write a postmortem.

緩和(mitigate)と修正(fix)は別の項目で、修正はインシデントが終わった後に置かれています。では、原因が分からないまま何を根拠に緩和するのか。同じ振り返りはこう答えます。

To mitigate an incident, you don’t have to fully understand the details—you only need to know the location of the root cause.

要るのは場所です。「直前のリリースから壊れ始めた」「エラーはこの地域に偏っている」——どこにあるかが分かれば、その場所を通り道から外せます。なぜ壊れたかは、外した後で調べられます。

Workbook はこの種の手を generic mitigation(汎用の緩和策)と呼び、例を2つ挙げます。

For example, responders could roll back a recent release when an outage is correlated with the release cycle, or reconfigure load balancers to avoid a region when errors are localized.

同じ段落で、限界も認めています。

It’s important to note that generic mitigations are blunt instruments and may cause other disruptions to the service. However, while they may have broader impact than a precise solution, they can be put in place quickly to stop the bleeding while the team discovers and addresses the root cause.

鈍い道具で、別の混乱を起こしうる。「緩和すれば安全」ではありません。それでも使うのは、速く止められるからです。そして道具は、壊れてから作っても間に合いません。

The right time to create general-purpose mitigation tools is before an incident occurs, not when you are responding to an emergency.

実演でフラグを切れたのも、v2 を出す前にフラグの内側へ新機能を入れておいたからです。

ここで逆向きの誤りに注意します。「理解より先に手を打て」は「とにかく再起動しろ」ではありません。SRE Book 第14章の優先順位は Stop the bleeding, restore service, and preserve the evidence for root-causing. で、証拠の保全が同じ文に並びます。第4期で扱うとおり、壊れた後はまず影響がどこまで届いたかを確定させ、直してみる・再起動するはその確定の機会を先に潰します。本教材の整理として、緩和に選ぶのは戻せる・記録に残る・証拠を消さない手です。フラグを切る・経路から外すは、壊れたコードや台を消さずに残します。