2026. gada 20. oktobrī elektroapgādes kļūme atslēdza vienu Google Cloud Londonas reģiona pieejamības zonu — europe-west2-b. Zonas serveri, lokālā krātuve un tīkla aparatūra palika bez strāvas, un incidents ilga aptuveni sešas stundas. To izjuta bankas, maksājumu pakalpojumu sniedzēji un SaaS platformas visā Eiropā. Ikvienam, kas darbina datubāzes mākonī, tas ir noderīgs piemērs — nevis tāpēc, ka zona sabojājās (zonas ir paredzētas tam, ka tās var sabojāties), bet gan tāpēc, kas notika zonās, kuras nesabojājās.
Kas notika
Saskaņā ar Google sākotnējo incidenta ziņojumu, kā to apkopojis IncidentHub:
- Plkst. 05:53 UTC objektā, kurā atrodas europe-west2-b, pazuda ārējā elektroapgāde. Gan galvenie, gan rezerves kontrolleri nespēja iedarbināt ģeneratorus, tāpēc objekts darbojās no UPS akumulatoriem.
- Ap 06:00 UTC akumulatori izlādējās, un viss zonā — serveri, krātuve, tīkla agregācija — izslēdzās. Datubāzu replikas šajā zonā kļuva nesasniedzamas.
- Automātiskā pārslēgšanās pārvietoja trafiku un datubāzu primāros mezglus uz divām atlikušajām zonām. Pēkšņais pieprasījums piesātināja to jaudu, un starp skartajiem pakalpojumiem bija Cloud SQL, AlloyDB, Memorystore un Bigtable ar "aizkavētu datubāzu pārslēgšanās pabeigšanu".
- Google paziņoja par incidenta beigām plkst. 12:10 UTC, taču neliels klientu skaits joprojām bija skarts plkst. 14:03. Daži atkarīgie pakalpojumi darbojās ar traucējumiem vēl vairākas stundas.
1. mācība: vairākas zonas ir nepieciešamas, bet nepietiek
Slodzes, kas pilnībā atradās europe-west2-b, vienkārši pārstāja darboties. Tie bija acīmredzamie zaudētāji. Interesantāka ir otra grupa — komandas, kas bija rīkojušās pareizi (primārais mezgls vienā zonā, rezerves mezgls citā) un tomēr piedzīvoja minūtēm vai stundām ilgas kļūdas. Pārslēgšanās notika, taču vienlaikus ar visu pārējo pārslēgšanos — uz zonām, kas pēkšņi kļuva daudz noslogotākas.
Augstas pieejamības arhitektūra ir tik laba, cik labi ir tās pieņēmumi. "Ja zona B sabojājas, pārņem rezerves mezgls zonā A" klusi pieņem, ka zonā A ir brīva jauda, ka vadības plakne to spēj ātri paaugstināt un ka nekas pārslēgšanās ceļā nav atkarīgs no zonas B.
2. mācība: plānojiet jaudu dienai, kad pārslēdzas visi
- Darbiniet rezerves mezglus pilnā izmērā. Rezerves mezgls, kas ir uz pusi mazāks par primāro, katru dienu ietaupa naudu un izmaksā jums avāriju tajā vienā dienā, kad tas ir svarīgi.
- Nepaļaujieties uz jaunu resursu izveidi reģionāla incidenta laikā. Šīs avārijas laikā jaunu virtuālo mašīnu izveide vairākas stundas bija traucēta. Ja jūsu atjaunošanas plānā rakstīts "izveidot jaunu repliku", tas var nestrādāt tieši tad, kad tas visvairāk vajadzīgs. Iepriekš izveidoti, darbojošies rezerves mezgli strādā.
- Savienojumu vētras ir reālas. Pēc pārslēgšanās visas lietotnes pieslēdzas vienlaikus. Savienojumu pūls, piemēram, PgBouncer, un saprātīga atkārtošanas aizture lietotnē pasargā jauno primāro mezglu no pārslodzes pirmajās minūtēs.
3. mācība: atrodiet slēptās starpzonu atkarības
Google norādīja, ka vadības plaknes izsaukumi uz sabojāto zonu beidzās ar noildzi. Jūsu sistēmā ir līdzīgas lamatas:
- Konsensa krātuve (etcd, Consul, ZooKeeper) Patroni vai citam pārslēgšanās pārvaldniekam, kuras dalībnieki izvietoti nevienmērīgi, tāpēc vienas zonas zaudējums nozīmē kvoruma zaudējumu.
- Viens savienojumu pūls, slodzes balansētājs vai bastiona serveris, kas nejauši atrodas sabojātajā zonā.
- Rezerves kopijas un WAL arhīvi, kas tiek rakstīti tikai zonas līmeņa krātuvē.
- Monitorings un brīdinājumi, kas izvietoti tajā pašā zonā, kur uzraugāmā datubāze — tāpēc trauksme izslēdzas kopā ar pacientu.
Kā izvietot noturīgu PostgreSQL klasteri, ieskaitot konsensa krātuves novietojumu, aprakstām ceļvedī par PostgreSQL augstu pieejamību ar Patroni.
Jautājums, ko šonedēļ vērts uzdot savai komandai: kad pēdējo reizi apzināti pārslēdzāt ražošanas datubāzi? Ja godīgā atbilde ir "nekad" vai "pēdējās avārijas laikā", jūs vēl nezināt, cik ilgi pārslēgšanās aizņem, kas tās laikā salūzt un vai lietotnes korekti pieslēdzas no jauna.
4. mācība: iepriekš izlemiet, kad pamest reģionu
Google ieteikums incidenta laikā bija pārvietot slodzes uz citu zonu vai reģionu, ja iespējams. Tas ir reāli tikai tad, ja jau pastāv replika citā reģionā, nesenas rezerves kopijas citā reģionā un uzrakstīta rīcības instrukcija. Iepriekš nosakiet atjaunošanas punkta un atjaunošanas laika mērķus (RPO un RTO), kam ir tiesības iedarbināt reģionālo pārslēgšanos un kurā incidenta brīdī šis lēmums tiek pieņemts. Komunikācijas pusi aplūkojam rakstā par datubāzes incidenta pirmajām 15 minūtēm.
Galvenās atziņas
- Zonas sabojājas. Īstais pārbaudījums ir, vai atlikušās zonas spēj uzņemt visu pārslēgšanos vienlaikus.
- Turiet rezerves mezglus darbībā pilnā izmērā; nepaļaujieties uz jaunu resursu izveidi incidenta laikā.
- Pārbaudiet konsensa krātuves, savienojumu pūlus, rezerves kopijas un monitoringu, vai tie nav slēpti atkarīgi no vienas zonas.
- Regulāri testējiet pārslēgšanos un iepriekš izlemiet, kad pāriet uz citu reģionu.