Khép kín vòng phản hồi bằng cải tiến đã kiểm chứng

Xác định vòng phản hồi cần khép kín

Phần mềm tạo bằng chứng trong quá trình sử dụng: lỗi, chậm trễ, yêu cầu hỗ trợ, sự cố, phát hiện bảo trì và công việc thủ công lặp lại. Vòng đời hoàn chỉnh đưa bằng chứng đó trở lại các quyết định kỹ thuật.

Phần mềm tự cải tiến có thể có nghĩa là tự động hóa hỗ trợ nhận diện, đề xuất, thực hiện và kiểm chứng thay đổi. Điều đó không nhất thiết có nghĩa mô hình tự huấn luyện. Nêu rõ phần nào thay đổi: mã ứng dụng, cấu hình, test, chỉ dẫn, workflow hay tham số mô hình.

Self-healing khôi phục một trạng thái vận hành đã biết. Tự cải tiến thay đổi hệ thống để tạo kết quả tốt hơn trong tương lai. Tuyên bố thứ hai cần phép so sánh và biện pháp chống hồi quy.

Theo dõi một quan sát qua vòng đời

Trình tự dưới đây là phương pháp kỹ thuật được đề xuất. Nó không khẳng định sản phẩm nào tự thực hiện mọi bước.

Giữ liên kết giữa các đầu ra này. Hành động sau sự cố chỉ ghi “cải thiện giám sát” rất khó kiểm chứng. Tín hiệu, người phụ trách, ngưỡng và cách ứng phó đã thử nghiệm giúp nhận biết khi nào công việc hoàn tất.

Giữ đánh giá độc lập với đề xuất

Agent có thể tạo patch và đề xuất test. Nhóm vẫn phải kiểm tra các test đó có phát hiện vấn đề ban đầu hay không. Duy trì bộ đánh giá có phiên bản mà thay đổi không thể âm thầm làm yếu.

Với lỗi rò rỉ bộ nhớ giả định, so sánh workload và phiên bản tương đương. Bao gồm xuất dữ liệu lớn, hủy, thử lại và từ chối truy cập. Dùng dữ liệu tổng hợp thể hiện các cấu trúc liên quan mà không làm lộ bản ghi khách hàng.

Từ chối lần xuất nhanh hơn nếu nó làm mất bản ghi, bỏ qua phân quyền hoặc vượt chi phí được phép. Xác định những ràng buộc này trước khi tối ưu. Nếu không, hệ thống có thể cải thiện chỉ số được chọn nhưng làm dịch vụ kém đi.

Nếu thay đổi chỉ dẫn hoặc mô hình của agent, đánh giá hành vi trên nhiệm vụ đại diện và lỗi đã biết. Giữ phiên bản trước khả dụng. Cập nhật chỉ dẫn không phải bằng chứng rằng mô hình nền đã học từ sự cố.

Phát hành và đo kết quả

Canary release cho một nhóm người dùng giới hạn tiếp cận phiên bản ứng viên. So sánh tín hiệu của ứng viên với nhóm đối chứng, rồi xác định khi nào mở rộng hoặc dừng. Lưu lượng ít hoặc workload khác nhau có thể khiến so sánh chưa đủ để kết luận. Hướng dẫn canary.

Nhóm giả định ghi mức cơ sở từ workload tổng hợp cố định. Nhóm thử bản sửa, phát hành trong giới hạn đã được phê duyệt và kiểm tra các giai đoạn production có thể so sánh. Nếu bằng chứng vẫn chưa đủ, nhóm ghi nhận điểm chưa chắc chắn thay vì tuyên bố có cải thiện.

Cũng đo công việc thủ công lặp lại. Tự động hóa có thể giảm việc vận hành lặp lại, nhưng bản thân nó cũng cần bảo trì và xử lý lỗi. Tính các chi phí này khi đánh giá kết quả. Hướng dẫn giảm công việc lặp lại.

Làm cho hồ sơ phản hồi có thể sử dụng

Dùng các trường sau cho bài tập: quan sát và phiên bản; mức cơ sở; nguyên nhân đề xuất; tiêu chí chấp nhận; kiểm tra hồi quy; thay đổi và review; giới hạn phát hành; kết quả đo được; người phụ trách và lần review tiếp theo.

Taiga Maintaining kết nối phát hiện trong repository với công việc khắc phục. Initiatives kết nối thay đổi mong muốn với lập kế hoạch và bàn giao. Đây là các phần của chuỗi bằng chứng. Người phụ trách dịch vụ vẫn phải kiểm chứng triển khai và kết quả vận hành. Maintaining, Initiatives.

Software factory trưởng thành kết nối công việc này giữa các sản phẩm. Giữ quyền ra quyết định và tiêu chí đánh giá rõ ràng khi mức tự động hóa tăng. Bằng chứng cuối cùng là dịch vụ tốt hơn đã được kiểm chứng, không phải số lượng thay đổi được tạo nhiều hơn.