엔지니어링 팀이 경보 피로를 겪고 있습니까? 이 8가지 질문을 하세요

경보 피로는 운영을 처리하고 인프라를 유지 관리하는 엔지니어링 팀 사이에서 일반적인 문제입니다.

문제는 일반적으로 팀이 성장하고 복잡성이 증가하는 더 많은 인프라를 사용하기 시작함에 따라 경고를 작성하는 우연한 접근 방식에서 비롯됩니다. 이는 매우 정상적인 현상입니다. 회사 또는 팀이 성장함에 따라 관찰 가능성 문화와 견고한 경고 관행이 형성되는 데 시간이 걸리는 경우가 많습니다.

너무 민감하고, 너무 시끄럽고, 너무 조심스러운 경고를 생성하기 쉽습니다. 초기에는 제품의 초기 단계에서 조심하고 생산 신호를 극대화하는 것이 더 낫기 때문에 모든 것이 경계할 가치가 있는 것처럼 보입니다.

"기능 및 인프라의 수와 복잡성이 증가함에 따라 경고 개선은 일반적으로 우선 순위 목록에서 훨씬 아래로 내려갑니다."

당연히 이 접근 방식은 잘 확장되지 않지만 기능과 인프라의 수와 복잡성이 증가함에 따라 경고 개선은 일반적으로 우선 순위 목록에서 훨씬 아래로 내려갑니다. 그 결과 대기 중인 엔지니어에게 의미 없는 경고, 소음, 컨텍스트 전환 및 멀티태스킹이 많이 발생합니다. 극단적인 경우 팀원이 지치고 경고가 무시되며 대기 중인 팀은 서비스 품질을 개선하는 것에서 의미 있는 영향 없이 지속적으로 소방으로 전환합니다.

모든 회사와 마찬가지로 인터콤도 이러한 비효율성에 영향을 받지 않습니다. 그래서 우리는 경보 피로와 싸우기 위해 비교적 가벼운 프로세스를 고안했습니다.

알림 전략에 대한 우리의 생각

"경보 규율"의 개념은 경보를 제어하는 ​​핵심입니다. 기능 작업과 마찬가지로 경고 및 경고 전략은 신중하고 구조화된 방식으로 접근해야 합니다. 그러나 기능 작업과 달리 사전에 잘 계획할 수 있는 작업이 아닙니다.

결국 새 기능을 출시하기 전에 운영 상태와 소음을 예측할 수 있을 가능성은 거의 없습니다. 경고 작업이 지속 불가능한 수준까지 올라가지 않도록 정기적이고 계획된 방식으로 경고를 모니터링해야 합니다.

팀의 알림을 평가할 때 물어봐야 할 8가지 질문

빈번한 경보를 처리하는 팀을 위해 정기적인 경보 검토 세션을 도입했습니다. 이러한 작업은 처음에는 6주 엔지니어링 주기당 한 번 또는 여러 번 발생했지만 경보 및 모니터의 상태가 관리하기 쉬운 수준으로 개선됨에 따라 더 간격을 두게 되었습니다.

각 경고 검토 세션은 이전 기간에 실행된 경고의 순서가 지정된 경고 목록으로 시작하고 실행 빈도별로 정렬됩니다. PagerDuty 플랫폼을 경고 소스로 사용하고 해당 분석 기능을 통해 경고 빈도와 응답을 분석하는 데 필요한 정보를 얻을 수 있습니다. 전체 소음(즉, 가장 자주 발생하는 화재)에 가장 많이 기여하는 경보가 먼저 검토됩니다.

그런 다음 각 경고는 질문 체크리스트를 통해 전달됩니다.

1. 경고가 여전히 관련성이 있습니까?

오래되거나 유지 관리되지 않는 시스템으로 인해 발생하는 모든 경고는 대기 중인 엔지니어를 귀찮게 해서는 안 되며 즉시 제거해야 합니다.

2. 경고를 실행할 수 있습니까?

대기 중인 엔지니어가 경고를 받으면 근본적인 원인을 수정하거나 개선하기 위해 바로 지금 조치를 취할 수 있습니까? 경고가 실행 가능하지 않고 유용하지 않으면 제거해야 합니다. 문제 또는 성능 저하에 대한 주간 요약은 경고 내의 정보에 대한 더 나은 위치일 수 있습니다.

3. 경고의 정보는 실행이 불가능하더라도 즉시 유용합니까?

경고 정보는 크게 두 가지 범주로 나눌 수 있습니다.

• 신호: 이 경고는 시스템이 한계에 도달했음을 경고하지만 반드시 서비스가 영향을 받고 있다는 의미는 아닙니다. 예를 들어 100% CPU에서 실행 중인 서버 중 하나가 있습니다. 서비스가 여전히 제대로 작동하고 있다면 통화 중인 직원이 조사에 귀중한 시간을 할애해야 합니까? 결국, 귀하의 서버는 비용 대비 최고의 성능을 발휘합니다!
• 증상: 이러한 경고는 고객 경험이 영향을 받을 때 실행됩니다. 서비스가 호출자에게 반환하는 5XX HTTP 오류의 수를 예로 들 수 있습니다.

이 두 범주는 함께 가장 잘 작동합니다. 대기 중인 사람은 증상에 대응하고 문제를 해결해야 하며 신호를 추가 정보 소스로만 봐야 합니다.

4. 경고가 실행 가능하고 호출되는 경우 즉시 처리해야 합니까?

문제를 즉시 처리할 필요가 없는 경우 한밤중에 누군가를 깨우지 않아야 합니다. 팀은 이러한 상황에서 경고에 정보를 표시하는 대체 방법(예: Slack 또는 대시보드 알림 또는 문제 추적 메커니즘의 열린 작업)을 결정해야 합니다.

5. 실행 가능한 경우 런북 또는 문제 해결 링크가 있습니까? 팀의 모든 엔지니어가 따를 수 있을 만큼 단계가 명확합니까?

대기 엔지니어, 특히 새로운 엔지니어가 되는 최악의 경험 중 하나는 시간이 지남에 따라 엔지니어링 팀에 축적되는 부족 지식의 양입니다. 시스템의 해당 영역에 익숙하지 않고 문서화되지 않았다는 사실을 깨닫기 위해 심각도가 높은 생산 사고에 뛰어드는 것은 두려운 일입니다.

" 경고 문제 해결 정보를 명확하고 간단하며 최신 상태로 유지하면 사고를 완화하고 복구하는 데 걸리는 평균 시간을 줄이는 데 큰 도움이 됩니다. "

전문 지식이 있더라도 코드를 너무 오래 전에 작성하여 코드가 수행해야 할 작업을 명확하게 기억하지 못할 수 있습니다. 경고 문제 해결 정보를 명확하고 간단하며 최신 상태로 유지하면 사고(MTTM 및 MTTR)를 완화하고 복구하는 평균 시간을 줄이는 데 많은 도움이 됩니다.

6. 실행 가능한 경우 대시보드 링크가 있고 알려진 모든 잠재적 원인을 표시합니까?

대시보드는 많은 양의 시스템 정보를 한 번에 표시할 수 있는 좋은 방법입니다. 즉, 엔지니어는 문제의 원인을 파악하기 위해 다양한 로그, 메트릭 및 추적을 조사할 필요가 없습니다. 데이터를 대시보드로 집계하고 경고의 일부로 링크를 제공하면 훨씬 더 빠른 문제 해결이 가능합니다.

7. 경고가 너무 민감하거나 구체적이지 않습니까? 둔감화 또는 범위 변경의 이점이 있습니까?

많은 경고가 유용하지만 잘못 보정되었습니다. 너무 광범위하여 매번 발사하지 않거나 너무 구체적이고 동일한 사건에 대해 여러 번 발사하여 소음을 가중시킬 수 있습니다.

8. 마지막으로 인간이 교정을 해야 합니까?

어떤 면에서 모든 컴퓨터 코드는 인간이 할 수 있는 일을 자동화합니다. 그렇다면 경고를 유발하는 문제의 수정을 자동화하지 않는 이유는 무엇입니까? 코드의 버그 또는 시스템의 성능 문제와 같은 특정 까다로운 경고는 자동으로 수정하기 어려울 수 있지만 자동화된 작업은 많은 일반적인 문제를 해결할 수 있습니다.

AWS와 같은 클라우드 플랫폼에서 실행 중이고 추가 하드웨어 요청에 대해 걱정할 필요 없이 인프라를 프로비저닝할 수 있는 경우 특히 그렇습니다. 예를 들어 검색 클러스터의 노드에 장애가 발생한 디스크가 표시되는 경우 자동으로 교체하지 않는 이유는 무엇입니까? 트래픽 증가로 인해 서비스에 컴퓨팅 리소스가 부족한 경우 VM 또는 컨테이너를 확장하고 추가하지 않겠습니까? 수정 사항에 대한 세부 정보는 비경고 채널을 통해 팀에 보내져 여유 시간에 검토할 수 있습니다.

이 질문에 "아니오"라고 답한 적이 있습니까?

이러한 질문에 '아니오'라고 답하면 페이징 중지, 문제 해결 단계 개선, 자동화 또는 단순히 기본 시스템 문제 수정 등 경고를 개선하기 위해 팀이 일부 작업을 수행해야 하는 최우선 과제가 됩니다.

접근 방식의 핵심은 규칙적이고 계획적인 방식으로 이 작업을 수행하는 것입니다. 소음 수준을 낮게 유지하고 귀하의 작업 및 대기 엔지니어는 만족하고 생산적입니다. 그들은 소방 대신 품질을 개선하고 임팩트를 전달하는 데 집중할 수 있습니다.

인터콤에서 일하는 방식에 관심이 있습니까? 우리는 당신과 이야기하고 싶습니다 - 우리의 공개 엔지니어링 역할을 확인하십시오.