รับดูแลระบบเก่าที่ไม่มีเอกสาร และไม่มีคนเขียนเหลืออยู่: เริ่มจากตรงไหน?

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

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

รับดูแลระบบเก่าที่ไม่มีเอกสาร ควรเริ่มจากตรงไหน?

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

ลำดับที่แนะนำ:

1. Protect: backup เต็มรูปแบบ ทดสอบกู้คืน และเก็บสถานะเซิร์ฟเวอร์ปัจจุบัน
2. Inventory: สร้างรายการระบบจากสิ่งที่รันอยู่ ทั้งเซิร์ฟเวอร์ process พอร์ต งานตั้งเวลา configuration และ integration
3. Dependencies: ทำรายการไลบรารีและส่วนประกอบ (SBOM) (รวมอยู่ในเฟส Inventory ในตารางด้านล่าง)
4. Observe: เก็บ log และ telemetry เพื่อดูว่าระบบทำงานจริงอย่างไร
5. Characterize: เขียนเทสต์บันทึกพฤติกรรมปัจจุบันก่อนแก้โค้ด
6. Document: เขียนแผนผัง runbook และบันทึกการตัดสินใจแบบเบาๆ ไปพร้อมกัน
7. Decide: ตัดสินใจว่าจะดูแลต่อหรือปรับปรุงระบบ

ก่อนแตะระบบ ต้อง backup และเก็บสถานะอะไรไว้บ้าง?

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

ระบบเก่าที่รับช่วงมามีข้อควรระวังเพิ่มอีกข้อ CISA #StopRansomware Guide แนะนำให้เก็บซอร์สโค้ดหรือไฟล์ executable ไว้กับ backup แบบ offline ด้วย เพราะบางครั้งไฟล์ที่รันอยู่บนเซิร์ฟเวอร์คือสำเนาเดียวที่ยืนยันได้ว่าใช้งานได้จริง รายละเอียดหลัก 3-2-1 และการเก็บ backup แบบ offline ดูที่ วิธีดูแลระบบเก่าให้ใช้งานต่อได้อย่างปลอดภัย

นอกจากข้อมูล ให้เก็บ "ภาพถ่ายสถานะ" ของเซิร์ฟเวอร์ ณ วันที่รับช่วงไว้ด้วย เช่น สำเนาไดเรกทอรี configuration รายการแพ็กเกจที่ติดตั้ง รายการ service และงานตั้งเวลา หากระบบรันบน virtual machine ให้ทำ snapshot หรือ image ของเครื่องไว้เป็นจุดอ้างอิง ภาพสถานะนี้จะใช้เทียบเมื่อเกิดปัญหาว่าอะไรเปลี่ยนไปจากเดิม

จะสร้างรายการระบบ (inventory) จากระบบที่รันอยู่ได้อย่างไร?

ให้ถือว่าระบบที่รันอยู่คือเอกสารที่เชื่อถือได้ที่สุด แล้วไล่สำรวจทีละหมวดด้วยคำสั่งหรือเครื่องมือแบบอ่านอย่างเดียว (read-only) บันทึกผลลงไฟล์ที่ทีมเข้าถึงได้ร่วมกัน และยังไม่แก้ไขสิ่งใดในขั้นนี้

บนเซิร์ฟเวอร์ Linux คำสั่งพื้นฐานที่อ่านอย่างเดียว เช่น ps aux (process ที่รันอยู่), ss -tulpn (พอร์ตที่เปิดรับ ต้องใช้สิทธิ์ root จึงจะเห็นชื่อ process ของทุกพอร์ต), systemctl list-units --type=service และ systemctl list-timers (service และ timer), crontab -l ของแต่ละผู้ใช้กับไดเรกทอรี /etc/cron.* (งานตั้งเวลา) และ df -h (ดิสก์) ส่วนบน Windows Server ให้ดู Services, Task Scheduler และ IIS Manager แทน

หากพบว่าระบบปฏิบัติการ ภาษา หรือฐานข้อมูลหมดระยะการสนับสนุนแล้ว อ่านต่อที่ วิธีดูแลระบบเก่าให้ใช้งานต่อได้อย่างปลอดภัย

ระบบใช้ไลบรารีอะไรอยู่ และ SBOM ช่วยอะไร?

SBOM (Software Bill of Materials) คือรายการส่วนประกอบของซอฟต์แวร์ ช่วยให้รู้ว่าระบบพึ่งพาไลบรารีและเวอร์ชันใดบ้าง ซึ่งเป็นข้อมูลที่ระบบไม่มีเอกสารมักไม่มีใครรู้ CISA นิยาม SBOM ว่าเป็นรายการแบบซ้อนชั้น เปรียบเหมือนรายการส่วนผสมที่ประกอบเป็นซอฟต์แวร์

• OWASP Dependency-Check เป็นชุดเครื่องมือ Software Composition Analysis (SCA) ที่ระบุ dependency ของโปรเจกต์ และตรวจว่ามีช่องโหว่ที่เปิดเผยต่อสาธารณะแล้วหรือไม่
• OWASP Dependency-Track เป็นแพลตฟอร์มโอเพนซอร์สที่รับ SBOM รูปแบบ CycloneDX เพื่อทำทะเบียนส่วนประกอบ ค้นหาช่องโหว่ และบังคับใช้นโยบาย

ผลที่ได้คือรายการที่บอกว่าควรอัปเดตอะไรก่อน และส่วนไหนที่อัปเดตไม่ได้แล้วต้องหามาตรการอื่นมาควบคุมความเสี่ยง

ทำไมต้องสังเกตพฤติกรรมระบบก่อนแก้ไข?

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

เริ่มจาก log ที่มีอยู่ก่อน แล้วรวบรวมไว้ที่เดียวเพื่อค้นหาย้อนหลังได้ หากต้องการเห็นการเรียกใช้ข้ามส่วนประกอบ OpenTelemetry เป็น framework และชุดเครื่องมือโอเพนซอร์สสำหรับสร้าง ส่งออก และรวบรวม telemetry ได้แก่ traces, metrics และ logs โดยไม่ผูกกับผู้ขายรายใด การติดตั้ง instrumentation ถือเป็นการเปลี่ยนแปลงระบบอย่างหนึ่ง จึงควรทดสอบบน staging ก่อนเสมอ

ดูแนวทางเพิ่มเติมเรื่องการเฝ้าดูและปรับจูนระบบได้ที่ การดูแลประสิทธิภาพระบบ

Characterization test คืออะไร และช่วยให้แก้ระบบเก่าได้ปลอดภัยขึ้นอย่างไร?

Characterization test คือเทสต์ที่บันทึกว่าโค้ดเดิม "ทำงานอย่างไรอยู่ในตอนนี้" ไม่ใช่ว่าควรทำงานอย่างไร เมื่อแก้โค้ดแล้วเทสต์ยังผ่าน ก็มั่นใจได้มากขึ้นว่าพฤติกรรมเดิมไม่เปลี่ยนโดยไม่ตั้งใจ

Michael Feathers นิยามไว้ในคำนำของหนังสือ Working Effectively with Legacy Code (Prentice Hall, 2004) ว่า legacy code คือโค้ดที่ไม่มีเทสต์ และหนังสือเล่มนี้ครอบคลุมเรื่อง characterization test สำหรับบันทึกพฤติกรรมจริงของโค้ดเดิม เพื่อให้แก้ไขได้อย่างมั่นใจ

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

ควรเขียนเอกสารระบบเก่าแบบไหน ให้ทันใช้และไม่หนักเกินไป?

เขียนไปพร้อมกับที่เรียนรู้ โดยใช้รูปแบบเบาๆ ที่มีโครงสร้างอยู่แล้ว ไม่ต้องรอเขียนเอกสารฉบับสมบูรณ์ทีเดียว เก็บเอกสารไว้ใน repository เดียวกับโค้ด เพื่อให้แก้ไขไปพร้อมกับโค้ดได้

ADR เป็นแนวคิดที่ Michael Nygard ทำให้แพร่หลายจากบทความ "Documenting Architecture Decisions" ปี 2011 ตามที่ adr.github.io ระบุ สำหรับระบบที่รับช่วงมา ADR ฉบับแรกๆ มักเป็นการบันทึกสิ่งที่ค้นพบ เช่น เหตุผลที่ยังไม่อัปเกรดไลบรารีบางตัว

Runbook สำคัญอย่างไรกับระบบที่ไม่มีคนเขียนเหลืออยู่?

Runbook ทำให้งานประจำและการรับมือเหตุขัดข้องไม่ต้องพึ่งความจำของใครคนใดคนหนึ่ง หนังสือ Site Reliability Engineering ของ Google ระบุจากประสบการณ์ของ Google ว่า การคิดและบันทึกแนวปฏิบัติที่ดีไว้ล่วงหน้าใน "playbook" ทำให้ MTTR (mean time to repair หรือเวลาเฉลี่ยในการซ่อมให้ระบบกลับมาทำงาน) ดีขึ้นราว 3 เท่า เมื่อเทียบกับการแก้ปัญหาแบบด้นสด หนังสือใช้คำว่า playbook ซึ่งในบทความนี้ใช้ในความหมายเดียวกับ runbook

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

ใช้ข้อมูลจริงทดสอบระบบเก่าได้ไหม และ PDPA เกี่ยวข้องอย่างไร?

ไม่ควรนำข้อมูลส่วนบุคคลจาก production ไปใช้ทดสอบโดยตรง ควรใช้ข้อมูลที่ทำให้ระบุตัวบุคคลไม่ได้ (anonymised) หรือปกปิดบางส่วน (masked) บน environment ทดสอบ โดยเฉพาะเมื่อนำ backup มากู้คืนเพื่อทดลอง เพราะ staging อาจมีการควบคุมสิทธิ์หละหลวมกว่า production

เอกสารอ้างอิงภาษาไทยที่ใช้ได้คือ คู่มือ Anonymization Guideline (ฉบับภาษาไทย) ที่เผยแพร่บนเว็บไซต์ร่วมของ สวทช. และ สคส. (NSTDA x PDPC) ซึ่งปรับแปลมาจาก Guide to Basic Anonymisation ของ PDPC สิงคโปร์ คู่มือนี้แยกความหมายของ Anonymization ออกจาก De-identification และระบุเองว่าการปฏิบัติตามคำแนะนำในคู่มือไม่ได้หมายความว่าปฏิบัติตาม PDPA แล้ว จึงควรใช้เป็นแหล่งเรียนรู้เทคนิค ไม่ใช่ประกาศหรือแนวปฏิบัติทางการของไทย

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

จะลดการพึ่งพาความรู้ของคนคนเดียวได้อย่างไร?

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

CHAOSS ซึ่งเป็นโครงการภายใต้ Linux Foundation มีตัวชี้วัดชื่อ Contributor Absence Factor (เดิมเรียก Bus Factor) ที่ตั้งคำถามว่าโครงการจะเสี่ยงแค่ไหนหากคนที่ทำงานมากที่สุดออกไป ตัวชี้วัดนี้ออกแบบมาสำหรับโครงการโอเพนซอร์ส แต่ใช้เป็นแนวคิดเปรียบเทียบกับทีมดูแลระบบภายในองค์กรได้

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

แผนรับช่วงระบบที่ไม่มีเอกสารควรแบ่งเป็นเฟสอย่างไร?

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

ตัวอย่างสมมติ: รับช่วงระบบออกใบเสร็จภายใน

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

• Protect: restore test ครั้งแรกล้มเหลว เพราะ backup เดิมไม่รวมโฟลเดอร์ template ของใบเสร็จที่อยู่นอกไดเรกทอรีแอปพลิเคชัน ทีมแก้รายการ backup แล้วทดสอบซ้ำจนผ่าน
• Inventory: พบงานตั้งเวลาที่ส่งไฟล์ให้ระบบบัญชีทุกคืน ซึ่งไม่มีใครรู้มาก่อน จึงบันทึกเป็น integration
• Observe: log แสดงว่ามีหน้าจอหนึ่งที่ไม่มีผู้ใช้เรียกเลย จึงจดไว้เป็นคำถามให้เจ้าของงานยืนยัน แทนที่จะลบทันที
• Characterize: เขียนเทสต์บันทึกวิธีปัดเศษในใบเสร็จตามที่ระบบทำอยู่ ก่อนแก้ไขส่วนคำนวณ
• Decide: ทีมสรุปว่าดูแลต่อได้ในระยะสั้น พร้อมเสนอแผนปรับปรุงทีละส่วน

ประเด็นคือปัญหาที่พบในเฟส Protect และ Inventory ถูกค้นพบก่อนมีใครแก้โค้ด จึงแก้ได้โดยไม่กระทบผู้ใช้

เมื่อเข้าใจระบบแล้ว ควรดูแลต่อหรือปรับปรุงใหม่?

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

• ถ้าเลือกดูแลต่อ อ่าน วิธีดูแลระบบเก่าให้ใช้งานต่อได้อย่างปลอดภัย
• ถ้าเลือกปรับปรุง อ่าน แนวทางปรับปรุงระบบเก่า (Legacy Modernization) แนวทางหนึ่งคือ Strangler Fig ที่ Martin Fowler อธิบายว่าเริ่มจากส่วนเพิ่มเล็กๆ ซึ่งมักเป็นฟีเจอร์ใหม่ ที่สร้างต่อยอดแต่แยกจากโค้ดเดิม
• ถ้ายังไม่แน่ใจว่าจะใช้ทีมภายในหรือผู้ให้บริการภายนอก อ่าน Managed Services หรือทีม IT ภายใน และเมื่อจะทำสัญญาดูแลระบบ ดู เช็กลิสต์สัญญา MA และ SLA

ก่อนเริ่มแก้ไขระบบที่รับช่วงมา ต้องเช็กอะไรให้ครบ?

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

• มี backup เต็มรูปแบบ รวมสำเนาแบบ offline และกู้คืนบนเครื่องอื่นได้สำเร็จ
• เก็บ snapshot หรือภาพสถานะของเซิร์ฟเวอร์และ configuration ไว้เป็นจุดอ้างอิง
• มีรายการเซิร์ฟเวอร์ process พอร์ต งานตั้งเวลา integration และตำแหน่งของ credentials
• รู้ว่าซอร์สโค้ดที่มีตรงกับไฟล์ที่รันบน production หรือไม่
• มี SBOM และรู้ว่า dependency ใดมีช่องโหว่หรือหมดระยะการสนับสนุน
• เก็บ log ครอบคลุมรอบการทำงานสำคัญ และรู้ว่าการทำงานหลักวิ่งผ่านส่วนใด
• มี characterization test สำหรับส่วนที่จะแก้ไข
• มีแผนผังระดับ System context และ Container กับ runbook สำหรับงานประจำ
• environment ทดสอบใช้ข้อมูลที่ทำนิรนามหรือปกปิดแล้ว
• มีคนอย่างน้อยสองคนที่ทำงานประจำตาม runbook ได้

UNIXDEV รับดูแลระบบเดิมผ่านบริการ Legacy Application Maintenance ภายในขอบเขตงานที่ตกลงกัน ตั้งแต่สำรวจและทำรายการระบบ ตั้งค่า backup และ monitoring ปรับจูน และดูแลระบบต่อเนื่อง ส่วนงาน pipeline และโครงสร้างพื้นฐานดูได้ที่ DevOps & SRE

แหล่งอ้างอิงและอ่านต่อ

• Michael Feathers — Working Effectively with Legacy Code (Prentice Hall, 2004)
• The C4 model for visualising software architecture
• arc42 — Overview
• Michael Nygard — Documenting Architecture Decisions (2011)
• Architectural Decision Records (adr.github.io)
• Google SRE Book — Introduction
• CHAOSS — Contributor Absence Factor
• CISA — Software Bill of Materials (SBOM)
• OWASP Dependency-Check
• OWASP Dependency-Track
• OpenTelemetry — What is OpenTelemetry?
• Anonymization Guideline (ฉบับภาษาไทย) บนเว็บไซต์ NSTDA x PDPC
• CISA — #StopRansomware Guide
• Martin Fowler — Strangler Fig (2024)
• บทความที่เกี่ยวข้อง: เช็กลิสต์รับมอบระบบจากผู้รับจ้างเดิม

บทความโดย UNIXDEV Team · 30 ตุลาคม 2026 · สรุปแนวปฏิบัติเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย และตัวอย่างการรับช่วงระบบเป็นสถานการณ์สมมติ