현재 Microsoft Azure에 장애가 있나요?

Microsoft Azure 가용성 이해하기

Microsoft Azure는 여러 리전, subscription, resource 유형, identity 시스템 및 관리 인터페이스에 분산된 cloud service 모음입니다. 하나의 Azure service 또는 리전에 영향을 미치는 incident가 모든 Azure workload를 사용할 수 없게 만든다는 의미는 아닙니다.

여러 관련 없는 Azure resource에서 장애가 발생하거나, 문제가 갑자기 시작되었거나, 여러 network에서 동일한 operation이 실패한다면 먼저 Azure 공식 status page를 확인하세요. 게시된 incident가 영향을 받은 service, 리전 및 시간과 일치하는지 비교하세요. 일치하는 incident가 없다면 개별 resource, deployment, identity configuration, quota, DNS 경로, private endpoint 또는 application을 계속 조사하세요.

API 및 application 장애의 경우 HTTP status, 전체 response, Azure service, 리전, resource identifier, operation, timestamp, request 또는 correlation ID를 보존하세요. 이러한 정보는 platform incident와 authentication, authorization, deployment, DNS, timeout 및 application 문제를 구분하는 데 도움이 됩니다.

Microsoft Azure 문제 해결

1. 문제가 광범위한 Azure incident인지 확인

Azure 공식 status page를 열고 영향을 받은 service, 리전 및 시간과 일치하는 event를 찾으세요. 서로 관련 없는 resource 또는 operation이 동시에 실패하고 다른 network에서도 동일한 동작이 나타난다면 광범위한 incident일 가능성이 높습니다. 활성 incident 중에는 오류 세부 정보를 보존하고, 반복적이거나 파괴적인 변경을 수행하기보다 게시된 업데이트를 따르세요.

2. 하나의 resource 또는 workload가 실패하는 경우

resource의 현재 상태, 최근 configuration 변경 사항, deployment 기록, dependency 및 service별 log를 확인하세요. 해당되는 경우 요청이 의도한 subscription, resource group, 리전, endpoint 및 API version을 대상으로 하는지 확인하세요. 하나의 resource만 실패한다면 global Azure outage보다는 deployment, application, permission, quota 또는 configuration 문제일 가능성이 높습니다.

3. 로그인 실패와 authorization 실패 구분

portal 또는 API authentication 문제라면 사용 중인 tenant, subscription, account, service principal, managed identity, token 및 role assignment를 확인하세요. 일반적으로 401 response는 authentication 또는 token 문제를 의미하고, 403 response는 identity가 인증되었지만 필요한 permission이 없음을 의미합니다. 진단 보고서에 credential, access token 또는 secret을 포함하지 마세요.

4. 브라우저 및 Azure management interface 확인

문제가 브라우저에서만 발생한다면 private window 또는 다른 지원 브라우저를 사용해 보세요. 오래된 session, 차단된 cookie, extension 및 cache된 application data를 확인하세요. 가능하다면 portal을 underlying resource endpoint 또는 권한이 있는 command-line이나 API operation과 비교하세요. 다른 환경에서는 resource가 정상 작동한다면 브라우저 session 또는 management interface가 원인일 가능성이 높습니다.

5. network, DNS 및 TLS 장애 조사

timeout, connection 거부, name-resolution 실패 또는 certificate 오류가 발생한다면 두 번째 network에서 테스트하고 실제로 사용 중인 정확한 hostname을 resolve하세요. corporate proxy, firewall, VPN, private endpoint, routing, DNS 및 TLS inspection 설정을 검토하세요. public access는 작동하지만 private 또는 corporate network에서는 작동하지 않는다면 Azure resource를 변경하기 전에 해당 network 경로를 조사하세요.

6. API 및 deployment 실패 조사

전체 response body, HTTP status, operation name, timestamp, 리전 및 request 또는 correlation ID를 보관하세요. 일시적인 5xx response와 4xx authentication, authorization, validation, quota 또는 configuration response를 다르게 처리하세요. operation을 반복해도 안전한 경우에만 적절한 backoff를 사용해 retry하세요. 모든 실패한 request가 Azure outage를 의미하는 것은 아닙니다.