In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.
서비스 수준 관리는 데이터를 보편적인 언어로 표준화하는 관행입니다. 조직 내에서 이해관계자 간의 의사소통은 필요 이상으로 어려운 경우가 많습니다. IT 부서는 일반적으로 조직의 비즈니스 중심 부분이 이해할 수 있는 용어로 말하지 않으며, 결과적으로 IT 팀이 유용하다고 생각하는 용어로 의사소통하지도 않습니다. 안정성을 높이려면 이 언어 장벽을 해결하면 문제를 예방하는 데 도움이 됩니다. 서비스 수준 관리 또는 모든 당사자가 이해할 수 있는 보편적인 언어로 데이터를 표준화하는 방식이 이를 수행하는 데 도움이 됩니다.
서비스 수준 관리는 업타임, 성능 및 신뢰성 관행에 가장 잘 적용되지만 고객 경험, 혁신 및 성장, 운영 효율성 등 다른 관행에도 적용됩니다(이러한 관행에 대해 자세히 알아보십시오). 개선하려는 영역이 무엇이든 SLM을 사용하면 비즈니스 성과와 운영 결과라는 두 가지 주요 영역에 영향을 미칠 수 있습니다.
신뢰성 측면에서 요구되는 비즈니스 성과는 비즈니스에 영향을 미치는 인시던트 수, 기간 및 관련 인원 수를 줄이는 데 중점을 둡니다.
비즈니스를 방해하는 인시던트의 수를 줄입니다.
평균해결시간(MTTR)(MTTR)을 줄입니다.
심각한 인시던트당 평균 참여자 수(FTE)를 줄입니다.
신뢰성 측면에서 필요한 운영 결과는 디지털 제품의 상태에 중점을 둡니다.
표준 서비스 레벨에서 다루는 중요한 제품 애플리케이션의 비율을 기준으로 운영 성공을 측정하세요.
주요 이해관계자의 정책 채택 비율을 조사합니다.
이해관계자에게 중요한 것에 집중하고, 단순성을 보장하며, 서비스 수준 관리의 효율성을 입증하세요.
서비스 수준 관리를 사용하는 이유는 무엇입니까?
서비스 레벨과 안정성을 향상하려면 서비스의 모든 이해관계자가 관행을 채택해야 합니다. 여기에는 서비스 레벨의 힘과 가치를 신속하게 보여주고 각 그룹에 중요한 것이 무엇인지에 대한 논의를 시작하기 위한 엔지니어링 관리, 제품 관리, 경영진이 포함됩니다. 이 가이드의 단계를 수행하면 의미 있는 토론을 매우 빠르게 진행할 수 있습니다.
일반적인 방법은 먼저 하나의 디지털 제품에 대한 출력 성능과 입력 성능 서비스 레벨과 그 핵심 성능을 확립하는 것입니다. 여기에는 일반적으로 각 엔드포인트 애플리케이션(보통 1개 또는 2개)에 대해 하나의 전체 출력 및 입력 서비스 레벨이 포함되며, 엔드포인트 트랜잭션에서 측정된 가정된 중요 기능에 대해 약 4-7개의 출력 성능 서비스 레벨이 포함됩니다.
이 방법은 측정해야 할 것과 측정하지 말아야 할 것을 각 이해관계자에게 설문조사하지 않습니다. 이와 같은 시나리오에서는 설문조사가 너무 오래 걸리고 너무 많은 부분을 포함하기 때문입니다. 중요한 것은 기준선과 주요 프로세서를 "기능"으로 시작하는 것입니다.
서비스 레벨의 성공적인 구현은 전반적인 시스템 상태를 쉽게 측정하고 전달하는 능력을 보여줍니다. 초기 시연에서는 서비스 레벨 측정값을 개선하기 위해 더 많은 시간을 투자하는 것의 가치를 보여줄 것입니다. 완전한 데모를 빨리 제공할수록 더 빨리 광범위한 채택을 달성하고 모든 이해관계자와 협력하여 안정성 개선 프로세스를 시작할 수 있습니다!
계속하기 전에 몇 가지 일반적인 용어를 살펴보고 KPI를 정의해 보겠습니다.
술어
서비스 레벨은 시스템의 성능을 측정합니다. 지표를 사용하고 이를 예상 성능 및 결과에 대한 일련의 목표와 비교하여 서비스 레벨을 측정합니다.
우리는 서비스 수준 관리를 서비스 레벨 규정 준수를 보고, 유지, 관리하는 방식으로 정의합니다.
서비스 레벨 지표(SLI)는 서비스 레벨을 측정합니다. SLI는 측정하려는 항목을 식별하고 하나의 데이터 포인트 또는 복합 데이터 포인트를 측정합니다. SLI는 가장 일반적으로 성공한 프로세서 또는 이벤트의 백분율(%)을 나타냅니다. 1시간, 1일, 1주 등 특정 기간 동안 계산된 유효한 이벤트의 총 개수 대비 양호한 이벤트의 총 개수를 측정합니다.
예 SLI:
500밀리초 이내에 완료되는 로그인 API 트랜잭션의 비율입니다.
내부 서버 오류 없이 완료된 로그인 API 트랜잭션의 비율입니다.
500밀리초 이내에 내부 서버 오류 없이 완료된 로그인 API 트랜잭션의 비율입니다.
로그인 API에 대해 성공한 합성 검사 Ping의 비율입니다.
3초 이내에 방문 페이지로 전환되는 브라우저 로그인의 비율입니다.
3초 이내에 쿼리에 사용할 수 있는 수집된 측정항목의 비율입니다.
위의 일부 또는 모두가 단일 SLI로 집계되었습니다.
SLO(서비스 수준 목표)는 시스템, 작업 또는 기능의 예상 서비스 레벨을 설명합니다. 일반적으로 특정 기간 내에 하나 이상의 SLI에 필요한 성공 비율을 나타냅니다.
예시 SLO:
로그인 API는 매주 500밀리초 이내에 응답하고 오류가 99.99% 발생합니다.
모바일 로그인 기능은 매주 99.99% 시간 3초 이내에 랜딩 페이지로 전환됩니다.
메트릭의 데이터 수집은 매일 99.99% 시간 동안 API에서 사용된 후 3초 이내에 쿼리에 사용할 수 있습니다.
서비스 경계는 소비자가 외부 API 또는 엔드포인트라고도 하는 클라이언트를 통해 요청하는 시스템 지점인 경우가 많습니다. 서비스 경계는 하나의 애플리케이션 컬렉션이 다른 애플리케이션 컬렉션의 요청을 처리하는 두 개의 서로 다른 시스템 사이에 내부적으로 있을 수도 있습니다. 예를 들어, ID 관리 시스템은 클라이언트의 로그인 요청과 다양한 기능에 대한 권한 승인을 모두 제공할 수 있습니다.
경계 유형:
고객 대면 서비스 경계: 고객 대면 GraphQL API입니다. 이 경계는 각각의 의존성/종속성을 측정할 필요 없이 성능 상태를 측정하는 데 필요한 총 응답 시간 및 성공 지표를 제공합니다.
내부 서비스 경계: 고객 지향 GraphQL API 뒤에 있는 미들웨어 의존성/종속성. GraphQL 티어에 응답하는 각 의존성/종속성 API는 자체 내부 서비스 경계로 간주됩니다. 내부 서비스 경계는 1:1 비율로 전체 출력 성능 상태를 나타내지 않습니다. 예를 들어 GraphQL API에 대한 고객 요청은 7개의 내부 의존성/종속성에 도달할 수 있습니다. 하나의 느린 의존성/종속성은 원래 요청의 총 응답 시간 합계에 영향을 주지 않습니다.
오류 예산은 SLO(서비스 목표) 준수 여부를 측정하고 전달합니다. 서비스 수준 관리 문서 에 이 고급 방법에 대한 자세한 정보가 있습니다.
오류 예산은 "규정 위반"이 되기 전에 서비스가 얼마나 실패할 수 있는지 추적합니다. 오류 예산을 정의하고 측정하기 위해 몇 가지 다른 방법을 사용할 수 있습니다. "오류 예산"에서 "오류"라는 단어는 HTTP 요청 오류나 애플리케이션 오류를 의미하는 것이 아니라, 수준 서비스 목표(SLO)에 정의된 "잘못된 요청이나 이벤트"를 의미합니다.
참고: 오류 예산을 구현하기 전에 먼저 서비스 레벨 규정 준수를 정의, 계산 및 전달하는 방법을 배우는 것이 좋습니다. SLI가 목표, 목표를 얼마나 잘 충족하는지에 대한 성공 여부를 측정하기 위해 SLI에 대한 타격, 목표를 설정하는 것이 매우 중요합니다. 예를 들어, 로그인 요청 24시간 동안 각각 99.99%에서 500밀리초 이내에 오류가 없는지 여부를 추적할 수 있습니다. 24시간 SLI 준수 결과가 99.99%를 충족하면 목표가 달성된 것으로 간주할 수 있습니다.
참고문헌
Google은 오류 예산을 다음과 같이 정의합니다.
"간단히 말해서 오류 예산은 사용자가 불행해지기 시작하기 전에 특정 기간 동안 서비스가 누적할 수 있는 오류의 양입니다. 일단 서비스 수준 목표(SLO)에 대해 각각(SLI)에 대한 목표를 정의하면 — 오류 예산은 최대 100까지의 나머지입니다." -- Google Cloud - 유지보수 기간이 오류 예산에 미치는 영향 - SRE 팁
Atlassian은 오류 예산을 다음과 같이 정의합니다.
"오류 예산은 계약상의 결과 없이 기술 시스템이 실패할 수 있는 최대 시간입니다. 예를 들어 SLA(서비스 수준 계약)에 비즈니스가 고객에게 보상해야 하는 시간의 99.99%가 작동하도록 지정하는 경우 중단, 즉 오류 예산(또는 결과 없이 시스템이 다운될 수 있는 시간)은 연간 52분 35초입니다." -- Atlassian - 오류 예산이란 무엇이며 왜 중요한가요?
전제 조건
APM 측정 등을 통해 기본 애플리케이션에 대한 SLI를 모니터링하고 설정할 데이터가 있습니다.
또한 애플리케이션의 신세틱 테스트를 사용하여 고객에게 의존하지 않고 모니터링할 데이터를 생성할 수도 있습니다.