그것은
그것은 중복성 재배치 중복성 재배치란 정말 무엇인가? 중복성은 당신에게 대체 경로, 구성 요소 또는 상태 복사본을 제공한다. 재배치란 중복성의 대체 경로, 구성 요소 또는 상태 복사본 중 하나로 작업을 이동시키는 결정과 조정이다. 중복성이 깨지면 그 대체 경로, 구성 요소 또는 상태 복사본을 사용하여 작업을 이동시키는 것이다.
모바일 및 CI/CD 팀에게는 이게 더 중요한 문제이다. 라이브 업데이트 플랫폼은 단순히 배포 도구가 아니라 라우팅, 서명, 저장, 에지 전달, 장치 검사 및 롤백 동작의 체인이다. 그 체인 중 하나가 깨지지 않으면 전체 배포 경로가 여전히 붕괴할 수 있다.
목차
- 백업만으로는 충분하지 않다
- 중복성과 재배치: 짝으로 정의
- 일반적인 아키텍처 패턴 및 사용 시점
- 중요도에 따라 재배치 및 경계 임계값
- CI/CD 및 실시간 업데이트 전송에 Failover를 적용하는 방법
- Edge Update Platform을 Failover Chain으로 사용하는 방법
- Failover를 테스트하는 방법: 필요할 때가 아니라
- 실시간 업데이트 배포하는 팀에게 필요한 실용적인 체크리스트
백업이 충분하지 않다면
앱 배포가 보통 보이지만, 실제로 발생하는 일반적인 사고는 다음과 같습니다. 배포 시스템이 정상적으로 작동하고, 팀은 정상적인 배포를 기대합니다. 그런 다음 지역 에지 노드가 감소하고, 한 경로가 나쁜 건강 신호를 반환하기 시작하고, 배포는 일시 중단되고, 모두 같은 질문을 물어봅니다. "이 실패를 견딜 수 있습니까, 아니면 단지 감지할 수 있습니까?"
백업 인프라를 소유하는 것과 실제로 재dundancy failover 설계 사이의 격차입니다.
서버가 랙에 있는 것은 도움이 되지 않습니다. 사용자가 그것으로 향하도록 라우팅层이 nunca 가리키고, 인증 서비스가 그것을 찾을 수 없고, 배포 프로세스가 언제 switch를 해야 하는지 알지 못하면.
Microsoft의 아키텍처 지침은 격차를 명확히 설명합니다. 중복 구성 요소를 테스트하고 유효성 검사하고, 프론트 엔드와 백 엔드의 failover를 동기화하고, 자동 failover와 수동 failback를 사용하여, 단순한 복제가 종단 간 복구가 작동하는지 보장하지는 않습니다. 누구도 훈련하지 않은 백업은 단지 예산 라인에 있는 희망입니다. 유용한 모델은 네 가지 부분으로 구성됩니다. 중복 중복된 경로나 대체 경로가 존재하는지 여부를 설명합니다. 체계를 회복하는 나머지 chain이 어떻게 돌아오는지에 대한 답을 찾습니다. 유효성 검사 실제 조건하에만 작동하는 흰보드에만 작동하는지 여부에 대한 답을 찾습니다.
모바일 팀은 실시간 업데이트 전송에서 이것을 명확하게 볼 수 있습니다. 서비스가 부분 장애 후에 패키지를 서명, 저장, 라우팅, 검증할 수 없다면, 플랫폼은 한 개의 좁은 층에서 보기에 중복적일 수 있지만, 사용자에게 실패할 수 있습니다. 일반적으로 하나의 고장난 box가 아니라 box 사이의 전환 또는 누군가가 알아서 전환할 것이라는 가정 때문입니다. 동일한 논리는 사고 대응에서 발생합니다. 첫 분가는 다이어그램보다 더 중요합니다. Capgo의 사고 대응 지침.
Networking2000에서 제공하는 중복성 조언 중복성의 유용한 개요입니다. 중복성과 재시동은 같은 것으로 말하는 경우가 많습니다. 하지만 그들은 아님.
중복성
중복성은 동일한 작업을 수행할 수 있는 여러 구성 요소의 존재입니다. redundancy advice from Networking2000 reinforces the same lesson, duplication only helps when the rest of the system can move over to it. Failover 은 실패하는 구성 요소에서 책임을 다른 건강한 구성 요소로 옮기는 행위입니다.
잘 기억되는 кух인 예시
식당의 바쁜 кух인에 대해 생각해 보세요. 여러 요리사들이 같은 메뉴를 요리할 수 있다면, 그게 중복입니다. 주방장님이 한 명이 피로를 느끼고 바로 다음 티켓을 다른 사람에게 할당한다면, 그게 Failover입니다.
주방은 사람만 필요하지 않습니다. 실패를 감지하는 방법, 대체할 사람을 결정하는 규칙, 그리고 주문이 진행되는 동안 프론트 오피스에 혼란을 주지 않도록 하는 방법이 필요합니다. 그 때문에 중복성만 있는 것은 쓸모없는 용량이고 Failover만 있는 것은 혼란입니다.
중요한 차이점은 팀들이 중복성 구성 요소를 구입하거나 빌드한 후에 멈추는 경향이 있습니다. 그들은 두 개의 서버, 두 개의 지역, 또는 두 개의 데이터 복사본이 있는지 물어보고, 그들이 안전하다고 가정합니다. 실제 운영 환경에서 유용한 질문은 시스템이 문제를 빠르게 감지할 수 있는지, 스위치할 때 두 번째 장애를 일으키지 않고, 그리고 원래 경로가 회복될 때 스위치백을 할 수 있는지 여부입니다.
팀이 모든 팀이 해야 할 4가지 질문
실용적인 Failover 설계는 4가지 평가 기준에 따라 살거나 죽습니다.
- 감지 시간시스템이 문제가 있다는 것을 얼마나 빠르게 알 수 있는지
- 스위치 시간백업 경로로 작업을 이동하는 데 얼마나 오랜 시간이 걸리나요.
- 데이터 일관성백업이 안전하게 전환할 수 있는 상태를 가지고 있는가요.
- 역전성시스템이 선호하는 경로로 돌아갈 수 있으며, 상황이 더 악화되지 않도록 할 수 있나요.
이 질문은 데이터베이스, 로드 밸런서, 라이브 업데이트 PIPELINE과 같은 모든 경우에 동일하게 적용됩니다. 차이점은 전환되는 위치만 다릅니다. 모바일 릴리스 시스템에서 전환은 채널, 에지, 버전 간에 발생할 수 있습니다. 논리는 동일합니다. 건강한 대체 항목이 존재해야 하며, 시스템은 올바른 이유로 선택해야 합니다.
일반적인 아키텍처 패턴 및 사용 시기
failover에 대한 논리를 쉽게 이해하려면, 결정이 어디서 이루어지는지 물어보세요. 일부 팀은 하드웨어가 문제를 흡수하도록 합니다. 다른 팀은 소프트웨어, 로드 밸런서, 또는 글로벌 라우팅 레이어에 결정을 밀어넣습니다. 각 선택은 다른 종류의 실패를 처리하고, 각 선택은 다른 종류의 블라인드 스팟을 생성합니다.
각 패턴이 도움이 되는 곳
하드웨어 중복성 지역적이고 명확한 실패에 잘 작동합니다. 장치, 카드, 또는 노드가 다운되는 경우입니다. 이해하기가 간단하기 때문에, 플랫폼 성숙도에서 초기에 나타납니다. 단점은 하드웨어만으로는 오케스트레이션을 해결하지 못한다는 것입니다. 만약 상위 레이어가 무엇이 발생했는지 알지 못한다면, 트래픽이 여전히 잘못된 곳을 향할 수 있습니다.
소프트웨어 중복성 cloud-native 시스템에서 더 나은 선택이 될 수 있는 서비스, 프로세스 또는 애플리케이션 계층 내의 용량을 복제하는 대신, 중복된 박스 대신 중복된 서비스를 복제합니다.
Active-active 여러 경로가 동시에 제공되므로 단일 실패가 холод 시작을 생성하지 않습니다. 시스템이 동시 처리를 tolerate하고 데이터 모델이 동시 참여자 간에 일관성을 유지할 수 있는 경우 강력한 선택입니다. Active-passive 하나의 경로가 제공되며 다른 하나는 대기합니다. 더 쉬운 추론과 종종 더 간단한 권위적인 상태를 위한 선택이지만 비어 있는 용량을 지불해야 합니다.
지역 장애 회피 대규모 장애 영역이 단일 클러스터보다 더 큰 경우 도움이 됩니다. 전체 사이트 또는 영역이 불량한 경우 트래픽을 다른 곳으로 이동할 수 있습니다. DNS-기반 클라이언트에게 이동을 표시하기 위해 로드 밸런서-기반 요청 경로 근처에서 결정을 유지하기 위해
각 패턴이 어디서 부서지는지
모든 패턴은 어디선가 깨질 것이다. 하드웨어 중복성은 상위 의존성들이 여전히 공유되는 사실을 숨길 수 있다. 동시성 모델이 concurrency에 대비되지 않은 경우, active-active는 복잡해질 수 있다. active-passive는 오랫동안 비활성화되어 nobody가 패시브 쪽이 여전히 작동하는지에 대한 자신감을 잃을 수 있다. 지역 failover는 동일한 실패 도메인에 걸쳐있는 공유 서비스에 의해 패배할 수 있다. DNS로 구동되는 제어는 변경을 반영하는 데 시간이 걸릴 수 있으며, 로드 밸런서로 구동되는 제어는 로드 밸런서가 건강한 경우에만 도움이 된다.
모바일 업데이트 플랫폼의 경우, failover layer는 여러 계층에 걸쳐 있을 수 있다. 빌드 서버는 중복되며, 아티팩트 저장소는 복제되며, 에지 전달은 로드 밸런싱되지만, 중요한 문제는 어느 계층이 릴리스가 이동해야 하는지 결정하는지에 있다. broader 배포 관점을 원한다면, __CAPGO_KEEP_0__ multi-region deployment guide from Capgo 사용자 영향의 계층에서 시작하여 외곽으로 작업하라. 사용자는 업데이트가 에지에서 나간 후에만 느끼면, 에지는 failover 스토리의 일부이다.
적절한 패턴은 가장 복잡한 것이 아니라, 실패를 살아남기 위해 필요한 패턴이다. 작은 팀은 일반적으로 active-passive에 clear validation 경로를 추가한 다음, 하위 계층이 신뢰할 수 있는지 증명한 후에 concurrency를 더 추가한다.
중요한 것은 failover 패턴이 복잡하거나 복잡하지 않다는 것이 아니라, 실패를 살아남기 위해 필요한 패턴이다. weighted failover와 graduated thresholds는 이러한 패턴을 구현하는 데 도움이 될 수 있다.
중요한 것은 failover 패턴이 복잡하거나 복잡하지 않다는 것이 아니라, 실패를 살아남기 위해 필요한 패턴이다. weighted failover와 graduated thresholds는 이러한 패턴을 구현하는 데 도움이 될 수 있다.
Failover 결정은 단순히 yes 또는 no switch가 아니어야 합니다. 이진 논리는 시스템이 flapping하는 이유 중 하나입니다. 서비스는 단일 신호가 경계를 넘어갈 때 즉시 건강한 상태와 불건강한 상태 사이를 오가기 때문입니다. Weighted failover는 같은 상황을 더 많은 맥락으로 처리하여, 실패를 신호로 다루며 그 신호의 영향 수준이 다르다고 간주합니다.
이진 사고가 flapping하는 이유는 무엇인가?
Juniper의 chassis-cluster 모델은 구체적인 예를 제공합니다. 각冗餘 그룹은 시작 시 threshold로 시작하여, 각 모니터링 객체가 실패할 때 assign된 객체의 가중치를 뺍니다. Failover는 threshold가 0에 도달할 때만 발생하여, 운영자들은 개별 인터페이스 또는 구성 요소 손실이 얼마나 중요해야 하는지 결정할 수 있습니다. 255Juniper chassis-cluster冗餘 그룹 failover이 설정은 하드 컷오버보다 실제 운영 환경에 더 잘 맞습니다. 하나의 손상된 링크는 불편하지만 여전히 서비스가 가능합니다. 한 번에 여러 개의 모니터링된 구성 요소가 실패하는 경우, 전체적인 영향이 충분히 크면 switch를 하게 됩니다. 이것은 중요합니다. 부분적인 손상은 일반적이고, 즉시 스위치 오버는 원래 오류보다 더 많은 트래픽을 중단할 수 있기 때문입니다.).
가중치 체크가 결정을 어떻게 바꾸는지
How weighted health checks change the decision
네트워크 장비 바깥에서도 가중치 failover가 나타납니다. 회로 브레이커, 가중치 트래픽 풀, 그리고 스테이지드 이그레스 제어는 모두 같은 아이디어를 따릅니다. 첫 경고에 대해 두려워하지 마세요, 그러나 반복되는 신호를 무시하지 마세요. 정책은 스위칭이 비용을 들이는 이유로 조정할 수 있습니다. 일찍 failover를 하게 되면 세션을 깨뜨리고 상태 일치화를 복잡하게 만들며 한 사고를 두 사고로 만들 수 있습니다.
모바일 팀에게는 배포 제어에 동일한 논리가 적용됩니다. 라이브 업데이트 경로가 여전히 일부 관객에게는 건강한 상태일 수 있지만 더 작은 슬라이스가 이미 손상된 상태일 수 있습니다. 관찰 가능성이 세세하게 구분된다면 시스템은 위험선이 정의된 라인까지 edge에서 제공할 수 있습니다. edge는 그 결정의 일부이며 __CAPGO_KEEP_0__에서 설명하는 edge 네트워크 모델은 마지막 홉이 중앙 pipe라인과 같은 중요성을 가지는 이유를 설명합니다. edge network model from Capgo CI/CD 및 라이브 업데이트 전달에 failover를 적용하는 것입니다.
릴리스 pipe라인은 전달 시스템이지만, 회복 시스템도 같습니다. 그런 식으로 보게 되면 디자인 선택이 더 명확해집니다. 빌드 서버, 아티팩트 저장소, 서명 서비스, 롤아웃 채널은 모두 __CAPGO_KEEP_0__에서 설명하는 중복성 failover의 장소가 됩니다.
중복성 failover
failover를 CI/CD 및 라이브 업데이트 전달에 적용하는 것입니다.
failover를 CI/CD 및 라이브 업데이트 전달에 적용하는 것입니다. failover를 CI/CD 및 라이브 업데이트 전달에 적용하는 것입니다. 명확하게 해야 합니다.
pipeline을 서비스 경로처럼 다루세요.
만약 하나의 빌드 러너가 죽었다면,冗餘성은 다른 러너가 작업을 이어받을 수 있는지 여부에 따라 유용합니다. 만약 아티팩트 저장소가 사용할 수 없다면, pipeline은 다른 복사본 또는 다른 배포 경로가 필요합니다. 만약 롤아웃이 문제를 퍼뜨리기 전에 시스템이 업데이트를 중단해야 한다면, 시스템은 업데이트를 중단해야 합니다.
__CAPGO_KEEP_0__ OTA 업데이트 트리거 가이드 Capacitor OTA update trigger guide 실제 릴리스 chain은 일반적으로 세 가지 보호를 필요로 합니다.
빌드冗餘성
- 이것은 릴리스가 하나의 러너 또는 하나의 큐 오류로 막히지 않도록 합니다.아티팩트冗餘성
- 이것은 서명된 배포가 단일 오류 지점이 되지 않도록 합니다.채널 보호대
- 이것은 롤아웃이 문제를 퍼뜨리기 전에 시스템이 업데이트를 중단할 수 있도록 합니다.이러한 상황에서 배포를 중단하고 다시 시작하는 것은 중요합니다.
이것은 별개의 문제가 아닙니다. 이것은 다른 시점에서 발생하는 동일한 복구 스토리입니다.
롤백을 배포에 포함시켜 예외가 아닌 일반적인 과정으로 만듭니다.
롤백은 애플리케이션 계층에서 실패백의 개념과 같습니다. 시스템은 사용자를 나쁜 경로에서 멀리 떨어뜨리고, 문제가 해결되거나 수정될 때까지 안정적인 경로로 되돌려줍니다. 롤백이 수동으로만 실행되는 경우, 일반적으로 너무 늦게 도착합니다.
관찰성은 이러한 가능성을 제공하는 것입니다. 장치별 로그, 채택 신호, 실패 이벤트는 업데이트 경로가 계속 진행할 수 있는지 여부를 알려줍니다. 그 정보가 없다면, 팀은 눈먼 개가 되어 실패 오버 결정을 단순히 추측으로만 할 수 있습니다.
롤백 경로는 배포 경로와 마찬가지로 평범해야 합니다. 사고 시에 롤백 경로가 새로운 경험이라면, 충분히 설계되지 않았습니다.
Capgo은 CapacitorJS 또는 Electron live 업데이트를 배포하는 팀에 적합한 옵션입니다. 이 도구는 서명된 웹 번들, 채널 기반 배포, 장치별 로그, 자동 롤백 보호를 지원합니다. 이러한 기능은 실패 오버를 위해 중요합니다. 이는 플랫폼이 나쁜 배포를 감지, 분리, 그리고 반전할 수 있도록 해줍니다. 이는 스토어 리뷰 사이클을 기다리지 않고 가능합니다.
주목할 점은 하나의 도구가 모든 문제를 해결하는 것은 아닙니다. 주목할 점은 배포 pipeline이 강건한 시스템처럼 행동해야 한다는 것입니다. 단방향 방송이 아닌 것입니다.
엣지 업데이트 플랫폼을 실패 오버 체인으로 사용합니다.
업데이트 경로가 세계에서 대시보드가 말하는 것보다 더 오래 전에 깨지게 됩니다. 배포에서 빌드에서 서명, 저장소, 에지 네트워크를 통해 지역을 가로지르는 경우, 그리고 최종적으로 장치에 도달하여 오프라인, 느린, 또는 부분적으로 연결된 경우, 그 chain에서 단 한 번의 단계도 실패하면 업데이트는 실패 오버가 아닙니다. 그것은 중단되었습니다.
왜 에지 네트워크가 회복 경로에 속해야 하는가
지연 시간, 일관성, 서명된 배달, 장치별 로그는 전달의 주요 부담입니다. 검증할 수 없는 서명된 배달은 죽은 경로입니다. 장치가 그것을 신뢰하지 않도록 해야 하기 때문입니다. 요청이 어디에 도착하더라도 다른 콘텐츠를 제공하는 에지 노드가 회전 이벤트를 트리거할 수 있습니다. 그럼으로써 애플리케이션 자체가 건강한 경우에도 전달 문제가 신뢰성 문제로 변합니다.
에지 네트워크는 클래식 인프라와 동일한 논리를 따릅니다. 분산된 에지 네트워크는 전달의 중복성 layer가 되고, 회전 목표는 요청에 응답할 수 있는 다음 건강한 노드입니다. 라우팅 테이블이나 데이터베이스 복제와 같은 작업을 한 경우 패턴은 익숙할 것입니다. 모바일 배포는 업데이트 논리 뒤에 실패를 숨기기 때문에 깨진 단계를 더 쉽게 놓치게 됩니다.
그것에 대한 더 광범위한 개요를 원한다면 실제로 에지 네트워크가 무엇을 하는지 위치의 실패가 모바일 업데이트시스템에서 얼마나 중요한지에 대한 이유를 설명하는 데 도움이 됩니다. 동일한 아이디어는 또한 네트워크 에지에서 데이터를 처리하는 것,에서 성능과 실패 동작을 모두 변경합니다.
어떤 사용자 기반 채널이 제공하는 것
사용자 기반 채널, 예를 들어 베타, 스테이징, 프로덕션, 또는 고객 특정 스트림과 같은 채널은 팀이 전체 플릿이 그것에 의존하기 전에 복구 경로를 테스트할 수 있도록 해줍니다. 그게 중요하기 때문입니다. 동일한 번들이 장치 혼합, 네트워크 품질, 또는 롤아웃 타이밍에 따라 다르게 행동할 수 있기 때문입니다.
그것으로부터 몇 가지 실제적인 함의가 따릅니다.
- 베타 채널 업데이트 경로가 안정적이지만 더 넓은 노출을 피하기 위해 업데이트를 확인하는 데 도움이 됩니다.
- 스테이징 채널 롤백 및 다시 가져오기 동작이 제어된 환경에서 작동하는지 확인하는 데 도움이 됩니다.
- 프로덕션 채널 이전 경로가 체인에 문제가 없음을 보여주기 전에 릴리스를 받는 것이 좋습니다.
- 고객 특정 채널 일부 사용자가 다른 패치 주기 필요할 때 위험을 분리할 수 있습니다.
중요한 교훈은 에지 전송이 빌드 시스템의 비합리적인 복사본이 아니라 활성화된 복구 층입니다. 가장 가까운 건강한 노드가 서비스를 제공할 수 없으면 시스템은 다음 하나를 선택해야 합니다. 번들이 유효하지 않으면 플랫폼은 더 안전한 릴리스 상태로 돌아가야 합니다.
infrastructure와 모바일 배포 사이의 연결고리입니다. failover 목표는 항상 다른 서버가 아닙니다. 다음에 신뢰할 수 있는 에지에 있는 다음에 신뢰할 수 있는 패키지일 수 있습니다.
failover를 테스트하기 전에
중복성의 신화가 살아남는 이유
중복성의 신화가 살아남는 이유
신화는 보통 공유 의존성과 약한 물리적 분리와 관련이 있습니다. 두 시스템은 여전히 동일한 숨겨진 경로, 동일한 서명 서비스, 또는 동일한 아티팩트 저장소에 의존하기 때문에 실제로 분리되어 있지 않습니다.
이것이 테스트가 백업이 존재하는지 확인하는 것만 체크하는 테스트가 통과할 수 있는 이유입니다. 실제 failover 경로가 실패하는 동안.
이것은 모바일 배포와 에지 시스템에 더 중요합니다. chain은 여러 층을 거치기 때문입니다. rollback은 대시보드에서 건강하게 보일 수 있지만 장치가 백업 에지 위치에서 패키지를 다시 가져올 수 없습니다. 지역 failover는 성공적으로 보일 수 있지만 서명 서비스, 아티팩트 저장소, 또는 인증 경로가 공유 실패 도메인을 노출할 때까지. testing Capacitor OTA updates실습에서 재연해야 할 것들
__CAPGO_KEEP_0__ OTA 업데이트를 테스트하는 경우
A failover test에서 실제 복구 경로를 강제로 사용하는 것이 유용합니다. 실제 조건에서 전체 시퀀스를 연습하고, chain이 왜곡되거나 멈추거나 깨지는지 관찰해야 합니다. 더 광범위한 edge 관점은 여기서 도움이 됩니다, 왜냐하면 네트워크 edge에서 데이터 처리 지역 조건이 실패 스토리에 포함되면 “복구”라는 의미가 바뀌기 때문입니다.
실용적인 체크리스트는 다음과 같습니다.
- chaos drill의도적으로 컴포넌트를 제거하거나 저하하여 시스템이 깨끗하게 shift하는지 확인합니다.
- synthetic transaction지역 간에 요청이 완료될 수 있는지 확인합니다.
- planned regional failoverrouting, auth, storage, update delivery가 함께 움직이는지 확인합니다.
- staged rollout reversal실제 네트워크 조건에서 나쁜 라이브 업데이트가 중단되고 대체될 수 있는지 확인합니다.
- 모바일 롤백 검증, 백업 에지 위치에서 다시 로드할 수 있는 서명된 번들을 확인하세요.
실제 대체 경로를 실제로 접촉하지 않는 테스트는 단지 모니터링 대시보드가 작동하는지만 증명합니다.
강력한 팀은 실패 오버 테스트를 반복적인 운영 습관으로 다루며, 감사 시점에 백업 체인이 견고한지 확인하기 위해 기다리지 않습니다. 그들은 가장 중요한 실패 모드를 연습하고, 시스템이 수동으로 혼란스럽지 않게 복구할 수 있도록 전달을 단단히 하며, 계속해서 개선합니다.
실시간 업데이트 배포를 위한 팀의 실무 지침서
실시간 업데이트 배포는 데이터베이스나 로드 밸런서가 실패하는 곳과 같은 곳에서 실패할 수 있습니다. 단지 모바일에서 폭파 반경이 다르 뿐입니다. 나쁜 패키지, 깨진 에지 노드, 또는陈舊한 대체 채널은 사용자가 건강한 앱으로 보이는 동안 오래된 빌드로 고착될 수 있습니다.
실시간 업데이트 배포를 이번 주에 시작한다면, 릴리스 경로부터 시작하세요.
- weak point를 매핑하세요., DNS, 에지, 및 원본层에서 단일 실패 지점을 식별하고, 사용자 영향의 소유권을 가진 것을 적어보세요.
- 대체 경로를 확인하세요., 각 крит적 구성 요소가 건강한 백업 경로를 가지고 있는지 확인하세요. 단순히 종이 위에 복사된 자원만이 아닙니다.
- 채널 가드레일을 사용하세요.이러한 상황을 피하기 위해, 베타, 스테이징, 그리고 프로덕션을 분리하여 한 번의 잘못된 릴리즈가 전함 전체에 영향을 미치지 않도록 하세요.
- signed bundle을 요구하세요.because signed bundle이 검증되지 않은 경우 fallback 경로가 유효하지 않습니다.
- 장치별 신호를 감시하세요.로그와 수용률 데이터를 사용하여 failover가 트리거되어야 하는지 알려주는 감지 메커니즘으로 사용하세요.
- 롤백을 연습하세요.실제 사고가 발생하기 전에 마지막으로 알려진 좋은 버전이 깨끗하게 복원되지 않는다는 것을 발견하지 마세요.
- 예약된 혼란의 훈련을 실행하세요.서비스에서 일부 경로를 의도적으로 제거하고 chain이 정말로 shift하는지 관찰하세요.
- failback도 검증하세요.returning to preferred path는 시스템의 일부이며, 보너스 기능이 아닙니다.
재해로 인해 복구하는 팀은 소스에서 장치까지 릴리즈를 추적하고 정확한 위치에서 실패할 수 있는 곳을 지시할 수 있습니다. 그들은冗餘를 단순히 추가 복사본으로 다루지 않습니다. 그들은 edge update layer가 릴리즈 PIPELINE과 사용자의 장치 사이에 위치하는 체인에 대한 결정을, 검사를, 그리고 전달을 다루는 체계로 다루며, 이러한 체계가 압박을 받을 때도 작동해야 합니다.
만약 릴리스가 잘못되었다면, 이미 대응할 수 있는 대응책이 있어야 한다. 사고 대응 지침서와 함께 있어야 한다. 사고 대응 지침서
