요약

  • IBM은 외부 네트워크 공급자가 부정확한 라우팅을 IBM Cloud에 대량으로 유입해 심각한 혼잡을 일으켰고 서비스와 데이터센터에 영향을 미쳤다고 밝혔다. 동시대 보도와 Zello의 영향을 받은 고객 기록은 이 사건이 로그인, 활성 통신, 관리 콘솔, 상태 가시성까지 막았음을 보여주므로, 실질적 장애는 단일 애플리케이션 중단보다 광범위했다.
  • 공개 기록은 공급자 경로를 수용한 규칙, 예상치 못한 경로 수량에 대한 제한, 고객 도달성과 연계된 경보, 실패한 클라우드 네트워크에 의존하지 않는 관리 및 상태 경로에 대한 검토를 뒷받침한다. 그러나 공급자를 식별하지 않고, 정확한 계약이나 사설 토폴로지—네트워크 장치와 연결의 배치—를 공개하지 않으며, 어떤 통제가 없었거나 비효율적이었는지 입증하지 않는다.
  • IBM은 복구, 라우팅 정책—어떤 네트워크 경로를 수용하고 선호할지 정하는 규칙—의 조정, 완화 조치, 그리고 확인된 데이터 손실이나 사이버보안 문제가 없다고 보고했다. 이는 귀속된 진술이지 악의적 촉발 요인, 법적 책임, 전 세계적으로 동일한 복구 시간, 현재 교정 조치의 효율성을 입증하는 것은 아니다.

고객이 볼 수 있었던 장애

이 사건에 대한 첫 번째 유용한 설명은 프로토콜 도식이 아니다. 서비스를 이용하려는 사람들의 경험이다. TechCrunch는 문제가 2020년 6월 9일 태평양 시간 약 14시 30분에 나타나 광범위한 네트워킹 장애로 발전했다고 보도했다. 호스팅 서비스가 영향을 받았다. IBM의 주 상태 페이지는 사건 중 내부 서버 오류를 반환했고, 다른 IBM 서비스를 위한 별도 호스팅 상태 페이지는 광범위한 네트워크 영향을 보여주었다. 실시간 보도는 촉발 요인을 알지 못했다. 그 불확실성은 중요하다. 광범위한 장애의 관찰은 영향을 확립할 뿐 원인을 확립하지 않는다.

Zello의 인시던트 기록은 더 구체적인 다운스트림 시각을 제공한다. Zello는 중부 일광절약시간 18시 03분에 인시던트를 열었다. Zello는 대부분 사용자가 로그인하거나 재접속할 수 없었고, 이미 연결된 사람들은 통신을 잃었으며, 관리 콘솔을 사용할 수 없었고, 이름이 지정된 Zello 서비스 네 개가 영향을 받았다고 밝혔다. Zello는 같은 시간대 20시 22분에 인시던트를 해결됨으로 표시했다. 이 사실들은 Zello의 서비스와 사용자를 설명한다. IBM Cloud 고객 전체의 완전한 수치도, 모든 IBM 리전과 제품에 적용되는 보편적 시계도 아니다.

기술 뉴스 매체인 CRN은 IBM 파트너와 고객으로부터 유사한 통제 및 가시성 문제를 보도했다. 사람들은 환경, 콘솔, 상태 화면에 접근할 수 없었다. CRN은 IBM Cloud의 첫 공개 트윗을 동부 시간 20시 26분, 이후 전 서비스 복구 트윗을 21시 54분으로 기록했다. 이 타임스탬프는 공개 소통을 재구성하는 데 도움이 되지만, 복잡한 복구를 하나의 전 지구적 시작과 끝으로 바꾸지는 않는다. 클라우드 네트워크는 라우팅 정책이 바뀌고 혼잡이 줄며 서로 다른 서비스가 연결을 다시 확립하면서 단계적으로 돌아올 수 있다.

이후 IBM 공지는 귀속된 원인을 제공했다. The Register와 CRN이 보존한 대로, IBM은 외부 네트워크 공급자가 부정확한 라우팅을 IBM Cloud에 대량으로 유입했다고 밝혔다. IBM은 그로 인한 혼잡이 클라우드 서비스와 데이터센터에 영향을 미쳤다고 말했다. 또한 네트워크 전문가들이 라우팅 정책을 조정했고, 모든 서비스가 복구되었으며, 완화 조치가 취해졌고, 근본 원인 조사에서 데이터 손실이나 사이버보안 문제는 확인되지 않았다고 밝혔다.

이는 강력한 운영사 진술이지만 한계가 있다. 공개 자료에는 IBM 라우터—트래픽 경로를 선택하고 전달하는 네트워크 장치—의 로그, 이름이 밝혀지지 않은 공급자의 기록, 경로 교환에 대한 결정적이고 독립적인 재구성이 포함되지 않는다. 공지는 IBM이 무엇을 결론 내리고 무엇을 했는지 높은 수준에서 알려준다. 어떤 개별 메시지가 수용되었는지, 어떤 엔지니어가 변경을 승인했는지, 어떤 계약 당사자가 경로 수용 규칙을 소유했는지, 특정 안전장치가 없었는지는 공개하지 않는다.

Zello는 이후 영향을 받은 고객의 관점에서 메커니즘을 설명했다. 그 설명에 따르면 외부 공급자가 다수의 경로를 주입했다. 그러자 IBM Cloud의 서버들이 아웃바운드 IPv4 트래픽을 잘못된 목적지로 보내 심각한 혼잡과 서비스 상실에 기여했다. 인터넷 프로토콜 버전 4는 도달 가능한 각 장치나 서비스가 숫자 주소를 사용하는 널리 쓰이는 주소 체계다.

Zello의 설명은 라우팅 상태—네트워크가 현재 신뢰하고 사용하는 경로의 집합—를 애플리케이션 결과와 연결하기 때문에 유용하다. 이는 여전히 Zello의 공개 설명이며 IBM과 공급자의 사설 기록을 대체하지 않는다.

종합하면 공개 증거는 절제된 설명을 뒷받침한다. 공급자에서 시작된 라우팅 사건이 IBM의 경계에 도달했다. IBM은 심각한 혼잡과 서비스 영향을 부정확한 라우팅 탓으로 돌렸다. 독립적 관찰은 광범위한 도달성 및 상태 문제를 보여주었다. 영향을 받은 고객 한 곳이 로그인, 통신, 관리 실패를 기록했다. 복구는 단계적으로 이루어졌고 보고된 라우팅 정책 조정을 포함했다. 그보다 더 정확한 내용은 미확인으로 표시해야 한다.

라우팅 메시지가 어떻게 클라우드 장애가 되는가

BGP는 흔히 인터넷의 라우팅 시스템이라고 설명된다. 그 표현은 하나의 중앙 서비스가 모든 경로를 계산하는 것처럼 들릴 수 있다. 실제로 인터넷은 독립적으로 운영되는 네트워크들의 집합이다. 각각은 흔히 하나의 관리 정책 아래 있는 네트워크인 자율 시스템(AS)으로 표현된다. 이 시스템들은 경로 광고를 교환하여 각자가 네트워크 프리픽스, 즉 관련 주소 블록으로 트래픽을 어디로 보낼지 결정할 수 있게 한다.

경로 광고는 고객 데이터를 운반하지 않는다. 경로 광고는 어떤 경로를 사용할지 결정하는 네트워크의 일부인 제어 평면에 속한다. 고객 패킷, 즉 네트워크 데이터가 나뉘는 작은 단위는 그러한 결정이 설치된 뒤 실제 트래픽을 전달하는 장비와 링크인 데이터 평면을 통과한다. 제어 평면이 잘못된 경로를 학습하고 설치하면 데이터 평면은 충실히 트래픽을 잘못된 방향으로 보낼 수 있다. 따라서 장비 자체는 정상이어도 설치된 경로가 잘못되어 서비스에 도달할 수 없는 경우가 생긴다.

IBM의 공개 설명은 “부정확한 라우팅”이라는 넓은 표현을 쓴다. Zello는 다수의 경로가 주입되었다고 말한다. 어느 출처도 정확한 프리픽스, 사설 BGP 세션, 광고를 시작한 네트워크 목록, IBM이 이를 평가한 정책을 공개하지 않는다. 전체 인터넷 라우팅 테이블—라우터가 알고 있는 네트워크 경로의 목록—이 도착했다거나, 하나의 정확한 주소 블록이 사건을 일으켰다거나, 특정 최대 설정이 비활성화되었다고 말하는 것은 과장이다. 증거는 범주와 결과를 확립할 뿐 사설 명령 이력을 확립하지 않는다.

수량이 중요한 이유는 경로가 정보이자 작업이기 때문이다. 라우터는 메시지를 수신하고, 정책과 비교하고, 도달 가능한 네트워크에 대한 저장된 관점을 갱신하고, 선호 경로를 선택하며, 적절한 경우 전달 지침을 설치해야 한다. 또한 변경된 정보를 다른 라우터로 보낼 수 있다. 갑작스러운 예상 밖 경로 집합은 프로세서 시간, 메모리, 업데이트 용량 또는 링크 대역폭—한 연결이 주어진 시간에 운반할 수 있는 데이터량—을 소비할 수 있다. 개별 메시지가 구문상 유효하더라도 그 수나 내용은 손상성 변동—경로의 반복적 재계산과 교체—을 일으킬 수 있다.

그러면 혼잡은 한 곳 이상에서 나타날 수 있다. 라우팅 프로세서가 변경을 따라가지 못할 수 있다. 링크는 트래픽을 예상 밖 목적지로 운반하거나 사용 가능한 용량을 초과할 수 있다. 여러 경로를 써야 할 트래픽이 더 적은 경로에 집중될 수 있다. 애플리케이션은 응답이 오지 않을 때 재시도하여 수요를 늘릴 수 있다. IBM 공지는 부정확한 라우팅 뒤에 심각한 혼잡이 따랐다고 하지만 모든 병목을 특정하지는 않는다. 따라서 책임 있는 설명은 공개되지 않은 사설 측정을 주장하지 않으면서 그럴듯한 연쇄를 설명한다.

경로 수렴이라는 용어는 라우터가 변경을 처리하고 일관된 사용 가능 경로 집합에 정착하는 기간을 뜻한다. 수렴이 항상 즉각적인 것은 아니다. 그동안 서로 다른 장치가 일시적으로 다른 관점을 가질 수 있다. 일부 트래픽은 오래된 경로를, 일부는 새 경로를, 일부는 사용 가능한 경로를 전혀 따르지 않을 수 있다. 이는 라우팅 정책 조정이 단계적 복구를 낳을 수 있는 이유를 설명하는 데 도움이 된다. 그러나 IBM의 2020년 수렴 기간이나 내부 순서를 입증하지는 않는다.

이 사건을 자동으로 경로 유출이나 경로 탈취라고 부르면 안 된다. 경로 유출은 도달성 정보가 사용되도록 의도된 관계를 넘어 우발적으로 퍼지는 것이다. 경로 탈취는 다른 네트워크가 통제하는 주소에 도달하겠다는 무단 주장으로, 때로는 악의적이고 때로는 오류로 발생한다. 인정된 기록은 어느 범주도 확립하지 않는다. 기록은 외부 공급자가 부정확한 라우팅으로 IBM Cloud를 넘치게 했다고 말한다. 그 표현을 보존하면 익숙한 기술 용어가 조작된 증거가 되는 것을 막을 수 있다.

또한 이 사건을 분산 서비스 거부(DDoS) 공격, 즉 여러 출처의 트래픽으로 서비스를 압도하려는 의도적 시도라고 불러서도 안 된다. 혼잡은 발생했지만 혼잡만으로 적대적 의도가 입증되지는 않는다. IBM은 자사의 조사에서 사이버보안 문제가 확인되지 않았다고 밝혔다. 이는 가능한 모든 보안 결과에 대한 증거라기보다 귀속된 부정적 발견이지만, 근거 없는 공격 서사를 배격하기에는 충분하다.

공급자 경계는 통제를 적용하는 장소다

클라우드 기업은 어느 공급자도 인터넷을 혼자 운영할 수 없기 때문에 연결성을 구매하고 다른 네트워크와 라우팅 정보를 교환한다. 이 관계는 조직 간 경계를 만들지만, 그 경계는 운영 책임이 사라지는 장소가 아니다. 경계는 통제 표면이다. 어떤 정보와 트래픽이 들어올 수 있는지, 어느 정도의 변경이 허용되는지, 관계가 기대를 벗어날 때 무슨 일이 일어나는지를 정책이 결정하는 지점이다.

이 사건의 외부 공급자는 이름이 공개되지 않았다. 정확한 법인, 계약, 기술적 연결 지점, 내부 원인은 공개되지 않았다. 증거는 IBM이 직접 인터넷 트랜짓—다른 네트워크가 트래픽을 계속 운반하는 서비스—을 구매했는지, 중개 방식을 사용했는지, 특정 결정을 위임했는지 보여주지 않는다. 또한 각 경로 수용 규칙, 경고, 비상 연락 단계를 누가 소유했는지도 밝히지 않는다. 이러한 누락은 당사자 간의 공정한 책임 배분을 막는다.

그렇다고 통제 분석을 막지는 않는다. IBM Cloud는 수용된 라우팅 상태의 영향을 받은 환경을 운영했다. IBM Cloud는 공급자 정보가 자사 네트워크에 들어오는 조건을 정의하고, 고객 도달성의 건강을 관찰하며, 장애 중 엔지니어와 고객이 정보를 얻는 방법을 유지할 위치에 있었다. 공급자는 라우팅 정보를 보낸 시스템을 운영했다. 따라서 각 측은 서로 다른 사실과 행동을 통제했고, 고객은 어느 쪽도 통제하지 못했다.

최소한 운영 관계에는 예상 경로 모델이 있어야 한다. 그 모델은 피어—경로를 교환하는 인접 네트워크—나 공급자가 합리적으로 광고할 것으로 예상되는 주소 블록, 정상적인 변동 범위, 승인이 필요한 변경, 예외가 만료되는 방식을 식별한다. 이는 다른 연결에서 복사한 일반 목록이 아니라 실제 상업 및 네트워크 관계에 기반해야 한다. 공개 기록은 IBM과 공급자가 그러한 모델을 갖고 있었는지 말하지 않는다. 이 사건은 그 질문을 필요하게 만든다.

경계에는 비상 상황에서도 살아남는 소유권이 필요하다. 한 팀은 누가 새 경로 변경 수용을 중단할 수 있는지, 누가 안전하지 않은 정책을 철회할 수 있는지, 누가 공급자와 연락하는지, 누가 조사 중 고객 트래픽을 보호하는지, 누가 정상 교환 재개 시점을 결정하는지 알아야 한다. 계약이 책임을 설명할 수는 있지만 종이 위의 이름만으로는 충분하지 않다. 연락 경로, 접근 권한, 결정 권한은 공유 네트워크가 혼잡한 바로 그 순간에 작동해야 한다.

이 구분이 중요한 이유는 공급자 비난이 취약한 내부 억제의 변명이 될 수 있기 때문이다. 클라우드 운영자는 모든 파트너가 항상 올바른 정보를 보낼 것이라고 보장할 수 없다. 대신 자사 경계에서 신뢰할 수 없거나 예상 밖인 상태가 얼마나 활성화될지 결정할 수 있다. 반대로 운영자는 필터링 능력을 공급자가 아무 의무도 지지 않는다는 증거로 사용해서는 안 된다. 시작 네트워크는 정확한 광고, 안전한 변경 관행, 신속한 협력을 유지해야 한다. 책임은 분산되어 있지만 서로 바꿔 쓸 수 있는 것은 아니다.

가장 어려운 시험은 통제가 실제로 실행된 관계와 일치하는지다. 정책 문서는 승인된 경로만 수용한다고 말할 수 있지만 실제 실행 중인 구성은 훨씬 더 많은 것을 허용할 수 있다. 연락처 목록은 비상 책임자를 지정할 수 있지만 그 사람의 접근 권한이 실패한 네트워크에 의존할 수 있다. 대시보드는 장치 건강을 측정할 뿐 고객이 서비스에 도달할 수 있는지를 측정하지 않아 초록색으로 보일 수 있다. 서비스의 현실은 사건 당시의 코드, 구성, 설치된 라우팅 상태, 관찰된 고객 결과다.

표준 지침이 확립할 수 있는 것과 없는 것

RFC(Request for Comments) 7454는 BGP 운영 보안에 관한 공개 인터넷 엔지니어링 지침 문서다. 이 문서는 네트워크 운영자가 다른 네트워크에서 수신하고 다른 네트워크로 광고하는 경로에 대해 명시적 정책을 구축할 것을 권고한다. 연결된 네트워크에서 허용된 주소 블록만 수용하는 규칙인 인바운드 프리픽스 필터링과, 네트워크가 내보내서는 안 되는 경로를 광고하지 못하게 하는 아웃바운드 필터링을 논의한다.

이 지침은 또한 최대 프리픽스 제한, 즉 이웃이 라우터가 경고하거나 추가 경로를 거부하거나 교환을 닫기 전에 몇 개의 주소 블록을 광고할 수 있는지에 대한 보호 임계값을 논의한다. 값은 예상 관계와 장비 용량을 반영해야 한다. 너무 낮게 설정하면 정당한 확장을 방해할 수 있다. 너무 높게 설정하면 자원이 압박받기 전에 비정상적 폭주를 억제하지 못할 수 있다. 따라서 임계값은 이력, 용량 테스트, 예외 절차에 의해 뒷받침되는 운영 결정이다.

이러한 통제는 보고된 부정확한 라우팅 폭주와 직접 관련이 있다. 수용된 집합이 공급자 관계와 일치했는지, 경로 수가 합의된 범위를 벗어났는지, 비정상적 변경을 억제할 수 있었는지 질문할 어휘를 제공한다. 또한 인바운드와 아웃바운드 규율이 모두 중요한 이유를 보여준다. 한 네트워크의 안전하지 않은 내보내기가 다른 네트워크의 안전하지 않은 입력이 되기 때문이다.

RFC 7454는 IBM이 2020년 6월에 무엇을 구성했는지 독자에게 말하지 않는다. 특정 필터나 제한이 없었는지, 비활성화되었는지, 잘못 설정되었는지 입증하지 않는다. 모든 권고를 따랐다면 예방이 보장되었을 것이라고 확립할 수도 없다. 라우팅 사건은 유효한 정보, 장비 한계, 운영 오류, 단일 통제가 포괄하지 못하는 의존성의 예상 밖 조합을 악용할 수 있다.

따라서 건전한 검토는 표준을 평결이 아니라 벤치마크로 취급할 것이다. 조사자는 실제 공급자 정책을 예상 경로 집합과 비교하고, 비정상 경로 수나 내용 변화가 경보 임계값을 넘었는지 조사하고, 라우터와 운영자가 어떤 조치를 했는지 확인하며, 유사한 입력이 안전한 환경에서 억제되는지 테스트할 수 있다. 결과는 규칙이 존재했는지뿐 아니라 고객 도달성이 실패하기 전에 작동했는지도 식별해야 한다.

필터링에는 신뢰할 수 있는 데이터도 필요하다. 허용된 주소 블록 목록, 흔히 프리픽스 목록이라고 불리는 것은 고객이 주소 공간을 합법적으로 추가하거나 이전하거나 사용을 중단할 때 낡을 수 있다. 레지스트리 데이터는 할당과 라우팅 의도를 문서화하는 데 도움이 될 수 있지만, 레지스트리는 기록 보관자이지 모든 실제 패킷을 통제하는 기계가 아니다. 운영자는 기록을 계약, 승인된 변경, 실제 실행 중인 경로와 대조해야 한다. 정확한 기록은 정책을 뒷받침하지만 운영 검증을 대체하지 않는다.

또 다른 예방적 통제는 변경률을 인식한 처리다. 모든 라우터가 무제한 정책 변경을 한 번에 처리할 수 있거나 처리해야 하는 것은 아니다. 운영자는 비정상적인 추가 및 철회 비율에 경고하고, 비필수 경로 변경의 확산을 늦추고, 문제가 있는 연결 네트워크를 격리하거나, 갑작스러운 확장에 명시적 재정의를 요구할 수 있다. 정확한 설계는 장비와 서비스 아키텍처에 달려 있다. 이러한 조치 중 어느 것도 IBM 네트워크에 있었거나 없었다고 주장되지 않는다.

경계는 안전한 실패에 대해서도 테스트해야 한다. 한 공급자 세션이 수용 범위를 초과하면 대응은 안전하지 않은 입력이 초래했을 것보다 더 큰 장애를 만들어서는 안 된다. 테스트는 세션을 닫으면 모든 도달성이 사라지는지, 대체 경로에 충분한 용량이 있는지, 서비스가 얼마나 빨리 안정되는지, 엔지니어가 접근 권한을 유지하는지 조사해야 한다. 제어 평면을 보호하지만 고객 트래픽을 고립시키는 안전장치는 불완전하다.

도달성, 관리, 상태가 함께 실패했다

가장 중대한 관찰 중 하나는 고객과 파트너가 호스팅 애플리케이션뿐 아니라 콘솔과 상태 정보에 대한 접근도 잃었다는 점이다. 콘솔은 서비스를 검사하거나 변경하는 관리 인터페이스다. 콘솔이 관리하는 서비스와 동일한 네트워크 경로에 의존하면 라우팅 사건이 워크로드와 이를 진단·통제할 수단을 동시에 제거할 수 있다.

동일한 의존성이 인시던트 소통에도 영향을 줄 수 있다. 동시대 보도에 따르면 IBM의 주 상태 페이지는 사건 중 오류를 반환했다. 그것이 소통이 전혀 없었다는 것을 입증하지는 않는다. 별도 호스팅 정보와 소셜 미디어 업데이트가 존재했다. 다만 주 상태 채널이 보고 대상 플랫폼과 모든 실패 경로를 공유해서는 안 되는 이유를 보여준다.

대역 외 접근은 실패할 수 있는 일반 생산 경로에 의존하지 않도록 설계된 관리 경로다. 별도의 네트워크 연결, 자격 증명, 이름 확인—이름을 네트워크 주소로 바꾸는 서비스—라우팅, 호스팅을 사용할 수 있다. “별도”는 다른 웹 주소가 같은 기반 네트워크에서 제공되는 것이 아니라 실제 의존성을 설명해야 한다. 공개 기록은 IBM의 관리 설계를 공개하지 않으므로, 이는 예방적 연속성 통제이지 IBM에 그러한 통제가 없었다는 진술이 아니다.

클라우드 운영자는 각 핵심 통제 표면의 의존성 사슬을 지도화해야 한다. 클라우드 트래픽을 운반하는 핵심 네트워크인 클라우드 백본이 혼잡하면 네트워크 엔지니어가 관련 라우터에 도달할 수 있는가? 사용자를 검증하는 시스템인 신원 서비스가 영향을 받으면 인증할 수 있는가? 정상 모니터링 시스템에 도달할 수 없을 때 현재 구성과 경로 상태를 얻을 수 있는가? 고객 지원은 관리 콘솔에 의존하지 않고 영향을 볼 수 있는가? 상태 편집자는 영향을 받은 클라우드 리전이나 네트워크 밖에서 계속 사용 가능한 경로로 게시할 수 있는가?

답은 테스트해야 한다. 팀이 대응을 논의하는 탁상 훈련은 불분명한 소유권을 드러낼 수 있다. 실제 연속성 테스트는 더 나아가 일반 의존성을 의도적으로 사용할 수 없게 만든 상태에서 대체 접근 경로를 사용하고 테스트 상태 업데이트를 게시해야 한다. 목표는 민감한 아키텍처를 노출하는 것이 아니다. 독립적이라고 여긴 경로가 필요할 때 작동함을 확립하는 것이다.

상태 소통에는 신뢰도 모델도 필요하다. 첫 몇 분 동안 운영자는 최종 원인을 주장하지 않고 확인된 증상과 영향을 받은 기능을 보고할 수 있다. 관찰된 도달성 상실과 귀속된 공급자 설명을 구분할 수 있다. 하나의 명확한 시간대로 시각을 게시하고, 서로 다른 서비스가 별도로 돌아올 때 복구가 단계적이라고 밝힐 수 있다. 이렇게 하면 엔지니어가 진행 중인 가설을 확실성으로 바꾸도록 강요하지 않고 고객이 결정을 내릴 수 있다.

Zello 기록은 이것이 다운스트림에서 왜 중요한지 보여준다. 통신 서비스는 로그인, 활성 연결, 관리를 클라우드 공급자에 의존할 수 있다. 세 가지가 모두 사용 불가능해지면 Zello 자체 대응자들은 증거와 실패한 업스트림에 전적으로 의존하지 않는 고객 채널이 필요하다. 의존성 소유자는 공급자의 콘솔과 상태 페이지가 동시에 손상될 때 어떻게 운영할지 연습해야 한다.

귀속을 보존하는 타임라인

태평양 시간 약 14시 30분에 공개 관찰은 광범위한 IBM Cloud 네트워크 문제를 확인했다. 이는 인정된 기록에서 가장 이른 시각이지 모든 서비스의 보편적 장애 시작은 아니다. 장애 중 IBM 주 상태 페이지는 오류를 반환했고, 별도 호스팅 서비스 페이지는 광범위한 영향을 보여주었다.

Zello는 중부 일광절약시간 18시 03분에 고객 인시던트를 열었다. 로그인 또는 재접속 불가, 연결되어 있던 사용자의 통신 상실, 관리 콘솔 사용 불가, 네 개 서비스 영향이 문서화되었다. 이는 영향을 받은 고객의 시간 창을 제공할 뿐 IBM 사건 전체의 분모는 아니다.

CRN은 동부 시간 20시 26분의 IBM 공개 업데이트와 21시 54분의 복구 업데이트를 보도했다. Zello는 자사 인시던트를 중부 일광절약시간 20시 22분에 해결됨으로 표시했다. 시간대를 변환하면 이 기록들은 겹치지만 동일하지 않은 관찰을 보여준다. 각 게시자가 서로 다른 서비스나 소통 표면을 측정했으므로 하나의 분 단위 보편적 순서로 강제해서는 안 된다.

IBM의 이후 공지는 사건을 이름이 밝혀지지 않은 외부 공급자와 부정확한 라우팅 탓으로 돌렸다. 네트워크 전문가들이 라우팅 정책을 조정했고 서비스가 복구되었으며 완화 조치가 취해졌다고 밝혔다. 이는 경로 정책 조치를 복구 과정 안에 두지만 명령, 공급자 협력 순서, 서비스별 복귀를 밝히지는 않는다.

가장 정직한 설명은 단계적 복구다. 모든 고객 애플리케이션이 반드시 안정되기 전에 일부 가시성이 돌아왔다. 경로가 정착하면서 서로 다른 시스템이 자체 일정에 따라 재연결되었을 수 있다. 오래 유지되는 연결을 가진 애플리케이션은 새 로그인과 다르게 복구될 수 있다. 관리 기능은 워크로드 트래픽과 별도로 돌아올 수 있다. 공개 출처는 하나의 스위치가 클라우드 전체를 복구했다는 주장보다 점진적 복구 사실을 더 강하게 뒷받침한다.

연대기는 책임성의 일부다. 결정은 변화하는 증거 아래에서 이루어지기 때문이다. 운영 팀은 비정상 라우팅이 처음 도착한 시점, 혼잡 경고가 발생한 시점, 고객 도달성이 떨어진 시점, 공급자에 연락한 시점, 경로 정책이 바뀐 시점, 각 서비스 목표—가용성이나 응답 시간 같은 측정 가능한 목표—가 복구된 시점을 알아야 한다. 공개 보도에는 그 내부 순서의 단편만 있다. 완전한 사후 인시던트 기록은 사후에 불확실성을 다시 쓰지 않고 해당 사건들을 정렬해야 한다.

공급자 경계 검토가 보존해야 할 증거

텔레메트리는 시스템이 실행되는 동안 수집된 측정값과 이벤트 기록을 뜻한다. 이 부류의 사건에서 유용한 텔레메트리는 각 연결 네트워크에서 수신한 경로의 수와 비율, 허용 및 거부된 경로 집합, 선호 경로 변경, 프로세서 및 메모리 압력, 라우팅 업데이트 큐—처리를 기다리는 메시지의 백로그—링크 활용률, 즉 각 연결 용량 중 사용된 비율, 고객 도달성 테스트, 관리 접근 건강을 포함할 수 있다. 공개 증거는 이러한 IBM 측정값을 공개하지 않는다. 이는 귀속된 원인을 테스트하는 데 필요한 증거다.

경로 기록은 여러 가능성을 구분할 수 있을 만큼 충분한 맥락을 보존해야 한다. 공급자가 많은 새로운 정당한 프리픽스를 추가했는가? 상업 관계 밖의 경로를 광고했는가? 정책 업데이트로 이전에 거부되던 경로가 수용 가능해졌는가? 업데이트 비율이 급증하는 동안 내용은 안정적으로 유지되었는가? IBM의 대응이 선호도를 바꾸거나, 집합을 거부하거나, 세션을 닫거나, 트래픽을 다른 공급자로 옮겼는가? 이는 발생한 일에 대한 주장이 아니라 질문이다.

구성 이력도 똑같이 중요하다. 최종 구성은 복구 후 무엇이 남았는지를 보여줄 뿐, 영향이 시작될 때 무엇이 활성화되어 있었는지 반드시 보여주지는 않는다. 조사자는 사건 전 버전, 대응 중 각 변경, 누가 승인했는지, 어떤 효과가 뒤따랐는지 필요로 한다. 롤백은 이전에 알려진 구성으로 의도적으로 돌아가는 것이다. 빠르게 가능해야 하지만, 비상 되돌리기가 증거를 지우지 않도록 기록되어야 한다.

고객 도달성 테스트는 영향을 받은 네트워크 내부뿐 아니라 외부에서도 이루어져야 한다. 합성 프로브는 연결, 로그인, 간단한 거래를 시도함으로써 고객처럼 행동하는 자동 테스트다. 장치 건강은 초록색으로 남아 있어도 외부 사용자가 유효한 경로를 찾지 못할 수 있다. 여러 독립 네트워크의 프로브는 문제가 지역적, 공급자 특정, 광범위 중 무엇인지 보여줄 수 있다.

검토는 또한 블라스트 반경, 즉 하나의 실패로 영향을 받는 서비스, 고객, 리전 범위를 추적해야 한다. 공개 기록은 광범위한 영향과 명명된 다운스트림 결과를 입증하지만 감사된 분모를 제공하지 않는다. 내부적으로 서비스 소유자는 실패한 로그인, 연결 손실, 콘솔 오류, 네트워크 경로, 지원 보고를 대조해야 한다. 수치는 시도와 사람, 영향을 받은 서비스와 영향을 받은 고객을 구분해야 한다.

공급자 협력은 그 자체의 증거를 만든다. 인시던트 기록은 공급자가 문제를 인정한 시점, 각 측이 어떤 경로 집합을 유효하다고 믿었는지, 어느 측이 각 억제 조치를 취했는지, 당사자들이 복구가 안전하다고 어떻게 판단했는지 명시해야 한다. 민감한 상업 세부사항은 비공개로 남을 수 있다. 운영상 행동 배분은 두 회사가 경계를 공유한다는 이유만으로 알 수 없게 되어서는 안 된다.

증거 보존은 프라이버시와 보안도 보호해야 한다. 라우터와 애플리케이션 기록은 고객 네트워크나 민감한 토폴로지를 노출할 수 있다. 접근은 제한되고 보존 기간은 정당화되며 공개는 집계되어야 한다. 그러한 안전장치는 엄격한 사건 재구성과 양립한다. 프라이버시는 증거 처리 방식을 형성해야 하지만 증거 부재를 변명해서는 안 된다.

공개 기록이 입증하는 것

기록은 IBM Cloud가 2020년 6월 9일 광범위한 네트워킹 장애를 겪었음을 입증한다. 동시대 보도에 따르면 호스팅 서비스, 상태 가시성, 환경, 콘솔이 영향을 받았음을 입증한다. Zello가 자사 서비스에서 로그인, 재접속, 통신, 관리 실패를 문서화했음을 입증한다.

기록은 또한 IBM이 말한 바를 입증한다. IBM은 사건을 외부 네트워크 공급자가 부정확한 라우팅으로 IBM Cloud를 넘치게 해 심각한 혼잡을 일으킨 탓으로 돌렸다. IBM은 라우팅 정책이 조정되었고, 서비스가 복구되었으며, 완화 조치가 취해졌고, 자사 조사에서 데이터 손실이나 사이버보안 문제가 확인되지 않았다고 밝혔다. 운영사 귀속은 모든 재진술에서 가시적으로 남아야 한다.

RFC 7454는 명시적 경계 정책, 프리픽스 필터링, 피어별 경로 수 제한이 인정된 운영 안전장치임을 확립한다. 조사가 물어야 할 질문에 대한 분석 기준을 제공한다. IBM의 구성이나 공급자의 행위를 확립하지는 않는다.

조직 식별 색인인 BTW Media 직접 디렉터리는 International Business Machines Corporation에 대한 신원 연결을 뒷받침한다. 이벤트 보도는 IBM Cloud를 영향을 받은 운영사로 식별한다. 디렉터리는 어느 IBM 법인이 관련 공급자 계약에 서명했는지 확립하지 않으며, 이름이 밝혀지지 않은 공급자에 대해서는 아무 말도 하지 않는다. 신원 기록은 독자가 조직을 연결하도록 돕지만 실행 중인 네트워크를 재구성하지는 않는다.

여전히 알 수 없는 것

공급자는 여전히 이름이 밝혀지지 않았다. 공개 기록은 독립적으로 운영되는 네트워크에 부여된 숫자 식별자인 자율 시스템 번호나 경로를 수신한 정확한 IBM 네트워크를 식별하지 않는다. 패킷 수준 포렌식, 네트워크 트래픽의 상세 재구성에 필요한 프리픽스, 경로 속성—경로 선택에 영향을 주는 경로에 붙은 세부정보—정책 코드, 사설 세션, 타임스탬프를 공개하지 않는다.

경로 범주는 여전히 넓다. 출처는 악의적 의도, 탈취, 유출, 분산 공격을 입증하지 않는다. 공격자를 식별하지 않는다. 한 사람이 과실 결정을 내렸음을 보여주지 않는다. 더 강한 권위 있는 증거가 나오기 전까지 이 사건은 공개 문구에서 운영상 라우팅 실패로 남아야 한다.

전체 영향은 여전히 알 수 없다. IBM 고객, 영향을 받은 리전, 실패한 거래, 손실된 메시지, 재정적 손실, 계약상 크레딧에 대한 감사된 수치가 없다. Zello는 구체적인 다운스트림 효과를 입증하지만 그 사용자는 클라우드 전체의 대리 표본이 아니다. 파트너 보고는 의미 있는 접근 문제를 확립하지만 모집단 분모를 만들지는 않는다.

데이터 영향은 제한적이다. IBM은 자사 조사에서 데이터 손실이 확인되지 않았다고 밝혔다. 그 진술을 데이터가 손실되었다는 주장으로 뒤집어서는 안 된다. 또한 모든 고객의 애플리케이션 상태에 대한 독립 감사로 확장해서도 안 된다. 서비스는 저장된 데이터를 잃지 않고 도달성을 잃을 수 있으며, 고객은 여전히 중단과 불확실한 결과를 겪을 수 있다.

법적 책임은 여전히 알 수 없다. 공개 자료는 계약 위반, 과실, 규제 위반, 손해, 개인 책임을 확립하지 않는다. 여기서 공급자 경계 책임성은 통제, 결정, 증거, 연속성을 설명할 능력을 뜻하지 법적 판단을 뜻하지 않는다.

교정 조치의 효율성은 여전히 알 수 없다. IBM은 완화 조치가 취해졌다고 밝혔다. 출처는 전체 조치, 테스트 결과, 재발 기준, 현재 구성을 공개하지 않는다. 조치가 실패했다고 말하는 것은 불공정하고, 입증된 지속성을 갖췄다고 말하는 것은 근거가 없다. 현재의 보증에는 현재의 증거가 필요하다.

미확인 사항을 보증 질문으로 바꾸기

사설 세부정보의 부재가 모호한 결론을 낳아서는 안 된다. 정확한 보증 질문을 낳아야 한다. 공급자는 어떤 경로 집합을 보낼 것으로 예상되었는가? 어떤 집합이 도착했는가? 어떤 경로가 수용, 거부, 선호되었는가? 어떤 경로 수 및 변경률 임계값이 있었는가? 어떤 경보가 먼저 발생했는가? 어떤 고객 도달성 신호가 영향을 확립했는가? 누가 세션을 억제할 수 있었고 얼마나 빨리 할 수 있었는가?

다음 질문은 연속성에 관한 것이다. 일반 클라우드 도달성이 실패하는 동안 어떤 관리 경로가 사용 가능하게 남았는가? 어떤 상태 시스템이 영향을 받은 의존성 밖에서 호스팅되었는가? 지원 팀이 네트워크 엔지니어와 같은 영향을 볼 수 있었는가? 대체 공급자가 있었고 리디렉션된 부하를 운반할 수 있었는가? 페일오버는 백업 경로나 시스템으로의 통제된 전환이다. 백업이 진정으로 충분히 독립적이고 충분한 용량을 갖출 때만 유용하다.

테스트는 이러한 질문을 연결해야 한다. 공급자 경계 훈련은 격리된 환경에서 예상 밖 경로 광고의 안전한 집합을 재생할 수 있다. 예상 결과에는 거부 또는 억제, 명확한 경보, 보존된 관리 접근, 가시적인 고객 영향 신호가 포함되어야 한다. 두 번째 훈련은 주 공급자 상실을 시뮬레이션하고 트래픽이 안전하게 전환되는지 측정할 수 있다. 세 번째는 정상 상태 의존성을 제거하고 인시던트 소통이 여전히 작동하는지 검증할 수 있다.

보증은 민감한 토폴로지가 아니라 결과를 보고해야 한다. 운영자는 피어별 경로 규칙이 테스트되었고, 고객 목표가 실패하기 전에 비정상 볼륨이 억제되었고, 관리가 독립 경로를 통해 도달 가능하게 유지되었고, 복구가 테스트된 범위 내에서 완료되었다고 말할 수 있다. 주소 목록이나 라우터 이름을 공개할 필요는 없다. 청사진을 노출하지 않고도 의미 있는 보증이 가능하다.

관계가 바뀌면 검토를 반복해야 한다. 새 공급자 제품, 확장된 주소 범위, 합병, 라우터 플랫폼, 트래픽 패턴은 이전 가정을 무효화할 수 있다. 예외에는 소유자와 만료가 있어야 한다. 긴급 상황이 끝났다는 이유만으로 일시적으로 허용된 경로가 영구적이 되어서는 안 된다.

조작된 비난 없는 책임성

“제3자 공급자”라는 표현은 실패를 클라우드 운영자 외부의 것처럼 들리게 할 수 있다. 운영상 경계는 공유된다. 한 당사자가 정보를 보냈고, 다른 당사자가 그 정보가 자사 네트워크에서 어떻게 활성화될지 결정했다. 공개 기록은 책임을 배분하지 않지만 두 행동이 모두 조사에 속하는 이유를 보여준다.

IBM의 고객에 대한 의무는 모든 업스트림 오류를 불가능하게 만드는 것이 아니었다. 그것은 비현실적이다. 실질적 의무는 비례적인 수용 규칙을 갖춘 경계를 운영하고, 고객 결과를 모니터링하고, 비정상 행동을 억제하고, 통제와 소통을 보존하는 것이었다. 공급자의 실질적 의무는 정확한 라우팅, 안전한 변경, 신속한 협력을 유지하는 것이었다. 계약은 조직 사이에 공백을 남기는 대신 이러한 의무를 연결해야 한다.

고객은 다른 형태의 책임성을 필요로 한다. 무엇이 영향을 받는지, 데이터 무결성이 관련되는지, 복구가 어떻게 진행되는지, 어떤 의존성을 피해야 하는지에 대한 시의적절한 설명이 필요하다. 서비스가 도달 불가능한 동안 근거 없는 기술 용어나 비난 경쟁은 고객에게 도움이 되지 않는다.

경영진과 공공 부문 고객은 클라우드 아키텍처가 네트워크 통제를 핵심 서비스로 취급하는지 물어야 한다. 워크로드는 여러 데이터센터에 걸쳐 실행되면서도 공통 라우팅 경계, 콘솔, 신원 서비스, 상태 경로에 의존할 수 있다. 논리적 분산이 운영상 독립성을 보장하지는 않는다. 관련 질문은 어떤 실패가 여전히 여러 개의 겉보기에는 분리된 서비스를 한 번에 제거할 수 있는가이다.

이것이 운영 현실의 핵심 교훈이다. 레지스트리, 계약, 도식은 의도된 관계를 설명한다. 실행 중인 구성과 관찰된 도달성이 서비스 작동 여부를 결정한다. 좋은 기록은 운영자가 의도와 실행을 비교하게 해주므로 필요하다. 그러나 실제로 전달되는 패킷 위에 군림하지는 않는다.

출처

  1. https://www.theregister.com/2020/06/11/ibm_blames_external_network_provider/
  2. https://techcrunch.com/2020/06/09/ibm-cloud-suffers-prolonged-outage/
  3. https://www.crn.com/news/cloud/ibm-blames-massive-cloud-outage-on-third-party-network-provider
  4. https://status.zellowork.com/issues/5ef227ab4a0ebd6da0cb113e
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://btw.media/en/directory/international-business-machines-corporation-united-states-of-america-the