วิธีการใช้รูปแบบเซิร์ฟเวอร์ที่เปลี่ยนแปลงไม่ได้โดยไม่สูญเสียความสามารถในการทำ post-mortems?

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

แง่มุมที่ได้รับความนิยมของการใช้งานของวินัยนี้คือการลบวิธีการเข้าถึงระยะไกลไปยังเซิร์ฟเวอร์เมื่อมีการเปิดตัว (โดยเฉพาะการลบการเข้าถึง SSH) การลบการเข้าถึงระยะไกลเป็นวิธีที่ง่ายเพื่อให้แน่ใจว่าการกำหนดค่าเซิร์ฟเวอร์ตรงกับการกำหนดค่าที่จัดทำโดยการปรับใช้แบบอัตโนมัติ

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

วิธีการใช้รูปแบบเซิร์ฟเวอร์ที่เปลี่ยนแปลงไม่ได้โดยไม่สูญเสียความสามารถในการทำ post-mortems?

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

วิธีหนึ่งในการเก็บรักษาโพสต์ชันสูตรคือการรวมศูนย์การบันทึก มีวิธีการมากมายที่จะทำให้สำเร็จ ELK stack, Splunk, syslog ...

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

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

เป็นการยากที่จะเจาะจงมากขึ้นเกี่ยวกับการบรรลุเป้าหมายนี้การกระจายแต่ละครั้งมีวิธีการได้รับสิ่งต่าง ๆ และฉันไม่มีตัวอย่างทั่วไป

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

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

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

นอกจากนี้ @Tensibai กล่าวว่าสิ่งที่ดีกว่าคือการตั้งค่าการบันทึกและการตรวจสอบที่เหมาะสมดังนั้นทุกครั้งที่คุณต้องทำการโพสต์ชันสูตรมีข้อมูลเพียงพอที่จะทำ