OVH 2017 광네트워크 장애: 이중화 독립성과 책임성 검증

요약

사건 경계는 좁습니다:이 글은 2017년 11월 9일 루베(Roubaix) 광네트워크 장애만을 다룹니다. 같은 시간에 발생한 스트라스부르 전력 장애는 서로 다른 원리와 통제 사슬을 가진 별개의 사건이었습니다.
가시적 장애는 광범위했지만 전면적이지는 않았습니다:당시 기록은 루베에서 OVH의 네트워크 접점 6곳으로 향하는 연결성이 상실되었다고 서술했습니다. 이것이 OVH의 모든 경로, 고객 또는 워크로드가 같은 방식으로 실패했다는 증거는 아닙니다.
형식상의 이중화는 운영적 독립성을 제공하지 않았습니다:OVH는 이중화된 광연결을 갖추고 있었으나, 구성 상실 이후 루베 링크들은 함께 사용 불가능해졌고 저장된 구성에서 복구해야 했습니다.
공개된 근본 원인은 두 층위로 구성됩니다:OVH는 직접적 사건을 소프트웨어 결함과 광장비 구성 상실로 돌렸습니다. 동시에 경로 상실은 물리적 경로 이중화가 제거하지 못한 공유 구성·감독 장애 도메인의 존재를 드러냈습니다.
저장된 구성은 독립적인 복구 체계가 아니었습니다:저장된 구성이 복구를 가능하게 했지만, 그 존재만으로 실행 중인 광시스템의 가용성이 유지되지는 않았습니다. 백업 가용성, 복구 권한, 검증된 복구 가능성은 별도로 측정되어야 합니다.
책임은 통제권을 따릅니다:OVH는 아키텍처, 배포, 구성 보호, 모니터링, 복구, 고객 소통을 통제했습니다. 장비 제조사는 제품 결함 조사와 소프트웨어 수정을 통제했습니다. 피어·트랜짓 네트워크·고객은 자신들의 외부 이중화를 통제했지만, OVH의 내부 광 상태는 통제하지 못했습니다.
공표된 복구 계획은 두 문제를 올바르게 분리했습니다:OVH는 장비 제조사와 함께 소프트웨어 업그레이드를, 그리고 광 멀티플렉싱 시스템을 두 개의 시스템으로 분리하는 계획을 예고했습니다. 전자는 결함을, 후자는 재발 시 영향 반경을 제한하는 것이 목적이었습니다.
복구 계획은 발표만으로 입증되지 않습니다:신뢰할 수 있는 마무리에는 토폴로지와 구성 증거, 장애 주입 테스트, 독립적인 도달성 측정, 하나의 통제 실패가 더 이상 루베의 모든 외부 경로를 제거할 수 없다는 증명이 필요합니다.

책임을 배분하기 전에 루베 사건을 고정하라

OVH는 같은 날 두 건의 심각한 장애를 겪었습니다. 스트라스부르 사이트에는 전력 장애가, 루베에는 광네트워크 장애가 발생했습니다. OVH의 이후 성명은 두 사건을 동시 발생했지만 서로 무관한 것으로 명시적으로 서술했습니다. 이 구분은 책임성의 출발점이지, 더 큰 서사로 묶어버릴 세부사항이 아닙니다. [1]

두 사건을 결합하면 부정확한 인과 사슬이 만들어집니다. 스트라스부르는 전력 공급, 변환 장비, 발전기, 서비스 재시작이 문제였습니다. 루베는 광전송, 구성 상실, 외부 네트워크 위치로 향하는 연결성이 문제였습니다. 책임 시스템, 운영자, 벤더, 감지 신호, 복구 행위, 예방 테스트가 서로 달랐습니다.

따라서 이 글은 루베 광 장애에서 시작하여 관련 링크와 호스팅 사이트 연결성이 복구된 시점, 그리고 OVH가 발표한 루베 전용 복구 조치에서 끝납니다. 스트라스부르 전력 사건, 2017년 7월 스토리지 사건, 이후 2017년 12월의 네트워크 사건, 2021년 스트라스부르 화재, 별개의 2021년 라우팅 사건은 제외합니다. 이들 사건은 OVH의 더 넓은 역사를 이해하는 데 도움이 될 수 있으나, 루베 광 장애의 원인이나 복구에 대한 증거로 사용될 수 없습니다.

공개 연대기에는 두 가지 유용한 층위가 있습니다. OVH의 공식 성명은 루베 사이트가 2시간 30분 이내에 운영으로 복귀했다고 밝혔습니다. 영향을 받은 서비스 제공사는 별도로 같은 날 아침 고객에게 가시적인 도달 불가 상태를 기록하고, 광 구성이 회복된 이후 복구가 이루어졌다고 서술했습니다. [1][4]

이 두 기록은 서로 다른 층위에서 광 복구 시간창을 서술합니다. 모든 고객 서비스가 정확히 같은 시점에 회복되었다는 뜻은 아닙니다. 호스팅 사이트는 하나의 스택입니다. 전송 링크가 돌아오고, 라우팅 세션이 재수립되고, 경로가 수렴하며, 로드밸런서와 애플리케이션 의존성이 회복하고, 메일 큐가 비워지고, 모니터링이 정상화되며, 고객이 재시도합니다. 공개 증거에는 서비스별 복구표가 완전하게 담겨 있지 않습니다.

같은 원칙은 사건의 시작 지점에도 적용됩니다. 영향을 받은 서비스 제공사는 아침 장애 동안 일부 네트워크에서는 접근이 가능했지만 다른 네트워크에서는 불가능했다고 서술했고, OVH는 제공사 측 광 장애와 이후 복구를 서술했습니다. 이 두 시각은 반드시 모순되는 것이 아닙니다. 하나는 외부 고객이 관찰한 효과를 기록하고, 다른 하나는 제공사의 광 시스템에서 발생한 사건을 기록합니다. 서로 다른 관측자, 시계, 네트워크 경로는 서로 다른 경계를 볼 수 있습니다. [4]

책임성은 하나의 완벽한 시각을 강요하는 대신 이러한 구분을 보존하는 데 있습니다. 강한 인시던트 기록은 외부 프로브, 광 경보, 인터페이스 전이, 컨트롤러 로그, 라우팅 세션 변화, 고객 보고를 공통 시계에 맞춰 대조할 것입니다. 공개 자료는 그런 완전한 대조를 제공하지 않으므로, 이 글은 그것을 지어내지 않습니다.

실행 중인 네트워크가 드러낸 것

영향을 받은 서비스 제공사의 서술에 따르면, 루베 사이트는 OVH의 네트워크 접점 6곳으로 향하는 광전송에 의존하고 있었습니다. 공개 기록은 복수의 광경로와 광범위한 외부 연결성 상실을 서술하지만, 모든 회선, 고객 경로 또는 의존성에 대한 완전하고 검증된 토폴로지를 제공하지는 않습니다. [4]

이러한 세부가 중요한 이유는, 이 사건이 일상적인 단일 광섬유 절단으로 제시되지 않았다는 점을 보여주기 때문입니다. OVH와 당시 기록은 오히려 광 시스템에 영향을 준 소프트웨어 및 구성 장애, 그리고 장비 제조사와의 복구 작업을 서술했습니다. 이용 가능한 출처는 완전한 진단 순서나 내부 관리평면 상태를 노출하지 않습니다. [1][4]

공개된 근본 원인 서술은 광장비의 구성 상실을 밝혔습니다. OVH는 저장된 구성을 회복하여 영향받은 연결성을 복구했습니다. 회사는 직접적 사건을 소프트웨어 결함으로 돌리는 한편, 상관된 경로 상실은 공유 구성 및 감독 의존성에 관한 더 넓은 문제를 노출했습니다. [1][4]

이것은 의미 있는 서술이지만 완전한 포렌식 보고서는 아닙니다. 정확한 소프트웨어 버전, 초기 상태 변화, 프로세스 크래시, 스토리지 순서, 복제 의미론, 제어평면 선출, 인적 명령, 경보 연대기, 내부 인시던트 기록을 공개하지 않습니다. 구성 상실이 유일한 초기 원인이었는지, 아니면 더 깊은 통제 실패의 가시적 결과 중 하나였는지 증명하지도 않습니다.

가장 강한 방어 가능한 서술은 더 좁습니다. OVH의 광장비는 루베 외부 링크가 사용 불가능한 상태에 진입했고, OVH는 그 상태를 소프트웨어 결함과 구성 결여로 돌렸으며, 저장된 구성의 복구가 연결성을 되찾았고, OVH는 이후 소프트웨어 조치와 아키텍처 분리를 모두 제안했습니다.

실행 중인 네트워크가 일차 증거입니다. 자산 기록은 광섬유, 경로, 카드, 백업이 존재한다고 말할 수 있습니다. 설계 문서는 링크가 이중화되어 있다고 말할 수 있습니다. 사건 중 중요했던 것은 광 시스템이 루베의 도달성에 필요한 외부 연결성 제공을 멈췄다는 사실입니다. 운영 상태가 명목상의 다이어그램을 압도했습니다.

이것이 네트워크 인프라 책임성의 핵심 쟁점입니다. 이중화는 구성 요소 수만으로 세어서는 안 되며, 서비스를 제거할 수 있는 장애 도메인으로 평가해야 합니다.

물리적 다양성은 통제 도메인의 독립성이 아니다

탄력적 전송의 흔한 시각적 모델은 두 위치 사이의 두 회선입니다. 한 광섬유가 절단되면 트래픽이 다른 쪽을 사용합니다. 이 모델은 좁은 물리적 위험에는 유용합니다. 그러나 두 경로가 소프트웨어, 구성 권한, 감독 하드웨어, 타이밍, 전력, 관리 접근, 활성화 로직 또는 공통 복구 절차를 공유한다면 불완전합니다.

지리적으로 구분된 두 개의 광경로도 하나의 운영적 장애 도메인에 속할 수 있습니다. 같은 데이터베이스가 지배하는 카드에 종단할 수 있고, 같은 컨트롤러나 감독 쌍에 의존할 수 있으며, 같은 결함 소프트웨어 이미지를 받을 수 있고, 하나의 구성 트랜잭션을 상속할 수 있으며, 진단을 위해 하나의 관리 네트워크를 요구할 수 있고, 공통 안전 상태 진입 시 함께 닫힐 수 있습니다.

OVH의 사례는 바로 이 구분의 구체적 예입니다. 제공사는 이중화된 광연결을 서술했으나, 구성이 상실되었을 때 루베 링크들은 함께 사용 불가능해졌습니다. 연결성을 보존하려던 통제는 실제로 발생한 공유 구성 상태 장애를 담아내지 못했습니다. [1][4]

이것이 물리적 다양성이 무의미했다는 뜻은 아닙니다. 다른 위험을 다루었다는 뜻입니다. 탄력성 주장은 자신이 담아내는 위험 등급을 명명해야 합니다:

단일 광섬유 절단;
콘듐이트 또는 지리적 경로 실패;
광증폭기 또는 노드 하나의 상실;
라인 카드 또는 섀시 하나의 상실;
컨트롤러 또는 모니터링 카드 하나의 실패;
손상되었거나 결여된 구성;
공통 소프트웨어 결함;
관리 연결성 상실;
이중화된 시스템 전반에 전파된 운영자 오류;
인시던트 조건 하에서의 복구 실패.

설계가 앞의 세 가지는 통과하면서 여섯째 또는 일곱째 항목에서 실패할 수 있습니다. 보호 대상 장애 등급을 명명하지 않은 채 결과를 "이중화"라 부르면 가장 중요한 질문이 감춰집니다.

RFC 3439는 일반적 아키텍처 관점에서 복잡성에는 실제 비용이 있으며 시스템은 예상치 못한 상호작용에서 실패하는 경우가 많다고 경고합니다. 이 문서는 OVH의 사건에 대해 쓰인 것이 아니며 제공사의 내부 설계를 증명하지도 않습니다. 다만 유용한 분석 원칙을 제공합니다. 구성 요소, 복제본, 자동화를 추가하면 그 동작이 경계 지어지고 관측 가능하지 않는 한 공유 상태와 추가 장애 모드가 생길 수 있습니다. [14]

NIST의 사이버 탄력 시스템 지침 역시 탄력성을 예측, 견딤, 회복, 적응하는 공학적 능력으로 다룹니다. 이는 후기 프레임워크이며 2017년 OVH가 배치한 것의 증거가 아닙니다. 신중하게 적용하면, 네트워크는 예방 주장뿐 아니라 성능 저하 경계, 복구 권한, 증거 보존, 장애 이후의 적응으로 판단되어야 한다는 시사점을 줍니다. [17]

ITU 권고가 서술하는 광전송 아키텍처는 계층, 트레일 관계, 보호에 관한 어휘를 제공합니다. 이를 통해 공개 사실만으로 OVH의 사설 토폴로지를 재구성할 수는 없습니다. 여기서의 가치는 일반적 명제를 강화하는 것입니다. 광전송은 수동적인 유리가 아니라 제어, 감독, 복구 기능을 갖춘 관리되는 네트워크입니다. [18]

따라서 책임성 시험은 복제가 아니라 독립성입니다. 운영자는 어떤 요소가 독립적인지, 어떤 요소가 의도적으로 공유되는지, 그리고 각 공유 요소가 실패하면 무엇이 일어나는지 식별할 수 있어야 합니다.

저장된 구성은 운영적 가용성과 같지 않았다

OVH의 인시던트 서술은 저장된 구성이 복구되었다고 말합니다. 이 세부는 인프라 보증에서 반복되는 문제를 보여줍니다. 백업의 존재가 종종 복구 가능성과 동등하게 취급된다는 것입니다.

백업은 존재하면서도 서비스를 보존하는 데 실패할 수 있습니다. 같은 장애 도메인 안에 저장되어 있을 수 있습니다. 그 복제본이 같은 결함 소프트웨어의 영향을 받을 수 있습니다. 같은 손상된 상태를 포함할 수 있습니다. 시스템이 이를 자동으로 선택하거나 적재하지 못할 수 있습니다. 관리 접근이 불가능할 수 있습니다. 운영자의 물리적 개입이 필요할 수 있습니다. 복구 절차가 느리거나, 모호하거나, 공통 장애 상황에서 검증되지 않았을 수 있습니다.

루베 서술에 따르면 엔지니어들은 결국 저장된 구성을 회복했습니다. 이는 성공적인 복구 행위였습니다. 동시에, 복구 가능한 구성이 존재했다는 이유만으로 실행 중인 시스템이 가용성을 유지하지는 않았음을 보여줍니다. [1][4]

따라서 관련 통제는 "백업이 존재했다"보다 더 정밀합니다:

정확히 어떤 객체가 복사되었는가: 완전한 데이터베이스, 생성된 구성, 장치 상태, 트랜잭션 로그?
각 복사본을 어떤 프로세스가 기록했으며, 하나의 소프트웨어 결함이 모두를 손상시킬 수 있었는가?
복사본은 불변이었거나 독립적으로 버전 관리되었는가?
물리적·논리적으로 분리된 시스템에 저장되었는가?
복사본의 사용 가능 여부를 결정한 일관성 규칙은 무엇이었는가?
실패한 관리 구성 요소 없이 검증된 정상 버전을 선택할 수 있었는가?
복구는 자동이었는가, 운영자 승인이 필요했는가, 현지 접근에 의존했는가?
마지막 테스트에서 전체 복구에 얼마나 걸렸는가?
복구는 의도된 상태를 재현했는가, 아니면 마지막 복제 상태만을 재현했는가?
모든 광 노드와 라우터 측 링크가 정상적으로 돌아왔음을 확인한 증거는 무엇이었는가?

공개 자료는 이 목록의 일부만 답합니다. 구성 복구가 가능했다는 것은 보여줍니다. 복구가 독립적이었고, 사전 승인되었고, 정기적으로 훈련되었고, 서비스 목표와 대비해 측정되었다는 것은 보여주지 않습니다.

이 구분은 고객 및 이사회 보고에도 영향을 줍니다. "구성이 백업되었다"는 자산 서술입니다. "검증된 정상 구성을 독립적인 통제 경로를 통해 시험된 시간 안에 복구할 수 있으며, 그 과정에서 증거를 보존하고 장애 상태의 재유입을 막는다"는 운영 통제 서술입니다.

광전송은 호스팅 서비스의 일부였다

호스팅 책임성은 서버 또는 데이터센터 수준에서 논의되는 경우가 많습니다. 루베 장애는 그 경계가 너무 좁음을 보여줍니다. 서버는 전원과 건강 상태를 유지하면서도, 사이트를 외부 상호접속 지점과 연결하던 광전송이 실패하여 도달 불가 상태가 될 수 있습니다.

OVH의 공개 피어링 자료와 현재의 PeeringDB 및 RIPE 기록은 AS16276과 상당한 상호접속 규모를 식별합니다. 이 기록들은 네트워크 식별과 운영자 귀속에 유용합니다. 고객이나 조사자가 OVH의 네트워크를 다른 제공자와 구분하고 상호접속이 일어날 수 있는 위치를 파악하는 데 도움을 줍니다. 그러나 2017년 루베 회선의 운영 상태, 특정 패킷이 사용한 경로, 임의의 두 고객 서비스의 독립성을 증명하지는 않습니다. [8][9][10][11]

이것은 실재 층위의 구분입니다. 레지스트리나 디렉터리는 누가 자율 시스템을 운영하는지 기록할 수 있습니다. 피어링 페이지는 정책을 서술할 수 있습니다. 경로 수집기는 선별된 BGP 관측을 보존할 수 있습니다. 그중 어느 것도 실패한 광 시스템으로 하여금 트래픽을 전달하게 만들지 못합니다.

반대로, 광 장애가 네트워크 식별을 지우지는 않았습니다. AS 번호, 경로, 외부 관계는 어느 네트워크가 트래픽을 발신·전달해야 하는지 진단하는 데 의미 있는 증거로 남았습니다. 기록과 실행 중인 인프라는 서로 다른 책임 기능을 수행합니다. 기록은 권한을 식별하고 보존하며, 실행 시스템은 패킷이 움직이는지 여부를 결정합니다.

"이중화된" 호스팅이나 한 제공자로부터의 복수 서비스를 구매하는 고객은 자신의 의존성이 제공자 내부에서 수렴하는지 물어야 합니다. 별도 클러스터의 두 가상 머신이 같은 사이트 전송을 공유할 수 있습니다. 다른 건물의 두 서비스가 같은 메트로 광 시스템을 공유할 수 있습니다. 광고된 두 경로가 하나의 컨트롤러나 구성 데이터베이스로 수렴할 수 있습니다. 제품명과 자원 수는 이러한 의존성을 드러내지 않습니다.

Actility 보고는 교훈적인 외부 시각을 제공합니다. 일부 서비스는 도달 불가였지만 다른 데이터센터에 호스팅된 SaaS 제품은 영향받지 않았다고 밝히는 한편, 일부 위치나 네트워크에서는 도달 가능했고 다른 곳에서는 불가능했다고 서술했습니다. [4] 이 패턴은 의존성과 경로 이중화와 일치하지만, 공개 자료만으로 모든 경로나 서비스를 매핑하기에 충분하지는 않습니다.

고객의 교훈은 단순히 "두 제공자를 사용하라"가 아닙니다. 복수 제공자 설계는 집중도를 낮출 수 있지만, 그 자체의 DNS, 라우팅, 데이터 일관성, 보안, 운영 복잡성을 만듭니다. 더 강한 요구사항은 의존성 경계를 문서화하고 중요한 장애를 테스트하는 것입니다.

영향은 관측 가능한 증거에 묶여 있어야 한다

OVH는 다른 서비스에 대한 직접적인 결과를 인정하고, 고객 이메일 수신이 특히 어려웠다고 밝혔습니다. 회사는 사과하며 팀이 계속 대응 중이라고 말했습니다. [1] 당시 보도는 루베 환경 전반의 상당한 고객 영향을 서술했습니다. [5][6][7]

공개 출처는 완전한 영향받은 고객 수, 패킷 손실 시계열, 경로별 분석, 서비스 목록, 매출 영향, 최종 SLA 표를 제공하지 않습니다. 루베의 모든 워크로드가 광 장애 구간 전체에 걸쳐 도달 불가였다는 것을 증명하지도 않습니다. 하나의 공개 프로브가 성공했다는 이유만으로 서비스가 건강했다는 것을 증명하지도 않습니다.

서로 다른 네트워크는 서로 다른 동작을 관측했을 수 있습니다. 라우팅 정책, 캐시된 DNS 응답, 기존 세션, 대체 서비스 위치, 애플리케이션 재시도 로직이 모두 가시적 영향에 영향을 줄 수 있습니다. 일부 고객은 모든 접근을 잃었을 수 있습니다. 다른 고객은 남은 경로나 별도 사이트를 통해 서비스에 도달했을 수 있습니다. 이메일은 큐에 쌓여 나중에 도착할 수 있어, 전송 실패가 영구 손실이 아니라 지연으로 나타날 수 있습니다.

올바른 영향 서술은 세 층위를 갖습니다:

제공자가 보고한 인프라 영향:OVH의 서술에서 루베 사이트는 외부 광 링크를 잃었습니다.
외부에서 관측된 서비스 영향:고객과 최소 한 곳의 호스팅 제공사가 부분적 또는 광범위한 도달 불가와 특정 서비스 중단을 보고했습니다.
미상의 완전한 영향:공개 기록은 영향받은 모든 고객, 흐름, 경로, 서비스, 재무 결과를 열거하지 않습니다.

이 층위를 보존하면 과소 진술과 과장을 모두 막을 수 있습니다. 완전한 영향이 미상이라고 말하는 것이 사건을 축소하는 것이 아닙니다. 사이트의 주요 광 링크 상실은 본질적으로 심각합니다. 또한 증거가 지지하지 않는 전면 장애를 주장할 필요도 없습니다.

책임 있는 영향 보고는 독립 네트워크의 시간 경계가 있는 도달성, BGP 세션 상태, 링크 가용성, 집계 트래픽, 메일 적체, 주요 서비스 건강 상태, 고객 티켓 수, 복구 분포를 공표할 것입니다. 샘플링 한계와 시계를 서술할 것입니다. 전송 복구와 애플리케이션 복구를 분리할 것입니다.

통제 배분: 분산된 책임은 부재한 책임이 아니다

네트워크 인프라는 조직 경계를 넘습니다. 그 결과 책임이 "공유되었다"는 모호한 결론에 이르기 쉽습니다. 더 나은 방법은 통제에 따라 책임을 배분하는 것입니다.

OVH

OVH는 루베 광네트워크의 아키텍처, 물리 경로와 제어 시스템 사이의 관계, 그 범위 내의 소프트웨어 배포, 구성 보호, 모니터링, 인시던트 에스컬레이션, 현지 개입, 복구 순서, 고객 소통, 설계 변경 결정을 통제했습니다.

이 통제는 구체적 의무를 만듭니다. OVH는 공통 장애 도메인을 식별하고, 소프트웨어를 안전하게 스테이징하고, 검증된 정상 구성을 보존하고, 독립적인 진단 경로를 유지하고, 복구를 테스트하고, 고객 기대치를 설정하고, 수정된 설계가 재발을 담아낸다는 증거를 만들어야 했습니다.

OVH가 장비 소프트웨어 결함을 만들었을 필요는 없습니다. 그렇다고 아키텍처 책임이 사라지지는 않습니다. 운영자는 하나의 벤더 결함이 자신의 서비스에 어떻게 영향을 줄지 선택합니다. 결함이 모든 이중화 경로에 도달하는지, 롤백이 가능한지, 실패한 컨트롤러를 우회할 수 있는지를 결정합니다.

장비 제조사

장비 제조사는 제품 엔지니어링, 결함 분석, 수정된 소프트웨어, 벤더 진단, OVH에 제공되는 공개 범위를 통제했습니다. 공개 기록에 따르면 OVH는 제조사와 조사 중이었고 영향받은 소프트웨어의 업그레이드를 계획했습니다. [1][4]

공개된 벤더 보고서가 없는 한, 이 글은 정확한 소프트웨어 오류를 배분하거나 결함이 사전에 알려져 있었는지 단언할 수 없습니다. 그럼에도 제조사는 구성이 사라지거나 사용 불가능해진 이유를 규명하고 수정된 코드가 이 장애를 막음을 입증하는 제품 측 과제를 담당했습니다.

피어와 트랜짓 제공자

외부 네트워크 운영자는 자신들의 링크, BGP 세션, 경로 선호, 모니터링, 에스컬레이션을 통제했습니다. OVH 도달성의 상실을 관측하고, 대체 상호접속이 존재하는 곳에서는 적응할 수 있었습니다. 그러나 OVH의 내부 광 구성을 복구할 수는 없었습니다.

명시적 임포트·엑스포트 정책 같은 BGP 운영 관행은 도메인 간 경계에서 필수적입니다. RFC 7454와 RFC 8212는 후기 또는 일반적 라우팅 보호 장치이며, 이 광 사건의 진단이 아닙니다. 중요한 이유는 광의 복귀만으로 올바른 경로 교환이 증명되지 않기 때문입니다. 인터페이스가 복귀한 뒤 명시적 라우팅 정책은 경로 복구가 경계 내에 머물도록 돕습니다. [15][16]

고객

고객은 제공자 선택, 서비스 배치, 외부 모니터링, DNS 및 애플리케이션 페일오버, 데이터 복제, 자신의 인시던트 소통을 통제했습니다. OVH에서 여러 제품을 구매한 고객은 그 제품들이 루베 광 장애 도메인을 공유하지 않는다는 증거를 요구할 수 있었습니다.

고객은 OVH의 내부 광장비 상태, 구성 시스템, 광 토폴로지를 통제하지 못했습니다. 더 많은 이중화를 구매할 수 있었다는 이유로 제공자의 내부 전송 실패를 고객에게 돌리는 것은 잘못입니다. 고객의 탄력성과 제공자의 책임성은 보완 관계이지 대체 관계가 아닙니다.

규제자, 디렉터리, 관측자

레지스트리, ASN, 피어링 기록은 귀속과 역사 분석을 지원합니다. 측정 플랫폼은 선별된 라우팅 관측을 보존할 수 있습니다. 표준화 기구는 유용한 설계·운영 원칙을 정의합니다. 그러나 그중 어느 것도 루베 시스템을 운영하지 않았고 복구할 수도 없었습니다.

이 배분은 두 오류를 피합니다. 첫째는 벤더 버그를 제공자 실패의 완전한 면죄부로 다루는 것입니다. 둘째는 OVH 경계 밖의 고객 및 상호접속 통제를 인정하지 않고 모든 결과를 OVH에 돌리는 것입니다. 책임성은 예방, 감지, 봉쇄, 회복, 입증할 수 있는 능력을 따릅니다.

감지와 진단도 통제 표면의 일부다

공개 기록은 최초 내부 경보, 그 타임스탬프, 심각도, 소유자, 진단 품질을 공개하지 않습니다. 고객이 도달 불가를 보았고 OVH가 팀을 동원했다는 것은 알 수 있습니다. 모니터링이 광전송 상실, 관리 실패, 라우팅 세션 상실, 트래픽 붕괴, 고객 증상 중 무엇을 먼저 식별했는지는 알 수 없습니다.

이 결여된 증거는 중요합니다. 감지 설계가 중단 시간에 영향을 주기 때문입니다. "호스트 도달 불가"라는 경보는 광 컨트롤러 상태, 데이터베이스 건강, 카드 모드, 관리 도달성, 라우터 인터페이스 상태, 외부 경로 상실을 함께 보여주는 상관 기록보다 유용성이 떨어집니다.

공통 통제 실패는 모니터링 자체도 무력화할 수 있습니다. 모니터링 카드, 관리 네트워크, 구성 서비스가 같은 장애 도메인을 공유하면, 시스템은 서비스와 설명적 텔레메트리를 함께 잃을 수 있습니다. 엔지니어는 그때 어두운 장애에 직면합니다. 광범위한 증상, 불완전한 원격 접근, 휘발성 증거가 보존되기 전 장비 재시작 압박입니다.

독립적 진단 경로는 같은 제어평면의 두 번째 인터페이스만을 의미해서는 안 됩니다. 별도로 전력 공급되고 관리되는 접근, 최소 의존성, 알려진 보안 경계, 주 시스템이 손상되었을 때 상태를 캡처할 수 있는 능력이 필요합니다.

설계에는 운영 권한도 필요합니다. 누가 구성을 재설정할 수 있는가? 어떤 증거를 먼저 캡처해야 하는가? 어떤 검증된 정상 버전을 적재할 수 있는가? 언제 현지 개입이 필요한가? 재시작의 위험을 지속 중단과 어떻게 저울질하는가? 존재하지만 빠르게 승인될 수 없는 복구 계획은 유효한 통제가 아닙니다.

루베 서술은 광 시스템 복구가 백업의 존재를 관측하는 것 이상을 요구했음을 보여줍니다. [4] 이것은 복구 시간을 아키텍처 파라미터로 만듭니다. 복구가 여러 구성 요소의 재시작과 순서화에 의존한다면, 그 의존성은 탄력성 테스트와 서비스 목표에 나타나야 합니다.

공표된 복구는 결함 수정과 영향 반경 통제를 분리했다

OVH의 루베 공식 조치 계획은 두 부분이었습니다. 장비 제조사와 함께 소프트웨어 결함을 조사·수정하기 위한 업그레이드를 계획했고, 광 멀티플렉싱 시스템을 두 개의 별개 시스템으로 분배하여 장애 범위를 제한하는 프로젝트를 가속했습니다. [1]

이 구분은 기술적으로 중요합니다. 소프트웨어 수정은 알려진 결함을 다룹니다. 아키텍처 분리는 불확실성, 즉 또 다른 결함이나 다른 공통 통제 실패의 가능성을 다룹니다.

소프트웨어 패치는 전체 장애 등급이 사라졌음을 증명할 수 없습니다. 코드의 한 경로를 고치면서 공유 구성, 감독, 관리 의존성은 그대로 둘 수 있습니다. 반대로, 알려진 결함을 고치지 않은 채 시스템을 나누면 같은 소프트웨어와 상태가 동일하게 배치될 경우 두 개의 독립적으로 실패하는 시스템을 만들 수 있습니다.

따라서 강한 복구 프로그램은 두 차원을 모두 테스트합니다.

결함 수정

벤더 권고 또는 결함 기록을 영향받은 소프트웨어 버전에 연결한다.
정확한 장애 조건, 영향받은 구성 요소, 수정된 동작을 식별한다.
수정된 이미지를 대표 시스템에 스테이징한다.
구성 마이그레이션, 롤백, 상태 보존을 검증한다.
이전에 구성 상실을 일으켰던 조건을 실행한다.
장애가 더 이상 발생하지 않음을 보여주는 로그를 보존한다.

장애 도메인 분리

어떤 광경로가 어느 시스템에 종단하는지 문서화한다.
필요한 곳에서 제어, 모니터링, 구성 저장, 관리 접근을 분리한다.
하나의 구성 트랜잭션이 두 시스템을 모두 무력화하지 못하게 한다.
소프트웨어 배포를 카나리로 수행하고 모든 경로에 도달하기 전에 중단할 수 있게 한다.
한 시스템의 상실이 정의된 서비스 목표에 충분한 외부 용량과 도달성을 남긴다는 것을 증명한다.
축소된 토폴로지 하에서 트래픽 이동과 라우팅 수렴을 테스트한다.

복구 증거

실패한 제어 구성 요소에 의존하지 않고 검증된 정상 구성을 복구한다.
감지, 결정, 복구, 링크 복귀, 경로 수렴 시간을 측정한다.
복구 전후 체크섬과 토폴로지 상태를 보존한다.
내부 링크 상태를 독립적인 외부 프로브와 비교한다.
첫 성공적인 핑에서 전부 정상을 선언하는 대신 잔여 오류를 기록한다.

OVH의 공개 성명은 분리 실시 의도를 문서화합니다. 이 글을 위해 고정된 출처는 완료일, 구현 다이어그램, 독립 테스트, 이후 재발 훈련을 제공하지 않습니다. 책임 있는 결론은 공표된 방향이 올바른 통제 구분을 다루었으나, 그 효과는 이 기록에서 입증되지 않았다는 것입니다.

이중화 독립성을 검증하는 방법

운영자는 장애 도메인 매트릭스를 구성하여 인시던트를 반복 가능한 감사로 만들 수 있습니다. 고객과 관련된 각 경로를 물리 경로, 광 노드, 라인 카드, 섀시, 감독 시스템, 구성 저장소, 소프트웨어 릴리스, 관리 네트워크, 전력, 타이밍, 운영자 그룹, 복구 권한에 대해 매핑합니다.

매트릭스는 "이중화된" 각 경로 쌍에 대해 하나의 단순한 질문에 답해야 합니다. 어느 구성 요소가 여전히 둘 다를 제거할 수 있는가?

이 분석은 토폴로지 다이어그램에 가려진 의존성을 자주 드러냅니다. 별개 광섬유가 같은 건물로 들어올 수 있습니다. 별개 섀시가 하나의 컨트롤러를 사용할 수 있습니다. 별개 컨트롤러가 하나의 데이터베이스 클러스터를 공유할 수 있습니다. 별개 소프트웨어 인스턴스가 공통 자동화 파이프라인에서 하나의 잘못된 구성을 받을 수 있습니다. 별개 데이터센터가 하나의 DNS, 신원, 네트워크 제어 서비스에 의존할 수 있습니다.

매트릭스는 테스트되기 전까지는 가설일 뿐입니다. 유용한 테스트는 다음과 같습니다:

광섬유 하나를 제거하고 자동 광 보호를 검증한다;
섀시 하나를 제거하고 용량이 선언된 목표 안에 유지됨을 검증한다;
컨트롤러 하나를 격리하고 다른 시스템이 위험한 상태 수렴 없이 계속됨을 검증한다;
구성 복제본 하나를 손상시키거나 제거하고 안전한 선택을 검증한다;
주 관리 경로를 차단하고 독립 경로로 진단을 수행한다;
의도적으로 거부된 소프트웨어 이미지를 카나리에 배포하고 배포 봉쇄를 검증한다;
시간 압박 하에서 검증된 정상 구성을 복구한다;
독립 네트워크에서 BGP와 데이터평면 수렴을 측정한다;
고객 대면 상태가 장치 건강이 아니라 관측된 서비스를 반영하는지 검증한다;
외부 검토자가 결론을 재현할 수 있을 만큼의 증거를 보존한다.

합격 조건은 테스트 전에 정의되어야 합니다. "트래픽이 회복되었다"는 너무 모호합니다. 유용한 조건은 최소 용량, 최대 도달성 상실, 허용 패킷 손실, 수렴 시간, 서비스 등급, 외부 관측 지점, 증거 보존 요건을 명시합니다.

테스트는 유지보수도 고려해야 합니다. 많은 공통 실패는 이중화된 시스템이 의도적으로 정렬되는 업그레이드나 구성 변경 중에 발생합니다. 무작위 카드 상실을 견디는 설계라도, 공통 자동화 작업이 같은 잘못된 상태를 양쪽에 밀어넣으면 실패할 수 있습니다.

독립 운영이 모든 구성 요소를 다르게 만들 것을 요구하지는 않습니다. 완전한 이질성은 복잡성과 오류를 오히려 늘릴 수 있습니다. 요구되는 것은 공유 의존성이 명시적이고, 경계 지어지고, 검증된 복구와 맞물리는 것입니다. 목표는 다양성 연극이 아니라, 하나의 그럴듯한 실패가 이중화라고 광고된 모든 경로를 조용히 무력화할 수 없다는 증거입니다.

가정적 통제는 첫 놓친 기회를 명확히 한다

가정적(counterfactual) 분석은 하나의 통제가 사건을 반드시 막았을 것이라고 가장해서는 안 됩니다. 관측 가능한 통제가 어디서 순서를 바꿀 수 있었는지 묻는 것입니다.

소프트웨어 결함이 배포 전에 잡혔더라면

대표적인 스테이징 환경, 카나리 배포, 벤더 결함 테스트가 프로덕션 시스템에 도달하기 전에 실패 상태를 드러냈을 수 있습니다. 공개 증거는 결함이 스테이징에서 재현 불가능한 희귀 순서를 요구했는지 알려주지 않습니다. 따라서 이 가정은 가능성이지 입증이 아닙니다.

광 시스템이 독립적인 제어 상태를 가졌더라면

두 경로 그룹이 별개의 구성 권한과 감독 시스템을 가졌다면, 하나의 구성 데이터베이스 상실은 다른 그룹을 운영 상태로 남겼을 수 있습니다. OVH가 발표한 시스템 분리는 회사가 공통 장애 범위 축소의 가치를 보았음을 시사합니다. 사건 이전의 정확한 토폴로지는 공개되지 않아, 이 가정의 크기는 계산할 수 없습니다.

구성 복구에 독립 경로가 있었더라면

검증된 정상, 불변 구성과 대역 외 복구 메커니즘은 진단·복구 시간을 줄였을 수 있습니다. 인시던트 서술은 저장된 구성이 결국 복구되었다고 말합니다. 독립적인 복구 경로가 존재했는지, 어떻게 테스트되었는지, 복구의 어느 부분이 영향받은 제어 환경에 의존했는지는 보여주지 않습니다.

고객이 독립적인 호스팅 경로를 가졌더라면

다른 데이터센터나 제공자를 사용하는 고객은 일부 서비스 영향을 피할 수 있었습니다. Actility는 다른 데이터센터에 호스팅된 SaaS 제품은 영향받지 않았다고 보고했습니다. [4] 이 관측은 의존성 분산을 지지하지만, 모든 멀티사이트 설계가 성공했으리라는 증명은 아닙니다.

외부 도달성 증거가 통합되었더라면

독립 프로브와 라우팅 관측은 로컬 장치 복구와 고객 도달성을 구별하는 데 도움이 됐을 수 있습니다. 광 링크를 복구하지는 못했을 것입니다. 그 가치는 더 빠른 진단, 범위가 지정된 소통, 더 강한 마무리 입증이었을 것입니다.

첫 놓친 기회를 공개 증거로 확정할 수는 없습니다. 소프트웨어 보증, 아키텍처, 구성 상태 보호, 모니터링, 복구 설계 또는 그 조합이었을 수 있습니다. 사설 인시던트 기록은 권한을 갖고 합리적으로 행동할 수 있었던 가장 이른 통제를 식별해야 합니다.

결론을 바꿀 증거

결론은 의도적으로 반증 가능합니다. 더 강한 증거가 나타나면 바뀌어야 합니다.

장치 및 컨트롤러 로그는 구성 상실이 원인이 아니라 결과였음을 보여줄 수 있습니다. 벤더 보고서는 특정 하드웨어 또는 소프트웨어 조건을 식별할 수 있습니다. 토폴로지 기록은 광경로가 공개 서술이 시사하는 것보다 더 독립적이었음을, 또는 다른 공유 구성 요소가 그것들을 제거했음을 보여줄 수 있습니다. 구성 이력은 인적 변경, 자동화 작업, 상태 전이가 사건을 촉발했음을 보여줄 수 있습니다.

고객 및 측정 데이터는 영향 경계를 수정할 수 있습니다. 완전한 도달성 분석은 루베의 거의 전면적 고립 또는 상당한 잔여 연결성을 보여줄 수 있습니다. BGP 수집기 데이터는 어떤 외부 세션과 경로가 변했는지 확정할 수 있으나, 전달 결론을 뒷받침하려면 여전히 데이터평면 측정이 필요합니다.

복구 증거는 책임성 판단을 강화하거나 약화시킬 수 있습니다. 컨트롤러 및 구성 실패 하에서 독립적으로 테스트된 완료된 시스템 분리는 OVH가 교훈을 봉쇄로 전환했음을 보여줄 것입니다. 두 시스템이 여전히 하나의 장애 도메인을 공유함을 보여주는 이후 테스트는 복제가 독립성을 가져오지 못했음을 보여줄 것입니다.

이 글은 심각한 네트워크 장애가 발생했다는 서술을 위해 그런 기록을 요구하지 않습니다. 그 기록은 복구 주장을 완전하게 만들기 위해 요구됩니다.

결론

OVH의 루베 중단은 이중화가 무익하다는 교훈이 아니었습니다. 이중화는 자신이 담아낼 수 있는 장애의 관점에서 서술되어야 한다는 교훈이었습니다.

제공자는 이중화된 광연결과 저장된 구성을 갖추고 있었습니다. 이 통제는 실제 위험을 다루었습니다. 그러나 공통 광 제어 실패가 루베 연결성을 제거하는 것을 막지 못했고, 복구는 여전히 구성 회복에 의존했습니다.

OVH의 이후 조치 계획은 문제의 두 층위를 인식했습니다. 소프트웨어 결함을 고치고, 광 멀티플렉싱 시스템을 나누어 하나의 실패가 더 작은 범위를 갖게 하는 것입니다. 올바른 개념적 분리였습니다. 이 출처 집합의 공개 증거는 완료나 재발 저항을 증명하지 않습니다.

호스팅 및 네트워크 운영자에게 책임성 기준은 구체적입니다. 보호 대상 장애 등급을 명명하라. 공유 통제 도메인을 매핑하라. 독립 진단과 검증된 정상 복구를 보존하라. 한 시스템이 트래픽을 나르는 동안 그 시스템의 상실을 테스트하라. 제공자 바깥에서 도달성을 측정하라. 구성 요소 복제와 운영적 독립성을 구별할 만큼의 증거를 공표하라.

네트워크 식별 기록과 토폴로지 자산 목록은 누가 인프라를 운영하는지, 무엇이 존재해야 하는지 보여줄 수 있습니다. 인프라가 계속 작동하는지 여부는 실행 중인 코드의 증거, 관측된 도달성, 검증된 복구만이 보여줍니다.

OVH의 2017년 광네트워크 장애: 이중화 독립성이 책임성 시험대에 선 사건

왜 중요한가