검증된 개선으로 피드백 순환 완성하기

완성하려는 피드백 순환을 정의하세요

소프트웨어는 사용 중에 증거를 만듭니다. 오류, 지연, 지원 요청, 사고, 유지보수 발견 사항, 반복 수작업 등이 있습니다. 완전한 수명주기는 이 증거를 엔지니어링 결정에 다시 반영합니다.

자기 개선 소프트웨어는 자동화가 변경 식별, 제안, 구현, 검증을 돕는다는 뜻일 수 있습니다. 모델이 스스로 학습한다는 뜻일 필요는 없습니다. 애플리케이션 코드, 구성, 테스트, 지침, 작업 흐름, 모델 매개변수 중 무엇이 바뀌는지 명시하세요.

자동 복구는 알려진 운영 상태를 복원합니다. 자기 개선은 앞으로 더 나은 결과를 내도록 시스템을 바꿉니다. 두 번째 주장에는 비교와 회귀 방지가 필요합니다.

하나의 관찰을 수명주기 전체에서 추적하세요

아래 순서는 제안하는 엔지니어링 방법입니다. 어떤 제품이 모든 단계를 자율적으로 수행한다는 주장이 아닙니다.

이 산출물 사이의 연결을 유지하세요. ‘모니터링 개선’이라는 사후 분석 조치는 검증하기 어렵습니다. 명시된 신호, 담당자, 임계값, 테스트한 대응이 있으면 완료를 관찰할 수 있습니다.

평가를 제안과 독립적으로 유지하세요

에이전트는 패치를 만들고 테스트를 제안할 수 있습니다. 그래도 팀은 해당 테스트가 원래 문제를 탐지하는지 살펴봐야 합니다. 변경이 몰래 약화할 수 없는 버전 관리된 평가 집합을 보존하세요.

가상의 메모리 누수에서는 동등한 워크로드와 버전을 비교하세요. 대용량 내보내기, 취소, 재시도, 접근 거부 사례를 포함하세요. 고객 레코드를 노출하지 않으면서 관련 구조를 나타내는 합성 데이터를 사용하세요.

레코드를 누락하거나 인가를 우회하거나 허용 비용을 넘는다면 더 빠른 내보내기도 거부하세요. 최적화 전에 이 제약을 정하세요. 그렇지 않으면 선택한 지표는 좋아지면서 서비스는 나빠질 수 있습니다.

에이전트의 지침이나 모델을 바꾸면 대표 작업과 알려진 실패에서 동작을 평가하세요. 이전 버전을 사용할 수 있게 유지하세요. 지침 업데이트는 기반 모델이 사고에서 학습했다는 증거가 아닙니다.

릴리스하고 결과를 측정하세요

카나리 릴리스는 제한된 사용자 집단에 후보 버전을 제공합니다. 후보와 대조군의 신호를 비교하고 확대하거나 중지할 조건을 정하세요. 트래픽이 적거나 워크로드가 다르면 비교로 결론을 내리지 못할 수 있습니다. 카나리 지침.

가상의 팀은 고정된 합성 워크로드에서 기준선을 기록합니다. 수정을 테스트하고 승인된 경계 안에서 릴리스한 뒤 비교 가능한 프로덕션 기간을 확인합니다. 증거가 여전히 부족하면 개선을 선언하는 대신 불확실성을 기록합니다.

반복 수작업도 측정하세요. 자동화는 반복 부담을 줄일 수 있지만 유지보수와 실패 처리도 필요합니다. 결과를 판단할 때 이 비용을 포함하세요. 반복 수작업 지침.

피드백 기록을 활용할 수 있게 만드세요

실습에는 다음 항목을 사용하세요. 관찰과 버전, 기준선, 제안된 원인, 인수 기준, 회귀 검사, 변경과 검토, 릴리스 경계, 측정 결과, 담당자와 다음 검토입니다.

Taiga Maintaining은 저장소의 발견 사항을 수정 작업에 연결합니다. Initiatives는 의도한 변경을 계획 및 소프트웨어 제공에 연결합니다. 이들은 증거 연결의 일부를 제공합니다. 서비스 담당자는 여전히 배포와 운영 결과를 검증해야 합니다. Maintaining, Initiatives.

성숙한 소프트웨어 팩터리는 이 작업을 여러 제품에 걸쳐 연결합니다. 자동화가 늘어도 결정권과 평가 기준을 드러내세요. 최종 증거는 생성된 변경 수의 증가가 아니라 검증된 더 나은 서비스입니다.