"SRE는 소프트웨어 엔지니어에게 운영 팀을 설계하도록 요청하면 발생합니다." – 사이트 신뢰성 공학
이후 구글의 사이트 신뢰성 공학 도서가 출시 된 하나 개 이상의 경우에 나는 SRE는 기존의 운영 또는 응용 프로그램 지원 모델의 확장이라고 들었습니다.
Sys의 차이점을 정의한 몇 가지 질문이 있습니다. 관리자, DevOps 엔지니어 및 사이트 안정성 엔지니어 :
그러나 이러한 질문이나 답변 중 어느 것도 시스템 관리자와 사이트 안정성 엔지니어 의 차이점을 설명하지 않습니다 .
보다 포괄적 인 용어 : Google의 사이트 안정성 엔지니어링 실습과 기존의 분리 된 개발 및 운영 기능이 비즈니스 내 에서 중요한 차이점 은 무엇입니까 ?
답변:
고맙게도 Site Reliability Engineering은 Google에서 내부적으로 개발했으며 최근에야 더 광범위한 커뮤니티로 진출하기 시작한 이래로 매우 명확하게 정의되었습니다. 어떤 것은하지 ,하지만, 웹 작업 (- 명확성의 부족의 예로서, 당신은 귀하의 질문에 모두 사용 또는 "시스템 관리")입니다. 둘 중 하나가 무엇인지 확실하지 않은 경우 두 가지의 차이점에 대해 논의하기가 어렵습니다.
그러나 나는 모험심 많은 동료이기 때문에 기회를 줄 것이다.
전통적인 상점에서는 개발자와 sysadmin이 서로 매우 격분되어 있습니다. 개발자는 앱을 빌드 한 다음 코드가 커밋 되 자마자 작업이 완료된 것으로 간주합니다. sysadmins는 빌드 아티팩트 (통역 언어 인 경우 코드 일 수 있음)를 프로덕션 서버에 배치합니다. 응용 프로그램을 원활하게 실행하고 일반적으로 프로덕션 환경을 관리하는 것은 sysadmins의 작업입니다. 그러나 종종 성능 문제는 앱의 아키텍처 문제에서 비롯됩니다. sysadmin은 앱이 수행하는 작업을 알 수있는 프로그래밍 지식이 없으며 개발자는 프로덕션 트래픽이있는 프로덕션 토폴로지에서 앱이 어떻게 작동하는지 알지 못하므로 아무도 스스로 문제를 해결할 준비가되어 있지 않습니다.
또한 개발자는 일반적으로 새로운 기능을 얼마나 빨리 생성 할 수 있는지 판단하고 시스템 관리자는 앱에서 생산이 자주 발생하지 않는 방식을 판단합니다. 변화는 주요 파손 원인 중 하나이기 때문에 두 부서가 서로 경쟁하게됩니다.
어느 시점에서 일부 개발자 중심 기업 들은 이에 대해 화가 나서 "NoOps"연습을 시작했습니다. 운영 부서와 함께 제공되는 장애물을 제거했습니다. 실제로 이것은 개발자가 운영 역할을 맡았지만 이전 타이틀은 유지했음을 의미했습니다.
에서 NoOps을 둘러싼 토론 , 존 Allspaw, 다음 에디터 선택의 기술 운영 부사장의 편집자 잘 존경받는 웹 운영 책은 , 에디터 선택에 이런 식으로 역할을 정의 :
Etsy Operations는 다음을 담당합니다.
- 정전에 대응하고 통화합니다
- 경보 시스템 임계 값, 설계
- 건축 설계 및 검토
- 측정 항목 수집
- 응용 프로그램 구성
- 인프라 구축 / 관리
Etsy Development는 다음을 담당합니다.
- 정전에 대응하고 통화합니다
- 경보 시스템 임계 값, 설계
- 건축 설계 및 검토
- 측정 항목 수집
- 응용 프로그램 구성
- 공개 코드 배송
이 목록 중 어느 것도 포괄적이지 않으므로 거기에 뭔가 빠진 것 같습니다. Etsy Ops는 프로덕션 용 응용 프로그램 변경을 수행했지만 실제로는 적지 만 때로는 매우 깊습니다. Etsy Dev는 Chef를 변경하지만 실제로는 거의 없습니다. 책임이 너무 겹치면 왜 다른 점을 물어볼 수 있습니까? 도메인 전문 지식 및 배경. 많은 개발자들이 TCP 슬로우 스타트가 어떻게 작동하는지에 대한 지식이 많지 않지만 Ops는 그렇게합니다. 정렬 또는 관련성 알고리즘에 대한 포괄적 인 지식을 가진 Ops는 많지 않지만 Dev는 그 기능을 수행합니다. Ops는 수용 가능한 정확도로 신속하게 리소스 사용량을 예측 한 경험이 있지만 Dev는 그렇지 않습니다. 개발자는 모든 계층에 워크로드 옵션을 분배하는 장단점을 알지 못할 수도 있습니다 (1-7). 엔터티 관계 모델링은 개발자에게 자연 스러울 수 있지만 운영 체제에서는 그렇지 않을 수 있습니다. 결국, 그들은 모든 계층과 계층에서 다양한 형태의 비잔틴 실패 시나리오 및 복원력 패턴에 대한 솔루션을 발견합니다.
그의 세계에서 개발자와 운영 엔지니어는 매우 비슷한 수준의 기술과 책임을 가졌습니다. 그들이 다른 곳은 그들의 전문 지식이었습니다. 각기 다른 특성으로 인해 문제를 해결하기 위해 함께 일할 수 있었고 공통의 기본 수준의 기술로 언어를 제공 할 수있었습니다.
이것은 일반적으로 대부분의 경우 내가 수행하는 웹 작업의 정의입니다. 이것이 우리가 계속 진행할 것입니다.
그렇다면 사이트 신뢰성 엔지니어링이란 무엇입니까?
Google SRE 책은 SRE ...로 정의 된 다음 다른 책으로 열립니다. 그런 다음 장을 통해 역할과 세부 사항을 다루는 전체 책을 계속 정의합니다. 한 조직에서 개발 된 경우에도 작업을 하나의 합의 된 정의로 압축하기는 어려운 것 같습니다.
우선 Ben Traynor가 Google에 합류하여 최초의 사이트 안정성 엔지니어링 팀이 된 2003 년으로 돌아 가야합니다. 몇 단락 전에 우리는 2010 년대 초에 있었다는 것을 기억하십시오. 그러나 2003 년에도 업계는 여전히 sysadmin / developer 분할에 자연스러운 방식으로 설정되었습니다. 벤이 소프트웨어 엔지니어가 운영팀을 만들면 SRE가 일어날 것이라고 말했을 때 이것은 현재보다 두 세계가 훨씬 급격하게 융합되었습니다.
서문에 제공된 정의는 세 단어 각각을 개별적으로 강조합니다.
소개 장에는 다음과 같은 사이트 신뢰성 엔지니어링의 신조가 나와 있습니다.
저는 사이트 신뢰성 엔지니어링을 최신 웹 운영의 전문화 된 하위 집합으로 분류하고 싶습니다. SRE 조직은 모든 것을 자동화 하는 데 중점을 두며 상당히 큰 회사에서만 비용 효율적입니다. 오류 예산과 같은 아이디어는 서비스에 많은 수의 요청이있을 때만 작동 할 수 있습니다. 그렇지 않으면 세분성을 잃게됩니다 (작은 서비스의 경우 특정 오류는 분에 따라 요청의 0-20 %에 영향을 줄 수 있음). 진정한 SRE 팀을 확보하기에 충분히 큰 회사에는 보안 전용 팀이 있으므로 보안과 같은 관련 영역은 SRE 정의에 없습니다.
Google이 정의한 SRE 프로그램은 Google의 특정 요구에 맞게 개발 된 웹 운영 체제이며 다른 곳에 적용 할 필요는 없습니다.
그러나 최근 사이트 신뢰도 엔지니어링은 광범위한 산업에서 확장되고 있습니다. 비록 훨씬 작은 회사에서 일하고 있지만 내 직업 설명은 John Allspaw의 2012 Etsy 웹 작전 정의와 매우 잘 맞아도 현재의 직책은 SRE입니다. 내 이론은 우리가 단일 분야의 진화를 막기 위해 제목을 통해 속진하고 있다는 것입니다.
그렇다면 sysadmin과 SRE의 차이점은 무엇입니까? 그들이 타이틀을받은 연도. 기존 운영과 사이트 안정성 엔지니어링의 차이점은 무엇입니까? SRE는 새로운 도구 (hello, 컨테이너!)를 사용하여 현재 운영중인 화신입니다. 네트워크 프로그램이 점점 더 중요 해지고 중요 해짐에 따라 한 엔지니어가 더 많은 작업을 수행 할 수있는 관행에 대한 관심이 높아지고 있습니다.