장애 관리
이 페이지는 장애에 대해 수행할 수 있는 모든 작업에 대한 지침을 모아 놓았습니다.
장애 생성
수동으로 또는 자동으로 장애를 생성할 수 있습니다.
장애 목록에서
필수 조건:
- 프로젝트의 적어도 리포터 역할이 있어야 합니다.
장애를 장애 목록에서 생성하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Monitor > 장애를 선택합니다.
- 장애 생성을 선택합니다.
이슈 목록에서
- GitLab 13.4에서 도입됨.
필수 조건:
- 프로젝트의 적어도 리포터 역할이 있어야 합니다.
이슈 목록에서 장애를 만들려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Plan > 이슈를 선택하고 새 이슈를 선택합니다.
- 유형 드롭다운 목록에서 장애를 선택합니다. 페이지에는 장애와 관련된 필드만 사용할 수 있습니다.
- 이슈 만들기를 선택합니다.
경보에서
- GitLab 13.1에서 도입됨.
경보를 보고 있는 동안 장애 이슈를 만듭니다. 장애 설명은 경보에서 생성됩니다.
필수 조건:
- 프로젝트의 적어도 개발자 역할이 있어야 합니다.
경보에서 장애를 만들려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Monitor > 경고를 선택합니다.
- 원하는 경고를 선택합니다.
- 장애 생성을 선택합니다.
장애가 생성된 후 경보에서 보려면 장애 보기를 선택합니다.
경보와 연결된 장애를 닫으면, GitLab은 경보의 상태를 변경합니다 해결함으로. 그럼 이 경보의 상태 변경이 크레딧이 됩니다.
자동으로, 경보가 트리거될 때
프로젝트 설정에서 경보가 트리거될 때 장애를 자동으로 생성하도록 설정할 수 있습니다.
PagerDuty 웹훅 사용
- GitLab 13.3에서 도입됨.
- PagerDuty V3 웹훅 지원이 GitLab 15.7에서 도입되었습니다.
PagerDuty와 웹훅을 설정하여 각 PagerDuty 이슈에 자동으로 GitLab 장애를 생성할 수 있습니다. 이 구성에는 PagerDuty와 GitLab에서 변경을 가해해야 합니다.
필수 조건:
- 프로젝트의 적어도 관리자 역할이 있어야 합니다.
PagerDuty와 웹훅을 설정하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 설정 > Monitor를 선택합니다.
- 장애를 확장합니다.
- PagerDuty 통합 탭을 선택합니다.
- Active 토글을 활성화합니다.
- 통합 저장을 선택합니다.
- 나중에 사용할 Webhook URL의 값을 복사합니다.
- PagerDuty 웹훅 통합에 웹훅 URL을 추가하려면 PagerDuty 문서에 설명된 단계를 따릅니다.
통합이 성공적으로 이루어졌는지 확인하려면 PagerDuty에서 테스트 장애를 트리거하여 GitLab 장애가 이슈에서 생성되는지 확인하세요.
장애 목록 보기
장애 목록을 보려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- Monitor > 장애를 선택합니다.
장애의 세부 정보 페이지를 보려면 목록에서 선택하세요.
사고를 볼 수 있는 사용자
사고를 볼 수 있는지 여부는 프로젝트 가시성 수준과 사고의 기밀 상태에 달려 있습니다:
- 공개 프로젝트 및 기밀이 아닌 사고: 누구나 사고를 볼 수 있습니다.
- 비공개 프로젝트 및 기밀이 아닌 사고: 프로젝트에 대한 최소한 Guest 역할이 있어야 합니다.
- 기밀된 사고 (프로젝트 가시성에 관계없이): 프로젝트에 대한 최소한 Reporter 역할이 있어야 합니다.
사용자에게 할당
적극적으로 응답하는 사용자에게 사고를 할당하세요.
전제 조건:
- 프로젝트에 대한 최소한 Reporter 역할이 있어야 합니다.
사용자를 할당하려면:
- 사고에서 오른쪽 사이드바에서 담당자 옆에 있는 편집을 선택합니다.
- 드롭다운 목록에서 담당자로 추가할 사용자를 하나 이상 선택합니다.
- 드롭다운 목록 바깥 영역을 선택합니다.
심각도 변경
- 사고 상세 페이지에서의 심각도 편집은 GitLab 13.4에서 도입되었습니다.
사용 가능한 심각도 수준에 대한 자세한 내용은 사고 목록을 참조하세요.
전제 조건:
- 프로젝트에 대한 최소한 Reporter 역할이 있어야 합니다.
사고의 심각도를 변경하려면:
- 사고에서 오른쪽 사이드바에서 심각도 옆에 있는 편집을 선택합니다.
- 드롭다운 목록에서 새로운 심각도를 선택합니다.
또한 /severity 빠른 조치를 사용하여 심각도를 변경할 수 있습니다.
상태 변경
- GitLab 14.9에서 도입되었습니다. 기본적으로 비활성화 상태인
incident_escalations라는 플래그와 함께.- GitLab 14.10에서 GitLab.com 및 셀프 매니지드에서 활성화되었습니다.
- 기능 플래그
incident_escalations은 GitLab 15.1에서 제거되었습니다.
전제 조건:
- 프로젝트에 대한 최소한 Developer 역할이 있어야 합니다.
사고의 상태를 변경하려면:
- 사고에서 오른쪽 사이드바에서 상태 옆에 있는 편집을 선택합니다.
- 드롭다운 목록에서 새로운 심각도를 선택합니다.
Triggered는 새로운 사고의 기본 상태입니다.
당직 응답자로서
당직 응답자는 사고 페이지에 응답하여 상태를 변경할 수 있습니다.
상태를 변경하면 다음과 같은 효과가 있습니다:
- 인지됨(Acknowledged): 프로젝트의 에스컬레이션 정책에 따라 당직 페이지가 제한됨.
- 해결됨(Resolved): 해당 사고에 대한 모든 당직 페이지가 중단됨.
- 해결됨(Resolved)에서 Triggered로: 사고의 에스컬레이션 재시작.
GitLab 15.1 이전에는 경보에서 생성된 사고를 변경하면 경보 상태도 변경됩니다. GitLab 15.2 및 이후에서는 경보 상태가 독립적이며 사고 상태가 변경되어도 영향을 받지 않습니다.
에스컬레이션 정책 변경
전제 조건:
- 프로젝트에 대한 최소한 Developer 역할이 있어야 합니다.
사고의 에스컬레이션 정책을 변경하려면:
- 사고에서 오른쪽 사이드바에서 에스컬레이션 정책 옆에 있는 편집을 선택합니다.
- 드롭다운 목록에서 새로운 에스컬레이션 정책을 선택합니다.
기본적으로 새로운 사고에는 선택된 에스컬레이션 정책이 없습니다.
에스컬레이션 정책을 선택하면 사고 상태가 Triggered로 변경되어 사고가 당직 응답자에게 에스컬레이션됩니다.
GitLab 15.1 이전에는 경보에서 생성된 사고의 에스컬레이션 정책은 경보의 에스컬레이션 정책을 반영하며 변경할 수 없습니다. GitLab 15.2 및 이후에서는 사고의 에스컬레이션 정책이 독립적으로 변경할 수 있습니다.
사고 닫기
전제 조건:
- 프로젝트에 대한 최소한 Reporter 역할이 있어야 합니다.
사고를 닫으려면 오른쪽 상단에서 사고 작업 ()을 선택한 후 사고 닫기를 선택합니다.
경보에 연결된 사고를 닫으면 연결된 경보의 상태가 해결됨으로 변경됩니다. 이후 해당 경보의 상태 변경에 대한 크레딧이 부여됩니다.
자동으로 회복 알림을 통해 이슈 자동 닫기
- GitLab 13.4에서 HTTP 통합을 위해 도입되었습니다.
GitLab이 HTTP 또는 Prometheus 웹훅에서 회복 알림을 받으면, 이슈를 자동으로 닫기 위한 설정을 활성화합니다.
요구 사항:
- 프로젝트에 대해 최소한 Maintainer 역할을 가져야 합니다.
설정하는 방법:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 설정 > 모니터를 선택합니다.
- 인시던트 섹션을 확장합니다.
- 자동으로 연관된 인시던트 닫기 확인란을 선택합니다.
- 변경 사항 저장을 선택합니다.
GitLab이 회복 알림을 받으면 해당 이슈를 닫습니다. 이 동작은 GitLab Alert 봇에 의해 자동으로 닫혔음을 나타내는 시스템 노트로 기록됩니다.
인시던트 삭제
요구 사항:
- 프로젝트에 대해 소유자 역할을 가져야 합니다.
인시던트를 삭제하려면:
- 인시던트에서 인시던트 작업 ()을 선택합니다.
- 인시던트 삭제를 선택합니다.
또는:
- 인시던트에서 제목 및 설명 편집 ()을 선택합니다.
- 인시던트 삭제를 선택합니다.
기타 작업
GitLab의 인시던트는 이슈를 기반으로 구축되어 있기 때문에 다음과 같은 공통 작업이 있습니다:
도움말