사고 관리와 문제 관리 비교: 차이점은 무엇인가요?

매일 전 세계적으로 수십억 명의 사람들이 컴퓨터나 모바일 장치를 사용하여 인터넷에 액세스합니다. 항상 이러한 사용자 중 일부는 로딩 속도가 느리거나 충돌하기 쉬운 웹 사이트에 액세스하려고 시도합니다.

웹사이트의 성능이 저조한 한 가지 이유는 너무 많은 사람들이 동시에 사이트에 액세스하려고 시도하여 서버에 압도당했기 때문입니다. 그러나 DNS 구성 오류, 지속적인 서버 오류 또는 악의적인 행위자의 악의적인 공격을 포함하여 더 큰 우려를 나타낼 수도 있습니다.

사고는 수정이 필요한 IT 서비스의 오류 또는 합병증입니다. 이러한 사고 중 상당수는 특정 해결책이 필요한 일시적인 문제이지만, 보다 포괄적인 해결이 필요한 근본적인 문제 또는 더 복잡한 문제를 가리키는 문제를 문제라고 합니다.

이는 문제 및 오류 제어, 가동 시간 유지, 궁극적으로 고객 및 기타 이해 관계자에게 훌륭한 서비스 제공을 위한 두 가지 중요한 프로세스인 사고 및 문제 관리의 존재를 설명합니다.

조직은 고객에게 서비스를 제공하고 파트너와 협력하기 위해 디지털 기술에 점점 더 의존하고 있습니다. 조직의 기술 스택은 비즈니스를 성장시킬 수 있는 새로운 기회를 창출할 수 있습니다. 그러나 서비스 오류는 기하급수적인 혼란을 야기하고 평판과 상황에 손상을 줄 수도 있습니다.

사고 관리는 조직이 정상적인 비즈니스 프로세스를 방해할 수 있는 사고를 식별, 추적 및 해결하는 방법입니다. 사고가 발생하면 조직에서 최대한 빨리 사고 대응을 제공하는 반응적 프로세스인 경우가 많습니다.

디지털 혁신 및 기타 기술 중심 운영을 추구하는 조직이 증가함에 따라 고객에게 솔루션을 제공하기 위한 기술에 대한 의존도를 고려할 때 사고 관리의 중요성이 더욱 커지고 있습니다.

조직의 IT 서비스는 점점 더 복잡한 애플리케이션, 소프트웨어, 하드웨어 및 기타 기술 시스템으로 구성되어 있으며, 이 모든 것은 상호 의존적일 수 있습니다. 개별 프로세스가 중단되어 고객에게 제공하는 서비스가 중단되고 비즈니스 비용이 발생하고 평판 문제가 발생할 수 있습니다. 조직은 사고를 최소화하기 위해 고급 개발 운영(DevOps) 절차를 도입했지만 발생했을 때 해결하는 프로세스가 필요합니다.

조직은 매일 사소한 사고와 중대한 사고에 직면하여 관리해야 하며, 이 모든 사고는 정상적인 비즈니스 기능을 방해할 가능성이 있습니다. 조직은 시스템 중단, 네트워크 구성 문제, 버그, 보안 사고, 데이터 손실 등과 같은 계획되지 않은 중단을 포함하여 여러 유형의 사고에 주의를 기울여야 합니다.

기술 스택이 복잡해짐에 따라 사고 관리 프로세스를 전략적으로 관리하는 것이 더욱 중요해졌습니다. 조직의 모든 구성원들이 사고가 발생했을 때 어떻게 해야 하는지 알 수 있도록 합니다.

사고 관리 시스템은 직원들이 관찰한 사건(발생 후 몇 시간 후에 발생할 수 있음)을 기록하는 무뚝뚝한 도구에서 발전했습니다. 자동화 및 셀프 서비스 사고 관리 소프트웨어를 갖춘 강력하고 상시 가동되는 실무 환경을 통해 조직 내 모든 사람이 서비스 데스크에 사고를 보고할 수 있습니다.

사고를 즉시 해결하고 재발하지 않도록 하는 것이 중요합니다. 이것은 조직이 서비스 수준 계약(SLA)을 유지할 수 있게 해주며, 일정량의 가동 시간 또는 서비스에 대한 액세스를 보장할 수 있습니다. SLA를 준수하지 않으면 조직이 법적 또는 평판 위험에 노출될 수 있습니다.

사고 관리자는 사고 관리 프로세스의 주요 이해관계자입니다. 사고 관리자는 사고에 대한 대응을 관리하고 주요 이해 관계자에게 진행 상황을 전달할 책임이 있습니다. 이는 직원이 스트레스가 많은 조건에서 업무를 수행하면서 비즈니스에서 다양한 역할과 우선순위를 가진 이해관계자와 소통해야 하는 복잡한 IT 서비스 역할입니다.

문제 관리는 근본 원인을 해결하여 사고가 재발하지 않도록 하기 위한 것입니다. 특히 해당 사고가 여러 번 발생하여 문제 또는 알려진 오류로 진단되어야 하는 경우 논리적으로 사고 관리를 따릅니다.

문제 관리가 없는 사고 관리는 근본 원인이 아닌 증상만 해결하므로 향후 유사한 사고가 발생할 가능성이 있습니다. 효과적인 문제 관리는 문제에 대한 영구적인 해결책을 식별하여 조직이 미래에 관리해야 할 사고의 수를 줄입니다.

문제 관리 팀은 관찰한 사고와 보유한 기록 데이터에 따라 사후 대응적 또는 사전 예방적 문제 관리에 참여할 수 있습니다.

사고와 문제를 관찰할 때 고려해야 할 한 가지 주요 차이점은 단기 목표와 장기 목표입니다.

사고 관리는 추가 문제를 일으키지 않고 해당 서비스를 다시 온라인 상태로 전환한다는 명시된 목표를 가지고 문제 인스턴스에 개입하는 데 더 관심이 있습니다. 이는 바로 그 순간에 서비스를 계속 실행할 수 있는 단기적인 도구입니다.

문제 관리는 장기적인 대응에 더 중점을 두고 더 큰 잠재적 문제(즉, 문제)의 일부로 잠재적인 근본 원인을 해결합니다.

조직은 IT 서비스 관리(ITSM)를 사용하여 최종 사용자의 요구 사항을 충족하는 서비스의 구현, 제공 및 관리를 관리함으로써 IT 인프라를 양호한 상태로 유지하려고 노력합니다. ITSM은 예정되지 않은 가동 중지 시간을 최소화하고 모든 IT 리소스가 모든 최종 사용자에게 의도한 대로 작동하도록 하는 것을 목표로 합니다.

조직이 ITSM에 얼마나 많은 노력을 기울이는지에 관계없이 문제가 발생합니다. 조직이 예상치 못한 문제를 더 큰 문제로 발전하기 전에 해결하고 고칠 수 있는 능력은 큰 경쟁 우위가 될 수 있습니다. IT 서비스가 한 번 중단되면 사고로 간주됩니다.

예를 들어 서버에 액세스하려는 사람이 너무 많으면 서버가 충돌하여 조직에서 수정해야 하는 사고가 발생할 수 있습니다. 사고 관리는 사용자에게 영향을 미치는 특정 문제를 가능한 한 빠르고 신중하게 해결하는 것과 관련이 있습니다. 이 경우 사고 관리자는 조직의 직원에게 연락하여 조직이 이슈를 해결하는 동안 프로그램을 종료하도록 요청할 수 있습니다.

사고 관리와 문제 관리는 모두 두 가지 관리 접근 방식을 구현하고 문서화하기 위해 널리 채택된 지침 프레임워크인 정보 기술 인프라 라이브러리(ITIL)의 적용을 받습니다. ITIL은 사고가 발생하면 이에 대응하는 구조를 만듭니다. 이 글을 쓰는 시점을 기준으로 가장 최신 릴리스는 ITIL 4입니다.

ITIL은 IT 서비스를 관리하고 IT 지원 및 서비스 수준을 개선하기 위한 모범 사례 라이브러리입니다. ITIL 프로세스는 IT 서비스를 비즈니스 운영에 연결하여 비즈니스 목표가 변경될 때 변경할 수 있도록 합니다. 

ITIL의 핵심 구성 요소는 IT 서비스를 제공하는 데 필요한 모든 소프트웨어, IT 구성 요소, 문서, 사용자 및 하드웨어의 상호 의존성을 추적하고 관리하는 구성 관리 데이터베이스(CMDB)입니다. 또한 ITIL은 사고 관리와 문제 관리를 구분합니다.

지속적으로 충돌하는 서버는 하드웨어 오류나 잘못된 구성과 같은 더 크고 체계적인 문제를 나타낼 수 있습니다. IT 서비스 팀이 근본 원인을 파악하지 못하고 근본적인 문제에 대한 솔루션을 매핑하지 못하면 충돌이 계속될 수 있습니다. 이 경우 대응을 위해 반복되는 사고 수정과 관련된 문제 관리로의 에스컬레이션이 필요할 수 있습니다.

문제 관리란 문제의 근본 원인 분석과 권장 솔루션을 제공하는 것으로, 문제가 다시 발생하지 않도록 필요한 리소스를 파악하는 것을 말합니다.

효과적인 사고 및 문제 관리에는 실시간 모니터링, 자동화 및 불필요한 다운타임이나 비즈니스 중단을 방지하기 위해 가능한 한 빨리 문제를 해결하기 위해 협력하는 전담 작업자가 필요한 구조화된 워크플로가 포함됩니다. 두 가지 형태의 관리 모두 조직이 알아야 할 몇 가지 반복되는 구성 요소를 제공합니다.

인시던트 관리

• 사고 식별: 사고를 해결하려면 먼저 사고를 관찰해야 합니다. 조직은 사고 발생 시 알림을 감지하고 전송하기 위해 시스템을 점점 더 자동화하고 있습니다. 그러나 많은 경우 사고가 발생하고 있는지 확인하고, 개입이 필요한지 여부를 결정하고, 올바른 접근 방식을 확인하기 위해 사람이 필요합니다. 예를 들어, 서버 충돌은 디지털 우선 조직에서 흔히 발생하는 사고입니다. 서버가 오프라인 상태가 되면 자동화된 도구나 직원이 사고를 식별하여 사고 관리 프로세스를 시작할 수 있습니다.
• 사고 보고: 이는 기계나 사람이 관찰한 사고 기록을 카탈로그화하는 공식적인 프로세스입니다. 여기에는 개인 또는 시스템이 문제에 응답자를 할당하고, 사고를 분류하고, 영향을 받는 사업부와 해결 날짜를 식별하는 프로세스인 로깅이 포함됩니다.
• 사고 해결 우선순위: 현대 조직에서는 소프트웨어와 IT 서비스가 상호 의존적인 경우가 많기 때문에 하나의 사고가 다른 서비스에도 연쇄적인 영향을 미칠 수 있습니다. 때로는 사고가 더 큰 체계적 실패의 일부로 발생하여 치명적인 일련의 사건을 촉발할 수 있습니다. 예를 들어 여러 서버가 고장나면 비즈니스 분석 팀이 필요한 데이터에 액세스하지 못하거나 회사의 지식 근로자가 업무에 필요한 소프트웨어에 로그인하여 액세스하지 못할 수 있습니다. 또는 회사의 API가 실패하면 조직의 고객은 최종 사용자에게 서비스를 제공하는 데 필요한 정보에 액세스할 수 없을 수 있습니다. 두 상황 모두 대응 팀은 문제의 전체 범위를 평가하고 비즈니스에 대한 단기 및 장기 영향을 최소화하기 위해 해결할 사고의 우선 순위를 정해야 합니다. 조직에 가장 큰 영향을 미치는 사건에 따라 우선순위를 정할 수 있습니다.
• 사고 대응 및 억제: 그런 다음 자동화된 소프트웨어 또는 시스템의 도움을 받을 수 있는 대응 팀이 사고 문제 해결에 참여하여 비즈니스 중단을 최소화합니다. 대응 팀은 일반적으로 필요에 따라 내부 IT 팀 구성원, 외부 서비스 제공업체 및 운영 직원으로 구성됩니다.
• 사고 해결: 이는 IT 운영이 정상적인 서비스로 돌아가는 데 매우 중요합니다. IT 사고에 대한 잠재적인 해결 방법에는 잘못 작동하는 서버를 오프라인으로 전환하거나, 패치를 만들거나, 해결 방법을 설정하거나, 하드웨어를 변경하는 것이 포함됩니다.
• 사고 문서화 및 커뮤니케이션: 이는 향후 사고를 방지하는 데 도움이 되는 사고 수명 주기의 중요한 단계입니다. 많은 회사에서 직원들이 과거에 발생했을 수 있는 사고를 해결하는 데 도움이 되도록 검색할 수 있는 사고 보고서를 위한 지식 기반을 만듭니다. 또한 신입 사원은 회사가 최근에 직면한 사고와 적용된 솔루션에 대해 배울 수 있으므로 다음 사고에 대해 보다 쉽게 도움을 줄 수 있습니다. 문서는 문제가 반복되어 문제가 되는지 여부를 판단하는 데에도 중요하므로 문제 관리의 필요성이 높아집니다.

문제 관리

• 문제 평가: 이제 조직은 해당 사고가 문제 기록으로 분류되어야 하는지, 아니면 단순히 관련이 없는 사고인지 결정해야 합니다. 전자는 이제 문제 관리의 일부가 되었습니다.
• 문제 로깅 및 분류: IT 팀은 이제 식별된 문제를 로깅하고 각 발생 사항을 추적해야 합니다.
• 근본 원인 분석: 조직은 이러한 문제의 근본 원인을 연구하고 장기적인 해결책을 만들기 위한 로드맵을 개발해야 합니다. 이를 달성하는 한 가지 방법은 원래 문제를 식별할 수 있을 때까지 각 단계에서 재귀적인 "어떻게" 질문을 하는 것입니다.
• 문제 해결: 문제와 근본 원인을 이해하는 IT 팀은 이제 문제를 해결할 수 있습니다. 문제의 심각성이나 복잡성에 따라 신속한 대응 또는 장기적인 대응을 고려할 수 있습니다.
• 사후 분석: 관련 직원이 사고, 근본 원인 및 문제에 대한 대응책을 논의하는 사후 분석은 가동 시간을 유지하고 고객에게 우수한 서비스를 제공하는 데 관심이 있는 모든 투명한 조직에 중요한 구성 요소입니다. 사후 분석은 모든 사람에게 직원을 판단하거나 문제에 대해 비난하지 않고 개선 방법을 논의할 수 있는 기회를 제공합니다. 사후 분석의 목적은 무슨 일이 일어났는지 알아내고 조직을 개선하기 위한 조치를 정의하는 것입니다. 또한 팀이 향후 사고에 더 잘 대응할 수 있는 방법에 대한 통찰력을 제공할 수 있습니다. 사고 및 문제 관리를 활성화하고 간소화하기 위해 조직에 변화 관리가 필요한지 여부를 식별할 수 있습니다. 최고의 아이디어와 최고의 결과는 개방적이고 정직한 사후 분석 회의에서 나옵니다. 팀 문화는 이것이 팀이 IT 서비스를 개선할 수 있는 방법을 발견하는 방법이지 비난할 사람을 찾는 방법이 아니라는 것을 모든 구성원에게 확신시켜야 합니다. 팀은 이것이 정직하고 도움이 되는 행동인지 아닌지를 빠르게 이해할 수 있습니다.

조직은 종종 다음과 같은 몇 가지 핵심 성과 지표(KPI)를 기반으로 사고 관리자와 사고 관리 프로세스를 평가합니다.

• 조치를 취할 수 있는 평균 시간: 사고에는 탐지, 대응 및 수리가 필요합니다. 조직은 평균 알림 또는 인지 시간(MTTA), 평균 대응 시간 및 평균 복구 시간(MTTR)으로 사고 관리 서비스의 상황을 판단하며, 이 모든 지표는 조직이 사고에 어떻게 대응할 수 있는지 명확하게 파악할 수 있습니다.
• 평균 고장 간격(MTBF): 모든 IT 서비스에 대한 사고 사이의 시간입니다. 예상보다 더 자주 발생하는 MTBF는 보다 사전 예방적인 자세가 필요한 더 큰 문제를 의미할 수 있습니다.
• 가동: 서비스를 사용할 수 있고 의도한 대로 작동하는 시간입니다. 운영 시간이 너무 적으면 조직이 최종 사용자와의 SLA를 위반하거나 경쟁업체에 비즈니스를 잃을 위험이 있습니다.
• 보고된 사건 및 문제: 사고 관리자가 지정된 기간 동안 보고한 사고 수입니다. 보고된 사고가 증가하는 것은 더 큰 문제의 징후일 수 있습니다.

포괄적인 문제 및 사고 관리 계획을 갖춘 회사는 사고에 신속하게 대응하고 경쟁사보다 뛰어난 성과를 낼 수 있습니다. 다음과 같은 이점이 있습니다.

• 고객 만족도 및 충성도 향상: 고객은 지불한 서비스와 제품이 필요할 때마다 작동하기를 기대합니다. 점점 더 많은 제품이 소프트웨어(또는 스마트 장치와 같은 소프트웨어에 연결됨)입니다. 스마트 초인종을 만드는 회사에서 서버가 충돌하면 사람들이 집이나 아파트에 들어갈 수 없습니다. DNS 오류 문제가 있는 호텔 예약 웹사이트는 그날 수익을 잃고 잠재적으로 평생 고객을 경쟁업체에 빼앗길 수 있습니다. 사건과 문제의 영향은 조직에 큰 부담을 줄 수 있습니다. 사고에 더 빠르게 대응하고 가동 중지 시간을 최소화하는 회사는 고객이 만족하지 않을 경우 공급자를 바꿀 가능성이 있는 고객의 충성도를 얻을 수 있습니다. 강력한 사고 관리 전략은 가동 중지 시간과 고객 또는 직원의 퇴사 가능성을 줄여 기업의 비용을 절감하며, 이 두 가지 모두 어려운 비용과 관련이 있습니다.
• 직원 만족도 향상: 심각한 IT 사고는 고객만큼이나 직원에게도 영향을 미칩니다. 중요한 비즈니스 소프트웨어에 액세스할 수 없는 직원은 업무를 수행할 수 없습니다. 회사가 상황을 다시 온라인 상태로 만들려고 함에 따라 이들의 업무는 쌓여만 갑니다. 업무를 따라잡기 위해 초과 근무나 주말에 일해야 할 수 있으며, 이는 스트레스를 유발하고 사기를 위협할 수 있습니다.
• SLA 요구 사항 충족: 조직은 SLA에서 자사 제품 및 서비스에 대한 고객 기대치를 자세히 설명합니다. 조직은 SLA에서 서비스 약관을 지키지 않고 잠재적으로 경쟁업체에 고객을 잃을 경우 법적 조치를 취할 위험이 있습니다.

IBM® Turbonomic은 기존 ITOps 솔루션과 통합하고, 사일로화된 팀과 데이터를 연결하고, 수동적인 반응형 프로세스를 지속적인 애플리케이션 리소스 최적화로 전환하는 동시에 클라우드 소비를 33%까지 안전하게 줄입니다.

사고 관리를 위한 자체 호스팅 옵션인 IBM Cloud Pak for AIOps는 사전 예방적 사고 관리 및 자동화된 문제 해결을 달성하여 고객이 직면한 가동 중단을 최대 50%까지 줄이고 평균 복구 시간(MTTR)을 최대 50%까지 단축합니다.

Think 뉴스레터 구독하기