ลองสมมติว่าฐานข้อมูลกลับมาเปิดได้หลังเกิดเหตุ แต่รายการที่ผู้ใช้บันทึกก่อนระบบหยุดหายไปบางส่วน ใครจะตรวจว่าขาดอะไร และระหว่างนั้นธุรกิจทำงานต่ออย่างไร? คำถามนี้หนักกว่าการขอฐานข้อมูลทดสอบไม่สำเร็จ เพราะมีงานจริงและข้อมูลที่สร้างใหม่ไม่ได้ตามใจเข้ามาเกี่ยวข้องแล้ว
ในตอนสาม ผมแยกการทดลองขยายบริการออกจากการอนุญาตให้ระบบงานจริงใช้บริการ คราวนี้สมมติว่าทีมผลิตภัณฑ์เดิมขอนำฐานข้อมูลของแอปพลิเคชันที่ใช้ทำงานจริงมาอยู่บนแพลตฟอร์ม คำขอนี้ต้องพิจารณาใหม่ แม้วิธีขอใช้จะเหมือนเดิมและการทดลองก่อนหน้าจะทำงานได้ก็ตาม
ทีม บริการ และเหตุการณ์ในบทความนี้เป็นกรณีสมมติต่อจากตอนก่อน ไม่มีผลทดสอบหรือผลใช้งานจริงขององค์กรใด ผมจะใช้กรณีนี้อธิบายว่า ก่อนรับงานจริง ต้องตกลงความเสียหายที่ยอมรับได้ และมีหลักฐานว่าคนกับระบบรับมือได้ในขอบเขตนั้น คำว่าใช้งานจริงหรือ production จึงผูกกับงานและเงื่อนไขที่ระบุ ไม่ใช่ป้ายรับรองทั้งแพลตฟอร์ม
เริ่มจากสิ่งที่ธุรกิจต้องทำต่อได้
ก่อนคุยว่าฐานข้อมูลควรอยู่บนเครื่องแบบไหน ผมอยากให้เจ้าของงานอธิบายว่าแอปพลิเคชันนี้ใช้ทำอะไร ช่วงใดหยุดไม่ได้ ถ้าอ่านข้อมูลได้แต่บันทึกไม่ได้ยังทำงานต่อได้หรือไม่ และมีข้อมูลส่วนใดที่สูญหายแล้วสร้างคืนไม่ได้ คำตอบจะเปลี่ยนทั้งวิธีกู้คืน ค่าใช้บริการ และจำนวนคนที่ต้องดูแล
จากนั้นจึงเขียนข้อตกลงบริการให้ผู้ใช้และผู้ดูแลเข้าใจตรงกัน เช่น รองรับการใช้งานและปริมาณงานลักษณะใด รับปัญหาช่วงไหน แจ้งเหตุผ่านช่องทางใด ใครมีสิทธิ์สั่งจำกัดการใช้งาน และใครตัดสินใจให้งานธุรกิจกลับมาเดินต่อ ถ้างานต้องมีคนรับเหตุนอกเวลาปกติ แต่แผนยังมีเพียงคนช่วยเมื่อว่าง ก็ต้องแก้ช่องว่างนั้นก่อนรับปากเปิดใช้
ฐานข้อมูลพร้อม แล้วใครยืนยันให้งานกลับมา?
- เจ้าของงานธุรกิจ
- ตกลงผลกระทบที่ยอมรับได้ วิธีทำงานชั่วคราว และเงื่อนไขให้งานกลับมาเดินต่อ
- ทีมแอปพลิเคชัน
- ตรวจการอ่านเขียน ความถูกต้องของรายการ และงานค้างที่ต้องประมวลผลต่อ
- ผู้ดูแลบริการแพลตฟอร์ม
- รับเหตุ ประสานการกู้คืน จัดการสิทธิ และส่งต่อพร้อมข้อมูลเมื่อเปลี่ยนคนดูแล
- ผู้ให้บริการเบื้องหลัง
- รับผิดชอบตามบริการและเงื่อนไขที่ซื้อ ต้องตรวจว่าใครกู้ส่วนใดและมีข้อจำกัดอะไร
ข้อตกลงนี้ควรบอกด้วยว่าบริการมาตรฐานครอบคลุมแค่ไหน และเมื่อใดต้องหารือเพิ่มเติม งานที่ใช้ข้อมูลอ่อนไหว ข้อกำหนดเก็บรักษาเฉพาะ หรือระบบที่เกี่ยวข้องหลายฝ่าย อาจต้องใช้วิธีดูแลต่างจากฐานข้อมูลที่รองรับอยู่ การรับข้อยกเว้นเพิ่มควรมีผู้รับภาระและงบรองรับด้วย
วัดงานที่ผู้ใช้ทำสำเร็จ
Google อธิบายใน Implementing SLOs ว่าตัวชี้วัดบริการควรสะท้อนประสบการณ์ของผู้ใช้ และเป้าหมายต้องเป็นสิ่งที่ผู้เกี่ยวข้องตกลงร่วมกันได้ เราเรียกค่าที่เลือกวัดว่า SLI ส่วน SLO คือเป้าหมายของค่านั้นในช่วงเวลาที่กำหนด
สำหรับบริการสมมติ ผมจะดูแยกกันระหว่างการขอฐานข้อมูลสำเร็จกับการที่แอปพลิเคชันอ่านเขียนได้ตามเงื่อนไข หน้าขอใช้ตอบกลับตามปกติอาจเกิดพร้อมกับการที่ผู้ใช้บันทึกงานไม่ได้ จึงต้องกำหนดให้ชัดว่าคำขอใดนับรวม วัดจากจุดไหน ความล้มเหลวแบบใดนับ และดูในช่วงเวลาใด ไม่หยิบตัวเลขความพร้อมของผู้ให้บริการมาเป็นผลของแอปพลิเคชันโดยตรง
SLO เป็นเป้าหมายสำหรับดูแลและตัดสินใจเรื่องบริการ การตั้งค่านี้ไม่ได้ทำให้เกิดคำรับประกันตามสัญญาโดยอัตโนมัติ และไม่ใช่คำสัญญาว่าระบบจะไม่หยุด ผมจะยังไม่ใส่เปอร์เซ็นต์ให้บริการสมมติ เพราะต้องรู้ความต้องการ ผลกระทบ และความสามารถที่ตรวจได้ก่อน หากเป้าหมายที่ธุรกิจต้องการเกินสิ่งที่ทีมดูแลไหว ก็ต้องคุยเรื่องทางเลือกหรืองบเพิ่มก่อนเปิดใช้
เลือกว่าจะกู้กลับไปถึงไหน และรอได้นานเท่าไร
อีกสองคำที่ต้องคุยให้ถึงผลกระทบจริง ได้แก่ RTO ซึ่งเป็นเป้าหมายเวลาหยุดสูงสุดที่ยอมรับได้จนกู้บริการกลับมา และ RPO ซึ่งเป็นเป้าหมายช่วงข้อมูลย้อนหลังสูงสุดที่ยอมให้สูญหายได้ โดยวัดเป็นเวลา แนวทาง AWS Well-Architected เรื่องเป้าหมายการกู้คืน ให้กำหนดจากความต้องการธุรกิจและตรวจว่าทำได้จริง รวมถึงสิ่งที่ระบบต้องพึ่งพา
ในกรณีสมมติ เจ้าของงานต้องร่วมเลือกว่าหยุดทำงานได้นานแค่ไหน และยอมเสียข้อมูลย้อนหลังได้เพียงใด บางงานอาจรอการกู้คืนได้นานกว่า แต่เสียรายการที่บันทึกแล้วไม่ได้ ความต้องการคนละแบบนี้ทำให้วิธีออกแบบและต้นทุนต่างกัน ไม่มีตัวเลขชุดเดียวที่เหมาะกับทุกระบบ
กู้ข้อมูลถึงจุดไหน เปิดงานได้เมื่อไร
- จุดข้อมูลที่กู้ได้จริงตรวจชุดสำรอง บันทึกต่อเนื่อง และกุญแจที่ต้องใช้ ว่ากู้กลับมารวมกันได้ถึงจุดใด
- เวลาที่เกิดเหตุตรวจช่วงเวลาจากจุดข้อมูลที่กู้ได้ถึงจุดเกิดเหตุ และรายการที่อาจขาดหาย แล้วเทียบกับ RPO ที่ตกลงไว้
- กู้และตรวจระบบที่เกี่ยวข้องนำข้อมูลกลับมา เชื่อมสิทธิและเครือข่าย ตรวจแอปพลิเคชัน รวมถึงรายการค้างหรือซ้ำ
- ยืนยันให้บริการกลับมาวัดเวลาหยุดถึงจุดที่กลับมาใช้งานได้ตามนิยาม แล้วเทียบกับ RTO ที่ตกลงไว้
ข้อความว่าสำรองข้อมูลสำเร็จยังไม่ตอบว่ากู้กลับมาได้ ผมจะให้ทดลองกู้ในพื้นที่แยกที่ควบคุมสิทธิ ใช้ข้อมูลสร้างขึ้นสำหรับทดสอบก่อน และตรวจให้ถึงการเปิดแอปพลิเคชันอ่านเขียนข้อมูลที่กู้มา หากต้องทดสอบกับข้อมูลจริง ต้องประเมินและอนุมัติการเข้าถึงตามขอบเขตของข้อมูลนั้นต่างหาก
การจับเวลาต้องนับสิ่งที่อยู่ในขอบเขตตกลงด้วย เช่น เวลาตรวจพบเหตุ ติดต่อผู้รับผิดชอบ จัดสิทธิ กู้ฐานข้อมูล และตรวจความถูกต้องของงาน ไม่เริ่มนับเฉพาะตอนกดคำสั่งกู้จนเสร็จ แล้วใช้แทนเวลาที่ธุรกิจต้องรอทั้งหมด ผลที่ได้จากข้อมูลขนาดเล็กก็ยังไม่ยืนยันว่าจะทำเวลาเดียวกันได้เมื่อข้อมูลและปริมาณงานจริงต่างออกไป
ให้เห็นเหตุที่ต้องลงมือ และเปลี่ยนระบบอย่างมีทางรับมือ
ระบบที่ต้องพึ่งพาอาจมีทั้งเครือข่าย ระบบยืนยันตัวตน ที่เก็บข้อมูล และบริการภายนอก การทดสอบเฉพาะฐานข้อมูลทำงานตามปกติจึงเหลือคำถามอีกมาก ผมจะเลือกจำลองเหตุที่สำคัญต่อกรณีนี้ในพื้นที่ที่แยกและอนุญาตไว้ เช่น แอปพลิเคชันเชื่อมฐานข้อมูลไม่ได้ หรือระบบยืนยันตัวตนใช้ไม่ได้ แล้วดูว่าผู้ใช้พบอะไร งานค้างอยู่ที่ไหน และคนรับเหตุตรวจต่อได้หรือไม่
ข้อมูลติดตามระบบต้องช่วยตอบคำถามนั้นได้ ตั้งแต่คำขอที่ล้มเหลวไปถึงเหตุที่เกี่ยวข้อง โดยไม่บันทึกข้อมูลลับลงไปเกินจำเป็น ส่วนการแจ้งเตือนควรส่งถึงคนที่รับผิดชอบและมีสิ่งให้ลงมือทำ แนวทาง Alerting on SLOs ของ Google เน้นการแจ้งเหตุที่กระทบเป้าหมายบริการอย่างมีนัยสำคัญ สำหรับทีมสมมติ ผมอยากตรวจต่อว่าคนรับสายรู้ว่าจะดูอะไร ทำอะไรได้เอง และต้องเรียกใครมาช่วย
งานเปลี่ยนระบบก็ต้องพิจารณาถึงข้อมูล การย้อนรุ่นแอปพลิเคชันอาจช่วยเมื่อโค้ดมีปัญหา แต่ถ้ารุ่นใหม่เปลี่ยนโครงสร้างฐานข้อมูลหรือตัดข้อมูลทิ้งไปแล้ว การย้อนโค้ดไม่ได้ย้อนข้อมูลกลับให้ด้วย จึงต้องตรวจความเข้ากันได้ของรุ่นเก่ากับโครงสร้างใหม่ ทดลองการย้ายข้อมูล และตกลงว่าจะหยุด แก้ต่อ หรือกู้ข้อมูลเมื่อเข้าเงื่อนไขใด รวมถึงผลต่อรายการที่เขียนหลังเปลี่ยนรุ่น
ก่อนรับข้อมูลจริงยังต้องแยกสิทธิของงานทดสอบ งานจริง ผู้ดูแล และบัญชีที่แอปพลิเคชันใช้ ตรวจว่าการเข้าถึงที่ไม่ควรได้ถูกปฏิเสธ และเมื่อถอนสิทธิแล้วมีผลจริง ขอบเขตเดียวกันนี้ต้องตามไปถึงชุดสำรอง บันทึกระบบ และพื้นที่ที่ใช้กู้คืนด้วย การแยกหน้าจอหรือแยกชื่อฐานข้อมูลอย่างเดียวไม่ได้ยืนยันว่าข้อมูลแยกจากกันแล้ว
ใช้หลักฐานตัดสินใจว่าจะย้ายงานเมื่อไร
การทบทวนก่อนรับระบบงานจริงควรอิงสถาปัตยกรรม ความเสี่ยง และกำลังของบริการนั้น แนวคิด Production Readiness Review ใน Evolving the SRE Engagement Model ช่วยให้เห็นงานตรวจด้านความน่าเชื่อถือก่อนรับดูแล ผมจะนำมาปรับเป็นการคุยร่วมกันของเจ้าของงาน ทีมแอปพลิเคชัน และผู้ดูแลบริการ โดยให้ทุกข้อที่ยังเปิดอยู่มีผู้รับผิดชอบ
ตารางต่อไปนี้เติมเป็นตัวอย่างบันทึกของทีมสมมติ เพื่อให้เห็นว่าหลักฐานควรเปลี่ยนการตัดสินใจอย่างไร ช่องที่ระบุว่ายังขาดเป็นเงื่อนไขที่แต่งขึ้นเพื่ออธิบาย ไม่ใช่ผลตรวจของแพลตฟอร์มที่ใช้งานอยู่
| เรื่องที่ตัดสิน | หลักฐานในตัวอย่างสมมติ | งานถัดไปและผู้รับผิดชอบ |
|---|---|---|
| การกู้คืน | มีรายงานว่าสำรองสำเร็จ แต่ยังไม่ได้ตรวจให้แอปพลิเคชันทำงานกับข้อมูลที่กู้มา | ผู้ดูแลบริการกับทีมแอปพลิเคชันทดลองกู้ ตรวจข้อมูลและงานค้าง แล้วเทียบผลกับ RTO/RPO ที่เจ้าของงานตกลง |
| การรับเหตุ | มีคนรับเหตุในเวลาทำงาน แต่งานที่เสนอใช้ต้องมีคนรับเหตุนอกเวลานั้นด้วย | ผู้รับผิดชอบงบและผู้ดูแลบริการตกลงกำลังคน คนรับช่วง และต้นทุนก่อนรับขอบเขตนี้ |
| การเปลี่ยนรุ่น | มีวิธีย้อนรุ่นแอปพลิเคชัน แต่ยังไม่ได้ตรวจเมื่อรุ่นใหม่เปลี่ยนโครงสร้างข้อมูล | ทีมแอปพลิเคชันกับผู้ดูแลบริการทดสอบความเข้ากันได้และทางแก้ข้อมูล ก่อนอนุญาตการเปลี่ยนชนิดนั้น |
| สิทธิและข้อมูล | แยกบัญชีงานทดสอบกับงานจริงไว้ในแบบ แต่ยังขาดผลทดสอบการปฏิเสธสิทธิและถอนสิทธิ | ผู้ดูแลสิทธิร่วมกับผู้รับผิดชอบข้อมูลตรวจผ่านช่องทางใช้งานจริง รวมชุดสำรองและพื้นที่กู้คืน |
| คำตัดสินรอบนี้ | ยังมีช่องว่างด้านการกู้คืนและการรับเหตุที่กระทบขอบเขตงานที่ขอ | ยังไม่ย้ายงานจริง ให้ทำการซ้อมในพื้นที่แยก ปิดช่องว่างสำคัญ แล้วเจ้าของงานกับผู้ดูแลทบทวนร่วมกัน |
ถ้าหลักฐานเพียงพอสำหรับขอบเขตที่ตกลงแล้ว การเปลี่ยนผ่านควรเริ่มจากงานที่จำกัดผลกระทบได้ พร้อมเงื่อนไขหยุด ผู้ตัดสินใจ และวิธีดูแลข้อมูลระหว่างหยุด กำหนดว่าจะสังเกตอะไรและกลับมาทบทวนเมื่อไร การซ้อมกู้คืนหนึ่งครั้งอาจตอบเรื่องที่เลือกซ้อม แต่ยังเหลือเหตุอื่น ปริมาณข้อมูลที่ต่างออกไป และการเปลี่ยนแปลงในอนาคตที่ต้องตรวจต่อ
ต้องกันกำลังสำหรับงานประจำด้วย ทั้งทรัพยากรเผื่อรองรับภาระที่คาดไว้ งานอัปเดต การซ้อมกู้ การทบทวนสิทธิ และคนรับเหตุ ถ้าแผนจ่ายเฉพาะค่าฐานข้อมูล แต่ไม่มีเวลาสำหรับงานเหล่านี้ ความรับผิดชอบก็จะกลับไปกองอยู่กับคนเดิมอีกครั้ง
สำหรับตัวอย่างในตาราง ผมจะยังไม่กำหนดวันย้ายงานจริงจนกว่าจะเห็นผลกู้คืนและตกลงคนรับเหตุได้ สิ่งที่อยากวางบนโต๊ะก่อนอนุมัติคือ งานใดจะเริ่มใช้ ข้อมูลใดเข้ามาได้ ใครรับเหตุ และหลักฐานใดรองรับว่าทีมรับความเสี่ยงของงานนั้นไหว หากยังตอบเรื่องหนึ่งไม่ได้ ให้ระบุงานที่ต้องทำกับคนรับผิดชอบไว้ให้ชัดก่อนกลับมาตัดสินใจ
ที่มาและขอบเขต
บทความใช้แนวคิดเรื่อง SLI/SLO การแจ้งเตือน และการทบทวนก่อนรับดูแลจากหนังสือ SRE ของ Google กับคำอธิบายเป้าหมายการกู้คืนของ AWS ที่ลิงก์ไว้ในเนื้อหา ส่วนสถานการณ์ การแบ่งบทบาท ภาพ ตาราง และข้อเสนอการตัดสินใจเป็นการประยุกต์ของผมกับกรณีสมมติ ไม่ใช่เกณฑ์รับรองหรือข้อกำหนดร่วมของแหล่งอ้างอิง การประเมินบริการจริงยังต้องตรวจเงื่อนไขผู้ให้บริการ ข้อมูล และความเสี่ยงของงานนั้นโดยตรง