เปิดใช้แล้ว จะรู้ได้อย่างไรว่าแพลตฟอร์มคุ้มที่จะดูแลต่อ

สมมติว่าทีมปิดช่องว่างเรื่องการกู้คืนและคนรับเหตุจากตอนสี่ได้แล้ว ตกลงขอบเขตกับเจ้าของงาน และเปิดให้แอปพลิเคชันหนึ่งใช้ฐานข้อมูลจริง ผ่านไปหนึ่งรอบงาน มีคนขอฐานข้อมูลเพิ่ม ค่าใช้บริการก็เพิ่มตาม คำถามคือ ผู้ใช้ทำงานได้ดีขึ้นพอที่จะคุ้มกับภาระที่ทีมต้องดูแลต่อหรือยัง

นี่เป็นสถานการณ์สมมติต่อจากเรื่องเดิม ไม่ใช่ผลเปิดใช้ของ Supaket หรือลูกค้ารายใด ตอนสี่จบที่การเลื่อนย้ายงานจริงเพื่อหาหลักฐานเพิ่ม บทความนี้ตั้งเงื่อนไขใหม่ว่าทีมทำงานส่วนนั้นแล้วและเปิดใช้ในขอบเขตที่ตกลงไว้ จึงมาดูการตัดสินใจหลังเปิดใช้

เริ่มจากงานที่ผู้ใช้ต้องทำให้จบ

สำหรับบริการฐานข้อมูล คำขอสร้างฐานข้อมูลที่สำเร็จบอกได้ว่าทางเข้าใช้งานได้ แต่ยังไม่บอกว่าแอปพลิเคชันอ่าน เขียน และทำงานธุรกิจต่อได้จริง ผมจะให้เจ้าของงานเลือกงานสำคัญสักอย่างที่ตรวจได้ เช่น บันทึกรายการแล้วเรียกกลับมาดูได้ถูกต้อง จากนั้นดูว่ารอบงานนั้นสำเร็จแค่ไหน ล่าช้าหรือสะดุดตรงใด และต้องให้ทีมแพลตฟอร์มช่วยหลังบ้านกี่ครั้ง

ดูทั้งคนที่เริ่มใช้แล้วกลับมาใช้ต่อและคนที่หยุดใช้ด้วย แต่ไม่เอาจำนวนล็อกอินหรือจำนวนฐานข้อมูลมาแทนคุณค่าของงาน คนอาจถูกกำหนดให้ใช้บริการนี้อยู่แล้ว ส่วนฐานข้อมูลที่สร้างทิ้งไว้ก็ทำให้ยอดดูสูงโดยไม่มีงานเกิดขึ้น ถ้าผู้ใช้เลี่ยงไปใช้วิธีอื่น ควรถามเหตุผลจากงานจริงก่อนตีความว่าแพลตฟอร์มสำเร็จหรือล้มเหลว

เมื่อนำรอบก่อนกับรอบหลังมาเทียบ ต้องดูงานประเภทใกล้กัน ในช่วงเวลาที่เทียบได้ และบอกด้วยว่ามีคนช่วยเป็นพิเศษหรือมีการเปลี่ยนแอปพลิเคชันพร้อมกันหรือไม่ ถ้าเวลารอของผู้ใช้สั้นลงเพราะผู้ดูแลคอยแก้ด้วยมือทุกคำขอ ผลนั้นมีคุณค่าสำหรับผู้ใช้ แต่ยังไม่ใช่หลักฐานว่าระบบดูแลง่ายขึ้น

ดูเงินที่จ่าย พร้อมงานที่ต้องรับผิดชอบ

ใบแจ้งหนี้มักเห็นค่าเครื่อง พื้นที่เก็บข้อมูล สำรองข้อมูล และเครือข่าย แต่อีกส่วนอยู่ในเวลาคนที่ตั้งค่า อัปเดต ตรวจสิทธิ ซ้อมกู้ รับเหตุ และช่วยผู้ใช้ ผมจะบันทึกสองส่วนนี้คนละหน่วย เงินที่จ่ายเป็นบาท เวลาคนเป็นชั่วโมงและความสามารถในการรับงานอื่นที่ต้องเลื่อน ไม่เอาชั่วโมงไปคูณอัตราค่าจ้างแล้วประกาศว่าเป็นเงินสดที่ประหยัดได้โดยไม่มีการเปลี่ยนค่าใช้จ่ายจริง

ค่าใช้จ่ายร่วม เช่น ระบบติดตามและคนเวร อาจแบ่งให้แต่ละบริการเพื่อเห็นต้นทุนรวมตามกติกาที่เปิดเผย แนวคิด Allocation ของ FinOps ช่วยเรื่องการกำหนดวิธีแบ่งต้นทุนร่วม ส่วน Unit Economics ชวนผูกต้นทุนกับหน่วยที่มีความหมายต่อธุรกิจ ไม่ใช่ดูยอดใช้ทรัพยากรอย่างเดียว สำหรับเรื่องนี้ หน่วยที่น่าคุยอาจเป็นงานที่แอปพลิเคชันทำจบตามนิยามเดียวกัน ไม่ใช่จำนวน API request ซึ่งหนึ่งงานอาจเรียกหลายครั้ง

ต้นทุนรวมที่แบ่งให้ดู กับเงินที่จะเพิ่มหรือลดจริงเมื่อเปลี่ยนขอบเขต เป็นคนละคำถาม ถ้ารับแอปพลิเคชันเพิ่ม ระบบติดตามที่ซื้อไว้แล้วอาจยังไม่ต้องจ่ายเพิ่ม แต่พื้นที่สำรอง งานทดสอบ และคนรับเหตุอาจเพิ่มทันที ถ้าจะเลิกบริการ ก็ยังตัดค่าใช้จ่ายร่วมทั้งก้อนออกจากงบไม่ได้โดยอัตโนมัติ ต้องดูว่าทรัพยากรหรือสัญญาใดเลิกจ่ายได้จริงเมื่อไร ต้นทุนที่จ่ายไปแล้วไม่ควรเป็นเหตุให้ฝืนดูแลต่อ

ถ้าจะดูต้นทุนต่อหนึ่งงานที่ทำจบ ให้รวมค่าใช้จ่ายของงานที่สำเร็จ งานที่ล้มเหลว และงานที่ต้องทำซ้ำในช่วงและขอบเขตเดียวกันไว้ฝั่งต้นทุน ส่วนฝั่งจำนวนงานให้นับเฉพาะงานธุรกิจที่จบตามนิยาม ไม่เอาครั้งที่ลองใหม่มาบวกเป็นงานเพิ่ม เวลาคนของงานเหล่านี้ต้องบันทึกคู่กันเป็นชั่วโมง ไม่บวกเข้ากับเงินบาท การเทียบต่างรอบต้องใช้กลุ่มงานที่ใกล้กันด้วย ตัวเลขลดลงก็ไม่ได้แปลว่าควรขยายเสมอ หากงานที่เพิ่มมีข้อมูลอ่อนไหวกว่า ต้องรับเหตุนอกเวลา หรือพึ่งคนเฉพาะทาง ภาระและความเสี่ยงอาจเพิ่มเร็วกว่าปริมาณงาน ถ้าต้นทุนต่อหน่วยสูงขึ้นก็ต้องดูสาเหตุ อาจเป็นการเพิ่มความพร้อมให้บริการที่จำเป็นกับงานจริง ไม่ใช่ความสูญเปล่าทุกกรณี

ประชุมรอบถัดไปเพื่อเลือกทำอะไร

ผมจะให้เจ้าของงาน ทีมแอปพลิเคชัน ผู้ดูแลแพลตฟอร์ม และคนรับผิดชอบงบดูข้อมูลช่วงเดียวกัน งานที่ทำจบ ปัญหาที่ผู้ใช้เจอ รายการค่าใช้จ่าย งานดูแลที่เกิดจริง และความต้องการที่ยังไม่รองรับ คุยทั้งคนที่ยังใช้และคนที่เลิกใช้ แล้วจบด้วยทางเลือกที่มีเจ้าของและวันกลับมาดูผล ไม่ใช้คะแนนรวมก้อนเดียวกลบเรื่องที่ต้องแก้

ถ้าปัญหากระทบความถูกต้องของข้อมูลหรือสิทธิในขอบเขตที่เปิดอยู่ ต้องจัดการความเสี่ยงนั้นทันทีตามผลกระทบ ไม่รอรอบทบทวนประจำ ส่วนคำขอขยายที่ดูน่าสนใจยังรอได้จนเห็นว่าใครรับงานเพิ่ม การประหยัดต่อหน่วยจากผู้ใช้เดิมไม่ได้รับรองว่าบริการชนิดใหม่จะถูกและดูแลง่ายเท่ากัน

การยุติก็ต้องเป็นงานที่มีเจ้าของ แจ้งเวลาและทางเลือกให้ผู้ใช้ ย้ายหรือส่งออกข้อมูลตามเงื่อนไข ตรวจสิทธิและชุดสำรองที่ยังต้องเก็บ ปิดทรัพยากรเมื่อปลอดภัย แล้วตรวจค่าใช้จ่ายครั้งเดียวของการย้ายและการช่วยผู้ใช้ รวมถึงภาระตามสัญญาที่เลิกจ่ายไม่ได้ ก่อนเทียบกับค่าใช้จ่ายที่จะลดจริงในรอบถัดไป การลบฐานข้อมูลอย่างเดียวไม่ได้ทำให้งานหรือความรับผิดชอบหายไป

ให้คำว่า “คุ้ม” มีเงื่อนไขที่กลับมาตรวจได้

บันทึกการตัดสินใจหนึ่งหน้าควรระบุขอบเขตงาน ช่วงข้อมูลที่ใช้ เหตุผลที่เลือก ทางเลือกที่ไม่เลือก ผู้รับผิดชอบ และวันตรวจอีกครั้ง คำถามที่อยากให้เจ้าของงานกับผู้ดูแลตอบร่วมกันคือ ถ้าดูแลบริการนี้ต่ออีกหนึ่งรอบ ผู้ใช้ยังทำงานใดได้เพราะเราดูแลบริการนี้ และใครรับภาระที่ตามมา ถ้าตอบไม่ได้ ก็ยังไม่ควรรับคำขอเพิ่มเพียงเพราะแพลตฟอร์มเปิดอยู่แล้ว

ที่มาและขอบเขต

แนวคิดเรื่องการแบ่งต้นทุนร่วมและต้นทุนต่อหน่วยอ้างอิง FinOps Allocation กับ FinOps Unit Economics ส่วนงานฐานข้อมูล ลำดับภาพ ตาราง และข้อเสนอการทบทวนเป็นการประยุกต์กับกรณีสมมติ ไม่ใช่ผลวัดหรือเกณฑ์ที่ FinOps รับรองให้แพลตฟอร์มนี้ ความคุ้มของบริการจริงต้องใช้ข้อมูลต้นทุน ผลงาน และข้อผูกพันขององค์กรนั้นเอง