인시던트 대응 모범 사례 및 팁

1. 항상 점프백 챙기기

인시던트 대응자를 위한 “점프백”은 팀이 최소한의 지연으로 액세스해야 하는 모든 중요한 정보를 보관합니다. 디지털 문서일 가능성이 높지만 인시던트 대응자를 위한 중앙 집중식 출발점을 마련하면 큰 도움이 됩니다.

여기에는 다음과 같은 다양한 항목이 포함될 수 있습니다.

• 인시던트 대응 계획
• 담당자 목록
• 대기 일정
• 에스컬레이션 정책
• 회의 도구 링크
• 액세스 코드
• 정책 문서
• 기술 설명서 및 런북

2. 런북에서 실행하지 않기

런북은 주어진 시나리오에서 취해야 할 단계에 대한 가이드를 제공합니다. 시스템 전문가가 즉시 도움을 줄 수 없는 경우 대기 중 교대 근무를 진행하는 팀에게 특히 중요합니다. 잘 관리된 일련의 런북을 통해 팀은 더 빠르게 대응하고 인시던트 대응 관행에 대한 공유 기술 자료를 구축할 수 있습니다.

3. 혼돈 포용, 안정성 향상

카오스 엔지니어링은 시스템을 보다 견고하게 구축할 수 있는 방법을 파악하기 위해 의도적으로 오류를 삽입하여 시스템을 실험하는 관행입니다. Chaos Monkey가 좋은 예입니다. 원래 Netflix에서 개발한 Chaos Monkey는 의도적으로 프로덕션 시스템을 오프라인으로 전환하여 네트워크 복원력을 테스트하는 도구입니다.

4. NOC를 벗어나 생각하기

과거에는 Network Operations Centers(NOC)가 대규모 IT 시스템의 모니터링 및 알림 허브 역할을 했습니다. 최신 인시던트 관리 도구를 사용하면 이 프로세스를 크게 간소화할 수 있습니다. 정의된 알림 유형, 팀 일정 및 에스컬레이션 정책을 기반으로 알림 전달 워크플로를 자동화하여 사람의 실수 및/또는 지연 가능성을 방지할 수 있습니다.

5. 악화 대신 집계

여러 모니터링 도구에서 지속적으로 알림을 받는 것보다 더 나쁜 상황은 없습니다. 단일 도구를 통해 알림 흐름을 중앙 집중화하면 팀은 불필요한 사항을 더 잘 필터링하여 주의가 필요한 문제에 빠르게 집중할 수 있습니다.

6. 지식은 힘이라는 사실을 명심

기본 알림은 무언가 잘못됐다는 사실을 전달하지만, 항상 문제가 무엇인지 알려주지는 않습니다. 따라서 팀은 원인을 조사하고 파악해야 하므로 불필요한 지연이 발생합니다. 알림이 트리거된 이유에 대한 기술적 세부 정보와 알림을 결합하면 수정 프로세스를 훨씬 빠르게 시작할 수 있습니다.

7. 알림에 대한 알림

라틴어 구절 “quis custodiet ipsos custodes”(“경비원은 누가 지킵니까?”)는 보편적인 문제를 식별합니다. IT 팀과 개발자 팀이 사용하는 모니터링 도구는 그들이 보호하도록 설계된 시스템과 마찬가지로 인시던트 및 가동 중지 시간에 취약합니다. 전체적인 알림 프로세스를 통해 시스템과 시스템을 모니터링하는 도구 모두의 상태를 지속적으로 검사할 수 있습니다.

8. 출혈 멈추기

응급실 담당 의사는 환자가 도착할 때마다 모든 상황을 해결하려고 시도하다가 난관에 봉착하게 되면 더 큰 피해로 이어질 위험이 있음을 알고 있습니다. 그들의 초점은 환자를 급성 치료로 넘길 수 있을 만큼 안정화시키는 단기적인 조치에 있습니다. 기술 분야에서 억제 조치는 인시던트 범위를 최소한으로 제한하거나 더 이상적으로는 시스템을 다시 온라인으로 전환하는 임시 솔루션(네트워크 격리, 빌드 회귀, 서버 재시작 등)에 중점을 둡니다.

9. 개인이 아닌 팀으로

IT 및 DevOps 팀의 영웅 문화는 사라진 철학입니다. 시스템을 다시 온라인 상태로 전환할 수 있는 유일한 담당자라는 이유로 저녁과 주말에도 끝없이 일하는 고독한 엔지니어의 모습은 더 이상 유행이 아닙니다. 대신 팀은 말 그대로 '팀으로' 일하고 있습니다. 체인의 강도는 가장 약한 고리가 결정하므로 팀은 단 하나의 고독한 영웅 대신 팀 전체의 능력을 육성하기 위해 노력합니다.

10. 투명성 유지

사용자가 서비스 중단을 겪을 경우 인시던트는 일반적으로 짧은 시간 내에 공개됩니다. 이보다 앞서 나가려면 팀은 인시던트 커뮤니케이션 계획을 마련해야 합니다. 목표는 서비스 중단이 발생하고 있음을 공개적으로 인정하여 고객과의 신뢰를 구축하고, 문제를 해결하기 위한 조치가 취해지고 있음을 알리는 것입니다. Statuspage와 같은 도구는 이러한 정보를 배포하는 데 유용합니다.

11. 실패로부터 배우기

대다수의 IT 및 DevOps 팀은 “주요 시스템 중단”을 검토하는 데만 시간을 들인다고 말할 것입니다. 이것은 좋은 시작이지만 지속적인 영향을 미칠 수 있는 소규모 인시던트를 간과하는 경우가 많습니다. 모든 인시던트에 긴 보고서가 필요한 것은 아니지만 사후 검토 분석은 항상 유용합니다.

12. 근본 원인 찾기(근본 원인 없음!)

아니면 있습니까? 인시던트를 분석할 때 식별 가능한 하나의 “근본” 원인을 콕 짚을 수 있는 경우는 드뭅니다. 시스템은 종종 너무 복잡하고 상호 의존적이어서 인시던트에 대한 하나의 근본 원인을 정의할 수 없습니다. 근본 원인이 명백해 보이더라도(예: 키 입력 오류로 인한 애플리케이션 중단) 일반적으로 애플리케이션 중단을 허용한, 또는 방지하지 못한 외부 요인을 이해하기 위한 원인이 있습니다. 인시던트를 더 깊이 이해하려면 여러 가지 근본 원인을 찾아보세요.

13. 비난 배제

모든 인시던트 사후 검토의 목표는 무엇이 잘못되었는지, 향후 유사한 인시던트를 방지하려면 무엇을 할 수 있는지 이해하는 것입니다. 중요한 것은 이 프로세스를 비난하는 데 사용해서는 안 된다는 것입니다. “무엇”이 아닌 “누구”에 초점을 맞춘 팀은 감정에 눈이 멀어 무슨 일이 있었는지에 대한 분석을 진정으로 이해할 수 없기 때문입니다.

추가 사항

최신 인시던트 관리 환경에서는 변화가 유일한 상수입니다. 즉, 시스템은 새롭고 다양한 방식으로 지속적으로 스트레스를 받습니다. 이러한 점을 이해하는 팀은 문제가 '시스템이 과연 실패할까'가 아니라 '언제 실패할까'라는 사실도 알고 있습니다. 실패에 대비하기 위한 조치는 지속적인 성공의 핵심 요소로 인식되어야 하며, 엔지니어링 팀의 DNA에 통합되어야 합니다.

Jira Service Management와 같은 인시던트 관리 솔루션은 대기 일정을 구성하고 알림을 제공하는 것부터 더 나은 협업을 위한 팀 통합과 인시던트 사후 검토 실행에 이르기까지 위와 같은 13가지 각 항목에 도움이 될 것입니다.