슬럼 SRE. Booking.com 및 Google.com 전문가와 함께하는 완벽한 실험

우리 팀은 실험을 좋아합니다. 각 Slurm은 이전 Slurm의 정적인 반복이 아니라 경험에 대한 반성과 좋은 것에서 더 나은 것으로의 전환입니다. 하지만 함께 슬럼 SRE 우리는 참가자들에게 최대한 "전투"에 가까운 조건을 제공하기 위해 완전히 새로운 형식을 적용하기로 결정했습니다.

집중 과정 동안 우리가 한 일을 간략하게 요약하면 다음과 같습니다. “우리는 만들고, 부수고, 수리합니다.
우리는 공부하는 중이다." SRE는 단순한 이론으로는 거의 가치가 없습니다. 단지 연습, 실제 솔루션, 실제 문제일 뿐입니다.

참가자들은 Dmitry Anatolyevich의 예를 따라 활발한 경쟁 정신으로 누구도 잠들거나 iPhone에서 "Angry Birds"를 실행하는 것을 허용하지 않도록 팀으로 나뉘어졌습니다.

XNUMX명의 멘토가 참가자들에게 문제, 결함, 버그, 과제를 제공했습니다. Ivan Kruglov, Booking.com(네덜란드) 수석 개발자. Ben Tyler, Booking.com(미국)의 수석 개발자. Tungsten Labs(독일)의 CTO인 Eduard Medvedev. Evgeniy Varavva, Google(샌프란시스코)의 일반 개발자.

또한 참가자들은 팀으로 나뉘어 서로 경쟁합니다. 흥미로운?

Ivan, Ben, Eduard 및 Evgeniy는 대회가 시작되기 전에 친절한 레닌주의적 눈초리로 불쌍한 Slurm SRE 참가자들을 바라보고 있습니다.

따라서 작업은 다음과 같습니다.

우리는 우리의 것입니다, 우리는 새로운 세계를 건설 할 것입니다 ...

영화 예매 사이트가 있습니다. 사고는 사전 작업된 시나리오에서 멘토에 의해 만들어지며(아무도 특히 정교하고 교활한 즉흥적 행동을 배제하지 않지만) 사이트의 성능은 다양한 지표로 설명됩니다. 문제는 매우 다를 수 있습니다. 물랑루즈 극장 티켓은 데이터베이스에 로드되지 않습니다. 영화 포스터와 공연 포스터는 10초 이내에 데이터베이스에 로드됩니다. 개별 영화에 대한 설명이 멈춥니다. 0,1%의 주문이 이미 예약되었습니다. 때때로 결제 처리 시스템이 XNUMX~XNUMX분 동안 중단되는 경우가 있습니다. 그리고 실제 직장에서 Slurm SRE 참가자에게 닥칠 수 있는 수많은 불쾌한 일들입니다.

우리는 무엇이든...그리고 모두를 처리할 준비가 되어 있습니다.

우리의 오래 참음 웹사이트는 여러 마이크로서비스로 구성되어 있습니다. 이 기능의 임무는 모든 영화관의 공연, 가격, 이용 가능한 좌석에 대한 데이터를 집계하는 것입니다. 영화 안내를 표시하고 영화관, 공연, 홀 및 장소를 선택하고 티켓을 예약하고 결제할 수 있습니다. 일반적으로 시청자가 꿈꾸는 모든 것. 그러나 사용자는 사이트의 안정성과 접근성을 위한 엄청난 투쟁이 내부에서 진행되고 있는지조차 의심하지 않습니다.

집중 사이트의 경우 SLO, SLI, SLA 지표를 생성하고 아키텍처 및 인프라를 개발하고 사이트를 배포하고 모니터링 및 경고를 설정했습니다. 그리고 우리는 간다.

SLO, SLI, SLA

SLI - 서비스 수준 지표. SLO는 서비스 수준 목표입니다. SLA - 서비스 수준 계약.

SLA는 서비스에 대한 설명, 당사자의 권리와 의무, 그리고 가장 중요하게는 서비스 제공에 대해 합의된 품질 수준을 포함하는 서비스 고객과 공급업체 간의 공식적인 계약을 나타내는 ITIL 방법론 용어입니다. 서비스.

SLO는 서비스 수준 목표, 즉 SLI로 측정되는 서비스 수준의 목표 값 또는 값 범위입니다. SLO의 일반적인 값은 "SLI  Target" 또는 "Lower Limit  SLI  Upper Limit"입니다.

SLI는 서비스 수준 지표로, 제공된 서비스 수준의 한 측면을 신중하게 정의한 정량적 측정값입니다. 대부분의 서비스에서 핵심 SLI는 요청 대기 시간, 즉 요청에 대한 응답을 반환하는 데 걸리는 시간으로 간주됩니다. 기타 일반적인 SLI에는 수신된 모든 요청의 일부로 표시되는 오류율과 일반적으로 초당 요청 수로 측정되는 시스템 처리량이 포함됩니다.

우선, 우리는 비행기를 부수고, 그다음에는 소녀들을 부수고, 그 다음에는 소녀들을 부수겠습니다...

내부 및 외부 요인은 처음 몇 분부터 SLO를 "훼손"하기 시작했습니다. 개발자 실수, 인프라 장애, 방문자 유입, DDoS 공격 등 모든 것이 관리자의 머리에 떨어졌습니다. SLO를 악화시키는 모든 것.

"- 참가자 여러분, 서둘러 여러분을 기쁘게 해드리고 싶습니다. 여러분이 가장 먼저 실패하는 것은... 모든 것입니다!"

그 과정에서 발표자들은 안정성, 오류 예산, 테스트 관행, 중단 관리 및 운영 부하에 대해 논의했습니다.

우리는 화부도 아니고 목수도 아닙니다...

그런 다음 참가자들은 문제를 해결하기 시작했습니다. 가장 중요한 것은 무엇을 먼저 잡아야하는지 이해하는 것입니다.

"-주님, 이렇게, 이런 형태로, 저런 위치로 부서지는 걸 본 적이 없어요!"

그래서 사고가 발생했습니다. 결제 처리 서비스가 다운되었습니다. 가능한 한 최단 시간 내에 기능을 복원하려면 어떻게 해야 합니까?

참가자들을 다정하게 바라보는 전문가들은 또 다른 트릭을 준비하고 있다.

각 팀은 사고를 제거하기 위해 그룹의 작업을 구성합니다. 동료가 참여하고 이해관계자(이해관계자)에게 알립니다. 동시에 우선순위가 설정됩니다. 이러한 방식으로 참가자들은 극도로 제한된 시간 조건에서 압박감 속에서 작업하도록 훈련되었습니다.

“어떤 공포가 나왔나요?!”

숨을 내쉬고... 운동을 마무리하세요

발표자들과 함께 각 문제가 해결되고 사이트가 일시적으로 안정화된 후 팀은 SRE 관점에서 사건을 연구했습니다. 문제 발생 원인, 제거 진행 상황 등 문제를 자세히 분석했습니다. 그 후, 팀별로, 그리고 집단적으로 모니터링을 개선하는 방법, 아키텍처를 현명하게 변경하는 방법, 개발 및 운영에 대한 접근 방식을 조정하는 방법, 규제를 수정하는 방법 등 추가 방지 방법에 대한 결정을 내렸습니다. 연사들은 사후부검 실시 관행을 시연했습니다.

“또 누가 고통을 원하는가! - 나!"

팀의 성공은 전자 점수판에 엄격하고 명확하게 기록되었습니다.

첫 번째 장소 - 이해관계자로부터의 보너스.

출처 : habr.com