주요 SRE 원칙 및 사례: SRE의 사용자 쪽
성공적인 운영 프로세스는 원하는 안정성을 달성하고 유지하는 프로세스입니다. 이러한 프로세스는 컴퓨터를 처리하는 방법에 따라 달라지는 것처럼 해당 환경에 책임이 있는 인간을 어떻게 대하는지에 따라 달라집니다. 사이트 안정성 엔지니어링은 실제 사례에서 중요한 여러 가지 면에서 이 점을 알고 있습니다.
번거로운 작업
우선 “번거로운 작업”이라는 개념에 초점을 맞춥니다. SRE 컨텍스트에서 번거로운 작업은 사람이 수행하는 운영 작업 중 특정한 특성이 있는 작업을 나타냅니다. 번거로운 작업에는 장기간 사용되는 값이 없습니다. 의미 있는 방식으로 서비스를 개선하지 않습니다. 종종 반복적이며 자동화될 수 있더라도 대부분 수동 작업입니다. 시간에 따라 서비스 또는 시스템의 규모가 커지면 해당 시스템에 대한 요청의 수도 비례해서 양이 증가하고 수동 작업도 더 많이 필요해질 수 있습니다.
예를 들어 서비스는 SRE 팀이 수고로 간주되는 다음과 같은 운영 부하를 발생하도록 요구할 수 있습니다.
- 매주 무언가를 초기화합니다.
- 새 계정 및 디스크 공간을 직접 프로비전합니다.
- 수동으로 프로세스를 반복적으로 다시 시작합니다.
해당 작업을 완료해도 장기적으로나 영구적으로 서비스가 개선되지 않습니다. 또한 이러한 작업을 반복해서 반복해야 할 수 있습니다.
참고
이러한 특성의 요청을 다른 여러 위치와 마찬가지로 티켓 시스템에 유지하더라도 작업을 수행하고 티켓을 확인하는 일은 여전히 번거롭습니다. 잘 추적되는 번거로운 작업일뿐입니다.
SRE는 번거로운 작업을 싫어합니다. 적절한 경우 최대한 제거하기 위해 노력합니다. 이 부분이 SRE에서 자동화가 제 역할을 톡톡히 하는 영역입니다. 이러한 요청을 자동으로 처리할 수 있으면 팀이 요청 큐를 비우는 것보다 보람 있고 영향력 있는 작업을 수행할 여력이 생깁니다.
번거로운 작업과 관련하여 "적절한" 단어를 사용하는 것은 안정성을 중심으로 사용하는 것과 유사합니다. 번거로운 작업을 제거하는 작업이 다른 작업보다 우선 순위가 떨어지는 경우도 있지만, 전반적으로 서비스에서 번거로운 작업을 제거하는 일이 SRE의 주된 중점 업무입니다.
프로젝트 작업 및 반응형 “운영” 작업
번거로운 작업을 제거하거나 시스템의 안정성을 개선하는 데 필요한 작업을 수행하려면 SRE 시간을 적절하게 할당해야 합니다. 그들은 화재 처리, 페이지에 회신 또는 티켓 큐 처리에 모든 시간을 소비하지 않도록 하려고합니다. 번거로운 작업을 제거하고, 티켓이 필요하지 않도록 셀프 서비스 자동화를 구성하고, 서비스와 사람의 효율성을 향상하는 프로젝트를 빌드하기 위해 코드를 작성할 시간을 따로 확보해야 합니다. 일반적으로 인용되는 수치(원래 Google 모델에서 제공)는 팀의 운영 로드가 50%를 넘지 않는 선입니다.
참고
50%는 임의적인 수치이지만 실제로 많은 사람의 합리적인 목표로 사용되는 것 같습니다.
SRE의 모든 시간이 장애 해결에 투여되는 순간도 있을 수 있지만, 이런 상태가 계속되지는 않습니다. 팀의 반응형 “운영” 작업(대부분 번거로운 작업)이 장기간 시간의 50% 이상을 차지하는 경우에는 리소스가 소진되거나 안정성이 떨어질 수 있습니다. 이 경우에는 앞에서 논의한 유익한 선순환이 작동되지 않거나 생길 수 없습니다. SRE는 균형 잡히지 않은 대기 중인 로드에도 마찬가지로 주의를 기울입니다. 이런 로드 역시 팀에 매우 부정적인 영향을 줄 위험이 있기 때문입니다.
지금까지 SRE의 핵심 사례와 원칙에 대해 살펴보았으므로 이제 시작하는 방법에 대해 논의해 보겠습니다.