SRE 엔지니어 인턴으로 일주일을 보낸 방법. 소프트웨어 엔지니어의 눈으로 본 의무

SRE 엔지니어 - 연수생

먼저 제 소개를 하겠습니다. 나 - @tristan.read, 그룹의 프론트엔드 엔지니어 모니터::건강 GitLab. 지난주에 저는 대기 중인 SRE 엔지니어 중 한 명과 인턴으로 일하는 영광을 누렸습니다. 목표는 근무 중인 경찰관이 매일 사건에 어떻게 대응하는지 관찰하고 업무상 실제 경험을 쌓는 것이었습니다. 우리는 엔지니어가 사용자 요구 사항을 더 잘 이해하기를 원합니다. 기능들 모니터::건강.

나는 일주일 동안 SRE 엔지니어를 따라 어디든 따라가야 했습니다. 즉, 나는 인수인계에 참석하여 동일한 경보 채널을 모니터링하고 사건이 발생하는 경우 이에 대응했습니다.

사건

일주일 사이에 2건의 사건이 발생했다.

1. 암호화폐 채굴기

GitLab.com은 수요일에 사용량이 급증했습니다. GitLab 러너'a, 주자의 시간을 사용하여 암호화폐를 채굴하려는 시도로 인해 발생했습니다. 이 사건은 실행자의 작업을 중지하고 이와 관련된 프로젝트 및 계정을 삭제하는 자체 위반 무력화 도구를 사용하여 처리되었습니다.

이 이벤트가 발견되지 않았다면 자동화된 도구가 이를 포착했을 것입니다. 그러나 이 경우 SRE 엔지니어가 위반 사항을 먼저 발견했습니다. 인시던트 작업이 생성되었지만 해당 정보가 닫혀 있습니다.

2. Canary 및 주요 애플리케이션의 성능 저하

이 사건은 Gitlab.com의 Canary 및 주요 웹 애플리케이션의 속도 저하와 오류 빈도 증가로 인해 발생했습니다. 여러 Apdex 값이 위반되었습니다.

인시던트 작업 열기: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

주요 결과

일주일 동안 근무하면서 배운 몇 가지 사항은 다음과 같습니다.

1. 경고는 표준에서 벗어난 것을 감지할 때 가장 유용합니다.

경고는 여러 유형으로 나눌 수 있습니다.

• "초당 10개의 5xx 오류가 발생했습니다"와 같은 특정 임계값을 기반으로 하는 경고입니다.
• 임계값이 "특정 시간에 총 요청량의 5%당 10xx 오류 빈도"와 같은 백분율 값인 경고입니다.
• "5번째 백분위수의 90xx 오류"와 같은 과거 평균을 기반으로 하는 경고입니다.

일반적으로 유형 2와 3은 업무 중인 SRE에 더 유용합니다. 왜냐하면 프로세스에서 표준과의 편차를 드러내기 때문입니다.

2. 많은 경고는 결코 사건으로 확대되지 않습니다.

SR 엔지니어는 지속적으로 발생하는 경고를 처리하지만 그 중 대부분은 실제로 중요하지 않습니다.

그렇다면 정말 중요한 알림으로만 알림을 제한해 보는 것은 어떨까요? 그러나 이 접근 방식을 사용하면 심각한 피해를 초래할 수 있는 실제 문제로 눈덩이처럼 불어나는 초기 증상을 인식하지 못할 수도 있습니다.

대기 중인 SRE의 임무는 어떤 경고가 실제로 심각한 문제를 나타내는지, 그리고 해당 경고를 에스컬레이션하고 처리해야 하는지 여부를 결정하는 것입니다. 나는 이것이 또한 경고의 경직성 때문이라고 생각합니다. 위에서 설명한 상황에 따라 경고를 구성하는 여러 수준이나 "스마트" 방법이 있다면 더 좋을 것입니다.

기능 제안: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. 근무 중인 SRE는 많은 도구를 사용합니다.

내부 :

• GitLab 인프라 프로젝트: 런북이 여기에 게시되어 있으며 교대/주 배정, 사고 대응 작업이 제공됩니다.
• GitLab 문제: 조사, 검토 및 유지 관리도 문제에서 추적됩니다.
• GitLab 레이블: 자동화 작업은 봇이 작업 활동을 추적하는 데 사용하는 특정 레이블을 사용하여 시작됩니다.

외부 :

• PagerDuty: 경고
• Slack: PagerDuty/AlertManager 메시지 흐름이 여기에 표시됩니다. 슬래시 명령과 통합하여 경고 종료 또는 사건 에스컬레이션과 같은 다양한 작업을 수행합니다.
• Grafana: 장기적인 추세에 초점을 맞춘 측정항목 시각화.
• Kibana: 시각화/로그 검색, 특정 이벤트를 더 깊이 파고드는 기능을 제공합니다.
• Zoom: Zoom에는 지속적으로 실행되는 "소회의실"이 있습니다. 이를 통해 SRE 엔지니어는 회의실을 만들고 참가자를 연결하는 귀중한 시간을 낭비하지 않고도 이벤트에 대해 신속하게 논의할 수 있습니다.

그리고 많은 다른 사람들.

4. GitLab으로 GitLab.com을 모니터링하는 것은 단일 실패 지점입니다.

GitLab.com에 심각한 서비스 중단이 발생하는 경우 문제 해결 능력에 영향을 미치기를 원하지 않습니다. GitLab.com을 관리하기 위해 두 번째 GitLab 인스턴스를 시작하여 중지할 수 있습니다. 실제로 이는 이미 우리에게 효과적입니다. https://ops.gitlab.net/.

5. GitLab에 추가할 때 고려해야 할 몇 가지 기능

• 다중 사용자 작업 편집, Google 문서도구와 유사합니다. 이는 이벤트 중 사건에 대한 작업과 보고 작업에 도움이 됩니다. 두 경우 모두 여러 참가자가 실시간으로 무언가를 추가해야 할 수도 있습니다.
• 작업을 위한 추가 웹훅. 내부에서 다양한 GitLab 워크플로 단계를 실행하는 기능은 Slack 통합에 대한 의존도를 줄이는 데 도움이 됩니다. 예를 들어 GitLab 문제에서 슬래시 명령을 통해 PagerDuty에서 경고를 허용하는 기능이 있습니다.
  결론

SRE 엔지니어는 많은 복잡성으로 인해 어려움을 겪고 있습니다. 이러한 문제를 해결하는 더 많은 GitLab 제품을 보면 좋을 것입니다. 위에서 언급한 작업 흐름을 더 쉽게 만들어 줄 몇 가지 제품 추가 작업을 이미 진행 중입니다. 자세한 내용은 다음에서 확인할 수 있습니다. Ops 제품 비전 섹션.

우리는 이러한 훌륭한 기능을 모두 통합하기 위해 2020년에 팀을 확장할 예정입니다. 관심이 있으시면 확인해 보세요. 공석, 질문이 있으시면 언제든지 저희 팀에 문의해 주세요.

출처 : habr.com