DevOps là gì?

Định nghĩa mô hình DevOps

Ngày xửa ngày xưa, cách đây khoảng chục năm, lúc ấy loài phát triển phần mềm vẫn đang sử dụng một chu trình phát triển phần mềm (Software Development Life Cycle) bao gồm hai giai đoạn: phát triển (Dev) và vận hành(Operations-Ops).

Giai đoạn phát triển (development) bao gồm phần việc của designer, developer, QA QC…
Giai đoạn vận hành (operations) có sự tham gia của system engineer, system administrator, operation executive, release engineer, DBA, network engineer, security engineer…

Tuy nhiên, anh phát triển thì cứ phát triển, không cần biết cô vận hành có sung sướng được hay không. Cô vận hành thì cứ mỗi lần không sung sướng (gặp bug hay lỗi cấu hình) thì lại gọi hồn ông dev lên mà tế. Nói chung, 2 cơ thể cùng sống cạnh nhau trong một khu tập thể, nhưng gần như không bao giờ hòa hợp, chưa bao giờ họ nhìn vào một hướng.

Rồi một ngày, định mệnh run rủi thế nào khiến hai đứa ấy cưới nhau, và về chung một nhà, lúc ấy người ta gọi nó là DevOps. Vậy, DevOps tất nhiên là viết tắt của Development (Dev) và Operations (Ops) rồi, nhưng nó là cái gì mà khiên ông dev với bà vận hành đang như nước với lửa lại tự nhiên quấn lấy nhau không rời như vậy?

DevOps là tổng hòa của 3 yếu tố

Culture : văn hóa làm việc kết hợp giữa Dev và Ops
Practices : cách để thực hiện DevOps
Tools : những Tools cần để thực hiện DevOps

Như vậy, DevOps là một văn hóa làm việc kết hợp giữa dev với bộ phận operator (kỹ sư hệ thống, nhân viên bảo mật, kỹ sư mạng, kỹ sư hạ tầng,…) nhằm mục đích rút ngắn vòng đời phát triển sản phẩm, TĂNG KHẢ NĂNG của doanh nghiệp để phân phối sản phẩm và dịch vụ đến khách hàng MỘT CÁCH NHANH NHẤT. DevOps cũng không phải là một Tools hỗ trợ làm việc, mà là một phương pháp làm việc cần đến sự hỗ trợ của các Tools.

Ngoài ra, không có bất cứ một tiêu chuẩn nào để những những người sử dụng phương pháp DevOps để tuân theo. Nó chỉ đơn giản là một văn hóa, một cách làm việc kết hợp giữa dev và đội vận hành thay vì làm việc một mình hay chỉ một team độc lập nào đó.

DevOps làm việc thế nào

Trong mô hình DevOps (Develop + Operations), thì các team phát triển và vận hành không còn độc lập riêng lẻ nữa. Đôi khí, hai team này được gộp vào thành một team mà ở đó, các kỹ sư của cả 2 team sẽ trải qua tất cả các khâu trong vòng đời của sản phẩm từ phát triển, tới deploy và vận hành sản phầm. Mọi member trong team cũng có thể sẽ phải làm rất nhiều nhiệm vụ chứ không chỉ bị hạn chế trong một chức năng riêng lẻ như trong mô hình phát triển truyền thống.

Trong một số mô hình DevOps, team bảo đảm chất lượng(QA) và team bảo mật có thể cũng sẽ tham gia sâu vào quá trình phát triển và vận hành, cũng như xuyên suốt vòng đời của sản phẩm.

Nếu như bảo mật là vấn đề mà team DevOps focus vào, thì lúc đó, chúng ta có thể gọi đó là mô hình DevSecOps (Development + Security + Operations).

Các team trong mô hình DevOps sẽ cố gắng để TỰ ĐỘNG HÓA QUY TRÌNH vốn dĩ được làm một cách thủ công và chậm chạp trong mô hình truyền thống. Họ sẽ dùng các kĩ thuật và công cụ để vận hành và cải tiến sản phẩm một cách nhanh chóng và tin cậy cao hơn. Những công cụ này cũng giúp các kĩ sư hoàn thành các task một cách độc lập, thay vì phải yêu cầu sự trợ giúp từ các team khác. Ví dụ như team phát triển giờ có thể chạy lệnh để deploy source code mà không cần nhờ đến team vận hành hay IT nữa. Điều đó giúp tăng tốc độ của team lên rất nhanh.

I. DevOps Culture:

Với cách làm việc truyền thống trước đây - dev làm việc riêng và operations làm việc riêng, họ sẽ có mục tiêu công việc khác nhau. Nếu như mục tiêu của dev là xây dựng function đúng với requirement và release cho khách hàng càng nhanh càng tốt thì mục tiêu của operations là tạo ra một hệ thống ổn định. Trong một hoàn cảnh nào đó, hai mục tiêu này sẽ đối lập nhau, function có thể chạy tốt lúc release nhưng sau một thời gian có thể xuất hiện nhiều lỗi hoặc chạy chậm. Hoặc một sản phẩm suy nghĩ nhiều về maintaince system sẽ làm chậm thời gian release. Vì thế, DevOps được sinh ra với ý tưởng là kết hợp Dev và Ops mới một mục tiêu chung là “Speed and Stability” - Tốc độ và ổn định.

Vậy khi có 1 team DevOps, những mục tiêu đạt đến cụ thể như sau:

Fast time - to market (TTM) : code nhanh, deploy nhanh
Few production failures : khi sản phẩm được đảm bảo về tính ổn định ngay từ đầu thì lỗi sẽ ít xảy ra hơn
Immediate recovery from failures: không may nếu xảy ra lỗi, vì chúng ta có 1 team đầy đủ dev và ops nên có thể nhanh chóng nhận định nguyên nhân lỗi là do program hay do cấu trúc hệ thống,… và có thể nhanh chóng giải quyết vấn đề ngay lập tức.

Trong DevOps culture, cả dev và operations đều phải quan tâm đến tính ổn định và tốc độ của sản phẩm.Vì thế, dev và operations sẽ phải làm việc cùng nhau, sử dụng những tools kiểm tra tốc độ và tính ổn định của sản phẩm, nhờ vậy mà có thể tạo ra những sản phẩm tốt hơn.

Thử so sánh DevOps với mô hình làm việc truyền thống Traditional Silos, ta thấy như sau:

Ở mô hình Traditional Silos, dev viết code đưa sang QA test. QA phát hiện ra bug sẽ đưa cho dev fix, rồi chuyển lại cho QA để test. Quá trình này lặp đi lặp lại cho đến khi sản phẩm không còn bug, thì sẽ chuyển giao cho operation để deploy code lên môi trường. Lúc này, QA sẽ test lại lần nữa. Lúc này, nếu phát sinh ra bug thì nguyên nhân có thể là do code của dev viết sai hoặc do operation deploy sai. Với mô hình làm việc truyền thống, cách làm việc của mỗi team dev và operations như một “black-box”, không tin tưởng lẫn nhau, vì vậy việc tìm kiếm nguyên nhân lỗi sẽ mất thời gian hơn.

Tuy nhiên, với DevOps, dev QA và operations là 1 team thống nhất cùng làm 1 sản phẩm, họ sẽ sử dụng các tools như Jenkins, docker,… để tạo ra một hệ thống automation từ khi build code, test đến khi deploy. Nếu xảy ra bug họ có thể nhanh chóng revert lại version cũ, cùng nhau tìm hiểu nguyên nhân, fix bug rồi deploy code mới lên lại.

Tôi đã từng làm rất nhiều mobile game, nhưng rất tiếc phần lớn trong đó là thất bại. Một người bạn của tôi, anh ta cũng làm như tôi, số lượng game của anh ta chỉ đếm trên đầu ngón tay. Nhưng anh ta gặt hái được một số thành công nhất định vì lượng người chơi khá là nhiều. Anh ta chia sẻ cho tôi kinh nghiệm, việc game hay hay không không quan trọng, vấn đề là anh có đủ sức để liên tục release những bản vá lỗi của sản phẩm hàng tuần hay không. Bạn càng release các tính năng mới và fix các bugs nhanh, thì bạn càng đáp ứng được nhu cầu của khách hàng và tạo ra lợi thế cạnh tranh cho sản phẩm. Trong mô hình DevOps, chúng ta sẽ dùng các công cục CI và CD để tự động hóa từ build cho tới deploy để release sản phẩm.

II. DevOp Practices:

1.Build Automation

Build Automation là một quy trình tự động để chuẩn bị source code deploy lên môi trường bằng cách sử dụng script hoặc tool. Build automation sẽ giúp tiết kiệm thời gian, giúp bạn khỏi phải làm những công việc lặp đi lặp lại một cách nhàm chán theo đúng quy trình định sẵn. Điều này vô hình chung cũng sẽ đảm bảo code sẽ luôn được build theo một quy trình nghiêm ngặt, giống nhau mà không bị tác động bởi những yếu tố như sai sót của con người. Và cũng vì tránh các sai sót lúc build, các config cho môi trường build nên tách biệt hoàn toàn khỏi IDE cũng như system. Hãy cố gắng để cho code của bạn có thể được build trên bất cứ máy tính nào(dù là Windows, Linux hay MacOS), hay là có thể build bởi bất kì ai trong team.

2.Continuous Intergration ( CI - Tích hợp liên tục)

Với cách làm việc truyền thống, các developer sẽ làm việc riêng biệt với nhau và sau một khoảng thời gian nhất định, họ mới tiến hành merge code một lần. Tuy nhiên, với CI thì developer có thể merge code của họ liên tục và hệ thống CI sẽ chạy auto test để detect những vấn đề khi merge code. CI phải được tự động hóa, và thông thường được hỗ trợ bở một CI Server. Khi developer commit source code thay đổi của họ lên, CI Server sẽ thấy sự thay đổi này và bắt đầu thực hiện build, test source code thay đổi một cách tự động. Quá trình này sẽ được thực hiện nhiều lần trong 1 ngày, và nếu CI server phát hiện có vấn đề xảy ra nó sẽ ngay lập tức hiển thị thông báo cho developer. Trường hợp có một người khác đưa code của họ lên và xảy ra lỗi trong quá trình build hệ thống sẽ thông báo lỗi cho người đó tiến hành fix, đồng thời sẽ rollback lại để không làm ảnh hưởng đến những người khác.

Vậy lợi ích của CI là gì? Đầu tiên, CI sẽ giúp phát hiện ra bug sớm, thông báo cho developer. Developer có thể fix ngay lập tức hoặc rollback để không làm ảnh hưởng đến người khác. Tiếp theo, áp dụng CI sẽ giúp tránh việc phải merge một lượng code lớn khi release. Thay vào đó code sẽ được merge tự động liên tục. Đồng thời, nhờ vào việc code được merge liên tục nên chúng ta có thể release thường xuyên chứ không cần chờ đến cuối giai đoạn khi tất cả mọi thứ đã xong xuôi mới có thể release được. Khi code được build liên tục nó cũng tạo ra Continuos Testing (Test liên tục), QA có thể test ngay lập tức những chỉnh sửa đã được đưa lên mà không cần chờ đến khi mọi thứ hoàn thành. CI tạo ra một thói quen tốt cho develop, việc thường xuyên commit sẽ làm developer viết ra những đoạn code đơn giản, đúng chuẩn ko rườm ra.

3.Continuous Delivery và Continuous Deployment

Continuous Delivery (CD) là method đảm bảo code có thể được deploy bất cứ lúc nào. Thay vì phải quyết định có nên deploy code hay không thì team phải build, merge, test,… để đảm bảo code luôn ở trạng thái có thể deploy.

Một số người khi nhắc đến Continuous Delivery thường viết tắt là CD, tuy nhiên cách gọi tắt này sẽ khiến nhầm lẫn giữa Continuous Delivery và Continuous Deployment.

Continuous Deployment là một practice đảm bảo code thay đổi (có size nhỏ) được deploy liên tục lên product.

Vậy Continuous Delivery và Continuous Deployment khác nhau như thế nào ? Continous Delivery đảm bảo cho code có thể deploy bất cứ lúc nào. Trong khi Continuous Deployment là deploy thực tế lên product nhiều lần trong ngày.

Trên thực tế Continuous Delivery và Continuous Deployment được thực hiện theo flow sau:

Mỗi version code đưa lên đều trải qua một quy trình giống nhau, bao gồm: build automation, test automation,… Và nếu không có vấn đề gì xảy ra nghĩa là code đó có thể deploy.
Sau khi quyết định deploy thì sẽ thực hiện deploy tự động (deploy automation).
Nếu việc deploy gặp lỗi, hệ thống sẽ tự động rollback.
Developer sẽ nhanh chóng fix lỗi và redeploy version fix lỗi.

Với cách làm như vậy Continuous Delivery và Continuous Deployment sẽ đem lại những lợi ích như dưới đây:

Nhanh chóng đưa sản phẩm đến tay khách hàng
Giảm thiếu các vấn đề xảy ra khi deploy
Giảm thiếu risk: lượng deploy trong 1 lần càng nhiều, risk càng cao. Việc chia nhỏ lượng deploy sẽ giảm thiểu risk.
Rollback lập tức khi xảy ra lỗi
Giúp developer không còn lo lắng khi deploy khi đã có chức năng roll back automation.

4.Infrastructure as Code (IaC)

Infrastructure as Code là method giúp quản lý, xây dựng cơ sở hạ tầng (Infra) cho sản phẩm của bạn. Với Infrastructure as Code, thay vì thực hiện thủ công theo manual. Bạn có thể viết code và cho chạy tự động. Các đối tượng xây dựng trong Infra bao gồm: Server, Instance, môi trường, Container,…

Vì sao nên sử dụng IaC?

Đầu tiên, IaC đảm bảo việc tạo và quản lý resource đúng tiêu chuẩn. Tất cả mọi việc được thực hiện automation, ko có những sai sót nếu thực hiện bằng tay.
Tính linh hoạt: IaC cho phép thực hiện cùng một thay đổi giống nhau trên nhiều host, và có thể sử dụng lại trong tương lai.
Tính co dãn (Scalability) : khi cần thêm instance bạn chỉ cần cho chạy lại config giống với instance có sẵn và một instance mới được tạo ra chỉ trong vài phút hoặc vài giây.
Self-documenting: với IaC để xem những config của hệ thống chỉ cần xem trong source control, bạn không cần phải log lại hoặc tạo 1 tài liệu bất kỳ nào để lưu giữ thông tin config. Chính bản thân code được dùng để build infra chính là document.

(Tổng hợp)