EP.1 คืน Maintenance ไม่ควรจบที่ Terminal 80 หน้าต่าง

เปลี่ยนงาน SSH ซ้ำๆ ให้ Python + Netmiko ช่วยจัดการเป็น Workflow

เปิด SSH ทีละจอเพื่อแก้ Config 80 เครื่อง อาจทำให้งาน Routine ยืดยาวกว่าที่ควรเป็น

ใน Maintenance Window คืนนี้ ทีม Network มีภารกิจอัปเดตค่า NTP Server บน Switch และ Router หลายสิบตัวทั่วองค์กร

ขั้นตอนดูตรงไปตรงมา เปิด SSH เข้าอุปกรณ์ วางคำสั่ง ตรวจผลลัพธ์ แล้วขยับไปเครื่องถัดไป

ฟังดูง่าย…จนกระทั่งต้องทำวนซ้ำทั้งคืน

• — Terminal เริ่มเต็มหน้าจอ
• — Session หลุดกลางทาง
• — อุปกรณ์ตอบกลับช้ากว่าปกติ
• — Prompt ของแต่ละรุ่นไม่เหมือนกัน

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

“เราใส่คำสั่งครบทุกตัวแล้วจริงไหม?”

ในเวลาปกติ งานเหล่านี้อาจเป็นแค่ Routine ของทีม Network

แต่เมื่ออยู่ใน Maintenance Window ทุกนาทีมีต้นทุน และทุกคำสั่งส่งผลกับระบบ Production โดยตรง

เมื่อทีมต้องทำขั้นตอนเดิมซ้ำๆ ต่อเนื่องเป็นเวลานาน Human Error จึงมีพื้นที่เกิดขึ้นได้ง่ายกว่าเวลาปกติ

• — พิมพ์ IP ผิดหนึ่งหลัก
• — วางคำสั่งผิดอุปกรณ์
• — ลืม Save Config หลังแก้ไข
• — ข้าม Switch ไปหนึ่งตัวโดยไม่รู้ตัว

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

หลายทีมจึงเริ่มขยับจาก Manual CLI ไปสู่ Python for Network Automation เพื่อทำให้งานซ้ำควบคุมได้เป็นระบบกว่าเดิม

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

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

สิ่งที่น่าสนใจคือ Automation ไม่ได้ช่วยแค่เรื่องความเร็ว

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

จากเดิมที่งานจำนวนมากกระจายอยู่ใน Terminal หลายหน้าต่าง ทุกอย่างเริ่มถูกจัดเก็บเป็นข้อมูลที่นำไป Review ต่อได้

นี่คือจุดที่ Python มีคุณค่ากับ Network Engineer มากกว่าการเป็น “ภาษาเขียนโปรแกรมอีกภาษา”

เมื่อเข้าใจพื้นฐานอย่าง Variable, Loop, Function, File I/O และ Error Handling ทีมจะเริ่มเห็นว่า งานซ้ำที่เคยต้องใช้แรงคน สามารถจัดระเบียบใหม่ให้กลายเป็น Workflow ที่ควบคุมได้มากขึ้น

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

แต่นี่เป็นเพียงก้าวแรกของ Network Automation

เมื่อองค์กรมีอุปกรณ์มากขึ้น เปิดสาขาเพิ่มขึ้น และต้องคุมมาตรฐาน Config ให้เหมือนกันทั้งระบบ คำถามถัดไปคือ…

เราจะยังใช้วิธีแก้ไฟล์ต้นแบบทีละบรรทัดอยู่ไหม?

ตอนต่อไป (EP.2): จาก Script สั่งงาน สู่ Template, Config Audit และ REST API สำหรับ Network Engineer — ถ้างาน Maintenance คืนถัดไปยังต้องไล่เช็กทีละเครื่องเหมือนเดิม ทีมกำลังเสียเวลาไปกับงานซ้ำ หรือกำลังปล่อยให้ Manual Process กลายเป็นต้นทุนที่มองไม่เห็น?

EP.2 Network ใหญ่ขึ้น Manual Config ยิ่งต้องคุมมาตรฐาน

ใช้ Jinja2, Config Audit และ REST API ลดงานแก้มือ ก่อน Network ขยายหลายไซต์

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

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

สำหรับ Enterprise Network ความเร็วเป็นเพียงจุดเริ่มต้นของ Automation

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

• — ชื่ออุปกรณ์ควรเป็นรูปแบบเดียวกัน
• — IP Address อยู่ในแผน
• — VLAN ตรงกับ Design
• — Routing อยู่ใน Architecture ที่ออกแบบไว้
• — Security Policy คงมาตรฐานเดียวกันในทุกไซต์

และรายละเอียดเล็กๆ ใน Config ไม่ควรถูกปล่อยให้กลายเป็นปัญหาหลัง Go-live

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

• — ไซต์หนึ่งลืมแก้ Description
• — อีกไฟล์ยังค้างค่า IP จากสาขาเก่า
• — บางจุดเปิดพอร์ตที่ควรปิด
• — อุปกรณ์บางตัวมีคำสั่ง Security ไม่ครบ

รายละเอียดเหล่านี้อาจดูเล็กตอนเตรียมไฟล์ แต่หลัง Go-live อาจกลายเป็นปัญหาที่ทีมต้องย้อนกลับมาตามหา

ตรงนี้ Python เริ่มช่วยให้ Network Engineer ขยับจากการ “แก้ไฟล์ Config” ไปสู่การ “ออกแบบระบบสร้าง Config”

หนึ่งในเครื่องมือสำคัญคือ Jinja2 แนวคิดของ Jinja2 คือการแยก “โครงสร้างหลักของ Config” ออกจาก “ข้อมูลเฉพาะของแต่ละไซต์” เช่น Hostname, IP Address, VLAN, Interface, Site Code หรือค่าที่เปลี่ยนไปตามสาขา

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

จากความแม่นยำที่ขึ้นอยู่กับคนแก้ไฟล์ สู่ความแม่นยำที่มาจาก Template, Data และ Logic ที่ออกแบบไว้ล่วงหน้า

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

เครื่องมืออย่าง CiscoConfParse ร่วมกับ Regular Expression ช่วยให้ Python อ่านโครงสร้างของไฟล์ Config แล้วค้นหา Pattern ที่ทีมสนใจได้ เช่น พอร์ตที่เปิดค้าง คำสั่งที่ขาดหาย การตั้งค่าที่ไม่ตรง Policy หรือจุดที่ควรนำกลับมาตรวจสอบด้าน Security

เมื่อทีมเริ่มใช้ Python กับงาน Audit ได้ดีขึ้น สิ่งที่ได้จะมากกว่า Report คือ Config จะกลายเป็นข้อมูลที่ค้นหา เปรียบเทียบ ตรวจสอบ และใช้ประกอบการตัดสินใจได้ชัดเจนขึ้น

และเมื่อ Network ยุคใหม่เชื่อมต่อกับ Cloud, Data Center Platform หรือระบบบริหารจัดการอื่นๆ มากขึ้น Automation ก็เริ่มขยับออกจาก CLI ไปสู่ REST API Python สามารถสื่อสารกับระบบผ่าน HTTP และข้อมูลรูปแบบ JSON เพื่อดึงข้อมูล ส่งคำสั่ง หรือเชื่อมโยงการทำงานกับระบบส่วนกลางได้โดยตรง

ทักษะ Python พื้นฐานจึงเริ่มมีความหมายมากขึ้นสำหรับ Network Engineer

• — Loop ใช้จัดการอุปกรณ์จำนวนมาก
• — Function ลดโค้ดซ้ำและทำให้เรียกใช้งานง่ายขึ้น
• — File I/O ใช้อ่านข้อมูลอุปกรณ์และบันทึกผลลัพธ์
• — Error Handling ทำให้ Script รับมือกับอุปกรณ์ผิดปกติได้ดีขึ้น
• — Regular Expression ใช้ค้นหา Pattern ใน Config
• — OOP ช่วยจัดระเบียบโค้ดให้ต่อยอดได้
• — REST API เปิดทางให้ Network ทำงานร่วมกับระบบซอฟต์แวร์ยุคใหม่

สำหรับทีมที่อยากวางพื้นฐานเหล่านี้ให้เป็นระบบ NTC ขอแนะนำหลักสูตร Python for Network Engineers หลักสูตรนี้ช่วยวางพื้นฐาน Python สำหรับงาน Network Automation ตั้งแต่การเขียน Script พื้นฐาน การอ่านไฟล์และจัดการ Error ไปจนถึงการใช้ Netmiko, Jinja2, CiscoConfParse และ REST API กับงานเครือข่ายจริง