DevOps là gì? P/v DevOps Engineer Giao Hàng Nhanh

devops-la-gi-tantm

DevOps là một văn hóa làm việc, hướng đến việc kéo hai giai đoạn “phát triển” (development) và “vận hành” (operations) xích lại gần nhau hơn. Nhờ vậy, chu trình phát triển phần mềm được tối ưu hóa, nhanh và liên tục hơn.

Đọc bài phỏng vấn của ITviec Blog với anh Trần Minh Tấn, Lead Engineer kiêm DevOps Engineer tại Giao Hàng Nhanh, để biết:

  • DevOps là gì? Lợi ích của DevOps là gì?
  • Những tố chất và kĩ năng quan trọng nhất đối với người làm DevOps là gì?
  • Tài liệu tham khảo cho DevOps Engineer.

Xem việc làm DevOps tại ITviec

Tiểu sử: Anh Trần Minh Tấn tốt nghiệp Thạc sĩ chuyên ngành Khoa học Máy tính, Đại học Kĩ thuật Công nghệ TPHCM (Hutech) năm 2015. Anh bắt đầu sự nghiệp với vị trí Senior Software Engineer tại Tappy, sau đó là Chợ Tốt.

Hiện, anh Tấn đảm nhiệm vị trí Lead Engineer kiêm DevOps Engineer tại Giao Hàng Nhanh.

DevOps là gì? Anh có thể định nghĩa ngắn gọn?

DevOps là một văn hóa làm việc đề cao sự hợp tác, hướng đến việc kéo hai giai đoạn phát triểnvận hành xích lại gần nhau hơn.

Cụ thể:

Chu trình phát triển phần mềm (Software Development Life Cycle, viết tắt: SDLC) bao gồm hai giai đoạn chính: phát triển và vận hành.

Giai đoạn phát triển (development) bao gồm phần việc của designer, developer, QA QC…

Giai đoạn vận hành (operations) có sự tham gia của system engineer, system administrator, operation executive, release engineer, DBA, network engineer, security engineer…

Hai giai đoạn này tương đối tách rời nhau, đặc biệt là ở các công ty có quy mô trung bình trở lên.

Vì vậy, khái niệm DevOps ra đời nhằm tối ưu hóa chu trình phát triển phần mềm, giúp sản phẩm IT được release nhanh và thường xuyên hơn.

devops-la-gi-devops-process

DevOps = Development (phát triển tính năng sản phẩm) + Operations (vận hành)

Việc làm DevOps TPHCM

Việc làm DevOps Hà Nội

Như vậy, DevOps là một nhánh nghề nghiệp mới?

Theo Tấn, DevOps không phải là một nhánh nghề nghiệp mới. Nói đúng hơn, DevOps là tên gọi mới, là sự kế thừa và phát triển của một quan niệm về phát triển phần mềm đã tồn tại từ khá lâu.

Để cho dễ hình dung, và cũng để trả lời rõ hơn cho câu hỏi “DevOps là gì”, ta cần ngược trở lại lịch sử ngành phần mềm một chút.

Ở buổi ban sơ của kỉ nguyên máy tính, quy trình phát triển phần mềm không hề có sự phân tách rạch ròi giữa hai giai đoạn phát triển (development) và vận hành (operations). Anh kĩ sư đảm nhiệm việc develop, đồng thời cũng kiêm luôn việc test, deploy sản phẩm.

Và điều này cho đến nay vẫn đúng đối với các sản phẩm vừa và nhỏ. Lí do đơn giản: dev là người phát triển sản phẩm, nên anh ta cũng hiểu rõ về sản phẩm để chọn cách vận hành phù hợp nhất.

Sau đó, sự bùng nổ về quy mô của các công ty và sản phẩm công nghệ kéo theo quy mô hệ thống phình ra theo cấp số nhân. Từ một vài server, hệ thống có thể phát triển lên đến hàng chục, hàng trăm, hàng nghìn, hoặc thậm chí hàng triệu server (ví dụ như trường hợp của Google, Facebook).

Yêu cầu chuyên môn hóa trở nên gắt gao, khiến quy trình phát triển phần mềm chia tách thành những giai đoạn riêng biệt. Đây là giai đoạn mà dev và ops tách bạch.

Tuy nhiên, khoảng một thập kỉ trở lại đây, trước nhu cầu phát triển và cải tiến sản phẩm liên tục để đáp ứng thị trường, sự chia tách này lại bộc lộ những nhược điểm rõ rệt. Ngoài ra, ngành phát triển phần mềm cũng dịch chuyển theo một hướng khác – microservices.

Microservices: một sản phẩm lớn được chia tách làm rất nhiều service nhỏ, các service này liên kết với nhau tạo thành một sản phẩm hoàn chỉnh.

Ví dụ, đối với người dùng, một trang web thương mại điện tử là một sản phẩm hoàn chỉnh. Nhưng trên thực tế, trang web này được gộp lại từ rất nhiều feature như đăng kí, đăng nhập, tìm kiếm.v.v… Mỗi feature này là một service riêng, có thể sử dụng ngôn ngữ lập trình và database riêng.

Những bài toán mới được đặt ra:

  • Về mặt quy trình, làm thế nào để các bộ phận hợp tác trơn tru thuận lợi hơn?
  • Về mặt sản phẩm, làm thế nào để các service kết nối và giao tiếp với nhau theo rules hiệu quả, cũng như đảm bảo việc scaling được “êm ái”?

Sự có mặt của DevOps là để giải quyết những vấn đề này.

Lợi ích lớn nhất của việc dùng DevOps là gì?

Như đã nói ở trên, DevOps là một văn hóa làm việc, thuộc về vấn đề mindset.

Nói nôm na, anh muốn làm giời làm bể gì thì cũng phải “đả thông tư tưởng” trước đã. Một khi đã nghĩ thông suốt thì bắt tay vào làm sẽ nhanh hơn.

Đóng góp lớn nhất của DevOps là, cùng với phương pháp Agile, nó giúp hoàn thiện việc chuyển đổi quy trình phát triển và vận hành phần mềm từ mô hình thác nước (waterfall) sang mô hình phát triển/phát hành liên tục (continuous development/releases).

Vậy những lợi ích của DevOps là gì? Chủ yếu:

  • Tăng cường sự cộng tác chặt chẽ giữa nhóm phát triển (development) và nhóm vận hành (operation), cũng như khả năng làm việc liên chức năng (cross-functional).
  • Nâng cao tần suất triển khai (deployment), giúp rút ngắn thời gian phát triển/cải tiến sản phẩm.
  • Tận dụng các công cụ tự động hóa, giúp hạn chế rủi ro, giảm tỉ lệ thất bại.
  • Thời gian phục hồi sản phẩm nhanh hơn.

Tất cả đều phục vụ cho mục đích cuối cùng là cải thiện khả năng cung cấp dịch vụ IT một cách nhanh chóng. Từ đó, tăng khả năng cạnh tranh của sản phẩm/doanh nghiệp.

Tại sao nhu cầu tuyển dụng DevOps Engineer rất nhiều, nếu như DevOps không phải là một nhánh nghề nghiệp mới?

Như đã nói ở trên, trong những công ty nhỏ/start-up, rất thường xuyên anh developer sẽ kiêm nhiệm luôn phần operations: tự code, tự test, rồi tự deploy sản phẩm. Như vậy cũng là áp dụng văn hóa DevOps rồi.

Nhưng, tại những công ty quy mô lớn/rất lớn như Google, Facebook.v.v…, các vị trí thường đòi hỏi độ chuyên môn hóa cao. Để áp dụng văn hóa DevOps, họ sẽ cần những “nhân vật trung gian” đứng giữa Dev và Ops, nhằm giúp hai bên hợp tác “nuột” hơn. DevOps Engineer chính là “nhân vật trung gian” này.

Như vậy, DevOps Engineer là một vị trí nảy sinh do nhu cầu thực tiễn công việc, chứ không hẳn là một “nghề”.

Nếu để ý các tin tuyển dụng DevOps, bạn sẽ thấy: tùy công ty, sản phẩm mà trách nhiệm công việc/kĩ năng cụ thể cho vị trí DevOps Engineer sẽ có sự thay đổi.

Một số công ty yêu cầu DevOps Engineer kiêm luôn phần việc của System Engineer, hoặc Arch/Dev/QA.v.v…

Giá trị lớn nhất của một DevOps Engineer đem lại cho doanh nghiệp là:

1. Hiểu rõ văn hóa DevOps, từ đó lan truyền/tạo cảm hứng về sự hợp tác/kết nối giữa nhóm phát triển và nhóm vận hành trong doanh nghiệp.

2. Giúp tăng cường khả năng tự động triển khai/phát hành (auto-deployment/releases) cho sản phẩm. Bằng cách: sử dụng các tool sẵn có, hoặc tự phát triển các automated tool.

Xem thêm DevOps Engineer là gì

devops-la-gi-devops-engineer

Cho nên, công việc của DevOps Engineer sẽ phục vụ cho toàn công ty chứ không chỉ giới hạn trong một team nhỏ.

Việc làm DevOps Engineer TPHCM

Việc làm DevOps Engineer Hà Nội

Những kĩ năng và tố chất cần thiết để làm DevOps là gì?

DevOps Engineer thường là vị trí kiêm nhiệm (Developer kiêm nhiệm thêm phần việc operations, hoặc là System Engineer kiêm nhiệm thêm một phần việc của dev.v.v…)

Ví dụ, Tấn là System Engineer kiêm DevOps Engineer. Tấn muốn deploy version mới của sản phẩm lên 100 server. Nếu thực hiện việc này thủ công thì sẽ mất rất nhiều thời gian, và không tránh khỏi sai sót.

Trong trường hợp deploy thành công 50 con server, còn 50 con thất bại, thì cũng có nghĩa là sản phẩm của mình thất bại. Bởi vì cùng lúc sản phẩm sẽ chạy 2 version khác nhau, mà mình lại không kiểm soát 2 version này được. Muốn khắc phục thì cũng phải có thời gian.

Như vậy, để deploy nhanh hơn, hỗ trợ việc back-up, restore, đồng thời giảm thiểu rủi ro, thì với vai trò DevOps Engineer, Tấn sẽ viết automated script để ship code tự động lên server.

Cho nên, kĩ năng lập trình “cứng” là điều bắt buộc.

Ngôn ngữ lập trình phổ biến cho DevOps Engineer là Python, shell script.

Ngoài ra, để Ops, anh ta cũng cần hiểu sâu, thông thạo về hệ điều hành đang sử dụng (Linux, Docker.v.v…)

Đặc biệt, người làm DevOps phải có khả năng research tốt để nhanh chóng tìm ra giải pháp, xử lý tình huống.

Ví dụ, Tấn triển khai services trên nền tảng on premise. Một ngày “đẹp trời” nào đó, hệ thống gặp vấn đề, Tấn muốn move toàn bộ sản phẩm của mình lên cloud. Tuy nhiên, có rất nhiều cloud, nên chọn dùng cloud nào cho phù hợp?

Rõ ràng, trong tình huống này, nếu khả năng research không tốt, không nhanh chóng tìm ra cách để move toàn bộ mọi thứ đang chứa trên on premise lên cloud, thì sản phẩm của mình bị đình trệ rồi.

Hoặc, trong DevOps có rất nhiều bài toán hóc búa liên quan đến phần network, I/O, infra system .v.v… Một anh cứng về develop nhưng không hiểu sâu về phía Infra thì khi làm DevOps sẽ gặp rất nhiều khó khăn. Anh ta buộc phải research về Infra để phục vụ cho công việc.

Còn về tố chất, thì theo Tấn, sự cẩn thận, tỉ mỉ là quan trọng nhất.

Bởi vì, DevOps Engineer thường sẽ đảm nhiệm những công việc như migrate data cho công ty. Khi đó, chỉ cần xảy ra một sai sót nhỏ, ví dụ như sai 1 IP server, thì sẽ gây ảnh hưởng đến toàn hệ thống.

devops-la-gi

Một số tool thông dụng cho người làm DevOps

Sai lầm lớn nhất anh từng phạm phải khi làm DevOps là gì?

Sai lầm thì nhiều lắm, Tấn húc đầu vào tường hoài chứ gì. Có lần còn “trót dại” húc suýt bể đầu luôn. (cười)

Đợt ấy, team Tấn (ở công ty cũ) phụ trách migrate data sản phẩm, cụ thể là shipping data bằng automated tool.

Do chủ quan “code nhà mình” thì chắc “ngon lành cành đào” rồi, nên Tấn review không thật sự kĩ lưỡng. Tấn cũng chỉ test một phần (chứ không phải toàn bộ) trên môi trường staging – server test mà thôi.

Đến lúc đẩy code lên môi trường production thì, bùm, sự cố xảy ra!

Đại khái là sản phẩm lúc đó có tình trạng 2-3 user sử dụng 2-3 số điện thoại riêng biệt để đăng kí dùng chung 1 ID account. Khi những user này đăng nhập thành công, họ đều được redirect đến cùng 1 account.

Sự cố đã ảnh hưởng nghiêm trọng đến chuyện thanh toán tiền bạc của những ID account dùng chung, cũng như toàn bộ workflow của sản phẩm.

Vậy đấy. Chỉ là sai sót nhỏ trong một dòng code, nhưng cái giá phải trả thì quá đắt. Cả team Tấn gồm 7 người đã phải cày cật lực 10 ngày để khắc phục hậu quả.

Những bài học quan trọng anh đúc rút cho bản thân?

Từ sự cố kể trên, Tấn rút ra “bài học nhớ đời” là phải cực kì cẩn trọng, tuân thủ nghiêm ngặt quy trình QA QC trước khi release.

Ngoài ra, cần phải giữ bình tĩnh trong mọi tình huống, vì có cuống lên cũng không giải quyết được gì, mà chỉ thêm rối.

Ví dụ, có lần anh em team mình ở lại văn phòng làm việc khuya. Đến khoảng 3 giờ sáng thì xảy ra sự cố. Cả team vừa mệt vừa hoảng, nên cứ cuống lên rồi bị cuốn theo cái “hố đen” sự cố đến tận ngày hôm sau. Nếu bình tĩnh hơn, có lẽ bọn mình đã nhìn ra được giải pháp tốt nhất để xử lý tình huống ngay lúc đó.

Và, từ kinh nghiệm cá nhân, mình nhận thấy rằng làm việc nhóm thì phải biết thông cảm, an ủi người khác.

Bởi vì khi sản phẩm bị bug trên production, thì người chịu trách nhiệm về những tính năng đó đang rất áp lực. Lúc này, nếu leader chỉ biết la lối, làm căng lên thì bạn đó sẽ không còn tinh thần để tiếp tục làm việc/giải quyết vấn đề.

Một leader tốt cần giữ bình tĩnh để trấn tĩnh tinh thần anh em, đồng thời phải cùng lao vào giải quyết vấn đề, chứ không phải chỉ đứng đằng sau chỉ trỏ.

Tài liệu để tìm hiểu thêm DevOps là gì?

  • DevOps Việt Nam: hội nhóm mở trên Facebook, dành riêng cho các DevOps tại Việt Nam. Bạn có thể tìm thấy rất nhiều thông tin từ chia sẻ tài liệu, kinh nghiệm cho đến tuyển dụng DevOps tại đây.
  • What is DevOps: bài viết rất thú vị về sự ra đời cũng như những nguyên lý của DevOps.

Nếu muốn trao đổi thêm về DevOps, cứ ping mình ở skype cntt040, hoặc email cntt040@gmail.com. Mình rất vui được trò chuyện, chia sẻ kinh nghiệm cùng các bạn để học hỏi lẫn nhau.

Bạn muốn tìm hiểu DevOps là gì? Hoặc, bạn là một DevOps Engineer giàu kinh nghiệm? Hãy cùng chia sẻ ở phần bình luận phía dưới.

Và đừng quên tham khảo việc làm DevOps tại ITviec!

About the Author:

Storyteller

After nearly 10 years working in the online industry, Anh eventually found her strong passion for content marketing and storytelling. Read more...

Comments