Google Cloud công bố chi tiết sự cố GCVE

 (cloud.google.com)
1 điểm bởi GN⁺ 2024-05-26 | 1 bình luận | Chia sẻ qua WhatsApp
  • Sự cố của Google Cloud vào tháng 5/2024 là vụ việc xóa một phần môi trường GCVE của khách hàng tại Úc UniSuper; sau khi rà soát nội bộ, nguyên nhân và các biện pháp khôi phục đã được công bố
  • Phạm vi ảnh hưởng bị giới hạn ở một khách hàng, một khu vực, một dịch vụ và một trong nhiều GCVE Private Cloud của khách hàng; các khách hàng khác và những dịch vụ Google Cloud khác không bị ảnh hưởng
  • Trong quá trình triển khai ban đầu, có một giá trị đầu vào của công cụ nội bộ bị để trống, và hệ thống đã xử lý nó thành thời hạn cố định 1 năm; sau khi thời hạn kết thúc, Private Cloud tự động bị xóa
  • Khách hàng và đội ngũ Google đã tiến hành khôi phục 24x7 trong nhiều ngày, với bản sao lưu trên GCS và phần mềm sao lưu của bên thứ ba được sử dụng để phục hồi
  • Google Cloud đã ngừng sử dụng công cụ nội bộ liên quan, kiểm tra thủ công toàn bộ GCVE Private Cloud và sửa hành vi xóa để ngăn sự cố cùng loại tái diễn

Phạm vi sự cố

  • Sự cố lần này ảnh hưởng đến khách hàng Google Cloud là UniSuper, và Google Cloud đã hoàn tất rà soát nội bộ sau khi hệ thống của khách hàng được khôi phục
  • Tác động được giới hạn theo tiêu chí dịch vụ do Google quản lý
    • một khách hàng
    • một khu vực cloud
    • việc khách hàng sử dụng Google Cloud VMware Engine (GCVE)
    • một Private Cloud trải trên hai zone trong số nhiều GCVE Private Cloud mà khách hàng sở hữu
  • Các hạng mục không bị ảnh hưởng cũng được phân định rõ
    • các dịch vụ Google Cloud khác
    • các khách hàng khác đang dùng GCVE hoặc các dịch vụ Google Cloud khác
    • các GCVE Private Cloud khác, Google Account, Orgs, Folders, Projects của chính khách hàng đó
    • dữ liệu sao lưu trong Google Cloud Storage (GCS) ở cùng khu vực

Nguyên nhân: tham số trống trong công cụ nội bộ

  • Vào đầu năm 2023, một nhân viên vận hành của Google đã triển khai một trong các GCVE Private Cloud của khách hàng bằng công cụ nội bộ để đáp ứng yêu cầu bố trí dung lượng cụ thể
  • Công cụ này được dùng cho quy trình ngoại lệ trong quản lý dung lượng, và đã bị loại bỏ cũng như tự động hóa hoàn toàn trong quý 4/2023 nên không còn cần sự can thiệp của con người
  • Nhân viên vận hành đã tuân theo quy trình kiểm soát nội bộ, nhưng một tham số đầu vào trong quá trình cấp phát Private Cloud đã bị để trống
  • Do tham số trống, hệ thống đã gán cho tham số đó một giá trị mặc định chưa được biết tới khi đó là thời hạn cố định 1 năm
  • Khi thời hạn 1 năm do hệ thống gán kết thúc, GCVE Private Cloud của khách hàng đã bị xóa

Vì sao không có thông báo cho khách hàng

  • Việc xóa không xuất phát từ yêu cầu của khách hàng mà bắt nguồn từ tham số trống được để lại khi nhân viên vận hành của Google sử dụng công cụ nội bộ
  • Nếu khách hàng trực tiếp yêu cầu xóa, sẽ có thông báo trước; nhưng trong lần xóa này, không có thông báo nào được gửi cho khách hàng
  • Google Cloud cho biết đã sửa các điều kiện kích hoạt sự cố và hành vi của các hệ thống con để ngăn sự việc tương tự tái diễn

Quá trình khôi phục

  • Khách hàng và đội ngũ Google đã phối hợp 24x7 trong nhiều ngày để thực hiện công tác khôi phục
    • khôi phục GCVE Private Cloud của khách hàng
    • khôi phục cấu hình mạng và bảo mật
    • khôi phục ứng dụng
    • khôi phục dữ liệu để phục hồi toàn bộ vận hành
  • Cách tiếp cận kiến trúc vững chắc và có khả năng phục hồi của khách hàng đã hỗ trợ quá trình khôi phục
  • Các bản sao lưu dữ liệu được lưu trong Google Cloud Storage ở cùng khu vực không bị ảnh hưởng bởi việc xóa
  • Những bản sao lưu đó cùng với phần mềm sao lưu của bên thứ ba đã đóng vai trò quan trọng trong việc phục hồi nhanh chóng

Biện pháp ngăn tái diễn

  • Google Cloud đã thực hiện nhiều biện pháp để ngăn sự cố tái diễn
    • loại bỏ công cụ nội bộ đã kích hoạt chuỗi sự cố
    • kể cả khi cần quản lý dung lượng đặc thù, giờ đây khách hàng kiểm soát thông qua giao diện người dùng và phần liên quan đã được tự động hóa hoàn toàn
    • dọn dẹp cơ sở dữ liệu hệ thống và rà soát thủ công toàn bộ GCVE Private Cloud để xác nhận rằng không có triển khai GCVE nào khác bị đặt vào rủi ro
    • sửa hành vi hệ thống từng đặt GCVE Private Cloud thành đối tượng xóa trong workflow triển khai đó
  • Google Cloud đánh giá rằng trước đây chưa từng có sự cố nào có tính chất như lần này và đây không phải vấn đề mang tính hệ thống
  • Google Cloud cho biết các dịch vụ của họ có những cơ chế bảo vệ như soft delete, thông báo trước và sự kết hợp của human-in-the-loop khi cần; đồng thời xác nhận các cơ chế bảo vệ đó vẫn đang được duy trì
  • Sự phối hợp chặt chẽ với khách hàng là yếu tố quan trọng để khôi phục nhanh, và quản trị rủi ro có khả năng phục hồi cùng các fail-safe để ứng phó với sự cố bất ngờ là yếu tố thiết yếu cho việc phục hồi nhanh
  • Google Cloud cho biết dù đây là sự cố đơn lẻ, uptime và khả năng phục hồi của hãng vẫn được kiểm chứng độc lập là thuộc nhóm cao nhất trong các nền tảng cloud lớn

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-26
Ý kiến trên Hacker News

  • Nhìn vào mức độ ảnh hưởng của sự cố này thì thật ngạc nhiên khi các biện pháp cải thiện lại không sâu rộng hơn. Có vẻ họ chỉ làm đủ để cùng một vấn đề không lặp lại theo đúng cách cũ, nên nếu sau này ở đâu đó xuất hiện một lỗi tương đương thì hoàn toàn có thể dẫn đến kết quả tương tự hoặc còn tệ hơn
    Ví dụ, khi ngừng dịch vụ thì không nên xóa ngay mà nên giữ dữ liệu vài ngày trong trạng thái có thể khôi phục chỉ bằng một nút bấm; hoặc kiểm tra luồng xóa của mọi dịch vụ để vì bất kỳ lý do gì cũng phải thông báo cho khách hàng trước khi chấm dứt; hoặc thêm xét duyệt thủ công cho việc chấm dứt các dịch vụ đang hoạt động vượt quá một quy mô nhất định
    Nếu không có những biện pháp rộng như vậy thì bản phân tích sau sự cố này hoàn toàn không tạo được sự yên tâm. Với một tai nạn ngớ ngẩn đến mức này, bất kỳ nhà cung cấp nào còn chút tự hào về dịch vụ của mình hoặc muốn giữ uy tín cũng phải cho thấy họ sẽ làm quá mức cần thiết để chuyện này không bao giờ xảy ra nữa, nhưng Google Cloud có vẻ chỉ làm ở mức tối thiểu

    • Việc không xóa dữ liệu ngay khi chấm dứt dịch vụ là một nguyên tắc cơ bản của phần mềm doanh nghiệp quá hiển nhiên, nên việc Google đến năm 2024 vẫn chưa có điều này nói lên rất nhiều điều
      Ngay từ thời mới vào nghề, ý tưởng xóa ngay dữ liệu không còn cần nữa đã là vô lý rồi. Trong cơ sở dữ liệu thì người ta dùng xóa mềm bằng một cột đánh dấu đã xóa; dữ liệu trên đĩa thì được di chuyển hoặc đổi tên cho đến khi thật sự chắc chắn có thể xóa; và dù vậy vẫn giữ lại bản sao lưu mới là điều cơ bản
    • Rất đồng ý. Có vẻ họ quan tâm hơn đến việc nhấn mạnh rằng không có vấn đề mang tính hệ thống nào trong cách đội ngũ GCP vận hành nền tảng, và chính vì vậy lại khiến người đọc càng có cảm giác đúng là có vấn đề hệ thống nên thấy bất an hơn. Việc thiếu các biện pháp hợp lý trong bản phân tích sau sự cố trông như thể họ không hề có ý định sửa tận gốc
    • Nếu thay việc xóa thật bằng cờ đánh dấu xóa thì có thể lại sinh ra một lỗi thú vị kiểu “Google Cloud không thể xóa dữ liệu khách hàng nên đã vi phạm quy định của EU”. Có vẻ Google sẽ chọn rủi ro xóa nhầm hơn là không xóa nhầm, và ít nhất ở EU thì lựa chọn đó nghe cũng có lý
    • Không làm mấy việc này nghe như một trò đùa. Thật vô lý khi một nhà cung cấp cloud khổng lồ lại không nghĩ đến việc đặt cơ chế an toàn cho thao tác xóa dữ liệu. Thực tế thì chắc họ đã nghĩ đến nhiều lần rồi, chỉ là không triển khai vì tốn kém
    • Cái gọi là “phân tích sau sự cố” của Google thực sự khó hiểu. Bất kỳ ai từng vận hành dịch vụ online đều có thể thấy rõ là nó thiếu sót, mà kết luận còn đầy vẻ ngạo mạn. Kiểu như “đây là sự cố một lần, sẽ không bao giờ lặp lại, chúng tôi rất xin lỗi nhưng chúng tôi vẫn tuyệt vời và sẽ tiếp tục tuyệt vời”, nên hoàn toàn không cứu vãn được khoảnh khắc khiến người ta chỉ muốn ôm mặt trước Google Cloud

  • Nếu là khách hàng GCP và có TAM, bạn có thể hỏi một câu sẽ khiến họ khó xử. Hãy hỏi xem có cơ chế bảo vệ nào ngăn GCP vô tình xóa hàng loạt tài nguyên trong tài khoản của bạn khi họ mắc lỗi vận hành hay không
    Họ sẽ trả lời rằng vấn đề cụ thể này đã được giảm thiểu bằng việc loại bỏ công cụ đó và tăng cường tự động hóa, nhưng khi đó bạn có thể nói tiếp: “Tôi biết chuyện đó đã được sửa rồi. Vậy trước khi có một vụ xóa quy mô lớn thì có con người xem xét lại không?”
    Với góc nhìn của một người từng làm ở GCP và đã dùng AWS một cách tích cực còn lâu hơn, tôi thấy các biện pháp bảo vệ dựa trên con người của GCP gần như không có và ít hơn AWS rất nhiều. Dù sao thì việc hỏi TAM về rủi ro có thật này hoàn toàn đáng làm

    • Cứ gây áp lực đúng cách là được. Khi đó các TAM sẽ học được cách xử lý hệ thống nội bộ tốt hơn. Họ có thể không tự mình thay đổi được, nhưng đôi khi bạn vẫn có thể nhận được cam kết về đường dây báo cáo lên cấp trên hoặc một thỏa thuận không chính thức
      Nếu đủ nhiều TAM cùng lên tiếng thì biết đâu cuối cùng sẽ có ai đó ở cấp trên hành động
    • Nếu khi tài sản của khách hàng sắp bị xóa mà nhân viên Google liên hệ và đóng gói chuyện đó như một cơ hội để thử giữ chân khách hàng, thì có lẽ trong nội bộ sẽ dễ được chấp nhận hơn. Kèm theo đó còn có tác dụng phụ là thông báo rất rõ cho mọi người rằng sắp có thứ gì đó biến mất

  • Họ nói “đội ngũ Google đã làm việc 24x7 trong vài ngày”, nhưng có vẻ họ không biết số 7 ở đây nghĩa là gì

    • Chắc ý là 24 kỹ sư làm việc 7 giờ mỗi ngày. Bao gồm massage và đồ ăn miễn phí ở căng tin do đầu bếp nấu
    • Nếu hiểu hoàn toàn theo nghĩa đen thì đúng là hơi vô lý. Nhưng x7 đương nhiên có nghĩa là làm cả 7 ngày trong tuần, nên từ chiều thứ Năm đến sáng thứ Ba vẫn có thể gọi là làm việc 24x7. Ý là họ không nghỉ cuối tuần
    • Chắc làm quá nhiều nên vài ngày cảm giác như vài tuần
    • Nếu việc khắc phục kéo dài qua cuối tuần thì nói vậy cũng không phải vô lý
    • Cũng có thể ý là các thành viên trong nhóm thay ca nhau làm liên tục, không ngắt quãng vào ban đêm hay cuối tuần. Cá nhân tôi thấy với những dự án lớn như vậy thì đó luôn phải là chuẩn mặc định

  • Ồ, tôi đã nhầm. Tôi cứ tưởng mặc định của Terraform hay mấy thứ tương tự là xóa ngay không có thời gian phục hồi, rồi ai đó bên UniSuper thử nghiệm và đặt sai phạm vi xóa. Dù sao thì vẫn là vấn đề mặc định, nhưng tôi đã nghĩ đó là lỗi của công cụ bên thứ ba và phía UniSuper
    Việc hóa ra đây là vấn đề từ phía Google mới thật điên rồ. Chắc phía UniSuper chỉ biết thốt lên “cái quái gì vậy?”

    • Bài viết có nói rõ chuyện gì đã xảy ra và không liên quan gì đến UniSuper. Google đã triển khai private cloud bằng một công cụ nội bộ, và công cụ nội bộ của Google đó được cấu hình để tự động xóa sau 1 năm
    • Tôi đoán Google либо đã cấp một khoản credit khổng lồ vào hóa đơn GCP, hoặc trả hẳn một khoản bồi thường riêng

  • Bài liên quan: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
    [0]: https://news.ycombinator.com/item?id=40304666
    [1]: https://news.ycombinator.com/item?id=40313171

  • Việc không dừng lại ở điều tra một công cụ hay quy trình cụ thể, mà còn kiểm tra xem phần còn lại có vấn đề tự động xóa hay không và xác nhận cả hành vi xóa mềm, nghe có vẻ là một đợt rà soát khá kỹ lưỡng.
    Tiến thêm một bước nữa, họ cũng có thể đã rà soát mọi trường hợp mặc định để xem có hành vi mặc định nào đáng ngạc nhiên hay không. Tuy vậy, việc xác định điều gì là “đáng ngạc nhiên” có thể không dễ. Vì thường chính những người ít hiểu rõ công cụ hay API nhất lại dùng nguyên các giá trị mặc định

    • Phần “đã xác nhận cả hành vi xóa mềm” chính xác nằm ở đâu? Những gì họ nói chỉ là đã bảo đảm kịch bản tự động xóa cụ thể này sẽ không còn xảy ra nữa, và lý do chính dường như là “giờ việc triển khai đã được tự động hóa”.
      Trước đây vốn cũng đã tự động hóa, giờ chỉ là tự động hóa hơn nữa thôi, và điều đó hoàn toàn không tạo được cảm giác yên tâm rằng cơ chế xóa là an toàn một cách nhất quán. Nó chỉ có nghĩa là giờ không còn người vận hành ngồi sau tay lái nữa
    • Kiểu sự cố này đúng là một lý do quá tốt để cứ dùng AWS, nên chắc nội bộ cũng đã hoảng không nhẹ.
      “Private Cloud GCVE của khách hàng đã bị xóa sau khi khoảng thời gian 1 năm do hệ thống gán kết thúc. Việc xóa được kích hoạt do một nhân viên vận hành Google dùng công cụ nội bộ đã để trống tham số, và vì đây không phải là yêu cầu xóa từ phía khách hàng nên không có thông báo nào được gửi cho khách hàng. Nếu đây là thao tác xóa do chính khách hàng khởi tạo thì đã có thông báo trước.”
      Tèn ten! Chúng tôi kém cỏi đến mức để một đợt xóa quy mô lớn xảy ra mà không có rà soát của con người. May mà khách hàng này không tin chúng tôi và có bản sao lưu bên ngoài GCP nên chưa đến mức tiêu đời hoàn toàn
      “Trước đây chưa từng có sự cố nào có tính chất như vậy tại Google Cloud. Đây không phải là vấn đề mang tính hệ thống.”
      Dịch ra là: “Ôi trời, đội sales AWS và Azure chắc đã lấy thất bại khổng lồ này của chúng tôi gửi cho mọi khách hàng tiềm năng ba email mỗi người”

  • Khó mà tin được đây là lần đầu chuyện như vậy xảy ra lại nhắm vào một quỹ tương hỗ trị giá hàng tỷ USD. May là vấn đề của UniSuper đã được giải quyết, nhưng có lẽ cũng từng có những trường hợp khác nhỏ hơn đến mức bị bỏ qua.
    Chỉ hy vọng chuyện này sẽ là cú hích mà GCP cần

    • GCVE, tức VMware được quản lý, là một dịch vụ khá obscure. Đây là loại dịch vụ chỉ những doanh nghiệp trị giá hàng tỷ USD muốn nhấc nguyên cụm VMware hiện có lên rồi chuyển lên cloud mới dùng
    • Điểm mấu chốt của sự cố này là có một cấu hình tùy chỉnh đặc biệt mà phần lớn khách hàng không có hoặc không dùng, và nó đã vượt qua một số kiểm tra an toàn. Vì thế các khách hàng nhỏ “thông thường” sẽ không thể bị ảnh hưởng
    • Nếu là khách hàng nhỏ thì họ cũng vẫn sẽ đưa ra báo chí, và báo chí chắc chắn cũng sẽ đưa tin, nên khó mà nhìn nhận như vậy.
      “Google đã xóa dịch vụ cloud của chúng tôi” là tin lớn với doanh nghiệp ở bất kỳ quy mô nào

  • Họ nói rằng “CIO và đội ngũ kỹ thuật của khách hàng xứng đáng được khen ngợi vì đã phối hợp chặt chẽ với đội Google Cloud và thực hiện khôi phục 24x7 một cách nhanh chóng, chính xác”, nên tôi tự hỏi không biết họ chỉ được khen trong bài blog hay còn nhận được cả đống Google Cloud credit nữa

    • Nếu khách hàng đủ năng lực thì gần như không có thực tế nào mà họ lại để Google không phải trả khoản chi phí này. Sẽ chẳng lạ nếu hóa đơn cả năm nay về 0
    • Lẽ ra còn phải có cả bồi thường mang tính trừng phạt nữa

  • Tôi là khách hàng của UniSuper ở Úc. Khi đó tôi không biết chuyện gì đang xảy ra, chỉ nhận email hằng ngày trong lúc họ cố giải quyết. Mãi tới khi đọc tin tức tôi mới biết thực sự đã xảy ra chuyện gì. Cảm giác như họ đã giảm nhẹ toàn bộ sự việc xuống chỉ còn là thời gian ngừng hệ thống.
    Chỉ cần nghĩ đến việc thực sự đã có chuyện gì xảy ra với hàng tỷ USD tiền và quỹ hưu trí của mọi người cũng đủ rùng mình

    • Bạn có nhận những email giống người khác không? Gần như ngày nào cũng có email, và các từ như “disruption”, “apologies”, “frustration” được dùng lặp lại nhiều lần.
      Vài ngày sau còn có một email với tiêu đề “A letter from the CEO”
      “Chúng tôi muốn cập nhật cho bạn về sự gián đoạn dịch vụ.”
      “Trước hết, cá nhân tôi xin lỗi về sự cố lần này, đồng thời cảm ơn bạn đã chờ đợi trong khi đội ngũ của chúng tôi làm việc ngày đêm để lần lượt đưa các hệ thống trở lại trạng thái online.”
      Tôi nghĩ trong hoàn cảnh lúc đó cũng khó mà đòi hỏi một cách giao tiếp rõ ràng hơn hay một lời giải thích minh bạch hơn về những gì đã xảy ra bên trong Google Cloud

  • Thông báo ban đầu về sự việc này đã gây hiểu nhầm khá nhiều. Nó khiến người ta tưởng như Google đã vô tình xóa toàn bộ tài khoản GCP. Đọc bài này xong thì tôi yên tâm hơn đôi chút. Có vẻ như thứ bị mất chỉ là các máy ảo ở quy mô một region, và chuyện đó thực tế có thể xảy ra, hệ thống của tôi có lẽ chịu được mà không gặp vấn đề lớn.
    Bài gốc nghe như thể tất cả bucket GCS, cơ sở dữ liệu SQL ở mọi region đều biến mất hết, mà đó lại là một vấn đề hoàn toàn khác, và tôi hy vọng có thể tin rằng Google sẽ không làm ra chuyện như vậy

    • Khi UniSuper nói thứ bị xóa là subscription chứ không phải tài khoản, đó đã là một dấu hiệu cảnh báo. Nhiều người đã vội kết luận từ chỗ đó