이 가이드는 서비스 수준 관리의 품질을 개선하고 최적화하는 방법을 안내합니다. 이것은 관찰 가능성 성숙도에 대한 시리즈 의 일부입니다.
개요
서비스 수준 관리는 데이터를 모든 이해 관계자가 쉽게 전달할 수 있는 보편적인 언어로 표준화하는 관행입니다. IT는 일반적으로 비즈니스에 대해 말하지 않고 비즈니스는 일반적으로 IT에 대해 말하지 않으므로 안정성을 향상시키기 위해 관찰 가능성 언어 장벽을 먼저 해결해야 합니다.
신뢰성을 명확히 하기 위한 보편적인 언어에 대한 이러한 필요성은 서비스 수준 관리를 다시 대중화한 것입니다. 서비스 수준 관리는 가동 시간, 성능 및 안정성 측면 에서 가장 잘 알려져 있습니다. 그러나 서비스 수준 관리는 고객 경험 , 혁신 및 성장 , 운영 효율성 의 다른 관행에도 적용됩니다( 이러한 관행에 대해 자세히 알아보기 ).
이 구현 가이드는 가동 시간, 성능 및 안정성 사례의 맥락에서 서비스 수준 관리 사례를 알려줍니다.
원하는 결과
사업성과
신뢰성을 구현하는 데 필요한 비즈니스 결과는 비즈니스에 영향을 미치는 사고의 수, 기간 및 해당 사고에 관련된 사람들의 수를 줄이는 것입니다.
- 업무 중단 사고의 수 감소
- 평균 해결 시간(MTTR) 단축
- 심각한 사고당 평균 참여 인원(FTE) 감소
운영 결과
신뢰성 관행 내에서 서비스 수준 관리에 필요한 운영 결과는 디지털 제품 상태를 성공적으로 전달하는 것입니다. 운영 성공은 표준 서비스 수준이 적용되는 주요 제품 애플리케이션의 비율과 주요 이해 관계자가 채택한 비율로 측정됩니다. 이는 이해 관계자, 표준화, 단순성 보장, 컨설팅 및 서비스 수준 관리의 효율성 입증에 중요한 것에 집중함으로써 달성됩니다.
술어
다음은 이 가이드를 사용하기 전에 이해하는 데 도움이 될 수 있는 몇 가지 용어입니다.
핵심 성과 지표
서비스 상태란 무엇입니까?
상태는 클라이언트에서 최종 응답, 연결성 및 렌더링 가능성으로 측정된 모든 서비스 성능의 합계입니다. 현실은 귀하의 서비스가 "디지털 제품"이며 해당 제품은 사용자가 얼마나 잘 받는가에 달려 있다는 것입니다. 귀하의 기술은 최대한 복잡하지만 외부 API를 제외하고는 대부분 인터넷에서 볼 수 없는 폐쇄형 시스템입니다.
가장 중요한 상태 KPI는 다음 질문에 답하여 수집됩니다.
- 얼마나 빠르고 성공적으로 사용자에게 응답을 전달할 수 있습니까?
- 사용자가 당사 서비스에 연결할 수 있습니까?
- 클라이언트 앱이 콘텐츠를 빠르고 성공적으로 렌더링할 수 있습니까?
- 중요한 데이터를 빠르고 성공적으로 처리할 수 있습니까?
서비스 상태가 아닌 것은 ?
전통적으로 IT는 CPU, RAM, 디스크, 네트워크 등과 같은 하드웨어 데이터의 상태를 상호 연관시킬 수 있었습니다. 그러나 오늘날의 인프라 기술은 특히 Kubernetes와 같은 로드 밸런싱 및 오케스트레이션된 인프라와 같은 많은 부분을 보완합니다. 오늘날 이러한 "메트릭"은 진단 데이터로 간주되며 애플리케이션 성능 문제가 감지될 때 확인해야 하는 오류 지점의 일부일 뿐입니다.
서비스 상태는 독점적인 인프라 데이터가 아니며 독점적인 최종 사용자 클라이언트 성능 데이터도 아닙니다. 흥미롭게도 많은 사람들이 먼저 실제 사용자 모니터링(RUM) 또는 종단 간 트랜잭션 데이터(분산 추적)를 확인하여 상태를 확인하지만 더 많은 질문이 남아 있습니다.
사전 조치(사전적) 전에 대응(적극적)하는 방법을 배우십시오.
초기 건강 데이터를 설정할 때 사후 대응 및 사전 예방 조치에 대해 논의하는 것이 일반적입니다. 예를 들어 인프라의 하드웨어 성능을 알고 있으면 장애를 예측할 수 있습니다. 모놀리스 아키텍처가 지배적이었을 때 이전 진술이 사실이었던 때가 있었습니다. 분산 시스템은 하드웨어 성능과 해당 하드웨어에 있는 응용 프로그램의 출력 성능 사이에 선형 관계(1:1)가 없기 때문에 오늘날에는 완전히 사실이 아닙니다.
진정한 사전 예방을 위해서는 먼저 실제 입력 및 출력 데이터 포인트를 설정해야 합니다. 대응하기 전에 먼저 무엇을 측정해야 하는지 알아야 합니다. 사전 대응(선제적)을 하기 전에 먼저 대응하는 방법을 배워야 합니다. 단순하게 유지하고 점진적으로 기술을 구축하십시오. 이 가이드는 사전 예방적 행동으로 가는 가장 빠른 경로를 보여줍니다.
현실은 고객과 가장 가깝지만 클라이언트 장치보다 먼저 애플리케이션 계층에서 시작하는 것이 고객의 관점에서 건강 데이터를 관찰하는 가장 빠른 경로라는 것입니다.
기본 상태 데이터 포인트 및 해당 KPI
아래에 정의된 대로 이 가이드에서 출력 성능 및 입력 성능에 대한 서비스 수준 목표를 설정하고 측정하는 방법을 배웁니다.
고객 성과는 고객 경험에 대한 구현 가이드: 품질 기반 에서 다룹니다.
각 사용 사례는 데이터 입력, 출력 및 원하는 결과에 따라 크게 다르기 때문에 이 가이드에서는 데이터 품질을 다루지 않습니다.
클라이언트 성능 단계를 진행하기 전에 먼저 출력 성능 및 입력 성능 단계를 완료하는 것이 좋습니다. 출력 및 입력 SLO는 생성하기가 매우 쉽고 출력 및 입력 상태 데이터를 먼저 사용하는 것이 훨씬 더 큰 투자 수익을 얻을 수 있습니다. 설정하기 쉬울 뿐만 아니라 입력 및 출력 데이터 포인트는 안정성 여정에서 훨씬 더 빨리 수정 경로를 제공합니다.
전제 조건
기술 지원
학습 지원
- 적극 권장 : 이 서비스 수준 가이드에 대한 무료 대화형 온라인 과정
- 대시보드 및 NRQL 을 통해 기본 기술 달성
- 서비스 수준 관리 UI 검토
출력 성능 SLI 설정
다음은 출력 성능 SLI를 설정하는 단계에 대한 개요입니다.
- 서비스 식별
- 서비스 경계 식별
- 기준선 설정
- 서비스 수준 만들기
이제 이러한 단계를 더 자세히 설명합니다.
1. 서비스 식별
다음이 가정됩니다.
- 기본 애플리케이션은 New Relic APM 에이전트 로 계측됩니다.
- 애플리케이션 이름은 서비스 특성화 가이드 에 설명된 대로 친숙한 명명 규칙을 따릅니다.
- 엔터티 탐색기 에서 애플리케이션을 찾을 수 있습니다.
엔티티 탐색기에서 애플리케이션( Services - APM 엔티티 유형)을 찾아 선택합니다. 아래 개요 화면이 표시되어야 합니다. 아직 Service levels 클릭하지 마십시오.
2. 서비스 경계 식별
위의 용어 섹션 에서 서비스 경계 의 정의를 읽으십시오.
여기서 목표는 먼저 서비스의 출력을 측정하고 있는지 확인하는 것입니다. 해당 응용 프로그램의 종속성이 각각 응답 시간과 성공률에서 역할을 하지만 최종 및 총 응답 시간과 성공은 요청이 수신되고 응답되는 지점에서 쉽게 측정됩니다.
서비스 맵 및 오토맵 을 사용하여 보고 있는 애플리케이션이 엔드포인트 API를 실행하는 애플리케이션 또는 애플리케이션의 종속성인지 판별하는 데 도움이 됩니다.
예시
아래 스크린샷에서 귀하는 주문 처리를 지원하는 모든 애플리케이션에 대한 책임이 있습니다. 시작하기 위해 #2(Order-Composer)를 선택하고 Service maps 를 클릭했으며 Order-Composer가 실제로 종속성임을 발견했습니다. 따라서 진정한 의료 서비스 수준을 설정하려면 #1(주문 처리)을 선택해야 합니다.
귀하의 팀은 종속성인 Order-Composer에 대해서만 책임을 질 수 있습니다. 그렇다면 Order-Composer의 자체 서비스 수준은 자체 성능 모니터링에 완벽하게 적합합니다. 상태 보고서에서 더 나은 필터링을 위해 고객이 아닌 서비스 수준에 customer-facing:false 으로 태그를 지정해야 합니다. 또한 진정한 출력 성능, 입력 연결 서비스 수준 및 클라이언트 서비스 수준을 설정하기 위해 관찰 가능성 여정에서 고객 대면 엔드포인트(#1 주문 처리)와 협력하는 것을 고려하십시오.
3. 기준선 설정
기준을 설정하는 것은 서비스 수준의 채택 및 구현을 가속화하기 위한 중요한 단계입니다. 서비스 에 대한 설계 사양이 무엇인지 또는 있어야 했는지를 결정하는 것은 더 어렵습니다. 기준선을 설정하면 서비스의 현재 성능을 측정할 수 있으며 서비스 수준 보고서를 통해 기준선에 도달했는지 아니면 성능이 저하되었는지 알 수 있습니다.
거의 모든 데이터 세트에 대한 기준선을 만들 수 있습니다. 그러나 사용 사례에 따라 다른 공식과 권장 사항이 있습니다. 예를 들어 일부 데이터 세트에는 평균을, 다른 데이터 세트에는 백분위수를, 다른 데이터 세트에는 최대값을 사용해야 합니다.
서비스 수준을 시작할 때 애플리케이션의 출력 성능 부터 시작해야 합니다. 이를 위해 응답 시간(대기 시간)과 오류가 아닌 비율(성공)을 사용합니다.
어느 정도의 역사를 고려해야 합니까? 많지는 않습니다. 안정성 상태 측정항목을 설정하고 있습니다. 계절성과 최대 사용량은 좋은 성능을 위한 핸디캡이 아닙니다. 또한 측정에 더 많은 기록을 포함할수록 릴리스의 다른 코드베이스를 포함할 가능성이 높아집니다. 이전 배포는 아무리 작더라도 결과를 왜곡할 수 있습니다.
권장 기록은 공정한 기준을 설정하기 위해 1-2주 동안의 성능 데이터입니다.
예시 기준선
다음은 대기 시간에 대한 7일 서비스 수준 목표의 권장 목표를 나타내는 NRQL 쿼리의 예입니다.
FROM Transaction SELECT percentile(duration, 95) AS 'Latency Baseline SLI' WHERE appName='Order-Processing' SINCE 1 WEEK AGO성공(오류 없는) 기준선을 위해 다음 쿼리를 시도하십시오. 자신의 애플리케이션 이름을 Order-Processing 으로 대체해야 합니다.
FROM Transaction SELECT percentage(count(*), WHERE error is false) AS 'Success Baseline SLI' SINCE 1 WEEK AGO WHERE appName='Order-Processing'4. 서비스 수준 만들기
New Relic 플랫폼은 권장 사항을 자동으로 계산합니다. 그리고 당신을 위한 기준선.
참고: 서비스 수준 추가 버튼이 표시되지 않으면 New Relic 관리자에게 권한을 확인하십시오.
위의 " 서비스 식별 " 섹션은 애플리케이션 APM 데이터를 찾는 방법을 보여줍니다. "서비스 수준"이라는 동일한 섹션의 스크린샷에서 #2를 볼 수 있습니다. 애플리케이션 APM 데이터를 찾고 서비스 수준 을 클릭합니다. 아래 보기를 참조해야 합니다.
기본 서비스 수준 목표 추가를 클릭하면 거의 즉시 대기 시간 SLI 및 성공 SLI와 각각의 목표가 생성됩니다.
각 SLO 스코어카드의 오른쪽 상단 모서리에 있는 세 개의 점 아이콘을 클릭하여 모든 설정을 보고 변경할 수 있습니다.
참고: 데이터가 SLO 점수를 채우는 데 약 10분이 소요됩니다. 이는 데이터 수명 및 쿼리 성능을 위해 이벤트-메트릭 서비스 를 사용하기 때문입니다. 변환이 발생하고 데이터를 채우기 시작하는 데는 잠시 시간이 걸립니다.
입력 성능 SLI 설정
입력 성능 SLI 설정 프로세스 개요:
- 합성 수표를 만드십시오.
- 서비스 수준 지표를 만드십시오.
다음은 이러한 단계에 대한 자세한 내용입니다.
1. 합성 수표 만들기
가장 일반적인 입력 성능 서비스 수준은 종종 "연결성" 또는 "가동 시간"이라고 합니다. 이는 상태 API 엔드포인트에 대한 간단한 검사이거나 단순히 URL을 로드하는 것입니다. 이 두 가지 모두 당사의 종합 모니터링 서비스를 사용하여 쉽게 수행할 수 있습니다. 데이터 보고를 시작하는 방법을 알아보려면 간단한 브라우저 모니터 추가 및 스크립팅된 API 테스트 추가 를 참조하세요.
2. 서비스 수준 지표 생성
첫 번째 단계를 완료하면 이제 데이터가 있어야 합니다.
이제 서비스 수준 관리 서비스를 사용하여 입력 지표 및 목표를 생성합니다.
entity explorer [엔터티 탐색기] 에서 오른쪽의 Service levels [서비스 수준을] 선택한 다음 + Add a service level indicator [+서비스 수준 표시기 추가를] 클릭합니다.
참고: 서비스 수준 추가 버튼이 표시되지 않으면 New Relic 관리자에게 권한을 확인하십시오.
다음으로 항목 유형을 Synthetic monitors 으로 필터링합니다. 아래 스크린샷을 참조하세요.
다음 단계:
- 해당 목록에서 합성 모니터를 찾아 클릭합니다. 그러면 왼쪽 패널에서 계속 버튼이 활성화됩니다. 계속 을 클릭합니다.
- 성공 서비스 수준에 대한 권장 설정 버튼이 표시됩니다(아래 참조). 클릭하세요.
- 필요에 따라 태그, 제목 및 설명을 적절하게 변경합니다.
- 저장 을 클릭합니다.
기능 SLI 설정
여기에서 서비스 수준 채택을 실제로 가속화할 수 있습니다!
이 작업을 완료하기 위해 응용 프로그램이나 서비스에 대한 친밀한 지식이 필요하지 않습니다. 소비자 대면 API(서비스 경계)가 어디에 있는지 알고 아래 단계를 따르기만 하면 됩니다.
이것은 관찰 가능성 성숙도 여정의 주요 단계입니다. 로그인 또는 결제 승인과 같은 중요한 비즈니스 기능에 대한 서비스 수준을 갖추면 IT와 비즈니스 간의 언어 장벽이 빠르게 해소될 것입니다. 기능에 대한 서비스 수준 점수는 서비스 수준이 저하되기 시작할 때 보다 정확한 수정 경로를 제공합니다. 예를 들어 로그인 서비스 수준이 저하되기 시작하면 소비자 대면 API에서 시작하는 ID 관리 종속성과 워크플로를 살펴봐야 합니다.
참고: 이 작업에서는 " 출력 SLI 설정 " 섹션에서 배운 기술을 기반으로 합니다.
이 프로세스의 개요는 다음과 같습니다.
- 애플리케이션 기능을 평가합니다.
- 기능의 기준을 설정합니다.
- 기능 서비스 수준을 만듭니다.
이러한 단계는 아래에서 더 자세히 설명됩니다.
위 의 출력 SLI 설정 섹션에 설명된 대로 서비스 경계 애플리케이션을 식별합니다.
다음 NRQL 쿼리를 실행하여 가장 자주 사용되는 트랜잭션의 기준선을 식별합니다. Order-Processing 을 식별한 애플리케이션 이름으로 바꿔야 합니다.
FROM Transaction SELECT count(*), percentile(duration, 95) WHERE appName='Order-Processing' FACET name SINCE 1 WEEK AGO아래 스크린샷과 비슷한 내용이 표시되어야 합니다.
"구매"와 관련이 있는 첫 번째 거래 상태가 표시됩니다. 이제 "구매" 기능 서비스 수준을 생성할 수 있습니다.
참고: 이 거래가 구매 기능을 나타내는지 확실하지 않더라도 이 연습은 응용 프로그램 팀과 리더십에 기능 서비스 수준의 가치를 보여주는 좋은 예가 됩니다. 여기서의 목표는 가능한 기술을 보여줌으로써 이해 관계자와 대화를 시작하는 것임을 기억하십시오.
쿼리 끝에 WHERE name='Controller/Sinatra//purchase' 을 추가하고 Controller/Sinatra//purchase 을 거래 이름으로 바꿉니다. 쿼리를 실행하여 작동하는지 확인하십시오. 이제 결과에 하나의 트랜잭션만 표시되어야 합니다. 이 쿼리와 DURATION (95%) 결과를 메모장에 복사합니다. 잠시 후 둘 다 필요합니다.
플랫폼에서 새 서비스 수준을 만듭니다. 새 서비스 수준 시작 은 입력 성능 SLI 설정에 설명되어 있습니다.
이 경우 항목 GUID를 통해 메타데이터(태그)를 유지할 수 있도록 목록에서 애플리케이션(APM Entity 유형)을 찾고 싶습니다. 위 섹션의 "합성 모니터" 대신 엔터티 필터 드롭다운에서 "APM"을 선택합니다.
적절하고 유효한 쿼리가 자동으로 채워지도록 "대기 시간" 안내 워크플로를 선택합니다.
메모장을 사용하여 name='your/transaction/name/here' 만 복사합니다.
아래 스크린샷에서 밑줄이 그어진 것처럼 서비스 수준의 두 쿼리에 AND 이 앞에 오는 이 조건을 추가합니다.
메모장에 복사된 원래 기준선의 DURATION (95%) 결과와 일치하도록 두 번째 쿼리의 duration < 1.78 부분을 조정하기만 하면 됩니다.
이 서비스 수준의 이름을 지정하고 설명을 업데이트한 다음 서비스 수준을 저장합니다.
이러한 기능 서비스 수준 중 몇 가지를 설정하고 피드백을 위해 애플리케이션 팀과 리더에게 프레젠테이션하는 것이 좋습니다.
개선 프로세스
경보 품질 관리
경보 품질 관리 는 서비스 수준 관리와 정말 잘 어울리는 또 다른 관찰 가능성 성숙도 방식입니다. 경고 품질 데이터와 서비스 수준 데이터를 나란히 사용하는 경우 경고 정책이 실제 영향에 맞게 조정되었는지 아니면 소음만 발생하는지 확인할 수 있다는 점에서 가치가 있습니다. 좋은 알림, 누락된 알림 및 시끄러운 알림의 유효성을 검사할 수 있습니다.
알림 품질 쿼리와 함께 SLI 준수 쿼리가 있는 사용자 지정 대시보드를 만들어 이를 수행할 수 있습니다.
아직 확인하지 않았다면 알림 품질 관리 가이드 를 확인하세요.
채택 및 지속적인 개선
서비스 수준과 안정성을 개선하려면 서비스의 모든 이해 관계자가 이 관행을 채택해야 합니다. 여기에는 엔지니어링 관리, 제품 관리 및 경영진 관리가 포함되지만 이에 국한되지 않습니다. 주요 목표는 이해 관계자에게 실제로 중요한 것이 무엇인지에 대한 의미 있는 토론을 시작하기 위해 이해 관계자에게 서비스 수준의 힘과 가치를 신속하게 입증하는 것입니다. 이 가이드의 단계를 통해 의미 있는 토론을 매우 빠르게 진행할 수 있습니다.
채택률이 높은 입증된 방법은 먼저 하나의 디지털 제품과 주요 기능에 대한 출력 성능 및 입력 성능 서비스 수준을 설정하는 것입니다. 여기에는 일반적으로 각 엔드포인트 애플리케이션에 대한 하나의 전체 출력 및 입력 서비스 수준(보통 1-2개)이 포함되며, 그 다음에는 엔드포인트 트랜잭션에서 측정된 가정된 중요 기능에 대한 약 4-7개의 출력 성능 서비스 수준이 포함됩니다.
이 방법에는 측정해야 하는 것과 측정하지 말아야 하는 것에 대해 각 이해관계자를 조사하지 않는 것이 포함됩니다. 설문 조사는 일반적으로 긴 대기 시간, 많은 질문, 좌절, 입증된 가치의 부족 및 최적이 아닌 답변을 초래합니다. 베이스라인과 주요 트랜잭션을 "기능"으로 시작한다는 것을 기억하십시오.
위에서 설명한 것처럼 이러한 끝점이 무엇인지, 어떤 끝점 트랜잭션이 어떤 기능을 구성하는지 자유롭게 가정합니다. 처음에는 정확성이 핵심이 아닙니다. 성공적인 시작의 핵심은 건강을 쉽게 측정하고 전달할 수 있는 능력을 입증하는 것입니다. 초기 시연은 기본 서비스 수준에서 측정되는 것과 측정되지 않는 것을 개선하기 위해 더 많은 시간을 투자하는 것의 가치를 보여줄 것입니다.
기다리지 마세요. 해당 시연을 빨리 제공하고 시연을 더 완벽하게 할수록 더 빨리 광범위한 채택을 달성하고 모든 이해 관계자와 협력하여 안정성 개선 프로세스를 시작할 수 있습니다!
오토메이션
이해 관계자에게 효과가 있는 것과 그렇지 않은 것을 설정했으면 자동화를 통해 규모에 맞게 SLM을 설계할 수 있습니다. New Relic Terraform 라이브러리 를 공부하여 서비스 수준 관리 자동화에 대한 학습을 시작할 수 있습니다.
사업 가치
위의 " 원하는 결과 " 섹션에 명시된 바와 같이; 이전의 결론은 사고에 영향을 미치는 비즈니스 비용을 줄이는 것입니다.
그러나 서비스 수준은 사고 중 예상 수익 손실과 구독 기반 비즈니스의 예상 수익을 정량화하는 데도 도움이 될 수 있습니다.
수익 손실 은 온라인 소매와 같은 거래에 의해 생성된 수익과 비즈니스에 벌금이 내장된 서비스 수준 계약 계약이 있는 경우 지불한 벌금에 대해 쉽게 추정할 수 있습니다.
위험 수익은 각 고객이 월간 또는 연간 구독 가치를 갖는 구독 기반(SaaS) 비즈니스 모델에 대한 것입니다. 영향을 받는 고객 수와 기간별 구독 수익을 쉽게 추정하여 "위험 수익"을 계산할 수 있습니다. 참고: 구독 비즈니스는 서비스 수준 계약 계약 내에서 위약금을 받을 수도 있습니다. 이 계약은 아래에 명시된 대로 포함되어야 합니다.
서비스 수준 계약 위반의 직접적인 비용 정량화
이전 위반의 비용을 결정합니다. 예를 들어 온라인 소매업체는 서비스 손실(중단 시간) 동안 분당 예상 수익 손실을 알고 있습니다. 법무팀은 서비스 수준 계약(SLA) 계약 위반의 벌금 비용을 알려줄 수 있습니다. 두 손실 모두 서비스 수준 위반에 대한 New Relic 데이터를 사용하여 실시간으로 쉽게 추정 할 수 있습니다.
서비스 수준 위반의 수익 기회 비용 정량화
아래의 세 가지 변수를 결정하십시오.
- (A) 벌금 또는 수익 손실을 유발하는 위반 횟수
- (B) 평균 위반 기간
- (C) 분/시간당 평균 벌금 또는 수익 손실
이 세 가지 변수(A B C)를 곱하여 복구할 수 있는 총 수익 기회를 계산합니다.
수익 누출 정량화
아래 두 변수를 결정하십시오.
- (A) 총 수익(기간당)
- (나) 고객에게 지급한 위약금 총액(A와 같은 기간 기준)
B/A를 나누어 수익 누출 % 비율을 계산합니다.
서비스 수준 목표 추적
서비스 수준은 테스트, 경고, 게임 데이 및 기타 반복되는 관행과 마찬가지로 하나의 관행입니다. 시스템의 "상태"를 측정하는 데 도움이 되는 과학적 도구로 생각할 수 있습니다. 그러나 모든 도구와 마찬가지로 서비스 수준에는 보정이 필요합니다.
팀 프로세스에 서비스 수준 관행을 포함시키십시오. 다음 권장 사항은 New Relic의 팀 내에서 서비스 수준을 사용한 경험에서 추출되었으며 특정 팀 요구 사항에 맞게 조정해야 합니다.
서비스 수준을 정기적으로 검토하고 다음에 주의하십시오.
SLI는 인시던트 및 페이지를 반영합니까?
일주일 동안 오류 예산은 얼마입니까?
- 너무 낮으면 드롭의 원인을 조사하고 "분석" 기능을 사용하여 드롭을 일으킨 나쁜 이벤트를 찾습니다.
- 100%이면 지표가 정확하고 SLO가 충분히 공격적인지 확인하세요. 100%이면 SLO가 너무 안전함을 나타냅니다.
- 다양한 기간(1d/7d/28d)에서 관찰되는 추세는 무엇입니까?
경기가 있는 날에는 SLI를 주시하십시오. SLI는 경고와 마찬가지로 영향을 반영해야 합니다.
프로덕션에서 오류 예산이 줄어들면 스테이징에서 오류가 발생하지 않은 이유를 평가하십시오.
다음 단계
관찰 가능성 성숙도 관행의 다음 단계는 클라이언트 브라우저 또는 모바일 장치에서 측정된 고객 경험 서비스 수준을 추가하는 것입니다. 다시 말하지만, 위의 개선 프로세스에서 설명한 대로 먼저 가치를 증명하는 것이 중요합니다. 기억하십시오. 관찰 가능성은 여정이며 성숙에는 시간, 연습 및 인내가 필요합니다.
여행을 계속하려면 다음을 참조하세요.
- 고객 경험에 대한 가이드: 품질 기반 .
- 아직 확인하지 않았다면 경보 품질 관리 에 대한 가이드를 참조하세요.