Большой разбор Cloudflare, почему серверы начали грузиться по четыре часа

Cloudflare разобрали, как обычное обновление firmware превратило перезагрузку bare-metal серверов в многочасовое ожидание. Отличный пример того, как маленькая деталь в UEFI boot order ломает rollout почти на 2 000 машин.

Суть проблемы: после обновления firmware серверы проходили POST нормально, но потом линейно перебирали неподходящие варианты сетевой загрузки. IPv4 HTTPS boot, IPv4 iPXE, снова таймауты — и только потом рабочий IPv6 HTTPS boot. Каждый неудачный network boot съедал примерно по 5 минут. На одном reboot неприятно, а в firmware upgrade automation, где несколько компонентов обновляются через последовательные перезагрузки, это раздувалось почти до 4 часов.

В разборе показывают путь расследования:

🔘 serial console вместо гадания по мониторингу;
🔘 как UEFI, PXE, iPXE и HTTPS boot участвуют в загрузке;
🔘 почему firmware начал перебирать интерфейсы не в том порядке;
🔘 как Cloudflare стала задавать network boot interface order заранее в pre-boot PXE stage;
🔘 какие ограничения всплыли: старые UEFI-версии не поддерживают boot ordering, а настройки могут сбрасываться после firmware upgrade;
🔘 как всё завели через существующий release pipeline без ручного похода в BIOS.

Главная цифра: firmware upgrade automation сократили с почти 4 часов до 3 минут, а последующий single boot — примерно с 20 минут до менее чем минуты.

Сохранять тем, кто отвечает за bare metal, firmware updates, PXE/iPXE-загрузку или просто любит production-разборы, где проблема прячется не в коде приложения, а в цепочке до старта ОС. Тут хорошо видно, почему boot order, таймауты и vendor quirks стоит тестировать так же внимательно, как обычный rollout.

@prog_stuff