웨비나 "SRE - 과장 또는 미래?"

웨비나의 음질이 좋지 않아 스크립트로 작성했습니다.

내 이름은 Medvedev Eduard입니다. 오늘은 SRE가 무엇인지, SRE가 어떻게 나타나는지, SRE 엔지니어의 작업 기준, 신뢰성 기준에 대해 조금, 모니터링에 대해 조금 이야기하겠습니다. 한 시간 안에 많은 것을 알 수 없기 때문에 정상을 걸을 것이지만 추가 검토를 위해 자료를 제공하고 모두 기다리고 있습니다. 슬러미 SRE. XNUMX월 말 모스크바에서

먼저 SRE가 무엇인지 - 사이트 안정성 엔지니어링에 대해 이야기해 보겠습니다. 그리고 그것이 별개의 위치, 별개의 방향으로 어떻게 나타났는지. 모든 것은 전통적인 개발 서클에서 Dev와 Ops가 완전히 다른 두 팀이며 일반적으로 두 가지 완전히 다른 목표를 가지고 있다는 사실에서 시작되었습니다. 개발 팀의 목표는 새로운 기능을 출시하고 비즈니스 요구 사항을 충족하는 것입니다. Ops 팀의 목표는 모든 것이 제대로 작동하고 아무 것도 중단되지 않는지 확인하는 것입니다. 분명히 이러한 목표는 서로 직접적으로 모순됩니다. 모든 것이 작동하고 중단되지 않도록 하려면 가능한 한 적은 새 기능을 출시하십시오. 이 때문에 현재 DevOps라고 불리는 방법론이 해결하려는 내부 갈등이 많습니다.

문제는 DevOps에 대한 명확한 정의와 DevOps의 명확한 구현이 없다는 것입니다. 2년 전 예카테린부르크에서 열린 컨퍼런스에서 연설을 했는데 지금까지 DevOps 섹션은 "DevOps란 무엇인가"라는 보고서로 시작되었습니다. 2017년에 Devops는 거의 10년이 되었지만 여전히 그것이 무엇인지 논쟁하고 있습니다. 그리고 이것은 Google이 몇 년 전에 해결하려고 시도한 매우 이상한 상황입니다.

2016년 Google은 Site Reliability Engineering이라는 책을 발표했습니다. 그리고 사실 이 책으로 SRE 운동이 시작되었습니다. SRE는 특정 회사에서 DevOps 패러다임의 특정 구현입니다. SRE 엔지니어는 시스템이 안정적으로 작동하도록 노력합니다. 그들은 대부분 개발자, 때로는 강력한 개발 배경을 가진 관리자에게서 나옵니다. 그리고 그들은 시스템 관리자가 하던 일을 하지만 개발에 대한 강력한 배경과 코드 측면에서 시스템에 대한 지식은 이러한 사람들이 일상적인 관리 작업에 기울어지지 않고 자동화에 기울어져 있다는 사실로 이어집니다.

구조적 문제를 해결하는 SRE 엔지니어가 있다는 사실에서 SRE 팀의 DevOps 패러다임이 구현되는 것으로 나타났습니다. 여기 사람들이 8년 동안 이야기해 온 것과 동일한 Dev와 Ops 간의 연결이 있습니다. SRE의 역할은 신규 이민자가 SRE가 되지 않는다는 점에서 아키텍트의 역할과 유사합니다. 경력 초기에 있는 사람들은 아직 경험이 없고 필요한 지식의 폭이 없습니다. SRE는 정확히 무엇이 언제 잘못될 수 있는지에 대한 매우 미묘한 지식이 필요하기 때문입니다. 따라서 원칙적으로 회사 내부와 외부 모두에서 약간의 경험이 필요합니다.

그들은 SRE와 devops의 차이점을 설명할 것인지 묻습니다. 그녀는 방금 설명되었습니다. 조직에서 SRE의 위치에 대해 이야기할 수 있습니다. Ops가 여전히 별도의 부서인 이 고전적인 DevOps 접근 방식과 달리 SRE는 개발 팀의 일부입니다. 그들은 제품 개발에 참여합니다. SRE가 한 개발자에서 다른 개발자에게 전달되는 역할인 접근 방식도 있습니다. 예를 들어 UX 디자이너, 개발자 자신, 때로는 제품 관리자와 같은 방식으로 코드 검토에 참여합니다. SRE는 동일한 수준에서 작동합니다. 우리는 그것들을 승인해야 하고 검토해야 합니다. 그래야 각 배포에 대해 SRE가 다음과 같이 말할 것입니다. 그렇다면 허용 가능한 한도 내에서. 이것에 대해서도 이야기하겠습니다.

따라서 SRE는 코드 변경을 거부할 수 있습니다. 그리고 일반적으로 SRE가 잘못 구현되면 일종의 작은 충돌이 발생합니다. 사이트 안정성 엔지니어링에 관한 같은 책에서 하나가 아닌 많은 부분에서 이러한 충돌을 피하는 방법을 설명합니다.

그들은 SRE가 정보 보안과 어떤 관련이 있는지 묻습니다. SRE는 정보 보안에 직접 관여하지 않습니다. 기본적으로 대기업에서는 개인, 테스터, 분석가가 이를 수행합니다. 그러나 SRE는 또한 보안에 영향을 미치는 일부 작업, 일부 커밋, 일부 배포가 제품의 가용성에도 영향을 미칠 수 있다는 점에서 이들과 상호 작용합니다. 따라서 전체적으로 SRE는 분석가를 포함한 보안 팀을 포함한 모든 팀과 상호 작용합니다. 따라서 SRE는 DevOps를 구현하려고 할 때 주로 필요하지만 동시에 개발자의 부담이 너무 커집니다. 즉, 개발팀 자체가 이제 Ops도 책임져야 한다는 사실에 더 이상 대처할 수 없습니다. 그리고 별도의 역할이 있습니다. 이 역할은 예산에 계획되어 있습니다. 때때로 이 역할은 팀 규모에 따라 결정되고, 별도의 사람이 나타나며, 때로는 개발자 중 한 명이 그 역할을 맡습니다. 이것이 팀에 첫 번째 SRE가 나타나는 방식입니다.

SRE의 영향을 받는 시스템의 복잡성, 운영의 신뢰성에 영향을 미치는 복잡성은 필연적이고 우발적입니다. 필요한 복잡성은 제품의 복잡성이 새로운 제품 기능에 필요한 정도로 증가하는 경우입니다. 무작위 복잡성은 시스템의 복잡성이 증가하지만 제품 기능 및 비즈니스 요구 사항이 이에 직접적인 영향을 미치지 않는 경우입니다. 개발자가 어딘가에서 실수를 했거나 알고리즘이 최적이 아니거나 특별한 필요없이 제품의 복잡성을 증가시키는 몇 가지 추가 관심사가 도입되었습니다. 좋은 SRE는 항상 이러한 상황을 차단해야 합니다. 즉, 임의 추가로 인해 난이도가 높아지는 모든 커밋, 배포, 풀 요청은 차단되어야 합니다.

문제는 팀에 많은 지식을 갖춘 시스템 관리자인 엔지니어를 고용하지 않는 이유입니다. 엔지니어 역할을 하는 개발자는 최고의 인력 배치 솔루션이 아니라고 들었습니다. 엔지니어 역할의 개발자가 항상 최고의 인력 배치 솔루션은 아니지만 여기서 요점은 Ops에 종사하는 개발자가 자동화에 대한 열망이 조금 더 있고 구현을 위한 지식과 기술이 조금 더 있다는 것입니다. 이 자동화. 따라서 일상적인 작업뿐만 아니라 MTTR(Mean Time To Recovery, 복구 시간)과 같은 중요한 비즈니스 매개변수와 같은 일부 특정 작업에 대한 시간을 단축합니다. 따라서 나중에 이것에 대해서도 이야기하고 조직을 위해 비용을 절약합니다.

이제 SRE 운영 기준에 대해 이야기하겠습니다. 그리고 우선 신뢰성에 관한 것입니다. 소규모 회사, 신생 기업에서는 사람들이 서비스가 잘 작성되면 제품이 올바르게 작성되면 작동하고 중단되지 않을 것이라고 가정하는 경우가 종종 있습니다. 그게 다야, 우리는 좋은 코드를 작성하므로 중단할 것이 없습니다. 코드는 매우 간단하며 깨뜨릴 것이 없습니다. 이들은 우리가 테스트가 필요하지 않다고 말하는 사람들에 관한 것입니다. 왜냐하면 이것이 세 가지 VPI 방법이기 때문에 여기에서 중단되는 이유입니다.

물론 이것은 모두 잘못된 것입니다. 그리고이 사람들은 실제로 그러한 코드에 매우 자주 물립니다. 왜냐하면 일이 깨지기 때문입니다. 상황은 때때로 가장 예측할 수 없는 방식으로 중단됩니다. 때때로 사람들은 절대 일어나지 않을 것이라고 말합니다. 그리고 그것은 항상 발생합니다. 충분히 자주 발생합니다. 이것이 바로 아무도 100% 가용성을 위해 노력하지 않는 이유입니다. 100% 가용성은 절대 발생하지 않기 때문입니다. 이것이 표준입니다. 따라서 서비스 가용성에 대해 이야기할 때 항상 2에 대해 이야기합니다. 3구, 4구, 5구, 5구. 이를 가동 중지 시간으로 변환하면 예를 들어 5개의 나인은 연간 가동 중지 시간이 2분보다 약간 많고 3,5개의 나인은 XNUMX일의 가동 중지 시간입니다.

그러나 어느 시점에서 POI, 투자 수익이 감소하는 것은 분명합니다. 3개의 47에서 XNUMX개의 XNUMX로 전환하면 다운타임이 XNUMX일 이상 감소합니다. XNUMX 아홉에서 XNUMX로 가면 가동 중지 시간이 매년 XNUMX 분 줄어 듭니다. 그리고 비즈니스에는 중요하지 않을 수 있습니다. 그리고 일반적으로 요구되는 신뢰성은 기술적 문제가 아니라 우선 비즈니스 문제이며 제품 문제입니다. 제품 사용자가 허용할 수 있는 중단 시간 수준, 기대하는 것, 지불하는 금액, 예를 들어 손실 금액, 시스템 손실 금액.

여기서 중요한 질문은 나머지 구성 요소의 신뢰성입니다. 4개의 5가 2개인 스마트폰에서는 10개의 8와 XNUMX개의 XNUMX의 차이가 눈에 띄지 않기 때문입니다. 대충 XNUMX년에 XNUMX번 서비스에서 스마트폰 고장이 난다면 OS 쪽에서 고장이 XNUMX번 발생했을 가능성이 높습니다. 사용자는 이것에 익숙하며 XNUMX년에 한 번 더 주의를 기울이지 않을 것입니다. 신뢰성 증가와 이익 증가의 가격을 연관시킬 필요가 있습니다.
SRE에 관한 책에는 4개의 3에서 0,1개의 1로 증가하는 좋은 예가 있습니다. 가용성 증가는 900% 미만인 것으로 나타났습니다. 그리고 서비스 수익이 연간 900만 달러라면 수익 증가는 900달러입니다. 경제성을 3% 높이는 데 연간 XNUMX달러 미만의 비용이 든다면 그 증가는 금전적으로 타당합니다. XNUMX년에 XNUMX달러 이상이 든다면 수익 증가가 단순히 인건비, 자원 비용을 보상하지 않기 때문에 더 이상 말이 되지 않습니다. 그리고 우리에게는 XNUMX개의 XNUMX로 충분할 것입니다.

이것은 물론 모든 요청이 동일한 단순화된 예입니다. 그리고 3개의 4에서 2개의 3로 이동하는 것은 충분히 쉽지만 동시에 예를 들어 9개의 XNUMX에서 XNUMX으로 이동하면 이미 XNUMX달러를 절약할 수 있으므로 재정적으로 합리적일 수 있습니다. 당연히 실제로 등록 요청 실패는 페이지 표시 실패보다 더 나쁩니다. 요청은 가중치가 다릅니다. 비즈니스 관점에서 완전히 다른 기준을 가질 수 있지만 어쨌든 일반적으로 일부 특정 서비스에 대해 이야기하지 않는 경우 이는 상당히 신뢰할 수 있는 근사치입니다.
서비스에 대한 아키텍처 솔루션을 선택할 때 SRE가 코디네이터 중 하나인지 여부에 대한 질문을 받았습니다. 안정성이 손실되지 않도록 기존 인프라에 통합하는 경우를 가정해 보겠습니다. 예, 풀 요청, 커밋, 릴리스가 아키텍처, 새로운 서비스 도입, 마이크로 서비스, 새로운 솔루션 구현에 영향을 미치는 것과 같은 방식으로 SRE가 있습니다. 경험이 필요하고 자격이 필요하다고 전에 말한 이유는 무엇입니까? 실제로 SRE는 모든 아키텍처 및 소프트웨어 솔루션에서 차단 목소리 중 하나입니다. 따라서 엔지니어로서의 SRE는 우선 이해해야 할 뿐만 아니라 일부 특정 결정이 신뢰성, 안정성에 어떤 영향을 미치는지 이해하고 이것이 비즈니스 요구와 어떤 관련이 있는지, 그리고 어떤 관점에서 받아들일 수 있는지 이해해야 합니다. 그렇지 않습니다.

따라서 이제 전통적으로 SRE에서 SLA(서비스 수준 계약)로 정의된 안정성 기준에 대해 이야기할 수 있습니다. 아마도 친숙한 용어일 것입니다. SLI(서비스 수준 지표). SLO(서비스 수준 목표). 서비스 수준 계약은 아마도 상징적인 용어일 것입니다. 특히 네트워크, 제공업체, 호스팅과 함께 작업한 경우에는 더욱 그렇습니다. 이것은 전체 서비스의 성능, 페널티, 오류에 대한 일부 페널티, 메트릭, 기준을 설명하는 일반 계약입니다. 그리고 SLI는 가용성 지표 그 자체입니다. 즉, SLI는 서비스의 응답 시간, 오류 수(백분율)입니다. 일종의 파일 호스팅이라면 대역폭이 될 수 있습니다. 인식 알고리즘의 경우 예를 들어 응답의 정확성이 지표가 될 수 있습니다. SLO(Service Level Objective)는 각각 SLI 지표, 값 및 기간의 조합입니다.

SLA가 이와 같을 수 있다고 가정해 보겠습니다. 이 서비스는 연중 99,95% 이용 가능합니다. 또는 99개의 중요한 지원 티켓이 분기당 3시간 이내에 마감됩니다. 또는 매월 요청의 85%가 1,5초 이내에 응답됩니다. 즉, 우리는 점차 오류와 실패가 매우 정상적이라는 것을 이해하게 됩니다. 이것은 수용 가능한 상황이며 계획 중이며 어느 정도 기대하고 있습니다. 즉, SRE는 실수할 수 있고 오류에 정상적으로 응답해야 하며 오류를 고려해야 하는 시스템을 구축합니다. 그리고 가능할 때마다 사용자가 눈치 채지 못하거나 눈치 채지 만 모든 것이 완전히 무너지지 않는 일종의 해결 방법이있는 방식으로 오류를 처리해야합니다.

예를 들어 YouTube에 동영상을 업로드했는데 YouTube에서 즉시 변환할 수 없는 경우, 동영상이 너무 크거나 형식이 최적이 아닌 경우 시간 초과로 인해 요청이 자연스럽게 실패하지 않고 YouTube에서 502 오류를 제공하지 않습니다. , YouTube는 다음과 같이 말합니다. “우리는 모든 것을 만들었고 귀하의 비디오를 처리 중입니다. 10분 정도면 준비가 완료됩니다." 예를 들어 프런트 엔드 개발을 해본 적이 있다면 친숙한 우아한 저하의 원칙입니다.

신뢰성, 오류, 기대치를 가지고 작업하는 데 매우 중요한 다음 용어는 MTBF 및 MTTR입니다. MTBF는 고장 사이의 평균 시간입니다. MTTR 평균 복구 시간, 평균 복구 시간. 즉, 오류가 발견된 순간부터 오류가 나타난 순간부터 서비스가 완전히 정상 작동하도록 복원되는 순간까지의 시간입니다. MTBF는 주로 코드 품질에 대한 작업으로 수정됩니다. 즉, SRE가 "아니오"라고 말할 수 있다는 사실입니다. 그리고 SRE가 "아니오"라고 말할 때 자신이 해롭거나 나쁘기 때문이 아니라 모두가 고통을 겪을 것이기 때문에 말하는 것임을 전체 팀에 대한 이해가 필요합니다.

다시 말하지만, 내가 자주 참조하는 바로 그 책에도 많은 기사, 방법, 방법, 다른 개발자가 SRE를 싫어하기 시작하지 않도록 하는 방법이 있습니다. 반면 MTTR은 SLO(Service Level Objective) 작업에 관한 것입니다. 그리고 그것은 대부분 자동화입니다. 예를 들어 SLO는 분기당 4개의 가동 시간이기 때문입니다. 이는 3개월 동안 13분의 다운타임을 허용할 수 있음을 의미합니다. 그리고 MTTR은 13분을 넘을 수 없다는 것이 밝혀졌습니다. 13분 동안 가동 중지 시간이 1회 이상 발생하면 해당 분기의 전체 예산이 이미 소진되었음을 의미합니다. 우리는 SLO를 위반하고 있습니다. 충돌에 대응하고 수정하는 13분은 기계에게는 많은 시간이지만 인간에게는 매우 짧습니다. 사람이 경고를 받을 때까지, 반응할 때까지, 오류를 이해할 때까지 이미 몇 분이 걸리기 때문입니다. 사람이 그것을 고치는 방법, 정확히 무엇을 고칠지, 무엇을 해야할지 이해할 때까지 몇 분 더 걸립니다. 실제로 서버를 다시 시작하거나 새 노드를 올리면 수동 MTTR은 이미 약 7-8분입니다. 프로세스를 자동화할 때 MTTR은 종종 XNUMX초, 때로는 밀리초에 도달합니다. Google은 일반적으로 밀리 초에 대해 이야기하지만 실제로는 물론 모든 것이 좋지 않습니다.

이상적으로 SRE는 작업을 거의 완전히 자동화해야 합니다. 이는 MTTR, 지표, 전체 서비스의 SLO 및 그에 따른 비즈니스 이익에 직접적인 영향을 미치기 때문입니다. 시간이 초과되면 SRE에 결함이 있는지 묻는 메시지가 표시됩니다. 다행히 아무도 탓할 사람이 없습니다. 그리고 이것은 Balmeless Postmortem이라는 별도의 문화입니다. 오늘은 이야기하지 않겠지 만 Slurm에서 분석하겠습니다. 이것은 많이 이야기할 수 있는 매우 흥미로운 주제입니다. 대략적으로 말하면 분기당 할당 된 시간을 초과하면 모든 사람이 약간의 책임을 져야합니다. 즉, 모든 사람을 비난하는 것이 생산적이지 않다는 것을 의미합니다. 내 경험상 이 접근 방식은 대부분의 팀, 특히 러시아에서는 약간 낯설지만 이치에 맞고 매우 잘 작동합니다. 따라서이 주제에 대해 읽을 수있는 기사와 문헌의 끝에서 추천하겠습니다. 또는 Slurm SRE로 오십시오.

설명하겠습니다. 분기당 SLO 시간이 초과되면 가동 중지 시간이 13분이 아니라 15분이면 누가 책임을 질 수 있습니까? 물론 SRE가 책임을 져야 할 수도 있습니다. 그가 분명히 나쁜 커밋이나 배포를 했기 때문입니다. 데이터 센터의 관리자는 일종의 예정되지 않은 유지 관리를 수행했을 수 있으므로 이에 대한 책임이 있을 수 있습니다. 데이터 센터 관리자의 책임이라면 SLO를 조정할 때 유지 관리를 계산하지 않은 Ops 담당자의 책임입니다. 관리자, 기술 이사 또는 데이터 센터 계약에 서명하고 데이터 센터의 SLA가 필요한 다운타임을 위해 설계되지 않았다는 사실에 주의를 기울이지 않은 사람이 이에 대한 책임이 있습니다. 따라서이 상황에서 조금씩 모두 책임이 있습니다. 그리고 그것은 이 상황에서 누군가를 비난하는 것은 의미가 없다는 것을 의미합니다. 하지만 당연히 수정해야 합니다. 그것이 사후 분석이 있는 이유입니다. 예를 들어 GitHub 포스트모템을 읽으면 이것은 항상 매우 흥미롭고 작고 예상치 못한 이야기입니다. 아무도 이 특정한 사람이 책임이 있다고 말하지 않는다는 것을 대체할 수 있습니다. 책임은 항상 특정한 불완전한 프로세스에 있습니다.

다음 질문으로 넘어갑시다. 오토메이션. 다른 맥락에서 자동화에 대해 이야기할 때 실제로 절약하는 것보다 자동화하는 데 더 많은 시간을 들이지 않고 작업을 자동화할 수 있는 시간을 알려주는 표를 자주 참조합니다. 걸림돌이 있습니다. 문제는 SRE가 작업을 자동화하면 자동화가 MTTR에 직접 영향을 미치기 때문에 시간과 비용을 절약할 수 있다는 것입니다. 그들은 말하자면 직원과 개발자의 사기를 구해주며 이는 또한 고갈될 수 있는 자원이기도 합니다. 그들은 일상을 줄입니다. 그리고 이 모든 것이 작업에 긍정적인 영향을 미치고 결과적으로 자동화가 시간 비용 측면에서 이치에 맞지 않는 것처럼 보이더라도 결과적으로 비즈니스에 긍정적인 영향을 미칩니다.

사실 거의 항상 그랬고 SRE의 역할에서 무언가를 자동화해서는 안 되는 경우는 거의 없습니다. 다음으로 오류 예산, 오류 예산에 대해 이야기하겠습니다. 사실, 모든 것이 자신을 위해 설정한 SLO보다 훨씬 낫다면 이것도 그다지 좋지 않은 것으로 나타났습니다. 이것은 SLO가 하한뿐만 아니라 대략적인 상한으로도 작동하기 때문에 다소 나쁩니다. 99% 가용성의 SLO를 설정하고 실제로 99,99%가 있는 경우 비즈니스에 전혀 해를 끼치지 않는 실험을 위한 공간이 있음이 밝혀졌습니다. 이 공간은 사용하지 마십시오. 실수에 대한 예산이 있으며 귀하의 경우에는 사용되지 않습니다.

우리는 그것으로 무엇을합니까? 우리는 문자 그대로 모든 것에 사용합니다. 생산 조건에서의 테스트, 성능에 영향을 미칠 수 있는 새로운 기능 출시, 릴리스, 유지 관리, 계획된 가동 중지 시간. 반대 규칙도 적용됩니다. 예산이 소진되면 SLO를 초과하게 되므로 새로운 것을 출시할 수 없습니다. 예산이 이미 소진되었습니다. 성능에 부정적인 영향을 미치는 경우, 즉 자체적으로 SLO를 직접적으로 증가시키는 일종의 수정이 아닌 경우 예산을 초과하고 있으며 이것은 나쁜 상황입니다. , 분석, 사후 분석 및 일부 프로세스 수정이 필요합니다.

즉, 서비스 자체가 잘 작동하지 않고 SLO가 지출되고 예산이 실험이 아닌 일부 릴리스가 아니라 자체적으로 지출되면 흥미로운 기능 대신 흥미로운 수정 사항 대신 흥미로운 릴리스 대신. 창의적인 작업 대신 예산을 다시 정리하거나 SLO를 편집하기 위해 어리석은 수정을 처리해야 하며, 이 또한 너무 자주 발생해서는 안 되는 프로세스입니다.

따라서 오류에 대한 예산이 더 많은 상황에서 SRE와 개발자 모두가 관심을 갖는 것으로 나타났습니다. 개발자에게 버그에 대한 큰 예산은 릴리스, 테스트, 실험을 처리할 수 있음을 의미합니다. SRE의 경우 오류에 대한 예산을 책정하고 해당 예산을 입력하면 직접적으로 업무를 잘 수행하고 있음을 의미합니다. 그리고 이것은 일종의 공동 작업의 동기에 영향을 미칩니다. 개발자로서 SRE의 의견을 경청하면 좋은 작업을 위한 더 많은 공간을 갖게 되고 일상적인 작업은 훨씬 줄어들 것입니다.

프로덕션에서의 실험은 대규모 팀에서 SRE의 매우 중요하고 거의 필수적인 부분이라는 것이 밝혀졌습니다. 그리고 일반적으로 카오스 엔지니어링이라고 불리는데, 카오스 몽키(Chaos Monkey)라는 유틸리티를 출시한 넷플릭스 팀에서 나온 것입니다.
Chaos Monkey는 CI/CD 파이프라인에 연결하고 생산 중인 서버를 무작위로 충돌시킵니다. 다시 말하지만, SRE 구조에서는 다운된 서버 자체가 나쁘지 않다는 사실에 대해 이야기하고 있습니다. 그리고 예산 범위 내라면 수용 가능하고 비즈니스에 해를 끼치지 않습니다. 물론 Netflix에는 충분한 중복 서버와 충분한 복제가 있으므로이 모든 것을 고칠 수 있으며 사용자 전체가 눈치 채지 못하며 예산에 따라 하나의 서버를 떠나지 않습니다.

Netflix는 한동안 이러한 유틸리티 전체를 보유하고 있었는데 그 중 하나인 Chaos Gorilla는 Amazon의 가용 영역 중 하나를 완전히 종료했습니다. 그리고 그러한 것들은 무엇이 무엇에 영향을 미치고 무엇이 무엇에 의존하는지 완전히 명확하지 않을 때 숨겨진 종속성을 드러내는 데 도움이됩니다. 그리고 이것은 마이크로서비스로 작업하고 문서가 완벽하지 않은 경우 익숙할 수 있습니다. 그리고 이것은 스테이징에서 포착할 수 없는 코드의 오류를 포착하는 데 많은 도움이 됩니다. 모든 스테이징은 정확한 시뮬레이션이 아니기 때문입니다. 또한 아마도 다른 것입니다. 최대 부하는 예상하지 못하고 예측할 수 없습니다. 그리고 다시 예산을 초과하지 않는 이러한 테스트는 스테이징, 자동 테스트, CI/CD 파이프라인이 결코 포착하지 못하는 인프라의 오류를 포착하는 데 매우 도움이 됩니다. 예산에 모두 포함되어 있는 한 서비스가 다운되는 것은 중요하지 않습니다. 매우 무섭게 보이지만 서버가 다운되는 것은 정말 악몽입니다. 아니요, 정상입니다. 버그를 잡는 데 도움이 됩니다. 예산이 있으면 지출할 수 있습니다.

Q: 어떤 문헌을 추천할 수 있습니까? 마지막에 나열하십시오. 많은 문헌이 있습니다. 몇 가지 보고서를 알려 드리겠습니다. 작동 방식 및 SRE는 자체 소프트웨어 제품이 없거나 최소한의 개발로 회사에서 작동합니다. 예를 들어 주요 활동이 소프트웨어가 아닌 기업에서. 주요 활동이 소프트웨어가 아닌 기업에서 SRE는 다른 곳과 정확히 동일하게 작동합니다. 인프라, 성장 및 확장이 필요합니다. 또한 SRE는 이러한 프로세스에서 발생할 수 있는 문제를 식별 및 예측하고 어느 정도 성장이 시작되고 비즈니스 요구 사항이 변경된 후에 문제를 제어하는 ​​데 도움이 됩니다. 최소한 몇 대의 서버가 있고 어느 정도 성장이 예상되는 경우 SRE를 갖기 위해 소프트웨어 개발에 참여할 필요가 전혀 없기 때문입니다.

소규모 프로젝트, 소규모 조직도 마찬가지입니다. 대기업에는 실험할 예산과 공간이 있기 때문입니다. 그러나 동시에 이러한 모든 실험 결과는 어디에서나 사용할 수 있습니다. 즉, SRE는 물론 Google, Netflix, Dropbox에 나타났습니다. 그러나 동시에 소기업과 신생 기업은 이미 압축된 자료를 읽고, 책을 읽고, 보고서를 볼 수 있습니다. 그들은 그것에 대해 더 자주 듣기 시작하고 구체적인 예를 봅니다. 괜찮다고 생각합니다. 정말 유용 할 수 있습니다. 이것도 필요합니다. 훌륭합니다.

즉, 이러한 프로세스를 표준화하는 모든 주요 작업이 이미 완료되었습니다. 귀사에서 구체적으로 SRE의 역할을 결정하고 이미 설명한 이러한 모든 관행을 실제로 구현하기 시작하는 것은 귀하의 몫입니다. 즉, 소기업의 유용한 원칙에서 이것은 항상 SLA, SLI, SLO의 정의입니다. 소프트웨어에 관여하지 않는 경우 오류에 대한 내부 예산인 내부 SLA 및 내부 SLO가 됩니다. 이는 거의 항상 팀 내 및 비즈니스 내에서 흥미로운 토론으로 이어집니다. 인프라, 이상적인 프로세스의 조직에 지출하는 것으로 판명될 수 있기 때문에 이상적인 파이프라인은 필요한 것보다 훨씬 더 많습니다. 그리고 IT 부서에 있는 이 4개의 XNUMX는 지금은 실제로 필요하지 않습니다. 그러나 동시에 시간을 보내고 실수에 대한 예산을 다른 것에 쓸 수 있습니다.

따라서 모니터링 및 모니터링 구성은 모든 규모의 회사에 유용합니다. 그리고 일반적으로 실수가 허용되는 곳, 예산이 있는 곳, 목표가 있는 곳에서 이러한 사고 방식은 3명의 스타트업부터 시작하여 모든 규모의 회사에 다시 유용합니다.

마지막으로 이야기할 기술적 뉘앙스는 모니터링입니다. SLA, SLI, SLO에 대해 이야기하는 경우 예산에 맞는지, 목표를 준수하는지, 최종 SLA에 미치는 영향을 모니터링하지 않고는 이해할 수 없기 때문입니다. 예를 들어 서버에 대한 요청 시간, 평균 시간 또는 데이터베이스에 대한 요청 수와 같은 일부 값이 있습니다. 그는 엔지니어가 결정한 표준을 가지고 있습니다. 메트릭이 표준에서 벗어나면 이메일이 도착합니다. 이것은 일반적으로 사람이 매번 메시지를 해석해야 할 때, 즉 메트릭의 값이 어떤 행동의 필요성. 둘째, 그는 기본적으로 조치가 필요하지 않을 때 이러한 모든 경고를 인식하지 않습니다. 이는 좋은 모니터링 규칙이며 SRE가 구현될 때 가장 먼저 적용되는 규칙은 조치가 필요할 때만 알림이 전송되어야 한다는 것입니다.

표준 사례에는 3가지 수준의 이벤트가 있습니다. 경고가 있고, 티켓이 있고, 로그가 있습니다. 경고는 즉각적인 조치를 취해야 하는 모든 것입니다. 즉, 모든 것이 고장 났으므로 지금 바로 수정해야 합니다. 티켓은 지연된 조치가 필요한 것입니다. 예, 무언가를 해야 하고, 수동으로 무언가를 해야 하며, 자동화가 실패했지만 다음 몇 분 동안은 할 필요가 없습니다. 로그는 조치가 필요하지 않은 모든 것이며 일반적으로 일이 잘 진행되면 아무도 로그를 읽지 않습니다. 돌이켜 보면 한동안 문제가 발생했지만 우리가 몰랐던 경우에만 로그를 읽으면 됩니다. 아니면 조사를 좀 하셔야 합니다. 그러나 일반적으로 조치가 필요하지 않은 모든 항목은 로그로 이동합니다.

이 모든 것의 부작용으로 어떤 이벤트에 조치가 필요한지 정의하고 이러한 조치가 무엇이어야 하는지 잘 설명했다면 이는 조치를 자동화할 수 있음을 의미합니다. 즉, 일어나는 일입니다. 우리는 경고에서 이동합니다. 행동에 옮기자. 이 작업에 대한 설명으로 이동합니다. 그런 다음 자동화로 이동합니다. 즉, 모든 자동화는 이벤트에 대한 반응으로 시작됩니다.

모니터링에서 Observability라는 용어로 넘어갑니다. 또한 지난 몇 년 동안 이 단어에 대해 약간의 과대 광고가 있었습니다. 그리고 그것이 문맥에서 무엇을 의미하는지 이해하는 사람은 거의 없습니다. 그러나 요점은 Observability가 시스템 투명성의 척도라는 것입니다. 문제가 발생한 경우 정확히 무엇이 잘못되었는지, 그 순간 시스템 상태가 어땠는지 얼마나 빨리 확인할 수 있습니까? 코드 측면에서: 어떤 기능이 실패했는지, 어떤 서비스가 실패했는지. 예를 들어 내부 변수, 구성의 상태는 무엇입니까? 인프라 측면에서 이것은 오류가 발생한 가용 영역이며, Kubernetes가 있는 경우 오류가 발생한 포드에서 포드의 상태는 어땠습니까? 따라서 Observability는 MTTR과 직접적인 관계가 있습니다. 서비스의 Observability가 높을수록 오류를 식별하기 쉽고, 오류를 수정하기 쉽고, 오류를 자동화하기 쉽고, MTTR이 낮습니다.

다시 소규모 회사로 이동하면 지금도 팀 규모를 어떻게 처리해야 하는지, 소규모 팀이 별도의 SRE를 고용해야 하는지에 대해 묻는 것이 매우 일반적입니다. 이미 이것에 대해 조금 더 일찍 이야기했습니다. 스타트업 또는 예를 들어 팀 개발의 첫 번째 단계에서는 SRE가 과도기적 역할을 할 수 있기 때문에 이것은 전혀 필요하지 않습니다. 그리고 이것은 최소한 약간의 다양성이 있기 때문에 팀을 조금 되살릴 것입니다. 또한 성장과 함께 일반적으로 SRE의 책임이 매우 크게 바뀔 것이라는 사실에 대해 사람들을 준비시킬 것입니다. 사람을 고용하면 물론 그는 약간의 기대가 있습니다. 그리고 이러한 기대는 시간이 지나도 변하지 않을 것이지만 요구 사항은 크게 변할 것입니다. 따라서 SRE를 고용하는 방법은 초기 단계에서 상당히 어렵습니다. 자신의 성장이 훨씬 쉽습니다. 하지만 생각해 볼 가치가 있습니다.

아마도 유일한 예외는 매우 엄격하고 잘 정의된 성장 요구 사항이 있는 경우입니다. 즉, 신생 기업의 경우 이것은 일종의 투자자의 압력 일 수 있으며 한 번에 여러 번 성장을 예측하는 것일 수 있습니다. 그런 다음 SRE를 고용하는 것은 정당화될 수 있기 때문에 기본적으로 정당화됩니다. 우리는 성장에 대한 요구 사항이 있으며 그러한 성장으로 인해 아무것도 깨지지 않을 것이라는 사실을 책임질 사람이 필요합니다.

질문이 하나 더 있습니다. 개발자가 테스트를 통과하는 기능을 여러 번 잘라냈지만 프로덕션을 중단하고, 기본을 로드하고, 다른 기능을 중단하고, 어떤 프로세스를 구현할지. 따라서 이 경우 도입되는 오류에 대한 예산이다. 그리고 일부 서비스, 일부 기능은 이미 프로덕션에서 테스트되고 있습니다. 적은 수의 사용자만 있지만 이미 생산 단계에 있는 경우 카나리아가 될 수 있습니다. 기능이 배포되었지만 예를 들어 모든 사용자의 절반이 문제가 발생하더라도 여전히 요구 사항을 충족할 것이라는 기대가 있습니다. 오류에 대한 예산. 따라서 예, 오류가 발생합니다. 일부 사용자에게는 모든 것이 중단되지만 이미 이것이 정상이라고 말했습니다.

SRE 도구에 대한 질문이 있었습니다. 즉, 다른 모든 사람이 사용하지 않는 SRE가 사용하는 특정 항목이 있습니까? 실제로 일부 고도로 전문화된 유틸리티가 있습니다. 예를 들어 로드를 시뮬레이션하거나 카나리아 A/B 테스트에 참여하는 일종의 소프트웨어가 있습니다. 그러나 기본적으로 SRE 툴킷은 개발자가 이미 사용하고 있는 것입니다. SRE는 개발팀과 직접 상호 작용하기 때문입니다. 그리고 다른 도구가 있는 경우 동기화하는 데 시간이 걸린다는 것이 밝혀질 것입니다. 특히 SRE가 대규모 팀에서 작동하는 경우 여러 팀이 있을 수 있는 대기업에서는 여기에서 많은 도움이 되는 전사적 표준화가 도움이 될 것입니다. 모두. 물론 이것은 결코 일어나지 않을 것입니다. 그리고 작업의 질, 적어도 일부 팀의 통제 품질이 크게 떨어질 것입니다.

웨비나가 종료됩니다. 나는 몇 가지 기본적인 것들을 말할 수 있었다. 물론 한 시간 안에 SRE에 대해 말하고 이해할 수 있는 것은 없습니다. 하지만 이런 사고 방식, 주요 핵심 사항을 전달할 수 있었으면 좋겠습니다. 그런 다음 관심이 있다면 주제를 탐구하고 스스로 배우고 다른 회사에서 다른 사람이 어떻게 구현하고 있는지 살펴볼 수 있습니다. 따라서 XNUMX월 초에 Slurm SRE로 오십시오.

Slurm SRE는 XNUMX일 집중 과정으로 지금 이야기하고 있는 내용에 대해 이야기하지만 훨씬 더 깊이 있고 실제 사례와 실습을 통해 전체 집중 과정은 실제 작업을 목표로 합니다. 사람들은 팀으로 나뉩니다. 여러분은 모두 실제 사례를 연구하게 될 것입니다. 따라서 Booking.com 강사 Ivan Kruglov와 Ben Tyler가 있습니다. Google, San Francisco 출신의 멋진 Eugene Barabbas가 있습니다. 그리고 나도 당신에게 말할 것입니다. 그러니 꼭 방문해 주세요.
그래서 참고 문헌. SRE에 대한 참조가 있습니다. 처음으로 같은 책 또는 Google에서 작성한 SRE에 관한 2권의 책에 있습니다. 다른 것 SLA, SLI, SLO에 대한 작은 기사, 여기서 용어와 해당 적용은 약간 더 자세히 설명되어 있습니다. 다음 3개는 다른 회사의 SRE에 대한 보고서입니다. 첫 번째 - SRE의 핵심, 이것은 Google의 Ben Trainer의 기조 연설입니다. 두번째 - Dropbox의 SRE. 세 번째는 다시 SRE에서 Google로. 의 네 번째 보고서 넷플릭스의 SRE, 5개국에 190명의 주요 SRE 직원만 있습니다. 이 모든 것을 살펴보는 것은 매우 흥미로운 일입니다. 왜냐하면 DevOps가 다른 회사와 심지어 다른 팀에 매우 다른 것을 의미하는 것처럼 SRE는 비슷한 규모의 회사에서도 매우 다른 책임을 갖기 때문입니다.

혼돈 공학의 원리에 대한 2개의 추가 링크: (1), (2). 그리고 마지막에는 Awesome Lists 시리즈의 3개 목록이 있습니다. 카오스 엔지니어링대략 SRE 그리고 약 SRE 툴킷. SRE의 목록은 믿을 수 없을 정도로 방대합니다. 모두 살펴볼 필요는 없으며 약 200개의 기사가 있습니다. 용량 계획 및 흠 없는 사후 분석에 대한 기사를 적극 추천합니다.

흥미로운 기사 : 삶의 선택으로서의 SRE

그동안 제 이야기를 들어주셔서 감사합니다. 당신이 뭔가를 배웠기를 바랍니다. 더 많은 것을 배울 수 있는 충분한 자료가 있기를 바랍니다. 그리고 보자. XNUMX월 되시길 바랍니다.
웨비나는 Eduard Medvedev가 주최했습니다.

추신: 읽기를 좋아하는 사람들을 위해 Eduard는 참고 문헌 목록을 제공했습니다. 실제로 이해하고 싶은 분들은 환영합니다. 슬러미 SRE.

출처 : habr.com