Rollback ability

Może trochę z tematyki bardziej podchodzącej pod site reliability eng., ale jakie kojarzycie/używacie najpraktyczniejsze sposoby zapewniania możliwości zrobienia rollbacka w każdym momencie, nawet jeżeli nowe dane nie są kompatybilne ze starym kodem?

Jedyne co mi przychodzi na myśl, to konwerter (np. sql) który 'naprawi' dane, ale przecież nie zawsze jest to możliwe

Jakieś ciekawe pomysły od strony kodu, aby to ułatwić / umożliwić?

A co dla Ciebie znaczy rollback?

Widzę dwa podstawowe pojęcia:

• point of no return (PONR) - punkt po osiągnięciu którego nie zrobimy rollbacku, bo się nie da/jest to zbyt przerażające/kosztowne/inny powód,
• rollback - przywracamy stan na jakiś wybrany punkt w czasie

Po PONR nie mamy zbyt dużego wyboru -> jesteśmy na produkcji i produkcja właśnie płonie -> wymyślamy kreatywne rozwiązywanie problemu. Im bardziej płonie, tym bardziej brawurowe pomysły są akceptowane, zaś najgłupsze sugestie (o ile dają nadzieję) znajdują posłuch.

Decyzja o rollbacku oznacza tyle, że akceptujemy szkodę i staramy się minimalizować straty biznesu/wpływ na klientów.
Technicznie korzystamy z mechanizmów standardowych:

• snapshot danych - silniki bazodanowe potrafią takie rollbacki (hasło: point in time recovery)
• systemy plików też potrafią (np. ZFS snapshots)

Mamy też ogólny problem -> "co zrobić z deltą, która się nazbierała od momentu wdrożenia nowego rozwiązania do momentu podjęcia decyzji o rollbacku?".
O ile mi wiadomo, to nie ma ogólnego rozwiązania takiego problemu, bo to czym jest "delta", zależy od konkretnego sytuacji (zmiany w jednym systemie mogą wyzwalać zmiany w innych systemach - tak działa integracja). Co zrobić? To jest decyzja biznesowa.

Technicznie:

• wypada takie delty zbierać, bądź być w stanie je zidentyfikować i później (pół)automatycznie przetworzyć (np. usunąć dane z systemu dla tych obiektów i odtworzyć akcje biznesowe używając "starego API"/wykonać dla takich danych inne, zdefiniowane przez biznes, akcje),
• można zaprojektować system w taki sposób, by wspierał wersjonowanie workfow (procesów biznesowych) (tj. stare dane są przetwarzane wg starej logiki, a nowe wg nowej) - w konfiguracji trzymamy informacje o tym, która wersja workflow jest obecnie tą obowiązującą. W ramach rollbacku przepinamy wersję na poprzednią, zaś "delta" encji dotkniętych rollbackiem jest analizowana i obsługiwana w ramch procesu utrzymaniowego (hasło: business process versioning),
• można zaprojektować akcje kompensacyjne.

Pewnie są produkty, dla których można mieć inne strategie. W projekcie, w którym jestem obecnie, mamy przewidziany cały proces biznesowy do przygotowania się na konieczność wykonania "rollbacku" i osobny proces do wykonania samego rollbacku. Jest tam sporo czynności manualnych, sporo wspomaganych skryptami. Koszt zbudowania i przetestowania automatu byłby zbyt duży, a ryzyko błędnego działania nie byłoby znacząco mniejsze.

W bardzo dużym skrócie bo to temat rzeka:

Najpraktyczniejszy jest sposób, podejście Forward Only. Nie ma możliwości zrobienia rollbacka (o dzień, dwa). Koniec. reagujesz na bieżąco i monitorujesz. Jeśli chodzi o skalę nieco mniejszą, np Blue/Green deployment, to owszem, spoko podejście i też się da. Tu pomagać mogą feature toggle też i nie mówimy o rollbacku na rok wstecz.
Dark deployment - tak to się chyba nazywa też może być pomocny.
Pomocny też może być Event Sourcing jako wybór architektury.

Generalnie, na poziomie samej infrastruktury załatwić się tego nie da i trzeba od razu tak zaprojektować aplikacje by się dało to w jakiś sposób wspierać. Wyżej wymienione podejścia pomagają. No i można i należy je ze sobą łączyć. Ale trzeba wiedzieć co chce się chce osiągnąć i dlaczego.

Np Jak jest dużo bugów które "psują dane" to problem pewnie leży gdzieś indziej i nie tylko rollback jest tu potrzebny.
Jak to wymóg biznesowy, to możliwe że Event Sourcing pomoże, dane nie znikną, a za jakiś czas zrobi się deployment który zapisane eventy "przeprocesuje" w inny sposób.

Ale gdybać sobie można, kluczowa kwestia to "po co".

Dzięki za podzielenie się wiedzą ;)