เหตุการณ์ระบบล่มของ Salesforce ในปี 2025: บทสรุปการหยุดชะงักครั้งใหญ่

ข้อสรุปที่สำคัญที่สุดจากบันทึกเหตุการณ์ระบบล่มของ Salesforce ในปี 2025 คือ ไม่มีเหตุการณ์ระบบล่มทั่วโลกของ Salesforce ครั้งเดียวที่กำหนดทั้งปี แต่ลูกค้าประสบกับรูปแบบการหยุดชะงักที่แตกต่างกันหลายแบบ เช่น การหยุดชะงักของบริการในวงกว้างในเดือนกุมภาพันธ์ ความล้มเหลวในการตรวจสอบสิทธิ์ในระบบคลาวด์หลายแห่งในเดือนมิถุนายน เหตุการณ์สำคัญบนแพลตฟอร์ม Heroku ที่เกิดจากการอัปเดตของผู้จำหน่ายโดยไม่ตั้งใจ เหตุการณ์เครือข่ายศูนย์ข้อมูลในอินเดียนาโพลิส และเหตุการณ์ในภายหลังที่จำกัดเฉพาะบางอินสแตนซ์หรือฟีเจอร์ ความแตกต่างนี้มีความสำคัญ เพราะการตอบสนองที่ถูกต้องขึ้นอยู่กับว่าอะไรล้มเหลว

หากผู้ใช้ไม่สามารถเข้าสู่ระบบได้ การรีเฟรชเบราว์เซอร์จะไม่ช่วยแก้ปัญหา หากหน้าสถานะสาธารณะแสดงผลช้า ระบบตรวจสอบการหยุดชะงักทั่วไปอาจแสดงผลไม่สมบูรณ์เช่นกัน หาก Salesforce ใช้งานได้ แต่คิวการผสานรวมติดขัด ระบบ CRM เองอาจดูเหมือนทำงานได้ปกติ ในขณะที่กระบวนการทางธุรกิจยังคงล้มเหลว บทเรียนที่ได้จากปี 2025 คือ การผสมผสานการแจ้งเตือนสถานะเฉพาะผู้เช่า การตรวจสอบอิสระ ขั้นตอนการทำงานด้วยตนเองที่ผ่านการทดสอบ และการตรวจสอบการกู้คืนสำหรับระบบปลายทาง

การเปลี่ยนแปลงครั้งใหญ่ที่จะส่งผลกระทบต่อ Salesforce ในปี 2025 มีอะไรบ้าง?

เหตุการณ์ต่อไปนี้มีประโยชน์สำหรับการทบทวนย้อนหลัง เนื่องจากแสดงให้เห็นถึงรูปแบบความล้มเหลวที่แตกต่างกัน อย่างไรก็ตาม เหตุการณ์เหล่านี้ไม่ได้หมายความว่าเหตุการณ์สถานะของ Salesforce ทั้งหมดในปี 2025 ได้ถูกระบุไว้ในที่นี้แล้ว

สำหรับเหตุการณ์ในเดือนกุมภาพันธ์และเหตุการณ์ Salesforce Trust นั้น วันที่ ขอบเขต และการอัปเดตการกู้คืนมาจากบันทึกเหตุการณ์ของ Salesforce ได้แก่การหยุดชะงักของบริการเมื่อวันที่ 7 กุมภาพันธ์เหตุการณ์การตรวจสอบสิทธิ์ข้ามคลาวด์เมื่อวันที่ 10 มิถุนายนเหตุการณ์ในอินเดียนาโพลิสเมื่อวันที่ 18 มิถุนายน เหตุการณ์เกี่ยว กับ อินสแตน ซ์เมื่อวันที่ 1 พฤศจิกายนและเหตุการณ์ WhatsApp เมื่อวันที่ 31ธันวาคม

เหตุการณ์เมื่อวันที่ 10 มิถุนายน เผยให้เห็นความล้มเหลวสองระดับที่แตกต่างกัน

วันที่ 10 มิถุนายนมีความสำคัญเป็นพิเศษ เพราะ “การหยุดชะงักของ Salesforce” สามารถหมายถึงเหตุการณ์มากกว่าหนึ่งอย่างได้ รายงานความน่าเชื่อถือของ Salesforce ระบุว่าเกิดความล้มเหลวในการตรวจสอบสิทธิ์แบบหลายปัจจัยซึ่งส่งผลกระทบต่อระบบคลาวด์หลายแห่ง ส่วนรายงานการแก้ไขปัญหาในภายหลังของ Heroku ระบุว่าเกิดการหยุดชะงักของบริการแพลตฟอร์มซึ่งเริ่มต้นเวลา 06:00 UTC และเกิดจากการอัปเดตระบบโดยไม่ตั้งใจซึ่งผู้จำหน่ายได้นำไปใช้กับโครงสร้างพื้นฐานการผลิต

Heroku ยอมรับว่าเว็บไซต์แสดงสถานะของตนได้รับผลกระทบเช่นกัน จากการอัปเดตการแก้ไขปัญหาของ Heroku พบ ว่า ข้อบกพร่องในการออกแบบหน้าแสดงสถานะและความหน่วงของ API ทำให้เกิดการหมดเวลา และหน้าดังกล่าวอาจแสดงว่าไม่มีเหตุการณ์ใด ๆ เกิดขึ้น Heroku กล่าวว่าได้ตอบสนองด้วยมาตรการควบคุมต่างๆ รวมถึงการหยุดการอัปเกรดระบบปฏิบัติการของผู้จำหน่ายโดยอัตโนมัติอย่างถาวร การตรวจสอบภาพ การตรวจสอบเพิ่มเติม เนื้อหาสถานะที่แคชไว้ การวางแผนการสื่อสารที่เป็นอิสระ และขั้นตอนการตอบสนองต่อเหตุการณ์ที่เข้มงวดมากขึ้น

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

สถิติปี 2025 สอนอะไรแก่ลูกค้าของ Salesforce บ้าง?

1. การตรวจสอบสิทธิ์จำเป็นต้องมีแผนความต่อเนื่องของตนเอง

ทีมงานอาจมีข้อมูลแอปพลิเคชันที่ใช้งานได้ปกติ แต่ก็ยังไม่สามารถทำงานได้หากการเข้าสู่ระบบ การตรวจสอบสิทธิ์แบบหลายปัจจัย หรือเส้นทางการเชื่อมต่อข้อมูลประจำตัวล้มเหลว เรื่องนี้มีความสำคัญอย่างยิ่งสำหรับธุรกิจที่ใช้ Salesforce, Heroku, Commerce และ Marketing Cloud ร่วมกัน ควรบันทึกว่าผู้ใช้รายใดจำเป็นต้องเข้าถึงระบบใดบ้าง ระบุผู้ติดต่อฉุกเฉินที่สามารถรับข้อมูลอัปเดตจากผู้จำหน่าย และกำหนดว่างานใดบ้างที่สามารถดำเนินการต่อได้แม้จะเข้าสู่ระบบไม่สำเร็จ

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

2. หน้าแสดงสถานะทั่วไปไม่เพียงพอ

เอกสารของ Salesforce เองอธิบายว่าสถานะความน่าเชื่อถือ (Trust Status)ให้ข้อมูลเกี่ยวกับความพร้อมใช้งานและประสิทธิภาพ ในขณะที่ มุมมอง My Trust Center รุ่นใหม่กว่า ได้รับการออกแบบโดยคำนึงถึงผู้เช่าและผลิตภัณฑ์ที่รองรับ ประเด็นสำคัญในการใช้งานนั้นง่ายมาก: คุณต้องทราบตัวระบุอินสแตนซ์หรือผู้เช่าของคุณก่อนที่จะเกิดเหตุการณ์ขึ้น

Salesforce ยังมีคำแนะนำสำหรับการสมัครรับข้อความและการแจ้งเตือนจาก My Trust Centerด้วย ตั้งค่าการแจ้งเตือนสำหรับบุคคลที่ต้องดำเนินการ ไม่ใช่เฉพาะผู้ดูแลระบบที่สร้างองค์กรขึ้นมาในตอนแรกเท่านั้น รักษาช่องทางการสื่อสารที่เป็นอิสระ เช่น หน้าสถานะภายใน หรือกลุ่มข้อความที่ได้รับอนุมัติ เพื่อให้บริษัทของคุณสามารถสื่อสารได้แม้ว่าเว็บไซต์สถานะของผู้ขายจะทำงานช้าหรือไม่สามารถใช้งานได้ก็ตาม

3. การกู้คืนระบบนั้นมีความหมายมากกว่าแค่การเห็นหน้าจอเข้าสู่ระบบ

เมื่อ Salesforce รายงานว่าบริการกลับมาใช้งานได้ตามปกติแล้ว เหตุการณ์ดังกล่าวอาจยังคงส่งผลกระทบต่อธุรกิจอยู่ การร้องขอ API ที่ล่าช้าอาจถูกลองใหม่สองครั้ง ข้อความที่อยู่ในคิวอาจมาถึงล่าช้า หรือการปรับใช้ที่ล้มเหลวอาจทำให้ข้อมูลไม่ตรงกัน หลังจากกู้คืนแล้ว ให้ตรวจสอบเวิร์กโฟลว์ที่สำคัญที่สุด ได้แก่ การตรวจสอบสิทธิ์ การเรียกใช้ API งานที่กำหนดเวลาไว้ คิวการผสานรวม การส่งอีเมลหรือข้อความ การสร้างบันทึก และความทันสมัยของรายงาน

ตัวอย่างเช่น ลองนึกภาพทีมสนับสนุนขนาดกลางที่มีเจ้าหน้าที่ใช้เคสใน Salesforce ในขณะที่ระบบอีคอมเมิร์ซอีกระบบส่งข้อมูลอัปเดตผ่านการเชื่อมต่อ หาก Salesforce กลับมาใช้งานได้ในเวลา 10:00 น. แต่คิวการเชื่อมต่อมีข้อความที่ล้มเหลวจากช่วงเวลาที่ระบบขัดข้อง ทีมไม่ควรปิดเหตุการณ์เพียงเพราะเบราว์เซอร์โหลดได้แล้ว การทดสอบที่ถูกต้องคือการตรวจสอบว่าข้อมูลอัปเดตเคสใหม่และเคสที่ล้มเหลวก่อนหน้านี้ดำเนินการผ่านเวิร์กโฟลว์ทั้งหมดโดยไม่ซ้ำซ้อนหรือไม่

มาตรการรักษาความต่อเนื่องใดบ้างที่เหมาะสมกับองค์กรของคุณ?

วิธีนำบทสรุปนี้ไปใช้ประโยชน์ในปี 2026 และปีต่อๆ ไป

เริ่มต้นด้วยแผนผังความสัมพันธ์แบบหน้าเดียว เขียนรายละเอียดเกี่ยวกับอินสแตนซ์หรือเทนเนนต์ของ Salesforce ผู้ให้บริการข้อมูลประจำตัว ระบบคลาวด์ที่เชื่อมต่อ การผสานรวมที่สำคัญ การสมัครรับสถานะ และกระบวนการด้วยตนเองที่ใช้ระหว่างที่ระบบล่ม จากนั้นกำหนดการตรวจสอบการกู้คืนที่เป็นรูปธรรมสำหรับเวิร์กโฟลว์ที่สำคัญแต่ละรายการ “Salesforce กลับมาใช้งานได้แล้ว” นั้นกว้างเกินไป “เคสใหม่ ข้อความขาออก และการอัปเดตคำสั่งซื้อกำลังดำเนินการโดยไม่มีรายการซ้ำ” นั้นสามารถทดสอบได้

สุดท้ายนี้ ให้ตรวจสอบการเปลี่ยนแปลงที่อาจส่งผลต่อความพร้อมใช้งาน เช่น การอัปเดตจากผู้ให้บริการ การเปลี่ยนแปลงระบบปฏิบัติการ การออกเวอร์ชันใหม่ การเปลี่ยนแปลงการกำหนดค่า และการย้ายอินสแตนซ์ เหตุการณ์ Heroku ในเดือนมิถุนายนแสดงให้เห็นว่าเหตุใดการเปลี่ยนแปลงที่เกิดขึ้นโดยไม่ได้รับการดูแลจึงต้องมีการควบคุมที่เข้มงวด และเหตุใดการสื่อสารสถานะจึงต้องการความยืดหยุ่นเช่นกัน เหตุการณ์เมื่อวันที่ 18 มิถุนายนแสดงให้เห็นว่าเหตุใดความจุทางกายภาพและการพึ่งพาศูนย์ข้อมูลจึงยังคงมีความสำคัญในบริการคลาวด์ การลดประสิทธิภาพของฟีเจอร์ในเดือนธันวาคมแสดงให้เห็นว่าเหตุใดทีมจึงควรตรวจสอบฟังก์ชันที่พวกเขาใช้งานจริง ไม่ใช่แค่ความพร้อมใช้งานระดับสูงสุดของแพลตฟอร์มเท่านั้น

ดังนั้น การตอบสนองที่เหมาะสมที่สุดจึงขึ้นอยู่กับเงื่อนไข องค์กรขนาดเล็กอาจต้องการการแจ้งเตือนและรายการตรวจสอบด้วยตนเองที่ชัดเจน ธุรกิจที่ไม่สามารถหยุดการขายหรือการสนับสนุนได้นั้นต้องการการตรวจสอบอิสระ การกู้คืนที่คำนึงถึงคิว และกระบวนการหยุดทำงานที่ได้รับการฝึกฝนมาอย่างดี องค์กรที่มีกฎระเบียบเข้มงวดต้องการการกู้คืนที่ผ่านการทดสอบ หลักฐาน และการกำกับดูแล บันทึกการหยุดทำงานของ Salesforce ในปี 2025 สนับสนุนข้อสรุปที่สอดคล้องกันข้อหนึ่งคือ ความยืดหยุ่นนั้นสร้างขึ้นจากห่วงโซ่การพึ่งพาของลูกค้า ไม่ใช่จากตัวบ่งชี้สถานะสีเขียวเพียงอย่างเดียว

แหล่งที่มาและขอบเขต

บทวิเคราะห์ย้อนหลังนี้ใช้บันทึกเหตุการณ์ความไว้วางใจของ Salesforce และเอกสารของ Salesforce หรือ Heroku ที่มีอยู่ ณ เวลาที่เขียนบทความนี้ หน้าเว็บเกี่ยวกับเหตุการณ์อาจได้รับการอัปเดตหลังจากแก้ไขปัญหาแล้ว และความครอบคลุมของผลิตภัณฑ์ Salesforce จะแตกต่างกันระหว่างสถานะความไว้วางใจและศูนย์ความไว้วางใจของฉัน ในกรณีที่ Salesforce ไม่ได้เผยแพร่การวิเคราะห์สาเหตุที่แท้จริงโดยละเอียด บทความนี้จะไม่อนุมานถึงการวิเคราะห์ดังกล่าว