Bắt đầu từ khối lượng công việc của bạn, không phải một gói lưu trữ
Liệt kê các hành trình tạo giá trị hoặc rủi ro: lần truy cập đầu, tìm kiếm, đăng nhập, chi tiết sản phẩm, gửi biểu mẫu, thanh toán, cập nhật trình soạn thảo hoặc gọi API. Với mỗi hành trình, ghi lại số lượng yêu cầu đỉnh hoặc người dùng đồng thời, kích thước payload, cá nhân hóa, phụ thuộc và vùng khách truy cập. Bao gồm công việc theo lịch và quản trị vì chúng tiêu thụ cùng tài nguyên.
Chuyển danh sách thành các tiêu chí chấp nhận. Largest Contentful Paint (LCP) đo việc tải nội dung chính; Interaction to Next Paint (INP) đo độ phản hồi; và Cumulative Layout Shift (CLS) đo dịch chuyển bất ngờ. Google mô tả ngưỡng tốt là LCP trong 2.5 giây, INP dưới 200 mili-giây và CLS dưới 0.1. Thêm các mục hoàn thành tuyến đường, thời gian phản hồi máy chủ và mục tiêu tỷ lệ lỗi.
Đừng để một trang nhanh được cache thay thế cho giao dịch yêu cầu xác thực hoặc truy vấn cơ sở dữ liệu.
Xác định khoảng đỉnh, tăng trưởng dự kiến, chiến dịch bùng nổ và công việc hàng loạt chồng chéo.
Đánh dấu xem nút thắt cổ chai có được kiểm soát bởi nhà cung cấp, đội của bạn hay bên thứ ba.
So sánh năng lực, giới hạn và hành vi mở rộng
Yêu cầu bảng giới hạn ẩn sau lời chào: CPU và bộ nhớ, hiệu năng lưu trữ, kết nối cơ sở dữ liệu, giới hạn worker, phí mạng, điều khiển yêu cầu và ràng buộc lân cận chia sẻ. “Băng thông không giới hạn” không cho biết ứng dụng có thể thực hiện đủ công việc không được cache vào thời điểm đỉnh hay không. Hỏi các chỉ số nào hiển thị và dữ liệu duy trì trong bao lâu.
Khả năng mở rộng chỉ có ý nghĩa khi biết được bộ kích hoạt, độ trễ, trần và giá. Xác nhận liệu nó có tự động, liệu phiên và công việc còn an toàn, và điều gì xảy ra khi đạt trần. Ưu tiên một bài kiểm tra tại đỉnh dự kiến và vượt quá để kiểm tra thực tế thay vì chỉ chấp nhận tuyên bố năng lực lý thuyết. Phần dự phòng là quyết định kinh doanh, không phải một tỷ lệ chuẩn chung.
So sánh thời gian phản hồi p95 hoặc p99, không chỉ trung bình.
Thu thập thời gian phản hồi của cơ sở dữ liệu, hàng đợi và API thượng nguồn trong quá trình kiểm tra.
Ước tính chi phí mở rộng, phân phối, sao lưu và vùng thứ hai trước khi cam kết.
Đặt origin có chủ đích và xác thực phân phối
Chọn vùng origin dựa trên vị trí khán giả, phụ thuộc ứng dụng, yêu cầu vị trí dữ liệu và quyền truy cập vận hành. Thử nghiệm từ các vùng địa lý và điều kiện mạng đại diện. Một mạng phân phối nội dung (CDN) là bộ nhớ đệm phân tán có thể phục vụ tài nguyên đủ điều kiện gần khách hơn và giảm tải origin; nó không thay thế origin, cơ sở dữ liệu hay ứng dụng khỏe mạnh.
Kiểm tra header và hành vi, không chỉ một cài đặt trên dashboard. Tài nguyên tĩnh có phiên bản thường có thể đặt thời gian sống dài hơn vì khi cập nhật sẽ có URL mới. Các phản hồi động và cá nhân hóa cần quy tắc rõ ràng. HTTP phân biệt cache chia sẻ và cache riêng; thông tin tài khoản không được tái sử dụng cho khách hàng khác. Diễn tập xóa cache (purge) và quay lui.
Ghi lại lần truy cập đầu và lần truy cập trở lại vì trạng thái cache khác nhau.
Xác minh Cache-Control và khóa cache cho trang, tài nguyên tĩnh, cookie, tham số và locale.
Ghi chép cách nhân viên được ủy quyền vô hiệu hóa một quy tắc có hại mà không phơi bày nội dung nhạy cảm.
Xem việc bằng chứng phục hồi như một yêu cầu về hiệu suất
Hỏi những gì được sao lưu, các bản sao sống ở đâu, thời hạn lưu trữ, quyền khôi phục và liệu bản sao lưu bao phủ cơ sở dữ liệu, upload, mã, cấu hình và hạ tầng không. Định nghĩa Recovery Point Objective (RPO) là dữ liệu mất chấp nhận được tính theo thời gian, và Recovery Time Objective (RTO) là thời gian phục hồi chấp nhận được. Đặt cả hai dựa trên hậu quả kinh doanh, không phải mặc định gói.
Một bản sao lưu thành công không phải là bằng chứng phục hồi. CISA khuyến nghị kiểm tra phục hồi theo lịch, và AWS nói phục hồi thảm họa cần được đánh giá và thử nghiệm. Phục hồi một bản sao gần đây trong môi trường cô lập, kiểm tra bản ghi và media quan trọng, sử dụng trình tự đã ghi, và ghi lại thời gian đã trôi. Một vùng thay thế có thể giảm một số rủi ro nhưng tăng chi phí và độ phức tạp.
Khôi phục một tệp hoặc bản ghi mà không ghi đè dữ liệu hiện tại.
Giới hạn quyền khôi phục và giữ thông tin đăng nhập phục hồi cùng runbook sẵn có cho người ứng phó được ủy quyền.
Một snapshot cơ sở dữ liệu có thể không tái tạo thiết lập, phiên bản ứng dụng hoặc quy tắc phân phối.
Đánh giá hỗ trợ và trách nhiệm chia sẻ trước khi cần đến nó
So sánh phạm vi hỗ trợ, giờ làm việc, kênh, leo thang và sự khác biệt giữa sự cố nền tảng và khắc phục ứng dụng. Yêu cầu trách nhiệm bằng văn bản cho việc vá, cơ sở dữ liệu được quản lý, TLS, quy tắc firewall, sao lưu và khôi phục. Một cam kết hỗ trợ hữu ích khi nó ghi rõ chủ sở hữu và hành động tiếp theo trong một kịch bản thực tế.
Xem xét vai trò truy cập, xác thực đa yếu tố, nhật ký kiểm toán, xử lý bí mật và cô lập tài khoản. Với thẻ thanh toán hoặc dữ liệu được điều chỉnh nhạy cảm, tính năng lưu trữ một mình không chứng minh tuân thủ. Dùng so sánh này như đầu vào kỹ thuật và lấy đánh giá bảo mật, pháp lý hoặc tuân thủ có thẩm quyền cho kiến trúc thanh toán và nghĩa vụ áp dụng.
Hỏi nhà cung cấp xử lý như thế nào khi restore thất bại, cơ sở dữ liệu bão hòa hoặc một quy tắc cache gây hại.
Kiểm tra ai có thể thay đổi production, đọc backup, xem logs và tạo credential.
Tín dụng dịch vụ và phạm vi quản lý có thể kèm điều kiện có ý nghĩa.
Chạy các bài kiểm tra so sánh thực tế, an toàn và giữ bảng điểm
Dùng cùng một release, ý định cấu hình và kịch bản kiểm thử cho mọi ứng viên. Chạy một baseline, đỉnh dự kiến, spike ngắn, thời gian duy trì và bài tập phục hồi hoặc triển khai an toàn. AWS khuyến nghị môi trường giống production, kịch bản định nghĩa, giám sát toàn kiến trúc, dữ liệu đã làm sạch hoặc tổng hợp, và kiểm tra định kỳ. Xin phép nhà cung cấp và tuân theo chính sách thử nghiệm của họ.
Kết hợp kiểm thử phòng lab có kiểm soát với dữ liệu thực trường sau khi ra mắt. Kiểm tra phòng lab lặp lại được để gỡ lỗi; dữ liệu thực phản ánh thiết bị, mạng, địa lý, trạng thái cache và hành vi thật. Xem lại bảng điểm sau các phát hành lớn hoặc thay đổi phụ thuộc. SIU có thể biến phát hiện thành gia cố trước khi ra mắt, sửa chữa phân công chủ sở hữu và cải tiến sẵn sàng quay lui.
Giữ nhất quán vị trí, đồng thời, trạng thái cache và payload.
Lưu thời gian tuyến đường, lỗi, chỉ số tài nguyên, phiên bản, chi phí và quan sát.
Chọn phương án đáp ứng nhu cầu đã ghi và có chi phí vận hành bền vững.
