Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 60 — Ops Career: SRE, DevOps, Platform Engineer Path

Operations Management for Tech Bài 60/60

Mở đầu — vì sao bài này quan trọng

Suốt 59 bài trước, bạn đã học cách vận hành hệ thống: từ incident management, SLI/SLO, observability, chaos engineering, cho tới Kubernetes, IaC và cost optimization. Nhưng có một câu hỏi mà mọi học viên đều gãi đầu ở cuối khóa: "Tất cả những kỹ năng này gộp lại thành nghề gì? Và tôi nên đi theo con đường nào?"

Đây là câu hỏi cực kỳ thực tế, bởi thị trường tuyển dụng Việt Nam và khu vực đang dùng ba cái tên gần như thay thế nhau — SRE, DevOps Engineer, Platform Engineer — trong khi thực chất chúng là ba nghề khác nhau về triết lý, kỹ năng và lộ trình phát triển. Một JD (job description) ghi "DevOps Engineer" ở công ty A có thể yêu cầu công việc giống hệt "SRE" ở công ty B. Nếu bạn không hiểu bản chất, bạn dễ chọn nhầm công ty, đàm phán nhầm mức lương, hoặc học nhầm kỹ năng cho 2 năm tới.

Bài này là bản đồ nghề nghiệp. Chúng ta sẽ phân biệt rõ ba con đường, xem chúng chồng lấn ở đâu, mức lương và lộ trình thăng tiến ra sao trong bối cảnh Việt Nam, và quan trọng nhất: giúp bạn tự vẽ ra kế hoạch 12–24 tháng để tiến tới vai trò mình muốn. Đây không phải lý thuyết suông — đây là quyết định ảnh hưởng trực tiếp tới thu nhập và sự thỏa mãn nghề nghiệp của bạn.

Khái niệm cốt lõi

Ba nghề, ba triết lý gốc

Điều đầu tiên cần khắc cốt ghi tâm: ba nghề này không xếp thành thang bậc "cái nào cao hơn cái nào". Chúng là ba trục kỹ năng khác nhau, xuất phát từ ba triết lý khác nhau.

SRE (Site Reliability Engineer) — sinh ra từ Google, được định nghĩa gọn là "cái xảy ra khi bạn giao việc vận hành cho một kỹ sư phần mềm". Triết lý cốt lõi: reliability (độ tin cậy) là một tính năng của sản phẩm, phải được đo bằng SLI/SLO và quản lý bằng error budget. SRE nghiêng nặng về code — họ viết automation, xây tooling để loại bỏ toil, và dành phần lớn thời gian cải thiện độ tin cậy của một hoặc vài dịch vụ cụ thể. Nếu bạn thích viết code Go/Python để giải quyết vấn đề vận hành, thích tư duy bằng con số (p99 latency, error budget còn bao nhiêu %), SRE là nhà của bạn.

DevOps Engineer — thực ra DevOps nguyên gốc là một văn hóa, không phải chức danh. Nó nói về việc phá bỏ bức tường giữa Dev và Ops, để cùng chịu trách nhiệm "you build it, you run it". Nhưng thị trường đã biến nó thành một job title cụ thể: người xây và vận hành CI/CD pipeline, IaC, dev tooling, giúp lập trình viên ship code nhanh và an toàn. DevOps Engineer nghiêng về flow — làm sao để một dòng code đi từ commit tới production mượt mà nhất. Họ sống trong GitLab CI, Jenkins, GitHub Actions, Terraform, Ansible.

Platform Engineer — nghề mới nhất và đang bùng nổ mạnh nhất (2023 trở đi). Triết lý: thay vì mỗi team tự lo hạ tầng, hãy xây một Internal Developer Platform (IDP) — một sản phẩm nội bộ để lập trình viên tự phục vụ (self-service). Platform Engineer coi các lập trình viên trong công ty là khách hàng của mình. Họ xây "golden path": nhấn một nút là có sẵn database, pipeline, monitoring, secret. Nghề này lấy tư duy sản phẩm áp vào hạ tầng. Backstage (của Spotify), Crossplane, Kubernetes operator là công cụ tiêu biểu.

Chúng chồng lấn ở đâu

Cả ba đều đứng trên nền tảng chung mà bạn đã học trong khóa này: Linux, networking, container/Kubernetes, observability, cloud (AWS/GCP/Azure), và tư duy incident. Đó là lý do JD hay nhầm lẫn.

Cách phân biệt nhanh khi đọc một JD:

  • JD nói nhiều về SLO, on-call, error budget, giảm toil bằng code → thực chất là SRE.
  • JD nói nhiều về pipeline, tự động hóa deploy, quản lý môi trường → thực chất là DevOps.
  • JD nói về self-service platform, developer experience, golden path, xây tooling cho các team khác dùng → thực chất là Platform Engineering.

Bức tranh Việt Nam

Ở Việt Nam năm 2026, thực tế thị trường có vài đặc điểm cần biết:

Thứ nhất, phần lớn công ty vừa và nhỏ tuyển "DevOps Engineer" nhưng kỳ vọng người đó làm cả ba vai — vừa dựng pipeline, vừa on-call, vừa lo hạ tầng. Đây gọi vui là "DevOps full-gánh". Điều này có mặt lợi: bạn học được rộng rất nhanh.

Thứ hai, danh xưng "SRE" và "Platform Engineer" thường chỉ xuất hiện ở các công ty đủ lớn để tách team — như các ví MoMo, VNPay, Tiki, Shopee/Sea, Grab, hay các product company có traffic lớn. Ở đó mới có đủ quy mô để một team chỉ chuyên lo reliability hoặc chỉ chuyên xây platform.

Thứ ba, về mức lương (tham khảo, USD quy đổi, thị trường 2026): một DevOps junior 1–2 năm kinh nghiệm rơi vào khoảng 700–1.200 USD/tháng; mid-level 3–5 năm khoảng 1.500–2.500 USD; senior SRE/Platform ở product company lớn có thể 3.000–5.000 USD, và nếu làm remote cho công ty nước ngoài, con số này cao hơn đáng kể. Điểm mấu chốt: SRE và Platform ở tier cao thường trả nhỉnh hơn DevOps thuần, vì đòi hỏi cả kỹ năng code lẫn tư duy hệ thống.

Tình huống thực tế

Tình huống 1: Cùng một người, ba công ty gọi ba tên khác nhau

Anh Đức, 4 năm kinh nghiệm ở Đà Nẵng, đi phỏng vấn ba nơi cùng lúc. Công ty outsourcing gọi anh là "DevOps Engineer", mô tả công việc: dựng Jenkins pipeline cho khách hàng. Một fintech ở TP.HCM gọi cùng bộ kỹ năng ấy là "SRE", nhưng thêm yêu cầu on-call 24/7 và định nghĩa SLO cho cổng thanh toán. Một startup product gọi anh là "Platform Engineer", muốn anh xây một cổng self-service để 40 lập trình viên tự tạo môi trường staging.

Diễn giải: cùng một CV, ba chức danh, ba kỳ vọng khác nhau. Anh Đức nhận ra: fintech thực chất cần người tư duy reliability và chịu được áp lực on-call; startup cần người có tư duy sản phẩm và biết code tooling; outsourcing cần người nhanh tay dựng pipeline theo yêu cầu khách. Anh chọn fintech vì thích đo lường bằng con số và không ngại on-call — và đàm phán được mức cao hơn 30% so với vai DevOps thuần vì trách nhiệm reliability nặng hơn.

Bài học: đừng đọc chức danh, hãy đọc trách nhiệm thực tế trong JD và hỏi thẳng ở vòng phỏng vấn: "Tỷ lệ thời gian tôi viết code so với thao tác thủ công là bao nhiêu? Có on-call không? Khách hàng của tôi là end-user hay các lập trình viên nội bộ?"

Tình huống 2: Startup Đông Nam Á trưởng thành và tách team

Một startup logistics ở Jakarta (giả định hợp lý, kiểu như một công ty trong hệ Sea/Grab) trong hai năm đầu chỉ có 3 "DevOps Engineer" gánh tất cả: pipeline, hạ tầng AWS, on-call. Khi công ty tăng từ 20 lên 120 lập trình viên, ba người này kiệt sức — họ trở thành "cổ chai" (bottleneck) vì mọi team đều phải chờ họ tạo môi trường, cấp quyền, dựng monitoring.

Ban lãnh đạo quyết định tách: hai người chuyển sang team Platform để xây Backstage portal cho các team tự phục vụ; một người chuyển sang team SRE để lo SLO và incident cho dịch vụ thanh toán trọng yếu. Sau 6 tháng, thời gian trung bình để một team mới có môi trường production giảm từ 2 tuần xuống còn 2 giờ.

Diễn giải: đây là quỹ đạo trưởng thành điển hình. Ban đầu "DevOps full-gánh" là đủ và cần thiết. Nhưng khi tổ chức lớn lên, nhu cầu chuyên môn hóa xuất hiện, và ba nghề tách ra một cách tự nhiên.

Bài học: nếu bạn đang ở giai đoạn "full-gánh", đó không phải điều xấu — đó là cơ hội học rộng. Nhưng hãy để ý mình nghiêng về hướng nào (thích code platform hay thích lo reliability) để khi công ty tách team, bạn chủ động chọn nhánh phù hợp thay vì bị phân bổ ngẫu nhiên.

Tình huống 3: Chuyển ngành từ backend developer sang SRE

Chị Lan là backend developer 5 năm ở một e-commerce Việt Nam, giỏi Java và Go nhưng chán viết business logic. Chị nhận thấy mình luôn là người "nhảy vào cứu" mỗi khi production sập, và thích cảm giác đó. Chị quyết chuyển sang SRE.

Chị không bắt đầu lại từ đầu. Chị tận dụng lợi thế code sẵn có, học thêm ba mảng mình yếu: Kubernetes vận hành thực chiến, observability (Prometheus + Grafana), và tư duy SLO. Trong 8 tháng, chị nhận on-call cho một dịch vụ nhỏ, tự viết vài runbook và một tool automation loại bỏ toil thủ công của team. Với portfolio đó, chị chuyển nội bộ sang team SRE mà không mất năm kinh nghiệm nào.

Diễn giải: SRE là con đường tự nhiên nhất cho developer muốn chuyển sang Ops, vì nền tảng code đã có sẵn — thứ mà nhiều DevOps xuất thân từ sysadmin lại thiếu.

Bài học: background của bạn quyết định con đường ngắn nhất. Developer → SRE. Sysadmin/network → DevOps → Platform. Đừng vứt bỏ nền tảng cũ, hãy bắc cầu từ nó.

Hướng dẫn từng bước

Đây là quy trình 5 bước để tự vẽ lộ trình 12–24 tháng cho bản thân.

Bước 1 — Tự đánh giá trục kỹ năng. Cho điểm bản thân từ 1–5 trên bốn trục: (a) khả năng code/automation, (b) kiến thức hạ tầng/cloud/K8s, (c) tư duy reliability (SLO, incident), (d) tư duy sản phẩm/trải nghiệm người dùng. Trục nào mạnh nhất gợi ý nghề phù hợp: code + reliability nghiêng SRE; hạ tầng + flow nghiêng DevOps; code + tư duy sản phẩm nghiêng Platform.

Bước 2 — Chọn một nghề mục tiêu (không phải cả ba). Việc chọn không khóa bạn mãi mãi, nhưng giúp bạn tập trung 12 tháng tới. Ai cũng cố "học hết mọi thứ" sẽ giỏi nửa vời ở tất cả.

Bước 3 — Xác định khoảng cách kỹ năng (skill gap). Lấy 5–7 JD thật của nghề mục tiêu ở mức lương bạn muốn, gạch chân những yêu cầu bạn chưa đáp ứng. Đó chính là danh sách học tập của bạn, ưu tiên cái xuất hiện nhiều lần nhất.

Bước 4 — Xây portfolio chứng minh, không chỉ chứng chỉ. Chứng chỉ (CKA cho Kubernetes, AWS/GCP Associate, Terraform Associate) là điểm cộng nhưng nhà tuyển dụng tin bằng chứng thực chiến hơn. Hãy tạo một repo GitHub: dựng một cụm K8s, một CI/CD pipeline hoàn chỉnh, một dashboard observability, viết vài blog post kể lại một incident bạn xử lý. Đây là thứ khiến bạn nổi bật.

Bước 5 — Tận dụng vị trí hiện tại làm bàn đạp. Đừng chờ đổi việc mới bắt đầu. Xung phong nhận on-call, tự động hóa một tác vụ thủ công của team, đề xuất SLO cho một dịch vụ. Chuyển vai nội bộ luôn dễ và ít rủi ro hơn nhảy công ty.

Lỗi thường gặp & mẹo

Lỗi 1 — Sưu tầm chứng chỉ thay vì kinh nghiệm. Nhiều bạn có 5 chứng chỉ nhưng chưa từng xử lý một incident thật, chưa từng viết một dòng Terraform chạy production. Nhà tuyển dụng nhìn ra ngay ở vòng technical. Mẹo: mỗi chứng chỉ nên đi kèm ít nhất một dự án thật áp dụng kiến thức đó.

Lỗi 2 — Bỏ bê kỹ năng code, đặc biệt nếu muốn làm SRE/Platform. Nhiều người từ sysadmin tưởng biết vài script bash là đủ. Không đủ. SRE và Platform hiện đại đòi hỏi biết ít nhất một ngôn ngữ đàng hoàng (Go hoặc Python). Mẹo: bắt đầu bằng cách viết lại các bash script phức tạp thành Python có test.

Lỗi 3 — Chạy theo hype "Platform Engineering" khi tổ chức chưa đủ chín. Xây IDP cho một công ty 10 lập trình viên là lãng phí — bạn đang giải bài toán không tồn tại. Platform chỉ có ý nghĩa khi có đủ nhiều "khách hàng nội bộ". Mẹo: xét quy mô tổ chức trước khi chọn nhánh này.

Lỗi 4 — Nghĩ ba nghề là thang bậc, cố "leo" từ DevOps lên SRE lên Platform. Sai hoàn toàn. Đây là ba trục ngang, không phải thang dọc. Một senior DevOps hoàn toàn có thể lương cao hơn một Platform Engineer junior. Mẹo: chọn theo thứ bạn thích làm mỗi ngày, không theo "danh xưng nghe oách".

Lỗi 5 — Bỏ quên kỹ năng mềm. Ở cấp senior trở lên, giá trị của bạn không chỉ là kỹ thuật mà là khả năng dẫn dắt incident, viết postmortem blameless, thuyết phục team khác dùng platform của bạn. Mẹo: luyện viết và giao tiếp — đây là thứ phân biệt senior với người "giỏi kỹ thuật nhưng mãi không lên được".

Mẹo về lộ trình thăng tiến: cả ba nghề đều rẽ đôi ở cấp cao — nhánh IC (Individual Contributor): Staff Engineer, Principal Engineer, chuyên sâu kỹ thuật; và nhánh quản lý: Team Lead, Engineering Manager. Bạn không bắt buộc phải làm quản lý mới lên lương cao. Nhánh IC ở các product company lớn có thể lên tới Principal với thu nhập ngang giám đốc.

Bài tập thực hành

  • Đọc JD thực chiến: Lên các trang tuyển dụng (ITviec, TopDev, LinkedIn) tìm 6 tin: 2 "DevOps", 2 "SRE", 2 "Platform Engineer" ở Việt Nam. Với mỗi tin, phân loại lại theo trách nhiệm thực tế thay vì chức danh. Bạn sẽ ngạc nhiên khi thấy nhiều tin bị đặt tên sai.
  • Tự đánh giá 4 trục: Cho điểm bản thân 1–5 trên bốn trục ở phần Hướng dẫn. Viết ra một câu kết luận: "Dựa trên điểm mạnh, nghề phù hợp nhất với tôi trong 12 tháng tới là ___ vì ___."
  • Bản đồ skill gap: Chọn 1 nghề mục tiêu, lấy 5 JD ở mức lương mong muốn, liệt kê top 5 kỹ năng bạn còn thiếu, xếp theo tần suất xuất hiện. Đây là kế hoạch học tập của bạn cho 6 tháng tới.
  • Khởi động portfolio: Tạo một repo GitHub công khai với ít nhất một thành phần thật: một Terraform module, một GitHub Actions pipeline, hoặc một Helm chart kèm README giải thích. Bắt đầu nhỏ nhưng thật.
  • (Nâng cao) Viết lộ trình 24 tháng: Vẽ timeline gồm: kỹ năng cần học theo quý, một chứng chỉ mục tiêu, ít nhất hai dự án portfolio, và cột mốc chuyển vai (nội bộ hoặc đổi việc). Chia sẻ với một mentor để nhận phản hồi.

Tóm tắt

Bài này khép lại toàn khóa bằng câu hỏi quan trọng nhất: những kỹ năng bạn đã học dẫn tới nghề gì, và bạn nên đi hướng nào.

  • SRE, DevOps, Platform Engineer là ba trục ngang, không phải thang bậc. Chúng khác nhau về triết lý: SRE nghiêng reliability và code; DevOps nghiêng flow (CI/CD, IaC); Platform nghiêng tư duy sản phẩm và self-service cho lập trình viên nội bộ.
  • Chức danh trên JD hay đặt sai; hãy đọc trách nhiệm thực tế — hỏi thẳng về tỷ lệ code, on-call, và ai là "khách hàng" của bạn.
  • Ở Việt Nam, công ty nhỏ thường tuyển "DevOps full-gánh" (học rộng nhanh), còn SRE/Platform tách team chỉ xuất hiện ở các product company lớn có traffic cao.
  • Background quyết định con đường ngắn nhất: developer → SRE; sysadmin/network → DevOps → Platform. Tận dụng nền cũ, đừng vứt bỏ.
  • Portfolio thực chiến thắng chứng chỉ suông. Kết hợp cả hai, và tận dụng vị trí hiện tại làm bàn đạp thay vì chờ đổi việc.
  • Lộ trình cao cấp rẽ đôi: nhánh IC (Staff/Principal) hoặc nhánh quản lý — chọn theo thứ bạn thích làm mỗi ngày.
Chúc mừng bạn đã hoàn thành khóa Operations Management for Tech. Bản đồ đã có trong tay — giờ là lúc chọn hướng đi và bắt đầu bước đầu tiên.