Lần theo sự cố Hetzner AX162 bằng powerstat, sensors và dmidecode

 (ubicloud.com)
1 điểm bởi GN⁺ 2025-02-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • Ubicloud đã triển khai các máy chủ AX162 mới của Hetzner vì chúng có vẻ tốt hơn AX161 cả về hiệu năng lẫn giá thành, nhưng khi vận hành lại gặp vấn đề độ tin cậy khi sự cố xảy ra thường xuyên gấp 16 lần
  • Việc lần tìm nguyên nhân bắt đầu từ các nhật ký hệ thống còn sót lại byte NULL, rồi lần lượt loại trừ tải, nhiệt độ, thông tin linh kiện và mức tiêu thụ điện năng; các công cụ chủ chốt là sensors, dmidecode, powerstat
  • Trong dữ liệu ban đầu, AX161 có 11 sự cố trong 3.784 ngày phục vụ với AFR 1,06, còn AX162 ghi nhận AFR 16,84 với 34 sự cố trong 737 ngày
  • 80% máy chủ từng gặp sự cố sẽ gặp sự cố thứ hai trong vòng 24 giờ, và Hetzner đã thông báo lỗi lô bo mạch chủ mà không xác nhận liệu có áp giới hạn điện năng hay không
  • AX162 -v3 sau khi chuyển sang bo mạch chủ mới nhất đã giảm AFR xuống 0,39 sau vài tháng giám sát; phần cứng mới nên được kiểm chứng theo từng bước, bắt đầu từ các workload không cốt lõi

Các vụ crash lặp lại sau khi đưa AX162 vào sử dụng

  • Ubicloud phát triển phần mềm biến nhà cung cấp bare metal thành một nền tảng đám mây và từ lâu đã dùng Hetzner như một nhà cung cấp máy chủ giá rẻ, đáng tin cậy
  • Dòng máy chủ AX162 của Hetzner nhanh chóng được đưa vào sử dụng vì mang lại hiệu năng tốt hơn và giá thấp hơn mẫu AX161 trước đó
  • Ba tuần sau khi mua máy chủ AX162 đầu tiên, một máy đã bị crash và nhật ký hệ thống còn lại byte NULL
    • Điều này được hiểu là dấu hiệu của một lỗi đột ngột, tương tự mất điện, khiến các thao tác ghi không thể hoàn tất bình thường
  • Ở lần kiểm tra phần cứng ban đầu, Hetzner không phát hiện điều gì bất thường, nhưng một tuần sau lại xảy ra một vụ crash khác, rồi các sự cố lặp lại trong vài ngày tiếp theo

Cách sự cố xuất hiện

  • Tất cả các vụ crash đều chỉ xảy ra trên máy chủ AX162
  • Sự cố được chia thành hai dạng
    • Sau khi khởi động lại thủ công, máy chủ quay trở lại online
    • Máy chủ không phản hồi cả yêu cầu khởi động lại lẫn mã chẩn đoán từ kỹ sư Hetzner, buộc phải thay máy
  • Máy chủ thường hoạt động bình thường trong thời gian dài, nhưng sau vụ crash đầu tiên thì khả năng xảy ra thêm crash tăng cao
  • Người ta quan sát thấy kiểu diễn tiến là nhiều lần lặp lại dạng crash thứ nhất rồi cuối cùng chuyển sang dạng thứ hai, dẫn tới việc phải thay máy chủ

Loại trừ tải và nhiệt độ trước

  • AX162 cung cấp 96 vCPU, và Ubicloud có các workload sử dụng đồng thời toàn bộ số vCPU này
  • Họ xem xét giả thuyết tải cao có thể gây tăng nhiệt hoặc phát sinh vấn đề ngoài dự kiến, nhưng sự cố cũng xảy ra vào thời điểm tải thấp hoặc thậm chí không có tải
  • Để xem mối tương quan giữa nhiệt độ và sự cố, họ thu thập nhiệt độ các thành phần hệ thống bằng lệnh sensors
  • Dữ liệu nhiệt độ được gom bằng một tác vụ cron đơn giản, và khi kiểm tra lại sau lần crash tiếp theo, nhiệt độ không cao hơn đáng kể so với mức trung bình

Điều tra thông tin linh kiện và mức tiêu thụ điện

  • Họ dùng lshw và dmidecode để kiểm tra model và số serial của các linh kiện phần cứng
  • Khi so sánh linh kiện giữa các máy AX162 từng bị crash và các máy không bị, họ không tìm thấy khác biệt có ý nghĩa
  • Do linh kiện cũ có thể dễ hỏng hơn, họ cũng xem xu hướng tăng của số serial, nhưng ngay cả các máy có serial mới nhất vẫn bị crash
  • Trong các trung tâm dữ liệu mở rộng quy mô, điện năng thường là yếu tố ràng buộc hơn không gian, và nhà vận hành có thể giới hạn mức điện tiêu thụ trên mỗi máy
    • Ubicloud không biết Hetzner có giới hạn điện năng tiêu thụ hay không, nhưng họ cho rằng triệu chứng hoạt động ổn định trong thời gian dài rồi xuất hiện crash lặp lại khá khớp với dạng hao mòn phần cứng
    • Sau khi loại trừ từng giả thuyết khác, khả năng bị giới hạn điện năng trở thành giả thuyết mạnh nhất
  • Họ dùng powerstat -R để đo mức tiêu thụ điện tối đa trong thời gian dài và so sánh với thông số công bố
    • AX161: điện tối đa công bố 147W, điện tối đa đo được 168W
    • AX162: điện tối đa công bố 408W, điện tối đa đo được 266W
  • Sự chênh lệch này khiến họ nghi ngờ Hetzner có thể đang giới hạn mức điện sử dụng thực tế

Tỷ lệ sự cố nhìn qua AFR

  • Để so sánh độ tin cậy phần cứng, họ dùng Annualized Failure Rate (AFR)
  • AFR có những giới hạn, nhưng vẫn là một chỉ số đủ đơn giản để bắt đầu so sánh tỷ lệ sự cố
  • Kết quả đo ban đầu cho thấy tỷ lệ sự cố của AX162 cao hơn AX161 rất nhiều
    • AX161: 11 sự cố, tổng 3.784 ngày phục vụ, AFR 1,06
    • AX162: 34 sự cố, tổng 737 ngày phục vụ, AFR 16,84
  • Dữ liệu này củng cố quan sát rằng AX162 có khả năng gặp sự cố cao gấp 16 lần so với các model khác
  • Những máy đã từng crash một lần có xác suất crash lại rất cao, và 80% số máy từng crash sẽ gặp lần crash thứ hai trong vòng 24 giờ

Thay bo mạch chủ và giới hạn của v2

  • Ubicloud đã gửi cho Hetzner một ticket hỗ trợ chi tiết, bao gồm nghi vấn bị giới hạn điện năng và dữ liệu AFR
  • Hetzner không xác nhận cũng không phủ nhận khả năng giới hạn điện năng, nhưng cho biết họ đã xác nhận lỗi ở một lô bo mạch chủ
  • Hetzner đã nhận được một lô bo mạch chủ mới và khuyến nghị thay bo mạch chủ cho các máy chủ bị ảnh hưởng
  • Việc thay hàng loạt máy chủ trên quy mô lớn có thể ảnh hưởng tới workload của khách hàng, nhưng do các vụ crash lặp lại nên khi đó phần lớn tác vụ quan trọng đã được chuyển khỏi AX162, nhờ vậy việc thay thế vẫn khả thi
  • Ngay cả sau khi thay sang bo mạch chủ mới, họ vẫn không đưa các workload quan trọng quay lại AX162 mà tiếp tục giám sát trong thời gian dài
  • Ban đầu không có crash nào, nhưng sau hai tuần, các máy gắn bo mạch chủ mới cũng bắt đầu crash
    • AX162 -v2: 11 sự cố, tổng 758 ngày phục vụ, AFR 5,30
  • v2 crash ít thường xuyên hơn AX162 ban đầu, nhưng tỷ lệ sự cố vẫn còn cao

Kết quả ổn định ở v3

  • Sau khi liên hệ lại với Hetzner, họ biết rằng còn có phiên bản bo mạch chủ mới nhất với độ tin cậy được cải thiện hơn nữa
  • Họ di chuyển máy chủ sang phiên bản mới nhất và theo dõi độ tin cậy
  • Sau khi quan sát các máy chủ mới trong vài tháng, họ kết luận vấn đề crash của AX162 đã được giải quyết
  • So sánh AFR cuối cùng như sau
    • AX161: 11 sự cố, tổng 3.784 ngày phục vụ, AFR 1,06
    • AX162: 34 sự cố, tổng 737 ngày phục vụ, AFR 16,84
    • AX162 -v2: 11 sự cố, tổng 758 ngày phục vụ, AFR 5,30
    • AX162 -v3: 4 sự cố, tổng 3.738 ngày phục vụ, AFR 0,39
  • AFR của AX162 -v3 thậm chí còn thấp hơn cả AX161

Cải thiện quy trình vận hành

  • Khi áp dụng sớm một dòng máy chủ mới, có thể phát sinh những vấn đề ngoài dự kiến
  • AX162 có cấu hình rất hấp dẫn, và việc Hetzner ngừng AX161 cũng trông giống như một tín hiệu cho thấy dòng mới đã sẵn sàng cho production
  • Họ cho rằng nếu chờ thêm 6 tháng thì có lẽ đã tránh được nhiều vấn đề
  • Những thay đổi sắp tới gồm có
    • Thực hiện kiểm chứng kỹ lưỡng hơn đối với các model máy chủ mới
    • Với phần cứng mới, bắt đầu triển khai dần từ các workload không cốt lõi
    • Bổ sung thêm nhiều nhà cung cấp bare metal để phân tán rủi ro
  • Ubicloud hiện đã hỗ trợ thêm hai nhà cung cấp bare metal là Leaseweb và Latitude, đồng thời cũng đang tiến hành bổ sung nhà cung cấp thứ tư

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-21
Các ý kiến trên Hacker News

  • Các mẫu AX khác (AX42, AX52, AX102) cũng có vấn đề nghiêm trọng về độ tin cậy, hỏng sau vài tháng
    Vì chúng dựa trên bo mạch chủ bị lỗi, Hetzner sẽ phải thay phần lớn, có lẽ là toàn bộ bo mạch chủ của các máy chủ được sản xuất trước một ngày nhất định trong 12 tháng tới [0]
    [0] https://docs.hetzner.com/robot/dedicated-server/general-info...

    • Tôi đang dùng hai máy AX42; một máy nhận được trong đợt giảm giá Eurocup thì ổn định từ đó đến nay, còn máy kia đã bị thay hai lần
      Máy thay mới nhất có vẻ trụ được, nên với mẫu quan sát nhỏ thì trông giống như tỷ lệ hỏng 50%. Con số thực tế có lẽ chỉ Hetzner và ASRock biết

  • Ở công ty cũ, DevOps thường xuyên phát hiện hỏng quạt CPU trên thiết bị của Hetzner
    Việc này tách biệt với các lỗi HDD/SSD thường được dự đoán trước và phải tự giám sát. Đó là một trong những lý do máy chủ không quản lý rẻ hơn instance đám mây

    • Tôi cũng thường thấy bộ phận làm mát bị hỏng ở Azure, và khi làm ở Google thì đó cũng là một vấn đề dai dẳng dù ở mức thấp
      Ngày đầu gia nhập Dropbox, tôi nói với đội rằng “có thể tìm thấy trong fleet một máy đang chạy ở 400MHz”, và thực tế đúng như vậy. Một bộ điều khiển PSU dự phòng bị lỗi đã kích hoạt PROCHOT. Khi có nhiều máy thì những chuyện như vậy sẽ xảy ra
    • “Không quản lý” nghĩa là bạn có quyền truy cập ở mức silicon và KVM từ xa, chứ không có nghĩa là trách nhiệm với phần cứng vật lý được chuyển sang cho khách hàng
      Việc sở hữu, bảo trì và sửa chữa đúng cách thiết bị vật lý vẫn là trách nhiệm của công ty hosting, bao gồm cả giám sát. Trước đây có thể phải cài script hoặc package để kết nối vào hệ thống giám sát, nhưng nay khi IPMI và các thứ tương tự đã là tiêu chuẩn thì họ có thể làm mà không cần khách hàng hỗ trợ
      Nếu không phải chỉ cung cấp chỗ đặt rack, điện và mạng, thì phạm vi chịu trách nhiệm đến đâu là vấn đề hợp đồng. Nếu Hetzner không phát hiện nổi lỗi quạt CPU trên phần cứng của chính họ và triển khai hệ thống mới mà không kiểm thử đủ, thì đó có vẻ là bằng chứng cho thấy họ đang tiếp tục trượt dốc
    • Tôi phản đối mạnh mẽ cả việc dựa vào các dependency miễn phí lẫn việc chỉ chọn phương án rẻ nhất
      Khi đánh giá mua sắm, nếu không dành dù chỉ chút thời gian để nghĩ từ phía đối tác mà chỉ tìm cách giảm chi phí và tăng doanh thu, thì trừ khi bạn thuộc ngành bán hàng đáng ngờ, bạn sẽ không trụ được lâu
      Phần cứng máy chủ thực sự rất rẻ, và với một lập trình viên có năng lực ở mức nào đó, đa số chương trình đều có thể xử lý bằng một máy chủ đơn lẻ hoặc một máy ảo. Nên trả 50 đô la/tháng thay vì 25 đô la/tháng để cho họ một chút biên lợi nhuận. Dù vậy cũng không có gì đảm bảo công ty đó sẽ không phá sản hoặc sẽ xem bạn là khách hàng quý, và cuối cùng bạn vẫn đang dựa vào cấu trúc mà cả hệ thống có lãi nhờ các khách hàng lớn
      Nếu doanh nghiệp của bạn ở Mỹ thì nên dùng nhà cung cấp hosting của Mỹ

  • Lời khuyên “nếu chờ 6 tháng thì đã tránh được nhiều vấn đề, và những người dùng sớm thường là người tìm ra vấn đề trước để về sau được sửa” có thể áp dụng cho mọi hệ thống cần độ ổn định
    Nếu không có vấn đề bảo mật, hãy chờ vài tháng hoặc duy trì trạng thái chậm hơn một hai phiên bản

    • GitHub đang cố thêm tính năng này vào dependabot: https://github.com/dependabot/dependabot-core/issues/3651
    • Đây cũng là một mô thức đã thành công lâu dài trong tự nhiên. Các cá thể già dùng cá thể trẻ, thiếu kinh nghiệm làm đơn vị thử nghiệm nhiệt tình
      Ví dụ, trong rừng, một con lợn rừng già sẽ phát tín hiệu an toàn để cố dụ lũ con đi trước vào một khoảng trống đáng ngờ. Nói theo phía công nghệ thì giống như viết bài blog thổi phồng một công nghệ chưa sẵn sàng cho production
    • Tôi là tác giả bài blog. Nhìn chung đây đúng là thực hành tốt
      Dù vậy, cũng may là những vất vả của chúng tôi đã giúp nguyên nhân gốc lộ ra nhanh hơn
      Tôi không viết trong bài, nhưng về sau chúng tôi cũng đã cân nhắc phương án nhận máy chủ rồi để nhàn rỗi khoảng một tháng, không chạy workload thực của khách hàng. Chi phí sẽ cao hơn, nhưng có thể giúp phát hiện vấn đề tiềm ẩn mà không ảnh hưởng tới người dùng. Trong trường hợp của chúng tôi, các crash bắt đầu 3 tuần sau khi triển khai máy chủ AX162 đầu tiên, nên cần ít nhất một tháng, có lẽ là một khoảng đệm dài hơn
    • Tùy từng hệ thống. Kelly Johnson của Skunk Works từng nêu một trong các quy tắc chính rằng hệ thống kiểm tra hiện tại phù hợp với tinh thần yêu cầu của quân đội và nên được dùng cho các dự án mới, đồng thời hãy chuyển nhiều trách nhiệm kiểm tra cơ bản hơn cho nhà thầu phụ và nhà cung cấp, và đừng kiểm tra trùng lặp
      Tuy nhiên, việc Ubicloud dùng một model mới hoặc một tranche mua mới mà không burn-in sẽ là lần đầu tiên và cũng là lần cuối. Tôi cũng làm ở đó và là đồng sáng lập

  • Dell thỉnh thoảng cũng có vấn đề kiểu này. Khi nhận lô đầu tiên của một máy chủ đời trước, máy chủ thỉnh thoảng mất các thiết bị ở phía I/O sau, nên phải thay phần I/O phía sau của bo mạch chủ
    Ví dụ như bộ điều khiển Ethernet, iDRAC, đôi khi cả BIOS cũng biến mất. Sau khi xử lý xong vấn đề này, chúng chạy tốt gần 10 năm
    Gần đây chúng tôi cho nghỉ hưu vì mọi thứ từ card RAID đến bộ điều áp nguồn đều đã hao mòn. Việc khởi động lại một máy chủ vốn đang chạy ổn chỉ vì thay đổi cấu hình, rồi vĩnh viễn mất card RAID do electromigration ăn mòn các trace bên trong bộ xử lý RAID, là một trải nghiệm khiến người ta tỉnh cả người

    • Dell có rất nhiều vấn đề. Chỉ một bo mạch mini bị lỗi của đèn LED mặt trước cũng có thể khiến máy chủ không boot hoặc không chạy được, và trong trường hợp đó DRAC cũng chết

  • Hetzner không xác nhận cũng không phủ nhận khả năng giới hạn điện năng, nên tôi tò mò giới hạn điện năng sẽ dẫn đến kết quả gì
    Bài viết nói phần cứng có thể xuống cấp nhanh hơn, nhưng tôi không hiểu vì sao
    Nhìn vào việc Hetzner không phản hồi và các số đo của UbiCloud, có vẻ họ thực sự giới hạn điện năng. Nếu không thì hẳn họ đã nói là không

    • Tôi đã thấy điều tương tự ở nhiều dịch vụ cloud: CPU scaling governor được đặt thành một giá trị “xanh” chỉ có lợi cho nhà cung cấp cloud, hoàn toàn không có lợi cho người dùng, và chỉ làm giảm mạnh hiệu năng CPU tối đa
      Để kiểm tra, chạy cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. Giá trị nên là performance
      Nếu không phải, có thể đặt bằng echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. Sẽ hữu ích với workload dùng nhiều CPU. Sau khi reboot nó sẽ quay lại như cũ, nên có thể dùng cron/systemd, v.v. để duy trì
      Tất nhiên nếu bạn tự trả tiền điện hoặc dùng phần cứng của mình thì scaling governor nên do bạn tự quyết. Nhưng với server bare metal thuê thì performance mới là đúng

  • Phần nói rằng nhà vận hành datacenter giới hạn mức dùng điện theo từng server để tăng số lượng máy trong giới hạn điện năng, và điều này có thể làm mainboard xuống cấp nhanh hơn, nghe trái với trực giác
    Tìm sơ qua thì giới hạn điện năng có vẻ làm tăng tuổi thọ hữu dụng của nhiều linh kiện
    Các kết quả tìm kiếm nói ngược lại chỉ nói rằng nhiệt độ vận hành cao khi bị thermal throttling có thể làm các linh kiện như tụ điện xuống cấp nhanh hơn. Nhưng bài viết đã xem nhiều cảm biến nhiệt độ, và đã nói rõ không phải trường hợp đó

    • Khi tìm hiểu, tôi có thấy vài bài nói giới hạn điện năng có thể gây xuống cấp phần cứng, nhưng giờ không còn nguồn chính xác
      Một trả lời bên dưới đã chia sẻ một ví dụ, và khi tìm kiếm thì tôi thấy thêm vài nguồn nữa [1], [2]
      Tuy nhiên tôi không phải kỹ sư điện tử nên có thể hiểu chưa hoàn toàn chính xác. Việc xuống cấp có thể không phải do bản thân giới hạn điện năng mà do dao động điện năng, hoặc do yếu tố khác
      [1] https://electronics.stackexchange.com/questions/65837/can-el...
      [2] https://superuser.com/questions/1202062/what-happens-when-ha...
    • Công suất = điện áp × dòng điện
      Điện áp là giá trị do công ty điện lực cung cấp, còn dòng điện được giám sát theo từng rack. Trong datacenter, phản ứng thông thường khi vượt giới hạn dòng điện là cầu chì nổ hoặc bị yêu cầu trả thêm tiền
      Cách duy nhất để giảm điện năng mà server dùng là throttling CPU. Thông thường CPU được throttling thông qua hệ điều hành, nên cần có sự phối hợp
      Tôi đoán có thể làm qua bộ điều khiển baseband lights-out mà không cần OS tham gia, nhưng nếu vậy thì khả năng cao sẽ thấy trong /sys
    • Lạ thật. Tôi luôn đọc rằng điện năng và nhiệt độ cao sẽ làm thiết bị điện tử xuống cấp nhanh hơn nhiều. Có kỹ sư điện tử nào giải thích được không?
    • Mọi rack trong datacenter đều có ngân sách điện năng, và trên thực tế nó bị giới hạn bởi lượng nhiệt mà hệ thống điều hòa có thể lấy ra khỏi datacenter hơn là lượng điện khả dụng
      Dù vậy vẫn giới hạn theo từng rack để vài server công suất cao không làm sập một phạm vi lớn hơn của datacenter
      Tôi không chắc cách giới hạn là gì, nhưng một aptomat đơn giản như ở nhà có thể là giải pháp dễ. Khi đó nếu ngắt thì nguồn của cả rack sẽ tắt, ảnh hưởng đến toàn bộ rack và nhiều khách hàng, nên không lý tưởng
      Lựa chọn khác là bộ giới hạn dòng/công suất[0], nhưng vì P = U * I nên có thể tạo ra nhiều vấn đề hơn. Điện áp (U) giảm khiến toàn bộ hệ thống rơi vào trạng thái điện áp thấp, sinh ra các glitch kỳ lạ. Đây cũng là cách phổ biến để vượt qua nhiều cơ chế bảo vệ của chip. Raspberry Pi cũng đã mở một challenge[1] để tìm các lỗi kiểu này và kiểm tra chip chịu được các kiểu tấn công, gồm cả tấn công điện áp, đến mức nào
      [0] - https://en.m.wikipedia.org/wiki/Current_limiting
      [1] - https://www.raspberrypi.com/news/security-through-transparen...
    • Một khả năng là ở cấu hình điện năng thấp, CPU ít nóng hơn, nên quạt quay ít hơn, khiến các linh kiện khác nhận được ít luồng khí hơn và ngược lại lại nóng hơn
      Cách xử lý thông thường là cũng giám sát nhiệt độ của các linh kiện khác đó và đưa vào đầu vào của thuật toán tốc độ quạt. Không biết thực tế ở đây có xảy ra chuyện đó không

  • Không thể biết chắc, nhưng cũng có thể là vấn đề về nguồn, tín hiệu hoặc VRM
    Việc CPU không nóng không có nghĩa là thứ gì đó khác trên bo mạch không vượt ngoài thông số và rơi vào lỗi nghiêm trọng
    Các vấn đề mainboard quanh nguồn và tín hiệu rất khó chẩn đoán. Bên ngoài chúng biểu hiện thành đủ loại triệu chứng trông như lỗi của linh kiện khác, và theo kinh nghiệm thì lỗi khởi tạo RAM cùng các lần restart ngẫu nhiên rất phổ biến. Cuối cùng bạn sẽ thay thử mọi thứ cho đến khi thực sự thay mainboard

  • Tôi cũng từng gặp chuyện tương tự trên AX102 đang dùng, và có vẻ nó crash do vấn đề liên quan đến card mạng
    May là hỗ trợ của Hetzner xử lý phần cứng thay thế khá tốt. Khá đau đầu, nhưng là cơ hội tốt để học cách khắc phục sự cố phần cứng, và với cá nhân tôi thì đáng công

    • Tôi cũng vậy. AX102 crash dù gần như không có tải, log không có gì, và cũng không bật lại được
      Hetzner đã xem nhiều lần nhưng không tìm ra gì, hoặc chỉ thay keo tản nhiệt CPU và đầu nối PSU. Tôi đã chuyển sang AX162 và đến giờ vẫn ổn

  • Liệu ai có kinh nghiệm về trung tâm dữ liệu có thể phỏng đoán Hetzner đã đạt được giải pháp thương mại nào với nhà cung cấp bo mạch chủ trong trường hợp này không?
    Có nên hiểu là họ đã được thay miễn phí toàn bộ bo mạch chủ, thậm chí còn nhận bồi thường không?

    • Nếu mua máy chủ của thương hiệu nổi tiếng thì phần cứng lỗi chắc chắn sẽ được thay thế.
      Việc bồi thường chỉ có thể có nếu đã đàm phán trước, và trong trường hợp đó phải trả thêm chi phí. Thay vì cố đòi nhà cung cấp trả chi phí downtime, khả năng cao mua thứ như bảo hiểm gián đoạn kinh doanh sẽ hợp lý hơn. Ngay cả khi lỗi thuộc về nhà cung cấp cũng vậy.
      Hetzner không phải khách hàng thông thường. Là một phần của tối ưu chi phí cực đoan, họ có khả năng mua các linh kiện rẻ nhất, và cũng có thể đã đàm phán mức giá thấp hơn mà không kèm bảo hành. Nếu vậy, họ hẳn phải tự mua bo mạch chủ thay thế.
    • Ngay từ đầu có vẻ họ đã nhận được lô hàng này với giá rất rẻ. Vì các máy chủ đó ban đầu được cung cấp không mất phí cài đặt.
      Đó là thời điểm World Cup bóng đá được tổ chức ở Đức.

  • Đây là lần đầu tôi nghe nói rằng nhà vận hành trung tâm dữ liệu giới hạn mức tiêu thụ điện của từng máy chủ vì ràng buộc về điện năng, và điều đó có thể khiến bo mạch chủ xuống cấp nhanh hơn; khá bất ngờ.