Tweet
Năm 2009, hai nhân viên từ Flickr (một trang web chia sẻ image) , John Allspaw và Paul Hammond, đã trình bày một cuộc nói chuyện có tiêu đề ”Hơn 10 Deploy mỗi ngày: Hợp tác Dev và Ops tại Flickr” với một loạt các nhà phát triển tại hội nghị O’Reilly Velocity. Trong buổi nói chuyện này, Allspaw và Hammond nói rằng cách duy nhất để xây dựng, kiểm tra và triển khai phần mềm đó là làm cho việc phát triền và vận hành được tích hợp với nhau. Sự táo bạo vượt bậc của việc có thể deploy phần mềm mới một cách nhanh chóng chính là củ cà rốt thúc đẩy sự ra mắt của khái niệm DevOps. Trong nhiều năm kể từ thời điểm đó, DevOps đã chuyển từ việc được một nhóm nhỏ những người nhiệt huyết và đi ngược lại với văn hóa thông thường đã trở thành một thứ thực tế hơn và có thể định lượng được để vận hành bộ máy sản xuất và phát hành phần mềm. Phần lớn các công ty phát triển phần mềm đang tìm cách nắm bắt hiệu quả của mô hình này để đạt được lợi thế cạnh tranh và có thể thích ứng tốt hơn với sự thay đổi từ nhu cầu của khách hàng và ngành.
Tóm lại, DevOps là một nền văn hóa chia sẻ, trong đó các nhà phát triển(developers) và những người vận hành(operations) là một đơn vị có thể thăng trầm cùng nhau. Nó là một ứng dụng thực tế của Lean và Agile. Mục tiêu của DevOps là trở thành công cụ hỗ trợ kinh doanh thời gian thực bằng cách loại bỏ nỗ lực lãng phí và sự rườm rà trong công việc để giải quyết tốt hơn nhu cầu của khách hàng. DevOps có năm nguyên tắc hướng dẫn:
Hình 13-16 cho thấy các thành phần cốt lõi của DevOps và cách chúng có mối quan hệ với nhau.
ĐẶT DEVOPS VÀO THỰC TIỄN: “BA CÁCH”
Khi thảo luận về DevOps, khó có thể không nhắc đến hai cuốn sách rất quan trọng về chủ đề này.Cuốn sách đầu tiên trong số đó, The Phoenix Project, của Gene Kim, Kevin Behr và George Spafford, đã tạo tiền đề cho việc hiểu lợi ích của các phương pháp DevOps thông qua một câu chuyện dựa trên kinh nghiệm của các tác giả và những người đóng góp và cho thấy cách một công ty hư cấu chuyển từ gần như ngừng kinh doanh thành một ngôi sao đang nổi vượt trội hơn đối thủ cạnh tranh. Điều thú vị của cuốn sách là bạn có thể tìm thấy nhiều ví dụ về cuộc sống hàng ngày của bạn được nêu trong đó. Mặc dù có thể sẽ không sớm được dựng thành phim bom tấn, nhưng đọc nhanh có thể dễ dàng cho thấy lợi ích của các phương pháp DevOps. Cuốn sách DevOps quan trọng thứ hai là DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, được viết bởi Gene Kim, Jez Humble, Patrick Debois và John Willis. Cuốn sách này là một cái nhìn thực tế hơn về chủ đề và cung cấp cái nhìn sâu sắc về “Ba cách” của DevOps (được thảo luận trong các phần sau), cung cấp một khuôn khổ để triển khai trong tổ chức của riêng bạn. Nếu bạn muốn biết thêm về DevOps, bạn chắc chắn nên chọn hai cuốn sách này.
Cách Thứ Nhất: Hệ thống và Luồng
Hệ thống đường cao tốc hoạt động hết công suất về cơ bản là một bãi đậu xe, nơi không một ai di chuyển. Tất cả chúng ta đã phải dành thời gian nhìn chằm chằm vào đèn phanh khi tham gia giao thông. Đối với một nhà công nghệ một kịch bản công việc tương đương bao gồm làm thêm giờ và bỏ lỡ bữa cơm gia đình xảy ra quá phổ biến. Nhiều vấn đề xảy ra do hiệu ứng gợn sóng của việc không biết mọi thứ trôi chảy như thế nào và không thể hình dung mọi công việc đang di chuyển như thế nào trong hệ thống. Có một cái nhìn tổng thể về cách mà công việc diễn ra từ quá trình phát triển đến sản xuất là điều cần thiết để tìm ra những cách tối ưu qua đó đạt được mục tiêu cuối cùng của một ứng dụng đâng hoạt động cung cấp giá trị. Nhiều nhóm sử dụng bảng kanban để hình dung công việc, bằng việc thông qua một ứng dụng như Jira hay đơn giản là dán các ghi chú về luồng công việc lên bảng trắng để mọi người có thể thấy những gì đang làm và những gì cần phải làm. Sử dụng bảng kanban có thể giúp một nhóm hợp lý hóa những việc mà họ cần hoàn thành trong một khoảng thời gian nhất định. Hình 13-17 cho thấy cách đầu tiên của DevOps, đó là tập trung vào hệ thống và luồng.
Hình 13-17 Cách đầu tiên: Hệ thống và luồng
Để hoàn thành mục tiêu, bạn phải giảm bớt các unit(đơn vị) công việc, hoặc lô công việc để chúng được sắp xếp hợp lý hơn nhằm ngăn chặn tình trạng ùn tắc do khối lượng công việc. Trong một Agile sprint, người ta thường làm việc trên một tập hợp nhỏ các tính năng trong khoảng thời gian hai tuần để giảm mức độ làm việc trong một khoảng thời gian nhất định. Điều này cho phép các nhà phát triển có thời gian để xây dựng khả năng mà không bị choáng ngợp hoặc bị sao nhãng theo nhiều hướng. Điều này cũng áp dụng cho mặt vận hành, vì cả hai mặt đều cần thiết để hệ thống hoạt động mượt mà.
Các nhà phát triển không thể chỉ tạo ra các bản cập nhật ứng dụng cho các nhóm vận hành của họ mà không có cái nhìn chắc chắn về cách triển khai từng bản cập nhật và các nhóm vận hành phải xây dựng một hệ thống có thể xử lý tốc độ và sự nhanh nhẹn mà các nhà phát triển cần. Bằng cách để bộ phận phát triển và bộ phận vận hành làm việc cùng nhau để hiểu rõ ràng buộc ở đâu, bạn có thể tối ưu hóa hệ thống và di chuyển nhanh hơn.
Chất lượng không phải yếu tố cuối cùng của quá trình phát triển và triển khai. Nó phải được trải dài trên toàn bộ hệ thống. Chờ đợi một vấn đề được tìm thấy trong Q&A sẽ tạo ra nhiều vấn đề phức tạp có thể khiến mọi thứ trở nên tồi tệ hơn nhiều. Bạn giải quyết một tình huống khó khăn càng sớm, thì nổ lực làm việc tổng thể của bạn sẽ càng giảm đi. Điều này cũng tương đương với việc tiết kiệm tiền bạc và thời gian. Toàn bộ vấn đề là giảm lãng phí thời gian cho việc làm lại. Bạn phải liên tục tối ưu hóa hệ thống để làm cho nó hoạt động hiệu quả hơn. Không có gì là hoàn hảo với DevOps; bạn đang ở trong trạng thái liên tục loại bỏ sự thiếu hiệu quả. Bạn phải có khả năng thích ứng với nhu cầu kinh doanh và yêu cầu luôn thay đổi của khách hàng.
Sau đây là những đặc điểm chính của cách thứ nhất:
Cách Thứ Hai: Vòng Lặp Phản Hồi (Feedback Loops)
Một trong những điều bạn sẽ thấy lặp đi lặp lại trong DevOps là sự tương đồng với sản xuất. Vì phần lớn triết lý quản lý này bắt nguồn từ Lean và Hệ thống sản xuất Toyota, các khái niệm như ngăn ngừa lỗi là trọng tâm trong cách tiếp cận. Ý tưởng của một feedbcak loop(vòng lặp phản hồi) là cung cấp hướng dẫn và định hướng về những gì đang hoạt động và những gì không hoạt động. Nếu điều gì đó không hoạt động, bạn phải đảm bảo rằng điều đó sẽ không xảy ra nữa để không rơi vào “bánh xe đau đớn của chuột hamster”. DevOps yêu cầu bạn coi phản hồi như một món quà và thực hiện các chỉnh sửa. Hình 13-18 cho thấy cách thứ hai của DevOps, tập trung vào feedback loop.
Bạn càng lấy mẫu phản hồi, bạn càng có thể phát hiện sự cố và khôi phục chúng nhanh hơn. Trong Hệ thống Sản xuất Toyota, dây chuyền sản xuất có một thứ gọi là dây Andon(Adon Cord), có thể được bất kỳ ai kéo vào bất cứ lúc nào để dừng dây chuyền sản xuất. Hình thức phản hồi này là ngay lập tức và rất rõ ràng. Nó cũng bắt đầu quá trình tập hợp một vấn đề cho đến khi nó được khắc phục, nơi mọi người trong khu vực tập trung giải quyết vấn đề trước khi đường truyền được khởi động lại. Trong DevOps, kiểu trao quyền này có nghĩa là khi phát hiện sự cố với phần mềm, cả nhóm sẽ nỗ lực để khắc phục nguyên nhân cơ bản.
Khi một vấn đề nào đó được giải quyết, đó chưa phải là lúc để có một bữa tiệc ăn mừng; đó là lúc để lúc ghi lại và cải thiện các quy trình dẫn đến vấn đề đang xảy ra: Học hỏi từ những sai lầm của bạn để bạn có thể tiến xa hơn.
Sau đây là các đặc điểm chính của cách thứ hai:
Cách Thứ Ba: Liên Tục Thử Nghiệm Và Học Hỏi
Làm thế nào để thúc đẩy sự đổi mới? Tạo ra một nền văn hóa tin tưởng nơi mọi người của bạn được phép thử những điều mới và thất bại. Điều đó không có nghĩa là bạn chỉ đang tung xúc xắc với những ý tưởng lập dị; mặt khác, nó có nghĩa là có một cách tiếp cận năng động và kỷ luật để thử nghiệm và chấp nhận rủi ro. Rất hiếm khi thành công xảy ra trong lần thử đầu tiên. Khi có sự cố xảy ra, tránh chỉ tay và đổ lỗi cho người khác; thay vào đó, hãy tìm ra vấn đề là gì và những gì có thể cải thiện được để làm cho nó tốt hơn. Hình 13-19 cho thấy cách thứ ba của DevOps, tập trung vào thử nghiệm và học hỏi liên tục.
DevOps nói nhiều về việc liên tục cải tiến và sửa chữa các vấn đề để làm cho hệ thống hoạt động tốt hơn. Đó là một mục tiêu cao cả, nhưng thời gian ở đâu đề làm những việc đó? Câu trả lời đơn giản là bạn cần phải dành thời gian. Nói cách khác, bạn sắp xếp thời gian để mọi người tập trung vào việc cải thiện hệ thống và thử các phương pháp và công nghệ mới.
Cuối cùng, bạn phải xây dựng văn hóa chia sẻ và học hỏi. Một phương pháp đơn giản để thực hiện điều này là tạo kho lưu trữ code được chia sẻ và lấy kho tàng thông tin đó từ máy tính xách tay cá nhân và luôn có sẵn khi mọi người trong công ty cần.
Sau đây là các đặc điểm chính của cách thứ ba:
Tóm lại, DevOps là một nền văn hóa chia sẻ, trong đó các nhà phát triển(developers) và những người vận hành(operations) là một đơn vị có thể thăng trầm cùng nhau. Nó là một ứng dụng thực tế của Lean và Agile. Mục tiêu của DevOps là trở thành công cụ hỗ trợ kinh doanh thời gian thực bằng cách loại bỏ nỗ lực lãng phí và sự rườm rà trong công việc để giải quyết tốt hơn nhu cầu của khách hàng. DevOps có năm nguyên tắc hướng dẫn:
- Văn hóa: Để DevOps hoạt động, văn hóa tổ chức phải thay đổi. Cho đến nay, đây là một trong những khía cạnh khó nắm bắt nhất, nhưng nó là yếu tố quan trọng nhất để dẫn đến thành công. DevOps yêu cầu văn hóa chia sẻ.
- Tự động hóa: Trong khi DevOps không chỉ là một bộ công cụ phần mềm, tự động hóa là lợi ích dễ nhận biết nhất. Các kỹ thuật tự động hóa tăng tốc đáng kể quá trình deploy sản phẩm, cho phép phát hiện và sửa chữa các lỗ hổng sớm hơn, đồng thời loại bỏ sự can thiệp của con người vào các nhiệm vụ lặp đi lặp lại.
- Lean: Giảm thiểu những nỗ lực lãng phí và hợp lý hóa quy trình là những mục tiêu của Lean. Đó là triết lý quản lý về sự cải tiến và học hỏi liên tục.
- Đo lường: Trừ khi bạn đo lường kết quả của mình, bạn không bao giờ có thể cải thiện. Thành công với DevOps đòi hỏi việc đo lường các chỉ số về hiệu suất, quy trình và con người càng thường xuyên càng tốt.
- Chia sẻ: DevOps yêu cầu văn hóa phản hồi và chia sẻ. Phá vỡ các silo và tạo ra một môi trường chia sẻ hòa nhập là mục tiêu cuối cùng.
Hình 13-16 cho thấy các thành phần cốt lõi của DevOps và cách chúng có mối quan hệ với nhau.
Hình 13-16 DevOps
ĐẶT DEVOPS VÀO THỰC TIỄN: “BA CÁCH”
Khi thảo luận về DevOps, khó có thể không nhắc đến hai cuốn sách rất quan trọng về chủ đề này.Cuốn sách đầu tiên trong số đó, The Phoenix Project, của Gene Kim, Kevin Behr và George Spafford, đã tạo tiền đề cho việc hiểu lợi ích của các phương pháp DevOps thông qua một câu chuyện dựa trên kinh nghiệm của các tác giả và những người đóng góp và cho thấy cách một công ty hư cấu chuyển từ gần như ngừng kinh doanh thành một ngôi sao đang nổi vượt trội hơn đối thủ cạnh tranh. Điều thú vị của cuốn sách là bạn có thể tìm thấy nhiều ví dụ về cuộc sống hàng ngày của bạn được nêu trong đó. Mặc dù có thể sẽ không sớm được dựng thành phim bom tấn, nhưng đọc nhanh có thể dễ dàng cho thấy lợi ích của các phương pháp DevOps. Cuốn sách DevOps quan trọng thứ hai là DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, được viết bởi Gene Kim, Jez Humble, Patrick Debois và John Willis. Cuốn sách này là một cái nhìn thực tế hơn về chủ đề và cung cấp cái nhìn sâu sắc về “Ba cách” của DevOps (được thảo luận trong các phần sau), cung cấp một khuôn khổ để triển khai trong tổ chức của riêng bạn. Nếu bạn muốn biết thêm về DevOps, bạn chắc chắn nên chọn hai cuốn sách này.
Cách Thứ Nhất: Hệ thống và Luồng
Hệ thống đường cao tốc hoạt động hết công suất về cơ bản là một bãi đậu xe, nơi không một ai di chuyển. Tất cả chúng ta đã phải dành thời gian nhìn chằm chằm vào đèn phanh khi tham gia giao thông. Đối với một nhà công nghệ một kịch bản công việc tương đương bao gồm làm thêm giờ và bỏ lỡ bữa cơm gia đình xảy ra quá phổ biến. Nhiều vấn đề xảy ra do hiệu ứng gợn sóng của việc không biết mọi thứ trôi chảy như thế nào và không thể hình dung mọi công việc đang di chuyển như thế nào trong hệ thống. Có một cái nhìn tổng thể về cách mà công việc diễn ra từ quá trình phát triển đến sản xuất là điều cần thiết để tìm ra những cách tối ưu qua đó đạt được mục tiêu cuối cùng của một ứng dụng đâng hoạt động cung cấp giá trị. Nhiều nhóm sử dụng bảng kanban để hình dung công việc, bằng việc thông qua một ứng dụng như Jira hay đơn giản là dán các ghi chú về luồng công việc lên bảng trắng để mọi người có thể thấy những gì đang làm và những gì cần phải làm. Sử dụng bảng kanban có thể giúp một nhóm hợp lý hóa những việc mà họ cần hoàn thành trong một khoảng thời gian nhất định. Hình 13-17 cho thấy cách đầu tiên của DevOps, đó là tập trung vào hệ thống và luồng.
Hình 13-17 Cách đầu tiên: Hệ thống và luồng
Để hoàn thành mục tiêu, bạn phải giảm bớt các unit(đơn vị) công việc, hoặc lô công việc để chúng được sắp xếp hợp lý hơn nhằm ngăn chặn tình trạng ùn tắc do khối lượng công việc. Trong một Agile sprint, người ta thường làm việc trên một tập hợp nhỏ các tính năng trong khoảng thời gian hai tuần để giảm mức độ làm việc trong một khoảng thời gian nhất định. Điều này cho phép các nhà phát triển có thời gian để xây dựng khả năng mà không bị choáng ngợp hoặc bị sao nhãng theo nhiều hướng. Điều này cũng áp dụng cho mặt vận hành, vì cả hai mặt đều cần thiết để hệ thống hoạt động mượt mà.
Các nhà phát triển không thể chỉ tạo ra các bản cập nhật ứng dụng cho các nhóm vận hành của họ mà không có cái nhìn chắc chắn về cách triển khai từng bản cập nhật và các nhóm vận hành phải xây dựng một hệ thống có thể xử lý tốc độ và sự nhanh nhẹn mà các nhà phát triển cần. Bằng cách để bộ phận phát triển và bộ phận vận hành làm việc cùng nhau để hiểu rõ ràng buộc ở đâu, bạn có thể tối ưu hóa hệ thống và di chuyển nhanh hơn.
Chất lượng không phải yếu tố cuối cùng của quá trình phát triển và triển khai. Nó phải được trải dài trên toàn bộ hệ thống. Chờ đợi một vấn đề được tìm thấy trong Q&A sẽ tạo ra nhiều vấn đề phức tạp có thể khiến mọi thứ trở nên tồi tệ hơn nhiều. Bạn giải quyết một tình huống khó khăn càng sớm, thì nổ lực làm việc tổng thể của bạn sẽ càng giảm đi. Điều này cũng tương đương với việc tiết kiệm tiền bạc và thời gian. Toàn bộ vấn đề là giảm lãng phí thời gian cho việc làm lại. Bạn phải liên tục tối ưu hóa hệ thống để làm cho nó hoạt động hiệu quả hơn. Không có gì là hoàn hảo với DevOps; bạn đang ở trong trạng thái liên tục loại bỏ sự thiếu hiệu quả. Bạn phải có khả năng thích ứng với nhu cầu kinh doanh và yêu cầu luôn thay đổi của khách hàng.
Sau đây là những đặc điểm chính của cách thứ nhất:
- Làm mọi công việc có thể nhìn thấy được
- Giảm kích thước lô công việc
- Giảm khoảng cách của công việc
- Xây dựng chất lượng bằng cách ngăn chặn các khiếm khuyết được truyền xuống hạ lưu
- Không ngừng tối ưu hóa cho các mục tiêu kinh doanh
Cách Thứ Hai: Vòng Lặp Phản Hồi (Feedback Loops)
Một trong những điều bạn sẽ thấy lặp đi lặp lại trong DevOps là sự tương đồng với sản xuất. Vì phần lớn triết lý quản lý này bắt nguồn từ Lean và Hệ thống sản xuất Toyota, các khái niệm như ngăn ngừa lỗi là trọng tâm trong cách tiếp cận. Ý tưởng của một feedbcak loop(vòng lặp phản hồi) là cung cấp hướng dẫn và định hướng về những gì đang hoạt động và những gì không hoạt động. Nếu điều gì đó không hoạt động, bạn phải đảm bảo rằng điều đó sẽ không xảy ra nữa để không rơi vào “bánh xe đau đớn của chuột hamster”. DevOps yêu cầu bạn coi phản hồi như một món quà và thực hiện các chỉnh sửa. Hình 13-18 cho thấy cách thứ hai của DevOps, tập trung vào feedback loop.
Hình 13-18 Cách thứ hai: Vòng lặp phản hồi
Bạn càng lấy mẫu phản hồi, bạn càng có thể phát hiện sự cố và khôi phục chúng nhanh hơn. Trong Hệ thống Sản xuất Toyota, dây chuyền sản xuất có một thứ gọi là dây Andon(Adon Cord), có thể được bất kỳ ai kéo vào bất cứ lúc nào để dừng dây chuyền sản xuất. Hình thức phản hồi này là ngay lập tức và rất rõ ràng. Nó cũng bắt đầu quá trình tập hợp một vấn đề cho đến khi nó được khắc phục, nơi mọi người trong khu vực tập trung giải quyết vấn đề trước khi đường truyền được khởi động lại. Trong DevOps, kiểu trao quyền này có nghĩa là khi phát hiện sự cố với phần mềm, cả nhóm sẽ nỗ lực để khắc phục nguyên nhân cơ bản.
Khi một vấn đề nào đó được giải quyết, đó chưa phải là lúc để có một bữa tiệc ăn mừng; đó là lúc để lúc ghi lại và cải thiện các quy trình dẫn đến vấn đề đang xảy ra: Học hỏi từ những sai lầm của bạn để bạn có thể tiến xa hơn.
Sau đây là các đặc điểm chính của cách thứ hai:
- Mở rộng phản hồi để ngăn sự cố quay lại lần nữa
- Cho phép phát hiện và khôi phục nhanh hơn
- Xem các sự cố khi chúng xảy ra và tập hợp chúng lại cho đén khi chúng được khắc phục
- Tối đa hóa cơ hội để học hỏi và cải thiện
Cách Thứ Ba: Liên Tục Thử Nghiệm Và Học Hỏi
Làm thế nào để thúc đẩy sự đổi mới? Tạo ra một nền văn hóa tin tưởng nơi mọi người của bạn được phép thử những điều mới và thất bại. Điều đó không có nghĩa là bạn chỉ đang tung xúc xắc với những ý tưởng lập dị; mặt khác, nó có nghĩa là có một cách tiếp cận năng động và kỷ luật để thử nghiệm và chấp nhận rủi ro. Rất hiếm khi thành công xảy ra trong lần thử đầu tiên. Khi có sự cố xảy ra, tránh chỉ tay và đổ lỗi cho người khác; thay vào đó, hãy tìm ra vấn đề là gì và những gì có thể cải thiện được để làm cho nó tốt hơn. Hình 13-19 cho thấy cách thứ ba của DevOps, tập trung vào thử nghiệm và học hỏi liên tục.
Hình 13-19 Cách thứ ba: Liên tục thử nghiệm và học hỏi
DevOps nói nhiều về việc liên tục cải tiến và sửa chữa các vấn đề để làm cho hệ thống hoạt động tốt hơn. Đó là một mục tiêu cao cả, nhưng thời gian ở đâu đề làm những việc đó? Câu trả lời đơn giản là bạn cần phải dành thời gian. Nói cách khác, bạn sắp xếp thời gian để mọi người tập trung vào việc cải thiện hệ thống và thử các phương pháp và công nghệ mới.
Cuối cùng, bạn phải xây dựng văn hóa chia sẻ và học hỏi. Một phương pháp đơn giản để thực hiện điều này là tạo kho lưu trữ code được chia sẻ và lấy kho tàng thông tin đó từ máy tính xách tay cá nhân và luôn có sẵn khi mọi người trong công ty cần.
Sau đây là các đặc điểm chính của cách thứ ba:
- Tiến hành thử nghiệm, có kỷ luật và chấp nhận rủi ro
- Xác định thời gian để khắc phục sự cố và cải thiện hệ thống
- Khi có vấn đề, đừng chỉ tay
- Tạo ra một kho lưu trữ chia sẻ code