Chúng ta dùng TechVerse như một **công ty giả định**: bạn vừa gia nhập một nhóm làm sản phẩm phần mềm với vai trò Junior DevOps Engineer. Tên công ty và câu chuyện chỉ giúp đặt kiến thức vào bối cảnh. Bạn không cần tài khoản nội bộ TechVerse để học.
## 1. Một tính năng đến tay người dùng như thế nào?
Giả sử nhóm cần thêm API tra cứu đơn hàng. PM làm rõ yêu cầu: khách hàng được xem đơn của mình, trạng thái phải dễ hiểu, trường hợp không tìm thấy đơn phải được xử lý. Backend viết API, Frontend nối giao diện, QA kiểm tra hành vi. Nhưng đến đây khách hàng vẫn chưa dùng được tính năng.
Nhóm còn phải đóng gói phần mềm, cấu hình môi trường chạy, triển khai phiên bản mới và theo dõi kết quả. Máy chạy ứng dụng cần đủ tài nguyên; ứng dụng phải kết nối đúng cơ sở dữ liệu; người trực vận hành cần biết cách nhận diện lỗi. Những việc này thuộc phần đưa phần mềm vào sử dụng và duy trì nó.
Đó là lý do vòng đời phát triển phần mềm, hay **SDLC**, không dừng ở viết code. Một thay đổi có giá trị khi giải quyết đúng nhu cầu và hoạt động trong môi trường thực tế. Nếu API trả đúng dữ liệu trong bài test nhưng thường xuyên timeout khi khách hàng sử dụng, công việc của nhóm chưa kết thúc.
Trong tình huống TechVerse, nhóm gồm Frontend, Backend, QA, DevOps và PM. Sơ đồ quản lý có thể đi từ lãnh đạo tới trưởng bộ phận, PM rồi các nhóm Agile. Tuy nhiên, khi xử lý một bản phát hành, điều bạn cần hiểu trước là ai cung cấp thông tin gì, ai thực hiện bước nào và cả nhóm kiểm chứng kết quả ra sao.
## 2. Vì sao bàn giao giữa Dev và Ops dễ gặp vấn đề?
Hãy xem một cách làm thủ công. Developer hoàn thành API, nén source thành file ZIP rồi gửi Ops. Ops đăng nhập máy chủ, chép file, sửa cấu hình và khởi động lại ứng dụng. Sau đó API lỗi. Developer hỏi phiên bản nào đang chạy; Ops hỏi có thay đổi biến môi trường nào không. Không ai có một bản ghi đầy đủ của lần triển khai.
Vấn đề không nằm ở việc hai nhóm tồn tại riêng. Vấn đề là thông tin và trách nhiệm bị ngắt ở điểm bàn giao. Developer biết code cần gì nhưng người triển khai không biết. Ops thấy lỗi nhưng khó nối lỗi với thay đổi gần nhất. QA kiểm tra một gói phần mềm khác với gói cuối cùng được đưa lên máy chủ.
Ta gọi tình trạng các nhóm làm việc tách biệt, ít chia sẻ thông tin là **silo**. Khi mỗi bên chỉ tối ưu phần việc của mình, toàn bộ quá trình có thể vẫn chậm và khó kiểm soát. Dev muốn đưa tính năng mới nhanh; Ops muốn hệ thống ổn định. Hai mong muốn đều hợp lý, nhưng cần một cách làm chung để cân bằng.
DevOps tập trung vào văn hóa cộng tác và các thực hành kết nối phát triển với vận hành. Team cùng chịu trách nhiệm về kết quả phần mềm, giảm thao tác lặp lại bằng tự động hóa và dùng phản hồi để cải tiến. Tốc độ và độ tin cậy là mục tiêu cần kiểm chứng, không phải kết quả tự động có được sau khi cài một công cụ.
Ví dụ, trước khi triển khai API, nhóm thống nhất cách đánh dấu phiên bản, danh sách kiểm tra và người theo dõi sau triển khai. Những bước đó đã cải thiện cách làm ngay cả khi pipeline còn đơn giản. Công cụ sẽ giúp thực hiện quy trình nhất quán hơn khi nhóm đã hiểu quy trình ấy.
## 3. DevOps đi cùng SDLC và Agile
Một vòng đời dễ nhớ là **Plan → Code → Build → Test → Release → Deploy → Operate → Monitor → Plan**. Các bước có thể lặp hoặc chồng lên nhau trong thực tế. Sơ đồ là cách đọc trách nhiệm và luồng phản hồi, không phải yêu cầu mọi công ty tổ chức thành tám bộ phận.
Ở Plan, nhóm làm rõ nhu cầu và tiêu chí chấp nhận. Ở Code, kỹ sư thay đổi mã nguồn. Build tạo ra gói có thể sử dụng, chẳng hạn một artifact hoặc container image. Test kiểm tra hành vi và phát hiện lỗi. Release chuẩn bị hoặc xác định phiên bản đủ điều kiện phát hành; Deploy đưa phiên bản vào môi trường đích. Cách dùng từ release có thể khác giữa các tổ chức, nên nhóm cần thống nhất nghĩa khi làm việc.
Operate là duy trì phần mềm đang chạy, xử lý sự cố và những nhu cầu vận hành. Monitor là quan sát các tín hiệu như lỗi, độ trễ và tài nguyên. Phản hồi từ đây quay lại Plan: có thể nhóm cần sửa một truy vấn chậm trước khi thêm tính năng mới. Một dashboard chỉ có ý nghĩa khi giúp ai đó quyết định hoặc hành động.
**Agile** giúp nhóm làm việc theo các bước nhỏ và thích nghi qua phản hồi. **DevOps** bổ sung sự phối hợp phát triển–vận hành và thực hành kỹ thuật để thay đổi tiếp tục đi tới môi trường sử dụng. Hai cách tiếp cận hỗ trợ nhau. Hoàn thành một sprint mà vẫn mất nhiều ngày bàn giao thủ công là một điểm nhóm có thể cải thiện.
Ngày đầu bạn chưa cần viết pipeline hay quản lý cluster. Hãy tập hỏi: đầu vào của bước này là gì, đầu ra có nhận diện được không, nếu thất bại ai nhận phản hồi? Ba câu hỏi đó giúp bạn đọc quy trình thực tế tốt hơn việc học thuộc danh sách công cụ.
## 4. CAMS: bốn góc nhìn để cải thiện cách làm
**Culture – Văn hóa.** Khi API lỗi sau triển khai, Dev, QA và Ops cùng xem dữ liệu, xác định ảnh hưởng và phân công xử lý. Thay vì kết thúc ở câu “máy tôi vẫn chạy”, developer chia sẻ cách tái hiện và thay đổi gần nhất. Trách nhiệm chung không có nghĩa là mọi người làm mọi việc; mỗi phần việc vẫn cần người phụ trách rõ ràng.
**Automation – Tự động hóa.** Một bước build phải được thực hiện giống nhau nhiều lần. Nếu kỹ sư tự gõ từng lệnh, sửa file rồi chép kết quả, thao tác dễ khác giữa các lần. Đưa bước đã hiểu rõ vào script hoặc pipeline giúp lặp lại và lưu kết quả. Tự động hóa một quy trình sai vẫn tạo kết quả sai, vì vậy cần kiểm tra đầu ra và cách xử lý lỗi.
**Measurement – Đo lường.** Nhóm cần dữ liệu để biết cải tiến có tác dụng hay không. Chẳng hạn, ghi thời gian từ lúc bắt đầu triển khai đến lúc xác nhận ứng dụng ổn, số lần triển khai cần khắc phục hoặc thời gian phục hồi dịch vụ. Phải thống nhất mốc bắt đầu và kết thúc trước khi so sánh. Không dùng riêng số lần deploy để kết luận một nhóm làm tốt hơn nhóm khác.
**Sharing – Chia sẻ.** Sau khi sửa lỗi cấu hình, ghi lại triệu chứng, nguyên nhân đã xác nhận và cách kiểm tra. Người vào ca sau có thể tiếp tục công việc. Tài liệu ngắn nhưng có bằng chứng hữu ích hơn câu “đã fix”. Chia sẻ cả điều chưa biết giúp nhóm tránh lặp lại một giả định sai.
Bạn có thể áp dụng cả bốn ngay trong lab: trao đổi khi gặp lỗi, dùng cùng lệnh kiểm tra, ghi kết quả, rồi viết ghi chú để người khác đọc được. Đây là một phiên bản nhỏ của cách làm trong doanh nghiệp, chưa cần hạ tầng phức tạp.
## 5. Ai phối hợp với ai trong một lần phát hành?
Trong câu chuyện API đơn hàng, Backend cung cấp thay đổi và những yêu cầu cấu hình. Frontend xác nhận cách gọi API và cách hiển thị lỗi. QA xây dựng các trường hợp kiểm tra, bao gồm người dùng không có quyền xem đơn hàng. DevOps hỗ trợ tự động hóa build/deploy và làm cho kết quả triển khai quan sát được. PM phối hợp thứ tự ưu tiên và thời điểm phát hành.
Trước khi đưa thay đổi đi tiếp, nhóm có thể ghi vào công việc: mã thay đổi liên quan, kết quả test, cấu hình cần thiết và cách nhận biết triển khai thành công. Khi thông tin nằm cùng một nơi, người nhận việc không phải đoán. Jira có thể là nơi theo dõi công việc; Confluence có thể lưu hướng dẫn. Một nhóm nhỏ vẫn có thể dùng issue và Markdown để đạt mục đích tương tự.
DevOps Engineer thường xây dựng và duy trì các cơ chế giúp nhóm giao phần mềm: pipeline, môi trường, cách quản lý cấu hình và tín hiệu vận hành. Nhưng developer vẫn có trách nhiệm với khả năng chạy của code; QA vẫn góp phần vào chất lượng; PM vẫn cần hiểu rủi ro phát hành. Đưa mọi yêu cầu vận hành cho một người sẽ tạo điểm nghẽn mới.
**Mở rộng – bối cảnh doanh nghiệp:** nhóm có thể mời người phụ trách bảo mật xem xét quyền truy cập hoặc dữ liệu nhạy cảm từ sớm. Với API đơn hàng, câu hỏi “ai được đọc đơn này?” nên xuất hiện khi làm rõ yêu cầu. Day 1 chỉ nhận diện trách nhiệm này; thiết kế bảo mật chi tiết nằm ngoài bài.
## 6. Đọc toolchain theo vấn đề cần giải quyết
Đừng bắt đầu bằng việc cài tất cả công cụ trên slide. Hãy gắn mỗi tên với một công việc cụ thể:
| Nhu cầu | Công cụ trong bài | Điều cần nhớ |
| --- | --- | --- |
| Theo dõi mã nguồn | Git / GitHub | Git quản lý lịch sử; GitHub hỗ trợ lưu repository và cộng tác |
| Tự động build, test, deploy | Jenkins / GitHub Actions | Chạy các bước được nhóm định nghĩa và lưu kết quả |
| Đóng gói môi trường chạy | Docker | Image là gói; container là một instance đang được chạy từ image |
| Điều phối ứng dụng container | Kubernetes | Quản lý workload container; chưa cần cài trong Day 1 |
| Quan sát hệ thống | Prometheus / Grafana | Thu thập dữ liệu metrics và trình bày để nhóm quan sát |
| Theo dõi việc và kiến thức | Jira / Confluence | Ghi công việc, quyết định và hướng dẫn |
**Git khác GitHub.** Bạn có thể dùng Git trên máy mà chưa có tài khoản GitHub. Một commit ghi nhận trạng thái thay đổi trong lịch sử; push đưa các commit tới repository từ xa. Đưa code lên GitHub cũng chưa có nghĩa ứng dụng đã được triển khai.
**CI – Continuous Integration** là thực hành tích hợp thay đổi thường xuyên và kiểm tra tự động. Trong ví dụ này, một push có thể kích hoạt workflow build và test. Workflow là định nghĩa các bước chạy; runner là nơi thực thi chúng. Cách tổ chức sự kiện, job và runner được giải thích trong [tài liệu GitHub Actions](https://docs.github.com/en/actions/get-started/understand-github-actions).
**CD có hai cách dùng.** Continuous Delivery giữ phần mềm ở trạng thái có thể phát hành, với khả năng có bước quyết định trước production. Continuous Deployment tự động đưa thay đổi đạt các kiểm tra tới production. Vì vậy, thấy chữ CI/CD chưa đủ để biết hệ thống có tự deploy production hay không; hãy đọc luồng và điều kiện của nhóm.
**Docker** giúp đóng gói ứng dụng và các phụ thuộc cần thiết trong image. Môi trường nhất quán hơn không có nghĩa mọi khác biệt biến mất: cấu hình, dữ liệu, mạng và tài nguyên vẫn ảnh hưởng kết quả. **Kubernetes** hỗ trợ quản lý ứng dụng container, nhưng không tự viết bài test hay sửa lỗi nghiệp vụ cho bạn. Xem [tổng quan Kubernetes](https://kubernetes.io/docs/concepts/overview/) khi cần hiểu vai trò của nó.
Toolchain trên là một ví dụ. Jenkins và GitHub Actions có thể là hai lựa chọn cho cùng nhu cầu; không bắt buộc dùng cả hai. Confluence hỗ trợ chia sẻ xuyên suốt quá trình, không phải một bước xử lý source code. Prometheus và Grafana giúp cung cấp phản hồi, không phải bằng chứng rằng một lần deploy đã đáp ứng mọi yêu cầu người dùng.
## 7. Ví dụ thực tế: đưa API đơn hàng đi qua một quy trình rõ ràng
Trở lại tình huống giả định, nhóm muốn tránh việc gửi ZIP không rõ phiên bản. Developer tạo commit cho thay đổi API rồi mở đề nghị xem xét code. QA và developer thống nhất các trường hợp test. Khi thay đổi được đưa vào luồng kiểm tra, CI lấy đúng revision và chạy build/test. Nếu test thất bại, nhóm sửa nguyên nhân trước khi đi tiếp.
Khi kiểm tra đạt, pipeline tạo image có định danh truy vết về thay đổi. Nhóm dùng image đó để triển khai môi trường thử nghiệm, xác nhận hành vi và quyết định có đưa tiếp tới production hay không. Sau triển khai, người được phân công theo dõi lỗi API và độ trễ, đồng thời kiểm tra một luồng người dùng quan trọng.
Giả sử số lỗi tăng sau phát hành. Nhóm có thể đối chiếu phiên bản hiện tại với thay đổi vừa đưa lên, đọc log liên quan và đánh giá cách phục hồi. Đây là lợi ích của thông tin xuyên suốt: biết đang chạy gì và biết bước nào đã kiểm tra. Tự động hóa không loại bỏ sự cố, nhưng có thể làm quá trình phát hiện và xử lý rõ ràng hơn.
**Mở rộng – phục hồi:** quay về phiên bản trước là một lựa chọn trong một số tình huống, nhưng phải xét tương thích cấu hình và dữ liệu. Nếu cấu trúc dữ liệu đã thay đổi, đổi image đơn thuần có thể chưa đủ. Bài này chỉ đặt câu hỏi phục hồi; không hướng dẫn thao tác production.
Sau sự cố, nhóm cập nhật test hoặc hướng dẫn và đưa công việc cải tiến vào kế hoạch. Đó là vòng phản hồi khép kín. Nếu chỉ dựng dashboard rồi không có người xem và xử lý, vòng này vẫn bị đứt.
## Hands-on: kiểm tra workstation và ghi lại bằng chứng
Thực hiện theo [lab workstation](lab.md). Bạn cần Git, Docker và VS Code trên máy học cá nhân. Nếu chưa cài, dùng hướng dẫn chính thức theo hệ điều hành trong lab; thời gian tải và xử lý yêu cầu hệ thống có thể vượt 25 phút.
Trong PowerShell trên Windows hoặc terminal trên Linux/macOS, kiểm tra Git:
```shell
git --version
```
Kết quả cần có `git version` và số phiên bản. Sau đó kiểm tra Docker:
```shell
docker version
```
Hãy phân biệt phần `Client` với `Server`: chỉ thấy phiên bản CLI chưa chứng minh đã kết nối được Docker Engine. Lệnh kiểm tra Engine được chọn trong cấu hình hiện tại, có thể ở máy khác. Lab hướng dẫn ghi nhận trường hợp lỗi mà không tự thay đổi service. Tham khảo [mô tả lệnh Docker version](https://docs.docker.com/reference/cli/docker/version/).
Mở VS Code, tạo một file Markdown trong thư mục học và ghi hệ điều hành, kết quả Git, trạng thái Docker, điều còn vướng. Extension phục vụ DevOps có thể bổ sung theo bài học sau; Day 1 không yêu cầu một bộ extension cụ thể. Jira/Confluence là **Optional / company-specific**; nếu không có quyền truy cập, dùng file Markdown thay thế.
## Những lỗi người mới thường gặp
- **Đồng nhất DevOps với chức danh.** Chức danh DevOps Engineer tồn tại; DevOps còn là cách cộng tác và thực hành của cả nhóm.
- **Học tên tool trước vấn đề.** Hãy giải thích công cụ giảm thao tác hoặc cung cấp thông tin nào trong luồng.
- **Cho rằng pipeline xanh nghĩa là sản phẩm chắc chắn đúng.** Kiểm tra chỉ bao phủ những gì nhóm đã định nghĩa; vẫn cần quan sát sau deploy.
- **Cho rằng Agile bị thay thế.** Nhóm vẫn cần vòng phản hồi về yêu cầu và cách làm, cùng khả năng đưa thay đổi vào vận hành.
- **Đánh dấu Docker đạt khi chỉ có Client.** Cần xem kết quả kết nối Engine và ghi lỗi nếu có.
## Checklist cuối bài
- [ ] Tôi giải thích được một điểm bàn giao dễ gây lỗi và cách cải thiện.
- [ ] Tôi mô tả được CAMS bằng hành động cụ thể.
- [ ] Tôi phân biệt được Git/GitHub và CI/CD ở mức nhập môn.
- [ ] Tôi chỉ ra được phần việc của Dev, QA, DevOps và PM.
- [ ] Tôi đã kiểm tra Git, Docker, VS Code và ghi đúng trạng thái.
## Bài tập
Hoàn thành việc kiểm tra Git, Docker và VS Code. Viết một ghi chú setup trên Confluence nếu có workspace được cấp; nếu không, nộp file `day-01-notes.md`. Ghi công cụ hoạt động, lỗi còn lại và trạng thái Jira nếu được yêu cầu trong lớp. Instructor sẽ đối chiếu bằng chứng cài đặt, đúng mục tiêu của bài gốc.
Để tự kiểm tra hiểu bài, viết thêm một đoạn mô tả API đơn hàng đi từ commit tới phản hồi vận hành. Chọn một điểm có thể thất bại và nêu ai cần phối hợp xử lý. Đây là bài bổ sung giúp nối các khái niệm với công việc, không đòi hỏi bạn triển khai API thật.
## Ngày tiếp theo
Previous: Không có — đây là bài đầu tiên. Next: **TBD** — Day 2 chưa được xử lý. [Course index](../../COURSE.md).
Nguồn bài: slide Day 1 do người học cung cấp; xem [bản đồ nguồn và phần bổ sung](source-map.md) cùng [tài liệu tham khảo](references.md).