変更の影響範囲を見積もる
誰が傷つくのか、どの経路が最も脆いのか、失敗時にどう戻すのかを洗い出す
あなたは今回の変更に反対する立場です。任務は、この変更が誰を傷つけうるかを見つけることです。以下の変更内容とシステム依存関係から、次を出力してください：1）影響を受ける呼び出し元、データ、定期ジョブ、下流をすべて挙げ、それぞれどう壊れるかを示す；2）「影響を受ける人数 × 復旧の難しさ」で上位三つのリスクを並べる；3）この変更が前提にしているが、まだ検証されていない仮定を挙げる；4）リリース順序とロールバック手順を、戻す判断となる指標のしきい値付きで示す。「影響は限定的です」で締めず、具体的な根拠を出してください。 ［変更 diff／依存関係／トラフィック量］
使い方
まず、このデータを読んでいて、自分のチームが保守していない利用側を探します。見落とされやすいのは、周辺のスクリプトとレポートです。
向いている場面
- 共有フィールドの単位や API の返却形式を変えますが、各クライアントのリリース時期はそろっていません。
- 複数のサービスが間接的に読んでいる設定キーを削除または改名しようとしています。
向いていない場面
- 呼び出し元がまだない新機能なら、影響範囲は空です。労力は別のところに向けるべきです。
- 契約が変わらない内部リファクタリングなら、リスクは局所的で、テストもすでに押さえています。
例
入力
diff: /api/orders の `amount` を元から分に変更。あわせて orders.amount の型を INT から BIGINT に変更。 既知：モバイルの 2 バージョンがまだ稼働中。財務の日次レポートが毎日 01:00 にこのテーブルを読む。
得られるもの
最もリスクが高いのは旧モバイルで、`amount` を元から分に変えても例外は出ず、19.9 元が 1990 元と静かに表示されるだけで、エラー率の監視では捕まりません。次は財務の日次レポートで、INT から BIGINT への変更により、01:00 に誰も見ていないところで解析や精度の前提が壊れる可能性があります。ロールバックは API の返却とカラム型の両方を対象にし、判断は「金額関連の問い合わせ、または日次レポートの検証差異が 0.01% 超」とし、5xx の増加を待たないようにします。
よくある誤用
- 自分のサービスの範囲だけで評価することです。実際に傷つくのは、同じテーブルを読むレポートと旧クライアントです。
- 「ロールバックスクリプトがある」を安全の根拠にすることです。新しい単位でデータが書き込まれた後では、コードを戻しても意味は戻りません。
こう変えると効く
- 「今回の変更が影響しないはずの隣接機能を一つ対照として挙げる」と加えると、影響範囲の分析が過剰反応でないことを確かめられます。
- 「影響を受ける当事者ごとに観測可能な信号を一つ」と求めると、リスク一覧がリリース後に見張れる指標になります。