Contabo ปิดเซิร์ฟเวอร์ของฉันโดยไม่มีการเตือน ฉันค้นพบมันห้าชั่วโมงต่อมาโดยบังเอิญ

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

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

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

เหตุใดการตรวจสอบแบบเรื่อย ๆ จึงล้มเหลวเมื่อคุณต้องการมากที่สุด

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

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

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

ห้าชั่วโมงของความเงียบสงบที่ต้องใช้จริง ๆ

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

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

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

การสร้างมอนิเตอร์ที่ควรจะมีอยู่

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

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

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

จากเครื่องมือส่วนตัวไปยังแพลตฟอร์ม

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

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

แพลตฟอร์มทั้งหมดที่ uptime.yeb.to ตอนนี้มีอยู่เพราะการปิดเซิร์ฟเวอร์ที่ไม่ประกาศครั้งเดียวและห้าชั่วโมงของความเงียบสงบ ทุกคุณลักษณะสามารถติดตามกลับไปสู่ความล้มเหลวเฉพาะที่จะถูกจับได้ หรือป้องกันได้อย่างสมบูรณ์ด้วยการตรวจสอบที่เหมาะสม เหตุการณ์ Contabo ไม่ได้เป็นปัญหาเซิร์ฟเวอร์ครั้งสุดท้ายที่เกิดขึ้น แต่มันเป็นเหตุการณ์ครั้งสุดท้ายที่ไปไม่ตรวจสอบเป็นเวลาห้าชั่วโมง ความแตกต่างนั้นทำให้เกิดความแตกต่างทั้งหมด