Về bản chất, DevOps nhấn mạnh vào mối quan hệ cộng tác giữa team phát triển (development) và team IT vận hành (IT operations). Nhưng thường thì từ khóa DevOps và rất nhiều những nguyên lý cốt yếu xung quanh có thể bị hiểu lầm.
Top 5 sự thật về DevOps
Sự thật 1: Khát khao liên tục phát triển
DevOps team nên tập trung vào yếu tố liên tục thử nghiệm và cải tiến.
Trong suốt vòng đời chuyển giao sản phẩm (SDLC), sẽ có rất nhiều chỗ có thể cải tiến.
Các software developers, QA engineers, IT professionals, operation support team đều cần phải đóng góp vào các cải tiến này. Từ việc lập kế hoạch đến khi triển khai, gồm cả khâu bảo trì, bảo dưỡng, không có lý nào lại không có chỗ cần cải tiến.
Cả quá trình CI/CD (continuous integration/continuous delivery) và quản trị sự cố sẽ trở nên dễ dàng hơn nếu bạn liên tục chạy vòng lặp và cải tiến quy trình, công cụ và workflow.
Để có được sự liên tục cải tiến, mọi người trong team cần phải cởi mở, ham học hỏi các ngôn ngữ mới, thử các kỹ thuật QA khác nhau hoặc sẵn sàng thay đổi cấu trúc team.
Sự thật 2: Cộng tác tốt hơn và thường xuyên hơn
Cộng tác là một thành tố trọng tâm trong DevOps.
Cộng tác chặt chẽ trong bất cứ mảng nào, kể cả việc bảo trì CI/CD pipeline, hay liên quan đến việc tăng tốc phản hồi vá lỗi và sửa chữa các sự cố.
Các team liên chức năng (cross-functional) cần có sự giao tiếp trong, trước và sau khi một tính năng được phát hành hoặc khi một sự cố xảy ra. Một DevOps team tốt sẽ cải tiến quá trình cộng tác của mình qua các công cụ ChatOps, các báo cáo review sau sự cố hay một công cụ nhìn trực quan trong việc kiểm soát, cảnh báo, và đưa ra các thông tin chuyển giao phần mềm.
Sự thật 3: DevOps cần có sự đồng thuận và ủng hộ của cả tổ chức
Để triển khai DevOps hiệu quả tại công ty của bạn, bạn cần có sự đồng thuận và ủng hộ từ phía lãnh đạo. DevOps thường triển khai chỉ ở bộ phận developers và IT operations, nhưng nhiều nguyên lý về DevOps có thể áp dụng liên đới sang bộ phận sales, marketing, bộ phận operations support.
Khi các team đều tuân theo các nguyên lý của DevOps, và bạn có được sự ủng hộ từ phía ban lãnh đạo, các team liên chức năng có thể cộng tác tốt hơn để chuyển giao giá trị liên tục tới khách hàng.
Sự thật 4: Tự động hóa
Bất cứ những thứ tự động hóa từ cảnh báo cho đến tự động hóa quá trình chuyển giao phần mềm cần mang lại sự hiệu quả và giúp quy trình làm việc giữa người-người dễ dàng và thuận tiện hơn. Tự động hóa có thể áp dụng ở gần như bất cứ khâu nào trong vòng đời phát triển phần mềm (SDLC).
Chìa khóa để việc tự động hóa hiệu quả hơn là tìm ra những nỗi đau trong việc quản lý sự cố (incident management) hoặc quá trình chuyển giao phần mềm và bắt đầu tự động hóa những chỗ bạn có thể làm.
Khi bạn đã định nghĩa được vòng đời phát triển phần mềm hoặc các nỗi đau khi quản lý sự cố, bạn có thể tập trung tự động hóa khâu deployments, alert payloads, alert routing, on-call rotations…. Nhưng đến cuối cùng, việc tự động hóa cần phải đáng tin cậy và cải tiến được chất lượng cuộc sống của những người cùng làm việc với bạn và cả khách hàng.
Sự thật 5: Trách nhiệm, Sở hữu và minh bạch
Trước khi khái niệm DevOps được truyền bá rộng rãi, nhiều team đã thực hiện việc này bằng cách chuyển các task, từ bộ phận này sang bộ phận kia trong cả chu trình phát triển phần mềm. Có nghĩa là từ Product Managers, Front-end Developers, Platform Engineers, IT professionals, QA engineers,... làm việc một cách riêng rẽ ở từng task của họ trong suốt vòng đời phát triển phần mềm, và có rất ít hiểu biết về những thứ khác ngoài cái họ làm.
Một DevOps team thì cần có sự tham gia của tất cả những người cần thiết trong 1 project, kể từ khi lập kế hoạch đến khi triển khai (deployment). Việc này tạo ra sự minh bạch trong từng bước của vòng đời phát triển phần mềm. Khi bạn làm việc trong một team DevOps đủ nhỏ, và cộng tác chặt chẽ với nhau, tất cả mọi người đều nắm quyền chủ động và ownership cho code mà họ viết. Khi làm việc liên chức năng, các kỹ sư có thể nhìn ra code của họ ráp vào cả hệ thống như nào là phù hợp. Sau đó, các kỹ sư có thể được trao trách nhiệm để bảo trì phần code mà họ viết, như vậy họ sẽ càng tập trung vào tính độ ổn định của toàn thể services mà họ build.
DevOps team nhận lấy trách nhiệm cả ở mặt phát triển và bảo trì của hệ thống sẽ có cái nhìn sâu hơn về hệ thống và tạo nên bất cứ thứ gì dựa trên sự tin cậy lẫn nhau.
Top 5 hiểu nhầm về DevOps
Hiểu nhầm 1. DevOps là triển khai một quy trình hay công cụ nào đó.
Cần hiểu rõ DevOps không phải công cụ, cũng không phải một quy trình. DevOps là một văn hóa ở đó mọi người tin rằng sự cộng tác, liên tục thử nghiệm và cải tiến sẽ mang lại sự thành công.
Không có một công cụ hay quy trình có thể khiến team bạn trở thành 1 DevOps team.
Mọi team đều cấu trúc khác nhau, không có một cách tiếp cận trong việc build sản phẩm ổn định cho tất cả mọi loại team.
Một người hiểu và thực hành được các giá trị của DevOps mới chính là yếu tố tạo nên một thứ văn hóa DevOps.
Hiểu nhầm 2. Tất cả đều cần trở thành 1 System Admin và Developer
Đây là 1 ý nghĩ sai lệch về DevOps, rằng một người trong team cần phải vừa là developer vừa là system admin.
Thực tế không phải người nào cũng có thể làm mọi việc. Ý tưởng rằng tất cả đều có thể code và biết về rack servers là không chính xác, đặc biệt trong kỷ nguyên phát triển các ứng dụng trên cloud.
Nhưng một team như một thể thống nhất cần có kinh nghiệm của cả developer và system admin. Ngay cả khi team bạn đang chạy các ứng dụng trên cloud, có kỹ năng của System admin có thể giúp bạn xử lý các vấn đề liên quan đến các nền tảng AWS hay GCP.
Đa dạng các chuyên môn trong một team DevOps có thể giúp bạn thiết lập các công cụ monitoring, các backups, runbooks, và các chính sách bảo mật được tốt hơn. Khi ở trong cùng một team DevOps với nhau, các Sysadmin có thể dễ dàng cộng tác với developers để phát hiện các vấn đề tiềm ẩn trong code hoặc trong cơ sở hạ tầng.
Dần dần, mọi người trong team đều có thể học hỏi lẫn nhau và thêm hiểu biết về việc viết code, đồng thời bảo trì hệ thống. Với sự đa dạng các bộ kỹ năng cùng phối hợp với nhau trong 1 team DevOps, việc quản lý các sự cố và chuyển giao phần mềm sẽ nhanh hơn và góp phần vào một CI/CD pipeline ổn định và đáng tin cậy hơn.
Hiểu nhầm 3: DevOps là một vị trí cụ thể
Một vài công ty có chức danh cho các kỹ sư CNTT là DevOps Engineer.
Nhưng khi nói đến từ khóa DevOps, ta không nên hiểu nó chỉ là 1 vị trí cụ thể. Tương tự như ý ở trên, bạn không thể đòi hỏi một người phải có chuyên môn ở mọi khâu của vòng đời phát triển phần mềm.
Developers và các kỹ sư CNTT trong 1 Team DevOps cần có những kỹ năng rộng ở nhiều mảng và đồng thời có chuyên môn sâu ở 1 vài mảng nhất định. Như vậy, với một team nhỏ, mọi người có thể hỗ trợ, bọc lót cho nhau, để cùng tạo nên một văn hóa tin cậy lẫn nhau, và cùng cộng tác trong vòng đời phát triển phần mềm.
Hiểu nhầm 4: DevOps chỉ dành cho các công ty quy mô nhỏ.
Một hiểu nhầm thường thấy khi mọi người thường nghĩ rằng DevOps khó để triển khai và áp dụng ở các công ty, tổ chức quy mô lớn.
Nhưng thực tế các công ty lớn hay nhỏ đều có thể tìm ra những cách sáng tạo và độc đáo để ứng dụng DevOps vào đội nhóm.
Tuy mỗi công ty có tốc độ phát triển khác nhau và cấu trúc tổ chức phòng ban cũng sẽ thay đổi theo thời gian. Việc cần làm là phát hiện các điểm yếu, các lỗ hổng trong quy trình làm việc, để tìm ra cách ứng dụng DevOps vào trong team của bạn ra sao.
Các thành tố của văn hóa DevOps
Hiểu nhầm 5: Chỉ có 1 quy trình cụ thể cho DevOps
Như đã nói ở trên, không có 1 thứ gì áp dụng cho tất cả (one-size-fits-all). DevOps cũng vậy. Có rất nhiều yếu tố khi triển khai các công cụ, khi xây dựng đội nhóm, khi thiết lập các quy trình, mà bạn không thể áp đặt chỉ một cách thức duy nhất để triển khai chúng.
Bất cứ quy trình nào bạn muốn thiết lập và mang vào đội nhóm để tạo lập văn hóa DevOps, hãy đảm bảo rằng các quy trình này tập trung vào yếu tố cải tiến liên tục, cộng tác, trách nhiệm và tự động hóa.
Theo insights.magetstore.com
Japan IT Works
