คุณจะรู้สึกอย่างไรหากวันหนึ่งในฤดูร้อนศูนย์ข้อมูลพร้อมอุปกรณ์ของคุณมีลักษณะเช่นนี้
สวัสดีทุกคน! ฉันชื่อ Dmitry Samsonov ฉันทำงานเป็นผู้ดูแลระบบชั้นนำที่ "" ภาพถ่ายแสดงหนึ่งในสี่ศูนย์ข้อมูลที่ติดตั้งอุปกรณ์ที่ให้บริการโครงการของเรา ด้านหลังกำแพงมีอุปกรณ์ประมาณ 4 ชิ้น: เซิร์ฟเวอร์ ระบบจัดเก็บข้อมูล อุปกรณ์เครือข่าย ฯลฯ - เกือบ ⅓ ของอุปกรณ์ทั้งหมดของเรา
เซิร์ฟเวอร์ส่วนใหญ่เป็น Linux นอกจากนี้ยังมีเซิร์ฟเวอร์หลายสิบเครื่องบน Windows (MS SQL) ซึ่งเป็นมรดกของเราซึ่งเราละทิ้งอย่างเป็นระบบมาหลายปีแล้ว
ดังนั้นในวันที่ 5 มิถุนายน 2019 เวลา 14:35 น. วิศวกรที่ศูนย์ข้อมูลแห่งหนึ่งของเราจึงได้รายงานสัญญาณเตือนไฟไหม้
การปฏิเสธ
14:45. เหตุการณ์ควันเล็กน้อยในศูนย์ข้อมูลเป็นเรื่องปกติมากกว่าที่คุณคิด ตัวบ่งชี้ภายในห้องโถงเป็นเรื่องปกติ ดังนั้นปฏิกิริยาแรกของเราจึงค่อนข้างสงบ: พวกเขาแนะนำการห้ามการทำงานกับการผลิต นั่นคือ การเปลี่ยนแปลงการกำหนดค่าใด ๆ การเปิดตัวเวอร์ชันใหม่ ฯลฯ ยกเว้นงานที่เกี่ยวข้องกับการแก้ไขบางสิ่งบางอย่าง
ความโกรธ
คุณเคยพยายามค้นหาตำแหน่งที่แน่นอนจากนักผจญเพลิงไหมว่าไฟเกิดขึ้นบนหลังคาที่ไหน หรือลองขึ้นไปบนหลังคาที่กำลังลุกไหม้ด้วยตัวเองเพื่อประเมินสถานการณ์หรือไม่? ระดับความเชื่อมั่นในข้อมูลที่ได้รับผ่านคนห้าคนจะเป็นอย่างไร?
14: 50 ได้รับข้อมูลว่าเพลิงไหม้กำลังเข้าใกล้ระบบทำความเย็น. แต่จะมามั้ย? ผู้ดูแลระบบที่ปฏิบัติหน้าที่จะลบการรับส่งข้อมูลภายนอกออกจากด้านหน้าของศูนย์ข้อมูลนี้
ในขณะนี้ ส่วนหน้าของบริการทั้งหมดของเราซ้ำกันในศูนย์ข้อมูล XNUMX แห่ง โดยมีการใช้การปรับสมดุลที่ระดับ DNS ซึ่งช่วยให้เราสามารถลบที่อยู่ของศูนย์ข้อมูลแห่งเดียวออกจาก DNS ได้ จึงช่วยปกป้องผู้ใช้จากปัญหาที่อาจเกิดขึ้นกับการเข้าถึงบริการ . หากเกิดปัญหาในศูนย์ข้อมูลแล้ว ระบบจะปล่อยให้หมุนเวียนโดยอัตโนมัติ คุณสามารถอ่านเพิ่มเติมได้ที่นี่:
เพลิงไหม้ยังไม่ส่งผลกระทบต่อเราแต่อย่างใด ทั้งผู้ใช้และอุปกรณ์ไม่ได้รับความเสียหาย นี่เป็นอุบัติเหตุใช่ไหม? ส่วนแรกของเอกสาร “แผนปฏิบัติการอุบัติเหตุ” กำหนดแนวคิดของ “อุบัติเหตุ” และส่วนจะสิ้นสุดดังนี้:
«หากมีข้อสงสัยว่ามีอุบัติเหตุหรือไม่ ก็คืออุบัติเหตุ!»
14:53. มีการแต่งตั้งผู้ประสานงานเหตุฉุกเฉิน
ผู้ประสานงานคือบุคคลที่ควบคุมการสื่อสารระหว่างผู้เข้าร่วมทั้งหมด ประเมินขนาดของอุบัติเหตุ ใช้แผนปฏิบัติการฉุกเฉิน ดึงดูดบุคลากรที่จำเป็น ติดตามความสมบูรณ์ของการซ่อมแซม และที่สำคัญที่สุดคือมอบหมายงานใด ๆ กล่าวอีกนัยหนึ่ง นี่คือบุคคลที่จัดการกระบวนการตอบสนองเหตุฉุกเฉินทั้งหมด
ประมูล
15:01. เราเริ่มปิดการใช้งานเซิร์ฟเวอร์ที่ไม่เกี่ยวข้องกับการใช้งานจริง
15:03. เราปิดบริการที่สงวนไว้ทั้งหมดอย่างถูกต้อง
ซึ่งไม่เพียงแต่รวมถึงส่วนหน้า (ซึ่ง ณ จุดนี้ผู้ใช้ไม่สามารถเข้าถึงได้อีกต่อไป) และบริการเสริม (ตรรกะทางธุรกิจ แคช ฯลฯ) แต่ยังรวมถึงฐานข้อมูลต่างๆ ที่มีปัจจัยการจำลองแบบ 2 ขึ้นไป (, , , ฯลฯ)
15: 06 ได้รับข้อมูลว่าเกิดเพลิงไหม้คุกคามห้องโถงศูนย์ข้อมูลแห่งหนึ่ง เราไม่มีอุปกรณ์ในห้องนี้ แต่ความจริงที่ว่าไฟสามารถลามจากหลังคาไปยังห้องโถงได้ทำให้ภาพของสิ่งที่เกิดขึ้นเปลี่ยนไปอย่างมาก
(ต่อมาปรากฏว่าไม่มีภัยคุกคามทางกายภาพต่อห้องโถง เนื่องจากมันถูกปิดผนึกอย่างแน่นหนาจากหลังคา ภัยคุกคามมีเฉพาะกับระบบทำความเย็นของห้องโถงนี้เท่านั้น)
15:07. เราอนุญาตให้ดำเนินการคำสั่งบนเซิร์ฟเวอร์ในโหมดเร่งความเร็วโดยไม่ต้องตรวจสอบเพิ่มเติม ().
15:08. อุณหภูมิในห้องโถงอยู่ในเกณฑ์ปกติ
15: 12 มีการบันทึกการเพิ่มขึ้นของอุณหภูมิในห้องโถง
15:13. เซิร์ฟเวอร์มากกว่าครึ่งหนึ่งในศูนย์ข้อมูลถูกปิด มาต่อกัน
15:16. มีการตัดสินใจปิดอุปกรณ์ทั้งหมด
15:21. เราเริ่มปิดเครื่องเซิร์ฟเวอร์ไร้สัญชาติโดยไม่ต้องปิดแอปพลิเคชันและระบบปฏิบัติการอย่างถูกต้อง
15:23. มีการจัดสรรกลุ่มคนที่รับผิดชอบ MS SQL (มีเพียงไม่กี่คนการพึ่งพาบริการนั้นไม่ดีนัก แต่ขั้นตอนในการกู้คืนฟังก์ชันการทำงานใช้เวลานานกว่าและซับซ้อนกว่าเช่น Cassandra)
พายุดีเปรสชัน
15: 25 ได้รับข้อมูลการปิดไฟฟ้า 16 ห้องโถงจาก 6 ห้อง (หมายเลข 7, 8, 9, XNUMX) อุปกรณ์ของเราตั้งอยู่ในห้องโถง 7 และ 8 ไม่มีข้อมูลเกี่ยวกับห้องโถงทั้งสองของเรา (หมายเลข 1 และ 3)
โดยปกติในช่วงเกิดเพลิงไหม้ แหล่งจ่ายไฟจะถูกปิดทันที แต่ในกรณีนี้ เนื่องจากการประสานงานของนักดับเพลิงและบุคลากรด้านเทคนิคของศูนย์ข้อมูล จึงไม่ปิดทุกที่และไม่ได้ปิดทันที แต่ตามความจำเป็น
(ทราบภายหลังว่าไม่ได้ปิดไฟฟ้าในห้องโถง 8 และ 9)
15:28. เรากำลังเริ่มปรับใช้ฐานข้อมูล MS SQL จากการสำรองข้อมูลในศูนย์ข้อมูลอื่นๆ
มันจะใช้เวลานานเท่าไหร่? มีความจุเครือข่ายเพียงพอสำหรับทั้งเส้นทางหรือไม่
15: 37 มีการบันทึกการปิดระบบเครือข่ายบางส่วน
การจัดการและเครือข่ายการผลิตแยกจากกันทางกายภาพ หากเครือข่ายการผลิตพร้อมใช้งาน คุณสามารถไปที่เซิร์ฟเวอร์ หยุดแอปพลิเคชัน และปิดระบบปฏิบัติการได้ หากไม่มีให้ใช้งาน คุณสามารถเข้าสู่ระบบผ่าน IPMI หยุดแอปพลิเคชันและปิดระบบปฏิบัติการได้ หากไม่มีเครือข่ายใดเลย คุณจะไม่สามารถทำอะไรได้เลย “ขอบคุณแคป!” คุณจะคิด
“และโดยทั่วไปแล้ว มีความวุ่นวายมากมาย” คุณอาจคิดเช่นกัน
ประเด็นก็คือเซิร์ฟเวอร์แม้จะไม่มีไฟ แต่ก็สร้างความร้อนจำนวนมหาศาลได้ แม่นยำยิ่งขึ้น เมื่อมีการทำความเย็น พวกมันจะสร้างความร้อน และเมื่อไม่มีการระบายความร้อน พวกมันจะสร้างนรกนรก ซึ่งอย่างดีที่สุดจะทำให้ส่วนหนึ่งของอุปกรณ์ละลายและปิดอีกส่วนหนึ่ง และที่เลวร้ายที่สุด... ทำให้เกิด ไฟในห้องโถงซึ่งเกือบจะรับประกันว่าจะทำลายทุกสิ่ง
15:39. เราแก้ไขปัญหาเกี่ยวกับฐานข้อมูล conf
ฐานข้อมูล conf เป็นแบ็กเอนด์สำหรับบริการที่มีชื่อเดียวกัน ซึ่งแอปพลิเคชันที่ใช้งานจริงทั้งหมดใช้เพื่อเปลี่ยนการตั้งค่าอย่างรวดเร็ว หากไม่มีฐานนี้ เราไม่สามารถควบคุมการทำงานของพอร์ทัลได้ แต่ตัวพอร์ทัลเองก็สามารถทำงานได้
15:41. เซ็นเซอร์อุณหภูมิบนอุปกรณ์เครือข่ายหลักจะบันทึกค่าที่อ่านได้ใกล้เคียงกับค่าสูงสุดที่อนุญาต นี่คือกล่องที่ใช้พื้นที่ทั้งหมดแร็คและรับรองการทำงานของเครือข่ายทั้งหมดภายในศูนย์ข้อมูล
15:42. ตัวติดตามปัญหาและวิกิไม่พร้อมใช้งาน สลับไปที่โหมดสแตนด์บาย
นี่ไม่ใช่การผลิต แต่ในกรณีที่เกิดอุบัติเหตุ ความพร้อมของฐานความรู้ใดๆ อาจเป็นสิ่งสำคัญ
15:50. ระบบตรวจสอบระบบใดระบบหนึ่งปิดอยู่
มีหลายอย่างและมีหน้าที่รับผิดชอบในด้านต่างๆ ของบริการ บางส่วนได้รับการกำหนดค่าให้ทำงานอัตโนมัติภายในศูนย์ข้อมูลแต่ละแห่ง (นั่นคือ จะตรวจสอบเฉพาะศูนย์ข้อมูลของตนเอง) ส่วนอื่นๆ ประกอบด้วยส่วนประกอบแบบกระจายที่สามารถรอดพ้นจากการสูญเสียศูนย์ข้อมูลใดๆ ได้อย่างโปร่งใส
ในกรณีนี้มันหยุดทำงาน ซึ่งทำงานในโหมดสแตนด์บายหลัก เปลี่ยนเป็นสแตนด์บายแล้ว
การนำมาใช้
15:51. เซิร์ฟเวอร์ทั้งหมดยกเว้น MS SQL ถูกปิดผ่าน IPMI โดยไม่ได้ปิดอย่างถูกต้อง
คุณพร้อมสำหรับการจัดการเซิร์ฟเวอร์ขนาดใหญ่ผ่าน IPMI หากจำเป็นหรือไม่?
ช่วงเวลาที่การช่วยเหลืออุปกรณ์ในศูนย์ข้อมูลเสร็จสิ้นในขั้นตอนนี้ ทุกสิ่งที่สามารถทำได้ก็ทำไปแล้ว เพื่อนร่วมงานบางคนสามารถพักผ่อนได้
16: 13 ได้รับข้อมูลว่าท่อฟรีออนจากเครื่องปรับอากาศแตกบนหลังคา - ซึ่งจะทำให้การเปิดตัวศูนย์ข้อมูลล่าช้าหลังจากไฟดับแล้ว
16:19. จากข้อมูลที่ได้รับจากเจ้าหน้าที่เทคนิคของศูนย์ข้อมูล อุณหภูมิที่เพิ่มขึ้นในห้องโถงได้หยุดลงแล้ว
17:10. ฐานข้อมูล conf ได้รับการกู้คืนแล้ว ตอนนี้เราสามารถเปลี่ยนการตั้งค่าแอปพลิเคชันได้แล้ว
เหตุใดสิ่งนี้จึงสำคัญมากหากทุกอย่างทนทานต่อข้อผิดพลาดและทำงานได้แม้ไม่มีศูนย์ข้อมูลเพียงแห่งเดียว
ประการแรก ไม่ใช่ทุกสิ่งที่จะทนทานต่อข้อผิดพลาด มีบริการรองต่างๆ ที่ยังไม่รอดจากความล้มเหลวของศูนย์ข้อมูลได้ดีพอ และมีฐานข้อมูลในโหมดมาสเตอร์-สแตนด์บาย ความสามารถในการจัดการการตั้งค่าช่วยให้คุณสามารถทำทุกอย่างที่จำเป็นเพื่อลดผลกระทบจากอุบัติเหตุที่มีต่อผู้ใช้แม้ในสภาวะที่ยากลำบาก
ประการที่สอง เห็นได้ชัดว่าการทำงานของศูนย์ข้อมูลจะไม่ได้รับการกู้คืนอย่างสมบูรณ์ในอีกไม่กี่ชั่วโมงข้างหน้า ดังนั้นจึงจำเป็นต้องดำเนินมาตรการเพื่อให้แน่ใจว่าการไม่พร้อมใช้งานของแบบจำลองในระยะยาวจะไม่นำไปสู่ปัญหาเพิ่มเติม เช่น ดิสก์เต็มใน ศูนย์ข้อมูลที่เหลือ
17:29. เวลาพิซซ่า! เราจ้างคน ไม่ใช่หุ่นยนต์
การพักฟื้น
18:02. ในห้องโถงหมายเลข 8 (ของเรา) 9, 10 และ 11 อุณหภูมิคงที่แล้ว หนึ่งในอุปกรณ์ที่ยังคงออฟไลน์ (หมายเลข 7) เป็นที่เก็บอุปกรณ์ของเรา และอุณหภูมิที่นั่นยังคงสูงขึ้นอย่างต่อเนื่อง
18:31. พวกเขาได้ดำเนินการสตาร์ทอุปกรณ์ในห้องโถงหมายเลข 1 และ 3 โดยห้องโถงเหล่านี้ไม่ได้รับผลกระทบจากเพลิงไหม้
ขณะนี้เซิร์ฟเวอร์กำลังเปิดตัวในห้องโถงหมายเลข 1, 3, 8 โดยเริ่มจากเซิร์ฟเวอร์ที่สำคัญที่สุด มีการตรวจสอบการทำงานที่ถูกต้องของบริการที่ทำงานอยู่ทั้งหมด ยังคงมีปัญหากับห้องโถงหมายเลข 7
18:44. เจ้าหน้าที่ด้านเทคนิคของศูนย์ข้อมูลพบว่าในห้องหมายเลข 7 (ซึ่งมีเฉพาะอุปกรณ์ของเราเท่านั้น) เซิร์ฟเวอร์จำนวนมากไม่ได้ปิดอยู่ จากข้อมูลของเรา เซิร์ฟเวอร์ 26 เครื่องยังคงออนไลน์อยู่ที่นั่น หลังจากตรวจสอบครั้งที่สอง เราพบเซิร์ฟเวอร์ 58 เครื่อง
20:18. ช่างเทคนิคของศูนย์ข้อมูลเป่าลมผ่านห้องที่ไม่มีเครื่องปรับอากาศผ่านท่อเคลื่อนที่ที่วิ่งผ่านโถงทางเดิน
23:08. ผู้ดูแลระบบคนแรกถูกส่งกลับบ้าน มีคนต้องนอนตอนกลางคืนเพื่อที่จะทำงานต่อในวันพรุ่งนี้ ต่อไป เราจะเปิดตัวผู้ดูแลระบบและนักพัฒนาเพิ่มเติม
02:56. เราเปิดตัวทุกสิ่งที่สามารถเปิดตัวได้ เราทำการตรวจสอบบริการทั้งหมดหลายครั้งโดยใช้การทดสอบอัตโนมัติ
03:02. ปรับปรุงเครื่องปรับอากาศในห้องโถงที่ 7 สุดท้ายแล้ว
03:36. เรานำส่วนหน้าในศูนย์ข้อมูลมาหมุนเวียนใน DNS จากช่วงเวลานี้ปริมาณการใช้งานของผู้ใช้เริ่มมาถึง
เรากำลังส่งทีมผู้บริหารส่วนใหญ่กลับบ้าน แต่เราทิ้งคนไว้ข้างหลังไม่กี่คน
คำถามที่พบบ่อยเล็กน้อย:
ถาม: เกิดอะไรขึ้นระหว่างเวลา 18:31 น. ถึง 02:56 น.
ตอบ: ตาม "แผนปฏิบัติการภัยพิบัติ" เราเปิดตัวบริการทั้งหมด โดยเริ่มจากบริการที่สำคัญที่สุด ในกรณีนี้ ผู้ประสานงานในการแชทจะให้บริการแก่ผู้ดูแลระบบฟรี ซึ่งจะตรวจสอบว่าระบบปฏิบัติการและแอปพลิเคชันเริ่มทำงานหรือไม่ มีข้อผิดพลาดใดๆ หรือไม่ และตัวบ่งชี้เป็นเรื่องปกติหรือไม่ หลังจากการเปิดตัวเสร็จสิ้น เขาจะรายงานในแชทว่าเขาว่างและได้รับบริการใหม่จากผู้ประสานงาน
กระบวนการนี้ช้าลงอีกเนื่องจากฮาร์ดแวร์ที่ล้มเหลว แม้ว่าการหยุดระบบปฏิบัติการและการปิดเซิร์ฟเวอร์จะดำเนินการอย่างถูกต้อง แต่เซิร์ฟเวอร์บางตัวจะไม่ส่งคืนเนื่องจากความล้มเหลวของดิสก์ หน่วยความจำ และแชสซีอย่างกะทันหัน เมื่อสูญเสียพลังงาน อัตราความล้มเหลวจะเพิ่มขึ้น
ถาม: ทำไมคุณไม่สามารถรันทุกอย่างพร้อมกัน แล้วแก้ไขสิ่งที่เกิดขึ้นในการตรวจสอบได้
ตอบ: ทุกอย่างจะต้องค่อยๆ ทำ เนื่องจากมีการขึ้นต่อกันระหว่างบริการต่างๆ และควรตรวจสอบทุกอย่างทันทีโดยไม่ต้องรอการตรวจสอบ - เพราะเป็นการดีกว่าที่จะจัดการกับปัญหาทันทีโดยไม่ต้องรอให้แย่ลง
7:40. แอดมินคนสุดท้าย(ผู้ประสานงาน) เข้านอนแล้ว งานวันแรกเสร็จสิ้นแล้ว
8:09. นักพัฒนา วิศวกรศูนย์ข้อมูล และผู้ดูแลระบบกลุ่มแรก (รวมถึงผู้ประสานงานคนใหม่) เริ่มทำงานฟื้นฟู
09:37. เราเริ่มยกห้องโถงหมายเลข 7 (ห้องสุดท้าย)
ในเวลาเดียวกัน เรายังคงกู้คืนสิ่งที่ไม่ได้รับการแก้ไขในห้องอื่นๆ ต่อไป: การเปลี่ยนดิสก์/หน่วยความจำ/เซิร์ฟเวอร์ แก้ไขทุกสิ่งที่ "เบิร์น" ในการตรวจสอบ สลับบทบาทกลับในรูปแบบมาสเตอร์สแตนด์บาย และสิ่งเล็กๆ น้อยๆ อื่น ๆ ซึ่งมี แต่ก็ค่อนข้างมาก
17:08. เราอนุญาตให้ทำงานปกติทั้งหมดกับการผลิต
21:45. งานวันที่สองเสร็จสิ้นแล้ว
09:45. วันนี้เป็นวันศุกร์. ยังคงมีปัญหาเล็กน้อยในการติดตาม สุดสัปดาห์กำลังมาถึง ใครๆ ก็อยากพักผ่อน เรายังคงซ่อมแซมทุกสิ่งที่เราสามารถทำได้อย่างต่อเนื่อง งานผู้ดูแลระบบปกติที่อาจเลื่อนออกไปถูกเลื่อนออกไป ผู้ประสานงานเป็นคนใหม่
15:40. ทันใดนั้นครึ่งหนึ่งของอุปกรณ์เครือข่ายหลักในศูนย์ข้อมูลอีกแห่งก็เริ่มต้นใหม่อีกครั้ง แนวรบถูกนำออกจากการหมุนเพื่อลดความเสี่ยง ไม่มีผลกระทบต่อผู้ใช้ ต่อมาปรากฎว่าเป็นแชสซีที่ผิดปกติ ผู้ประสานงานกำลังซ่อมแซมอุบัติเหตุสองครั้งพร้อมกัน
17:17. การทำงานของเครือข่ายในศูนย์ข้อมูลอื่นได้รับการกู้คืนแล้ว ทุกอย่างได้รับการตรวจสอบแล้ว ศูนย์ข้อมูลถูกหมุนเวียน
18:29. งานวันที่สามและโดยทั่วไปเป็นการบูรณะหลังเกิดเหตุเสร็จ
เล่ม
04.04.2013 , "เพื่อนร่วมชั้น" —เป็นเวลาสามวันพอร์ทัลไม่สามารถใช้งานได้ทั้งหมดหรือบางส่วน ตลอดเวลาที่ผ่านมา ผู้คนมากกว่า 100 คนจากเมืองต่างๆ จากบริษัทต่างๆ (ขอขอบคุณอีกครั้ง!) จากระยะไกลและโดยตรงในศูนย์ข้อมูล ด้วยตนเองและโดยอัตโนมัติ ได้ซ่อมแซมเซิร์ฟเวอร์นับพันเครื่อง
เราได้ข้อสรุปแล้ว เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้นอีก เราได้ดำเนินการและดำเนินการอย่างต่อเนื่องมาจนถึงทุกวันนี้
อะไรคือความแตกต่างที่สำคัญระหว่างอุบัติเหตุปัจจุบันกับ 404?
- เรามี “แผนปฏิบัติการอุบัติเหตุ” เราทำแบบฝึกหัดไตรมาสละครั้ง - เราแสดงบทบาทสมมติในสถานการณ์ฉุกเฉิน ซึ่งกลุ่มผู้บริหาร (ในทางกลับกัน) จะต้องกำจัดโดยใช้ "แผนปฏิบัติการฉุกเฉิน" ผู้ดูแลระบบชั้นนำผลัดกันแสดงบทบาทเป็นผู้ประสานงาน
- ในโหมดทดสอบทุกไตรมาส เราจะแยกศูนย์ข้อมูล (ตามลำดับ) ผ่านเครือข่าย LAN และ WAN ซึ่งช่วยให้เราสามารถระบุปัญหาคอขวดได้ทันที
- ดิสก์เสียหายน้อยลง เพราะเราได้กระชับมาตรฐาน: ชั่วโมงการทำงานน้อยลง ค่าเกณฑ์ที่เข้มงวดยิ่งขึ้นสำหรับ S.M.A.R.T.
- เราละทิ้ง BerkeleyDB ซึ่งเป็นฐานข้อมูลเก่าและไม่เสถียรซึ่งต้องใช้เวลามากในการกู้คืนหลังจากรีสตาร์ทเซิร์ฟเวอร์
- เราลดจำนวนเซิร์ฟเวอร์ที่ใช้ MS SQL และลดการพึ่งพาเซิร์ฟเวอร์ที่เหลือ
- เรามีของเราเอง ซึ่งเราได้ย้ายบริการทั้งหมดอย่างจริงจังมาเป็นเวลาสองปีแล้ว ระบบคลาวด์ทำให้วงจรการทำงานกับแอปพลิเคชันทั้งหมดง่ายขึ้นอย่างมาก และในกรณีที่เกิดอุบัติเหตุ ระบบจะมอบเครื่องมือพิเศษเช่น:
- หยุดแอปพลิเคชันทั้งหมดได้อย่างถูกต้องในคลิกเดียว
- ย้ายแอปพลิเคชันจากเซิร์ฟเวอร์ที่ล้มเหลวได้ง่าย
- การจัดอันดับอัตโนมัติ (ตามลำดับความสำคัญของบริการ) การเปิดตัวศูนย์ข้อมูลทั้งหมด
อุบัติเหตุที่อธิบายไว้ในบทความนี้ถือเป็นอุบัติเหตุครั้งใหญ่ที่สุดนับตั้งแต่วันที่ 404 แน่นอนว่าไม่ใช่ทุกอย่างจะราบรื่น ตัวอย่างเช่น ในระหว่างที่ไม่มีศูนย์ข้อมูลที่ได้รับความเสียหายจากไฟไหม้ในศูนย์ข้อมูลอื่น ดิสก์บนเซิร์ฟเวอร์ตัวใดตัวหนึ่งเกิดความล้มเหลว นั่นคือ มีเพียงหนึ่งในสามแบบจำลองในคลัสเตอร์ Cassandra เท่านั้นที่ยังคงสามารถเข้าถึงได้ ซึ่งเป็นเหตุผลว่าทำไม 4,2% ของอุปกรณ์เคลื่อนที่ ผู้ใช้แอปพลิเคชันไม่สามารถเข้าสู่ระบบได้ ในเวลาเดียวกัน ผู้ใช้ที่เชื่อมต่ออยู่แล้วยังคงทำงานต่อไป โดยรวมแล้วจากอุบัติเหตุดังกล่าว มีการระบุปัญหามากกว่า 30 รายการ ตั้งแต่ข้อบกพร่องซ้ำๆ ไปจนถึงข้อบกพร่องในสถาปัตยกรรมบริการ
แต่ความแตกต่างที่สำคัญที่สุดระหว่างอุบัติเหตุปัจจุบันกับครั้งที่ 404 คือในขณะที่เรากำลังกำจัดผลที่ตามมาของไฟไหม้ ผู้ใช้ยังคงส่งข้อความและสนทนาทางวิดีโอถึง ,เล่นเกม,ฟังเพลง,ให้ของขวัญกัน,ชมวีดีโอ,ละครโทรทัศน์และช่องทีวีต่างๆ และยังได้สตรีมเข้ามาอีกด้วย .
อุบัติเหตุของคุณเป็นยังไงบ้าง?
ที่มา: will.com