Tất cả bài học

Tại sao bắt đầu từ Network?

Mình không chọn cách chia sẻ kiến thức theo dạng “khóa học đóng gói” như nhiều trung tâm. Thay vào đó, mình chia sẻ theo đúng hành trình thực tế mà mình đã đi qua — từ Network, System đến DevOps.

Sau khi trải nghiệm và làm việc thực tế ở nhiều lớp của hạ tầng, mình nhận ra một điều rất quan trọng: Network là nền tảng cốt lõi để hiểu toàn bộ hệ thống.

Dù bạn làm ở bất kỳ layer nào:

• System có network của system (IP, routing, firewall, port…)
• Ảo hóa có network của ảo hóa (bridge, NAT, overlay…)
• Kubernetes có network của Kubernetes (pod network, service, ingress…)

Bất kỳ công nghệ hay hệ thống nào cũng đều có một lớp network bên dưới. Nếu không hiểu rõ phần này, bạn sẽ rất khó debug, rất khó tracing, và gần như “mù” khi hệ thống gặp sự cố.

Chính vì vậy, mình lựa chọn bắt đầu từ nền tảng như CCNA (Cisco Certified Network Associate) — không phải để bạn trở thành một Network Engineer, mà để bạn có đủ kiến thức nền tảng giúp hiểu được cách các hệ thống giao tiếp và vận hành.

Khi có nền tảng network vững, bạn sẽ học System nhanh hơn, hiểu DevOps sâu hơn, và đặc biệt là có khả năng phân tích, xử lý sự cố một cách logic và hiệu quả.

Tất nhiên, học Network để làm DevOps sẽ khác với việc đi theo chuyên sâu Network Engineer. Ở đây, mình tập trung vào hiểu bản chất, áp dụng thực tế và phục vụ cho vận hành hệ thống, không phải cấu hình thiết bị ở mức chuyên sâu của vendor.

Nếu bạn hiểu được Network, bạn không chỉ học nhanh hơn — bạn còn hiểu được chuyện gì đang thực sự xảy ra bên trong hệ thống.

Ban đầu, tài liệu có thể tạo cảm giác khá dài và “nặng đô” đối với người mới tiếp cận. Tuy nhiên trên thực tế, thời gian để đọc và nắm được nội dung lại không nhiều — mỗi chương chỉ cần vài phút tập trung là có thể hiểu được những ý chính.
Quan trọng hơn, CCNA không phải là tài liệu để đọc một lần rồi bỏ qua, mà nên được xem như một “cuốn sách gối đầu giường” đối với bất kỳ ai theo đuổi lĩnh vực hạ tầng và hệ thống. Hãy tận dụng những khoảng thời gian rảnh để đọc lại, củng cố từng phần kiến thức. Qua thời gian, các khái niệm về network sẽ dần trở nên quen thuộc, logic và nằm trong tư duy của bạn một cách tự nhiên.
Khi đó, bạn sẽ nhận ra sự khác biệt rõ rệt trong cách tiếp cận vấn đề, khả năng phân tích hệ thống, và hiểu sâu hơn vì sao nền tảng network — mà CCNA mang lại — lại quan trọng đến vậy trong con đường làm nghề.

🚀 Chặng 2: Làm quen với Git

Ở chặng này, bạn sẽ bắt đầu với Git.

Nói thẳng một chút: nếu học Git theo kiểu “đào sâu toàn bộ”, đi hết mọi ngóc ngách, thì sẽ rất dài, rất chi tiết… và cũng rất dễ buồn ngủ. Thực tế khi đi làm, bạn không cần dùng đến 100% những gì Git có.

🎯 Cách tiếp cận thực tế

Kinh nghiệm của mình là:

Chỉ tập trung học những thứ dùng hàng ngày và bắt buộc phải biết.

Còn những phần nâng cao hoặc ít dùng, bạn chỉ cần:

• Biết là Git có hỗ trợ
• Hiểu sơ nó dùng để làm gì
• Khi cần thì đọc lại hoặc search (Google/AI là đủ)

💡 Góc nhìn thực chiến

Đây là cách mình đã làm việc với Git mỗi ngày — thực tế, đơn giản, và hiệu quả.

Vì vậy, trong phần này:

• Không nhồi nhét lý thuyết
• Không cố học cho “đủ”
• Không làm bạn quá tải ngay từ đầu

Thay vào đó, mình sẽ tập trung vào:

• Những gì đang dùng thật trong công việc
• Viết theo cách dễ hiểu nhất
• Giúp bạn áp dụng được ngay

🔥 Mục tiêu

Sau chặng này, bạn sẽ:

• Nắm được những thao tác Git quan trọng nhất
• Tự tin làm việc cơ bản với Git trong thực tế
• Và quan trọng nhất: không nản ngay từ chặng 2 😄

🐧 Chặng 3: Bash Shell Scripting

Ở phần này bạn sẽ học về Bash Shell Scripting.

Nói thật luôn: chặng này hay hơn hẳn mấy phần trước.

🎯 Góc nhìn thực tế

Hồi mình mới học Bash, thầy mình nói một câu khá thấm:

Học Bash bài bản sẽ nhìn phát biết ngay:

• Thằng nào copy script trên mạng về chạy mà không hiểu gì
• Thằng nào hiểu từ dòng đầu tiên: nó là cái gì, tại sao nó phải viết như vậy

Chỉ cần vậy thôi là đủ phân biệt:

• Junior
• với Senior

📚 Thực tế lúc mới học

Thầy mình ném cho một đống tài liệu full tiếng Anh.
Dài… rất dài… đọc xong kiểu: “cái quái gì đây vcđ” 🤯

Học thì lâu, đọc thì mệt, nhiều đoạn đọc xong cũng chả hiểu hết.

Nhưng mà:

Đây là phần đáng học nhất.

💡 Tại sao lại phải học cho tử tế?

Bash không chỉ là:

• Viết script automate
• Chạy job này job kia

Mà nó là thứ giúp bạn hiểu:

Linux nó đang chạy kiểu gì dưới hood, sự thấu hiểu hệ điều hành là đây.

Bạn sẽ bắt đầu nhận ra:

• Mọi thứ trong Linux thực ra chỉ là command + process + file
• Tại sao Linux lại gọi là mã nguồn mở
• Hệ điều hành nó vận hành “đơn giản mà mạnh” như nào

Mấy cái này nếu chỉ học kiểu lướt lướt (kể cả LPI I, LPI II) thì:

Khó mà ngấm được hết.

⚠️ Nói trước cho đỡ sốc

Ở phần này sẽ có đoạn:

• Đọc không hiểu
• Làm không chạy
• Hoặc hiểu lơ mơ

Chuyện bình thường.

🔥 Cách học đúng (kinh nghiệm thật)

Đừng cố hiểu hết ngay.

Cứ:

• Đọc
• Làm
• Bí thì search
• Và thỉnh thoảng quay lại đọc lại

Thầy mình gọi đây là:

“sách gối đầu giường”

Lúc đầu không hiểu đâu.
Nhưng sau một thời gian đi làm, quay lại đọc:

Tự nhiên thấy “à, hóa ra nó là như này”

Và lúc đó bạn mới thấy:

Linux nó hay thật sự 🚀

🌐 Chặng 4: Web Stack & High Availability

Đây là chặng bạn bắt đầu bước vào:

“hệ thống production thật ngoài đời”

Bạn sẽ học:

• Nginx / Reverse Proxy
• Load Balancing
• High Availability
• Redis / Cache
• Database Replication
• Queue & Background Job
• Monitoring & Troubleshooting

🎯 Góc nhìn thực tế

Lúc đầu ai cũng nghĩ:

“web chạy được là xong”

Nhưng đi làm rồi mới hiểu:

• service chết
• nginx timeout
• db nghẽn
• deploy lỗi
• một node sập kéo cả hệ thống đi luôn 💀

Và đó là lúc bạn nhận ra:

Chạy được ≠ chạy ổn định.

💡 Thứ đáng học nhất ở chặng này

Bạn sẽ bắt đầu hiểu:

• Request đi qua hệ thống như nào
• Vì sao cần reverse proxy
• Cache cứu hệ thống ra sao
• Vì sao DB luôn dễ thành bottleneck
• Một hệ thống HA thật sự hoạt động thế nào

Và quan trọng nhất:

Bắt đầu có tư duy nhìn cả hệ thống thay vì từng service.

🔥 Cách học đúng

Đừng học kiểu:

• copy config
• học thuộc command

Hãy:

• tự dựng
• tự phá
• tự debug
• đọc log
• fix lỗi

Vì nghề này:

kỹ năng thật nằm ở lúc hệ thống đang cháy 🔥

🖥️ Chặng 5: Ảo hóa với VMware vSphere

Đến đây, bạn đã biết mạng chạy thế nào, biết viết script, biết dựng một web stack có HA.

Câu hỏi tiếp theo là:

Vậy mấy con server đó… nó thực sự nằm ở đâu?

🎯 Góc nhìn thực tế

Đọc trên mạng thì thấy ai cũng nói cloud, cloud, cloud.

Nhưng đi làm ở Việt Nam, bạn sẽ gặp một sự thật khác:

Rất nhiều doanh nghiệp — ngân hàng, bảo hiểm, viễn thông, nhà máy, cơ quan nhà nước — vẫn chạy on-prem. Và phần lớn on-prem là VMware.

Không phải vì họ lạc hậu. Mà vì dữ liệu nhạy cảm, vì quy định, vì đã đầu tư hạ tầng, vì chi phí.

Nên nếu bạn đi làm infra ở VN, khả năng rất cao là:

• Ngày đầu tiên bạn được cấp một account vCenter
• Con VM bạn ssh vào không phải "cloud" gì cả — nó nằm trên một con ESXi trong phòng server
• Muốn xin thêm RAM cho service, bạn phải hiểu host còn bao nhiêu tài nguyên

💡 Tại sao chặng này quan trọng hơn bạn nghĩ

Ảo hóa là tầng nằm dưới tất cả những thứ bạn sắp học.

Container chạy trên VM. VM chạy trên hypervisor. Hypervisor chạy trên phần cứng thật.

Nếu không hiểu tầng này, bạn sẽ gặp mấy tình huống rất "ảo":

• VM chậm bất thường mà trong VM nhìn CPU vẫn nhàn → hóa ra host bị overcommit
• Hai VM cùng subnet mà không ping được nhau → vấn đề nằm ở vSwitch / VLAN, không phải trong OS
• Datastore đầy → cả cụm VM đứng hình, và bạn debug trong VM cả buổi mà không ra

Rất nhiều sự cố "không thể hiểu nổi" bên trong VM, nguyên nhân thật lại nằm ở tầng bên dưới nó.

Và một điều nữa: cloud thực chất chính là ảo hóa được đóng gói lại và bán theo giờ. Hiểu ESXi, datastore, vSwitch rồi thì sau này nhìn EC2, EBS, VPC bạn sẽ thấy quen mặt ngay.

📚 Bạn sẽ đi qua những gì

• ESXi và máy ảo — hypervisor thực sự làm gì
• vCenter — quản lý tập trung nhiều host
• Virtual Network & Storage — vSwitch, port group, datastore
• Cluster, vMotion, HA, DRS — vì sao doanh nghiệp bảo trì server mà dịch vụ không sập

Riêng phần cuối là thứ mình thấy "wow" nhất hồi mới học:

Di chuyển một VM đang chạy từ host này sang host khác, mà người dùng không hề biết.

⚠️ Nói trước cho đỡ sốc

Chặng này lab nặng máy nhất trong cả lộ trình. ESXi thích RAM, và bạn thì thường chỉ có một cái laptop.

Không sao. Cứ nested virtualization, cứ dựng nhỏ, cứ giảm cấu hình xuống mức tối thiểu. Mục tiêu là hiểu cách nó vận hành, không phải dựng datacenter trong phòng trọ 😄

Và nếu chưa có điều kiện lab đầy đủ — đọc kỹ vẫn có giá trị. Vì thứ bạn cần mang đi làm là tư duy về tầng hạ tầng bên dưới, không phải thuộc menu của vCenter.

🔥 Mục tiêu

Sau chặng này, bạn sẽ:

• Hiểu VM thực sự chạy trên cái gì, và tài nguyên nó lấy từ đâu
• Nhìn một hệ thống on-prem và biết nó được thiết kế thế nào
• Debug được những sự cố mà nguyên nhân nằm dưới lớp OS
• Và bước vào chặng Docker với một câu hỏi rất tự nhiên: "vậy container khác VM ở chỗ nào?" 🚀

🐳 Chặng 6: Docker & Container

Cuối cùng cũng tới Docker.

Mình biết là nhiều bạn muốn nhảy thẳng vào đây từ ngày đầu tiên. Rất nhiều lộ trình trên mạng cũng dạy Docker ngay bài 1.

Nhưng mình cố tình để nó ở chặng 6. Và đây là lý do.

🎯 Vì sao Docker không nên là thứ học đầu tiên

Docker là một công cụ cực kỳ dễ dùng và cực kỳ dễ hiểu sai.

Gõ docker run nginx — chạy được ngay. Cảm giác rất sướng. Nhưng rồi:

• Container không kết nối được với nhau → bạn không hiểu, vì bạn chưa nắm network namespace, bridge, NAT
• Restart cái là mất sạch data → bạn không hiểu, vì bạn chưa hiểu filesystem và mount
• Container "chạy rồi tự tắt" → bạn không hiểu, vì bạn chưa hiểu process là gì trong Linux

Docker không tạo ra phép màu. Nó chỉ đóng gói lại những thứ Linux vốn đã có: process, namespace, cgroup, filesystem, network.

Bạn đã đi qua Network (chặng 1) và Bash/Linux (chặng 3). Nên đến đây, Docker sẽ không còn là hộp đen nữa — nó là thứ bạn hiểu được từ bên trong.

Đó chính là khác biệt giữa người dùng được Docker và người hiểu Docker.

💡 Docker giải quyết vấn đề gì (nói cho thật)

Câu kinh điển trong nghề:

"Trên máy tao chạy được mà?"

Dev viết code chạy ngon trên laptop. Đẩy lên server thì lỗi. Khác version, khác thư viện, khác config, khác OS.

Docker chốt lại cuộc tranh cãi đó:

Đóng gói cả app và môi trường của nó vào một image. Chạy ở đâu cũng như nhau.

Nghe đơn giản, nhưng nó thay đổi hoàn toàn cách doanh nghiệp build và deploy phần mềm — và là nền tảng cho mọi thứ hiện đại phía sau: CI/CD, Kubernetes, GitOps.

📚 Bạn sẽ đi qua những gì

• Docker cơ bản: container vs VM, kiến trúc, lifecycle
• Image & Dockerfile: từ kéo image trên Docker Hub đến tự build image của mình
• Network & Storage: kết nối container và giữ được data (chỗ này chết nhiều người nhất)
• Docker Compose: một file YAML, dựng nguyên cả stack

⚠️ Nói trước cho đỡ sốc

Đừng học Docker theo kiểu học thuộc lệnh.

Thuộc 30 lệnh docker mà không hiểu image layer, volume, network — đi làm gặp sự cố là đứng hình ngay.

Hai chỗ mà fresher hay ngã nhất:

• Volume/data: container là ephemeral (chạy xong là mất). Data phải nằm ngoài container. Không hiểu chỗ này, bạn sẽ có ngày xóa nhầm dữ liệu thật.
• Network: container nói chuyện với nhau bằng cách nào, port publish khác port expose ra sao, vì sao localhost trong container không phải localhost của bạn.

🔥 Cách học đúng

Cứ:

• Tự viết Dockerfile, đừng copy
• Build image, thấy nó nặng 1.2GB thì tìm cách làm cho nó nhẹ xuống
• Cố tình xóa container để xem data còn hay mất
• Dựng lại chính cái web stack ở chặng 4 — nhưng bằng docker-compose

Đến khi bạn thấy:

"Ơ, cái này chỉ là process bị nhốt trong namespace thôi mà"

thì bạn đã qua được chặng này thật sự 🚀

🎯 Mục tiêu

Sau chặng này, bạn sẽ:

• Đóng gói được app bất kỳ thành image
• Dựng full stack (web + db + cache) bằng một file compose
• Hiểu vì sao container nhẹ hơn VM, và khi nào không nên dùng container
• Và sẵn sàng cho câu hỏi tiếp theo: "vậy nếu tôi có 200 container trên 10 server thì quản kiểu gì?" — đó chính là Kubernetes.

☸️ Chặng 7: Kubernetes

Đây là chặng khó nhất lộ trình. Mình nói trước cho bạn chuẩn bị tinh thần.

Nhưng cũng nói luôn: nếu bạn đã đi qua 6 chặng trước một cách tử tế, thì K8s không đáng sợ như lời đồn.

🎯 Bắt đầu từ một câu hỏi rất đời

Ở chặng 6, bạn dựng được full stack bằng docker-compose. Ngon.

Nhưng rồi doanh nghiệp hỏi bạn:

• Nếu con server chạy compose đó chết thì sao?
• App đang bị 10.000 người truy cập, muốn scale từ 2 lên 20 container thì làm sao?
• Deploy version mới mà không được downtime, làm kiểu gì?
• Container tự chết lúc 2h sáng — ai dựng nó dậy?

Compose không trả lời được mấy câu đó. Và Kubernetes ra đời chính để trả lời.

Nói ngắn gọn: Kubernetes là docker-compose ở quy mô cluster, có khả năng tự chữa lành.

Nếu bạn nhớ đúng một câu trong chặng này, hãy nhớ câu đó. Mọi khái niệm rối rắm sau này đều xoay quanh nó.

⚠️ Nói trước cho đỡ sốc

Chặng này sẽ có lúc bạn thấy:

• Một biển YAML
• Một đống danh từ lạ: Pod, ReplicaSet, Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet...
• Lỗi thì đọc log ra một mớ chữ không hiểu gì

Bình thường. Ai học K8s cũng qua đoạn đó.

Mẹo của mình: đừng cố nhớ tên. Với mỗi khái niệm, chỉ hỏi đúng một câu:

"Nó sinh ra để giải quyết vấn đề gì?"

• Pod → vì container cần một "vỏ" để K8s quản
• Deployment → vì pod chết thì phải có ai dựng lại
• Service → vì pod có IP thay đổi liên tục, cần một địa chỉ cố định
• Ingress → vì không lẽ mở 50 port ra ngoài Internet
• ConfigMap/Secret → vì config và password không được nhét cứng vào image

Hiểu vấn đề trước, tên gọi tự khắc dính vào đầu.

💡 Đây là lúc mọi thứ bạn học ráp lại

Vui nhất ở chặng này là bạn sẽ thấy 6 chặng trước quay lại đủ mặt:

• Network (chặng 1): pod network, service, iptables, DNS nội bộ — bạn hiểu được vì sao đã học
• Bash/Linux (chặng 3): container vẫn chỉ là process, debug vẫn là đọc log, xem process, xem port
• HA/Load balancing (chặng 4): giờ nó nằm sẵn trong K8s
• Ảo hóa (chặng 5): cluster của bạn chạy trên đám VM đó
• Docker (chặng 6): image bạn build sẽ chạy trong pod

Nếu học K8s mà chưa vững mấy phần trên, bạn sẽ chỉ đang copy YAML. Còn học đúng thứ tự, bạn sẽ thấy K8s rất logic.

📚 Bạn sẽ đi qua những gì

Từ Pod, Deployment, Service, ConfigMap/Secret, StatefulSet (chạy database trên K8s), Job/CronJob, bảo mật và giới hạn tài nguyên, Ingress + TLS — rồi capstone: tự dựng cluster on-prem và đưa nguyên cái Compose ở chặng 6 lên K8s.

Và có một bài mà mình rất muốn bạn đọc kỹ: Day-2 Operations.

Vì đây mới là sự thật của nghề:

Dựng được cluster chỉ là ngày đầu tiên. Giữ nó sống được vài năm mới là công việc thật.

Upgrade version, backup etcd, xử lý node chết, quản certificate hết hạn, dọn resource rác... Không khóa học nào thích dạy phần này, nhưng đi làm thì đó là 90% thời gian của bạn.

🔥 Mục tiêu

Sau chặng này, bạn sẽ:

• Deploy được app multi-service lên cluster thật
• Hiểu cluster tự chữa lành, scale, rolling update như thế nào
• Debug được khi pod không lên, service không thông, ingress trả 502
• Và quan trọng nhất: nhìn K8s không còn thấy nó là ma thuật nữa 🚀

🔄 Chặng 8: Helm & GitOps

Chặng cuối. Và cũng là chặng giống công việc thật nhất.

Ở đây bạn không học thêm một tool mới cho vui — bạn học cách một team vận hành hệ thống hàng ngày, một cách chuyên nghiệp.

🎯 Vấn đề mà chặng này giải

Xong chặng 7, bạn deploy được lên K8s. Nhưng thực tế đi làm sẽ đập vào mặt bạn mấy chuyện này:

• App có 15 file YAML. Nhân với 3 môi trường (dev/staging/prod) là 45 file, khác nhau vài dòng. Sửa tay → sai sót là chuyện sớm muộn.
• Ai đó kubectl apply tay lúc 11h đêm để fix gấp. Sáng hôm sau không ai biết trên production đang chạy config gì.
• Deploy xong, không biết nó có ổn không — cho tới khi khách hàng gọi điện.

Chặng này trả lời cả ba:

• Helm → đóng gói YAML thành "package" có tham số, một chart chạy được nhiều môi trường
• GitOps (ArgoCD) → Git là nguồn sự thật duy nhất. Muốn đổi production thì phải commit. Không ai sửa tay trên cluster nữa.
• Observability → nhìn thấy hệ thống trước khi khách hàng nhìn thấy
• CI/CD → từ git push tới production, không chạm tay

💡 Câu quan trọng nhất của cả chặng

Trên production, thứ đáng sợ không phải là lỗi. Thứ đáng sợ là không ai biết vì sao nó thành ra như thế này.

GitOps sinh ra để chống đúng nỗi sợ đó.

Mọi thay đổi đều đi qua Git: có commit, có người review, có lịch sử, có thể revert. Cluster tự đồng bộ theo Git. Ai đó sửa tay → hệ thống tự kéo về đúng trạng thái trong Git.

Nghe hơi "cứng nhắc", nhưng đi làm rồi bạn sẽ thấy nó cứu bạn — nhất là lúc 2h sáng, khi cần biết chính xác ai đã đổi gì, lúc nào.

📊 Và Observability — phần mình muốn bạn đọc kỹ

Câu này mình học được bằng cách... trả giá:

Hệ thống không tự nói cho bạn biết nó đang ốm. Bạn phải chủ động đo nó.

Không có monitoring, quy trình xử lý sự cố của bạn sẽ là:

1. Khách hàng gọi
2. Bạn hoảng
3. SSH vào từng server đoán mò
4. Sửa xong không biết vì sao nó hỏng, cũng không biết vì sao nó khỏi

Có monitoring, nó thành:

1. Alert kêu trước khi khách hàng biết
2. Mở dashboard, nhìn metric, khoanh vùng
3. Xem log đúng chỗ, xác định nguyên nhân
4. Fix, và viết lại RCA để lần sau không lặp lại

Khác nhau một trời một vực. Và đây chính là ranh giới giữa "người biết dùng tool" và "người vận hành được hệ thống".

🔥 Mục tiêu

Sau chặng này, bạn sẽ:

• Đóng gói app bằng Helm chart, deploy nhiều môi trường từ một nguồn
• Dựng luồng GitOps với ArgoCD — production luôn khớp với Git
• Quản lý nhiều cluster từ một chỗ với Rancher
• Có monitoring/alert để biết hệ thống ốm trước khi khách hàng gọi
• Dựng pipeline CI/CD từ git push tới production

🎓 Và sau chặng 8?

Đến đây, bạn đã đi hết một vòng: Network → Git → Linux/Bash → Web stack & HA → Ảo hóa → Docker → Kubernetes → GitOps.

Đó đúng là con đường mình đã đi, và cũng là bức tranh hạ tầng mà một doanh nghiệp thật đang vận hành mỗi ngày.

Nhưng nói thật lòng:

Học xong lộ trình không biến bạn thành senior. Nó chỉ giúp bạn không còn sợ hệ thống nữa.

Phần còn lại — kinh nghiệm, phản xạ, sự bình tĩnh lúc production đang cháy — chỉ có đi làm và va thật mới có được.

Và đó cũng là lý do mình mở mục Case & hỏi đáp: để những lần "va" đó được ghi lại, để người sau đỡ phải trả giá như người trước 🚀