เราอยู่ตรงไหนของแผนที่#

บนแถบ 5 ขั้น คราวนี้ Run สว่าง

ชิ้นจิ๊กซอว์ที่ 8 พังตอนตีสาม คือเรื่องที่ 17 มองเห็นระบบ เรื่องที่ 18 ระบบล่มและรับมือเหตุ และเรื่องที่ 19 backup และกู้คืน

ชิ้นนี้ปิดช่วงที่ 2 เมื่อมีลูกค้าจริง

หัวใจของตอนนี้#

backup ที่ไม่เคยลองกู้ ไม่ใช่ backup และระบบต้องบอกเราก่อนลูกค้า

ทำไมเรื่องนี้สำคัญ?#

ตอน 7 กับ 8 ทำให้ทุก repo มีด่านและทางถอยแล้ว

แต่ทางถอยช่วยได้เฉพาะเรื่องที่เรารู้ทัน

ถ้าไม่มีสัญญาณเตือน เราจะรู้จากลูกค้า

ถ้า backup กู้ไม่ได้จริง ข้อมูลที่หายก็หายถาวร

ทางถอยของตอน 7 ถอย build ได้ แต่ถอยข้อมูลไม่ได้

หลัก 5 ข้อข้างล่างคือวิธีทำให้หัวใจข้อนี้เป็นจริง

03:12 ที่มิวทักมาก่อน#

ตีสามสิบสองนาที หน้าจองคิวของมิวตอบ 500 (ตัวอย่าง)

ต้นหลับอยู่ ไม่มี alert สักตัว

07:40 มิวส่ง LINE มาว่า “ระบบเข้าไม่ได้ตั้งแต่ตีสาม” (ตัวอย่าง)

ต้นเปิด log แล้วเจอว่า migration ตัวหนึ่งทำตารางเสียไปหนึ่งตาราง

เขาจะกู้จาก backup รายคืน

แล้วก็พบว่าไฟล์ dump มีขนาด 0 byte มา 3 สัปดาห์แล้ว (ตัวอย่าง)

ทุก repo มีกฎแล้ว แต่ไม่มีใครเฝ้า#

ทางถอยของตอน 7 สมมติว่ามีคนเห็นปัญหาก่อน

template ของตอน 8 ส่งกฎชุดเดียวกันให้ทุก repo

ตอนนี้ template ต้องส่ง alert ชุดเดียวกัน health check และลิงก์ไป runbook ไปด้วย

lauren (@poteto) เขียนไว้ ว่า “we rely on experiments, root causing, observability to deal with systems we don’t understand.”

ไม่มีใครเข้าใจระบบได้ทั้งหมด เราจึงต้องมีเครื่องมือที่บอกว่าตอนนี้เกิดอะไรขึ้น

หลัก 1: เตือนจากอาการที่ลูกค้าเห็น#

ถ้าระบบจะบอกเราก่อนลูกค้า มันต้องดูสิ่งที่ลูกค้าเห็น

Google SRE book เขียนไว้ ว่า “Your monitoring system should address two questions: what’s broken, and why?”

DORA เขียนไว้ ว่า “Good monitoring is a staple of high-performing teams”

ต้นเริ่มจาก alert แค่ 3 ตัว:

• health check ล้ม 2 ครั้งติด (ตัวอย่าง)
• error rate เกิน 2% นาน 5 นาที (ตัวอย่าง)
• backup job รันไม่จบ

เครื่องมือเป็นแค่ตัวอย่าง เช่น Sentry แผน Developer ราคา $0 และ “Limited to one user” ตามหน้าราคา

Chris Sev หัวหน้าทีม DevRel ที่ Auth0 เล่าไว้ ว่าเขาให้ agent “watching for PRs that merged and testing production to see if anything broke” และ “i have notifications on @sentry and @posthog”

หลัก 2: runbook หน้าเดียวที่เปิดตอนง่วงแล้วทำตามได้#

ระบบบอกเราแล้วยังไม่พอ ตอนตีสามเราต้องรู้ว่าจะทำอะไรก่อน

runbook ของต้นมี 5 ขั้น:

1. ดูอาการ จากลิงก์ dashboard และ log
2. ถอยก่อน แล้วค่อยหาสาเหตุ ใช้สูตรถอยของตอน 7
3. ถ้าข้อมูลเสีย หยุดการเขียนข้อมูล แล้วกู้ตามหลัก 3
4. แจ้งลูกค้า ด้วยข้อความที่เขียนไว้ล่วงหน้า
5. เปิด ticket สำหรับ postmortem

runbook บอกด้วยว่าใครทำอะไรได้ ใช้ตัวตนจากตอน 5 และทางด่วนจากตอน 7

หลัก 3: backup นับเมื่อกู้ได้จริงเท่านั้น#

นี่คือครึ่งแรกของประโยคในกล่องหัวใจ

AWS Well-Architected ข้อ REL09-BP04 เขียนไว้ ว่า “Perform periodic recovery of the data to verify backup integrity and processes”

และอธิบายว่า “Testing the recovery of the backups verifies that data can be restored when needed without having any worry that data might be missing or corrupted, that the restoration and recovery is possible within the RTO for the workload”

RTO คือกู้เสร็จในเวลาเท่าไหร่ RPO คือข้อมูลหายย้อนไปได้มากสุดแค่ไหน

database แบบ managed หลายเจ้ามี PITR เช่น Neon เขียนไว้ ว่า “instant restore capability, also known as point-in-time restore or PITR, you can restore a root branch to an earlier state”

ย้อนได้นานแค่ไหนขึ้นกับแผนที่ใช้ ต้องเช็กเอง

ทุกเดือนต้นทำ 4 อย่าง:

1. กู้ไปที่ branch ทดลอง ไม่แตะของจริง
2. นับแถวในตารางสำคัญ
3. เปิดแอปต่อกับ branch นั้น แล้วลอง login
4. จด RTO และ RPO ที่วัดได้จริงลงบันทึก

หลัก 4: ฝึกก่อนวันจริง#

runbook ที่ไม่เคยใช้ก็เหมือน backup ที่ไม่เคยกู้ เราไม่รู้ว่ามันใช้ได้

Google SRE book เขียนไว้ ว่า “SREs break our systems, watch how they fail, and make changes to improve reliability”

ต้นซ้อมทุกไตรมาส ครั้งละ 30 นาที (ตัวอย่าง)

เขาปิดแอป preview เอง เปิดจับเวลา แล้วทำตาม runbook ทีละขั้น

ขั้นไหนผิด เขาแก้ runbook ทันที

หลัก 5: postmortem ที่ไม่โทษใคร รวมถึง agent#

พังแล้วต้องไม่พังแบบเดิมซ้ำ ระบบถึงจะบอกเราได้เร็วขึ้นทุกครั้ง

Google SRE book เขียนไว้ ว่า “A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions”

และต้อง “must focus on identifying the contributing causes of the incident without indicting any individual or team”

ถ้า agent เป็นคนทำพลาด ผลของ postmortem คือกฎใหม่ ไม่ใช่การโทษ

Chris Sev เขียนไว้ ว่า “you should always be creating new instructions using pstack’s /correct so it doesnt happen again”

lauren ตอบเขา ว่า “yeah, codebase is memory!”

GitLab เองก็เปิด postmortem ให้ทุกคนอ่าน ตามลิงก์ด้านบน

runbook และบันทึกการกู้ของต้นหน้าตาเป็นยังไง?#

แถวหนึ่งใน runbook ของต้น (ตัวอย่าง):

แถวหนึ่งในบันทึกการลองกู้ (ตัวอย่าง):

ลองเล่นคืนเดิมใหม่ (ตัวอย่าง):

03:12 หน้าจองพัง

03:14 alert health check ดังที่โทรศัพท์ต้น

03:16 agent-ops หยุดการเขียนข้อมูล แล้วเปิด runbook ขั้น 3 (ตัวอย่าง)

03:25 ต้นกู้ตารางด้วย PITR ไปที่ branch ทดลอง ตรวจแล้วสลับใช้ ระบบกลับมา (ตัวอย่าง)

มิวตื่นมาเจอข้อความสั้นๆ ว่าเมื่อคืนระบบล่ม 13 นาที และแก้แล้ว

มาตรฐานว่ายังไง

ISO/IEC 29110 ระดับ Basic เขียนไว้ว่า “A disciplined management process that provides project visibility and corrective actions of project problems and deviations is performed.” เรื่องนี้อยู่ในกระบวนการ Project Management

ISO/IEC/IEEE 12207 มี operation และ maintenance อยู่ในกลุ่ม Technical processes และมี risk management อยู่ในกลุ่ม Technical management

ISO/IEC 27001 ก็มีเรื่อง backup และการรับมือ incident อยู่ในภาคผนวก

ผมเทียบเอง: บริษัทใหญ่มีเวร on-call และ DR site ต้นมี alert 3 ตัว runbook หน้าเดียว และการลองกู้เดือนละครั้ง แต่ตอบคำถามเดียวกันสามข้อ: รู้ทันไหม ทำอะไรก่อน และกู้ได้จริงไหม

จิ๊กซอว์ชิ้นที่เติมแล้ว#

ชิ้นที่ 8 เติมแล้ว ระบบบอกต้นก่อนลูกค้า และ backup ถูกพิสูจน์แล้วว่ากู้ได้

ชิ้นนี้ปิดช่วงที่ 2 เมื่อมีลูกค้าจริง

สิ่งที่ผมได้จากตอนนี้#

ถ้าต้นเริ่มใหม่#

ถ้าต้นเริ่มใหม่ เขาจะทำเรื่องนี้ตั้งแต่วันแรกไหม?

backup กับการลองกู้หนึ่งครั้ง: ทำ ก่อนมีลูกค้าจ่ายเงินคนแรก

alert 3 ตัว: ทำตั้งแต่วันแรก ใช้ราว 30 นาที ฿0 (ตัวอย่าง)

การซ้อมและ postmortem แบบเป็นทางการ: รอหลัง incident ครั้งแรก

ตอนต่อไป#

เช้าวันหนึ่ง บิลค่า API สูงกว่าปกติสิบเท่า (ตัวอย่าง)

agent ตัวหนึ่งวนทำงานซ้ำทั้งคืน และไม่มีอะไรหยุดมัน

ตอนหน้า บริษัทของต้นเริ่มโต และเราจะได้เพดานค่าใช้จ่ายกับปุ่มหยุดที่ใส่ไว้ใน runbook

คำถามที่พบบ่อย#

ผู้ให้บริการทำ backup ให้แล้ว ยังต้องลองกู้อีกไหม?

ต้อง GitLab มี backup ทุกวัน แต่คืนที่ต้องใช้กลับว่างเปล่า AWS เองก็แนะนำให้ลองกู้เป็นรอบ

ทำคนเดียว ต้องมี on-call ไหม?

ให้ alert เข้าโทรศัพท์ และเขียนไว้ว่าจะตอบลูกค้าภายในกี่ชั่วโมง ตอน 11 จะใส่เรื่องนี้ในเอกสาร support

agent แก้ incident เองได้ไหม?

ได้เฉพาะขั้นที่ runbook ให้ agent-ops ทำ การ restore ยังเป็นของต้น

postmortem ต้องเปิดเผยไหม?

ไม่จำเป็น แต่ข้อความสั้นๆ ถึงลูกค้าช่วยเรื่องความเชื่อใจ

Next → ภาค 2 ตอนที่ 10: agent ใช้เงินแทนเรา