Команда відновлення як частина дизайну, а не аварійний скрипт після помилки

У багатьох системах є дані, які не є первинною правдою, але потрібні для швидкої роботи.

Це можуть бути лічильники, денормалізовані підсумки, проєкції, пошукові індекси, кешовані агрегати або допоміжні таблиці для читання.

Поки все працює правильно, вони майже непомітні. Але після пропущеної події, збою черги, помилки в коді або невдалого розгортання похідний стан може розійтися з канонічними даними.

Якщо система не має штатного способу це перевірити й виправити, команда відновлення з’являється вже під час інциденту - поспіхом і без достатніх гарантій.

Відновлення можливе лише тоді, коли зрозуміло, з чого саме треба відтворювати стан.

Наприклад, кількість непрочитаних повідомлень може бути похідною від самих повідомлень і записів про прочитання. Пошуковий індекс - від основних сутностей. Денний підсумок - від окремих операцій.

Якщо похідне поле починає містити унікальну інформацію, якої більше ніде немає, воно вже перестає бути безпечно відновлюваним.

Важливо не стрибати одразу до запису нового значення.

Спочатку система повинна вміти обчислити очікуваний стан без змін. Потім порівняти його з тим, що збережено. І лише після цього - виконати контрольоване виправлення.

Так одна й та сама логіка може використовуватись для діагностики, моніторингу, ручної перевірки й самого відновлення.

Такий сервіс легко викликати з команди, тесту, адміністративної перевірки або фонового завдання.

Якщо перерахунок одразу змінює дані, стає складніше зрозуміти масштаб розбіжності до виправлення.

Режим лише перевірки особливо важливий для великих наборів даних.

Він дозволяє спочатку відповісти на питання: скільки записів пошкоджено, наскільки велика різниця, чи проблема локальна, чи системна.

Це значно безпечніше, ніж запускати команду, яка одразу переписує тисячі рядків.

Типовий запуск без параметрів може бути лише діагностичним.

Для реального запису потрібен явний прапорець. Це зменшує ризик випадкового масового виправлення під час перевірки.

Якщо команда вже відновила правильний стан, повторний запуск не повинен створювати нових змін.

Для похідних значень це природна властивість: ми щоразу обчислюємо очікуваний результат із канонічних даних і приводимо збережене значення до нього.

Повний перерахунок усієї системи не завжди потрібен.

Практично корисно мати можливість обмежити перевірку одним користувачем, одним агрегатом, часовим діапазоном, конкретною сутністю або невеликим набором ідентифікаторів.

Це пришвидшує діагностику й зменшує ризик під час точкового виправлення.

Для великої таблиці краще працювати пакетами, фіксувати прогрес і не тримати блокування довше, ніж потрібно.

У деяких випадках перед записом варто ще раз прочитати актуальний канонічний стан, щоб не перезаписати зміни, які відбулися під час довгого перерахунку.

Пошуковий індекс часто повністю відновлюваний з основної бази даних.

Тому поряд із інкрементальним оновленням корисно мати штатний повний перерахунок: побудувати очікувані документи, перевірити відсутні або зайві записи й за потреби переіндексувати їх.

Якщо є лише код "оновити індекс після зміни моделі", але немає способу відтворити весь індекс, система сильніше залежить від того, що жодна подія ніколи не буде пропущена.

Проєкції зручні саме тому, що оптимізують читання. Але оптимізація не повинна робити дані невиправними.

Якщо проєкція будується з подій або основних таблиць, механізм її побудови краще оформити так, щоб його можна було викликати не тільки під час звичайного потоку, а й для повного відтворення.

Наявність штатного відновлення не означає, що розбіжності можна ігнорувати.

Якщо команда постійно знаходить один і той самий тип розбіжності, треба виправляти причину: втрачену подію, некоректний обробник, стан гонитви, неповну транзакцію або неправильну модель оновлення.

Шлях відновлення потрібен як страховка й інструмент відновлення, а не як регулярна заміна правильної бізнесової логіки.

Якщо порівняння відокремлене від запису, його можна запускати періодично для вибірки або критичних агрегатів.

Так система може помітити розбіжність до того, як її побачить користувач.

Але частота й обсяг такої перевірки повинні відповідати вартості запиту й важливості даних.

Лічильник, проєкція або індекс можуть бути дуже зручними, але вони стають безпечнішими, коли система знає, як перевірити їх проти канонічних даних.

Тоді інцидент не починається з написання одноразового скрипта. Уже є перевірений шлях: обчислити очікуване значення, показати різницю, обмежити область і виконати ідемпотентне виправлення.

Якщо дані можна відтворити, здатність їх відтворити варто проєктувати разом із самими похідними даними.