Đám mây có thể giảm độ phức tạp khi triển khai, nhưng không tự loại bỏ trách nhiệm vận hành. Với đội kỹ thuật tinh gọn, nền tảng chỉ thực sự giảm gánh nặng khi quản lý trạng thái sức khỏe và tự phục hồi. Trách nhiệm đó còn bao gồm vá lỗi, mở rộng và cảnh báo trong suốt vòng đời ứng dụng.
Năng lực đó được kiểm chứng rõ nhất lúc 3 giờ sáng. Vấn đề không chỉ là dịch vụ có tiếp tục hoạt động hay không, mà còn là có ai phải thức dậy để giữ nó hoạt động hay không.
Khi cảnh báo xuất hiện, người trực có thể không phải người xây dịch vụ. Họ không biết ngưỡng cảnh báo nào đã được đặt lúc triển khai và cũng không rõ hệ thống đang tự phục hồi hay chờ con người quyết định. Bài viết gốc của The New Stack về trách nhiệm vận hành của Elastic Beanstalk xác định đây là ranh giới quan trọng. Một dịch vụ thực sự tiếp nhận gánh nặng vận hành, còn một nền tảng khác có thể chỉ trì hoãn gánh nặng đó.
Hệ thống vượt qua phép thử lúc 3 giờ sáng phải biết trạng thái khỏe mạnh là gì. Nó cũng phải biết cách phản ứng khi trạng thái ấy không còn đúng và cách thông báo chuyện đã xảy ra. Những quyết định này cần được xác lập khi triển khai, thay vì được đưa ra giữa sự cố.
Nội dung
Bốn mươi kỹ sư, tám ứng dụng và không có đội vận hành riêng
Một đội gồm 40 kỹ sư vận hành tám ứng dụng sản xuất cần chuẩn hóa trách nhiệm vận hành mà không nhất thiết phải lập ngay một bộ phận hạ tầng riêng. Nếu mỗi lập trình viên đồng thời phải triển khai, giám sát và trực sự cố, chi phí vận hành sẽ trực tiếp làm giảm thời gian dành cho sản phẩm.
Hạ tầng đám mây phát triển theo hai hướng. Một phía cung cấp toàn quyền kiểm soát bằng hạ tầng dưới dạng mã, lưới dịch vụ và các quy trình triển khai tùy chỉnh. Cách này mạnh và linh hoạt, nhưng phù hợp hơn với tổ chức đã đầu tư nhân sự vận hành để gánh chi phí của sự linh hoạt đó.
Phía còn lại hướng đến sự đơn giản cho một ứng dụng: đẩy mã nguồn lên và nhận một địa chỉ truy cập. Mô hình này thuận tiện cho lần triển khai đầu tiên, nhưng sớm bộc lộ giới hạn khi doanh nghiệp quản lý nhiều dịch vụ, cần kiểm soát tuân thủ hoặc tiếp nhận một ứng dụng không phù hợp với khuôn mẫu của nền tảng.
Khoảng trống vận hành của đội kỹ thuật tinh gọn
The New Stack mô tả một doanh nghiệp có 40 kỹ sư và tám ứng dụng sản xuất. Hai ứng dụng tạo ra 80% doanh thu. Người làm công việc kỹ sư độ tin cậy hệ thống thực chất là một lập trình viên cấp cao, còn lịch trực sự cố là nhiệm vụ không ai muốn nhận. Doanh nghiệp có một đợt kiểm toán tuân thủ vào quý III nhưng chưa bắt đầu chuẩn bị.
Khoản đầu tư đúng đắn là đưa sản phẩm ra thị trường. Chi phí của khoảng trống vận hành nằm trong những gì đội ngũ không thể hoàn thành.
Mỗi kỹ sư đều đóng góp trên toàn bộ hệ thống. Người viết tính năng cũng triển khai, giám sát và nhận cảnh báo khi tính năng gặp sự cố. Điều này không có nghĩa đội ngũ thiếu năng lực. Ở giai đoạn đó, tuyển riêng một đội hạ tầng có thể chưa phải khoản đầu tư hợp lý.
Mỗi chu kỳ phát triển dành cho việc nâng cấp quy trình triển khai là một chu kỳ không tạo ra tính năng khách hàng yêu cầu. Một lập trình viên xử lý cảnh báo lúc 3 giờ sáng rồi dự họp sản phẩm lúc 9 giờ sẽ bị giảm năng suất, nhưng phần thiệt hại ấy thường không xuất hiện trên bảng theo dõi nào. Những thay đổi về vai trò kỹ sư trong thời đại mới càng khiến ranh giới giữa phát triển và vận hành trở nên đáng chú ý.
Những ứng dụng không ai dự định sẽ phải vận hành
Danh mục ứng dụng của doanh nghiệp thường gồm cả hệ thống mới và phần mềm kế thừa mà đội hiện tại không xây dựng. Một nền tảng quản lý trọn vòng đời phải tiếp nhận được các ứng dụng này trong trạng thái hiện có, nếu không đội kỹ thuật sẽ phải duy trì nhiều mô hình vận hành song song.
Doanh nghiệp có thể nhận thêm sản phẩm sau sáp nhập và mua lại, kế thừa công cụ nội bộ do một kỹ sư đã nghỉ việc ba năm trước viết, hoặc vận hành phần mềm thương mại đã được tùy chỉnh vượt quá phạm vi hỗ trợ của nhà cung cấp.
Một mô hình chung cho phần mềm kế thừa
Một số ứng dụng nghiệp vụ còn được viết bằng ngôn ngữ mà không thành viên hiện tại nào chủ động lựa chọn. Dù vậy, chúng vẫn đang phục vụ khách hàng hoặc đáp ứng yêu cầu tuân thủ. Doanh nghiệp không có ngân sách và cũng không được giao nhiệm vụ viết lại toàn bộ. Những ứng dụng này cần một môi trường chấp nhận chúng trong trạng thái hiện tại.
Nếu dịch vụ quản lý ứng dụng chỉ hỗ trợ hệ thống mới, đội kỹ thuật buộc phải duy trì hai mô hình vận hành. Một mô hình dành cho ứng dụng đang xây dựng và một mô hình khác dành cho ứng dụng kế thừa. Sự phân chia này khiến cấu hình dần sai lệch, bản vá bị chậm và các vấn đề kiểm toán tích tụ.
Một dịch vụ quản lý trọn vòng đời phải tiếp nhận được ứng dụng Java đóng gói dưới dạng tệp WAR và dịch vụ .NET Framework chạy trên Windows. Phạm vi đó còn gồm ứng dụng Python bị ràng buộc với một môi trường thực thi cụ thể và dịch vụ đóng gói trong thùng chứa đã chạy ở nơi khác. Tất cả cần được áp dụng cùng mô hình vận hành, giao diện triển khai, cách vá lỗi và cơ chế mở rộng.
Dữ liệu thị trường cho thấy điều gì?
Dữ liệu thị trường cho thấy kỹ thuật nền tảng đã trở thành một năng lực tổ chức, nhưng trách nhiệm này chưa được chuẩn hóa ở mọi doanh nghiệp. Theo nghiên cứu của CNCF và SlashData, 28% tổ chức có đội kỹ thuật nền tảng chuyên trách, trong khi 41% phân chia năng lực này cho nhiều đội.
Janakiram MSV là nhà phân tích và cố vấn về nền tảng đám mây bản địa. Ông nhận định mô hình đám mây bản địa đã chuẩn hóa lớp hạ tầng quanh thùng chứa và Kubernetes, nhưng chưa chuẩn hóa ranh giới trách nhiệm giữa đội ứng dụng và phần hạ tầng bên dưới. Kỹ thuật nền tảng xuất hiện phần lớn để thiết lập lại ranh giới đó.
Khoảng trống xuất hiện khi danh mục mở rộng
Theo nghiên cứu của CNCF và SlashData được nguồn gốc trích dẫn, 28% tổ chức có đội kỹ thuật nền tảng chuyên trách, 41% phân chia năng lực này cho nhiều đội và 3% chưa có cách tiếp cận chính thức.
Mức trưởng thành thường chững lại ở ứng dụng thứ ba, thay vì lần triển khai đầu tiên. Một đội 40 kỹ sư có thể duy trì dịch vụ đầu tiên nhờ hiểu rõ hệ thống. Sau đó, một thương vụ mua lại mang đến khối lượng công việc .NET. Thương vụ đó còn đưa vào một công cụ nội bộ do người đã nghỉ việc hai năm trước phát triển. Đội ngũ lập tức phải duy trì ba mô hình vận hành mà không ai có nhiệm vụ thống nhất chúng.
Tuyển thêm người không tự động giải quyết được khoảng trống này. Thứ còn thiếu là một tư thế vận hành được chuẩn hóa. Đây cũng là vấn đề cốt lõi khi xây dựng hạ tầng và quy trình vận hành hệ thống có thể mở rộng cùng danh mục ứng dụng.
Hàng trăm nghìn lần triển khai bộc lộ điều gì?
Dữ liệu từ nhiều lần triển khai sản xuất cho thấy rủi ro không kết thúc sau khi mã nguồn được đưa lên hệ thống. Rủi ro xuất hiện sau đó, khi ứng dụng suy giảm trong im lặng, khả năng quan sát đến muộn, chi phí tăng theo danh mục hoặc cấu hình bảo mật không được thực hiện.
Các nhận định này dựa trên hàng trăm nghìn lần triển khai sản xuất của hàng nghìn khách hàng. Đó là dữ liệu quan sát của đội ngũ Elastic Beanstalk được trình bày trên The New Stack. Quy mô đó cho thấy điều gì thực sự hỏng, điều gì bị đẩy lên thành sự cố lúc 3 giờ sáng và điều gì khiến một đội đủ tin nền tảng để không phải liên tục nghĩ về nó.
Ứng dụng ổn định đến mức không ai dám chạm vào
Một lần triển khai thành công không chứng minh ứng dụng sẽ tiếp tục khỏe mạnh. Nếu đội ngũ ngại thay đổi hệ thống vì sợ làm hỏng nó, sự ổn định bề ngoài có thể che giấu một quy trình vận hành mong manh.
Một đội dành trọn hai ngày để triển khai ứng dụng Spring Boot cùng quy trình tích hợp, phân phối liên tục và chứng chỉ SSL. Việc triển khai thành công. Sau đó, không ai đụng đến ứng dụng trong ba tháng, không hẳn vì nó ổn định mà vì mọi người sợ làm hỏng nó.
Khách hàng cuối cùng báo ứng dụng không thể truy cập. Đội kỹ thuật mất bốn giờ điều tra xem điều gì đã thay đổi và phải ngăn sự cố lặp lại bằng cách nào. Theo tác giả thuộc đội ngũ Elastic Beanstalk trong bài đăng trên The New Stack, đây là dạng thất bại phổ biến nhất họ quan sát được: quá trình triển khai thành công trong im lặng rồi hệ thống suy giảm mà không ai nhận ra.
Một bản phát hành có thể thành công một phần thì rồi sẽ thất bại một phần.
Nền tảng tạo được niềm tin khi mỗi lần triển khai hoặc hoàn tất đầy đủ, hoặc được đảo ngược hoàn toàn. Đội ngũ không nên phải xử lý trạng thái trung gian hay tìm hiểu quy trình quay lui thủ công giữa lúc chịu áp lực.
Khả năng quan sát đến muộn ba tuần
Khả năng quan sát chỉ có giá trị khi dữ liệu đã tồn tại trước lúc sự cố xảy ra. Số liệu, dấu vết và tín hiệu sức khỏe cần xuất hiện ngay từ lần triển khai đầu tiên, thay vì được bổ sung sau khi đội ngũ đã mất thông tin cần thiết để chẩn đoán.
Một lập trình viên nhận thấy thời gian phản hồi đang giảm chất lượng và cần số liệu sử dụng bộ nhớ. Nền tảng không thu thập thông tin đó theo mặc định. Cả đội phải dành một chu kỳ phát triển để viết tệp cấu hình và cài tác nhân giám sát trên từng máy. Thông tin họ cần từ ba tuần trước chỉ xuất hiện sau ba tuần.
Khả năng quan sát thường bị xem là phần bổ sung thay vì thành phần mặc định. Theo tác giả, mọi đội họ từng quan sát chỉ bổ sung giám sát sau sự cố đầu tiên đều ước mình đã làm sớm hơn. Đội tránh được tình huống này nhận số liệu, dấu vết và tín hiệu sức khỏe ngay từ lúc triển khai. Họ không phải sửa mã hoặc dành thêm một chu kỳ để nối các công cụ.
Chi phí tăng theo số lượng ứng dụng
Chi phí vận hành tăng nhanh khi mỗi ứng dụng sao chép một ngăn xếp hạ tầng và quy trình quản trị riêng. Nền tảng dùng chung trách nhiệm vận hành có thể quản lý danh mục như một hệ thống, thay vì buộc đội ngũ lặp lại cùng một phần việc cho từng ứng dụng.
Khi mỗi ứng dụng có hạ tầng riêng, chi phí vận hành tăng tuyến tính theo danh mục. Trong ví dụ của The New Stack, đội chạy tám ứng dụng phải chịu mức chi phí chung gấp tám lần đội chạy một ứng dụng. Nguyên nhân không phải ứng dụng nào cũng cần tài nguyên chuyên dụng, mà là kiến trúc nền tảng giả định sự cô lập thay vì dùng chung trách nhiệm vận hành.
Mô hình này khiến doanh nghiệp ngại di chuyển các ứng dụng kế thừa. Tuy nhiên, một cuộc kiểm toán tuân thủ vẫn yêu cầu cùng tiêu chuẩn quản trị, nhịp vá lỗi và kiểm soát truy cập, bất kể ứng dụng cũ đang chạy theo mô hình nào.
Cấu hình bảo mật không ai thực hiện
Một đội không có chuyên gia bảo mật riêng khó duy trì những biện pháp kiểm soát đòi hỏi cấu hình chuyên môn. Trong trường hợp đó, chứng nhận tuân thủ, cô lập mạng và kiểm soát truy cập cần được nền tảng cung cấp theo mặc định.
Doanh nghiệp 40 kỹ sư trong ví dụ không có đội bảo mật. Họ chỉ có một lập trình viên cấp cao đọc các chuẩn CIS vào cuối tuần, trong khi cuộc kiểm toán vẫn diễn ra đúng lịch. Một đội không có chuyên gia khó triển khai những biện pháp kiểm soát đòi hỏi cấu hình chuyên môn. Khó khăn càng lớn khi mọi kỹ sư đều còn một danh sách công việc sản phẩm chưa bao giờ ngắn lại.
Trong hoàn cảnh này, tư thế bảo mật đáng tin cậy nhất là thứ nền tảng cung cấp sẵn: chứng nhận tuân thủ, cô lập mạng và kiểm soát truy cập. Việc hệ thống tự gánh các thiết lập lặp lại cũng giúp tránh tình trạng trách nhiệm bị đẩy qua lại giữa đội phát triển và đội bảo mật phải tự xác định ưu tiên.
Những mô hình này đòi hỏi điều gì ở nền tảng?
Một nền tảng chịu trách nhiệm vận hành phải xác định trạng thái khỏe mạnh, cung cấp khả năng quan sát từ lúc triển khai và áp dụng cùng cơ chế quản trị cho toàn bộ danh mục. Nền tảng cũng phải tự xử lý các nhiệm vụ lặp lại như vá lỗi, mở rộng, phục hồi và luân chuyển chứng chỉ.
Bốn vấn đề trên có cùng nguyên nhân. Nền tảng yêu cầu đội kỹ thuật đưa ra một quyết định vận hành, rồi đội đưa ra quyết định sai hoặc không đưa ra quyết định nào. Câu hỏi cần đặt ra không phải là phải cấu hình gì cho đội ngũ, mà là những quyết định nào đội ngũ không nên phải tự đưa ra.
Nền tảng phải xác định trạng thái khỏe mạnh trước yêu cầu đầu tiên, thay vì sau sự cố đầu tiên. Khả năng quan sát phải có ngay lúc triển khai. Ứng dụng thứ tám cần được quản lý bằng cùng mô hình, cơ chế quản trị và cách tính chi phí như ứng dụng đầu tiên. Bảo mật cũng phải được kế thừa mặc định nếu doanh nghiệp chưa thể xây một bộ phận chuyên trách.
Đây là lựa chọn kiến trúc về nơi trách nhiệm vận hành thường trực thuộc về. Đội kỹ thuật cung cấp mã nguồn, tệp Dockerfile, ảnh dựng sẵn hoặc khối lượng công việc cần di chuyển. Từ đó, nền tảng chịu trách nhiệm cho việc vá lỗi, mở rộng, tự phục hồi, luân chuyển chứng chỉ, lập kế hoạch năng lực và đánh giá sức khỏe trong suốt vòng đời ứng dụng.
Elastic Beanstalk được xây lại theo hai chế độ
Theo bài gốc, Elastic Beanstalk được xây lại để quản lý các lớp bên dưới ứng dụng theo hai chế độ. Chế độ Tiêu chuẩn dành cho từng ứng dụng hoặc khối lượng công việc Windows, còn chế độ Cụm mở rộng mô hình trách nhiệm trên toàn bộ danh mục ứng dụng.
Bài gốc cho biết AWS đã xây lại Elastic Beanstalk thành một dịch vụ quản lý ứng dụng nhận trách nhiệm vận hành cho mọi lớp bên dưới ứng dụng. Thay đổi kiến trúc quan trọng là dịch vụ chuyển từ mô hình một môi trường trước đây sang hai chế độ.
Chế độ Tiêu chuẩn cung cấp quyền sở hữu vận hành đầy đủ cho từng ứng dụng riêng lẻ và khối lượng công việc Windows hoặc .NET Framework. Toàn bộ ngăn xếp vận hành được quản lý cho một dịch vụ.
Chế độ Cụm mở rộng cùng mô hình trách nhiệm cho cả danh mục. Chế độ này dùng chung hạ tầng và đưa mã nguồn thành ứng dụng đang chạy. Ứng dụng thứ tám chia sẻ chi phí vận hành chung với bảy ứng dụng trước, thay vì sao chép toàn bộ phần chi phí ấy.
Với doanh nghiệp có 40 kỹ sư, đang chạy tám ứng dụng sản xuất và có thể nhận thêm 10 ứng dụng trong quý sau, khác biệt nằm ở phạm vi. Một nền tảng bao phủ cả danh mục hữu ích hơn nền tảng chỉ tiếp nhận những ứng dụng đơn giản vừa với khuôn mẫu của nó.
Thị trường đang hội tụ quanh trách nhiệm vận hành
Các nền tảng hiện đều tiếp nhận một phần trách nhiệm khi triển khai, nhưng khác nhau ở lượng trách nhiệm trả lại cho đội ứng dụng khi có sự cố, đến kỳ vá lỗi hoặc bước vào kiểm toán. Vì vậy, tiêu chí so sánh cần vượt ra ngoài khả năng chuyển mã nguồn thành một địa chỉ truy cập.
Một nền tảng giúp lập trình viên không phải quản lý hạ tầng trong tuần làm việc nhưng lại đưa toàn bộ gánh nặng trở lại lúc 3 giờ sáng Chủ nhật mới chỉ giải quyết một nửa vấn đề.
Theo SDxCentral, Magic Quadrant 2026 của Gartner về nền tảng ứng dụng cloud native đặt AWS, Microsoft, Google và Red Hat ở góc phần tư Leaders, còn Render, Netlify và Upsun ở góc phần tư Niche Players. Khi việc chuyển mã nguồn thành địa chỉ truy cập đã trở thành khả năng phổ biến, điểm khác biệt là bên nào chịu trách nhiệm vận hành ứng dụng thứ tám sau ba năm phát hành.
Dù vậy, nền tảng không nên loại bỏ mọi lựa chọn. Các quyết định hạ tầng thường lệ cần được đưa ra khỏi đường đi của lập trình viên, nhưng đội ngũ có nhu cầu đặc thù vẫn cần lối thoát để can thiệp. Một nền tảng không cho phép lựa chọn có thể trình diễn tốt nhưng sẽ gặp trở ngại khi tiếp nhận ứng dụng không vừa với quan điểm kiến trúc của nó.
Phép thử lúc 3 giờ sáng
Phép thử lúc 3 giờ sáng đánh giá liệu nền tảng có thực sự sở hữu trách nhiệm vận hành hay chỉ làm cho lần triển khai đầu tiên trở nên dễ dàng. Một nền tảng vượt qua phép thử phải biết trạng thái khỏe mạnh, tự phản ứng khi trạng thái thay đổi và thông báo đủ rõ để con người chỉ can thiệp khi cần.
Với đội ngũ đang vận hành hệ thống sản xuất quan trọng bằng nhân sự tinh gọn và danh mục ngày càng lớn, đây là tiêu chí đánh giá thực tế. Nền tảng của thập kỷ tới không chỉ giúp triển khai dễ hơn. Nó phải quyết định trước hệ thống sản xuất sẽ phản ứng thế nào khi sự cố xảy ra.
Đến 3 giờ sáng, thời điểm thích hợp để đưa ra các quyết định nền tảng đã qua. Hệ thống cần biết trạng thái khỏe mạnh là gì, phải làm gì khi trạng thái đó thay đổi và phải thông báo sự việc ra sao. Đám mây đã trao thêm năng lực cho đội kỹ thuật. Phần còn thiếu là một nền tảng ở lại để chịu trách nhiệm trong suốt vòng đời ứng dụng.
Hãy đối chiếu nền tảng hiện tại với phép thử lúc 3 giờ sáng trước khi danh mục ứng dụng tiếp tục mở rộng.
