변경 및 사고 관리

민첩한 문화 구축이 어떻게 대부분의 조직에서 필수가 되었는지, 그리고 솔루션에 대한 운영 준비 상태 를 평가하는 것의 중요성에 대해 논의했습니다. 변경 관리 및 사고 관리는 IT 운영 관리의 초석입니다. 변화가 자주 발생하는 민첩한 환경에서 이는 조직의 핵심 구성 요소입니다.

변경 관리 및 인시던트 관리는 ITIL 프레임워크에 포함된 잘 정의된 ITSM(IT 서비스 관리) 사례입니다.

이 두 가지 주제는 본질적으로 관련이 없을 수도 있지만, 나는 그것들이 매우 상호 연결되어 있어 동일한 전제에 뿌리를 두고 있다고 믿습니다.

인시던트 관리는 이벤트 또는 중단에 대응할 때 구조화되고 잘 정의된 프로세스를 갖는 것이며, 변경 관리는 잠재적으로 인시던트를 유발할 수 있는 환경 변경의 위험을 평가하는 프로세스를 갖는 것입니다. 중단이 환경에 미치는 영향을 적절하게 평가할 수단이 없는 경우 주어진 변경의 위험을 어떻게 적절하게 평가할 수 있습니까?

이를 위해 다음과 같은 참고용 프레임워크/워크플로를 제안합니다. 처음에는 다소 복잡해 보일 수 있지만 이 모델의 목표는 영향을 평가하는 프로세스를 예술이 아닌 과학으로 만들어 정전이 발생했을 때 방해가 될 수 있는 일부 주관성을 제거하는 것입니다. 발생하고 판단은 순간의 긴급성에 의해 흐려집니다.

아무도 당신이 확립되고 잘 알려진 프로세스를 가지고 있다고 비난해서는 안 되며, 그 프로세스를 따른다고 해서 일부 세부 사항에 동의하지 않을 수도 있습니다. 그러나 향후 변경 사항에 영향을 줄 수 있도록 언제든지 논의에 초대할 수 있습니다.

아래에 표시된 워크시트는 공유 Google 스프레드시트 로 사용할 수 있습니다.

정전 영향 평가

정전의 결과를 평가하는 것은 일반적으로 매우 주관적입니다. 예를 들어 그 영향이 단일 사용자가 있는 컴퓨터 시스템의 완전한 중단인 경우 해당 단일 사용자가 신규 인턴이거나 회사의 CEO인 경우 IT 직원의 응답이 크게 다를 수 있다는 점을 유감스럽게 생각합니다. . 개발 시스템은 개발자가 해당 시스템 없이 작업을 수행할 수 없는 경우 프로덕션 시스템으로 간주될 수 있습니다. 하지만 로컬 시스템에서 개발할 수 있을까요? 그것은 정말로 당신의 상황에 달려 있으며, 오늘 사실이 내일 더 이상 사실이 아닐 수도 있음을 명심해야 합니다. 정기적으로 해당 시스템의 중요성을 재평가해야 합니다.

다시 한 번, 명확성과 투명성이 핵심이며, 이러한 논의를 통해 서비스 사용자 및 이해 관계자와 결과에 대한 합의에 도달해야 합니다. 아마도 잘 정의된 SLO(서비스 수준 목표) 문서일 수 있습니다. 필요한 경우 사용자가 이 시스템의 가치에 대한 정확한 정보를 팀에 제공하고 유지하도록 장려합니다. 프로덕션 시스템은 백업을 더 자주 수행하지만 월별 비용은 더 많이 들 수 있습니다.

각 서비스의 중요도 평가는 기업 수준에서 수행되어야 하며, 모두가 자신의 부서가 다른 부서보다 더 중요하다고 생각하며 평가는 상대적이며 공정하게 객관적이어야 합니다.

특히 마이크로서비스의 경우 환경의 종속성을 이해하고 문서화하는 것도 중요합니다. PoC 서비스가 프로덕션 시스템의 업스트림 종속성일 수 있습니까? C4 방법론( 텍스트에서 다이어그램 만들기 참조)은 매우 유용하고 문서화가 중요하며 하루 종일 Visio 다이어그램을 수행하기 위해 시스템 설계자가 필요하지 않습니다. 저는 "예쁜" 다이어그램보다 조잡하지만 정확한 다이어그램을 선호합니다. 낮.

유효성

사용 가능하려면 시스템에 액세스할 수 있고 사용할 수 있어야 합니다. 사용자가 시스템에 액세스할 수 없거나 시스템이 느리거나 응답하지 않으면 사용자 관점에서 사용할 수 없습니다. 일반적으로 다운타임이라는 용어는 시스템을 사용할 수 없는 기간을 나타내는 데 사용됩니다.

사고 심각도

심각도 는 사용자가 볼 때 문제로 인해 시스템 가용성에 발생한 손상 또는 피해의 양입니다.

성공 또는 실패의 관점에서 측정된 경험.

인시던트의 심각도 를 확인하려면 가장 관련성이 높은 카테고리 를 선택하십시오.

사고 영향 유형

문제의 영향 유형 문제가 발생한 빈도로 측정한 문제의 발생 빈도와 문제를 경험한 사용자가 앞으로 문제를 피하거나 극복하는 방법을 배울 수 있는지 관찰하여 측정한 문제의 지속성 요인 .

유형은 다음과 같습니다.

• 지속됨 - 문제가 결정되지 않은 시간 동안 모든 사용자에게 일정합니다.
• 임시 - 문제는 모든 사용자에게 일정하지만 미리 결정된 짧은 기간 동안만 발생합니다.
• 산발적 - 문제는 "한 번만" 또는 일부 사용자에게만 나타납니다.

영향 유형과 결합된 사고 심각도는 영향 유형 승수를 선택하는 데 사용됩니다.

가장 관련성이 높은 카테고리 선택 :

영향을 받는 시스템 가중치 및 사고 범주 등급

시스템에는 조직에 대한 상대적 중요도 수준에 따라 임의의 시스템 가중치 가 할당됩니다.

영향 유형 승수 와 결합된 이 가중치는 영향 점수 를 결정하는 데 사용됩니다.

가장 높은 점수를 받은 영향을 받는 시스템을 선택하십시오.

사고 관리

특정 시스템에 대한 전체 중단의 영향을 명확하게 이해하고 이를 정량화할 수 있는 방법이 있으면 사고 관리 프로세스 정의를 시작할 수 있습니다.

범위

내부 데이터 센터의 문제인지, 클라우드 공급자나 ISP의 문제인지 여부에 관계없이 보고된 중단의 실제 원인에 관계없이 사고 관리 프로세스를 따라야 합니다.

인시던트 관리 프로세스는 사용자 요청에 적합하지 않거나 사용자 시스템 또는 로컬 구성의 문제를 추적하는 데 적합하지 않으며 공유 기관 시스템의 문제를 추적하기 위한 것입니다. 또한 사용자가 변경 또는 새 응용 프로그램을 요청하는 것은 적절하지 않습니다. 이러한 목적을 위해 서비스 요청 프로세스를 구현해야 합니다.

목표

사고 관리의 목표는 영향을 받는 서비스를 신속하게 복구하는 것입니다. 중단의 심각도 및 영향에 따라 문제 관리 프로세스는 관련되어 있지만 뚜렷한 목표를 제공하는 하나 또는 일련의 관련 사고의 근본 원인을 결정하는 데 필요할 수 있습니다.

단계

1. 감지하다
2. 대답하다
3. 다시 덮다
4. 배우다
5. 개선하다

주어진 사고 또는 잠재적 사고의 범주 등급은 사고 심각도 및 영향을 받는 시스템 에 미치는 영향 유형의 요인으로 계산됩니다. 이 등급은 인시던트 관리(3페이지 참조)에서 중단 범위를 결정하는 데 사용되며 변경 관리2에서 수행되는 작업의 잠재적 위험을 결정하는 데 사용됩니다.

가장 심각한 영향을 받는 시스템의 영향 점수 는 상황에 대한 가장 적절한 조치 및 커뮤니케이션 계획을 포함하는 사고 범주 등급 을 결정하는 데 사용됩니다.

사고 범주 평가 및 커뮤니케이션 계획

영향 점수 등급 은 사건 범주 와 사건을 적절하게 전달하고 기록하기 위해 따라야 하는 단계를 결정합니다.

이러한 작업은 예시로 제공되며 추가 단계를 포함해야 합니다.

변경 관리

변경 관리 프로세스는 위에서 논의한 것과 정확히 동일한 영향을 받는 시스템 가중치 및 인시던트 범주 등급 을 사용해야 합니다. 조직에 대한 중단 측정은 변경되지 않았습니다. 유일한 차이점은 운영 중단 기간 동안 해당 중단이 발생할 가능성을 포함해야 한다는 것입니다. 변화. 아래에서 더 자세히 알아보기 위해 먼저 용어를 정의해 보겠습니다.

범위

변경 관리는 사내 또는 클라우드에서 회사의 IT 시스템에 대한 모든 변경 사항에 적용됩니다.

목표

변경 관리 프로세스 는 사고 관리 프로세스와 동일한 영향 등급을 사용합니다 . 변경 관리의 목표는 적절한 커뮤니케이션 채널과 승인을 따를 수 있도록 조직의 서비스에 대한 변경 위험 수준을 적절하게 평가하는 것입니다. 또한 목표는 다음과 같습니다.

1. IT에서 요구하는 변경 사항의 시기적절하고 효과적인 구현 지원
2. 조직에 대한 위험을 적절하게 관리
3. 조직에/조직에 대한 변경의 부정적인 영향 최소화
4. 변경 사항이 원하는 비즈니스 결과를 달성하도록 보장
5. 거버넌스 및 규정 준수 기대치 충족 보장
   

주어진 사고 또는 잠재적 사고의 범주 등급은 사고 심각도 및 영향을 받는 시스템 에 미치는 영향 유형의 요인으로 계산됩니다.

있을 수 있는 일

가능성 은 위험이 발생할 확률이며 종종 5점 척도로 순위가 매겨집니다.

• 확실함 - 80~100% - 변경 중 또는 변경 후에 문제가 나타날 가능성이 매우 높습니다.
• 가능성 - 60~80% - 변경 중 또는 변경 후에 문제가 발생할 가능성이 있습니다.
• 가능 - 40~60% - 변경 중이나 변경 후에 문제가 발생할 수 있지만 거의 발생하지 않을 것입니다.
• 가능성 없음 - 20~40% - 변경 중 또는 변경 후에 문제가 발생할 가능성이 희박함
• 희귀 - 0~20% - 변경 중 또는 변경 후에 문제가 발생할 가능성이 매우 낮음

제안된 변경의 위험 요소는 가능한 가장 높은 사고 범주 등급 에 이 위험이 발생할 가장 높은 가능성 을 곱하여 측정됩니다.
위험 = 가능성 x 심각도

조직의 시스템 및 지원 인프라에 변경 사항을 적용할 때 IT 팀은 다음 위험 평가 매트릭스를 기반으로 변경 사항의 잠재적 영향을 평가합니다.

위험 등급 및 커뮤니케이션 계획 변경

위험 요소 및 변경의 긴급성에 따라 IT 팀은 다음을 따릅니다.

사용자에게 변경 사항을 알리는 단계: