V časných ranních hodinách 27. srpna 2026 postihl Proton rozsáhlý výpadek, který ovlivnil služby pro řadu uživatelů. Hlavní příčinou byl celkový výpadek chladicího systému v našem frankfurtském datacentru. Ačkoli jsou všechny systémy v Protonu redundantní a máme dostatečnou kapacitu, abychom zvládli kompletní výpadek datacentra, existuje malé množství scénářů, kdy převzetí služeb při selhání může trvat déle a vést k narušení služeb pro uživatele.

Zde je časová osa toho, co se stalo, jaká rozhodnutí jsme během incidentu učinili a proč a jak byl vyřešen.

Časová osa

Krátce po 23:00 (středoevropského času) ve středu 26. srpna došlo k poruše chladicího systému v hlavní místnosti našeho frankfurtského datacentra. Kolem 23:15 začala teplota stoupat z přibližně 21,8 °C (nominální teplota) na 51,9 °C za méně než půl hodiny, přičemž některé měřicí sondy v místnosti hlásily teplotu vzduchu 60 °C. Jak teploty stoupaly, serverové a síťové vybavení v objektu začalo jedno po druhém selhávat.

Incident viditelný pro uživatele začal kolem půlnoci 27. srpna, kdy selhání eskalovala do bodu, kdy byla ztracena kritická redundance. K tomu došlo, když selhal primární i záložní síťový přepínač na kritickém racku a tento rack bohužel obsahoval několik primárních kopií databází. Ačkoli jsou téměř všechny systémy Protonu redundantní a převzetí služeb při selhání probíhá automaticky/okamžitě, převzetí služeb u primárních databází se neprovádí automaticky bez lidského dohledu.

Tuto kontrolu si ponecháváme kvůli snaze vyhnout se takzvaným stavům „split-brain“, kdy dočasná nedostupnost primární databáze znamená, že repliky zmeškají některé aktualizace a desynchronizují se způsobem, který může být později obtížné uvést do souladu. Když navíc dojde k převzetí služeb primární databáze při selhání, standardním operačním postupem je přepnout na repliku ve stejném datacentru z důvodu latence a výkonu. Specifická povaha problému však znamenala, že by to nemuselo být vhodné, protože bychom potenciálně mohli přepínat na něco, co by také selhalo.

Rozhodnutí

V tomto okamžiku museli pohotovostní inženýři Protonu pod extrémním tlakem učinit několik zásadních rozhodnutí.

  • Dát přednost opětovnému zprovoznění služby online, nebo se přednostně zaměřit na řešení problému s chlazením a záchranu hardwaru uvnitř datacentra?
  • Máme přepnout na repliky ve stejné budově ve Frankfurtu (což je rychlejší a méně rušivé, ale potenciálně jen dočasné řešení, pokud by se horko nepodařilo dostat pod kontrolu), nebo přepnout do Curychu?
  • Máme přepnout všechno, nebo jen to, co je v danou chvíli nefunkční? Máme pohotovostní plány pro kompletní výpadek datacentra, kdy k plnému a většinou automatickému přepnutí dochází poměrně rychle, ale situaci, kdy náhodné servery jeden po druhém selhávají, naše logika přepínání při selhání dobře nezvládá.

Rychlost, s jakou teploty stoupaly, nás nakonec donutila upřednostnit záchranu hardwaru před opětovným zprovozněním služeb online. Toto rozhodnutí obvykle není nutné dělat, protože chladicí systémy bývají redundantní a úplná ztráta chlazení je poměrně vzácná, což znamená, že zbývá poměrně dost času, než se teploty stanou kritickými. Problém ještě zhoršuje velký nárůst hustoty výkonu serverů v posledních letech kvůli výkonnějším CPU a GPU pro AI. V důsledku toho to, co dříve trvalo 3–4 hodiny, než se stalo kritickým, dosáhlo kritického stavu za 20 minut.

Pohotovostní tým se proto zaměřil na komunikaci s provozním týmem na místě v datacentru, aby obnovil chlazení a zároveň vypnul co nejvíce serverů v zájmu jejich ochrany. Vzhledem k nedostatku serverového vybavení spojenému s probíhajícím boomem AI by velkou část tohoto vybavení – v případě zničení – nebylo možné v krátkém čase nahradit. Jeho záchrana musela mít přednost, a to i za cenu možného prodloužení výpadku.

Do 0:45 SELČ se nám podařilo obnovit chlazení, teploty v objektu začaly klesat a pohotovostní tým přesunul pozornost na obnovu služeb. V této chvíli jsme se rozhodli přepnout primární databáze na Frankfurt, pokud replika stále fungovala, a do Curychu v případech, kdy ve Frankfurtu žádná funkční replika nezbyla, abychom příliš neměnili toky síťového provozu a případně nezpůsobili novou nestabilitu. Tato možnost byla vybrána, protože jsme předpokládali, že když už máme chlazení pod kontrolou, bude poměrně snadné uvést Frankfurt zpět online a rychlejší než přepínat do Curychu.

Bohužel se ukázalo, že tomu tak není. Během incidentu dosáhlo mnoho síťových karet ve frankfurtské infrastruktuře teploty 105 °C (běžná provozní teplota je 45 °C), což spouští speciální režim teplotní ochrany a způsobuje deaktivaci síťových karet až do provedení studeného restartu systému. Naše nastavení zabezpečení omezuje možnost přistupovat k out-of-band řadiči našich systémů, což si vyžádalo probuzení dalších zaměstnanců, kteří pomohli s obnovou.

Do 1:30 SELČ se nám podařilo uvést většinu služeb zpět online pro většinu uživatelů. Některé méně kritické systémy, jako jsou vyskakovací oznámení nebo zpracování plateb, však byly obnoveny až kolem 2:00 SELČ.

Jak jsme uvedli v původní zprávě o incidentu, žádné e-maily se neztratily, ale doručování e-mailů v obou směrech bylo během incidentu zpožděno.

I když byly služby pro uživatele plně obnoveny, pro naše inženýry, zejména pro databázový tým, noc ještě neskončila. Naše infrastruktura zůstala ve vysoce abnormálním stavu, kdy některé primární databáze byly v Curychu a jiné ve Frankfurtu a několik z nich fungovalo se sníženou redundancí a/nebo sníženým výkonem. Náš tým pracoval celou noc na vyřešení nejnaléhavějších z těchto problémů a práce na obnovení plné redundance pokračovaly po celý den 27. srpna.

Ačkoli se nám podařilo zachránit téměř veškerou infrastrukturu, některé servery bohužel utrpěly tepelnou smrt a zatím nevíme, zda incident s přehřátím ovlivní životnost přeživšího vybavení.

Hlavní příčina a další kroky

Následné vyšetřování z 27. srpna odhalilo hlavní příčinu selhání chlazení při výměně vzduchových filtrů na obou redundantních vzduchových kompresorech napájejících chladicí systém. Provozovatel datacentra bohužel tuto operaci provedl uprostřed noci, bez předchozího upozornění, a také neinformoval o selhání chlazení v momentě, kdy k němu došlo, což dramaticky zkrátilo čas, který jsme měli na reakci. Úzce spolupracujeme s provozovatelem, abychom opakování tohoto incidentu zabránili.

Je však také známým limitem naší současné databázové infrastruktury, že výpadek tohoto typu může vést k delšímu procesu obnovy než obvykle. Řada událostí, které k tomuto incidentu vedly, je vysoce nepravděpodobná – a přesto k nim došlo.

Práce na odolnosti databází potřebné k řešení tohoto typu selhání již probíhají a jejich dokončení je stále plánováno do konce roku. V současné době je také uváděna do provozu další kapacita infrastruktury, včetně nových prostor v datacentrech, a očekává se, že bude k dispozici během několika příštích týdnů, což ještě více sníží naši závislost na jediné lokalitě.

K tomuto incidentu bohužel došlo dříve, než byla tato vylepšení plně zavedena. Nyní přezkoumáváme, kde můžeme zbývající práce bezpečně urychlit při zachování úrovně péče vyžadované pro změny kritické databázové infrastruktury.

Uvědomujeme si, že naši uživatelé očekávají od Protonu velmi vysokou úroveň spolehlivosti, a tento incident posiluje důležitost dokončení těchto prací a neustálého zvyšování našich standardů odolnosti. Znovu se bezvýhradně omlouváme každému uživateli, kterého se výpadek dotkl.