이제 가동 중단의 전체 범위와 오류 그룹을 이해했으므로 오류를 할당하고 해당 상태를 업데이트할 수 있습니다. New Relic 내에서 오류를 할당하면 수집한 모든 정보를 코드 소유자에게 전송할 수 있습니다. 오류 받은 편지함을 관리하면 여러 팀의 작업이 더 쉬워집니다. 프로세스가 쉬우면 결의안 실행이 빠르고 효율적이 됩니다.
목표
이 자습서에서는 수정 사항을 더 빨리 배포할 수 있도록 오류를 관리하는 과정을 안내합니다.
- 올바른 팀에 오류를 할당하는 방법 알아보기
- 오류 상태 업데이트
오류 그룹 관리
올바른 팀에 오류 할당
Error group summary [오류 그룹 요약] 페이지에서 오류 그룹을 올바른 팀에 할당할 수 있습니다.
사람이나 팀에 오류를 지정하면 의사소통 오류가 제거됩니다. 오류를 해결하는 데 도움이 된 정보는 코드 소유자에게 직접 전달되어 사용자가 중단한 부분부터 다시 시작할 수 있습니다.
그러면 과제가 이메일을 통해 팀에 전달됩니다.
오류 상태 표시
할당되면 오류 상태를 업데이트할 수 있습니다.
이 기능에는 몇 가지 다른 이점이 있습니다.
- 오류 그룹이 예상되는 경우 오류를 Ignored [무시됨] 으로 표시할 수 있습니다. 예상되는 오류는 귀하와 팀에 알려져 있습니다. 이는 중요하지 않은 버그일 수도 있고, 최종 사용자와 관련된 오류일 수도 있습니다(누군가 잘못된 비밀번호를 사용하는 경우 등).
- 그러나 가능한 한 예상되는 오류를 해결하는 것이 좋습니다. 오류 그룹을 무시해도 New Relic이 향후 오류를 보고하는 것을 방지하지 않으며 이는 데이터 수집에 기여합니다.
- New Relic은 시간이 지남에 따라 오류 상태를 추적합니다. 예를 들어, 오류 그룹을 Resolved [해결됨]으로 표시했지만 나중에 새 배포와 함께 나타나는 경우 New Relic은 해당 오류를 Regression [회귀] 로 표시합니다.
근본 원인 조사
일반적인 오류를 줄이거나 심각한 중단에 대응하든 관계없이 오류 발생의 직접적인 원인으로 연결되는 데이터를 따르고 있습니다. 마당에 범람한 새는 파이프를 고쳤을지 모르지만 애초에 균열을 일으킨 원인을 발견하지 못했습니다.
팀에 오류 그룹을 할당하면 모든 사람이 중단을 초래한 프로세스를 식별하는 회고를 개최하는 것이 더 쉽습니다. 금이 간 파이프로 다시 가져오려면: 배관공을 만나면 마당에 있는 나무가 파이프 전체로 자라고 있다고 말합니다. 모든 사람이 동일한 데이터를 볼 수 있는 회고전은 자연스럽게 팀의 전반적인 워크플로우 개선으로 이어집니다.
다음은 서비스 중단에 대한 몇 가지 일반적인 근본 원인입니다.
생산 전 환경에서 부적절한 보증 테스트.
결과가 예상과 같은지 확인하기 위해 코드베이스 내의 모든 함수 또는 메서드를 테스트하지 못했습니다.
업스트림 종속성 요구 사항, 용량 또는 제한 사항에 대한 오해. 예를 들어, 데이터베이스 쿼리가 로드가 적은 사전 프로덕션에서 잘 실행되지만 스트레스를 받으면 느려지기 시작합니다.
용량 계획 부족. 코드가 일반적인 부하에서 모든 일반 테스트를 통과할 수 있지만 수요가 최고조에 달하면 수행되지 않습니다.
근본 원인은 존재하는 팀 수만큼 다양할 수 있습니다. 그러나 요점은 데이터를 따르고, 소통하고, 직접적인 원인을 넘어 더 깊이 파고드는 것입니다.
다음은 뭐지?
축하해요! 오류 받은 편지함을 사용하여 앱의 심각한 오류를 추적하는 방법을 배웠습니다. 이 튜토리얼 시리즈에서는 다음을 배웠습니다.
- 시작할 서비스를 식별하고 오류 그룹의 우선순위를 지정하는 방법
- 스택 추적 및 로그를 사용하여 오류의 성격을 확인하는 방법
- 여러 팀에 오류 그룹을 할당하는 방법
이제 오류 받은 편지함을 사용하여 오류를 진단하고 해결하는 방법을 배웠으므로 다른 자습서를 탐색할 수 있습니다.
- 오류 받은편지함에 대해 자세히 알아보고 싶으신가요? 몇 가지 모범 사례를 보려면 오류 받은 편지함 문서를 확인하세요.
- 인프라에서 발생한 사고를 해결하려는 경우 호스트 데이터 문제 해결 에 대한 튜토리얼을 확인하세요.
- 앱이 느린가요? 느린 앱 동작 문제 해결에 대한 튜토리얼을 확인하세요.