Trường Hợp Sử Dụng – Giao Hàng Cùng Chef

Chuyển đổi nội dung buổi nói chuyện:

Chào buổi sáng. Tôi nhận ra rằng mình chưa hiển thị tên lên slide, nên vừa mới bổ sung – chắc khá khó để các bạn nhìn thấy nhưng tôi là Michael Ducy, đến từ Chef. Hôm nay, tôi sẽ chia sẻ góc nhìn về pipeline phát hành phần mềm, đặc biệt từ phía vận hành. Nội dung sẽ có một số thay đổi so với bản tóm tắt ban đầu, nhằm mang lại cái nhìn thực tế và ứng dụng sát nhất về quá trình vận hành release pipeline. Cảm ơn bạn đồng nghiệp phía sau đã hỗ trợ tắt nhạc giúp tôi để bắt đầu phần trình bày.

Đầu tiên, tôi muốn khảo sát: Có bao nhiêu người ở đây đã từng sử dụng Chef? Một vài người. Ai đã từng nghe về Chef? Khá nhiều hơn. Vậy có ai hoàn toàn chưa biết Chef là gì không? Cũng có một số bạn. Đây là điều quan trọng cần lưu ý.

Trong vài năm gần đây, Chef khởi đầu như một công cụ quản lý cấu hình. Khi áp dụng triết lý infrastructure as code, chúng tôi dần vận hành giống như những lập trình viên về quy trình và tư duy quản lý hạ tầng. Ban đầu, Chef chủ yếu phục vụ lĩnh vực vận hành web quy mô lớn, đặc biệt thương mại điện tử. Sau này, phạm vi áp dụng mở rộng hơn, bao gồm cả các tổ chức doanh nghiệp, ngân hàng… Trong bối cảnh DevOps phát triển, Chef đã trở thành yếu tố phù hợp với làn sóng này.

Chủ đề trọng tâm hôm nay là hành trình xây dựng pipeline phát hành và giải thích vì sao chúng tôi tiếp cận theo cách riêng khác biệt.

Về cơ bản, nếu phải mô tả Chef trong một câu ngắn gọn: Chef là giải pháp infrastructure as code. Nghĩa là Chef cung cấp ngôn ngữ DSL dựa trên Ruby cho phép bạn lập trình hóa quy trình triển khai và cấu hình các thành phần (có thể là file, dịch vụ chạy trên hệ thống hoặc endpoints API). Điển hình, trong quá trình release pipeline, chúng tôi tự động thao tác với Artifactory API để xuất bản RPM lên hệ thống download của Chef. Quan điểm infrastructure as code là mã hạ tầng (Chef code) nên được vận hành tương tự như bất kỳ code base tham chiếu nào khác – tôi sẽ phân tích sâu hơn ở phần sau.

Vậy, ba yếu tố cốt lõi mà infrastructure as code cần đảm bảo: [1] Có thể tái dựng hệ thống/doanh nghiệp từ repository chứa cả mã nguồn ứng dụng và mã hạ tầng; [2] Luôn có bản backup dữ liệu (bởi vì dữ liệu không thuộc phạm vi Chef đảm trách); [3] Có tài nguyên máy tính (dù vật lý, ảo hóa hay Cloud – AWS, Azure, v.v). Ba yếu tố trên là nền tảng giúp bạn xây dựng và khôi phục toàn bộ stack vận hành.

Để hạ tầng như mã có thể duy trì, bạn nên treat nó như bất kỳ codebase nào. Điều đó đồng nghĩa với việc áp dụng các kỹ thuật, quy trình phát triển phần mềm: kiểm soát version bằng source control, kiểm thử (testing), và tích hợp pipeline CI/CD cho mã hạ tầng.

Về kiểm thử – chúng tôi nhận thấy khi chuyển sang mô hình infrastructure as code, test coverage mang ý nghĩa sống còn từ hai khía cạnh: [1] Kiểm tra tính đúng đắn của mã Chef (unit test); [2] Xác nhận thực tế việc triển khai mã hạ tầng tại môi trường sống và đúng như kỳ vọng (integration test). Các công cụ như serverspec, inspec và các tool cộng đồng hỗ trợ sâu rộng cho quy trình này.

Điều mà tôi nhận thấy từ góc độ vận hành là: trước kia khi viết shell script, việc kiểm thử chủ yếu chỉ là triển khai thủ công lên hệ thống thật – manual testing. Tuy nhiên, khi tiến tới release pipeline hiện đại, tự động hóa kiểm thử là bước bắt buộc, bất kỳ test nào chưa tự động hãy tìm cách thay đổi hoặc loại bỏ, để không bị sa lầy vào quy trình thủ công gây chậm trễ và rủi ro.

Chúng tôi đã áp dụng Test Driven Development (TDD) cho infrastructure as code. Quy trình là viết test trước (red), test fail, sau đó viết mã để test pass (green). Đây là phương pháp giúp kiểm soát chất lượng, giới hạn lỗi và hướng tới pipeline phát hành tin cậy.

Khi xây dựng release pipeline cho Chef cookbook, chúng tôi quan sát và rút ra nhiều mô hình, pattern tốt cũng như những sai sót phổ biến trong thực tiễn khách hàng – và tôi sẽ phân tích kỹ hơn trong các phần tiếp theo.

Một hiện tượng trong ngành là khái niệm Continuous Delivery đang được phổ biến rộng rãi nhưng ít ai thực sự soi xét giá trị cốt lõi mà nó mang lại cho doanh nghiệp.

Bạn có thể nghe nhắc tới “ba phương pháp” trong DevOps – ý tưởng này lấy cảm hứng từ cuốn sách “The Phoenix Project” của Gene Kim: [1] Tư duy hệ thống (System Thinking); [2] Khuếch đại vòng phản hồi (Amplify Feedback); [3] Học tập & cải tiến liên tục.

Với tư duy hệ thống, bạn có thể tránh tối ưu cục bộ, nhìn nhận toàn diện từ lúc mã được commit cho tới khi chạy trên hệ thống thật, và nhận biết được mọi tác động tới các mắt xích đầu/cuối trong dây chuyền phát hành.

Pipeline phát hành còn giúp khuếch đại feedback – khi lỗi phát sinh ở đâu hệ thống sẽ báo ngay, giúp bạn nhanh chóng nắm bắt vấn đề và cải thiện. Từ đó, doanh nghiệp duy trì động lực cải tiến liên tục quy trình, công nghệ.

Mô hình deployment pipeline đề xuất trong sách “Continuous Delivery” (2010) là ví dụ điển hình minh họa tính tối ưu hóa và feedback loop ngắn, giúp mọi thành viên dễ dàng quan sát tổng thể quy trình – điều mà thực tế nhiều doanh nghiệp lại triển khai quá phức tạp, phân nhánh đa môi trường, merging phức tạp, thiếu đồng nhất và khó tối ưu hóa toàn hệ thống.

Vấn đề phổ biến là pipeline ngày càng phình to, khó kiểm soát do chứa quá nhiều bước, tính năng hoặc xử lý batch lớn – dẫn tới việc phát hiện lỗi, rollback khắc phục trở nên khó khăn, mất nhiều thời gian và nguồn lực.

Vì vậy, lời khuyên là hãy tinh gọn pipeline, tập trung vào cải tiến liên tục thông qua các thay đổi nhỏ, incremental, giảm số bước kiểm thử tới mức tối thiểu có thể xác thực chất lượng sản phẩm, tận dụng lợi ích troubleshooting khi xảy ra lỗi – chỉ cần đối chiếu một thay đổi nhỏ là đủ xác định nguyên nhân.

Đồng nhất cấu trúc pipeline, quy trình và nomenclature giữa các nhóm giúp tăng cường consistency, tối ưu hóa kiểm thử, đảm bảo chất lượng cũng như rút ngắn thời gian onboard khi chuyển nhóm hoặc dự án mới.

Khi pipeline đồng nhất, doanh nghiệp dễ dàng áp dụng chung các bước kiểm thử bảo mật, compliance hoặc tích hợp thêm công cụ, tạo tiền đề cho automation, tiết kiệm thời gian học lại quy trình, hạn chế tranh cãi không cần thiết (hiện tượng “bike shedding” – hình thành từ Parkinson’s Law of Triviality).

Về tối ưu hóa pipeline: Chúng ta có thể mượn khái niệm value stream mapping từ Lean/Toyota Production System. Nhìn vào dòng giá trị, bạn sẽ nhận ra rõ ràng đâu là thời gian tạo giá trị thực sự, đâu là lãng phí (muda), từ đó tập trung loại bỏ triệt để thời gian chờ đợi, approve, thủ tục hoặc các bước không tạo giá trị cho khách hàng.

Các nguyên tắc Lean như mô tả ở trên bao gồm kiểm soát defect, hạn chế “overproduction” những thứ không có nhu cầu, giảm inventory chờ xử lý… Về mặt công cụ, các giải pháp như Vagrant giúp developer nhanh chóng tạo môi trường phát triển gần sát production, nâng cao chất lượng kiểm thử ngay từ đầu pipeline.

Ngoài ra, kiểm soát số lượng tính năng vào pipeline – bởi có thống kê rằng 2/3 feature phát hành không bao giờ được sử dụng tới, AB Testing và điều phối feedback nhanh từ khách hàng cực kỳ quan trọng giúp tránh đầu tư vào các tính năng dư thừa.

Việc tự động hóa kiểm thử, giảm các thủ tục giấy tờ, approval hoặc wait states quá nhiều là chiến lược then chốt để delivery nhanh, an toàn và ổn định.

Đến phần giải pháp: Chef Delivery thực tế được thiết kế để xử lý các vấn đề về pipeline hiện đại – với quy trình đồng nhất, mỗi khi phát hành một tính năng, mã sẽ được lint, kiểm thử, review, duyệt (rule of four eyes), tiếp tục merge vào master, build và deploy trực tiếp lên môi trường acceptance – nơi chạy kiểm thử thực tế smoke, functional. Product manager/owner sẽ quyết định có phát hành/handover ra production hay không.

Tất cả các nhóm, sản phẩm đều sử dụng chung pipeline này, dễ dàng kiểm soát chất lượng, chu trình kiểm thử, rút ngắn thời gian phát hành, nhanh chóng rollback/khoanh vùng khi gặp lỗi. Khi phát hành, các artifact phụ thuộc sẽ được kiểm thử chéo đảm bảo không ảnh hưởng lẫn nhau – điều này chỉ thực hiện được khi pipeline đồng nhất toàn doanh nghiệp.

Các ưu điểm lớn của Chef Delivery là: đồng nhất quy trình giữa các team, enforce batch nhỏ, incremental release, kiểm thử chất lượng chuẩn hóa, pipeline có thể bật/tắt linh hoạt từng phase, cực kỳ dễ tạo/làm mới với chỉ 2 lệnh cơ bản – giúp rút ngắn thời gian triển khai và vận hành cho đội ngũ IT.

Thông điệp quan trọng: Hãy bắt đầu tối ưu hóa pipeline bằng việc xuất bản artifact đầu tiên, sau đó từng bước tích hợp testing vào các phase khác nhau.

Softribution sẵn sàng tư vấn và triển khai các giải pháp hiện đại về pipeline phát hành, tối ưu hóa quy trình DevOps phù hợp doanh nghiệp của bạn. Liên hệ Softribution ngay hôm nay để được chuyên gia hỗ trợ xây dựng hệ thống tự động hóa phát hành phần mềm và chọn lựa giải pháp phù hợp nhất!