Dio migracije koji svi preskaču: put nazad

Četiri godine smo proveli u tehničkom vodstvu na američkom marketplaceu, i za to vrijeme smo zamijenili jezik, framework, hosting i mobilni stack. Korisnici nikada nisu vidjeli stranicu koja ne radi.

Zanimljivo nije to što smo migrirali. Svi migriraju. Zanimljivo je to što smo sve mogli poništiti za nekoliko sekundi, u bilo kojem trenutku, bez deploya — a to je promijenilo način na koji je cijela stvar odrađena.

Tri dijela, i onaj koji nedostaje

Migracija traži tri stvari:

1. Prebacivanje podataka u novi oblik
2. Održavanje oba sistema usklađenim dok rade uporedo
3. Put nazad ako je novi pogrešan

Većina planova ima prvo. Dobri imaju drugo. Treće je razlog zašto se migracije zakazuju za 2 ujutro u nedjelju — ne zato što je posao noću drugačiji, nego zato što svi znaju da, ako pođe po zlu, plana nema, nego samo duga večer.

Prebacivanje podataka

Uzeli smo dump stare baze i napisali skriptu koja ga je učitala u novu, uz preslikavanje kolona i strukture usput.

To je onaj uobičajeni dio, uz jednu odluku koju vrijedi imenovati: namjerno smo zadržali isti database engine. Jezik se promijenio, framework se promijenio, hosting se promijenio, mobilni stack se promijenio. Da se promijenila i baza, ne bi postojala nijedna fiksna tačka prema kojoj bi se provjerilo da se novi sistem ponaša kao stari.

Kada mijenjate četiri stvari, petu držite mirno. To je jedini način da se zna koja je od te četiri nešto pokvarila.

Održavanje oba usklađenim

Ovdje je otišao najveći dio razmišljanja, a razlog nije bio tehnički.

Web smo kontrolisali. Web korisnik dobije novu verziju pri sljedećem učitavanju stranice, pa se web mogao prebaciti odjednom. Telefone nismo kontrolisali. Mobilni korisnik se ažurira kada mu se prohtije, a stare aplikacije nisu imale mehanizam da mu kažu da nova postoji — objavili smo nove aplikacije na oba storea, ali aplikacija koja je već instalirana na nečijem telefonu to ne zna.

Gašenje starog backenda pokvarilo bi softver koji radi na velikoj instaliranoj bazi uređaja. Zato je stari sistem morao nastaviti raditi, što je značilo da se stari i novi moraju slagati.

Na staru bazu smo postavili trigere koji su upise prosljeđivali u novu — i isto to u obrnutom smjeru. Oglas kreiran u novom sistemu pojavio bi se u starom, a oglas kreiran u starom pojavio bi se u novom. Dvije sheme, održavane usklađenim, u produkciji, više od godinu dana.

stare mobilne aplikacije                  web + nove aplikacije
           │                                        │
           ▼                                        ▼
    ┌──────────────┐  trigeri, u oba smjera  ┌──────────────┐
    │  stara baza  │◄───────────────────────►│  nova baza   │
    └──────────────┘                         └──────────────┘
      radilo je preko godinu dana, dok saobraćaj ka staroj strani nije pao na nulu

Jednosmjerna sinhronizacija bila bi lakša i bila bi pogrešna. Mobilni korisnici su i dalje kreirali i mijenjali zapise; bez povratnog puta, novi sistem bi odmah bio zastario tačno na mjestima koja su bila bitna.

Znati kada stati

Stari sistem nismo ugasili na datum. Ugasili smo ga kada je analitika pokazala da je saobraćaj prema njemu pao na nulu — kada je posljednji korisnik stare mobilne aplikacije prestao.

To je trajalo više od godinu dana, i bila je to ispravna odluka. Datum je nagađanje obučeno u plan. Mjerenje je činjenica, a činjenica je bila da su ljudi nastavili koristiti staru aplikaciju dugo nakon što bismo voljeli da su prestali.

Ako vaše gašenje ima datum a nema mjeru, nemate plan, imate nadu.

Put nazad

Naš rollback je bila promjena origina na CDN-u. Sekunde. Bez deploya, bez builda, bez čekanja.

To svojstvo je ono što vrijedi kopirati, a ne radi se konkretno o CDN-u. Radi se o tome da put za rollback ne smije ovisiti o onome što vraćate unazad. Ako povratak traži deploy, a deploy pipeline je dio onoga što ste promijenili, onda je vaš put nazad tačno onoliko pouzdan koliko i promjena koju pokušavate poništiti.

Postavite jedno pitanje o vlastitom planu: ako je novi sistem pogrešan u 15 sati u utorak, koji je niz radnji koji nas vraća na stari, i koliko to traje? Ako odgovor uključuje build, prespor je. Ako odgovor uključuje osobu koja je na godišnjem, to nije odgovor.

Šta mijenja to što postoji put nazad

Ovo je dio koji nismo očekivali.

Kada je rollback udaljen nekoliko sekundi, migrirate tokom dana. Radite to dok su svi budni, uz tim koji gleda, u utorak, kada osoba iz podrške može podići telefon, a inženjer ne razmišlja u 3 ujutro.

Samopouzdanje nije razmetanje — strukturno je. Promjena koju možete poništiti trenutno je druga klasa rizika od one koju ne možete, i zaslužuje drugu klasu ceremonije.

Šta bismo uradili drugačije

Sinhronizacija je radila više od godinu dana, što je bilo ispravno, ali nikada nismo zapisali šta bismo uradili da se dva sistema raziđu. Nisu se razišla, a to je bila sreća koliko i dizajn. Provjera usklađenosti — poređenje brojeva zapisa i checksuma između njih dva po rasporedu — košta gotovo ništa i pretvara „slažu se“ iz pretpostavke u činjenicu.

Ovo je nastalo iz četiri godine tehničkog vodstva na američkom marketplaceu, gdje je isti period dao i analitički sloj koji prima dva miliona upisa dnevno. Pročitajte studiju →