Kiểm tra lệch cấu hình trước khi sửa mã ứng dụng

Khi tính năng hỏng mà không có bản phát hành rõ ràng, sửa mã ứng dụng có vẻ là một bước tiến. Trước hết, hãy hỏi dịch vụ còn chạy với thiết lập mà nhóm đã thống nhất không. Lệch cấu hình là khác biệt giữa trạng thái chuẩn được duyệt và thiết lập có hiệu lực. Câu hỏi hữu ích không phải hai tệp có khác nhau không, mà là khác biệt cụ thể nào giải thích triệu chứng nghiệp vụ đang thấy.

Xác định trạng thái chuẩn

Ghi phiên bản ứng dụng đã duyệt, thiết lập vận hành, tham chiếu thành phần phụ thuộc và ngoại lệ theo môi trường. Mỗi ngoại lệ cần có người phụ trách và lý do. Đừng coi môi trường thử nghiệm là bản sao hoàn hảo của môi trường thật khi có khác biệt chủ ý.

Tách tham chiếu bí mật khỏi thiết lập thông thường. OWASP mô tả vòng đời bí mật gồm tạo mới, luân chuyển, thu hồi và hết hạn.[5] Vì vậy, thay đổi ở thành phần bí mật phụ thuộc cần được kiểm tra theo vòng đời, thay vì mặc định ứng dụng đột nhiên có lỗi. Chỉ so siêu dữ liệu được phép xem, không để lộ giá trị bí mật.

So trạng thái dự kiến với hành vi thực tế

Yêu cầu đối chiếu có kiểm soát các thiết lập mà dịch vụ bị ảnh hưởng thực sự sử dụng. Tệp cấu hình được lưu chỉ là một phần câu hỏi. Ghi phạm vi đối chiếu và chỗ nhóm chưa quan sát được. Giới hạn kết quả ở thông tin mà người rà soát có quyền xem.

Chia khác biệt thành biến thể được duyệt, thay đổi chưa giải thích và chi tiết không liên quan. Với mỗi khác biệt có khả năng liên quan, viết giả thuyết dự đoán một tác động quan sát được. Đừng đưa mọi thiết lập về trạng thái cũ chỉ vì trạng thái đó quen thuộc.

Rà soát cấu hình không phải lý do trì hoãn mọi bản sửa lỗi. Nếu thiết lập thực tế khớp trạng thái chuẩn, hoặc thử nghiệm bác bỏ giả thuyết, hãy chuyển hướng điều tra. Giữ kết quả phủ định để nhóm không lặp lại cùng phép so sánh.

Kiểm soát thay đổi chặt cũng tốn công và có thể làm chậm điều chỉnh khẩn cấp hợp lệ. Cho phép ngoại lệ có phê duyệt, nhưng ghi mục đích và điều kiện cần rà soát lại. Kết quả cần là trạng thái vận hành được giải thích, không phải quy tắc thiếu thực tế rằng mọi môi trường phải luôn giống hệt nhau.

Ví dụ giả định: thiếu bước phê duyệt

Trong ví dụ giả định này, ứng dụng chi phí không còn yêu cầu phê duyệt lần hai với một phòng ban. Phiên bản ứng dụng vẫn khớp bản phát hành đã duyệt. Rà soát phát hiện quy tắc phòng ban trong cấu hình có hiệu lực bị thay đổi.

Nhóm tái hiện hành vi trong thử nghiệm có kiểm soát, rồi kiểm tra cả quy tắc cũ lẫn quy tắc dự kiến. Chủ quy trình xác nhận chính sách đúng trước khi có điều chỉnh được phép. Đây là minh họa điều tra, không phải bằng chứng rằng cấu hình luôn giải thích được lỗi chưa rõ nguyên nhân.

Dùng danh sách rà soát khác biệt

Yêu cầu biên bản rà soát ngắn trước khi duyệt sửa mã chỉ để bù cho một thiết lập chưa được giải thích.

• Nêu trạng thái chuẩn đã duyệt và người sở hữu.
• Liệt kê khác biệt có chủ ý của môi trường bị ảnh hưởng.
• So thiết lập có hiệu lực mà không tiết lộ giá trị bí mật.
• Gắn từng khác biệt liên quan với triệu chứng kiểm chứng được.
• Ghi điều chỉnh được phép và cách đảo ngược.