คำถามติดแท็ก post-mortem

ฉันรับผิดชอบชุดงานการประมวลผลคิว SQS ด้วยนโยบายการปรับขนาดในApproximateNumberOfMessagesVisibleตัวชี้วัด CloudWatch งานเหล่านี้อาจล้มเหลวในการติดตามจำนวนข้อความที่ส่งด้วยเหตุผลหลายประการ: การลดลงของบริการลดความสามารถของข้อความที่สามารถประมวลผลได้ AutoScaling ถึงขีด จำกัด สูงสุดในขณะที่ความลึกของคิวยังคงเพิ่มขึ้น S3 Outage ส่งผลกระทบต่อบริการ AWS อื่น ๆ ( AutoScalingบริการ) ที่งานการประมวลผลคิวใช้เพื่อตอบสนองความต้องการ เมื่อพูดถึงการขาดหายกับสมาชิกในทีมที่ไม่ใช่ด้านเทคนิคฉันต้องการสื่อสารความล่าช้าเฉพาะของการประมวลผลคิวที่สามารถแปลเป็นความเสื่อมโทรมที่ลูกค้าเห็นได้ ฉันจะทำสิ่งนี้กับ SQS queues ได้อย่างไร

13 amazon-web-services  amazon-sqs  amazon-cloudwatch  post-mortem 

บางครั้งคุณต้องตรวจสอบภาชนะบรรจุซึ่งหยุดทำงานหรือภาชนะบรรจุซึ่งหลังจากการเริ่มต้นการตายอย่างรวดเร็วและหยุดลง docker exec -ti <id> bash ใช้งานได้กับการเรียกใช้คอนเทนเนอร์เท่านั้นเมื่อเสร็จสิ้นพรอมต์ bash จะสิ้นสุดลงเช่นกัน ด้วยdocker startคุณไม่สามารถให้คำสั่งที่แตกต่างกันและถ้าคอนเทนเนอร์ตายทันทีอีกครั้งคุณจะไม่มีเวลาพอที่จะเข้าไปในคอนเทนเนอร์และทำการตรวจสอบของคุณ เราสามารถทำได้docker commitแล้วdocker runในภาพใหม่ด้วยคำสั่งที่แตกต่างกัน แต่ฉันสงสัยว่ามีทางเลือกอื่น ๆ หมายเหตุ : docker logsเพียงแค่คืนสิ่งที่แอพพลิเคชั่นพิมพ์ไปยัง stdout / stderr นั่นอาจไม่เพียงพอที่จะคิดออกว่าปัญหาคืออะไร

13 docker  containers  post-mortem 

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

12 immutable-servers  post-mortem