다음을 포함하여 사이트 안정성 엔지니어링 및 DevOps 간의 관계에 대하여 나오는 일반적인 질문 집합이 있습니다. "어떻게 같습니까?" 어떻게 다를까요? 조직에 둘 다 있을 수 있나요?" 이 문서에서는 이 관계를 보다 자세히 이해할 수 있도록 SRE 및 DevOps 커뮤니티에서 제공한 일부 답변을 공유하려고 합니다.
어떻게 같습니까?
SRE와 DevOps 모두 다음을 포함한 문제에 대한 대응으로 만들고 개발한 최신 작업 방식 사례입니다.
- 프로덕션 환경 및 개발 프로세스의 복잡성 증가
- 이러한 환경의 지속적인 작동에 대한 비즈니스 종속성 개선
- 이러한 환경의 규모에 비례하여 직원의 규모를 조정할 수 없음
- 운영 안정성을 유지하면서 더 빠르게 움직여야 할 필요성
두 작업 방식 모두 모니터링/가시성, 자동화, 설명서 및 공동 작업 소프트웨어 개발 도구와 같은 문제를 처리하는 데 중요한 주제에 주의를 기울입니다.
SRE와 DevOps 간의 도구와 작업 영역 사이에는 상당한 중복이 있습니다. 사이트 안정성 통합 문서에 나와 있듯이 "SRE는 DevOps와 동일하다고 생각되지만 이유가 약간 다릅니다."
두 작업 방식을 비교하는 세 가지 방법
SRE와 DevOps 간의 유사성은 명확합니다. 여기에서 매우 흥미로운 점은 두 가지 방식이 어떻게 다른지 또는 나뉘는지입니다. 여기서는 이 질문에 대해 미묘한 차이를 드러내는 방식으로 이 관계에 대해 생각해 보는 세 가지 방법을 제공합니다. 이러한 답변에 동의하지 않을 수 있지만 각각 토론을 위한 좋은 시작점을 제공합니다.
"클래스 SRE가 인터페이스 DevOps 구현"
사이트 안정성 통합 문서(리소스 책 목록에서 언급)는 첫 번째 챕터에서 SRE 및 DevOps에 대해 설명합니다. 첫 번째 챕터에서는 "클래스 SRE가 인터페이스 DevOps 구현"을 부제목으로 사용합니다. 이는 SRE가 DevOps 철학의 구체적인 구현으로 간주될 수 있음을 시사(개발자를 겨냥한 문구 사용)한다는 의미입니다. 이 챕터에서 지적하듯이 "DevOps는 상세 수준에서 작업 실행 방법이 비교적 자동이지만, SRE는 상당히 금지하는 작업 방식입니다. 따라서 이 두 가지가 어떻게 관련되는지에 대한 질문에 대해 SRE는 DevOps의 여러 가능한 구현 중 하나로 간주할 수 있다는 것이 한 가지 가능한 답변입니다.
SRE가 안정성이라면 DevOps는 전달
SRE와 DevOps 모두의 정의는 여러 개 있기 때문에 이러한 비교는 약간 불명확하지만 여전히 유용할 수 있습니다. 이 비교는 "각 작업 방식을 핵심 사항을 반영하는 한두 가지 단어로 표현해야 한다면 어떤 말이 될 수 있을까”라는 질문에서 시작합니다.
사이트 안정성 엔지니어링 허브에 나오는 다음과 같은 SRE 정의를 사용하는 경우:
사이트 안정성 엔지니어링은 조직이 해당 시스템, 서비스 및 제품에서 ‘적절한’ 수준의 안정성을 지속적으로 달성하도록 지원하는 엔지니어링 분야입니다.
그러면 SRE에 적합한 단어는 "안정성"이라고 말할 수 있습니다. 이름 중간에 이 말이 들어가는 것도 이 주장의 뛰어난 증거가 됩니다.
Azure DevOps 리소스 센터에 나오는 다음 DevOps 정의를 사용하는 경우:
DevOps는 최종 사용자에게 지속적으로 가치를 업데이트할 수 있는 사람, 프로세스 및 제품의 합집합입니다.
그러면 DevOps에 대한 유사한 표현은 "전달"일 수 있습니다.
따라서 "SRE가 안정성이라면 DevOps는 전달"입니다.
관심 방향
이 답변은 Microsoft의 리소스 책 목록에 있는 Seeking SRE(SRE 탐색) 중에 Thomas Limoncelli가 기여한 부분에서 인용되거나 약간 다른 말로 표현됩니다. 그는 DevOps 엔지니어가 대체적으로 소프트웨어 개발 수명 주기 파이프라인에 초점을 맞추고 이따금 프로덕션 운영을 책임지는 반면, SRE는 프로덕션 작업에 집중하면서 가끔 SDLC 파이프라인을 책임진다고 언급합니다.
그러나 보다 중요한 점은 그가 한 쪽은 소프트웨어 개발 프로세스로 시작하고 다른 쪽은 프로덕션 운영 작업에서 시작하는 다이어그램도 그린다는 것입니다. 이 둘은 개발자의 코드를 사용하여 작성되고 원하는 수의 테스트 및 단계를 거쳐 안내된 다음 해당 코드를 프로덕션으로 이동하는 일반적인 파이프라인에 연결됩니다.
Limoncelli는 DevOps 엔지니어가 개발 환경에서 시작하여 프로덕션을 향한 단계를 자동화한다고 말합니다. 완료되면 다시 돌아가 병목 현상을 최적화합니다.
반면 SRE는 프로덕션 작업에 집중하고 최종 결과를 개선하는 수단으로 파이프라인에 깊게 관련됩니다(기본적으로 반대 방향으로 작동).
이것이 SRE 및 DevOps 초점 방향의 차이이며, 이러한 차이가 둘 사이를 구분하는 데 도움이 될 수 있습니다.
동일한 조직에 공존
해결하고자 하는 마지막 질문은 "동일한 조직에 SRE와 DevOps 둘 다 있을 수 있나요??"입니다.
이 질문에 대한 대답은 확실하게 "예!"입니다.
이전 답변이 두 가지 작업 방식이 어떻게 겹치는지, 언제 겹치지 않는지, 초점 면에서 어떻게 상호 보완적인지 이해하는 데 도움이 되었을기를 바랍니다. DevOps 작업 방식이 구성된 조직은 SRE 직위나 팀을 만드는 일에 전념할 필요 없이 작은 규모로(예: SLI 및 SlO 시도) SRE 방식을 실험해 볼 수 있습니다. 이 패턴이 상당히 일반적입니다.
다음 단계
사이트 안정성 엔지니어링 또는 DevOps에 대해 자세히 알고 싶으십니까? 사이트 안정성 엔지니어링 허브 및 Azure DevOps 리소스 센터를 확인하세요.