IT 인시던트 알림이란 무엇입니까?
인시던트 알림은 팀에 변경 사항, 위험이 높은 조치 또는 IT 환경 장애를 알리기 위해 모니터링 도구에서 생성하는 알림입니다.
예를 들어, 의사가 약물을 처방할 수 있도록 구축된 시스템은 의사가 요청하는 용량이 비정상적으로 높거나, 환자 파일에 나열된 체중에 맞지 않거나, 다른 일반적인 약물과의 약물 상호 작용 위험을 초래하는 경우 알림을 생성할 수 있습니다.
마찬가지로, 기술 제품을 모니터링하기 위해 구축된 시스템은 시스템이 오프라인 상태가 되거나, 웹 요청을 처리하는 데 평소보다 오래 걸리거나, 데이터베이스 지연 시간이 설정된 임계값을 초과하여 느려지는 경우 알림을 생성할 수 있습니다.
IT 알림의 목표는 수동 모니터링 없이 24시간 내내 제품 가동 시간, 속도 및 기능에 영향을 미치는 문제를 빠르게 파악하고 해결하는 것입니다.
IT 알림이 중요한 이유는 무엇입니까?
상시 가동 시스템의 중요성이 계속 높아짐에 따라 가동 중지 시간에 따른 비용도 증가하고 있으며 전문가들은 평균 비용이 분당 5,600달러에서 9,000달러 사이라고 추정합니다. 시스템 장애가 발생하면 매분 상당한 비용이 발생하기 때문에, 감당할 수 없을 만큼 커지기 전에 문제를 파악하는 것은 비즈니스 수익에 큰 영향을 줍니다(물론 IT 팀의 일정 및 스트레스 수준에도 영향을 줌).
IT 알림은 주요 인시던트로 변할 수 있는 시스템 중단 또는 변경에 대한 첫 번째 방어선입니다. IT 팀은 시스템을 자동으로 모니터링하고 서비스 중단 및 위험한 변경에 대한 알림을 생성하여 가동 중지 시간과 그로 인해 발생하는 상당한 비용을 최소화할 수 있습니다.
알림 모범 사례
IT 알림은 인시던트 관리에서 분명히 중요한 부분이지만, 사실 설정하고 잊어버려도 되는 간단한 해결 방법이 아닙니다. 알림 임계값을 너무 낮게 설정하면 받은 편지함이 알림으로 넘치고, 대기 중 팀의 만족도가 떨어지고, 알림 피로를 유발할 수 있습니다. 임계값을 너무 높게 설정하면 중요한 문제를 놓치고 회사에는 수백만 달러의 비용이 들게 될 수 있습니다.
가장 효과적인 IT 알림 시스템이 이러한 모범 사례를 염두에 두고 설정되어 있는 이유입니다.
모니터링 자동화
문제를 빠르고 효과적으로 식별하는 가장 좋은 방법은 모니터링을 자동화하는 것입니다.
데이터베이스가 평소보다 느리게 응답합니까? 사용자의 앱 로드 시간이 평균보다 느립니까? 중요한 시스템이 가동 중지되었습니까? 기술자 중 한 명이 위험 신호처럼 보이는 요청을 했습니까? 시스템은 이러한 문제를 자동으로 감시하고 문제 발생 시 알려야 합니다.
스마트 알림 임계값 설정
모든 알림에 즉각적인 주의가 필요합니까? 대다수 회사의 대답은 '아니오'입니다. 따라서 적절한 알림 임계값을 설정해야 합니다.
한밤중에 개발자를 깨울 가치가 있는지 또는 아침까지 보류할 수 있는지 파악하는 것은 대응 시간이 빠른 만족스러운 개발자와 주말 내내 새로운 직장을 알아보는 알림 피로를 겪는 팀 간의 차이를 만들어낼 수 있습니다.
중복된 알림 제거
알림 피로에 대한 한 연구에 따르면, 병원에서 일하는 임상의의 경우 중복된 알림이 들어올 때마다 알림에 대한 주의력이 30% 감소한 것으로 나타났습니다. 그리고 이 연구 결과는 개발자의 경우에도 같을 것입니다. 똑같은 알림을 많이 받을수록 주의를 덜 기울이게 됩니다. 그래서 가장 좋은 방법은 중복된 알림을 제거하고 미리 알림을 최소화하는 것입니다.
우선 순위 및 심각도 수준 설정
다른 알림보다 중요한 알림은 분명히 있습니다. 웹사이트 서비스 중단은 자주 사용하지 않는 기능의 일시적인 속도 저하보다 우선시될 것입니다. 악성 해킹은 앱에서 올바르게 렌더링되지 않는 이미지보다 우선 순위가 더 높을 것입니다.
시스템에서 알림의 우선 순위와 심각도를 인식해야 할 뿐만 아니라 인시던트 해결 담당자에게 우선 순위를 명확하게 전달해야 합니다. 여기서 가장 좋은 방법은 시각, 청각 및 감각 신호를 사용하여 팀이 다음으로 집중해야 할 부분을 빠르고 명확하게 나타내는 것입니다.
조치 가능한 알림 만들기
무엇이 잘못되었는지 파악하는 것은 좋습니다. 다음으로 무엇을 해야 할지 아는 것은 더욱 좋습니다. 그래서 조치를 취할 수 없는 알림의 경우, 조치를 취할 수 있도록 만들어야 합니다.
DevOps 팀이 항공 업계로부터 배울 수 있는 한 부분입니다. 비행 중에 조종사의 계기판에 알림이 표시되면 조치 가능한 확인 목록이 함께 제공됩니다. 알림 시스템에 이러한 세부 정보를 구축하면 진단 시간이 단축되고 개발자가 프로세스를 빠르게 진행할 수 있습니다.
이는 개발자가 한밤중에 잠에서 깨어 최상의 컨디션이 아닐 때 특히 유용합니다.
적합한 알림 기술 선택
이러한 모범 사례를 따르는 IT 알림 시스템을 개발한다는 것은 알림에 대해 전략적으로 대처한다는 것을 의미합니다. 또한 그렇게 하기 위해 적합한 기술을 선택해야 한다는 의미이기도 합니다. 공급업체를 선택할 때 다음 사항을 고려하는 것이 좋습니다.
다양한 알림 채널
알림을 보내는 데 자주 선택되는 채널은 이메일입니다. 하지만 사실 이메일이 항상 올바른 방법은 아닙니다. 긴급한 알림의 경우 SMS, 모바일 푸시 알림 또는 음성 통화를 원하거나 필요할 수 있습니다. 다양한 방법으로 알림을 보낼 수 있는 시스템을 찾으세요.
향상된 알림
조치 가능한 알림은 곧 자세한 알림입니다. 즉, 짧은 문자 메시지만으로 항상 충분하지는 않습니다. 엄격한 문자 제한에 주의하고 차트, 로그, 런북 및 확인 목록을 첨부하여 알림에 대한 추가 컨텍스트를 제공하고 개발자에게 다음으로 수행해야 할 작업을 알릴 수 있는 기술을 찾으세요.
사용자 지정 알림 작업
대부분의 알림 기술에서는 알림에 메모를 추가하거나 알림을 닫을 수 있습니다. 하지만 때로는 그 사이에 단계가 있습니다. 예를 들면, 추가 조사를 위해 알림을 에스컬레이션하거나, 서비스 티켓을 만들거나, 서버를 다시 시작하는 경우가 있습니다. 단순히 열고 닫는 것 이상의 일을 하도록 지원하는 기술 솔루션을 찾아보세요.
자동화된 작업
일부 알림의 경우 다음으로 수행해야 할 작업이 복잡하고 숙련된 개발자의 인사이트가 필요한 경우도 있으며, 다음 단계가 명확한 알림도 있습니다.
명확한 다음 단계(진단 테스트, 해결 조치)가 있는 알림의 경우 사전 정의된 기준을 충족하는 알림에 대해 해당 대응을 자동으로 트리거하는 시스템이 필요합니다.
예를 들어, 데이터베이스 속도가 느려지면 자동으로 백업 데이터베이스로 전환하도록 알림 시스템을 설정할 수 있습니다. 문제 A 해결의 첫 번째 단계가 항상 서버를 다시 시작하는 것이라면, 한밤중에 알림을 보내기 전에 서버를 다시 시작하고 결과를 모니터링하도록 알림 시스템을 설정할 수 있습니다.
알림 사용자 정의 및 분류
알림을 받으면 팀에서는 알림을 체계화하고, 추가 정보로 태그를 지정하고, 필터링할 수 있어야 합니다.
알림 라이프사이클 추적
인시던트 사후 검토에서는 알림이 언제 들어왔는지, 누가 알림을 받았는지, 언제 확인했는지, 어떤 조치를 취했는지 알고 싶을 것입니다. 어떤 기술을 선택하든 이러한 세부 사항을 자동으로 추적하도록 하세요. 그러면 효과가 있는 것과 그렇지 않은 것을 파악하고, KPI를 개선하고, 이전의 인시던트를 문서화하여 대기 중 팀이 과거 인시던트로부터 배우고 배운 내용을 향후 인시던트에서 다시 참조하는 일이 더 간단해집니다.
경고 및 알림 정책
여기서의 모범 사례는 알림에 대한 지능형 임계값을 설정하고 사소한 문제로 인해 개발자가 자다가 일어나지 않도록 하는 것이라면 콘텐츠와 시점에 따라 알림을 억제, 지연 및 신속하게 처리할 수 있는 기술이 필요합니다.
모니터링을 위한 실시간 모니터링
어떤 시점에든 알림 시스템이 가동되고 있는지 어떻게 알 수 있습니까?
올바른 기술에는 자체 모니터링 시스템을 갖추고 있습니다. Opsgenie에서는 모니터링 도구가 활성 상태이고 연결되어 있는지, 사용자 지정 작업이 일정에 따라 완료되는지 지속적으로 확인하는 Heartbeats라는 도구를 사용하여 이 작업을 수행합니다. 신호가 꺼지면 시스템에서 즉시 알림을 보냅니다.