วันที่เวนเดอร์หายไป ระบบไม่ได้หยุดตาม ผู้ใช้ยังล็อกอินทุกเช้า ลูกค้ายังจ่ายเงินผ่านระบบ และจะมีคนถามคุณว่า “ถ้าพังขึ้นมา ใครแก้”
บทความนี้คือลำดับงานที่เราใช้เมื่อรับช่วงระบบต่อจากทีมอื่น เขียนให้คนที่ไม่ได้เป็นนักพัฒนาทำตามได้ ข้อสำคัญคือทำตามลำดับ เพราะงานในสัปดาห์แรกทำให้งานที่เหลือเป็นไปได้
- 1 สัปดาห์ที่ 1: กุญแจและข้อมูลสำรอง ทุกบัญชีอยู่ในชื่อองค์กร และลองกู้ข้อมูลสำรองได้จริงหนึ่งครั้ง
- 2 สัปดาห์ที่ 2: แผนที่ระบบ สรุปหนึ่งหน้า ระบบมีกี่ส่วน ข้อมูลอยู่ไหน ค่าใช้จ่าย และอะไรต่ออายุเมื่อไร
- 3 สัปดาห์ที่ 3: ความเสี่ยง ความปลอดภัย PDPA และดูว่ามีชุดทดสอบกับวิธี deploy หรือยัง
- 4 สัปดาห์ที่ 4: ตัดสินใจ แยกระบบเป็นสามกองก่อน แล้วค่อยคุยเรื่องทำใหม่
สัปดาห์ที่ 1: เอาสิทธิ์การเข้าถึงกลับมาไว้ในมือ
ทุกอย่างเริ่มจากคำถามเดียว คือใครถือกุญแจ ทำรายการบัญชีทั้งหมดที่ระบบต้องใช้ แล้วดูว่าแต่ละบัญชีอยู่ในชื่อใคร
- โดเมนและ DNS ถ้าโดเมนหมดอายุ ทุกอย่างหยุดพร้อมกัน ดูวันหมดอายุไว้ด้วย
- คลาวด์หรือโฮสติ้ง ที่ระบบรันอยู่ และบัตรเครดิตที่ผูกไว้
- Repository ของซอร์สโค้ด เช่น GitHub หรือ GitLab
- บัญชีนักพัฒนาบน App Store และ Google Play ถ้ามีแอปมือถือ
- LINE OA และ LINE Developers ถ้ามีระบบบน LINE
- บริการอื่นที่ระบบเรียกใช้ เช่น ระบบส่งอีเมล ระบบชำระเงิน หรือ SMS
บัญชีไหนอยู่ในชื่อองค์กรแล้ว ให้เปลี่ยนรหัสผ่าน เปิดการยืนยันตัวตนสองชั้น และตั้งเจ้าของฝั่งคุณอย่างน้อยสองคน บัญชีไหนอยู่ในชื่อเวนเดอร์หรือพนักงานของเวนเดอร์ ให้ขอโอนเข้าชื่อองค์กรเป็นลายลักษณ์อักษร ส่วนใหญ่ทำได้โดยไม่ต้องย้ายระบบ ทั้ง repository แอปบน App Store และแอปบน Google Play ล้วนมีขั้นตอนโอนไปยังบัญชีอื่นได้
- 1 อยู่ในชื่อเวนเดอร์ บัญชีที่เวนเดอร์หรือพนักงานของเวนเดอร์ถือไว้
- 2 ขอโอนเป็นลายลักษณ์อักษร ทำหนังสือขอโอนทีละบัญชีเข้าชื่อองค์กร
- 3 อยู่ในชื่อองค์กร เปลี่ยนรหัสผ่าน เปิดยืนยันตัวตนสองชั้น และมีเจ้าของฝั่งคุณสองคน
งานอีกอย่างของสัปดาห์นี้คือ สำรองข้อมูลทันที อย่าเชื่อว่ามีข้อมูลสำรองอยู่แล้วจนกว่าจะได้เห็นไฟล์ และได้ลองกู้คืนลงเครื่องแยกจริงๆ สักครั้ง
สัปดาห์ที่ 2: ทำแผนที่ระบบ
ตอนนี้คุณเข้าระบบได้แล้ว ขั้นต่อไปคือรู้ว่ามีอะไรอยู่ตรงไหน เขียนสรุปหนึ่งหน้าว่า
- ระบบมีกี่ส่วน ทำงานที่ไหน และคุยกันอย่างไร
- ข้อมูลอยู่ที่ไหน โดยเฉพาะข้อมูลส่วนบุคคล
- มีค่าใช้จ่ายรายเดือนอะไรบ้าง ใครจ่าย และอะไรจะต่ออายุเมื่อไร ทั้งโดเมน ใบรับรอง SSL และค่าสมาชิกนักพัฒนาของ Apple
- มีงานอัตโนมัติอะไรที่รันอยู่เบื้องหลัง เช่น งานตัดรอบประจำคืน
หน้านี้จะกลายเป็นเอกสารที่มีค่าที่สุดขององค์กรในเรื่องระบบนี้ และเป็นสิ่งแรกที่เวนเดอร์รายต่อไปจะขอ
สัปดาห์ที่ 3: ดูความเสี่ยง
เมื่อเห็นภาพรวมแล้ว ให้ไล่ดูสามเรื่อง
ความปลอดภัย ไลบรารีที่ระบบใช้มีช่องโหว่ที่รู้กันอยู่แล้วหรือไม่ เซิร์ฟเวอร์อัปเดตล่าสุดเมื่อไร และใครยังเข้าระบบได้บ้าง ถ้าเวนเดอร์เดิมยังมีสิทธิ์อยู่ “เผื่อไว้ก่อน” ให้ถอนออก
PDPA ตามกฎหมาย องค์กรของคุณคือผู้ควบคุมข้อมูลส่วนบุคคล เวนเดอร์ที่ยังถือข้อมูลอยู่คือผู้ประมวลผลข้อมูล ซึ่งต้องมีข้อตกลงระหว่างกัน ถ้าไม่มีข้อตกลงและไม่ได้ทำงานด้วยกันแล้ว ให้ขอให้ลบข้อมูลและยืนยันเป็นลายลักษณ์อักษร
ความรู้ ระบบมีชุดทดสอบอัตโนมัติไหม มีเอกสารวิธี deploy ไหม ถ้าไม่มีทั้งสองอย่าง การแก้ไขทุกครั้งจะเสี่ยงและช้ากว่าที่ควร ต้องรู้ไว้ก่อนรับปากผู้ใช้เรื่องฟีเจอร์ใหม่
สัปดาห์ที่ 4: ตัดสินใจ แต่อย่าเริ่มจากการรื้อ
เวนเดอร์รายใหม่จำนวนมากจะเสนอให้ทำใหม่ทั้งหมด บางครั้งก็จำเป็นจริง แต่ส่วนใหญ่ไม่ใช่ ระบบที่ใช้งานอยู่ทุกวันเก็บความรู้เรื่องเงื่อนไขทางธุรกิจไว้มากกว่าเอกสารใดๆ การรื้อทำใหม่ทั้งระบบคือการทิ้งความรู้นั้นแล้วเรียนรู้ใหม่ด้วยงบของคุณ
ทางที่ปลอดภัยกว่าคือแยกเป็นสามกอง
- ส่วนที่ใช้ได้ดี ปล่อยไว้ แค่เพิ่มการทดสอบและการเฝ้าดู
- ส่วนที่ต้องซ่อม แก้ทีละส่วน โดยมีชุดทดสอบคุ้มกันไว้
- ส่วนที่เกินจะซ่อม ค่อยสร้างใหม่ และสร้างเฉพาะส่วนนั้น
- ส่วนที่ใช้ได้ดี ปล่อยไว้ แค่เพิ่มการทดสอบและการเฝ้าดู
- ส่วนที่ต้องซ่อม แก้ทีละส่วน โดยมีชุดทดสอบคุ้มกันไว้
- ส่วนที่เกินจะซ่อม สร้างใหม่ เฉพาะส่วนนั้น
การตัดสินใจนี้ควรมาจากการอ่านโค้ดจริงและรายการความเสี่ยงที่เขียนไว้ ไม่ใช่มาจากความรู้สึกของใครคนใดคนหนึ่ง
สามกับดักที่เจอบ่อย
- ให้เวนเดอร์เดิมเก็บสิทธิ์ไว้ “เผื่อฉุกเฉิน” สิทธิ์ที่ไม่มีใครดูแลคือช่องโหว่ ถ้าจำเป็นจริง ให้สร้างบัญชีชั่วคราวที่มีวันหมดอายุ
- ข้อมูลสำรองที่ไม่เคยลองกู้ ไฟล์สำรองที่ไม่เคยกู้คืนสำเร็จ ยังพึ่งพาไม่ได้
- รับปากฟีเจอร์ใหม่ก่อนระบบนิ่ง ทุกฟีเจอร์ที่เพิ่มบนระบบที่ยังไม่เข้าใจ จะทำให้ปัญหาเดิมหาตัวยากขึ้น
ถ้าอยากรู้ว่าระบบของคุณเสี่ยงแค่ไหน ลองเช็กความเสี่ยงเวนเดอร์ 12 ข้อ ใช้เวลาประมาณสามนาที