บันทึกอาการและผลกระทบต่อธุรกิจ
บันทึกสิ่งที่ผู้ใช้สังเกต เหตุการณ์เริ่มเมื่อไหร่ บริการหรือสถานที่ใดได้รับผลกระทบ ขอบเขตของผลกระทบ หลักฐานที่มี และติดต่อที่น่าเชื่อถือ อย่าบังคับให้ผู้รายงานวินิจฉัยสาเหตุหลักหรือกำหนดลำดับความสำคัญทางเทคนิค
ซอฟต์แวร์การจัดการเหตุการณ์
ซอฟต์แวร์การจัดการเหตุการณ์สำหรับการกู้คืนบริการ—ไม่ใช่แค่ปิดตั๋ว
มอบบันทึกการปฏิบัติงานหนึ่งชุดสำหรับทีมรับมือเพื่อบันทึกผลกระทบ ผู้รับผิดชอบ การวินิจฉัย การอัปเดต วิธีแก้ปัญหาชั่วคราว การกู้คืน การตรวจสอบ และการติดตาม
มุมมองเหตุการณ์สดจะเปิดในกรณีที่มีการหยุดให้บริการและความเสี่ยงด้านเวลา มันแสดงสิ่งที่ทีมรับมือและเจ้าของบริการต้องตัดสินใจในตอนนี้ จากนั้นจะเก็บหลักฐานที่จำเป็นเพื่อยืนยันการฟื้นฟูและเรียนรู้จากการเกิดซ้ำ
ใช้ฟรีได้สูงสุด 5 คน โดยไม่ต้องใช้บัตรเครดิต
ปรับฟิลด์ เวิร์กโฟลว์ และแดชบอร์ดได้โดยไม่ต้องเขียนโค้ด สำรวจเทมเพลตแอปและกรณีใช้งานกว่า 1,000 รายการ
มุมมองแรกจะแสดงงานเหตุการณ์ที่กำลังดำเนินอยู่ ใช้แท็บมือถือเพื่อรายงานอาการ ผลกระทบ หลักฐาน และรายละเอียดการติดต่อจากโทรศัพท์
สดบริบทของผลกระทบและบริการ
เป็นผู้รับผิดชอบเจ้าของการตอบสนองและการอัปเดตต่อไป
ตรวจสอบแล้วการกู้คืนพร้อมการยืนยันจากผู้ใช้
รักษาความเร่งด่วนโดยไม่สูญเสียการควบคุม
บันทึกควรช่วยให้ผู้คนกู้คืนบริการได้อย่างรวดเร็วในขณะที่ป้องกันไม่ให้บริบทสำคัญและการตัดสินใจสูญหายไปในแชท
กำหนดความรับผิดชอบด้านการตอบสนองและการสื่อสาร
กำหนดให้บุคคลหนึ่งรับผิดชอบต่อเหตุการณ์ และอีกบทบาทหนึ่งรับผิดชอบในการอัปเดตผู้มีส่วนได้ส่วนเสียเมื่อจำเป็น แสดงการดำเนินการถัดไป เวลาอัปเดตถัดไป สถานะการยกระดับ และความเสี่ยงเป้าหมายแทนการพึ่งพาการเตือนส่วนตัว
กู้คืน ตรวจสอบ และเปิดใหม่เมื่อจำเป็น
บันทึกวิธีแก้ชั่วคราวหรือการดำเนินการกู้คืน การตรวจสอบทางเทคนิค การยืนยันจากผู้ใช้ที่ได้รับผลกระทบ และเงื่อนไขในการเปิดใหม่ สถานะว่า 'แก้ไขแล้ว' ไม่ควรลบการตรวจสอบการกู้คืนที่ล้มเหลว
ให้รายละเอียดกับผู้ชมแต่ละกลุ่มที่สามารถนำไปใช้ได้
ทีมรับมือ เจ้าของบริการ ผู้นำ และผู้ใช้ที่ได้รับผลกระทบต้องการมุมมองที่แตกต่างกันของเหตุการณ์เดียวกัน
บริบททางเทคนิคสำหรับทีมรับมือ
เก็บอาการที่สังเกตได้ การเปลี่ยนแปลงล่าสุด รายการคอนฟิกที่ได้รับผลกระทบ บันทึกหรือเอกสารแนบ บันทึกการสอบสวน สมมติฐาน การดำเนินการ และผลลัพธ์ในลำดับเวลาโดยไม่เปิดเผยการสนทนาทางเทคนิคส่วนตัวในฐานะอัปเดตของผู้ใช้
อัปเดตที่ชัดเจนสำหรับผู้ใช้ที่ได้รับผลกระทบ
เผยแพร่ผลกระทบที่ยืนยันแล้ว วิธีแก้ไขชั่วคราวที่มีอยู่ กิจกรรมการฟื้นฟูปัจจุบัน และเวลาของอัปเดตถัดไป แยกข้อเท็จจริงออกจากสมมติฐานและเก็บสถานะผู้ชมและการส่งมอบให้ชัดเจน
บริบทการตัดสินใจสำหรับเจ้าของบริการ
แสดงผลกระทบทางธุรกิจ เวลาในการดำเนินการ ความสำคัญของบริการ ข้อผูกพันที่พลาด การยกระดับ ซ้ำซาก และว่าจำเป็นต้องมีการทบทวนปัญหาหรือการเปลี่ยนแปลงหลังการฟื้นฟูหรือไม่
เปลี่ยนเหตุการณ์ให้เป็นการปฏิบัติการที่ปลอดภัยในอนาคต
ไม่ใช่ทุกเหตุการณ์ที่จะต้องมีการสรุปผลอย่างเต็มรูปแบบ แต่การปิดแต่ละครั้งควรทิ้งผลลัพธ์ปฏิบัติการที่สามารถชี้แจงได้
สร้างงานปัญหาเมื่อการเกิดซ้ำมีความสำคัญ
เชื่อมโยงอาการซ้ำและเหตุการณ์ที่เกี่ยวข้องกับบันทึกปัญหาเพื่อให้การทำงานหาสาเหตุหลัก ข้อผิดพลาดที่ทราบ และวิธีแก้ไขชั่วคราวดำเนินต่อไปหลังจากช่องทางตอบสนองเงียบลง
ควบคุมการเปลี่ยนแปลงที่ลดความเสี่ยง
เมื่อการแก้ไขถาวรต้องมีการปรับเปลี่ยนการผลิต ให้เชื่อมโยงเหตุการณ์นั้นกับการเปลี่ยนแปลงโดยมีการตัดสินใจเกี่ยวกับความเสี่ยง การตรวจสอบ การอนุมัติ การดำเนินการ และการย้อนกลับ
ตรวจสอบว่าผลลัพธ์ยังคงอยู่
กำหนดเวลาการตรวจสอบประสิทธิผลสั้น ๆ สำหรับบริการที่เปิดใหม่ การแจ้งเตือนซ้ำ ข้อร้องเรียนของผู้ใช้ หรือการดำเนินการแก้ไขที่ยังไม่เสร็จ ความมั่นใจในการปิดงานจะสูงขึ้นเมื่อสามารถกลับมาตรวจสอบได้
จัดลำดับความสำคัญตามผลกระทบ ความเร่งด่วน และบริบทบริการ
ฉลากความรุนแรงควรอธิบายรูปแบบการตอบสนอง ไม่ใช่แทนการตัดสินใจ
| สภาพที่สังเกตพบ | รูปแบบการตอบสนอง | หลักฐานก่อนปิด |
|---|---|---|
| บริการสำคัญไม่สามารถใช้งานได้สำหรับผู้ใช้หลายคน | การประสานงานเหตุการณ์ใหญ่และการอัปเดตบ่อยครั้ง | เกณฑ์การกู้คืนเป็นไปตามข้อกำหนด; ผู้มีส่วนได้เสียได้รับแจ้งแล้ว |
| วัสดุเสียหายพร้อมวิธีแก้ชั่วคราว | รับผิดชอบเหตุการณ์และตอบสนองตามเป้าหมาย | ยืนยันวิธีแก้ชั่วคราวหรือการกู้คืนแล้ว |
| ผลกระทบต่อผู้ใช้น้อย | คิวเหตุการณ์มาตรฐาน | ผู้รายงานหรือเจ้าของบริการยืนยันการใช้งาน |
| อาการเดิมเกิดซ้ำ | เหตุการณ์พร้อมกับปัญหาที่เชื่อมโยง | แยกงานกู้คืนทันทีและงานป้องกัน |
เหตุผลที่ JODOO เหมาะสม
ปรับการตอบสนองต่อเหตุการณ์ตามผลกระทบ ลำดับความสำคัญ และการกู้คืน
กำหนดค่าบันทึกเหตุการณ์ตามสัญญาณที่ทีมรับมือต้องการ: บริการที่ได้รับผลกระทบ, ผลกระทบต่อผู้ใช้, เวลาที่ผ่านไป, เจ้าของ, การดำเนินการปัจจุบัน, ความถี่ในการอัปเดต, วิธีแก้ชั่วคราว, การกู้คืน, และการยืนยัน
ผลลัพธ์คือบันทึกเหตุการณ์ที่สนับสนุนการดำเนินการระหว่างความผิดปกติและยังคงมีประโยชน์หลังการฟื้นฟูปรับระดับความสำคัญด้วยข้อเท็จจริงที่สังเกตได้
เปลี่ยนคำถามเกี่ยวกับผลกระทบและความเร่งด่วนโดยไม่ถามผู้รายงานให้วินิจฉัยสาเหตุ จากนั้นส่งบันทึกไปยังทีมที่รับผิดชอบ
เก็บการตอบสนองและการสื่อสารไว้ด้วยกัน
บันทึกการสืบสวน การตัดสินใจ วิธีแก้ปัญหาชั่วคราว การอัปเดตผู้ชม และการดำเนินการถัดไปที่ตกลงกันไว้ต่อเหตุการณ์เดียวกัน
ตรวจสอบก่อนปิด
ต้องมีการฟื้นฟูทางเทคนิค การยืนยันทางธุรกิจ การยืนยันจากผู้ใช้ หรือการตรวจสอบที่กำหนดไว้ และรักษาประวัติก่อนหน้านั้นเมื่อเหตุการณ์ถูกเปิดใหม่
แยกการประสานงานการตอบสนองออกจากการตรวจจับทางเทคนิค
Jodoo สามารถประสานงานบันทึกเหตุการณ์และการโอนต่อมนุษย์โดยไม่แทนที่เครื่องมือความสามารถในการสังเกตหรือการแจ้งเตือน
ใช้ Jodoo สำหรับ
การจับผลกระทบ ความสำคัญ ผู้รับผิดชอบ ประวัติการสอบสวน การสื่อสาร การตรวจสอบการกู้คืน การเปิดใหม่ และงานปัญหาหรือการเปลี่ยนแปลงที่เกี่ยวข้อง
เชื่อมต่อเครื่องมือทางเทคนิคที่มีอยู่
อ้างอิงการแจ้งเตือน บันทึก ร่องรอย เหตุการณ์ที่มีคิวการเรียกดู บันทึกการปรับใช้งาน การสื่อสารสถานะ และหลักฐานทางเทคนิคจากระบบที่มีอำนาจของพวกเขา
เลือกแพลตฟอร์มเหตุการณ์เฉพาะทางเมื่อ
การเชื่อมโยงเหตุการณ์พื้นเมือง การแจ้งเตือนอัตโนมัติ การวางแผนการสนทนาเหตุการณ์ หรือการตอบสนองที่ขับเคลื่อนด้วยการสังเกตเป็นข้อกำหนดหลักในการซื้อ
คำถามที่ทีมบริการถามก่อนเปลี่ยนระบบ
ความแตกต่างระหว่างเหตุการณ์กับคำขอบริการคืออะไร?
เหตุการณ์จะฟื้นฟูบริการที่ถูกขัดจังหวะหรือเสื่อมสภาพโดยไม่คาดคิด คำขอบริการจะตอบสนองความต้องการที่กำหนดไว้และคาดหวัง เช่น การเข้าถึง อุปกรณ์ หรือบริการมาตรฐาน รักษาวงจรชีวิตให้เกี่ยวข้องแต่แยกออกจากกัน
ผู้ใช้ควรเลือกความสำคัญของเหตุการณ์หรือไม่?
โดยทั่วไปพวกเขาควรอธิบายผลกระทบที่สังเกตได้และความเร่งด่วน ทีมบริการสามารถใช้โมเดลลำดับความสำคัญโดยพิจารณาบริการที่ได้รับผลกระทบ ขอบเขตผู้ใช้ ช่วงเวลาสำคัญ ผลกระทบด้านความปลอดภัยหรือการปฏิบัติตามกฎหมาย และความพร้อมของวิธีแก้ไขชั่วคราว
เหตุการณ์สามารถเปิดใหม่ได้หลังจากการแก้ไขหรือไม่?
ได้ เก็บรักษาการดำเนินการกู้คืนเดิมและผลการตรวจสอบ บันทึกเหตุผลที่บริการล้มเหลวอีกครั้ง และดำเนินวงจรชีวิตต่อไปแทนที่จะลบหรือปกปิดการตัดสินใจก่อนหน้า
การแจ้งเตือนจากการตรวจสอบสามารถป้อนเข้าสู่บันทึกเหตุการณ์ได้หรือไม่?
ได้ ผ่านการรวมหรืออัตโนมัติที่เหมาะสม การตรวจสอบยังคงเป็นแหล่งสัญญาณทางเทคนิค Jodoo ประสานความเข้าใจเกี่ยวกับผลกระทบ ผู้รับผิดชอบ การอัปเดต การตรวจสอบการกู้คืน และงานที่เกี่ยวข้อง
ผู้ตอบเหตุการณ์สามารถเปลี่ยนแปลงฟิลด์ของเหตุการณ์และการตรวจสอบการกู้คืนได้หรือไม่?
ผู้สร้างที่ได้รับอนุญาตสามารถปรับฟิลด์การรับข้อมูล กฎลำดับความสำคัญ ขั้นตอนการตอบสนอง การแจ้งเตือน หลักฐานการกู้คืน และแดชบอร์ดได้โดยไม่ต้องใช้โค้ดเมื่อการปฏิบัติเรื่องเหตุการณ์มีความเจริญขึ้น
สำรวจแอปที่ใช้งานได้
ตรวจสอบเหตุการณ์ทั้งหมดตั้งแต่รายงานจนถึงการกู้คืนที่ตรวจสอบแล้ว
เปิดตัวอย่างที่เติมข้อมูลไว้สำหรับการตอบสนองที่ใช้งานอยู่ การสื่อสาร วิธีแก้ปัญหาชั่วคราว การกู้คืน การเปิดใหม่ และการติดตามปัญหาก่อนปรับเวิร์กโฟลว์ให้เหมาะกับบริการของคุณ
สำรวจการดำเนินงานเหตุการณ์