Google Cloud เปิดเผยรายละเอียดเหตุการณ์ GCVE

 (cloud.google.com)
1 คะแนน โดย GN⁺ 2024-05-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เหตุการณ์ของ Google Cloud ในเดือนพฤษภาคม 2024 เป็นกรณีที่ลบส่วนหนึ่งของสภาพแวดล้อม GCVE ของลูกค้าในออสเตรเลีย UniSuper โดยหลังการตรวจสอบภายในได้เปิดเผยสาเหตุและมาตรการกู้คืน
  • ขอบเขตผลกระทบจำกัดอยู่ที่ ลูกค้าหนึ่งราย·รีเจียนหนึ่งแห่ง·บริการหนึ่งรายการ และ Private Cloud หนึ่งรายการจากหลายรายการของ GCVE Private Cloud ของลูกค้า โดยลูกค้ารายอื่นและบริการ Google Cloud อื่นไม่ได้รับผลกระทบ
  • ระหว่างการ deploy ครั้งแรก ค่าอินพุตหนึ่งค่าของเครื่องมือภายในว่างอยู่ และระบบตีความเป็น ระยะเวลาคงที่ 1 ปี ทำให้ Private Cloud ถูกลบโดยอัตโนมัติหลังสิ้นสุดระยะเวลาดังกล่าว
  • ลูกค้าและทีม Google ดำเนินการ กู้คืนแบบ 24x7 เป็นเวลาหลายวัน โดยใช้ข้อมูลสำรองใน GCS และซอฟต์แวร์สำรองข้อมูลจาก third party ในการกู้คืน
  • Google Cloud ดำเนินมาตรการเพื่อป้องกันไม่ให้เกิดเหตุการณ์ประเภทเดียวกันซ้ำ ด้วยการยกเลิกเครื่องมือภายในดังกล่าว ตรวจสอบ GCVE Private Cloud ทั้งหมดด้วยตนเอง และแก้ไขพฤติกรรมการลบ

ขอบเขตของเหตุการณ์

  • เหตุการณ์นี้ส่งผลกระทบต่อลูกค้า Google Cloud คือ UniSuper และ Google Cloud ได้ทำการตรวจสอบภายในเสร็จสิ้นหลังจากกู้คืนระบบของลูกค้าแล้ว
  • ผลกระทบถูกจำกัดตามบริการที่ Google จัดการ
    • ลูกค้าหนึ่งราย
    • คลาวด์รีเจียนหนึ่งแห่ง
    • การใช้งาน Google Cloud VMware Engine(GCVE) ของลูกค้า
    • Private Cloud หนึ่งรายการที่ครอบคลุมสองโซน จาก GCVE Private Cloud หลายรายการที่ลูกค้ามี
  • รายการที่ไม่ได้รับผลกระทบก็ถูกแยกออกอย่างชัดเจน
    • บริการ Google Cloud อื่น
    • ลูกค้ารายอื่นที่ใช้ GCVE หรือบริการ Google Cloud อื่น
    • GCVE Private Cloud อื่นของลูกค้ารายดังกล่าว, Google Account, Orgs, Folders, Projects
    • ข้อมูลสำรองใน Google Cloud Storage(GCS) ที่อยู่ในรีเจียนเดียวกัน

สาเหตุ: พารามิเตอร์ว่างในเครื่องมือภายใน

  • ช่วงต้นปี 2023 ผู้ปฏิบัติงานของ Google ได้ deploy หนึ่งใน GCVE Private Cloud ของลูกค้าด้วยเครื่องมือภายใน เพื่อให้ตรงตาม ข้อกำหนดด้านการจัดวาง capacity เฉพาะ
  • เครื่องมือนี้ถูกใช้ในกระบวนการยกเว้นสำหรับการจัดการ capacity และถูกยกเลิกพร้อมทำให้เป็นอัตโนมัติเต็มรูปแบบในไตรมาส 4 ปี 2023 จึงไม่จำเป็นต้องมีการแทรกแซงจากมนุษย์อีกต่อไป
  • ผู้ปฏิบัติงานปฏิบัติตามขั้นตอนควบคุมภายใน แต่ระหว่างกระบวนการ provisioning ของ Private Cloud มีพารามิเตอร์อินพุตหนึ่งค่าว่างอยู่
  • เนื่องจากพารามิเตอร์ว่าง ระบบจึงกำหนดค่าเริ่มต้นที่ในเวลานั้นยังไม่เป็นที่รับรู้ คือ ระยะเวลาคงที่ 1 ปี ให้กับพารามิเตอร์ดังกล่าว
  • เมื่อระยะเวลา 1 ปีที่ระบบกำหนดไว้สิ้นสุดลง GCVE Private Cloud ของลูกค้าจึงถูกลบ

เหตุผลที่ไม่มีการแจ้งเตือนลูกค้า

  • การลบไม่ได้มาจากคำขอของลูกค้า แต่มาจาก พารามิเตอร์ว่าง ที่ผู้ปฏิบัติงานของ Google ทิ้งไว้ขณะใช้เครื่องมือภายใน
  • หากลูกค้าเป็นผู้ขอลบเอง จะมีการแจ้งเตือนล่วงหน้า แต่การลบครั้งนี้ไม่ได้มีการส่งแจ้งเตือนไปยังลูกค้า
  • Google Cloud อธิบายว่าได้แก้ไขเงื่อนไขที่ก่อให้เกิดเหตุการณ์และพฤติกรรมของระบบย่อยแล้ว เพื่อไม่ให้เกิดเรื่องเดียวกันซ้ำอีก

กระบวนการกู้คืน

  • ลูกค้าและทีม Google ร่วมมือกันแบบ 24x7 เป็นเวลาหลายวันเพื่อดำเนินงานกู้คืน
    • กู้คืน GCVE Private Cloud ของลูกค้า
    • กู้คืนการตั้งค่าเครือข่ายและความปลอดภัย
    • กู้คืนแอปพลิเคชัน
    • กู้คืนข้อมูลเพื่อฟื้นฟูการดำเนินงานทั้งหมด
  • แนวทางสถาปัตยกรรมที่แข็งแกร่งและมี resilience ของลูกค้าช่วยในการกู้คืน
  • ข้อมูลสำรองที่เก็บไว้ใน Google Cloud Storage ในรีเจียนเดียวกันไม่ได้รับผลกระทบจากการลบ
  • ข้อมูลสำรองดังกล่าวและซอฟต์แวร์สำรองข้อมูลจาก third party มีบทบาทสำคัญต่อการกู้คืนอย่างรวดเร็ว

มาตรการป้องกันการเกิดซ้ำ

  • Google Cloud ดำเนินมาตรการหลายอย่างเพื่อป้องกันไม่ให้เหตุการณ์เกิดซ้ำ
    • ยกเลิก เครื่องมือภายใน ที่กระตุ้นลำดับเหตุการณ์ของอุบัติเหตุ
    • แม้ต้องมีการจัดการ capacity เฉพาะ ตอนนี้ลูกค้าจะควบคุมผ่าน user interface และส่วนที่เกี่ยวข้องถูกทำให้เป็นอัตโนมัติเต็มรูปแบบแล้ว
    • ทำความสะอาดฐานข้อมูลระบบ และตรวจสอบ GCVE Private Cloud ทั้งหมดด้วยตนเอง เพื่อยืนยันว่า deployment ของ GCVE อื่นไม่ได้ตกอยู่ในความเสี่ยง
    • แก้ไขพฤติกรรมของระบบใน deployment workflow ดังกล่าวที่เคยตั้งค่า GCVE Private Cloud ให้เป็นเป้าหมายการลบ
  • Google Cloud ประเมินว่าไม่เคยมีเหตุการณ์ลักษณะเดียวกันนี้มาก่อน และไม่ใช่ ปัญหาเชิงระบบ
  • บริการของ Google Cloud มีมาตรการป้องกันตามความจำเป็น เช่น soft delete, การแจ้งเตือนล่วงหน้า และ human-in-the-loop และยืนยันว่ามาตรการป้องกันเหล่านี้ยังคงถูกดูแลต่อไป
  • ความร่วมมืออย่างใกล้ชิดกับลูกค้ามีความสำคัญต่อการกู้คืนอย่างรวดเร็ว และ การบริหารความเสี่ยงที่มี resilience พร้อม fail-safe เพื่อรับมือเหตุการณ์ไม่คาดคิดเป็นสิ่งจำเป็นต่อการกู้คืนอย่างรวดเร็ว
  • Google Cloud ระบุว่าแม้เหตุการณ์นี้จะเป็นเหตุการณ์ครั้งเดียว แต่ uptime และ resilience ของตนยังได้รับการ ตรวจสอบโดยอิสระ ว่าอยู่ในระดับสูงสุดในบรรดาคลาวด์หลัก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-26
ความคิดเห็นจาก Hacker News

  • เมื่อดูจากขนาดของผลกระทบของเหตุการณ์นี้แล้ว น่าแปลกใจที่มาตรการปรับปรุงไม่ได้ลึกซึ้งกว่านี้ ทั้งหมดดูเหมือนแค่ทำให้ปัญหาเดิมไม่เกิดซ้ำในรูปแบบเดิม ดังนั้นในอนาคต ถ้ามีข้อบกพร่องที่เทียบเท่ากันเกิดขึ้นที่ไหนสักแห่ง ก็อาจได้ผลลัพธ์คล้ายกันหรือแย่กว่านั้น
    เช่น เมื่อยุติบริการ ไม่ควรลบทันที แต่ควรเก็บข้อมูลไว้หลายวันในสถานะที่กู้คืนได้ด้วยปุ่มเดียว หรือควร audit flow การลบของทุกบริการเพื่อแจ้งลูกค้าก่อนการยุติไม่ว่าจะด้วยเหตุผลใด หรือควรใส่การตรวจสอบโดยมนุษย์สำหรับการยุติบริการที่ใช้งานอยู่และมีขนาดเกินระดับหนึ่ง
    หากไม่มีมาตรการที่กว้างแบบนี้ postmortem นี้ก็ไม่ได้ทำให้สบายใจเลย สำหรับอุบัติเหตุที่ไร้เหตุผลถึงขนาดนี้ ผู้ให้บริการที่มีความภูมิใจในบริการของตัวเองแม้แต่นิด หรืออยากรักษาชื่อเสียง ควรจะแสดงให้เห็นแบบเกินพอว่าจะไม่ให้เกิดเรื่องแบบนี้อีก แต่ดูเหมือน Google Cloud ทำเพียงขั้นต่ำเท่านั้น

    • การไม่ลบข้อมูลทันทีเมื่อยุติบริการเป็นพื้นฐานของซอฟต์แวร์องค์กรที่ชัดเจนมาก จนการที่ Google ยังไม่มีสิ่งนี้ในปี 2024 บอกอะไรได้มาก
      ตั้งแต่สมัยเป็นพนักงานใหม่ แนวคิดว่าจะลบข้อมูลที่ไม่จำเป็นแล้วทันทีนั้นก็ฟังไม่ขึ้นอยู่แล้ว ในฐานข้อมูล ปกติจะใช้soft delete โดยมีคอลัมน์สำหรับทำเครื่องหมายว่าลบแล้ว ส่วนข้อมูลบนดิสก์ก็ย้ายหรือเปลี่ยนชื่อไว้จนกว่าจะแน่ใจจริง ๆ ว่าลบได้ และถึงอย่างนั้นก็ยังเก็บ backup ไว้
    • เห็นด้วยอย่างยิ่ง ดูเหมือนผู้ดูแล GCP สนใจจะเน้นย้ำว่าไม่มีปัญหาเชิงระบบในวิธีที่พวกเขาบริหารแพลตฟอร์มมากกว่า และกลับเป็นจุดนั้นเองที่ทำให้อ่านแล้วรู้สึกกังวลหนักว่ามีปัญหาเชิงระบบอยู่ การที่ postmortem ขาดมาตรการสามัญสำนึกแบบนี้ ดูเหมือนหมายความว่าไม่ได้คิดจะแก้จริง ๆ
    • ถ้าเปลี่ยนการลบจริงให้เป็น flag การลบ ก็อาจเกิดบั๊กสนุก ๆ อีกแบบ เช่น “Google Cloud ลบข้อมูลลูกค้าไม่ได้ จึงละเมิดกฎระเบียบของ EU” Google น่าจะเลือกการลบโดยไม่ตั้งใจมากกว่าการไม่ลบโดยไม่ตั้งใจ และอย่างน้อยใน EU ก็คงเป็นแบบนั้น
    • การไม่ทำเรื่องแบบนี้เหมือนเรื่องตลก ผู้ให้บริการคลาวด์รายใหญ่ไม่คิดจะใส่ safety guard ให้การลบข้อมูล มันไม่สมเหตุสมผลเลย ในความเป็นจริงคงเคยคิดกันหลายครั้งแล้ว แต่ไม่ได้ทำเพราะมีค่าใช้จ่าย
    • “postmortem” ของ Google นี่เข้าใจยากจริง ๆ คนที่เคยเดินระบบออนไลน์จะรู้ได้ชัดเจนว่าไม่เพียงแต่ไม่เพียงพอ แต่ข้อสรุปยังเต็มไปด้วยความอหังการ แบบว่า “เป็นเหตุการณ์ครั้งเดียว จะไม่เกิดอีก ขอโทษจริง ๆ แต่เรายอดเยี่ยมและจะยอดเยี่ยมต่อไป” จึงไม่ได้ชดเชยโมเมนต์ที่ทำให้ Google Cloud ต้องเอามือกุมหน้าเลย

  • ถ้าคุณเป็นลูกค้า GCP และมีTAM ลองถามแบบนี้ดู พวกเขาน่าจะลำบากใจ ให้ถามว่ามีมาตรการป้องกันอะไรบ้างที่จะทำให้เมื่อ GCP ทำพลาดด้านการจัดการแล้วไม่เผลอลบ resource จำนวนมากในบัญชีของคุณ
    เขาน่าจะตอบว่าปัญหาเฉพาะนั้นบรรเทาแล้วด้วยการเลิกใช้เครื่องมือนั้นและเพิ่ม automation ก็ให้ถามต่อว่า “ผมรู้ว่าแก้เรื่องนั้นแล้ว แล้วก่อนการลบขนาดใหญ่ มีคนตรวจสอบไหม”
    จากมุมมองของคนที่เคยทำงานที่ GCP และใช้งาน AWS อย่างจริงจังมานานกว่า ดูเหมือนว่ามาตรการป้องกันที่อาศัยคนของ GCP แทบไม่มี และน้อยกว่า AWS มาก อย่างไรก็ตาม คุ้มมากที่จะถาม TAM เกี่ยวกับความเสี่ยงจริงนี้

    • กดดันให้ถูกจุดก็พอ แล้ว TAM จะได้เรียนรู้วิธีจัดการระบบภายในให้ดีขึ้น ถึงจะเปลี่ยนอะไรเองคนเดียวไม่ได้ แต่บางครั้งก็อาจได้คำมั่นเรื่องเส้นทางรายงานขึ้นผู้บริหารหรือข้อตกลงไม่เป็นทางการ
      ถ้ามี TAM มากพอส่งเสียงดัง สักวันคนข้างบนอาจขยับก็ได้
    • ถ้าบอกว่าการที่พนักงาน Google ติดต่อเมื่อลูกค้ากำลังจะถูกลบสินทรัพย์ เป็นโอกาสในการพยายามรักษาลูกค้าไว้ ภายในบริษัทน่าจะขายไอเดียนี้ได้ง่ายกว่า ผลพลอยได้คือทำให้ทุกคนรู้ชัดเจนว่ากำลังจะมีอะไรบางอย่างถูกลบทิ้ง

  • บอกว่า “ทีม Google ทำงานแบบ 24x7 หลายวัน” แต่ดูเหมือนจะไม่รู้ว่าเลข 7 ในนี้หมายถึงอะไร

    • น่าจะหมายถึงวิศวกร 24 คนทำงานวันละ 7 ชั่วโมง รวมถึงนวดและอาหารโรงอาหารฟรีที่เชฟทำให้
    • ถ้าตีความตามตัวอักษรสุด ๆ ก็จริงที่ฟังไม่ค่อยสมเหตุสมผล แต่ x7 ย่อมหมายถึงทำงาน 7 วันต่อสัปดาห์ ดังนั้นตั้งแต่บ่ายวันพฤหัสถึงเช้าวันอังคารก็ทำงานแบบ 24x7 ได้ หมายถึงไม่ได้หยุดเสาร์อาทิตย์
    • คงทำงานหนักมากจนหลายวันรู้สึกเหมือนหลายสัปดาห์
    • ถ้างานบรรเทาผลกระทบกินช่วงสุดสัปดาห์ ก็ยังพอสมเหตุสมผล
    • อาจหมายถึงสมาชิกทีมสลับกะกันทำงานต่อเนื่องโดยไม่หยุดช่วงกลางคืนหรือสุดสัปดาห์ก็ได้ ส่วนตัวคิดว่าโปรเจกต์ใหญ่แบบนี้ควรเป็นมาตรฐานแบบนั้นเสมอ

  • ว้าว ผมคิดผิด นึกว่า default ของเครื่องมืออย่าง Terraform คือการลบทันทีโดยไม่มีช่วงเวลากู้คืน และใครสักคนฝั่ง UniSuper ทดสอบแล้วกำหนด scope การลบผิด ถึงจะยังเป็นปัญหา default อยู่ แต่คิดว่าเป็นความผิดของเครื่องมือ third-party กับฝั่ง UniSuper
    กลายเป็นว่าเป็นปัญหาฝั่ง Googleจริง ๆ นี่มันบ้ามาก UniSuper คงรู้สึกว่า “นี่มันอะไรกัน?”

    • ในบทความบอกแล้วว่าเกิดอะไรขึ้น และไม่เกี่ยวกับ UniSuper Google deploy private cloud ด้วยเครื่องมือภายใน และเครื่องมือภายในของ Googleนั้นถูกตั้งค่าให้ลบอัตโนมัติหลังผ่านไป 1 ปี
    • ผมว่า Google คงให้เครดิตก้อนใหญ่ในบิล GCP หรือไม่ก็จ่ายค่าชดเชยแยกต่างหากไปเลย

  • บทความที่เกี่ยวข้อง: 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

  • ฟังดูเหมือนเป็นการตรวจสอบที่ค่อนข้างละเอียด เพราะไม่ได้หยุดอยู่แค่การตรวจสอบเครื่องมือหรือขั้นตอนเฉพาะ แต่ยังดูส่วนอื่น ๆ ด้วยว่าไม่มี ปัญหาการลบอัตโนมัติ หรือไม่ และตรวจสอบพฤติกรรมการลบแบบ soft delete ด้วย
    ถ้าจะก้าวไปอีกขั้น ก็อาจตรวจสอบกรณีค่าเริ่มต้นทั้งหมดว่ามีพฤติกรรมค่าเริ่มต้นใดที่น่าประหลาดใจหรือไม่ แต่การตัดสินว่าอะไร “น่าประหลาดใจ” อาจทำได้ยาก เพราะคนที่ไม่ค่อยรู้จักเครื่องมือหรือ API ดีที่สุดมักเป็นคนที่ใช้ค่าเริ่มต้นตามเดิม

    • ส่วนที่ว่า “ตรวจสอบพฤติกรรมการลบแบบ soft delete ด้วย” อยู่ตรงไหนกันแน่? เขาพูดแค่ว่ารับประกันไม่ให้สถานการณ์การลบอัตโนมัติแบบนี้เกิดขึ้นอีก และเหตุผลหลักก็ดูเหมือนจะเป็น “ตอนนี้การ deploy ถูกทำให้เป็นอัตโนมัติแล้ว”
      ก่อนหน้านี้ก็เป็นอัตโนมัติอยู่แล้ว และตอนนี้อัตโนมัติมากขึ้น ซึ่งไม่ได้ทำให้มั่นใจเลยว่ากลไกการลบนั้นปลอดภัยอย่างสม่ำเสมอ แปลแค่ว่าไม่มีโอเปอเรเตอร์นั่งอยู่หลังพวงมาลัยแล้วเท่านั้น
    • เหตุการณ์แบบนี้เป็นเหตุผลชั้นดีให้หันไปใช้ AWS เฉย ๆ เลย ภายในคงตกใจกันพอสมควร
      “GCVE Private Cloud ของลูกค้าถูกลบหลังจากครบระยะเวลา 1 ปีที่ระบบกำหนดไว้ การลบถูก trigger จากผลที่โอเปอเรเตอร์ของ Google ซึ่งใช้เครื่องมือภายในปล่อยพารามิเตอร์ว่างไว้ และเนื่องจากไม่ใช่คำขอลบจากลูกค้า จึงไม่มีการส่งการแจ้งเตือนให้ลูกค้า หากเป็นการลบที่ลูกค้าเป็นผู้เริ่มเอง ก็จะมีการแจ้งเตือนล่วงหน้า”
      แต่นแต๊น! เราไร้ความสามารถถึงขั้นปล่อยให้เกิดการลบครั้งใหญ่โดยไม่มีการตรวจสอบจากมนุษย์ โชคดีที่ลูกค้ารายนี้ไม่ได้เชื่อใจเราและมีแบ็กอัปอยู่นอก GCP เลยไม่พังยับทั้งหมด
      “Google Cloud ไม่เคยมีเหตุการณ์ลักษณะนี้มาก่อน ไม่ใช่ปัญหาเชิงระบบ”
      แปลว่า “ให้ตายเถอะ เซลส์ของ AWS กับ Azure เอาความล้มเหลวครั้งใหญ่ของเราไปอ้างแล้วส่งอีเมลหาลูกค้าเป้าหมายทุกคน คนละสามฉบับ”

  • บอกว่าเหตุการณ์แบบนี้เกิดขึ้นครั้งแรกกับ กองทุนรวมมูลค่าหลายหมื่นล้านดอลลาร์ นั้นเชื่อยาก ดีแล้วที่ปัญหาของ UniSuper ได้รับการแก้ไข แต่ก็น่าจะเคยมีกรณีอื่นที่เล็กจนถูกมองข้ามได้อยู่บ้าง
    ได้แต่หวังว่าเรื่องนี้จะเป็นแรงกระตุ้นที่ GCP ต้องการ

    • GCVE หรือ VMware แบบ managed เป็นบริการที่ค่อนข้าง obscure เป็นบริการที่มีแต่ บริษัทมูลค่าหลายหมื่นล้านดอลลาร์ ที่ต้องการยกชุด VMware เดิมขึ้นไปไว้บนคลาวด์แบบ lift-and-shift เท่านั้นที่จะใช้
    • ประเด็นสำคัญของเหตุการณ์นี้คือมี การตั้งค่าเฉพาะแบบพิเศษ ที่ลูกค้าส่วนใหญ่ไม่มีหรือไม่ได้ใช้ และมันข้ามการตรวจสอบความปลอดภัยบางส่วนไป ดังนั้นจึงไม่สามารถกระทบลูกค้าเล็ก ๆ “ทั่วไป” ได้
    • ถึงจะเป็นลูกค้ารายเล็กก็คงเอาเรื่องไปบอกสื่อ และสื่อก็น่าจะรายงานแน่นอน ดังนั้นมองแบบนั้นยาก
      “Google ลบบริการคลาวด์ของเรา” เป็นข่าวใหญ่สำหรับบริษัททุกขนาด

  • เขาบอกว่า “CIO และทีมเทคโนโลยีของลูกค้าสมควรได้รับคำชมที่ทำงานอย่างใกล้ชิดกับทีม Google Cloud เพื่อกู้คืนระบบแบบ 24x7 ได้อย่างรวดเร็วและแม่นยำ” เลยสงสัยว่าได้แค่คำชมในบล็อกโพสต์ หรือได้ เครดิต Google Cloud ก้อนโตไปด้วย

    • ถ้าเป็นลูกค้าที่เก่งพอ ไม่มีความเป็นจริงแบบไหนที่ Google จะไม่ต้องเป็นคนจ่ายค่าใช้จ่ายนี้ คงไม่แปลกใจเลยถ้าปีนี้ไม่มีใบแจ้งหนี้เลย
    • ควรมีค่าเสียหายเชิงลงโทษด้วย

  • เป็นลูกค้า UniSuper ในออสเตรเลีย ตอนนั้นไม่รู้ว่าเกิดอะไรขึ้น แต่ระหว่างที่พยายามแก้ไขก็ได้รับอีเมลทุกวัน จริง ๆ แล้วรู้ว่าเกิดอะไรขึ้นจากข่าว รู้สึกเหมือนพวกเขาลดทอนเรื่องทั้งหมดให้เหลือแค่ ระบบล่ม ประมาณนั้น
    แค่จินตนาการว่ามีอะไรเกิดขึ้นจริงกับเงินของผู้คนและเงินกองทุนเกษียณมูลค่าหลายหมื่นล้านดอลลาร์ก็น่ากลัวแล้ว

    • คุณได้รับอีเมลแบบเดียวกับที่คนอื่นได้รับหรือเปล่า? มีอีเมลมาแทบทุกวัน และใช้คำอย่าง “disruption”, “apologies”, “frustration” หลายครั้ง
      ผ่านไปไม่กี่วันก็มีอีเมลหัวข้อ “A letter from the CEO” ด้วย
      “เราขอแจ้งอัปเดตเกี่ยวกับการหยุดชะงักของบริการ”
      “ก่อนอื่น ผมขออภัยเป็นการส่วนตัวต่อเหตุขัดข้องครั้งนี้ และขอขอบคุณที่อดทนรอขณะที่ทีมของเราทำงานทั้งกลางวันและกลางคืนเพื่อทยอยนำระบบกลับมาออนไลน์อีกครั้ง”
      ในสถานการณ์ตอนนั้น ผมคิดว่ายากที่จะเรียกร้องการสื่อสารที่ชัดเจนกว่านี้ หรือคำอธิบายที่ชัดกว่านี้ว่าเกิดอะไรขึ้นภายใน Google Cloud

  • ประกาศแรกเกี่ยวกับเหตุการณ์นี้ทำให้เข้าใจผิดค่อนข้างมาก ฟังดูเหมือน Google ลบทั้งบัญชี GCP โดยไม่ตั้งใจ พออ่านข้อความนี้แล้วก็รู้สึกโล่งใจขึ้น ดูเหมือนสิ่งที่เสียไปมีแค่ เครื่องเสมือนขนาดระดับหนึ่งรีเจียน เท่านั้น และเรื่องแบบนั้นเกิดขึ้นได้จริง และผมคิดว่าระบบของผมน่าจะรับมือได้โดยไม่มีปัญหาใหญ่
    บทความเดิมฟังดูเหมือนบัคเก็ต GCS ของทุกรีเจียน, ฐานข้อมูล SQL ฯลฯ หายไปหมด ซึ่งเป็นปัญหาคนละเรื่องโดยสิ้นเชิง และหวังว่าจะเชื่อได้ว่า Google จะไม่ทำเรื่องแบบนั้น

    • ตอนที่ UniSuper บอกว่าไม่ใช่บัญชี แต่เป็น subscription ที่ถูกลบ นั่นเป็นสัญญาณเตือนแล้ว หลายคนรีบด่วนสรุปจากตรงนั้น