Phân tích hậu sự cố gián đoạn control plane và hệ thống phân tích của Cloudflare
(blog.cloudflare.com)- Từ 11:43 UTC ngày 2/11/2023, control plane và các dịch vụ phân tích của Cloudflare bị gián đoạn, ảnh hưởng đến thay đổi qua dashboard/API, chức năng log và phân tích
- Điểm khởi đầu của sự cố là lỗi nguồn PDX-04 tại Oregon do Flexential vận hành; cơ sở này chứa cụm phân tích lớn nhất và hơn một phần ba thiết bị của cụm high-availability
- Khi quá trình khôi phục utility feed, generator, UPS và circuit breaker liên tiếp gặp vấn đề, các phụ thuộc Kafka·ClickHouse chỉ có tại PDX-04 đã phá vỡ thiết kế high-availability
- Lúc 13:40 UTC ngày 2/11, Cloudflare quyết định failover sang site disaster recovery ở châu Âu; đến 17:57 UTC, phần lớn tác động đến khách hàng đã giảm, nhưng xử lý log, một số API bespoke, cấu hình thủ công Magic WAN và upload Stream còn bị ảnh hưởng lâu hơn
- Cloudflare triển khai Code Orange cho các yêu cầu high-availability của sản phẩm GA, kế hoạch disaster recovery đã được kiểm chứng, chaos testing bao gồm loại bỏ toàn bộ một core datacenter, và kế hoạch ngăn mất log
Phạm vi sự cố và tác động đến khách hàng
- Từ 11:43 UTC ngày 2/11/2023, control plane và các dịch vụ phân tích của Cloudflare gặp sự cố
- Control plane chỉ các giao diện hướng khách hàng, gồm website và API
- Dịch vụ phân tích bao gồm logging và báo cáo phân tích
- Toàn bộ sự cố kéo dài từ 11:44 UTC ngày 2/11 đến 04:25 UTC ngày 4/11
- Lúc 17:57 UTC ngày 2/11, phần lớn control plane đã được khôi phục tại cơ sở disaster recovery
- Sau khi cơ sở disaster recovery online, với phần lớn sản phẩm, nhiều khách hàng có thể đã không gặp vấn đề
- Một số dịch vụ mất nhiều thời gian khôi phục hơn, và khách hàng dùng các dịch vụ đó có thể thấy vấn đề cho đến khi được giải quyết hoàn toàn
- Dịch vụ raw log không được cung cấp cho phần lớn khách hàng trong hầu hết thời gian sự cố
- Dịch vụ mạng và bảo mật của Cloudflare hoạt động như dự kiến trong suốt sự cố
- Có những khoảng thời gian khách hàng không thể thay đổi các dịch vụ đó
- Lưu lượng đi qua mạng Cloudflare không bị ảnh hưởng
Thiết kế ban đầu: high-availability dựa trên 3 datacenter ở Oregon
- Control plane và hệ thống phân tích của Cloudflare chủ yếu chạy trên các máy chủ tại 3 datacenter quanh Hillsboro, Oregon
- Ba datacenter độc lập với nhau, mỗi nơi có nhiều utility power feed và nhiều kết nối mạng dự phòng, độc lập
- Các cơ sở được chọn ở vị trí đủ xa để khó bị cùng lúc ảnh hưởng bởi thiên tai, nhưng đủ gần để vận hành cụm dữ liệu dự phòng active-active
- Ba cơ sở liên tục đồng bộ dữ liệu
- Theo thiết kế, ngay cả khi một cơ sở offline, các cơ sở còn lại vẫn phải tiếp tục vận hành được
- Thiết kế high-availability này bắt đầu được triển khai từ 4 năm trước
- Phần lớn các hệ thống control plane cốt lõi đã được chuyển sang cụm high-availability
- Dịch vụ của một số sản phẩm mới vẫn chưa nằm trong cụm high-availability
- Hệ thống logging được chủ ý không đưa vào cụm high-availability
- Log được xử lý như một bài toán phân tán: xếp hàng tại network edge rồi chuyển đến Oregon core hoặc cơ sở logging khu vực
- Nếu cơ sở logging offline, log phân tích sẽ chờ tại edge, và độ trễ phân tích được xem là chấp nhận được
Khởi đầu lỗi nguồn PDX-04
- Cơ sở lớn nhất trong 3 cơ sở ở Oregon là PDX-04 do Flexential vận hành
- Cloudflare đặt cụm phân tích lớn nhất tại đây
- Hơn một phần ba thiết bị của cụm high-availability cũng nằm ở cơ sở này
- Đây cũng là vị trí mặc định của các dịch vụ chưa được onboard vào cụm high-availability
- Cloudflare là một khách hàng tương đối lớn, sử dụng khoảng 10% tổng công suất của cơ sở này
- Lúc 08:50 UTC ngày 2/11, một sự kiện bảo trì ngoài kế hoạch xảy ra trên một trong các feed điện độc lập của Portland General Electric (PGE) cấp cho PDX-04
- Sự kiện này làm một feed đi vào PDX-04 bị gián đoạn
- Flexential khởi động generator để bù cho feed bị gián đoạn
- Flexential không thông báo cho Cloudflare rằng họ đã failover sang nguồn generator
- Công cụ quan sát của Cloudflare không phát hiện nguồn điện đã thay đổi
- Nếu được báo trước, Cloudflare đã có thể giám sát cơ sở sát hơn và chuyển các dịch vụ control plane phụ thuộc vào cơ sở này sang nơi khác
- Việc Flexential vận hành đồng thời utility feed còn lại và generator cũng là điều bất thường
- Flexential vận hành 10 generator, bao gồm cả thiết bị dự phòng, đủ để gánh toàn bộ tải của cơ sở
- Cũng có thể vận hành cơ sở chỉ bằng utility feed còn lại
- Cloudflare không nhận được câu trả lời rõ ràng về lý do Flexential vận hành kết hợp utility power và generator power
Nguyên nhân chưa được xác nhận và việc generator dừng hoạt động
- Nguyên nhân gốc rễ của các sự kiện sau đó và một số quyết định vẫn chưa được Flexential xác nhận rõ ràng
- Một khả năng còn bỏ ngỏ là Flexential có thể đã tham gia chương trình DSG của PGE
- DSG là chương trình cho phép công ty điện lực địa phương sử dụng generator của datacenter để cung cấp thêm điện cho lưới điện
- Đổi lại, công ty điện lực hỗ trợ bảo trì generator và cung cấp nhiên liệu
- Cloudflare không tìm thấy hồ sơ nào cho thấy Flexential đã thông báo về chương trình DSG
- Cloudflare cũng không nhận được câu trả lời liệu DSG có đang được kích hoạt vào thời điểm xảy ra sự cố hay không
- Khoảng 11:40 UTC, xảy ra ground fault tại transformer của PGE ở PDX-04
- Cloudflare cho rằng transformer này có thể là thiết bị hạ điện áp của feed thứ hai đi vào datacenter, nhưng chưa được xác nhận
- Cũng chưa được xác nhận liệu ground fault này có bắt nguồn từ hoạt động bảo trì ngoài kế hoạch của PGE đã ảnh hưởng đến feed thứ nhất hay không
- Ground fault trên đường dây cao áp 12.470V được thiết kế để hệ thống điện ngắt nhanh nhằm tránh hư hại
- Biện pháp bảo vệ này cũng làm toàn bộ generator của PDX-04 dừng lại
- Kết quả là cả utility line và 10 generator đều offline
- PDX-04 có các dàn pin UPS được cho là có thể duy trì cơ sở trong khoảng 10 phút
- Khoảng thời gian này nhằm bắc cầu giữa lỗi nguồn và việc generator tự động khởi động lại
- Theo quan sát lỗi thiết bị của Cloudflare, pin bắt đầu hỏng chỉ sau 4 phút
- Flexential mất lâu hơn rất nhiều so với 10 phút để khôi phục generator
Chậm khôi phục điện và thông báo đầu tiên
- Dù không được xác nhận chính thức, Cloudflare nghe từ nhân viên Flexential về ba yếu tố cản trở khôi phục generator
- Do cách mạch bị trip bởi ground fault, cần tiếp cận vật lý generator để khởi động lại thủ công
- Hệ thống kiểm soát ra vào của Flexential không có nguồn dự phòng bằng pin nên đã offline
- Ca trực đêm không có nhân sự vận hành hoặc chuyên gia điện có kinh nghiệm, chỉ có nhân viên an ninh và một kỹ thuật viên mới vào làm được một tuần, không có người đi kèm
- Trong khoảng 11:44–12:01 UTC, khi generator chưa được khởi động lại hoàn toàn, pin UPS cạn và mọi khách hàng trong datacenter mất điện
- Flexential không thông báo cho Cloudflare về vấn đề cơ sở trong quá trình này
- Cloudflare lần đầu nhận biết vấn đề datacenter lúc 11:44 UTC, khi 2 router kết nối cơ sở với bên ngoài offline
- Khi không thể truy cập router trực tiếp hoặc qua out-of-band management, Cloudflare liên hệ Flexential và cử đội tại chỗ đến cơ sở
- Thông điệp sự cố đầu tiên Flexential gửi cho Cloudflare là lúc 12:28 UTC
- Nội dung cho biết vấn đề nguồn tại PDX-04 bắt đầu khoảng 12:00 UTC, kỹ sư đang khôi phục và sẽ cập nhật tiến độ mỗi 30 phút
Vấn đề phụ thuộc lộ ra trong thiết kế high-availability
- PDX-04 đã có thiết kế được chứng nhận Tier III trước khi xây dựng và được kỳ vọng cung cấp SLA high-availability, nhưng Cloudflare vẫn lên kế hoạch cho khả năng cơ sở này offline
- Tác động dự kiến là gián đoạn phân tích, log xếp hàng và bị trễ tại edge, và tạm dừng các dịch vụ ưu tiên thấp chưa tích hợp vào cụm high-availability
- Việc hai datacenter còn lại đảm nhiệm cụm high-availability và giữ các dịch vụ cốt lõi online nhìn chung hoạt động đúng kế hoạch
- Vấn đề là một số dịch vụ đáng lẽ phải nằm trong cụm high-availability lại phụ thuộc vào các dịch vụ chỉ chạy tại PDX-04
- Kafka và ClickHouse, phụ trách xử lý log và phân tích, chỉ được cung cấp tại PDX-04
- Một số dịch vụ chạy trong cụm high-availability phụ thuộc vào chúng
- Các phụ thuộc này lẽ ra phải lỏng hơn, phải fail một cách graceful hơn, và phải được phát hiện từ trước
- Trong kiểm thử cụm high-availability, Cloudflare từng đưa từng cơ sở trong hai cơ sở còn lại và cả hai cùng lúc hoàn toàn offline
- Cloudflare cũng đã kiểm thử việc đưa phần high-availability của PDX-04 offline
- Tuy nhiên, họ chưa kiểm thử việc đưa toàn bộ cơ sở PDX-04 hoàn toàn offline
- Các tiêu chuẩn yêu cầu sản phẩm mới và cơ sở dữ liệu liên quan được tích hợp vào cụm high-availability cũng quá lỏng
- Các đội sản phẩm có những con đường khác nhau để đi đến giai đoạn alpha
- Theo thời gian, backend sẽ được chuyển sang best practice, nhưng điều này không được yêu cầu chính thức trước khi tuyên bố GA
- Kết quả là khả năng bảo vệ dự phòng hoạt động không nhất quán giữa các sản phẩm
Chuyển sang site disaster recovery
- Lúc 12:48 UTC, Flexential khởi động lại generator và điện trở lại một phần cơ sở
- Khôi phục điện cho datacenter thường diễn ra từng bước theo từng mạch
- Khi đến lúc bật lại các mạch của Cloudflare, các circuit breaker được xác định là đã hỏng
- Không rõ các breaker này hỏng do ground fault hoặc surge, hay đã có vấn đề từ trước
- Flexential bắt đầu thay các breaker hỏng
- Số breaker hỏng nhiều hơn lượng dự trữ trong cơ sở, nên họ phải mua thêm breaker mới
- Khi Cloudflare thấy nhiều dịch vụ offline hơn dự kiến và Flexential không thể đưa ra thời gian khôi phục, lúc 13:40 UTC họ quyết định failover sang site disaster recovery ở châu Âu
- Chỉ một tỷ lệ nhỏ của toàn bộ control plane cần failover
- Phần lớn dịch vụ tiếp tục chạy trên hệ thống high-availability ở hai core datacenter còn lại
- Lúc 13:43 UTC, dịch vụ đầu tiên được khởi động tại site disaster recovery
- Site này được thiết kế để cung cấp các dịch vụ control plane cốt lõi khi có thảm họa
- Một số dịch vụ xử lý log không được hỗ trợ
- Sau khi dịch vụ khởi động, các lệnh gọi API trước đó bị lỗi đổ dồn lại, gây ra vấn đề thundering herd
- Cloudflare áp dụng rate limit để kiểm soát lượng request
- Trong giai đoạn này, khách hàng của hầu hết sản phẩm có thể thấy lỗi gián đoạn khi thay đổi qua dashboard hoặc API
- Đến 17:57 UTC, các dịch vụ chuyển sang site disaster recovery đã ổn định và tác động trực tiếp đến phần lớn khách hàng giảm xuống
- Một số hệ thống như Magic WAN vẫn cần cấu hình thủ công
- Xử lý log và một số dịch vụ liên quan đến API bespoke không thể dùng cho đến khi PDX-04 được khôi phục
Khôi phục chậm ở một số sản phẩm và khởi động lại PDX-04
- Một số sản phẩm không chạy đúng tại site disaster recovery
- Chủ yếu là các sản phẩm mới chưa được triển khai và kiểm thử đầy đủ quy trình disaster recovery
- Bao gồm dịch vụ Stream để upload video mới và một số dịch vụ khác
- Các đội Cloudflare tiến hành đồng thời hai hướng
- Triển khai lại các dịch vụ đó tại site disaster recovery
- Chuyển chúng sang cụm high-availability
- Flexential thay các circuit breaker hỏng, khôi phục cả hai utility feed, và xác nhận nguồn điện ổn định lúc 22:48 UTC
- Vì các đội đã ứng phó khẩn cấp suốt cả ngày, Cloudflare quyết định để phần lớn nhân sự nghỉ ngơi và bắt đầu công việc đưa PDX-04 trở lại vào sáng hôm sau
- Quyết định này làm chậm toàn bộ quá trình khôi phục, nhưng nhằm giảm khả năng gây thêm sai sót
- Từ sáng ngày 3/11, việc khôi phục dịch vụ PDX-04 bắt đầu
- Khởi động vật lý thiết bị mạng
- Bật hàng nghìn máy chủ và khôi phục dịch vụ
- Do có khả năng nhiều lần power cycle đã xảy ra trong sự cố, trạng thái các dịch vụ trong datacenter không thể biết trước
- Quy trình khôi phục an toàn là thực hiện bootstrap hoàn chỉnh cho toàn bộ cơ sở
- Máy chủ quản lý cấu hình được đưa online thủ công, và việc dựng lại mất 3 giờ
- Sau đó các máy chủ còn lại được dựng lại theo cách bootstrap
- Mỗi máy chủ mất từ 10 phút đến 2 giờ để dựng lại
- Dù chạy song song trên nhiều máy chủ, một số phần cần khôi phục tuần tự do phụ thuộc giữa các dịch vụ
- Tất cả dịch vụ được khôi phục hoàn toàn lúc 04:25 UTC ngày 4/11/2023
- Với phần lớn khách hàng, dữ liệu phân tích cũng được lưu tại core datacenter ở châu Âu, nên dự kiến không mất dữ liệu trong hầu hết phân tích trên dashboard và API
- Một số dataset không được nhân bản sang EU sẽ còn khoảng trống kéo dài
- Khách hàng dùng Logpush không được xử lý log trong hầu hết thời gian sự cố, và các log không nhận được sẽ không được khôi phục
Code Orange và kế hoạch cải thiện
- Cloudflare còn nhiều câu hỏi cần Flexential trả lời, nhưng họ kết luận rằng cũng phải dự liệu cả trường hợp lỗi toàn bộ datacenter
- Tương tự Code Yellow·Code Red của Google, Cloudflare đưa vào quy trình riêng mang tên Code Orange, nhằm tập trung nguồn lực kỹ thuật vào giải quyết vấn đề trong các sự kiện hoặc khủng hoảng nghiêm trọng
- Các chức năng kỹ thuật không cốt lõi được chuyển sang những công việc đảm bảo độ tin cậy cao cho control plane
- Các thay đổi dự kiến gồm
- Loại bỏ phụ thuộc vào core datacenter trong cấu hình control plane của mọi dịch vụ, và khi có thể, chuyển để mạng phân tán của Cloudflare chạy trước
- Đảm bảo control plane chạy trên mạng vẫn tiếp tục hoạt động ngay cả khi mọi core datacenter đều offline
- Yêu cầu các sản phẩm và tính năng GA phụ thuộc vào core datacenter phải dựa vào cụm high-availability mà không có phụ thuộc phần mềm vào một cơ sở cụ thể
- Yêu cầu các sản phẩm và tính năng GA có kế hoạch disaster recovery đáng tin cậy đã được kiểm thử
- Kiểm thử blast radius của lỗi hệ thống và giảm tối thiểu số dịch vụ chịu ảnh hưởng khi lỗi xảy ra
- Triển khai chaos testing nghiêm ngặt hơn cho mọi chức năng datacenter, bao gồm loại bỏ hoàn toàn từng cơ sở core datacenter
- Audit kỹ mọi core datacenter và lập kế hoạch tái audit để đảm bảo tuân thủ tiêu chuẩn
- Xây dựng kế hoạch disaster recovery cho logging và phân tích để log không bị mất ngay cả trong tình huống lỗi mọi core datacenter
- Cloudflare tổng kết rằng dù đã có các hệ thống và quy trình cần thiết, họ thiếu sự nghiêm ngặt để buộc phải tuân thủ chúng và kiểm thử các phụ thuộc chưa biết
1 bình luận
Ý kiến trên Hacker News
Việc dành phần lớn bài viết để nêu đích danh một nhà cung cấp rồi quy trách nhiệm và suy đoán nguyên nhân gốc rễ là một lựa chọn kỳ lạ.
Việc công khai rằng đó là khách hàng lớn trong cơ sở, và thậm chí đưa cả sơ đồ điện mà nhà cung cấp đánh dấu là Confidential vào bản phân tích sau sự cố, cũng có vẻ khá không phù hợp.
Có thể hiểu việc giải thích yếu tố kích hoạt và bối cảnh của sự cố, nhưng trọng tâm của phân tích sau sự cố phải là sự cố của Cloudflare, chứ không phải nhà cung cấp.
Flexential cũng cần làm phân tích sau sự cố của riêng họ, nhưng Cloudflare không cần suy đoán thay rồi công khai điều đó.
Cũng có thể Cloudflare muốn chủ động giải thích trước khi ai đó khác dựng nên câu chuyện trước.
Trong tình huống có ba bên và nhiều hệ thống liên quan đan xen, việc Cloudflare muốn biết đến cùng chuyện gì đã xảy ra để đưa các chế độ lỗi phức hợp như thế này vào thiết kế trong tương lai là hợp lý.
Cá nhân tôi thì biết ơn những thông tin Cloudflare đã chia sẻ.
99% trách nhiệm thuộc về Cloudflare, bên đã không hoàn thành nhiệm vụ cốt lõi.
Việc đào sâu vào bên thứ ba đến mức này ngược lại cho thấy sự việc này đáng xấu hổ với Cloudflare đến đâu.
Có vẻ họ cũng không kiểm tra cầu dao đúng cách, và dù đây là cơ sở tương đối mới, họ còn không đảm bảo được một nửa trong 10 giờ cần để sạc pin máy phát điện.
Trong quá trình bảo trì này lẽ ra họ phải chuyển hoàn toàn sang máy phát điện, và có lẽ họ đã không làm được vì đang hỗ trợ PGE.
Tôi nghĩ CEO Cloudflare nói đúng. Dịch vụ trung tâm dữ liệu là thứ người ta trả tiền với kỳ vọng có dự phòng hoàn toàn; địa điểm này được nói là có 18MW, nhưng nhìn vào thì thậm chí không rõ có phải chỉ có 2 nguồn cấp hay không.
Nếu một nguồn cấp chết thì cấu hình 2N phải tiếp quản, và nếu có máy phát điện thì lẽ ra không nên có vấn đề.
Nếu vậy, việc đưa vào phần mô tả các sự kiện ban đầu đã nắm được cho đến nay là hợp lý.
Có vẻ nhiều khả năng sẽ có phân tích tiếp theo.
https://twitter.com/eastdakota/status/1720688383607861442?t=...
Nhìn vào phần được trích dẫn, nguyên nhân gốc rễ của sự cố là phụ thuộc vào một trung tâm dữ liệu duy nhất.
Họ nói rằng phần lớn hệ thống control plane cốt lõi đã được chuyển sang cụm có tính sẵn sàng cao, nhưng một số sản phẩm mới thì chưa; một số dịch vụ lẽ ra phải nằm trong cụm có tính sẵn sàng cao lại phụ thuộc vào các dịch vụ chỉ chạy ở PDX-04; và một số sản phẩm không được đưa lên site khôi phục thảm họa đúng cách.
Với một công ty như Cloudflare, vốn chống đỡ một phần quan trọng của Internet, thì đây là chuyện khá đáng xấu hổ.
Cloudflare nói rằng vì cho phép nhiều nhóm đổi mới nhanh, các sản phẩm đã đi theo các con đường khác nhau cho đến alpha ban đầu, rồi theo thời gian sẽ chuyển sang best practice, nhưng họ không yêu cầu đó là điều kiện bắt buộc trước khi phát hành rộng rãi.
Đây là một thất bại quản lý hoàn toàn. Chẳng phải họ đã bán cho khách hàng phần mềm có chất lượng alpha theo tiêu chuẩn nội bộ của Cloudflare sao?
https://news.ycombinator.com/item?id=38113503
Có vẻ họ thiếu tự nhận thức.
Đây là mức nghiệp dư, và đặc biệt nghiêm trọng ở chỗ các dịch vụ mới đã được phát hành mà không có tính sẵn sàng cao.
Với tư cách là người bị ảnh hưởng đôi chút bởi sự cố này, tôi thấy bản phân tích sau sự cố này còn thiếu.
75% nội dung nói về sự cố điện ở PDX-04 và trách nhiệm của Flexential; nếu chỉ nhìn văn bản thì những gì xảy ra ở đó có vẻ gần như thảm họa, nên điều đó có thể hiểu được.
Nhưng theo bài viết, đến ngày 2/11 theo UTC, điện đã được khôi phục hoàn toàn, vậy mà sau đó Cloudflare vẫn mất thêm khoảng 30 giờ để khôi phục hoàn toàn.
Thời gian khôi phục còn dài hơn cả sự cố, nhưng bài viết chỉ nói rằng quá nhiều dịch vụ phụ thuộc lẫn nhau. Tôi muốn biết chi tiết hơn vì sao việc khôi phục toàn bộ vận hành lại mất lâu như vậy.
Không có bài học nào rút ra từ chính quá trình khôi phục sao? Hay thật sự chỉ là mất chừng ấy thời gian để đồng bộ lại dữ liệu từ edge về “bộ não”?
Một phần còn thiếu nữa là thiếu giao tiếp với khách hàng enterprise. Hỗ trợ của Cloudflare gần như im lặng ngoài trang trạng thái; dù thực tế có thể không làm được nhiều, họ vẫn cần cố gắng giao tiếp.
Điều này càng đúng hơn sau khi bản phân tích sau sự cố đổ lỗi cho việc Flexential thiếu giao tiếp; tôi thích sản phẩm của Cloudflare, nhưng tôi nghĩ cần rút ra nhiều kết luận hơn từ sự việc này.
Tuy nhiên gọi đây là phân tích sau sự cố thì hơi lệch. Một bản phân tích sau sự cố đầy đủ phải có mức chi tiết như đã nói ở trên.
Khi logging sập thì chính xác dịch vụ nào thất bại? Nó được thiết kế như vậy ngoài ý muốn sao? Vì sao không ai nhận ra?
Điểm tốt là bài phân tích hậu sự cố của Cloudflare rất kỹ lưỡng
Cách giải thích thẳng thắn và minh bạch thật sự mới mẻ so với chiến lược truyền thông mơ hồ của hầu hết các công ty khác
Chúng tôi cũng bị ảnh hưởng, nhưng chính những bài viết như thế này lại khiến tôi không muốn rời đi. Ai cũng có thể mắc lỗi và có những ngày tồi tệ; điều tạo nên khác biệt là cách họ phản ứng sau đó
Sự cố điện chỉ cần một đoạn là đủ, sau đó lẽ ra phải chuyển sang phía Cloudflare. Sự cố trung tâm dữ liệu có thể xảy ra
Bài học thật sự nằm ở cách phản ứng của Cloudflare, khi họ không cân nhắc và khôi phục đúng mức trong tình huống đó
Chúng tôi phụ thuộc rất nhiều vào CloudFlare Images, mà trong 30 ngày gần đây dịch vụ này đã ngừng hoạt động hơn 67 giờ
Ngày 9/10 là 22 giờ, ngày 2–4/11 là 42 giờ, xen giữa còn có các sự cố khoảng 1 giờ; độ khả dụng trong tháng vừa rồi là 90,6%
Minh bạch là một điểm khác biệt tuyệt vời giữa các nhà cung cấp cạnh tranh ở mức độ khả dụng 99,9%, nhưng nếu đến một chữ số 9 còn chỉ vừa vượt qua thì cũng chẳng có nhiều ý nghĩa
Điều đó không giúp cải thiện hành vi nhiều, và có thể làm các động lực trở nên tệ hơn
Tôi đánh giá cao việc họ nói sẽ sửa các lỗi quy trình ở đây. Tuy vậy, luôn có sự căng thẳng giữa di chuyển nhanh và làm cho chắc chắn
Thường thì những chuyện này được xử lý như thời tiết: bị mưa ướt rồi mới đi mua áo mưa
Tôi tò mò làm sao để biến độ tin cậy thành một phần của văn hóa mà không để quy trình trói buộc phát triển
Cũng có thể mô hình hóa hệ thống bằng phần mềm, rồi xác thực mô hình đó bằng phân tích lưu lượng. Nếu có thể giảm chi phí thử nghiệm độ tin cậy bằng các thí nghiệm ảo, có lẽ sẽ bắt được nhiều vấn đề hơn trước khi phát hành
Thật lạ là đọc bài này xong tôi lại giảm niềm tin vào Cloudflare
Họ công kích khá mạnh rằng Flexential đã hành xử thiếu chuyên nghiệp, và chuyện đó có thể đúng
Nhưng việc toàn bộ hệ thống mà mọi người phụ thuộc bị sập là một thất bại dự phòng khổng lồ từ phía Cloudflare. Một trung tâm dữ liệu như vậy có biến mất thì dịch vụ vẫn phải duy trì được
Đặc biệt đáng lo là thiết kế chủ đích lại bắt đầu bằng câu “mặt phẳng điều khiển và hệ thống phân tích của Cloudflare chủ yếu chạy trên các máy chủ tại 3 trung tâm dữ liệu gần Hillsboro, Oregon”
Nếu là mặt phẳng điều khiển được người dùng toàn cầu sử dụng thì cần phân tán địa lý rộng hơn rất nhiều. Điều còn đáng ngạc nhiên hơn là đây không phải một triển khai lỗi, mà nằm ở cấp thiết kế chủ đích
Nếu đưa một sản phẩm mới ra cho người tiêu dùng, chẳng phải thiết kế dự phòng nên là ưu tiên hàng đầu sao? Việc nó từng là một tùy chọn đã khiến tôi bất ngờ
Tôi cũng dùng Cloudflare cho một số hệ thống, vì tin rằng nếu xảy ra sự cố như vậy thì họ sẽ có cơ chế chuyển đổi dự phòng tốt. Giờ tôi phải nghĩ lại xem Cloudflare Workers có thật sự an toàn trước những quyết định thiết kế kiểu này không
Việc các lệnh gọi API từng thất bại dồn lại và làm dịch vụ quá tải khi bật site khôi phục thảm họa cũng cho thấy thiết kế cốt lõi của Cloudflare rốt cuộc chưa được dự phòng đủ tốt
Tôi thất vọng vì bài viết này cố đẩy trách nhiệm sang Flexential. Với tư cách khách hàng, tôi kỳ vọng Cloudflare xử lý một cách êm thấm ngay cả khi ngày mai Flexential biến mất vì động đất
Đặt cả một cụm quan trọng như vậy trong khu vực đã biết có rủi ro động đất và sóng thần có phải là ý hay không?
Có vẻ như khôi phục thảm họa ở châu Âu cũng không hoạt động đúng
Câu “chúng tôi chưa từng kiểm thử việc đưa toàn bộ cơ sở PDX-04 hoàn toàn ngoại tuyến” là một bài học đau đớn
Nhưng nếu không tắt nguồn trung tâm dữ liệu về mặt vật lý, hoặc ít nhất cắt mạng của nó với thế giới bên ngoài, thì chưa thật sự kiểm thử thảm họa
Có thể trách nhà vận hành cơ sở, nhưng cuối cùng thì họ phải có khả năng khôi phục ngay cả khi một trung tâm dữ liệu hoàn toàn ngoại tuyến và không bao giờ quay lại nữa
Thiên tai có thể xóa sổ cơ sở đó khỏi Trái Đất
Tôi thích đoạn “vì cả đội đã dốc toàn lực ứng phó khẩn cấp suốt cả ngày, chúng tôi quyết định để phần lớn nghỉ ngơi rồi sáng hôm sau bắt đầu chuyển lại về PDX-04. Quyết định này làm chậm quá trình khôi phục hoàn toàn, nhưng chúng tôi tin rằng nó giảm khả năng chồng thêm sai sót”
Trong các báo cáo kiểu này, sự mệt mỏi của con người thường bị đánh giá thấp. Cố sửa một sự cố lớn khi đã quá kiệt sức chỉ làm tăng các lỗi lẽ ra có thể tránh được
Tôi không biết điều đó vận hành thế nào trong một tổ chức tầm cỡ Cloudflare, nhưng bên chúng tôi cũng có kế hoạch cho nhân viên luân phiên làm việc và ngủ khi xảy ra sự cố lớn
Vấn đề là cần có cách bàn giao trạng thái hiện tại của sự cố cho những người mới thức dậy hoặc mới kết nối vào
Như Mike Tyson nói, ai cũng có kế hoạch cho đến khi bị đấm một cú vào mặt
Cấu trúc bài viết khá đáng ngạc nhiên. Họ dành 75% blog để nói về bên thứ ba, rồi chỉ dùng ít đoạn hơn nhiều cho nỗ lực khôi phục của chính Cloudflare
Việc đưa ra lộ trình phía trước là tích cực, nhưng tôi tự hỏi tại sao bây giờ họ không chỉ thừa nhận thất bại và tình hình, rồi sau khi mọi chuyện lắng xuống mới công bố một bản phân tích hậu sự cố đầy đủ, không suy đoán
Nhà đầu tư có thể chỉ đọc bài này hoặc phần tóm tắt và xem đây là một vấn đề nhà cung cấp đơn giản, thay vì một vấn đề sâu cần nhiều tháng làm lại và tốn hàng triệu đô la
Tài liệu này không hay
Họ có một cấu hình tính sẵn sàng cao gồm 3 trung tâm dữ liệu nhưng đã thất bại hoàn toàn
Tại sao phần đầu tài liệu lại toàn đổ lỗi cho nhà vận hành trung tâm dữ liệu? Việc quản lý cơ sở trung tâm dữ liệu nằm ngoài tầm kiểm soát của Cloudflare
Cloudflare đã đánh cược rằng không kiểm thử đúng cách cấu hình tính sẵn sàng cao mà họ có thể kiểm soát cũng sẽ không sao
Vấn đề vận hành trung tâm dữ liệu thì nên bàn với nhà vận hành, nhưng đó là chuyện giữa hai bên, không phải nội dung nên đưa vào bản phân tích hậu sự cố này
Phần quan trọng lại bị chôn quá sâu. Phải cuộn một lúc lâu mới thấy câu này
“Một số dịch vụ lẽ ra phải nằm trong cụm có tính sẵn sàng cao lại đang phụ thuộc vào các dịch vụ chỉ chạy tại PDX-04”
Đây mới chính là điểm cốt lõi
Nếu đã xây dựng một site “thảm họa”, có lẽ phải tìm bằng được cách kiểm thử nó
Họ nói rằng khi dịch vụ được bật lên, các lệnh gọi API vốn đang thất bại dồn dập đổ tới, gây ra vấn đề bầy sấm sét, và họ đã triển khai giới hạn tốc độ để kiểm soát lượng yêu cầu
Nhưng nội dung này dường như không có trong các mục ở cuối bài
Điều tôi tò mò lúc này là, khi hệ thống phức tạp đến mức có thể gây ra lỗi bán ổn định[1] và không có dư địa để kiểm thử bằng lưu lượng thật, thì nên thiết kế chuyển đổi dự phòng lạnh như thế nào
Có thể hình dung các kỹ thuật sẽ dùng để triển khai, nhưng vấn đề là thiết kế và kiểm thử sao cho xác nhận được các kỹ thuật đó hoạt động trong tình huống thực tế
Một điểm nữa có vẻ hoàn toàn bị bỏ sót là sự cố bắt đầu lúc 11:43 UTC ngày 2/11, nhưng thời điểm họ quyết định chuyển sang site khôi phục sau thảm họa ở châu Âu là 13:40 UTC
Vì sao lại mất lâu như vậy để ra quyết định? Tôi hiểu đây không phải quyết định có thể xem nhẹ, nhưng dù trong phần lớn thời gian họ kỳ vọng điện sẽ sớm được khôi phục, 2 giờ vẫn trông như quá do dự
Dù có cam kết nào đi nữa, cũng cần có một ngưỡng được định trước để buộc phải bấm nút chuyển. Ngưỡng đó thật sự được đặt xa đến vậy sao?
[1] http://charap.co/metastable-failures-in-distributed-systems/
Thứ gây ra hỏng hóc thường lại chính là hệ thống dự phòng