Azure의 SaaS 워크로드에 대한 인시던트 관리
SaaS(Software as a Service) 솔루션용 ISV(독립 소프트웨어 공급업체)는 고객을 위해 솔루션을 운영해야 합니다. 이렇게 하려면 예기치 않은 프로덕션 상황을 원활하게 처리하는 조직 설정 및 문화권이 필요합니다. 설계자는 그에 따라 관리 프로세스 및 도구를 디자인해야 합니다.
이 문서에서는 프로덕션 SaaS 솔루션의 인시던트 관리를 지원하기 위해 조직의 문화권, 프로세스 및 도구를 조정하는 방법을 안내합니다.
서비스 공급자로서의 책임 이해
SaaS 솔루션을 운영한다는 것은 고객의 24x7 IT 및 운영 부서임을 의미합니다. 적절한 인력, 문화권, 프로세스 및 도구를 준비해야 합니다.
디자인 고려 사항
24x7x365 지원을 담당합니다. SaaS 솔루션을 운영하려면 조직이 항상 인시던트 대응에 대비해야 합니다. 이 준비에는 업무 시간 외에 인시던트가 발생할 수 있으므로 항상 팀 구성원을 사용할 수 있도록 하는 것이 포함됩니다.
라이브 사이트 지원에 는 시스템 가용성, 보안, 성능 또는 배포에 영향을 주는 인시던트에 대한 실시간 모니터링 및 대응이 포함됩니다. 사용자 또는 고객은 이러한 인시던트 감지할 수 있습니다. 이러한 인시던트 처리에는 압력을 받고 있는 문제를 분석하고 해결하는 기능을 비롯한 특정 기술이 필요합니다.
라이브 사이트 지원은 스트레스가 많을 수 있으며 팀 구성원을 지원하는 것이 중요합니다. 팀이 이 책임을 새로 맡은 경우 신중하게 전환을 계획합니다. 인시던트 중에 대기 중인 의무, 보상 및 사용 불가 관리에 대한 문제를 해결합니다.
위험: 기술 및 기대 관리. 모든 엔지니어가 24x7x365 지원 역할에 적합한 것은 아닙니다. SaaS 솔루션을 지원하도록 기존 팀을 전환할 때 적절한 기대치가 설정되고 교육 기회가 제공되도록 합니다.라이브 사이트 문화를 구축합니다. 지원 사례 및 인시던트 관리 방법 및 에스컬레이션 발생 방법을 고려합니다. 목표는 팀 구성원이 자신의 책임을 이해하고 인시던트 처리에 필요한 기술과 도구를 갖도록 하는 것입니다.
신생 기업 및 소규모 조직에는 라이브 사이트 문제에 대한 간단한 계획이 있을 수 있습니다. 엔지니어는 처음에 고객 지원 사례에 응답하여 최전방 지원 역할을 할 수 있습니다. 성숙한 조직 또는 엔터프라이즈 고객을 사용하는 SaaS 공급자는 보다 구조화된 지원과 전담 팀이 필요합니다.
절충: 운영 우수성 및 비용. 라이브 사이트 이벤트를 관리하면 새 기능 또는 버그 수정에 대한 개발 시간을 방해할 수 있습니다. 개발 속도가 중요한 경우 전용 라이브 사이트 리소스를 고용하는 것이 좋습니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 지원 사례를 처리하기 위한 최전방 팀을 소개합니다. 복잡한 경우 이 팀은 엔지니어링 팀이 조사에 필요한 정보를 수집합니다. 공급업체는 최전방 지원 팀 역할을 하며 초기 문제 분석을 수행하고 간단한 문제를 해결할 수 있습니다. |
인시던트 처리 책임이 있는 엔지니어링 팀에 과부하가 부과되고 정기적인 업무 중단을 처리하지 않습니다. |
| 엔지니어가 복잡한 사례를 처리하고, 조사하고, 조치를 취할 수 있도록 온콜 함수에 투자합니다. 가능하면 각 엔지니어가 한 번에 며칠 동안 호출되는 동안 팀 구성원 간에 호출 시 책임을 회전합니다. |
잘 정의된 책임 및 에스컬레이션 경로를 사용하면 엔지니어링 워크플로를 방해하지 않고 문제를 신속하게 식별하고 해결할 수 있습니다. |
| 인시던트 관리를 위해 특수화된 조달 도구입니다. 모든 응답자가 이러한 도구를 효과적으로 사용하는 방법을 이해하고 액세스할 수 있는지 확인합니다. 시스템 상태를 모니터링하고, 고객이 보고한 문제를 추적하고, 문제를 식별하고, 대기 엔지니어에게 에스컬레이션하고, 응답하지 않는 엔지니어를 관리하고, 프로덕션에서 변경을 수행할 수 있는 도구를 선택합니다. |
올바른 도구를 사용하면 온콜 팀이 보안 및 운영 제어를 유지하면서 인시던트 식별 및 해결에 도움이 됩니다. |
| 모니터링, 배포, 업데이트 및 기타 정기적인 관리 작업을 개선합니다. | 운영 완성도에 투자하면 라이브 사이트 문제의 가능성을 줄일 수 있습니다. 문제가 발생하면 잘 정의된 작업을 배치하면 해결 시간이 단축됩니다. |
응답 계획 정의
인시던트가 불가피하다는 것을 인정하고 인시던트 대응 계획을 정의하여 준비합니다. 이 사전 예방적 접근 방식을 사용하면 첫 번째 인시던트 중에 대응 전략을 고안할 필요가 없습니다.
일반적으로 고객의 서비스 사용 능력에 영향을 주는 주요 인시던트에 대해 미리 계획합니다. 이 준비는 인시던트가 발생할 때 관리할 때 스트레스와 복잡성을 최소화하는 데 도움이 됩니다.
디자인 고려 사항
에스컬레이션 경로를 정의합니다. 팀이 지원 작업에 대한 에스컬레이션 프로세스를 이해해야 합니다. 많은 SaaS 솔루션에서 고객은 일선 지원 팀에 문의한 다음 엔지니어링 팀과 통신합니다. 고객이 누구와 상호 작용해야 하는지, 왜 이러한 프로세스를 우회해서는 안 되는지 알고 있어야 합니다. 또한 엔지니어링 팀이 Microsoft의 지원 팀을 포함하여 공급업체의 도움을 구하는 시기와 방법을 알고 있는지 확인합니다.
심각도 수준을 정의합니다. 인시던트마다 사용자와 고객에게 중요도가 다릅니다. 주요 프로덕션 중단을 처리하는 방법은 사소한 버그를 해결하는 방법과 다릅니다. 고객 영향에 따라 심각도 수준을 정의하고 각 수준에 대한 적절한 기대치 및 타임라인을 설정합니다.
심사에 필요한 문서 정보입니다. 효과적인 인시던트 대응을 위해서는 설명서를 최신 상태로 유지하는 것이 중요합니다. 이 설명서에는 시스템의 아키텍처 레이아웃, 구성 요소 수준 세부 정보, 소유자 및 주요 연락처가 포함됩니다. 부정확하거나 오래된 정보로 인해 인시던트 대응 팀이 시스템 운영, 책임 및 인시던트의 잠재적 영향을 파악하는 데 귀중한 시간을 낭비할 수 있습니다.
고객에게 효과적인 커뮤니케이션을 계획합니다. 상태 업데이트를 제공하는 것이 인시던트 관리의 핵심입니다. 상태 업데이트는 고객이 인시던트 특성을 이해하고 비슷한 문제가 발생하는 고객의 지원 사례 양을 줄이는 데 도움이 됩니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 고객에게 최전방 지원 팀과 지원 사례를 여는 것과 같은 명확한 인시던트 보고 프로세스를 제공합니다. | 인시던트 검색 및 대응 방법의 일관성을 보장하여 해결 시간을 줄이고 정보가 손실되거나 간과되지 않도록 방지합니다. |
| 아키텍처 레이아웃, 구성 요소 수준 세부 정보, 개인 정보 또는 보안 분류, 소유자 및 주요 연락처를 문서화합니다. | 심사 팀은 정보를 쉽게 사용할 수 있으며 조사 및 영향 평가에 집중할 수 있습니다. |
| 인시던트 대응 팀이 로그와 같은 필요한 자산 및 시스템에 액세스할 수 있는지 확인합니다. 또한 안전하고 제어된 프로세스를 통해 프로덕션을 변경할 수 있어야 합니다. | 팀이 시간을 낭비하지 않도록 하여 작업을 더 빠르게 복원할 수 있습니다. |
| 직접 빌드하는 대신 상업용 상태 페이지를 사용합니다. | 상용 상태 페이지를 사용하여 시간을 절약합니다. 다른 조직에서 호스팅하는 상태 페이지도 시스템에서 중단된 동안 고객이 액세스할 수 있습니다. |
체계적으로 인시던트 관리
정의된 계획을 준수하는 것은 응답 시간 동안 즉흥적인 작업을 방지하는 데 중요합니다. 이 방법은 이러한 상황을 관리하는 스트레스와 복잡성을 최소화하는 데 도움이 됩니다.
디자인 고려 사항
인시던트 심각도를 할당합니다. 인시던트 대응 계획을 사용하여 인시던트 심각도를 확인합니다. 고객은 종종 인시던트 중에 좌절합니다. 우선 순위를 지정할 수 있도록 표시되는 영향을 이해하는 것이 중요합니다. 고객이 현실적인 기대를 가질 수 있도록 인시던트의 심각도를 명확하게 전달합니다.
침착하고 명확하게 생각하십시오. 인시던트가 스트레스가 많고 모호할 수 있으며, 여러 이해 관계자가 주의를 기울여야 합니다. 인시던트 내에서 누가 주도권을 잡는지 명확한 프로세스를 갖습니다. 불완전한 정보로 작동해야 할 수 있음을 인정하면서 최대한 인시던트 심사 상황을 계속 제어해 보세요.
조직 리더는 인시던트를 적극적으로 조사하거나 완화하는 팀 구성원을 보호하여 도움을 줄 수 있습니다.
고객에게 상태를 전달합니다. 충분한 정보를 게시하도록 상태 페이지를 업데이트합니다. 즉시 통신하고 예상 해결 시간과 같은 필요한 정보를 제공합니다. 고객에게 자주 업데이트를 제공하여 신뢰를 유지합니다.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 인시던트 중에는 검색보다 복구 우선 순위를 지정합니다. 인시던트가 발생하면 신속하게 복원 작업의 우선 순위를 지정하여 고객의 중단을 최소화합니다. |
문제의 원인을 아직 이해하지 못하더라도 영향을 받는 구성 요소 주위에 라우팅하거나 업데이트를 롤백하여 복구할 수 있습니다. |
| 가동 중단 시 시기적, 명확하고 빈번한 업데이트를 제공합니다. | 고객 신뢰를 심어주고 최전방 지원 팀의 부담을 줄일 수 있습니다. |
| 활성 인시던트 중에 통신 관리자를 지정합니다. 이 관리자는 한 사람이거나 인시던트 간에 팀 구성원 간에 책임을 회전할 수 있습니다. | 엔지니어링 팀에 대해 하나의 음성을 사용하여 대화를 중앙 집중화하고 다른 팀 구성원의 방해를 줄입니다. 또한 혼란스러운 인시던트 중에 충돌하는 정보가 고객 또는 이해 관계자에게 도달하는 것을 방지합니다. |
| Microsoft와 같은 공급업체에 대한 중요 업무용 지원 계획이 있는지 확인합니다. | 중단이 발생하는 경우 Microsoft와 같은 플랫폼 공급업체와의 응답 통신을 통해 문제가 있는 위치를 파악하고 중단 기간을 단축해야 합니다. |
인시던트 후 검토 수행
인시던트에서 복구한 후에는 발생한 내용을 검토하고 분석하여 인시던트를 알아봅니다. 기술 변경, 프로세스 조정 또는 더 많은 교육을 포함할 수 있는 수정 작업을 구현합니다.
디자인 고려 사항
인시던트에서 알아봅니다. 중단은 귀중한 학습 기회를 제공합니다. 인시던트 후 철저한 검토를 수행하여 교훈을 식별하고 개선 사항을 구현합니다. 주요 인시던트에는 여러 원인이 있는 경우가 많습니다. 운영 프로세스와 같은 솔루션의 다른 계층이 문제를 에스컬레이션하기 전에 방지하거나 감지할 수 있는지 여부를 평가합니다. 또한 동일한 문제의 위험이 있을 수 있는 솔루션의 다른 위치에서도 유사한 패턴을 찾습니다.
고객과 통신합니다. 많은 ISV는 특히 고품질 업데이트를 기대하는 엔터프라이즈 고객을 위해 인시던트 후 통신을 제공합니다. 고객이 문제 및 완화 단계를 이해할 수 있도록 투명하고 충분한 정보를 제공합니다. 그러나 보안 및 무결성을 유지하려면 솔루션 아키텍처 또는 구성 요소에 대한 과도한 내부 세부 정보를 공유하지 마세요.
디자인 권장 사항
| 추천 | 장점 |
|---|---|
| 내부 인시던트 후 검토를 수행하는 프로세스를 만듭니다. 문제에 기여한 이유를 파악하는 데 집중합니다. 기술적 원인, 프로세스가 중단에 기여한 방법 및 인시던트에 대응하는 방법을 고려합니다. |
내부 인시던트 후 검토는 프로덕션 중단에서 학습하고 유사한 문제가 다시 발생할 위험을 최소화하는 데 도움이 됩니다. |
| 수정이 필요한 모든 항목을 해결하기 위해 구조화된 계획을 수립합니다. 명확한 책임과 타임라인을 포함합니다. | 명확한 책임은 각 역할이 기능적 기대치를 충족하고, 명확성을 향상시키며, 원하는 수준에서 투명한 보고를 가능하게 하는 데 도움이 됩니다. |
| 고객 관련 인시던트 후 검토를 게시합니다. 불필요한 내부 세부 정보 또는 시스템 아키텍처를 공개하지 않고도 고객에게 문제 및 완화 단계를 이해할 수 있는 충분한 세부 정보를 제공합니다. 인시던트 후 통신은 항상 인간이 작성하고 게시해야 합니다. 기술 및 비기술 관련자는 정확성과 명확성을 위해 통신을 검토해야 합니다. |
이 방법은 고객의 신뢰를 유지하고 인시던트에서 학습하고 식별된 문제를 해결하도록 보장합니다. |
다음 단계
디자인 영역을 검토한 후 평가 도구로 이동하여 디자인을 평가합니다.