บทความ · 25 ต.ค. 2569 · อ่าน 6 นาที

เวนเดอร์หายไป ระบบยังต้องเดินต่อ: สิ่งที่ต้องทำใน 30 วันแรก

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

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

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

  1. 1 สัปดาห์ที่ 1: กุญแจและข้อมูลสำรอง ทุกบัญชีอยู่ในชื่อองค์กร และลองกู้ข้อมูลสำรองได้จริงหนึ่งครั้ง
  2. 2 สัปดาห์ที่ 2: แผนที่ระบบ สรุปหนึ่งหน้า ระบบมีกี่ส่วน ข้อมูลอยู่ไหน ค่าใช้จ่าย และอะไรต่ออายุเมื่อไร
  3. 3 สัปดาห์ที่ 3: ความเสี่ยง ความปลอดภัย PDPA และดูว่ามีชุดทดสอบกับวิธี deploy หรือยัง
  4. 4 สัปดาห์ที่ 4: ตัดสินใจ แยกระบบเป็นสามกองก่อน แล้วค่อยคุยเรื่องทำใหม่
ภาพที่ 1 แต่ละสัปดาห์ต่อยอดจากสัปดาห์ก่อนหน้า ไม่มีกุญแจก็ทำแผนที่ไม่ได้ ไม่มีแผนที่ก็ประเมินความเสี่ยงไม่ได้

สัปดาห์ที่ 1: เอาสิทธิ์การเข้าถึงกลับมาไว้ในมือ

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

  • โดเมนและ DNS ถ้าโดเมนหมดอายุ ทุกอย่างหยุดพร้อมกัน ดูวันหมดอายุไว้ด้วย
  • คลาวด์หรือโฮสติ้ง ที่ระบบรันอยู่ และบัตรเครดิตที่ผูกไว้
  • Repository ของซอร์สโค้ด เช่น GitHub หรือ GitLab
  • บัญชีนักพัฒนาบน App Store และ Google Play ถ้ามีแอปมือถือ
  • LINE OA และ LINE Developers ถ้ามีระบบบน LINE
  • บริการอื่นที่ระบบเรียกใช้ เช่น ระบบส่งอีเมล ระบบชำระเงิน หรือ SMS

บัญชีไหนอยู่ในชื่อองค์กรแล้ว ให้เปลี่ยนรหัสผ่าน เปิดการยืนยันตัวตนสองชั้น และตั้งเจ้าของฝั่งคุณอย่างน้อยสองคน บัญชีไหนอยู่ในชื่อเวนเดอร์หรือพนักงานของเวนเดอร์ ให้ขอโอนเข้าชื่อองค์กรเป็นลายลักษณ์อักษร ส่วนใหญ่ทำได้โดยไม่ต้องย้ายระบบ ทั้ง repository แอปบน App Store และแอปบน Google Play ล้วนมีขั้นตอนโอนไปยังบัญชีอื่นได้

  1. 1 อยู่ในชื่อเวนเดอร์ บัญชีที่เวนเดอร์หรือพนักงานของเวนเดอร์ถือไว้
  2. 2 ขอโอนเป็นลายลักษณ์อักษร ทำหนังสือขอโอนทีละบัญชีเข้าชื่อองค์กร
  3. 3 อยู่ในชื่อองค์กร เปลี่ยนรหัสผ่าน เปิดยืนยันตัวตนสองชั้น และมีเจ้าของฝั่งคุณสองคน
ภาพที่ 2 บัญชีส่วนใหญ่โอนได้โดยไม่ต้องย้ายระบบ ทั้ง repository แอปบน App Store และแอปบน Google Play มีขั้นตอนโอนไปบัญชีอื่นได้

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

สัปดาห์ที่ 2: ทำแผนที่ระบบ

ตอนนี้คุณเข้าระบบได้แล้ว ขั้นต่อไปคือรู้ว่ามีอะไรอยู่ตรงไหน เขียนสรุปหนึ่งหน้าว่า

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

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

สัปดาห์ที่ 3: ดูความเสี่ยง

เมื่อเห็นภาพรวมแล้ว ให้ไล่ดูสามเรื่อง

ความปลอดภัย ไลบรารีที่ระบบใช้มีช่องโหว่ที่รู้กันอยู่แล้วหรือไม่ เซิร์ฟเวอร์อัปเดตล่าสุดเมื่อไร และใครยังเข้าระบบได้บ้าง ถ้าเวนเดอร์เดิมยังมีสิทธิ์อยู่ “เผื่อไว้ก่อน” ให้ถอนออก

PDPA ตามกฎหมาย องค์กรของคุณคือผู้ควบคุมข้อมูลส่วนบุคคล เวนเดอร์ที่ยังถือข้อมูลอยู่คือผู้ประมวลผลข้อมูล ซึ่งต้องมีข้อตกลงระหว่างกัน ถ้าไม่มีข้อตกลงและไม่ได้ทำงานด้วยกันแล้ว ให้ขอให้ลบข้อมูลและยืนยันเป็นลายลักษณ์อักษร

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

สัปดาห์ที่ 4: ตัดสินใจ แต่อย่าเริ่มจากการรื้อ

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

ทางที่ปลอดภัยกว่าคือแยกเป็นสามกอง

  1. ส่วนที่ใช้ได้ดี ปล่อยไว้ แค่เพิ่มการทดสอบและการเฝ้าดู
  2. ส่วนที่ต้องซ่อม แก้ทีละส่วน โดยมีชุดทดสอบคุ้มกันไว้
  3. ส่วนที่เกินจะซ่อม ค่อยสร้างใหม่ และสร้างเฉพาะส่วนนั้น
  1. ส่วนที่ใช้ได้ดี ปล่อยไว้ แค่เพิ่มการทดสอบและการเฝ้าดู
  2. ส่วนที่ต้องซ่อม แก้ทีละส่วน โดยมีชุดทดสอบคุ้มกันไว้
  3. ส่วนที่เกินจะซ่อม สร้างใหม่ เฉพาะส่วนนั้น
ภาพที่ 3 การรื้อทำใหม่ทั้งระบบคือการทิ้งส่วนที่ยังใช้ได้ไปด้วย แยกกองก่อน งานจะเหลือเฉพาะส่วนที่เกินจะซ่อม

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

สามกับดักที่เจอบ่อย

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

ถ้าอยากรู้ว่าระบบของคุณเสี่ยงแค่ไหน ลองเช็กความเสี่ยงเวนเดอร์ 12 ข้อ ใช้เวลาประมาณสามนาที

กำลังจะรับช่วงระบบที่ทีมอื่นทำไว้?

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

สอบถามแพ็กเกจ Takeover →

หรือเริ่มจากนัดคุย 30 นาที ไม่มีค่าใช้จ่าย →