사이트 신뢰성 엔지니어링

Site reliability engineering

Site Reliability Engineering(SRE; 사이트 신뢰성 엔지니어링)은 소프트웨어 엔지니어링의 측면을 통합하여 인프라스트럭처 [2]및 운영 문제에 적용하는 일련의 원칙[1] 및 프랙티스입니다.주요 목표는 확장성과 신뢰성이 뛰어난 소프트웨어 [2]시스템을 구축하는 것입니다.사이트 신뢰성 엔지니어링은 소프트웨어 개발과 IT 운영을 결합하는 일련의 프랙티스인 DevOps와 밀접하게 관련되어 있으며 SRE는 DevOps의 [2][3]특정 구현으로도 설명되고 있습니다.

역사

사이트 신뢰성 엔지니어링 분야는 2003년 [6]입사 후 사이트 신뢰성 팀을 설립한 벤 트레이너 슬로스와 [4][5]함께 구글에서 시작되었습니다.2016년 구글은 1,000명 이상의 사이트 신뢰성 [7]엔지니어를 고용했습니다.2003년 구글에서 시작된 이후, 이 개념은 더 넓은 소프트웨어 개발 산업으로 확산되었고, 그 후 다른 기업들은 사이트 [8]신뢰성 엔지니어를 고용하기 시작했습니다.소규모 기업은 전용 SRE를 [8]필요로 하는 규모로 운영되지 않는 경우가 많기 때문에 이 직책은 대규모 웹 기업에서 더 일반적입니다.이 개념을 채택한 조직은 Airbnb, Dropbox, IBM,[9] LinkedIn, [7]Netflix 및 Wikimedia입니다.[10]2021년 DevOps Institute의 보고서에 따르면, 2,000명의 응답자를 대상으로 한 설문조사에서 조직의 22%가 SRE 모델을 [11][12]채택했습니다.

정의.

사이트 신뢰성 엔지니어링은 직무 역할로서 솔로 실무자에 의해 수행되거나 보다 광범위한 엔지니어링 조직 내에서 일반적으로 다음을 조합하는 팀을 구성할 수 있습니다.시스템 가용성, 지연 시간, 성능, 효율성, 변경 관리, 모니터링, 긴급 대응 및 용량 계획.[13]사이트 신뢰성 엔지니어는 소프트웨어 엔지니어링, 시스템 엔지니어링 또는 시스템 [14]관리에 대한 경험이 있는 경우가 많습니다.사이트 신뢰성 엔지니어링의 초점에는 자동화, 시스템 설계 [14]및 시스템 복원력 향상 등이 포함됩니다.

사이트 신뢰성 엔지니어링은 원칙과 관행의 집합으로서 누구나 수행할 수 있습니다.SRE는 보안 엔지니어링과 유사하지만, 누구나 우수한 보안 프랙티스에 기여할 것으로 기대되지만, 기업은 최종적으로 그 업무에 전문 인력을 투입하기로 결정할 수 있습니다.반대로 기업은 인터넷 시스템의 보안을 위해 보안 엔지니어를 고용하고 신뢰성 목표를 정의하고 확보하기 위해 SRE도 고용할 수 있습니다.

사이트 신뢰성 엔지니어링은 DevOps의 특정[2][3] 구현으로도 설명되어 왔지만, DevOps는 [2]보다 광범위하게 인프라스트럭처에 중점을 두고 있는 반면, 특히 신뢰성 높은 시스템 구축에 중점을 두고 있습니다.

Stephen Gossett은 빌트인에서 일부 기업이 운영팀을 [8]의미 있는 변경 없이 SRE 팀으로 재브랜드화했다고 밝혔습니다.이는 DevOps 팀으로 재브랜드된 운영 팀에도 해당됩니다.

원칙과 프랙티스

현장 신뢰성 엔지니어링 [15][16]원칙의 표준 목록을 정의하려는 시도는 여러 번 있었지만 합의가 이루어지지 않았지만 일반적으로 다음과 같은 특성이 그러한 정의의 대부분에 포함된다.

  • 자동화 또는 배제하는 비용 효율이 뛰어난 반복적인 자동화 또는 배제
  • 필요한 것보다 훨씬 더 높은 신뢰성을 추구하는 것을 피합니다.필요한 것을 정의하는 것 자체가 실천입니다(아래의 실천 리스트 참조).
  • 가용성, 지연 시간 및 효율성에 대한 위험을 줄이는 방향으로 시스템을 설계합니다.
  • 관찰가능성: 사전에 무엇을 [17]묻고 싶은지 알 필요 없이 시스템에 대해 임의의 질문을 할 수 있습니다.

사이트 신뢰성 엔지니어링 프랙티스도 매우 다양하지만, 아래 목록은 비교적 일반적으로 적어도 부분적으로 구현되어 있습니다.

  • 위에서 개략적으로 설명한 첫 번째 원칙의 실행으로서 관리를 열심히 한다.
  • 신뢰성 목표의 정의와 측정-SLI, SLO 및 오류 예산.
  • 신뢰성에 중점을 둔 비추상적 대규모 시스템 설계(NALSD)
  • 관찰 가능성을 위한 설계 및 구현.
  • 사고 관리 프로세스의 정의, 테스트 및 실행.
  • 용량 계획
  • CI/CD를 포함한 변경 및 릴리스 관리
  • 카오스 엔지니어링

실장

사이트 신뢰성 엔지니어링 팀은 사내의 다른 팀과 다양한 형태로 SRE의 원칙과 실무에 관여합니다.다음으로 일반적인 SRE 팀 [18]구현의 개요를 나타냅니다.

부엌 싱크대, 일명 "Everything SRE"

일반적으로 다루는 서비스 또는 워크플로우의 범위는 제한되지 않습니다.

사회 기반 시설

다른 팀의 업무 효율을 높이는 데 도움이 되는 백그라운드 시스템의 신뢰성에 초점을 맞춥니다.이들은 "플랫폼" 팀이나 "플랫폼 운영" 팀과 혼동되는 경우가 많습니다.인프라스트럭처 SRE 팀은 1개 이상의 플랫폼 엔지니어링 팀과 짝을 이룰 수 있지만, 인프라스트럭처 SRE 팀은 위의 원칙과 프랙티스에 기재된 작업의 대부분은(전부는 아니더라도) 수행하는 데 중점을 두고 있다는 점에서 다릅니다.플랫폼 팀은 플랫폼 구축에 중점을 두는 경향이 있으며, 신뢰성이 요구되지만 이것이 플랫폼 구축의 유일한 우선 순위는 아닙니다.

도구들

시스템 신뢰성을 측정, 유지 및 개선하기 위한 도구에 초점을 맞춥니다.예를 들어 Nagios Core.

제품 또는 응용 프로그램

제품 및/또는 애플리케이션 담당 SRE 팀일부 대기업은 이들 중 몇 명을 고용하는 경향이 있다.

내장

일반적으로 SRE의 개인 실무자 또는 소프트웨어 엔지니어링 팀 내의 2인 1조로 상기의 원칙과 프랙티스의 대부분을 적용합니다.

자문

SRE의 원칙과 실천 방법에 대해 상담합니다.이들은 보통 상기 구현 중 하나 또는 여러 팀에서 일한 경험이 있는 SRE입니다.외부 컨설팅 SRE 팀의 SRE는 흔히 '고객 신뢰성 엔지니어'라고 불립니다.고객의 구성이나 코드를 변경하는 일은 거의 없습니다.

SRE를 채용한 대기업은, 복수의 제품/애플리케이션 SRE 팀이 복수의 제품의 특정의 요구에 응해, 인프라스트럭처 SRE 팀이 플랫폼의 엔지니어링 그룹과 제휴해 신뢰성의 목표를 달성하는 등, 상기의 실장을 조합하는 경향이 있습니다.두 제품/애플리케이션 모두에 공통 플랫폼입니다.

산업

USENIX는 2014년부터 업계의 사이트 신뢰성 엔지니어를 대상으로 매년 SRE Conference를 개최하고 있으며,[19] 이와 유사한 주제를 가진 지역 Conference도 개최하고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Evaluating where your team lies on the SRE spectrum". Google Cloud Blog. Retrieved 2021-06-26.
  2. ^ a b c d e Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall, eds. (2016). Site Reliability Engineering: How Google Runs Production Systems. Sebastopol, CA: O'Reilly Media. ISBN 978-1-4919-5118-7. OCLC 945577030.
  3. ^ a b Vargo, Seth; Fong-Jones, Liz (March 1, 2018). What's the Difference Between DevOps and SRE? (class SRE implements DevOps) (Video). Google.
  4. ^ Hill, Patrick. "Love DevOps? Wait until you meet SRE". Atlassian. Retrieved June 17, 2021.{{cite web}}: CS1 maint :url-status (링크)
  5. ^ "What is SRE?". Red Hat. Retrieved June 17, 2021.{{cite web}}: CS1 maint :url-status (링크)
  6. ^ Treynor, Ben (2014). "Keys to SRE". USENIX SREcon14. Retrieved June 17, 2021.{{cite web}}: CS1 maint :url-status (링크)
  7. ^ a b Fischer, Donald (March 2, 2016). "Are site reliability engineers the next data scientists?". TechCrunch. Retrieved June 17, 2021.{{cite web}}: CS1 maint :url-status (링크)
  8. ^ a b c Gossett, Stephen (June 1, 2020). "What Is a Site Reliability Engineer? What Does an SRE Do?". Built In. Retrieved June 17, 2021.{{cite web}}: CS1 maint :url-status (링크)
  9. ^ "Site Reliability Engineering". IBM Cloud Education. IBM. November 12, 2020. Retrieved June 21, 2021.{{cite web}}: CS1 maint :url-status (링크)
  10. ^ "SRE - Wikitech". wikitech.wikimedia.org. Retrieved 2021-10-17.
  11. ^ Oehrlich, Eveline; Groll, Jayne; Garbani, Jean-Pierre (2021). Upskilling 2021 Enterprise DevOps SkillsReport (PDF) (Report). DevOps Institute. Retrieved June 17, 2021.
  12. ^ Oehrlich, Eveline (May 4, 2021). "What it takes to be a site reliability engineer". TechBeacon. Micro Focus. Retrieved June 17, 2021.{{cite web}}: CS1 maint :url-status (링크)
  13. ^ Treynor, Ben. "In Conversation" (Interview). Interviewed by Niall Murphy. Google Site Reliability Engineering.
  14. ^ a b Jones, Chris; Underwood, Todd; Nukala, Shylaja (June 2015). "Hiring Site Reliability Engineers" (PDF). ;login:. Vol. 40, no. 3. pp. 35–39. Retrieved June 17, 2021.
  15. ^ "The 7 SRE Principles [And How to Put Them Into Practice]". www.blameless.com. Retrieved 2021-06-26.
  16. ^ "Evaluating where your team lies on the SRE spectrum". Google Cloud Blog. Retrieved 2021-06-26.
  17. ^ "Learn about observability Honeycomb". docs.honeycomb.io. Retrieved 2021-06-26.
  18. ^ "SRE at Google: How to structure your SRE team". Google Cloud Blog. Retrieved 2021-06-26.
  19. ^ "Usenix SREcon". USENIX. 2021. Retrieved June 17, 2021.

추가 정보

외부 링크