---
title: "การรายงานเหตุการณ์ตาม DORA และ NIS2: รับสายโทรเข้าก่อนเวลาจะหมด"
description: "DORA ให้เวลาคุณ 4 ชั่วโมงนับจากการจัดระดับ NIS2 ให้ 24 ชั่วโมงนับจากรับรู้ และไม่มีนาฬิกาเรือนไหนหยุดเดินตอนกลางคืน นี่คือวิธีส่งการแจ้งเตือนจากระบบตรวจจับให้กลายเป็นสายโทรเข้าที่ดังจริงด้วย Echobell"
date: 2026-07-31
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - การรายงานเหตุการณ์ตาม DORA
  - การรายงานเหตุการณ์ตาม NIS2
  - เส้นตายตามกฎระเบียบ
  - แจ้งเตือนด้วยสายโทรเข้า
  - การแจ้งเตือนทีม on-call
---

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

เส้นตายการรายงานเหตุการณ์ของสหภาพยุโรปทุกฉบับเริ่มนับจากสิ่งที่เครื่องจักรตรวจพบ และเดินหน้านับต่อไปขณะที่ทีมของคุณหลับอยู่ ถ้าการแจ้งเตือนที่เริ่มเดินนาฬิกามาถึงในรูปแบบพุชเงียบ ๆ เวลา 02:40 ของคืนวันอาทิตย์ คุณก็เผาเวลาไปแล้วหนึ่งในสี่ของกรอบเวลารายงานตาม DORA ก่อนที่มนุษย์คนแรกจะได้อ่านมันด้วยซ้ำ คู่มือนี้จะแสดงวิธีวางสายโทรเข้าที่ดังจริงไว้หน้าเวิร์กโฟลว์การรายงานของคุณด้วย [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-dora-nis2-incident-reporting-alerts-th&mt=8) เพื่อให้นาฬิกาและการตอบสนองของคุณเริ่มเดินไปพร้อม ๆ กัน

ตอนนี้ขนาดของปัญหาเป็นตัวเลขที่วัดได้แล้ว ไม่ใช่การคาดเดา เมื่อวันที่ 3 มิถุนายน 2026 หน่วยงานกำกับดูแลยุโรปทั้งสามแห่งเผยแพร่ภาพรวมทั่วสหภาพยุโรปฉบับแรกของเหตุการณ์ ICT ร้ายแรงที่รายงานภายใต้ DORA คือ **เหตุการณ์ร้ายแรง 3,383 ครั้ง** ในปี 2025 เฉลี่ย **0.18 ครั้งต่อสถาบันการเงิน** ที่อยู่ในขอบเขต โดย **ราวหนึ่งในสาม** มีผลกระทบข้ามพรมแดน ([EBA](https://www.eba.europa.eu/publications-and-media/press-releases/esas-publish-first-report-dora-major-ict-related-incidents), [ESMA](https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents)) รายละเอียดที่ควรกำหนดรูปแบบการแจ้งเตือนของคุณคือ มีเพียง **10%** เท่านั้นที่เกี่ยวข้องกับความมั่นคงปลอดภัยไซเบอร์ ตัวขับเคลื่อนหลักคือระบบล้มเหลวและเหตุการณ์ภายนอก

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

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

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

| ระเบียบ | เส้นตายแรก | จากนั้น | สุดท้าย |
| --- | --- | --- | --- |
| **DORA** (สถาบันการเงินในสหภาพยุโรป) | แจ้งเบื้องต้นภายใน **4 ชั่วโมง** นับจากจัดระดับเหตุการณ์ว่าร้ายแรง และไม่เกิน **24 ชั่วโมง** นับจากรับรู้เหตุการณ์ | รายงานระหว่างทางอย่างช้าที่สุด **72 ชั่วโมง** หลังการแจ้งเบื้องต้น | รายงานฉบับสมบูรณ์ไม่เกิน **หนึ่งเดือน** หลังรายงานระหว่างทาง (ฉบับล่าสุด) |
| **NIS2** (หน่วยงานจำเป็นและหน่วยงานสำคัญในสหภาพยุโรป) | แจ้งเตือนล่วงหน้าโดยไม่ชักช้าเกินควร และไม่ว่ากรณีใดต้องภายใน **24 ชั่วโมง** นับจากรับรู้เหตุการณ์ที่มีนัยสำคัญ | แจ้งเหตุการณ์ภายใน **72 ชั่วโมง** นับจากรับรู้ | รายงานฉบับสมบูรณ์ไม่เกิน **หนึ่งเดือน** หลังการแจ้งเหตุการณ์ |
| **SEC Item 1.05** (บริษัทจดทะเบียนในสหรัฐฯ) | โดยทั่วไปต้องยื่นแบบ 8-K ภายใน **สี่วันทำการ** หลังพิจารณาว่าเหตุการณ์มีสาระสำคัญ | — | — |

กรอบเวลาของ DORA มาจาก Commission Delegated Regulation (EU) 2025/301 ซึ่งเป็นมาตรฐานทางเทคนิคด้านเนื้อหาและกรอบเวลาของการรายงานเหตุการณ์ เผยแพร่เมื่อ 20 กุมภาพันธ์ 2025 เพื่อเสริม [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) ([คณะกรรมาธิการยุโรป](https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/implementing-and-delegated-acts/digital-operational-resilience-regulation_en), [ตัวบทมาตรา 5](https://www.springlex.eu/en/packages/dora/rts-ir-regulation/article-5/)) ส่วน DORA เองมีผลบังคับใช้ตั้งแต่ 17 มกราคม 2025 ([ESMA](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora))

กรอบเวลาของ NIS2 อยู่ในมาตรา 23(4) ของ [Directive (EU) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) โดยรัฐสมาชิกต้องอนุวัติภายใน 17 ตุลาคม 2024 ([คณะกรรมาธิการยุโรป](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive)) ส่วนเส้นตายของ SEC มาจากกฎการเปิดเผยข้อมูลด้านความมั่นคงปลอดภัยไซเบอร์ที่ประกาศใช้เมื่อ 26 กรกฎาคม 2023 ([SEC](https://www.sec.gov/newsroom/press-releases/2023-139))

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

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

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

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

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

**ช่วยได้นิดหน่อยภายใต้ DORA และมีโอกาสสูงว่าไม่ช่วยสำหรับคุณ** Delegated Regulation (EU) 2025/301 อนุญาตให้สถาบันการเงินที่มีเส้นตายตรงกับวันหยุดสุดสัปดาห์หรือวันหยุดธนาคารในรัฐสมาชิกของตน ยื่นได้ภายในเที่ยงของวันทำการถัดไป แต่มาตราเดียวกันก็ตัดสิทธิ์นี้ออกจากสถาบันสินเชื่อ คู่สัญญากลาง ผู้ดำเนินการศูนย์ซื้อขาย และหน่วยงานที่เป็นหน่วยงานจำเป็นหรือหน่วยงานสำคัญภายใต้ NIS2 หน่วยงานกำกับดูแลยังอาจยกเลิกสิทธิ์นี้สำหรับหน่วยงานอื่นที่มีความสำคัญเชิงระบบได้ด้วย ([มาตรา 5](https://www.springlex.eu/en/packages/dora/rts-ir-regulation/article-5/), [สรุปโดย Advisera](https://advisera.com/cdr-2025-301/time-limits-for-the-initial-notification-and-for-the-intermediate-and-final-reports/))

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

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

Echobell ทำอย่างเดียว คือเปลี่ยน webhook หรืออีเมลให้เป็นสายโทรเข้า สายที่ดังจริง สั่นจริง และทะลุโหมดโฟกัสกับโหมดห้ามรบกวนของ iOS ได้เหมือนสายจากคนในครอบครัว (ดู[การทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)) มันอยู่ระหว่างระบบที่ตรวจพบเหตุการณ์กับมนุษย์ที่ต้องเป็นคนเริ่มเดินนาฬิกา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- **จัดระดับเหตุการณ์** มันไม่มีความเห็นว่าเรื่องหนึ่งเป็น "ร้ายแรง" ตาม DORA "มีนัยสำคัญ" ตาม NIS2 หรือ "มีสาระสำคัญ" ตามกฎของ SEC หรือไม่ นั่นคือดุลพินิจที่คนของคุณต้องตัดสินโดยเทียบกับเกณฑ์ในตัวบทที่เกี่ยวข้อง
- **ยื่นเอกสารให้ใคร** มันไม่ได้ยื่นต่อหน่วยงานกำกับดูแล CSIRT หรือ SEC มันแค่พาให้มนุษย์มาถึงจุดที่ลงมือยื่นได้
- **ทำหน้าที่เป็นระบบเก็บบันทึกหรือระบบ GRC ของคุณ** ระเบียบเหล่านี้ต้องการเอกสาร ทะเบียน และหลักฐานที่แอปแจ้งเตือนผลิตให้ไม่ได้ Echobell จงใจเก็บเนื้อหาและประวัติการแจ้งเตือนไว้บนเครื่องของคุณเท่านั้น โดยมีเพียงข้อมูลบัญชี ช่อง และการติดตามอยู่บนเซิร์ฟเวอร์ ([แนวคิดด้านความเป็นส่วนตัว](/th/docs/features)) ซึ่งดีต่อการลดข้อมูลให้น้อยที่สุด แต่ใช้เป็นร่องรอยสำหรับตรวจสอบไม่ได้
- **มาพร้อมหนังสือรับรองการปฏิบัติตามกฎเกณฑ์** ไม่มีใบรับรอง รายงานการตรวจสอบ หรือ 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](/th/blog/echobell-android-release)) พฤติกรรมของการแจ้งเตือนแบบสายโทรต่างกันไปในแต่ละแพลตฟอร์ม จึงควรทดสอบบนเครื่องที่ผู้ตอบสนองของคุณพกจริง

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

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

---

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

- [เหตุคลาวด์ล่มกลายเป็นเรื่องปกติใหม่: จะยังได้รับการแจ้งเตือนได้อย่างไร](/th/blog/cloud-outage-alerts)
- [รับการแจ้งเตือนด้วยสายโทรเมื่อ API ของคุณล่ม](/th/blog/phone-call-alerts-api-downtime)
- [Opsgenie สิ้นสุดอายุการใช้งาน: การปิดตัวปี 2027 และทางเลือกอื่น](/th/blog/opsgenie-end-of-life-alternatives)
- [วิธีทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [คู่มือการเชื่อมต่อ Webhook](/th/docs/webhook)
- [คู่มือเรื่องเงื่อนไข](/th/docs/conditions)