Chào các bạn, trong bài viết này tôi xin phép được chia sẻ với các bạn những trải nghiệm của tôi với khái niệm DevOps. Trong quãng thời gian làm việc tại BizflyCloud, tôi ngoài công việc của một engineering, tôi cũng có giai đoạn làm scrummaster, product owner, architect nên tôi nghĩ tôi may mắn khi có cái nhìn đa chiều về việc này. Tôi sẽ kể cho các bạn nghe vài câu chuyện về cái gọi là DevOps này.
Mở đầu
Hãy tưởng tượng chúng ta đang điều hành một quầy nước chanh siêu bận rộn với bạn bè của mình. Khách hàng cứ đến liên tục, và công việc trở nên cực kỳ căng thẳng. Mọi thứ bắt đầu hỗn loạn, nước chanh bị đổ, cốc bị mất, và khách hàng xếp hàng dài, chờ đợi mà không thể phục vụ nhanh chóng. Bạn nhận ra rằng nếu không tổ chức lại quy trình, bạn sẽ không thể tiếp tục kinh doanh hiệu quả. Bạn muốn tất cả mọi thứ diễn ra suôn sẻ, nhanh chóng, không gặp sự cố.
Để làm được điều đó, bạn quyết định thay đổi cách thức làm việc tự động hóa, tối ưu quy trình, và cải thiện sự phối hợp giữa tất cả các bạn làm việc ở các công đoạn khác nhau. Bạn nhận ra rằng nếu mỗi người làm việc độc lập và không trao đổi với nhau, mọi thứ sẽ luôn rối tung lên. Chính lúc này, bạn cần phải áp dụng một cách làm việc mới
Trong quá khứ
Tôi lấy ví dụ. Lúc tôi còn ở TechSolutions để phát triển một hệ thống Cloud Environment, có rất nhiều chuyện diễn ra làm cho nhóm kỹ sư vô cùng thất vọng. Từ những việc như chạy hệ thống CI, chia các branch cho dự án (master, develop branch, etc.) cho đến chuyện sự phối hợp giữa các team về dev và ops, nó thực sự đau đầu. Tôi đơn cử thế này, vì một lý do nào đó mà hardening security (e.g. ssh, authentication, etc.) trong môi trường cloud phải thay đổi, nhóm ops phải viết lại Ansible, tuy nhiên các dev ko biết, đâm ra vẫn sử dụng các parameter cũ. Do đó khi một loạt commit sử dụng các parameter cũ của các dev được đưa lên CI sẽ break luôn cả CI, gây ra một loạt bug. Mà CI break nghĩa là sản phẩm không chạy được, không giao cho khách hàng được. Do đó chúng tôi lại phải ngồi lại với nhau, xem log là lỗi ở đâu, trong khi đó một nhóm khác vẫn tiếp tục công việc để hoàn thành sprint.
Nhưng tưởng thế là xong, ví dụ cái lỗi này nó xuất hiện gần lúc deadline phải gửi release mới cho khách hàng thì các bạn tính sao. Trong khi đó, khi theo lý thuyết Agile thì các bạn phải cố gắng hết sức để hoàn thành sprint, nhưng nếu chia team ra để tìm lỗi thì lấy đâu người để hoàn thành sprint. Do đó, nó sẽ đẻ ra cái gọi là: Stop the line. Tức là thế này, dừng toàn bộ việc dev cho sprint lại, tập trung nguồn lực fix bug, trouble shooting để đảm bảo CI phải chạy, kịp deadline cho release, còn lại sprint goal thì ta sẽ tính toán lại và tất nhiên việc tính toán lại này sẽ làm chậm việc hoàn thành các feature tiếp theo mà khách hàng mong muốn. Lúc này thì product owner, project manager phải làm cách nào đó để thuyết phục khách hàng cho mình giao sản phẩm chậm lại. Thật là mệt mỏi vì sau đó nhóm kỹ sư lại phải họp với nhau, thiết kế lại sprint goal, chính lại các task, một loạt meeting cho việc này. Quả thực là lằng nhằng và mệt mỏi. Chưa kể nhiều lúc vì lí do bắt buộc mà vừa phải fix bug, vừa phải hoàn thành features, quả thực mệt mỏi.
Sự cẩu thả
Mà hài hước hơn là thế này nữa. Có những lúc vì lý do nào đó mà một commit lỗi lại được nhóm manager merge chỉ vì kịp cho release, đảm bảo giao feature cho khách hàng cho dù nó lỗi. Xong cái một loạt bug gửi về vì cái commit này mà rõ ràng nhóm kỹ sư ko merge nó. Xong rồi cái quy trình phía trên được lặp lại, nào là “Stop the line”, trouble shooting, v.v…
Những lý do kiểu này nếu tích tụ dần sẽ đem lại vô cùng nhiều ức chế cho các kỹ sư. Đến với Nokia, tôi lại gặp một tình trạng thế này: Sprint quá ngắn, quá ít product owner (PO). Các bạn đã biết là, với Agile thì sprint goal cực kỳ quan trọng. Trong mỗi một sprint, các kỹ sư phải thiết lập các task làm sao để hoàn thành feature được đưa ra từ PO. Vấn đề là sprint quá ngắn với 1 tuần, trong khi thứ 2 thì toàn meeting, còn lại 4 ngày trong tuần, chưa kể có người ốm người không, làm thế nào để hoàn thành bây giờ.
Ví dụ thế này, khi sprint này ko hoàn thành, tuần tới chúng tôi lại họp vừa để thiết kế lại các task cho feature cũ, vừa phải thiết kế luôn cho cả feature mới. Khổ nỗi nếu feature mới priority của nó cao hơn (tức là feature này cần phải giao cho khách hàng sớm hơn cái cũ), thế là chúng tôi gạt cái cũ qua một bên, làm cái mới. Cái cũ làm được một nửa, chưa đầu vào đâu thì lại có cái mởi, giả sử tuần tới lại có cái mới khác mà priority cao hơn cả thì sao :(. Thế là sự việc này nó cứ tiếp diễn dài hơi, cái sau chống chéo cái trước, mỗi thứ làm được một ít, chả cái nào hoàn chỉnh, chả ra đâu vào đâu cả.
Chưa kể đến việc, số lượng PO quá ít, một PO ko bao quát toàn bộ một team (nếu team đó đủ lớn), do đó việc thiết kế các user story của PO bị chậm lại, delay luôn cả sprint (vì các task phải dựa trên user story của PO), hoặc là làm chậm thời gian cho release, hoặc là vô hình chung đặt áp lực lên kỹ sư phải làm cật lực để hoàn thành. Mà tình trạng trên thì nó cứ thường xuyên diễn ra, ai cũng kêu ca. Tôi cũng đã đề xuất là tại sao không tằng sprint thành 2 tuần. Khổ nỗi là giờ tự nhiên có một thằng Tây nó đến nhà các bạn, nó bảo các bạn ăn khoai tây chiên, không được ăn cơm, các bạn có nghe không :D
Hơi vội vàng
Đúng vậy, chính vì cách suy nghĩ “thế giới bên ngoài” đôi khi quá khác biệt so với thực tế trong công ty, việc thay đổi sprint từ một sang hai tuần nghe có vẻ hợp lý để giảm bớt áp lực, nhưng ngay lập tức gặp phải vấn đề khi quyết định này được đưa ra mà không có sự thảo luận với đội ngũ. Các quyết định được đưa ra từ những người không thực sự hiểu rõ tình hình thực tế của các nhóm chúng tôi có thể gây ra sự bối rối và thất vọng, dù việc thay đổi sprint có thể giúp các kỹ sư có thêm thời gian để làm việc hoàn thiện hơn, nhưng không phải ai cũng hiểu được tầm quan trọng của việc này. Và khi những người từ ngoài vào can thiệp quá sâu mà không hiểu nhu cầu thực tế của đội ngũ, tất cả sẽ chỉ làm tình hình tệ thêm.
Khi tôi nhìn lại, tôi nhận ra rằng vấn đề lớn không phải là sprint dài hay ngắn mà là cách các nhóm làm việc với nhau. Giống như cái ví dụ lúc trước về quầy nước chanh, nếu các bạn làm việc riêng biệt mà không hợp tác chặt chẽ, mọi thứ sẽ luôn bị rối tung. Thay vì chỉ kéo dài sprint, chúng tôi cần phải tối ưu hóa cách thức giao tiếp và làm việc chung giữa các nhóm. Nếu chúng ta không thay đổi cách làm việc giữa Dev, Ops, và PO, thì dù thay đổi sprint cũng chẳng giúp ích gì.
Và rồi, điều gì đã xảy ra? Giữa lúc này, tôi bắt đầu nghĩ lại về khái niệm DevOps. Nếu chúng ta chỉ mãi làm việc như thế này, khi Dev luôn phải đối mặt với các deadline gấp gáp, còn Ops thì chỉ lo duy trì sự ổn định, thì không bao giờ chúng tôi có thể đạt được một sự hợp tác hiệu quả. Nếu chúng ta không xây dựng được một quy trình liên tục, nơi mà sự phối hợp giữa các nhóm luôn là ưu tiên hàng đầu, thì chỉ là vòng luẩn quẩn thôi.
Cùng nhìn lại
Đây là lúc tôi và team quyết định ngồi lại cùng nhau để trao đổi trực tiếp với các PO, PM, và các nhóm khác để thay đổi cách thức làm việc. Chúng tôi bắt đầu xây dựng quy trình DevOps thật sự, không phải chỉ là việc thêm một nhóm mới vào, mà là việc thay đổi toàn bộ cách làm việc của đội. DevOps trong trường hợp này là không chỉ là tự động hóa các công việc hay chỉnh sửa một chút ở quy trình, mà là việc tạo ra một văn hóa làm việc mới, nơi mà tất cả mọi người đều hiểu và hỗ trợ nhau từ đầu đến cuối.
Mặc dù không có sự thay đổi ngay lập tức, nhưng chúng tôi dần nhận ra những cải thiện tích cực. Các cuộc họp không còn vô nghĩa, các nhóm bắt đầu hiểu và hỗ trợ nhau trong quá trình xử lý lỗi, triển khai sản phẩm, và không còn “stop the line” nữa. Tuy vẫn có những vấn đề xảy ra, nhưng chúng tôi biết cách phối hợp và giải quyết chúng một cách hiệu quả.
Nhìn lại, tôi nhận ra rằng DevOps không phải là một câu thần chú giúp chúng ta giải quyết mọi vấn đề ngay lập tức. Nó là một quá trình cần thay đổi từ cả quy trình lẫn văn hóa làm việc. Và khi tất cả các nhóm hiểu và áp dụng DevOps đúng cách, mọi thứ sẽ trở nên hiệu quả hơn và ít căng thẳng hơn.
Vậy DevOps là gì
Chúng tôi (Devops) là những người chịu trách nhiệm xây dựng cầu nối giữa đội ngũ phát triển phần mềm và đội ngũ vận hành hệ thống, từ đó đảm bảo quá trình phát triển cũng như triển khai, bảo trì phần mềm được thực hiện trơn tru và hiệu quả.
Không giống như các vai trò truyền thống chỉ tập trung vào một lĩnh vực cụ thể, DevOps hướng đến việc tối ưu hóa toàn bộ chu trình phát triển phần mềm. Kết hợp các công cụ tự động hóa, cải tiến quy trình và áp dụng những phương pháp làm việc linh hoạt để rút ngắn thời gian phát hành sản phẩm, giúp giảm thiểu lỗi và nâng cao trải nghiệm người dùng.
Ngoài ra, DevOps không chỉ là một công việc hay chức danh, mà còn là một văn hóa làm việc, khuyến khích sự hợp tác chặt chẽ giữa các bộ phận liên quan. Thông qua đó, các doanh nghiệp có thể đáp ứng nhanh chóng các thay đổi của thị trường và nhu cầu khách hàng.
DevOps sẽ làm gì
Vai trò của một DevOps chúng tôi rất đa dạng, bao gồm việc tối ưu hóa hiệu suất, tự động hóa quy trình và đảm bảo hệ thống vận hành ổn định. Chúng tôi không chỉ làm việc với opensource mà còn quản lý toàn bộ hạ tầng CNTT.
Dưới đây là một số công việc chính mà DevOps Engineer đảm nhận:
Tích hợp và triển khai liên tục (CI/CD): Chúng tôi thường thiết lập và vận hành các pipeline CI/CD (Continuous Integration/Continuous Deployment) để tự động hóa các quy trình kiểm thử, triển khai phần mềm. Điều này giúp giảm thiểu thời gian chờ đợi giữa các giai đoạn phát triển, đưa sản phẩm ra thị trường nhanh hơn.
Quản lý hạ tầng và triển khai: Chúng tôi chịu trách nhiệm thiết lập, duy trì hạ tầng công nghệ, từ máy chủ vật lý đến các dịch vụ cloud như BizflyCloud, AWS, Google Cloud hoặc Azure. Các công cụ như Docker, Kubernetes, hoặc Terraform thường được sử dụng để đảm bảo hệ thống có khả năng mở rộng và hoạt động ổn định.
Giám sát và xử lý sự cố: Một phần quan trọng trong công việc của Devops là theo dõi hiệu suất hệ thống, phát hiện sớm các sự cố và đưa ra giải pháp khắc phục kịp thời. Chúng tôi thường sử dụng các công cụ giám sát như Prometheus, Grafana hoặc ELK Stack để đảm bảo hệ thống luôn sẵn sàng hoạt động.
Tự động hóa quy trình: Chúng tôi tập trung vào việc tự động hóa các tác vụ lặp đi lặp lại, từ việc xây dựng, triển khai các ứng dụng đến sao lưu dữ liệu và cập nhật hệ thống. Điều này không chỉ tăng hiệu suất làm việc mà còn giảm nguy cơ xảy ra lỗi do thao tác thủ công.
Bảo mật và tối ưu hóa: Ngoài việc duy trì hệ thống, DevOps cũng phải đảm bảo rằng các quy trình, hạ tầng luôn tuân thủ các tiêu chuẩn bảo mật nghiêm ngặt. Chúng tôi cũng thực hiện tối ưu hóa tài nguyên để giảm chi phí và tăng hiệu suất.
Hỗ trợ và đào tạo: DevOps chúng tôi cũng có nhiệm vụ hướng dẫn các thành viên khác trong nhóm sử dụng công cụ và quy trình mới, từ đó tăng tính đồng bộ và hiệu quả.
Cuối cùng
Qua tất cả, tôi tin rằng con đường từ khó khăn đến hiệu quả không bao giờ là dễ dàng, nhưng khi chúng ta kiên trì và không ngừng học hỏi, kết quả cuối cùng sẽ xứng đáng. DevOps, với tất cả những gì nó mang lại, đã giúp chúng tôi nhìn nhận lại cách làm việc, tìm ra những cơ hội cải tiến và thực sự mang lại giá trị cho tổ chức. Và nếu bạn đang ở một bước khởi đầu tương tự, hãy nhớ rằng những thay đổi lớn sẽ đến từ những bước nhỏ và kiên trì.
Comments powered by Disqus.