SLA อัตราการทำงาน และขั้นตอนตรวจสอบเมื่อเกิดเหตุขัดข้อง
SLA
อัตราการทำงาน
เหตุขัดข้อง
หน้าสถานะ
บทความนี้สำหรับใคร
สำหรับผู้รับผิดชอบการแยกแยะสาเหตุเมื่อแอปที่เชื่อมต่อในการใช้งาน production เกิดอาการ「ไม่ทำงาน」
สำหรับผู้รับผิดชอบการแยกแยะสาเหตุเมื่อแอปที่เชื่อมต่อในการใช้งาน production เกิดอาการ「ไม่ทำงาน」
เป้าหมายอัตราการทำงาน
| แพลน | เป้าหมายอัตราการทำงานต่อเดือน | การรับประกัน SLA |
|---|---|---|
| Starter | 99.5% (best effort) | ไม่มี |
| Growth | 99.9% | มี |
| Enterprise | 99.95% ขึ้นไป (สัญญาเฉพาะราย) | มี (มีค่าชดเชย) |
หน้าสถานะ
ReceiptRoller เผยแพร่สถานะการทำงานผ่านหน้าสถานะสาธารณะ
https://status.receiptroller.io
- API, Webhook, การอนุมัติ, พอร์ทัลนักพัฒนา และการเชื่อมต่อ SNS แต่ละตัวจะแสดงแยกกัน
- ดูประวัติเหตุขัดข้องย้อนหลัง 90 วันได้
- สมัครรับได้ผ่าน RSS / Webhook / อีเมล
เราแนะนำให้ทีมที่ใช้งาน production รวมหน้านี้เข้ากับบอร์ดเฝ้าติดตาม
ขั้นตอนการแยกแยะสาเหตุเมื่อเกิดเหตุขัดข้อง
ขั้นตอนที่ 1: แยกแยะว่าเป็นฝั่งเราหรือฝั่งภายนอก
- ฟังก์ชันอื่นของเรายังทำงานอยู่หรือไม่
- หน้าสถานะของ ReceiptRoller มีเหตุขัดข้องกับฟังก์ชันที่เกี่ยวข้องหรือไม่
- มีการ deploy ของเราเองในช่วงที่ผ่านมาหรือไม่
ขั้นตอนที่ 2: กรณีสงสัยว่าเป็นเหตุขัดข้องฝั่ง ReceiptRoller
- ตรวจสอบหน้าสถานะ
- เก็บ
X-RR-Request-Idของ request ในช่วง 5 นาทีที่ผ่านมา - เก็บเนื้อหาของ error response (HTTP status, code, message)
- ตรวจสอบขอบเขตผลกระทบ (ทุก request ล้มเหลว / บางส่วนล้มเหลว / เฉพาะ endpoint บางตัว)
ขั้นตอนที่ 3: กรณีสงสัยว่าเป็น environment ของเราเอง
- พิจารณา rollback การ deploy ล่าสุด
- environment variable และ secret ถูกต้องหรือไม่
- เครือข่าย DNS TLS certificate
- สถานะของ 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 วันล่วงหน้า
- การแจ้งจะผ่านหน้าสถานะ ประกาศในพอร์ทัลนักพัฒนา และอีเมล
คู่มือที่เกี่ยวข้อง
หมวดหมู่
แท็ก
API (22)
OAuth (15)
Android (10)
iOS (9)
Webhook (8)
api (7)
oauth (5)
getting-started (4)
การลงทะเบียนแอป (4)
การแก้ปัญหา (4)