Cloudflare's 'Minor Database Tweak' Took Down Half the Internet – Was It Ineptitude or Hubris?
«Мелкое изменение в базе данных» уронило половину интернета — глупость или высокомерие?
blog.cloudflare.com
So let me get this straight: a five-minute 'improvement' to database permissions — meant to make things more secure — silently doubled a critical config file, crashed the entire routing system of one of the internet’s backbone companies, and took out millions of websites globally. And no, it wasn’t a hacker. It was an internal query gone wild. The kind of bug you’d expect from a startup’s third intern.
Так уточним: пяти минут хватило, чтобы «улучшить» права доступа к базе данных — это должно было повысить безопасность — но вместо этого файл конфигурации вдвое увеличился, обрушил всю систему маршрутизации одного из китов интернета и вывел из строя миллионы сайтов по всему миру. И при этом не было хакеров. Всё из-за сбоя внутреннего запроса. Типичная ошибка, на которую способен только третий стажёр в стартапе.
What’s wild is that their own status page went down too — hosted off-Cloudflare, mind you — which made engineers think they were under cyber attack. Oh, the delicious irony. And the fix? Rolling back a file. A. File. Not exactly quantum-level problem-solving.
Поразительно, что даже их страница статуса упала — причём размещена она вне Cloudflare — а это заставило инженеров думать, что идёт кибератака. Ах, изысканная ирония. А решение? Откатить файл. Всего лишь файл. Не самые передовые методы квантового программирования.
Это была не «просто конфигурация» — это системный сбой. Главная проблема? Отсутствие валидации внутренних настроек. Если вы не обрабатываете собственные конфиги как пользовательский ввод, подобные сбои — лишь вопрос времени. Элементарная гигиена разработки.
Хорошо, но… разве запрос к метаданным в ClickHouse не был очевидно ошибочным? Нет фильтрации по базе данных? Это же SQL 101. Кто это утвердил?
Именно поэтому нельзя выкатывать изменения в пиковое время. А ещё — любой лимит размера файла должен вызывать оповещение до сбоя. Но ладно, мы же учимся, да?
Честно, за такое меня бы уволили в моей компании. У нас всего один сервер EC2, и даже я настроил скрипты отката и проверки работоспособности.
Именно так. «Проверочный» слой должен был обнаружить ошибочные данные при вводе, а не при ошибке выполнения. Это классическая модель сбоя.
Честно, это похоже на оправдание в стиле «кто мог это предвидеть?». Система вернула вдвое больше метаданных. Кто-то должен был протестировать генератор файлов на расширенном выводе.
Почти поэтично: стражи интернета, призванные останавливать атаки, пали из-за одного непроверенного разрешения. Брандмауэр не взломали, но привратник забыл запереть боковую дверь.