S rollbackom od nekoliko sekundi mogli smo s PHP-a na Node preći danju

Četiri godine bio sam tehnički lider na američkom marketplaceu i za to vrijeme zamijenili smo jezik, framework, hosting i mobilni stack. Korisnici nikad nisu vidjeli stranicu koja ne radi.

Neobično je bilo to što smo migraciju mogli poništiti za nekoliko sekundi, u bilo kojem trenutku i bez deploya. To je promijenilo kako smo vodili migraciju.

Migracija traži tri stvari:

1. Prebacivanje podataka u novi oblik
2. Usklađenost oba sistema dok rade uporedo
3. Put nazad ako novi sistem ne valja

Većina planova pokriva prvo, a dobri pokrivaju i drugo. Treće obično nedostaje i zato se migracije zakazuju za 2 ujutro u nedjelju. Posao noću nije ništa drugačiji, ali svi znaju da za povratak nema plana ako nešto pođe po zlu.

Uzeli smo dump stare baze i napisali skriptu koja ga je učitala u novu, usput preslikavajući kolone i strukturu.

Taj dio je bio uobičajen, uz jedan izuzetak: odlučili smo zadržati isti database engine. Promijenili su se jezik, framework, hosting i mobilni stack. Da se promijenila i baza, ne bismo imali ništa stalno s čim bismo novi sistem mogli porediti kad provjeravamo ponaša li se kao stari.

Pošto su se mijenjale četiri stvari, samo smo uz petu koja je ostala ista mogli znati koja je od te četiri nešto pokvarila.

Na ovo smo potrošili najviše razmišljanja, a razlog nije bio tehnički.

Web smo kontrolisali. Korisnik weba dobije novu verziju pri sljedećem učitavanju stranice, pa smo web mogli prebaciti. Telefone nismo kontrolisali. Korisnik mobilne aplikacije ažurira kad mu se prohtije, a stare aplikacije nisu imale način da korisnicima jave da postoji nova verzija. Nove aplikacije objavili smo u oba storea, ali aplikacija koja je već instalirana na nečijem telefonu to ne zna.

Da smo ugasili stari backend, pokvarili bismo softver koji je radio na desetinama hiljada uređaja. Zato je stari sistem morao nastaviti raditi, a stari i novi sistem morali su se slagati.

Na staru bazu postavili smo triggere koji su njene upise prosljeđivali u novu, a isto smo uradili i u obrnutom smjeru. Oglas napravljen u novom sistemu pojavio se u starom, a oglas napravljen u starom sistemu pojavio se u novom. Dvije šeme bile su usklađene u produkciji više od godinu dana.

Sinhronizacija u jednom smjeru bila bi lakša, ali bi bila pogrešna. Korisnici mobilnih aplikacija i dalje su pravili i mijenjali zapise, pa bi bez povratnog smjera novi sistem odmah zastario, i to na mjestima koja su bila bitna.

Za gašenje starog sistema nismo odredili datum. Ugasili smo ga kad je analitika pokazala da je saobraćaj prema njemu pao na nulu, što je značilo da je i posljednji korisnik prestao koristiti staru mobilnu aplikaciju.

To je trajalo više od godinu dana i bila je to ispravna odluka. Svaki datum koji bismo odabrali bio bi nagađanje. Mjerenje je pokazalo da su ljudi staru aplikaciju koristili još dugo nakon što smo se nadali da će prestati.

Ako planirate gašenje sistema, vežite ga za ovakvu metriku.

Naš rollback bio je promjena origina na CDN-u, koja je trajala nekoliko sekundi i nije tražila ni deploy ni build.

Ono što vrijedi preuzeti radi i bez CDN-a: put nazad ne smije zavisiti od onoga što vraćate. Ako povratak traži deploy, a deploy pipeline je dio onoga što ste promijenili, put nazad nije nimalo pouzdaniji od promjene koju pokušavate poništiti.

Postavite jedno pitanje o svom planu: ako se u utorak u 15 sati pokaže da novi sistem ne valja, kojim nizom koraka se vraćamo na stari i koliko to traje? Ako odgovor uključuje build, prespor je. Ako odgovor uključuje osobu koja je na godišnjem odmoru, to nije odgovor.

Nisam očekivao da će rollback promijeniti i to kad radimo. Kad se na stari sistem možete vratiti za nekoliko sekundi, migrirate danju: u utorak, dok su svi budni i tim prati šta se dešava, kad neko iz podrške može podići telefon i nijedan inženjer ne mora rješavati problem u 3 ujutro.

Za rad usred dana trebalo je samopouzdanja, a imali smo ga zahvaljujući tome kako je migracija bila postavljena. Promjena koju možete odmah poništiti mnogo je manje rizična od one koju ne možete, pa ne traži toliko formalnosti.

Sinhronizacija je radila više od godinu dana, što je bilo ispravno, ali nikad nismo zapisali šta bismo uradili da se dva sistema raziđu. Nisu se razišli, a to je bilo koliko do dizajna, toliko i do sreće. Redovna provjera usklađenosti, koja poredi broj zapisa i checksume u oba sistema, ne košta skoro ništa, a ono što smo samo pretpostavljali, da se sistemi slažu, postalo bi provjerena činjenica.