안정성 테스트 전략을 설계하기 위한 아키텍처 전략

Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:08 비정상 상황 엔지니어링의 원칙을 적용하여 복원력 및 가용성 시나리오를 테스트합니다. 안정성 테스트를 사용하여 워크로드가 오류를 견딜 수 있는지 확인하고, 수요에 따라 크기를 조정하고, 정의된 대상 내에서 복구할 수 있는지 확인합니다.

안정성 테스트는 중단을 일으키기 전에 아키텍처 약점을 파악합니다. 오류 시나리오에 대해 의도적으로 테스트하지 않으면 복원력 패턴이 실제로 작동하는지 또는 워크로드가 정의된 대상 내에서 복구되는지 여부를 알 수 없습니다.

가용성에 영향을 주는 보안 위험, 시스템을 사용할 수 없게 만드는 성능 문제 및 인시던트 대응을 제한하는 운영 격차를 테스트할 때 워크로드의 안정성을 강화합니다. 이 문서의 전략을 사용하여 오류 모드에 대해 워크로드의 유효성을 정기적으로 검사하는 테스트 주기를 설정합니다. 아키텍처가 변경되고 인시던트가 새로운 약점을 드러낼 때 테스트를 진화합니다. 시간이 지남에 따라 안정성 상태를 강화하는 피드백 루프를 만들면서 워크로드가 오류를 견딜 수 있고, 수요를 충족하도록 크기를 조정하고, RTO 및 RPO 목표 내에서 복구할 수 있다는 확신을 쌓습니다.

이 문서의 주요 전략은 테스트를 위한 OE:09 아키텍처 전략에 설명된 기본 테스트 사례를 기반으로 합니다. 먼저 해당 문서를 검토합니다. 이 가이드의 권장 사항은 안정성으로 범위가 지정되며, 워크로드가 오류를 견딜 수 있고 대상 내에서 복구할 수 있는 능력에 대한 확신을 달성하는 데 중점을 줍니다.

다음 표에서는 이 문서 전체에서 사용되는 주요 안정성 용어를 정의합니다.

정의

기간 Definition
Availability 상당한 가동 중지 시간 없이 애플리케이션 워크로드가 정상 상태로 실행되는 시간입니다.
카오스 엔지니어링 시스템 복원력을 지속적으로 향상하기 위해 비정상 상황 테스트를 팀 문화, 엔지니어링 사례 및 개발 수명 주기에 안전하게 통합하는 방법입니다.
카오스 테스팅 중단 조건에서 워크로드가 작동하는 방식에 대한 특정 복원력 가설의 유효성을 검사하는 제어된 실험입니다.
결함 주입 구성 요소, 종속성 또는 시스템 경로에 오류를 의도적으로 도입하는 기술입니다.
복구 가능성 RTO(합의된 복구 시간) 및 RPO(복구 지점) 대상 내에서 중단된 후 정상 작업을 복원하는 기능입니다.
Resiliency 일시적인 오류, 인프라 중단, 수요 급증과 같은 오류를 견딜 수 있는 워크로드의 기능은 허용 가능한 사용자 환경 내에서 계속 작동합니다.
장애 조치 (페일오버) 주 구성 요소가 실패할 때 보조 구성 요소로 전환하는 프로세스입니다.
Failback 복구된 후 주 지역에서 작업을 복원하는 프로세스입니다.
오류 예산 SLO(서비스 수준 목표)에서 파생된 정의된 기간 동안 시스템에 허용되는 최대 오류 수준입니다.

서비스 유형에 따라 안정성 테스트 범위 정의

안정성 테스트의 범위를 정의할 때 사용하는 서비스의 공유 책임 모델을 고려합니다. 각 서비스 유형(IaaS, PaaS, SaaS)에는 다양한 안정성 보장 및 오류 처리에 대한 다양한 수준의 제어가 제공됩니다. 자신이 담당하는 신뢰성 측면에 테스트를 집중하세요.

  • 테스트 깊이를 사용자의 책임과 일치시킬 수 있습니다. IaaS(인프라 서비스)의 경우 팀은 대부분의 안정성 결정을 소유하므로 비정상 상황 엔지니어링 및 오류 주입을 통해 철저한 유효성 검사에 투자합니다. PaaS(플랫폼) 및 SaaS(소프트웨어) 서비스의 경우 공급자는 기본 안정성의 대부분을 관리합니다. 워크로드가 PaaS에서 인프라 장애 조치(failover)를 처리하는 방법, 제한, 서비스 성능 저하 또는 부하 패턴의 변경과 같은 이러한 서비스와 상호 작용하는 방법에 중점을 줍니다.

  • 혼합 서비스 워크로드를 고려합니다. 워크로드가 여러 서비스 유형에 걸쳐 있는 경우 테스트 책임은 구성 요소마다 다릅니다. 가용성 영역 장애 발생 시 VM 기반 인프라 구성 요소의 장애 조치(failover)는 테스트할 수 있지만, 고가용성을 위해 설계된 PaaS 데이터베이스의 경우에는 공급자의 보장에 의존할 수 있습니다. 이러한 경계가 어디에 있는지 확인하고 테스트가 둘 사이의 간격을 커버하는지 확인합니다.

신뢰성 목표에 대해 엔드투엔드로 테스트하세요

SLO, RTO 및 RPO와 같은 안정성 대상은 오류 조건에서 워크로드가 작동하는 방식을 정의합니다. 개별 구성 요소뿐만 아니라 전체 중요 흐름에서 통과 및 실패 조건으로 사용합니다.

  • 전체 흐름에서 복구의 유효성을 검사합니다. 단일 구성 요소는 RTO 내에서 복원될 수 있지만 다운스트림 종속성도 복원해야 하는 경우 전체 복구 시간이 대상을 초과할 수 있습니다. 문제를 감지하고 응답하는 시간을 포함하여 전체 흐름의 총 복구 시간을 고려합니다.

  • SLO 및 오류 예산으로 테스트 범위를 정의합니다. 오류 예산은 오류 주입에 투입할 수 있는 투자 규모를 의미합니다. 비정상 상황 테스트를 제한하여 SLO 내에 유지하고 흐름 복구 대상을 사용하여 각 테스트의 경계를 정의합니다.

중요한 흐름 및 오류 모드에서 안정성 시나리오 빌드

워크로드의 중요한 흐름과 해당 흐름에 영향을 줄 수 있는 실패 모드로 시작합니다. 오류 모드 분석을 사용하여 가장 영향력 있는 오류 시나리오를 식별하고 복원력 및 복구 전략의 유효성을 검사하는 테스트를 빌드합니다.

영향 및 가능성에 따라 우선 순위를 지정합니다. 모든 실패 모드가 동일한 테스트 투자를 보증하는 것은 아닙니다. 가장 높은 잠재적인 사용자 영향과 발생할 가능성이 가장 높은 시나리오에 먼저 집중합니다. 오류 모드 분석을 통해 이 우선 순위를 지정합니다.

내결함성 및 복구 메커니즘의 유효성 검사

가동 중지 시간을 발생하거나 사용자 환경을 저하시킬 가능성이 가장 큰 시나리오에 초점을 맞춥니다. 이 섹션의 전략을 사용하여 오류를 처리하고 효과적으로 복구하는 워크로드의 기능을 검증하는 테스트를 빌드합니다.

백업 및 복원

백업 및 복원 테스트는 데이터 보호 방법이 복구 목표를 충족하는지 확인해야 합니다.

  • 테스트 주기를 설정합니다. 백업 구성, 데이터 스키마 또는 인프라 변경 빈도에 따라 복원을 테스트해야 하는 빈도를 결정합니다. 자주 변경하려면 복원 테스트가 더 자주 필요합니다.

  • 복구 대상을 설정합니다. RPO 및 RTO 대상에 대한 실제 복원 시간을 측정하여 백업 전략이 복구 목표를 충족하는지 확인합니다.

  • 백업 완전성을 가정하지 마세요. 데이터의 하위 집합만 캡처하도록 백업을 잘못 구성할 수 있습니다. 복원 작업의 성공 여부뿐만 아니라 데이터 무결성 및 완전성의 유효성을 검사합니다.

  • 격리된 상태로 테스트합니다. 프로덕션과는 별도로 환경에서 복원의 유효성을 검사하여 라이브 워크로드를 중단하지 않고 철저한 검사를 실행할 수 있습니다.

일시적인 오류

일시적인 네트워크 중단, 간략한 서비스 사용 불가 및 연결 시간 제한과 같은 일시적인 오류는 일반적인 안정성 위험입니다. 워크로드가 사용자에게 영향을 주지 않고 이러한 오류를 처리하는지 확인합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.

  • 소유한 항목에 집중합니다. SDK 또는 플랫폼 서비스가 재시도 및 회로 중단을 자동으로 처리하는 경우 모든 재시도 실패 또는 회로 차단기가 열리는 경우와 같이 기본 제공 메커니즘이 소진될 때 발생하는 작업을 테스트합니다.

  • 오류 처리 구성의 유효성을 검사합니다. 워크로드의 오류 처리 구성을 평가합니다. 재시도 정책, 회로 차단기 임계값 및 시간 제한 값이 현실적인 오류 조건에서 예상대로 작동하는지 확인합니다.

  • 일시적 오류와 영구 오류 사이의 경계를 테스트합니다. 실패가 예상 임계값을 넘어서까지 지속될 때 워크로드가 재시도 동작에서 폴백 또는 저하 상태로 원활하게 전환되는지 검증하세요.

  • 복원력 기능의 일시적인 오류를 고려합니다. 영역 중복성 및 유사한 디자인은 일반적인 장애 조치(failover) 작업 중에 일시적인 오류를 생성하는 경우가 많습니다. 예를 들어 영역 중복 데이터베이스는 중단 중에 트래픽이 정상 영역으로 이동함에 따라 일시적인 연결 오류를 일으킬 수 있습니다. 워크로드가 사용자에게 큰 영향을 주지 않고 이러한 예상 일시적인 오류를 처리할 수 있는지 테스트합니다.

부하 및 확장 응답

워크로드가 급격한 급증과 점진적인 증가 모두에서 수요 변경 시 안정성을 유지하는지 확인합니다. 자세한 내용은 크기 조정 전략을 참조하세요. 부하 및 스트레스 테스트 지침은 테스트 권장 사항을 참조하세요.

  • 스케일 아웃 및 스케일 인을 모두 테스트합니다. 새 용량이 충분히 빠르게 온라인 상태가 되며 크기 조정이 요청을 삭제하거나 분리된 리소스를 남기지 않는지 확인합니다.

  • 스케일링 지연을 고려하세요. 크기 조정을 트리거하는 조건 충족과 새 용량 준비 사이에는 항상 지연이 있습니다. 워크로드가 해당 간격 동안 수요를 처리할 수 있는지 또는 추가 용량을 미리 프로비전해야 하는지 여부를 결정합니다.

종속성 오류

워크로드는 타사 API, 관리형 플랫폼 서비스 또는 공유 내부 서비스와 같이 직접 제어할 수 없는 서비스에 따라 달라질 수 있습니다. 워크로드가 사용자에게 상당한 중단 없이 해당 종속성에서 오류를 처리하는지 확인합니다.

  • 중요도별로 종속성을 분류합니다. 모든 종속성이 동일한 테스트 투자를 보증하는 것은 아닙니다. 중요한 흐름에 있고 기본 제공 중복성 또는 대체 경로가 없는 종속성에 대한 테스트의 우선 순위를 지정합니다.

  • 각 종속성에 대한 대체 동작을 테스트합니다. 종속성을 사용할 수 없게 되면 워크로드가 완전히 실패하지 않고 대체 경로 또는 동작으로 대체되어야 합니다. 각 대체 기능이 올바르게 활성화되고 관련 없는 기능이 계속 작동하는지 확인합니다.

  • 부분 및 연속 실패를 고려합니다. 종속성은 이진 방식으로 거의 실패하지 않습니다. 전체 중단만 테스트하지 마세요. 대기 시간 증가, 일시적 오류, 그리고 부분적인 데이터 가용성을 포함합니다.

  • 격리와 영향 범위 제한을 검증합니다. 단일 종속성 오류가 관련 없는 기능과 연계되지 않는지 확인합니다.

자기 보존 및 복구

전체 복구가 즉시 수행되지 않을 때 워크로드가 감소된 용량에서 계속 작동할 수 있는지 여부를 포함하여 자체 복구 및 자기 보존 디자인 이 오작동에 어떻게 대응하는지 확인합니다.

  • 자동화된 복구 엔드 투 엔드를 테스트합니다. 상태 모델을 평가하여 올바른 검사를 포함하는지 확인합니다. 이러한 검사가 오류를 정확하게 감지하고, 예상대로 자동화된 수정을 트리거하고, 시스템을 허용 가능한 기간 내에 정상 상태로 되돌리는지 확인합니다.

  • 수동 복구 절차서를 검증하세요. 자동화된 복구는 모든 시나리오를 다루지 않습니다. 실제 조건에서 수동 Runbook을 테스트하여 운영자가 압력을 받고 복구 시간 목표 내에서 실행할 수 있는지 확인합니다.

  • 점진적 성능 저하 동작을 검증합니다. 구성 요소에 장애가 발생하면 워크로드는 완전히 중단되지 않고 성능이나 기능이 일부 저하된 상태로 계속 실행되어야 합니다. 예를 들어 수동 검토를 위해 요청을 대기열에 넣는 것과 같은 제한된 모드로 운영할 수 있는지, 그리고 저하된 사용자 경험이 사용자에게 허용 가능한지 테스트합니다. 팀에서 이 상태에서 워크로드를 운영하는 방법과 전체 기능을 복원하는 방법을 알고 있는지 확인합니다.

DR(인시던트 및 재해 복구)

인시던트 또는 재해가 발생하면 신속하게 감지하고 효과적으로 대응하는 기능이 중요합니다. 계획 및 프로세스를 테스트하여 치명적인 오류 및 주요 인시던트 문제를 해결하는지 확인합니다. DR 테스트에 전용 환경을 사용하여 프로덕션 워크로드에 영향을 주지 않도록 합니다. 자세한 내용은 재해 복구 계획을 참조하세요.

  • 인시던트 검색 메커니즘의 유효성을 검사합니다. 인시던트 시뮬레이션을 통해 모니터링 로그가 필요한 정보를 캡처하고 경고가 적절하게 트리거되는지 확인합니다. 예를 들어 증가된 요청 실패율이 감지되는 속도와 모니터링 데이터가 샘플링되는 빈도를 테스트합니다.

  • 인시던트 관리 프로세스를 테스트합니다. 팀이 인시던트 대응 절차를 효과적으로 따를 수 있도록 합니다. 자세한 내용은 인시던트 응답을 참조하세요.

  • 전체 장애 조치(failover) 및 장애 복구(failback)를 테스트합니다. 격리된 개별 조각을 테스트하면 실제 전환 중에만 나타나는 조정 실패를 놓칠 수 있습니다. DNS 전환, 백업 및 데이터 복제 일관성 복원, 클라이언트 다시 연결을 비롯한 전체 장애 조치(failover) 시퀀스의 유효성을 검사합니다. 또한 초기 전환보다 더 복잡한 기본 배포에 대한 장애 복구(failback)를 테스트합니다.

  • 장애 조치 환경에서 용량을 검증합니다. 장애 조치(failover) 환경에 사전에 프로비저닝된 용량이 충분히 확보되어 있어, 장애 조치 직후 즉시 트래픽을 처리하고도 부하로 인해 시스템이 무너지지 않는지 확인합니다. 크기 조정 메커니즘을 활성화하고 크기 조정 접근 방식의 유효성을 검사하는 동안 환경이 작업을 유지할 수 있음을 테스트합니다. 자세한 내용은 로드 및 크기 조정 응답을 참조하세요.

  • 목표와 비교하여 측정합니다. DR 테스트가 RTO 또는 RPO를 충족하지 않는 경우 간격을 분석하고 그에 따라 DR 계획을 업데이트합니다.

  • 사용자 및 프로세스의 유효성을 검사합니다. DR 테스트는 통신 채널을 확인하고, 운영자가 복구 절차를 실행하는 데 필요한 액세스 및 권한이 있는지 확인하고, 압력을 받고 있는 DR 관련 Runbook을 신속하게 찾을 수 있는지 확인해야 합니다.

테이블탑 훈련을 통해 계획을 테스트하고 평가하세요

테이블탑 훈련은 실제 인시던트가 그 허점을 드러내기 전에 안정성 테스트의 미비점을 발견하는 데 도움이 됩니다. 팀과 함께 실패 시나리오를 시뮬레이션하여 테스트되지 않은 조건을 식별하고 응답 프로시저가 예상대로 작동하는지 확인할 수 있습니다.

  • 실제 인시던트 시뮬레이션 지역 가동 중단 또는 손상된 배포와 같은 실패 시나리오를 살펴보고 팀에서 이를 감지, 대응 및 복구하기 위해 수행하는 단계를 설명하도록 합니다. 이러한 논의는 종종 테스트를 통해 유효성을 검사하지 않은 시스템 동작에 대한 가정을 표시합니다.

  • 결과를 테스트 사례로 전환합니다. 연습 중에 나타나는 간격과 미지의 값을 사용하여 새로운 안정성 테스트를 만듭니다. 팀에서 특정 종속성이 실패할 때 워크로드가 어떻게 작동하는지 아무도 모르는 경우 테스트 전략에 추가하는 시나리오입니다.

계획된 중단과 계획되지 않은 중단을 활용

계획된 유지 관리 또는 계획되지 않은 중단으로 인해 워크로드가 오프라인 상태인 경우 테스트를 수행하고 워크로드에 대한 이해를 향상시킬 수 있는 고유한 기회가 있습니다.

계획된 유지 보수

업데이트 또는 패치에 대한 유지 관리 기간 동안 유지 관리 작업에 포함되지 않은 구성 요소 및 흐름을 테스트합니다. 예기치 않게 워크로드를 저하하거나 오프라인으로 전환할 위험 없이 테스트를 실행할 수 있습니다. 충분한 시간이 있는 경우 작업이 완료된 후 유지 관리와 관련된 구성 요소도 테스트합니다.

계획되지 않은 중단

계획되지 않은 모든 중단은 안정성 테스트 전략을 강화할 수 있는 기회입니다. 서비스를 복원하고 인시던트 후 검토를 완료한 후 결과를 사용하여 테스트를 개선합니다.

  • 완화 조치를 테스트합니다. 해결 방법 또는 임시 수정을 적용한 경우 영구 수정이 적용되기 전에 예상 부하를 처리할 수 있는지 확인합니다.

  • 유사한 약점을 검색합니다. 중단에 기여한 동일한 구성 또는 디자인 패턴에 대해 다른 구성 요소를 검토합니다. 동일한 방식으로 실패하기 전에 해당 구성 요소에 대한 테스트를 추가합니다.

다양한 유형의 테스트 결합

서로 다른 유형의 테스트를 함께 실행하는 경우 각 테스트가 격리된 상태로 실행되면 표시되지 않는 안정성 문제를 표시할 수 있습니다. 워크로드는 정상적인 조건에서는 특정 부하를 처리할 수 있지만, 장애를 주입하면 동일한 부하에서도 실패가 발생할 수 있습니다.

  • 기존 테스트 인프라를 다시 사용합니다. 부하 테스트를 위한 인프라 및 테스트 도구가 이미 있는 경우 이를 사용하여 비정상 상황 테스트를 동시에 실행합니다. 동일한 테스트 실행에서 부하 및 오류 주입을 결합하면 수요와 오류가 동시에 발생하는 현실적인 조건에서 워크로드가 작동하는 방식을 보여 줍니다.

  • 비프로덕션 환경에서 시작합니다. 오류 모드를 안전하게 탐색할 수 있는 위험 수준이 낮은 환경에서 안정성 테스트를 시작합니다. 비프로덕션 환경에서 인사이트를 소진하고 폭발 반경을 제한하고 신속하게 롤백할 수 있는 안전 장치를 마련한 후에만 프로덕션 테스트로 이동합니다.

오류 주입과 카오스 엔지니어링을 활용하세요

오류 주입 및 비정상 상황 엔지니어링은 의도적으로 오류를 도입하고 응답을 관찰하여 워크로드의 복원력에 대한 신뢰를 구축하는 데 도움이 됩니다. 실험을 실행하기 전에 완화 전략을 마련해야 합니다.

  • 정기적으로 비정상 상황 실험을 실행합니다. 테스트 범위를 평가합니다. 신뢰할 수 있다고 가정하는 구성 요소 및 흐름에 오류를 삽입합니다. 아키텍처가 변경되면 새로운 실패 모드가 나타나고 이전 가정이 더 이상 유지되지 않을 수 있습니다. 정기적으로 실험을 실행하여 회귀를 catch하고, 새 종속성을 확인하고, 최근 변경 내용이 약점을 도입하지 않았는지 확인합니다.

  • 실패 모드 분석을 사용하여 실험에 초점을 맞춥니다. 각 실험은 특정 오류 또는 오류 집합을 대상으로 하고 특정 구성 요소의 손실을 견딜 수 있는 지정된 흐름의 기능을 테스트하는 것과 같은 명확한 가설을 가져야 합니다. 실험에서 새 실패 모드 또는 발견되지 않은 종속성이 표시되면 오류 모드 분석을 업데이트하여 최신 상태로 유지합니다.

  • 실험 중 영향 범위를 제한합니다. 대상 구성 요소는 신속하게 복구하고 각 오류 주입의 효과에 대한 정보에 입각한 기대치를 설정할 수 있습니다. 실험이 범위를 벗어나거나 예기치 않은 결과를 생성하는 경우 중지합니다. 사용자에게 미치는 영향을 최소화하여 의미 있는 데이터 수집의 균형을 조정합니다.

  • 기준선을 기준으로 측정합니다. 각 실험의 흐름 및 구성 요소에 대한 일관된 안정성 및 성능 메트릭을 설정합니다. 성능이 저하된 상태 메트릭을 이러한 기준과 비교하여 오류의 전체 효과를 이해하고 복원력 디자인이 대상을 충족하는지 여부를 확인합니다.

  • 결과를 테스트 전략에 다시 공급합니다. 실험 결과를 사용하여 새 테스트를 추진하고, 복구 계획을 업데이트하고, 수정 백로그 항목을 알립니다. 예기치 않은 동작이 발생하면 해당 동작에 대한 대상 테스트를 만들고 수정 전략을 설계합니다.

트레이드오프: 프로덕션 환경에서의 오류 주입 테스트는 서비스에 영향을 줄 수 있으며 다운타임을 초래할 수 있습니다. 이 가능성에 대해 이해 관계자와 투명하게 설명합니다. 실험을 중지하고 신속하게 롤백할 수 있도록 안전 장치를 마련하고, 중요한 기간 동안 테스트를 실행하거나 피해야 하는 시기를 유연하게 유지할 수 있습니다. 의도하지 않은 중단을 방지하려면 충분한 중복성을 계획하고 이해 관계자가 비용 절충을 이해하도록 합니다.

위험: 안정성 테스트는 여러 오류 모드에서 적용 범위를 확장할 수 있지만 더 이상 의미 있는 값을 제공하지 않으면 중지해야 합니다. 알려진 안정성 문제의 백로그가 이미 있는 경우 더 많은 테스트를 추가하는 대신 해당 문제 해결의 우선 순위를 지정합니다.

Azure 지원

Azure Test Plans 는 계획된 수동 테스트, 사용자 승인 테스트, 예비 테스트 및 관련자의 피드백 수집에 필요한 모든 기능을 제공하는 브라우저 기반 테스트 관리 솔루션입니다.

Azure Chaos Studio는 클라우드 애플리케이션 및 서비스 복원력을 측정, 이해 및 개선하는 데 도움이 되는 비정상 상황 테스트를 사용하는 관리형 서비스입니다.

Azure 앱 테스트는 Azure Load Testing 사용하여 극작가 작업 공간 및 성능 테스트를 사용하여 기능 테스트를 실행하여 애플리케이션의 문제를 식별할 수 있는 서비스입니다.

Azure Service Health Azure 포털의 전용 섹션인 계획된 유지 관리 창이 있어 향후 유지 관리 활동에 대한 정보를 제공합니다. Azure 리소스에 영향을 줄 수 있는 이벤트를 강조 표시하여 미리 준비하는 데 도움이 됩니다.

연결 모니터 는 Azure 및 하이브리드 환경 모두에서 네트워크 연결의 가상 모니터링 및 실시간 테스트에 사용할 수 있는 Azure Network Watcher 의 기능입니다. 비정상 상황 엔지니어링 시나리오에서 연결 모니터를 사용하여 대상 네트워크 구성 요소에 오류를 삽입하고 대기 시간 및 패킷 손실과 같은 주요 메트릭을 지속적으로 측정할 수 있습니다. 이 기능을 통해 팀은 개별 흐름 구성 요소와 엔드 투 엔드 네트워크 경로 모두에서 중단이 네트워크 안정성에 미치는 영향을 관찰할 수 있습니다. 오류의 영향을 평가하고 개선할 영역을 식별하려면 연결 모니터 원격 분석을 기준 메트릭과 비교합니다.

안정성 검사 목록

전체 권장 사항 세트를 참조하세요.