Hỗ trợ Drupal: hợp đồng bảo trì nên gồm những gì

Phần lớn người tìm hỗ trợ Drupal đã có sẵn site. Họ thừa kế nó từ một agency đã rút đi hoặc một lập trình viên đã nghỉ; giờ bản cập nhật quá hạn, một biểu mẫu ngừng gửi thư, hoặc một khuyến cáo bảo mật vừa rơi xuống mà không ai biết có liên quan không. Họ cần không phải trang bán hàng, mà là tài liệu phạm vi: công việc là gì, hợp đồng công bằng viết ra sao, và giá bao nhiêu.

Đây là tài liệu đó. Nó nêu công việc site Drupal cần mỗi tháng, các sự thật vận hành quyết định hợp đồng bảo trì có đáng tiền, và khoảng giá thực tế tại Anh. Hãy đọc nó cạnh bản đề xuất của bên cung cấp: phần hữu ích là thấy đề xuất thiếu câu trả lời nào.

Hai điều khiến Drupal khác bảo trì web thông thường. Khuyến cáo bảo mật chạy theo lịch công bố, nên khoảng phơi nhiễm đo được và viết được vào hợp đồng. Và site Drupal là tập hợp mô-đun đóng góp với người bảo trì độc lập, nên phải có ai đó theo hộ bạn đích nâng cấp luôn dịch chuyển.

Hợp đồng bảo trì Drupal nên bao gồm gì? Giám sát khuyến cáo bảo mật khớp bộ mô-đun của bạn, cập nhật nhân và mô-đun đóng góp theo chu kỳ định sẵn qua staging, kiểm chứng sao lưu khôi phục được thật, giám sát uptime và lỗi ứng dụng, cùng ngân sách thay đổi ghi rõ. Tại Anh, mức đó chạy từ khoảng 250 bảng mỗi tháng cho site giới thiệu đơn giản tới hơn 2.000 bảng cho site phức tạp. Dưới mức đó, bạn mua giám sát chứ không phải hỗ trợ.

Hỗ trợ Drupal thực chất là gì, tính theo từng tháng

Hỏi giá ba agency, bạn sẽ nhận ba gói tên là Essential, Business và Enterprise, mỗi gói là một danh sách danh từ. Danh từ không phải công việc. Công việc là một tập tác vụ lặp lại, hoặc diễn ra theo lịch hoặc không hề diễn ra, và cách làm hữu ích là buộc bên cung cấp mô tả từng thứ như một hoạt động, có người phụ trách và có tần suất.

Có tám hoạt động như vậy. Giám sát và vá theo khuyến cáo bảo mật. Cập nhật nhân và mô-đun đóng góp. Nâng cấp phụ thuộc và phiên bản nền tảng. Kiểm chứng sao lưu và diễn tập khôi phục. Giám sát uptime và lỗi ứng dụng. Kiểm tra suy giảm hiệu năng. Hỗ trợ nội dung và biên tập. Cùng một ngân sách thay đổi cho những việc nhỏ luôn xuất hiện.

Hợp đồng nêu đủ tám thứ chưa chắc đã tốt, nhưng hợp đồng chỉ nêu bốn thì chắc chắn thiếu, và bốn thứ bị cắt gần như luôn giống nhau: diễn tập khôi phục, suy giảm hiệu năng, nâng cấp nền tảng và ngân sách thay đổi. Đó đều là những thứ tốn tiền, nên chúng biến mất.

Vì sao tên gói che mất công việc

“Phiếu hỗ trợ không giới hạn” không nói ai sẽ vá bảo mật cho nhân vào thứ Tư thứ ba của tháng. “Giám sát chủ động” không nói hai giờ sáng có người đọc cảnh báo hay nó nằm chờ tới thứ Hai. “Nỗ lực tối đa” thì không nói gì cả.

Hãy thay mỗi cụm bằng ba dữ kiện: hoạt động, tần suất, và vai trò có tên thực hiện nó. Phần lớn trang giới thiệu gói tan chảy dưới cách xử lý đó, còn những bên trụ lại mới đáng để nói chuyện tiếp.

Khung thời gian vá chính là toàn bộ sản phẩm

Drupal phát hành bản bảo mật theo lịch, điều này hiếm và cực kỳ hữu ích. Bản bảo mật cho nhân ra trong khung thứ Tư thứ ba của tháng , bắt đầu lúc 1200 giờ America/New York, tức 1600 hoặc 1700 UTC tùy mùa. Các dự án đóng góp có khung phát hành bảo mật mọi thứ Tư , nên khuyến cáo cho dự án đóng góp đến thường xuyên hơn nhiều so với nhân, và đến theo lô.

Hệ quả là lỗ hổng tự nó không phải rủi ro. Mọi người chạy Drupal nhận cùng một lỗ hổng vào cùng một thời điểm, công bố công khai. Rủi ro nằm ở khoảng trống giữa lúc khuyến cáo lên mạng và lúc bản vá có mặt trên production, vì trong khoảng đó lỗi đã được ghi chép, đánh chỉ mục và đang bị dò bởi những người đọc khuyến cáo nhanh hơn bên cung cấp của bạn.

So với số giờ của khoảng trống ấy, mọi điều khoản khác trong hợp đồng hỗ trợ chỉ là trang trí. Nên câu hỏi đầu tiên dành cho một bên cung cấp tiềm năng là bài toán số học, không phải triết học. Thứ Tư thứ ba tháng sau, mấy giờ sẽ có người đọc khuyến cáo, và bao giờ bản vá lên production? “Trong phạm vi SLA tiêu chuẩn của chúng tôi” không trả lời câu hỏi đó.

Drupal chấm điểm rủi ro thế nào, và điều đó nên làm gì với hợp đồng

Mọi khuyến cáo Drupal đều mang một con số, và con số đó là công cụ soạn điều khoản bị bỏ phí nhất trên nền tảng này. Drupal chấm lỗ hổng bằng Hệ thống chấm điểm lạm dụng chung của NIST, tức NISTIR 7864 , cho ra điểm từ 0 đến 25 trên sáu chỉ số: độ phức tạp của tấn công, yêu cầu xác thực, ảnh hưởng tới tính bí mật, ảnh hưởng tới tính toàn vẹn, mức sẵn có của mã khai thác, và độ phổ biến của mục tiêu.

Điểm ánh xạ sang năm nhãn công khai. Từ 0 đến 4 là không nghiêm trọng, 5 đến 9 là ít nghiêm trọng, 10 đến 14 là nghiêm trọng vừa, 15 đến 19 là nghiêm trọng, và 20 đến 25 là cực kỳ nghiêm trọng. Các mức đó công khai, ổn định và không để bên nào tự diễn giải.

Điều đó biến chúng thành xương sống tự nhiên cho một SLA hỗ trợ, vậy mà gần như không ai dùng. Thay vì bịa ra định nghĩa mức độ riêng để rồi bên cung cấp cãi lại sau, hãy viết cam kết phản hồi thẳng theo điểm Drupal: cực kỳ nghiêm trọng vá trong số giờ đã nêu kể cả ngoài giờ, nghiêm trọng trong một ngày làm việc, nghiêm trọng vừa vào chu kỳ kế tiếp, còn lại gộp lô. Không bên nào được lôi lại chuyện “khẩn cấp” nghĩa là gì, vì một bên thứ ba đã quyết hộ rồi.

Cực kỳ nghiêm trọng là một sự kiện vận hành khác hẳn

Bản nhân cực kỳ nghiêm trọng rất hiếm, và Drupal xử lý chúng khác đi. Đội bảo mật đăng trước một thông báo dịch vụ công để chủ site kịp thu xếp người trực. PSA-2026-05-18 đã làm đúng vậy, cảnh báo ngày 18 tháng 5 năm 2026 về một bản nhân cực kỳ nghiêm trọng dự kiến ra thứ Tư ngày 20 tháng 5, ảnh hưởng mọi nhánh được hỗ trợ.

Chính lời báo trước đó là thứ hợp đồng bảo trì nên xoay quanh, vì nó biến một tình huống khẩn cấp thành một lịch hẹn. Bên cung cấp biết về PSA từ thứ Hai và đã giữ sẵn khung triển khai cho thứ Tư là bên đang vận hành dịch vụ hỗ trợ. Bên đến thứ Năm mới biết thì đang vận hành một danh sách gửi thư.

Còn một biện pháp giảm nhẹ đáng biết. Drupal Steward là tường lửa ứng dụng web trả phí, phân tán toàn cầu, do Hiệp hội Drupal và đội bảo mật vận hành, cung cấp vá ảo ở tầng mạng cho các lỗ hổng nhân cực kỳ nghiêm trọng, để site được che chắn trong lúc bản cập nhật còn đang thử. Giá công bố bằng đô la Mỹ và tăng theo lưu lượng: dưới 20 đô la mỗi tháng cho site phục vụ khoảng 1 triệu yêu cầu HTTP, dưới 100 đô la mỗi tháng khi vượt 10 triệu. Nó mua thời gian chứ không mua miễn nhiễm, và hợp đồng tốt sẽ ghi rõ ai trả khoản đó.

Điều chính sách khuyến cáo bảo mật không bao phủ

Ba ngoại lệ trong chính sách quy trình và quyền hạn về khuyến cáo bảo mật thay đổi việc mà một hợp đồng bảo trì phải làm, và hầu hết hợp đồng hỗ trợ im lặng về cả ba.

Khuyến cáo chỉ phát cho bản phát hành ổn định. Nếu một mô-đun trên site đang chạy bản alpha, beta, ứng viên phát hành hay bản dev, sẽ không bao giờ có khuyến cáo cho nó, và việc không có tin tức chẳng nói lên điều gì. Phạm vi bao phủ cũng là đăng ký tự nguyện theo từng dự án chứ không tự động, nên một mô-đun đóng góp ngoài phạm vi có thể ôm một lỗi đã biết mà không có kênh thông báo nào.

Rồi tới điều hay khiến người ta vấp: không có khuyến cáo nào cho thư viện bên ngoài, kể cả khi một dự án đóng góp bắt bạn cài nó. Thư viện JavaScript hay PHP được kéo vào như một phụ thuộc là vấn đề của bạn, do bạn theo dõi, và nó sẽ không xuất hiện trong nguồn tin Drupal.

Phạm vi bao phủ cũng có thể bị rút

Bao phủ bảo mật không vĩnh viễn. PSA-2026-07-22 đã rút bao phủ khuyến cáo khỏi mô-đun QA Accounts, với lý do nó đặt sự tiện dụng lên trên bảo mật và chỉ dành cho những site không truy cập được từ internet.

Rủi ro có hình dạng như vậy. Một mô-đun bạn cài nhiều năm trước khi còn được bao phủ có thể lặng lẽ mất bao phủ, mà trên site không có gì thay đổi để báo cho bạn. Giữ một bản kiểm kê mọi dự án đã cài kèm trạng thái bao phủ hiện tại và độ ổn định của bản phát hành là công việc lặp lại thật sự, và nó thuộc về hợp đồng, bằng văn bản.

Nâng cấp phụ thuộc và nền tảng cũng là việc hỗ trợ

Hạng mục hay bị loại nhất khỏi hợp đồng hỗ trợ Drupal lại chính là hạng mục cuối cùng quyết định site có sống nổi hay không. Yêu cầu nền tảng của Drupal dịch chuyển, và dịch chuyển theo những bậc cần đổi hosting chứ không phải một lệnh composer update.

Về PHP, Drupal 10 cần tối thiểu PHP 8.1 , còn Drupal 11 đã lấy PHP 8.3 làm mức tối thiểu kể từ 11.1. Hỗ trợ PHP 8.5 xuất hiện ở Drupal 11.3, và Drupal 12.0 chỉ hỗ trợ PHP 8.5. Chi tiết cuối quan trọng hơn vẻ ngoài: một site đang thoải mái trên PHP 8.1 hôm nay còn cách Drupal 12 hai lần buộc phải dời nền tảng.

Yêu cầu cơ sở dữ liệu cũng dịch xa như vậy. Drupal 11 cần MySQL 8.0 trở lên, MariaDB 10.6 trở lên, PostgreSQL 16 trở lên, hoặc SQLite 3.45 trở lên. Drupal 10 còn chấp nhận MySQL 5.7.8, MariaDB 10.3.7 và PostgreSQL 12. Một host được quản lý vẫn phục vụ MySQL 5.7 là vật cản trên đường nâng cấp chứ không phải tiểu tiết, và ghi chép của chúng tôi về thứ gì thực sự chạy Drupal tốt nói rõ nên chuyển đi đâu.

Vòng đời Drupal 10 kết thúc đã là vấn đề của hợp đồng bảo trì

Drupal 10 hết vòng đời vào ngày 9 tháng 12 năm 2026 , và Drupal 12 ra trong cùng tuần đó, tuần bắt đầu ngày 7 tháng 12 năm 2026. Hỗ trợ bảo mật cho nhánh 11.3.x và 10.6.x cũng kết thúc tại thời điểm ấy. Tính đến tháng 9 năm 2026, các nhánh còn nhận bản bảo mật là 11.4.x, 11.3.x và 10.6.x.

Đối chiếu với lịch, đó là khoảng ba tháng. Bất kỳ site Drupal 10 nào chưa có kế hoạch nâng cấp kèm báo giá trong tháng 9 năm 2026 sẽ dành tháng 12 để hoặc trả phí gấp, hoặc chạy không hỗ trợ, và lựa chọn thứ hai nên là quyết định có chủ ý chứ không phải hệ quả của việc trôi đi.

Một hợp đồng xứng với phí của nó lẽ ra đã cho ra bốn thứ: báo cáo tình trạng nâng cấp hiện tại, một lượt quét mã lỗi thời trong mô-đun tự viết và giao diện, một lượt kiểm tra mức sẵn sàng của mọi mô-đun đóng góp với Drupal 11 và 12, cùng một ước tính bằng văn bản. Nếu bên cung cấp chưa đưa ra thứ nào, đó chính là kết luận. Phân tích của chúng tôi về chi phí, lựa chọn và hạn chót khi chuyển đổi Drupal nêu rõ công việc gồm những gì, và cùng cách hoạch định đó nằm trong các dự án phát triển website của chúng tôi.

Sao lưu chẳng đáng gì cho tới khi khôi phục được thử

Gần như mọi hợp đồng hỗ trợ Drupal đều hứa sao lưu. Rất ít hợp đồng hứa khôi phục, và khác biệt đó là toàn bộ giá trị của dòng đấy. Trung tâm An ninh mạng Quốc gia Anh nói thẳng trong hướng dẫn cho tổ chức nhỏ: khi đã tạo bản sao lưu , bạn cần biết cách khôi phục nó và kiểm tra xem nó có chứa mọi thứ quan trọng hay không.

Một lần khôi phục Drupal có ba bộ phận, và bản sao lưu thiếu sót thất bại ở bộ phận thứ hai với tần suất đều đến chán ngán. Bạn cần cơ sở dữ liệu, thư mục tệp công khai lẫn riêng tư, và cấu hình. Bản sao lưu bắt được cơ sở dữ liệu nhưng bỏ thư mục tệp sẽ khôi phục ra một site nội dung nguyên vẹn mà không có ảnh: với script giám sát thì đó là site chạy tốt, với khách hàng thì đó là thảm họa.

Hãy yêu cầu một lần diễn tập khôi phục có ghi ngày, thực hiện trên môi trường dùng một lần, kèm ghi chú bằng văn bản về thời gian mất bao lâu và thiếu những gì. Mỗi quý một lần là tần suất hợp lý với đa số site. Nếu bên cung cấp chưa từng làm, họ không biết thời gian phục hồi của chính họ, và bạn cũng vậy.

Giám sát uptime và lỗi, và uptime thực sự đo cái gì

Có một khoảng cách lớn giữa máy chủ còn sống và site còn dùng được, và Drupal nằm gọn trong đó. Một lỗi nghiêm trọng của PHP, một giới hạn bộ nhớ cạn kiệt, một kết nối cơ sở dữ liệu hỏng hay một lần dựng lại bộ nhớ đệm thất bại đều tạo ra trang mà phép kiểm tra ngây thơ đọc thành thành công, hoặc một mã 500 trơ trọi mà không ai canh.

Giám sát đo ở tầng máy chủ cho bạn biết cái máy có phản hồi. Giám sát đo ở tầng ứng dụng yêu cầu một trang thật, đi theo chuyển hướng, và khẳng định nội dung mong đợi có mặt trong phần thân phản hồi. Đó là hai sản phẩm khác giá, và một đề xuất chỉ ghi “giám sát uptime” mà không nói loại nào đang mô tả loại rẻ hơn.

Bên dưới đó là nhật ký của chính Drupal. Báo cáo thông điệp nhật ký gần đây và nhật ký lỗi PHP là nơi một lượt cron hỏng, một hàm lỗi thời hay một mô-đun ném ngoại lệ ở mọi yêu cầu sẽ lộ ra rất lâu trước khi khách phàn nàn. Phải có người đọc chúng theo lịch. Bài của chúng tôi về SLA uptime có ý nghĩa nói rõ các con số phần trăm quy ra bao nhiêu phút được phép.

Đọc một SLA hỗ trợ Drupal bằng con mắt phê phán

Phần lớn SLA hỗ trợ được viết để được ký chứ không phải để được dùng, và chúng được ký vì chúng được đọc rất nhanh. Ba điều khoản gánh gần hết trọng lượng, và đọc kỹ chúng chỉ mất mười phút.

Thời gian phản hồi không phải thời gian xử lý xong

Một SLA hứa phản hồi hai giờ thường chỉ hứa sẽ có người xác nhận phiếu trong hai giờ. Nó không hứa ai đó nhìn vào site của bạn. Bên cung cấp nghiêm túc sẽ cam kết một mốc xử lý xong, hoặc tối thiểu một mốc cho chẩn đoán và giải pháp tạm, với thời gian sửa nêu riêng.

Khi công việc thực sự không thể đóng khung thời gian, hợp đồng trung thực sẽ nói vậy và cam kết nỗ lực liên tục cho tới khi xong. Đó là cam kết thật. “Phản hồi hai giờ” đứng một mình là cam kết gửi một email.

Định nghĩa mức độ nghiêm trọng quyết định tất cả

Mọi SLA đều có bảng mức độ nghiêm trọng, và thường chính bên cung cấp là bên gán mức. Đó là kẽ hở. Nếu định nghĩa Mức 1 là “site không truy cập được”, thì một quy trình thanh toán hỏng với một phần ba khách hàng sẽ là Mức 3 và tuần sau mới được xem.

Hãy viết định nghĩa quanh tác động kinh doanh thay vì trạng thái kỹ thuật, và đưa ví dụ cụ thể vào hợp đồng: một bước thanh toán hỏng, một trang đăng nhập quản trị không vào được, một biểu mẫu liên hệ hỏng trên trang hỏi giá. Rồi thống nhất ai gán mức và bạn khiếu nại một lần gán ra sao.

Giờ trực không phải giờ hành chính

“Giờ hành chính” và “giờ trực” chỉ hai thứ khác nhau nhưng hay bị dùng lẫn. Giờ trực là quãng thời gian đồng hồ chạy và có người có nghĩa vụ hành động. Nếu giờ trực là 09:00 đến 17:30 các ngày làm việc, thì một khuyến cáo công bố lúc 1700 UTC vào một thứ Tư tháng 12 sớm nhất cũng phải sáng hôm sau mới có người nhận.

Riêng với Drupal, hãy để ý khung bảo mật cho nhân mở lúc 1600 hoặc 1700 UTC. Một bên cung cấp ở Anh có giờ trực kết thúc lúc 17:30 nằm ngay rìa khung đó về mặt cấu trúc, nên thu xếp ngoài giờ cho khuyến cáo cực kỳ nghiêm trọng cần được nêu tên riêng và tính giá riêng.

Cái gì được tính là sự cố, và cái gì bị loại trừ

Phần loại trừ là nơi một hợp đồng bảo trì lặng lẽ rẻ đi so với vẻ ngoài. Các loại trừ thông thường hoàn toàn hợp lý khi đứng riêng và bất hợp lý khi ghép lại: lỗi hosting của bên thứ ba, sự cố do nhân viên khách hàng gây ra, trục trặc ở mô-đun không do bên cung cấp cài, mọi thứ dính tới giao diện trả phí, và mọi thứ bên cung cấp xếp là thay đổi chứ không phải lỗi.

Cái cuối là lưỡi dao. Nếu sửa một lỗi cần đổi cấu hình, mà đổi cấu hình thì tính phí, thì gần như mọi sự cố đều có thể xếp lại sang cột tính phí. Hãy hỏi thẳng họ phân biệt lỗi với thay đổi ra sao, và xin hai ví dụ mỗi loại từ chính công việc gần đây của họ.

Cũng cần xem chuyện gì xảy ra với bên thứ ba. Khi cổng thanh toán, trình kết nối CRM hay nhà cung cấp hosting mới là bên có lỗi, họ điều phối việc sửa hay phiếu bị đóng vì ngoài phạm vi? Điều phối là công việc thật và đáng trả tiền, nhưng chỉ khi hợp đồng nói rằng nó có xảy ra.

Ba mô hình hợp đồng bảo trì, so sánh một cách trung thực

Gần như mọi thỏa thuận hỗ trợ Drupal đều thuộc một trong ba hình dạng, và mỗi hình dạng là câu trả lời hợp lý cho một hoàn cảnh khác nhau. Sai lầm là mua hình dạng này mà kỳ vọng hành vi của hình dạng kia.

Số giờ cố định mỗi tháng

Bạn mua một khối giờ, chẳng hạn tám hoặc mười sáu, và bên cung cấp dùng chúng cho bất cứ việc gì bạn yêu cầu. Nó minh bạch, dễ so báo giá, và hợp với tổ chức có dòng thay đổi nhỏ đều đặn cùng một người nội bộ đủ sức xếp thứ tự ưu tiên.

Điểm yếu là bảo trì phải tranh cùng một túi giờ với tính năng. Trong tháng bận, việc vá bảo mật lặng lẽ thua trang đích của chiến dịch, vì người tiêu giờ có hạn chót còn bản vá thì không tạo cảm giác đó. Nếu mua mô hình này, hãy khoanh sẵn một phần số giờ cho bảo trì ngay trong hợp đồng.

Sửa lỗi không giới hạn cộng thay đổi báo giá riêng

Bên cung cấp gánh bảo trì và sửa lỗi nhỏ với một phí cố định hằng tháng, còn mọi thứ vượt ngưỡng đã thỏa thuận thì báo giá riêng. Đây là mô hình đa số agency đẩy tới, và với một site ổn định cùng người chủ hay lo thì nó thực sự là câu trả lời đúng, vì nó biến rủi ro biến thiên thành một dòng cố định trong ngân sách.

Điểm yếu là ranh giới. “Sửa nhỏ” chưa được định nghĩa cho tới khi có người cần nó, và ngưỡng dịch chuyển tùy tháng đó trôi ra sao. Hãy đòi một định nghĩa bằng văn bản, lý tưởng là một khung thời gian như dưới ba mươi phút, kèm báo cáo hằng tháng liệt kê những gì đã được gánh.

Thuần túy tính theo thời gian và vật tư

Không hợp đồng bảo trì, một đơn giá ngày, và làm việc khi bạn yêu cầu. Đây là lựa chọn trung thực cho một site rủi ro thấp có chủ thực sự chịu theo dõi cập nhật, và cho tổ chức có năng lực nội bộ chỉ cần trợ giúp chuyên môn thỉnh thoảng chứ không cần trực.

Điểm yếu là không có gì chủ động xảy ra, vì không ai được trả tiền để nhìn. Cách này cũng xếp hàng rất tệ: bạn cạnh tranh với khách có hợp đồng để giành cùng nhóm kỹ sư, nên vào ngày xấu, phản hồi tính bằng tuần chứ không bằng giờ.

Vấn đề động cơ trong hỗ trợ không đo đếm

Hỗ trợ không đo đếm có một vấn đề cấu trúc mà không ai trong ngành thích bàn. Nếu bên cung cấp nhận tiền như nhau bất kể site ngốn bao nhiêu giờ, thì mỗi giờ bỏ vào site của bạn đều bào mòn biên lợi nhuận của họ, và hành vi hợp lý về mặt thương mại là bỏ ra càng ít càng tốt.

Điều đó thường không lộ ra thành bỏ bê. Nó lộ ra thành thiên vị cách sửa nhanh thay vì cách sửa đúng, dập triệu chứng thay vì truy nguyên nhân, và hoãn lần nâng cấp mô-đun đòi cả ngày kiểm thử hồi quy. Nó cũng lộ ra theo chiều ngược lại ở các gói rẻ, nơi mức phí chỉ hợp lý nếu site thật sự không bao giờ bị đụng tới.

Đối trọng là nghĩa vụ báo cáo. Một báo cáo hằng tháng liệt kê số giờ đã dùng, bản cập nhật đã áp, khuyến cáo đã đánh giá và phiếu đã đóng làm cho mức tiêu thụ hiện rõ với cả hai bên, và biến một tài khoản lỗ thành một cuộc trò chuyện thay vì một đợt tụt dốc dịch vụ chậm rãi. Bên nào tự tin vào mô hình này đều sẽ đồng ý. Bên nào chống lại là đang cho bạn biết mô hình đó thực chất phục vụ điều gì.

Làm tốt về mặt vận hành trông ra sao

Ba thói quen kỹ thuật tách một bên cung cấp Drupal có thể đỡ site của bạn an toàn khỏi một bên đang ứng biến. Không thứ nào lạ lẫm, và cả ba đều dễ hỏi.

Composer, hoặc không gì cả

Tài liệu của chính Drupal nói thẳng về việc trộn các cách cập nhật, cảnh báo rằng site có thể gặp sự cố cập nhật nghiêm trọng nếu cập nhật bằng Composer bị trộn với cách khác, và rằng một khi Composer quản một mô-đun thì nó cũng phải quản nhân. Một bên còn tải thư mục mô-đun lên bằng FTP sớm muộn sẽ xóa mất thư mục vendor mà một mô-đun đóng góp phụ thuộc vào.

Hãy hỏi composer.json và composer.lock có nằm trong quản lý phiên bản không, và Composer chạy trên production hay bạn triển khai một sản phẩm đã dựng sẵn. Câu trả lời nào cũng có thể đúng. Không có câu trả lời thì không thể đúng.

Một môi trường staging khớp với production

Một site staging chạy phiên bản PHP khác, phiên bản cơ sở dữ liệu khác hay bộ mô-đun khác thì không kiểm chứng được điều gì hữu ích. Ý nghĩa của staging là để một bản vá bảo mật hỏng ở nơi không tốn tiền, và nó chỉ làm được vậy khi hai môi trường khớp nhau trên đúng những trục hay vỡ.

Hãy hỏi staging được làm mới từ production thế nào, bao lâu một lần, và nó có giữ một bản sao đã khử nhạy cảm của nội dung thật hay không. Một site staging với ba nút thử sẽ không lộ ra bản cập nhật làm vỡ một view chạy trên 40.000 hàng.

Cấu hình nằm trong quản lý phiên bản

Drupal mặc định giữ cấu hình trong cơ sở dữ liệu , và hệ thống quản lý cấu hình tồn tại để xuất nó ra các tệp có thể commit, xem xét và nhập vào môi trường khác. Đội dùng nó tái lập được thiết lập của site một cách tất định. Đội không dùng nó thì đang bấm qua các màn hình quản trị trên production và cầu may.

Đây là tín hiệu rõ nhất trong một cuộc nói chuyện với bên cung cấp. Hãy hỏi một thay đổi làm trên staging đi tới production bằng cách nào. Nếu câu trả lời là một lời mô tả chứ không phải một khoảng lặng, phần còn lại của cuộc trò chuyện thường ổn.

Nếu họ không mô tả nổi việc triển khai, đó chính là câu trả lời

Không có cách nói nào lịch sự cho chuyện này. Một bên không thể mô tả, trong một phút thong thả, mã đi từ máy lập trình viên tới site đang chạy của bạn ra sao là đang nói với bạn rằng việc triển khai của họ là ứng biến. Triển khai ứng biến chính là lý do các bản vá bảo mật bị hoãn: không ai muốn chạy một quy trình thủ công đầy rủi ro vào tối thứ Tư.

Điều khoản bàn giao mà không ai đọc

Sẽ tới lúc bạn đổi bên cung cấp, và điều khoản chi phối khoảnh khắc đó được viết khi mọi người còn thân thiện và được đọc khi không ai thân thiện nữa. Nó nên nói rõ bốn điều.

Ai sở hữu mã, gồm cả mô-đun tự viết và phần giao diện, và theo giấy phép nào. Kho mã nằm ở đâu và quyền truy cập chuyển giao ra sao. Rằng một bản xuất đầy đủ cơ sở dữ liệu, tệp và cấu hình sẽ được cung cấp theo định dạng đã nêu, trong số ngày làm việc đã nêu. Và rằng thông tin đăng nhập DNS, hosting cùng dịch vụ bên thứ ba được trao lại chứ không bị giữ.

Kiểu thất bại thường không phải ác ý. Đó là một bên đặt site của bạn trên tài khoản của chính họ, giữ bản sao duy nhất của kho mã, và mất sáu tuần mới trả lời vì bạn không còn là khách trả tiền. Hãy xin điều khoản bàn giao trước khi ký, và coi sự miễn cưỡng là thông tin.

Drupal 7: hết vòng đời, hỗ trợ mở rộng, và khoảng cách giữa hai thứ đó

Hỗ trợ bảo mật cho Drupal 7 đã kết thúc ngày 5 tháng 1 năm 2025 . Cộng đồng ngừng làm bản vá, và hệ sinh thái mô-đun đóng góp khổng lồ từng khiến Drupal 7 hữu dụng cũng ngừng được bảo trì theo.

Hiệp hội Drupal vận hành một chương trình nhà cung cấp hỗ trợ bảo mật mở rộng, và HeroDevs cùng Tag1 Consulting là các đơn vị được chứng nhận theo chương trình đó. Mua gói hỗ trợ ấy là quyết định chính đáng cho tổ chức thực sự không thể chuyển đổi trong năm nay, và nó tốt hơn hẳn so với không có gì.

Thứ nó không làm được là khiến site an toàn theo nghĩa thông thường. Một đơn vị thương mại vá những lỗ hổng họ tìm ra hoặc được báo, theo lịch của riêng họ, cho bộ mô-đun họ đã đồng ý bao phủ. Nó không khôi phục quy trình khuyến cáo công khai, không bao phủ mọi mô-đun đóng góp bạn tình cờ đang cài, và không vươn tới các thư viện bên ngoài mà những mô-đun đó phụ thuộc vào. Hỗ trợ mở rộng là cách chạy một nền tảng không còn hỗ trợ trong tầm kiểm soát, và một hợp đồng hỗ trợ không đồng nghĩa với an toàn.

Nếu tháng 9 năm 2026 bạn vẫn ở trên Drupal 7, lời khuyên trung thực là tiêu tiền cho việc chuyển đổi thay vì cho tiền thuê. Hướng dẫn phát triển web Drupal năm 2026 của chúng tôi nói về nền tảng như hiện tại, còn chi tiết sâu hơn về quy trình khuyến cáo nằm trong bài bảo mật Drupal, khuyến cáo và rủi ro thật .

Hỗ trợ nội dung và ngân sách thay đổi

Hai hạng mục bị đẩy khỏi hợp đồng hỗ trợ vì khó khoanh vùng, và cả hai đều là thứ khách hàng thực sự cảm nhận được.

Hỗ trợ nội dung và biên tập nghĩa là có người thêm được một loại nội dung, sửa được một view lọc sai, đào tạo lại biên tập viên sau khi nhân sự thay đổi, hoặc tìm ra vì sao một kiểu ảnh đang cắt mất mặt người. Nó ít kịch tính và tần suất cao, và một hợp đồng thiếu nó sẽ tạo ra khách hàng thôi hỏi và bắt đầu làm vòng qua site.

Ngân sách thay đổi là nửa còn lại. Site nào cũng tích lại một hàng chờ việc nhỏ: thêm một trường trên biểu mẫu, một chuyển hướng sau khi dời trang, đổi người nhận thư hỏi giá. Đặt tên cho hàng chờ đó bằng một hạn mức giờ hằng tháng là thứ ngăn nó thành dự án khẩn cấp mỗi quý. Hai tới bốn giờ mỗi tháng là con số thực tế với site nhỏ, tám tới mười sáu giờ với site bận rộn.

Hỗ trợ Drupal tốn bao nhiêu tại Anh

Các con số dưới đây là ước tính nội bộ năm 2026, dựa trên công việc thực tế của agency Anh chứ không phải khảo sát công bố, và giả định bên cung cấp làm đủ tám hoạt động nêu trên chứ không bán gói giám sát kèm hộp thư.

Site giới thiệu nhỏ nằm khoảng 250 đến 600 bảng mỗi tháng, đủ cho giám sát khuyến cáo, chu kỳ vá hằng tháng, kiểm chứng sao lưu và một hai giờ thay đổi. Site cỡ vừa có tích hợp chạy quanh 700 đến 1.800 bảng, vì mỗi tích hợp thêm một bề mặt hồi quy phải kiểm lại sau mỗi bản cập nhật nhân. Site phức tạp hay đa ngôn ngữ có mã tự viết bắt đầu quanh 2.000 bảng và lên tới 6.000 bảng.

Thỏa thuận chỉ giám sát, khi bên cung cấp canh khuyến cáo và báo thứ nào áp dụng nhưng không triển khai, thấp hơn: khoảng 250 đến 450 bảng. Đặt cạnh đơn giá ngày 600 đến 900 bảng của agency Anh, hợp đồng 1.500 bảng mua gần hai ngày kỹ sư. Chi tiết ở bài đơn giá và cách thẩm định lập trình viên Drupal , ngân sách rộng hơn ở chi phí bảo trì phần mềm .

Điều gì đẩy một site từ khoảng này sang khoảng kế tiếp

Bản năng là định giá hỗ trợ theo lưu lượng, mà lưu lượng thì gần như không liên quan. Một site 200.000 lượt truy cập mỗi tháng với hai mươi mô-đun và không tích hợp lại rẻ hơn một site 2.000 lượt có trình kết nối CRM, cổng thanh toán và một lần chuyển đổi tự viết.

Ba thứ mới thực sự đẩy chi phí. Số mô-đun, vì mỗi mô-đun đóng góp là một nguồn khuyến cáo phải canh và một rủi ro tương thích ở mỗi lần cập nhật nhân. Số tích hợp, vì mỗi cái là một hợp đồng bên ngoài có thể đổi dưới chân bạn và một lượt kiểm thử hồi quy phải chạy lại. Và lượng biên tập, vì một nhóm biên tập bận rộn sinh ra câu hỏi hỗ trợ, thay đổi phân quyền và chỉnh mô hình nội dung với nhịp đều đặn.

Mã tự viết là hệ số nhân trên cả ba. Một site có 12.000 dòng mã mô-đun tự viết cần một lượt quét mã lỗi thời và một lượt hồi quy ở mỗi bản phát hành nhỏ, tức một ngày công mà site thuần mô-đun đóng góp không phải chịu. Khoảng giá cao nhất sinh ra từ đó, và đó là phần việc các dự án phát triển phần mềm của chúng tôi thường được nhờ gánh.

Những câu nên hỏi một bên cung cấp tiềm năng

Sáu câu hỏi, cùng những câu trả lời đáng lo.

Site của chúng tôi đang chạy phiên bản Drupal và PHP nào, và lộ trình nâng cấp ra sao? Câu trả lời cần họ đi tra là ổn. Câu trả lời tới sau một tuần thì không. Các anh làm sao biết một khuyến cáo bảo mật áp dụng cho chúng tôi? “Chúng tôi theo dõi drupal.org” là câu yếu; thứ bạn muốn nghe là một bản kiểm kê mô-đun theo từng site.

Hãy dẫn tôi qua quy trình triển khai của các anh. Sự ngập ngừng ở đây là tín hiệu tiêu cực mạnh nhất trong cả cuộc trò chuyện. Lần gần nhất các anh khôi phục site này từ bản sao lưu là khi nào? “Chúng tôi sao lưu hằng ngày” không phải câu trả lời. Hợp đồng loại trừ những gì, và các anh quyết định một việc là lỗi hay là thay đổi bằng cách nào? Và cuối cùng: nếu chúng tôi rời đi, chúng tôi nhận được gì và nhanh đến đâu?

Chuyện gì xảy ra khi không có hợp đồng bảo trì

Đây là một trình tự hơn là một lời cảnh báo, và nó chạy với tốc độ gần như nhau trên mọi site Drupal không được hỗ trợ.

Vài tháng đầu không có gì xảy ra, và đó chính là vấn đề, vì nó dạy mọi người rằng chẳng cần gì xảy ra. Đâu đó giữa tháng thứ sáu và tháng thứ mười hai, đống cập nhật tồn đọng vượt qua điểm mà từ đó cập nhật không còn an toàn khi làm riêng lẻ, vì một mô-đun giờ cần nhân mới hơn, nhân cần PHP mới hơn, mà host không có. Áp một bản vá đã thành một dự án.

Rồi site trôi hẳn ra khỏi phạm vi hỗ trợ nền tảng, và một thay đổi của trình duyệt hay của PHP làm hỏng thứ gì đó nhìn thấy được. Việc sửa giờ bắt đầu bằng một lần nâng cấp không ai dự trù, báo giá như việc khẩn, và những phần site không có tài liệu bị dựng lại thay vì được sửa. Nếu trên đường đi xảy ra một vụ lộ dữ liệu cá nhân, ICO yêu cầu thông báo trong vòng 72 giờ kể từ khi biết, với các vụ có khả năng gây rủi ro cho quyền và tự do của con người, và đó là hạn chót bạn giữ được bằng nhật ký và bản sao lưu mà bạn hoặc có hoặc không.

Hóa đơn khắc phục luôn gấp nhiều lần hợp đồng lẽ ra đã ngăn được nó, và khác biệt không nằm ở công sức. Nó nằm ở chỗ việc có kế hoạch diễn ra vào thứ Ba kèm phương án quay lui, còn việc khẩn cấp diễn ra vào Chủ nhật mà không có.

Chốt đúng phạm vi trước khi ký

Mục đích của tất cả những điều trên không phải khiến bạn nghi ngờ các bên cung cấp. Nó là để việc so sánh hai bản đề xuất có ý nghĩa, vì hiện tại phần lớn báo giá hỗ trợ Drupal không thể so sánh ngay từ thiết kế: chữ khác nhau, loại trừ khác nhau, và không có định nghĩa chung về công việc hằng tháng là gì.

Hãy lấy tám hoạt động, các mức rủi ro của Drupal, ba mô hình hợp đồng và sáu câu hỏi, rồi đặt chúng cạnh thứ đang nằm trên bàn bạn. Cái gì sống sót qua đó mới là một đề xuất thật.

Mecanik hỗ trợ các site Drupal như một phần công việc phát triển website và phát triển phần mềm của chúng tôi, và lần làm việc đầu tiên thường là một cuộc kiểm kê chứ không phải một lần sửa, vì phần lớn site tìm đến chúng tôi không nói được mô-đun nào của mình còn được nguồn khuyến cáo bảo mật bao phủ.

Câu hỏi thường gặp

Hợp đồng bảo trì Drupal nên bao gồm những gì? Tám hoạt động: giám sát khuyến cáo bảo mật đúng với bộ mô-đun của bạn, cập nhật nhân và mô-đun đóng góp theo chu kỳ đã định, nâng cấp phụ thuộc và nền tảng PHP, kiểm chứng sao lưu kèm diễn tập khôi phục, giám sát uptime và lỗi ứng dụng, kiểm tra suy giảm hiệu năng, hỗ trợ biên tập, và một ngân sách thay đổi ghi rõ số giờ. Hợp đồng chỉ nêu bốn thứ là thiếu, và bốn thứ thường vắng mặt là diễn tập khôi phục, kiểm tra hiệu năng, nâng cấp nền tảng và ngân sách thay đổi.

Hỗ trợ Drupal tốn bao nhiêu mỗi tháng tại Anh? Theo ước tính nội bộ của chúng tôi cho năm 2026, một site giới thiệu nhỏ vào khoảng 250 đến 600 bảng mỗi tháng, một site cỡ vừa có một hai tích hợp là 700 đến 1.800 bảng, và một site đa ngôn ngữ phức tạp với mô-đun tự viết là 2.000 đến 6.000 bảng. Thỏa thuận chỉ giám sát nằm quanh 250 đến 450 bảng. So với đơn giá ngày 600 đến 900 bảng của agency Anh, hợp đồng 1.500 bảng mua được khoảng hai ngày công kỹ sư.

Drupal phát hành bản vá bảo mật khi nào? Bản bảo mật cho nhân Drupal ra trong khung thứ Tư thứ ba của tháng, bắt đầu lúc 1200 giờ America/New York, tức 1600 hoặc 1700 UTC tùy mùa. Các dự án đóng góp có khung phát hành bảo mật vào mọi thứ Tư. Trước các bản nhân cực kỳ nghiêm trọng luôn có một thông báo dịch vụ công để chủ site kịp thu xếp người trực.

Hỗ trợ mở rộng cho Drupal 7 có đồng nghĩa với an toàn không? Không. Hỗ trợ bảo mật cho Drupal 7 đã kết thúc ngày 5 tháng 1 năm 2025, và Hiệp hội Drupal chứng nhận HeroDevs cùng Tag1 Consulting theo chương trình nhà cung cấp hỗ trợ bảo mật mở rộng. Các đơn vị đó vá những gì họ bao phủ, theo lịch riêng của họ, cho một bộ mô-đun đã thỏa thuận. Nó không khôi phục quy trình khuyến cáo công khai, không bao phủ mọi mô-đun đóng góp bạn đang cài, cũng không vươn tới thư viện bên ngoài.

Drupal 10 hết vòng đời khi nào? Drupal 10 hết vòng đời vào ngày 9 tháng 12 năm 2026, trong chính tuần Drupal 12 được phát hành, tuần bắt đầu ngày 7 tháng 12 năm 2026. Hỗ trợ bảo mật cho nhánh 11.3.x và 10.6.x kết thúc cùng thời điểm. Drupal 12 chỉ hỗ trợ PHP 8.5, nên các site dùng PHP cũ hơn cần đổi hosting trước khi nâng cấp chứ không phải sau.