คือเรื่องปกติของ Enterprise
ไม่เหมือนกันเลย
จัดการได้ทุก vendor
เกือบทุก Enterprise ที่มี network ขนาดใหญ่จะเจอสถานการณ์เดียวกัน — มี Cisco, Huawei, Mikrotik และอื่น ๆ อยู่ในระบบเดียวกัน นี่คือ multi-vendor network environment ที่ฟังดูเป็นเรื่องปกติ แต่กลายเป็น headache เมื่อต้อง จัดการ network หลาย vendor พร้อมกัน บทความนี้อธิบายว่าทำไมมันถึงเกิดขึ้น ความท้าทายที่แท้จริงคืออะไร และวิธีจัดการที่ได้ผลจริง
ทำไม Enterprise ถึงมี Router/Switch หลาย Vendor ในระบบเดียว
Multi-vendor ไม่ได้เกิดจากการวางแผนผิด — แต่เป็นผลของการเติบโตตามธรรมชาติขององค์กร มีสาเหตุที่พบบ่อยหลายอย่าง
- การจัดซื้อคนละช่วงเวลา — แต่ละปีงบประมาณเลือก vendor ที่คุ้มที่สุดตอนนั้น สะสมมาหลายยี่ห้อ
- การควบรวมกิจการ — merge กับองค์กรอื่นที่ใช้ vendor ต่างกัน แล้วต้องรวมระบบ
- ความเหมาะสมเฉพาะจุด — บาง vendor เก่งเรื่อง core บางเจ้าคุ้มกว่าสำหรับ edge/branch
- หลีกเลี่ยง vendor lock-in — ตั้งใจกระจายความเสี่ยงไม่ผูกกับเจ้าเดียว
ผลคือ network ที่ “ทำงานได้” แต่ “จัดการยาก” เพราะแต่ละ vendor มีวิธีทำงานของตัวเอง
ความท้าทายของ Multi-vendor Environment
CLI Command ต่างกันทุก Vendor
สิ่งเดียวกัน — เช่น การตั้งค่า VLAN — ใช้ command คนละชุดในแต่ละ vendor engineer ต้องจำหลาย syntax และสลับ mindset ไปมา ซึ่งเพิ่มโอกาส error โดยเฉพาะเมื่อทำงานเร็ว ๆ
| งาน | Cisco IOS | Huawei VRP | Mikrotik |
|---|---|---|---|
| เข้า config mode | configure terminal | system-view | /interface |
| ดู config | show running-config | display current-configuration | export |
| save config | write memory | save | (auto) |
Firmware Update Cycle ไม่ตรงกัน
แต่ละ vendor ปล่อย firmware update และ security patch คนละรอบ ทีมต้องติดตามหลาย roadmap พร้อมกัน และวางแผน maintenance window ที่ไม่ชนกัน — ยิ่ง vendor มาก ยิ่งซับซ้อน
Script ที่ใช้กับ Cisco ใช้กับ Huawei ไม่ได้
นี่คือหัวใจของปัญหา automation ใน multi-vendor — script หรือ template ที่เขียนไว้สำหรับ vendor หนึ่งใช้กับอีก vendor ไม่ได้เลย ถ้าไม่มีระบบจัดการที่ดี ทีมจะมี template แยกตาม vendor ที่ต้อง maintain หลายชุด ทวีความยุ่งยากของscript template management ขึ้นไปอีก
วิธีจัดการ Multi-vendor Network ที่ได้ผลจริง
ตัวอย่าง: Topology ที่มี Cisco + Huawei + Mikrotik อยู่ด้วยกัน
ลองนึกถึง Enterprise ทั่วไปที่มี network แบบนี้ — แต่ละชั้นใช้ vendor ที่เหมาะกับงานและงบ
ทั้ง 3 ชั้นต้อง provision, monitor และ maintain — ถ้าทำแยกตาม vendor คือ 3 workflow, 3 ชุด script, 3 จุดที่ผิดพลาดได้ แต่ถ้ามี abstraction layer เดียว ทีมจัดการทั้งหมดผ่านระบบเดียวได้
Tool ที่รองรับ Multi-vendor ในปัจจุบัน
ตลาดมีเครื่องมือหลายแบบที่รองรับ multi-vendor แต่ละแบบเหมาะกับทีมต่างกัน
- Automation framework (เช่น Ansible) — รองรับหลาย vendor ผ่าน module แต่ต้องมี developer ดูแล playbook (เทียบข้อดี-ข้อเสียในบทความ Ansible vs Netmiko)
- Vendor management platform เฉพาะเจ้า — จัดการได้ดีแต่มักผูกกับ vendor นั้น ๆ ไม่เหมาะกับ multi-vendor จริง
- Dedicated multi-vendor provisioning platform — ออกแบบมาเพื่อ multi-vendor โดยตรง มี abstraction layer และ centralized inventory ในตัว ใช้ GUI ได้โดยไม่ต้องเขียน code
สำหรับทีมไทยที่มี Cisco, Huawei, Mikrotik ปนกันและไม่มี developer ประจำ — LINKFLO รองรับ multi-vendor ผ่าน template ที่ auto-assign ตาม device จริง ทำให้ช่างหน้างานจัดการได้ทุก vendor ผ่าน workflow เดียว
สรุป
Multi-vendor network เป็นความจริงที่หลีกเลี่ยงได้ยากสำหรับ Enterprise ที่เติบโต และมันจะเป็น headache ตราบใดที่ทีมยังจัดการแบบแยกตาม vendor ทางออกไม่ใช่ “บังคับให้เหลือ vendor เดียว” ซึ่งมักเป็นไปไม่ได้ในทางปฏิบัติ แต่คือการมี abstraction layer ที่ทำให้ vendor ที่ต่างกันถูกจัดการผ่านระบบเดียว — เปลี่ยนความหลากหลายจากภาระให้เป็นความยืดหยุ่น
ช่างหน้างานทำงานได้ทุก vendor โดยไม่ต้องจำ CLI หลายชุด
บทความโดยทีม Bluesharp — ผู้พัฒนา LINKFLO แพลตฟอร์ม Network Provisioning สำหรับองค์กรไทย
