옵스지니 구매자 가이드 - 올바른 경보 및 인시던트 관리 솔루션을 선택하기 위하여
- Brian Han (한진규)
실행 가능한 경보 생성으로 해결 속도 극대화
개발자 또는 IT 스택에서 문제가 발생하면 MTTR (mean time-to-resolve)을 줄이기 위해 필요한 첫 번째 요구 사항은 알림을 분류하고 올바르게 라우팅하는 것입니다. 이러한 이유로 온 - 콜 및 경보 솔루션이 모든 산업의 운영 팀에 신속히 채택되고 있습니다. 그러나 경고가 실행 가능한지 확인하는 것은 항상 일반적인 관행 인 것은 아니지만 응답 시간을 더욱 단축 할 수 있으므로 비즈니스에 영향을 미치기 전에 문제를 해결할 수 있습니다.
이 백서는 대응 가능한 경고를 작성하고 응답자가 사건을 효율적으로 알 수 있도록 안내하는 지침서 역할을하지만 MTTR을 더욱 줄이기 위한 상황 및 지침을 제공합니다.
실행 가능한 경보란 무엇입니까?
사고 대응 세계에서 실행 가능한 경보는 문제를 설명하고 적절한시기에 적절한 사람에게 전달되며 긴급 성뿐만 아니라 문제의 영향 범위를 전달하는 경보입니다. 경고는 대응자에게 올바른 방향으로 지시하여 손상을 방지하거나 최소화하는 것이 바람직합니다.
실행 가능한 경고 :
- 적시에 올바른 사람들에게 알린다.
- 상황에 맞는 정보로 문제를 조사하는 방법을 제안합니다
- 자동화를 통해 일반적인 작업 수행 가능
적시에 올바른 사람들에게 알리기
소개에서 언급 했듯이 대부분의 운영팀은 인시던트 일정을 정의하고 인시던트 발생시 경보를 라우트하는 기능을 위해 경보 및 통화 관리 솔루션을 채택합니다. 설정할 것이 거의 없기때문에 이러한 응용 프로그램은 경보 세부 정보를 보고 일부 필터링을 적용하여 잡음을 억제하고 사전 지정된 팀으로 보낼 수 있습니다. 보다 현대적인 도구를 사용하면 복잡한 논리를 라우팅 워크 플로우에 도입 할 수 있습니다. 경보의 특정 세부 사항을 타이밍과 결합하여 사용자는 긴급성을 판단하고 라우팅을 향상시킬 수 있습니다. 경보 심화가 여기에서 중요한 역할을 합니다. 예를 들어 사용자의 "Gold Level Customers"에 영향을 주는 특정 서버에서 오류가 보고 되면 이 속성을 지정하는 경보에 해당 속성이나 태그를 추가 할 수 있으므로 높은 우선 순위로 라우팅하는 데 도움이됩니다.
상황에 맞는 정보로 이슈를 조사하는 방법 제안
경보에 태그와 속성을 추가하면 효과적인 라우팅을 도울 뿐만 아니라 문제의 컨택스트를 제공하여 응답자의 시간을 절약 할 수 있습니다. 경보 내에서 추가 정보가 제공되면 대응 계획을 조사하고 공식화하는 데 소요되는 시간을 줄일 수 있습니다. 긴급 사태와 사건의 영향을 판단 할 수 있는 정보는 흔하지 않습니다. 로깅, 모니터링, 티켓팅 및 구성 관리 도구 전반에 정보가 흩어져 있습니다. 경보 생성 중에 보충 세부 정보를 제공하여 컨텍스트 전환을 방지하십시오.
또한 다른 정보는 빠른 응답에 도움이됩니다. 런북(runbook) 링크를 준비하는 것은 경보 생성 중에 수행되는 풍부한 예제입니다. 런북(Runbooks)은 응답자가 따라야 할 절차와 작업을 나열합니다. 런북을 갖는 것은 계획된 노력의 확실한 증거이며 MTTR을 줄이기위한 핵심 열쇠입니다. 런북 작성은 지속적인 프로세스입니다. 지침은 분명해야하며 모두가 해당 내용을 같은 의미로 이해해야합니다. 사건이 발생한 후, 학습자는 학습 내용을 반영하고 지시 사항을 업데이트해야합니다.
자동화를 통해 일반적인 작업 수행 가능
문맥 정보로 경보가 강화되면 지원 정보 검색을 자동화하고 응답자에게 원-클릭 작업을 제공함으로써 더 많은 가치를 실현할 수 있습니다. 자동화 할 수 있는 작업에는 조사 정보 수집, 개선 조치 취하기 및 자동으로 통신 및 협업 시작하기 등이 포함됩니다.
• 더 많은 조사 정보 수집
조사 작업은 관련 정보의 검색을 자동화합니다. 서비스에 수동으로 로그인하고 쿼리를 실행하는 등 시간이 많이 걸리는 작업은 경고에 첨부 된 작업 단추를 사용하여 자동화 할 수 있습니다.
응용 프로그램 로그를 검색하거나 그래프를 첨부하거나 서버에 ping을 수행하면 문제를 조사하는 동안 상당한 시간을 절약 할 수 있습니다. 또한 사전 정의 된 쿼리 및 작업을 사용하여 이러한 데이터의 검색을 자동화하면 사람의 실수 가능성을 줄일 수 있습니다.
Use case from a joint webinar by OpsGenie and Logentries:
https://www.opsgenie.com/webinars/logentries-2-use-cases-logs-incident-response
• 개선 조치를 취하십시오.
원-클릭 수정 작업을 수행하면 복잡한 워크플로우를 자동화하여 상당한 시간을 절약 할 수 있습니다. 사건을 해결할 수있는 반복적인 작업이 있는 경우 경보에 조치를 취하십시오. 프로세스 또는 서버를 다시 시작하는 것은 일반적인 해결 작업의 예입니다. 또 다른 예는 새 서버를 로드밸런서에 추가하여 요청수의 급증을 처리하는 것입니다. 자동화는 대부분의 반복적인 작업에서 의미가 있지만, 핵심은 사람들이 여전히 중요한 행동을 취할 때, 특히 중요도에 따라 결정 할 수 있도록 유연성을 제공하는 것입니다.
• 커뮤니케이션 및 협업 개시
우선 순위가 높은 사건의 경우, 사건 대응 팀 구성원은 서로 이야기해야합니다. 쉽게 액세스 할 수있는 신뢰 할 수 있고 통일 된 도구가 있어야 합니다. 팀 멤버가 전화 또는 화상 회의 브리지에 참여 할 수있게 해주는 경보상의 버튼은 경보 강화의 좋은 예입니다. 이와 같은 강화 된 경보는 단순한 메신저가 아닌 응답자와 이해관계자를 하나로 모으기 때문에 팀이 사건을 더 빨리 해결할 수 있도록 도와줍니다. OpsGenie의 ICC (Incident Command Center)는 사고 대응팀을 하나로 모으는 또 다른 통일 된 방법입니다. 팀은 작업중인 경보에 액세스하고 강화된 뷰(view)를 통해 정보를 교환 할 수 있습니다.
경보를 강화하게하면 MTTR에 큰 영향을 줄 수 있습니다. 경보 강화는 응답자가 이전 워크플로우와 응답 절차를 간소화하기 위해 이전 경험을 구축하는 데 도움이 되는 지속적인 프로세스입니다. NOC의 시스템 관리자 또는 운영 엔지니어는이 지침을 활용하여 가능한 한 자동화하고 영향을 많이받는 사건에 대한 사람의 판단이 필요한 중요한 작업 만 남겨 둡니다.
OpsGenie를 사용한 실제 시나리오
OpsGenie는 실행 가능한 경고를 생성하는 완벽한 도구 세트를 제공합니다. 기능은 다음과 같습니다.
- 사용자 지정 작업
- 필터링
-중복 제거 및 그룹화
-webhooks를 사용하여 주문형 데이터 검색
-runbooks 참조 및 만들기
-전화 및 회의 브리지에 대한 액세스
이 사용 사례는 OpsGenie에서 경보강화가 어떻게 수행되는지 보여주기 위한 것입니다.
이 사용 사례는 인시던트의 라이프 사이클을 중심으로 설계된 몇 가지 단계로 구성됩니다. OpsGenie는 AWS CloudWatch에서 임계 값을 초과하는 것부터 시작하여 경보를 수신하고 실행 인터페이스를 첨부하고 조사 작업을 수행하며 동일한 인터페이스 내에서 비디오 브리지를 사용하여 공동 작업을 수행합니다.
이 사용 사례에서는 AWS 람다 함수가 실패 할 때 AWS CloudWatch가 경고를 트리거합니다. AWS Lambda는 Amazon의 서버리스 컴퓨팅 서비스입니다. 이 함수는 DynamoDB 및 ElasticSearch에 액세스하여 데이터를 저장하고 쿼리합니다.
단계별 흐름은 다음과 같습니다.
- AWS CloudWatch 알람이 트리거 됨
- OpsGenie는 경보를 수신하고 누가 통화 중인지 결정합니다.
- 경보 생성 중에 Runbook이 경보에 추가됩니다.
- 스크립트가 CW 로그를 검색하여 경고에 첨부합니다.
- NewRelic에서 Elasticsearch CPU 사용량 메트릭을 검색하기 위해 사용자 지정 작업이 실행됩니다.
- 팀이 클릭 한 번으로 비디오 브리지에 참여합니다.
1 단계 : AWS CloudWatch 알람이 트리거됩니다.
Amazon CloudWatch는 Amazon Web Services (AWS) 및 AWS에서 실행되는 응용 프로그램에 대한 모니터링을 제공합니다. 메트릭을 보면서 사용자 정의 경보를 트리거합니다. OpsGenie는 이러한 경보의 디스패처 역할을합니다.
샘플 사용 사례에서 AWS CloudWatch는 AWS Lambda와 함께 작동합니다. 그것은 일종의 로깅과 후속 작업을 검색하는 기본적이고 가장 쉬운 방법입니다. 사용자가 AWS CloudWatch Alarms를 작성하여 처리되지 않은 예외, 시간 초과 또는 메모리 부족 예외와 같은 특정 조건이 발생할 때 알림을받습니다.
함수가 실패하면 OpsGenie CloudWatch 통합은 다음과 같은 페이로드를 받습니다.
AlarmName: us-east-2 sre-dynamodb-autoscale-put-config Lambda execution failed
functionName: sre-dynamodb-autoscale-put-config
logGroupName: /aws/lambda/sre-dynamodb-autoscale-put-config
NewStateReason: Threshold Crossed: 1 datapoint [1.0 (18/01/18 02:08:00)] was greater than the threshold (0.0). NewStateValue: ALARM
OldStateValue: INSUFFICIENT_DATA
Region: us-east-2
StateChangeTime: 2018-01-18T02:09:25.285+0000
Trigger: {Dimensions=[{name=FunctionN ame, value=sre-dynamodb-autoscale-put-config}]}
OpsGenie의 구성은 다음과 같습니다. 수신 된 페이로드를 원하는 형식으로 경고에 매핑합니다.
2 단계 : OpsGenie가 경보를 받고 누가 통보대상인지 결정합니다.
이 단계에서는 사전 정의 된 온-콜 일정, 라우팅 규칙 및 에스컬레이션을 사용하여 통보대상인 사람을 결정하고 통보해야합니다. 관련 정보는 경보에 자동으로 첨부됩니다.
수백 개의 팀과 서비스가 있는 복잡한 시스템이나 NOC에서는 누가 무엇을 책임지고 있는지 알아 내기 위해 외부 서비스가 자주 사용됩니다. 이것 또한 경보 강화입니다.
3 단계 : 알림 생성 중에 알림에 Runbook이 추가됩니다.
런북(Runbooks)은 사고 발생시간 동안에 행동을 취하기 위해 응답자가 의존하는 가이드입니다. 통합 고급 설정 옵션의 경고 설명이나 세부 정보에 쉽게 추가 할 수 있습니다.
여기에 런북에 대한 링크를 추가하는 것도 또 다른 옵션입니다.
4 단계 : 스크립트가 AWS CloudWatch 로그를 검색하여 경고에 첨부합니다.
OpsGenie는 웹 액세스 URL 끝점 (종종 웹 훅이라고도 함)에 HTTP POST 요청을 보내고 경고 활동 데이터를 전달할 수 있습니다. URL 끝점은 웹에서 URL에 액세스 할 수있는 한 모든 플랫폼, 웹 서버 등이 될 수 있습니다. Webhook 데이터에는 HTTP 요청 페이로드 (JSON)의 일부인 경고 필드 (alertId, username, alias, entity, userId)의 하위 집합뿐만 아니라 경고 활동 (만들기, 확인 등)이 포함됩니다. 또한 사용자는 webhook 호출을 추가하기 위해 사용자 정의 헤더를 정의 할 수 있습니다.
자체 웹 서버를 만들고 이벤트를 직접 처리하는 것은 webhook 통합과 함께 항상 옵션입니다. 그러나 OpsGenie는 개발 및 유지 관리를 쉽게하는 두 가지 방법을 권장합니다.
AWS Lambda와 같은 서버가 필요없는 아키텍처
유지 보수 및 리소스 사용이 이러한 플랫폼에서 문제가 되지 않기 때문에 사용자는 종종 AWS Lambda 또는 Azure Functions와 같은 서버리스(Serverless) 서비스를 선택하여 Webhook Integration 과 통합합니다. 서버리스(Serverless) 서비스는 자동화 된 확장성으로도 알려져 있으므로 많은 경보를 발생시키는 사건의 경우 시스템은 수동으로 작업하지 않아도 쉽게 확장 할 수 있습니다.
Marid Integration
Marid는 내부 및 외부 시스템의 통합에 직면 한 문제를 해결하기 위해 설계된 통합 서버입니다. OpsGenie Marid 통합을 사용하면 시스템과 OpsGenie 간의 양방향 브리지를 관리 할 수 있습니다. OpsGenie 경고 활동을 시스템에 전달하고 시스템의 이벤트에 대한 경고를 업데이트합니다. Marid는 사용하기 쉬운 미리 로드된 패키지를 사용하여 스크립트를 쉽게 만들 수 있습니다.
인터넷 종단점을 만드는 옵션이 아닌 경우 Marid를 프록시 서버로 사용해야합니다. 이 경우, Marid가 이를 수행하는 방법입니다.
OpsGenie는 사용사례에 중점을두고 webhook 통합을 사용하여 http 끝점에 요청합니다. 코드에 필요한 경고 세부 정보가 있으면 CW 로그를 쿼리하고 데이터를 경고에 다시 첨부합니다. 가짜 코드는 다음과 같습니다.
• 경고 세부 정보가 포함 된 HTTP 페이로드 수신
• 리소스 ID 및 시간 간격을 지정하여 AWS CloudWatch 서비스에 요청합니다
• 경고 ID를 지정하여 수신 된 로그를 추가하도록 OpsGenie에 요청하십시오.
5 단계 : NewRelic에서 Elasticsearch CPU 사용량 메트릭을 검색하기 위해 사용자 지정 작업이 실행됩니다.
사용자 지정 경고 조치는 OpsGenie가 사용자가 경고에 신속하고 효과적으로 대응할 수있는 또 다른 방법입니다. OpsGenie의 통합 기능과 함께 사용자 지정 작업에는 Ping, Trace Route 또는 Create Ticket과 같은 관련 항목이 포함됩니다. 단일 경고의 경우 최대 10 개의 사용자 지정 동작을 정의 할 수 있습니다. 맞춤 작업을 실행하면 초기 공동 조사가 가능합니다.
문제로
응용 프로그램은 종종 외부 서비스에 의존하여 데이터를 저장하고 검색합니다. 이 경우 lambda 함수는 DynamoDB 및 ElasticSearch에 액세스합니다. AWS CloudWatch에서 수신 한 장애 경고의 경우, 로그를 조사한 후 부하 증가가 서비스의 품질에 영향을 미치지 않는지 확인하기 위해 ElasticSearch 클러스터를 확인할 수 있습니다.
"NewRelic에서 Elasticsearch CPU 사용량 가져 오기"라는 사용자 지정 작업은 API를 사용하여 NewRelic Insights에서 관련 항목을 검색합니다.
OpsGenie는 사용자 지정 동작이 실행될 때 HTTP 끝점 (webhook)을 호출하고 사용자가 경고에서 동작을 실행 한 정보를 전달할 수 있습니다. OpsGenie는 4단계에서 설명한대로 Marid 유틸리티도 제공합니다.
이전 단계에서와 같이 경고 생성 직후에 스크립트를 실행하는 대신 필요에 따라 사용자 지정 작업이 실행됩니다. 웹 또는 모바일 인터페이스, API 또는 심지어 Slack과 같은 통합에서 실행될 수 있습니다.
스크립트의 흐름은 다음과 같습니다.
• 경고 ID로 HTTP 페이로드 수신
• ElasticSearch 클러스터의 CPU 사용량 관련된 최신 메트릭을 검색을 위한 NewRelic Insights API에 대한 요청 생성
• 검색된 메트릭을 첨부하여 경보 세부 정보 업데이트
다양한 모니터링 솔루션은 서로 다른 기능을 제공합니다. 예를 들어 Nagios 나 DataDog를 사용하면 일반 텍스트 대신 리소스 사용법 이미지를 첨부 할 수 있습니다. 이는 종종 예외 또는 차이점이 차트에 나타나기 쉽기 때문에 빠른 통찰력을 얻기 위해 매우 유용할 수 있습니다.
6 단계 : 팀이 원-클릭으로 비디오 브리지에 참여합니다.
OpsGenie Conference Bridge는 OpsGenie 응용 프로그램 내에서 회의 브리지를 시작할 수있는 기능을 제공합니다. 이를 통해 주요 개인과 협업하여 원하는 웹 회의 공급자를 사용하여 인시던트를 해결할 수 있습니다. 이 기능을 사용하면 사고가 발생하면 팀을 구성하고 회의 브리지에 쉽게 참여할 수 있습니다. 사고 통지 내에서 미리 설정된 회의 브릿지 세부 정보에 즉시 액세스 할 수 있으므로 응답자는 원-클릭으로 통화에 참여할 수 있습니다.
결론
실행 가능한 경보를 작성하는 것이 MTTR을 줄이기 위한 핵심 요소입니다. 상황별 통찰력에 액세스하고, 조사 및 개선 조치를 취하고, 팀을 원-클릭으로 모으는 것은 이를 생성하는 일반적인 아이디어입니다. OpsGenie는 고유의 유연한 솔루션을 제공하거나 적절한 리소스에 대한 액세스를 제공함으로써 사용자가 이러한 기능을 실현할 수 있도록 지원합니다.
추가 자료 :
https://docs.opsgenie.com/v1.0/docs/callbacks https://www.opsgenie.com/blog/2017/01/monitoring-aws-lambda-functions https://docs.opsgenie.com/ v1.0 / docs / marid-integration-server-for-opsgenie https://docs.opsgenie.com/docs/aws-cloudwatch-integration https://docs.opsgenie.com/v1.0/docs/conference- bridge https://docs.opsgenie.com/docs/custom-actions https://docs.opsgenie.com/v1.0/docs/webhook-integration
2018 년 3 월
파일
