DevOps Foundations

1. DevOps là gì? Định nghĩa nghiêm túc

Định nghĩa ngắn nhất: DevOps là cách làm phần mềm trong đó nhóm phát triển (Development) và nhóm vận hành (Operations) hợp tác chặt chẽ, cùng chịu trách nhiệm cho toàn bộ vòng đời sản phẩm — từ ý tưởng đến production và bảo trì.

Nhưng định nghĩa đó vẫn mơ hồ. Cụ thể hơn, DevOps có 3 lớp:

1. Văn hóa (Culture) — niềm tin chung: trust, blameless, shared ownership, fail-fast learning. Đây là phần khó nhất, mất năm tháng.
2. Thực hành (Practices) — CI/CD, Infrastructure as Code, monitoring, postmortem, error budget. Có quy trình rõ.
3. Công cụ (Tools) — Git, Docker, Kubernetes, Terraform, Prometheus. Tool đến và đi.

Khi ai đó nói "team chúng tôi đang làm DevOps", họ thường chỉ chạm tới lớp Tools (đã có Jenkins) hoặc Practices (có pipeline). Văn hóa thì mới là tâm điểm — và là phần ít team đạt được.

1.1. Tại sao tên là "DevOps"?

Năm 2009, Patrick Debois (kỹ sư Bỉ) tổ chức conference đầu tiên gọi là DevOpsDays tại Ghent. Tên ghép từ Dev + Ops, ý nói phá tường ngăn 2 phòng ban. Trước đó, John Allspaw và Paul Hammond ở Flickr trình bày bài huyền thoại "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr" tại Velocity 2009 — đây là khoảnh khắc cộng đồng nhận ra: Dev và Ops có thể hợp tác thay vì đối đầu.

1.2. Vấn đề DevOps cố giải quyết

Trước DevOps, Dev và Ops có mục tiêu xung đột:

Hai bên sẽ thường xung đột trong các tình huống thực tế: Dev push 1 release, deploy fail, Ops nói "code lỗi", Dev nói "config lỗi"; hoặc prod chậm, Ops yêu cầu giảm thông lượng, Dev kêu "vậy feature mới sẽ trễ"; hoặc Dev cần thư viện mới, Ops từ chối vì "chưa được kiểm thử". Sản phẩm chậm, mất ưu thế cạnh tranh.

DevOps giải bài toán bằng cách gắn KPI chung: cả 2 chịu trách nhiệm cho deployment frequency, MTTR, customer satisfaction. Khi cùng KPI, mâu thuẫn biến thành hợp tác.

2. Lịch sử ra đời — 50 năm gọn lại

2.1. Thời tiền sử (1970-1990): Sysadmin thủ công

Code build trên máy dev → copy file qua FTP lên server → ssh vào sửa config trực tiếp. Lỗi xảy ra liên tục: server "snowflake" (mỗi cái khác nhau, không ai nhớ ai cài gì), configuration drift, "works on my machine".

2.2. Thời Waterfall (1990-2005)

Dự án có 4 giai đoạn nối tiếp: Requirements → Design → Implementation → Deploy. Mỗi giai đoạn vài tháng. Khi Dev xong, "throw over the wall" cho QA → khi xong cho Ops deploy. Mỗi lần qua tường, kiến thức và context mất một phần.

Vấn đề: requirement thay đổi sau khi xong implementation → đập đi xây lại. Big-bang release vài tháng/lần, lỗi nhiều, rollback đau.

2.3. Thời Agile (2001-2010)

Năm 2001, 17 người ký Agile Manifesto — đề ra nguyên lý làm việc lặp ngắn, customer feedback liên tục. Scrum, XP, Kanban phát triển. Iteration giảm từ 6 tháng xuống 2 tuần.

Nhưng Agile chỉ áp dụng cho Dev. Ops vẫn waterfall: deploy lên prod vẫn vài tháng/lần. Khoảng cách Dev (2 tuần) và Ops (3 tháng) tạo ra "agile bottleneck" — Dev xong nhanh nhưng feature kẹt ở Ops.

2.4. Sự ra đời của DevOps (2007-2009)

• 2007-2008: Patrick Debois (Bỉ) làm consultant chính phủ, frustrated bởi sự cô lập Dev/Ops. Bắt đầu nói chuyện công khai về cách giải quyết.
• 06/2009: 10+ Deploys Per Day at Flickr trình bày tại O'Reilly Velocity, San Jose. Đây là proof-of-concept đầu tiên: deploy nhiều lần/ngày không phải mơ. Họ nhấn mạnh: tools (build/deploy automation), culture (respect, trust, blamelessness).
• 10/2009: DevOpsDays đầu tiên tại Ghent, Bỉ. Tên "DevOps" chính thức ra đời.
• 2010-2013: Cộng đồng tăng trưởng. Sách Continuous Delivery (2010, Jez Humble) định nghĩa CD. The Phoenix Project (2013, Gene Kim) là tiểu thuyết transform văn hóa.

2.5. Container Era (2013-2018)

• 03/2013: Docker ra mắt — đóng gói app + dependency lại thành 1 unit chạy mọi nơi. Solomon Hykes demo tại PyCon: "Build, ship, run any app, anywhere."
• 06/2014: Kubernetes open source bởi Google (dựa trên Borg).
• 2014: Terraform 0.1 (HashiCorp) — IaC declarative.
• 2015: CNCF (Cloud Native Computing Foundation) thành lập, đỡ đầu Kubernetes.

2.6. Cloud Native (2018-2024)

• Service mesh (Istio 2017, Linkerd 2018), GitOps (ArgoCD 2018), Observability (OpenTelemetry 2019).
• FinOps thành đề tài chính khi cloud spend vượt kiểm soát.
• Khái niệm "Platform Engineering" và "Internal Developer Platform" (IDP) phổ biến.

2.7. AI-Ops + Platform Era (2024+)

AI hỗ trợ chẩn đoán incident, autoscaling theo dự đoán. Backstage (Spotify) thành de-facto IDP. FinOps tích hợp vào platform. DevOps tiếp tục tiến hóa nhưng văn hóa cốt lõi giữ nguyên.

3. CALMS — 5 trụ cột văn hóa DevOps

Năm 2010, Jez Humble đề xuất khung CALMS để mô tả văn hóa DevOps. Đây là kim chỉ nam đánh giá team có thực sự "DevOps" hay chỉ "DevOps cosplay".

3.1. C — Culture (Văn hóa)

Văn hóa là gốc. Khi văn hóa sai, mọi tool đều thất bại. Đặc trưng văn hóa DevOps:

• Trust — tin đồng nghiệp làm đúng, không micromanage.
• Blameless — sau incident, hỏi "hệ thống của ta thiếu gì khiến lỗi xảy ra?", không phải "ai làm sai?".
• Shared ownership — code chạy trên prod là của mọi người, không phải "của Ops".
• Psychological safety — dám nói "tôi không biết", "tôi đã làm sai".
• Continuous learning — postmortem, brown bag, internal tech talk.

3.2. A — Automation (Tự động hóa)

Quy tắc: "Nếu làm thủ công 3 lần, lần thứ 4 hãy tự động hóa."

Các thứ phải automate:

• Build — compile, package, container build.
• Test — unit, integration, E2E, security scan.
• Deploy — push artifact lên environment.
• Provision — tạo server, network, DB (IaC).
• Configure — install package, set config (Ansible, cloud-init).
• Monitor — alert, dashboard, log aggregate.
• Recovery — auto-restart, auto-scale, auto-failover.

Mục tiêu: chỉ giữ lại task cần quyết định thủ công (architecture, business decision). Mọi việc thực thi đều automate.

3.3. L — Lean (Tinh gọn)

Lean học từ Toyota Production System. Loại bỏ 7 lãng phí (waste):

1. Partially done work — code chưa merge nằm chờ.
2. Extra features — feature không ai dùng.
3. Relearning — không document, mỗi lần debug từ đầu.
4. Handoffs — chuyển task qua nhiều người, mỗi lần mất context.
5. Delays — chờ approve, chờ env, chờ infra.
6. Task switching — nhiều việc song song, không cái nào xong.
7. Defects — bug bị release, phải fix sau.

DevOps thực hiện small batch: deploy thường xuyên + nhỏ thay vì hiếm + lớn. Vì:

• Lỗi nhỏ, dễ debug (1 commit deploy → biết ngay commit đó gây lỗi).
• Rollback dễ.
• Feedback nhanh từ user.
• Reduce work-in-progress (WIP).

3.4. M — Measurement (Đo lường)

Câu nói của Peter Drucker: "Cái gì không đo được, không quản được."

DevOps đo:

• Performance — latency P50/P95/P99, throughput, error rate.
• Reliability — uptime, SLO compliance.
• Velocity — DORA 4 metrics (xem mục 6).
• Quality — code coverage, defect escape rate.
• Customer — NPS, conversion rate.

Đặc biệt: vanity metrics (số commit, số deploy) ít giá trị nếu không liên kết với business outcome. Đo cái quan trọng, không đo cái dễ đo.

3.5. S — Sharing (Chia sẻ)

Kiến thức là tài sản team, không phải cá nhân. Cách chia sẻ:

• Postmortem công khai — sau incident, viết lên wiki, mọi người đọc.
• Runbook — quy trình xử lý incident, không phụ thuộc 1 người.
• RFC (Request for Comments) — đề xuất kiến trúc, mọi người comment.
• Internal tech talk — chia sẻ kiến thức.
• Pair programming, mob programming.
• "Bus factor" — nếu 1 người bị bus, ai thay được? Mục tiêu bus factor > 2 cho mọi system critical.

"If only one person can do something, you have a single point of failure — in the team, not just the system."

4. Ba cách (Three Ways) của Phoenix Project

Cuốn The Phoenix Project (Gene Kim, 2013) đặt ra 3 nguyên lý cốt lõi:

4.1. The First Way — Flow (từ Dev sang Ops)

Tối ưu dòng chảy work từ Dev → Test → Ops → Customer. Kỹ thuật:

• Visualize work — Kanban board.
• Limit WIP — không nhận thêm task khi quota đầy.
• Reduce batch size — small commit, small PR, small deploy.
• Reduce handoffs — cross-functional team.
• Continuously identify constraints (theory of constraints).

4.2. The Second Way — Feedback (từ Ops ngược về Dev)

Phản hồi liên tục, fast, ngược dòng:

• Test trong CI báo Dev biết bug ngay.
• Monitoring báo Dev biết code chậm.
• User feedback (NPS, support ticket) báo product team.
• Incident postmortem báo cả công ty.

Mục tiêu: feedback loop tối thiểu (giây-phút thay vì ngày-tuần).

4.3. The Third Way — Continual Learning & Experimentation

Văn hóa thử nghiệm, học hỏi:

• A/B testing.
• Chaos engineering — chủ động làm lỗi để tìm điểm yếu.
• Game day — tập dượt incident.
• 20% time — thời gian tự do nghiên cứu.
• Tolerate mistakes if they teach.

Đặt ngược lại: nếu team không có thời gian học, không có quyền sai, sẽ không có cải tiến.

5. DevOps Lifecycle — 8 giai đoạn vô tận

Lifecycle DevOps thường vẽ thành biểu tượng vô cực ∞ — không có điểm bắt đầu hay kết thúc. 8 giai đoạn:

Lưu ý: lifecycle là liên tục, không phải tuần tự một lần. Mỗi commit nhỏ đi qua hết 8 stage trong vài phút.

6. DORA — 4 Metrics đo "DevOps thật sự"

Năm 2014-2019, DORA (DevOps Research and Assessment, sau Google mua lại) khảo sát hơn 30,000 dev qua 6 năm. Kết luận: high-performing team luôn vượt low-performing team trên 4 metric duy nhất:

6.1. Deployment Frequency

Định nghĩa: tần suất team push code lên production.

6.2. Lead Time for Changes

Định nghĩa: thời gian từ commit code → code chạy production.

6.3. MTTR — Mean Time to Recover

Định nghĩa: thời gian trung bình từ khi incident xảy ra → recover hoàn toàn.

6.4. Change Failure Rate

Định nghĩa: % deploy gây lỗi production cần rollback hoặc hotfix.

6.5. Bài học từ DORA

• Speed và Stability không đối nghịch. Elite team vừa deploy nhanh hơn vừa lỗi ít hơn. Đây là phát hiện quan trọng nhất.
• Practice quan trọng hơn tool. Team có Jenkins/K8s xịn nhưng deploy 1 lần/tháng = Low. Team dùng GitHub Actions cơ bản nhưng deploy hàng ngày = High.
• Văn hóa quyết định. Westrum culture (generative, learning) tương quan mạnh với high-performing.

7. DevOps trong dòng chảy Agile / Lean / Toyota

DevOps không phát sinh từ chân không — nó đứng trên vai 3 phong trào:

7.1. Toyota Production System (1948-)

Taiichi Ohno phát minh Lean Manufacturing:

• Just-in-Time — sản xuất theo demand, không stockpile.
• Andon Cord — bất cứ công nhân nào thấy lỗi đều có quyền dừng dây chuyền. (DevOps tương đương: bất cứ ai cũng có quyền block deploy nếu thấy bất ổn.)
• Kaizen — cải tiến liên tục, từng bước nhỏ.
• Genchi Genbutsu — đến tận nơi xem (DevOps: chạy production thật, không chỉ đọc spec).

7.2. Lean Software Development (Mary & Tom Poppendieck, 2003)

Adapt Lean cho phần mềm. 7 nguyên lý:

1. Eliminate waste
2. Build quality in
3. Create knowledge
4. Defer commitment (last responsible moment)
5. Deliver fast
6. Respect people
7. Optimize the whole

7.3. Agile (2001-)

Agile Manifesto, 12 nguyên tắc. Quan trọng nhất:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

DevOps = Agile mở rộng tới Operations. Agile dừng ở "delivery to QA"; DevOps tiếp tục "delivery to production và operate continuously".

7.4. So sánh dòng chảy

8. Anti-pattern — DevOps cosplay

Nhiều công ty tuyên bố "đang làm DevOps" nhưng thực ra chỉ tạo silo mới. Các anti-pattern điển hình:

8.1. "DevOps Team" silo

Tạo team mới gọi là DevOps, nhét hết Jenkins/Docker/K8s vào đó. Dev gửi ticket "deploy giùm tôi", DevOps team làm. Đây chính là Ops cũ đổi tên — không thay đổi gì về văn hóa.

Đúng hơn: dev tự deploy, DevOps team (nay gọi là Platform team) build self-service tool để dev tự làm.

8.2. "DevOps Engineer" job title

Đăng tin tuyển "DevOps Engineer" với job description: "thành thạo Jenkins, Docker, K8s, Terraform, Ansible". Đây là sysadmin cộng kỹ năng tool — không phải DevOps.

Đúng hơn: tuyển SRE, Platform Engineer, hoặc Cloud Engineer với rõ trọng tâm. "DevOps Engineer" là term marketing.

8.3. Tool-first

"Ta cài Jenkins → đã làm DevOps." Tool không có ý nghĩa nếu văn hóa vẫn cũ (deploy 1 lần/quý, dev không có quyền vào prod, blame culture).

8.4. NoOps

Một số người nói "với serverless ta không cần Ops nữa". Sai. Vẫn có observability, scaling, security, cost — chỉ là infra Ops được abstract đi. Đặt code trên Lambda không tự động làm tool stable.

8.5. "Shift-left everything"

Bắt dev làm hết: code + test + security + ops + on-call. Kết quả: dev burn out, không tập trung được. Đúng hơn: shift-left knowledge, không phải workload. Có Platform team support.

8.6. Áp DORA mà không hiểu

Đặt KPI "deploy 10 lần/ngày". Kết quả: dev tách commit thành nhiều PR vô nghĩa để đạt số. Đây là Goodhart's Law: "Khi metric trở thành target, nó hết là metric tốt."

9. DevOps vs SRE vs Platform Engineering

Ba khái niệm hay bị lẫn lộn. So sánh:

Câu nói nổi tiếng:

"Class SRE implements interface DevOps." — Liz Fong-Jones

Tức là SRE là cách triển khai cụ thể của DevOps. DevOps là tư tưởng, SRE là cách Google làm.

Còn Platform Engineering: "Platform Engineering is what happens when you industrialize DevOps." — Sam Newman. Platform team build internal tool để các product team tự làm.

10. Mythbusters — 7 hiểu lầm phổ biến

1. "DevOps là tool" — Sai. DevOps là văn hóa. Tool chỉ là phương tiện.
2. "DevOps thay thế Agile" — Sai. DevOps mở rộng Agile sang Ops. Không thay thế.
3. "DevOps không cần document" — Sai. DevOps cần document nhiều hơn (runbook, RFC, postmortem) — nhưng document thực dụng, không phải spec dài 100 trang.
4. "DevOps = Cloud" — Sai. DevOps áp dụng được on-prem, hybrid, edge. Cloud chỉ tiện nhất.
5. "DevOps làm Ops mất việc" — Sai. Ops chuyển vai trò sang Platform/SRE — kỹ năng nâng cao, lương cao hơn.
6. "DevOps đảm bảo zero downtime" — Sai. Mục tiêu là recover nhanh, không phải zero failure. Failure là chuẩn.
7. "DevOps có thể cài trong 3 tháng" — Sai. Tool 3 tháng. Văn hóa 2-3 năm.

11. Bài tập

1. Tự khảo sát công ty/team hiện tại theo CALMS:
   • Cho điểm mỗi yếu tố C-A-L-M-S từ 1-5.
   • Yếu tố nào yếu nhất? Tại sao?
   • Nếu được sửa 1 thứ trong tháng tới, sẽ là gì?
2. Tính DORA cho project gần nhất:
   • 30 ngày qua deploy bao nhiêu lần?
   • Lead time trung bình từ commit → prod?
   • Có incident không? MTTR thế nào?
   • % deploy phải rollback?
   • Bạn đang ở cấp Elite / High / Medium / Low?
3. Đọc một engineering blog:
   • Đọc "How Discord Stores Trillions of Messages" hoặc "How Stripe Manages Risk".
   • Tóm tắt: họ giải quyết vấn đề gì? Trade-off nào?
   • So sánh với cách bạn (sẽ) làm.
4. Phân biệt thuật ngữ: viết 2-3 câu mỗi cái:
   • Continuous Integration vs Continuous Delivery vs Continuous Deployment.
   • SLI vs SLO vs SLA.
   • MTTR vs MTBF vs MTTF.
   • Blameless postmortem vs trách nhiệm cá nhân.
5. Tình huống xung đột:
   • Dev push code lên prod, sau 30 phút system chậm, support flood ticket.
   • Phong cách "blame culture" sẽ phản ứng thế nào?
   • Phong cách DevOps sẽ phản ứng thế nào?
   • So sánh kết quả lâu dài (sau 1 năm) của 2 cách.
6. Đọc Phoenix Project (chương 1-3):
   • Bill Palmer được giao nhiệm vụ gì?
   • Brent Geller là ai? Đại diện cho vấn đề gì?
   • WIP (Work In Progress) gây hại thế nào trong câu chuyện?
7. Vẽ DevOps lifecycle 8-stage cho project hiện tại: ở mỗi stage, tool nào đang dùng? Stage nào đang manual? Stage nào tự động?

12. Quiz