29 เม.ย. 2568·3 นาที
วิธีสร้างเว็บแอปที่ติดตามการปฏิบัติตาม SLA อย่างแม่นยำ
เรียนรู้วิธีออกแบบและสร้างเว็บแอปที่ติดตามการปฏิบัติตาม SLA: กำหนดตัวชี้วัด เก็บอีเวนต์ คำนวณผล แจ้งเตือนเมื่อละเมิด และรายงานอย่างแม่นยำ
เรียนรู้วิธีออกแบบและสร้างเว็บแอปที่ติดตามการปฏิบัติตาม SLA: กำหนดตัวชี้วัด เก็บอีเวนต์ คำนวณผล แจ้งเตือนเมื่อละเมิด และรายงานอย่างแม่นยำ
การปฏิบัติตาม SLA หมายถึงการทำตามข้อสัญญาที่วัดผลได้ใน Service Level Agreement (SLA)—สัญญาระหว่างผู้ให้บริการกับลูกค้า งานของแอปคือการตอบคำถามง่าย ๆ พร้อมหลักฐาน: เราทำตามที่สัญญาไว้สำหรับลูกค้ารายนี้ ในช่วงเวลานี้หรือไม่?
เป็นประโยชน์ที่จะแยกสามคำที่เกี่ยวข้องออกจากกัน:
เว็บแอปติดตาม SLA ส่วนใหญ่เริ่มจากชุดตัวชี้วัดเล็ก ๆ ที่สัมพันธ์กับข้อมูลการปฏิบัติการจริง:
ผู้ใช้ต่างกันต้องการความจริงเดียวกัน แต่การนำเสนอแตกต่างกัน:
ผลิตภัณฑ์นี้เกี่ยวกับ การติดตาม หลักฐาน และการรายงาน: การเก็บสัญญาณ การใช้กฎที่ตกลงกัน และการสร้างผลลัพธ์ที่เป็นมิตรกับการตรวจสอบ มัน ไม่รับประกันประสิทธิภาพ; มันวัด—อย่างแม่นยำ สม่ำเสมอ และในรูปแบบที่คุณสามารถชี้แจงได้ในภายหลัง
ก่อนออกแบบตารางหรือเขียนโค้ด ให้ชัดเจนอย่างเจ็บปวดว่าคำว่า "การปฏิบัติตาม" หมายถึงอะไรสำหรับธุรกิจคุณ ปัญหาส่วนใหญ่ของการติดตาม SLA ไม่ใช่ปัญหาทางเทคนิค—แต่เป็นปัญหาข้อกำหนด
เริ่มจากการเก็บแหล่งข้อมูลความจริง:
จดกฎเหล่านี้เป็นกฎชัดเจน ถ้ากฎอธิบายไม่ได้ชัด มันคำนวณไม่ได้อย่างน่าเชื่อถือ
รายการ "สิ่งจริง" ที่ส่งผลต่อเลข SLA:
ระบุด้วยว่าใครต้องการอะไร: ทีมซัพพอร์ตต้องการความเสี่ยงละเมิดแบบเรียลไทม์ ผู้จัดการต้องการสรุปรายสัปดาห์ ลูกค้าต้องการสรุปที่เข้าใจง่าย (มักสำหรับหน้า status)
จำกัดขอบเขต เลือกชุดขั้นต่ำที่พิสูจน์ว่าระบบทำงาน end-to-end เช่น:
สร้างเช็คลิสต์หนึ่งหน้าเพื่อตรวจสอบภายหลัง:
ความสำเร็จเป็นแบบนี้: สองคนคำนวณเดือนตัวอย่างด้วยมือและแอปของคุณให้ผลตรงกันเป๊ะ
ตัวติดตาม SLA ที่ถูกต้องเริ่มจากโมเดลข้อมูลที่สามารถอธิบาย เหตุผล ว่าทำไมเลขจึงเป็นอย่างนั้น หากคุณไม่สามารถย้อนตัวเลขความพร้อมใช้งานรายเดือนกลับไปยังเหตุการณ์และกฎที่ใช้ได้ คุณจะเผชิญข้อพิพาทกับลูกค้าและความไม่แน่นอนภายใน
อย่างน้อยควรมีโมเดล:
ความสัมพันธ์ที่มีประโยชน์คือ: customer → service → SLA policy (อาจผ่าน plan). Incident และ event จะอ้างอิง service และ customer
บั๊กด้านเวลาเป็นสาเหตุอันดับหนึ่งของคณิตศาสตร์ SLA ผิดพลาด ให้เก็บ:
occurred_at เป็น UTC (timestamp พร้อมบริบทโซนเวลา)received_at (เมื่อระบบของคุณเห็นมัน)source (ชื่อมอนิเตอร์, integration, manual)external_id (เพื่อลบซ้ำจาก retries)payload (JSON ดิบสำหรับดีบักในอนาคต)ยังเก็บ customer.timezone (สตริง IANA เช่น America/New_York) เพื่อการแสดงผลและตรรกะชั่วโมงทำการ แต่ไม่ใช้เพื่อเขียนทับเวลาของเหตุการณ์
ถ้า SLA แบบเวลาในการตอบหยุดนอกชั่วโมงทำการ ให้ทำแบบจำลองปฏิทินอย่างชัดเจน:
working_hours ต่อลูกค้า (หรือภูมิภาค/บริการ): วันของสัปดาห์ + เวลาเริ่ม/เลิกholiday_calendar ที่เชื่อมโยงกับภูมิภาคหรือลูกค้า พร้อมช่วงวันที่และป้ายชื่อทำให้กฎเป็นข้อมูลที่เปลี่ยนได้เพื่อให้ ops ปรับปฏิทินได้โดยไม่ต้อง deploy
เก็บ อีเวนต์ดิบ ในตาราง append-only และเก็บ ผลลัพธ์ที่คำนวณแล้ว แยกต่างหาก (เช่น sla_period_result). แต่ละแถวผลลัพธ์ควรรวม: ขอบเขตช่วงเวลา, เวอร์ชันอินพุต (เวอร์ชันนโยบาย + เวอร์ชันเอนจิน), และการอ้างอิงไปยัง event IDs ที่ใช้ นี่ทำให้การคำนวณซ้ำปลอดภัยและให้ร่องรอยการตรวจสอบเมื่อมีคำถามจากลูกค้าว่า "คุณนับนาทีการล่มไหนบ้าง?"
ตัวเลข SLA ของคุณเชื่อถือได้เท่ากับอีเวนต์ที่คุณนำเข้า เป้าหมายคือเรียบง่าย: เก็บทุกการเปลี่ยนแปลงที่สำคัญ (เริ่มล่ม, รับทราบเหตุการณ์, คืนบริการ) พร้อม timestamp ที่สม่ำเสมอและบริบทเพียงพอเพื่อคำนวณการปฏิบัติตามภายหลัง
ทีมส่วนใหญ่มักดึงจากระบบผสม:
Webhooks มักดีที่สุดเพื่อความแม่นยำแบบเรียลไทม์และโหลดต่ำ: ระบบต้นทางส่งเหตุการณ์ไปยัง endpoint ของคุณ
Polling เป็นการสำรองที่ดีเมื่อไม่มี webhooks: แอปคุณดึงการเปลี่ยนแปลงเป็นช่วงๆ นับตั้งแต่ cursor ล่าสุด ต้องจัดการ rate-limit และตรรกะ "since" อย่างรอบคอบ
CSV import ช่วยในการเติมข้อมูลย้อนหลังและย้ายระบบ ให้ถือเป็นเส้นทางนำเข้าระดับหนึ่งเพื่อให้คุณสามารถประมวลผลประวัติได้โดยไม่ต้องใช้วิธีแก้ปัญหาเฉพาะ
ทำให้อินพุตทุกรูปเป็นรูป "event" ภายในเดียว แม้ว่าพื้นผิวต้นทางจะแตกต่าง:
event_id (required): เอกลักษณ์และคงที่ข้าม retries. ใช้ GUID ของต้นทางถ้ามี; มิฉะนั้นสร้าง hash แบบกำหนดได้source (required): เช่น datadog, servicenow, manualevent_type (required): เช่น incident_opened, incident_acknowledged, service_down, service_upoccurred_at (required): เวลาที่เหตุการณ์เกิดขึ้น (ไม่ใช่เวลาที่คุณได้รับ) พร้อมโซนเวลาreceived_at (system): เมื่อแอปของคุณนำเข้าservice_id (required): บริการที่เกี่ยวข้องกับ SLAincident_id (optional but recommended): เชื่อมหลายอีเวนต์เข้ากับเหตุการณ์เดียวattributes (optional): priority, region, customer segment, ฯลฯเก็บ event_id พร้อมข้อจำกัด unique เพื่อทำให้การนำเข้า idempotent: การ retry จะไม่สร้างรายการซ้ำ
ปฏิเสธหรือกักอีเวนต์ที่:
occurred_at ไกลไปในอนาคตservice_id ที่รู้จัก (หรือสร้าง workflow “unmapped” เฉพาะ)event_id ที่มีอยู่แล้ววินัยนี้ตอนแรกจะช่วยให้คุณไม่ต้องเถียงกันเรื่องรายงาน SLA ต่อมา—เพราะคุณจะชี้ไปยังอินพุตที่สะอาดและตรวจสอบได้
เอนจินคำนวณคือที่ซึ่ง "อีเวนต์ดิบ" กลายเป็นผลลัพธ์ SLA ที่คุณสามารถปกป้องได้ กุญแจคือต้องปฏิบัติราวกับบัญชี: กฎกำหนดได้ ผลลัพธ์ชัดเจน และมีร่องรอยการเล่นซ้ำได้
เปลี่ยนทุกอย่างเป็นสตรีมเรียงลำดับต่อหนึ่งเหตุการณ์ (หรือ per service-impact):
จากไทม์ไลน์นี้ ให้คำนวณระยะเวลาโดยการรวมช่วงเวลา ไม่ใช่หัก timestamp สองอันแบบลวกๆ
กำหนด TTFR เป็นเวลาที่คิดค่าบริการระหว่าง incident_start และ first_agent_response (หรือ acknowledged ขึ้นอยู่กับคำเขียนใน SLA). กำหนด TTR เป็นเวลาที่คิดค่าบริการระหว่าง incident_start และ resolved.
"เวลาที่คิดค่าบริการ" หมายถึงการตัดช่วงเวลาที่ไม่ควรถูกนับออก เช่น:
รายละเอียดการใช้งาน: เก็บฟังก์ชันปฏิทิน (ชั่วโมงทำการ, วันหยุด) และฟังก์ชันกฎที่รับไทม์ไลน์แล้วคืนช่วงเวลาที่ต้องคิดค่าบริการ
ตัดสินใจก่อนว่าคุณจะคำนวณแบบ:
สำหรับการล่มบางส่วน ให้ถ่วงน้ำหนักตามผลกระทบเฉพาะเมื่อสัญญาระบุไว้ มิฉะนั้นให้ถือว่า "degraded" เป็นประเภทการละเมิดแยกต่างหาก
การคำนวณแต่ละครั้งควรทำซ้ำได้ เก็บ:
เมื่อกฎเปลี่ยน คุณสามารถรันคำนวณซ้ำตามเวอร์ชันโดยไม่เขียนทับประวัติ—สำคัญสำหรับการตรวจสอบและข้อพิพาทลูกค้า
การรายงานคือจุดที่การติดตาม SLA จะสร้างความน่าเชื่อถือหรือถูกตั้งคำถาม แอปของคุณควรระบุอย่างชัดเจน ช่วงเวลาที่วัด นาทีที่ถูกนับ และ วิธีได้มาซึ่งตัวเลขสุดท้าย
สนับสนุนช่วงรายงานที่ลูกค้าใช้จริง:
เก็บช่วงเวลาเป็น explicit start/end timestamps (ไม่ใช่ "month = 3") เพื่อให้คุณสามารถเล่นซ้ำการคำนวณได้ในภายหลังและอธิบายผลลัพธ์
สับสนบ่อยๆ คือการนับตัวส่วนว่ารวมทั้งช่วงหรือเฉพาะ "เวลาที่มีสิทธิ์"
กำหนดสองค่าต่อช่วง:
แล้วคำนวณ:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
ถ้า eligible minutes อาจเป็นศูนย์ (เช่น บริการที่มอนิเตอร์เฉพาะชั่วโมงทำการและช่วงนั้นไม่มีเวลา) ให้กำหนดกฎล่วงหน้า: แสดง "N/A" หรือถือเป็น 100%—แต่ต้องสม่ำเสมอและมีเอกสาร
SLA ส่วนใหญ่ต้องการทั้งเปอร์เซ็นต์และผลลัพธ์แบบสองค่า
เก็บค่า "ระยะห่างไปสู่การละเมิด" (งบ downtime ที่เหลือ) เพื่อให้แดชบอร์ดเตือนก่อนขีดจำกัดจะถูกข้าม
สุดท้าย เก็บอินพุตดิบ (เหตุการณ์ที่นับ/ยกเว้นและการปรับแก้) เพื่อให้ทุกรายงานตอบว่า "ทำไมตัวเลขนี้ถึงเป็นอย่างนี้" ได้โดยไม่ต้องอ้างวาทกรรม
เอนจินคำนวณของคุณอาจสมบูรณ์แต่ก็ยังล้มเหลวถ้า UI ไม่ตอบคำถามพื้นฐาน: "ตอนนี้เรากำลังปฏิบัติตาม SLA หรือไม่ และทำไม?" ออกแบบแอปให้แต่ละหน้าขึ้นต้นด้วยสถานะชัดเจน แล้วให้คนลงลึกไปยังตัวเลขและเหตุการณ์ดิบที่สร้างมัน
Overview dashboard (สำหรับผู้ปฏิบัติการและผู้จัดการ). นำด้วยไทล์เล็ก ๆ ชุดหนึ่ง: compliance ของช่วงปัจจุบัน, ความพร้อมใช้งาน, การปฏิบัติตามเวลาในการตอบ, และ "เวลาที่เหลือก่อนการละเมิด" ถ้ามี ป้ายกำกับให้ชัดเจน (เช่น "Availability (this month)" แทนคำว่า "Uptime"). หากรองรับ SLA หลายรายการต่อหนึ่งลูกค้า ให้โชว์สถานะที่แย่ที่สุดก่อนและให้ผู้ใช้ขยายดู
Customer detail (สำหรับทีมบัญชีและการรายงานให้ลูกค้า). หน้าลูกค้าควอสรุปบริการทั้งหมดและชั้น SLA สำหรับลูกค้านั้น พร้อมสถานะผ่าน/เตือน/ล้มเหลวสั้น ๆ (เช่น "นับ 2 เหตุการณ์; นับ downtime 18 นาที"). เพิ่มลิงก์ไปยังหน้า status และการส่งออกรายงาน
Service detail (สำหรับการสืบสวนเชิงลึก). แสดงกฎ SLA ที่แน่นอน หน้าต่างการคำนวณ และการแจกแจงว่าตัวเลขปฏิบัติตามถูกสร้างขึ้นอย่างไร รวมถึงกราฟความพร้อมใช้งานตามเวลาและรายการเหตุการณ์ที่นับต่อ SLA
Incident timeline (สำหรับการตรวจสอบ). หน้ามุมมองเหตุการณ์เดียวควรแสดงไทม์ไลน์ของเหตุการณ์ (ตรวจพบ, รับทราบ, บรรเทา, แก้ไข) และ timestamp ใดถูกใช้สำหรับตัวชี้วัด "การตอบ" และ "การแก้ไข"
ทำให้ตัวกรองสอดคล้องกันในทุกหน้าจอ: ช่วงวันที่, ลูกค้า, บริการ, ชั้น, และ ความรุนแรง ใช้หน่วยเดียวกันทุกที่ (นาที vs วินาที; เปอร์เซ็นต์ด้วยทศนิยมเดียวกัน). เมื่อผู้ใช้เปลี่ยนช่วงวันที่ ให้ปรับทุกตัวชี้วัดบนหน้าเพื่อไม่ให้เกิดความไม่ตรงกัน
เมตริกสรุปแต่ละรายการควรมีเส้นทาง "ทำไม?":
ใช้ tooltip อย่างประหยัดเพื่อคำนิยามคำว่า "Excluded downtime" หรือ "ชั่วโมงทำการ" และแสดงข้อความกฎเต็มบนหน้าบริการเพื่อไม่ให้คนคาดเดา
ใช้ภาษาธรรมดาแทนคำย่อ (“Response time” แทน “MTTA” เว้นแต่ผู้ชมคาดหวัง) สำหรับสถานะ ให้ผสมสีและป้ายข้อความ (เช่น "At risk: ใช้งบผิดพลาด 92% แล้ว") เพื่อหลีกเลี่ยงความคลุมเครือ ถ้าแอปของคุณรองรับ audit logs ให้เพิ่มกล่องเล็ก ๆ "Last changed" บนกฎ SLA และเชื่อมไปยัง /settings/audit-log เพื่อให้ผู้ใช้ตรวจสอบการเปลี่ยนแปลงได้
การแจ้งเตือนคือจุดที่แอปติดตาม SLA หยุดเป็นรายงานพาสซีฟและเริ่มช่วยทีมหลีกเลี่ยงค่าปรับ การแจ้งเตือนที่ดีที่สุดมาทันเวลา ระบุชัด และปฏิบัติได้—หมายถึงบอกคนว่าต้องทำอะไรต่อ ไม่ใช่แค่ว่า "แย่"
เริ่มด้วยสามประเภททริกเกอร์:
ทำให้ทริกเกอร์กำหนดค่าได้ต่อลูกค้า/บริการ/SLA เพราะสัญญาต่างกันทนต่อความผิดพลาดคนละระดับ
ส่งการแจ้งเตือนไปยังที่ที่คนตอบจริง:
การแจ้งเตือนแต่ละครั้งควรรวม deep links เช่น /alerts, /customers/{id}, /services/{id}, และหน้าเหตุการณ์หรือรายละเอียดเพื่อให้ผู้ตอบยืนยันตัวเลขได้เร็ว
ทำ deduplication โดยการจัดกลุ่มการแจ้งเตือนด้วยคีย์เดียวกัน (customer + service + SLA + period) และกดการแจ้งซ้ำในช่วง cooldown
เพิ่ม quiet hours ตามโซนเวลาทีมเพื่อให้การแจ้งเตือน "ใกล้จะละเมิด" ที่ไม่สำคัญรอจนชั่วโมงทำการ ในขณะที่ "เกิดการละเมิด" สามารถข้าม quiet hours ได้หากรุนแรง
รองรับ escalation rules (เช่น แจ้ง on-call หลัง 10 นาที, เลื่อนให้ผู้จัดการหลัง 30 นาที) เพื่อป้องกันการค้างในกล่องจดหมายเดียว
ข้อมูล SLA มีความอ่อนไหวเพราะอาจเปิดเผยประสิทธิภาพภายในและสิทธิ์เฉพาะลูกค้า ให้ปฏิบัติการควบคุมการเข้าถึงเป็นส่วนหนึ่งของ "คณิตศาสตร์" SLA: เหตุการณ์เดียวกันอาจให้ผลการปฏิบัติตามต่างกันขึ้นกับ SLA ของลูกค้าที่ใช้
เก็บบทบาทให้เรียบง่าย แล้วค่อยขยายเป็นสิทธิ์ละเอียดขึ้น
ค่าเริ่มต้นปฏิบัติเหมาะคือ RBAC + tenant scoping:
กำหนดชัดเจนเกี่ยวกับข้อมูลเฉพาะลูกค้า:
เริ่มด้วย email/password และบังคับ MFA สำหรับบทบาทภายใน วางแผนรองรับ SSO ในภายหลัง (SAML/OIDC) โดยแยกตัวตน (who they are) ออกจากการอนุญาต (what they can access). สำหรับ integrations ให้ใช้ API keys ผูกกับบัญชีบริการที่มีสโคปแคบและรองรับการหมุนเวียนคีย์
เพิ่ม audit entries ที่ไม่เปลี่ยนแปลงสำหรับ:
เก็บ ใคร, อะไรเปลี่ยน (ก่อน/หลัง), เมื่อไร, ที่ไหน (IP/user agent), และ correlation ID. ทำให้บันทึกค้นหาและส่งออกได้ (เช่น /settings/audit-log)
แอปติดตาม SLA มักไม่ทำงานโดดเดี่ยว คุณจะต้องมี API ที่ให้มอนิเตอร์ ตั๋ว และเวิร์กโฟลว์ภายในสร้างเหตุการณ์ ดันอีเวนต์ และดึงรายงานโดยอัตโนมัติ
ใช้ base path ที่มีเวอร์ชัน (เช่น /api/v1/...) เพื่อพัฒนาพารามิเตอร์โดยไม่ทำลายการรวมระบบเดิม
Endpoint สำคัญที่ครอบคลุมกรณีใช้งานส่วนใหญ่:
POST /api/v1/events สำหรับนำเข้าการเปลี่ยนสถานะ (up/down, ตัวอย่าง latency, หน้าต่างบำรุงรักษา). GET /api/v1/events สำหรับการตรวจสอบและดีบักPOST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidentsGET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} เพื่อจัดการสัญญาและ thresholdsGET /api/v1/reports/sla?service_id=...&from=...&to=... สำหรับสรุปการปฏิบัติตามPOST /api/v1/alerts/subscriptions เพื่อจัดการ webhook/email targets; GET /api/v1/alerts สำหรับประวัติการแจ้งเตือนเลือก convention เดียวและใช้ทั่วทั้ง API เช่น: limit, pagination แบบ cursor, พร้อมตัวกรองมาตรฐานอย่าง service_id, sla_id, status, from, และ to. ทำให้การเรียงลำดับคาดเดาได้ (เช่น sort=-created_at)
ส่งข้อผิดพลาดแบบมีโครงสร้างด้วยฟิลด์คงตัว:
{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }
ใช้ HTTP statuses ชัดเจน (400 validation, 401/403 auth, 404 not found, 409 conflict, 429 rate limit). สำหรับการนำเข้าอีเวนต์ พิจารณา idempotency (Idempotency-Key) เพื่อให้ retries ไม่สร้างเหตุการณ์ซ้ำ
ใช้ rate limits ที่เหมาะสมต่อ token (และเข้มงวดขึ้นสำหรับ endpoints การนำเข้า), ล้าง input, และตรวจสอบ timestamp/zone. ให้ใช้โทเค็น API แบบสโคป (อ่านอย่างเดียวสำหรับรายงาน vs เขียนเหตุการณ์) และบันทึกว่าใครเรียก endpoint ไหนเพื่อการตรวจสอบ (รายละเอียดในส่วน audit log ที่ /blog/audit-logs)
ตัวติดตาม SLA ตอบคำถามเดียวด้วยหลักฐาน: คุณทำตามข้อผูกพันตามสัญญาสำหรับลูกค้าและช่วงเวลาที่ระบุหรือไม่?
ในทางปฏิบัติ หมายถึงการรับสัญญาณดิบ (มอนิเตอร์, ตั๋ว, การอัพเดตด้วยมือ), นำกฎของลูกค้ามาใช้ (ชั่วโมงทำการ, ข้อยกเว้น) และผลิตผลลัพธ์ที่อ่านตรวจสอบได้เป็น pass/fail พร้อมรายละเอียดประกอบ
ให้ใช้:
แยกแบบจำลองเหล่านี้ออกจากกันเพื่อให้คุณปรับปรุงความน่าเชื่อถือ (SLO) โดยไม่ไปเปลี่ยนการรายงานเชิงสัญญา (SLA)
MVP ที่ดีมักจะติดตาม 1–3 ตัวชี้วัด ครบจุดสิ้นสุดถึงปลายทาง:
ตัวชี้วัดเหล่านี้เชื่อมกับแหล่งข้อมูลจริงได้ชัดเจนและบังคับให้คุณทำส่วนยาก ๆ เช่น ช่วงเวลา ปฏิทิน และข้อยกเว้นตั้งแต่ต้น
ความล้มเหลวมักมาจากกฎที่ไม่ได้ระบุไว้ จงรวบรวมและจดไว้:
ถ้ากฎใดอธิบายไม่ชัด อย่าพยายามเดาในโค้ด—ให้ถือเป็นประเด็นต้องชี้แจงก่อน
เริ่มด้วยเอนทิตีที่เรียบง่าย ชัดเจน และน่าเบื่อ:
มุ่งสู่ความสามารถในการตรวจสอบ: ทุกตัวเลขที่รายงานควรลิงก์กลับไปยัง และ ที่ใช้
จัดเก็บเวลาอย่างถูกต้องและสม่ำเสมอ:
occurred_at เป็น UTC พร้อมบริบทโซนเวลาreceived_at (เมื่อระบบของคุณเห็นเหตุการณ์)แล้วทำให้ช่วงเวลารายงานเป็น explicit (start/end) เพื่อให้คุณสามารถทำซ้ำรายงานได้แม้ข้ามการเปลี่ยน DST
ทำให้ทุกอย่างเป็นรูปแบบ event ภายในเดียวกันที่มี ID คงที่:
event_id (unique, คงที่เมื่อ retry)source, event_type, , คำนวณระยะเวลาโดยการ รวมช่วงเวลา บนไทม์ไลน์ ไม่ใช่การลบ timestamp สองตัวโดยตรง
กำหนด "เวลาที่คิดค่าบริการ" โดยตัดช่วงเวลาที่ไม่ควรถูกนับออก เช่น:
เก็บช่วงเวลาที่ได้มาและรหัสเหตุผลเพื่ออธิบายอย่างชัดเจนว่าถูกนับเพราะเหตุใด
ติดตามตัวประกอบสองค่าอย่างชัดเจน:
แล้วคำนวณ:
availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes
ถ้า eligible minutes เป็นศูนย์ ให้กำหนดนโยบายล่วงหน้า (เช่น แสดง "N/A" หรือถือเป็น 100%) และนำไปใช้สม่ำเสมอ
ทำให้ UI ตอบคำถาม "เรากำลังปฏิบัติตาม SLA ตอนนี้หรือไม่ และทำไม" ในหนึ่งสายตา:
สำหรับการแจ้งเตือน ให้เน้นทริกเกอร์ที่ปฏิบัติได้: ใกล้จะละเมิด, เกิดการละเมิด, และการละเมิดซ้ำ—แต่ละรายการให้ลิงก์ไปยังหน้าที่เกี่ยวข้อง เช่น /customers/{id} หรือ /services/{id}
occurred_atservice_idincident_id และ attributes เป็น optionบังคับ idempotency ด้วยข้อจำกัด unique บน event_id. สำหรับ mapping ที่หายไปหรือการมาถึงนอกลำดับ ให้กัก/quarantine หรือตั้งธงตรวจสอบ—อย่าแก้ข้อมูลเงียบ ๆ