[比推] 18 листопада Cloudflare зазнав збою, ця ситуація набула великого розголосу — CDN, послуги безпеки, Workers KV, Turnstile, Access та безліч інших продуктів вийшли з ладу, вони самі заявили, що це був найсильніший збій з 2019 року.
Спочатку команда думала, що їх атакували DDoS, але після тривалих перевірок виявилося, що це зробив хтось із їхніх: змінили права доступу до бази даних, в результаті чого згенерований конфігураційний файл мав помилку, що призвело до збою в основній системі проксі. Врешті-решт, вдалося відкотити стару конфігурацію, і повне відновлення відбулося о 1:06 19 числа за пекинським часом.
Офіційний звіт блогу написаний досить щиро, прямо визнає “недопустимо”, каже, що потрібно прискорити модернізацію системної стійкості. Для нас, хто використовує їхні послуги для запуску проектів, подібного рівня збій інфраструктури дійсно слід запам'ятати — навіть найпотужніші постачальники можуть зазнати невдачі через внутрішні помилки; багатовимірне розгортання та плани реагування слід готувати заздалегідь.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Огляд найсерйознішого збої в історії Cloudflare: це не атака, а помилка в налаштуваннях.
[比推] 18 листопада Cloudflare зазнав збою, ця ситуація набула великого розголосу — CDN, послуги безпеки, Workers KV, Turnstile, Access та безліч інших продуктів вийшли з ладу, вони самі заявили, що це був найсильніший збій з 2019 року.
Спочатку команда думала, що їх атакували DDoS, але після тривалих перевірок виявилося, що це зробив хтось із їхніх: змінили права доступу до бази даних, в результаті чого згенерований конфігураційний файл мав помилку, що призвело до збою в основній системі проксі. Врешті-решт, вдалося відкотити стару конфігурацію, і повне відновлення відбулося о 1:06 19 числа за пекинським часом.
Офіційний звіт блогу написаний досить щиро, прямо визнає “недопустимо”, каже, що потрібно прискорити модернізацію системної стійкості. Для нас, хто використовує їхні послуги для запуску проектів, подібного рівня збій інфраструктури дійсно слід запам'ятати — навіть найпотужніші постачальники можуть зазнати невдачі через внутрішні помилки; багатовимірне розгортання та плани реагування слід готувати заздалегідь.