Xác định sự sẵn sàng quanh kết quả của khách hàng
Bắt đầu với kết quả, không phải nhãn cơ sở hạ tầng. Một trang chủ có thể truy cập không đủ nếu người truy cập không thể hoàn thành nhiệm vụ quan trọng. Với mỗi hành trình quan trọng, nêu rõ ai đang cố gắng làm gì, thành công nghĩa là gì, và kết quả nào là không chấp nhận được. Bắt đầu với vài hành trình để đội có thể đưa ra quyết định thực tế.
Phân loại mỗi bước là thiết yếu, quan trọng, hoặc có thể trì hoãn. Thiết yếu nghĩa là hành trình không thể hoàn tất nếu thiếu nó; quan trọng có thể chấp nhận giải pháp tạm thời trong thời gian giới hạn; có thể trì hoãn thì có thể bỏ, hoãn hoặc đơn giản hóa. Đây là quyết định sản phẩm được thông tin bởi kỹ thuật, không phải một thứ hạng kỹ thuật phổ quát.
Ghi nhận một kết quả có thể sử dụng được, ví dụ đơn hàng được chấp nhận và xác nhận được lưu, thay vì chỉ đặt mục tiêu phản hồi trang.
Lập bản đồ phụ thuộc và quyết định phần nào có thể suy giảm
Với mỗi đường dẫn quan trọng, lập bản đồ hosting hoặc delivery, DNS, dịch vụ ứng dụng, cơ sở dữ liệu, xác thực, email, thanh toán, tìm kiếm, thẻ, công cụ consent, và API bên ngoài. Ghi nhận chủ sở hữu, đường hỗ trợ, giới hạn liên quan và ảnh hưởng đến người dùng nếu mỗi thành phần không sẵn có. OWASP khuyến nghị hiểu biết về phụ thuộc phần mềm; kỷ luật sở hữu tương tự giúp với phụ thuộc vận hành.
Phụ thuộc cứng là khi nó hỏng sẽ dừng nhiệm vụ. Phụ thuộc mềm có thể vắng mặt hoặc lỗi thời trong khi nhiệm vụ cốt lõi vẫn hoạt động. AWS mô tả giảm nhẹ (graceful degradation) như giữ chức năng cốt lõi hoạt động khi các phụ thuộc không khỏe. Xác định một lựa chọn theo sản phẩm: ẩn widget không thiết yếu, hoãn báo cáo, hoặc hiển thị giải pháp thay thế trung thực. Không được tự ý tạo danh mục tồn kho, giá cả, trạng thái đơn hàng hoặc kết quả thanh toán.
Ghi lại mục đích, chủ sở hữu, giới hạn đã biết, phương án dự phòng, liên hệ thay đổi và ngày kiểm tra gần nhất cho mỗi mục.
Biến dự báo lưu lượng thành thí nghiệm năng lực
Sử dụng một kịch bản, không chỉ một con số lưu lượng. Nêu rõ sự kiện, mô hình tới, hỗn hợp yêu cầu, tỷ lệ đăng nhập, địa lý, hoạt động thanh toán hoặc ghi đồng thời, và thời kỳ đỉnh. Bao gồm trường hợp cao và các giả định. Google lưu ý rằng các yêu cầu có thể có chi phí tài nguyên rất khác nhau, vì vậy requests per second (yêu cầu mỗi giây) một mình có thể là mô hình năng lực kém.
Kiểm tra lưu lượng đại diện, bền vững, đầu-cuối chống lại cấu hình gần với production, có phê duyệt và các biện pháp an toàn. AWS cảnh báo không nên chỉ kiểm tra các thành phần, dùng một tập con yêu cầu không đại diện, hoặc dừng lại ở biên độ nhỏ hơn mức tải dự kiến. Tài liệu hóa trở ngại hoặc chậm trễ đầu tiên. Thử nghiệm trên production có thể ảnh hưởng khách hàng; dùng môi trường có kiểm soát trừ khi đây là bài tập được lên kế hoạch và có nhân sự phù hợp.
Giữ lại kịch bản, cấu hình, hỗn hợp yêu cầu, thời lượng, trở ngại quan sát được, thay đổi năng lực, và chủ sở hữu theo dõi.
Chuẩn bị lựa chọn thay đổi, quay lui và khôi phục
Trước thay đổi rủi ro cao, xác định artifact hoặc cấu hình cần khôi phục, phê duyệt cần thiết, người được ủy quyền, và phương pháp xác thực. Giữ một runbook ngắn để tạm dừng phát hành, revert deployment, tắt feature flag, giảm tích hợp không quan trọng, hoặc khôi phục dữ liệu theo thủ tục được phê duyệt. Thử nghiệm cơ chế trước sự kiện; một bản sao lưu hoặc kế hoạch quay lui chưa được diễn tập là một giả định.
Đặt mục tiêu khôi phục từ tác động kinh doanh. Recovery Time Objective (RTO) là độ trễ tối đa chấp nhận được trước khi dịch vụ được phục hồi. Recovery Point Objective (RPO) là mất mát dữ liệu tối đa chấp nhận được tính từ điểm khôi phục gần nhất. AWS cảnh báo tránh các mục tiêu tùy tiện hoặc không thực tế và lưu ý rằng các mục tiêu phụ thuộc ảnh hưởng đến những gì khả thi. Xem các mục tiêu là mục tiêu lập kế hoạch, không phải lời hứa với khách hàng.
Xác minh một quy trình quay lui hoặc khôi phục giới hạn, an toàn và ghi lại những gì đã được kiểm tra, bởi ai, và bất kỳ khoảng trống nào được tìm thấy.
Giao quyền sở hữu trước khi các quyết định trở nên khẩn cấp
Danh sách liên hệ thôi chưa phải là sở hữu. Với mỗi đường dẫn quan trọng, chỉ định một chủ sở hữu kinh doanh cho kết quả chấp nhận được, một chủ sở hữu kỹ thuật cho việc thực hiện, và một chủ quyết định được ủy quyền thực hiện thay đổi bảo vệ. Chỉ rõ người dự phòng và làm rõ khi nào nhà cung cấp, agency, bộ xử lý thanh toán hoặc đội nội bộ là chủ sở hữu hành động tiếp theo.
Tiến hành một review sẵn sàng ngắn trước khi lưu lượng tới. Đi qua một thất bại phụ thuộc: cái gì còn lại khả dụng, cần dùng cần gạt nào là an toàn, ai phê duyệt và cách kiểm tra thành công. Đây là tổng duyệt chủ động, không phải báo cáo trạng thái trực tiếp. Ghi lại các hành động có ngày, chủ sở hữu và hạn hoàn thành.
Tiền ủy quyền các hành động an toàn hẹp khi thích hợp để biện pháp bảo vệ không phải chờ chuỗi phê duyệt mơ hồ.
Xem xét đặc biệt với đường dẫn nhạy cảm về thanh toán và bảo mật
Sự sẵn sàng của trang thanh toán phải bảo toàn tính chính xác cũng như khả dụng. Không được bỏ qua xác thực, làm yếu kiểm soát truy cập, lộ thông tin xác thực, hoặc thay đổi tùy tiện các script trên trang thanh toán. Hướng dẫn của PCI SSC đề cập đến ủy quyền, tính toàn vẹn và phát hiện giả mạo cho script trang thanh toán và header HTTP ảnh hưởng bảo mật. Nếu trang chấp nhận thẻ hoặc sử dụng iframe thanh toán, hãy để merchant, processor, acquirer và chuyên gia an ninh/phù hợp đủ điều kiện xem xét các thay đổi quan trọng.
Giữ một danh mục các script, tích hợp, phiên bản và quyền sở hữu tài khoản trong production, và hạn chế ai có thể thay đổi chúng. OWASP lưu ý rằng việc có danh mục phụ thuộc và ghim phiên bản (version pinning) có thể giảm sự không chắc chắn về những gì vào build, trong khi các phát hiện tự động vẫn cần xác minh thủ công. Những thực hành này hỗ trợ sự sẵn sàng nhưng không thiết lập tuân thủ PCI hay thay thế đánh giá an ninh.
Chỉ sử dụng luồng thay thế được processor phê duyệt và đã được xem xét; không bao giờ thu thập dữ liệu thẻ qua kênh informal.