แนวปฏิบัติที่ดีในการใช้งาน production

การใช้งาน production แนวปฏิบัติที่ดี การเฝ้าติดตาม การ deploy
บทความนี้สำหรับใคร
แนวทางปฏิบัติสำหรับทีมที่ต้องการใช้งานแอปที่เชื่อมต่อ ReceiptRoller บน production ได้อย่างเสถียร

แยก environment ออกเป็น 3 ชุด

environment วัตถุประสงค์ แอป RR
productionลูกค้าจริง ร้านค้าจริงแอป production
stagingตรวจสอบก่อนปล่อยขึ้น productionแอปสำหรับ staging
developmentการพัฒนาและทดสอบประจำวันแอปสำหรับพัฒนา (แยกรายบุคคลได้)

แยก secret, ฐานข้อมูล และ URL ออกจากกันทั้งหมด

การเฝ้าติดตาม (ขั้นต่ำ)

  • อัตราความสำเร็จของการเรียก API: เตือนเมื่อต่ำกว่า 99%
  • อัตราการถูกจำกัด rate limit: เตือนเมื่อเกิน 1%
  • อัตราความสำเร็จของการรับ Webhook: เตือนเมื่อต่ำกว่า 99%
  • การต่ออายุโทเคนล้มเหลว: แจ้งทันที
  • การตรวจสอบลายเซ็นล้มเหลว: เตือนหากเกิดขึ้นต่อเนื่อง
  • คิวประมวลผลค้าง: เตือนเมื่อเกินเกณฑ์

การ deploy

  • ทดสอบอัตโนมัติใน CI: ตรวจ type, unit test, API contract test
  • Canary: ปล่อยเวอร์ชันใหม่ให้ traffic บางส่วนก่อน
  • แผน rollback: ย้อนกลับไปเวอร์ชันก่อนด้วยคำสั่งเดียว
  • กลยุทธ์ migration: การเปลี่ยน DB schema ทำเป็น 2 ขั้น (เพิ่ม → ลบ) ในการปล่อย
  • feature flag: deploy ฟีเจอร์ใหม่โดยปิดไว้ แล้วค่อยสลับเปิดบน production

การติดตามเวอร์ชันฝั่ง ReceiptRoller

  • สมัครรับ「ประกาศ」ไว้
  • ออก log สำหรับ Sunset / Deprecation header เพื่อแจ้งเตือน
  • ทำ inventory การใช้ API ที่ไม่แนะนำในการรีวิวรายเดือน
  • เมื่อมี API เวอร์ชันใหม่ ให้ตรวจสอบล่วงหน้าใน staging

โครงสร้างพื้นฐานของการรับมือเหตุขัดข้อง

  1. ตรวจจับ: การแจ้งเตือนจากระบบเฝ้าติดตามดังขึ้น
  2. เริ่มดำเนินการ: ผู้รับผิดชอบ on-call เริ่มลงมือภายใน 15 นาที
  3. ระบุขอบเขตผลกระทบ: ใครและอะไรที่หยุดทำงาน
  4. รับมือชั่วคราว: rollback หยุดฟีเจอร์ หรือแก้ด้วยตนเอง
  5. แจ้ง: แจ้งร้านค้าและผู้ใช้ที่ได้รับผลกระทบ
  6. รับมือถาวร: แก้ที่ต้นเหตุ
  7. ทบทวน: postmortem (เพื่อปรับปรุง ไม่ใช่หาคนผิด)

รักษาเอกสารให้พร้อม

  • Runbook: ขั้นตอนรับมือเหตุขัดข้องที่พบบ่อย
  • แผนผังสถาปัตยกรรม: จุดเชื่อมต่อกับ ReceiptRoller
  • ผู้ติดต่อ: ช่องทางฝ่ายสนับสนุน ReceiptRoller และผู้ติดต่อภายในทีม
  • รายการ environment variable: ค่าคืออะไร ดึงมาจากไหน
  • ขั้นตอนกู้คืน: การกู้ DB การ rollback deploy การสร้าง secret ใหม่

บัญชีทดสอบและข้อมูลทดสอบ

  • สำหรับ E2E test ที่แตะ production ให้ใช้ร้านค้าทดสอบและผู้ใช้ทดสอบเฉพาะ
  • กำหนดหมายเลขบัตรเครดิตทดสอบและอีเมลทดสอบเป็นค่าคงที่
  • โดยหลักการห้ามทดสอบด้วยข้อมูล production (ความเสี่ยงด้านการจัดการข้อมูลส่วนบุคคล)

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

วันที่เผยแพร่: 2569-04-27 วันที่อัปเดต: 2569-07-05
กลับไปที่รายการวิธีใช้งาน
หมวดหมู่
ทั้งหมด ทั่วไป 14 Webhook 6 การแก้ปัญหา 6 การลงทะเบียนแอปพลิเคชัน 5 คู่มือตามประเภทข้อมูล 5 พื้นฐาน API 5 การดำเนินงานและความปลอดภัย 4 เริ่มต้นใช้งาน 4 การยืนยันตัวตนและข้อมูลรับรอง 3 คู่มือแยกตามโดเมนข้อมูล 3
แท็ก
API (22) OAuth (15) Android (10) iOS (9) Webhook (8) api (7) oauth (5) getting-started (4) การลงทะเบียนแอป (4) การแก้ปัญหา (4)