그것은
그것은 중복성 failover 중복성 failover이란 무엇인가? 중복성은 당신에게 대체 경로, 구성 요소 또는 상태의 복사본을 제공한다. failover는 중복성의 대체 경로, 구성 요소 또는 상태의 복사본 중 하나로 작업을 이동할 때 어떤 것이 깨지더라도 결정하고 조정하는 것이다.
모바일 및 CI/CD 팀에게는 이게 가장 중요한데, 인프라 체크리스트가 대부분 인정하지 않는다. 라이브 업데이트 플랫폼은 단순히 배포 도구가 아니라 라우팅, 서명, 저장, 에지 전달, 장치 검사 및 롤백 동작의 체인이다. 그 체인 중 하나가 깨끗하게 fail over할 수 없다면, 전체 릴리스 경로가 여전히 붕괴할 수 있다.
목차
- 백업만으로는 충분하지 않다
- 중복성과 failover를 pair로 정의한다
- 일반적인 아키텍처 패턴과 사용할 때
- 가중 failover와 경계 임계값
- CI/CD 및 실시간 업데이트 전송에 Failover를 적용하는 방법
- Edge Update Platform을 Failover Chain으로 사용하는 방법
- Failover를 테스트하는 방법: 필요할 때까지
- 실시간 업데이트 배포하는 팀에게 실용적인 체크리스트
백업이 충분하지 않다면
애플리케이션 배포가 평범하게 보인다. 배포 시스템이 정상적으로 작동하고 팀은 정상적인 롤아웃을 기대한다. 그런 다음 지역 에지 노드가 감소하고 한 경로가 나쁜 건강 신호를 반환하기 시작하고 배포는 일시 중단된다. 그때마다 팀은 같은 질문을 물어본다. "이 실패를 견뎌낼 수 있습니까? 아니면 단지 감지할 수 있나요?"
백업 인프라를 소유하는 것과 실제 재dundancy failover 설계 사이의 격차입니다.
서버가 랙에 있는 것은 도움이 되지 않습니다. 사용자가 라우팅层로 가도록 지시하지 않으면, 인증 서비스가 접근할 수 없으면, 배포 프로세스가 언제 switch를 해야 하는지 알지 못하면.
Microsoft의 아키텍처 지침은 격차를 명확하게 설명합니다. 중복된 구성 요소를 테스트하고 유효성 검사하고, 프론트 엔드와 백 엔드의 failover를 동기화하고, 자동 failover와 수동 failback를 사용하여 단순한 복제가 종단 간 복구가 작동하는지 보장하지는 않습니다. 누구도 훈련하지 않은 백업은 단지 예산 라인에 있는 희망입니다. 유용한 모델은 네 가지 부분으로 구성됩니다. 중복 중복된 경로나 대체 경로가 존재하는지 여부를 설명합니다. 체인 전체가 정상 상태로 돌아올 수 있는지에 대한 답입니다. 유효성 검사 실제 상황에서만 작동하는 흰 보드에만 작동하는지 여부를 확인하는 것입니다.
모바일 팀은 실시간 업데이트 전송에서 이 사실을 명확하게 이해합니다. 서비스가 부분 장애 후에 패키지를 서명, 저장, 라우팅, 검증할 수 없다면, 플랫폼은 한 개의 좁은 층면에서 중복적이지만 사용자에게 실패할 수 있습니다. 일반적으로 장애는 하나의 고장난 Box가 아니라 Box 간의 전환 또는 누군가가 알아서 전환할 것이라는 가정 때문입니다. 동일한 논리는 사고 대응에서도 적용됩니다. 첫 분초가 다이어그램의 아키텍처보다 더 중요합니다. Capgo의 사고 대응 지침.
Networking2000에서 제공하는 중복성에 대한 유용한 개요 Networking2000에서 제공하는 중복성에 대한 유용한 개요 중복성과 장애 복구
중복성과 장애 복구는 종종 같은 것으로 여겨지지만 그렇지 않습니다.
중복성 중복성은 동일한 작업을 수행할 수 있는 여러 구성 요소의 존재입니다. __CAPGO_KEEP_0__ Failover 은 실패하는 구성 요소를 건강한 구성 요소로 책임을 옮기는 행위입니다.
잘 기억되는 кух인 예시
식당의 바쁜 кух인에 대해 생각해 보세요. 여러 명의 요리사가 같은 메뉴를 요리할 수 있다면, 그게 중복입니다. 주방장님이 한 명이 피로를 느끼고 바로 다음 티켓을 다른 사람에게 할당한다면, 그게 Failover입니다.
주방은 사람만 필요하지 않습니다. 실패를 감지할 수단, 대체할 사람을 결정하는 규칙, 그리고 주문이 진행되는 동안 프론트 오피스에 혼란을 주지 않도록 하는 방법이 필요합니다. 그 때문에 중복만 있는 경우는 쓸모없는 용량이고 Failover만 있는 경우는 혼란입니다.
중요한 차이점은 팀들이 중복 구성 요소를 구입하거나 구축한 후에 멈추는 경향이 있습니다. 그들은 두 개의 서버, 두 개의 지역, 또는 두 개의 데이터 복사본이 있는지 물어보고, 그들이 안전하다고 가정합니다. 실제 운영 환경에서 유용한 질문은 시스템이 문제를 빠르게 감지할 수 있는지, 스위치할 때 두 번째 장애를 일으키지 않고, 원래 경로가 회복되면 스위치백을 할 수 있는지 여부입니다.
팀이 모든 팀이 해야하는 4가지 질문
실용적인 Failover 설계는 4가지 평가 기준에 따라 살거나 죽습니다.
- 감지 시간시스템이 문제가 있다는 것을 빠르게 알 수 있는 시간입니다.
- 스위치 오버 시간백업 경로로 작업을 이동하는 데 걸리는 시간은 얼마나 될까요.
- 데이터 일관성백업이 안전하게 전환할 수 있는 상태를 가지고 있는지 여부.
- 역전파성시스템이 선호 경로로 돌아갈 수 있는지 여부.
이 질문은 데이터베이스, 로드 밸런서, 실시간 업데이트 PIPELINE과 같은 모든 경우에 동일하게 적용됩니다. 차이점은 전환되는 위치만 다릅니다. 모바일 릴리스 시스템에서 전환은 채널, 에지, 또는 버전 간에 발생할 수 있습니다. 논리는 동일합니다. 건강한 대체 경로가 존재해야 하며 시스템은 올바른 이유로 이를 선택해야 합니다.
공통 아키텍처 패턴 및 사용 시기
failover에 대한 논리를 쉽게 이해하는 가장 쉬운 방법은 결정이 어디서 이루어지는지 물어보는 것입니다. 일부 팀은 하드웨어가 문제를 흡수하도록 합니다. 다른 팀은 소프트웨어, 로드 밸런서, 또는 글로벌 라우팅 레이어에 결정을 밀어넣습니다. 각 선택은 다른 종류의 실패를 처리하고 다른 종류의 블라인드 스팟을 생성합니다.
각 패턴이 도움이 되는 곳
하드웨어冗餘 하드웨어冗餘는 장치, 카드, 또는 노드가 다운되는 경우에 잘 작동합니다. 이해하기 쉬운 것이므로 플랫폼 성숙도에서 초기에 나타납니다. 단점은 하드웨어만으로는 오케스트레이션을 해결하지 못한다는 것입니다. 만약 상위 레이어가 무엇이 발생했는지 알지 못하면 트래픽이 여전히 잘못된 곳을 향할 수 있습니다.
소프트웨어冗餘 cloud-native 시스템에서 더 나은 선택은 서비스, 프로세스 또는 애플리케이션 계층 내의 용량을 복제하는 것입니다.
활성-활성 활성-활성은 동시에 여러 경로가 작동하므로 단일 실패가 холод 시작을 생성하지 않습니다. 시스템이 동시 처리를 tolerate하고 데이터 모델이 활성 참여자 간에 일관성을 유지할 수 있는 경우 강력한 선택입니다. 활성-비활성 활성-비활성은 보수적인 선택입니다. 하나의 경로가 작동하고 다른 하나는 대기합니다. 더 쉬운 사고와 종종 권위적인 상태를 위한 더 간단한 선택이지만 비활성화 될 때까지 비활성화 된 용량을 지불해야 합니다.
지역 장애 회피 대규모 장애가 발생할 경우 지역 장애 회피는 한 클러스터보다 더 큰 영향을 받을 수 있습니다. 만약 한 사이트 또는 영역이 비정상 상태가 된다면 트래픽을 다른 곳으로 이동할 수 있습니다. DNS-기반 DNS-기반 전략은 클라이언트에게 이동을 표시하는 데 사용됩니다. 로드 밸런서-기반 로드 밸런서-기반 전략은 요청 경로 근처에서 결정을 유지합니다.
이 패턴은 어디서 부서지나요?
모든 패턴은 어디선가 깨질 수 있습니다. 하드웨어冗餘는 여전히 공유된 업스트림 의존성을 숨길 수 있습니다. 동시성 모델이 concurrency에 적합하지 않으면 active-active는 복잡해질 수 있습니다. active-passive는 오랫동안 비활성화되어 nobody가 패시브 쪽이 여전히 작동하는지에 대한 자신감을 잃을 수 있습니다. 지역 failover는 동일한 실패 도메인을跨하는 공유 서비스로 패배할 수 있습니다. DNS-기반 제어는 변경을 반영하는 데 느려질 수 있으며, 로드 밸런서-기반 제어는 밸런서 자체가 건강한 경우에만 도움이 됩니다.
모바일 업데이트 플랫폼의 경우, failover layer는 여러 계층에 걸쳐 있을 수 있습니다. 빌드 서버는冗餘가 될 수 있으며, 아티팩트 저장소는 복제될 수 있으며, 에지 전달은 로드 밸런싱이 될 수 있지만, 중요한 질문은 릴리스가 이동해야 하는 계층은 무엇인지입니다. broader 배포 시야를 원한다면, __CAPGO_KEEP_0__ multi-region deployment guide from Capgo 사용자 영향의 소유 계층부터 시작하여 외곽으로 작업하세요. 사용자는 업데이트가 에지에서 나간 후에만 느끼게 되므로, 에지는 failover 스토리의 일부입니다.
올바른 패턴은 가장 복잡한 것이 아닙니다. 그것은 당신이 살아남으려는 실패와 일치하는 패턴입니다. 작은 팀은 일반적으로 active-passive와 명확한 검증 경로를 추가한 다음, 하위 계층이 신뢰할 수 있는지 증명한 후에 더 많은 concurrency를 추가합니다.
가중 failover 및 경계 임계값
__CAPGO_KEEP_0__
Fail오버 결정은 단순히 yes 또는 no switch로만 이루어지지 않아도 됩니다. 이진 논리는 시스템이 건강하고 비건강한 상태 사이를 오가게 하는 한 가지 이유입니다. 단일 신호가 경계를 넘어갈 때 서비스가 다시 시작되는 즉시 발생합니다. 가중치 failover는 같은 상황을 더 많은 맥락과 함께 처리합니다. 이는 실패를 다르게 영향력을 가지는 신호로 다루며, 실패의 영향력을 다르게 가중치로 처리합니다.
이진 사고가 왜 flapping을 일으키는가
Juniper의 chassis-cluster 모델은 구체적인 예를 제공합니다. 각冗余 그룹은 시작 시 threshold의 값을 255로 설정하고, monitored object가 실패할 때 할당된 가중치를 뺍니다. Failover는 threshold가 0에 도달할 때만 발생합니다. 이는 운영자에게 개별 인터페이스 또는 구성 요소 손실의 정도를 결정할 수 있도록 합니다.Juniper chassis-cluster冗余 그룹 failover).
이 설정은 hard cutover보다 실제 운영 환경에 더 잘 부합합니다. 하나의 손상된 링크는 불편하지만 여전히 서비스가 가능합니다. 한 번에 여러 개의 monitored piece가 실패하는 경우, 전체적인 영향이 큰 경우가 있을 수 있습니다. 이는 partial degradation이 일반적이고, 즉시 스위치 오버가 원래 오류보다 더 많은 트래픽을 중단할 수 있기 때문입니다.
가중치 건강 검사로 결정이 어떻게 바뀌는가
네트워크 장비 바깥에서도 가중치 failover가 나타난다. 회로 브레이커, 가중치 트래픽 풀, 스테이지드 이그레스 제어는 모두 같은 아이디어를 따른다. 첫 경고에 대해선 두려워하지 말고, 반복되는 신호를 무시하지 말라. 정책은 스위칭이 비용을 들기 때문에 조정할 수 있다. 일찍 failover를 하게 되면 세션을 깨뜨리고, 상태 일치화를 복잡하게 만들고, 한 사고를 두 사고로 만들 수 있다.
모바일 팀에게도 같은 논리가 적용된다. 배포 제어에 대해 말이다. 라이브 업데이트 경로가 여전히 일부 관객에게는 건강한 상태일 수 있지만, 더 작은 슬라이스가 이미 손상된 상태일 수 있다. 관찰 가능성이 세세하게 구분된다면, 시스템은 리스크가 정의된 라인까지 도달할 때까지 에지에서 서비스를 계속 제공할 수 있다. 에지는 그 결정의 일부이며, __CAPGO_KEEP_0__ 에지 네트워크 모델은 마지막 홉이 중앙 pipe라인과 같은 중요성을 가지는 이유를 설명한다. edge network model from Capgo 짧은 비디오로 정신 모델을 더 쉽게 유지할 수 있다.
가중치 failover는 문제를 프레임하는 방식을 바꾼다. 컴포넌트가 살아있는지 죽어있는지 물어보지 말고, 경로에 남아있는 신뢰도는 얼마나 되는지 물어보라. 시스템이 부분적인 결함이 일반적이고, 강제로 급하게 스위칭하는 것보다 꾸준히 유지하는 것이 더 좋을 때, 더 솔직한 질문이다.
Failover를 CI/CD 및 라이브 업데이트 전달에 적용한다.
릴리스 pipe라인은 전달 시스템이지만, 회복 시스템도 동시에 작동한다. 그런 식으로 보면, 디자인 선택이 더 명확해진다. 빌드 서버, 아티팩트 저장소, 서명 서비스, 롤아웃 채널은 모두 __CAPGO_KEEP_0__에서
중복성 failover __CAPGO_KEEP_0__ explicit하게 명시되어야 합니다.
pipeline을 서비스 경로처럼 다루세요.
만약 하나의 빌드 러너가 죽었다면,冗餘성은 다른 러너가 작업을 이어받을 수 있는지 여부에 따라 유용합니다. 만약 아티팩트 저장소가 사용할 수 없다면, pipeline은 다른 복사본 또는 다른 배포 경로가 필요합니다. 만약 롤아웃이 잘못된 상태에 도달했다면, 시스템은 문제가 퍼지기 전에 업데이트를 보내지 않도록 멈추어야 합니다.
CI/CD 및 실시간 업데이트 전송은 일반적인 배포 스크립트와는 다릅니다. 성숙한 pipeline은 릴리스가 계속되거나 중단되거나 역전될 수 있는지 여부를 알 수 있어야 합니다. Capacitor OTA 업데이트 트리거 가이드 실용적인 릴리스 chain은 일반적으로 세 가지 보호를 필요로 합니다.
빌드冗餘성
- 빌드 러너나 큐가 중단되지 않도록 하세요.아티팩트冗餘성
- 아티팩트가 단일 실패 지점이 되지 않도록 하세요.채널 보호대
- live-update delivery이러한 상황에서 배포를 중단할 수 있으므로 완전한 노출을 막을 수 있습니다.
이것은 별개의 문제가 아닙니다. 그것은 경로의 다른 지점에서 동일한 복구 스토리입니다.
롤백을 배포에 포함시켜 예외가 아닌 일반적인 부분으로 만듭니다.
롤백은 실패백의 애플리케이션 계층입니다. 시스템은 사용자를 나쁜 경로에서 멀리하고 나중에 문제를 이해하거나 수정할 때 안정적인 경로로 되돌려줍니다. 롤백이 수동으로 진행되는 경우, 일반적으로 너무 늦게 도착합니다.
관찰성은 이것이 가능하게 만듭니다. 장치별 로그, 채택 신호 및 실패 이벤트는 업데이트 경로가 계속 진행할 수 있는지 여부를 알려줍니다. 그 정보가 없으면 팀은 눈먼 개가 되어 실패 오버 결정을 단순히 추측으로만 할 수 있습니다.
롤백 경로는 배포 경로와 마찬가지로 평범해야 합니다. 사고 시에 롤백 경로가 새로운 경험이라면 충분히 설계되지 않았습니다.
Capgo은 CapacitorJS 또는 Electron live updates를 배포하는 팀에 적합한 옵션입니다. 왜냐하면 signed web bundles, channel-based distribution, 장치별 로그 및 자동 롤백 보호를 지원하기 때문입니다. 이러한 기능은 실패 오버를 위해 중요합니다. 왜냐하면 그것은 플랫폼이 나쁜 배포를 감지, 분리 및 역전할 수 있도록 해주기 때문입니다. 그것은 스토어 리뷰 사이클을 기다리지 않고.
점은 하나의 도구가 모든 것을 해결하는 것이 아니라는 것입니다. 점은 배포 pipeline이 강건한 시스템처럼 행동해야 한다는 것입니다. 단방향 방송이 아닌.
Edge Update Platforms는 실패 오버 chain입니다.
업데이트 경로가 세계에서 대시보드가 말하는 것보다 훨씬 더 오래 전에 깨질 수 있습니다. 배포에서 빌드에서 서명, 저장소로 이동, 지역을跨하는 에지 네트워크를 통해, 그리고 최종적으로 장치로 이동할 수 있습니다. 장치가 오프라인, 느리거나 부분적으로 연결된 경우에. 그 chain에서 단 한 번의 단계도 실패하면 업데이트는 실패를 넘어가지 못합니다. 그것은 멈췄다.
에지 네트워크가 복구 경로에 포함되어야 하는 이유
지연 시간, 일관성, 서명된 배달, 장치별 로그는 전달의 중추적 요소입니다. 검증할 수 없는 서명된 배달은 죽은 경로입니다. 장치가 그것을 신뢰하지 않도록 해야 합니다. 요청이 어디에 도착하더라도 다른 콘텐츠를 제공하는 에지 노드가 실패 이벤트를 트리거할 수 있습니다. 그럼에도 불구하고 애플리케이션 자체가 건강한 경우, 전달 문제가 신뢰성 문제로 변합니다.
에지 네트워크는 클래식 인프라와 동일한 논리를 따릅니다. 분산된 에지 네트워크는 전달의 중복 계층이 되고, 요청에 대한 응답을 할 수 있는 다음 건강한 노드가 실패 타겟이 됩니다. 라우팅 테이블이나 데이터베이스 복제와 같은 패턴을 작업한 경우, 그것은 익숙한 패턴입니다. 모바일 배포는 업데이트 논리 뒤에 실패를 숨기기 때문에, 깨진 단계를 더 쉽게 놓치게 됩니다.
그것에 대한 더 광범위한 개요를 원한다면 실제로 에지 네트워크가 무엇을 하는지 지리적 실패의 지역성이 모바일 업데이트 시스템에서 얼마나 중요한지 설명하는 데 도움이 됩니다. 같은 아이디어는 또한 네트워크 에지에서 데이터를 처리하는 것, 지역 처리가 성능과 실패 동작을 모두 변경합니다.
어떤 사용자 기반 채널이 구매하는 것
사용자 기반 채널, 예를 들어 베타, 스테이징, 프로덕션, 또는 고객 특정 스트림과 같은 채널은 팀이 전부의 함량에 의존하기 전에 회복 경로를 테스트할 수 있도록 해줍니다. 그게 중요하기 때문입니다. 동일한 번들이 장치 혼합, 네트워크 품질, 또는 롤아웃 타이밍에 따라 다르게 행동할 수 있기 때문입니다.
그것이 의미하는 바는 몇 가지 실용적인 함의를 따릅니다.
- 베타 채널 업데이트 경로가 안정적인지 확인하기 위해 더 넓은 노출 전에 검증해 볼 수 있도록 도와줍니다.
- 스테이징 채널 제어된 환경에서 롤백 및 다시 가져오기 동작이 작동하는지 확인할 수 있도록 해줍니다.
- 프로덕션 채널 이전 경로가 체인에 문제가 없음을 보여주기 전에 릴리스를 받을 수 있도록 해야 합니다.
- 고객 특정 채널 일부 사용자가 다른 패치 주기 필요할 때 위험을 분리할 수 있도록 해줍니다.
중요한 교훈은 에지 전송은 빌드 시스템의 비활성적인 미러가 아닙니다. 그것은 활성화된 회복 층입니다. 가장 가까운 건강한 노드가 서비스를 제공할 수 없으면 시스템은 다음 하나를 선택해야 합니다. 번들이 유효화 될 수 없으면 플랫폼은 더 안전한 릴리스 상태로 돌아가야 합니다.
인프라스트럭처와 모바일 배포 사이의 연결고리입니다. Failover 목표는 항상 다른 서버가 아닐 수 있습니다. 다음에 신뢰할 수 있는 에지에서 다음에 신뢰할 수 있는 패키지를 찾을 수 있습니다.
필요할 때까지 Failover 테스트하기
중복성의 신화는 행복한 경로가 설득력이 있기 때문에 살아남습니다. 팀은 중복된 인프라를 보지만, 실제 실패 시 모든 것을 무너뜨리는 숨겨진 의존성을 놓치고 있습니다. 간단히 말하면, 중복된 부분은 테스트하고 검증해야 하며, 프론트 엔드와 백 엔드 Failover는 동기화되어야 합니다.
중복성의 신화가 왜 살아남는지
신화는 보통 공유된 의존성과 약한 물리적 분리와 관련이 있습니다. 두 시스템은 여전히 같은 숨겨진 경로, 같은 서명 서비스, 또는 같은 아티팩트 저장소에 의존하기 때문에 실제로 분리되어 있지 않습니다.
이것이 왜 백업이 존재하는지 확인하는 테스트만 수행하면, 실제 Failover 경로가 실패하는 동안 통과할 수 있음을 의미합니다.
이것은 모바일 배포와 에지 시스템에 더더욱 중요합니다. chain은 여러 층을 거치기 때문입니다. 롤백은 대시보드에서 건강하게 보일 수 있지만, 장치가 백업 에지 위치에서 패키지를 다시 가져올 수 없을 때, 지역 Failover는 성공적으로 보일 수 있습니다. 서명 서비스, 아티팩트 저장소, 또는 인증 경로가 공유된 실패 도메인을 노출할 때까지. testing Capacitor OTA updates실습에서 어떤 것을 연습해야 하나요?
__CAPGO_KEEP_0__
A useful failover test forces the actual recovery path, not a fake one. The team should rehearse the complete sequence under realistic conditions, then watch where the chain bends, stalls, or breaks. A broader edge perspective helps here, because 네트워크 에지에서 데이터 처리 local conditions이 실패 스토리에서 부분이 되면 "recovery"의 의미가 바뀌게 됩니다.
A practical checklist looks like this:
- Chaos drills의도적으로 컴포넌트를 제거하거나 성능을 낮추어 시스템이 깨끗하게 shift되는지 확인합니다.
- Synthetic transactions across regions한 지역이 unavailable일 때 요청이 완료되는지 확인합니다.
- Planned regional failoversrouting, auth, storage, update delivery가 함께 움직이는지 확인합니다.
- Staged rollout reversals실제 네트워크 조건에서 잘못된 live update를 중단하고 대체할 수 있는지 확인합니다.
- __CAPGO_KEEP_0____CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
__CAPGO_KEEP_0__
- __CAPGO_KEEP_0____CAPGO_KEEP_0__
- __CAPGO_KEEP_0____CAPGO_KEEP_0__
- __CAPGO_KEEP_0__이러한 상황을 피하기 위해, 베타, 스테이징, 그리고 프로덕션을 분리하여 한 번의 잘못된 릴리즈가 전사 차원에서 발생하지 않도록 하세요.
- 서명된 번들을 요구하세요.인증할 수 없는 번들이 유효한 대체 경로가 아니라는 이유로.
- 장치별 신호를 감시하세요.로그와 수용률 데이터를 감시하여, Failover가 트리거되어야 하는지 알려주는 감시 메커니즘을 사용하세요.
- 롤백을 연습하세요.실제 사고가 발생하기 전에, 마지막으로 알려진 좋은 버전이 깨끗하게 복원되지 않는다는 것을 발견하지 않도록 하세요.
- 예약된 혼란의 훈련을 실행하세요.서비스에서 일부 경로를 의도적으로 제거하고, 실제로 chain이 shift하는지 관찰하세요.
- Failback도 검증하세요.대체 경로로 돌아가는 것이 시스템의 일부라는 것을 기억하세요.
복구가 잘되는 팀은 소스에서 장치까지 릴리즈를 추적하고, 실패할 수 있는 정확한 위치를 지목할 수 있습니다. 그들은冗餘를 단순히 추가 복사본으로만 생각하지 않습니다. 그들은 체인에 작동해야 하는 압박을 받는 edge update layer를 포함하여, 릴리즈 PIPELINE과 사용자의 장치 사이의 체인에 작동해야 하는 결정, 검사, 그리고 전달을 다룹니다.
release가 잘못되면, 대응은 이미 연습되어야 합니다. 사고 대응 가이드 작성자
