Khóa học này ghi lại hành trình học các kiến thức nền tảng về “DevOps” trong 12 ngày. Các bài viết là bản tiếng Việt của tài liệu 90DayofDevOps của Micheal Cade và đã có qua sửa đổi, bổ sung, chỉnh sửa và tóm gọn cho phù hợp với người đọc Việt Nam.
Mục tiêu là dành ra 12 ngày để tìm hiểu về các lĩnh vực liên quan tới “DevOps” phục vụ cho việc xây dựng kiến thức nền tảng. Cuộc hành trình này nhằm giúp đỡ những bạn có chung mục tiêu và cũng kì vọng rằng tài liệu này sẽ làm phong phú thêm nguồn thông tin tiếng Việt về DevOps.
Ngày 1: Học một ngôn ngữ lập trình (Go)
Ngày 2: Kiến thức cơ bản về Linux
Ngày 3: Kiến thức về mạng (Network)
Ngày 6: Kiến thức cơ bản về Container
Ngày 7: Tổng quan về Kubernetes
Ngày 8: Cơ sở hạ tầng dưới dạng mã (Infrastructure as Code)
Ngày 9: Tự động hóa quản lý cấu hình (Configuration management)
Ngày 10: Tổng quan về CI/CD pipelines
Ngày 11: Giám sát, quản lý log và trực quan hóa dữ liệu
Ngày 12: Lưu trữ & Bảo vệ Dữ liệu
Dưới đây là một danh sách không bao gồm mọi khía cạnh của DevOps, nhưng nó sẽ tập trung vào các lĩnh vực mà tác giả cảm thấy sẽ hữu ích cho quá trình học và hiểu biết tổng quan. Mọi đóng góp đều được hoan nghênh.
Bắt đầu hành trình ngay bây giờ
Trong 12 ngày tới, tôi sẽ cố gắng ghi lại danh sách các tài nguyên này và đề cập tới những kiến thức nền tảng. Tôi cũng muốn nhận được sự giúp đỡ, ủng hộ của cộng đồng bằng cách chia sẻ hành trình của riêng bạn cũng như các tài nguyên bạn đã sử dụng để chúng ta có thể học hỏi, giúp đỡ lẫn nhau.
Trong bài viết này chúng ta sẽ tìm hiểu, khám phá các nguyên tắc cơ bản của DevOps trước khi đi sâu vào từng phần cụ thể.
Dưới đây là một road map về DevOps mà tôi nghĩ rằng mọi người nên xem kỹ từ đó có thể tạo bản đồ tư duy sao cho phù hợp với sở thích và mục đích của riêng mình:
Đây là một tài liệu tuyệt vời giúp tôi trong việc bắt đầu tạo danh sách này và chuẩn bị cho bài viết đầu tiên. Bạn cũng có thể thấy các chủ đề khác được đề cập chi tiết hơn 12 chủ đề được liệt kê trong danh sách của tôi.
Bước chân đầu tiên – DevOps là gì?
Trước khi bắt đầu hành trình 12 ngày để học những kiến thức liên quan tới DevOps, chúng ta nên bắt đầu với câu hỏi “DevOps là gì?”
Đầu tiên, DevOps không phải một công cụ. Bạn không thể mua, nó cũng không phải một phần mềm hay một dự án mã nguồn mở trên Github chúng ta có thể download. Nó cũng không phải là một ngôn ngữ lập trình và càng không phải là một phép thuật hắc ám.
DevOps là một cách để phát triển phần mềm một cách thông minh hơn.
Khoan, Dừng…khoảng chừng là 2 giây… nếu bạn không phải một nhà phát triển phần mềm, bạn có nên dừng hành trình của mình ngay bây giờ và không tiếp tục đọc tài liệu này???
Không hề. Hãy ở lại với anh em… Lý do vì DevOps là sự kết hợp giữa việc phát triển (Dev) và vận hành (Ops).
Như bạn có thể thấy, tôi chủ yếu làm việc với các VM và ở gần hơn với phần vận hành (Operations). Tuy nhiên trong cộng đồng, dù cho các bạn có các nền tảng khác nhau, làm việc ở các vị trí khác nhau, DevOps chắc chắn vẫn sẽ giúp bạn trong công việc hàng ngày. Dù là kỹ sư phát triển phần mềm, kỹ sư vận hành hệ thống tới các kỹ sư quản lý chất lượng đều có thể học và áp dụng các phương pháp tốt nhất trong công việc của mình bằng cách hiểu rõ hơn về DevOps.
DevOps là một tập hợp các phương pháp thực hành giúp chúng ta đạt được mục tiêu sau: Giảm thời gian từ khi lên ý tưởng cho một sản phẩm đến khi phát hành được sản phẩm nhằm phục vụ người dùng cuối, bất kể đó là một khách hàng bên ngoài hay là một người dùng nội bộ.
Một chủ đề khác mà chúng ta sẽ đề cập trong tuần đầu tiên là Phương pháp Agile
DevOps và Agile được áp dụng rộng rãi cùng với nhau giúp ứng dụng của bạn được phân phối liên tục.
Xem thêm: DevOps là gì? Các công cụ thường dùng trong DevOps
Điểm mấu chốt của tư duy, văn hoá DevOps là thu hẹp, chia nhỏ quy trình phát triển phần mềm có thể kéo dài nhiều năm thành các bản phát hành nhỏ hơn và thường xuyên hơn. Một điểm quan trọng khác cần hiểu ở đây là trách nhiệm của một kỹ sư DevOps trong việc thu hẹp khoảng cách giữa các nhóm đã được đề cập: nhóm phát triển, nhóm vận hành, nhóm quản lý chất lượng.
Từ góc độ DevOps, Phát triển, Kiểm thử và Triển khai đều liên quan tới nhóm DevOps.
Cuối cùng, Tự động hoá cũng phải được triển khai để các công việc đạt hiệu quả cao nhất.
Trách nhiệm của kỹ sư DevOps
Như đã đề cập ngắn gọn ở trên, chúng ta cần phải đi sâu hơn vào việc có hai phần chính khi tạo một ứng dụng. Đầu tiên là phát triển (Develop), nơi kỹ sư phát triển phầm mềm lập trình ứng dụng và kiểm tra (test) nó. Sau đó là phần vận hành (Operations) nơi ứng dụng được triển khai (deploy) và duy trì (maintain) trên máy chủ.
DevOps là liên kết giữa hai quá trình
Để hiểu rõ về DevOps và các nhiệm vụ mà một kỹ sư DevOps cần thực hiện, chúng ta cần hiểu về các công cụ, quy trình, tổng quan về chúng và cách chúng kết hợp với nhau.
Tất cả bắt đầu với ứng dụng! Bạn sẽ biết rõ rằng, khi nói tới DevOps, ứng dụng là trung tâm.
Các kỹ sư phát triển tạo ra các ứng dụng bằng nhiều công nghệ khác nhau, chúng ta sẽ đề cập tới điều này sau. Để phát triển ứng dụng, các kỹ sư phát triển cũng có thể sử dụng nhiều ngôn ngữ lập trình, công cụ xây dựng (build tools), kho mã (code repositories), v.v.
Là một kỹ sư DevOps, bạn không lập trình các ứng dụng nhưng việc hiểu rõ về cách làm việc của một kỹ sư phát triển cũng như các hệ thống, công cụ và quy trình mà họ sử dụng là chìa khoá thành công của bạn.
Bạn cần biết ứng dụng được cấu hình như thế nào để tương tác với tất các các dịch vụ hoặc dữ liệu cũng như đưa ra yêu cầu về cách mà chúng ta có thể và nên kiểm tra điều đó.
Ứng dụng cần được triển khai ở đâu đó, để cho đơn giản thì chúng ta sẽ coi đó là một máy chủ. Sau đó, người dùng cuối hoặc khách hàng sẽ truy cập tới ứng dụng thông qua máy chủ được triển khai.
Máy chủ này sẽ chạy ở đâu đó, có thể là on-premise, public cloud hoặc serverless (OK tôi đã đi quá xa, chúng ta sẽ không đề cập tới serverless nhưng đó là lựa chọn mà ngày càng nhiều doanh nghiệp đang sử dụng). Ai đó cần triển khai, cài đặt cấu hình các máy chủ này và chuẩn bị để chúng có thể chạy ứng dụng đã được phát triển. Công việc này có thể sẽ là nhiệm vụ của một kỹ sư DevOps.
Các máy chủ chạy một hệ điều hành và để đơn giản thì chúng ta sẽ coi đó là Linux, vì thế chúng ta sẽ có nguyên một phần hoặc một tuần để bạn có được kiến thức nền tảng về phần này.
Chúng ta cũng nên có kiến thức về mạng và cấu hình mạng vì có thể các máy chủ cần giao tiếp với nhau hoặc với các thành phần khác trong mạng và môi trường của nó. Đôi khi đây cũng sẽ là trách nhiệm của một kỹ sư DevOps. Chúng ta sẽ đi vào chi tiết trong các phần riêng về DNS, DHCP, cân bằng tải, v.v.
Quý bà/quý ông biết tuốt
Bạn không cần phải là một chuyên gia về mạng hoặc cơ sở hạ tầng nhưng bạn cần có kiến thức nền tảng về cách triển khai các thành phần của hệ thống và giúp chúng có thể kết nối với nhau. Cũng giống như vậy, bạn không cần là một kỹ sư phát triển nhưng cần có kiến thức cơ bản về ngôn ngữ lập trình. Bạn hoàn toàn có thể bắt đầu với tư cách là một chuyên gia trong lĩnh vực nào đó và sử dụng nó như một bước đệm tốt để bạn có thể làm quen với các lĩnh vực còn lại.
Khả năng cao là bạn cũng sẽ không quản lý và tương tác với các máy chủ hoặc ứng dụng hàng ngày.
Chúng ta đã nhắc tới máy chủ khá nhiều nhưng có khả năng là ứng dụng của bạn sẽ được phát triển để chạy trong các containers. Do phần lớn các containers vẫn cần chạy trên các máy chủ nên ngoài kiến thức về chúng, bạn cũng cần hiểu về ảo hoá, dịch vụ cơ sở hạ tầng trên cloud (Cloud IaaS). Trong 90 ngày này, containers sẽ là một phần được chú trọng.
Tóm tắt tổng quan
Ở một mặt, chúng ta có các kỹ sư phát triển để tạo ra các tính năng và sửa lỗi cho ứng dụng.
Mặt khác, chúng ta có một các môi trường, cơ sở hạ tầng hoặc máy chủ được cấu hình và quản lý để chạy ứng dụng này và giao tiếp với tất cả các dịch vụ mà ứng dụng cần.
Câu hỏi lớn là làm thế nào để chúng ta đưa những tính năng và bản sửa lỗi đó vào ứng dụng của mình và cung cấp cho những người dùng cuối?
Làm cách nào để chúng ta phát hành phiên bản mới của ứng dụng? Đây là một trong những nhiệm vụ chính của kỹ sư DevOps và điều quan trọng ở đây là không chỉ tìm ra cách thực hiện điều này một lần mà chúng ta cần thực hiện việc này liên tục theo một cách tự động, hiệu quả mà vẫn bao gồm quá trình kiểm thử!
Vòng đời DevOps – Tập trung vào ứng dụng
Trong những bài viết tới, chúng ta sẽ nói đến vòng đời của DevOps (Phát triển liên tục, Kiểm thử, Triển khai, Giám sát) rất nhiều lần. Nếu bạn muốn trở thành một kỹ sư DevOps thì bạn sẽ quen với việc lặp đi lặp lại những điều này. Tuy nhiên, việc liên tục cải thiện từng quá trình trong vòng đời này sẽ khiến công việc của chúng ta trở nên thú vị.
Sau đây, chúng ta sẽ nhìn tổng thể các quá trình phát triển ứng dụng từ khi bắt đầu tới khi kết thúc và nhắc lại điều này nhiều lần như một vòng lặp liên tục.
Phát triển
Hãy tưởng tượng chúng ta đang bắt đầu phát triển mội ứng dụng hoàn toàn mới. Nếu bạn là một kỹ sư phát triển, bạn cần thảo luận với khách hàng hoặc người dùng cuối về các yêu cầu của họ rồi đưa ra kế hoạch, những yêu cầu về mặt tính năng, thiết kế cho ứng dụng của bạn. Sau đó, chúng ta tạo ứng dụng mới này từ các yêu cầu đó.
Nói tới các công cụ ở quá trình này, không có yêu cầu thực sự nào khác ngoài việc chọn môi trường phát triển tích hợp (IDE) và ngôn ngữ lập trình mà bạn muốn sử dụng để viết ứng dụng.
Hãy nhớ rằng, là một kỹ sư DevOps, bạn có có thể không phải là người lên kế hoạch cũng như lập trình ứng dụng cho người dùng cuối. Việc này thường sẽ được một kỹ sư phát triển đảm nhiện. Tuy nhiên, sẽ rất tuyệt vời nếu bạn có thể đọc được một số đoạn mã và hiểu được các yêu cầu của ứng dụng, từ đó đưa ra các quyết định tốt nhất cho cơ sở hạ tầng cho hệ thống mới.
Ứng dụng này có thể được viết bằng bất cứ ngôn ngữ nào, nhưng điều quan trọng là mã ứng dụng nên được quản lý bởi một hệ thống kiểm soát phiên bản (version control system). Chúng ta sẽ tìm hiểu chi tiết hơn về mục này ở phần sau (cụ thể là sẽ tập trung vào git).
Dù có 1 hay nhiều thành viên tham gia vào dự án, phương pháp tốt nhất vẫn là sử dụng một kho lưu trữ(code repository) để lưu trữ mã giúp nhiều thành viên có thể cộng tác khi làm việc với mã chương trình. Kho lưu trữ mã có thể được lưu trữ công khai hoặc riêng tư, bạn cũng có thể sẽ nghe nói đến việc sử dụng GitHub hoặc GitLab làm kho lưu trữ. Chúng ta sẽ đề cập đến những điều này trong phần nói về Git.
Kiểm thử
Ở quá trình này, chúng ta đã có các yêu cầu và đang phát triển ứng dụng. Vấn đề tiếp theo là chúng ta cần đảm bảo rằng mã ứng dụng cần được kiểm thử ở các môi trường khác nhau mà chúng ta có hoặc cụ thể hơn là với ngôn ngữ lập trình chúng ta đã chọn.
Quá trình này cho phép nhóm quản lý chất lượng (QA) kiểm tra lỗi, chúng ta thường sử dụng các containers để mô phỏng môi trường kiểm thử để có thể giảm thiểu chi phí cho các máy chủ vật lý hoặc cơ sở hạ tầng trên cloud.
Quá trình này có khả năng cao là sẽ được tự động hoá như một phần của quá trình Tích hợp liên tục được nhắc tới sau đây.
Tự động hoá quá trình kiểm thử sẽ giải phóng 10, 100 thậm chí hàng nghìn kỹ sư quản lý chất lượng khỏi việc phải kiểm tra một cách thủ công. Từ đó họ có thể tập trung vào các phần khác trong hệ thống giúp tăng tốc độ phát triển, tạo ra nhiều chức năng mới hơn thay vì sa lầy vào việc kiểm tra lỗi và phần mềm và làm chậm quá trình phát hành các phiên bản mới theo mô hình thác nước truyền thống.
Tích hợp
Ở giữa vòng đời DevOps là Tích hợp – một phần rất quan trọng. Đây là một phương thức khi mà khi các lập trình viên thay đổi mã nguồn một cách thường xuyên hơn. Điều này có thể diễn ra hàng ngày hoặc hàng tuần.
Với mỗi thay đổi, ứng dụng sẽ được kiểm tra bằng các giai đoạn kiểm thử tự động, điều này sẽ phát hiện sớm các vấn đề hoặc lỗi trước khi đi tới quá trình tiếp theo.
Nhưng chúng tôi không tạo ra ứng dụng, chúng tôi mua nó từ một nhà cung cấp phần mềm
Đừng lo, rất nhiều doanh nghiệp làm vậy và sẽ tiếp tục làm điều này. Nhà cung cấp phần mềm sẽ là người thực hiện 3 quá trình ở trên nhưng có thể bạn vẫn muốn áp dụng quá trình cuối cùng vào ứng dụng của bạn. Quá trình này cho phép việc triển khai ứng dụng nhanh chóng và hiệu quản hơn.
Việc hiểu về các quá trình cũng rất quan trọng vì có thể bạn sẽ mua các ứng dụng từ nhà cung cấp ngày hôm nay, nhưng không chắc bạn sẽ làm điều tương tự vào ngày mai, hoặc có thể nó sẽ có ích khi bạn chuyển sang một công việc mới?
Triển khai
Cuối cùng thì chúng ta cũng đã xây dựng xong ứng dụng, kiểm thử với các yêu cầu của người dùng cuối, bây giờ chúng ta cần triển khai ứng dụng này để người dùng cuối có thể sử dụng.
Đây chính là quá trình mà các đoạn mã sẽ được triển khai lên các máy chủ của môi trường production và cũng chính là một quá trình cực kỳ thú vị và cũng chính là phần mà chúng ta sẽ đào sâu hơn trong 86 ngày còn lại.
Các ứng dụng khác nhau đòi hỏi các yêu cầu khác nhau về phần cứng và cấu hình. Đó là khi quản lý cấu hình ứng dụng (Application Configuration Management) và cơ sở hạ tầng ứng dụng dưới dạng mã (Infrastructure as Code) đóng vai trò then chốt trong vòng đời DevOps. Các ứng dụng có thể được đóng gói và chạy trong các containers hoặc chạy trên các máy ảo (VM). Điều này khiến chúng ta cần sử dụng các nền tảng như Kubernetes để điều phối các containers và đảm bảo ứng dụng ở trong trạng thái mong muốn nhằm phục vụ người dùng cuối.
Chúng ta sẽ tìm hiểu chi tiết về các chủ đề quan trọng này trong vài tuần tới để có kiến thức nền tảng tốt hơn về chúng và khi nào thì nên sử dụng.
Giám sát
Mọi thứ diễn ra rất nhanh chóng, chúng ta đã triển khai úng dụng mới và liên tục cập nhật những tính năng mới và luôn kiểm thử trước mỗi lần phát hành để đảm bảo không có bug nào trong ứng dụng. Ứng dụng cũng đang chạy trong môi trường mà cấu hình cũng như hiệu năng ổn định theo đúng yêu cầu.
Nhưng bây giờ chúng ta phải đảm bảo rằng người dùng cuối có được trải nghiệm theo đúng những gì họ mong đợi. Trong quá trình này, chúng ta cần phải đảm bảo rằng hiệu suất của ứng dụng được theo dõi liên tục. Việc này cũng giúp các kỹ sư phát triển có thể đưa ra quyết định tốt hơn để cải tiến ứng dụng trong các bản phát hành tiếp theo nhằm đem lại trải nghiệm tốt hơn cho người dùng cuối.
Giai đoạn này cũng là khi chúng ta nhận các phản hồi về các tính năng và nhu cầu của người dùng cuối với ứng dụng.
Độ tin cậy (reliability) cũng là một yếu tố quan trọng. Suy cho cùng thì chúng ta muốn ứng dụng của mình luôn sẵn sàng bất cứ khi nào người dùng cần. Chính vì vậy, các yếu tố khác như bảo mật, tính quan sát, quản lý dữ liệu cần được giám sát liên tục và kết quả được sử dụng để liên tục cải tiến, cập nhật ứng dụng bằng việc phát hành các phiên bản mới.
Một vài ý kiến đóng góp từ cộng đồng và cụ thể là @_ediri cũng đề cập rằng các FinOps cũng nên là một phần của quá trình liên tục này. Ứng dụng và Dữ liệu đang chạy và được lưu trữ cũng nên được theo dõi liên tục để đảm bảo mọi thay đổi của tài nguyên không gây ra thiệt hại đáng kể về mặt tài chính, đặc biệt với hoá đơn điện toán đám mây của bạn.
FinOps, viết tắt của Financial Operations, là một phương thức quản lý nhằm nâng cao trách nhiệm chung đối với cơ sở hạ tầng và chi phí điện toán đám mây của một tổ chức.
Đây cũng là thời điểm thích hợp để nói về “Kỹ sư DevOps” được nhắc tới ở trên. Mặc dù có rất nhiều người đang nắm giữ vị trí Kỹ sư DevOps nhưng đó không phải là vị trí duy nhất để áp dụng quy trình DevOps. Quan điểm của tôi khi nói với những người trong cộng đồng là, danh hiệu “kỹ sư DevOps” không nên là mục tiêu cho bất kỳ ai vì bất cứ vị trí nào cũng nên áp dụng các quy trình, văn hoá DevOps được nhắc tới ở đây. DevOps nên được sử dụng ở các vị trí khác ví dụ như kỹ sư/kiến trúc sư Cloud, kỹ sư quản lý ảo hoá, kỹ sư quản lý cơ sở hạ tầng,… Việc sử dụng vị trí “kỹ sư DevOps” ở trên chỉ để làm nổi bật phạm vi mà quy trình được sử dụng bởi bất kỳ vị trí nào ở trên và các vị trí khác.
DevOps & Agile
Bạn có biết sự khác biệt của DevOps và Agile? Chúng được hình thành như những khái niệm độc lập. Nhưng bây giờ hai thuật ngữ đang dần được hợp nhất.
Trong bài viết này, chúng ta sẽ xem xét sự khác biệt quan trọng giữa Agile và DevOps và tìm hiểu lý do tại sao hai thứ được kết nối chặt chẽ như vậy.
Tôi nghĩ bây giờ là thời điểm thích hợp để tìm hiểu về DevOps và Agile vì chúng có nhiều điểm tương đồng với nhau. Tuy chúng có mục tiêu và các quy trình giống nhau nhưng hi vọng bài viết này có thể tóm tắt được những ý chính để có thể hiểu sâu hơn về 2 khái niệm khác biệt này.
Hãy bắt đầu với các định nghĩa.
Agile Development
Agile là một cách tiếp cận tập trung vào việc cung cấp các kết quả nhỏ và nhanh hơn thay vì phát hành một thay đổi lớn của sản phẩm. Phần mềm được phát triển trong nhiều phân đoạn (iteration). Nhóm sản phẩm phát hành các phiên bản mới trong các bản cập nhật hàng tuần hoặc hàng tháng. Mục tiêu cuối cùng của Agile là tối ưu trải nghiệm của người dùng cuối.
DevOps
Chúng ta đã đề cập tới khái niệm này trong nhiều ngày qua theo một số cách khác nhau để mô tả mục tiêu cuối cùng của DevOps. DevOps thường được nhắc tới như các phương pháp phát triển và phân phối phần mềm dựa trên sự hợp tác giữa nhóm phát triển phần mềm và nhóm vận hành. Lợi ích chính của DevOps là đơn giản hoá quy trình phát triển và giảm thiểu thông tin sai lệch.
Sự khác biệt giữa Agile và DevOps
Sự khác biệt lớn nhất là mối bận tâm (preoccupations). Agile và DevOps có những mối bận tâm khác nhau nhưng chúng lại giúp đỡ lẫn nhau. Agile muốn có những phân đoạn ngắn, điều này gần như cần có các quy trình tự động hoá (automations) mà DevOps đem lại. Agile muốn khách hàng dùng thử các phiên bản và nhận được phản hồi một cách nhanh chóng, điều này gần như chỉ có thể thực hiện được nếu DevOps có thể tạo môi trường mới một cách dễ dàng.
Thành phần tham gia
Agile tập trung vào việc tối ưu hoá giao tiếp giữa người dùng cuối và nhóm phát triển, trong khi DevOps nhắm tới nhóm phát triển và nhóm vận hành. Chúng ta có thể nói Agile hướng tới khách hàng, trong khi DevOps là một tập hợp các phương pháp nội bộ.
Team
Agile thường được áp dụng cho nhóm phát triển và quản lý dự án. Còn vai trò của các kỹ sư DevOps được thể hiện ở phần giao giữa việc phát triển, quản lý chất lượng (QA) và vận hành bởi vì họ tham gia vào tất cả các giai đoạn của chu kỳ sản phẩm và là một phần của team Agile.
Các frameworks được áp dụng
Agile có rất nhiều framework quản lý để đạt được sự linh hoạt và minh bạch: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven. DevOps tập trung vào sự cộng tác trong việc phát triển nhưng không có các framework cụ thể. DevOps thúc đẩy các phương pháp như cơ sở hạ tầng dưới dạng mã (IaC), kiến trúc dưới dạng mã, giám sát, tự khắc phục lỗi (Self-Healing), tự động hóa kiểm thử (end to end test automation) … Tuy nhiên, đây không được coi là các framework, mà chỉ là các phương pháp.
Nhận xét/Phản hồi
Trong Agile, nguồn phản hồi chính là người dùng cuối còn với DevOps những phản hồi từ các bên liên quan(stakeholders) và bản thân nhóm có mức độ ưu tiên cao hơn.
Phạm vi tập trung
Agile tập trung nhiều hơn vào phát triển phần mềm hơn là triển khai và bảo trì. DevOps cũng tập trung vào phát triển phần mềm, nhưng giá trị và công cụ của nó cũng bao gồm các giai đoạn sau phát hành như triển khai, giám sát, tính sẵn sàng cao, bảo mật và bảo vệ dữ liệu.
Tài liệu
Agile ưu tiên tính linh hoạt và các nhiệm vụ hơn việc bàn giao tài liệu và giám sát. Trái lại, DevOps coi tài liệu dự án là một trong những thành phần thiết yếu của dự án.
Rủi ro
Rủi ro của Agile đến từ tính linh hoạt của các phương pháp của nó. Các dự án Agile rất khó dự đoán và đánh giá rủi ro do thứ tự ưu tiên và yêu cầu thay đổi liên tục.
Rủi ro của DevOps đến từ việc hiểu sai thuật ngữ và thiếu các công cụ thích hợp. Một số người hiểu nhầm rằng DevOps chỉ là một tập hợp các phần mềm để triển khai phần mềm và tích hợp liên tục. Chính vì suy nghĩ đó mà không có sự đóng góp, thay đổi cấu trúc cơ bản của quá trình phát triển.
Công cụ
Các công cụ Agile tập trung vào việc cộng tác giao tiếp quản lý, đo lường và xử lý phản hồi. Các công cụ phổ biến nhất bao gồm JIRA, Trello, Slack, Zoom, SurveyMonkey, v.v.
DevOps sử dụng các công cụ để giao tiếp nhóm, phát triển phần mềm, triển khai và tích hợp như Jenkins, GitHub Actions, BitBucket, v.v. Mặc dù Agile và DevOps có trọng tâm và phạm vi hơi khác nhau nhưng chúng có các giá trị chính gần như giống nhau, chính vì vậy có thể kết hợp và hỗ trợ lẫn nhau rất tốt.
Kết hợp với nhau… có phải là một ý tưởng tốt? cần thảo luận?
Kết hợp Agile và DevOps sẽ mang lại những lợi ích sau:
- Quản lý linh hoạt và công nghệ mạnh mẽ.
- Phương pháp Agile giúp các nhóm DevOps giao tiếp, trao đổi về các ưu tiên một các hiệu quả hơn.
- Yêu cầu triển khai nhanh chóng và thường xuyên của bạn hợp lý hoá cho các chi phí phát sinh từ quá trình tự động hóa.
- Nó giúp làm tốt hơn: quá trình giao tiếp, hợp tác của các nhóm sử dụng Agile, tăng động lực cho nhóm và giúp giảm tỷ lệ nghỉ việc.
- Kết quả là bạn có một sản phẩm với chất lượng tốt hơn.
Agile cho bạn quay lại các quá trình phát triển sản phẩm trước đó để sửa lỗi và tránh khỏi việc mắc quá nhiều nợ kỹ thuật (technical debt). Để áp dụng đồng thời Agile và DevOps, chúng ta cần thực hiện 7 bước sau:
- Tích hợp các nhóm phát triển và vận hành.
- Tạo các nhóm xây dựng và điều hành và thảo luận tất cả các vấn đề liên quan tới phát triển, vận hành cần được thảo luận bởi toàn bộ nhóm DevOps.
- Thay đổi cách tiếp cận với các sprints, đánh giá các nhiệm vụ DevOps có cùng mức độ ưu tiên với các nhiệm vụ phát triển. Khuyến khích các nhóm phát triển và vận hành trao đổi ý kiến về quy trình làm việc của nhóm còn lại và thảo luận các vấn đề có thể xảy ra.
- QA có mặt trong tất cả các quy trình phát triển.
- Chọn các công cụ phù hợp.
- Tự động hoá mọi thứ mà bạn có thể.
- Do lường và kiểm soát các bản phân phối bằng cách đánh số dễ hiểu.
Kế hoạch > Viết mã > Xây dựng > Kiểm thử > Phát hành > Triển khai > Vận hành > Giám sát >
Và bây giờ chúng ta sẽ tập trung vào các bước riêng lẻ và chu trình liên tục của một ứng dụng từ đầu đến cuối trong thế giới DevOps.
Kế hoạch
Tất cả bắt đầu với việc lên kế hoạch, đây là lúc nhóm phát triển họp lại với nhau để thảo luận và tìm ra các tính năng và bản sửa lỗi mà họ muốn có trong sprint tiếp theo. Đây cũng là lúc mà kỹ sư DevOps tham gia và tìm hiểu những phần liên quan tới công việc của mình. Bạn cũng có thể đóng góp ý kiến vào các quyết định của nhóm phát triển, giúp họ có thể làm việc với cơ sở hạ tầng mà bạn đã xây dựng hoặc hướng họ đến lựa chọn tốt hơn nếu họ đang không lựa chọn phương án tốt nhất. Một điều quan trọng nên nhớ là nhóm phát triển đang là khách hàng của bạn, đây là cơ hội tốt để làm việc với họ trước khi mọi thứ không đi trên con đường tốt nhất.
Viết mã
Sau khi việc lên kế hoạch kết thúc, họ sẽ bắt đầu viết mã, bạn có thể hoặc có thể không liên quan nhiều đến giai đoạn này. Tuy nhiên, bạn có thể tham gia, hướng dẫn nhóm phát triển để họ hiểu rõ hơn về cơ sở hạ tầng, những dịch vụ nào có sẵn và cách tốt nhất để sử dụng những dịch vụ đó.
Xây dựng
Đây là điểm bắt đầu của quy trình tự động hoá. Chúng ta sẽ lấy mã nguồn từ nhóm phát triển, và xây dựng ứng dụng từ đó. Tuỳ thuộc vào ngôn ngữ họ sử dụng mà chúng ta có thể sẽ chuyển mã, biên dịch hoặc tậm chí là xây dựng một Docker image từ mã nguồn. Dù như thế nào, chúng ta vẫn sẽ sử dụng các CI/CD pipeline cho quá trình này.
Kiểm thử
Sau khi chúng ta xây dựng xong mã nguồn, chúng ta cần kiểm thử bằng các bài kiểm tra trên bản build mới. Các bài kiểm tra này thường sẽ được nhóm phát triển hoặc QA chuẩn bị trước, chúng ta cũng có thể đóng góp ý kiến vào việc cách mà các bài kiểm tra nên được viết. Quá trình kiểm thử nhằm giảm thiểu việc phát sinh các vấn đề trên môi trường sản xuất (production). Nó có thể không đảm bào hoàn toàn nhưng chúng ta muốn càng gần với một sự đảm bảo càng tốt, một là không đưa thêm lỗi mới, hai là không phá vỡ những thứ đang hoạt động.
Phát hành
Sau khi vượt qua các bài kiểm tra, chúng ta sẽ thực hiện quá trình phát hành. Quá trình này có thể không tồn tại phụ thuộc vào loại ứng dụng bạn đang làm việc cùng. Mã nguồn có thể được lưu trữ ở bất kỳ đâu, chẳng hạn như GitHub hoặc kho lưu trữ git, hoặc mã đã được biên dịch hay Docker image đã được lưu giữ trong sổ đăng ký (registry) hoặc kho lưu trữ (repository) và có thể truy cập được từ máy chủ sản xuất trong quá trình triển khai.
Triển khai
Cuối cùng, chúng ta triển khai mã lên môi trường sản xuất (production). Chỉ đến lúc này, doanh nghiệp mới có thể nhận ra giá trị từ thời gian, nỗ lực và sự tận tuỵ mà chúng ta và nhóm phát triển đã đưa vào sản phẩm.
Vận hành
Sau khi triển khai ứng dụng, chúng ta sẽ chuyển qua giai đoạn vận hành, đây là lúc mà bạn có thể nhận các cuộc gọi từ khách hàng về việc website hoặc ứng dụng của họ rất chậm. Sau đó bạn cần tìm hiểu lý do và sau đó có thể xây dựng một hệ thống mở rộng quy mô tự động (auto-scaling) để tăng số lượng máy chủ trong giờ cao điểm và giảm số lượng máy chủ trong giờ thấp điểm. Một hoạt động khác là vòng lặp phản hồi từ môi trường sản xuất tới nhóm vận hành để cho biết về các sự kiện chính đã xảy ra trên môi trường sản xuất. Điều này có thể được tự động hoá hoặc không tuỳ thuộc và môi trường của bạn nhưng mục tiêu là luôn luôn tự động hoá khi có thể. Tuỳ thuộc vào môi trường, có thể một số bước cần được thực hiện trước khi sẵn sàng cho việc đó, nhưng lý tưởng nhất là bạn sẽ triển khai tự động như một phần của quy trình tự động hoá. Nếu bạn có thể, sẽ rất tốt nếu có thêm một số thông báo ở các bước để cho nhóm vận hành biết rằng việc triển khai đã xảy ra.
Giám sát
Tất cả đều dẫn đến bước cuối cùng, giám sát. Điều này quan trọng với các các vấn đề vận hành như khắc phục sự cố, tự động mở rộng quy mô. Bạn có thể sẽ không biết có vấn đề xảy ra nếu bạn không giám sát hệ thống. Một số ví dụ cho các số liệu mà bạn có thể giám sát là: % sử dụng bộ nhớ, % sử dụng CPU, dung lượng ổ đĩa, thời gian phản hồi của API, và một phần rất quan trọng, logs. Nhờ logs, nhóm phát triển có thể xem những gì đã và đang diễn ra mà không cần truy cập vào hệ thống của môi trường sản xuất.
Lặp lại
Sau khi hoàn thành, chúng ta quay lại từ đầu bắt đầu bằng việc lên kế hoạch và lặp lại toàn bộ chu trình.
Liên tục
Nhiều công cụ giúp chúng ta thực hiện quy trình liên tục ở trên với mục tiêu cuối cùng là tự động toàn bộ quy trình. Việc này thường được gọi là Tích hợp liên tục / Phân phối liên tục / Triển khai liên tục hoặc viết tắt là “CI/CD”. Chúng ta sẽ có nguyên một tuần trong 90 ngày để tìm hiểu kiến thức cơ bản với một số ví dụ và hướng dẫn.
Phân phối liên tục
Phân phối liên tục = Kế hoạch > Viết mã > Xây dựng > Kiểm thử
Tích hợp liên tục
Đây là kết quả của Phân phối liên tục cộng với kết quả của giai đoạn Phát hành. Nếu thất bại thì sẽ quay trở lại Phân phối liên tục, nếu thành công thì chuyển sang giai đoạn Triển khai liên tục.
Tích hợp liên tục = Kế hoạch > Viết mã > Xây dựng > Kiểm thử > Phát hành
Triển khai liên tục
Sau khi có bản phát hành thành công từ Tích hợp liên tục, chúng ta sẽ chuyển sang Triển khai liên tục gồm các giai đoạn sau.
Tích hợp liên tục phát hành thành công = Triển khai liên tục = Triển khai > Vận hành > Giám sát
Bạn có thể xem ba khái niệm liên tục ở trên là tập hợp đơn giản của các giai đoạn của Vòng đời DevOps.
DevOps – Những câu chuyện thực tế
Lúc đầu, DevOps được cho là không thực tế với nhiều người do thiếu môi trường và các điều kiện như Netflix hay các công ty trong Fortune 500 đang có. Nhưng giờ đây, tất cả các các doanh nghiệp đang tìm cách áp dụng các phương pháp DevOps, nó đang trở thành chuẩn mực.
Bạn sẽ thấy từ các tài liệu tham khảo bên dưới rằng có rất nhiều ngành và ngành dọc khác nhau đang sử dụng DevOps và nó có tác động tích cực đến các mục tiêu kinh doanh của họ.
Lợi ích bao trùm ở đây là nếu DevOps được thực hiện đúng cách, tốc độ và chất lượng phát triển phần mềm của doanh nghiệp sẽ được cải thiện.
Hôm nay, chúng ta sẽ xem xét các công ty thành công đã áp dụng phương pháp DevOps và chia sẻ câu chuyện thực tế của họ. Đây cũng là cơ hội tuyệt vời để cộng đồng tham gia. Bạn đã áp dụng văn hóa DevOps trong doanh nghiệp của mình chưa? Nó có thành công không?
Chúng ta đã đề cập đến Netflix và sẽ đề cập đến nó một lần nữa vì đây là một mô hình rất tốt và khá tiên tiến so với những gì chúng ta thường thấy ngày nay và cũng sẽ đề cập đến một số doanh nghiệp lớn khác đã và đang thành công khi áp dụng các phương pháp, văn hoá DevOps.
Amazon
Năm 2010, Amazon đã chuyển từ các máy chủ vật lý sang sử dụng điện toán đám mây AWS (Amazon Web Services). Điều này cho phép họ tiết kiệm tài nguyên bằng cách tăng/giảm dung lượng theo từng bước rất nhỏ. Chúng ta cũng biết rằng trong nhiều năm trở lại đây, AWS đã phát triển và tạo ra doanh thu khổng lồ cho Amazon.
Vào năm 2011 (theo video ở phía dưới), Amazon đã áp dụng một quy trình triển khai liên tục cho phép nhóm phát triển có thể triển khai mã bất cứ khi nào họ muốn tới bất cứ máy chủ nào họ cần. Điều này cho phép Amazon triển khai phần mềm mới cho các máy chủ sản xuất với thời gian trung bình là 11.6 giây!
Netflix
Ai sẽ không sử dụng Netflix? Đây rõ ràng là một dịch vụ phát trực tuyến khổng lồ với chất lượng cao, mang lại trải nghiệm người dùng tuyệt vời, ít nhất là đối với cá nhân tôi.
Tại sao trải nghiệm người dùng Netflix lại tuyệt vời như vậy? Khả năng cung cấp dịch vụ mà không gặp một lỗi nào đáng kể đòi hỏi tốc độ, sự linh hoạt và chú ý đến chất lượng.
Nhóm phát triển tại Netflix có thể tự động xây dựng các đoạn mã thành các web images có thể được triển khai mà không cần phụ thuộc vào đội vận hành. Khi các images được cập nhật, chúng được tích hợp vào cơ sở hạ tầng của Netflix bằng cách sử dụng nền tảng web được tùy biến.
Giám sát liên tục đảm bảo rằng nếu việc triển khai images không thành công, phiên bản trước đó sẽ được sử dụng và các truy cập sẽ được định tuyến lại đến phiên bản cũ đó.
Dưới đây là một cuộc nói chuyện tuyệt vời về những điều “nên làm” và “không nên làm” mà Netflix thực hành trong nhóm.
Etsy
Nhiều người trong chúng ta và nhiều doanh nghiệp đã thực sự phải vật lộn với việc triển khai chậm chạp và khó khăn. Tương tự với điều đó, chúng ta có thể đã có kinh nghiệm làm việc trong các nhóm phối hợp kém với nhau.
Với những gì đã đọc từ Amazon và Netflix, Etsy có thể đã cho phép nhóm phát triển tự triển khai mã nguồn của họ vào khoảng cuối năm 2009, thậm chí còn có thể trước hai doanh nghiệp lớn trên. (Thật không thể tin được!)
Một điều thú vị khác mà tôi rút ra được ở đây là khi các nhà phát triển cảm thấy có trách nhiệm với việc triển khai, họ cũng sẽ chịu trách nhiệm với hiệu suất ứng dụng, uptime và các mục tiêu, chỉ số khác.
Văn hóa học hỏi là một phần quan trọng của DevOps, và ngay cả thất bại cũng có thể trở thành thành công nếu chúng ta rút ra được các bài học từ đó. (Tôi không biết câu trích dẫn này thực sự đến từ đâu, nhưng nó có vẻ rất đúng!).
Chúng ta cũng sẽ có thêm một số câu chuyện khác về cách DevOps giúp thay đổi các doanh nghiệp rất thành công.
Tóm tắt những ngày đầu tiên của chúng ta khi tìm hiểu về DevOps
- DevOps là sự kết hợp giữa Phát triển (Dev) và Vận hành (Ops) cho phép một nhóm duy nhất quản lý toàn bộ vòng đời phát triển ứng dụng bao gồm Phát triển, Kiểm thử, Triển khai, Vận hành.
- Trọng tâm và mục đích chính của DevOps là rút ngắn vòng đời phát triển trong khi thường xuyên cung cấp các tính năng, bản sửa lỗi, chức năng phù hợp và liên quan chặt chẽ tới mục tiêu kinh doanh.
- DevOps là một cách tiếp cận cho quá trình phát triển phần mềm, qua đó phần mềm có thể được phân phối và phát triển một cách đáng tin cậy và nhanh chóng. Đôi khi còn được nhắc tới với các khái niệm như Phát triển, Kiểm thử, Triển khai, Giám sát (liên tục).
Tài liệu tham khảo
- DevOps for Developers – Day in the Life: DevOps Engineer in 2021
- 3 Things I wish I knew as a DevOps Engineer
- How to become a DevOps Engineer feat. Shawn Powers
- DevOps for Developers – Software or DevOps Engineer?
- Techworld with Nana -DevOps Roadmap 2022 – How to become a DevOps Engineer? What is DevOps?
- How to become a DevOps Engineer in 2021 – DevOps Roadmap
- How Netflix Thinks of DevOps
- 16 Popular DevOps Use Cases & Real Life Applications [2021]
- DevOps: The Amazon Story
- How Etsy makes DevOps work
- Adopting DevOps @ Scale Lessons learned at Hertz, Kaiser Permanente and lBM
- Interplanetary DevOps at NASA JPL
- Target CIO explains how DevOps took root inside the retail giant
Nếu bạn đã đọc hết bài viết này, chắc hẳn bạn đã biết rõ liệu đây có phải hành trình mà bạn muốn theo đuổi hay không. Hẹn gặp lại vào Ngày 1: Học một ngôn ngữ lập trình (Go)
Ngày thứ 1 chúng ta sẽ đi sâu vào một ngôn ngữ lập trình. Tôi sẽ không cố gắng để trở thành một kỹ sư phát triển phần mềm nhưng tôi muốn có thể hiểu những gì mà họ đang làm.
Các bài viết là bản tiếng Việt của tài liệu 90DaysOfDevOps của Micheal Cade và có qua sửa đổi, bổ sung. Tất cả đều có license [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa].
Mọi thắc mắc xin hãy liên hệ
Email: [email protected]
(Nguồn: vntechies.dev)
