요약

  • 마이크로소프트는 Azure DNS 가용성 영향 시기를 2021년 4월 1일 21:21~22:00 UTC로 명시했으나, 독립 신지식(synthetic) 모니터링은 21:20에 DNS 알람을 기록했습니다. 복구 속도는 서비스별로 달랐고, 마이크로소프트는 대부분의 영향 서비스가 22:30 UTC까지 복구되었다고 밝혔습니다.
  • 마이크로소프트는 이 사건을 특정 코드 결함을 드러내고 DNS 엣지 캐시 효율을 떨어뜨린 비정상적인 전역 DNS 질의 급증 탓으로 돌렸습니다. Azure DNS에 과부하가 걸렸고, 클라이언트 재시도가 정상적으로 보이는 부하를 더해 용량 방어 계층이 이를 폐기하지 않음으로써 이름 확인(name resolution) 가용성이 더 저하되었습니다.
  • 책임이 닿는 통제 표면은 가동 중인 DNS 시스템입니다: 압박 상황에서의 캐시 동작, 재시도를 인지하는 과부하 방어, 독립적인 상태 가시성, 경계 지어진 장애 범위, 회복의 증거. 공개 기록은 트래픽의 출처나 의도, 표적 도메인, 내부 로그, 개인별 책임, 완전한 손실 규모, 법적 귀책, 후속 조치 전부의 검증된 완료 여부를 확립하지 않습니다.

40분간의 DNS 장애, 이후 고르지 않은 서비스 복구

마이크로소프트가 명시한 장애 구간은 2021년 4월 1일 21:21 UTC에 시작되었습니다. 1분 전, Exoprise의 신지식 모니터링이 DNS 알람을 발생시켰습니다. 이 1분 차이를 매끈하게 지워야 할 모순은 아닙니다. Exoprise는 자체 외부 관측 지점에서 측정했고, 마이크로소프트는 운영자 입장의 장애 구간을 정의했습니다. 두 시각이 거의 일치한다는 사실은 오히려 이름 확인 장애가 운영자가 명시한 시작 시점과 사실상 같은 때 외부에서도 관측 가능해졌음을 보여줍니다.

마이크로소프트는 Azure DNS가 22:00 UTC까지 자동으로 복구되었다고 밝혔습니다. 그러나 이 복구가 모든 의존 서비스를 같은 순간에 정상으로 만든 것은 아니었습니다. 복구는 서비스마다 달랐고, 마이크로소프트는 대부분의 영향 서비스가 22:30 UTC까지 복구되었다고 했습니다. DNS가 다시 응답하는 동안 애플리케이션, 관리 포털, 세션, 대기 작업은 각자의 복구 경로를 거쳐야 합니다. 따라서 유용한 장애 보고는 이름 확인 계층의 복원과 그에 의존하는 모든 것의 회복을 구분해야 합니다.

증상은 광범위했지만 균일하지 않았습니다. 당시 보도는 Azure 자원에 접근하거나 관리하려 할 때 겪는 문제, Teams를 포함한 Microsoft 365 서비스 전반과 다른 마이크로소프트 제품군의 장애를 다루었습니다. Exoprise는 신지식 모니터링에서 하위 서비스 실패를 관측했습니다. Reuters는 서비스가 이후 정상 상태로 돌아왔다고 보도하면서 Teams에 대한 Downdetector 접수 건이 8,000건을 넘었다고 인용했습니다. 이 숫자는 한 플랫폼에 접수된 신고 수이지, 영향받은 사용자·고객·거래의 전수 조사가 아닙니다.

지리적 범위도 같은 절제를 요구합니다. 마이크로소프트는 여러 리전에 걸친 영향을 언급했습니다. 이는 분산형 연속성 사건을 뒷받침하지만, 모든 리전·리졸버·고객·도메인·제품이 같은 방식으로, 같은 구간 전체에 걸쳐 장애를 겪었다는 증명은 아닙니다. DNS 동작은 캐시 상태, 리졸버 선택, TTL, 재시도 정책, 특정 순간 사용자가 필요로 하는 이름에 따라 달라집니다. 따라서 같은 서비스의 두 사용자가 서로 다른 결과를 겪을 수 있으며, 어느 한쪽 관측이 틀린 것은 아닙니다.

이러한 변동성은 DNS 장애를 의외로 전달하기 어렵게 만듭니다. 필요한 응답이 캐시에 남아 있는 곳에서는 서비스가 건강해 보이지만, 다시 질의해야 하는 곳에서는 이용할 수 없을 수 있습니다. 기존 세션은 유지되는 동안 관리 기능이 실패할 수 있습니다. 공개 대시보드가 부분 복구를 보여주는 동안 의존성은 여전히 타임아웃될 수 있습니다. 책임 있는 결론은 '간헐적이고 다중 서비스에 걸친 이름 확인 피해'이며, 전면 블랙아웃이 아닙니다.

마이크로소프트가 설명한 장애 연쇄

DNS는 서비스 이름을, 클라이언트가 네트워크 목적지와 기타 서비스 정보를 찾는 데 쓰는 자원 레코드로 변환합니다. 클라우드 규모에서 권한(authoritative) DNS 플랫폼은 분산된 인프라로부터 크고 빠르게 변하는 수요를 처리해야 합니다. 엣지 캐시는 응답을 수요 근처에 두고 모든 요청을 같은 깊은 경로로 보내지 않음으로써 반복 작업을 줄입니다.

캐싱은 단순한 속도 기능이 아닙니다. 주어진 질의량에 대해 서비스가 수행해야 하는 작업량을 바꿉니다. 엣지 캐시가 효율적으로 응답하면 반복 수요를 하류 처리를 거의 거치지 않고 흡수할 수 있습니다. 효율이 떨어지면 겉으로 같아 보이는 수요 중 더 많은 부분이 서비스의 비용이 큰 부분에 닿습니다. 원시 질의 수만으로 수행한 용량 계획은 더 중요한 변수, 즉 현재 캐시 상태에서 각 질의가 얼마나 많은 작업을 유발하는지 놓칠 수 있습니다.

마이크로소프트의 이후 설명은 두 조건을 결합했습니다. 첫째, 마이크로소프트가 식별하지 않은 Azure 호스팅 도메인 집합을 겨냥한 비정상적인 전역 DNS 질의 급증이 있었습니다. 둘째, 이 연쇄가 DNS 엣지 캐시 효율을 떨어뜨리는 코드 결함을 드러냈습니다. 공개 기록은 이 결합을 마이크로소프트의 설명으로 뒷받침합니다. 결함이 원래 급증을 만들었다는 증거는 없고, 질의를 생성한 주체가 누구인지도 공개되지 않았습니다.

효율 저하는 시스템의 유효 여유분을 바꿔 놓았습니다. 정상 캐시 성능 기준으로 높은 질의율을 처리하도록 프로비저닝된 플랫폼은, 각 질의가 더 많은 작업을 만들 때 훨씬 적은 실사용 용량을 갖게 됩니다. 마이크로소프트는 Azure DNS에 과부하가 걸렸다고 말했습니다. 그 시점부터 클라이언트의 동작은 외부 세부사항이 아니라 장애 메커니즘의 일부가 되었습니다.

DNS 클라이언트는 평소에도 재시도합니다. 패킷이 유실될 수 있고, 서버가 바쁠 수 있으며, 두 번째 시도가 성공할 수 있기 때문입니다. 개별적으로는 합리적인 회복 동작입니다. 그러나 공유 서비스가 이미 과부하 상태일 때 재시도는 집단적으로, 가용 용량이 줄어드는 정확히 그 순간에 수요를 끌어올립니다. 실패한 첫 질의는 두 번째 질의가 되고, 어쩌면 다른 엔드포인트로 향하며, 반복 실패는 대규모 클라이언트 집단을 비슷한 타임아웃 간격으로 동기화할 수 있습니다.

마이크로소프트는 이 재시도 트래픽이 자사의 용량 급증(volometric-spike) 방어 계층에 정상으로 보였고 폐기되지 않았다고 밝혔습니다. 이 세부사항이 중요한 이유는, 단순 볼륨 급증을 인식하도록 조율된 통제는 형식적으로 유효한 재시도를 과잉 압박으로 다루지 않을 수 있기 때문입니다. 각 요청이 평범한 클라이언트 동작처럼 보여도 부하는 운영적으로 해를 끼칠 수 있습니다. 시스템은 고립된 패킷의 겉모습이 아니라 피드백 루프를 판단해야 합니다.

결과 연쇄는 구체적입니다. 비정상 질의 수요가 캐시 코드 결함과 만났다. 캐시 효율이 떨어졌다. Azure DNS에 과부하가 걸렸다. 클라이언트 재시도가 제공 부하를 증폭시켰다. 용량 방어가 정상처럼 보이는 재시도를 걸러내지 못했고 DNS 가용성이 더 하락했다. 이어진 확인 실패로 의존 서비스 이름이 간헐적으로 도달 불가 또는 관리 불가 상태가 되었습니다. 이는 뭉뚱그린 클라우드 장애 서술보다 정확하며, 공개 메커니즘으로 밟을 수 있는 지점까지가 한계입니다.

이 연쇄 어디에서도 최초 수요의 출처나 의도는 확립되지 않습니다. 마이크로소프트는 표적 도메인이나 질의를 생성한 시스템을 공개하지 않았습니다. 기록은 또한 캐시 결함을 낳은 정확한 코드 경로, 릴리스, 테스트 공백, 내부 변경도 식별하지 않습니다. 운영자 설명은 통제 분석을 지지할 수 있지만 완전한 포렌식 재구성으로 둔갑해서는 안 됩니다.

재시도가 개별 복구 동작을 공유 시스템 부하로 바꾼다

재시도 증폭은 책임이 분산되어 있기 때문에 되풀이되는 인프라 문제입니다. 클라이언트 라이브러리는 타임아웃과 재시도 일정을 정합니다. 재귀 리졸버는 재시도하거나 다른 권한 엔드포인트를 쓸 수 있습니다. 서비스 엣지는 작업에 응답할지, 대기시킬지, 흘려보낼지, 거부할지 결정합니다. 각 구성 요소는 설계대로 작동하면서도 결합된 시스템은 과부하의 더 깊은 곳으로 빠질 수 있습니다.

첫 번째 책임 질문은 과부하 모델이 이 피드백을 포함하는가입니다. 고정 질의 스트림으로 DNS 엣지를 시험하는 것은, 실제 클라이언트가 지연에 반응해 추가 수요를 만들 수 있다면 충분하지 않습니다. 더 대표적인 훈련은 응답 시간, 실패율, 재시도 동작을 연결해야 합니다. 캐시 효율이 저하될 때, 모델은 추가 작업이 지연을 충분히 높여 다음 재시도 물결을 촉발하는지 보여 주어야 합니다.

두 번째 질문은 방어가 정당한 접근을 지우지 않고 손상적 증폭을 구분하는가입니다. 모든 재시도를 단순히 드롭하면 하나의 연속성 실패를 다른 실패로 바꿀 뿐입니다. 반면 모든 재시도를 통과시키면 과부하 루프가 유지됩니다. 유용한 통제는 반복 질의 패턴, 캐시 효과, 도메인별 집중도, 리졸버 동작, 추가 시도가 사용자 결과를 개선하지 않을 가능성이 높은 지점에 대한 근거를 필요로 합니다.

세 번째 질문은 정상 최적화 계층이 약해졌을 때 독립 용량이 얼마나 남는가입니다. 캐시 결함이 건강한 캐시와 같은 비용 프로필을 낳는다고 가정해서는 안 됩니다. 운영자는 인바운드 패킷율뿐 아니라 유효 작업량, 큐잉, 응답 성공률에 기반한 임계값을 필요로 합니다. 캐시 히트율이 떨어지고 인바운드 볼륨이 일정하다면, 표면적 트래픽 스파이크보다 더 시급한 신호일 수 있습니다.

이 때문에 가동 중인 코드에 대한 증거가 중요합니다. 다이어그램은 분산 엣지, 이중화 노드, 과부하 방어를 보여줄 수 있습니다. 정책은 우아한 성능 저하를 요구할 수 있습니다. 그러나 어느 것도 특정 결함이 캐시 효율을 바꾸고 재시도가 곱해질 때 실제 무슨 일이 일어나는지 증명하지 않습니다. 신뢰는 관련 스트레스 아래에서 관측된 동작에서 나옵니다. 경계 지어진 큐, 영향받지 않은 도메인의 유지된 응답률, 통제된 재시도 부하, 플랫폼 외부에서도 보이는 회복이 그 대상입니다.

독립 관측이 서비스 경계를 드러낸다

마이크로소프트의 설명은 메커니즘을 제공하지만, 외부 관측은 그 메커니즘이 언제 고객 접점 경계를 넘었는지 보여줍니다. Exoprise는 21:20 UTC에 DNS 알람을 보고했고 이름 확인에 의존하는 서비스의 실패를 관측했습니다. 그 관측 지점은 마이크로소프트의 내부 캐시 코드나 사내 로그를 드러내지 못했습니다. 그러나 이 사건이 내부 카운터 이상 현상에 그치지 않았음을 보여주었습니다.

BleepingComputer의 당시 기술 보도는 과부하에 걸린 Azure DNS 서버, 엣지 캐시 효율 결함, 클라이언트 재시도 부하, 마이크로소프트의 대응 방침에 대한 운영자 설명을 보존했습니다. 동시에 마이크로소프트가 비정상 질의 급증에 대해 추가 세부사항을 제공하지 않았다는 점도 기록했습니다. 그 침묵은 원인을 채워 넣을 초대가 아니라 알 수 없음으로 남아야 합니다.

Reuters는 또 다른 종류의 교차 확인, 즉 마이크로소프트 서비스 전반의 장애와 회복에 대한 독립 보도를 공급했습니다. 동 기사의 Downdetector 신고 언급은 사용자 접점의 고통을 보여주는 가시 지표를 제공하되, 중요한 분모 한계를 지닙니다. 신고는 중복될 수 있고, 분포가 고르지 않으며, 인지도에 영향을 받습니다. 신고는 사람들이 문제를 겪었음을 보여주지만, 전체 모수를 측정하거나 각 신고에서 어떤 DNS 조회가 실패했는지 증명하지는 않습니다.

Azure 상태 이력 기록은 운영자 이벤트의 정체를 닻처럼 고정합니다. 상태 기록은 시기, 서비스 범위, 운영자 자신의 설명을 연결한다는 점에서 가치 있습니다. 그러나 그것은 원시 텔레메트리, 소스 코드, 후속 항목 전부의 독립 검증과 동등하지 않습니다. 가장 강한 공개 서술은 운영자의 메커니즘과 외부 측정·보도를 결합하면서 각각의 한계를 유지하는 것입니다.

상태 가시성 자체가 연속성 문제의 일부가 되었습니다. Exoprise와 당시 보도는 더 넓은 장애 동안 상태 및 지원 채널의 어려움을 언급했습니다. 공개 증거는 각 이용 불가 페이지나 채널 뒤의 의존성 그래프 전체를 확립하지 않습니다. 그러나 다음 거버넌스 질문을 지지합니다. 고객은 보고되는 서비스와 같은 실패 전제를 공유하지 않는 경로를 통해 신뢰할 수 있는 장애 정보를 얻을 수 있는가?

대역 외(out-of-band) 상태 경로는 이름만으로는 독립적일 수 없습니다. 게시 통제, 인증, DNS, 콘텐츠 전달, 지원 라우팅이 영향받은 플랫폼과 핵심 의존성을 공유한다면, 정보 수요가 가장 높은 순간에 사라질 수 있습니다. 독립성은 고객 네트워크에서, 장애 조건 아래서, 업데이트가 여전히 게시·조회될 수 있다는 증거와 함께 시험되어야 합니다.

외부 측정은 회복을 정의하는 데도 도움이 됩니다. 내부 대시보드가 DNS 서버가 작업을 수용한다고 보여주는 동안, 사용자는 여전히 낡은 실패, 타임아웃 큐, 이용 불가한 관리 화면에 부딪힐 수 있습니다. 여러 리전의 신지식 확인, 서비스별 프로브, 공개 상태 페이지 도달 가능성은 별개의 증거를 제공합니다. 어떤 단일 프로브도 모든 고객을 대표하지는 않지만, 서로 다른 관측 지점들 사이의 일치는 내부 초록불 하나보다 더 큰 신뢰를 줍니다.

DNS는 배경 배관이 아니라 연속성 통제 장치다

클라우드 서비스는 흔히 컴퓨팅, 스토리지, 애플리케이션 기능으로 묘사되지만, 사용자는 보통 이름을 통해 접근합니다. 확인될 수 없는 건강한 서버는 기능상으로 존재하지 않는 것과 같습니다. 찾을 수 없는 관리 엔드포인트는 다른 장애를 고치는 데 쓸 수 없습니다. 같은 이름 확인 문제를 공유하는 지원 페이지는 상황을 설명해 줄 수 없습니다. 따라서 DNS는 서비스 경로와 잠재적으로는 복구 경로 양쪽에 걸쳐 있습니다.

이 위치는 큰 의존 반경을 만듭니다. 하나의 DNS 장애는 서로 무관해 보이는 수많은 애플리케이션 실패로 표면화될 수 있습니다. Teams와 클라우드 콘솔, 다른 마이크로소프트 서비스는 서로 다른 애플리케이션 스택을 가지면서 같은 이름 확인 계층에 의존할 수 있습니다. 애플리케이션 팀들이 각자 자기 타임아웃이나 인증 증상만 보게 되기 때문에, 공통 통제 표면은 과소평가되기 쉽습니다.

책임성은 공유 의존성을 따라가야 합니다. 서비스 소유자는 자사 핵심 기능이 어떤 이름, 존, 확인 경로를 필요로 하는지 알아야 합니다. DNS 운영자는 어떤 서비스 계층이 특정 엣지 동작에 의존하는지 알아야 합니다. 장애 총괄은 공유된 이름 확인 실패와 수많은 동시 애플리케이션 결함을 구분할 방법이 필요합니다. 그 지도가 없으면 조직은 공통 계층이 여전히 손상된 채 하류 증상 조사에 복구 시간을 소모할 수 있습니다.

연속성에는 영향받지 않은 이름에 대한 주의도 필요합니다. 비정상 질의 급증은 공개되지 않은 Azure 호스팅 도메인 집합을 겨냥했지만, 보고된 영향은 더 넓은 DNS 가용성에 닿았습니다. 회복 탄력적 설계는 한 이름 집합에 집중된 압박이 무관한 질의에 응답하는 능력을 잠식하지 못하도록 해야 합니다. 공개 증거는 Azure의 정확한 격리 경계를 드러내지 않으므로, 질문은 '특정 파티션이 없었다는 주장'이 아니라 '블래스트 반경 통제가 입증되었는가'입니다.

같은 논리가 리전에도 적용됩니다. 지리적 분산은 리전들이 같은 위험한 상태나 자원 압박을 동시에 물려받지 않을 때만 가치가 있습니다. 전역으로 배포된 캐시 결함은 본래 분리된 용량을 함께 약화시킬 수 있습니다. 전역 방어 정책은 모든 곳에서 같은 결정을 내릴 수 있습니다. 따라서 리전 다양성은 물리적 위치 복수뿐 아니라 통제 상태의 다양성, 경계 지어진 배포, 압박 격리 능력을 포함해야 합니다.

이것이 DNS 레코드와 위임을 사실 계층으로 다룬다는 말의 실천적 의미입니다. 문서는 어느 서비스가 이름을 소유하고 요청이 어떻게 라우팅되어야 하는지 말할 수 있습니다. 그러나 사용자는 가동 중인 플랫폼이 내놓는 응답을 경험합니다. 운영적 정당성은 정확하고 가용한 이름 확인과 위임 경로의 지속 통제에서 나옵니다. 2021년 사건에서 관련 증거는 압박 아래에서 이름이 실제로 확인될 수 있었는지였습니다.

복구는 입증된 예방과 같지 않다

마이크로소프트는 Azure DNS가 22:00 UTC까지 자동으로 복구되었다고 밝혔습니다. 자동 복구는 장애 종료에 관한 중요한 증거입니다. 활성 서비스가 그 지점에서 수동 복원에 대한 언급 없이 가용성을 되찾았다는 뜻입니다. 그러나 그것만으로 과부하 상태가 왜 끝났는지, 방아쇠 수요가 바뀌었는지, 같은 조합이 재발할 수 있는지는 보여주지 않습니다.

마이크로소프트는 또한 과잉 재시도로부터 보호하기 위해 스파이크 방어 로직을 갱신했다고 밝혔습니다. 캐시 결함 수리와 비정상 트래픽 탐지·방어 개선을 후속 작업으로 나열했습니다. 이 진술들은 합리적인 통제 표면을 가리킵니다. 그러나 이 공개 기록에서 방어 갱신은 운영자가 보고한 조치이고, 캐시 수리와 탐지 개선은 운영자가 보고한 후속 작업으로 남습니다. 각 항목의 완료일, 플릿 적용 범위, 현재 성능은 독립적으로 검증되지 않았습니다.

예방의 증명은 닫힌 작업 항목 이상을 요구합니다. 캐시 결함의 경우, 관련 코드 경로가 수정되었고 장애 당시 중요했던 효율 저하를 재현하는 테스트가 있다는 증거가 필요합니다. 재시도 처리의 경우, 과부하 통제가 정당한 확인의 안전 수준을 유지하면서 증폭을 인식한다는 증거가 필요합니다. 비정상 수요 탐지의 경우, 영향받은 도메인과 리전 패턴 전반에서 유용한 알람 시점과 경계 지어진 방어를 보여주는 증거가 필요합니다.

회복 증거도 서비스 경계를 넘어야 합니다. Azure DNS 내부의 응답 성공률, 지연, 캐시 효과도 중요합니다. 그러나 여러 리전의 독립 확인, 관리 기능의 도달 가능성, 상태 채널의 가용성, 상관된 재시도 증가의 부재도 중요합니다. 리졸버 집단이 계속 타임아웃하는 동안 통제는 내부적으로 성공해 보일 수 있습니다. 외부 점검은 운영적 연속성이 실제로 돌아왔는지 판단하는 데 도움을 줍니다.

대부분의 서비스 회복 시점은 이 구분을 보여줍니다. DNS는 22:00 UTC까지 복구되었다고 했고, 대부분의 영향 서비스는 22:30까지 복구되었다고 했습니다. 성숙한 회복 측정은 두 마일스톤을 함께 추적해야 합니다. 첫째는 공유 의존성이 다시 응답한다는 뜻입니다. 둘째는 의존 시스템들이 자신의 백로그, 세션, 캐시, 컨트롤 플레인 영향을 처리해 마쳤다는 뜻입니다.

날조된 비난 없는 책임성

공개 증거는 결함, 최초 질의 조건, 테스트, 릴리스, 에스컬레이션, 복구의 개인 책임자를 지명하지 않습니다. 그 역할을 배정할 수 있는 내부 변경 기록이나 로그도 공개되지 않았습니다. 엔지니어나 관리자를 지명하면 시스템 책임성 분석이 추측으로 변합니다.

그럼에도 체계적 책임성은 여전히 요구가 깊습니다. 조직은 캐시 안전을 소유하는 사람, 롤아웃을 멈출 수 있는 사람, 재시도 흘려보내기 정책을 정하는 사람, 상태 경로 독립성을 검증하는 사람, 잔여 연속성 리스크를 수용하는 사람을 식별할 수 있습니다. 이 역할들은 2021년 사건을 특정 인물이 일으켰다는 주장 없이 의사결정 권한과 증거를 통해 평가될 수 있습니다.

같은 경계가 법적 결론에도 적용됩니다. 중대한 장애는 그 자체로 계약 위반, 과실, 규제 판정, 법원상 책임, 데이터 손실, 정확한 손해를 확립하지 않습니다. 네 개의 공개 출처 중 어느 것도 이 사건에 대해 그런 판정을 제공하지 않습니다. 기술적 책임성은 통제가 충분했는지, 주장이 검증되었는지를 물을 수 있으며, 법적 분쟁을 결정하는 척하지 않습니다.

영향 총계는 불완전합니다. 서비스 목록, 리전, 외부 알람, 장애 신고 수는 서로 다른 단위를 씁니다. 이를 고유 사용자 수나 재무 손실로 합산할 수 없습니다. 증거는 여러 마이크로소프트 서비스와 리전에 걸친 의미 있는 연속성 피해를 뒷받침하나, 완전한 분모는 뒷받침하지 않습니다.

마지막으로, 비정상 질의 급증은 마이크로소프트가 공개한 범위 안에 머물러야 합니다. 그 출처, 의도, 생성 시스템, 표적 도메인의 정체는 알려지지 않았습니다. 코드 결함은 급증이 일어났을 때 캐시 효율을 떨어뜨렸지만, 기록은 결함이 급증을 만들었다고 보여주지 않습니다. 이 사실들을 분리해 두면 쓸 수 있는 교훈이 남습니다. 최초 수요가 공개적으로 설명되지 않더라도, DNS 책임성은 관측된 시스템 동작을 통해 분석될 수 있습니다.

내구성 있는 기준은 운영적입니다. 캐시 통제는 비정상 수요 아래에서 효율을 증명해야 합니다. 재시도 통제는 개별 복구 동작이 공유 용량을 압도할 수 없음을 보여야 합니다. 방어는 평범한 사용자를 사라지게 하지 않고 해로운 증폭을 경계 지어야 합니다. 상태 경로는 진정으로 독립적인 의존성을 통해 도달 가능해야 합니다. 회복은 내부에서 선언되는 것과 마찬가지로 외부에서 입증되어야 합니다. 이것들은 동기나 비난에 대한 주장이 아니라, 가동 중인 연속성 시스템에 대한 시험입니다.

출처