- เมื่อวันที่ 12 มิถุนายน 2025 มีการเพิ่มขึ้นของข้อผิดพลาด 503 ทั่วโลกในการเรียก external API ของบริการ Google Cloud และ Google Workspace
- สาเหตุของข้อผิดพลาดมาจากการเปลี่ยนโค้ดในระบบ Service Control และการนำ policy ที่ไม่ถูกต้องซึ่งมี blank field อยู่ในข้อมูล policy มาใช้งาน
- ปัญหาลุกลามมากขึ้นจาก การจัดการข้อผิดพลาดที่ไม่เพียงพอ ในไบนารีหลักและการไม่ใช้ feature flag
- การกู้คืนใช้เวลาประมาณ 2–3 ชั่วโมง โดยภูมิภาค us-central-1 ใช้เวลานานกว่าเนื่องจากโครงสร้างพื้นฐานรับภาระเกิน
- Google ประกาศมาตรการป้องกันไม่ให้เกิดซ้ำ เช่น การแยกสถาปัตยกรรม, ปรับปรุงการจัดการข้อผิดพลาด, และเพิ่มความเข้มงวดในการตรวจสอบข้อมูล
ภาพรวมเหตุขัดข้องทั้งหมด
สรุปเหตุขัดข้องของบริการ Google Cloud และ Google Workspace
- ตั้งแต่เวลา 10:49 น. (PDT) ของวันที่ 12 มิถุนายน 2025 หลายบริการรวมถึง Google Cloud, Google Workspace และ Google Security Operations พบว่าข้อผิดพลาด 503 เพิ่มขึ้นอย่างรวดเร็วสำหรับ external API request
- Google แสดงความขอโทษอย่างยิ่งต่อผลกระทบร้ายแรงที่เกิดขึ้นกับบริการลูกค้าและความเชื่อมั่น
- Google API management and control plane ทำหน้าที่ตรวจสอบ policy และ quota ของแต่ละ request โดยระบบตรวจสอบหลักทำงานเป็นไบนารีชื่อ ‘Service Control’
การวิเคราะห์สาเหตุของเหตุขัดข้อง
โครงสร้างระบบที่เปลี่ยนไป – Service Control
- เมื่อวันที่ 29 พฤษภาคม 2025 มีการเพิ่ม ฟีเจอร์ใหม่เพื่อเสริมการตรวจสอบ quota policy ใน Service Control
- แม้จะทยอยเปิดใช้งานเป็นรายภูมิภาค แต่โค้ดที่มีปัญหาจะทำงานเฉพาะเมื่อ policy ถูกนำไปใช้จริง เท่านั้น จึงไม่ถูก trigger มาก่อนและการทดสอบล่วงหน้าไม่เพียงพอ
- เส้นทางของฟีเจอร์ใหม่นี้ไม่มี การจัดการข้อผิดพลาดที่เหมาะสมและไม่มี feature flag ทำให้ไบนารี crash ต่อเนื่องเมื่อเกิดสถานการณ์ null pointer
ลำดับการเกิดเหตุขัดข้อง
- เวลา 10:45 น. (PDT) ของวันที่ 12 มิถุนายน 2025 มีการใส่การเปลี่ยนแปลง policy ลงในตาราง Regional Spanner
- ข้อมูล policy นี้มี blank field ที่ไม่ได้ตั้งใจรวมอยู่ด้วย และถูก replicated ไปทั่วโลกเกือบแบบเรียลไทม์
- เมื่อ Service Control ประมวลผล policy นี้ จึงเกิด crash จาก null pointer และ instance ในแต่ละภูมิภาคเข้าสู่ภาวะ crash loop ทั่วโลก
- ภายใน 2 นาที ทีม SRE เริ่มรับรู้เหตุการณ์ และภายใน 10 นาทีสามารถระบุสาเหตุได้ จากนั้นปิดกั้นเส้นทางไบนารีชั่วคราว (red-button) และภูมิภาคส่วนใหญ่ฟื้นตัวได้ภายใน 40 นาที
ปัญหาเพิ่มเติมระหว่างการกู้คืน
- บางภูมิภาคขนาดใหญ่ เช่น us-central-1 เกิด herd effect ระหว่างการรีสตาร์ต task ของ Service Control จนทำให้โครงสร้างพื้นฐาน (ตาราง Spanner) รับภาระเกิน
- Service Control ไม่ได้ใช้ randomized exponential backoff ทำให้ภาระต่อโครงสร้างพื้นฐานยิ่งเพิ่มขึ้น
- ภูมิภาคดังกล่าวกู้คืนล่าช้าถึง 2 ชั่วโมง 40 นาที โดยมีการเบี่ยงทราฟฟิกเพื่อลดผลกระทบ และสุดท้ายบริการทั้งหมดกลับมาใช้งานได้
ผลกระทบต่อลูกค้าและขอบเขตของเหตุขัดข้อง
- ลูกค้าพบ ปัญหาในการเข้าถึง API และ user interface ขณะที่บริการสตรีมมิงและทรัพยากร IaaS ไม่ได้รับผลกระทบ
- ผลกระทบด้าน latency และ backlog ยังคงอยู่ในบางบริการนานสูงสุดเกิน 1 ชั่วโมง
- มีการระบุรายชื่อผลิตภัณฑ์ Google Cloud และ Google Workspace ที่ได้รับผลกระทบเป็นวงกว้าง
- ตัวอย่าง: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive และบริการอื่น ๆ อีกหลายสิบรายการ
แนวทางปรับปรุงในอนาคต
- แยกส่วนสถาปัตยกรรมบริการให้เป็นโมดูล เพื่อแยกแต่ละฟังก์ชัน และนำการทำงานแบบเปิดทางไว้เมื่อเกิดปัญหา (fail open) มาใช้
- เพิ่มความเข้มงวดในการ กระจายข้อมูลแบบ global replication เป็นลำดับขั้น และกระบวนการตรวจสอบจริง
- ปรับนโยบายให้การเปลี่ยนแปลงไบนารีหลักทั้งหมดต้อง อยู่หลัง feature flag และปิดไว้เป็นค่าเริ่มต้น
- ทบทวนการออกแบบให้สามารถตรวจจับข้อผิดพลาดและทำงานแบบ fail open ได้เมื่อเกิดเหตุ ผ่าน static analysis และการทดสอบที่ดีขึ้น
- มีแผนเพิ่มนโยบาย randomized exponential backoff รวมถึงเสริมความน่าเชื่อถือของการมอนิเตอร์และการสื่อสาร
- จะเสริม redundancy ของโครงสร้างพื้นฐานและระบบสื่อสารอัตโนมัติ เพื่อให้สามารถ มอนิเตอร์และส่งข้อมูลแก่ลูกค้าได้อย่างรวดเร็ว แม้ในสถานการณ์เหตุขัดข้อง
การประกาศเหตุขัดข้องและการสื่อสาร
- หลังเกิดเหตุไม่ถึง 1 ชั่วโมง มีการประกาศผ่าน Cloud Service Health แต่โครงสร้างพื้นฐานสำหรับการมอนิเตอร์เองก็ได้รับผลกระทบด้วย
- ลูกค้าบางรายไม่สามารถใช้ระบบมอนิเตอร์ที่ทำงานบน Google Cloud ได้ตามปกติ จึงตรวจจับสัญญาณและประเมินผลกระทบของเหตุขัดข้องได้ยาก
- Google ให้คำมั่นว่าจะ เสริมโครงสร้างพื้นฐานด้านการมอนิเตอร์และการสื่อสารกับลูกค้า ในอนาคต
ไทม์ไลน์หลักของเหตุขัดข้อง (สรุปรายงานย่อ)
- เริ่มเกิดเหตุขัดข้อง: 12 มิถุนายน 2025 10:49 น. (PDT)
- ภูมิภาคส่วนใหญ่กู้คืน: 12 มิถุนายน 2025 12:48 น. (PDT)
- เหตุขัดข้องสิ้นสุด: 12 มิถุนายน 2025 13:49 น. (PDT)
- ระยะเวลารวม: ประมาณ 3 ชั่วโมง
- พื้นที่ที่ได้รับผลกระทบ: ทั่วโลก
สรุปมาตรการหลังเหตุการณ์
- มีแผนจัดทำกลไกป้องกันความล้มเหลวเมื่อเกิดข้อผิดพลาดหรือความเสียหายของข้อมูลใน แพลตฟอร์มจัดการ API
- จะเพิ่มความเข้มงวดด้าน การตรวจสอบ, การทดสอบ, และการมอนิเตอร์ ก่อนการกระจาย global metadata
- จะขยาย การจัดการข้อผิดพลาดของระบบและการทดสอบแบบครอบคลุม สำหรับข้อมูลที่ไม่ถูกต้อง
รายการบริการที่ได้รับผลกระทบ (คัดบางส่วน)
บริการหลักของ Google Cloud
- Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine เป็นต้น
บริการหลักของ Google Workspace
- AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar เป็นต้น
บทสรุป
- เหตุขัดข้องครั้งนี้เป็นผลจากการทำงานร่วมกันของปัญหาใน โครงสร้างระบบจัดการ policy/quota, การตรวจสอบความสมบูรณ์ของข้อมูลที่ไม่เพียงพอ, และ การไม่มีระบบจัดการข้อผิดพลาดที่เหมาะสม
- Google ให้คำมั่นว่าจะ ปรับปรุงในระดับสถาปัตยกรรม และเสริมความสามารถในการรับมือเหตุขัดข้อง
2 ความคิดเห็น
ลิงก์ไปยังบทความเวอร์ชันที่ไม่ใช่ GN+
ความคิดเห็นจาก Hacker News
ในฐานะคนวงใน ตอนนี้กำลังใช้บัญชีชั่วคราวอยู่ และมองว่าสาเหตุรากของเหตุการณ์ครั้งนี้คือฝ่ายผู้นำละเลยหลักการเพื่อเร่งความเร็ว แนวปฏิบัติแบบนี้ดำเนินมาหลายปีจนสุดท้ายก็ชนเพดาน สิ่งที่เรียกว่า ‘query of death’ ครั้งนี้เป็นรูปแบบความล้มเหลวคลาสสิกที่แทบเลี่ยงไม่ได้ของเซิร์ฟเวอร์ C++ รุ่นเก่าที่แครชจากคิวรีบางแบบ Service Control เขียนด้วย C++ และพยายามลดความล้มเหลวประเภทนี้ด้วยแนวทางวิศวกรรมหลายอย่าง ตลอด 10 ปีที่ผ่านมาให้บริการโดยไม่มีอุบัติเหตุใหญ่ แต่ปัญหาคือนโยบายโควตาระดับโลกที่ทำขึ้นอย่างเร่งรีบภายใต้แรงกดดันจากผู้บริหาร ฟีเจอร์ใหม่แบบนี้ควรถูกพัฒนาเป็นบริการแยกต่างหาก หรืออย่างน้อยก็ควรปฏิบัติตามแนวทางเดิม รายงานทางการพูดถึงมาตรการรับมือน้อยกว่ามาตรฐานที่ทีมยึดถือกันมาเดิมมาก และทีมก็กำลังพยายามรักษามาตรฐานเดิมไว้ให้ได้มากที่สุด
คิดว่ารายงานอุบัติเหตุน่าสนใจดี ทีม SRE ตอบสนองได้เร็วมากภายใน 2 นาที และเริ่มทำ ‘red button’ rollout แล้ว ปัญหาคือเมื่อ Service Control task รีสตาร์ตในรีเจียนขนาดใหญ่อย่าง us-central-1 ก็เกิด ‘herd effect’ ที่ทำให้โครงสร้างพื้นฐาน (ตาราง Spanner) รับภาระเกินกำลัง เนื่องจาก Service Control ไม่ได้ implement random exponential backoff จึงทำให้การกู้คืนเต็มรูปแบบล่าช้าไปถึง 2 ชั่วโมง 40 นาที ในสถานการณ์แบบนี้โควตาปกติมักเต็มอย่างรวดเร็วและนำไปสู่ความขัดข้องใหม่ คิดว่าในกรณีเช่นนี้ถ้าโครงสร้างพื้นฐานรับไหว การหยุดใช้โควตาชั่วคราวหรือจำกัดความเร็วของงานกู้คืนให้ช้าลงก็น่าจะดี
นี่ดูเป็นความผิดพลาดระดับสมัครเล่นจริง ๆ NPE, ไม่มี error handling, ไม่มี exponential backoff, ไม่มี test coverage, ไม่มีการทดสอบใน staging environment, ไม่มี gradual rollout ล้วนเป็นความล้มเหลวร้ายแรงทั้งสิ้น เรื่องพวกนี้มีเขียนไว้หมดแล้วในหนังสือ SRE สารบัญ Google SRE Book, Building Secure and Reliable Systems TOC เลยสงสัยว่ามาตรฐานมันตกต่ำลงมาก หรือว่าหนังสือพวกนี้เป็นแค่การตลาด
ผมคิดว่าไม่ว่าจะเป็นมนุษย์หรือระบบอัตโนมัติ ก็ไม่มีการป้องกันใดที่สมบูรณ์แบบ สุดท้ายมันคือชุดของ trade-off ต่อให้ทำ unit test, integration test, static analysis, sequential deployment มากแค่ไหน พอระบบใหญ่ขึ้นก็ย่อมมีช่องโหว่ที่คาดไม่ถึงอยู่ดี นี่เป็นเหตุผลเดียวกับที่หนังสือบอกว่า “การเพิ่ม 9 อีกหนึ่งตัวต้องใช้ความพยายามมากขึ้นมาก” ในกรณีเลวร้ายที่สุดอาจต้องทำสำเนาสต็กทั้งหมดแล้ว replay ทราฟฟิกหลายเดือน ซึ่งไม่มีใครรับต้นทุนต่อประโยชน์ระดับนั้นไหว ตอนทำงานกับ OpenZFS ก็เคยเจอว่าตัวโค้ดดูปกติดี แต่ปัญหากลับโผล่มาจาก data edge case ที่เขียนไว้เมื่อ 10 ปีก่อน เมื่อระบบซับซ้อนพอ การทดสอบทุกความแปรผันย่อมเป็นไปไม่ได้ จึงต้องตัดสินใจบนพื้นฐานของความคุ้มค่าจริง ๆ อนึ่งผมเป็น SRE ของกูเกิล แต่ไม่ได้เกี่ยวกับเหตุการณ์นี้ และนี่เป็นความเห็นส่วนตัว
เหตุขัดข้องระดับโลกของกูเกิลแทบทั้งหมดดำเนินไปในรูปแบบคล้ายกัน คือระบบเฉพาะทางที่ถูกดีพลอยทั่วโลกอย่างรวดเร็วไปรับค่าคอนฟิกผิดพลาด โดยปกติการ rollout ไบนารีหรือการ push คอนฟิกทั่วไปจะใช้ gradual rollout อยู่แล้ว แม้แต่ใน Google Cloud แต่ก่อนก็มีหลายระบบที่ผูกกันแบบ global ทว่าตอนนี้ก็ถูกแยกเป็นรายภูมิภาคมากขึ้นและมีความน่าเชื่อถือสูงขึ้น เมื่อก่อนก็มี global outage อยู่บ่อยแต่ไม่ถูกเปิดเผย ผู้ใช้ส่วนใหญ่จึงคิดว่าเป็นปัญหา ISP ของตัวเอง ผมไม่คิดว่าตอนนี้มันแย่ลงเป็นพิเศษ และผมก็มีประสบการณ์ด้าน SRE เพิ่มเติมด้วย
ถ้ามองจากคนนอก หลังการปรับโครงสร้างครั้งใหญ่และคำพูดเรื่อง ‘ขี้เกียจ’ ของ CEO เป็นต้นมา ทุกอย่างก็ดูจะเน้นความเร็วและผลงานที่มองเห็นมากกว่าคุณภาพ และค่อย ๆ กลายเป็นสภาพแวดล้อมที่ถ้าตั้งคำถามกับวัฒนธรรมแบบนี้กลับถูกกันออกไปเสียเอง
อยากให้เปิดเผยรายละเอียดมากกว่านี้ ส่วนตัวมองว่าไม่ใช่ว่าไม่มีการทดสอบเลยตามที่พูดกัน แต่ไม่มีการทดสอบกรณีฟิลด์ว่างในนโยบาย (อินพุตที่เป็นปัญหา) มากกว่า และคำอธิบายก็ไม่ได้บอกว่าไม่มีการทดสอบใน staging environment เพียงแต่บอกว่าถ้ามี flag ก็น่าจะจับได้ นี่เป็นความเห็นส่วนตัว
ทำให้นึกถึงรายงานคลังดินปืนปี 1864 ที่ว่า “แม้แต่เครื่องมือที่อันตรายที่สุด เมื่อคุ้นเคยแล้ว คนก็จะสูญเสียความระมัดระวัง และเริ่มมองว่ากฎระเบียบเข้มงวดเกินจำเป็น”
ผมอยู่คนละทีมใน Cloud โดยทั่วไปแล้วโค้ดทุกชิ้นจะมีทั้ง unit test และ integration test การเปลี่ยนไบนารีหรือคอนฟิกจะค่อย ๆ ทำเป็นรายงาน รายภูมิภาค ตลอดหลายวัน และมี canary analysis ร่วมด้วย แม้แต่การ rollback ถ้ารีบเกินไปก็อาจทำให้สถานการณ์แย่ลง จึงมักทำอย่างช้า ๆ เช่น มองว่าไฟดับ 40 นาทีดีกว่าความขัดข้อง 4 ชั่วโมงจากการโหลดฐานข้อมูลกลางพร้อมกัน ผมไม่ได้เกี่ยวข้องกับเหตุการณ์นี้โดยตรง แต่จาก PM ดูเหมือนว่าโค้ดถูกทดสอบแล้ว เพียงแต่ edge case นี้ตกหล่นไป ปัญหาคือการตั้งค่านโยบายโควตาถูกใช้ผ่านการอัปเดตฐานข้อมูล ไม่ใช่ไบนารีหรือไฟล์คอนฟิก ทำให้การเปลี่ยนแปลงแพร่ไปยังฐานข้อมูลทั่วโลกภายในไม่กี่วินาที ปัญหา null pointer อาจเกิดขึ้นได้ในภาษาอื่นเช่นกันผ่าน assert() เมื่อเทียบกับความเสี่ยงของการ rewrite บริการหลักแบบนี้ด้วยภาษาอื่น ทางที่สมเหตุสมผลกว่าคือใช้ flag guard กับการตรวจนโยบายทั้งหมด ให้การตรวจนโยบายโควตา fail open และค่อย ๆ กระจายการเปลี่ยนแปลง DB เป็นรายภูมิภาค นี่เป็นความเห็นส่วนตัว
assert เป็นโครงสร้างที่ห้ามใช้งานตามนโยบายได้ง่ายกว่ามาก
ถ้าบอกว่าโค้ดถูกทดสอบแต่ edge case นี้ตกหล่นไป ก็เท่ากับสุดท้ายแล้วมันไม่ได้ถูกทดสอบนั่นเอง
การที่การเปลี่ยน DB ไม่ใช่การเปลี่ยนไบนารีหรือคอนฟิก ไม่ได้ทำให้ปัญหานี้ต่างออกไปเลย ถ้าการเปลี่ยนแปลงแพร่ทั่วโลกพร้อมกัน ไม่ว่าจะเป็นชนิดไหนก็เป็นเมล็ดพันธุ์แห่งหายนะเหมือนกัน เป็นรูปแบบเดียวกับกรณี Crowdstrike เป๊ะ
ถ้าความเห็นคือ “การ rewrite โดยเปลี่ยนภาษาเสี่ยงเกินไป” ก็เลยสงสัยว่าหมายความว่าความต้องการของบริการยังไม่ได้ถูกทำความเข้าใจอย่างถูกต้อง หรือว่าบริการนี้ไม่ได้สำคัญพอที่จะต้องใช้การย้ายระบบอย่างระมัดระวัง
เนื้อหาคือไบนารีแครชเพราะ null pointer โดยไม่มี error handling ที่เหมาะสม ถึงจุดนี้คงพอจะล้อได้ว่าเป็น ‘ความผิดพลาดมูลค่าล้านล้านดอลลาร์’
สงสัยว่าครั้งนี้ทำ SLA ของทั้งปีพังไปกี่รายการ
อดคิดไม่ได้ว่าถ้ามีภาษาที่ช่วยป้องกันปัญหาแบบนี้ได้ก็คงดี /s
Service Control (Chemist) เป็นบริการที่ค่อนข้างเก่าและทำหน้าที่สำคัญอย่างการยืนยันตัวตน สิทธิ์ การเฝ้าระวัง โควตา ฯลฯ ให้กับ GCP API หลายตัว ในเส้นทางของคำขอ GCP API ส่วนใหญ่จะผ่าน Chemist (จึงมองว่ามาตรการ fail open ไม่ค่อยได้ผล) ทั้ง Chemist และ proxy เขียนด้วย C++ และมี legacy code สะสมมาหลายปี แต่ละทีมมี static analysis, การทดสอบ, gradual deployment, feature flag, red button, ระบบ monitoring และ alerting ที่แข็งแรง โดยเฉพาะทีม SRE นั้นยอดเยี่ยม เนื่องจาก Chemist ต้องตรวจสอบนโยบายหลายแบบอย่าง IAM, โควตา ฯลฯ จึงมีหลายทีมเข้ามามีส่วนร่วมใน codebase และเพื่อไม่ต้องผ่านขั้นตอนอนุมัติของ Chemist ทุกครั้ง ก็มีส่วนที่ถูกพัฒนาผ่านทางลัดมากขึ้น ช่วงหลังมีทั้งการปรับโครงสร้างองค์กรและการทำงานแบบ offshore มากขึ้น ทำให้ไปเน้นโปรเจกต์ใหม่หวือหวาที่นำโดยระดับ L8/L9 ขณะที่คุณภาพ การบำรุงรักษา และความน่าเชื่อถือกลับกลายเป็นเรื่องรอง (วัฒนธรรมที่เปลี่ยนไปแบบนี้ทำให้ผมออกจาก Cloud) best practice ของเซิร์ฟเวอร์/บริการทั่วไปของกูเกิลหลายอย่างมักไม่ถูกทำตามที่นี่ ปัญหาครั้งนี้จึงใกล้เคียงกับเรื่องโค้ดและ code review ที่หละหลวมมากกว่า และการอนุมัติโค้ดที่มีข้อบกพร่องพร้อมกับให้ Spanner สะท้อนการเปลี่ยนคอนฟิกทันที ก็ยิ่งทำให้ปัญหาใหญ่ขึ้น
มีฟิลด์ว่างที่ไม่ตั้งใจรวมอยู่ในข้อมูลนโยบายของบริการ และ Service Control ก็อ่านฟิลด์ว่างนั้น (null) ตอนตรวจโควตาในแต่ละรีเจียนจนเกิด exception นี่เป็นอีกตัวอย่างที่ ‘ความผิดพลาดมูลค่าพันล้านดอลลาร์’ ของ Hoare ถูกทำซ้ำในหลายระบบของกูเกิล ปัญหาคือตั้งแต่แรกไม่ควรอนุญาตให้ ‘ฟิลด์ว่าง’ (null) แบบนี้เข้ามาได้ ควรระบุห้าม null (
NOT NULL) ไว้ในสคีมาเลย แต่น่าเสียดายที่ใน Spanner ค่าเริ่มต้นคือ nullable จึงต้องกำหนดเพิ่มเอง อีกโอกาสหนึ่งคือออกแบบในระดับโค้ดแอปด้วย type system หรือภาษา schema ให้สภาวะที่ไม่ถูกต้องเกิดขึ้นไม่ได้ หรือจะเพิ่มการตรวจสอบบังคับตามสคีมาตอน deserialize จาก datastore มาเป็นอ็อบเจ็กต์ของแอปก็ได้ จากที่ประเด็นในบทความเกิดบน code path ใหม่ ก็เลยสงสัยว่ามันไม่ถูกกรองตั้งแต่ชั้นข้อมูลหรือไม่ ตัวโปรแกรม Service Control เองก็เขียนด้วยภาษาที่ยอมให้ dereference null pointer ได้ซึ่งก็เป็นปัญหาอีก ถ้าผมเป็นผู้รับผิดชอบดูแล ผมคงคิดแผนปรับแก้แบบแตะน้อยที่สุดโดยเปลี่ยนนโยบายในโค้ดแอปให้เป็นโครงสร้างอย่าง ‘tagged enum type’ ที่ไม่สามารถแทนค่า null ได้ แม้ proto3 จะไม่มีข้อจำกัดแบบนี้ แต่ก็มีตัวอย่างแบบนี้มักมีการพูดถึง multi-region ว่าเป็นวิธีสร้างความยืดหยุ่นและความพร้อมใช้งาน แต่ในความเป็นจริงก็น่าสนใจที่แม้แต่ผู้ให้บริการคลาวด์รายใหญ่ก็ยังผูกโยงข้ามรีเจียนกันแน่นมากเมื่อเกิดเหตุขัดข้อง
เรื่องนี้เด่นชัดเป็นพิเศษใน GCP เพราะ GCP ปฏิบัติต่อรีเจียนต่างจากผู้ให้บริการรายอื่น ในมุมมองด้านความทนทาน ควรมอง GCP เป็นเหมือนรีเจียนเดียวที่รวมหลายโซนเข้าด้วยกัน
ถึงอย่างนั้น “ความขัดข้องที่เราไม่รู้จัก” ก็ยังอาจมีอยู่ จึงไม่ควรประเมินค่าผลของการทำชาร์ดตามรีเจียน/โซนต่ำเกินไป
ก็มีหลายกรณีที่การดีพลอยแบบ multi-region ช่วยป้องกันอุบัติเหตุได้ ดังนั้นควรดูเคสเหล่านั้นให้ชัดก่อนค่อยสรุป
ผมประหลาดใจกับรายละเอียดใน postmortem ของกูเกิลเสมอ ทั้งจากข้างในและข้างนอก บริษัทเรียนรู้เพื่อไม่ให้ทำผิดซ้ำ และเสริมโปรโตคอลกับ error handling ให้ระบบแข็งแรงขึ้น ในที่ที่ใหญ่ระดับกูเกิลย่อมมีบางอย่างผิดพลาดอยู่ตลอด แต่แก่นสำคัญคือกักผลกระทบไม่ให้ลามไปถึงลูกค้า/ผู้ใช้และระบบอื่น แม้อยู่ข้างในเอง ก็มีปัญหามากมายที่มองไม่เห็นขึ้นอยู่กับแต่ละทีม ผมมองว่านี่คือหนึ่งในระบบที่ซับซ้อนที่สุดที่มนุษย์เคยสร้าง ถ้ายังไม่ใช่ AGI ก็คงยากที่มนุษย์จะทำได้ดีกว่านี้
แต่เหตุขัดข้องครั้งนี้มีความผิดพลาดระดับจูเนียร์ต่อเนื่องหลายอย่าง ทั้งการจัดการข้อมูล null ไม่ได้ การทดสอบไม่พอ ไม่มี test coverage สำหรับฟีเจอร์ใหม่ และไม่ได้ตรวจสอบใน production ขนาดเล็กก่อนปล่อยใช้เต็มรูปแบบ ผมมั่นใจว่าถ้าเป็นกูเกิลเมื่อ 10 ปีก่อน ทุกคนคงหัวเราะกับความผิดพลาดแบบนี้
เท่าที่ผมเข้าใจ สาเหตุของเหตุขัดข้องครั้งนี้คือ 1) ฟีเจอร์ระดับ global ถูกปล่อยทั้งระบบในครั้งเดียว 2) เกิด null pointer dereference 3) ไม่มีนโยบาย retry ที่เหมาะสมจนก่อให้เกิดปัญหา 'thundering herd' ทั้งหมดนี้เป็นความผิดพลาดที่คนในวงการคุ้นเคยดี ไม่ใช่ตรรกะ distributed systems ซับซ้อนอะไรใหม่ แต่เป็น ‘ความผิดพลาดมือใหม่’ แบบคลาสสิกหลายอย่างที่ระเบิดพร้อมกัน
มีคำพูดว่า “เราจะไม่ทำผิดซ้ำแบบเดิมอีก” แต่ในความเป็นจริงก็ rollout การเปลี่ยนแปลงโดยไม่มี feature flag และฝั่ง client ก็ไม่มี exponential backoff ส่วนฝั่งเซิร์ฟเวอร์ก็ไม่มี load shedding ทั้งหมดนี้อยู่ใน google SRE book มาหลายปีแล้ว
ข้อผิดพลาดนี้เป็นปัญหา null pointer ที่ไม่ถูกจับไว้ บริษัทที่มีขนาดและมาตรฐานคุณภาพระดับกูเกิลกลับทำให้สแต็กส่วนใหญ่ล่มได้แบบนี้ อาจถูกมองว่าเป็นสัญญาณว่ามาตรการป้องกันการเกิดซ้ำของประเด็นร้ายแรงยังไม่เพียงพอ
นี่คือความผิดพลาดแบบเดิมที่เกิดซ้ำมานับครั้งไม่ถ้วน ประโยคที่สรุป global outage ส่วนใหญ่ได้ดีที่สุดคือ “เราดีพลอยฟีเจอร์ใหม่อย่างระมัดระวัง แต่บั๊กจะโผล่ก็ต่อเมื่อมีข้อมูลรูปแบบใหม่เข้ามาเท่านั้น” ไม่มีระบบไหนสมบูรณ์แบบ และในทุกการถกเถียงเรื่อง outage ของ FAANG สิ่งเดียวที่ไร้ที่ติคือ ‘ผู้เชี่ยวชาญหน้าคีย์บอร์ดบน HN’
ส่วนใหญ่เวลาเห็น downtime ของคนอื่น เรามักรีบวิจารณ์ว่าเป็น ‘ความผิดพลาดระดับจูเนียร์’ แต่พอเป็นงานตัวเองกลับเหลือคำอธิบายว่าเลี่ยงไม่ได้หรือคาดไม่ถึง ความผิดพลาดของมนุษย์เป็นสิ่งหลีกเลี่ยงไม่ได้ และความคาดหวังก็สูงเกินไปอยู่แล้ว ต่อให้ร้านค้าออฟไลน์ปิดกะทันหันก็จบลงที่คำว่า “ขออภัย” เท่านั้น มีแค่วงการไอทีที่เครียดกับเหตุขัดข้องไม่กี่ชั่วโมงเกินไป และอยากให้ทุกคนผ่อนคลายกันมากกว่านี้