이 가이드는 오류율, 오류 감지 및 고객 경험을 개선할 수 있도록 오류를 최적화하는 방법을 보여줍니다. 관찰 가능성 성숙도에 대한 시리즈 의 일부입니다.
개요
오류 추적은 고객의 소프트웨어 경험에 영향을 미치는 문제를 해결할 수 있도록 응용 프로그램 오류 및 오류율을 캡처하는 방법입니다.
이 가이드의 목표는 New Relic 고객 또는 팀이 다음을 수행할 수 있도록 하는 것입니다.
- 오류 관련 측정항목이 사용자에게 의미 있는 오류만 반영하도록 New Relic이 오류를 이해하는 방식을 보정합니다.
- 시간이 지남에 따라 오류 발생률 감소
요망되는 결과
애플리케이션 오류율과 평균 해결 시간을 줄여 고객 경험과 안정성을 개선합니다.
핵심 성과 지표
비즈니스 KPI
고객이 경험하는 오류를 줄이면 신뢰성이 향상됩니다. 안정성을 개선하는 조직은 더 높은 전환율(사용자 여정 완료율)과 더 높은 사용자 참여를 경험합니다. 이를 통해 조직은 수익 목표(상업적) 또는 사회적 영향 목표(비영리)를 더 가깝게 달성할 수 있습니다.
위의 비즈니스 KPI는 프런트엔드 애플리케이션을 제공하여 사용자를 지원한다는 가정하에 작동합니다. API를 통해 고객을 지원하는 경우 위의 KPI를 거래 엔터티 유형에 맞추는 것이 가능할 수 있습니다. API를 서비스로 제공하는 일부 조직은 아래와 같은 운영 KPI를 사용하여 제품의 품질을 홍보합니다.
운영 KPI
전제 조건
필수 설치 및 구성
우리의
,
, 모바일 모니터링, 서버리스 모니터링 또는 OpenTelemetry 솔루션에서 오류가 발생합니다.
웹 애플리케이션을 위한 최신 소스 맵
모바일 애플리케이션에 대한 최신 기호화
현재 상태 설정
애플리케이션을 위한 워크로드 생성
오류를 최적화하려는 응용 프로그램 및 서비스 목록을 정의하십시오. 오류 최적화 프로세스를 수행하는 팀은 이러한 앱과 서비스에 대한 전적인 책임과 통제를 가져야 합니다. 결정했으면 이러한 엔터티에 대한 작업 부하 를 설정합니다.
워크로드는 특정 팀이 담당하는 엔터티(애플리케이션, 인스턴스 등) 그룹입니다. 그들은 당신이 뭔가를 할 수 있는 엔터티에 대한 데이터만 볼 수 있도록 합니다. 앞으로 여기에서 설정한 워크로드를 기반으로 대부분의 작업을 수행할 것입니다.
워크로드를 설정하는 데 몇 분 밖에 걸리지 않습니다. 워크로드 지침 을 참조하십시오.
워크로드에 이미 익숙하고 애플리케이션과 서비스를 여러 워크로드로 나누고 싶다면 그렇게 할 수 있습니다. 각 워크로드에 대해 아래 단계를 따르세요.
워크로드에 대한 서비스 수준 생성
서비스 수준 을 사용하면 주어진 엔터티 그룹에 대한 서비스 수준 목표(SLO) 를 쉽게 구성하고 볼 수 있습니다. 서비스 수준을 사용하는 것은 오류 관리 프로젝트의 성공을 모니터링하고 전달할 수 있는 한 가지 방법입니다.
워크로드에서 서비스 수준 탭으로 이동합니다. 워크로드의 각 엔터티에 대한 오류율을 측정하는 서비스 수준을 만듭니다. 이는 서비스 수준 UI의 2단계에서 구성됩니다. 각 서비스 수준에 대해 WHERE 절을 사용하여 고려해서는 안 되는 양호한 요청이나 오류를 필터링합니다.
서비스 수준을 사용하여 현재 오류율에 대한 진행 상황 추적
위에 설명된 프로세스를 사용하여 현재 오류율을 기반으로 서비스 수준을 만들었습니다.
- SLO 열에는 기준선을 사용하여 선택한 목표 오류율이 표시됩니다.
- 운영 보기 모드는 목표에 대한 최근 성과를 보여줍니다.
- 기간별 기간 보기 모드는 장기간에 걸친 목표에 대한 성과를 보여줍니다.
- 개선 사항이 있으면 오류율 목표를 업데이트할 수 있습니다.
개선 프로세스
- 중요하지 않은 오류 식별
- 오류율에서 중요하지 않은 오류 제거
- 오류율 경고 설정
- 오류 영웅 명단 설정
- 오류 받은 편지함을 사용하여 오류 분류
- JIRA에 오류 링크
- 오류를 Slack에 연결
- CodeStream 사용
중요하지 않은 오류 식별
가장 편안하지만 오류를 탐색하십시오. 다음을 사용하여 이 작업을 수행할 수 있습니다.
- APM, 모바일 모니터링, JavaScript 오류, 서버리스 모니터링 및 OpenTelemetry에 대한 즉시 사용 가능한 보기
- 워크로드에 대해 필터링된 오류 받은 편지함
TransactionError,JavaScriptError,MobileRequestError,AwsLambdaInvocationError등의 NRQL 데이터 유형Span
오류율에서 중요하지 않은 오류 제거
다음 두 가지 방법 중 하나로 중요하지 않은 오류를 제거할 수 있습니다.
- 구성 (APM만 해당)을 사용하거나 삭제 규칙 을 사용하여 수집되지 않도록 합니다. 이 접근 방식은 캡처할 필요가 없다고 확신하는 오류에 대해서만 작동합니다. 이 접근 방식의 추가 이점은 잡음이 있는 오류에 대한 수집이 감소한다는 것입니다.
- NRQL을 사용하여 서비스 수준 계산에서 오류를 필터링합니다. 잘못된 응답의 WHERE 절 필터에 추가하여 이를 수행합니다. 오류율이 크게 향상되면 서비스 수준을 다시 설정해야 합니다. 이렇게 하면 오류 경고 정확도가 향상됩니다.
오류율 경고 설정
워크로드에 대한 서비스 수준 생성 에 설정된 각 서비스 수준을 검토하고 오류율이 허용 가능한 비율을 초과하여 증가할 때 팀에 알리는 경고를 생성합니다.
오류 영웅 명단 설정
경고는 현재 수준의 오류 성능을 충족하는지 알려주지만 개선하는 데 도움이 되지는 않습니다. 고객 감정을 개선하려면 팀 구성원이 매일 오류를 검토하는 프로세스를 만드십시오. 오류 영웅은 다음을 수행해야 합니다.
- 처음에는 스크롤 없이 볼 수 있는 부분에서 발생하는 오류에 초점을 맞춥니다. 일일 검토 프로세스의 경우 이는 지난 24시간 동안에만 발생한 오류에 초점을 맞추는 것을 의미합니다.
- 오류 받은 편지함 을 사용하여 오류 분류
오류 받은 편지함을 사용하여 오류 분류
오류 받은 편지함은 고객에게 영향을 미치기 전에 모든 오류를 사전에 감지, 분류하고 조치를 취할 수 있는 단일 장소입니다. 유사한 오류는 함께 그룹화되어 작업의 중복을 방지하고 발생 횟수에 따라 오류의 우선 순위를 지정할 수 있습니다.
오류 받은 편지함에 액세스할 때 팀과 관련된 오류만 표시되도록 작업 부하를 선택해야 합니다.
팀으로 받은 편지함에서 오류를 확인하기 위해 정기적으로 시간을 둡니다. 우선, 통과해야 할 오류 그룹이 많기 때문에 매일 또는 일주일에 몇 번 정도가 적합합니다. 나중에 매주 또는 격주로 하는 것이 더 적절할 수 있습니다.
추적, 로그 등과 같은 추가 정보를 얻기 위해 필요할 때 오류 세부 정보 화면을 클릭하여 오류를 하나씩 살펴보십시오. 이것은 오류의 원인을 가리키거나 추가 조사를 위한 시작점을 제공합니다.
간단한 토론 후에 오류 그룹을 다음 중 하나로 표시할 수 있습니다.
- 무시: 오류가 문제가 되지 않을 때 사용합니다. 그러면 해당 시점부터 받은 편지함 보기에서 오류 그룹이 숨겨집니다.
- 해결됨: 오류가 현재 수정된 알려진 문제의 결과인 경우에 사용합니다. 이렇게 하면 반복되지 않는 한 목록에서 오류 그룹이 제거됩니다. 재발하는 경우 이전에 구현한 수정 사항을 다시 고려해야 합니다.
참고: 오류 받은 편지함을 통해 오류를 무시 및/또는 해결해도 오류율 측정항목에 포함되는 오류는 중단되지 않습니다.
위의 상태 중 어느 것도 적합하지 않은 경우 추가 조사 및 해결을 위해 해당 팀 구성원에게 오류를 할당합니다. 해당 팀 구성원은 자신의 시간에 추가 조사를 수행하여 오류 그룹 메모를 진행 상황으로 업데이트하거나 메모 섹션을 통해 다른 팀 구성원에게 도움을 요청할 수 있습니다.
다음 심사 회의에서 이러한 오류 그룹을 다시 방문하여 이제 해결된 것으로 표시할 수 있는지 확인할 수 있습니다. 시간이 지남에 따라 새로운 오류 그룹이 더 적게 나타나고 KPI가 긍정적으로 움직이기 시작해야 합니다.
JIRA에 오류 링크
더 극단적이거나 복잡한 오류가 발생하면 다른 팀에 도움을 요청해야 할 수도 있습니다. 오류 받은 편지함을 Jira에 연결하면 도움이 될 수 있습니다. 오류 받은 편지함을 Jira 에 연결하면 오류 그룹에 연결된 티켓을 쉽게 만들 수 있습니다. Jira 템플릿을 통해 Jira로 전송되는 정보를 제어할 수 있습니다.
오류를 Slack에 연결
받은 편지함으로 들어오는 오류의 속도가 느려지면서 정규 팀 세션이 더 이상 시간을 잘 사용하지 못할 수 있습니다. 대안은 오류 받은 편지함을 Slack에 연결 하고 a) 순환하는 사람을 지정하여 채널을 모니터링하고 들어오는 오류 그룹을 해결/무시/할당하거나 b) 팀이 오류 그룹에 사전에 대응하도록 허용합니다.
CodeStream 사용
많은 오류 그룹이 해결하려면 코드 변경이 필요합니다. CodeStream을 New Relic 계정 에 연결하여 문제가 되는 코드를 IDE에서 직접 열어 코드를 직접 조사하십시오. 또한 개발자가 검토할 수 있도록 특정 코드 줄에 메모와 주석을 남길 수 있으며 그 반대의 경우도 마찬가지입니다.
CodeStream이 포함된 New Relic은 버전 번호를 확인하거나 SHA를 커밋할 수 있는 등 오류 그룹에 대한 더 많은 컨텍스트를 제공합니다. 또한 오류 받은 편지함을 중앙 집중식으로 사용하여 코드 문제를 식별, 논의 및 수정하면 코드 문제에 효율적으로 대응하고 작업 중복을 피할 수 있습니다.
가치 실현
연습을 진행하면서 매주 오류율을 검토하십시오. 오류율이 감소하면 평균 해결 시간이 빨라지고 고객 만족도가 높아집니다.