Điếu văn cho DevOps

Khái niệm và lịch sử của DevOps

• DevOps là một khái niệm được đưa ra vào khoảng năm 2007, với mục tiêu xóa bỏ ranh giới giữa những người quản lý phần cứng và những người viết phần mềm
• Ban đầu, đây là nỗ lực mô phỏng các quy trình và ý tưởng của NASA nhằm nâng cao độ an toàn của việc triển khai mã
• Vào thời điểm đó, quy trình triển khai phần mềm diễn ra như sau:
  • Nhóm phát triển chuẩn bị bản phát hành phần mềm máy chủ, nhóm QA kiểm thử rồi triển khai cho khách hàng
  • Nhóm vận hành nhận playbook bao gồm các thay đổi của phần mềm và cách ứng phó khi xảy ra sự cố
  • Triển khai cập nhật dần dần trong trung tâm dữ liệu và theo dõi
  • Ấn định ngày triển khai và giám sát sau triển khai

Các vấn đề của DevOps

• DevOps đòi hỏi rất nhiều lao động
• Cần sự phối hợp giữa nhóm phát triển, nhóm QA, technical writer và nhóm vận hành
• Việc phát hành tính năng diễn ra chậm, và các bản cập nhật quan trọng được ưu tiên trước
• Nhiều tổ chức áp dụng DevOps vì các lý do sau:
  • Không thể dễ dàng thay thế nhân sự kỹ thuật
  • Tuyển dụng khó khăn và tốn kém
  • Các nhà cung cấp SaaS giúp giảm bớt độ phức tạp
  • Nhấn mạnh lợi thế của nền tảng cloud
  • Các nhà phát triển không hài lòng vì phải mất rất lâu để một thay đổi nhỏ được triển khai

Hình hài thực tế của DevOps

• DevOps hướng tới việc tích hợp nhóm phát triển và nhóm vận hành thành một nhóm duy nhất
• Nhóm QA bị cắt giảm, và nhờ triển khai nhanh cùng phản hồi nhanh mà thời gian kiểm thử nội bộ được rút ngắn
• DevOps đôi khi bị nhầm lẫn với SRE của Google, nhưng SRE có cách tiếp cận có cấu trúc và nghiêm ngặt hơn
• Quy trình thực tế của DevOps như sau:
  • Nhà phát triển tạo branch trên git và thêm tính năng
  • Mở PR, đồng đội review rồi merge vào main
  • Hệ thống CI/CD bắt đầu build và push container lên registry
  • Hệ thống CD thông báo bản phát hành mới tới máy chủ và theo dõi việc triển khai có thành công hay không
  • Theo dõi các thay đổi sau triển khai thông qua các chỉ số nhận biết bản phát hành

Các yếu tố khiến DevOps thất bại

• Nhà phát triển kiểm thử trong môi trường local rồi triển khai lên máy chủ Linux, tạo ra những khác biệt nhỏ
• Nhóm vận hành không theo dõi việc triển khai nên khó xử lý sự cố
• Nhà phát triển thiếu kiến thức về vận hành hệ thống
• Việc đưa container vào đã giải quyết được một phần vấn đề, nhưng độ phức tạp trong vận hành vẫn tồn tại

Sự xuất hiện của container và các giới hạn của nó

• Container đã giải quyết vấn đề "chạy ngon trên máy tôi"
• Đơn giản hóa các thành phần cấu hình của máy chủ Linux
• Những vấn đề vẫn còn tồn tại
  • Vận hành (Operate): yêu cầu chuyên môn cho bảo trì hạ tầng, nâng cấp, v.v.
  • Quan sát (Observe): khó khăn trong việc xây dựng và quản lý hệ thống giám sát phức tạp
  • Phản hồi liên tục: xử lý phản hồi nội bộ còn chưa đầy đủ
  • Khám phá (Discover): thiếu chia sẻ kiến thức giữa các nhóm
  • Lập kế hoạch (Plan): khó khăn trong việc lập kế hoạch tập trung

Sự xuất hiện của Platform Engineering

• Platform Engineering là khái niệm nối tiếp DevOps: thay vì để nhóm phát triển phải hiểu vận hành nền tảng và tự giải quyết vấn đề, nhóm nền tảng sẽ đảm nhận việc đó
• Cách tiếp cận này phân tách rõ trách nhiệm giữa nhóm phát triển và vận hành nền tảng, giúp vai trò rõ ràng hơn, nhưng vẫn đòi hỏi nhiều kỹ năng kỹ thuật
• Cả nhà phát triển lẫn nhóm vận hành đều phải làm nhiều việc hơn

Kết luận

• Xu hướng tìm kiếm các công cụ đơn giản và không phụ thuộc nền tảng trong không gian hạ tầng đang gia tăng
• Nhiều tổ chức đang từ bỏ các công nghệ phức tạp như Kubernetes và quay lại với các workflow đơn giản hơn
• Platform Engineering không phải là lời giải vạn năng, và các tổ chức cần phân biệt điều gì thực sự cần thiết với điều gì không cần thiết
• Cần giữ lại những ưu điểm của cách tiếp cận DevOps, đồng thời tập trung vào sự đơn giản và ổn định

Ý kiến của GN⁺

1. Sự tiến hóa của DevOps và tình hình hiện tại là một ví dụ cho thấy rõ sự thay đổi xu hướng trong ngành công nghệ. Việc nhận ra khoảng cách giữa mục tiêu lý tưởng ban đầu và thực tế, rồi tìm kiếm một cách tiếp cận thực dụng hơn, là điều khá thú vị

2. Việc chuyển sang platform engineering có thể được xem là một nỗ lực thừa nhận các giới hạn của DevOps và tìm kiếm lời giải mới. Tuy nhiên, đây cũng không phải giải pháp hoàn hảo, và sẽ cần một cách tiếp cận được tùy biến theo quy mô và đặc điểm của từng tổ chức

3. Khi độ phức tạp của công nghệ cloud-native và kiến trúc microservices tăng lên, sự đơn giản và ổn định đang được đánh giá lại. Điều này cho thấy khi lựa chọn công nghệ, cần coi trọng hơn giá trị kinh doanh và hiệu quả vận hành

4. Những thay đổi trong DevOps và platform engineering nhấn mạnh tầm quan trọng của việc học hỏi và thích nghi liên tục trong lĩnh vực phát triển và vận hành phần mềm. Người làm kỹ thuật không chỉ cần học công cụ và phương pháp mới mà còn phải phát triển khả năng cân bằng giữa yêu cầu kinh doanh và độ phức tạp kỹ thuật

5. Trong tương lai, cách phát triển và vận hành phần mềm nhiều khả năng sẽ trở nên linh hoạt hơn và phù hợp hơn với từng bối cảnh. Thay vì các tổ chức lớn và startup nhỏ cùng áp dụng một cách làm, xu hướng sẽ là lựa chọn quy trình và công cụ tối ưu theo tình huống riêng của mình

[kaydash]

Khá thường xuyên
những người quản lý
lại kỳ vọng rằng chỉ cần áp dụng khái niệm DevOps
thì một cuộc đổi mới vĩ đại sẽ xuất hiện mà không cần nỗ lực
đó là lối suy nghĩ sai lầm của những doanh nghiệp cũ kỹ
(bất kể là tập đoàn lớn hay doanh nghiệp nhỏ)

[GN⁺]

Ý kiến Hacker News

• Trọng tâm cốt lõi là tập trung vào "build, test, deploy" trong sơ đồ "devops cycle"

  • Nhấn mạnh vào tốc độ và không tính đến sự xuất sắc trong kỹ thuật
  • Sa thải đội vận hành và tái cấu trúc QA
  • Mọi đội đều có lịch trực on-call
  • Tạo ra những thay đổi hỗn loạn cho hệ thống để đổi lấy lợi ích ngắn hạn
  • Vài tháng sau, mỗi lần thay đổi đều phát sinh sự cố
  • Công cụ devops hữu ích nhưng tốn kém và gây nhiều thất vọng
  • Các lập trình viên mới không biết devops nhưng biết container

• Đây là ý kiến dựa trên những vấn đề mà các đội devops đã trải qua

  • Cần có khả năng thêm dịch vụ mới và quản lý hạ tầng một cách an toàn
  • Devops đã trở thành tiêu chuẩn, không còn cần những công việc quản trị hệ thống mang tính thủ công

• Chỉ trích Kubernetes là không đúng

  • Kubernetes là ví dụ điển hình của kỹ nghệ phần mềm xuất sắc, được hỗ trợ tốt và chạy ở mọi nơi
  • Tốt hơn là học Kubernetes thay vì dùng các bash script ngẫu hứng

• Devops là việc gỡ bỏ rào cản để giúp triển khai phần mềm dễ dàng hơn

  • Triển khai hằng ngày giúp đưa mã nguồn chất lượng cao hơn vào sản xuất
  • Việc có lựa chọn chỉ triển khai khi code đã sẵn sàng là điều quan trọng
  • Phát hành hằng tháng tạo áp lực và có thể dẫn đến những lựa chọn kém hiệu quả

• Devops là một triết lý chứ không phải một phương pháp luận

  • Mục tiêu là tích hợp vận hành vào SDLC
  • Cloud đã khiến điều này trở nên dễ dàng hơn
  • Sự xuất hiện của các đội "DevOps" đã làm méo mó triết lý ban đầu

• Việc "phá bỏ silo" của ban lãnh đạo gần như chỉ mang tính hình thức

  • Quyền hạn không đi kèm trách nhiệm thì không hiệu quả
  • Những nhân sự devops giỏi nhất thích tự thay thế chính mình bằng code
  • Công cụ devops đã trưởng thành và được tài liệu hóa tốt
  • Lập trình viên không học Kubernetes cũng giống như lập trình viên không biết lệnh Linux

• Nếu người dùng có thể trở thành tester thì nên làm như vậy

  • Chỉ tồn tại vấn đề về mặt kinh tế
  • Nếu có nhiều khách hàng thì hãy để người dùng kiểm thử; nếu có ít khách hàng thì phải tự kiểm thử

• Đội platform chỉ khả thi ở các doanh nghiệp lớn

  • Doanh nghiệp vừa và nhỏ thiếu nhân lực devops nên phải chấp nhận căng thẳng và rủi ro
  • Việc thiếu đội platform gây ra nhiều vấn đề

• Devops là một triết lý chứ không phải một phương pháp luận

  • Trải nghiệm trong các đội silo chứng minh sự cần thiết của devops
  • Devops giúp các đội hiểu đầy đủ dự án và có thể tự triển khai

• Devops có ý định tốt

  • Vòng phản hồi nhanh rất quan trọng đối với tốc độ phát triển
  • Cần tìm ra giải pháp tối ưu phù hợp với tổ chức và sản phẩm