Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được nhận vào một công ty công nghệ đang phát triển nhanh ở TP.HCM. Ngày đầu tiên, người quản lý nói: "Tuần sau em sẽ join team Ops." Bạn gật đầu, nhưng trong đầu lại lóe lên một loạt câu hỏi mơ hồ: Ops là làm gì? Có phải cứ hệ thống sập thì gọi Ops? Ops khác gì với đội DevOps, với đội hạ tầng (infrastructure), với mấy anh chị viết code tính năng?
Đây chính là vấn đề của rất nhiều người mới bước vào lĩnh vực vận hành công nghệ. Từ "Operations" bị dùng quá rộng, quá mờ, đến mức mỗi công ty hiểu một kiểu. Ở nơi này Ops nghĩa là trực đêm sửa lỗi. Ở nơi khác Ops nghĩa là viết Terraform dựng máy chủ. Chỗ thứ ba lại gộp cả bảo mật, cả tối ưu chi phí vào đó.
Bài học này là nền móng cho toàn bộ khóa học. Trước khi ta đi sâu vào Incident Management, SRE, Observability hay Capacity Planning ở các bài sau, bạn cần một tấm bản đồ rõ ràng: Tech Operations là gì, ranh giới của nó ở đâu, và nó khác biệt thế nào với việc phát triển tính năng. Nắm chắc phần này, bạn sẽ không bị lạc khi gặp những thuật ngữ chồng chéo, và quan trọng hơn, bạn sẽ biết mình đang đứng ở đâu trong bộ máy công nghệ của một tổ chức.
Khái niệm cốt lõi
Tech Operations là gì?
Tech Operations (viết tắt Tech Ops, hay Technical Operations) là tập hợp các thực hành (practice), quy trình và công cụ nhằm giữ cho các hệ thống production chạy ổn định, hiệu quả và an toàn.
Hãy phân tích chậm ba từ khóa trong định nghĩa này, vì mỗi từ đều mang trọng lượng riêng:
- Ổn định (reliability): Hệ thống hoạt động đúng như kỳ vọng, không sập bất ngờ, và khi có sự cố thì hồi phục nhanh. Người dùng mở app đặt đồ ăn lúc 12h trưa cao điểm vẫn thanh toán được — đó là ổn định.
- Hiệu quả (efficiency): Hệ thống dùng đúng lượng tài nguyên cần thiết, không lãng phí. Không thể để một website 1.000 người dùng lại chạy trên hạ tầng đủ phục vụ 1 triệu người, vì tiền cloud sẽ đốt sạch ngân sách.
- An toàn (security & safety): Dữ liệu người dùng được bảo vệ, truy cập được kiểm soát, và mọi thay đổi lên hệ thống đều nằm trong tầm kiểm soát để không gây thảm họa.
Điểm khác biệt cốt lõi: Ops khác gì với phát triển tính năng?
Đây là trục phân biệt quan trọng nhất mà bạn cần khắc sâu. Hãy nhìn qua một phép so sánh:
Phát triển tính năng (Feature Development) trả lời câu hỏi: "Chúng ta xây thêm được gì để tạo giá trị mới cho người dùng?" Đội này viết chức năng đăng nhập bằng Face ID, thêm tính năng chia hóa đơn, làm màn hình gợi ý sản phẩm. Thành công của họ đo bằng: tính năng có ra đúng hạn không, người dùng có thích không.
Tech Operations trả lời một câu hỏi hoàn toàn khác: "Chúng ta giữ cho những gì đã có tiếp tục chạy tốt như thế nào?" Ops không tạo ra tính năng mới. Ops đảm bảo tính năng đã có luôn sẵn sàng, nhanh, an toàn — kể cả lúc 3h sáng, kể cả khi lượng truy cập tăng gấp 10 lần trong dịp sale.
Một cách ví von dễ nhớ trong bối cảnh Việt Nam: nếu feature team giống như đội xây thêm tầng, thêm phòng cho một tòa chung cư, thì Ops team giống như ban quản lý tòa nhà — lo điện nước không cắt, thang máy không kẹt, an ninh không lủng, và khi có sự cố cháy nổ thì phản ứng ngay. Cả hai đều cần thiết. Không có đội xây thì chẳng có gì để vận hành; nhưng không có ban quản lý thì tòa nhà đẹp đến mấy cũng thành nơi không ai dám ở.
Phạm vi của Tech Operations
Vậy cụ thể Tech Ops "cai quản" những gì? Dưới đây là các mảng chính tạo nên phạm vi của nó. Bạn sẽ thấy hầu hết các bài học tiếp theo trong khóa đều rơi vào một trong những mảng này:
- Reliability & Incident Management: Giữ hệ thống chạy, phát hiện và xử lý sự cố. Đây là trái tim của Ops.
- Monitoring & Observability: "Nhìn thấy" được hệ thống đang khỏe hay ốm thông qua logs, metrics, traces.
- Capacity & Performance: Đảm bảo hệ thống đủ sức chịu tải hiện tại và tương lai, chạy đủ nhanh.
- Change & Release Management: Kiểm soát cách các thay đổi (deploy code mới, đổi cấu hình) được đưa lên production một cách an toàn.
- Cost Optimization (FinOps): Tối ưu chi phí hạ tầng, tránh lãng phí.
- Security Operations: Vá lỗ hổng, quản lý bí mật (secrets), kiểm soát truy cập.
- Infrastructure & Automation: Dựng và quản lý hạ tầng bằng code (IaC), tự động hóa các việc lặp đi lặp lại.
- Disaster Recovery & Continuity: Chuẩn bị cho tình huống thảm họa để có thể phục hồi.
Ba nguyên tắc tư duy của người làm Ops
Trước khi vào ví dụ thực tế, có ba nguyên tắc tư duy nền tảng mà một người làm Ops giỏi luôn mang theo:
- Đo lường trước, hành động sau. Không đoán mò. Nếu không có số liệu chứng minh hệ thống đang chậm ở đâu, mọi nỗ lực "tối ưu" chỉ là mê tín.
- Ưu tiên khôi phục hơn tìm nguyên nhân. Khi prod đang sập, việc đầu tiên là làm nó chạy lại (mitigate), sau đó mới điều tra nguyên nhân gốc. Khách hàng không quan tâm bạn tìm ra lỗi hay chưa, họ chỉ muốn app chạy.
- Tự động hóa những việc lặp lại. Mọi thao tác thủ công lặp đi lặp lại đều là rủi ro (dễ sai) và lãng phí (tốn thời gian). Người làm Ops giỏi luôn tìm cách biến việc thủ công thành script.
Tình huống thực tế
Tình huống 1: Cú sập giờ cao điểm của một ứng dụng gọi xe
Hãy lấy bối cảnh một công ty gọi xe công nghệ giả định tên GoNhanh hoạt động tại Việt Nam. Vào một tối thứ Sáu lúc 18h30 — giờ tan tầm cao điểm — ứng dụng bắt đầu báo lỗi "Không tìm thấy tài xế" cho khoảng 40% người dùng, dù thực tế có hàng nghìn tài xế đang online.
Đội phát triển tính năng lúc đó đang bận... code tính năng mới cho tuần sau. Người đứng ra xử lý là đội Tech Ops. Họ nhìn vào bảng giám sát (dashboard) và thấy: dịch vụ matching (ghép tài xế với khách) đang có độ trễ tăng vọt từ 200ms lên 8 giây. Truy vào metrics sâu hơn, họ phát hiện database chứa vị trí tài xế đang bị quá tải vì số lượng truy vấn tăng đột biến giờ cao điểm.
Đội Ops không sửa code matching (đó là việc của dev). Thay vào đó, họ mitigate ngay: bật thêm read replica cho database và tăng cache cho dữ liệu vị trí. Sau 12 phút, độ trễ về lại 300ms, tỷ lệ lỗi giảm còn 2%. Xong việc khôi phục, họ mới ghi lại sự cố để hôm sau cùng dev phân tích nguyên nhân gốc.
Bài học rút ra: Ranh giới rất rõ. Ops chịu trách nhiệm giữ hệ thống chạy trong giờ cao điểm và khôi phục nhanh khi sự cố. Việc "tại sao query lại nặng thế" có thể là việc chung của dev và Ops sau đó, nhưng trong lúc cháy nhà, Ops là người cầm vòi cứu hỏa. Ưu tiên khôi phục trước, điều tra sau.
Tình huống 2: Hóa đơn cloud tăng gấp đôi ở một startup fintech
Một startup fintech tại Singapore, gọi tên là PayLah Labs (giả định), phục vụ thị trường Đông Nam Á. Trong một cuộc họp tài chính, CFO tá hỏa: hóa đơn AWS tháng này là 84.000 USD, tăng gấp đôi so với ba tháng trước, trong khi lượng người dùng chỉ tăng 15%.
CFO không hiểu vì sao. Đội phát triển tính năng cũng ngơ ngác — họ chỉ biết viết code, không ai theo dõi chi phí hạ tầng. Đây chính xác là lãnh địa của Tech Ops (mảng FinOps).
Đội Ops vào cuộc, rà soát và phát hiện: một kỹ sư đã tạo môi trường test với 20 máy chủ cấu hình lớn để chạy thử tính năng mới, xong việc nhưng quên tắt. Chúng chạy không tải suốt 6 tuần, đốt gần 30.000 USD. Ngoài ra, hệ thống lưu log đang ghi mọi thứ ở mức chi tiết nhất và giữ 90 ngày, tạo ra chi phí lưu trữ khổng lồ không cần thiết.
Đội Ops tắt các máy chủ thừa, đặt chính sách tự động dọn môi trường test sau 7 ngày, và điều chỉnh vòng đời log xuống 14 ngày cho log chi tiết. Hóa đơn tháng sau giảm về 41.000 USD.
Bài học rút ra: Tech Ops không chỉ lo hệ thống "chạy được", mà còn lo hệ thống "chạy hiệu quả về chi phí". Đây là phần dễ bị bỏ quên ở các startup non trẻ, nơi ai cũng lao vào làm tính năng mà không ai giữ vai trò "quản gia" cho hạ tầng. Chữ efficiency trong định nghĩa Tech Ops chính là ở đây.
Tình huống 3: Sự nhầm lẫn vai trò khiến sự cố kéo dài
Một sàn thương mại điện tử tầm trung tại Hà Nội, gọi là ChoViet (giả định), gặp sự cố trang thanh toán trắng xóa vào ngày đầu đợt sale 6.6. Vấn đề không phải ở kỹ thuật khó, mà ở chỗ không ai biết đây là việc của mình.
Đội feature nghĩ: "Chắc lỗi hạ tầng, để Ops lo." Đội hạ tầng nghĩ: "Máy chủ vẫn chạy tốt, chắc lỗi code, để dev lo." Trong 47 phút, hai bên đùn đẩy nhau trong khi doanh thu giờ vàng bốc hơi. Cuối cùng hóa ra là một thay đổi cấu hình (config) nhỏ được deploy sáng hôm đó đã trỏ sai địa chỉ cổng thanh toán.
Sau sự cố, ChoViet mới định nghĩa lại rõ ràng: mọi sự cố production đều có một "người chỉ huy sự cố" (incident commander) thuộc đội Ops đứng ra điều phối, bất kể nguyên nhân cuối cùng là gì. Ops không nhất thiết phải tự sửa, nhưng Ops chịu trách nhiệm điều phối để sự cố được giải quyết.
Bài học rút ra: Phạm vi của Ops không chỉ là kỹ thuật, mà còn là trách nhiệm điều phối. Khi vai trò mờ, sự cố kéo dài. Định nghĩa rõ ai làm gì trong Ops chính là một phần công việc nền tảng — và đó là lý do bài học "định nghĩa và phạm vi" này quan trọng đến vậy.
Hướng dẫn từng bước
Nếu bạn đang muốn xác định phạm vi Tech Ops cho đội của mình (hoặc đơn giản là muốn hiểu rõ mình đang làm gì), đây là quy trình 5 bước thực tế:
- Liệt kê các hệ thống production đang chạy. Viết ra tất cả dịch vụ, ứng dụng, database đang phục vụ khách hàng thật. Bạn không thể vận hành thứ mình không biết nó tồn tại.
- Với mỗi hệ thống, hỏi bốn câu: Nó có ổn định không? Có được giám sát không? Ai chịu trách nhiệm khi nó sập? Chi phí vận hành của nó là bao nhiêu? Bốn câu này ánh xạ trực tiếp vào bốn trụ cột: reliability, observability, ownership, cost.
- Vẽ ranh giới Dev — Ops. Ghi rõ: việc nào là "xây mới" (thuộc feature team), việc nào là "giữ cho chạy" (thuộc Ops). Với những việc nằm giữa (ví dụ: performance tuning), ghi rõ đó là trách nhiệm chung và cách phối hợp.
- Xác định điểm mù. Tìm những hệ thống không ai giám sát, không ai chịu trách nhiệm, hoặc không ai biết chi phí. Đây là những quả bom hẹn giờ. Ưu tiên xử lý chúng trước.
- Ghi lại thành tài liệu sống. Đừng để định nghĩa phạm vi nằm trong đầu một người. Viết ra, chia sẻ, và cập nhật khi tổ chức thay đổi. Một tài liệu phạm vi rõ ràng giúp người mới hòa nhập nhanh và tránh cảnh đùn đẩy như tình huống ChoViet ở trên.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm Tech Ops với "chỉ trực sửa lỗi". Nhiều người nghĩ Ops chỉ là ngồi chờ hệ thống sập rồi sửa. Thực tế, phần lớn công việc Ops giá trị nhất là phòng ngừa và tự động hóa để sự cố ít xảy ra hơn. Nếu đội Ops của bạn suốt ngày chữa cháy, đó là dấu hiệu họ đang thiếu thời gian cho việc phòng ngừa.
Lỗi 2: Đánh đồng Ops với DevOps hay SRE. Đây là các khái niệm liên quan nhưng không đồng nghĩa. Tech Ops là phạm vi công việc (giữ prod chạy). DevOps là một văn hóa và cách làm việc (xóa rào cản giữa dev và ops). SRE là một cách tiếp cận cụ thể để làm Ops bằng tư duy kỹ sư phần mềm. Chúng ta sẽ phân biệt kỹ ở các bài sau (đặc biệt Bài 7 và Bài 60), nên ở đây chỉ cần nhớ: đừng dùng lẫn lộn chúng như thể là một.
Lỗi 3: Ops ôm hết mọi thứ. Ở các công ty nhỏ, đội Ops dễ bị biến thành "cái sọt rác", cứ việc gì không rõ chủ thì đẩy sang Ops. Điều này khiến Ops quá tải và làm mờ ranh giới. Mẹo: luôn quay lại câu hỏi gốc — "việc này là giữ cho chạy hay xây mới?" — để quyết định nó có thuộc Ops không.
Mẹo 1: Bắt đầu từ production, không phải từ công cụ. Người mới hay lao vào học Kubernetes, Terraform trước. Nhưng gốc rễ của Ops là hiểu hệ thống production của bạn cần gì. Công cụ chỉ là phương tiện.
Mẹo 2: Nói ngôn ngữ của business. Khi giải thích giá trị của Ops cho sếp, đừng nói "chúng ta giảm p99 latency". Hãy nói "chúng ta đảm bảo khách vẫn thanh toán được trong giờ cao điểm, giữ được doanh thu". Kết nối kỹ thuật với kết quả kinh doanh là kỹ năng khiến người làm Ops được coi trọng.
Bài tập thực hành
Bài tập 1 — Phân loại công việc. Dưới đây là 6 đầu việc. Hãy phân loại mỗi việc là thuộc Feature Development, Tech Operations, hay cả hai (trách nhiệm chung), và giải thích ngắn gọn lý do:
- Viết tính năng cho phép người dùng thanh toán bằng QR code.
- Thêm máy chủ để chịu tải khi app được lên báo và lượng truy cập tăng gấp 5.
- Điều tra vì sao hóa đơn cloud tăng bất thường tháng này.
- Tối ưu một truy vấn database chạy chậm gây timeout ở giờ cao điểm.
- Thiết lập cảnh báo khi tỷ lệ lỗi của dịch vụ thanh toán vượt 1%.
- Thiết kế lại giao diện màn hình giỏ hàng cho đẹp hơn.
Bài tập 3 — Tự phản tư. Viết một đoạn 150 từ trả lời: "Trong định nghĩa Tech Ops gồm ba yếu tố ổn định, hiệu quả, an toàn — theo bạn yếu tố nào thường bị các công ty non trẻ ở Việt Nam bỏ quên nhất, và vì sao?" Không có đáp án đúng tuyệt đối; mục tiêu là rèn tư duy phản biện về phạm vi Ops.
(Gợi ý đáp án Bài tập 1: (1) Feature; (2) Ops; (3) Ops; (4) Cả hai — Ops phát hiện và có thể mitigate, dev sửa gốc; (5) Ops; (6) Feature.)
Tóm tắt
Qua bài học này, bạn cần khắc sâu ba điểm cốt lõi:
- Tech Operations là tập hợp các thực hành giữ cho hệ thống production chạy ổn định, hiệu quả và an toàn. Ba từ khóa ổn định — hiệu quả — an toàn chính là kim chỉ nam của mọi việc Ops làm.
- Ops khác biệt căn bản với phát triển tính năng ở câu hỏi nền tảng: feature team hỏi "xây thêm gì?", còn Ops hỏi "giữ cho những gì đã có chạy tốt thế nào?". Ví von: feature là đội xây tòa nhà, Ops là ban quản lý vận hành tòa nhà.
- Phạm vi Ops trải rộng từ incident management, observability, capacity, change management, đến cost optimization, security và disaster recovery — nhưng luôn có một sợi chỉ đỏ xuyên suốt: trách nhiệm giữ và điều phối để production luôn khỏe mạnh.
Ở các bài tiếp theo, chúng ta sẽ đi sâu vào từng mảng của tấm bản đồ này, bắt đầu từ vòng đời và vai trò trong Incident Management. Nhưng dù đi xa đến đâu, hãy luôn nhớ định nghĩa nền tảng bạn vừa học ở bài này — nó là chiếc la bàn giúp bạn không lạc lối.