인시던트 구성
Configuration
Rootly에서 생성된 모든 인시던트는 일련의 속성으로 표시될 수 있습니다. 이러한 속성은 내장되어 있거나 고객 속성일 수 있습니다. 인시던트 속성은 인시던트 관리 중에 중요한 역할을 합니다. 이는
- 각 인시던트를 특성화하는 데 도움이 됩니다 (예: kind = normal)
- 트리거 이벤트로 사용될 수 있습니다 (예: 상태 업데이트됨)
- 실행 조건을 정의하는 데 도움이 될 수 있습니다 (예: 심각도가 SEV0임)
- 메트릭 필터로 사용될 수 있습니다
- Liquid 구문을 사용하여 참조될 수 있습니다
고정 속성
고정 속성은 사용자 정의할 수 없습니다. 이들은 Rootly에 의해 그대로 생성되며, 플랫폼 전반에 걸쳐 일정 수준의 표준을 강제하기 위해 의도적으로 제한됩니다.인시던트 종류
종류 속성은 Rootly가 생성되는 인시던트의 분류를 식별하는 데 사용됩니다. 이 필드는 사용자 정의할 수 없으며 인시던트 생성 시 결정됩니다. 사용 가능한 인시던트 종류는 다음과 같습니다:| 종류 | 설명 | 데이터 값 |
|---|---|---|
| Incident | 이것들은 팀들이 가장 흔하게 생성하는 인시던트입니다. 이들은 다음을 통해 선언됩니다 /rootly new Slack 명령어. | normal |
| Sub Incident | 이들은 일반 인시던트 아래에 생성될 수 있는 하위 인시던트입니다. 이들은 기존 인시던트 채널 내에서 다음을 통해 선언됩니다 /rootly sub Slack 명령어. | normal_sub |
| Test Incident | 이들은 일반 인시던트와 동등하지만 테스트 목적으로 사용됩니다. 테스트 인시던트는 상태 페이지에 게시될 수 없습니다. 이들은 다음을 통해 선언됩니다 /rootly test Slack 명령어. | test |
| Sub Test Incident | 이들은 일반 하위 인시던트와 동등하지만 테스트 목적으로 사용됩니다. 하위 테스트 인시던트 역시 상태 페이지에 게시될 수 없습니다. 이들은 기존 테스트 인시던트 채널 내에서 다음을 통해 선언됩니다 /rootly sub Slack 명령어. | test_sub |
| Backfill Incident | 이들은 이미 해결된 후에 추가되는 인시던트입니다. 백필 인시던트가 선언되면, 인시던트 생성 시 트리거되는 모든 워크플로우는 실행되지 않습니다. 이들은 다음을 통해 선언됩니다 /rootly new Slack 명령어와 Backfill Incident를 선택합니다. | backfilled |
| Scheduled Maintenance | 이들은 계획된 유지보수 주기에 대해 선언될 수 있는 “인시던트”입니다. 이들은 고유한 상태와 다른 속성을 가집니다. 이들은 다음을 통해 선언됩니다 /rootly maintenance Slack 명령어. | scheduled |
인시던트 상태
인시던트 상태는 인시던트 대응 프로세스를 주도하는 핵심 구성 요소입니다. 이 섹션의 다른 속성들과 마찬가지로, 상태 또한 고정되어 있으며 사용자 정의할 수 없습니다. 사용 가능한 인시던트 상태는 다음과 같습니다:| 종류 | 설명 | 데이터 값 |
|---|---|---|
| 분류 | 분류 상태는 인시던트로 확인되지 않은 문제에 사용됩니다. 분류 상태로 인시던트를 선언하려면, 인시던트를 생성할 때 간단히 분류 중으로 표시 체크박스를 선택하면 됩니다. 이 상태는 예정된 유지보수에는 적용되지 않습니다. | in_triage |
| 시작됨 | 이는 인시던트의 공식적인 시작을 표시합니다. 분류 상태에서 시작됨 상태로 인시던트를 진행하거나 직접 시작됨 상태로 인시던트를 선언할 수 있습니다. 이 상태는 예정된 유지보수에는 적용되지 않습니다. | started |
| 완화됨 | 완화됨 상태는 인시던트의 영향이 중단되었음을 나타내는 데 사용됩니다. 이는 인시던트의 끝이 아닙니다. 이 상태는 예정된 유지보수에는 적용되지 않습니다. | mitigated |
| 해결됨 | 해결됨 상태는 인시던트의 종료를 나타내는 데 사용됩니다. 이는 일반적으로 회고가 생성되고 활성 이슈 티켓이 닫히는 시점입니다. 이 상태는 예정된 유지보수에는 적용되지 않습니다. | resolved |
| 취소됨 | 취소됨 상태는 인시던트의 수명 주기 중 언제든지 사용될 수 있습니다. 이는 일반적으로 거짓 양성 인시던트를 표시하거나 중복 인시던트를 닫는 데 사용됩니다. 이 상태는 예정된 유지보수에는 적용되지 않습니다. | cancelled |
| 예정됨 | 예정됨 상태는 예정된 유지보수에만 적용됩니다. 이는 유지보수 기간이 계획되고 생성되었음을 나타내는 데 사용됩니다. | scheduled |
| 진행 중 | 진행 중 상태는 예정된 유지보수에만 적용됩니다. 이는 유지보수 기간이 현재 활성 상태임을 나타내는 데 사용됩니다. | in_progress |
| 완료됨 | 완료됨 상태는 예정된 유지보수에만 적용됩니다. 이는 계획된 유지보수가 종료되었음을 나타내는 데 사용됩니다. | completed |
구성 가능한 속성
구성 가능한 속성은 내장되어 있지만 사용자 정의할 수 있습니다. 아래는 인시던트 관리 프로세스에 맞게 사용자 정의할 수 있는 구성 가능한 속성 목록입니다. 각 속성을 클릭하여 각 속성을 구성하는 방법과 Liquid 변수를 통해 참조하는 방법을 확인하세요.| 속성 | 설명 |
|---|---|
| 환경 | 이 속성을 사용하면 영향을 받는 환경에 따라 인시던트를 특성화할 수 있습니다. PROD에 영향을 미치는 인시던트는 DEV에만 영향을 미치는 인시던트보다 우선적으로 처리해야 합니다. |
| 심각도 | 이 속성은 인시던트의 영향 수준을 분류하는 데 도움이 됩니다. SEV0 인시던트는 SEV3 인시던트보다 우선적으로 처리되어야 합니다. |
| 인시던트 유형 | 이 속성은 종종 Kind 속성과 혼동됩니다. Kind는 Rootly 플랫폼에서 사용하는 내부 분류인 반면, Type은 회사의 인시던트 분류 요구 사항에 맞게 사용자 정의할 수 있습니다. 이 속성의 사용은 매우 유연합니다. 일부 회사는 이를 사용하여 UI 버그와 API 이슈를 구분합니다. 다른 회사들은 이 속성을 사용하여 내부 중단과 고객 대면 인시던트를 구분합니다. |
| 인시던트 역할 | 이 속성은 인시던트 중 대응자의 책임을 정의하는 데 도움이 됩니다. Incident Commander의 작업은 Communications Lead와 다른 작업을 가져야 합니다. |
| 팀 | 이 속성을 사용하면 인시던트를 담당 팀에 할당할 수 있습니다. 제품과 관련된 인시던트는 Product 팀으로 가야 하고, 보안 인시던트는 InfoSec 팀이 가장 잘 처리할 수 있습니다. |
| 서비스 | 이 속성을 사용하면 영향을 받는 서비스 구성 요소를 표시할 수 있습니다. 영향을 받는 서비스는 상태 페이지에 반영될 수 있습니다. |
| 기능 | 이 속성을 사용하면 인시던트 중에 중단된 특정 기능적 동작을 표시할 수 있습니다. 예를 들어, 항목을 장바구니에 담는 기능이나 로그인 기능 등입니다. Services와 마찬가지로, Functionalities도 상태 페이지에 표시될 수 있습니다. |
| 인시던트 원인 | 이 속성을 사용하면 인시던트의 근본 원인을 빠르게 분류할 수 있습니다. 이는 특히 과거 인시던트를 분석할 때 트렌드를 식별하는 데 유용합니다. |
속성 순서
각 속성 내의 항목 순서는 속성이 양식 필드로 사용될 때 항목이 표시되는 순서입니다. 항목의 순서는 전역적이며, 이는 필드와 상호 작용하는 모든 사람에게 영향을 미칩니다. 항목을 원하는 순서로 드래그 앤 드롭하거나 알파벳순으로 정렬하여 수동으로 항목의 순서를 사용자 정의할 수 있습니다.