การสิ้นสุดของเดือนแรกและต้นเดือนที่สองของฤดูร้อนปี 2019 กลายเป็นเรื่องยากและถูกทำเครื่องหมายด้วยบริการไอทีทั่วโลกที่ลดลงอย่างมาก ในบรรดาเหตุการณ์ที่น่าสังเกต: เหตุการณ์ร้ายแรงสองเหตุการณ์ในโครงสร้างพื้นฐาน CloudFlare (เหตุการณ์แรก - ด้วยมือที่คดเคี้ยวและทัศนคติที่ประมาทเลินเล่อต่อ BGP ในส่วนของ ISP บางรายจากสหรัฐอเมริกา ประการที่สอง - ด้วยการปรับใช้ CF ที่คดเคี้ยว ซึ่งส่งผลกระทบต่อทุกคนที่ใช้ CF และนี่คือบริการที่โดดเด่นมากมาย) และการทำงานที่ไม่เสถียรของโครงสร้างพื้นฐาน Facebook CDN (ส่งผลกระทบต่อผลิตภัณฑ์ FB ทั้งหมด รวมถึง Instagram และ WhatsApp) นอกจากนี้เรายังต้องติดตามการจัดจำหน่าย แม้ว่าการหยุดทำงานของเราจะสังเกตเห็นได้น้อยกว่ามากเมื่อเทียบกับพื้นหลังทั่วโลก มีคนเริ่มลากเฮลิคอปเตอร์สีดำและการสมรู้ร่วมคิด "อธิปไตย" เข้ามาแล้ว ดังนั้นเราจึงเผยแพร่การชันสูตรพลิกศพต่อสาธารณะเกี่ยวกับเหตุการณ์ของเรา
03.07.2019, 16: 05
เริ่มบันทึกปัญหาเกี่ยวกับทรัพยากร คล้ายกับความล้มเหลวในการเชื่อมต่อเครือข่ายภายใน เมื่อไม่ได้ตรวจสอบทุกอย่างอย่างสมบูรณ์ พวกเขาก็เริ่มตำหนิประสิทธิภาพของช่องทางภายนอกที่มีต่อ DataLine เนื่องจากเห็นได้ชัดว่าปัญหาอยู่ที่การเข้าถึงอินเทอร์เน็ต (NAT) ของเครือข่ายภายในจนถึงจุดที่นำเซสชัน BGP ไปทาง DataLine
03.07.2019, 16: 35
เห็นได้ชัดว่าอุปกรณ์ที่ให้บริการการแปลที่อยู่เครือข่ายและการเข้าถึงจากเครือข่ายท้องถิ่นของไซต์ไปยังอินเทอร์เน็ต (NAT) ล้มเหลว ความพยายามที่จะรีบูตอุปกรณ์ไม่ได้นำไปสู่สิ่งใด ๆ การค้นหาตัวเลือกอื่นสำหรับการจัดการการเชื่อมต่อเริ่มต้นขึ้นก่อนที่จะได้รับการตอบกลับจากฝ่ายสนับสนุนด้านเทคนิค เนื่องจากจากประสบการณ์สิ่งนี้ไม่น่าจะช่วยได้
ปัญหาค่อนข้างรุนแรงขึ้นเนื่องจากอุปกรณ์นี้ยังยุติการเชื่อมต่อขาเข้าของพนักงาน VPN ไคลเอนต์ และการกู้คืนจากระยะไกลก็ทำได้ยากขึ้น
03.07.2019, 16: 40
เราพยายามรื้อฟื้นแผน NAT สำรองที่มีอยู่ก่อนหน้านี้ซึ่งเคยใช้ได้ผลดีมาก่อน แต่เห็นได้ชัดว่าการปรับปรุงเครือข่ายหลายครั้งทำให้โครงการนี้ใช้งานไม่ได้เกือบทั้งหมด เนื่องจากการบูรณะอาจไม่ได้ผล หรืออย่างแย่ที่สุดก็ทำลายสิ่งที่กำลังทำงานอยู่ได้
เราเริ่มทำงานกับแนวคิดสองสามข้อในการถ่ายโอนการรับส่งข้อมูลไปยังชุดเราเตอร์ใหม่ที่ให้บริการแบ็คโบน แต่ดูเหมือนว่าไม่สามารถใช้งานได้เนื่องจากลักษณะเฉพาะของการกระจายเส้นทางในเครือข่ายหลัก
03.07.2019, 17: 05
ในเวลาเดียวกัน มีการระบุปัญหาในกลไกการแก้ไขชื่อบนเนมเซิร์ฟเวอร์ ซึ่งนำไปสู่ข้อผิดพลาดในการแก้ไขจุดสิ้นสุดในแอปพลิเคชัน และพวกเขาก็เริ่มกรอกไฟล์โฮสต์อย่างรวดเร็วด้วยบันทึกของบริการที่สำคัญ
03.07.2019, 17: 27
ฟังก์ชันการทำงานที่จำกัดของ Habr ได้รับการฟื้นฟูแล้ว
03.07.2019, 17: 43
แต่ท้ายที่สุดแล้ว ก็พบวิธีแก้ปัญหาที่ค่อนข้างปลอดภัยในการจัดระเบียบการรับส่งข้อมูลผ่านเราเตอร์ชายแดนตัวใดตัวหนึ่ง ซึ่งได้รับการติดตั้งอย่างรวดเร็ว การเชื่อมต่ออินเทอร์เน็ตได้รับการกู้คืนแล้ว
ในช่วงไม่กี่นาทีต่อมา มีการแจ้งเตือนจำนวนมากจากระบบการตรวจสอบเกี่ยวกับการคืนค่าฟังก์ชันการทำงานของเอเจนต์การตรวจสอบ แต่บริการบางอย่างกลับกลายเป็นว่าไม่สามารถใช้งานได้เนื่องจากกลไกการแก้ไขชื่อบนเนมเซิร์ฟเวอร์ (dns) ใช้งานไม่ได้
03.07.2019, 17: 52
NS ถูกรีสตาร์ทและล้างแคชแล้ว การแก้ไขได้รับการกู้คืนแล้ว
03.07.2019, 17: 55
บริการทั้งหมดเริ่มทำงานได้ ยกเว้น MK, Freelansim และ Toaster
03.07.2019, 18: 02
MK และ Freelansim เริ่มทำงาน
03.07.2019, 18: 07
นำเซสชัน BGP ที่บริสุทธิ์กลับมาด้วย DataLine
03.07.2019, 18: 25
พวกเขาเริ่มบันทึกปัญหาเกี่ยวกับทรัพยากรซึ่งเกิดจากการเปลี่ยนแปลงที่อยู่ภายนอกของกลุ่ม NAT และการไม่มีบริการจำนวนหนึ่งซึ่งได้รับการแก้ไขทันที เครื่องปิ้งขนมปังเริ่มทำงานทันที
03.07.2019, 20: 30
เราสังเกตเห็นข้อผิดพลาดที่เกี่ยวข้องกับบอท Telegram ปรากฎว่าพวกเขาลืมลงทะเบียนที่อยู่ภายนอกใน acl สองสามตัว (พร็อกซีเซิร์ฟเวอร์) ซึ่งได้รับการแก้ไขทันที
ผลการวิจัย
- อุปกรณ์ซึ่งเคยหว่านข้อสงสัยเกี่ยวกับความเหมาะสมไว้ก่อนหน้านี้ล้มเหลว มีแผนจะกำจัดมันออกจากงาน เนื่องจากมันรบกวนการพัฒนาเครือข่ายและมีปัญหาความเข้ากันได้ แต่ในขณะเดียวกัน มันก็ทำหน้าที่ที่สำคัญ ซึ่งเป็นเหตุผลว่าทำไมการเปลี่ยนใดๆ จึงทำได้ยากในทางเทคนิคโดยไม่รบกวนบริการ ตอนนี้คุณสามารถเดินหน้าต่อไปได้
- ปัญหา DNS สามารถหลีกเลี่ยงได้โดยการย้ายเข้าไปใกล้กับเครือข่ายแกนหลักใหม่ที่อยู่นอกเครือข่าย NAT และยังคงมีการเชื่อมต่อกับเครือข่ายสีเทาอย่างสมบูรณ์โดยไม่มีการแปล (ซึ่งเป็นแผนก่อนเกิดเหตุการณ์)
- คุณไม่ควรใช้ชื่อโดเมนเมื่อประกอบคลัสเตอร์ RDBMS เนื่องจากความสะดวกในการเปลี่ยนที่อยู่ IP อย่างโปร่งใสไม่จำเป็นอย่างยิ่งเนื่องจากการยักย้ายดังกล่าวยังต้องมีการสร้างคลัสเตอร์ใหม่ การตัดสินใจนี้ถูกกำหนดโดยเหตุผลทางประวัติศาสตร์ และประการแรกคือความชัดเจนของตำแหน่งข้อมูลตามชื่อในการกำหนดค่า RDBMS โดยทั่วไปแล้วกับดักแบบคลาสสิก
- โดยหลักการแล้วมีการดำเนินการแบบฝึกหัดที่เทียบเคียงได้กับ "อธิปไตยของ Runet" มีบางอย่างที่ต้องคำนึงถึงในแง่ของการเสริมสร้างขีดความสามารถในการเอาชีวิตรอดด้วยตนเอง
ที่มา: will.com