Cách xem bản đánh giá sau sự cố ngày 8 tháng 4 của Tencent Cloud

Vào ngày 8 tháng 4 năm 2024, dịch vụ xác thực của Tencent Cloud đã gặp sự cố ngừng hoạt động nghiêm trọng, khiến các dịch vụ hiển thị phụ thuộc vào xác thực đăng nhập, bao gồm cả bảng điều khiển, không khả dụng. Điều này không chỉ gây tổn hại đáng kể đến danh tiếng của Tencent Cloud mà còn ảnh hưởng đến niềm tin của nhiều người đối với các đám mây công cộng trong nước.

May mắn thay, Tencent ngày hôm qua đã phát hành Tencent Cloud Đánh giá và báo cáo sau sự cố ngày 8 tháng 4, trong đó nêu chi tiết nguyên nhân và diễn biến của vụ việc. Sự minh bạch này cho phép sự cố vượt ra ngoài phạm vi hộp đen, cho phép chúng tôi phân tích quá trình xem xét sau từ góc độ kỹ thuật và hiểu lý do tại sao ngay cả một công ty giàu tài nguyên như Tencent cũng có thể gặp phải sự cố như vậy.

Phân tích sau khi chết của Tencent Cloud về việc ngừng dịch vụ

Đầu tiên, chúng ta hãy xem xét dòng thời gian sự cố cung cấp bởi Đám mây Tencent:  

15:23: Phát hiện lỗi và ngay lập tức bắt đầu khôi phục dịch vụ trong khi điều tra nguyên nhân gốc rễ.  

15:47: Tìm thấy rồi khôi phục phiên bản không thể khôi phục hoàn toàn dịch vụ, yêu cầu khắc phục sự cố thêm.  

15:57: Xác định nguyên nhân cốt lõi là dữ liệu cấu hình bị lỗi và khẩn trương thiết kế giải pháp sửa chữa dữ liệu.  

16:02: Bắt đầu khôi phục dữ liệu trên tất cả các khu vực, với các dịch vụ API dần dần khôi phục theo từng khu vực.  

16:05: Quan sát thấy sự phục hồi dịch vụ API ở tất cả các khu vực ngoại trừ Thượng Hải, yêu cầu tập trung khắc phục sự cố ở Thượng Hải.  

16:25: Đã phát hiện Phụ thuộc vòng tròn API các vấn đề ở các bộ phận kỹ thuật của Thượng Hải, quyết định định tuyến lại giao thông đến các khu vực khác để phục hồi.  

16:45: Xác nhận khôi phục khu vực Thượng Hải với việc khôi phục hoàn toàn API và các dịch vụ PaaS phụ thuộc, nhưng lưu lượng truy cập bảng điều khiển tăng đột biến đòi hỏi phải mở rộng công suất gấp 9 lần.  

16:50: Khối lượng yêu cầu được bình thường hóa với hoạt động ổn định và khôi phục hoàn toàn dịch vụ bảng điều khiển.  

17:45: Hoàn thành thời gian quan sát kéo dài một giờ mà không phát hiện vấn đề gì, kết thúc hoạt động ứng phó khẩn cấp.  

 Phân tích nguyên nhân gốc rễ bởi Đám mây Tencent:  

Sự cố ngừng hoạt động do không đủ khả năng tương thích về phía trước những cân nhắc trong phiên bản API đám mây mới và cơ chế phát hành màu xám không đủ cho dữ liệu cấu hình.  

Trong quá trình nâng cấp API, các thay đổi về giao thức giao diện trong phiên bản mới đã gây ra logic xử lý bất thường cho giao diện cũ truyền dữ liệu sau triển khai phụ trợ. Điều này đã tạo ra dữ liệu cấu hình sai lầm nhanh chóng lan truyền khắp tất cả các khu vực do thiếu các biện pháp kiểm soát phát hành màu xám, gây ra lỗi API trên diện rộng.  

Các nỗ lực khôi phục sau lỗi tuân theo các quy trình khôi phục tiêu chuẩn, đồng thời hoàn nguyên các dịch vụ phụ trợ và dữ liệu cấu hình về các phiên bản trước đó khi khởi động lại dịch vụ API. Tuy nhiên, sự phụ thuộc vòng tròn nổi lên như thùng chứa nền tảng lưu trữ dịch vụ API bản thân nó yêu cầu chức năng API cho khả năng lập kế hoạch, ngăn chặn việc phục hồi dịch vụ tự động. Cuối cùng, cần phải có sự can thiệp thủ công của người vận hành để khởi động lại dịch vụ API và khôi phục hoàn toàn.  

 Hai vấn đề quan trọng đã được xác định:  

1. Việc nâng cấp phiên bản phụ trợ mà không có bản cập nhật giao diện người dùng tương ứng đã tiết lộ những thiếu sót về khả năng tương thích ngược (tài liệu của Tencent Cloud đề cập đến khả năng tương thích về phía trước, nhưng ngữ cảnh lại gợi ý các vấn đề về khả năng tương thích ngược).  
2. Lỗi khôi phục do hạn chế phụ thuộc vòng tròn.  

 Các câu hỏi chính vẫn còn: Tại sao Tencent Cloud lại gặp phải những vấn đề này? Các bình luận công khai thường xuyên đặt câu hỏi: “Với những lợi thế vốn có của nền tảng đám mây công cộng đối với thử nghiệm xám trực tuyến, làm sao tình trạng ngừng hoạt động trên quy mô toàn cầu vẫn có thể xảy ra?”

Lý do sâu xa về mặt kỹ thuật và kiến trúc

Do phân tích khám nghiệm tử thi chính thức thiếu chi tiết cụ thể nên nhiều khía cạnh vẫn còn khó khăn để phân tích một cách thuyết phục. Tuy nhiên, với tư cách là một ‘nhà phát triển nền tảng đám mây’, tôi sẽ chia sẻ một số nguyên nhân cơ bản tiềm ẩn dựa trên kinh nghiệm của tôi:  

1. Những thách thức vận hành do sự bùng nổ của microservice gây ra  
2. Rủi ro đáng kể từ việc tự động hóa được phân tích không đầy đủ  

Lưu ý rằng quan điểm của tôi có thể có những thành kiến khi làm việc chủ yếu trên phần mềm doanh nghiệp hơn là các dịch vụ trực tuyến, vì vậy độc giả nên xem xét nhiều quan điểm.

Những thách thức vận hành do sự bùng nổ của microservice gây ra  

Đầu tiên, hãy định nghĩa ‘sự bùng nổ của microservice’. Như đã giải thích trong một bài viết do InfoQ dịch có tiêu đề 微服务——版本组合爆炸！(Microservices—Sự bùng nổ kết hợp của các phiên bản!):  

Hãy để tôi giải thích điều này. Giả sử sản phẩm của chúng tôi bao gồm 10 microservice. Bây giờ giả sử mỗi microservice có một phiên bản mới (chỉ có một phiên bản, nghe có vẻ tầm thường). Nhìn vào sản phẩm một cách tổng thể, với mỗi thành phần có một phiên bản mới, chúng tôi hiện có 2^10 kết hợp—1.024 hoán vị của sản phẩm.  

Vì không có "quy tắc vàng" nào được chấp nhận rộng rãi để phân chia các vi dịch vụ nên các nhà phát triển và nhóm thường không đồng ý về mức độ chi tiết và ranh giới. Điều này dẫn đến sự phát triển quá mức của vi dịch vụ trong các hệ thống lớn, với mỗi dịch vụ tuân theo các chu kỳ phát hành độc lập. Mặc dù các giải pháp như Monorepo nhằm mục đích tối ưu hóa điều này, nhưng việc gỡ lỗi và xác thực nhiều dịch vụ vi mô vẫn còn nhiều thách thức.

Một kịch bản tương tự đã xảy ra vào cuối năm 2022 khi Elon Musk tweet về kiến trúc của Twitter (nay là X, mặc dù vẫn thường được gọi là Twitter), lưu ý rằng “một yêu cầu duy nhất phải vượt qua 1.200 RPC vi dịch vụ” là nguyên nhân gây ra độ trễ.  

Elon Musk’s bài đăng

Mặc dù là một trường hợp cực đoan, nhưng điều này phản ánh một thực tế chung: với các biện pháp quản trị và dịch vụ vi mô phong phú như ngắt mạch và xuống cấp, kiểm soát lưu lượng và tắt máy nhẹ nhàng—cùng với các bản phát hành canary—các nhà phát triển thường gặp khó khăn trong việc tiến hành thử nghiệm toàn diện. Sự tự mãn len lỏi vào, độ phức tạp của hệ thống tăng vọt và rủi ro không được chú ý cho đến khi xảy ra lỗi (đặc biệt khi việc giảm thiểu chủ động mang lại ROI hạn chế).  

Quay lại sự cố này: bản nâng cấp phụ trợ với giao diện người dùng chưa được nâng cấp đã gây ra sự cố tương thích với cấu trúc dữ liệu cũ. Những vấn đề như vậy sẽ không xảy ra trong một ứng dụng nguyên khối—ví dụ: bạn sẽ không bao giờ gặp phải lỗi SQL khi nâng cấp InnoDB mà không cập nhật trình phân tích cú pháp của MySQL, vì các thành phần này được nâng cấp và phát hành cùng nhau.  

Đây là’t để khẳng định kiến trúc nguyên khối là vượt trội, mà đúng hơn là để nhấn mạnh rằng sự bùng nổ phiên bản trở nên không thể tránh khỏi với quá nhiều dịch vụ vi mô. Phần mềm dựa trên lib truyền thống cũng phải đối mặt với “sự bùng nổ phụ thuộc”, nhưng sự phức tạp như vậy được ẩn giấu trong các giai đoạn xây dựng. Dịch vụ vi mô hiện đại, tuy nhiên, bộc lộ sự phức tạp này trong các giai đoạn vận hành.  

phụ thuộc địa ngục

Rủi ro đáng kể từ việc tự động hóa được phân tích không đầy đủ

Lý do chúng tôi nhận thấy rằng việc khôi phục không thể giải cứu nền tảng kịp thời là do 'sự phụ thuộc theo chu kỳ' – thậm chí khởi động lại phần phụ trợ API cũng yêu cầu dịch vụ API phải trực tuyến trước. Theo quan điểm của tôi, điều này thể hiện “rủi ro to lớn của việc tự động hóa được phân tích không đầy đủ”.

Với tư cách là nhà phát triển IaaS, chúng tôi hiểu sâu sắc mức độ phức tạp cực độ của phần mềm cơ bản mà chúng tôi vận hành, do đó liên tục nhắc nhở bản thân ‘Bạn có thể’t Tự động hóa những việc bạn làm’t Hiểu‘. Mã của chúng tôi về cơ bản thể hiện kiến ​​thức kinh doanh. Nếu sự hiểu biết của chúng ta về kinh doanh hoặc kiến ​​thức cơ bản không đủ sâu sắc, chúng ta không bao giờ được tự động hóa một cách mù quáng, nếu không kết quả sẽ chỉ trở nên tồi tệ hơn.

Tuy nhiên, thật đáng tiếc là dù bị thúc đẩy bởi 'yêu cầu' hay 'đánh giá hiệu suất', các nhà phát triển vẫn dễ dàng lao vào tự động hóa những thứ mà họ chưa hiểu hết. Như sự việc này chứng tỏ – khởi động lại dịch vụ vì 'giải pháp cuối cùng' của nhà phát triển phải giảm thiểu sự phụ thuộc và đảm bảo độ tin cậy. Nếu các nhà phát triển biết rằng việc khởi động lại dịch vụ API phụ thuộc vào dịch vụ API thì có thể họ đã không thiết kế nó theo cách này. Tuy nhiên, bất kể lý do gì, cuối cùng nó đã xảy ra.

Tại sao kiến trúc sư của chúng tôi nhấn mạnh điều này? Bởi vì nhân viên hỗ trợ kỹ thuật dưới áp lực của khách hàng/tại hiện trường thường cảm thấy ‘Tôi phải làm gì đó ngay bây giờ’, tương tự như việc các nhà phát triển/nhóm sản phẩm nghĩ rằng ‘việc này phải được tự động hóa’. Tuy nhiên, nếu không hiểu nguyên nhân thực sự hoặc các nguyên tắc cơ bản, hành động hấp tấp có thể tạo ra vấn đề lớn hơn – giống như trường hợp của Tencent Cloud khi việc khởi động lại dịch vụ API yêu cầu các dịch vụ API thông thường.”

Cách tiếp cận của ZStack

Cho dù đó là sự cố nghiêm trọng của dịch vụ S3 của AWS vào năm 2017, dịch vụ quy mô lớn không có sẵn của ứng dụng gọi xe trong nước vào năm ngoái hay sự cố ngừng hoạt động của Đám mây Tencent này, thay đổi nâng cấp vẫn là một trong những yếu tố chính gây ra lỗi trên diện rộng. Vậy ZStack giải quyết những vấn đề này như thế nào?

1. Chiến lược phát triển và xây dựng dựa trên kiến trúc microservice đang trong quá trình  

   Đây là Đám mây ZStackthiết kế kiến trúc cơ bản nhất. Thông qua các vi dịch vụ trong quá trình, chúng tôi đạt được cả lợi ích tách rời của vi dịch vụ và lợi thế vận hành/bảo trì của các ứng dụng nguyên khối, kết hợp một cách hữu cơ các dịch vụ vi mô với kiến trúc nguyên khối.

2. Nền tảng đám mây cung cấp các bản nâng cấp màu xám với mức độ chi tiết đến từng nút điện toán và bộ định tuyến VPC  

   Tính năng này đã có từ ZStack Cloud 4.4 và được cải tiến đáng kể trong phiên bản 5.0. Thông qua các nâng cấp chi tiết màu xám, người dùng có thể xác minh trạng thái dịch vụ trên từng nút điện toán và bộ định tuyến VPC. Bất kỳ sự bất thường nào được phát hiện đều có thể được khôi phục ngay lập tức, giúp tăng đáng kể niềm tin của người dùng vào việc nâng cấp. Kiến trúc và thiết kế chi tiết của bản nâng cấp màu xám của ZStack Cloud sẽ được giới thiệu trong các bài viết sau.  

Giao diện nâng cấp Node Gray tính toán

Giao diện nâng cấp màu xám của bộ định tuyến VPC

3. Những nâng cấp hấp dẫn cho các thành phần ảo hóa  

   Là phần mềm IaaS, các yêu cầu về độ tin cậy của mặt phẳng dữ liệu vượt xa các yêu cầu của mặt phẳng điều khiển. Mối quan tâm lớn nhất về độ tin cậy của mặt phẳng dữ liệu đến từ các thành phần ảo hóa như libvirt và qemu. Đặc biệt đối với qemu với tư cách là “người vận chuyển” máy ảo, bất kỳ sai sót nào cũng có thể trực tiếp gây gián đoạn dịch vụ người dùng. Vì vậy, ZStack cung cấp khả năng nâng cấp nóng cho các thành phần ảo hóa, cho phép người dùng thực hiện nâng cấp tại chỗ các phiên bản qemu đang chạy cục bộ mà không cần khởi động lại hoặc di chuyển VM.

4. Duy trì sự phụ thuộc quản lý đơn giản  

   Hưởng lợi từ thiết kế không trạng thái, quá trình khôi phục nâng cấp của ZStack luôn nhẹ. Trước khi nâng cấp, ZStack Cloud bảo tồn các thư mục cốt lõi. Rollback chỉ yêu cầu khôi phục cơ sở dữ liệu và các thư mục cốt lõi. Trong những trường hợp đặc biệt, chỉ cần đảm bảo phiên bản gói phần mềm chính xác trên các nút điện toán sẽ duy trì “lộ trình thoát” cuối cùng.

Khách quan mà nói, bất kể thiết kế thế nào, độ phức tạp và khiếm khuyết của phần mềm đều không thể tránh được 100%. Do đó, những nỗ lực phối hợp trong thiết kế kiến trúc, triển khai mã hóa, phạm vi kiểm tra, lập kế hoạch giải pháp và kinh nghiệm nhân sự vẫn rất cần thiết. Chính xác là thông qua sự phối hợp chặt chẽ như vậy đó ZStack đã liên tục phục vụ hơn 3.500 khách hàng trong nhiều năm qua.

Để biết thêm nội dung về thiết kế kiến trúc của ZStack, hãy theo dõi ZStack Tin tức & Sự kiện. Chúng tôi sẽ tiếp tục chia sẻ thêm những hiểu biết kỹ thuật.