Tweet
Network Maintenance — Vì sao nhiều kỹ sư mạng luôn bận “chữa cháy” nhưng hệ thống vẫn không ổn định?
Trong rất nhiều doanh nghiệp, có một nghịch lý khá quen thuộc.
Network team lúc nào cũng bận. Ngày nào cũng có ticket. Người dùng liên tục báo lỗi:
Nhìn từ bên ngoài, có vẻ team mạng làm việc rất vất vả. Nhưng kỳ lạ là hệ thống vẫn thiếu ổn định. Vấn đề nằm ở đâu?
Câu trả lời thường không nằm ở thiết bị.
Nó nằm ở cách vận hành hệ thống mạng.
Network Maintenance thực sự là gì?
Nhiều người nghĩ network maintenance đơn giản là:
“Thiết bị hỏng thì sửa.”
Đó chỉ là một phần rất nhỏ.
Trong môi trường enterprise, network maintenance là toàn bộ hoạt động nhằm giữ cho hạ tầng mạng:
Điều này bao gồm:
Network maintenance không phải sửa mạng.
Network maintenance là vận hành mạng như một hệ thống sản xuất (production system).
Hai kiểu kỹ sư mạng
Quan sát thực tế, có thể chia đội ngũ vận hành thành hai kiểu.
Kiểu 1: Firefighter Engineer (Chữa cháy)
Đặc trưng:
Workflow quen thuộc:
User báo lỗi → SSH vào thiết bị → sửa gì đó → hy vọng hết lỗi.
Ban đầu cách này có vẻ hiệu quả.
Nhưng khi hệ thống lớn lên:
thì mô hình này sụp đổ.
Kiểu 2: Structured Operations Engineer (Hoạt động có cấu trúc bài bản)
Đặc trưng:
Nguyên tắc:
Fix problems before users notice them.
Đây là cách vận hành của mature enterprise.
Firefighting là dấu hiệu của vận hành yếu
Interrupt-driven work không thể tránh hoàn toàn.
Ví dụ:
Nhưng nếu phần lớn thời gian của team chỉ để chữa cháy…
thì đó không phải dấu hiệu của “team chăm chỉ”.
Đó là dấu hiệu của: trưởng thành trong công tác vận hành mạng.
operational immaturity.
FCAPS — Framework kinh điển của vận hành mạng
Một trong những framework kinh điển nhất là FCAPS.
Nhiều người học certification có nghe qua, nhưng ít người áp dụng thực sự.
FCAPS gồm:
Điều thú vị là framework này vẫn cực kỳ phù hợp trong enterprise hiện đại.
F — Fault Management
Mục tiêu:
Phát hiện lỗi sớm nhất có thể.
Nếu user là người đầu tiên phát hiện lỗi…
thì monitoring của bạn thất bại.
Ví dụ enterprise cần giám sát:
Công cụ:
Best practice:
Không chỉ thu thập log.
Phải có:
Nếu không, bạn chỉ tạo ra log noise.
C — Configuration Management
Enterprise network không chết vì packet.
Nó thường chết vì con người.
Ví dụ:
Configuration management giúp kiểm soát thay đổi.
Nguyên tắc:
Mọi thay đổi đều phải:
Câu hỏi quan trọng:
Ai đã thay đổi cái gì? Khi nào? Vì sao?
Nếu không trả lời được…
bạn đang vận hành bằng niềm tin.
A — Accounting Management
Phần này thường ít được nhắc trong enterprise.
Nhưng rất quan trọng trong:
Ví dụ:
Modern equivalent:
Cloud FinOps cũng chính là một dạng accounting mindset.
P — Performance Management
Một mạng “đang chạy” chưa chắc là mạng “đang tốt”.
Ví dụ:
BGP up.
Nhưng:
Performance management giúp thấy vấn đề trước khi outage xảy ra.
Metrics nên theo dõi:
Layer 2:
Layer 3:
WAN:
Wireless:
S — Security Management
Một network ổn định nhưng không an toàn vẫn là thất bại.
Security maintenance gồm:
Ví dụ:
Một expired certificate có thể làm VPN outage.
Một AAA misconfiguration có thể lockout admin.
Security không phải dự án một lần.
Nó là maintenance liên tục.
Change Management — thứ cứu bạn khỏi thảm họa
Đây là phần rất nhiều kỹ sư trẻ xem nhẹ.
Ví dụ:
“Em chỉ đổi có một ACL thôi.”
Ba tiếng sau:
Tại sao?
Vì thay đổi nhỏ có thể có blast radius lớn.
Change management yêu cầu trả lời: Ai phê duyệt?
Network lead?
Security?
CAB?
Khi nào thay đổi?
Production giờ làm việc?
Hay maintenance window?
Rollback là gì?
Nếu fail:
Rollback mất bao lâu?
5 phút?
30 phút?
2 tiếng?
Ai cập nhật documentation?
Nếu không update docs:
tài liệu chết ngay sau lần change đầu tiên.
Backup — thứ bạn chỉ nhớ khi disaster xảy ra
Rất nhiều team “có backup”.
Nhưng hỏi:
“restore thử chưa?”
=> im lặng.
Backup thực sự phải:
Ví dụ:
Không chỉ backup:
show running-config
Mà phải có:
Documentation — dấu hiệu của đội ngũ trưởng thành
Network documentation tốt thường gồm: Physical topology
Cho biết:
thiết bị nào cắm với thiết bị nào.
Logical topology
Cho biết:
IP addressing plan
Nếu không có:
rất nhanh sẽ thành địa ngục subnet.
Inventory
Phải biết:
Design decision records
Cực kỳ quan trọng.
Ví dụ:
“Tại sao WAN dùng dual hub?”
“Tại sao OSPF area thiết kế kiểu này?”
Nếu architect nghỉ việc và không ai biết…
đó là technical debt.
Configuration Templates — tiêu chuẩn hóa để giảm lỗi
Một enterprise tốt không cấu hình “theo cảm hứng”.
Ví dụ access port template:
Nếu 10 engineer cấu hình 10 kiểu khác nhau:
troubleshooting sẽ là cơn ác mộng.
Template mang lại:
Modern evolution:
Góc nhìn thực chiến
Nếu team của bạn luôn bận chữa cháy…
hãy hỏi:
Mạng hoạt động ổn định không đến từ may mắn, nó đến từ viêc tuân thủ nguyên tắc quản lý!
Trong rất nhiều doanh nghiệp, có một nghịch lý khá quen thuộc.
Network team lúc nào cũng bận. Ngày nào cũng có ticket. Người dùng liên tục báo lỗi:
- Wi-Fi chập chờn
- VPN không vào được
- Voice call bị giật
- ERP chậm
- Branch office mất WAN
- Firewall CPU cao
- Core switch báo lỗi interface
Nhìn từ bên ngoài, có vẻ team mạng làm việc rất vất vả. Nhưng kỳ lạ là hệ thống vẫn thiếu ổn định. Vấn đề nằm ở đâu?
Câu trả lời thường không nằm ở thiết bị.
Nó nằm ở cách vận hành hệ thống mạng.
Network Maintenance thực sự là gì?
Nhiều người nghĩ network maintenance đơn giản là:
“Thiết bị hỏng thì sửa.”
Đó chỉ là một phần rất nhỏ.
Trong môi trường enterprise, network maintenance là toàn bộ hoạt động nhằm giữ cho hạ tầng mạng:
- Available
- Stable
- Predictable
- Secure
- Scalable
Điều này bao gồm:
- Troubleshooting
- Monitoring
- Capacity planning
- Hardware lifecycle management
- Software lifecycle management
- Configuration governance
- Documentation
- Security operations
- Change management
- Compliance
Network maintenance không phải sửa mạng.
Network maintenance là vận hành mạng như một hệ thống sản xuất (production system).
Hai kiểu kỹ sư mạng
Quan sát thực tế, có thể chia đội ngũ vận hành thành hai kiểu.
Kiểu 1: Firefighter Engineer (Chữa cháy)
Đặc trưng:
- chỉ phản ứng khi có sự cố
- không monitoring
- không baseline
- không documentation
- backup không rõ ở đâu
- thay đổi cấu hình trực tiếp trên production
- không rollback plan
Workflow quen thuộc:
User báo lỗi → SSH vào thiết bị → sửa gì đó → hy vọng hết lỗi.
Ban đầu cách này có vẻ hiệu quả.
Nhưng khi hệ thống lớn lên:
- 50 switch
- 200 AP
- nhiều branch
- firewall cluster
- MPLS / Internet hybrid WAN
- cloud connectivity
thì mô hình này sụp đổ.
Kiểu 2: Structured Operations Engineer (Hoạt động có cấu trúc bài bản)
Đặc trưng:
- giám sát chủ động
- có maintenance plan
- có configuration standard
- có change control
- có rollback
- có documentation
- có capacity planning
Nguyên tắc:
Fix problems before users notice them.
Đây là cách vận hành của mature enterprise.
Firefighting là dấu hiệu của vận hành yếu
Interrupt-driven work không thể tránh hoàn toàn.
Ví dụ:
- PSU hỏng
- ISP outage
- optic module fail
- routing process crash
- firmware bug
- unexpected broadcast storm
Nhưng nếu phần lớn thời gian của team chỉ để chữa cháy…
thì đó không phải dấu hiệu của “team chăm chỉ”.
Đó là dấu hiệu của: trưởng thành trong công tác vận hành mạng.
operational immaturity.
FCAPS — Framework kinh điển của vận hành mạng
Một trong những framework kinh điển nhất là FCAPS.
Nhiều người học certification có nghe qua, nhưng ít người áp dụng thực sự.
FCAPS gồm:
- Fault
- Configuration
- Accounting
- Performance
- Security
Điều thú vị là framework này vẫn cực kỳ phù hợp trong enterprise hiện đại.
F — Fault Management
Mục tiêu:
Phát hiện lỗi sớm nhất có thể.
Nếu user là người đầu tiên phát hiện lỗi…
thì monitoring của bạn thất bại.
Ví dụ enterprise cần giám sát:
- interface up/down
- BGP adjacency loss
- OSPF neighbor down
- VPN tunnel drop
- AP disconnect
- switch stack member failure
- PSU failure
- fan failure
- high CPU
- high memory
- packet drop
Công cụ:
- Syslog
- SNMP
- Telemetry
- NetFlow
- ThousandEyes
- Catalyst Center
- SolarWinds
- PRTG
- LibreNMS
Best practice:
Không chỉ thu thập log.
Phải có:
- alerting
- escalation
- correlation
- threshold tuning
Nếu không, bạn chỉ tạo ra log noise.
C — Configuration Management
Enterprise network không chết vì packet.
Nó thường chết vì con người.
Ví dụ:
- xóa nhầm route
- apply ACL sai
- NAT rule shadow
- trunk VLAN mismatch
- STP config inconsistency
- QoS policy typo
Configuration management giúp kiểm soát thay đổi.
Nguyên tắc:
Mọi thay đổi đều phải:
- documented
- approved
- traceable
- reversible
Câu hỏi quan trọng:
Ai đã thay đổi cái gì? Khi nào? Vì sao?
Nếu không trả lời được…
bạn đang vận hành bằng niềm tin.
A — Accounting Management
Phần này thường ít được nhắc trong enterprise.
Nhưng rất quan trọng trong:
- ISP
- MSP
- Guest network
- chargeback model
- cloud consumption tracking
Ví dụ:
- guest Wi-Fi billing
- department usage reporting
- WAN bandwidth chargeback
Modern equivalent:
Cloud FinOps cũng chính là một dạng accounting mindset.
P — Performance Management
Một mạng “đang chạy” chưa chắc là mạng “đang tốt”.
Ví dụ:
BGP up.
Nhưng:
- latency tăng
- packet loss tăng
- jitter tăng
- voice quality giảm
Performance management giúp thấy vấn đề trước khi outage xảy ra.
Metrics nên theo dõi:
Layer 2:
- interface utilization
- CRC
- drops
- STP events
Layer 3:
- routing churn
- ARP anomalies
- ICMP latency
WAN:
- packet loss
- MOS
- jitter
- SLA compliance
Wireless:
- channel utilization
- retry rate
- roaming performance
- SNR
- interference
S — Security Management
Một network ổn định nhưng không an toàn vẫn là thất bại.
Security maintenance gồm:
- firewall policy review
- VPN health
- AAA validation
- certificate lifecycle
- patching
- IDS/IPS monitoring
- segmentation audit
- access control review
Ví dụ:
Một expired certificate có thể làm VPN outage.
Một AAA misconfiguration có thể lockout admin.
Security không phải dự án một lần.
Nó là maintenance liên tục.
Change Management — thứ cứu bạn khỏi thảm họa
Đây là phần rất nhiều kỹ sư trẻ xem nhẹ.
Ví dụ:
“Em chỉ đổi có một ACL thôi.”
Ba tiếng sau:
- ERP chết
- VoIP lỗi
- branch mất kết nối
Tại sao?
Vì thay đổi nhỏ có thể có blast radius lớn.
Change management yêu cầu trả lời: Ai phê duyệt?
Network lead?
Security?
CAB?
Khi nào thay đổi?
Production giờ làm việc?
Hay maintenance window?
Rollback là gì?
Nếu fail:
- restore config?
- remove policy?
- fail back ISP?
- revert software?
Rollback mất bao lâu?
5 phút?
30 phút?
2 tiếng?
Ai cập nhật documentation?
Nếu không update docs:
tài liệu chết ngay sau lần change đầu tiên.
Backup — thứ bạn chỉ nhớ khi disaster xảy ra
Rất nhiều team “có backup”.
Nhưng hỏi:
“restore thử chưa?”
=> im lặng.
Backup thực sự phải:
- automated
- versioned
- tested
- recoverable
Ví dụ:
Không chỉ backup:
show running-config
Mà phải có:
- archived configs
- golden configs
- firmware images
- license info
- inventory metadata
Documentation — dấu hiệu của đội ngũ trưởng thành
Network documentation tốt thường gồm: Physical topology
Cho biết:
thiết bị nào cắm với thiết bị nào.
Logical topology
Cho biết:
- VLAN
- subnet
- routing domain
- VRF
- WAN topology
IP addressing plan
Nếu không có:
rất nhanh sẽ thành địa ngục subnet.
Inventory
Phải biết:
- model
- serial
- software version
- EOL status
- contract info
Design decision records
Cực kỳ quan trọng.
Ví dụ:
“Tại sao WAN dùng dual hub?”
“Tại sao OSPF area thiết kế kiểu này?”
Nếu architect nghỉ việc và không ai biết…
đó là technical debt.
Configuration Templates — tiêu chuẩn hóa để giảm lỗi
Một enterprise tốt không cấu hình “theo cảm hứng”.
Ví dụ access port template:
- portfast
- bpduguard
- port security
- description standard
Nếu 10 engineer cấu hình 10 kiểu khác nhau:
troubleshooting sẽ là cơn ác mộng.
Template mang lại:
- consistency
- auditability
- speed
- predictability
Modern evolution:
- Ansible templates
- Terraform
- Cisco NSO
- model-driven automation
Góc nhìn thực chiến
Nếu team của bạn luôn bận chữa cháy…
hãy hỏi:
- monitoring đủ chưa?
- baseline có chưa?
- config standard có chưa?
- backup test chưa?
- documentation sống hay chết?
- change control có thật không?
Mạng hoạt động ổn định không đến từ may mắn, nó đến từ viêc tuân thủ nguyên tắc quản lý!