Giai đoạn 1 - Tại sao lại phải DevOps?
Chào mừng bạn đến với chặng tiếp theo của hành trình 90 ngày cùng DevOps, và chúng ta đang ở điểm đến đầu tiên.
Nguồn: Orlando Espinosa
Ngày 2: Trách nhiệm của một kỹ sư DevOps 👨💻
Section titled “Ngày 2: Trách nhiệm của một kỹ sư DevOps 👨💻”Ở bài viết này, chúng ta sẽ đi sâu vào hai quá trình cơ bản: Phát triển (Dev - Development), nơi kỹ sư phát triển phần mềm sẽ lập trình và kiểm thử ứng dụng, và Vận hành (Ops - Operations), nơi ứng dụng được triển khai và vận hành trên hệ thống máy chủ.
Mối quan hệ “không thể tách rời”… 💖
Section titled “Mối quan hệ “không thể tách rời”… 💖”DevOps là gì? Vắt óc suy nghĩ đến đau đầu cho một câu trả lời, để rồi chúng ta nhận ra rằng, cần hiểu rõ về các công cụ, quy trình cũng như cách mà Dev và Ops phối hợp với nhau. Ta bắt đầu với từ khóa chính của ngày hôm nay: Ứng dụng.
Nguồn: MAAS
Mỗi ứng dụng được tạo ra bởi các kỹ sư phần mềm, bằng nhiều cách khác nhau, nhiều ngôn ngữ lập trình khác nhau: Java, Python, Ruby, JavaScript, C#, C++, … và được triển khai với nhiều công cụ cho các quy trình khác nhau: Dựng ứng dụng (Build), Quản lý mã nguồn (Source Control), Kiểm thử (Test), …
Là một kỹ sư DevOps, bạn cần hiểu rõ về cách làm việc của một kỹ sư phần mềm cũng như hệ thống, công cụ cần thiết cho quá trình phát triển đó. Tất nhiên, bạn không phải là một siêu nhân, và điểm quan trọng là bạn không đi lập trình các ứng dụng này - nếu ai đó bảo bạn làm DevOps nhưng bắt bạn lập trình mã nguồn ứng dụng, hãy cân nhắc lại công việc của mình.
Nguồn: Linkedin
Thứ bạn cần quan tâm với DevOps là cách ứng dụng tương tác với các dịch vụ, dữ liệu và những yêu cầu, phương pháp khác nhau mà chúng ta có thể kiểm chứng được những điều này.
Hãy xem máy chủ là nơi ứng dụng triển khai. Người dùng đầu cuối truy cập vào ứng dụng qua máy chủ này. Máy chủ này có thể là một máy chủ vật lý hoặc máy chủ ảo, hoặc một dịch vụ đám mây như AWS, Azure, GCP, hay thậm chí là phi máy chủ (Serverless) - à ừm, đây là xu hướng của nhiều doanh nghiệp hiện nay, mặc dù nó không phải là chủ đề mà chúng ta sẽ nói đến trong ngày hôm nay. Nhiệm vụ của một kỹ sư DevOps thực chất chính là chuẩn bị, cài đặt và triển khai ứng dụng trên máy chủ này.
Mỗi máy chủ có thể sử dụng một hệ điều hành khác nhau: Windows, Linux,… Ở series này, chúng ta sẽ dành ra1 tuần để nói về Linux. Đừng lo lắng nếu bạn chưa từng sử dụng Linux, chúng ta sẽ bắt đầu từ những kiến thức cơ bản nhất, để bạn không phải đau đầu đi làm khó chủ nhân trang web đâu.
Nguồn: Reddit
Những kiến thức cơ bản khác về Mạng máy tính và các dịch vụ mạng cũng sẽ được đề cập trong series này. Bởi lẽ,trách nhiệm của kỹ sư DevOps là đảm bảo các máy chủ có thể giao tiếp với nhau hoặc với các thành phần khác. DNS,DHCP, Cân bằng tải, … là những mục sẽ có trong phần sau của chuyến hành trình 90 ngày “đau khổ” này.
Mr./Mrs./Ms. Biết tuốt ✅
Section titled “Mr./Mrs./Ms. Biết tuốt ✅”Tại sao phải biết tuốt? Bạn không cần phải là một chuyên gia về mọi thứ, nhưng cần phải biết cách tìm hiểu và giải quyết vấn đề. Đặc biệt, bạn cần phải có kiến thức nền tảng về cách triển khai và kết nối các thành phần ứng dụng với nhau. Bạn cũng chả cần đi lập trình ứng dụng, nhưng ít nhất bạn phải nắm những điều cơ bản về lập trình, để hiểu được cách mà ứng dụng hoạt động. Nếu ai bảo rằng học DevOps là không cần phải biết lập trình - coi chừng họ đã quên mất ý nghĩa từ khóa DevOps đã bao gồm chữ Dev ở trong đó rồi.
Nguồn: Dzone
Có nhiều khả năng là bạn sẽ chẳng cần phải quản lý hay tương tác với máy chủ/ứng dụng mỗi ngày. Mà nhắc tới máy chủ mới nhớ, nói vậy thôi, chứ máy chủ ngoài đời thực nhiều khi chính là container. Điều này cũng có nghĩa là, bạn phải biết về Docker, Kubernetes, OpenShift, … để quản lý các container này. Đừng “Hoang mang” như ca sĩ Hồ Quỳnh Hương, chúng ta sẽ nói về container ở điểm dừng chân tiếp theo, để bạn không phải hát lên câu hát kinh điển: “Em quay cuồng trong mơ hồ…” thuở nào. 🎶
Nguồn: Wikipedia
Tóm tắt 📝
Section titled “Tóm tắt 📝”- DevOps là một quá trình kết hợp giữa phát triển và vận hành ứng dụng.
- Kỹ sư DevOps cần phải hiểu rõ về cách ứng dụng tương tác với các dịch vụ, dữ liệu và yêu cầu.
- Kỹ sư DevOps cần phải biết cách triển khai và kết nối hệ thống với nhau.
Có một điều quan trọng quên đề cập: Làm thế nào đưa tính năng mới/bản vá lỗi/phiên bản mới đến người dùng cuối một cách nhanh chóng, an toàn và hiệu quả? Ngoài ra cần phải bao gồm cả quá trình kiểm thử và đặc biệt là phải tự động hóa quá trình này. Đó chính là một trong những nhiệm vụ quan trọng của kỹ sư DevOps.
Xin được chấm dứt chặng 2 của hành trình này. Với những cố gắng thường xuyên trong những ngày qua, ước mong mọi người đã hiểu hơn phần nào nội dung bài viết này. Hẹn tái ngộ cùng mọi người vào ngày mai, cũng tại website này. 🚀
Ngày 3: Vòng đời của DevOps - Lấy ứng dụng làm trung tâm 📱
Section titled “Ngày 3: Vòng đời của DevOps - Lấy ứng dụng làm trung tâm 📱”Chào mừng quý vị và các bạn đến với ngày thứ ba của hành trình 90 ngày cùng DevOps.
Ngày hôm nay, điểm dừng chân tiếp theo của chúng ta sẽ là Vòng đời của DevOps. Chúng ta sẽ tìm hiểu về các giai đoạn của vòng đời này, từ khi ứng dụng được phát triển cho đến khi nó được triển khai và vận hành trên môi trường sản xuất. Tất nhiên, chúng ta sẽ dừng chân ở đây khá lâu, và di chuyển tới lui chỗ này rất nhiều lần, nhưng không vì thế mà nơi đây trở nên kém hấp dẫn hơn với du khách thập phương mỗi lần ghé thăm và thay đổi cách trải nghiệm của riêng mình.
Nguồn: Reddit
Nếu bạn đã sẵn sàng thì nào, lên đưòng thôiiii! 🚗
Điểm đến đầu tiên - Phát triển ứng dụng 🛠
Section titled “Điểm đến đầu tiên - Phát triển ứng dụng 🛠”Hãy tưởng tượng bạn đang bắt đầu phát triển một ứng dụng hoàn toàn mới, ví dụ như một mạng xã hội thuần Việt chẳng hạn, thu hút sự ủng hộ và hàng triệu đô la từ hàng chục triệu con người đang chờ đợi ngoài kia (nghe có vẻ xa vời ở hiện tại, vì khá nhiều đơn vị đã thất bại ê chề rồi). 🤣
Nguồn: ContentStudio Blog
Nếu bạn là một kỹ sư phần mềm, việc đầu tiên cần làm là 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 một bản kế hoạch tầm cỡ, những mục tiêu cho tính năng, thiết kế cho ứng dụng. Cuối cùng là tạo ra ứng dụng từ chính những mục tiêu đó.
Nói tới các công cụ có thể dùng được ở quá trình này, không có gì khác ngoài việc phải chọn ra một Môi trường phát triển tích hợp (IDE) và những ngôn ngữ lập trình phù hợp để viết ứng dụng.
Hãy nhớ rằng: Là một kỹ sư DevOps, bạn có thể không phải là người lên kế hoạch cũng như lập trình ứng dụng. Việc này thường sẽ được một kỹ sư phần mềm phụ trách. Tuy nhiên, sẽ là vi diệu nếu bạn có thể đọc được một vài đoạn mã nguồn trong đó và hiểu được cách ứng dụng hoạt động, từ đó đưa ra quyết định tốt nhất cho cơ sở hạ tầng của 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 đáng lưu tâm là mã nguồn của nó nên được quản lý bởi một hệ thống quản lý phiên bản (Version Control System). Chúng ta sẽ ghé thăm Git ở điểm dừng chân tiếp theo trong hành trình “bất ổn” này.
Và dù dự án triệu đô này đi theo lối nào, một mình hay nhóm lại với nhau (nhưng vẫn là tui-work… à nhầm teamwork), phương pháp tốt nhất vẫn là sử dụng một kho lưu trữ (Repository) để giúp các thanh viên có thể cộng tác với nhau khi làm việc với mã nguồn. Kho lưu trữ này có thể được Công khai hoặc lưu Riêng tư. Trong hành trình này, đôi lúc bạn cũng có thể sẽ nghe tôi nói về việc sử dụng GitHub hoặc GitLab làm kho lưu trữ. Chúng ta sẽ nhắc đến tụi kia cũng trong điểm dừng chân tiếp theo về Git.
Điểm đến thứ hai - Kiểm thử và xác thực 🧪
Section titled “Điểm đến thứ hai - Kiểm thử và xác thực 🧪”Ở điểm đến này, chúng ta đã có các mục tiê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ã nguồn ứng dụng cần được kiểm thử ở các môi trường khác nhau hoặc cụ thể hơn là với ngôn ngữ lập trình đã 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 trên các container, mô phỏng môi trường kiểm thử. Điều này giúp giảm thiểu chi phí cho các máy chủ vật lý hoặc cơ sở hạ tầng trên Điện toán đám mây.
Quá trình này tại nhiều doanh nghiệp rất nhiều khả năng là sẽ được tự động hoá như một phần của Tích hợp liên tục - Điểm đến tiếp theo ngay sau đây.
Tự động hoá quá trình kiểm thử sẽ giải phóng hàng chục, hàng trăm, thậm chí hàng nghìn kỹ sư quản lý chất lượng khỏi việc phải thực hiện các bước của quy trình 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 tính năng mới hơn thay vì sa lầy vào việc kiểm lỗi, 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. Bởi nếu theo thác nước truyền thống, kịch bản sẽ như thế này:
Nguồn: Markus Gärtner
Điểm đến thứ ba - Tích hợp 🎚
Section titled “Điểm đến thứ ba - Tích hợp 🎚”Ở giữa vòng đời DevOps là Tích hợp - một phần cực kỳ quan trọng. Đây là một điểm đến các lập trình viên ghé thăm mỗi khi thay đổi mã nguồn một cách thường xuyên hơn, hàng ngày hoặc hàng tuần.
Với mỗi thay đổi diễn ra trên kho lưu trữ, ứng dụng sẽ được kiểm thử tự động, giúp phát hiện sớm các vấn đề phát sinh trước khi đi tới điểm đến tiếp theo.
Khoan đã, chúng tôi không tạo ra ứng dụng, chúng tôi đi mua nó từ một nhà cung cấp phần mềm mà!!!
Gượm đã, rất nhiều doanh nghiệp hiện nay đang làm vậy và sẽ tiếp tục làm vậy. Nhà cung cấp dịch vụ sẽ là người thực hiện hành trình ba điểm đến kia nhưng đôi lúc, chính bạn vẫn muốn ghé qua điểm đến này và đưa nó vào trong ứng dụng của bạn. Việc này cho phép việc triển khai ứng dụng nhanh chóng và hiệu quả hơn.
Nắm rõ các quá trình thực sự rất quan trọng, bởi lẽ có thể bạn sẽ mua các ứng dụng từ bên thứ ba ngày hôm nay, nhưng bạn có chắc sẽ làm điều tương tự vào ngày mai? Hay nếu ngày mai bạn nhảy việc, thì sao? Bạn sẽ làm gì tiếp theo?
Nguồn: 9GAG
Điểm đến thứ tư - Triển khai 🚀
Section titled “Điểm đến thứ tư - Triển khai 🚀”Ghé xong ba điểm đến kia rồi, đến điểm thứ tư: Triển khai thôi!!!
Đây chính là quá trình mà mã nguồn sẽ được triển khai lên các máy chủ của môi trường sản xuất. Đây cũng là những gì chúng ta sẽ đi vào khám phá sâu hơn trong 86 ngày còn lại của hành trình này.
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 việc quản lý cấu hình ứng dụng (Application Configuration Management) và triển khai cơ sở hạ tầng dưới dạng mã nguồn (Infrastructure as Code) phát huy thế mạnh của mình trong vòng đời DevOps. Các ứng dụng có thể được đóng gói và chạy trong các container hoặc chạy trên các máy ảo (VM). Điều này cũng khiến chúng ta cần phải xem xét sử dụng Kubernetes để điều phối các container này và đảm bảo ứng dụng luôn ở trong trạng thái “sẵn sàng chiến đấu” nhằm phục vụ người dùng cuối.
Hãy tưởng tượng khi sử dụng Kubernetes, việc này sẽ xảy ra:
Nguồn: Dev Community
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 cũng như biết được khi nào thì nên sử dụng cái nào trong quá trình phát triển ứng dụng, bởi lẽ nếu mà bạn dùng sai, hậu quả có thể đong đếm bằng rất nhiều dollar!!! 💸
Điểm dừng chân cuối cùng - Vận hành và giám sát 🛡
Section titled “Điểm dừng chân cuối cùng - Vận hành và giám sát 🛡”Mọi thứ đã xong, điểm đến cuối cùng. Câu hỏi được đặt ra: Làm sao người dùng cuối có được trải nghiệm theo đúng những gì họ mong đợi?
Lúc 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ần mềm có thể đưa ra quyết định cải tiến ứng dụng trong các bản phát hành tiếp theo nhằm đem đến những trải nghiệm tốt hơn.
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 cần chú ý. Bởi suy cho cùng, chúng ta muốn ứng dụng của mình luôn sẵn sàng 24/7/365, bất cứ khi nào người dùng cần. Chính vì vậy, các yếu tố như tính tối mật, tính toàn diện, và tính khả dụng (Tam giác CIA) cần được giám sát liên tục để 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 cho phù hợp với điều kiện thực tế.
Có một số ý kiến khác nhau từ cộng đồng như của @_ediri cho rằng, 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 lưu trữ cũng nên được theo dõi liên tục để đảm bảo mọi thay đổi hệ thống 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 tổ chức.
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.
Hãy tưởng tượng, vào một ngày đẹp trời, bạn nhận được một hoá đơn điện toán đám mây như thế này, bạn sẽ có góc nhìn rõ nét hơn từ chính ý kiến trên:
Nguồn: Reddit
Ngày 4: DevOps & Agile
Section titled “Ngày 4: DevOps & Agile”Xin chào mọi người, cuối cùng thì sau một khoảng thời gian khắc phục sự cố liên quan đến thiết bị thì chặng hành trình của chúng ta lại tiếp tục với ngày thứ tư. Lần này chúng ta sẽ ghé thăm một điểm đến hoàn toàn mới, và cùng nhau chiêm nghiệm, so sánh sự khác biệt giữa hai trường phái khác nhau: DevOps và Agile. Thế rốt cuộc thì Agile nó khác DevOps chỗ nào, mà tại sao mình lại phải đi tham quan nó chứ? Phải chăng có một điều bí ẩn nào đang chờ đón mọi người?
Nguồn: Linkedin
Nếu sự tò mò này đã lên đến đỉnh điểm, vậy thì sẵn sàng lên đường thôi! 🚙
Ấn tượng ban đầu 🛤
Section titled “Ấn tượng ban đầu 🛤”
Nguồn: 9GAG
- Agile (hay Phương pháp Agile): Cách tiếp cận tập trung vào việc cung cấp các tính năng nhỏ và nhanh hơn thay vì phát hành một bản vá lớn của ứng dụng. Phần mềm được phát triển trong nhiều giai đoạn (iteration), các phiên bản mới sẽ được ra mắt 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: 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 chặt chẽ 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 giữa các bộ phận.
Phi thường làm nên khác biệt 🏕
Section titled “Phi thường làm nên khác biệt 🏕”
Nguồn: Oracle Base
Để nói đến sự khác biệt giữa hai trường phái này, có lẽ sẽ là đối tượng mà hai nơi này hướng đến. Tuy vậy, giữa hai nơi này có một mối liên kết mà chỉ có khi kết hợp lại với nhau mới làm nên thành công cho một dự án du lịch hoàn hảo. Trong giới hạn của phần hai này, xin phép nêu ra những điểm khác nhau trước nhất giữa cả hai.
”Kênh quốc gia” và “Kênh khu vực” 📺
Section titled “”Kênh quốc gia” và “Kênh khu vực” 📺”Thuật ngữ này được sử dụng trong phát thanh/truyền hình để nói đến một hệ thống gồm các kênh không chia theo vùng (VTV1, VTV2, VTV3) và kênh chuyên phục vụ theo vùng (VTV8, VTV9, VTV Cần Thơ). Nếu áp dụng cùng một hệ quy chiếu như truyền hình thì Agile thuộc nhóm Quốc gia (vì phục vụ trực tiếp từ nhóm phát triển đến khách hàng), trong khi đó DevOps lại thuộc nhóm Khu vực điển hình (phục vụ giữa nhóm phát triển và nhóm vận hành).
Bộ phận công tác 🏢
Section titled “Bộ phận công tác 🏢”Agile tập trung vào nhánh trái của Vòng lặp DevOps (tức nhóm phát triển, quản lý dự án). Trong khi đó, DevOps lại đứng ở giữa vòng lặp, vì gần như tất cả mọi giai đoạn của dự án đều có DevOps tham gia cùng. DevOps có thể được xem là một phần của nhóm Agile.
Bộ khung làm việc 📃
Section titled “Bộ khung làm việc 📃”Agile có nhiều bộ khung khác nhau để đạt sự linh hoạt và minh bạch, với một đường đi được vạch sẵn như hình dưới.
Nguồn: IWConnect
DevOps lại không có bất kỳ bộ khung nào cho quá trình phát triển. Cơ sở hạ tầng dưới dạng mã nguồn (IaC), giám sát và tự khắc phục lỗi, tự động hóa kiểm thử ứng dụng chỉ là các phương pháp chứ không được gọi là bộ khung, và các phương pháp này hỗ trợ cộng tác trong việc phát triển phần mềm.
Nhận xét và phản hồi ✅
Section titled “Nhận xét và phản hồi ✅”Với Agile, các thành viên sẽ nhận phản hồi trực tiếp từ phía khách hàng. Trong khi đó, DevOps tập trung nhận phản hồi của các nơi khác liên quan hoặc nhóm có ưu tiên cao hơn.
Phạm vi công việc 📖
Section titled “Phạm vi công việc 📖”Agile tập trung chủ yếu vào nhánh trái của Vòng lặp DevOps, đồng nghĩa với việc phạm vi công việc sẽ chỉ xoay quanh phát triển ứng dụng là chủ yếu. DevOps, tuy cũng tập trung phát triển ứng dụng, nhưng nơi này lại có thêm những hoạt động khác như triển khai, giám sát, bảo trì, bảo mật dữ liệu và khắc phục sự cố để đảm bảo tính khả dụng cao cho ứng dụng.
”Kịch bản phát sóng” 📓
Section titled “”Kịch bản phát sóng” 📓”“Kịch bản phát sóng” đối với DevOps là một trong những thành phần cực kỳ quan trọng. Ngược lại, Agile lại coi kịch bản này chỉ là một bộ khung để biến tấu sao cho phù hợp với các mục tiêu và giai đoạn khác nhau. Điều này khá giống với hình ảnh đối lập của một đạo diễn và một biên kịch - một người muốn mọi thứ phải theo đúng tiến trình của chương trình, còn một người lại chủ trương sáng tạo nội dung dựa trên kịch bản để giúp chương trình trở nên đáng theo dõi hơn.
Nguồn: Reddit
Rủi ro đi kèm ⚠
Section titled “Rủi ro đi kèm ⚠”Chính sự biến tấu của Agile lại biến thành rủi ro, với sự thay đổi liên tục về thứ tự ưu tiên cho từng đầu việc khiến các thành viên rất khó xác định mức độ an toàn của việc thay đổi.
Trong khi đó, nếu DevOps bị “phế võ công” hoặc “dùng sai chiêu thức”, rất có thể nhiều dự án sẽ bị bỏ hoang do không có tính thay đổi để thích nghi với điều kiện mới. Điều này xuất phát từ sự ngộ nhận không cần thiết liên quan đến việc coi DevOps là tập hợp phần mềm để triển khai vận hành liên tục.
”Công cụ truyền dẫn” 🖥
Section titled “”Công cụ truyền dẫn” 🖥”Agile tập trung nhiều ở nhánh trái Vòng lặp, có nghĩa các công cụ quản lý, phản hồi có dạng vé (ticket) sẽ được ưu tiên hơn như Jira, Trello, Zoom, SurveyMonkey,…
DevOps lại có những bộ công cụ khác để giao tiếp và phát triển phần mềm như Bitbucket, Jenkins, Github Actions, … Dù có sự khác biệt nhưng cả hai nơi vẫn có những điểm chung mà có thể cộng tác với nhau và cho ra một hành trình tuyệt vời.
Combo hoàn hảo cho một ngày diệu kỳ 🗃
Section titled “Combo hoàn hảo cho một ngày diệu kỳ 🗃”
Nguồn: Netsmartz
Kết hợp Agile và DevOps trong một chuyến hành trình duy nhất sẽ mang lại những lợi ích to lớn như:
- Lộ trình được quản lý linh hoạt với các công cụ mạnh mẽ.
- Phương pháp Agile giúp các nhóm DevOps giao tiếp, trao đổi về các nhiệm vụ ưu tiên một cách hiệu quả hơn.
- Tối ưu chi phí phát sinh từ quá trình tự động hóa, giúp hành trình trở nên nhanh chóng hơn và tăng tỷ lệ “tái thực hiện chuyến đi” hơn.
- Quá trình giao tiếp, hợp tác của các thành viên trong nhóm Agile trở nên tốt hơn, tăng động lực cho nhóm và giúp giảm tỷ lệ “trốn về nước”.
- Kết quả là sản phẩm ra mắt người dùng cuối có chất lượng và trải nghiệm 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 việc mắc quá nhiều sai sót kỹ thuật (technical debt). Để ghé thăm Agile và DevOps cùng lúc, chúng ta cần lên trước một bản kế hoạch như sau:
- Tích hợp các nhóm phát triển và vận hành lại thành một nhóm, tức là “Non sông liền một dải”. Đây là cách người ta gọi là “yêu nước trong từng hành động nhỏ nhất” 💖
- Các thành viên trong nhóm chung cần có tinh thần kiến tạo, xây dựng, sẵn sàng thảo luận và cùng đồng hành trong tất cả các vấn đề liên quan tới phát triển cũng như vận hành sản phẩm.
- Thay đổi cách tiếp cận với các điểm dọc đường (sprints), đánh giá các nhiệm vụ DevOps với mức độ ưu tiên tương đương với các nhiệm vụ phát triển phần mềm.
- Nhóm Kiểm định chất lượng cần có mặt trong tất cả các quy trình phát triển.
- Lựa chọn các công cụ công tác phù hợp, tránh tình trạng “lấy râu ông này, cắm cằm bà kia”
- Tự động hoá mọi thứ có thể. Hãy thù ghét những ai thích làm bằng tay không vì lí do gì cả 🤣
- Đo lường và kiểm soát các bản cập nhật mới bằng những cách làm dễ hiểu và đạt sự thống nhất giữa các thành viên.
Đây là những gì mà các kỹ sư cần phải làm. Còn bạn, bạn nghĩ sao về “Kế hoạch 7 bước” này? Hãy chia sẻ cùng mình nhé.
Ngày 5: Vòng lặp DevOps ♾
Section titled “Ngày 5: Vòng lặp DevOps ♾”Xin chào mọi người, cuối cùng chúng ta đến chặng 5 - chặng áp chót của Giai đoạn 1 hành trình 90 ngày cùng DevOps đầy “bất ổn” nhưng cũng nhiều niềm vui này. Ngay bây giờ chúng ta sẽ đến ngay với chiếc vòng lặp DevOps mà mình đã chia sẻ với mọi người ở phần đầu của hành trình này.
Bài này sẽ ít tấu hài hơn, vì đơn giản đây là lúc mà chúng ta cần những thứ chuyên sâu hơn. Nào, bắt đầu thôi!
Các giai đoạn trong vòng lặp
Section titled “Các giai đoạn trong vòng lặp”Trước đó chúng ta có Kế hoạch 7 bước cho việc tích hợp Agile và DevOps với nhau. Thực chất DevOps có tới 8 giai đoạn chính.
Plan - Lên kế hoạch 📑
Section titled “Plan - Lên kế hoạch 📑”Làm gì cũng vậy, một bản kế hoạch chỉnh chu luôn là thứ cần thiết nhất cho một dự án triệu đô. Đâ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 cũng như bản sửa lỗi mà họ muốn có trong chặng tiếp theo.
Đây cũng là lúc mà các kỹ sư DevOps cũng sẽ tham gia 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 quan trọng của nhóm phát triển, giúp họ có thể làm việc tốt với cơ sở hạ tầng mà bạn đã xây dựng hoặc hướng đến một lựa chọn tối ưu hơn nếu nhóm đang không lựa chọn phương án tốt nhất.
Một điều nên nhớ là nhóm phát triển phần mềm giờ đây đang được xem là khách hàng của nhóm DevOps, vì thế đây chính là cơ hội tuyệt vời để cùng nhau tìm ra giải pháp phù hợp với tất cả mọi người trước khi mọi thứ “chệch khỏi đường ray” và khiến dự án bị “vỡ tổ ong”.
Nguồn: Reddit
Code - Lập trình 👨💻
Section titled “Code - Lập trình 👨💻”Ở giai đoạn này, các kỹ sư DevOps sẽ không trực tiếp tham gia (như đã từng đề cập ở chặng 4); thay vào đó, họ sẽ đưa ra các ý kiến đóng góp để hỗ trợ các lập trình viên có được cái nhìn tổng quan nhất về cơ sở hạ tầng của ứng dụng, cũng như các dịch vụ sẽ cung cấp cho người dùng đầu cuối và cách sử dụng sao cho hợp lý.
Nguồn: QuoteFancy
Build - Xây dựng 🏗
Section titled “Build - Xây dựng 🏗”Đến lúc DevOps ra tay, chúng ta sẽ sử dụng mã nguồn đã có sẵn và xây dựng ứng dụng. Tuỳ thuộc vào ngôn ngữ nhóm phát triển sử dụng mà chúng ta có thể sẽ chuyển mã, biên dịch hoặc thậm chí là xây dựng một mẫu Docker (image) từ mã nguồn. Dù như thế nào đi nữa, chúng ta vẫn sẽ sử dụng các CI/CD pipeline (quy trình) cho giai đoạn này.
Nguồn: Docker
Test - Kiểm thử ✅
Section titled “Test - Kiểm thử ✅”Sau khi dựng xong ứng dụng, việc tiếp theo cần làm trước khi phát hành phiên bản mới của ứng dụng là chuyển sang giai đoạn kiểm thử. Các tình huống kiểm thử (test case) sẽ được nhóm Kiểm định hoặc nhóm Phát triển lập trình trước, tuy nhiên chúng ta có thể góp ý sao cho phù hợp.
Một tình huống thực tế được đưa ra, đó là việc ứng dụng không bao quát được tất cả tình huống lỗi có thể xảy ra trong quá trình người dùng cuối sử dụng sản phẩm, thường gọi là giới hạn biên (Edge). Thực ra đây là một trường hợp bình thường, bởi lẽ, mục đích chính của việc này nhằm giúp giảm lỗi và đảm bảo hai điều:
- Không có lỗi mới phát sinh trong quá trình vận hành phiên bản mới.
- Phiên bản mới không tác động đến các tính năng đang vận hành bình thường.
Nguồn: Reddit
Release - Phát hành 📱
Section titled “Release - Phát hành 📱”Đến lúc phát hành ứng dụng rồi.
Quá trình này không phụ thuộc vào mã nguồn hay phương thức dựng ứng dụ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ã nguồn đã biên dịch dưới dạng tập tin .exe 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.
Deploy - Triển khai ⚡
Section titled “Deploy - Triển khai ⚡”Cuối cùng, chúng ta triển khai ứng dụng 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, công sức và sự tận tuỵ mà Nhóm DevOps và Nhóm phát triển đã đưa vào sản phẩm.
Nguồn: Jason St-Cyr
Operate - Vận hành 📬
Section titled “Operate - Vận hành 📬”Đây là giai đoạn mà DevOps bận bịu nhất đây: Nhận phản hồi từ khách hàng, đi tìm nguyên nhân, xây dựng hệ thống điều tiết và cân bằng tải cho hệ thống theo các khung giờ nhất định trong ngày. Ngoài ra, còn có một việc nữa mà giai đoạn này cần quan tâm, đó chính là xây hệ thống cảnh báo (bằng tay hoặc tự động) các sự kiện liên quan từ môi trường chính đến nhóm Vận hành, và các doanh nghiệp thường được khuyến khích sẽ thực hiện tự động hóa để giảm chi phí và tăng hiệu quả.
Nguồn: Jira
Monitor - Giám sát 📶
Section titled “Monitor - Giám sát 📶”Đây là giai đoạn cuối cùng của một chu trình. Các chỉ số như tỷ lệ % sử dụng CPU, RAM, ổ đĩa, thời gian phản hồi và đặc biệt là nhật trình (logs), là những thứ vũ khí quan trọng nhất giúp các thành viên của nhóm Phát triển biết được thực sự điều gì đang diễn ra và khắc phục sự cố, mở rộng quy mô hệ thống tự động hoặc khi cần thiết.
Nguồn: Netdata
Vòng lặp tiếp diễn
Section titled “Vòng lặp tiếp diễn”Chu trình hoàn thành, chúng ta sẽ 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ộ vòng lặp này hằng ngày/tuần/tháng cho những bản phát hành/cập nhật tiếp theo.
Nguồn: Jason St-Cyr
Tự động hóa - Liên tục
Section titled “Tự động hóa - Liên tục”
Nguồn: LinearB
Với các dự án lớn, đòi hỏi cần phải tự động hóa để tối ưu được nguồn lực cho quy trình phát triển phần mềm. Việc sử dụng các công cụ cho công cuộc tự động hóa này được gọi là “Tích hợp và Triển khai liên tục” (CI/CD). Chúng ta sẽ ghé qua điểm đến này ở những giai đoạn tiếp theo của hành trình 90 ngày này. Dưới đây là giới thiệu sơ lược của các quá trình.
Phân phối liên tục
Section titled “Phân phối liên tục”Phần này bao gồm các giai đoạn từ 1 tới 4 của Vòng lặp.
- Lập kế hoạch (Plan)
- Lập trình (Code)
- Xây dựng (Build)
- Kiểm thử (Test)
Tích hợp liên tục (CI)
Section titled “Tích hợp liên tục (CI)”Phần Tích hợp liên tục (Continuous Integration) bao gồm Phân phối liên tục và Giai đoạn 5 của Vòng lặp là Phát hành. Nếu thất bại ở giai đoạn 5 thì phải quay lui về giai đoạn 1, nếu thành công sẽ chuyển sang Triển khai liên tục (gồm các giai đoạn tiếp theo từ 6 đến 9).
- Phát hành liên tục (CI)
- Phát hành (Release)
- Triển khai liên tục (CD)
Triển khai liên tục (CD)
Section titled “Triển khai liên tục (CD)”Sau khi thành công ở giai đoạn 5, ứng với mỗi bản phát hành, chúng ta đi tiếp tới các giai đoạn từ 6 - 9. Chùm giai đoạn này được gọi là Triển khai liên tục (Continuous Delivery/Deployment). Cụ thể:
- Triển khai (Deploy)
- Vận hành (Operate)
- Giám sát (Monitor)
Ngày 6: DevOps ngoài đời thực 🏘
Section titled “Ngày 6: DevOps ngoài đời thực 🏘”Xin chào mọi người. Cuối cùng thì chúng ta đã đến với ngày cuối cùng của giai đoạn 1 rồi. Chúng ta đã tìm hiểu rất nhiều, gần như tất tần tật mọi thứ về DevOps, cũng như những khó khăn mà một người làm DevOps gặp phải. Ngày hôm nay, chúng ta sẽ đi ra thế giới một chút, lắng nghe những câu chuyện có thật về cách các doanh nghiệp lớn áp dụng thành công DevOps vào quá trình vận hành và phát triển, giúp tăng tốc độ và cải thiện chất lượng cho sản phẩm.
Nào, hãy sẵn sàng để khởi động chuyến hành trình này thôi! ⛵
Đi chợ “trời” thôi - Chuyện từ Amazon 🛍
Section titled “Đi chợ “trời” thôi - Chuyện từ Amazon 🛍”Chúng ta sẽ quay lại năm 2010 - Thời điểm mà Amazon - một tập đoàn đa ngành lớn của Hoa Kỳ quyết định chuyển toàn bộ hệ thống từ máy chủ truyền thống sang máy chủ ảo chạy trên AWS - một dịch vụ khác do hãng tự sản xuất. Việc chuyển đổi này giúp tập đoàn tiết kiệm rất nhiều tài nguyên bằng cách điều chỉnh hạn ngạch máy ảo theo nhiều giai đoạn nhỏ khác nhau. Kết quả của việc này là biến AWS - Amazon Web Services trở thành “gà đẻ trứng vàng” cho Amazon.
Một năm sau, vào năm 2011, Amazon tiến hành áp dụng CI/CD (xem lại ngày 5 để hiểu thuật ngữ này) cho phép nhóm Phát triển phần mềm có thể đưa mã nguồn ứng dụng vào vận hành bất kỳ lúc nào, trong thời gian siêu ngắn mà theo như ghi nhận trong một video (sẽ được chia sẻ ở mục Tài liệu tham khảo), trung bình chỉ có 11.6 giây (11.6 giây là chưa đến 20% của một phút).
Dưới đây là một mô hình mẫu, sử dụng AWS được mình dựng trong quá trình thực hiện Khóa luận tốt nghiệp vào năm 2023.
Mua hàng xong rồi - Về mở Netflix và … xem nhé 💽
Section titled “Mua hàng xong rồi - Về mở Netflix và … xem nhé 💽”Tại sao là Netflix và xem, chứ không phải thuật ngữ gốc? Bởi vì thuật ngữ gốc chỉ những người yêu nhau mới hiểu (nó mang yếu tố 18+, mà đây là chiến dịch về công nghệ nên nó không phù hợp để đăng ở chỗ này) 🤣
Okay, mặc dù Netflix liên tục dính tai tiếng ở Việt Nam vì vấn đề bản quyền và nội dung chưa phù hợp, dưới góc độ công nghệ, đây vẫn là một trường hợp rất thành công khi áp dụng DevOps.
Trải nghiệm theo dõi trên Netflix là một thứ trải nghiệm mà người dùng rất ưa chuộng: Tốc độ cao, chất lượng 4K, không giật màn hình và các tính năng được truy cập đơn giản.
Nhóm Phát triển tại Netflix đã tự động xây dựng mã nguồn thành các bản dựng có thể triển khai trực tiếp, tích hợp trở lại vào cơ sở hạ tầng của Netflix bằng các nền tảng web có thể tùy biến thông minh.
Nguồn: GeeksForGeeks
Quá trình giám sát liên tục (Monitor) cũng được triển khai xuyên suốt nhằm đảm bảo việc định tuyến chính xác trong trường hợp thất bại ở việc triển khai phiên bản mới của ứng dụng. Để nắm rõ hơn, mình có cung cấp một video trong phần Tài liệu tham khảo để mọi người có thể theo dõi và tham khảo thêm.
Câu chuyện thứ ba - Việt Nam ở đâu?
Section titled “Câu chuyện thứ ba - Việt Nam ở đâu?”Thật sự mà nói, ở Việt Nam mà áp dụng DevOps thì cũng có đó, nhưng mà để có một cái câu chuyện chuyên sâu để kể cho mọi người là rất khó, bởi đơn giản, không phải tự nhiên mà vị trí DevOps ở Việt Nam lại liên quan nhiều đến yếu tố “đa nhiệm” và “chi phí” đến như vậy - Nếu một cá nhân nào đó làm DevOps ở Việt Nam, họ gần như cần phải biết mọi thứ, đó là còn chưa kể việc tuyển một kỹ sư DevOps giỏi ở nhiều công ty đồng nghĩa với việc sa thải hàng loạt lập trình viên khác. Thường cái gì ảnh hưởng đến “chén cơm” người ta thì sẽ ngại chia sẻ hơn rất rất nhiều.
Nhưng mà cũng may, vẫn còn được 1 bài báo nói về DevOps ở FPT Software, trong mục Tài liệu tham khảo để gửi đến mọi người đọc qua. Bên cạnh đó là rất nhiều câu chuyện thành công khác ở đó, mời quý vị theo dõi.
Tóm tắt giai đoạn 1
Section titled “Tóm tắt giai đoạn 1”- DevOps là sự kết hợp giữa Phát triển (Development) và Vận hành (Operations) 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.
- 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 mật thiết tới các 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.
Hẹn gặp mọi người ở những ngày tiếp theo, nơi mà chúng ta sẽ bắt đầu giai đoạn 2 của chuyến hành trình, với việc học một ngôn ngữ lập trình hoàn toàn mới. 🚀
Tài liệu tham khảo 📚
Section titled “Tài liệu tham khảo 📚”Mời mọi người chuyển sang trang này để theo dõi tất cả tài liệu liên quan đến DevOps trong giai đoạn đầu tiên, để giúp bản thân có được những kiến thức cơ bản nhất về DevOps. Hẹn gặp mọi người ở những ngày tiếp theo! 🚀
Giai đoạn 1 - Tham khảo