/ tất cả bài học → CHẶNG 01 · Networking ( CCNA )

Bài 01

Vì sao DevOps phải hiểu Network? Lộ trình và mindset

04 tháng 5, 2026 · 30 phút đọc

Bài 01 — Vì sao DevOps phải hiểu Network? Lộ trình và mindset

Chặng 01 — Networking | Bài 01 | Thời lượng: 45–60 phút

Tiền đề: Biết dùng terminal Linux cơ bản. Đã từng nghe qua "IP", "router", nhưng chưa cần thuộc.

Phần 1 — Tại sao bài này quan trọng với DevOps?

Bài này là bài khai mạc của cả chặng — bạn chưa cần học command nào. Mục tiêu là trả lời câu hỏi: DevOps thì học network để làm gì, học sâu đến đâu, học theo lộ trình nào? Trả lời sai câu này, bạn sẽ học sai cách: hoặc học quá lý thuyết kiểu CCNA chuẩn (mất 3 tháng học những thứ đời này không bao giờ dùng), hoặc học quá nông kiểu "biết IP với port là đủ" (rồi sự cố production xảy ra, đứng nhìn log không biết làm gì).

Mình đã thấy cả hai loại. Một bạn học CCNA đầy đủ ở trung tâm 6 tháng, vào công ty mình ngày đầu tiên gặp Kubernetes thì bối rối — vì khoá đó dạy Cisco IOS chứ không dạy tcpdump, không dạy network namespace. Một bạn khác tự học, biết dùng Docker khá ổn, nhưng đến lúc service trong K8s gọi nhau bị MTU mismatch thì không biết đường nào mà lần. Cả hai đều thiếu một thứ giống nhau: cái khung tư duy network gắn với công việc DevOps thực tế.

Bài này dựng cái khung đó. Sau bài này bạn sẽ biết: 22 bài tiếp theo giải quyết vấn đề gì, vì sao sắp xếp theo thứ tự đó, đến mức nào thì gọi là "đủ dùng để đi làm". Và bạn sẽ setup xong môi trường lab — lab thật sự chạy được, không phải coi mấy cái screenshot trên slide.

Phần 2 — Bản chất vấn đề: Mindset DevOps khác Network Engineer thuần

Trước hết, phải tách bạch: Network Engineer thuần (kiểu kỹ sư hệ thống mạng, làm cho ISP/datacenter/Cisco) và DevOps Engineer học network — hai vai trò này dùng kiến thức network khác nhau.

Network Engineer thuần ngồi với router/switch vật lý hàng ngày. Họ phải thuộc Cisco IOS, biết cấu hình OSPF area type, debug spanning tree convergence, tune BGP timers. Họ ít khi đụng đến code application.

DevOps Engineer thì khác. Bạn không cấu hình router vật lý — đó là việc của team Network hoặc của cloud provider (AWS, GCP đã lo phần đó). Bạn cũng không design lại routing protocol cho cả công ty. Việc của bạn là: đảm bảo application chạy được trên hạ tầng mạng đó. Khi sự cố xảy ra, bạn phải biết nó là vấn đề của application code, của container network, của cloud security group, hay của DNS — và xử lý đúng người.

Cụ thể, mindset DevOps về network là:

1. Hiểu để debug, không phải để cấu hình. Bạn cần biết cách packet đi từ A đến B, biết tầng nào có thể fail, biết tool nào để xem ở tầng đó — chứ không cần thuộc cú pháp router ospf 1 của Cisco.

2. Linux first, không phải Cisco first. 95% network mà DevOps đụng vào nằm trên Linux: container, K8s, cloud VM. Nên ip route, iptables, tcpdump quan trọng hơn show ip route của Cisco. Mình vẫn dạy switch/router để hiểu khái niệm, nhưng trọng tâm là Linux networking.

3. Network là một tầng trong stack — không phải vũ trụ riêng. Bạn phải biết network kết nối với application và infrastructure ra sao: DNS lỗi → app báo gì? MTU sai → K8s pod biểu hiện thế nào? TLS handshake fail → log microservice ra dòng gì?

4. Đủ sâu để debug 80% sự cố, biết đủ để hỏi đúng người cho 20% còn lại. Bạn không cần thành chuyên gia BGP — đủ để biết khi nào cần kéo team Network vào cuộc.

Với mindset này, lộ trình 22 bài được thiết kế để bạn đi đúng vào những thứ DevOps thật sự dùng — không lan man.

Phần 3 — Đi sâu: 4 mức năng lực và lộ trình

3.1 Bốn mức năng lực network của một DevOps

Mình hay dùng thước đo này khi phỏng vấn và onboard:

┌──────────────────────────────────────────────────────────┐
│ Mức 1 — Biết khái niệm                                   │
│   "Em biết IP là gì, biết router làm gì."                │
│   → Học từ sách, chưa bao giờ debug thật.                │
├──────────────────────────────────────────────────────────┤
│ Mức 2 — Đọc được trace                                   │
│   "Đưa em output tcpdump, em chỉ ra được 3-way handshake │
│    có thành công không, TLS có fail không."              │
│   → Bắt đầu hữu dụng cho team.                           │
├──────────────────────────────────────────────────────────┤
│ Mức 3 — Tự debug được sự cố                              │
│   "App báo timeout — em tự lần ra được nguyên nhân,      │
│    dùng đúng tool ở đúng tầng, không cần ai chỉ."        │
│   → Đủ làm DevOps Engineer.                              │
├──────────────────────────────────────────────────────────┤
│ Mức 4 — Thiết kế được hạ tầng network                    │
│   "Em thiết kế VPC, subnet layout, routing, security     │
│    group cho một hệ thống microservice từ đầu."          │
│   → Senior/Lead DevOps.                                  │
└──────────────────────────────────────────────────────────┘

Sau chặng này, bạn ở giữa mức 2 và mức 3. Mức 4 là chuyện của các chặng sau (Container, Orchestration, CI/CD) khi đã có context cụ thể về production load.

3.2 Lộ trình 22 bài

Lộ trình chia 6 phần (xem chi tiết trong file chang-01-networking-curriculum.md):

A. Khái niệm nền        (Bài 1–5)   ──┐
                                       │ Mức 1 → Mức 2
B. Hạ tầng mạng         (Bài 6–10)  ──┘

C. Protocols nền        (Bài 11–14) ──┐
                                       │ Mức 2 → Mức 3
D. Application & Sec    (Bài 15–18) ──┘

E. Linux thực chiến     (Bài 19–21) ──┐
                                       │ Sẵn sàng cho chặng 02-04
F. Capstone             (Bài 22)    ──┘

Tại sao thứ tự này? Vài nguyên tắc:

Khái niệm nền trước hạ tầng: Phải hiểu IP, packet, OSI trước khi nói switch/router làm gì. Switch và router chỉ là thiết bị thực thi các khái niệm đó.
Protocols sau hạ tầng: TCP, DNS sống trên IP. Chưa hiểu IP thì học TCP cũng nghe ù tai.
Linux để cuối: Linux networking là ứng dụng của tất cả những gì học trên. Học Linux trước sẽ thiếu context — học sau thì mọi thứ chốt lại.
Capstone là bài tổng hợp: MTU/fragmentation đặt cuối vì nó dùng kiến thức của mọi tầng. Lab capstone mô phỏng một sự cố production thật.

3.3 Mỗi bài bạn cần đầu tư bao nhiêu?

Mỗi bài thiết kế cho 60–90 phút — gồm: đọc lý thuyết (~~20 phút) + làm lab (~~30–60 phút) + làm câu hỏi tự kiểm tra. Đừng đọc xong rồi skip lab — đọc 10 bài không lab thua xa làm chắc 1 bài có lab. Mình đảm bảo điều đó qua kinh nghiệm onboard rất nhiều bạn.

Phần 4 — Câu chuyện hiện trường

💡 Một lần ở production...

Tháng 3/2023, team mình tuyển một bạn intern DevOps — tạm gọi là H. H học CNTT, GPA tốt, đã làm vài project Docker cá nhân. Phỏng vấn vào câu hỏi network thì trả lời rất tự tin: "Em biết TCP/IP, biết HTTP, biết container network rồi anh."

Tuần thứ 2 onboard, mình giao cho H task nhỏ: deploy thêm một service Node.js vào cluster K8s staging, expose qua Ingress. Code và Helm chart đã có sẵn từ template. Đáng lẽ là task 2 tiếng.

H làm gần một ngày không xong. Đến chiều, H nói: "Anh ơi, em deploy được rồi nhưng gọi API qua Ingress nó báo 502 Bad Gateway. Em google nhưng không hiểu lý do."

Mình ngồi cùng H 30 phút. Hỏi:

— "Em đã kubectl get pods chưa?" → Pods Running.
— "kubectl logs có lỗi gì không?" → Không, app log thấy bình thường.
— "Em đã kubectl exec vào pod rồi curl localhost:3000 thử chưa?" → H ngơ ngác. "Sao phải làm vậy ạ?"

Mình bảo H làm thử. Kết quả: curl: (7) Failed to connect to localhost port 3000. App đang listen ở 127.0.0.1:3000 — chỉ accept connection từ trong chính container, không phải 0.0.0.0:3000. Service K8s gửi traffic vào container qua IP của pod — không phải 127.0.0.1 — nên bị refuse.

H nói: "Em không biết là 127.0.0.1 với 0.0.0.0 nó khác nhau." Đó là kiến thức của Bài 02 trong chặng này.

Ngày hôm sau mình ngồi với H thêm 1 tiếng vẽ lại từ đầu: máy tính có nhiều interface (lo, eth0...), mỗi interface có IP riêng. Bind 127.0.0.1 chỉ accept loopback — bind 0.0.0.0 accept mọi interface. Đây là kiến thức cơ bản tới mức ai cũng "biết" — nhưng H không thực sự hiểu nên không liên hệ được khi gặp lỗi.

Bài học rút ra:

"Biết khái niệm" và "hiểu để dùng" là hai chuyện khác nhau. H đã biết IP, biết localhost — nhưng không nội hoá được mức để áp dụng khi debug. Đó là Mức 1, chưa lên được Mức 2.

Mỗi sự cố production đều test lại kiến thức nền. Network học vững → debug nhanh. Học hời → ngồi nhìn log nửa ngày.

Tốc độ debug là một KPI ngầm của DevOps. Không ai đánh giá bạn qua bài kiểm tra lý thuyết — họ đánh giá qua việc bạn lần ra root cause của một sự cố trong bao lâu.

Phần 5 — Lab thực hành: Setup môi trường lab xuyên chặng

Mục tiêu: Sau lab này bạn có một môi trường lab hoạt động được, dùng cho toàn bộ 22 bài sau này. Lab này không kiểm tra kiến thức — nó là khâu chuẩn bị.

Môi trường: Laptop chạy Windows/macOS/Linux, RAM ≥ 8GB (ideal 16GB), ổ cứng còn ≥ 30GB.

Các bước

Bước 1 — Cài VirtualBox

VirtualBox là phần mềm tạo máy ảo — bạn sẽ chạy Linux server bên trong máy chính của mình. Vào https://www.virtualbox.org/wiki/Downloads, tải bản phù hợp OS, cài như cài app bình thường.

Bước 2 — Tạo Ubuntu Server VM

Tải Ubuntu Server 22.04 LTS ISO từ https://ubuntu.com/download/server. Trong VirtualBox, tạo VM mới với cấu hình:

Tên:        devops-lab-01
RAM:        2048 MB
CPU:        2 cores
Ổ cứng:     20 GB
Network:    NAT (mặc định, sẽ đổi sau)

Khởi động VM, chọn ISO Ubuntu Server, cài đặt theo hướng dẫn. Lúc cài, chọn tuỳ chọn cài OpenSSH để sau này SSH từ máy thật vào VM được.

Sau khi cài xong, login vào VM, chạy:

# Cập nhật package list và upgrade hệ thống
sudo apt update && sudo apt upgrade -y

# Cài bộ tool networking cơ bản — sẽ dùng xuyên suốt khoá học
sudo apt install -y net-tools iproute2 iputils-ping traceroute mtr-tiny tcpdump dnsutils curl wget tmux vim

Bước 3 — Cài Cisco Packet Tracer (cho bài 06–10)

Packet Tracer mô phỏng switch/router Cisco — không cần phần cứng thật. Tải từ https://www.netacad.com/courses/packet-tracer (cần đăng ký tài khoản miễn phí Cisco NetAcad).

Lưu ý: Packet Tracer chỉ dùng cho 5 bài về switch/router. Đa số bài còn lại dùng Linux.

Bước 4 — Cài Wireshark trên máy thật (host)

Tải từ https://www.wireshark.org/download.html. Lab phần lớn chạy trên VM, nhưng Wireshark cài host để bắt cả traffic của host lẫn VM.

Bước 5 — Verify môi trường

Trên VM, chạy:

# Kiểm tra interface mạng - phải thấy ít nhất 'lo' và 'enp0s3' (hoặc tương tự)
ip addr show

# Kiểm tra ra được Internet
ping -c 3 8.8.8.8

# Kiểm tra DNS
nslookup google.com

# Kiểm tra tcpdump chạy được (cần sudo)
sudo tcpdump -c 5 -i any

Trên máy thật, mở Packet Tracer → tạo một workspace trống → kéo 1 PC và 1 Switch ra → nối lại. Chỉ cần đảm bảo app chạy được, chưa cần cấu hình gì.

Kết quả mong đợi:

VM Ubuntu chạy được, ping ra Internet thông
Đầy đủ tool networking đã cài
Packet Tracer mở được, kéo thả thiết bị được
Wireshark mở được trên host

Self-check:

Trên VM, gõ ip addr show eth0 (hoặc tên interface tương tự). Bạn thấy IP gì? IP đó là Public hay Private? (Sẽ giải thích ở Bài 05.)
SSH từ máy thật vào VM xem có vào được không. Nếu không, có thể cần config Port Forwarding trong VirtualBox.
Chạy sudo tcpdump -i any -c 10 rồi mở browser truy cập một website. Bạn thấy có packet xuất hiện không?

Phần 6 — Best practices

1. Học theo lộ trình, đừng nhảy bài

WHY: Mỗi bài giả định bạn đã thuộc bài trước. Nhảy đến bài 17 (TLS) khi chưa hiểu Bài 03 (TCP/IP) sẽ không hiểu vì sao TLS dựng trên TCP.

HOW: Đọc tuần tự. Nếu bí, tra lại bài trước thay vì Google.

2. Làm lab — không skip

WHY: Network là kiến thức cơ thể (muscle memory). Đọc 100 lần không bằng làm 1 lần. Lab thiết kế để bạn gõ, lỗi, tự sửa — đó mới là học thật.

HOW: Mỗi bài mở terminal làm theo từng command. Khi gặp lỗi không như mong đợi, đọc message → đoán nguyên nhân → fix. Đừng copy-paste mù.

3. Ghi chép ngắn gọn — bằng ngôn ngữ của mình

WHY: Đọc xong tưởng hiểu, vài tuần là quên. Viết lại bằng cách hiểu của mình giúp encode dài hạn.

HOW: Sau mỗi bài, mở Notion/Obsidian/Google Docs, viết 5–10 dòng tóm tắt: "Bài này dạy gì, tôi nhớ nhất điều gì, lab tôi gặp lỗi nào". Một năm sau giở lại sẽ cảm ơn bản thân.

4. Tập tư duy "tầng nào?" mỗi khi gặp lỗi

WHY: Đây là thói quen quan trọng nhất. Mọi sự cố network đều có thể quy về một tầng cụ thể.

HOW: Mỗi khi bạn gặp lỗi network (kể cả lỗi trên máy cá nhân — wifi không vào được, file tải bị chậm), trước khi Google, dừng 30 giây tự hỏi: "Đây là Layer mấy?".

5. Đừng ngại hỏi — nhưng hỏi sau khi đã thử

WHY: Hỏi mà chưa tự thử = không nhớ câu trả lời. Tự thử rồi vẫn không ra → hỏi → câu trả lời sẽ in vào đầu.

HOW: Quy tắc 30 phút: tự debug 30 phút trước khi đi hỏi. Khi hỏi, mô tả: bạn đã làm gì, kết quả ra sao, đã thử cái gì.

Phần 7 — Pitfalls — Những lối học sai cần tránh

Pitfall 1: Học CCNA truyền thống một cách máy móc

Triệu chứng: Học thuộc lòng câu lệnh Cisco IOS, thi xong CCNA nhưng không debug được lỗi DNS đơn giản.
Nguyên nhân: CCNA chuẩn dạy Network Engineer, không phải DevOps. Có những phần (như STP convergence, OSPF area type) đời DevOps không bao giờ đụng.
Phòng tránh: Theo lộ trình của khoá này — đã filter sẵn cho DevOps. Nếu bạn vẫn muốn cert CCNA cho CV, xong khoá này có thể tự bổ sung 20% còn lại trong vài tuần.

Pitfall 2: Skip lý thuyết vì "anh em coder không cần"

Triệu chứng: "Em biết Docker rồi, em có cần học OSI không?". Vài tháng sau gặp MTU mismatch là đứng hình.
Nguyên nhân: Coi container là "magic" thay vì hiểu nó là Linux network namespace + bridge.
Phòng tránh: Học từ Bài 01. Container network ở chặng 04 sẽ rất nhẹ nhàng nếu nền vững.

Pitfall 3: Học chay, không có môi trường lab

Triệu chứng: Đọc xong cả khoá, mở terminal là quên hết command.
Nguyên nhân: Não nhớ cái nó làm, không nhớ cái nó đọc.
Phòng tránh: Lab Phần 5 là bắt buộc. Không setup được môi trường lab, đừng đọc tiếp các bài sau.

Pitfall 4: Phụ thuộc vào AI, copy-paste mọi command

Triệu chứng: Hỏi ChatGPT cho mọi vấn đề, dán command vào terminal mà không biết nó làm gì.
Nguyên nhân: Tiện. Nhưng đến lúc AI bịa command sai, hoặc lúc không có Internet (off-site, customer site), bạn không xoay được.
Phòng tránh: Quy tắc: Mỗi command AI gợi ý, bạn phải hiểu ít nhất 70% trước khi chạy. Không hiểu → đọc man hoặc docs trước.

Pitfall 5: Tham học nhiều thứ song song

Triệu chứng: Vừa học CCNA, vừa AWS, vừa Kubernetes, vừa Python — không cái nào sâu.
Nguyên nhân: FOMO. Nhưng não người không multitask hiệu quả với kỹ năng kỹ thuật.
Phòng tránh: Một chặng một lúc. Network xong rồi sang System. Sang Container thì gác Network lại — nó sẽ tự được củng cố qua thực hành ở các chặng sau.

Phần 8 — Liên kết với DevOps thực tế

Network không phải kiến thức "học xong cất tủ". Nó tái xuất ở mọi chặng sau:

Chặng 02 — System: Hiểu network giúp bạn đọc được output của ss, netstat, lsof -i — những lệnh dùng hằng ngày để debug system.
Chặng 03 — Virtualization: Network của VM (NAT, Bridge, Host-Only) là ứng dụng trực tiếp của Bài 06–08.
Chặng 04 — Container: Container network = Linux network namespace + bridge + iptables. Đúng những gì học ở Bài 19–21.
Chặng 05 — Kubernetes: CNI (Calico, Flannel) là overlay network. Service ClusterIP/NodePort/LoadBalancer là ứng dụng của Layer 4. Ingress là Layer 7. Không có nền network, K8s nhìn như phép thuật.
Chặng 06 — CI/CD: Pipeline thường gặp lỗi network: kết nối được tới Git? Pull được Docker image từ registry? Deploy được vào staging cluster? Toàn debug network.
Chặng 07 — Observability: Metrics network (latency, packet loss, RTT), tracing distributed systems — dựa hết trên hiểu biết về TCP và HTTP.

Đặc biệt: Khi đi phỏng vấn DevOps, 90% câu hỏi technical đều có thành phần network. Không có cách nào tránh.

Phần 9 — Dùng AI thông minh khi học chặng này

Prompt tốt 1 — Hỏi để xác minh hiểu:

Tao đang học [chủ đề]. Cách hiểu của tao là [diễn đạt bằng từ của tao].
Cách hiểu này có chính xác không? Có lỗ hổng gì không?

Prompt tốt 2 — Hỏi để thấy ví dụ thực tế:

Trong môi trường Kubernetes production thật, [khái niệm A] biểu hiện như thế nào?
Cho tao 1 ví dụ cụ thể về sự cố liên quan và cách debug.

Prompt tốt 3 — Hỏi để tạo câu hỏi luyện tập:

Tao vừa học xong bài [N] về [chủ đề]. Hãy ra cho tao 5 câu hỏi tình huống
(không phải lý thuyết) để kiểm tra xem tao có thực sự hiểu không.

Cảnh báo:

AI hay bịa command Cisco IOS — như mình đã nhắc ở bài 03. Mọi command Cisco lấy từ AI, verify với docs Cisco hoặc lab thử trong Packet Tracer.
AI có thể nhầm version Linux — ifconfig đã deprecated, nhưng AI thỉnh thoảng vẫn khuyên dùng. Khoá này dạy ip (modern) thay cho ifconfig.
AI không thay được lab — Đừng để AI "làm hộ" lab. Nó có thể đưa output mẫu, nhưng bạn không gõ vào terminal thì không nhớ.

Phần 10 — Tóm tắt: 3 điều cần khắc cốt

DevOps học network để debug, không phải để cấu hình thiết bị. Mindset Linux first, không phải Cisco first. 95% network bạn đụng vào nằm trên Linux.
Có 4 mức năng lực — sau chặng này bạn ở giữa Mức 2 và Mức 3. Đủ để đọc được tcpdump, đủ để tự debug 80% sự cố production thường gặp.
Lab là bắt buộc, không optional. Đọc 100 trang lý thuyết thua xa làm 10 lab. Setup môi trường ở Phần 5 là khâu chuẩn bị cho cả khoá — đừng skip.

Phần 11 — Câu hỏi tự kiểm tra

Mindset network của DevOps khác Network Engineer thuần ở những điểm nào? Cho 3 điểm khác biệt cụ thể.
Trong câu chuyện ở Phần 4, bạn intern H thiếu gì? Đó là kiến thức của Mức năng lực số mấy?
Bạn ở mức năng lực nào hiện tại (1, 2, 3, hay 4)? Vì sao bạn nghĩ vậy? (Câu này không có đáp án đúng — tự reflection.)
Vì sao khoá này đặt Linux Networking ở Phần E (cuối) thay vì Phần A (đầu)?
Lab của bài này có 5 bước. Sau khi làm xong, bạn có thể ping 8.8.8.8 từ trong VM Ubuntu được không? Nếu không, vấn đề có thể nằm ở đâu? (Gợi ý: VirtualBox network mode.)
Pitfall số 4 nói "phụ thuộc vào AI". Bạn có đang ở trong tình trạng đó không? Nếu có, kế hoạch cụ thể để cai bớt là gì?
Nếu có người hỏi bạn "DevOps thì học network bao nhiêu là đủ?", bạn sẽ trả lời ra sao bằng 3–4 câu?

Bài tiếp theo: Bài 02 — IP, MAC, Packet — 3 khái niệm nền tảng mà ai cũng nhầm.