ทำไม Network Engineer ต้องเรียน Python สำหรับ Automation
ในยุคที่เครือข่ายมีความซับซ้อนมากขึ้นเรื่อยๆ การจัดการ Network Device ทีละตัวด้วยมือไม่สามารถ Scale ได้อีกต่อไป ลองนึกภาพว่าคุณมี Switch 200 ตัวกระจายอยู่ทั่วองค์กร แล้วต้อง Update NTP Server Configuration บนทุกตัว ถ้าทำแบบ Manual คุณต้อง SSH เข้าไปทีละตัว พิมพ์ Command เดิมๆ ซ้ำ 200 ครั้ง ใช้เวลาทั้งวัน แถมยังเสี่ยงต่อ Typo Error อีกด้วย แต่ถ้าใช้ Python Script งานเดียวกันนี้ใช้เวลาไม่ถึง 5 นาที และไม่มี Human Error
Network Automation ไม่ได้หมายความว่า Network Engineer จะถูกแทนที่ด้วย Script แต่หมายความว่า Network Engineer จะมีเวลามากขึ้นในการทำงานที่สำคัญจริงๆ เช่น Network Design, Capacity Planning, Security Architecture และ Troubleshooting Complex Issues แทนที่จะเสียเวลาไปกับงาน Repetitive ที่ Script ทำได้ดีกว่า
คำถามที่พบบ่อยคือ ทำไมต้อง Python ทำไมไม่ใช้ Ansible หรือ Tool อื่น คำตอบคือ Python เป็น Foundation ของ Network Automation ทั้งหมด Ansible เองก็เขียนด้วย Python Library อย่าง Netmiko, NAPALM, Nornir ล้วนเขียนด้วย Python การรู้ Python ทำให้คุณเข้าใจว่า Tool เหล่านี้ทำงานอย่างไร สามารถ Customize ได้เมื่อ Tool ไม่ตอบโจทย์ และสามารถสร้าง Tool ของตัวเองได้เมื่อจำเป็น
นอกจากนี้ Python ยังเป็นภาษาที่เรียนรู้ง่ายที่สุดสำหรับ Non-programmer เพราะมี Syntax ที่อ่านง่ายเหมือนภาษาอังกฤษ มี Library สำหรับ Network Automation มากมาย และมี Community ที่ใหญ่มากทั้งใน Network Engineering และ Software Development ทำให้หาข้อมูลและตัวอย่างได้ง่าย Certification อย่าง Cisco DevNet, Juniper Automation และ Arista Network Programmability ล้วนใช้ Python เป็นภาษาหลัก
Python Basics สำหรับ Network Engineer: เริ่มต้นแค่นี้พอ
Network Engineer ไม่จำเป็นต้องเรียน Python ทั้งหมดจึงจะเริ่ม Automate Network ได้ มี Concept หลักๆ ที่ต้องรู้ไม่กี่อย่าง ได้แก่ Variable สำหรับเก็บข้อมูลเช่น IP Address หรือ Hostname, Data Types พื้นฐาน ได้แก่ String สำหรับ Command Text, List สำหรับรายชื่อ Device, Dictionary สำหรับเก็บข้อมูล Device แบบ Key-Value
Loop เป็น Concept ที่สำคัญที่สุดสำหรับ Network Automation เพราะหัวใจของ Automation คือการทำซ้ำ for loop ช่วยให้คุณ Iterate ผ่าน List ของ Device แล้วรัน Command เดียวกันบนทุกตัว ตัวอย่างเช่น for device in device_list ตามด้วย connect(device) และ send_command(“show version”) แค่ 3 บรรทัดนี้ก็ส่ง Command ไปยัง Device ทุกตัวได้แล้ว
Conditional Statement (if/else) ใช้สำหรับ Decision Making เช่น ถ้า Output ของ show interface มี “down” ให้แจ้งเตือน หรือถ้า Device เป็น Cisco ให้ใช้ Command แบบหนึ่ง ถ้าเป็น Juniper ให้ใช้ Command แบบอื่น Function ใช้สำหรับจัดกลุ่ม Code ที่ใช้ซ้ำบ่อยๆ เช่น สร้าง Function ชื่อ backup_config() แล้วเรียกใช้กับ Device ทุกตัว
File I/O ใช้สำหรับอ่านและเขียนไฟล์ เช่น อ่าน Device List จากไฟล์ CSV, เขียน Backup Config ลงไฟล์ หรือสร้าง Report เป็น Text File Exception Handling (try/except) สำคัญมากสำหรับ Network Script เพราะ Network Device อาจไม่ตอบสนอง, Connection อาจ Timeout, Authentication อาจผิด Script ที่ดีต้องจัดการ Error เหล่านี้ได้อย่างเหมาะสม
สำหรับการติดตั้ง Python แนะนำ Python 3.10 ขึ้นไป ติดตั้งจาก python.org ใช้ pip สำหรับติดตั้ง Library เพิ่มเติม และใช้ Virtual Environment (venv) สำหรับแยก Project แต่ละ Project ออกจากกัน Editor แนะนำ VS Code ที่มี Python Extension ดีมาก มี Syntax Highlighting, Auto-complete และ Debugger ที่ช่วยให้เขียน Code ได้เร็วขึ้น
Netmiko: SSH เข้า Network Device ง่ายๆ ด้วย Python
Netmiko เป็น Python Library ที่ถูกสร้างขึ้นโดย Kirk Byers โดยเฉพาะสำหรับ Network Automation ผ่าน SSH เป็น Library ที่ได้รับความนิยมสูงสุดสำหรับงาน Network Automation ด้วย Python เพราะใช้งานง่ายมากและรองรับ Vendor หลากหลาย ทั้ง Cisco IOS, Cisco IOS-XE, Cisco NX-OS, Cisco ASA, Juniper Junos, Arista EOS, HP ProCurve, MikroTik, Fortinet, Palo Alto และอีกมากมาย
Netmiko ทำงานโดยการสร้าง SSH Connection ไปยัง Network Device ส่ง Command แล้วรับ Output กลับมา ฟังดูเหมือนง่ายแต่ในความเป็นจริงมีความซับซ้อนมากมายที่ Netmiko จัดการให้ เช่น การรอ Device Prompt ให้พร้อม, การจัดการ Pagination (–More–), การเข้า Enable Mode, การจัดการ Timing ที่ต่างกันของแต่ละ Vendor, การจัดการ SSH Key Exchange Algorithm ที่หลากหลาย ทั้งหมดนี้ถ้าเขียนเองด้วย Paramiko (SSH Library พื้นฐาน) จะซับซ้อนมาก
การติดตั้ง Netmiko ง่ายมาก เพียง pip install netmiko หลังจากนั้นก็พร้อมใช้งาน การใช้งานเบื้องต้นเริ่มจากการสร้าง Dictionary ที่เก็บข้อมูล Device ประกอบด้วย device_type (เช่น cisco_ios), host (IP Address), username, password จากนั้นใช้ ConnectHandler เพื่อสร้าง Connection และใช้ send_command เพื่อส่ง Show Command
send_command ใช้สำหรับส่ง Command ที่ไม่เปลี่ยนแปลง Configuration เช่น show version, show interfaces, show ip route, show running-config จะส่ง Command แล้วรอรับ Output ทั้งหมดกลับมาเป็น String สามารถนำ Output ไป Parse หรือเก็บลงไฟล์ได้ตามต้องการ
send_config_set ใช้สำหรับส่ง Configuration Command เช่น การสร้าง VLAN, การตั้งค่า Interface, การเปลี่ยน NTP Server โดยส่งเป็น List ของ Command เช่น [“interface gi0/1”, “description Uplink”, “no shutdown”] Netmiko จะเข้า Configuration Mode ให้อัตโนมัติ ส่ง Command ทีละบรรทัด แล้ว Exit Configuration Mode เมื่อเสร็จ
สำหรับ Multi-device Script สามารถสร้าง List ของ Device แล้วใช้ for loop เพื่อ Connect และส่ง Command ไปยังทุก Device ตัวอย่างเช่น สร้าง devices = [device1, device2, device3] แล้ววนลูป for device in devices: net_connect = ConnectHandler(**device) output = net_connect.send_command(“show version”) แค่นี้ก็ดึง Show Version จากทุก Device ได้แล้ว
NAPALM: Vendor-Agnostic Network Automation
NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) เป็น Python Library ที่มี Abstraction Layer อยู่เหนือ Vendor-specific CLI ทำให้สามารถเขียน Code เดียวกันแล้วทำงานได้กับหลาย Vendor โดยไม่ต้องสนว่า CLI Syntax ต่างกันอย่างไร ตัวอย่างเช่น NAPALM function ชื่อ get_facts() จะ Return ข้อมูลพื้นฐานของ Device (Hostname, Model, Serial Number, OS Version, Uptime) ในรูปแบบ Dictionary เดียวกัน ไม่ว่าจะเป็น Cisco, Juniper, Arista หรือ Vendor อื่น
NAPALM ถูกออกแบบมาสำหรับ Network ที่มีหลาย Vendor ซึ่งเป็นสภาพจริงของ Enterprise Network ส่วนใหญ่ ที่อาจมี Cisco Switch, Juniper Router, Palo Alto Firewall และ Arista Data Center Switch อยู่ในเครือข่ายเดียวกัน ถ้าใช้ Netmiko ต้องเขียน Code แยกสำหรับแต่ละ Vendor เพราะ Command ต่างกัน แต่ NAPALM ซ่อนความแตกต่างเหล่านี้ไว้ใน Driver
NAPALM รองรับ Getter Function มากมาย ได้แก่ get_facts (ข้อมูลพื้นฐาน), get_interfaces (รายละเอียด Interface), get_interfaces_ip (IP Address ของ Interface), get_lldp_neighbors (LLDP Neighbor), get_bgp_neighbors (BGP Neighbor), get_arp_table (ARP Table), get_mac_address_table (MAC Address Table), get_config (Running/Startup/Candidate Config), get_environment (CPU, Memory, Temperature) และอีกมากมาย
ฟีเจอร์ที่ทรงพลังที่สุดของ NAPALM คือ Configuration Management ที่รองรับ Compare Config และ Commit/Rollback สามารถ Load Configuration ใหม่เข้าไปใน Device แล้วเปรียบเทียบกับ Config ปัจจุบัน (Compare Config หรือ Diff) ดูว่ามีการเปลี่ยนแปลงอะไรบ้างก่อน Commit ถ้า Config ใหม่มีปัญหาสามารถ Rollback กลับไปยัง Config เดิมได้ทันที ฟีเจอร์นี้ทำให้การเปลี่ยนแปลง Configuration ปลอดภัยขึ้นมาก
การ Load Config ของ NAPALM มีสองแบบ คือ load_merge_candidate ที่เอา Config ใหม่ไป Merge กับ Config เดิม (เพิ่มหรือเปลี่ยน เหมือน CLI ปกติ) และ load_replace_candidate ที่เอา Config ใหม่ไปแทนที่ Config เดิมทั้งหมด หลังจาก Load แล้ว ใช้ compare_config() เพื่อดู Diff จากนั้นใช้ commit_config() เพื่อ Apply หรือ discard_config() เพื่อยกเลิก
การติดตั้ง NAPALM ใช้ pip install napalm จะติดตั้ง Core Library พร้อม Driver สำหรับ Vendor หลักๆ ถ้าต้องการ Driver เพิ่มเติมสำหรับ Vendor อื่นก็ติดตั้งแยก เช่น pip install napalm-ros สำหรับ MikroTik RouterOS
Nornir: Inventory-based Concurrent Automation
Nornir เป็น Python Automation Framework ที่ออกแบบมาเพื่อแก้ปัญหาของ Netmiko และ NAPALM ในเรื่อง Scalability เมื่อต้องจัดการ Device จำนวนมาก ปัญหาของ Netmiko คือถ้ามี Device 200 ตัว แล้วทำทีละตัว (Sequential) จะใช้เวลานานมาก Nornir แก้ปัญหานี้ด้วย Concurrent Execution ที่รัน Task บน Device หลายตัวพร้อมกัน
Nornir ใช้ Inventory System ที่เก็บข้อมูล Device ในไฟล์ YAML หรือ SimpleInventory Plugin ประกอบด้วยไฟล์ hosts.yaml (รายชื่อ Device พร้อม IP, Username, Password, Platform), groups.yaml (กลุ่มของ Device ที่แชร์ Setting เดียวกัน เช่น Cisco_IOS, Juniper_Junos) และ defaults.yaml (Default Setting ที่ Apply กับทุก Device)
Nornir ไม่ได้มี Transport Layer เป็นของตัวเอง แต่ใช้ Plugin System ที่สามารถใช้ Netmiko, NAPALM หรือ Paramiko เป็น Transport ได้ ตัว Nornir จะจัดการเรื่อง Inventory, Concurrency, Result Processing และ Filtering ส่วน Plugin จะจัดการเรื่องการ Connect และส่ง Command จริงๆ
Plugin ที่นิยมมากที่สุดคือ nornir_netmiko ที่ใช้ Netmiko เป็น Transport ทำให้ได้ความง่ายของ Netmiko รวมกับ Concurrency ของ Nornir ตัวอย่างเช่น สามารถส่ง show version ไปยัง Device 200 ตัวพร้อมกัน (Default 20 Thread) ใช้เวลาไม่กี่วินาทีแทนที่จะเป็นหลายนาที
Nornir มี Filtering System ที่ทรงพลัง สามารถ Filter Device จาก Inventory ตาม Platform, Group, Custom Data หรือ Function ตัวอย่างเช่น nr.filter(platform=”cisco_ios”) จะเลือกเฉพาะ Cisco IOS Device, nr.filter(F(groups__contains=”core_switches”)) จะเลือกเฉพาะ Core Switch ทำให้สามารถรัน Task บนกลุ่ม Device ที่เฉพาะเจาะจงได้ง่าย
Result Processing ของ Nornir ถูกออกแบบมาอย่างดี ผลลัพธ์จาก Task จะถูกเก็บใน AggregatedResult Object ที่สามารถ Iterate ผ่าน Device แต่ละตัว ดูว่า Task สำเร็จหรือล้มเหลว ดู Output ของแต่ละ Device และ Print Summary ได้ทันที ทำให้ง่ายต่อการวิเคราะห์ผลลัพธ์เมื่อรันบน Device จำนวนมาก
TextFSM และ TTP: Parse CLI Output ให้เป็น Structured Data
ปัญหาใหญ่ของ Network Automation คือ Output จาก CLI ของ Network Device เป็น Unstructured Text ที่ออกแบบมาสำหรับคนอ่าน ไม่ใช่สำหรับ Machine ตัวอย่างเช่น show ip interface brief บน Cisco IOS จะ Return ข้อมูลเป็น Table ที่ Format ด้วย Space ถ้าจะดึงเฉพาะ Interface ที่ Down ต้อง Parse Text ด้วย Regex ซึ่งซับซ้อนและเปราะบาง
TextFSM เป็น Library ที่พัฒนาโดย Google สำหรับ Parse Semi-structured Text ทำงานโดยใช้ Template File ที่กำหนด Pattern ของ Output สำหรับแต่ละ Command จากนั้น TextFSM จะ Parse Output ตาม Template แล้ว Return ข้อมูลเป็น List ของ Dictionary ที่สามารถนำไปใช้ต่อได้ง่าย
NTC Templates เป็น Community Project ที่รวม TextFSM Template สำหรับ Command ที่ใช้บ่อยของ Vendor ต่างๆ มี Template มากกว่า 1,000 รายการ ครอบคลุม Cisco, Juniper, Arista, HP และอีกหลาย Vendor ติดตั้งผ่าน pip install ntc-templates จากนั้น Netmiko สามารถใช้ NTC Templates อัตโนมัติผ่าน Parameter use_textfsm=True ใน send_command ทำให้ Output กลายเป็น Structured Data ทันที
TTP (Template Text Parser) เป็นอีกทางเลือกหนึ่งสำหรับ Parse CLI Output ที่มี Syntax ง่ายกว่า TextFSM มาก TTP Template ดูเหมือน Output จริงของ Command โดยมี Variable ในตำแหน่งที่ต้องการดึงข้อมูล ตัวอย่างเช่น Template สำหรับ parse show ip interface brief อาจเป็น “{{ interface }} {{ ip_address }} {{ status }} {{ protocol }}” ซึ่งอ่านง่ายกว่า TextFSM Template มาก
ปัจจุบัน Network Device รุ่นใหม่หลายตัวรองรับ Structured Output ผ่าน API เช่น NETCONF/YANG (XML), RESTCONF (JSON) หรือ gNMI (Protobuf) ซึ่งไม่ต้อง Parse Text เลย แต่ในความเป็นจริง องค์กรส่วนใหญ่ยังมี Legacy Device ที่รองรับแค่ CLI ดังนั้น TextFSM/TTP ยังคงจำเป็นอีกนาน
Jinja2 Templates: สร้าง Configuration อัตโนมัติ
Jinja2 เป็น Template Engine สำหรับ Python ที่นิยมใช้ในการสร้าง Network Device Configuration อัตโนมัติ แทนที่จะเขียน Config ด้วยมือทีละ Device Jinja2 ช่วยให้สร้าง Template ที่มี Variable แล้ว Render ด้วยข้อมูลของ Device แต่ละตัว
ตัวอย่าง Jinja2 Template สำหรับ Switch Port Configuration อาจมีลักษณะแบบนี้ interface {{ interface_name }} ขึ้นบรรทัดใหม่ description {{ description }} ขึ้นบรรทัดใหม่ switchport mode access ขึ้นบรรทัดใหม่ switchport access vlan {{ vlan_id }} เมื่อ Render Template นี้ด้วยข้อมูล interface_name=GigabitEthernet0/1, description=User_Port, vlan_id=100 จะได้ Config พร้อมใช้งาน
Jinja2 รองรับ Control Structure เช่น for loop สำหรับสร้าง Config ซ้ำๆ เช่น สร้าง VLAN 10 อัน หรือ Configure Interface 48 Port, if/else สำหรับ Conditional Config เช่น ถ้า Interface เป็น Uplink ให้ใช้ Trunk Mode ถ้าเป็น Access Port ให้ใช้ Access Mode, Filter สำหรับ Transform Data เช่น upper() สำหรับแปลงเป็นตัวพิมพ์ใหญ่ หรือ default() สำหรับกำหนดค่า Default
Best Practice ในการใช้ Jinja2 สำหรับ Network Config คือแยก Template (โครงสร้าง Config) ออกจาก Data (ข้อมูลของ Device แต่ละตัว) โดยเก็บ Template เป็นไฟล์ .j2 และเก็บ Data เป็นไฟล์ YAML หรือ CSV ทำให้ Network Engineer ที่ไม่รู้ Python สามารถแก้ไข Data ได้โดยไม่ต้องแตะ Code และ Template สามารถ Reuse ได้กับ Device ทุกตัวที่ใช้ Platform เดียวกัน
สร้าง Config Backup Script: โปรเจกต์แรกสำหรับ Network Automation
Config Backup เป็นโปรเจกต์แรกที่ดีที่สุดสำหรับเริ่มต้น Network Automation เพราะง่าย มีประโยชน์ทันที และไม่เปลี่ยนแปลง Config ของ Device (Read-only) จึงปลอดภัยมาก
Script สำหรับ Config Backup มีขั้นตอนดังนี้ อ่าน Device List จากไฟล์ (CSV หรือ YAML), วน Loop ผ่านทุก Device, Connect ด้วย Netmiko, ส่ง Command show running-config, เก็บ Output ลงไฟล์ โดยตั้งชื่อไฟล์ตาม Hostname และวันที่ เช่น SW-CORE-01_2026-04-10.txt, Log ผลลัพธ์ว่า Backup สำเร็จหรือล้มเหลว
สำหรับ Script ที่ Production-ready ควรเพิ่ม Error Handling ด้วย try/except เพื่อจัดการกรณี Connection Timeout, Authentication Failure หรือ Command Error ควรมี Logging ที่บันทึกทุกกิจกรรมลงไฟล์ Log ควรรองรับหลาย Platform โดยเก็บ device_type ใน Device List และควรมี Retry Logic ที่ลองใหม่เมื่อ Connection ล้มเหลว
เพื่อให้ Backup มีประสิทธิภาพมากขึ้น ใช้ Nornir แทน for loop เพื่อ Backup หลาย Device พร้อมกัน ใช้ Git เพื่อ Track การเปลี่ยนแปลงของ Config ในแต่ละวัน และ Schedule Script ด้วย Cron หรือ Task Scheduler ให้รันอัตโนมัติทุกวัน
สร้าง Compliance Checker: ตรวจสอบ Config ว่าตรงตาม Standard
Compliance Checker เป็นโปรเจกต์ที่มีประโยชน์มากสำหรับ Network Security ช่วยตรวจสอบว่า Configuration ของ Device ทุกตัวตรงตาม Security Standard ขององค์กร เช่น NTP Server ถูกต้อง, SSH Version 2 ถูกเปิดใช้, Telnet ถูกปิด, SNMP Community String ไม่ใช้ค่า Default, Password Encryption ถูกเปิด, Logging Server ถูกตั้งค่า, Banner ถูกตั้ง
หลักการทำงานคือ ดึง Running Config จาก Device ด้วย Netmiko หรือ NAPALM จากนั้นตรวจสอบว่า Config มีหรือไม่มี Pattern ที่กำหนด ตัวอย่างเช่น ตรวจสอบว่ามี “ntp server 10.1.1.1” อยู่ใน Config หรือไม่ ตรวจสอบว่าไม่มี “transport input telnet” ตรวจสอบว่ามี “service password-encryption” เป็นต้น
ผลลัพธ์ของ Compliance Checker ควรสร้างเป็น Report ที่แสดงว่า Device ไหน Pass หรือ Fail ในแต่ละ Check Item พร้อม Summary ว่ามี Device กี่เปอร์เซ็นต์ที่ Comply สามารถ Output เป็น CSV สำหรับ Import เข้า Spreadsheet หรือ JSON สำหรับแสดงผลบน Dashboard
สำหรับ Advanced Compliance Checker สามารถเพิ่ม Auto-remediation ที่เมื่อพบว่า Device ไม่ Comply ระบบจะ Push Config ที่ถูกต้องเข้าไปอัตโนมัติ อย่างไรก็ตาม Auto-remediation ต้องใช้ด้วยความระมัดระวัง ควร Test อย่างถี่ถ้วนก่อน Deploy และควรมี Approval Process ก่อน Push Config ไปยัง Production Device
Automate VLAN Deployment: Push Config ไปหลาย Switch พร้อมกัน
VLAN Deployment เป็นงานที่ Network Engineer ทำบ่อยมาก เมื่อมี Department ใหม่หรือ Project ใหม่ ต้องสร้าง VLAN ใหม่บน Switch ทุกตัวที่เกี่ยวข้อง ถ้ามี Switch 30 ตัว การ SSH เข้าไป Create VLAN ทีละตัวจะเสียเวลามาก
Script สำหรับ VLAN Deployment ประกอบด้วย กำหนด VLAN Information (VLAN ID, Name, Subnet), สร้าง Config Command ด้วย Jinja2 Template, Connect ไปยัง Switch ทุกตัวด้วย Nornir, ส่ง Config ด้วย send_config_set, Verify ด้วย show vlan brief, Save Config ด้วย write memory
สิ่งสำคัญเมื่อ Push Config ไปยัง Production Device คือต้องมี Validation ก่อนและหลัง Push ก่อน Push ต้อง Verify ว่า VLAN ID ไม่ซ้ำกับที่มีอยู่ ต้อง Verify ว่า Device สามารถรับ Config ได้ (เช่น VLAN Database ไม่เต็ม) หลัง Push ต้อง Verify ว่า VLAN ถูกสร้างสำเร็จ ต้อง Verify ว่า Device ยังทำงานปกติ และต้อง Save Config เพื่อให้อยู่ถาวร
ควรเพิ่ม Rollback Plan ใน Script ด้วย ถ้า Push Config ไปแล้วเกิดปัญหา ต้องสามารถ Rollback กลับได้ วิธีง่ายที่สุดคือ Backup Config ก่อน Push และมี Script สำหรับ Restore Config เดิมเตรียมไว้ สำหรับ Device ที่รองรับ NAPALM สามารถใช้ commit_config() และ rollback() ที่ Built-in มาได้เลย
Error Handling สำหรับ Network Script: ต้องรัดกุม
Network Script ต่างจาก Script ทั่วไปตรงที่ต้องจัดการกับ Environment ที่ไม่แน่นอน Network Device อาจไม่ตอบสนอง, Link อาจ Down, Authentication อาจเปลี่ยน, Device อาจ Busy อยู่กับ Process อื่น ดังนั้น Error Handling ต้องรัดกุมมาก
Error ที่พบบ่อยที่สุดใน Network Automation ได้แก่ NetmikoTimeoutException เมื่อ Device ไม่ตอบสนองภายในเวลาที่กำหนด อาจเกิดจาก Device Down, ACL บล็อก SSH หรือ Routing Issue, NetmikoAuthenticationException เมื่อ Username หรือ Password ผิด, ReadTimeout เมื่อ Command ใช้เวลานานกว่าที่กำหนด เช่น show tech-support ที่อาจใช้เวลาหลายนาที, ConnectionException เมื่อ SSH Connection ถูกตัด
Best Practice สำหรับ Error Handling คือ ใช้ try/except ครอบทุก Connection และ Command, Log Error พร้อม Device Information เพื่อให้รู้ว่า Device ไหนที่มีปัญหา, ไม่หยุด Script ทั้งหมดเมื่อ Device ตัวเดียว Error (ใช้ continue เพื่อข้ามไป Device ถัดไป), มี Summary ท้าย Script ว่า Device ไหน Success ไหน Fail, ตั้ง Timeout ที่เหมาะสม ไม่สั้นเกินไปจนเกิด False Timeout และไม่ยาวเกินไปจนเสียเวลา
สำหรับ Production Script ควรมี Retry Logic ที่ลองใหม่อัตโนมัติเมื่อ Connection ล้มเหลว โดยมี Exponential Backoff (รอนานขึ้นเรื่อยๆ ก่อนลองใหม่) และ Maximum Retry Count เพื่อไม่ให้ลองไม่จบ ควรมี Circuit Breaker Pattern ที่ถ้า Device ล้มเหลวติดต่อกันหลายครั้ง ให้หยุดลองและแจ้ง Admin แทน
Scheduling ด้วย Cron: รัน Script อัตโนมัติตามเวลา
Network Automation Script หลายตัวต้องรันเป็นประจำ เช่น Config Backup ทุกวัน, Compliance Check ทุกสัปดาห์, Health Check ทุกชั่วโมง การมานั่งรัน Script เองทุกครั้งไม่เหมาะสม ควรใช้ Scheduler ให้รันอัตโนมัติ
บน Linux ใช้ Cron ที่เป็น Built-in Scheduler คำสั่ง crontab -e เพื่อแก้ไข Cron Schedule ตัวอย่าง 0 2 * * * /usr/bin/python3 /opt/scripts/backup.py หมายถึง รัน backup.py ทุกวันตี 2 สำหรับ 0 */4 * * * /usr/bin/python3 /opt/scripts/health_check.py หมายถึง รัน health_check.py ทุก 4 ชั่วโมง
บน Windows ใช้ Task Scheduler ที่สามารถ Schedule ได้ผ่าน GUI หรือ Command Line ด้วย schtasks สามารถกำหนดได้ว่ารันเมื่อไหร่ รันด้วย User อะไร รันเมื่อ Network Available หรือไม่ และ Action เมื่อ Task Fail
สิ่งที่ต้องระวังเมื่อ Schedule Network Script คือ Script ต้อง Handle ทุก Error ได้เอง เพราะไม่มีคนนั่งดู, ต้องมี Logging ที่ดี เพื่อให้ Admin กลับมาดูได้ว่า Script รันสำเร็จหรือไม่, ต้อง Set Working Directory ให้ถูกต้อง เพราะ Cron อาจ Run จาก Directory ที่ต่างจากที่ Test, ต้อง Set Environment Variable ที่จำเป็น เช่น PATH, ต้องมี Lock Mechanism ป้องกัน Script ตัวเดียวรัน Overlap กัน
Git Integration: Version Control สำหรับ Network Config
Git ไม่ได้มีไว้สำหรับ Software Developer เท่านั้น Network Engineer สามารถใช้ Git เพื่อ Track การเปลี่ยนแปลงของ Network Configuration ได้ ซึ่งเป็นสิ่งที่ขาดไม่ได้สำหรับ Network ขนาดใหญ่
แนวคิดคือ ใช้ Config Backup Script ดึง Config จากทุก Device ทุกวัน แล้ว Commit เข้า Git Repository ทำให้สามารถ ดูว่า Config เปลี่ยนแปลงอะไรบ้างในแต่ละวัน (git diff), ดูว่าใครเปลี่ยน Config เมื่อไหร่ (git log), กลับไปใช้ Config เก่าได้ (git checkout), เปรียบเทียบ Config ของ Device สอง Version ได้ (git diff commit1 commit2), ตั้ง Alert เมื่อมีการเปลี่ยนแปลง Config ที่ไม่ได้อยู่ใน Change Management
โครงสร้าง Git Repository สำหรับ Network Config ที่แนะนำคือ แยก Directory ตาม Site หรือ Device Group เช่น configs/core-switches/, configs/access-switches/, configs/routers/, configs/firewalls/ ในแต่ละ Directory มีไฟล์ Config ของ Device แต่ละตัว ตั้งชื่อตาม Hostname เช่น SW-CORE-01.cfg
สำหรับ Advanced Implementation สามารถ Integrate Git กับ CI/CD Pipeline ได้ เช่น เมื่อมี Pull Request ที่เสนอการเปลี่ยนแปลง Config ระบบ CI จะ Validate Config อัตโนมัติ (Syntax Check, Compliance Check) เมื่อ PR ถูก Approve และ Merge ระบบ CD จะ Push Config ไปยัง Device อัตโนมัติ แนวคิดนี้เรียกว่า GitOps for Network หรือ NetDevOps ซึ่งกำลังเป็นที่นิยมในองค์กรขนาดใหญ่
จาก Script สู่ Production Tooling: ยกระดับ Network Automation
เมื่อเริ่มชำนาญ Network Automation ขั้นต่อไปคือการพัฒนาจาก Script เดี่ยวๆ ไปเป็น Production-grade Tool ที่ Team สามารถใช้ร่วมกันได้ ซึ่งมีหลายแนวทาง
FastAPI หรือ Flask สำหรับสร้าง REST API ที่ครอบ Network Automation Function เช่น สร้าง API Endpoint สำหรับ Create VLAN, Backup Config, Check Compliance ทำให้ผู้ใช้ไม่ต้องรู้ Python แค่เรียก API ผ่าน Web Browser หรือ Postman ก็ใช้ Automation ได้
Streamlit หรือ Gradio สำหรับสร้าง Web Interface แบบง่ายๆ ที่ Network Engineer คนอื่นในทีมสามารถใช้ Automation ผ่าน Web GUI ได้ โดยไม่ต้องรู้ Code ตัวอย่างเช่น สร้าง Web Form ที่มี Dropdown เลือก Device, Text Box ใส่ VLAN ID และ Name, Button สำหรับ Create VLAN ทำให้ Junior Engineer สามารถ Deploy VLAN ได้ง่ายๆ ผ่าน Web
ChatOps คือการ Integrate Automation เข้ากับ Chat Platform เช่น Slack หรือ Microsoft Teams ทำให้ Engineer สามารถสั่ง Automation ผ่าน Chat ได้ เช่น พิมพ์ “/backup all” ใน Slack แล้ว Bot จะรัน Backup Script ให้ หรือพิมพ์ “/check compliance site-bkk” แล้ว Bot จะรัน Compliance Check แล้วส่ง Report กลับมาใน Chat
Ansible เป็นอีกทางเลือกสำหรับ Production Tooling ที่เพิ่ม Idempotency (รันซ้ำกี่ครั้งก็ได้ผลเหมือนเดิม), Role-based Structure, Inventory Management และ Playbook ที่อ่านง่ายกว่า Python Script ข้อดีของ Ansible คือ Network Engineer ที่ไม่รู้ Python สามารถเขียน Playbook ด้วย YAML ได้ แต่เบื้องหลังก็ยังใช้ Python Library เช่น Netmiko และ NAPALM อยู่ดี
สำหรับองค์กรขนาดใหญ่ อาจพิจารณา Platform อย่าง AWX/Ansible Tower สำหรับจัดการ Ansible Playbook ผ่าน Web GUI, StackStorm สำหรับ Event-driven Automation หรือ Nautobot/NetBox สำหรับ Source of Truth ที่เก็บข้อมูล Network Infrastructure ทั้งหมดเป็น Database แล้วใช้เป็น Input สำหรับ Automation
สรุป: เส้นทาง Network Automation ด้วย Python
Network Automation ด้วย Python ไม่ใช่ทางเลือกอีกต่อไป แต่เป็นทักษะที่จำเป็นสำหรับ Network Engineer ในปี 2026 เริ่มต้นด้วยการเรียน Python Basics ที่จำเป็น ฝึกใช้ Netmiko สำหรับ SSH Automation เรียนรู้ NAPALM สำหรับ Vendor-agnostic Automation และ Nornir สำหรับ Scale ไปยัง Device จำนวนมาก ใช้ TextFSM/TTP สำหรับ Parse Output และ Jinja2 สำหรับ Generate Config
เริ่มจากโปรเจกต์ง่ายๆ อย่าง Config Backup แล้วค่อยพัฒนาไปเป็น Compliance Checker, VLAN Deployment, Config Generator และ Production Tooling ที่ Team ใช้ร่วมกันได้ Schedule Script ด้วย Cron ใช้ Git Track Config Changes และ Integrate เข้ากับ CI/CD Pipeline สำหรับ NetDevOps
Resource ที่แนะนำสำหรับการเรียนรู้ ได้แก่ หนังสือ Network Programmability and Automation โดย O’Reilly, Python for Network Engineers Course จาก Kirk Byers (ผู้สร้าง Netmiko), Cisco DevNet Certification ที่เน้น Network Programmability, NTC (Network to Code) Blog ที่มีบทความ Network Automation มากมาย และ Nornir Documentation ที่มีตัวอย่างครบถ้วน
Network Automation เป็นการลงทุนที่คุ้มค่า เวลาที่ใช้เรียนรู้ Python และ Automation Library จะช่วยประหยัดเวลาได้มหาศาลในระยะยาว ลด Human Error ที่เกิดจาก Manual Configuration เพิ่มความสม่ำเสมอของ Configuration ทั่วทั้ง Network และทำให้ Network Engineer สามารถโฟกัสกับงานที่สำคัญกว่างาน Repetitive
