배포 후에도 서비스 책임지기

사용자가 의존하는 서비스를 정의하세요

배포는 소프트웨어를 사용할 수 있게 합니다. 운영은 사용자, 의존성, 트래픽, 요구사항이 바뀌어도 소프트웨어를 유용하게 유지합니다. 코드 생성기가 이 지속적인 작업을 없애지는 않습니다.

가상의 고객 내보내기에서 사용자는 접근 가능한 페이지 이상을 필요로 합니다. 허용된 레코드를 필요한 형식으로 허용 가능한 시간 안에 받아야 합니다. 다른 조직의 데이터 접근도 서비스가 막아야 합니다.

릴리스 전에 담당자를 정하세요. 서비스 약속에 포함된다면 정상 근무 시간 밖에 누가 대응하는지 기록하세요. 공급업체가 일부 작업을 수행할 수는 있지만 조직에는 여전히 명확한 결정 및 소통 경로가 필요합니다.

서비스 수준 지표인 SLI는 서비스 동작의 정해진 속성을 측정합니다. 서비스 수준 목표인 SLO는 정해진 기간에 대한 해당 지표의 목표를 설정합니다. 사용자 요구와 운영 역량을 바탕으로 목표를 선택하세요.

Google의 SRE 지침은 이 접근과 신뢰성 결정에 오류 예산을 사용하는 방법을 설명합니다. 의미를 확인하지 않고 다른 서비스의 목표를 복사하지 마세요. SLO 지침, 오류 예산 정책 예시.

내보내기에서는 처리 대상 요청의 성공 조건을 정의하세요. 예상된 접근 거부와 시스템 실패를 구분하세요. 어려운 요청을 숨기는 것만으로 지표가 좋아지지 않도록 제외 항목을 문서화하세요.

가시성을 높이려고 전체 내보내기 결과를 로그에 남기지 마세요. 진단에 필요한 최소 정보만 수집하고 접근을 보호하세요.

누가 조율하고 조사하며 소통하는지 정하세요. 작은 팀에서는 역할을 겸할 수 있지만 책임은 명확해야 합니다. 관찰과 조치를 기록하세요.

Google의 사고 대응 지침은 기술적 완화와 함께 조율과 소통을 강조합니다. 기술적으로 올바른 수정을 해도 사용자가 소식을 받지 못하거나 여러 대응자가 충돌하는 변경을 할 수 있습니다. 사고 대응.

에이전트는 승인된 데이터 경계 안에서 로그를 요약하거나 가설을 비교할 수 있습니다. 사고가 긴급하다는 이유로 무제한 프로덕션 권한을 얻어서는 안 됩니다. 예외 접근에는 정해진 상위 보고 및 승인 경로를 사용하세요.

대표적인 가상 데이터로 복구 절차를 테스트하세요. 삭제된 레코드나 이미 보낸 메시지처럼 코드 롤백으로 되돌릴 수 없는 것을 확인하세요. 서비스 복원에 필요한 시간과 정보를 기록하세요.

의존성 업데이트, 접근 권한 검토, 필요한 경우 인증서 갱신, 용량 변경, 문서 수정 등 지속적인 작업을 배정하세요. 유지보수 역량이 없는 서비스는 출시 예산이 끝난 뒤에도 할 일이 계속 쌓입니다.

사고 후에는 관찰한 원인을 해결할 개선책을 선택하세요. 이를 구현과 검증에 연결하세요. 이렇게 수명주기를 다시 연결합니다. 운영 증거가 팀이 다음에 명세하고 구축할 것을 바꿉니다.