Fiecare server are o durată de viață. Generațiile de hardware evoluează, nevoile de capacitate se schimbă, un site depășește mașina pe care a fost lansat sau pur și simplu apare un loc mai bun pentru el. Mutarea unui site de pe un server pe altul e una dintre cele mai obișnuite operațiuni din găzduire și, în același timp, una dintre cele mai temute, chiar dacă nimeni n-o recunoaște, pentru că varianta ei tradițională înseamnă o pagină de mentenanță, un weekend pierdut și un șir de ore în care nimeni nu știe exact ce server vede un anumit vizitator.
Ne-am construit platforma astfel încât o migrare să nu mai arate așa. Mutăm site-uri live de pe un server pe altul fără nicio întrerupere vizibilă pentru vizitatori: fără pagină de mentenanță, fără anunț, fără intervenție în toiul nopții. Site-ul continuă să răspundă de pe serverul vechi până când cel nou e verificat și gata, iar apoi traficul comută într-o clipă. Am făcut asta pe site-uri de producție, inclusiv pe un magazin online cu trafic intens, în mijlocul unei săptămâni normale.
Articolul de față explică cum funcționează și, mai important, de ce schimbă felul în care se iau deciziile de infrastructură.
Vechea capcană: propagarea DNS
Ca să înțelegi ce am schimbat, ajută să vezi de unde vine, de obicei, durerea de cap. Într-o migrare clasică, adresa site-ului tău, adică înregistrarea lui DNS, arată direct către serverul vechi. Mutarea înseamnă să schimbi acea înregistrare ca să arate către cel nou. Problema e că schimbările DNS nu intră în vigoare peste tot deodată. Resolverele din întreaga lume păstrează în cache vechiul răspuns și fiecare renunță la el când vrea, în decurs de minute sau ore.
Decalajul ăsta e capcana. În timpul propagării, unii vizitatori ajung pe serverul vechi și alții pe cel nou, iar orice se schimbă pe o parte, o comandă, un formular trimis, un comentariu, e invizibil pe cealaltă. Soluțiile clasice sunt toate neplăcute: îngheți site-ul ca să nu se mai poată schimba nimic, pui o pagină de mentenanță sau programezi toată operațiunea la cea mai liniștită oră pe care o găsești și accepți că la capete tot se va încurca ceva. Migrarea în sine poate dura o oră; perioada de incertitudine e cea care mănâncă weekendul.
Cu traficul prin edge, problema arată cu totul altfel
Pe platforma noastră, DNS-ul nu arată către serverul pe care se află la un moment dat un site. Arată către edge, stratul de trafic pe care îl rulăm în fața fiecărui site găzduit. Edge-ul preia conexiunea securizată, aplică protecții precum firewall-ul de aplicații web și gestionarea boților, apoi trimite fiecare cerere către serverul care rulează site-ul în acel moment.
Un singur strat intermediar, și capcana dispare. Când un site se mută, adresa lui publică nu se schimbă deloc, așa că restul internetului nu are nimic de propagat. Singurul lucru care se schimbă e o decizie internă de rutare la edge-ul nostru: cererile pentru site-ul ăsta merg de acum către serverul nou, nu către cel vechi. Decizia intră în vigoare pentru toți vizitatorii în același moment, pentru că se ia într-un singur loc pe care îl controlăm, nu în mii de cache-uri pe care nu le controlăm.
Cum se desfășoară de fapt o mutare
Odată rezolvată problema adresării, migrarea în sine devine o succesiune de pași atenți, fără grabă. Pregătim mai întâi site-ul pe serverul de destinație: aceleași containere securizate, aceeași configurație, construite din aceleași definiții ca originalul, pentru că tot ce ține de felul în care rulează un site e descris în formă versionată, nu adunat manual pe o singură mașină. Apoi aducem datele pe noul server și verificăm rezultatul, în timp ce serverul vechi continuă să servească fiecare vizitator, iar nimeni nu simte nimic.
Verificarea e pasul pe care refuzăm să îl grăbim. Înainte să mutăm orice trafic, comparăm noul mediu cu site-ul care rulează: aplicația pornește, conținutul e prezent, integrările răspund, certificatele sunt în ordine. Abia când serverul nou a demonstrat că e pregătit, edge-ul comută traficul, instantaneu și pentru toată lumea. O sincronizare finală închide micul decalaj acumulat în timpul comutării, și mutarea e gata.
Observă ce lipsește din succesiunea asta: o pagină de mentenanță, un site înghețat, un salt în gol. Până în clipa comutării, serverul vechi are controlul deplin. Din clipa următoare, îl are cel nou. Nu există o perioadă intermediară în care site-ul să fie mutat pe jumătate, iar dacă verificarea ar fi scos la iveală o problemă, comutarea pur și simplu nu ar fi avut loc, fără ca vizitatorii să bănuiască ceva.
Facem asta pe site-uri live, în zilele lucrătoare
Pe hârtie orice procedură sună bine, așa că merită spus că nu vorbim despre o capacitate teoretică. Am mutat site-uri de producție între servere în acest fel, inclusiv un magazin online unde fiecare minut de întrerupere înseamnă comenzi pierdute, și am făcut-o la mijlocul săptămânii, în timpul programului normal, fără pagină de mentenanță. Vizitatorii au navigat și au cumpărat pe toată durata operațiunii. Pentru proprietarul magazinului, migrarea s-a rezumat la un mesaj de la noi care anunța că s-a încheiat.
Faptul că facem asta în timpul săptămânii, în loc să o ascundem în toiul nopții, într-un weekend, e o alegere deliberată. O operațiune care e sigură doar când nu se uită nimeni nu e cu adevărat sigură; e doar neobservată. Pentru că procedura ține site-ul disponibil fără pauză, o putem rula când toată echipa noastră e odihnită și prezentă, adică exact momentul în care vrei ca cineva să facă verificările finale. La două după-amiaza, oamenii sunt pur și simplu mai atenți decât la două noaptea.
Reversibilitatea e adevăratul câștig
Lipsa întreruperilor e partea pe care o observă clienții, dar câștigul mai profund e efectul asupra deciziilor. Când mutarea e riscantă, alegerile de infrastructură încremenesc. Un site rămâne pe un server învechit nu pentru că ar crede cineva că e cel mai bun loc pentru el, ci pentru că migrarea pare o operație pe cord deschis și nimeni nu vrea să programeze una fără un motiv presant. Hardware mai bun, o amplasare mai bună, costuri mai mici: toate așteaptă o mutare care se tot amână.
Când mutarea devine rutină, deciziile astea se redeschid. O generație de servere cu performanță mai bună la același preț merită adoptată, pentru că ne costă o după-amiază din timpul nostru și nimic din al tău. Reechilibrarea site-urilor între mașini, retragerea hardware-ului vechi când decidem noi, nu când cedează el, mutarea unui site în creștere pe un server mai puternic înainte să îl forțeze pe cel actual: toate acestea devin întreținere de rutină, nu un proiect cu registru de riscuri. Și pentru că edge-ul poate comuta traficul în oricare direcție, chiar și mutarea în sine rămâne reversibilă până în clipa în care noul server și-a dovedit fiabilitatea.
Infrastructura ar trebui să rămână o alegere
Ideea cu care am vrea să rămâi nu ține de fapt de migrări. Ține de ce schimbă mobilitatea pentru o relație de găzduire. Un site care se poate muta liber nu e niciodată ostaticul mașinii de sub el. Serverul devine ce ar fi trebuit să fie dintotdeauna: o componentă înlocuibilă în slujba site-ului, aleasă pe merit și înlocuită fără fasoane când apare ceva mai bun.
Ăsta e standardul după care ne judecăm propria platformă. Cel mai bun semn că o migrare a reușit e că nimeni din afara echipei nu are vreodată vreun motiv să afle că a avut loc.