การดูแลระบบ AWS
ข้อตกลงบริการดูแลระบบ AWS ควรครอบคลุมอะไรบ้าง
แนวทางกำหนดขอบเขตงาน แบ่งหน้าที่ และตรวจให้งานดูแล AWS ประจำวันมีผู้รับผิดชอบชัดเจน
1. กำหนดระบบและผลลัพธ์ที่ต้องการให้ชัด
สำหรับ SME ไทยที่กำลังขยายธุรกิจในอาเซียน การตกลงจ้างดูแลระบบ AWS ควรเริ่มจากระบบธุรกิจที่ต้องการให้ดูแล เช่น พอร์ทัลรับคำสั่งซื้อ ระบบคลังสินค้า หรือระบบรายงาน ระบุบัญชี AWS สภาพแวดล้อม ระบบที่เชื่อมต่อ และกลุ่มผู้ใช้ให้ครบ คำว่า “ดูแลคลาวด์ให้เรา” เพียงอย่างเดียวเปิดช่องให้แต่ละฝ่ายเข้าใจขอบเขตต่างกันได้มาก
ในบทความนี้ บริการดูแลระบบหมายถึงขอบเขตงานที่ตกลงกันสำหรับการดำเนินงานบน AWS เช่น ขอบเขตที่ธุรกิจหารือกับ BlissJunction เริ่มจากผลกระทบต่อธุรกิจว่าเมื่อระบบใช้งานไม่ได้ งานใดจะหยุด ใครได้รับผลกระทบ และช่วงการค้าใดต้องเตรียมตัวเป็นพิเศษ แล้วใช้คำตอบเหล่านี้จัดลำดับความสำคัญ
- ระบุเจ้าของระบบฝั่งธุรกิจและผู้ติดต่อด้านเทคนิคของแต่ละแอปพลิเคชัน
- ระบุสภาพแวดล้อมที่รวมอยู่ในงาน พร้อมบันทึกระบบของผู้ให้บริการรายอื่นและงานที่อยู่นอกขอบเขต
- ตกลงขั้นตอนเพิ่มประเทศ แอปพลิเคชัน หรือบัญชี AWS ใหม่เข้ามาในขอบเขตบริการ
2. ทำให้ทุกฝ่ายเห็นหน้าที่ของตนเอง
AWS ใช้โมเดลความรับผิดชอบร่วมกันด้านความปลอดภัย โดย AWS ดูแลความปลอดภัยของโครงสร้างพื้นฐานคลาวด์ ส่วนลูกค้ายังมีหน้าที่ที่แตกต่างกันตามบริการและการตั้งค่าที่ใช้ เมื่อมีผู้ให้บริการดูแลระบบเพิ่มเข้ามา จึงต้องระบุให้ชัดว่าผู้ให้บริการจะดำเนินงานส่วนใดแทนลูกค้า
จัดทำตารางง่าย ๆ ให้แต่ละแถวเป็นงานหนึ่งรายการ และแต่ละคอลัมน์ระบุผู้ลงมือทำ ผู้อนุมัติ และผู้ที่ต้องรับทราบ ครอบคลุมทั้งโค้ดแอปพลิเคชัน การตัดสินใจเกี่ยวกับข้อมูล และโครงสร้างพื้นฐาน จากนั้นลองไล่เหตุการณ์ที่มีโอกาสเกิดขึ้นจริงร่วมกัน เพื่อหาช่องว่างระหว่างทีมก่อนเกิดเหตุขัดข้อง
- การเปลี่ยนสิทธิ์เข้าถึงต้องระบุผู้ร้องขอ ผู้อนุมัติ ผู้ดำเนินการ และผู้ทบทวนสิทธิ์
- การติดตั้งแพตช์ควรแยกงานโครงสร้างพื้นฐานออกจากการทดสอบความเข้ากันได้ของแอปพลิเคชันและการอนุมัติขึ้นระบบ
- การติดต่อฝ่ายสนับสนุน AWS ต้องระบุผู้เปิดเคสและผู้จัดเตรียมหลักฐานจากแอปพลิเคชัน
3. ระบุงานประจำและหลักฐานการทำงาน
ขอบเขตงานที่นำไปใช้ได้ควรบอกทั้งสิ่งที่ต้องทำและหลักฐานว่างานเสร็จแล้ว “การเฝ้าติดตามระบบ” ควรระบุอาการที่ส่งผลต่อผู้ใช้ การแจ้งเตือนที่ต้องติดตาม และสิ่งที่ต้องทำเมื่อได้รับการแจ้งเตือน การเก็บตัวชี้วัดจำนวนมากมีประโยชน์จำกัดหากไม่มีผู้รับผิดชอบตอบสนอง
จัดทำตารางงานประจำให้ครอบคลุมการบำรุงรักษาที่ตกลงกัน การทบทวนสิทธิ์ ความจุระบบ และค่าใช้จ่าย บันทึกขั้นตอนทำงานในคู่มือปฏิบัติงานหรือ runbook พร้อมเงื่อนไขก่อนเริ่ม สิทธิ์ที่ต้องใช้ วิธีจัดการข้อผิดพลาด และการส่งต่อปัญหา สำหรับข้อมูลสำรอง ให้ตกลงระยะเวลาเก็บรักษาและทดสอบการกู้คืนเทียบกับเป้าหมายธุรกิจ ได้แก่ ระยะเวลาที่หยุดระบบได้และปริมาณข้อมูลที่ยอมสูญเสียได้
- บันทึกผลการสำรองข้อมูลและทดสอบเป็นระยะว่าข้อมูลที่กู้คืนกลับมาใช้งานได้จริง
- เก็บประวัติการบำรุงรักษา ข้อยกเว้นที่ยังไม่ปิด และงานถัดไปไว้ด้วยกัน
- ทบทวนค่าใช้จ่ายที่เปลี่ยนไปกับผู้มีอำนาจอนุมัติการปรับการตั้งค่าหรือรูปแบบการใช้งาน
4. ตกลงวิธีจัดการเหตุขัดข้องและการเปลี่ยนแปลง
การแจ้งเตือน เหตุขัดข้อง และคำขอเปลี่ยนแปลงต้องใช้วิธีจัดการต่างกัน กำหนดระดับความรุนแรงตามผลกระทบต่อธุรกิจ แล้วตกลงช่องทางติดต่อ เวลาบริการ ลำดับการส่งต่อปัญหา และการรายงานความคืบหน้า แยกความคาดหวังเรื่องการตอบรับออกจากการกู้คืน เพราะการรับทราบปัญหาไม่ได้แปลว่าระบบกลับมาใช้งานได้แล้ว
สำหรับงานที่วางแผนไว้ ให้ระบุผู้ประเมินความเสี่ยง ผู้อนุมัติ ผู้ทดสอบผล และผู้ตัดสินใจย้อนกลับการเปลี่ยนแปลง รวมถึงช่องทางจัดการงานเร่งด่วนเมื่อใช้ขั้นตอนอนุมัติปกติไม่ได้ ธุรกิจที่ให้บริการหลายประเทศในอาเซียนควรระบุเขตเวลาของช่วงบำรุงรักษาและภาษาที่ใช้รายงานสถานการณ์ด้วย
- ทดสอบลำดับการติดต่อและจัดให้มีผู้อนุมัติสำรอง
- แยกให้ชัดว่าผู้ให้บริการทำอะไรได้ทันที และงานใดต้องขออนุมัติก่อน
- ทบทวนเหตุขัดข้องสำคัญเพื่อระบุสาเหตุ ผู้รับผิดชอบงานติดตาม และกำหนดเสร็จ
5. ทำให้บริการตรวจสอบและส่งต่อได้
การทบทวนบริการควรช่วยให้เจ้าของธุรกิจตัดสินใจได้ ตรวจดูเหตุขัดข้องที่เกิดซ้ำ งานค้าง ผลทดสอบการกู้คืน ค่าใช้จ่ายที่เปลี่ยนไป และความเสี่ยงที่ต้องให้ธุรกิจพิจารณายอมรับ ระบุเจ้าของงานและวันที่ให้กับทุกประเด็นที่ยังไม่ปิด หากเดือนที่ปัญหาลดลงเกิดจากการใช้งานน้อยลง ก็ควรอธิบายบริบทนี้แทนการสรุปว่าการดูแลระบบดีขึ้น
ตกลงสิ่งที่ต้องส่งมอบเมื่อเปลี่ยนผู้ดูแลตั้งแต่เริ่มต้น ธุรกิจต้องเข้าถึงบัญชี AWS ประวัติการดำเนินงาน แผนผังระบบ และเอกสารการตั้งค่าตามที่ตกลงกันได้อย่างต่อเนื่อง กำหนดวิธีถอนสิทธิ์ระดับสูงและส่งต่องานที่ยังไม่เสร็จเมื่อเปลี่ยนบุคลากรหรือผู้ให้บริการ
- กำหนดรอบทบทวนให้เหมาะกับความสำคัญของระบบและความถี่ของการเปลี่ยนแปลง
- ขอหลักฐานงานที่เสร็จแล้วควบคู่กับข้อเสนอที่รอการตัดสินใจ
- ปรับตารางความรับผิดชอบทุกครั้งที่แอปพลิเคชันหรือทีมเปลี่ยนไป
6. สถานการณ์สมมติ: พอร์ทัลรับคำสั่งซื้อในอาเซียน
สมมติว่าผู้จัดจำหน่ายไทยรายหนึ่งกำลังเปิดพอร์ทัลตัวแทนจำหน่ายในมาเลเซียและเวียดนาม ทีมพัฒนารับผิดชอบการออกรุ่นแอปพลิเคชัน ผู้ให้บริการดูแลระบบรับผิดชอบโครงสร้างพื้นฐาน AWS ตามขอบเขตที่ตกลง และผู้จัดการฝ่ายปฏิบัติการขายเป็นเจ้าของกระบวนการสั่งซื้อ ตัวอย่างนี้ใช้ประกอบการวางแผน ไม่ใช่กรณีศึกษาลูกค้าหรือแพ็กเกจบริการที่ให้คำมั่นไว้
ก่อนเปิดใช้งาน ทีมซ้อมเหตุการณ์ส่งคำสั่งซื้อไม่สำเร็จ แม้โครงสร้างพื้นฐานจะทำงานปกติ แต่กฎตรวจสอบข้อมูลในแอปพลิเคชันอาจปฏิเสธคำสั่งซื้อ การซ้อมช่วยให้รู้ว่าใครรวบรวมบันทึกระบบ ใครตรวจโค้ด ใครแจ้งทีมขาย และใครอนุมัติการย้อนกลับ ข้อตกลงพร้อมใช้งานเมื่อทุกฝ่ายส่งต่องานเหล่านี้ได้โดยไม่ต้องคาดเดา
- เตรียมรายการระบบ ปฏิทินธุรกิจ และรายชื่อผู้ตัดสินใจก่อนหารือขอบเขตงาน
- ใช้ตัวอย่างงานประจำหนึ่งงาน เหตุขัดข้องหนึ่งเหตุ และการซ้อมกู้คืนหนึ่งครั้งทดสอบขอบเขตที่เสนอ
- สรุปช่องว่างที่ยังเหลือและมอบหมายผู้รับผิดชอบก่อนเริ่มบริการ