일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- django
- Back tracking
- spring boot
- GitHub
- 구현
- DFS
- Algorithm
- hash table
- 코딩테스트
- SWEA
- CSV
- SQL
- 알고리즘
- Vue.js
- aws
- Data Structure
- Python
- JavaScript
- boj
- 코테
- Trie
- 시뮬레이션
- Linked list
- BFS
- 알고리듬
- Bruth Force
- programmers
- 모의SW역량테스트
- Priority Queue
- gpdb
- Today
- Total
hotamul의 개발 이야기
DevOps와 SRE(Site Reliability Engineering) 차이 본문
DevOps
DevOps란 개발과 운영 간 초점이 달라서 생기는 문제를 해결하기 위해(왜 빠르게 개발하고 적용해야 할까?), 빠른 개발 속도와 시스템 안정성 두 마리 토끼를 잡기 위한 일종의 도구 및 문화 또는 철학이다. What is DevOps? | Atlassian
개인적으로는 오늘의집 MSA Phase 1. DevOps - 오늘의집 블로그에서 DevOps와 DevOps 엔지니어의 역할에 대해 현실적으로 잘 설명하고 있다고 생각한다.
class SRE implements interface DevOps
?
DevOps와 SRE를 설명할 때 많은 사람들이 책: The Site Reliablity Workbook by Google의 첫 번째 Chapter의 Subtitle인 "class SRE implements interface DevOps"를 인용한다. 즉 DevOps는 "Role"이 아닌 문화(interface)이고 SRE는 DevOps의 많은 구현 방식(implements) 중 하나라는 의미이다.
하지만 현실엔 DevOps 직무 / SRE 직무가 따로 존재한다. (DevOps 직무만, SRE 직무만 있는 경우도 많다. 개인적으로 DevOps는 문화이자 목표로, SRE는 방법론이라는 의미로 사용되었으면 한다.)
"What's the relationship between SRE and DevOps?"를 참고해서, 커뮤니티에서 이야기 되고 있는 두 직무의 역할로서의 차이점을 이야기해보고자 한다.
SRE is to reliability as DevOps is to delivery
SRE는 안정성, DevOps는 전달에 관련된 부분에 더 중점을 두고 있다고 한다.
개념적으로는 SRE는 조직이 시스템, 서비스 및 제품에서, 적절한 수준의 안정성을 지속적으로 달성할 수 있도록 돕는데 전념하는 엔지니어링 분야이고 (SLI(Service Level Indicators), SLO(Service Level Objectives) 예시, 이 문서는 SLI와 SLO를 정의할 때 참고하기에 매우 좋아 보인다), DevOps는 최종 사용자에게 지속적으로 가치를 전달할 수 있도록, 사람 또는 프로세스 및 제품의 조합의 의미이다.
"Seeking SRE" 책에서는 DevOps 엔지니어는 "프로덕션 운영 책임이 낮고, 소프트웨어 개발 수명 주기, 파이프라인에 주로 집중하여 파이프라인을 지속적으로 개선"하는 역할이라고 설명했고 SRE 엔지니어는 "프로덕션 운영 책임이 높고, 이를 개선하기 위한 관점으로 소프트웨어 개발 수명 주기 파이프라인에 참여"하는 역할이라고 설명하고 있다.
즉 DevOps, SRE 직무 모두 운영 안정성을 유지하면서 더 빠르게 움직이기 위한다는 목표는 동일하지만 DevOps는 소프트웨어의 life cycle에 조금 더 집중하고 SRE는 시스템 안정성에 더 집중하는 역할로 여겨지고 있는 것 같다.
더 자세한 차이를 알아보고 싶다면 채용 공고를 살펴 보는 것도 좋을 것 같다. 주관적인 내용을 빼고 작성하고 싶었지만, 중간중간 사념이 글에 들어간 것 같고 추상적인 표현이 너무 많은 것 같아서 아쉽다. 예시로 들만한 경험들을 쌓고 생각을 정리하면서 업데이트해봐야겠다.
'etc.' 카테고리의 다른 글
Data Consistency in Distributed Systems (microservices) (0) | 2023.10.13 |
---|---|
Prometheus Pulling (pros and cons) (0) | 2023.04.24 |
왜 빠르게 개발하고 적용해야 할까? (0) | 2023.04.14 |
Big data/event-driven Architecture (0) | 2023.03.17 |
tmpfs란 무엇일까? (0) | 2023.03.14 |