คำถามติดแท็ก sla

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

2
การกระจายทางภูมิศาสตร์ทนต่อความผิดพลาดและระบบตรวจสอบแอปพลิเคชัน / โฮสต์ที่“ ชาญฉลาด”
ทักทาย, ฉันต้องการถามความคิดเห็นของกลุ่มและมุมมองเกี่ยวกับระบบการตรวจสอบแบบกระจายคุณใช้อะไรและคุณตระหนักถึงสิ่งใดที่อาจทำเครื่องหมายในช่องของฉัน ความต้องการค่อนข้างซับซ้อน ไม่มีจุดล้มเหลวเดียว จริงๆ. ฉันตายไปแล้ว! ต้องสามารถทนต่อความล้มเหลวของโหนดเดี่ยว / หลายโหนดได้ทั้ง 'ต้นแบบ' และ 'ผู้ปฏิบัติงาน' และคุณอาจคิดว่าไม่มีตำแหน่งการตรวจสอบ ("ไซต์") ที่มีหลายโหนดอยู่ในนั้นหรืออยู่ในเครือข่ายเดียวกัน ดังนั้นสิ่งนี้อาจเป็นกฎของเทคนิค HA ดั้งเดิมเช่น DRBD หรือ Keepalive ตรรกะการกระจายฉันต้องการที่จะปรับใช้ 5+ โหนดในหลายเครือข่ายภายในหลายศูนย์ข้อมูลและในหลายทวีป ฉันต้องการมุมมอง "Birds Eye" ของเครือข่ายและแอปพลิเคชันของฉันจากมุมมองของลูกค้าของฉันคะแนนโบนัสสำหรับตรรกะการตรวจสอบจะไม่จมเมื่อคุณมี 50+ โหนดหรือแม้กระทั่ง 500+ โหนด ต้องมีความสามารถในการจัดการเช็คโฮสต์ / บริการจำนวนพอสมควรพอสมควรลากานิโอสำหรับตัวเลขของ ballpark ถือว่ามีโฮสต์ 1,500-2500 โฮสต์และบริการ 30 รายการต่อโฮสต์ มันจะดีมากถ้าเพิ่มโหนดการตรวจสอบมากขึ้นช่วยให้คุณสามารถขยายขนาดเชิงเส้นบางทีในเวลา 5 ปีฉันอาจมองตรวจสอบโฮสต์ 5000 และ 40 บริการต่อโฮสต์! เพิ่มในจากบันทึกของฉันข้างต้นเกี่ยวกับ 'ตรรกะกระจาย' …
12 monitoring  nagios  sla 

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.