SRE(Site Reliability Engineering)는 웹 프로젝트의 가용성을 보장하는 접근 방식입니다. DevOps를 위한 프레임워크로 간주되며 DevOps 방식을 성공적으로 적용하는 방법에 대해 설명합니다. 이 기사의 번역 4장 서비스 수준 목표 книги 사이트 신뢰성 공학 Google에서. 나는 이 번역을 직접 준비했으며 모니터링 프로세스를 이해하는 데 있어 내 경험을 바탕으로 했습니다. 텔레그램 채널에서 모니터im_it и Habré의 마지막 게시물 또한 서비스 수준 목표에 관한 같은 책의 6장을 번역하여 출판했습니다.

고양이 번역. 즐겁게 읽으세요!

실제로 어떤 지표가 중요한지, 이를 어떻게 측정하고 평가해야 하는지 이해하지 못하면 서비스 관리가 불가능합니다. 이를 위해 우리는 내부 API 또는 공개 제품 중 하나를 사용하는지 여부에 관계없이 사용자에게 특정 수준의 서비스를 정의하고 제공합니다.

우리는 서비스 수준 지표(SLI), 서비스 수준 목표(SLO) 및 서비스 수준 계약(SLA)을 이해하려는 사용자의 욕구에 대한 직관, 경험 및 이해를 사용합니다. 이러한 차원은 우리가 모니터링하고 예상되는 서비스 품질을 제공할 수 없는 경우 대응할 주요 지표를 설명합니다. 궁극적으로 올바른 측정항목을 선택하면 문제가 발생할 경우 올바른 조치를 취하는 데 도움이 되며 SRE 팀이 서비스 상태에 대한 확신을 갖게 됩니다.

이 장에서는 메트릭 모델링, 메트릭 선택 및 메트릭 분석의 문제를 해결하기 위해 사용하는 접근 방식을 설명합니다. 설명의 대부분은 예제가 없으므로 구현 예제(셰익스피어 작품 검색)에서 설명한 셰익스피어 서비스를 사용하여 주요 사항을 설명합니다.

서비스 수준 용어

많은 독자들이 SLA의 개념에 익숙할 것입니다. 그러나 SLI 및 SLO라는 용어는 일반적으로 SLA라는 용어가 과부하되고 상황에 따라 다양한 의미를 갖기 때문에 신중하게 정의할 가치가 있습니다. 명확성을 위해 이러한 값을 분리하려고 합니다.

지표

SLI는 서비스 수준 지표로, 제공된 서비스 수준의 한 측면을 신중하게 정의한 정량적 측정값입니다.

대부분의 서비스에서 핵심 SLI는 요청 대기 시간, 즉 요청에 대한 응답을 반환하는 데 걸리는 시간으로 간주됩니다. 기타 일반적인 SLI에는 수신된 모든 요청의 일부로 표시되는 오류율과 일반적으로 초당 요청 수로 측정되는 시스템 처리량이 포함됩니다. 측정값은 종종 집계됩니다. 원시 데이터는 먼저 수집된 다음 변화율, 평균 또는 백분위수로 변환됩니다.

이상적으로는 SLI가 관심 있는 서비스 수준을 직접 측정하지만 때로는 원래 측정항목을 얻거나 해석하기 어렵기 때문에 관련 측정항목만 측정에 사용할 수 있습니다. 예를 들어 클라이언트 측 대기 시간이 더 적절한 측정 기준인 경우가 많지만 서버에서만 대기 시간을 측정할 수 있는 경우도 있습니다.

SRE에 중요한 또 다른 유형의 SLI는 가용성, 즉 서비스를 사용할 수 있는 시간 부분입니다. 성공적인 요청 비율로 정의되는 경우가 많으며 때로는 수율이라고도 합니다. (수명(데이터가 장기간 보존될 가능성)은 데이터 저장 시스템에서도 중요합니다.) 100% 가용성은 불가능하지만 100%에 가까운 가용성은 종종 달성할 수 있으며, 가용성 값은 다음과 같이 표현됩니다. "99" 수 » 가용성 비율. 예를 들어 99,999% 및 2% 가용성은 "5 nines" 및 "99,95 nines"로 표시될 수 있습니다. Google Compute Engine의 현재 명시된 가용성 목표는 'XNUMX%'입니다.

대상

SLO는 서비스 수준 목표, 즉 SLI로 측정되는 서비스 수준의 목표 값 또는 값 범위입니다. SLO의 일반적인 값은 "SLI  Target" 또는 "Lower Limit  SLI  Upper Limit"입니다. 예를 들어 SLO를 100밀리초 미만의 평균 검색 쿼리 대기 시간으로 설정하여 셰익스피어 검색 결과를 '빠르게' 반환하도록 결정할 수 있습니다.

올바른 SLO를 선택하는 것은 복잡한 프로세스입니다. 첫째, 항상 특정 값을 선택할 수는 없습니다. 서비스에 대한 외부 수신 HTTP 요청의 경우 QPS(초당 쿼리) 지표는 주로 사용자의 서비스 방문 희망에 따라 결정되며 이에 대한 SLO를 설정할 수 없습니다.

반면에 각 요청의 평균 대기 시간이 100밀리초 미만이기를 원한다고 말할 수 있습니다. 그러한 목표를 설정하면 짧은 대기 시간으로 프런트엔드를 작성하거나 그러한 대기 시간을 제공하는 장비를 구입해야 할 수도 있습니다. (100밀리초는 분명히 임의의 숫자이지만 대기 시간 수치는 더 낮은 것이 더 좋습니다. 빠른 속도가 느린 속도보다 낫다는 증거가 있으며, 특정 값 이상의 사용자 요청을 처리할 때 대기 시간이 발생하면 실제로 사람들이 멀리 떨어져 있게 된다는 증거가 있습니다. 귀하의 서비스에서.)

다시 말하지만, 이는 언뜻 보기보다 더 모호합니다. 계산에서 QPS를 완전히 제외하면 안 됩니다. 사실 QPS와 대기 시간은 서로 밀접한 관련이 있습니다. QPS가 높을수록 대기 시간이 길어지는 경우가 많으며 서비스는 일반적으로 특정 로드 임계값에 도달하면 성능이 급격히 저하됩니다.

SLO를 선택하고 게시하면 서비스 작동 방식에 대한 사용자 기대치가 설정됩니다. 이 전략을 사용하면 성능 저하 등 서비스 소유자에 대한 근거 없는 불만을 줄일 수 있습니다. 명시적인 SLO가 없으면 사용자는 원하는 성능에 대해 자신만의 기대치를 설정하는 경우가 많으며 이는 서비스를 설계하고 관리하는 사람들의 의견과는 아무런 관련이 없을 수 있습니다. 이러한 상황은 서비스에 대한 기대가 부풀려져 사용자가 서비스에 대한 실제보다 접근성이 더 높을 것이라고 잘못 믿고, 시스템이 실제보다 덜 안정적이라고 사용자가 믿을 때 불신을 야기할 수 있습니다.

계약서

서비스 수준 계약은 포함된 SLO를 충족하거나 충족하지 못한 결과를 포함하는 사용자와의 명시적 또는 암시적 계약입니다. 결과는 금전적인 것(할인이나 벌금)일 때 가장 쉽게 인식되지만 다른 형태를 취할 수도 있습니다. SLO와 SLA의 차이점을 설명하는 쉬운 방법은 "SLO가 충족되지 않으면 어떻게 되나요?"라고 묻는 것입니다. 명확한 결과가 없다면 SLO를 보고 있는 것이 거의 확실합니다.

SLA는 비즈니스 및 제품 결정과 밀접하게 연결되어 있으므로 일반적으로 SRE는 SLA 생성에 관여하지 않습니다. 그러나 SRE는 실패한 SLO의 결과를 완화하는 데 참여합니다. 또한 SLI를 결정하는 데 도움이 될 수 있습니다. 분명히 계약에서 SLO를 측정하는 객관적인 방법이 있어야 하며 그렇지 않으면 의견 차이가 있을 것입니다.

Google 검색은 공개 SLA가 없는 중요한 서비스의 예입니다. Google은 모든 사람이 검색을 최대한 효율적으로 사용하기를 원하지만 전 세계와 계약을 체결하지는 않았습니다. 그러나 검색을 사용할 수 없는 경우에도 여전히 결과가 있습니다. 검색을 사용할 수 없는 경우 당사의 평판이 하락하고 광고 수익도 감소하게 됩니다. Google for Work와 같은 다른 많은 Google 서비스는 사용자와 명시적인 서비스 수준 계약을 맺고 있습니다. 특정 서비스에 SLA가 있는지 여부에 관계없이 SLI 및 SLO를 정의하고 이를 사용하여 서비스를 관리하는 것이 중요합니다.

이론이 너무 많습니다. 이제 경험해 보세요.

실제 지표

서비스 수준을 측정하기 위해 적절한 지표를 선택하는 것이 중요하다는 결론을 내렸다면 이제 어떤 지표가 서비스나 시스템에 중요한지 어떻게 알 수 있습니까?

당신과 당신의 사용자는 무엇에 관심이 있습니까?

모니터링 시스템에서 추적할 수 있는 SLI로 모든 측정항목을 사용할 필요는 없습니다. 사용자가 시스템에서 원하는 것이 무엇인지 이해하면 여러 지표를 선택하는 데 도움이 됩니다. 지표를 너무 많이 선택하면 중요한 지표에 집중하기 어렵고, 적은 수를 선택하면 시스템의 상당 부분이 방치될 수 있습니다. 우리는 일반적으로 시스템 상태를 평가하고 이해하기 위해 몇 가지 주요 지표를 사용합니다.

서비스는 일반적으로 해당 서비스와 관련된 SLI 측면에서 여러 부분으로 나눌 수 있습니다.

• 이 예의 셰익스피어 서비스에 대한 검색 인터페이스와 같은 사용자 정의 프런트 엔드 시스템입니다. 사용 가능하고, 지연이 없고, 대역폭이 충분해야 합니다. 따라서 질문을 할 수 있습니다. 요청에 응답할 수 있습니까? 요청에 응답하는 데 얼마나 걸렸나요? 얼마나 많은 요청을 처리할 수 있나요?
• 스토리지 시스템. 그들은 낮은 응답 대기 시간, 가용성 및 내구성을 중요하게 생각합니다. 관련 질문: 데이터를 읽거나 쓰는 데 얼마나 걸리나요? 요청 시 데이터에 접근할 수 있나요? 필요할 때 데이터를 사용할 수 있나요? 이러한 문제에 대한 자세한 논의는 26장 데이터 무결성: 읽은 내용이 작성되는 내용을 참조하십시오.
• 데이터 처리 파이프라인과 같은 빅 데이터 시스템은 처리량과 쿼리 처리 대기 시간에 의존합니다. 관련 질문: 얼마나 많은 데이터가 처리되나요? 요청 수신부터 응답 발행까지 데이터가 이동하는 데 얼마나 걸리나요? (시스템의 일부 부분에서는 특정 단계에서 지연이 발생할 수도 있습니다.)

지표 수집

많은 서비스 수준 지표는 Borgmon(아래 참조)과 같은 모니터링 시스템을 사용하여 서버 측에서 가장 자연스럽게 수집됩니다. 10장 시계열 데이터를 기반으로 한 연습 알림) 또는 Prometheus 또는 단순히 주기적으로 로그를 분석하여 상태 500의 HTTP 응답을 식별합니다. 그러나 클라이언트 측 모니터링이 부족하면 영향을 미치는 많은 문제가 누락될 수 있으므로 일부 시스템에는 클라이언트 측 메트릭 수집 기능이 갖추어져 있어야 합니다. 사용자에게 영향을 미치지만 서버 측 측정항목에는 영향을 미치지 않습니다. 예를 들어 셰익스피어 검색 테스트 애플리케이션의 백엔드 응답 대기 시간에 초점을 맞추면 JavaScript 문제로 인해 사용자 측에서 대기 시간이 발생할 수 있습니다. 이 경우 브라우저가 페이지를 처리하는 데 걸리는 시간을 측정하는 것이 더 나은 측정 기준입니다.

집합

단순성과 사용 편의성을 위해 원시 측정값을 집계하는 경우가 많습니다. 이 작업은 신중하게 수행되어야 합니다.

초당 요청 수와 같이 일부 측정 항목은 단순해 보이지만 이렇게 간단해 보이는 측정값도 시간이 지남에 따라 암묵적으로 데이터를 집계합니다. 측정값이 초당 한 번씩 수신됩니까, 아니면 분당 요청 수에 대한 평균이 측정됩니까? 후자의 옵션을 사용하면 몇 초 동안만 지속되는 훨씬 더 높은 순간 요청 수를 숨길 수 있습니다. 초당 200개의 요청을 짝수로 처리하고 나머지 시간은 0으로 처리하는 시스템을 생각해 보세요. 초당 요청 100개의 평균값 형태의 상수와 순간 로드의 두 배는 동일한 것이 아닙니다. 마찬가지로 평균 쿼리 대기 시간은 매력적으로 보일 수 있지만 중요한 세부 정보가 숨겨져 있습니다. 즉, 대부분의 쿼리는 빠르지만 느린 쿼리가 많을 수도 있다는 것입니다.

대부분의 지표는 평균보다는 분포로 보는 것이 더 좋습니다. 예를 들어 SLI 대기 시간의 경우 일부 요청은 빠르게 처리되는 반면 일부 요청은 항상 더 오래 걸리거나 때로는 더 오래 걸릴 수도 있습니다. 간단한 평균을 사용하면 이러한 긴 지연을 숨길 수 있습니다. 그림은 예를 보여줍니다. 일반적인 요청을 처리하는 데 약 50ms가 걸리지만 요청의 5%는 20배 느립니다! 평균 대기 시간만을 기반으로 한 모니터링 및 경고는 하루 종일 동작의 변화를 보여주지 않습니다. 실제로는 일부 요청의 처리 시간(맨 위 줄)에 눈에 띄는 변화가 있습니다.

50, 85, 95, 99 백분위수 시스템 지연 시간. Y축은 로그 형식입니다.

지표에 백분위수를 사용하면 분포의 모양과 특성을 확인할 수 있습니다. 99 또는 99,9와 같이 높은 백분위수 수준은 최악의 값을 나타내고, 50번째 백분위수(중앙값이라고도 함)는 가장 빈번한 상태를 나타냅니다. 측정항목. 응답 시간 분산이 클수록 장기 실행 요청이 사용자 경험에 더 많은 영향을 미칩니다. 부하가 높거나 대기열이 있는 경우 효과가 향상됩니다. 사용자 경험 연구에 따르면 사람들은 일반적으로 응답 시간 차이가 높은 느린 시스템을 선호하므로 일부 SRE 팀은 99,9 백분위수에서 메트릭 동작이 양호하면 대부분의 사용자가 문제를 경험하지 않을 것이라는 점을 근거로 높은 백분위수 점수에만 집중합니다. .

통계 오류에 대한 참고 사항

우리는 일반적으로 값 집합의 평균(산술 평균)보다는 백분위수를 사용하여 작업하는 것을 선호합니다. 이를 통해 평균과 상당히 다른(그리고 더 흥미로운) 특성을 갖는 더 많은 분산된 값을 고려할 수 있습니다. 컴퓨팅 시스템의 인위적인 특성으로 인해 메트릭 값이 왜곡되는 경우가 많습니다. 예를 들어 어떤 요청도 0ms 미만의 응답을 받을 수 없으며 시간 제한이 1000ms라는 것은 더 큰 값으로는 성공적인 응답이 불가능함을 의미합니다. 시간 초과보다. 결과적으로 우리는 평균과 중앙값이 동일하거나 서로 가까울 수 있다는 사실을 받아들일 수 없습니다!

사전 테스트 없이 특정 표준 가정과 근사치가 유지되지 않는 한 데이터가 정규 분포를 따른다는 결론을 내리지 않도록 주의합니다. 배포가 예상과 다른 경우 문제를 해결하는 자동화 프로세스(예: 이상값이 발견되면 높은 요청 처리 지연 시간으로 서버를 다시 시작함)가 작업을 너무 자주 수행하거나 충분하지 않을 수 있습니다(둘 다 그렇지 않음). 매우 좋은).

지표 표준화

매번 추측할 필요가 없도록 SLI의 일반적인 특성을 표준화하는 것이 좋습니다. 표준 패턴을 충족하는 모든 기능은 개별 SLI 사양에서 제외될 수 있습니다. 예를 들면 다음과 같습니다.

• 집계 간격: "1분 동안 평균"
• 집계 영역: "클러스터의 모든 작업"
• 측정 빈도: "10초마다"
• 포함되는 요청: "블랙박스 모니터링 작업에서 HTTP GET"
• 데이터 획득 방법: "서버에서 측정된 모니터링 덕분에"
• 데이터 액세스 대기 시간: "마지막 바이트까지의 시간"

노력을 절약하려면 각 공통 지표에 대해 재사용 가능한 SLI 템플릿 세트를 만드세요. 또한 모든 사람이 특정 SLI의 의미를 더 쉽게 이해할 수 있도록 해줍니다.

실제 목표

측정할 수 있는 것이 아니라 사용자가 관심을 갖는 것이 무엇인지 생각(또는 알아내는 것)부터 시작하세요. 사용자가 관심을 갖는 사항은 측정하기 어렵거나 불가능한 경우가 많으므로 결국 사용자의 요구 사항에 더 가까워질 수 있습니다. 그러나 측정하기 쉬운 것부터 시작하면 결국 덜 유용한 SLO가 됩니다. 결과적으로 우리는 처음에 원하는 목표를 식별한 다음 특정 지표를 사용하여 작업하는 것이 지표를 선택한 다음 목표를 달성하는 것보다 더 효과적이라는 사실을 때때로 발견했습니다.

목표를 정의하세요

최대한의 명확성을 위해 SLO 측정 방법과 SLO가 유효한 조건을 정의해야 합니다. 예를 들어 다음과 같이 말할 수 있습니다. 두 번째 줄은 첫 번째 줄과 동일하지만 SLI 기본값을 사용합니다.

• Get RPC 호출의 99%(평균 1분 이상)가 100ms 이내에 완료됩니다(모든 백엔드 서버에서 측정).
• Get RPC 호출의 99%가 100ms 이내에 완료됩니다.

성능 곡선의 모양이 중요한 경우 여러 SLO를 지정할 수 있습니다.

• Get RPC 호출의 90%가 1ms 이내에 완료되었습니다.
• Get RPC 호출의 99%가 10ms 이내에 완료되었습니다.
• Get RPC 호출의 99.9%가 100ms 이내에 완료되었습니다.

사용자가 대량 처리(처리량이 중요한 경우)와 대화형 처리(대기 시간이 중요한 경우) 등 이기종 워크로드를 생성하는 경우 각 로드 클래스에 대해 별도의 목표를 정의하는 것이 좋습니다.

• 고객 요청의 95%에는 처리량이 필요합니다. 실행된 RPC 호출 수를 1초 미만으로 설정합니다.
• 99%의 클라이언트는 대기 시간에 관심이 있습니다. 트래픽이 1KB 미만이고 실행 시간이 10ms 미만인 RPC 호출 수를 설정합니다.

SLO가 100% 충족될 것이라고 주장하는 것은 비현실적이며 바람직하지 않습니다. 이렇게 하면 새로운 기능 도입 및 배포 속도가 느려지고 값비싼 솔루션이 필요할 수 있습니다. 대신 오류 예산(허용된 시스템 가동 중지 시간의 비율)을 허용하고 이 값을 매일 또는 매주 모니터링하는 것이 좋습니다. 고위 경영진은 월별 또는 분기별 평가를 원할 수 있습니다. (오류 예산은 단순히 다른 SLO와 비교하기 위한 SLO입니다.)

SLO 위반 비율은 오류 예산과 비교할 수 있습니다(3장 및 섹션 참조). "오류 예산에 대한 동기"), 새 릴리스를 배포할 시기를 결정하는 프로세스에 대한 입력으로 사용되는 차이 값이 있습니다.

목표값 선택

계획 값(SLO) 선택은 선택한 SLI, SLO(및 가능한 경우 SLA)에 반영되어야 하는 제품 및 비즈니스 관심 사항으로 인해 순전히 기술적인 활동이 아닙니다. 마찬가지로 인력 배치, 출시 기간, 장비 가용성 및 자금 조달과 관련된 문제에 관한 정보를 교환해야 할 수도 있습니다. SRE는 이 대화에 참여해야 하며 다양한 옵션의 위험과 실행 가능성을 이해하는 데 도움이 되어야 합니다. 보다 생산적인 토론을 보장하는 데 도움이 될 수 있는 몇 가지 질문을 생각해 냈습니다.

현재 성과를 기준으로 목표를 선택하지 마십시오.
시스템의 강점과 한계를 이해하는 것이 중요하지만, 추론 없이 측정 기준을 적용하면 시스템을 유지 관리하는 데 방해가 될 수 있습니다. 상당한 재설계 없이는 달성할 수 없는 목표를 달성하려면 영웅적인 노력이 필요합니다.

단순하게 유지
복잡한 SLI 계산으로 인해 시스템 성능의 변화가 숨겨지고 문제의 원인을 찾기가 더 어려워질 수 있습니다.

절대적인 것을 피하세요
대기 시간을 늘리지 않고 무한정 증가하는 로드를 처리할 수 있는 시스템을 갖고 싶은 유혹이 있지만, 이 요구 사항은 비현실적입니다. 이러한 이상에 접근하는 시스템은 설계 및 구축에 많은 시간이 필요할 가능성이 높으며, 운영 비용이 많이 들고, 그 이하의 작업을 수행하려는 사용자의 기대에 비해 너무 좋을 것입니다.

가능한 한 적은 수의 SLO를 사용하세요.
시스템 속성을 적절하게 적용하려면 충분한 수의 SLO를 선택하세요. 선택한 SLO 보호: 특정 SLO를 지정하여 우선순위에 대한 논쟁에서 결코 승리할 수 없다면 해당 SLO를 고려할 가치가 없을 것입니다. 그러나 모든 시스템 속성이 SLO를 적용할 수 있는 것은 아닙니다. SLO를 사용하여 사용자 만족도 수준을 계산하기는 어렵습니다.

완벽함을 추구하지 마세요
로드 시 시스템 동작에 대해 자세히 알아보면 시간이 지남에 따라 SLO의 정의와 목표를 언제든지 구체화할 수 있습니다. 지나치게 엄격한 목표를 선택하여 달성할 수 없다고 판단되면 완화해야 하는 것보다 시간이 지남에 따라 다듬을 수 있는 부동 목표로 시작하는 것이 더 좋습니다.

SLO는 사용자의 관심사를 반영하므로 SRE 및 제품 개발자의 작업 우선순위를 결정하는 핵심 동인이 될 수 있고 그래야 합니다. 좋은 SLO는 개발팀에게 유용한 시행 도구입니다. 그러나 잘못 설계된 SLO는 팀이 지나치게 공격적인 SLO를 달성하기 위해 영웅적인 노력을 기울이면 낭비적인 작업으로 이어질 수 있고, SLO가 너무 낮으면 품질이 낮은 제품이 될 수 있습니다. SLO는 강력한 수단이므로 현명하게 사용하세요.

측정을 제어하세요

SLI 및 SLO는 시스템을 관리하는 데 사용되는 핵심 요소입니다.

• SLI 시스템을 모니터링하고 측정합니다.
• SLI와 SLO를 비교하고 조치가 필요한지 결정합니다.
• 조치가 필요하다면 목표를 달성하기 위해 어떤 일이 일어나야 하는지 파악하세요.
• 이 작업을 완료하세요.

예를 들어 2단계에서 요청 시간이 초과되어 아무 작업도 수행하지 않으면 몇 시간 내에 SLO가 중단되는 것으로 나타나면 3단계에서는 서버가 CPU에 바인딩되어 있고 더 많은 서버를 추가하면 부하가 분산된다는 가설을 테스트하는 작업이 포함될 수 있습니다. SLO가 없으면 조치를 취해야 할지 여부(또는 시기)를 알 수 없습니다.

SLO 설정 - 그러면 사용자 기대치가 설정됩니다.
SLO를 게시하면 시스템 동작에 대한 사용자 기대치가 설정됩니다. 사용자(및 잠재 사용자)는 서비스가 사용하기에 적합한지 이해하기 위해 서비스에서 무엇을 기대할 수 있는지 알고 싶어 하는 경우가 많습니다. 예를 들어, 사진 공유 웹 사이트를 사용하려는 사람들은 동일한 서비스가 아카이브 기록 관리 시스템에 이상적일지라도 가용성이 약간 떨어지는 대신 수명과 저렴한 비용을 약속하는 서비스 사용을 피하고 싶어할 수 있습니다.

사용자에 대한 현실적인 기대치를 설정하려면 다음 전략 중 하나 또는 둘 다를 사용하십시오.

• 안전 여유를 유지하십시오. 사용자에게 광고되는 것보다 더 엄격한 내부 SLO를 사용하세요. 이를 통해 문제가 외부에 드러나기 전에 대응할 수 있는 기회를 얻을 수 있습니다. 또한 SLO 버퍼를 사용하면 시스템 성능에 영향을 미치는 릴리스를 설치할 때 안전 여유를 확보할 수 있으며 다운타임으로 인해 사용자를 불편하게 하지 않고도 시스템을 쉽게 유지 관리할 수 있습니다.
• 사용자의 기대를 초과하지 마십시오. 사용자는 귀하가 말하는 것이 아니라 귀하가 제공하는 것을 기반으로 합니다. 서비스의 실제 성능이 명시된 SLO보다 훨씬 나은 경우 사용자는 현재 성능에 의존하게 됩니다. 의도적으로 시스템을 종료하거나 가벼운 부하에서 성능을 제한하면 과도한 의존성을 피할 수 있습니다.

시스템이 기대치를 얼마나 잘 충족하는지 이해하면 시스템 속도를 높이고 접근성과 탄력성을 높이는 데 투자할지 여부를 결정하는 데 도움이 됩니다. 또는 서비스 성능이 너무 좋으면 기술 부채 상환, 새로운 기능 추가 또는 새로운 제품 출시와 같은 다른 우선 순위에 일부 직원 시간을 투자해야 합니다.

실제 계약

SLA를 작성하려면 비즈니스 및 법무팀이 SLA 위반에 대한 결과와 처벌을 정의해야 합니다. SRE의 역할은 SLA에 포함된 SLO를 충족하는 데 발생할 수 있는 문제를 이해하도록 돕는 것입니다. SLO 생성에 대한 대부분의 권장 사항은 SLA에도 적용됩니다. SLA가 많을수록 불합리하거나 충족하기 어려워 보이는 SLA를 변경하거나 제거하기가 더 어렵기 때문에 사용자에게 약속하는 것에 대해서는 보수적인 것이 현명합니다.

번역을 끝까지 읽어주셔서 감사합니다. 모니터링에 대한 내 전보 채널을 구독하십시오. 모니터im_it и Medium의 블로그.

출처 : habr.com