Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn mở ứng dụng ngân hàng để chuyển tiền lúc 9 giờ sáng thứ Hai, nhưng màn hình cứ quay tròn rồi báo lỗi. Hoặc bạn vào một sàn thương mại điện tử đúng giờ flash sale, click "Mua ngay" và nhận về trang trắng. Trong những khoảnh khắc đó, có một đội ngũ ở phía sau đang căng mình để mọi thứ trở lại bình thường trước khi hàng chục nghìn người dùng khác cũng gặp lỗi tương tự. Đó chính là công việc của IT Operations — hay còn gọi tắt là Ops.
Nếu các lập trình viên (developer) là người xây ngôi nhà, thì Ops là người vận hành ngôi nhà đó: đảm bảo điện nước chạy đều, cửa nẻo an toàn, và khi có sự cố thì có người đến sửa ngay. Một sản phẩm phần mềm dù được viết đẹp đến đâu, nếu không có ai lo phần vận hành thì cũng chỉ là code nằm im trên máy tính. Chính vì vậy, đây là bài học nền tảng — bài mở đầu của cả khóa. Trước khi chúng ta đi sâu vào Incident Management, SRE, hay Observability ở các bài sau, bạn cần hiểu bức tranh tổng thể: Ops là gì, đội ngũ Ops làm những việc gì, và tại sao vai trò này ngày càng quan trọng trong bất kỳ công ty công nghệ nào — từ startup vài người ở TP.HCM cho tới các tập đoàn như Shopee, VNG hay Techcombank.
Mục tiêu của bài này không phải dạy bạn một kỹ thuật cụ thể, mà là giúp bạn có được tấm bản đồ nghề nghiệp để định vị mọi kiến thức phía sau.
Khái niệm cốt lõi
IT Operations là gì?
IT Operations là tập hợp các hoạt động, quy trình và con người chịu trách nhiệm giữ cho hệ thống công nghệ của một tổ chức chạy ổn định, an toàn và hiệu quả về chi phí. Nói ngắn gọn: developer viết ra tính năng, còn Ops đảm bảo tính năng đó luôn sẵn sàng phục vụ người dùng — 24 giờ mỗi ngày, 7 ngày mỗi tuần.
Điểm khác biệt cốt lõi giữa Development và Operations nằm ở mục tiêu. Developer được đo lường bằng tốc độ ra tính năng mới. Ops được đo lường bằng độ ổn định của hệ thống. Hai mục tiêu này thường xung đột — thêm tính năng mới đồng nghĩa với thêm rủi ro. Chính sự căng thẳng lành mạnh này là lý do các mô hình như DevOps và SRE ra đời (chúng ta sẽ học kỹ ở các bài sau).
Năm trụ cột trách nhiệm của Ops
Công việc của một đội Ops, dù ở công ty nào, thường xoay quanh năm trụ cột chính. Hãy ghi nhớ năm trụ cột này vì nó chính là khung xương của toàn bộ khóa học.
1. Giữ hệ thống chạy ổn định (Reliability). Đây là nhiệm vụ trung tâm. Ops phải đảm bảo website, API, cơ sở dữ liệu luôn "sống" và phản hồi nhanh. Người ta thường đo bằng chỉ số uptime (thời gian hệ thống hoạt động) — ví dụ "99,9% uptime" nghĩa là hệ thống chỉ được phép "chết" khoảng 8,7 giờ trong cả năm. Nghe thì nhỏ, nhưng với một sàn TMĐT, mỗi phút downtime giữa giờ cao điểm có thể mất hàng trăm triệu đồng doanh thu.
2. Ứng phó và quản lý sự cố (Incident Response & Management). Không hệ thống nào chạy mãi không lỗi. Khi sự cố xảy ra — server sập, database quá tải, thanh toán lỗi — Ops là người đầu tiên nhận được cảnh báo (alert) và phải nhanh chóng phát hiện, khoanh vùng, khắc phục. Đây là công việc đòi hỏi bình tĩnh và có quy trình rõ ràng, không phải "chữa cháy" theo cảm tính. (Bài 2 và Bài 5 sẽ đi sâu vào phần này.)
3. Hoạch định năng lực (Capacity Planning). Ops phải trả lời câu hỏi: "Hệ thống của chúng ta chịu được bao nhiêu người dùng cùng lúc? Khi nào cần thêm server?" Dự báo sai theo hướng thiếu thì hệ thống sập lúc đông khách; dự báo thừa thì đốt tiền vào hạ tầng không dùng đến. Đây là bài toán cân bằng cực kỳ thực tế. (Bài 3 và Bài 13 sẽ mổ xẻ chi tiết.)
4. Tuân thủ và bảo mật (Security & Compliance). Ops chịu trách nhiệm vá lỗ hổng (patching), quản lý quyền truy cập, sao lưu dữ liệu, và đảm bảo hệ thống tuân thủ các quy định. Với các công ty tài chính hay xử lý dữ liệu cá nhân người Việt (theo Nghị định 13/2023 về bảo vệ dữ liệu cá nhân), phần này không phải "tùy chọn" mà là bắt buộc pháp lý.
5. Tối ưu chi phí (Cost Optimization). Hạ tầng đám mây (cloud) như AWS, Google Cloud, hay Azure tính tiền theo mức sử dụng. Một cấu hình lãng phí có thể khiến hóa đơn cloud phình to gấp đôi mà không ai để ý. Ops ngày càng phải đội thêm chiếc mũ "quản lý tài chính hạ tầng" — lĩnh vực này gọi là FinOps. (Bài 35 sẽ dành riêng cho chủ đề này.)
Ba khái niệm bạn sẽ gặp lại xuyên suốt khóa học
Trước khi đóng phần lý thuyết, hãy làm quen với ba thuật ngữ nền tảng:
- SLA (Service Level Agreement): cam kết chính thức với khách hàng, ví dụ "chúng tôi cam kết 99,9% uptime". Vi phạm có thể phải đền bù.
- Downtime: khoảng thời gian hệ thống không hoạt động. Kẻ thù số một của Ops.
- On-call: cơ chế trực sự cố. Luôn có một người "cầm máy" sẵn sàng xử lý khi hệ thống báo lỗi lúc nửa đêm.
Tình huống thực tế
Tình huống 1: Sàn TMĐT và cơn ác mộng flash sale
Hãy hình dung một công ty TMĐT giả định tên "ChợViệt", quy mô trung bình tại Việt Nam. Vào lúc 0 giờ ngày 11/11 — thời điểm sale lớn nhất năm — lượng truy cập bất ngờ tăng gấp 15 lần so với ngày thường. Trong 3 phút đầu, cơ sở dữ liệu đơn hàng bị quá tải, thời gian phản hồi vọt từ 200 mili-giây lên 12 giây, và khoảng 40% người dùng thấy lỗi khi thanh toán.
Điều đáng nói: đội developer của ChợViệt đã viết code rất tốt. Vấn đề không nằm ở code, mà ở vận hành. Đội Ops đã không dự báo đúng đỉnh tải (thiếu Capacity Planning), không cấu hình tự động mở rộng server (auto-scaling), và hệ thống cảnh báo phát hiện sự cố quá chậm.
Bài học rút ra: Một sản phẩm tốt có thể thất bại vì vận hành kém. Sự cố này gần như 100% có thể phòng tránh nếu đội Ops làm tốt hai trụ cột "Reliability" và "Capacity Planning". Đây cũng là lý do vì sao các sàn lớn như Shopee hay Lazada tổ chức "diễn tập tải" (chúng ta gọi là Game Day, học ở Bài 25) trước mỗi mùa sale.
Tình huống 2: Khi tiết kiệm nhầm chỗ khiến hóa đơn cloud phình to
Một startup fintech tại Singapore (thị trường Đông Nam Á rất gần với Việt Nam về đặc thù) từng chia sẻ câu chuyện: họ chạy toàn bộ hệ thống trên AWS. Trong giai đoạn phát triển nhanh, đội kỹ thuật liên tục tạo server mới để test và... quên tắt đi. Sau 4 tháng, hóa đơn cloud lên tới hơn 60.000 USD/tháng, trong khi ước tính thực tế chỉ cần khoảng 35.000 USD.
Khi một kỹ sư Ops được giao rà soát, họ phát hiện gần 40% chi phí đến từ các server "ma" không còn phục vụ ai, cùng với việc lưu trữ dữ liệu ở loại ổ đĩa đắt tiền không cần thiết. Sau khi dọn dẹp và đặt cảnh báo ngân sách (budget alert), họ cắt được gần một nửa hóa đơn mà không ảnh hưởng gì đến hiệu năng.
Bài học rút ra: Trụ cột "Cost Optimization" không phải chuyện của riêng phòng kế toán. Trong công ty công nghệ, người hiểu rõ hạ tầng nhất — tức là Ops — mới là người tối ưu chi phí hiệu quả nhất. Một kỹ sư Ops giỏi FinOps có thể "kiếm về" cho công ty số tiền lớn hơn cả lương của chính họ.
Tình huống 3: Cuộc gọi lúc 3 giờ sáng
Anh Minh, một System Administrator tại một công ty SaaS ở Hà Nội, kể lại: một đêm anh nhận cuộc gọi cảnh báo tự động lúc 3 giờ sáng — hệ thống gửi email cho khách hàng đã ngừng hoạt động. Anh mở laptop, xem log, phát hiện dịch vụ gửi mail bên thứ ba đã hết hạn mức (quota). Anh chuyển tạm sang nhà cung cấp dự phòng trong 20 phút, hệ thống hoạt động lại, rồi sáng hôm sau viết một bản postmortem (báo cáo mổ xẻ sự cố, học ở Bài 11) để cả đội cùng rút kinh nghiệm và thiết lập cảnh báo sớm hơn về hạn mức.
Bài học rút ra: Công việc Ops gắn liền với văn hóa on-call — luôn có người sẵn sàng ứng phó. Nhưng một đội Ops trưởng thành không dừng ở "chữa cháy". Họ biến mỗi sự cố thành cơ hội cải tiến, để lần sau không phải thức dậy lúc 3 giờ sáng nữa. Đó là tư duy cốt lõi phân biệt Ops chuyên nghiệp với Ops nghiệp dư.
Hướng dẫn từng bước
Nếu bạn muốn bắt đầu tư duy như một người làm Ops ngay từ hôm nay, hãy thực hành khung tư duy sáu bước sau khi nhìn vào bất kỳ hệ thống nào:
- Vẽ ra bức tranh hệ thống. Liệt kê các thành phần chính: người dùng truy cập vào đâu, dữ liệu đi qua những đâu (web server, ứng dụng, cơ sở dữ liệu, các dịch vụ bên ngoài). Bạn không thể vận hành thứ bạn không hiểu.
- Xác định điểm yếu chí mạng (single point of failure). Hỏi: "Nếu thành phần này chết, điều gì xảy ra?" Nếu chỉ có một database và nó sập là cả hệ thống ngừng, thì đó là điểm cần ưu tiên gia cố.
- Thiết lập cách quan sát hệ thống. Bạn cần biết hệ thống đang khỏe hay ốm. Tối thiểu phải theo dõi được: hệ thống còn sống không, phản hồi nhanh hay chậm, tỷ lệ lỗi bao nhiêu. (Đây là nền tảng của Observability — cả cụm bài 18–23.)
- Cài đặt cảnh báo (alert) cho những gì thực sự quan trọng. Chỉ báo động khi có vấn đề ảnh hưởng người dùng thật, tránh báo động giả gây "mệt mỏi cảnh báo".
- Chuẩn bị sẵn kịch bản ứng phó. Với mỗi sự cố có thể lường trước, hãy viết sẵn các bước xử lý (runbook — Bài 10). Lúc sự cố xảy ra là lúc tệ nhất để bắt đầu suy nghĩ.
- Rà soát chi phí và bảo mật định kỳ. Mỗi tháng, dành thời gian xem hóa đơn cloud có bất thường không, có server nào bỏ quên không, có bản vá bảo mật nào cần cập nhật không.
Lỗi thường gặp & mẹo
Lỗi 1: Nghĩ rằng "Ops chỉ là khởi động lại server". Đây là hiểu lầm phổ biến nhất. Việc restart chỉ là phần nổi. Ops hiện đại là kỹ thuật thực thụ — liên quan đến kiến trúc, tự động hóa, phân tích dữ liệu và cả kinh tế học hạ tầng. Nếu bạn thấy mình cứ restart mãi một dịch vụ, đó là dấu hiệu cần tìm và sửa nguyên nhân gốc, không phải làm hoài động tác chữa cháy.
Lỗi 2: Chỉ tập trung giữ hệ thống chạy mà quên chi phí. Nhiều đội tự hào 100% uptime nhưng lại đốt tiền gấp ba lần cần thiết. Uptime và chi phí phải được cân nhắc cùng lúc.
Lỗi 3: Không ghi chép lại sự cố. Sửa xong là quên. Kết quả là cùng một lỗi lặp lại năm lần trong một năm. Mẹo: luôn viết postmortem, dù ngắn, cho mỗi sự cố đáng kể.
Lỗi 4: Ranh giới "đây là việc của dev, không phải việc của tôi". Ops và Dev trong công ty hiện đại phải phối hợp chặt. Văn hóa đổ lỗi giữa hai bên là dấu hiệu của một tổ chức chưa trưởng thành.
Mẹo vàng cho người mới: Hãy học cách tự động hóa những việc lặp đi lặp lại. Nếu bạn làm một thao tác thủ công quá ba lần, hãy nghĩ cách viết script để máy làm thay. Công việc thủ công lặp lại này có một cái tên riêng — toil — và giảm toil là một trong những kỹ năng đáng giá nhất của nghề Ops (Bài 53).
Bài tập thực hành
- Vẽ bản đồ hệ thống. Chọn một dịch vụ bạn dùng hằng ngày (ví dụ: một ứng dụng đặt đồ ăn như ShopeeFood hoặc GrabFood). Vẽ sơ đồ đơn giản các thành phần bạn nghĩ nó có: ứng dụng di động, máy chủ, cơ sở dữ liệu, dịch vụ thanh toán, bản đồ. Đánh dấu đâu có thể là điểm yếu chí mạng.
- Đóng vai Ops trong sự cố. Đọc lại Tình huống 1 (ChợViệt). Viết ra 5 việc bạn sẽ làm ngay trong 10 phút đầu tiên khi hệ thống quá tải giữa flash sale, và 3 việc bạn sẽ làm sau đó để nó không tái diễn.
- Soi hóa đơn. Tự đặt câu hỏi: nếu bạn phụ trách một hệ thống chạy trên cloud tốn 20.000 USD/tháng, bạn sẽ kiểm tra những gì để tìm chỗ lãng phí? Liệt kê ít nhất 4 điểm.
- Tự đánh giá. Với năm trụ cột đã học (Reliability, Incident Response, Capacity Planning, Security, Cost), hãy tự chấm điểm mức độ hiểu của bạn hiện tại từ 1 đến 5 cho mỗi trụ cột. Điểm thấp nhất chính là nơi bạn nên chú ý nhất ở các bài tiếp theo.
Tóm tắt
IT Operations là "trái tim vận hành" của mọi công ty công nghệ — nơi biến code thành dịch vụ thực sự chạy được và phục vụ người dùng liên tục. Chúng ta đã đi qua:
- Định nghĩa Ops và điểm khác biệt cốt lõi với Development: Dev tối ưu tốc độ, Ops tối ưu độ ổn định.
- Năm trụ cột trách nhiệm: giữ hệ thống ổn định, ứng phó sự cố, hoạch định năng lực, bảo mật & tuân thủ, và tối ưu chi phí.
- Ba tình huống thực tế cho thấy vận hành kém có thể đánh sập cả sản phẩm tốt, tiết kiệm nhầm chỗ khiến chi phí phình to, và mỗi sự cố đều là cơ hội cải tiến.
- Khung tư duy sáu bước để bắt đầu nhìn hệ thống như một người làm Ops.