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