Dublējuma atjaunošanas gadījuma izpēte: atgriežoties 6 stundas atpakaļ
Publicēts 2026. gada 10. jūlijā
02:14 UTC interneta veikals pārtrauca ierakstīt pasūtījumus datubāzē. Līdz 02:19 vietne joprojām apkalpoja kešatmiņā saglabātās lapas, taču norēķināšanās jau bija kļuvusi par fikciju. Šī dublējuma atjaunošanas gadījuma izpēte apraksta, kas notika tālāk produkcijas VPS mazam e-komercijas uzņēmumam, ko mēs atjaunojām, ko mēs neatjaunojām akli un kāpēc pakalpojums atkal bija stabils vēl pirms saullēkta.
Klientam bija samērā standarta steks augošam tiešsaistes veikalam - Nginx, PHP-FPM, MariaDB, Redis un vadības panelis, ko izmantoja divi darbinieki bez sistēmadministratora pieredzes. Datplūsma nebija milzīga, taču laiks bija sāpīgs. Izpārdošanas kampaņa bija palielinājusi pasūtījumu apjomu, datubāzes ieraksti sasniedza maksimumu, un glabātuves problēma failu sistēmas līmenī sāka bojāt aktīvās datubāzes tabulas. Ne gluži Holivudas stila drāma, bet pietiekami nopietni, lai katra minūte būtu svarīga.
Pirmais uzdevums nebija atjaunošana. Pirmais uzdevums bija apturēt bojājumu izplatīšanos. Mēs ieslēdzām lietotni apkopes režīmā, saglabājām pašreizējo diska stāvokli pārskatīšanai un pārbaudījām, vai replikācija, momentuzņēmumi vai loģiskie izmetumi mums sniedz tīrāko atjaunošanas punktu. Tas ir svarīgāk, nekā cilvēkiem patīk atzīt. Ātra atjauno šana ir laba. Ātra atjaunošana uz bojātiem datiem ir tikai ātra vilšanās.
Kas neizdevās un kā mēs to sapratām
Žurnāli tagad stāstīja vienu un to pašu stāstu. MariaDB sāka ziņot par InnoDB lapu kontrolsummu kļūdām, kam sekoja tabulu avārijas rakstīšanas ziņā noslogotajās pasūtījumu un sesiju tabulās. Pats hipervizors bija vesels. CPU, RAM un tīkla uzvedība palika normāla. Tas sašaurināja notikumu no plašas platformas atteices uz viesa līmeņa glabātuves integritāti.
Pirms pieskārāmies dublējumiem, mēs pārbaudījām trīs lietas. Pirmkārt, vai problēma bija izolēta nelielam tabulu kopumam un vai to varēja salabot uz vietas. Otrkārt, vai nesenie dublējumi bija derīgi un piemontējami. Treškārt, vai kādus darījumus, kas tika pabeigti pēc pēdējā zināmā labā dublējuma, varēja rekonstruēt no lietotnes žurnāliem, e-pasta apstiprinājumiem vai maksājumu vārtejas ierakstiem.
Šo trešo pārbaudi bieži izlaiž. Nevajadzētu. Dublējuma atjaunošana nav visa atkopšana. Uzņēmumiem rūp trūkstoši pasūtījumi, klientu ieraksti un rēķinu stāvoklis, nevis tikai tas, vai MySQL atkal startē.
Atjaunošanas ceļš, ko mēs izvēlējāmies
Šī dublējuma atjaunošanas gadījuma izpēte ir noderīga tāpēc, ka acīmredzamā izvēle nebija labākā izvēle. Mums bija trīs iespējamie ceļi.
Pilna VM momentuzņēmuma atritināšana klikšķu skaita ziņā būtu bijusi visātrākā, taču tā arī izmestu vairākas stundas leģitīmu satura izmaiņu, spraudņu atjauninājumu un klientu kontu labojumu. Tabulu labošanai uz vietas bija pārāk liels risks, jo bojājums jau bija skāris galvenos transakciju datus. Labāks ceļš bija atjaunošana failu un datubāzes līmenī jaunā instancē, kam sekoja selektīva datu saskaņošana.
Tāpēc vispirms mēs izveidojām tīru atjaunošanas vidi. Tas pats VPS izmērs, tā pati OS saime, tā pati paneļa versija, tas pats PHP atzars. Pārbūve paralēlā instancē dod elpas telpu. Tā arī aizsargā sākotnējo sistēmu kriminālistiskai pārskatīšanai, kas ir noderīgi, ja klientam jāsaprot pamatcēlonis vai jāpārbauda, ka problēmu nav izraisījusi lietotnes uzvedība.
Mēs paņēmām pēdējo veiksmīgo automātisko dublējumu no 23:00 UTC. Tad mēs to pārbaudījām pirms pārslēgšanas. Tas izklausās elementāri, taču daudzas komandas par dublējumu problēmām uzzina tikai vissliktākajā iespējamajā stundā. Arhīvs piemontējās pareizi, kontrolsummas sakrita, datubāzes imports pabeidzās bez kļūdām, un lietotne izolācijā palaidās. Labi. Miers sākas tur.
Pakalpojuma atjaunošana, neradot jaunas problēmas
Atkopšanai bija četri posmi. Pirmkārt, infrastruktūra. Mēs pārbūvējām tīmekļa steku, piemērojām jau apstiprinātos sistēmas atjauninājumus un saskaņojām izpildlaika versijas, lai lietotne neizgāztos negaidītas atkarību neatbilstības dēļ.
Otrkārt, dati. Datubāzes atjaunošana pabeidzās 11 minūtēs. Tīmekļa faili tika atjaunoti mazāk nekā 4 minūtēs. Multivides līdzekļi bija neskarti, kas klientu pasargāja no bojātiem produktu attēliem un dusmīgajiem pārlūka lodziņiem. Redis netika atjaunots no dublējuma, jo kešatmiņas dati pēc būtības ir vienreizlietojami. Vecas kešatmiņas atgriešana jaunā vidē ir viena no tām mazajām kļūdām, kas vēlāk rada lielu jucekli.
Treškārt, validācija. Mēs pārbaudījām pieteikšanos lietotnē, norēķināšanās plūsmu, administratora ierakstus, cron izpildi, SSL derīgumu, izejošo pastu un maksājumu vārtejas atgriezenisko izsaukumu uzvedību. Mēs arī salīdzinājām ierakstu skaitu pasūtījumu, klientu un kataloga tabulās ar gaidāmajām izaugsmes līknēm no iepriekšējās nedēļas. Skaitļiem nav jābūt nevainojamai dzejai, taču tiem nevajadzētu izskatīties dīvaini.
Ceturtkārt, saskaņošana. Laikā no 23:00 UTC līdz 02:14 UTC tika apstrādāti daži veiksmīgi maksājumi. Šie ieraksti atjaunotajā datubāzē neeksistēja, jo tie notika pēc dublējuma punkta. Mēs tos atjaunojām no maksājumu pakalpojumu sniedzēja apstiprinājumiem, e-pasta pasūtījumu paziņojumiem un tīmekļa piekļuves žurnāliem. Tieši šeit pieredzējis operators ietaupa uzņēmumam daudz sāpju. Tehniski veiksmīga atjaunošana, kurā pazūd apmaksāti pasūtījumi, patiesībā nav veiksme.
Līdz 03:41 UTC lietotne bija pieejama klienta iekšējai pārskatīšanai. Līdz 04:06 UTC DNS un malas maršrutēšana novirzīja produkcijas datplūsmu atpakaļ uz atjaunoto instanci. Kopējie klientiem redzamie norēķināšanās traucējumi bija nedaudz mazāki par divām stundām, kamēr lasīšanas piekļuve lielākajai daļai vietnes bija pieejama lielā incidenta daļā.
Kas padarīja atkopšanu ātru
Tā nebija veiksme, un tā nebija viena maģiska dublējuma poga. Ātrums radās no sagatavošanās un no lēmumu skaita samazināšanas incidenta laikā.
Klientam jau bija automātiski plānoti dublējumi ar saglabāšanas periodu, uzraudzīta servera uzvedība un atbalsta ceļš, kas nepazuda biļešu klusumā. Tas mainīja nakts gaitu. Mēs nestrīdējāmies par to, vai dublējums eksistē. Mēs izvēlējāmies drošāko atjaunošanas punktu un to validējām.
Nozīme bija arī vides konsekvencei. Tā kā hostinga steks bija standartizēts, mēs nepavadījām 45 nervozas minūtes, atklājot, ka atjaunotajai lietotnei vajadzīgs vecs PHP paplašinājums vai trūkstoša sistēmas bibliotēka. Cilvēki bieži nenovērtē, cik daudz atkopšanas laika tiek nodedzināts konfigurācijas novirzē.
Bija arī viens mazāk redzams ieguvums - nošķirt to, kam ir stāvoklis, no tā, kas ir vienreizlietojams. Ar datubāzes saturu, augšupielādētajiem multivides failiem, konfigurāciju un SSL resursiem apgājās rūpīgi. Kešatmiņa, pagaidu faili un ģenerētās sesijas tika pārbūvētas tīri. Tas padara atkopšanu vieglu un ļauj neienest veco troksni jaunā palaišanā.
Ko māca šī dublējuma atjaunošanas gadījuma izpēte
Galvenā mācība nav vienkārši dublēt savu serveri. Lielākā daļa uzņēmumu jau zina šo teikumu. Grūtākā mācība ir veidot atkopšanu ap biznesa funkciju, nevis tikai infrastruktūras objektiem.
VM momentuzņēmums ir noderīgs, taču tas var būt pārāk truls instruments. Datubāzes izmetums ir noderīgs, bet nepietiekams, ja augšupielādētie faili ir atsevišķi. Vadības paneļa dublējums ir ērts, taču ērtība joprojām ir jāpārbauda. Pareizā dublēšanas stratēģija ir atkarīga no tā, kā lietotne uzvedas, cik bieži dati mainās un kāds zaudējumu apjoms patiešām ir pieņemams.
E-komercijas vietnei produktu attēli parasti var pieļaut nedaudz vecākus atjaunošanas punktus nekā pasūtījumu ieraksti. SaaS lietotnei klientu datubāzes stāvoklis var būt svarīgāks nekā lokālās failu sistēmas saturs. Digitālajai aģentūrai, kas vienā serverī hostē vairākas klientu vietnes, izolācija kļūst kritiska, jo vienai trokšņainai vietnei nevajadzētu pārvērst atkopšanu par visa statīva galvassāpēm.
Arī testēšana ir pelnījusi lielāku cieņu. Dublējumi ir solījumi, līdz tie tiek atjaunoti. Pēc atjaunošanas tie kļūst par pierādījumiem. Šī atšķirība ir dārga.
Kas mainījās pēc incidenta
Mēs neuzskatījām atkopšanu par finiša līniju. Pēc pakalpojuma stabilizēšanas mēs pārskatījām glabātuves uzvedību, failu sistēmas veselību, datubāzes integritātes pārbaudes un dublēšanas politikas laiku. Tūlītējais tehniskais cēlonis norādīja uz viesa līmeņa diska nekonsekvenci rakstīšanas slodzes apstākļos, taču plašākais jautājums bija, kā nākamreiz samazināt ietekmes rādiusu.
Datubāzes slānim tika pielāgots dublēšanas biežums, lai kampaņu laikā saīsinātu atjaunošanas punkta riska periodu. Brīdinājumu sliekšņi I/O gaidīšanai un datubāzes kļūdu modeļiem tika padarīti stingrāki. Klients arī pārgāja no viena atjaunošanas domāšanas modeļa uz daudzslāņainu - automātiski dublējumi, pārbaudītas atjaunošanas procedūras un skaidrāka pieeja transakciju saskaņošanai.
Tieši šeit pārvaldīts operacionālais atbalsts atpelna savu vērtību. Ne jau tāpēc, ka incidenti nekad nenotiek, bet tāpēc, ka tad, kad tie notiek, kāds jau zina, kur vispirms skatīties un ko nesabojāt, kamēr tas tiek labots. Šī mazā atšķirība bieži vien ir visa atšķirība.
Ja jūs darbināt ieņēmumus ģenerējošas slodzes, svarīgais jautājums nav tas, vai jums ir dublējumi. Svarīgais jautājums ir, vai pulksten 2 naktī jūs varat atjaunot pareizos datus pareizajā vietā, ātri tos pārbaudīt un ņemt vērā to, kas notika pēc dublējuma izveides. Ja atbilde ir neskaidra, sistēma joprojām prasa uzmanību. Labāk atbildēt uz to klusā pēcpusdienā nekā norēķināšanās atteices laikā.
Andres Saar Klientu apkalpošanas inženieris