Bức tranh DevOps và production
Thực hiện trên server của bạn, rồi kiểm tra từng tiêu chí.
Vì sao cần học
Học Docker, Kubernetes hay Terraform mà chưa biết chúng giải quyết vấn đề gì thì dễ thành thuộc lệnh mà không hiểu. Bài này đặt câu hỏi trước khi học công cụ: một ứng dụng chạy được trên laptop cần thêm những gì để người dùng truy cập ổn định, cập nhật an toàn và khôi phục được khi có sự cố?
Module 00 chỉ giới thiệu ngắn. Mỗi khái niệm sẽ được học sâu ở module dùng đến nó (spiral learning).
Mục tiêu
Sau bài này bạn có thể:
- Giải thích DevOps là cách tổ chức để thay đổi phần mềm nhanh và an toàn, không phải tên một công cụ hay một chức danh.
- Phân rã một web app thành các thành phần cần có khi chạy production.
- Nhận diện điểm lỗi đơn lẻ (SPOF) và rủi ro khi triển khai.
- Phân biệt rollback, backup/restore, RTO và RPO.
- Chọn được vài chỉ số (SLI) cho biết hệ thống đang chạy tốt.
Điều kiện tiên quyết
- Biết mở terminal và sửa file bằng một trình soạn thảo. Bấm biểu tượng ⓘ ở góc trên bên phải khối lệnh để mở phần giải thích lệnh và tham số; bấm lần nữa để thu gọn.
- Để bấm Kiểm tra, cần liên kết agent theo bài Chuẩn bị workspace thực hành. Bạn có thể viết bài phân tích trước rồi kiểm tra sau.
Mental model
Từ "chạy được" đến "chạy ổn định"
Lập trình viên thường kết thúc ở câu "trên máy tôi chạy được". Vận hành bắt đầu từ câu hỏi tiếp theo: chạy ở đâu, ai truy cập, lỗi thì sao, cập nhật thế nào, dữ liệu có mất không.
Áp dụng nguyên tắc Problem → Limitation → Solution → Trade-off cho mọi quyết định:
Ứng dụng chạy bằng
python3 app.pytrong terminal → logout là tiến trình dừng → cần trình quản lý tiến trình (systemd) → phải viết unit file và học thêm một công cụ.
Trong ví dụ này, python3 là chương trình chạy mã Python và app.py là file mã nguồn được chạy. Đây là tình huống minh họa, chưa yêu cầu bạn có file app.py hay chạy lệnh này.
Khái niệm nền tảng
| Khái niệm | Hiểu ngắn gọn | Học sâu ở |
|---|---|---|
| Dev vs Ops, DevOps, SDLC | Dev muốn thay đổi nhanh, Ops muốn hệ thống ổn định. DevOps giảm xung đột này bằng tự động hóa, đo lường và trách nhiệm chung trong suốt vòng đời phần mềm. | 06, 19 |
| CI / Continuous Delivery / Continuous Deployment | CI: mỗi thay đổi được build và test tự động. Delivery: luôn sẵn sàng phát hành. Deployment: tự phát hành lên production khi pass. | 06 |
| Infrastructure as Code | Mô tả hạ tầng bằng file trong Git thay vì thao tác tay. | 07, 08 |
| GitOps | Git là nguồn sự thật; một agent kéo trạng thái từ Git và áp vào hệ thống. | 16 |
| SRE | Vận hành bằng tư duy kỹ sư phần mềm: SLO, error budget, tự động hóa việc lặp lại. | 19 |
| Platform Engineering | Xây nền tảng nội bộ để đội phát triển tự phục vụ. | 19 |
| Declarative vs imperative, desired state | Imperative: "chạy lệnh A rồi B". Declarative: "tôi muốn có 3 bản chạy", hệ thống tự tìm cách đạt. | 08, 10 |
| Idempotency | Chạy lại nhiều lần cho cùng kết quả, không tạo thêm tác dụng phụ. | 07 |
| Reconciliation | Vòng lặp so sánh trạng thái thực tế với trạng thái mong muốn rồi sửa chênh lệch. | 10, 16 |
| Latency / throughput | Một request mất bao lâu, hệ thống xử lý được bao nhiêu request mỗi giây. | 17 |
| Availability / reliability | Tỉ lệ thời gian dùng được; khả năng làm đúng việc theo thời gian. | 17, 19 |
| SPOF, scaling | Thành phần mà khi hỏng thì cả hệ thống ngừng; mở rộng theo chiều dọc hoặc chiều ngang. | 09, 11, 13 |
| Rollback | Quay về phiên bản trước khi bản mới lỗi. | 04, 06, 11, 16 |
| RTO / RPO | RTO: được phép ngừng tối đa bao lâu. RPO: được phép mất tối đa bao nhiêu phút dữ liệu. | 04, 19 |
| SLI / SLO / SLA | SLI là chỉ số đo, SLO là mục tiêu nội bộ, SLA là cam kết có hệ quả với khách hàng. | 17, 19 |
Rollback khác backup
Rollback đưa code hoặc cấu hình về bản cũ. Nó không đưa dữ liệu về trạng thái cũ. Nếu bản mới chạy migration xóa một cột, rollback code không lấy lại cột đó; chỉ backup và restore mới làm được. Vì thế mọi kế hoạch nâng cấp có thay đổi dữ liệu đều cần backup đã được thử restore.
Thực hành (Guided Lab)
Tình huống
Một nhóm khởi nghiệp nhờ bạn đưa ứng dụng KDC Notes lên Internet. Hiện trạng:
- Web app Python, chạy bằng
python3 app.pytrên laptop của lập trình viên, port 5000. - Dữ liệu ghi chú lưu trong PostgreSQL cài trên chính laptop đó.
- Người dùng upload file đính kèm, app lưu vào thư mục
uploads/cạnh mã nguồn. - Quên mật khẩu thì app gửi email qua tài khoản Gmail cá nhân của một lập trình viên, mật khẩu ghi thẳng trong
config.py. - Mỗi lần cập nhật, lập trình viên
git pull(lấy và tích hợp thay đổi từ repository Git ở máy chủ) rồi khởi động lại app. Mất khoảng 2 phút downtime. - Mục tiêu: 2.000 người dùng trong 3 tháng tới, chấp nhận ngừng tối đa 1 giờ khi có sự cố lớn, không được mất quá 15 phút dữ liệu.
Yêu cầu
Tạo file phân tích trong lab root, mặc định là ~/kdc-labs:
mkdir -p ~/kdc-labs/foundations
cd ~/kdc-labs/foundations
Giải thích lệnh và tham số
| Thành phần | Ý nghĩa |
|---|---|
mkdir | Tạo thư mục. |
-p trong mkdir | Tạo cả thư mục cha còn thiếu; không báo lỗi chỉ vì thư mục đã tồn tại. |
~ | Thư mục home của tài khoản đang dùng; trên Mac của bạn thường là /Users/<tên-user>. |
~/kdc-labs/foundations | Thư mục lưu bài phân tích, nằm trong lab root. |
cd | Đổi thư mục làm việc của terminal; không tạo thư mục. |
Lệnh thành công thường không in gì. Chạy pwd để in đường dẫn thư mục hiện tại, rồi ls để liệt kê tên file và thư mục bên trong. Không cần sudo cho thư mục bài tập trong home của bạn.
Viết analysis.md với đúng năm heading cấp 2 dưới đây. Mỗi phần chỉ cần vài gạch đầu dòng; không cần biết công cụ cụ thể, hãy mô tả nhu cầu.
# Phân tích KDC Notes
## Thành phần
<!-- Cần những thành phần gì để chạy production? Máy chủ, reverse proxy, TLS, DNS, database, lưu trữ file, gửi email, secrets, log... -->
## Luồng request
<!-- Người dùng gõ địa chỉ trên trình duyệt: request đi qua những bước nào cho đến database rồi quay lại? -->
## Điểm lỗi đơn lẻ
<!-- Thành phần nào hỏng thì toàn bộ app ngừng? Rủi ro bảo mật nào cần xử lý ngay? -->
## Rollback
<!-- Bản mới bị lỗi thì quay lại thế nào? Backup database ra sao để đạt RPO 15 phút và RTO 1 giờ? -->
## Đo lường
<!-- Những chỉ số nào cho biết app đang phục vụ tốt (SLI)? Đặt một SLO thử. -->
Gợi ý tự đánh giá
Bài phân tích tốt thường đề cập:
- Thư mục
uploads/trên một máy là SPOF và không đi theo khi chuyển server. - Mật khẩu email trong mã nguồn là rủi ro bảo mật: cần đưa ra khỏi Git và đổi mật khẩu vì nó đã nằm trong lịch sử commit.
- RPO 15 phút nghĩa là backup database mỗi ngày một lần là không đủ.
git pulltrực tiếp trên production làm rollback khó; nên đóng gói phiên bản để quay lại được.- SLI nên đo từ góc nhìn người dùng, ví dụ tỉ lệ request thành công hoặc thời gian phản hồi, không chỉ CPU.
Tự kiểm tra (Verification)
grep '^## ' ~/kdc-labs/foundations/analysis.md
Giải thích lệnh và tham số
grep tìm và in các dòng khớp mẫu trong file. Mẫu '^## ' nghĩa là tìm dòng bắt đầu (^) bằng hai dấu # và một dấu cách. Dấu nháy đơn giữ nguyên mẫu để shell không diễn giải nó. Đường dẫn cuối lệnh là file cần đọc; lệnh này không sửa file.
Lệnh phải in ra đủ năm heading. Sau đó chọn server và bấm Kiểm tra kết quả. Agent chỉ kiểm tra cấu trúc file; nội dung là để bạn tự đánh giá và mang theo khi học các module sau.
Ghi chú production
Giữ file này. Ở Module 04 bạn sẽ triển khai chính kiến trúc này bằng tay. Ở Module 20 (capstone) bạn sẽ thấy nhiều câu trả lời trong bài này thay đổi khi đã có container, Kubernetes và observability.