การรายงานเหตุการณ์ตาม DORA และ NIS2: รับสายโทรเข้าก่อนเวลาจะหมด

สารบัญ

• นาฬิกาการรายงานกำหนดอะไรไว้บ้าง
• ทำไมเส้นตายการรายงานจึงเป็นปัญหาเรื่องการปลุกคนให้ตื่น
• วันหยุดสุดสัปดาห์ช่วยซื้อเวลาให้คุณไหม
• วิธีวางโทรศัพท์ที่ดังได้ไว้หน้าเวิร์กโฟลว์การรายงานของคุณ
• ขั้นที่ 1 — สร้างช่องแบบโทรเข้าที่สงวนไว้สำหรับเหตุการณ์ที่ต้องรายงาน
• ขั้นที่ 2 — ชี้ระบบตรวจจับของคุณมาที่ webhook นั้น
• ขั้นที่ 3 — ใช้เงื่อนไขเพื่อให้เฉพาะเรื่องที่เข้าข่ายเท่านั้นที่ทำให้เครื่องดัง
• ขั้นที่ 4 — จับระบบที่ส่งได้แต่อีเมล
• ขั้นที่ 5 — ให้คนที่รับผิดชอบนาฬิกาอยู่ในช่องเดียวกัน
• ขั้นที่ 6 — ทดสอบขณะเปิดโหมดห้ามรบกวน
• สิ่งที่ Echobell ไม่ได้ทำ
• คำถามที่พบบ่อย
• การใช้ Echobell ทำให้เราปฏิบัติตาม DORA หรือ NIS2 ได้เลยไหม
• นาฬิกา 4 ชั่วโมงของ DORA เริ่มเดินเมื่อไรกันแน่
• การแจ้งเตือนล่วงหน้าตาม NIS2 ต้องมีรายละเอียดเหตุการณ์ครบถ้วนไหม
• ระบบมอนิเตอร์ของเราส่งอีเมลหาวิศวกรที่อยู่เวร on-call อยู่แล้ว แค่นั้นยังไม่พออีกหรือ
• ฝ่ายกำกับการปฏิบัติตามกฎเกณฑ์กับฝ่ายวิศวกรรมรับการแจ้งเตือนเดียวกันได้ไหม
• สายจะทะลุโหมดห้ามรบกวนได้จริงไหม
• ใช้ได้เฉพาะบน iOS ใช่ไหม
• ควรใส่ข้อมูลอะไรลงใน payload ของ webhook
• บทความที่เกี่ยวข้อง

เส้นตายการรายงานเหตุการณ์ของสหภาพยุโรปทุกฉบับเริ่มนับจากสิ่งที่เครื่องจักรตรวจพบ และเดินหน้านับต่อไปขณะที่ทีมของคุณหลับอยู่ ถ้าการแจ้งเตือนที่เริ่มเดินนาฬิกามาถึงในรูปแบบพุชเงียบ ๆ เวลา 02:40 ของคืนวันอาทิตย์ คุณก็เผาเวลาไปแล้วหนึ่งในสี่ของกรอบเวลารายงานตาม DORA ก่อนที่มนุษย์คนแรกจะได้อ่านมันด้วยซ้ำ คู่มือนี้จะแสดงวิธีวางสายโทรเข้าที่ดังจริงไว้หน้าเวิร์กโฟลว์การรายงานของคุณด้วย Echobell เพื่อให้นาฬิกาและการตอบสนองของคุณเริ่มเดินไปพร้อม ๆ กัน

ตอนนี้ขนาดของปัญหาเป็นตัวเลขที่วัดได้แล้ว ไม่ใช่การคาดเดา เมื่อวันที่ 3 มิถุนายน 2026 หน่วยงานกำกับดูแลยุโรปทั้งสามแห่งเผยแพร่ภาพรวมทั่วสหภาพยุโรปฉบับแรกของเหตุการณ์ ICT ร้ายแรงที่รายงานภายใต้ DORA คือ เหตุการณ์ร้ายแรง 3,383 ครั้ง ในปี 2025 เฉลี่ย 0.18 ครั้งต่อสถาบันการเงิน ที่อยู่ในขอบเขต โดย ราวหนึ่งในสาม มีผลกระทบข้ามพรมแดน (EBA, ESMA) รายละเอียดที่ควรกำหนดรูปแบบการแจ้งเตือนของคุณคือ มีเพียง 10% เท่านั้นที่เกี่ยวข้องกับความมั่นคงปลอดภัยไซเบอร์ ตัวขับเคลื่อนหลักคือระบบล้มเหลวและเหตุการณ์ภายนอก

พูดอีกอย่างคือ เหตุการณ์ที่ทำให้นาฬิกาตามกฎระเบียบเริ่มเดินนั้นส่วนใหญ่เป็นเรื่องน่าเบื่อ ๆ ทั้งนั้น ทั้งการ deploy ที่ล้มเหลว dependency ที่ตายไป หรือผู้ให้บริการล่ม ก็คือสิ่งเดียวกับที่ระบบมอนิเตอร์ของคุณจับได้ตอนตีสามและส่งไปยังโทรศัพท์ที่เปิดโหมดห้ามรบกวนอยู่นั่นเอง

นาฬิกาการรายงานกำหนดอะไรไว้บ้าง

สามระเบียบ สามสัญญาณเริ่มต้นที่ต่างกัน และทั้งหมดเดินแบบเรียลไทม์ นี่คือสิ่งที่ตัวบทฉบับปัจจุบันระบุไว้

กรอบเวลาของ DORA มาจาก Commission Delegated Regulation (EU) 2025/301 ซึ่งเป็นมาตรฐานทางเทคนิคด้านเนื้อหาและกรอบเวลาของการรายงานเหตุการณ์ เผยแพร่เมื่อ 20 กุมภาพันธ์ 2025 เพื่อเสริม Regulation (EU) 2022/2554 (คณะกรรมาธิการยุโรป, ตัวบทมาตรา 5) ส่วน DORA เองมีผลบังคับใช้ตั้งแต่ 17 มกราคม 2025 (ESMA)

กรอบเวลาของ NIS2 อยู่ในมาตรา 23(4) ของ Directive (EU) 2022/2555 โดยรัฐสมาชิกต้องอนุวัติภายใน 17 ตุลาคม 2024 (คณะกรรมาธิการยุโรป) ส่วนเส้นตายของ SEC มาจากกฎการเปิดเผยข้อมูลด้านความมั่นคงปลอดภัยไซเบอร์ที่ประกาศใช้เมื่อ 26 กรกฎาคม 2023 (SEC)

ทำไมเส้นตายการรายงานจึงเป็นปัญหาเรื่องการปลุกคนให้ตื่น

เพราะไม่มีนาฬิกาเรือนไหนผูกกับเวลาทำงานของคุณ DORA นับจากการจัดระดับและจากที่หน่วยงานรับรู้ NIS2 นับจากที่หน่วยงานรับรู้ ส่วน SEC นับจากการพิจารณาว่ามีสาระสำคัญ การจะถือว่าช่วงเวลาใดนับเป็น "การรับรู้" นั้นเป็นดุลพินิจทางกฎหมายที่ฝ่ายกำกับการปฏิบัติตามกฎเกณฑ์ของคุณต้องตัดสิน แต่ไม่มีข้อความใดในตัวบทเหล่านี้เลยที่ให้เริ่มนับใหม่เพราะคนแรกที่ควรเห็นการแจ้งเตือนบังเอิญหลับอยู่

ลองคิดย้อนกลับด้วยเส้นทางที่คับที่สุดของ DORA คุณมีเวลา 4 ชั่วโมงนับจากวินาทีที่เหตุการณ์ถูกจัดระดับว่าร้ายแรง และการจัดระดับเกิดขึ้นไม่ได้ก่อนที่มนุษย์จะได้ดูมัน ถ้าตรวจพบตอน 02:40 ไม่มีใครรับทราบจนถึง 08:00 และการจัดระดับใช้เวลาสืบสวนอีก 90 นาที คุณก็จะยื่นแจ้งเบื้องต้นราว 11:00 ซึ่งยังอยู่ในกรอบนอกสุด 24 ชั่วโมง แต่ก็ใช้เวลาไปกว่าแปดชั่วโมงจากเพดาน 24 ชั่วโมงไปกับการนอนล้วน ๆ ถ้าย่นช่องว่างของการรับทราบลงได้ ทุกขั้นตอนถัดไปก็มีที่หายใจมากขึ้น

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

วันหยุดสุดสัปดาห์ช่วยซื้อเวลาให้คุณไหม

ช่วยได้นิดหน่อยภายใต้ DORA และมีโอกาสสูงว่าไม่ช่วยสำหรับคุณ Delegated Regulation (EU) 2025/301 อนุญาตให้สถาบันการเงินที่มีเส้นตายตรงกับวันหยุดสุดสัปดาห์หรือวันหยุดธนาคารในรัฐสมาชิกของตน ยื่นได้ภายในเที่ยงของวันทำการถัดไป แต่มาตราเดียวกันก็ตัดสิทธิ์นี้ออกจากสถาบันสินเชื่อ คู่สัญญากลาง ผู้ดำเนินการศูนย์ซื้อขาย และหน่วยงานที่เป็นหน่วยงานจำเป็นหรือหน่วยงานสำคัญภายใต้ NIS2 หน่วยงานกำกับดูแลยังอาจยกเลิกสิทธิ์นี้สำหรับหน่วยงานอื่นที่มีความสำคัญเชิงระบบได้ด้วย (มาตรา 5, สรุปโดย Advisera)

ดังนั้นองค์กรที่มีโอกาสเจอเหตุการณ์ในคืนวันอาทิตย์มากที่สุด ก็คือกลุ่มที่ไม่ได้รับการผ่อนผันวันหยุดพอดี ส่วนมาตรา 23 ของ NIS2 ไม่มีการขยายเวลาช่วงวันหยุดเลยแม้แต่น้อย ให้วางแผนโดยถือว่านาฬิกาเดินในวันเสาร์เหมือนที่เดินในวันอังคาร แล้วถือว่าการขยายเวลาที่คุณอาจได้รับเป็นโบนัส ไม่ใช่กันชน

วิธีวางโทรศัพท์ที่ดังได้ไว้หน้าเวิร์กโฟลว์การรายงานของคุณ

Echobell ทำอย่างเดียว คือเปลี่ยน webhook หรืออีเมลให้เป็นสายโทรเข้า สายที่ดังจริง สั่นจริง และทะลุโหมดโฟกัสกับโหมดห้ามรบกวนของ iOS ได้เหมือนสายจากคนในครอบครัว (ดูการทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต) มันอยู่ระหว่างระบบที่ตรวจพบเหตุการณ์กับมนุษย์ที่ต้องเป็นคนเริ่มเดินนาฬิกา

ขั้นที่ 1 — สร้างช่องแบบโทรเข้าที่สงวนไว้สำหรับเหตุการณ์ที่ต้องรายงาน

สร้างช่องใน Echobell แล้วตั้งประเภทการแจ้งเตือนเป็น โทรเข้า นี่คือสิ่งที่ทำให้โทรศัพท์ดังแทนที่จะส่งพุชเงียบ ๆ (ประเภทการแจ้งเตือน) ตั้งชื่อที่ไม่มีทางเข้าใจผิด เช่น "Reportable incident — wake up" แล้วใช้ช่องนี้กับเรื่องอื่นเด็ดขาด คัดลอก URL ของ webhook จากหน้ารายละเอียดช่อง หน้าตาจะประมาณ https://hook.echobell.one/t/<channel-token> ให้ถือว่าเป็นความลับ

ขั้นที่ 2 — ชี้ระบบตรวจจับของคุณมาที่ webhook นั้น

อะไรก็ตามที่ตรวจพบเหตุการณ์ให้ส่งคำขอ HTTP ไปยัง URL ของช่อง Echobell มีคู่มือเฉพาะสำหรับ Grafana, Prometheus Alertmanager, Uptime Kuma และ UptimeRobot ส่วนอย่างอื่นที่ POST JSON ได้ก็ใช้คู่มือ webhookได้เลย payload ที่ดีควรมีข้อมูลพอให้ตัดสินใจจัดระดับเบื้องต้นได้โดยไม่ต้องเปิดโน้ตบุ๊ก:

{
  "title": "Reportable candidate: {{service}}",
  "message": "{{service}} down since {{started_at}} — client-facing: {{client_impact}}",
  "externalLink": "https://status.internal.example/incident/{{id}}"
}

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

ขั้นที่ 3 — ใช้เงื่อนไขเพื่อให้เฉพาะเรื่องที่เข้าข่ายเท่านั้นที่ทำให้เครื่องดัง

สายโทรที่ดังทุกครั้งที่มีคำเตือนจะเลิกเป็นสายโทรและกลายเป็นเสียงรบกวนพื้นหลัง เงื่อนไขของ Echobell กรองจากค่าตัวแปรด้วยตรรกะ AND/OR ได้ คุณจึงกำหนดได้ว่าต้อง severity == "critical" และ client_impact == true เท่านั้นช่องจึงจะโทรหาใคร ส่วนอะไรที่ต่ำกว่าเกณฑ์นั้นให้ส่งไปช่องแบบสำคัญตามเวลาหรือมาตรฐานแยกต่างหาก ช่องสำหรับเหตุการณ์ที่ต้องรายงานควรดังปีละไม่กี่ครั้ง ไม่ใช่ทุกสัปดาห์

ขั้นที่ 4 — จับระบบที่ส่งได้แต่อีเมล

ฟีดสถานะของผู้ขายจำนวนมาก เครื่องมือเฝ้าระวังการฉ้อโกง และผู้ให้บริการภายนอกหลายราย แจ้งเตือนทางอีเมลเท่านั้น ซึ่งเป็นเรื่องสำคัญภายใต้ DORA เพราะความล้มเหลวฝั่งผู้ให้บริการก็อยู่ในขอบเขตเต็ม ๆ ทุกช่องของ Echobell มีที่อยู่อีเมลของตัวเองได้ กฎการส่งต่อเพียงข้อเดียวจึงเปลี่ยนข้อความเหล่านั้นให้กลายเป็นสายโทรได้ (ทริกเกอร์อีเมล, การตั้งค่าอีเมลเป็นสายโทร)

ขั้นที่ 5 — ให้คนที่รับผิดชอบนาฬิกาอยู่ในช่องเดียวกัน

ฝ่ายวิศวกรรมเป็นคนเจอเหตุการณ์ แต่ฝ่ายกำกับการปฏิบัติตามกฎเกณฑ์ เจ้าหน้าที่เวร หรือ DPO เป็นเจ้าของเส้นตาย แชร์ช่องแล้วให้ผู้ติดตามแต่ละคนเลือกระดับความเร่งด่วนของตัวเอง วิศวกรที่อยู่เวร on-call ก็จะได้รับสาย ขณะที่ผู้ตอบสนองคนที่สองได้รับการแจ้งเตือนแบบสำคัญตามเวลา และควรเปิด โทรซ้ำเมื่อสายไม่ติด เพื่อให้ระบบพยายามโทรอีกครั้งเมื่อสายถูกโหมดโฟกัสสกัดไว้

ขั้นที่ 6 — ทดสอบขณะเปิดโหมดห้ามรบกวน

ส่ง webhook ทดสอบขณะเปิดโหมดห้ามรบกวนบนทุกเครื่องที่เกี่ยวข้อง อย่างน้อยไตรมาสละครั้ง เส้นทางการยกระดับที่ไม่เคยทดสอบก็เป็นแค่ข้อสันนิษฐาน และข้อสันนิษฐานนี่แหละคือวัตถุดิบของการทบทวนหลังเกิดเหตุ

สิ่งที่ Echobell ไม่ได้ทำ

การพูดให้ชัดตรงนี้สำคัญยิ่งกว่าที่อื่น เพราะเป็นเวิร์กโฟลว์ที่อยู่ใต้การกำกับดูแล

Echobell ทำสิ่งเหล่านี้: เปลี่ยน webhook หรืออีเมลให้เป็นสายโทรที่ดังจริง การแจ้งเตือนแบบสำคัญตามเวลา หรือพุชมาตรฐาน ทะลุโหมดโฟกัสและโหมดห้ามรบกวนของ iOS สำหรับการแจ้งเตือนแบบโทรเข้า กรองด้วยเงื่อนไขและเทมเพลต และส่งการแจ้งเตือนเดียวกันไปยังช่องที่ทีมแชร์ร่วมกัน

Echobell ไม่ได้ทำสิ่งเหล่านี้:

• จัดระดับเหตุการณ์ มันไม่มีความเห็นว่าเรื่องหนึ่งเป็น "ร้ายแรง" ตาม DORA "มีนัยสำคัญ" ตาม NIS2 หรือ "มีสาระสำคัญ" ตามกฎของ SEC หรือไม่ นั่นคือดุลพินิจที่คนของคุณต้องตัดสินโดยเทียบกับเกณฑ์ในตัวบทที่เกี่ยวข้อง
• ยื่นเอกสารให้ใคร มันไม่ได้ยื่นต่อหน่วยงานกำกับดูแล CSIRT หรือ SEC มันแค่พาให้มนุษย์มาถึงจุดที่ลงมือยื่นได้
• ทำหน้าที่เป็นระบบเก็บบันทึกหรือระบบ GRC ของคุณ ระเบียบเหล่านี้ต้องการเอกสาร ทะเบียน และหลักฐานที่แอปแจ้งเตือนผลิตให้ไม่ได้ Echobell จงใจเก็บเนื้อหาและประวัติการแจ้งเตือนไว้บนเครื่องของคุณเท่านั้น โดยมีเพียงข้อมูลบัญชี ช่อง และการติดตามอยู่บนเซิร์ฟเวอร์ (แนวคิดด้านความเป็นส่วนตัว) ซึ่งดีต่อการลดข้อมูลให้น้อยที่สุด แต่ใช้เป็นร่องรอยสำหรับตรวจสอบไม่ได้
• มาพร้อมหนังสือรับรองการปฏิบัติตามกฎเกณฑ์ ไม่มีใบรับรอง รายงานการตรวจสอบ หรือ SLA ตามสัญญาแนบมาด้วย ถ้าคุณจะนำมาใช้ในเวิร์กโฟลว์ที่อยู่ใต้การกำกับดูแล ให้ผ่านกระบวนการบริหารความเสี่ยงจากบุคคลที่สามด้าน ICT ของคุณเองเหมือนเครื่องมืออื่น ๆ และเก็บช่องทางสำรองที่ไม่ต้องพึ่งมันไว้ด้วย
• รับประกันการนำส่ง สายโทรขึ้นอยู่กับโครงสร้างพื้นฐานการส่งพุช เครือข่าย และโทรศัพท์ที่มีแบตเตอรี่ ให้มองว่ามันเป็นชั้นที่ย่นเวลาการรับทราบลงได้อย่างมาก ไม่ใช่มาตรการควบคุมที่คุณจะชี้ให้ผู้ตรวจสอบดูได้

พูดกันตรง ๆ คือ ภาระหน้าที่ตามกฎระเบียบของคุณไม่ได้เปลี่ยนไปเพราะแอปไหนโทรหาคุณ สิ่งที่สายโทรเปลี่ยนคือจำนวนชั่วโมงระหว่างที่เครื่องจักรตรวจพบกับที่คนตัดสินใจ และภายใต้นาฬิกา 4 ชั่วโมง ชั่วโมงเหล่านั้นคืองบเวลาเกือบทั้งหมด

คำถามที่พบบ่อย

การใช้ Echobell ทำให้เราปฏิบัติตาม DORA หรือ NIS2 ได้เลยไหม

ไม่ การปฏิบัติตามกฎเกณฑ์ขึ้นอยู่กับการกำกับดูแล กระบวนการจัดระดับ เอกสาร และการยื่นจริงต่อหน่วยงานกำกับดูแลหรือ CSIRT ของคุณ Echobell แค่ย่นช่องว่างระหว่างการตรวจพบกับการรับทราบของมนุษย์เท่านั้น มันเป็นปัจจัยนำเข้าหนึ่งของกระบวนการ ไม่ใช่ตัวกระบวนการ

นาฬิกา 4 ชั่วโมงของ DORA เริ่มเดินเมื่อไรกันแน่

เมื่อจัดระดับ ภายใต้ Delegated Regulation (EU) 2025/301 การแจ้งเบื้องต้นต้องยื่นภายในสี่ชั่วโมงนับจากจัดระดับเหตุการณ์ว่าร้ายแรง และไม่ว่ากรณีใดต้องไม่เกิน 24 ชั่วโมงนับจากวินาทีที่หน่วยงานรับรู้ นี่คือข้อจำกัดสองข้อที่แยกจากกันและคุณต้องทำให้ได้ทั้งคู่ ซึ่งเป็นเหตุผลว่าทำไมการตัดสินใจจัดระดับที่รวดเร็วจึงสำคัญพอ ๆ กับการแจ้งเตือนที่รวดเร็ว

การแจ้งเตือนล่วงหน้าตาม NIS2 ต้องมีรายละเอียดเหตุการณ์ครบถ้วนไหม

ไม่ต้อง มาตรา 23(4) ของ Directive (EU) 2022/2555 จงใจให้การแจ้งเตือนล่วงหน้าภายใน 24 ชั่วโมงเป็นข้อมูลชั่วคราว คือระบุว่าสงสัยหรือไม่ว่าเหตุการณ์เกิดจากการกระทำที่ผิดกฎหมายหรือมุ่งร้าย และมีความเป็นไปได้หรือไม่ว่าจะมีผลกระทบข้ามพรมแดน ส่วนภาพที่ครบถ้วนกว่านั้นต้องยื่นในการแจ้งเหตุการณ์ภายใน 72 ชั่วโมง และการวิเคราะห์สาเหตุรากอยู่ในรายงานฉบับสมบูรณ์อีกหนึ่งเดือนถัดมา

ระบบมอนิเตอร์ของเราส่งอีเมลหาวิศวกรที่อยู่เวร on-call อยู่แล้ว แค่นั้นยังไม่พออีกหรือ

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

ฝ่ายกำกับการปฏิบัติตามกฎเกณฑ์กับฝ่ายวิศวกรรมรับการแจ้งเตือนเดียวกันได้ไหม

ได้ แชร์ช่องแล้วทุกคนที่ติดตามจะได้รับทริกเกอร์ โดยแต่ละคนเลือกประเภทการแจ้งเตือนของตัวเอง รูปแบบที่พบบ่อยคือ วิศวกรที่อยู่เวร on-call ติดตามแบบโทรเข้า ส่วนเจ้าหน้าที่กำกับการปฏิบัติตามกฎเกณฑ์ที่อยู่เวรใช้แบบโทรเข้าสำหรับช่องเหตุการณ์ที่ต้องรายงาน และแบบสำคัญตามเวลาสำหรับเรื่องอื่น

สายจะทะลุโหมดห้ามรบกวนได้จริงไหม

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

ใช้ได้เฉพาะบน iOS ใช่ไหม

ไม่ใช่ Echobell มีให้ใช้ทั้งบน iOS และบน Android ผ่าน Google Play (ดูประกาศเปิดตัวเวอร์ชัน Android) พฤติกรรมของการแจ้งเตือนแบบสายโทรต่างกันไปในแต่ละแพลตฟอร์ม จึงควรทดสอบบนเครื่องที่ผู้ตอบสนองของคุณพกจริง

ควรใส่ข้อมูลอะไรลงใน payload ของ webhook

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

---

บทความที่เกี่ยวข้อง

• เหตุคลาวด์ล่มกลายเป็นเรื่องปกติใหม่: จะยังได้รับการแจ้งเตือนได้อย่างไร
• รับการแจ้งเตือนด้วยสายโทรเมื่อ API ของคุณล่ม
• Opsgenie สิ้นสุดอายุการใช้งาน: การปิดตัวปี 2027 และทางเลือกอื่น
• วิธีทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต
• คู่มือการเชื่อมต่อ Webhook
• คู่มือเรื่องเงื่อนไข