Rollback — передумова, а не фінальний пункт

Rollback-план має існувати до pilot, тому що після зміни може бути пізно зʼясовувати, як повернути code, configuration, data і traffic. Для кожної поверхні вкажіть checkpoint, trigger, owner, команду або процедуру та спосіб перевірити відновлення.

Code rollback і state rollback — різні речі. Повернення branch або artifact не скасовує вже виконаний backfill, змінений schema state, зовнішній side effect чи несумісний config. Якщо state recovery не доведений, рішення має бути HOLD.

Rollback matrix

ПоверхняTriggerПоверненняПеревіркаМежа
Code/artifactfailed check або critical regressionпопередній revision/artifactdiff і smoke signalне відміняє state changes
Configurationstartup/config mismatchпопередня versioned configstartup і representative flowsecrets не копіювати в docs
Data/schemainvariant або read failureapproved backout/forward-fixintegrity та compatibility checksможе бути irreversible
Traffic/routingerror rate або parity discrepancyswitch до source pathrouting і output comparisonпотрібен owner
Decisionневідомий recovery pathHOLD без pilotотримати missing evidenceне маскувати Unknown

Поля, без яких rollback не є планом

  • точка, з якої можна відновити source state;
  • конкретний observable trigger і поріг рішення;
  • відповідальний owner та канал ескалації;
  • порядок code/config/data/routing actions;
  • перевірка після rollback і умова, коли потрібен forward-fix;
  • явна позначка irreversible або неперевірених операцій.

Stop condition для pilot

MIGRATION_PLAN.md — documented example
## Rollback gate
- Trigger: behavior discrepancy, integrity failure, or unavailable recovery evidence
- Owner: migration decision owner
- Code action: return to source checkpoint
- Config/data action: <approved procedure — Unknown until verified>
- Verification: compare representative flow and invariants
- Decision: HOLD until all recovery steps are verified

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush