Оновлення щодо збою сервісів Spaceship

13 серпня ми зіткнулися з масштабним збоєм у роботі сервісів, який вплинув на низку сервісів Spaceship.

Причиною стала несправність системи охолодження в дата-центрі RadiusDC: Phoenix, де розміщено деякі критично важливі операції Spaceship. Це змусило нас перевести сервіси в офлайн, щоб захистити інфраструктуру клієнтів від перегріву та можливих пошкоджень.

Усе, що постраждало внаслідок інциденту, тепер відновлено, а наші команди продовжують уважно стежити за системами, щоб переконатися, що вони залишаються стабільними.

Ми щиро шкодуємо про вплив на клієнтів, які покладаються на нас щодо своїх вебсайтів, електронної пошти та інших онлайн-сервісів. До спричиненого цим збою та обставин, що стоять за ним, ставляться вкрай серйозно.

Що сталося

Інцидент почався, коли через сильний шторм вийшли з ладу системи охолодження в дата-центрі Phoenix, через що температура навколо нашої інфраструктури досягла критичних рівнів.

Подальша робота систем у таких умовах створювала ризик перегріву обладнання та довгострокових і катастрофічних пошкоджень. Переведення сервісів в офлайн спричинило значні перебої, але це було необхідно для захисту інфраструктури наших клієнтів.

Утримання обладнання в офлайні до моменту, коли системи охолодження знову запрацюють, також дало температурі час повернутися до безпечних рівнів до початку відновлення. Це допомогло уникнути створення додаткових проблем, які могли б ще більше затягнути і без того серйозний інцидент.

Як постраждали клієнти

Збій вплинув на сервіси, зокрема Shared, VPS, пересилання електронної пошти та Spacemail. Spaceship.com залишався онлайн протягом усього інциденту.

Ось розбивка того, як ситуація вплинула на ключові продукти та сервіси:

Операції хостингу

Було порушено доступ клієнтів до вебсайтів і хостингових сервісів: багато клієнтських вебсайтів були недоступні, працювали повільно або повертали помилки. Деякі білінгові операції також були недоступні після того, як систему, відповідальну за їх обробку, було переведено в офлайн під час інциденту.

EasyWP

Було порушено роботу панелі керування EasyWP і вебсайтів клієнтів. Під час відновлення деякі клієнтські вебсайти залишалися недоступними після відновлення EasyWP.com і панелі керування, а деякі повертали помилки підключення до бази даних.

Spacemail

Роботу поштових сервісів також було порушено. Постраждалі клієнти не могли надсилати електронні листи, а вхідні листи не могли бути доставлені, поки відповідні сервери були офлайн.

Важливо, що це не означало автоматичну втрату вхідних повідомлень. Поштові провайдери зазвичай здійснюють подальші спроби доставки, коли сервер одержувача тимчасово недоступний. Тож повідомлення надходили, але пізніше, ніж зазвичай.

Як ми відновили сервіси

RadiusDC почав якнайшвидше відновлювати свою охолоджувальну потужність, водночас було встановлено тимчасові чилери та спрямовано їх у нашу зону дата-центру, щоб допомогти знизити температуру.

Наші команди безперервно працювали на місці разом із RadiusDC, щоб відновити охолодження. Ми почали повертати сервіси в онлайн лише після того, як температура повернулася до безпечних робочих рівнів і ми були впевнені, що немає ризику перегріву або довгострокових пошкоджень.

Після відновлення безпечних умов роботи ми розпочали контрольоване відновлення всієї нашої інфраструктури. Це мало відбуватися поступово, тому клієнти бачили повернення різних сервісів у різний час.

Чому сервіси відновлювалися поетапно

Масштаб інциденту означав, що різні частини нашої платформи були порушені одночасно. Хоча клієнти сприймають їх як окремі сервіси, інцидент у дата-центрі вплинув на інфраструктуру, задіяну в наданні низки з них.

Такі сервіси, як хостинг і електронна пошта, залежать від кількох технологічних рівнів, зокрема серверів, мереж, сховищ і баз даних. Їх відновлення означало повернення цих різних елементів в онлайн у правильному порядку, а не просте одночасне ввімкнення всього одразу.

Що буде далі

Ми дуже серйозно ставимося до цього збою та його впливу на наших клієнтів. 

Наші команди проводять ретельний аналіз ситуації, щоб посилити наші системи та гарантувати, що подібні інциденти не повторяться.

Ми будемо повністю прозорими щодо того, що дізнаємося, і поділимося з вами результатами разом із заходами, яких ми вживаємо.

ВИПРАВЛЕННЯ: Наш оператор дата-центру — RadiusDC, а не PhoenixNAP, як було зазначено в кількох ранніх дописах у X від 13 серпня. PhoenixNAP не причетний до цього інциденту.