장애를 분석하고 조치를 전달해도 비슷한 코드가 다른 서비스에 남아 있으면 같은 문제가 다시 생길 수 있다. 그렇다고 SRE가 모든 서비스의 코드를 반복해서 확인할 수는 없다. 이미 확인한 장애 패턴을 개발 중에 찾는 방법이 필요했다.
팀원과 CI 단계에서 장애를 예방할 수 있는 검사 체계를 검토했다. CI는 코드 변경을 통합할 때 빌드와 검사를 반복하는 과정이다. 실행하지 않고 코드를 살펴보는 정적 분석으로 최소 품질 기준과 알려진 위험 패턴을 확인할 수 있을지 논의했다. 당시에는 SonarQube를 기준으로 적용 가능성을 검토했다.
이런 접근을 Shift Left라고 한다. 소프트웨어 개발 생명주기(SDLC)를 설계에서 개발과 검증을 거쳐 운영으로 이어지는 순서로 놓으면 개발 단계가 왼쪽에 있다. 운영에서 찾던 문제를 그보다 앞에서 발견하고 수정하는 것이다.
운영에서 문제가 발견되면 코드 수정 외에도 고객 영향을 줄이는 조치가 필요하다. 원인을 분석하고 변경을 검증한 뒤 다시 배포해야 한다. 개발 중에 찾으면 코드를 수정하고 검사하는 범위에서 끝낼 수 있는 문제가 고객 대응까지 이어지는 것이다.
Google Cloud의 변경 관리 문서도 발견 시점이 늦어질수록 비용이 커지는 이유를 고객 영향과 분석자의 맥락 전환으로 설명한다. 아래 그래프는 그 차이를 설명하는 개념도다. 실제 측정값이나 단계별 비용 배수를 나타내지는 않는다.
개발 단계에서 모든 장애를 찾을 수 있는 것은 아니다. 코드의 형태로 확인할 수 있는 위험과 실제 트래픽이나 의존 서비스 상태가 있어야 나타나는 문제를 구분해야 한다. 앞단의 검사는 운영 모니터링과 복구 절차를 대신하지 않는다.
쿼리 결과가 과도하게 늘어날 수 있는 코드 패턴도 검사 후보였다. 코드를 실행하지 않고 위험한 조합을 찾을 수 있는지 검토했다. 다만 패턴에 맞는다는 이유만으로 모두 잘못된 코드라고 할 수는 없다. 실제 데이터와 사용 조건을 확인할 검토 대상인지 오류로 판정할 대상인지 나눠야 한다.
규칙을 많이 추가하면 개발 팀이 확인할 결과도 늘어난다. 어떤 장애를 막으려는 검사인지 설명할 수 있어야 하고 정상 코드를 문제로 표시하는 경우도 확인해야 한다. 검사 결과를 받는 팀이 이유를 이해하고 수정할 수 없다면 검사를 앞에 붙여도 대응할 사람만 바뀐다.
이 과제에서 논의한 것은 CI 단계의 검사 방식과 적용 가능성이었다. 전사 도입을 마쳤거나 장애 감소를 확인한 단계는 아니다. 이미 겪은 문제 중 코드에서 찾을 수 있는 것부터 검사 대상으로 정하려고 했다.
장애 대응에 드는 인력과 인프라 비용을 줄이고 고객 영향을 예방하려면 개발 단계에서 찾을 수 있는 문제부터 줄여야 한다. 그래서 운영에서 확인한 장애 패턴을 개발과 검증 단계에서 찾는 활동에 집중하고 있다.