주요 클라우드 서비스 중단으로 인해 Google Compute Engine에 영향을 미쳤습니다.
Google은 2019 년 6 월 2 일 12시 25 분 (PDT)에 처음으로 '문제'를 신고했습니다. 현재 모든 유형의 재해에서 흔히 볼 수 있듯이이 중단에 대한 보고서는 소셜 미디어에 처음 나타났습니다. 소셜 미디어는 재난 발생 초기에 어떤 유형의 정보도 얻을 수있는 가장 신뢰할 수있는 곳으로 보인다.
이르는 모든 정보에 대한 첫 번째 정보원이되었습니다. [/ caption] Gmail, YouTube, SnapChat 등 많은 서비스가 영향을 받았습니다. [/ caption]우리가이 최신 Google Compute Engine 작동 중단에 대한 공식적인 근본 원인 분석을 기다리는 동안 Google은 "미국 동부 지역에서 높은 수준의 네트워크 혼잡"으로 인해 다운 타임이 발생했다고보고했습니다. 네트워크 문제를 일으킨 원인을 확인하기 위해 기다려야 할 것입니다. 인간의 실수, 사이버 공격, 하드웨어 오류 또는 다른 것이 었습니까?
이 구름 파동을 준비 했습니까?
마지막으로 주요 클라우드 정전 중에 썼습니다. 클라우드에서 비즈니스 핵심 워크로드를 실행하는 경우 클라우드 서비스 공급자와 상관없이 피할 수없는 중단을 계획하는 것이 중요합니다. 2018 년 9 월 4 일의 다단계 Azure 정전은 전기 폭풍과 관련된 전력 서지 중 2 차 HVAC 시스템이 가동되지 않는 것과 관련이 있습니다. 단일 데이터 센터 내에 장애가 발생했지만 정전으로 인해이 단일 데이터 센터에 종속 된 여러 서비스가 노출되었습니다. 이로 인해 데이터 센터 자체가 단일 실패 지점이되었습니다.
재해 복구 계획을 세우십시오.
클라우드의 인프라를 활용하여 가용 영역, 지역 또는 클라우드 서비스 제공 업체간에 중요한 데이터를 지속적으로 복제함으로써 위험을 최소화하십시오. 데이터 보호 외에도 업무 핵심 응용 프로그램을 신속하게 복구 할 수있는 절차를 마련하는 것이 모든 재해 복구 계획의 필수 요소입니다. 다양한 복제 및 복구 옵션을 사용할 수 있습니다. 여기에는 Azure Site Recovery와 같은 클라우드 공급 업체가 제공하는 서비스, SQL Server Always On Availability Group과 같은 응용 프로그램 별 솔루션, Windows 및 Linux에서 실행되는 다양한 응용 프로그램을 보호하는 SIOS DataKeeper와 같은 타사 솔루션까지 포함됩니다. 단일 클라우드 제공 업체에 전적으로 의존하는 재해 복구 전략을 사용하면 단일 클라우드 내의 여러 지역에 영향을 줄 수있는 시나리오가 발생할 수 있습니다. 다중 데이터 센터 또는 다중 지역 재해는 거의 발생하지 않습니다. 그러나 지난 가을에 발생한 이러한 최근의 가동 중단과 Azure의 정전으로 인해 단일 데이터 센터에 장애가 발생하더라도 영향은 여러 데이터 센터 또는 클라우드 내의 영역까지 광범위하게 퍼질 수 있습니다. 위험을 최소화하려면 재해 복구 사이트가 기본 클라우드 플랫폼 외부에있는 다중 클라우드 또는 하이브리드 클라우드 시나리오를 고려하십시오. 클라우드는 사용자 자신의 데이터 센터만큼이나 작동 불능입니다. 재난 대비를위한 조치를 취해야합니다. 가장 중요한 비즈니스 용 앱을 먼저 살펴 보는 것이 좋습니다. 오프라인 상태에서 관리하고있는 클라우드 포털을 사용할 수 없다면 어떻게 할 것입니까? 복구 할 수 있니? RTO 및 RPO 목표를 달성합니까? 그렇지 않은 경우 재해 복구 전략을 다시 평가할 때입니다.
"준비를하지 않으면 실패 할 준비를하고 있습니다."– 벤자민 프랭클린
