SRE 란 무엇입니까? 사이트 안정성 엔지니어의 중요한 역할

세상이 온라인으로 전환됨에 따라 웹 사이트, 클라우드 애플리케이션 및 클라우드 인프라의 안정성은 전자 상거래 운영에서 글로벌 은행, 검색 엔진에 이르기까지 모든 분야에서 중요한 비즈니스 필수 요소가되었습니다.

시스템과 워크로드를 관리하는 방식이 변경되었습니다. 오늘날 우리는 귀중한 하이 터치 고성능 서버에 대해 거의 생각하지 않고 대신 가상화를 통해 함께 풀링 된 상용 서버 랙에 랙을 장착하고 분산 된 소프트웨어 아키텍처를 통해 서버 중단으로 인한 다운 타임을 방지합니다. 초점은 하드웨어에서 소프트웨어 정의 인프라로, 일관성이없고 오류가 발생하기 쉬운 수동 프로세스에서 일관되고 안정적이며 반복 가능한 자동화 작업으로 옮겨졌습니다.

사이트 안정성 엔지니어링은 프로그래밍 가능한 인프라를 유지하고 여기에서 실행되는 워크로드의 가용성을 최대화하는 관행입니다. SRE (사이트 안정성 엔지니어) 직책은 Google 홀에서 시작되었습니다. Google은 천년이 시작될 무렵 소프트웨어 개발자와 운영 직원 간의 관계를 재정의하고 함께 협력하여 견고하고 유연한 시스템을 구축 할 수 있도록 지원했습니다. 핵심 원칙으로서 지속적인 개선 및 자동화.

SRE 란 무엇입니까?

기본 수준에서 SRE는 확장 성이 뛰어나고 안정적인 시스템을 만드는 노스 스타 목표와 함께 인프라 및 운영 문제에 소프트웨어 엔지니어링 원칙을 적용합니다.

Google의 엔지니어링 부사장이자 SRE의 대부인 Ben Treynor는 "기본적으로 소프트웨어 엔지니어에게 운영 기능 설계를 요청하면 이런 일이 발생합니다."라고 말합니다.

SRE 책임 중 가장 중요한 것은 서비스 수준 임계 값을 설정하는 것인데, 이는 종종 서비스 수준 목표 (SLO)로 나타나며 릴리스가 승인되는지 여부를 알려주는 데 도움이됩니다. 성배는 항상 신성한 '파이브 나인'또는 99.999 % 가동 시간입니다. 가동 시간이 좋을수록 더 많은 로프 개발자가 멋진 새 제품을 출시하고 더 많은 수면 SRE를 얻을 수 있으며, 이는 이전의 개발자 및 운영 적대감과는 거리가 먼 기능 간의 상호 유익한 관계로 이어집니다.

SRE 기능은 일반적으로 시스템 성능, 가용성, 대기 시간, 효율성, 모니터링, 용량 계획 및 비상 대응과 같은 일련의 주요 안정성 메트릭에서 측정됩니다.

[추가 정보 : 애플리케이션 모니터링 : devops가 더 잘할 수있는 것]

SRE의 주요 직무

좋은 SRE는 특히 자동화라는 한 가지에 집착 할 것입니다.

모니터링 소프트웨어 공급 업체 New Relic의 SRE 인 Jason Qualman은 블로그 게시물에서 다음과 같이 말합니다.“이 역할의 대부분은 사람들이하는 비효율적이고 시간 소모적 인 일에 대해 생각하고 가능한 한 빨리 중단합니다. 수작업으로 깡통을 걷어차는 대신 '지금 당장이 작업을 자동화하고 다른 사람이이 고통스러운 일을하지 않도록 시간을 할애 할 것입니다.'라고 말하는 것입니다.”

SRE 역할의 또 다른 핵심 요소는 소프트웨어 릴리스의 일관성과 반복성을 보장하기위한 모범 사례를 정의하는 "릴리스 엔지니어링"이라는 것입니다.

“릴리스 엔지니어는 소스 코드 관리, 컴파일러, 빌드 구성 언어, 자동화 된 빌드 도구, 패키지 관리자 및 설치 프로그램에 대해 (전문가가 아닌 경우) 확실하게 이해하고 있습니다. 그들의 기술 세트가 깊은 여러 도메인에 대한 지식이 포함되어 개발, 구성 관리, 테스트 통합, 시스템 관리, 고객 지원, "디나 맥넛, 구글의 기술 프로그램 매니저는 정액 책을 썼다 사이트 신뢰성 엔지니어링 에 오라일리에서 출판 ( 2016 년이며 Google 직원 Jennifer Petoff, Niall Richard Murphy, Chris Jones, Betsy Beyer가 작성했습니다.

그런 다음 비상 및 사고 대응 및 사후 분석과 함께 경고, 대기 중, 문제 해결을 포함하는 역할의 대응 부분이 있습니다.

본질적으로 SRE는 시스템을 모니터링하고 문제가 발생할 때 대응하는 최선의 방법을 알고 있으며, 발생할 수있는 고장을 수정하는 시간을 줄이기 위해 응답 플레이 북을 지속적으로 작성하고 다시 작성하는 것이 중요합니다. Google에서 여기에는 사건을 문서화하고, 원인이되는 모든 근본 원인을 이해하고, 향후 예방 조치를 구현하는 것이 포함됩니다.

Google 직원 John Lunney와 Sue Lueder는 Site Reliability Engineering 책 의 기고 장에서 "사후 분석을 작성하는 것은 처벌이 아닙니다. 회사 전체를위한 학습 기회입니다 .

[또한 : IT 운영에 애자일 방법론을 적용하기위한 3 단계]

SRE 대 devops 엔지니어

당신이 무슨 생각을하는지 알아요. 모든 것이 devops와 비슷하게 들리지만, 용어에 관해서는 SRE 직함이 실제로 devops 엔지니어보다 약 5 년 앞선 것입니다.

둘 다 유사한 원칙에 근거하고 있지만 그 차이는 미묘하고 중요합니다. 두 가지 작업 방식 모두 개발자와 운영 직원 간의 장벽을 허물고 해당 서비스의 핵심 복원력을 유지하면서 개발자 팀의 속도를 높이는 것을 목표로합니다.

주요 차이점은 devops 엔지니어는 지속적인 배포 및 개발자 속도 지원에 중점을 두는 반면 SRE는 릴리스를 성공적으로 배포 및 모니터링하고 소프트웨어 정의 인프라를 유지하는 데 중점을두고 소프트웨어 수명주기 전반에 걸쳐 안정성과 자동화를 책임집니다. SRE는 더 넓은 엔지니어링 팀 내에서 필수적인 기능을 가지고 있습니다. 즉, 안정적인 시스템 구축에 초점을 맞춘 전문가의 자리를 확보합니다.

Devops Institute의 Jayne Groll은 다음과 같이 설명합니다. SRE는 고객이 소비하는 시점에서 지속적인 운영을 엔지니어링하는 데 중점을 둡니다.”

Google의 SRE 역사

2000 년대 초 Google에서 SRE 원칙을 기원으로 거슬러 올라가는 것은이 분야에서 중추적 인 객체 교훈을 제공합니다.

“Google에 왔을 때 저는 운 좋게도 소프트웨어 엔지니어 인 사람들로 구성된 팀의 일원이되어 역사적으로 수작업으로 해결 된 문제를 해결하는 방법으로 소프트웨어를 사용하는 경향이있었습니다. 따라서이 운영 작업을 수행 할 공식 팀을 만들 때가되었을 때 '모든 것은 소프트웨어 문제로 취급 할 수 있습니다'접근 방식을 취하고 실행하는 것이 당연했습니다.”Ben Treynor는 Google 내부 블로그의 인터뷰에서 말했습니다.

“따라서 SRE는 기본적으로 운영 팀이 수행 한 작업을 기본적으로 수행하지만 소프트웨어 전문 지식이있는 엔지니어를 사용하고 이러한 엔지니어는 본질적으로 인간 노동을 자동화하는 경향이 있고 자동화를 대체 할 수있는 능력이 있다는 사실을 바탕으로합니다. ”Treynor가 덧붙입니다.

Google은 또한 SRE 팀을 구성하는 방법에 대해 매우 엄격하게 생각합니다. 모든 Google SRE는 Google 소프트웨어 엔지니어 또는 'Google 소프트웨어 엔지니어링 자격에 매우 가까운 후보자'여야합니다. 또한 인프라 관리 기술, 가장 일반적으로 "Unix 시스템 내부 및 네트워킹 (레이어 1에서 레이어 3) 전문 지식"이 있어야합니다.

SRE 자격은 여전히 ​​회사마다 다른 경향이 있지만 기본 원칙에 관한 한 Google 접근 방식은 확실한 출발점입니다. 세부 사항은 비즈니스 요구 사항, 설정된 프로세스 및 조직에서 이미 채택한 기술 스택에 따라 달라집니다.

SRE 직업 설명 및 급여

SRE는 일반적으로 통화 중이거나 문제 해결을 위해 뛰어 드는 것과 같은 기존 운영 기능을 수행하는 데 약 50 %의 시간을 소비합니다. 나머지 50 %는 시간이 지남에 따라 기본 시스템의 복원력, 자동화 및자가 치유를 더욱 강화하기위한 소프트웨어 개발에 집중하고 있습니다. 그렇기 때문에이 역할에는 소프트웨어 엔지니어링 기술과 운영 기술의 탄탄한 조합이 필요합니다. 좋은 SRE가 조직되고, 압박감에 시원하고, 문제 해결사가 될 것입니다. SRE 관리자는 팀 성과, 전략 및 최적화를 담당합니다.

하지만 SRE 역할이 존재하지 않는 조직은 어떻습니까? O'Reilly 보고서 "SRE 란 무엇입니까?" LinkedIn의 Kurt Andersen과 Split (릴리스 관리 소프트웨어 공급 업체)의 Craig Sebenik은 "풀뿌리"접근 방식을 권장합니다. 그들은“소규모 SRE 팀 (또는 개인)을 변경하고 구현할 동기가있는 개발 팀을 찾을 것을 권장합니다. 시간이 지나면 그 성공을 다른 팀에 긍정적 인 예로 사용할 수 있습니다. "

구직 사이트 인디 드에 따르면 SRE의 평균 연봉은 미국에서 약 $ 130,000, 영국에서 £ 76,000입니다.

SRE 리소스

DevOps Institute의 인증부터 O'Reilly, Microsoft 및 Google의 도서 및 온라인 리소스에 이르기까지 SRE 기술을 구축하기위한 리소스가 풍부합니다.  Jennifer Petoff, Niall Richard Murphy, Chris Jones, Betsy Beyer 의 앞서 언급 한 550 페이지 분량의 거대  사이트 안정성 엔지니어링 은 2016 년에 출판 된 주제에 대한 최고의 책입니다.이 책은 Google에서 온라인으로 무료로 제공됩니다. 

이 주제에 대한 다른 최근 책으로는   Jennifer Petoff, JC van Winkel, Preston Yoshioka의 Training Site Reliability Engineers 가 있습니다. SRE 란?  작성자 : Kurt Andersen 및 Craig Sebenik; David N. Blank-Edelman의 SRE 찾기  및   Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara 및 Stephen Thorne의 The Site Reliability Workbook .

O'Reilly는 또한 전 Google 사이트 안정성 엔지니어 인 Liz Fong-Jones가이 SRE Essentials 재생 목록에서 간편하게 선별 한 주제에 대한 온라인 자산, 비디오 및 eBook의 포괄적 인 라이브러리를 보유하고 있습니다.

온라인 학습 거점 Coursera는 인기있는 사이트 안정성 엔지니어링 : Google Cloud 교육의 안정성 측정 및 관리를 포함한 여러 과정을 제공합니다. 이 과정은 Pluralsight에서도 이용할 수 있으며 초급 과정 인 SRE (Site Reliability Engineering) : Elton Stoneman의 The Big Picture도 있습니다. Linux Foundation은 DevOps 및 SRE Fundamentals : Implementing Continuous Delivery라는 제목의자가 학습 과정을 제공합니다.

영국 기반 Jellyfish Training은 SRE Foundation (SREF)을위한 다양한 2 일 개인 교육 과정 옵션을 제공합니다.

devops에 대해 자세히 알아보기

  • DevOps 란 무엇입니까? 소프트웨어 개발 혁신
  • DevOps 프로그램을 시작하는 3 가지 방법
  • DevOps 모범 사례 : 채택해야하는 5 가지 방법
  • DevOps 변환을 추적하기위한 15 개의 KPI
  • 애플리케이션 모니터링 : DevOps가 더 잘할 수있는 것
  • 사이트 안정성 엔지니어링이 DevOps를 만나는 곳
  • 협업 애자일 DevOps 팀이되기위한 5 가지 원칙
  • IT 운영에 애자일 방법론을 적용하는 3 단계
  • 애자일 팀이 사고 관리를 지원하는 방법
  • Dataops가 데이터, 분석 및 기계 학습을 개선하는 방법
  • 데이터 과학 및 기계 학습에 DevOps 적용
  • DevOps 백 로그의 우선 순위를 정하기위한 7 가지 질문