인시던트 관리란 무엇입니까?
인시던트 관리는 개발 및 IT 운영 팀이 예기치 않은 이벤트 또는 서비스 중단에 대응하고 서비스를 운영 상태로 복원하는 프로세스입니다.
Atlassian에서는 인시던트를 서비스 중단 또는 서비스 품질 저하를 야기하여 즉각적인 대응이 필요한 이벤트로 정의하고 있습니다. ITIL 또는 ITSM 관행을 따르는 팀에서는 이 대신 '주요 인시던트'라는 용어를 사용하기도 합니다.
인시던트 관리 핸드북 받기
PDF를 다운로드하여 인시던트 관리 원칙 및 관행, 그리고 Jira Service Management를 사용하여 이 배운 점을 적용하는 방법을 알아보세요.
인시던트는 서비스 품질을 방해하거나 저하시킬 수 있는(또는 그렇게 하도록 위협하는) 모든 종류의 이벤트입니다. 비즈니스 애플리케이션의 가동 중단은 인시던트입니다. 아직 중지되지 않았지만 속도가 늦은 웹 서버도 인시던트가 될 수 있습니다. 실행 속도가 느려 생산성을 저해합니다. 더 큰 문제는 완전히 장애가 발생할 위험이 더 크다는 것입니다. 인시던트는 전역 웹 서비스 전체 중단에서 간헐적인 오류가 발생하는 소수의 사용자에 이르기까지 심각도가 매우 다양할 수 있습니다.
영향을 받은 서비스가 의도한 상태로 기능을 재개하면 인시던트가 해결된 것으로 간주됩니다. 여기에는 영향을 완화하고 기능을 복원하는 데 필요한 작업만 포함됩니다.
인시던트 관리의 중요성
Atlassian의 인시던트 관리 가치
인시던트 관리는 조직이 올바르게 수행해야 하는 가장 중요한 프로세스 중 하나입니다. 서비스 중단은 비즈니스에 막대한 비용을 초래할 수 있으므로 팀은 문제에 신속하게 대응하고 해결할 수 있는 효율적인 방법이 필요합니다. 팀에게는 인시던트의 우선 순위를 정하고, 더 빠르게 해결하며, 사용자에게 더 나은 서비스를 제공하기 위한 신뢰할 수 있는 방법이 필요합니다.
팀이 인시던트에 직면한 경우 다음과 같이 도움이 되는 계획이 필요합니다.
- 신속하게 복구할 수 있도록 효과적으로 대응합니다.
- 고객, 이해 관계자, 서비스 소유자 및 조직 내 다른 관계자와 명확하게 커뮤니케이션합니다.
- 팀으로서 효과적으로 협업하여 문제를 더 빠르게 해결하고 문제 해결을 방해하는 장벽을 제거합니다.
- 서비스 중단으로부터 배우고 교훈을 적용하여 서비스를 개선하며 미래를 위한 프로세스를 조정하여 지속해서 개선합니다.
Atlassian이 주요 인시던트를 어떻게 처리하는지 알아보시겠습니까? 내부 인시던트 관리 핸드북을 발행했습니다. 누구나 핸드북을 통해 배우고, 적용하고, 적합하다고 생각하는 방식으로 사용할 수 있습니다.
인시던트 관리 프로세스 유형
다양한 유형의 회사는 여러 유형의 인시던트 관리 프로세스를 선호하는 경향이 있습니다. 모든 회사에 적합한 하나의 프로세스는 없으므로 회사에 따라 다양한 접근 방식을 볼 수 있습니다.
많은 팀이 ITIL 인증에 설명된 것과 같은 기존 IT 스타일의 인시던트 관리 프로세스에 의존합니다. 그 외의 팀은 사이트 신뢰성 엔지니어(SRE) 또는 DevOps 스타일의 인시던트 관리 프로세스에 더 많이 의존합니다.
IT 인시던트 관리 프로세스
인시던트 관리 프로세스는 IT 팀이 서비스 방해 또는 중단을 조사, 기록 및 해결하도록 돕습니다. ITIL 인시던트 관리 워크플로는 가동 중지 시간을 줄이고 인시던트가 직원의 생산성에 미치는 영향을 최소화하는 것을 목표로 합니다. 인시던트를 관리를 위한 템플릿을 사용하여 반복 가능한 인시던트 관리 워크플로를 만들면 팀이 인시던트를 로그, 진단, 해결하고 활동을 기록할 수 있습니다.
ITIL 프레임워크는 주로 비즈니스 내에서 서비스를 운영하는 IT 팀에서 사용합니다. 일반적으로 팀은 IT 팀이 직면할 수 있는 거의 모든 유형의 인시던트와 문제, 프로세스를 포괄하는 ITIL에서 필요한 것을 가져오고 나머지는 그대로 둡니다. ITIL은 팀이 적극적인 문제 해결 문화를 조성하는 데 집중해야 할 때 유용합니다. 규정된 프로세스는 팀이 일관된 방식으로 인시던트와 작업을 추적하도록 도와주므로 보고 및 분석이 향상되고 더 효율적인 서비스와 더 성공적인 팀으로 이어질 수 있습니다.
IT 인시던트 관리 프로세스의 단계
인시던트 식별 및 기록
인시던트는 직원, 고객, 공급업체, 모니터링 시스템 등 어느 곳에서나 발생할 수 있습니다. 출처와 관계없이 처음 두 단계는 간단합니다. 누군가 인시던트를 식별하면 다른 누군가 이것을 로그합니다. 이 인시던트 로그(즉, 티켓)는 일반적으로 다음을 포함합니다.
- 인시던트를 보고하는 사용자의 이름
- 인시던트가 보고된 날짜 및 시간
- 인시던트에 대한 설명(중지되었거나 제대로 작동하지 않는 사항)
- 추적을 위해 인시던트에 할당한 고유 식별 번호
범주화
모든 인시던트에 논리적이고 직관적인 범주(및 필요에 따라 하위 범주)를 할당합니다. 이것은 데이터를 분석하여 추세와 패턴을 파악하는 데 도움이 되며, 효과적인 문제 관리 및 향후 인시던트 방지에 있어 중요한 부분입니다.
순위 지정
모든 인시던트의 우선 순위를 지정해야 합니다. 먼저 비즈니스에 미치는 영향, 영향을 받을 관련자의 수, 적용 가능한 SLA, 인시던트가 잠재적으로 재무, 보안 및 컴플라이언스에 미치는 영향을 평가합니다. 이 인시던트를 다른 모든 미해결 인시던트와 비교하여 상대적 우선 순위를 결정합니다. 모범 사례는 인시던트가 발생하기 전에 심각도 및 우선 순위 수준을 정의하여 인시던트 관리자가 우선 순위를 빠르게 알 수 있게 하는 것입니다.
대응
- 초기 진단: 이상적으로는 전면 지원 팀이 진단부터 종료까지 인시던트를 확인할 수 있지만, 그렇지 못할 경우 다음 단계는 모든 관련 정보를 로그하고 다음 티어 팀으로 에스컬레이션하는 것입니다.
- 에스컬레이션: 다음 팀은 로그된 데이터를 가져와 진단 프로세스를 계속하고, 이 팀이 인시던트를 진단할 수 없으면 다음 팀으로 에스컬레이션합니다.
- 커뮤니케이션: 팀은 영향을 받는 내부 및 외부 이해 관계자와 정기적으로 업데이트 사항을 공유합니다.
- 조사 및 진단: 인시던트의 성격을 식별할 때까지 계속됩니다. 가끔 팀은 외부 자원이나 다른 부서의 팀원을 동원하여 해결 방안을 협의하고 지원합니다.
- 해결 및 복구: 이 단계에서 팀은 진단을 받고 인시던트 해결에 필요한 단계를 수행합니다. 적절한 해결 방법을 확인한 후에도 일부 수정(예: 버그 패치 등)을 테스트하고 배포해야 할 수 있으므로, 복구는 작업을 완전히 복원하는 데 걸리는 시간을 의미합니다.
- 종료: 인시던트가 에스컬레이션되면 최종적으로 서비스 데스크로 다시 전달하여 종료됩니다. 품질을 유지하고 원활한 프로세스를 보장하기 위해 서비스 데스크 직원만 인시던트를 종료할 수 있으며, 인시던트 소유자는 인시던트를 보고한 사용자에게 해결이 만족스럽고 인시던트를 종료해도 되는지 확인해야 합니다.
DevOps 및 SRE 인시던트 관리 프로세스
인시던트 관리에 대한 DevOps 또는 SRE 접근 방식을 통해 서비스를 구축하는 팀도 서비스를 실행하고 장애가 발생할 경우 이를 수정합니다. 이 접근 방식은 상시 가동 클라우드 서비스, 전역으로 액세스되는 웹 애플리케이션, 마이크로서비스 및 SaaS(Software as a Service)의 성장과 함께 폭발적인 인기를 얻었습니다.
일상 및 업무를 위해 사용하는 소프트웨어가 사용자와 같은 물리적 위치에 있는 서버에서 호스팅되지 않는 경우가 점점 늘어나고 있습니다. 전 세계 수천 또는 수백만 명의 사용자를 위해 데이터 센터에 배포된 웹 액세스 애플리케이션일 가능성이 높습니다. 이 서비스를 실행하는 팀에 가장 중요한 것은 애질리티 및 속도입니다. 또한 모든 가동 중지 시간은 하나의 조직이 아닌 수천 개의 조직에 영향을 미칠 수 있습니다.
“직접 구축하고 직접 운영하는” 접근 방식의 장점은 애자일 팀에 필요한 유연성을 제공하지만 누가 언제 무엇을 담당하는지는 불분명할 수도 있습니다. DevOps 팀은 덜 구조화된 개발 프로세스로 편안하게 성공을 거둘 수 있습니다. 그러나 인시던트 관리를 위한 핵심 프로세스를 표준화하는 것이 가장 좋습니다. 이렇게 하면 인시던트 발생 시 어떻게 대응해야 할지 정확히 알 수 있으며 문제를 추적하고 해결 방법을 보고할 수 있습니다.
DevOps 인시던트 관리 팀의 3가지 신념
- 대기 중 담당자 교대 근무: DevOps 팀은 특정 팀원을 대기 중 담당자로 지정하는 대신 일반적으로 모든 팀원이 대기 일정에 따라 교대로 근무하여 밤에 일어나 인시던트에 대응해야 하는 부담을 나눕니다.
- 구축한 엔지니어가 문제를 해결하기에도 가장 적합: “직접 구축하고 직접 운영하는” 정신의 핵심 아이디어는 서비스에 가장 익숙한 '빌더'가 서비스 중단을 해결하기에도 가장 적합하다는 것입니다.
- 신속한 구축, 책임감 있는 실행: 엔지니어가 서비스 중단 시 자신과 팀원이 곤란한 상황에 처해 있다는 사실을 알게 되면 높은 품질의 코드를 배포해야 한다는 동기 부여가 강해집니다.
이 접근 방식은 신뢰할 수 있는 서비스를 구축하는 방법을 알아야 하는 팀에 빠른 대응 시간과 더 빠른 피드백을 보장합니다.
Atlassian 인시던트 핸드북에서 인시던트 관리에 대한 DevOps 친화적인 접근 방식을 간략하게 설명합니다.
인시던트 관리 도구
인시던트 관리는 단순히 도구만으로 수행되는 것이 아니라 도구, 관행, 인력을 적절히 조합하여 이루어집니다. 다음은 효과적인 인시던트 관리를 위한 몇 가지 가장 일반적인 도구 범주입니다.
- 인시던트 추적: 모든 인시던트를 추적하고 문서화하여 추세를 식별하고 시간 경과에 따라 비교할 수 있습니다.
- 채팅방: 실시간 문자 커뮤니케이션은 팀으로서 인시던트를 진단하고 해결하는 데 중요합니다. 또한 향후의 대응 분석을 위한 풍부한 데이터 세트도 제공합니다.
- 화상 채팅: 화상 채팅은 많은 인시던트에 대한 문자 채팅을 보완하며, 팀 화상 채팅은 결과를 논의하고 대응 전략을 수립하는 데 도움이 됩니다.
- 알림 시스템: Jira Service Management와 같은 도구는 모니터링 시스템과 통합되어 대기 중 교대 근무 및 에스컬레이션을 관리합니다.
- 문서화 도구: Confluence와 같은 도구는 인시던트 상태 문서 및 사후 검토를 캡처할 수 있습니다.
- Statuspage: Statuspage를 통해 내부 이해 관계자 및 고객과 상태에 대해 커뮤니케이션하고 모두가 정보를 공유할 수 있게 합니다.
인시던트 관리 토픽
추천 자습서
Jira Service Management의 인시던트 관리에 대해 알아보시겠습니까?
가입하여 더 많은 기사와 자습서를 보세요.
Thank you for subscribing