PagerDuty, 운영 부서가 밤에 잠을 잘 수 없는 이유

시스템이 복잡해질수록 온갖 종류의 경고가 너무 많아집니다. 그리고 이러한 동일한 경고에 반응하고 이를 집계하고 시각화해야 합니다. 많은 분들에게 긴장될 정도로 익숙한 상황이라고 생각합니다.

논의될 솔루션은 가장 예상치 못한 것은 아니지만 검색 결과 이 ​​주제에 대한 본격적인 기사가 반환되지 않습니다.

그래서 FunCorp의 경험을 공유하고 직무 프로세스가 어떻게 구성되어 있는지, 누가 전화하는지, 왜, 어떻게 볼 수 있는지에 대해 이야기하기로 결정했습니다.

PagerDuty란 무엇입니까?

그래서 이 모든 문제를 해결하기 위해 우리는 편리한 도구를 찾기 시작했습니다. 몇 가지 검색 끝에 PagerDuty를 선택했습니다. PD는 우리에게 수많은 통합과 설정을 갖춘 상당히 완전하고 간결한 솔루션인 것처럼 보였습니다. 그녀는 어떤가요?

즉, PagerDuty는 다양한 통합을 통해 들어오는 사고를 처리하고, 임무 명령을 설정한 후 사고 수준(상위 수준 - 호출, 하위 수준 - 애플리케이션/SMS에서 푸시).

담당관은 누구입니까?

아마도 이곳이 PD 설정을 시작하는 첫 번째 장소일 것입니다.

FunCorp에도 다른 회사와 마찬가지로 명예직 장교가 있습니다. 하루에 한 번 엔지니어에서 엔지니어로 전송됩니다. PagerDuty의 경고에 대한 소위 첫 번째 및 두 번째 응답 라인이 있습니다. 우선순위가 높은 경보가 도착했다고 가정하고, 첫 번째 회선에서 당직 담당자에게 전화를 걸고 10분이 지나도 아무런 반응이 없으면(즉, 확인 또는 해결 상태로 전환되지 않음) 통화가 두 번째 회선으로 넘어갑니다. 의무 엔지니어. 이는 에스컬레이션 정책을 통해 PagerDuty 자체에서 구성됩니다.

부관이 응답하지 않으면 알림이 다시 다음으로 돌아갑니다. 주된 담당관에게.

따라서 수신되는 우선 순위가 높은 경고는 처리되지 않은 상태로 남아 있을 수 없습니다. 

이제 사고가 어디서 발생할 수 있는지 살펴보겠습니다.

우리는 어떤 통합을 사용합니까?

PD는 다양한 서비스로부터 다양한 사건을 접하게 됩니다. 현재 우리는 약 25개의 서비스를 보유하고 있으며 이를 처리하기 위해 일부 기성 통합을 사용합니다.

• 프로 메테우스

주요 측정항목 수집 시스템은 Prometheus입니다. Habré에는 이미 많은 내용이 기록되어 있습니다. 다양한 환경에 대한 여러 가지가 있다고 말씀드리겠습니다. 하나는 가상 머신과 도커에서 측정항목을 수집하고, 다른 하나는 Amazon 서비스에서, 세 번째는 하드웨어 머신에서 수집합니다. Telegraf는 주로 메트릭 내보내기로 사용됩니다.

• 이메일

여기에서도 제목에서 모든 것이 명확하다고 생각합니다. 이 통합은 cron이 실행하는 일부 스크립트에서 알림을 보내는 데 사용됩니다. PD는 당신이 편지를 보낼 특정 주소를 알려줍니다. 이러한 통합을 통해 서비스를 생성할 때 우선 순위, 들어오는 사건을 처리할 순서, 경고를 정확히 생성하는 방법(각 수신 편지, 수신 편지 + 특정 규칙 등)을 설정할 수 있습니다.

• 느슨하게

제 생각에는 매우 흥미로운 통합입니다. 어떤 일이 발생했지만 사건으로 덮이지 않는 경우가 있습니다. 따라서 Slack에서 통합을 추가하여 인시던트를 생성했습니다. 즉, 기업 Slack에 쓸 수 있습니다. /callofduty 모든 것이 느리고 곧 중단됩니다. 그러면 PD가 처리해서 담당 엔지니어에게 사건을 전달하게 됩니다.

우리는하다:

우리는보다:

• API

HTTP 통합. 사실 여기에는 특별히 흥미로운 내용은 없으며 본문이 JSON 형식인 POST 요청뿐입니다. 예를 들어 흥미로운 점은 다음을 사용하여 외부 모니터링에 사용한다는 것입니다. https://www.statuscake.com/. 이 서비스는 세계 각지에서 당사 사이트의 접근성을 확인합니다. 허용되지 않는 응답 코드(예: 502)를 수신하는 경우 인시던트가 생성되고 모든 것이 위에서 설명한 체인을 따릅니다. StatusCake 자체에는 내부 URL, SSL 인증서 또는 도메인 만료를 모니터링하는 기능이 있습니다.

• 리브레NMS

이는 또 다른 모니터링 시스템입니다. 해당 웹사이트에서 자세한 내용을 확인할 수 있습니다. https://www.librenms.org/. 이를 통해 서버에서 네트워크 인터페이스와 iDRAC를 모니터링합니다.

Datadog, CloudWatch와 같은 통합도 있었습니다. 그들에게 무슨 일이 일어났는지 더 자세히 알 수 있습니다. 여기에.

눈에 보이게 함

주요 사고 보고 시스템은 Slack입니다. PD에게 들어오는 모든 사건은 특별 채팅에 기록되며, 상태가 변경되면 채팅에도 표시됩니다.

천장에 매달린 모니터 화면에 유용한 데이터를 표시할 기회가 생겼을 때 우리(데브옵스 부서)에는 표시할 것이 아무것도 없다는 것을 갑자기 깨달았습니다. 훌륭한 Grafana가 있지만 그것이 모든 것을 포괄하지는 않으며 직원들은 차트가 아닌 경고에 반응합니다.

PD를 위한 간결하고 유익한 "보드"를 GitHub에서 철저하게 검색했지만 실패한 후, 우리는 필요한 것만으로 직접 작성하기로 결정했습니다. 처음에는 PD 인터페이스 자체를 표시하는 아이디어도 있었지만, 오히려 불편해 보였다.

이를 작성하려면 읽기 전용 권한을 가진 PD로부터 키를 얻기만 하면 됩니다.
그리고 이것이 우리가 얻은 것입니다:

화면에는 현재 열려 있는 사건, 선택한 일정에 따라 현재 근무 중인 엔지니어의 이름, 우선순위가 높은 사건이 없는 시간이 표시됩니다(우선순위가 높은 사건이 있는 패널은 빨간색으로 강조 표시됩니다).

여기에서 이 구현의 소스를 확인하세요..

그 결과, 우리는 모든 사건을 볼 수 있는 편리한 대시보드를 받았습니다. 여러분 중 일부가 우리의 경험이 유용하다고 생각하면 기쁠 것입니다.

출처 : habr.com