컨텍스트의 SRE
SRE와 관련된 몇 가지 사례를 살펴보기 전에, 이전 단원에서 방금 학습한 몇 가지 아이디어를 컨텍스트에 적용하는 것이 좋습니다. 이 짧은 단원에서는 SRE의 몇 가지 배경 및 우리가 익숙한 운영 사례에 어떤 관련이 있는지 알아보겠습니다. 이 지식을 알면 컨텍스트에 따른 운영사례를 더 잘 납득할 수 있기 때문에 나중에 더 큰 도움이 됩니다. 또한 “SRE와 ...의 차이점은 무엇인가요?”라는 질문을 받을 경우 바로 대답할 수 있습니다.
기록
SRE의 간단한 역사는 2003년 Google에서 시작됩니다. 현재 Treynor Sloss인 Ben Treynor는 Google의 "프로덕션 팀"(당시 소프트웨어 엔지니어 7명)의 리더십을 맡았습니다. Treynor는 다음과 같이 잘 알려진 아이디어를 만들었습니다. "기본적으로 소프트웨어 엔지니어에게 운영 기능 설계를 요청하면 이런 일이 발생합니다." 이러한 배경을 알면 SRE를 처음 접하는 운영진들이 SRE가 “소프트웨어 엔지니어링”같다고 느끼는 이유를 설명하는 데 도움이 됩니다. SRE는 코딩을 중요시 하고, 소스제어 시스템을 주로 다루는 가치관 및 도구사양을 가져왔습니다. Google SRE의 초기 및 현재 구현은 O'Reilly에서 발생된 두 권의 책에 잘 문서화되어 있습니다(시작 단원 참조).
Google 직원들이 퇴사하고 회사 직원들이 공개적으로 사례를 자세히 논의하면서 SRE는 업계의 많은 조직으로 확산되기 시작했습니다. SRE가 새 조직으로 확산되면서 해당 조직도 SRE 원칙과 사례를 채택하고 현지 문화에 맞게 조정했습니다. 이 확장 프로세스를 통해 현장에서 수많은 SRE 구현이 생성되었습니다.
DevOps 및 SRE
이제 더 많은 업계들이 크기 조정, 개발 속도 대 운영의 안정성, 사이트 안정성 엔지니어링 트렌드를 같이하는 기타 소프트웨어와의 호환성 문제같은 동일한 문제에 직면했습니다. Google(및 당시 몇 개의 대규모 회사)의 외부에서 비슷한 문제를 해결하기 위해 만든 것이 DevOps입니다.
DevOps에 대한 여러 유용한 정보는 DevOps 리소스 센터를 참조하세요.
참고
DevOps 및 SRE는 동일한 과제를 해결하기 위한 두 가지 병행 시도임을 알아야 합니다. SRE는 DevOps 이후의 다음 진화 단계가 아닙니다. SRE는 “DevOps의 미래”로 생성된 것이 아닙니다.
SRE와 DevOps의 차이점은 여전히 현장에서 많이 논의되고 있는 주제입니다. 대부분의 사람들이 동의하는 몇 가지 차이점은 다음과 같습니다.
- SRE는 안정성에 중점을 둔 엔지니어링 분야입니다. DevOps는 별개의 개발 및 운영 조직과 일반적으로 관련된 사일로를 허물고자 하는 충동에서 등장한 문화적 움직임입니다.
- SRE는 “저는 SRE(사이트 안정성 엔지니어)입니다”와 같이 역할 이름일 수 있지만 DevOps는 역할 이름이 될 수 없습니다. 엄격히 말해서, 직업이 “DevOps”인 사람은 없습니다.
- SRE는 보다 규범적인 경향이 있고, DevOps는 의도적으로 규범적이 아닙니다. 이러한 점에서 거의 모두가 쓰고 있는 연쇄적인 통합/지속적인 운영, Agile 원칙 등이 제일 대표적인 예라고 할 수 있습니다.
두 운영 사례인 DevOps와 SRE는 모니터링/식별 가능 및 자동화를 둘 다 선호합니다(이유는 다를 수 있음). 이것이 SRE 사례 및 원칙을 기존 DevOps 사례가 있는 조직으로 쉽게 가져올 수 있는 이유 중 하나입니다. 해당 프로세스는 의도를 갖고 신중하게 수행해야 합니다. 또한 증분 방식으로 구현할 수 있고 또 그래야 합니다. 급하게 전환할 필요가 없습니다.
경고
조직의 담당자 직함만 바꾸는 구현 전략으로는 결코 성공할 수 없습니다. 이 경우 SRE가 제공하는 혜택을 얻을 수 없습니다. 더 효과적인 제안 사항은 이 단원의 시작 섹션을 참조하세요.
결론
이 짧은 단원에서는 SRE 및 DevOps와 관련된 컨텍스트를 간단히 살펴보았습니다. SRE 및 DevOps는 운영 사례에서 인접한 사고 학교로 가장 잘 생각됩니다.
이제 SRE의 몇 가지 배경을 간략하게 살펴보았으므로 핵심 원칙으로 바로 넘어가겠습니다.