결과를 검토하기 전까지는 릴리스가 완전하지 않다.

Source: Dev.to

‘릴리스는 결과가 검토될 때까지 완성되지 않는다’는 실용적인 운영 원칙이며, 슬로건이 아니다.
분석, 자동화, 소프트웨어 운영의 유용한 형태는 보통 마케팅 버전보다 조용하다. 모든 것을 수집하거나 모든 것을 자동화하는 것이 아니라, 작업을 이해하고 검토하며 개선하기 쉽게 만드는 것이 핵심이다.

많은 팀이 변경 사항을 배포하고 대시보드가 움직이는 것을 지켜보지만, 그 움직임을 릴리스와 연결하지 않는다. 차트는 변하지만 검토는 여전히 추측에 머문다.

바로 여기서 많은 팀이 명확성을 잃는다. 도구, 차트, 워크플로, 활동은 있지만 증거와 의사결정 사이의 연결이 약하다. 그 연결이 약하면 소프트웨어 작업을 평가하기가 어려워진다. 팀은 여전히 결정을 내리지만, 검토 가능한 운영 상황보다 기억, 의견, 긴급성에 더 의존한다.

릴리스를 영향을 미쳐야 할 신호와 연결하라. 배포 전에 기대 결과를 정의하고, 분석 레이어에 릴리스 컨텍스트를 보존하며, 충분한 증거가 모인 후에 검토한다.

중요한 세부 사항은 절제이다. 유용한 시스템은 모든 가능한 행동을 추적하거나 모든 단계를 자동화할 필요가 없다. 운영자가 상황을 이해하고 보다 자신 있게 행동할 수 있도록 돕는 신호를 보존하면 된다.

이는 보통 워크플로에 이름을 붙이고, 결과를 가시화하며, 신호를 설명할 충분한 컨텍스트를 보존하고, 다듬어진 인터페이스 뒤에 숨기지 않고 불확실성을 명시적으로 드러내는 것을 의미한다.

예상 결과, 실제 신호, 불확실성, 다음 결정을 비교함으로써 릴리스를 검토한다. 목표는 모든 릴리스가 정상 작동했음을 증명하는 것이 아니라, 명확히 배우는 것이다.

검토 가능한 시스템은 스스로 상태를 설명할 수 있기 때문에 신뢰하기 쉽다. 무엇이 일었는지, 무엇이 변했는지, 무엇이 여전히 불확실한지, 그리고 다음에 어떤 결정을 내려야 하는지를 보여준다.

WebmasterID에게 이것이 실용적인 방향이다: 운영자가 불필요한 잡음 없이 명확히 볼 수 있도록 돕는 소프트웨어, 분석, 워크플로 인프라.

가장 강력한 시스템은 데이터가 가장 많은 시스템이 아니다. 다음 결정을 내려야 할 때도 올바른 신호를 이해할 수 있는 시스템이 바로 강력한 시스템이다.