TOR ระบบเครือข่าย ภาครัฐไทย 2026 — Checklist วาง spec ที่ผ่าน e-bidding
Checklist 12 หัวข้อสำหรับร่าง TOR ระบบเครือข่ายภาครัฐที่สมบูรณ์ ครอบคลุม vendor-neutral spec, redundancy SLA, Wi-Fi roaming, log retention ตาม PDPA และเงื่อนไข warranty ที่มักหลุดใน e-bidding
1. ทำไม TOR network ที่หน่วยรัฐมักหลุด — สถิติจาก e-GP#
ระบบ e-GP (Electronic Government Procurement) ของกรมบัญชีกลางรองรับการประกาศ TOR สาธารณะก่อนเปิดประมูล ทำให้ผู้ค้าทุกรายสามารถวิจารณ์ร่างได้ภายใน 3 วันทำการ อย่างไรก็ตาม ในทางปฏิบัติ TOR ระบบเครือข่ายจำนวนมากยังผ่านไปโดยมีจุดอ่อนสำคัญที่ไม่ถูกทักท้วง
ปัญหาที่พบบ่อยจากการพิจารณา TOR บน e-GP ได้แก่ การระบุยี่ห้อหรือรุ่นอุปกรณ์อย่างชัดเจน (เช่น "Cisco Catalyst 9300" หรือ "Fortinet FortiGate 100F") ซึ่งขัดกับหลักการแข่งขันเสรีตามระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 ข้อ 21 ที่กำหนดให้ spec ต้องไม่กีดกันผู้ยื่นข้อเสนอรายอื่น
นอกจากนี้ยังพบ spec ที่ขาด redundancy clause, ไม่ระบุ SLA uptime, Wi-Fi ไม่ระบุ roaming standard, และไม่มีเงื่อนไข log retention ที่สอดคล้องกับกฎหมาย ผลคือโครงการเสี่ยงถูกอุทธรณ์หลังประมูล หรือเมื่อติดตั้งจริงแล้วระบบไม่ตอบโจทย์การใช้งานจริงของหน่วยงาน
2. หลักเกณฑ์พื้นฐาน — vendor-neutral + competitive#
ก่อนลงรายละเอียด TOR ทีมร่าง spec ต้องเข้าใจหลักการที่ดำรงอยู่ตลอดทุกข้อกำหนด
ห้ามระบุยี่ห้อ รุ่น หรือ part number เว้นแต่ระบุว่า "หรือเทียบเท่า" พร้อมกำหนด performance ที่วัดได้ เช่น แทนที่จะเขียน "Switch Cisco Catalyst 9300 Series" ให้เขียนว่า "Layer 3 Managed Switch ที่รองรับ throughput ไม่น้อยกว่า 176 Gbps, รองรับ OSPF/BGP, PoE+ ไม่น้อยกว่า 30W ต่อ port"
การระบุยี่ห้อโดยไม่มีวลี "หรือเทียบเท่า" ถือเป็นเหตุให้ผู้ค้ารายอื่นยื่นอุทธรณ์ต่อคณะกรรมการพิจารณาอุทธรณ์ฯ กรมบัญชีกลางได้ และหน่วยงานอาจต้องเริ่มกระบวนการใหม่ทั้งหมด
กำหนดด้วย standard สากล เช่น IEEE 802.3at/bt, IEEE 802.11ax (Wi-Fi 6), ITU-T G.8032 สิ่งเหล่านี้ไม่ผูกกับผู้ผลิตรายใดและสามารถพิสูจน์ได้ด้วยการทดสอบ
แยก functional spec ออกจาก brand preference หาก TOR ต้องการ management platform ให้ระบุ feature ที่ต้องการ เช่น "รองรับ REST API, SNMP v3, Syslog" แทนการระบุชื่อ platform เฉพาะ
3. Checklist 12 หัวข้อที่ TOR network ต้องมี#
| # | หัวข้อ | สถานะที่มักพบ |
|---|---|---|
| 1 | วัตถุประสงค์และขอบเขตงาน | มักมี แต่ไม่ครบ |
| 2 | Topology diagram และจำนวนจุดติดตั้ง | มักขาด |
| 3 | Bandwidth / throughput ขั้นต่ำ | ระบุไม่ชัด |
| 4 | Redundancy / failover requirement | มักหลุด |
| 5 | Wi-Fi standard, roaming, capacity | มักหลุด |
| 6 | Security baseline (802.1X, VLAN, ACL) | บางส่วน |
| 7 | Management & monitoring (SNMP, Syslog) | มักมี |
| 8 | Log retention + format (เชื่อม PDPA/พ.ร.บ.คอมฯ) | มักหลุด |
| 9 | Warranty period + response time SLA | ไม่ครบ |
| 10 | Onsite support requirement | ไม่ชัดเจน |
| 11 | Acceptance test criteria | มักกว้างเกิน |
| 12 | Documentation & training | มักสั้นเกิน |
ใช้ตารางนี้เป็น review checklist ก่อนส่งร่าง TOR เข้าคณะกรรมการ หากหัวข้อใดว่างหรือคลุมเครือ ให้เติมก่อนประกาศสาธารณะ
4. Section ที่หลุดบ่อย: Redundancy / Failover SLA#
TOR หลายฉบับระบุเพียง "ระบบต้องมีความเสถียร" โดยไม่กำหนดตัวเลขที่วัดได้ ทำให้เมื่อระบบ downtime ผู้รับจ้างอ้างว่าเป็น "เหตุสุดวิสัย" และหน่วยงานไม่มีฐานในการปรับหรือบังคับ SLA
สิ่งที่ TOR ควรระบุชัดเจน:
- Uptime SLA ไม่น้อยกว่า 99.5% ต่อเดือน (เท่ากับ downtime ไม่เกิน 3.6 ชั่วโมง/เดือน) หรือระดับที่เหมาะสมกับ criticality ของระบบ
- Redundancy topology เช่น Core Switch ต้องมี dual power supply และ uplink redundancy แบบ LAG หรือ RSTP/MSTP
- Failover time กรณี uplink หลักล้มเหลว ต้องสลับไป backup link ภายใน ไม่เกิน 50ms (ระบุ standard เช่น ITU-T G.8032 Ethernet Ring Protection)
- ISP redundancy หากโครงการรวม internet link ให้ระบุ multi-homing หรือ backup link requirement ด้วย
สำหรับโครงการวงเงินต่ำที่ไม่สามารถมี dual uplink ได้ ให้ระบุ "acceptable single point of failure" พร้อม response time หากเกิด failure เพื่อให้โครงการสมจริงและผ่าน e-bidding โดยไม่ถูกวิจารณ์ว่า overspec
5. Section ที่หลุดบ่อย: Wi-Fi roaming + capacity sizing#
Wi-Fi เป็นจุดอ่อนที่สุดใน TOR ภาครัฐ เพราะมักระบุเพียง "จัดหา Access Point จำนวน X ตัว รองรับ IEEE 802.11ac" โดยไม่มี roaming และ capacity spec ใดเลย
ปัญหาที่เกิดตามมา: อุปกรณ์ Mobile เช่น notebook ของเจ้าหน้าที่ไม่ตัดต่อ AP อัตโนมัติเมื่อเดินจากห้องหนึ่งไปอีกห้อง (sticky client) และในห้องประชุมที่มีผู้ใช้จำนวนมาก AP ไม่สามารถรองรับการเชื่อมต่อพร้อมกันได้
ข้อกำหนดที่ควรระบุ:
- Wi-Fi standard: IEEE 802.11ax (Wi-Fi 6) เป็น minimum สำหรับโครงการใหม่ปี 2026
- Roaming standard: รองรับ IEEE 802.11r (Fast BSS Transition) และ 802.11k/v (Neighbor Report/BSS Transition Management) เพื่อ seamless roaming
- Capacity per AP: ระบุ concurrent client ที่ต้องรองรับได้จริง เช่น ไม่น้อยกว่า 50 concurrent users ต่อ AP พร้อม throughput ไม่น้อยกว่า 500 Mbps รวม
- Coverage requirement: ระดับ signal ไม่น้อยกว่า -67 dBm ในพื้นที่ใช้งานทุกจุด พิสูจน์ด้วย RF survey report หลังติดตั้ง
- Controller/Management: ระบุว่าต้องการ centralized management (cloud-based หรือ on-premise) และ feature ที่ต้องการ เช่น band steering, load balancing
หลีกเลี่ยงการระบุ "Wi-Fi Controller ยี่ห้อ X" เพราะ controller มักผูกกับ AP ของผู้ผลิตเดียวกัน ให้ระบุ feature ที่ต้องการแทน และอนุญาตให้ใช้ cloud-managed หรือ on-premise ได้ทั้งคู่
6. Section ที่หลุดบ่อย: Log retention (link PDPA + พ.ร.บ.คอมฯ)#
พ.ร.บ. ว่าด้วยการกระทำความผิดเกี่ยวกับระบบคอมพิวเตอร์ พ.ศ. 2550 (ฉบับแก้ไข 2560) มาตรา 26 กำหนดให้ผู้ให้บริการเก็บข้อมูล traffic log ไว้ไม่น้อยกว่า 90 วัน และต้องพร้อมส่งเมื่อเจ้าหน้าที่ร้องขอ
TOR ที่ไม่ระบุ log requirement จะทำให้ผู้รับจ้างติดตั้งระบบโดยไม่มี syslog server หรือ log aggregation ใดเลย ซึ่งเสี่ยงต่อการตรวจสอบจากหน่วยงานกำกับดูแล
สิ่งที่ TOR ต้องระบุ:
- Log types: Network device syslog (authentication, configuration change, interface up/down), DHCP lease log, Firewall/NAT session log
- Retention period: ไม่น้อยกว่า 90 วัน ตามพ.ร.บ.คอมพิวเตอร์ฯ และหากหน่วยงานมี PDPA obligation เพิ่มเติม ให้ระบุ 1 ปีเป็น best practice
- Log format: RFC 5424 Syslog หรือ CEF (Common Event Format) เพื่อให้ SIEM รองรับได้
- Storage: ระบุว่าเก็บ log บน dedicated log server หรือ SIEM ที่มีอยู่แล้ว และต้องมี integrity check (hash) ป้องกันการแก้ไข
- Access control: Log ต้องเข้าถึงได้เฉพาะ authorized administrator พร้อม audit trail ของการเข้าถึง log เอง
PDPA ไม่ได้กำหนดระยะเก็บ log โดยตรง แต่หากข้อมูลใน log ประกอบด้วย IP address ที่ระบุตัวบุคคลได้ ก็อยู่ภายใต้หลักการ data minimization และ storage limitation ซึ่งหมายถึงเก็บเท่าที่จำเป็นและมีกำหนดเวลาลบชัดเจน
7. Section ที่หลุดบ่อย: Warranty + Response time + Onsite#
TOR หลายฉบับระบุ "รับประกัน 1 ปี" โดยไม่มีรายละเอียดใด ทำให้เกิดข้อพิพาทเมื่ออุปกรณ์เสียและผู้รับจ้างอ้างว่า warranty ครอบคลุมเฉพาะการเปลี่ยนอะไหล่โดยไม่รวมค่าแรง หรือ response time ช้ากว่าที่หน่วยงานคาดหวัง
ข้อกำหนด warranty ที่ครบถ้วน:
- Warranty period: ระบุชัดว่า hardware warranty ต้องไม่น้อยกว่า 3 ปี สำหรับ core/distribution layer และ 1-3 ปีสำหรับ access layer ตามความเหมาะสมของวงเงิน
- Response time SLA: กำหนดแยกตาม severity เช่น Critical (network down) ต้องมีการตอบสนองภายใน 4 ชั่วโมง, Major ภายใน 8 ชั่วโมง, Minor ภายใน 1 วันทำการ
- Onsite support: ระบุว่าต้องการ onsite support หรือ remote support และหากต้องการ onsite ให้ระบุว่าต้องมีช่างในพื้นที่ (จังหวัด/ภาค) เพื่อลด response time จริง
- Spare part: กรณีอุปกรณ์หลักเสียและไม่สามารถซ่อมได้ภายใน X ชั่วโมง ผู้รับจ้างต้องจัดหาอุปกรณ์ทดแทน (loaner) มาแทนชั่วคราว
- EOL/EOS protection: หากผู้ผลิตประกาศ End-of-Support ระหว่างสัญญา ผู้รับจ้างต้องแจ้งล่วงหน้าและเสนอทางแก้ไข
8. ตัวอย่าง TOR snippet ใช้ได้จริง (vendor-neutral, copy-paste)#
ตัวอย่างข้อกำหนด Core Switch ที่เขียนแบบ vendor-neutral:
ข้อ 4.1 Core Switch
อุปกรณ์ Core Switch ต้องมีคุณสมบัติไม่น้อยกว่าดังต่อไปนี้:
- เป็น Layer 3 Managed Switch รองรับ switching capacity ไม่น้อยกว่า 480 Gbps
- รองรับ port SFP+ 10G ไม่น้อยกว่า 24 port และ QSFP+ 40G/100G ไม่น้อยกว่า 4 port
- รองรับ Routing Protocol: OSPF, BGP-4, VRRP/HSRP หรือ VRRP (สอดคล้อง RFC 5798)
- มี dual redundant power supply แบบ hot-swappable
- รองรับ Stacking หรือ VSS/MC-LAG เพื่อ logical redundancy
- รองรับ SNMP v2c/v3, Syslog (RFC 5424), REST API สำหรับ management
- อุปกรณ์ต้องไม่อยู่ในสถานะ End-of-Sale หรือ End-of-Support ณ วันที่ยื่นข้อเสนอ
ข้อ 4.2 Wireless Access Point
- รองรับ IEEE 802.11ax (Wi-Fi 6) dual-band (2.4 GHz และ 5 GHz)
- รองรับ IEEE 802.11r, 802.11k, 802.11v สำหรับ seamless roaming
- รองรับ concurrent user ไม่น้อยกว่า 50 clients ต่อ AP ที่ throughput รวมไม่น้อยกว่า 500 Mbps
- ระบบ centralized management ต้องรองรับ RF optimization อัตโนมัติและ report การใช้งาน
ข้อ 8.1 Log Retention
ผู้รับจ้างต้องติดตั้งระบบ syslog collection ที่สามารถเก็บ log จากอุปกรณ์เครือข่ายทุกตัวได้ไม่น้อยกว่า 90 วัน ตามพ.ร.บ. ว่าด้วยการกระทำความผิดเกี่ยวกับระบบคอมพิวเตอร์ฯ โดย log ต้องมี timestamp synchronized กับ NTP server (pool.ntp.org หรือ NTP server ของหน่วยงาน) และมีการป้องกันการแก้ไขด้วย checksum
9. สรุป + Action Priority#
การร่าง TOR ระบบเครือข่ายที่ผ่าน e-bidding ได้อย่างราบรื่นและได้ระบบที่ใช้งานได้จริงต้องเริ่มจาก 3 สิ่งสำคัญ ได้แก่ vendor-neutral spec ที่วัดได้, SLA ที่มีตัวเลขชัดเจน และ compliance clause ที่ครบถ้วน ลำดับความสำคัญในการแก้ไขหากเวลาจำกัด:
- ด่วนที่สุด: ลบการระบุยี่ห้อ/รุ่น หรือเพิ่มวลี "หรือเทียบเท่า" ทันที — ป้องกันการอุทธรณ์
- สำคัญ: เพิ่ม uptime SLA และ failover time ที่วัดได้ — กำหนดฐานการบังคับใช้สัญญา
- จำเป็นตามกฎหมาย: เพิ่ม log retention requirement 90 วัน — ปฏิบัติตามพ.ร.บ.คอมพิวเตอร์ฯ
- คุณภาพระบบ: เพิ่ม Wi-Fi roaming standard และ capacity spec — ลดปัญหาหลังส่งมอบ
- ป้องกันข้อพิพาท: เพิ่ม warranty response time และ onsite requirement ที่ชัดเจน
ก่อนส่ง TOR ให้ผ่านการ review โดยบุคคลที่ไม่ใช่ผู้เขียน อ่านจากมุมมองผู้ค้าที่ต้องการแข่งขัน หากพบจุดที่ตีความได้มากกว่าหนึ่งแบบ ให้แก้ไขให้ชัดก่อนประกาศ
C9NETWORK ให้บริการ consult การร่าง TOR ระบบเครือข่ายแบบ vendor-neutral สำหรับหน่วยงานราชการและรัฐวิสาหกิจ พร้อมรีวิว spec เดิมและเสนอข้อกำหนดที่ผ่าน e-bidding ได้อย่างถูกต้องตามระเบียบกระทรวงการคลัง หากต้องการความช่วยเหลือในการร่างหรือตรวจทาน TOR ติดต่อทีมงาน C9NETWORK ได้เลย