조치 가능한 경고
지금까지 이 모듈에서는 시스템의 안정성에 대해 생각하고 측정하고 상호 작용하는 방법을 살펴보았습니다. 그러나 신뢰성이 우리와 상호 작용하는 방법도 있습니다. 바로 경고입니다. 이전에 본 SLI 및 SLO를 포함하여 다양한 메트릭 및 신호를 기반으로 경고를 보내도록 Azure Monitor 및 기타 도구를 쉽게 설정할 수 있습니다. Azure는 Azure Service Health 기능을 통해 서비스 문제에 따라 경고를 보낼 수도 있습니다.
경고를 쉽게 보내는 기능에는 잠재적인 위험이 따릅니다. 앞서 살펴본 SRE 정의에서 지속적이라는 단어는 바로 이 대목에서 등장합니다.
사이트 안정성 엔지니어링은 조직이 시스템, 서비스, 제품에서 적절한 수준의 안정성을 지속적으로 달성하도록 지원하는 엔지니어링 원칙입니다.
경고는 시스템에 문제가 있을 때 알려주도록 설계되었습니다. 그러나 경고가 부적절하게 구성되면 지속 가능한 운영 방식을 만들려는 목표가 훼손될 수 있습니다. SLI 및 SLO를 조직에 도입하기 위해 들인 모든 노력이 직원들에게 폭풍우 같은 경고를 받게 될 경우 무산될 수 있습니다. 경고 피로는 운영 커뮤니티에서 잘 알려진 질병입니다. 이 단원의 목표는 조직에서 이런 사태가 발생하지 않도록 돕는 것입니다.
경고 피로도의 주요 원인은 조치를 취할 수 없는 경고입니다. 생성을 피하는 방법을 알아보겠습니다.
경고란?
잘못된 경고로 인해 문제가 발생할 수 있는 이유를 이해하려면 경고의 목적과 경고와 다른 운영 신호의 차이점을 생각해야 합니다.
조치 가능한 경고에 해당하지 않는 것:
로그: 경고는 이벤트 기록이 아닙니다. 그것은 로그 작업입니다. 발생한 이벤트를 기록하려는 경우 호출기가 아닌 로그 파일에 기록하세요.
경고: 경고는 소프트웨어 빌드 완료와 같이 중요하지 않은 상황을 알리기 위한 것이 아닙니다. 뉴스를 전달한다는 명목으로 사용자를 방해하고 집중력을 깨뜨려서는 안 됩니다.
하트비트: 경고는 시스템이 아직 실행 중이라는 경고로 사용하면 안 됩니다. 사람들이 “1시간마다 한 번 시스템에서 호출이 오지 않으면 문제가 있는 것이니 처리해야 한다”고 말하는 것을 본 적이 있을 것입니다. 이것은 끔찍한 아이디어입니다.
조치 가능한 경고는 문제 해결을 위해 사람의 조사와 개입이 필요한 상황에서 사용됩니다. 경고는 주의가 필요한 예외적이거나 예기치 않은 무엇이 발생했음을 알리는 것이어야 합니다.
사전 설정된 제한 내에서 리소스를 크기 조정하는 것과 같이 자동화된 프로세스를 통해 시스템이 처리할 수 있는 이벤트인 경우 경고가 필요하지 않습니다. 시스템이 이를 처리하고 로그에 작성하면 됩니다. 시스템에서 성공적으로 처리된 상황이 있다고 새벽 2시에 호출해 알려 줘서는 안 됩니다.
조치 가능한 경고 만들기
경고가 조치 가능하려면 다음을 갖춰야 합니다.
단순성: 수신자가 무엇을 해야 할지 알기 전에 당황해야 하는 경고를 만들고 싶지는 않을 것입니다. 경고가 너무 복잡하면 한밤중에 방금 깨어난 불쌍한 사람은 그것이 의미하는 바를 알아내려고 노력하는 것만으로도 귀중한 시간을 잃게 될 것입니다.
범위: 메시지를 받는 사람이 메시지를 효과적으로 분류하기 위해 가장 먼저 해야 할 일 중 하나는 문제의 범위를 결정하는 것입니다. 단일 서버와 관련된 문제인가요? 하나의 서비스? 전체 지역? 세계적인? 받는 사람이 더 쉽게 파악할 수 있도록 경고에 이 정보를 포함합니다.
컨텍스트: 경고를 받을 사람이 경고를 처리하기 위해 알아야 할 사항은 무엇인가요? 이 부분을 자세히 살펴보겠습니다.
경고에 컨텍스트 제공
받는 사람에게 필요한 컨텍스트를 제공하려면 조치 가능한 경고에 항상 포함되어야 하는 몇 가지 요소를 살펴보겠습니다.
경고는 어디에서 제공됩니까? 많은 조직에서는 언제나 여러 모니터링 시스템이 사용되며 상호 연결된 시스템이 많습니다. "급여 시스템 THX-1138에 대한 이 경고는 'prod' Azure Monitor 구독에서 제공됩니다."라는 경고가 표시되면 누군가에게 엄청난 시간을 절약할 수 있습니다.
어떤 기대 사항이 위반되었는가? 현재 상태를 설명하는 경고는 별로 유용하지 않습니다. “데이터베이스 서버가 80% 부하로 실행 중입니다”와 “데이터베이스 서버가 60% 이하의 부하로 실행되어야 하지만 지난 2시간 동안 80% 부하로 실행 중입니다”를 비교해 보세요.
이것이 (고객에게) 왜 문제가 되는가? 어떤 상황이 고객에게 미쳤거나 미칠 수 있는 영향 또는 효과에 대한 정보는 중요도를 결정하고 우리 대응을 적절하게 측정하는 방법을 제공합니다.
수행할 다음 단계는 무엇인가? 가능한 경우 경고에는 이 문제를 진단하고 해결하는 데 도움이 되는 문제 해결 가이드 또는 기타 문서에 대한 포인터인 경우에도 응답하는 사람이 다음에 수행해야 하는 작업이 포함되어야 합니다.
이런 유용한 컨텍스트를 포함시키고 경고를 조치 가능하게 만들려 노력하면 운영 관행이 더욱 지속 가능해지고 이러한 경고에 대한 대응이 보다 쉬워집니다.