SLA อัตราการทำงาน และขั้นตอนตรวจสอบเมื่อเกิดเหตุขัดข้อง

SLA อัตราการทำงาน เหตุขัดข้อง หน้าสถานะ
บทความนี้สำหรับใคร
สำหรับผู้รับผิดชอบการแยกแยะสาเหตุเมื่อแอปที่เชื่อมต่อในการใช้งาน production เกิดอาการ「ไม่ทำงาน」

เป้าหมายอัตราการทำงาน

แพลน เป้าหมายอัตราการทำงานต่อเดือน การรับประกัน SLA
Starter99.5% (best effort)ไม่มี
Growth99.9%มี
Enterprise99.95% ขึ้นไป (สัญญาเฉพาะราย)มี (มีค่าชดเชย)

หน้าสถานะ

ReceiptRoller เผยแพร่สถานะการทำงานผ่านหน้าสถานะสาธารณะ

https://status.receiptroller.io
  • API, Webhook, การอนุมัติ, พอร์ทัลนักพัฒนา และการเชื่อมต่อ SNS แต่ละตัวจะแสดงแยกกัน
  • ดูประวัติเหตุขัดข้องย้อนหลัง 90 วันได้
  • สมัครรับได้ผ่าน RSS / Webhook / อีเมล

เราแนะนำให้ทีมที่ใช้งาน production รวมหน้านี้เข้ากับบอร์ดเฝ้าติดตาม

ขั้นตอนการแยกแยะสาเหตุเมื่อเกิดเหตุขัดข้อง

ขั้นตอนที่ 1: แยกแยะว่าเป็นฝั่งเราหรือฝั่งภายนอก

  1. ฟังก์ชันอื่นของเรายังทำงานอยู่หรือไม่
  2. หน้าสถานะของ ReceiptRoller มีเหตุขัดข้องกับฟังก์ชันที่เกี่ยวข้องหรือไม่
  3. มีการ deploy ของเราเองในช่วงที่ผ่านมาหรือไม่

ขั้นตอนที่ 2: กรณีสงสัยว่าเป็นเหตุขัดข้องฝั่ง ReceiptRoller

  1. ตรวจสอบหน้าสถานะ
  2. เก็บ X-RR-Request-Id ของ request ในช่วง 5 นาทีที่ผ่านมา
  3. เก็บเนื้อหาของ error response (HTTP status, code, message)
  4. ตรวจสอบขอบเขตผลกระทบ (ทุก request ล้มเหลว / บางส่วนล้มเหลว / เฉพาะ endpoint บางตัว)

ขั้นตอนที่ 3: กรณีสงสัยว่าเป็น environment ของเราเอง

  1. พิจารณา rollback การ deploy ล่าสุด
  2. environment variable และ secret ถูกต้องหรือไม่
  3. เครือข่าย DNS TLS certificate
  4. สถานะของ DB แคช และ external API ปลายทาง

การยกระดับสู่ฝ่ายสนับสนุน

ระดับเบา (แยกแยะเองได้)

โพสต์ไปยังคอมมูนิตี้นักพัฒนา อาจได้ข้อมูลเชิงลึกจากนักพัฒนาคนอื่น

ระดับกลาง (แยกแยะสาเหตุเองไม่ได้)

ส่งอีเมลไปยังช่องทางฝ่ายสนับสนุน โปรดแนบข้อมูลต่อไปนี้เสมอ

  • ID ของแอป (client ID)
  • ช่วงเวลาที่เกิดเหตุ (ระบุ UTC หรือ JST ให้ชัดเจน)
  • API endpoint และ HTTP method ที่ได้รับผลกระทบ
  • request_id สองสามรายการ
  • เนื้อหาของ error response
  • สิ่งที่ตรวจสอบมาแล้วในฝั่งของคุณ

ระดับร้ายแรง (กระทบ production มาก)

แพลน Growth ขึ้นไปมีช่องทางฝ่ายสนับสนุนเร่งด่วน สำหรับ Enterprise มีช่อง Slack เฉพาะเป็นต้น

การรับมือเมื่อไม่เป็นไปตาม SLA

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

การแจ้งการบำรุงรักษาตามแผน

  • โดยหลักการเป็นการ deploy แบบ rolling ที่ไม่มีผลกระทบ
  • หากมีการเปลี่ยนแปลงขนาดใหญ่ จะแจ้งอย่างน้อย 14 วันล่วงหน้า
  • การแจ้งจะผ่านหน้าสถานะ ประกาศในพอร์ทัลนักพัฒนา และอีเมล

คู่มือที่เกี่ยวข้อง