請求legacy systemを止めずに進化させる

Scenario

八年間運用されたsubscription billing monolithへ、新しい税丸め規則と顧客名schemaを導入する。仕様書だけでは実挙動を説明できず、batch処理、外部税service、手動運用、隠れた並行更新が存在する。big-bang rewriteを行わず、未知を明示したsystem map、characterization test、段階migration、rollback、保守引継ぎまでを証拠で完成させる課題である。

制約

• 既存invoiceの金額と監査履歴を変更せず、新税規則は指定日以降の新規計算だけへ適用する
• big-bang rewriteを禁止し、未知領域を推測で埋めずsystem mapへ明記する
• databaseはsynthetic 2TB相当、旧版と新版のapplicationが7日間共存する
• monthly close中の停止時間は10分以内、利用者journeyのsynthetic SLOは99.95パーセントとする
• backfill、dual read、dual write、cutover、contractに観測、停止、再開、rollback条件を置く
• invoice jobの重複実行、concurrent update、外部税serviceのtimeoutと結果不明を再現する
• 保守teamとplatform teamのowner、dependency、SLO、cognitive load、escalationを明示する
• 実在顧客情報と実料金を使わず、固定seedとsynthetic価格で再現可能な評価を行う
• 二つの投資案をengineering hours、operations hours、信頼性、capacity、option valueで比較する
• rollback後のsystem outcomeと旧新版双方のread compatibilityを15分以内に検証する

提出証拠

Build

実行経路・変更理由・未知領域を持つsystem map、現行挙動を固定するcharacterization test、税丸めmutationをkillするTDD履歴、互換API、storage ADR、transaction不変条件、expand-contract各phaseの実行証拠

Operate

旧新版のSLI・SLO、backfill progressとerror、負荷・memory profile、外部依存timeout、shadow・canary・rollback結果、重複jobとmigration incident drill、maintenance runbook

Explain

技術者向け実行経路とmigration詳細、事業・監査向け影響と停止条件、operations向けrunbookを相互参照できる設計文書、非同期decision log、費用と機会損失の説明

Review

第三者がsystem mapから隠れた経路をfindingとして提出し、author fix後にbackfill error rateという単一制約だけを変更する。characterization、migration、SLO、rollback、economicsを独立再評価する

Milestone

1. productionを変更せずfixture、runtime trace、dependency、batch、手動操作、未知領域をsystem mapへ固定する
2. 変更要求をdomain rule、不変条件、API互換性、storage、transaction、threat・privacy constraintへ追跡する
3. REDから税丸めとschema compatibilityを実装し、旧新版共存、concurrency、重複job、外部依存失敗を検証する
4. expand、backfill、dual read、cutover、contractをcanaryで進め、閾値からstop・resume・rollbackを実行する
5. incident drill、第三者review、修正、独立再評価を行い、team interface、投資判断、runbookを更新する

レビュー質問

1. 仕様書と実挙動が異なる箇所はどのcharacterization evidenceで固定され、未知はどこに残るか
2. 税丸めと顧客名変更を分離した場合の可逆性と運用費用はどう変わるか
3. 旧新版が共存する各phaseでwrite、read、retry、rollbackの互換性を誰が判定するか
4. backfill commandの終了成功ではなくsystem outcomeと監査結果を何で証明するか
5. 隠れた経路、重複job、外部依存遅延、concurrent updateのどれが停止条件を発火するか
6. 第三者reviewで発見した未知がtest、migration、runbook、cost、team boundaryへ伝播したか

統合するレッスン

1. システム思考とエンジニアリングのトレードオフ

   この課題では統合・補強して扱います。

2. アルゴリズム選択を計算量と測定で検証する

   この課題では統合・補強して扱います。

3. CPU・メモリ経路とアクセス局所性

   この課題では統合・補強して扱います。

4. プロセス・スレッド・並行性の不変条件

   この課題では統合・補強して扱います。

5. ネットワーク遅延と部分失敗を層別に診断する

   この課題では統合・補強して扱います。

6. 要求を発見し、境界と例外をドメインモデルへ結ぶ

   この課題では統合・補強して扱います。

7. API契約を失敗、再送、進化まで設計する

   この課題では統合・補強して扱います。

8. 変更理由でモジュール境界を設計しADRで更新する

   主評価: 変更理由、dependency direction、cycle、migration seamをsystem mapとADRへ追跡し、境界を更新する

9. TDDとリスク別テスト戦略で変更を証明する

   主評価: 税丸めをREDから実装し、実process evidence、behavior hash、mutation killで回帰能力を検証する

10. 脅威モデルを設計・検証・残余リスクへ接続する

    この課題では統合・補強して扱います。

11. アクセスパターンと制約からストレージADRを再計算する

    この課題では統合・補強して扱います。

12. 分離異常を再現し、abortとretryまで設計する

    この課題では統合・補強して扱います。

13. 重複・順序・分断を再現し復旧境界を設計する

    この課題では統合・補強して扱います。

14. 負荷曲線と実測profileから安全容量を判断する

    この課題では統合・補強して扱います。

15. 利用者journeyからSLI、SLO、alert、runbookを導く

    この課題では統合・補強して扱います。

16. 読者の判断を支える設計文書とADRを構成する

    主評価: 同じmigration evidenceを経営・監査・実装・operations向けviewへ再構成して判断可能性を検証する

17. 倫理・privacy・社会的影響を設計制約へ変える

    この課題では統合・補強して扱います。

18. 未知を残したままlegacy systemを安全に変更する

    主評価: 編集前に実行経路、変更理由、未知領域を地図化し、characterization testで現行挙動を再現する

19. 互換性を保つschema migrationを段階実行する

    主評価: expand、backfill、dual read、cutover、contractへ観測・停止・rollback条件を割り当て実行する

20. incident responseを検証可能な学習へ変える

    主評価: migration incidentのimpact、timeline、decision、寄与要因、検証可能な対策を追跡してreviewを更新する

21. CI・段階配信・supply chainを結果証拠で閉じる

    この課題では統合・補強して扱います。

22. engineering economicsで信頼性と容量へ投資する

    主評価: engineering・operations時間、capacity、reliability、機会費用、感度を比較して投資案を再評価する

23. コードレビューを協働品質システムとして運営する

    この課題では統合・補強して扱います。

24. チームインターフェースで社会技術アーキテクチャを設計する

    主評価: owner、capability、dependency、cognitive load、SLO、enablementをteam interfaceとして検証する

25. 時差と言語を越える非同期RFCを設計する

    この課題では統合・補強して扱います。

26. 証拠と撤退条件で技術方針を率いる

    この課題では統合・補強して扱います。

評価基準