เขียน TOR ระบบอย่างไรให้ได้ระบบที่ดูแลต่อได้

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

ความต่างของสองคำถามนี้ไม่ปรากฏในวันตรวจรับ มันปรากฏในปีที่สาม ตอนที่คนที่เคยทำโครงการย้ายงานไปแล้ว และไม่มีใครในองค์กรตอบได้ว่าระบบ restore ข้อมูลกลับมาอย่างไร

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

เงื่อนไขที่หนึ่ง เอกสารสถาปัตยกรรมที่อ่านแล้วทำงานต่อได้

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

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

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

เงื่อนไขที่สอง สิทธิ์ในบัญชีผู้ให้บริการคลาวด์ต้องอยู่ในมือองค์กร

เรื่องนี้ฟังดูเป็นรายละเอียดทางธุรการ แต่เป็นเงื่อนไขที่กระทบความต่อเนื่องของระบบมากที่สุดในบรรดาสามข้อ

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

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

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

เงื่อนไขที่สาม ขั้นตอนกู้คืนที่ทดสอบแล้ว ไม่ใช่แค่การสำรองข้อมูล

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

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

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

ข้อจำกัดของสามข้อนี้

สามเงื่อนไขข้างต้นทำให้ขั้นตอนจัดซื้อช้าลง และทำให้ราคาที่ผู้พัฒนาเสนอสูงขึ้น เพราะงานที่เพิ่มขึ้นเป็นงานจริงที่ต้องใช้เวลา

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

สิ่งที่เราไม่แนะนำคือการเขียนครบทั้งสามข้อลงไปโดยไม่มีใครตั้งใจจะตรวจ

เงื่อนไขที่ไม่ถูกตรวจไม่ได้ช่วยอะไร และทำให้เอกสารยาวขึ้นเฉยๆ

สรุป

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

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

หากองค์กรของคุณกำลังอยู่ในขั้นร่างขอบเขตงาน และอยากให้มีคนช่วยอ่านทบทวนก่อนประกาศ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรงๆ