CASE 방법: 인도적 모니터링

지이이인! 새벽 3시, 멋진 꿈을 꾸고 있는데 갑자기 전화가 옵니다. 당신은 이번 주에 근무 중인데 무슨 일이 있었던 것 같습니다. 자동화된 시스템이 무엇이 잘못되었는지 알아내기 위해 전화를 겁니다. 이는 현대 컴퓨터 시스템 관리의 중요한 측면이지만 사람들에게 더 나은 알림을 제공하는 방법을 살펴보겠습니다.

다양한 모니터링 팀에서 수십 년 동안 업무를 수행하면서 탄생한 모니터링 철학에 대해 알아보세요. 그녀는 Rob Evashchuk의 실제 성경에 큰 영향을 받았습니다. 경고에 대한 나의 철학 (나의 알림 철학)에 관한 책에 포함되어 있습니다. 구글 SRE, John Alspaugh의 책 경고 디자인에 대한 고려 사항 (알림 설정에 관한 참고 사항).

켈리 던, 아리짓 무케리 и 막심 페타조니 — 게시물 편집에 도움을 주셔서 감사합니다.

CASE란 무엇인가요?

나는 다음과 같은 아름다운 약어를 생각해 내기로 결정했습니다. Brendan Gregg의 USE 방법 또는 Tom Wilkie의 RED 방법. 나는 그것을 부른다 CASE 방식. 그는 자동 모니터링 작업 시 주의해야 할 네 가지 사항을 설명합니다.

• C내용이 많은 (컨텍스트 바인딩)
• A실행 가능 (실용가치)
• S증상 기반 (증상 강조)
• E가치 있는 (등급)

CASE를 사용하면 건전한 무관심으로 알림을 처리하고 밤에 사람들을 깨우지 않습니다. 모니터링의 유용성과 효과성을 정기적으로 평가해야 합니다. 사람이 알림을 받으면 더 나은 정신 모델과 더 많은 자신감을 갖게 됩니다.

더 쉽게 기억할 수 있도록 CASE가 필요하다고 상상해 보세요. [즉, 사례, 이유 - 번역가의 메모] 각 경고를 정당화합니다. :색안경:

그리고 이게 다 왜 있는 걸까요?

임무를 수행하는 것은 고통스러울 수 있습니다. 많은 이유들로 인해. 그리고 CASE는 그 모든 것을 제거하지는 않습니다. 하지만 이를 사용하면 밤에 일어나서 더 나은 알림을 받을 수 있습니다. 이 방법은 이 문제에도 도움이 되는 다양한 조직 프로세스를 다룹니다.

RED 및 USE 방법의 장점은 도움을 받아 일하는 방법을 알 수 있을 뿐만 아니라 서로 동일한 언어를 사용할 수 있다는 것입니다. CASE 방법을 사용하면 시스템을 보호하면서도 동료를 바쁘게 만드는 알림에 대해 더 쉽게 논의할 수 있기를 바랍니다.

요점은 조직에서 알림이 건전한 무관심으로 처리되는 문화를 조성해야 한다는 것입니다. 특정 목적을 위해 알림을 생성할 수 있지만 나중에 가치를 잃지 않는다는 것은 사실이 아닙니다. 이 알림을 설정한 이유는 무엇입니까? 기준이 개정된 지 얼마나 됐나요? CASE를 사용하면 이러한 질문에 답할 수 있습니다.

컨텍스트 중심 - 컨텍스트 바인딩

오전 3시는 똑똑한 단어가 많이 포함된 메시지를 읽기에 가장 좋은 시간이 아닙니다. 효과적으로 대응하려면 정보가 필요합니다. 이상적으로 이는 상황이 즉시 명확해지는 특정 문제에 대한 정보여야 하며, 이것이 가능하도록 알림을 구성해야 합니다. 이것이 '관찰'과 '지향'이다 OODA 루프. 끊임없이 사람의 주의를 산만하게 하는 것은 훨씬 더 많은 비용이 들기 때문에 이 설정에 시간을 보내는 것은 부끄러운 일이 아닙니다. 서로를 존중합시다.

문제의 원인은 다양합니다. 특히 유령.

담당관을 어떻게 도울 수 있습니까? 담당관이 가장 먼저 보는 것은 알림이므로 이를 바탕으로 모든 가설을 세웁니다. 그런 다음 지침과 대시보드를 살펴보지만 일반 정보뿐만 아니라 특정 알림에 대한 데이터가 항상 있습니까? Alspaugh는 "알림을 어떻게 해석하거나 응답할 것인지 생각해 보세요"라고 조언합니다(슬라이드 29).1. 좋은 알림은 임계값에 따라 구성되는 것이 아니라 근무자에게 초점을 맞춥니다.

알림 컨텍스트를 개선하는 방법에 대한 몇 가지 아이디어는 다음과 같습니다.

• 일반적인 지침이나 대시보드뿐만 아니라 유용하고 특별하게 만들어진 것을 사용자에게 보여주세요. 이전에는 저와 팀원들이 특정 알림을 위해 구성된 조사 대시보드를 사용했습니다. 이는 문제가 알려진 경우 도움이 되지만 다른 사람들에게는 혼란을 줄 뿐입니다. 우리는 여기서 균형을 찾아야 합니다.
• 알림 기록에 대해 알려주십시오. 새로운 알림입니까? 자주 작동합니까? 계절인가요?
• 시스템 상태에 대한 최근 변경 사항을 표시합니다. 최근에 달라진 점이 있나요? (예: 배포 또는 기능 활성화/비활성화)
• 관계를 표시하고 정신 모델에 대한 정보를 제공합니다. 시스템 종속성은 기능 표시와 함께 명확하게 표시되어야 합니다.
• 사용자를 팀과 신속하게 연결하세요. 진행 중인 사건을 볼 수 있나요? 아니면 회사 내 다른 사람이 알림을 받았는지 알 수 있나요? 프로그램 사고 관리 활성화됐나요?

이상적으로 사고 관리 프로그램은 사고 조사의 알림 컨텍스트를 개선하는 방법에 대한 조언을 제공합니다. 항상 노력해야 할 것이 있습니다!

실행 가능 - 실용적인 가치

담당관은 통지에 대응하여 조치를 취해야 합니까? 아무것도 할 필요가 없고 무엇을 해야 할지 불분명하다면 왜 그를 깨운 걸까요? 근무 중인 사람들을 짜증나게 하고 조치가 필요하지 않은 알림은 피해야 합니다.

imgur.com에 게시물보기

어떻게 해야 하나요? 당신은 무엇을 원하세요?

과거에는 시스템이 단순하고 팀 규모가 작았을 때 우리는 상황을 파악하기 위해 모니터링을 설정했습니다. 힙의 로드가 증가했다는 알림을 통해 이후에 서비스가 오작동하는 경우 상황을 알 수 있습니다. 우리 시스템은 항상 다양한 심각도의 성능 저하 상태에서 작동하기 때문에 대규모로 이러한 알림은 혼란만 야기할 뿐입니다. 이는 빠르게 다음으로 이어진다. 알림으로 인한 피로 물론 감도가 상실됩니다. 따라서 당직관은 이러한 통보를 무시하거나 심지어 필터링하고, 필요에 따라 항상 응답하지 않습니다. 이 함정에 빠지지 마십시오! 모든 알림을 연속으로 설정한 다음 이메일을 통해 일부 Godforsaken 폴더로 보내지 마십시오.

실용적인 가치가 있는 통지는 다음과 같습니다.

• 알림을 받으려면 단순히 뉴스를 보고하는 것보다 조치가 필요합니다.
• 이 작업은 자동화하기 어렵거나 위험합니다. 작업을 자동화할 수 있다면 자동화하고 사람들을 괴롭히지 마세요!
• 통지에는 긴급 권장 사항이 포함되어 있습니다. 서비스 수준 계약 (SLA) 또는 회복 시간 목표 (RTO). 그러면 담당 책임자는 조직의 사고 관리 프로그램을 활성화할 수 있습니다.

명확히 하고 싶습니다. API에 대한 가장 중요한 SLO(서비스 수준 목표)에 대해서만 알림이 제공되어야 한다고 말하는 것은 아닙니다. SLO 모니터링은 지속적으로 조각화되고 나누어져 있으며 모든 서비스에 대해 동일한 접근 방식이 필요합니다. 귀하에게 비용을 지불하는 고객에 대해 가장 중요한 SLO를 추적하게 될 것은 분명합니다. 그러나 데이터베이스와 같은 인프라 SLO도 모니터링해야 합니다. 곧 내부 고객을 상대하고 지원해야 할 것입니다. 그리고 무한히 계속됩니다.

증상 기반 - 증상 강조

원하든 원하지 않든 분산 시스템(Kavaj)에서 작업하고 있습니다.2. 결과적으로 서비스를 격리하고 오류로부터 보호하기 위해 다양한 전술을 사용합니다(Trainor 외)3. 지연된 가비지 수집이나 중단된 데이터베이스 쿼리가 문제를 나타내더라도 가까운 시일 내에 사용자에게 문제가 발생하지 않는다면 서둘러 문제를 해결할 필요가 없습니다.

이는 중요한 신호이며 실용적인 가치가 있을 수 있지만 사용자를 방해하지 않는다면 교환원의 주의를 분산시킬 만큼 긴급하지는 않습니다. 원인 기반 알림은 시스템 오류에 대한 정신 모델의 스냅샷입니다. 실패의 가능한 원인을 모두 나열하는 것보다 중요한 증상을 추적하는 것이 더 좋습니다.

알림을 의미 있게 만들려면 다음에 집중하세요. 성과 지표, 사용자에게 중요합니다. Evashchuk은 이를 "사용자 모니터링"이라고 부릅니다. 이 철학은 조직 전체에 적용되어야 함을 기억하십시오. 서비스의 인프라 깊숙한 곳에 긴급한 문제가 있는 경우 해당 팀이 이를 처리합니다. 이러한 오류로부터 시스템을 보호하는 것은 완전히 별개의 문제입니다(Trainer 외, 중요한 종속성을 최소화하기 위한 전략 섹션).3.

증상은 다양하지 않습니다.

Richard Cook은 복잡한 시스템에는 결함, 단점, 문제가 가득하다는 사실을 상기시켜 줍니다.4. 가능한 모든 이유를 나열하는 것은 Sisyphean 작업입니다. 문제를 설명하려고 노력하지만 문제는 항상 변합니다. Cindy Sridharan은 "시스템이 매 순간 완벽한 상태일 필요는 없다"고 믿으며 보다 인간적인 접근 방식을 사용하는 것이 더 좋습니다("분산 시스템 관찰 가능성" ("분산 시스템 모니터링"), 7)5.

사고 후 알림 방지

일반적으로 원인에 대한 알림은 인시던트를 수정하도록 구성됩니다. 그리고 발생한 사실에 대한 이러한 제한된 알림은 시스템이 매번 새로운 침입 방법을 제시하기 때문에 잘못된 보안 감각을 생성합니다.

원인 통지에 속지 마십시오. 더 나은 생각 :

• 증상 기반 알림에서 문제를 발견하지 못한 이유는 무엇입니까?
• 사용자의 상황을 개선하는 것이 도움이 될까요?
• 발생한 일에 대한 알림을 누적하는 대신 더 빠르게 진단할 수 있도록 모니터링 도구를 어떻게 개선할 수 있습니까?

진단을 위한 모니터링 도구는 증상에서 해결 방법으로 이동하는 방법으로 생각하는 경우에만 도움이 됩니다. 이러한 피드백이 없으면 과거 실패에 대한 늦은 알림과 차트가 쏟아져 나올 뿐 미래 실패에 대해서는 한마디도 하지 못할 것입니다. 이는 조직이 방어에서 공격으로 전환할 수 있는 좋은 기회입니다. 그리고 개발자와 제품 관리자는 동일한 기대치와 명확한 목표를 갖게 됩니다. 사례(CASE(:wink:))는 각 알림에 대해 명확합니다.

이유 기반 알림은 적당히 허용됩니다.

때때로 당사 시스템은 원인 기반 알림 측면에서 선택의 여지가 거의 없는 경우가 있습니다. 그리고 때때로 근무하는 사람들은 증상이 확실히 실패로 이어질 것이라는 것을 완벽하게 이해하므로 실질적인 가치가 있습니다. 어쩌면 당신은 무슨 일이 일어나고 있는지 확신하지 못하고 안전을 위해 알림을 설정하고 있을 수도 있습니다. 성능 문제를 해결하기 위해 시스템을 변경할 수 있을 때까지 이 조치는 일시적이기 바랍니다.
이러한 상황을 처리할 때 CASE의 다른 구성 요소를 염두에 두십시오. 일시적이라고 해서 머리로 생각하는 것을 멈출 수 있는 것은 아닙니다.

평가됨 - 평가

시스템에 대한 모든 변경 사항(새로운 코드, 새로운 인프라, 새로운 모든 것)은 실패의 범위를 확장합니다(Cook, 3).4 이 알림은 여전히 ​​예상대로 작동합니까? 시스템의 명확하고 최신 정신 모델 및 일부 지원 알림에 대한 응답 경험 예방적 접근 - 주요 기능은 다음과 같습니다. 학습 중심 조직. 시스템의 결함은 끊임없이 진화하고 있으며 우리는 이를 따라잡아야 합니다.

각 알림의 품질을 지속적으로 평가하여 예상대로 작동하는지 확인해야 합니다. 친애하는 지도자 여러분! 팀이 이 프로세스를 확립하도록 도와주면 팀이 훨씬 쉬워질 것입니다! 다음은 몇 가지 평가 아이디어입니다.

• 사용 카오스 엔지니어링, 경기일 또는 기타 알림 테스트 방법. 대규모 사고 관리 시스템에 의존하지 않고도 팀이 스스로 이를 수행할 수 있습니다!
• 모든 사고 관련 알림 수집을 사고 관리 프로그램에 통합하세요. 유용함, 유해함, 부적절함, 불분명함 등을 표시하고 피드백으로 사용하세요.
• 올바른 알림은 드물게 트리거되며 신중하게 테스트됩니다. 모든 링크가 작동하는지, 올바른 컨텍스트를 가리키는지 등을 확인하세요.
• 알림이 전혀 실행되지 않거나 너무 자주 실행된다면 알림에 문제가 있는 것입니다. 수정하거나 제거하세요. 지나친 수동성이나 활동성을 주의하세요!
• 만료 날짜가 포함된 알림 타임스탬프를 설정하세요. 만료 날짜가 만료된 경우 CASE 메서드를 사용하여 알림을 평가하고 타임스탬프를 업데이트합니다. 식품과 마찬가지로 유통기한을 정기적으로 확인하세요.
• 알림 개선 프로세스를 단순화합니다. 모니터링을 코드로 사용하고 Git 리포지토리에 알림을 저장하세요. 끌어오기 요청은 팀의 참여를 돕고 과거 알림 기록을 제공합니다. 그리고 더 이상 알림을 변경하거나 알림 책임자에게 허가를 요청하는 것을 두려워하지 않을 것입니다.
• 간단한 경우에도 알림에 대한 피드백 설정 구글 양식, 담당 직원이 알림을 쓸모 없거나 방해가 되는 것으로 표시하도록 합니다. 알림 자체에 링크나 클릭 유도 문구를 삽입하고 정기적으로 피드백을 검토하세요.
• 팀 내에서 규칙을 정하세요. 업무가 적을 때는 업무를 단순화하기 위해 근무하는 사람들에게 일을 맡기세요. 당신 이후의 모든 것이 이전보다 조금 더 나아지기를 바랍니다.

결론

저는 CASE 방법이 개발자와 조직이 자동화된 알림 설정 및 전송에 대해 논의하는 데 도움이 된다고 믿습니다. 한 개발자가 CASE 방법을 사용하여 알림 평가를 시작한 다음 전체 조직이 다른 개발자, 관리 및 사고 관리 프로그램에 참여하여 알림을 양호한 상태로 유지할 수 있습니다. 이를 위해서는 특별한 도구나 복잡한 프로세스가 필요하지 않습니다.

업계 전체는 최고 수준의 고객 서비스를 희생하지 않고 근무하면서 인적 요소에 대해 생각해야 합니다. 이러한 모든 도구와 관행은 개선될 수 있고 개선되어야 합니다. CASE 메소드가 도움이 되기를 바랍니다.

향상된 알림을 즐겨보세요!

출처 : habr.com