DevOps Engineer thực sự làm gì trong một dự án Cloud?
Gần đây đi trà đá thấy anh em DevOps nổ ra cuộc thảo luận rất hay, xoay quanh việc DevOps làm Cloud và DevOps làm On-premise. Và câu hỏi tôi thấy anh em nói nhiều là DevOps Engineer thực sự làm gì trong một dự án Cloud?
DevOps VietNam là hệ sinh thái hỗ trợ anh em kỹ sư và doanh nghiệp phát triển cùng ngành tại Việt Nam với nhiều hoạt động có tâm có tầm từ lâu anh em đều biết. Tôi thì cũng chỉ là một thợ trông server, may mắn được quyền tác giả nên cũng muốn chia sẻ một chút góc nhìn cá nhân trong khoảng gần 10 năm làm nghề.
Vì ý kiến cá nhân (nói đúng ra thì cũng học hỏi thêm từ nhóm anh em Senior khác hôm thảo luận) nên có thể có nhiều bác thấy gật gù, có nhiều bác thì nhăn mặt.
Nếu để mà nói về mindset và công việc của một DevOps thực sự không khác gì làm dâu trăm họ. Tuy vẫn những công việc, công nghệ rất hay được nhắc tới nhưng mỗi người có trải nghiệm riêng, mỗi công ty lại có văn hóa riêng, nên theo tôi thì không một bài viết nào có thể chia sẻ thực sự thỏa mãn tất cả mọi người. Nhưng thấy cũng chưa có ai chia sẻ nên mạnh dạn gõ phím. Mong lắng nghe được thêm ý kiến của các bác và giúp bạn nào chưa có hình dung nhé.
Khi dự án bắt đầu, DevOps làm gì?
Chúng ta vào ngay lúc ban đầu của dự án, ví dụ bài toán cho một team phát triển sản phẩm gồm vài API, background workers, PostgreSQL và Team quyết định triển khai lên AWS.
Lúc này, theo tôi công việc của DevOps không nên là nhận yêu cầu rồi bắt tay dựng VPC, EC2 hay EKS ngay.
Trước hết cần làm rõ ứng dụng có những thành phần nào, chúng giao tiếp với nhau ra sao, yêu cầu về availability, security, khả năng mở rộng và phục hồi dữ liệu đến mức nào. Cùng với đó là ngân sách, năng lực vận hành và các quy định pháp lý của dự án.
Từ những thông tin này, DevOps phối hợp với Architect và Development team lựa chọn, thiết kế nền tảng Cloud phù hợp.
Chẳng hạn như ứng dụng nên chạy trên EC2, ECS hay EKS? Database sử dụng RDS hay tự quản lý? Network được phân chia và kiểm soát truy cập thế nào? Nếu một Availability Zone gặp sự cố, những thành phần nào cần tiếp tục hoạt động?
Khi phương án được thống nhất, DevOps triển khai infrastructure, cấu hình networking, IAM, quản lý secrets, thiết lập môi trường và sử dụng Infrastructure as Code để quản lý những tài nguyên đó.
Vì vậy, theo tôi nghĩ kết quả cần đạt được ở giai đoạn này là một nền tảng Cloud mà ứng dụng có thể triển khai lên, được quản lý nhất quán, có khả năng thay đổi và đáp ứng các yêu cầu kỹ thuật đã xác định.
Ở đây tôi thấy có một điểm đáng bàn là việc lựa chọn công nghệ, dựng được EKS không có nghĩa dự án cần EKS. Một team nhỏ với vài services có thể vận hành hiệu quả hơn trên ECS Fargate nhưng cố lên EKS cho “chuyên nghiệp” thì có thể kéo theo rất nhiều rủi ro. Ngược lại, nếu tổ chức đã có nền tảng Kubernetes và đội ngũ đủ năng lực vận hành, dự án lại yêu cầu mở rộng mức độ phức tạp, EKS lại có thể là lựa chọn hợp lý.
Điều quan trọng không phải công nghệ nào hiện đại hơn, mà là những yêu cầu và đánh đổi nào dẫn đến quyết định đó và khi cân đối được và mất chúng ta quyết định cái gì.
Anyway, cuộc sống là chuỗi những sự lựa chọn và ra quyết định 😀
Khi Developer bắt đầu release, DevOps làm gì?
Có infrastructure rồi, nhưng Developer không thể cứ mỗi lần release lại gửi Docker image cho DevOps rồi nhờ triển khai thủ công.
Lúc này DevOps cần xây dựng quy trình đưa thay đổi từ source code lên production.
Công việc có thể bao gồm CI/CD pipeline, build và quản lý artifacts, kiểm tra bảo mật, quản lý cấu hình theo môi trường, deployment strategies và những cơ chế hỗ trợ rollback.
Nhưng chỗ này cần nhìn sâu thêm một chút.
Nếu pipeline deploy thành công nhưng phiên bản mới có lỗi thì sao? Nếu cần rollback application nhưng database vừa chạy một migration không tương thích ngược thì sao? Nếu deployment thất bại giữa chừng, hệ thống có tiếp tục phục vụ người dùng được không?
Đó là những tình huống mà chỉ viết pipeline chưa thể giải quyết hết.
DevOps cần phối hợp với Developer để thống nhất cách release, kiểm soát thay đổi và xử lý khi deployment gặp vấn đề.
Vì vậy, theo tôi thấy phần này kết quả cần đạt được là Developer có thể đưa phần mềm lên production thông qua một quy trình rõ ràng, lặp lại được, có kiểm soát và không phụ thuộc quá nhiều vào thao tác thủ công của một cá nhân.
Nói cách khác, DevOps không phải người được thuê để deploy code hộ Developer mãi mãi. Một phần công việc của DevOps là xây dựng khả năng để team có thể tự làm việc đó một cách an toàn.
Khi ứng dụng đã lên production, DevOps làm gì?
Đến đây thì là lúc những quyết định trước đó bắt đầu được kiểm chứng thực tế.
Ứng dụng chạy được chưa có nghĩa là vận hành được.
DevOps cần phối hợp xây dựng observability, alerting, backup, recovery, capacity management và các quy trình phục vụ vận hành production.
Ví dụ, một ngày hệ thống bắt đầu trả về nhiều lỗi 5xx. Kubernetes vẫn healthy, CPU và memory không có gì bất thường.
Nhưng database connection pool đã cạn do số lượng requests tăng đột biến (phần này thấy nhiều bác tác giả cũng chia sẻ rồi).
Nếu chỉ giám sát tài nguyên infrastructure, chúng ta rất khó nhìn thấy nguyên nhân. Vì vậy, ngoài CPU, memory hay network, hệ thống còn cần application metrics, logs, traces và những chỉ số phản ánh hoạt động thực tế của dịch vụ.
Khi sự cố xảy ra, DevOps có thể tham gia khoanh vùng nguyên nhân, kiểm tra hạ tầng, hỗ trợ rollback, điều chỉnh tài nguyên hoặc phối hợp với Developer xử lý vấn đề ở application.
Có một điều tôi thấy thực sự nên hiểu là không phải cứ production có lỗi thì DevOps phải sửa tất cả. Nhưng các cơ chế để phát hiện, chẩn đoán và phục hồi hệ thống cần được chuẩn bị từ trước.
Tương tự, cấu hình backup thành công không có nghĩa là dữ liệu chắc chắn khôi phục được. Nếu chưa kiểm thử restore thì chúng ta cũng chưa biết khả năng phục hồi thực tế đến đâu.
Vì vậy, tôi thấy đi đến đây rồi thì kết quả cần đạt được là hệ thống không chỉ chạy trong điều kiện bình thường, mà còn có khả năng phát hiện, xử lý và phục hồi khi mọi thứ không diễn ra như mong đợi.
Khi hệ thống đã vận hành ổn định, DevOps còn làm gì?
Đây là phần tôi thấy cũng đáng nói trong các dự án Cloud.
Có những ý kiến Cloud là đồ xài sẵn có gì nữa đâu mà khó khăn? Tôi không thích góc nhìn này chút nào hoặc là bạn ấy chưa làm thực sự toàn cảnh một dự án hoặc là chưa dùng đủ sâu.
Không phải dựng xong infrastructure, có CI/CD và monitoring là hết việc.
Sau một thời gian vận hành, những vấn đề mới bắt đầu xuất hiện.
Developer mất nhiều thời gian chờ tạo môi trường. Deployment có quá nhiều bước thủ công. Tài nguyên cấp phát dư thừa. Cloud bill tăng đều nhưng không rõ chi phí đang tập trung ở đâu. Một số thành phần được triển khai từ đầu nhưng giờ không còn phù hợp.
Vì vậy tôi nghĩ DevOps cần liên tục đánh giá và cải thiện những điểm này.
Đôi khi là xây dựng self-service infrastructure để Developer chủ động hơn. Đôi khi là cải tiến pipeline, chuẩn hóa cấu hình, tối ưu tài nguyên hoặc điều chỉnh cơ chế autoscaling.
Riêng trên Cloud, chi phí là một yếu tố quan trọng được đưa lên hàng đầu, anh em cũng hiểu rồi, đồng tiền đi liền khúc ruột 😀
Một hệ thống có thể đạt yêu cầu về performance và availability, nhưng nếu chi phí vận hành vượt xa khả năng hoặc nhu cầu thực tế của dự án thì kiến trúc ấy đẹp mấy cũng khó mà được approve.
Tuy nhiên, tối ưu không đơn giản là giảm bill. Giảm một nửa chi phí database nhưng làm tăng nguy cơ downtime thì với tôi không phải là quyết định tốt.
Tôi nghĩ trách nhiệm ở đây là liên tục cải thiện sự cân bằng giữa khả năng vận hành, độ tin cậy, bảo mật, chi phí và tốc độ phát triển sản phẩm.
Như Đức Phật tìm ra con đường Trung Đạo cái gì “quá” đều không tốt 😀
Và muốn biết những cải tiến đó có hiệu quả hay không, phải nhìn vào kết quả như: thời gian triển khai có giảm không, sự cố có được phát hiện và phục hồi nhanh hơn không, Developer có bớt phụ thuộc vào thao tác thủ công không, chi phí có tương xứng với nhu cầu không.
Nếu không đo lường được sự thay đổi, rất dễ rơi vào tình trạng triển khai thêm công cụ nhưng không biết hệ thống thực sự tốt lên ở đâu.
Vậy đâu là công việc cốt lõi của DevOps Engineer?
Với kinh nghiệm của tôi khi nhìn xuyên suốt một dự án Cloud, tôi thấy công việc của DevOps có thể tóm lại:
- Ở giai đoạn xây dựng: DevOps tham gia thiết kế, triển khai và quản lý nền tảng Cloud để ứng dụng có môi trường vận hành phù hợp.
- Ở giai đoạn phát triển và phát hành: DevOps xây dựng các cơ chế tự động hóa, giúp Developer kiểm thử, triển khai và thay đổi ứng dụng an toàn, nhất quán.
- Ở giai đoạn production: DevOps xây dựng và duy trì những năng lực giám sát, vận hành, xử lý sự cố và phục hồi hệ thống.
- Trong suốt vòng đời dự án: DevOps tiếp tục cải tiến nền tảng, giảm công việc thủ công, kiểm soát rủi ro và tối ưu việc sử dụng tài nguyên Cloud.
Và như tôi cũng vừa nói, tùy tổ chức/quy mô mà những trách nhiệm này có thể được chia sẻ giữa DevOps, SRE, Platform Engineering, Security và Development team. Không có nghĩa một DevOps Engineer phải tự mình làm tất cả.
Nhưng nếu hỏi DevOps đóng góp gì cho dự án, tôi nghĩ đây là những phần công việc và kết quả khá cụ thể để chúng ta nhìn vào.
Lời kết
Quay lại câu chuyện DevOps làm Cloud và On-premise, tôi nghĩ mục tiêu và bản chất công việc không khác nhau quá nhiều. Điều thay đổi là môi trường, công cụ, giới hạn và những quyết định kỹ thuật chúng ta phải quyết định.
Cloud cho phép tạo tài nguyên nhanh, sử dụng managed services và tự động hóa ở quy mô lớn. Nhưng đi kèm với đó là những bài toán về quyền truy cập, chi phí theo mức sử dụng, quản lý cấu hình, trách nhiệm bảo mật và độ phức tạp của hệ thống.
Vì vậy, DevOps Engineer làm Cloud không chỉ cần biết sử dụng các dịch vụ Cloud, mà còn phải hiểu cách kết hợp và vận hành chúng thành một nền tảng phục vụ quá trình phát triển phần mềm.
Nên tôi nghĩ trả lời câu hỏi “DevOps Engineer thực sự làm gì trong một dự án Cloud” đó là người tham gia xây dựng và duy trì những năng lực kỹ thuật giúp ứng dụng có thể được triển khai, thay đổi, vận hành và phục hồi một cách đáng tin cậy trên Cloud.
Chắc không nghe tôi gõ phím ở trên đọc mỗi đúc kết thì anh em nhăn mặt đúng kiểu “khẩu hiệu” 😀
Còn Terraform, Kubernetes, AWS hay CI/CD là những công cụ và công nghệ chúng ta sử dụng để thực hiện các công việc ấy. Làm được công cụ là một kỹ năng. Biết thiết kế và kết hợp chúng thành một hệ thống phù hợp với dự án là một năng lực khác.
Và tôi nghĩ chính ở phần thứ hai, kinh nghiệm và tư duy engineering của người làm DevOps bắt đầu tạo ra sự khác biệt giữa trình độ của người này với người kia.