Aktualizace výpadku služeb Spaceship

Dne 13. srpna jsme zaznamenali rozsáhlý výpadek služeb, který ovlivnil řadu služeb Spaceship.

Příčinou bylo selhání chladicího systému v datovém centru RadiusDC: Phoenix, které hostuje některé klíčové operace Spaceship. To nás donutilo odstavit služby, abychom ochránili zákaznickou infrastrukturu před přehřátím a možným poškozením.

Vše, co bylo incidentem ovlivněno, již bylo obnoveno a naše týmy nadále pečlivě monitorují systémy, aby zajistily jejich stabilitu.

Velmi se omlouváme za dopad na zákazníky, kteří jsou na nás závislí kvůli svým webům, e-mailu a dalším online službám. Narušení, které to způsobilo, i okolnosti, které za tím stojí, bereme mimořádně vážně.

Co se stalo

Incident začal, když kvůli silné bouři selhaly chladicí systémy v datovém centru Phoenix, což způsobilo, že teploty v okolí naší infrastruktury dosáhly kritických hodnot.

Pokračování provozu systémů v takových podmínkách by znamenalo riziko přehřátí zařízení a dlouhodobého či katastrofického poškození. Odstavení služeb způsobilo značné narušení, ale bylo nezbytné k ochraně infrastruktury našich zákazníků.

Ponechání zařízení offline, dokud nebyly chladicí systémy opět online, také poskytlo teplotám čas vrátit se na bezpečnou úroveň před zahájením obnovy. To pomohlo zabránit vzniku dalších problémů, které by mohly ještě více prodloužit již tak závažný incident.

Jak byli zákazníci ovlivněni

Výpadek ovlivnil služby včetně Shared, VPS, přeposílání e-mailů a Spacemail. Spaceship.com zůstal po celou dobu incidentu online.

Zde je přehled toho, jak situace ovlivnila klíčové produkty a služby:

Hostingové operace

Byl ovlivněn přístup zákazníků k webům a hostingovým službám, přičemž mnoho zákaznických webů bylo nedostupných, pomalých nebo vracelo chyby. Některé fakturační operace byly po dobu incidentu také nedostupné poté, co byl systém odpovědný za jejich zpracování odstaven.

EasyWP

Nástěnka EasyWP a zákaznické weby byly narušeny. Během obnovy zůstaly některé zákaznické weby nedostupné i po obnovení EasyWP.com a Nástěnky, přičemž některé vracely chyby připojení k databázi.

Spacemail

E-mailové služby byly také narušeny. Dotčení zákazníci nemohli odesílat e-maily a příchozí e-maily nemohly být doručeny, zatímco příslušné servery byly offline.

Důležité je, že to neznamenalo, že by byly příchozí zprávy automaticky ztraceny. Poskytovatelé e-mailu obvykle provádějí další pokusy o doručení, když je přijímající server dočasně nedostupný. Zprávy tedy dorazily, ale později než obvykle.

Jak jsme obnovili služby

RadiusDC začalo co nejdříve obnovovat svou chladicí kapacitu, zatímco byly nainstalovány dočasné chladiče a nasměrovány do naší části datového centra, aby pomohly snížit teploty.

Naše týmy nepřetržitě pracovaly na místě společně s RadiusDC na obnovení chlazení. Služby jsme začali vracet online teprve poté, co se teploty vrátily na bezpečnou provozní úroveň a byli jsme si jisti, že nehrozí přehřátí ani dlouhodobé poškození.

Po obnovení bezpečných provozních podmínek jsme zahájili řízenou obnovu napříč naší infrastrukturou. To muselo probíhat postupně, takže zákazníci viděli návrat různých služeb v různých časech.

Proč byly služby obnovovány po etapách

Rozsah incidentu znamenal, že byly současně narušeny různé části naší platformy. Ačkoli je zákazníci vnímají jako samostatné služby, incident v datovém centru ovlivnil infrastrukturu zapojenou do poskytování řady z nich.

Služby jako hosting a e-mail spoléhají na více vrstev technologií, včetně serverů, sítí, úložišť a databází. Jejich obnova znamenala vrátit tyto různé prvky online ve správném pořadí, namísto prostého opětovného zapnutí všeho najednou.

Co bude následovat

Toto narušení a jeho dopad na naše zákazníky bereme velmi vážně. 

Naše týmy provádějí důkladné přezkoumání situace, aby posílily naše systémy a zajistily, že se podobné incidenty nebudou opakovat.

Budeme zcela transparentní ohledně toho, co zjistíme, a podělíme se s vámi o výsledky spolu s kroky, které podnikáme.

OPRAVA: Naším provozovatelem datového centra je RadiusDC, nikoli PhoenixNAP, jak bylo uvedeno v několika dřívějších příspěvcích na X z 13. srpna. PhoenixNAP není do tohoto incidentu zapojen.