데브옵스는 무엇일까?

프로덕션 환경에 배포하는데 필요한 시간을 단축하고 해당 서비스의 신뢰성과 품질을 높이는 것
1~3년차 생각: 개발자를 위한 개발자
4년차: 데브옵스 문화를 만드는 조직. 그렇다면 데브옵스 문화는 무엇일까?

데브옵스 핸드북에서 발췌한 데브옵스 문화 일부

데브옵스의 목표는 개발자로 구성된 소규모 팀이 기능을 독립적으로 구현하고, 프로덕션가 유사한 환경에서 정확성을 검증하며, 코드를 프로덕션 환경으로 빠르고 안전하게 배포하는 것이다.
2000대에는 데브옵스가 도입되기 전에 개발코드를 배포하기 위해 몇개월 소요되었다.
변경 사항이 버전 관리에 커밋될때마다 프로덕션가 유사한 환경에서 자동 테스트가 신속하게 실행된다. 자동화 테스트를 이용하면 개발자들이 자신의 실수를 빠르게 발견할 수 있다. 따라서 높은 자율성을 얻게 되고 작업의 실패 가능성은 작아지며 전체적인 혼란을 초래하지 않고도 작업할 수 있다.
데브옵스 문화는 문제를 숨기거나 보류하지 않고 두려움 없이 이야기 해야한다.
자동화 테스트에는 동료 리뷰를 수행한다.
어떻게 해결할 수 있는지 잘 이해하기 위해 서로 비난하지 않는 포스트모템을 진행한다. 포스트모템 보고서를 검색할 수 있게 만들어 비슷한 문제를 해결하려는 팀이 참고하도록 하거나, 전체 조직에 걸쳐 공유 소스코드 저장소를 생서해 조직 전체의 집단 지식이 담긴 코드, 라이브러리 및 구성 내용을 쉽게 활용해야 한다.
프로덕션 환경에 결함을 주입해 계획된 시스템이 어떻게 실행하는지 배운다.

SRE팀은 무엇일까?

개발부터 운영까지 모든 절차에 대해 신뢰감을 줄수 있도록 환경을 조성하는 팀
내 제품이 잘 운영되고 있는 것을 확신시키는 팀. 만약 문제가 있을 경우 누구나 빨리 발견할 수 있게 시스템을 만들고 빨리 고칠 수 있는 길잡이 역할을 하는 팀
개발, 운영, 성능향상, 트러블 슈팅 등 모든 곳에 관여하여 팀이 성장할 수 있도록 하는 팀

데브옵스 문화를 적용했을 때 단점

데브옵스는 빠른 배포(또는 기능적용)를 가능하게 한다. 따라서 빠른 배포로 발생하는 문제점을 야기시킨다.
장애가 발생화면 근본원인을 찾는데 시간이 많이 들 수 있다.
따라서 시스템 전반에 가시성이 충분히 확보되야 하고 수시로 관찰방법을 훈련해야 한다고 생각한다.
빠른 배포와 모니터링을 위해 많은 도구를 사용하게 되고 이는 오히려 생산성을 저하시키는 결과를 만들 수 있을 것 같다.

개인적인 생각

DevOps가 문화나 철학에 가깝다고 하면, SRE는 조금 더 운영에 집중하는 측면이 있는 것 같음.
DevOps는 개발부터 배포 및 운영까지 근간에 깔리는 문화나 파이프라인 및 철학을 설계하는 측면이라면, SRE는 정말 서비스 신뢰성을 높이기 위해서 코드나 인프라 영역에서 기술적으로 할 수 있는 일을 하는 작업에 가까움. 그래서 SRE를 한다고 하면 개발은 필수적으로 할 수 있어야 함.
개인적인 경험에 기반하면, DevOps일 때는 인프라를 운영하고 CI/CD 파이프라인을 구축하는 등의 역할을 통해서 회사에서 서비스를 빠르고 안전하게 개발할 수 있도록 기반을 마련해주는 역할을 했다면, SRE로 일을 할 때는 어떻게 서비스 장애를 더 빠르게 인지하고, 장애 빈도를 줄여나갈 수 있는지 분석하고 개선하는 역할에 집중했던 것 같음.

GPT 답변

DevOps

목적: 개발(Development)과 운영(Operations) 간의 장벽을 허물어 효율적인 소프트웨어 개발 및 배포를 목표로 합니다. 주요 원칙:

자동화: 빌드, 테스트, 배포, 모니터링 등 모든 단계를 자동화하여 일관성 있고 신속한 배포를 가능하게 합니다.
협업: 개발자와 운영자가 긴밀히 협력하여 문제를 빠르게 해결하고, 지속적인 피드백을 통해 소프트웨어 품질을 높입니다.
CI/CD: 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Delivery/Deployment)를 통해 코드 변경 사항이 신속하게 배포될 수 있도록 합니다.
문화: 신뢰, 책임, 공동 목표를 강조하는 조직 문화를 형성하여 DevOps의 원칙을 실천합니다.

SRE (Site Reliability Engineering)

목적: 소프트웨어 시스템의 안정성, 가용성, 성능을 보장하면서 운영 효율성을 극대화하는 것을 목표로 합니다. 주요 원칙:

SLI/SLO/SLA: 서비스 수준 지표(Service Level Indicators), 서비스 수준 목표(Service Level Objectives), 서비스 수준 계약(Service Level Agreements)을 정의하고, 이를 기반으로 시스템의 신뢰성을 측정하고 관리합니다.
에러 버짓: 일정 수준의 오류 허용 범위를 설정하여 신뢰성과 혁신 간의 균형을 유지합니다.
자동화: 반복적이고 수동적인 작업을 자동화하여 인적 오류를 줄이고, 운영 효율성을 높입니다.
모니터링: 시스템 상태를 지속적으로 모니터링하여 문제를 조기에 발견하고 대응합니다.
블라마제(Failure Analysis): 사고 분석을 통해 문제의 원인을 파악하고 재발 방지 대책을 마련합니다.

주요 차이점

관점: DevOps는 문화와 협업에 더 중점을 두는 반면, SRE는 신뢰성과 운영 효율성에 더 중점을 둡니다. 역할: DevOps는 개발자와 운영자 간의 협업을 촉진하는 역할을 담당하는 반면, SRE는 운영의 신뢰성과 성능을 유지하는 데 더 집중합니다. 측정 지표: DevOps는 주로 배포 빈도, 배포 속도 등을 중시하는 반면, SRE는 신뢰성 지표(SLI/SLO)와 에러 버짓을 중시합니다.

요약

DevOps: 협업, 자동화, CI/CD, 조직 문화. SRE: 신뢰성, 에러 버짓, 자동화, 모니터링, 사고 분석. 이 두 가지 접근 방식은 상호 보완적이며, 많은 조직이 둘 다 채택하여 더 안정적이고 신뢰할 수 있는 시스템을 구축하고 있습니다.

GwonsooLee / Podcast

데브옵스와 SRE는 무엇인가? #2