지원팀은 동일한 버그에 대한 세 개의 티켓이 있습니다. 한 사용자는 결제를 클릭한 후 체크아웃이 멈추는 것을 보고 있습니다. 다른 사용자는 로그인 후 화면이 검은색이 된다고 보고하고 있습니다. 세 번째 사용자는 앱이 업데이트된 후 런칭 시 충돌하는 것을 보고하고 있습니다. 팀의 누구도 로컬에서 이를 재현할 수 없습니다. QA 팀도 테스트 디바이스에서 이를 재현할 수 없습니다. 분석 도구는 감소가 나타나지만 이유는 알려주지 않습니다.
그것이 조직이 앱 문제가 아니라는 것을 깨닫는 지점입니다. 그들은 앱 건강 모니터링 문제가 있습니다. 건강한 앱은 우연히 건강하지 않습니다. 건강한 앱은 팀이 실제 디바이스에서, 실제 네트워크 조건에서, 실제 릴리스에서 일어나는 모든 것을 볼 수 있기 때문에 건강합니다. 이것은 모든 제품 카테고리에서 중요하지만, 특히 고위험 소프트웨어에서尤其 명확합니다. 글로벌 mHealth 앱 시장은 2024년 37.5억 달러로 평가되었으며, 2030년까지 86.37억 달러에 이를 것으로 예상됩니다. problem.
USD 37.5 billion USD 86.37 billion Grand View Research mHealth app market analysis2024 2030mHealth
앱을 모니터링하는 팀은 다른 곳에서 더 나은 결정을 내리기 때문에 일반적으로 더 나은 결과를 얻습니다. 그들은 릴리스 규율을 강화하고 소유권을 명확히하고 디버깅에서 추측의 양을 줄입니다. 좋은 도구는 도움이 되지만 더 큰shift는 운영입니다. 사용자가 앱이 깨졌다고 말할 때까지 기다리지 않습니다.
현재 설정이 콘솔 로그, 앱 스토어 리뷰, 지원 이슈로 대부분 구성되어 있다면 그거부터 고쳐보세요. 그 다음 개발자 워크플로우를 개선하세요. 좋은 시작점은 앱 팀이 구조화된 도구와 피드백 루프를 갖춘 현대 개발자 경험 설정을 살펴보는 것입니다. 모던 개발자 경험 환경 구축.
목차
- 소개 앱의 건강은 지금보다 더 중요합니다.
- 앱 헬스 모니터링이 실제로 무엇을 의미하는지
- 추적해야 하는 코어 메트릭스와 비타
- 인스트루먼테이션 및 텔레메트리 아키텍처를 설계하는 방법
- 데이터에서 액션으로: 알람, SLO, 그리고 런북
- 라이브 업데이트와 릴리즈 관찰성을 통해 회복 속도를 높입니다.
소개: 앱 건강은 지금 더 중요합니다.
생산 중단은 드문 경우지만, 일반적인 작업 중에 시작됩니다. 사용자가 업데이트된 앱을 열고 느린 화면을 만났을 때, 백그라운드 동기화가 안드로이드 빌드에서 멈추거나, 백엔드 변경이 이전 클라이언트 버전을 깨트리는 경우...
지원팀은 결과를 보는 것이 아니라 원인을 보는 경우가 많습니다. 사용자는 작업을 중단하고 다시 시도하여 중복 상태를 만들거나 자신감을 잃고 떠나게 됩니다.
앱 헬스 모니터링은 이제 기본적인 엔지니어링 분야입니다. 모바일 또는 데스크톱으로 자바스크립트를 배포하는 팀은 장치, 네트워크, OS 버전, 백엔드 의존성, 릴리스 채널과 같은 다양한 요소로 구성된 라이브 시스템을 운영하고 있습니다. 앱이 프로덕션에서 어떤 일을 하고, 팀이 동작이 변경될 때 얼마나 швидко 수정할 수 있는지에 대한 시야가 필요합니다.
건강한 소프트웨어는 팀이 관찰, 진단, 복구를 할 수 있는 소프트웨어입니다.
마지막 부분이 누락됩니다. 많은 팀은 충돌, 지연, API 실패를 모니터링하고, 수정을 위한 배포 경로를 별도의 문제로 다룹니다. 실제로 릴리스 PIPELINE도 건강합니다. 문제를 감지할 수 있지만 앱 스토어 리뷰를 통한 수정을 몇 일 동안 기다리면 사용자는 여전히 폭파 영역에 있습니다. 즉시 목표된 패치를 배포할 수 있다면, 프로덕션 문제는 작게 유지됩니다.
이것이 강력한 모니터링이 엔지니어링 속도 향상에 기여하는 이유 중 하나입니다. CLEAR한 테레메트리와 신뢰할 수 있는 릴리스 경로를 가진 팀은 작은 변경을 배포할 수 있으며, 회귀를 더 일찍 감지하고, 올바른 버전을 수정하는 대신 무작위로 롤백할 수 있습니다. 좋은 릴리스 및 디버깅 워크플로우를 위한 개발자 경험 도구 문제를 발견한 후 수정을 프로덕션에서 바로 적용하는 시간을 단축합니다.
사용자가 반복적으로 의존하는 제품에서 압박이 가장 높지만 패턴은 UNIVERSAL입니다. 의료, 상업, 금융 기술, 내부 운영 도구 및 고객 포털은 실패가 가시성이 없거나 수정이 너무 느리면 신뢰를 잃습니다. 모니터링은 가동 시간을 보호하는 동시에 릴리스 신뢰, 지원 품질 및 팀이 드라마 없이 복구할 수 있는 능력을 보호합니다.
App Health Monitoring이 실제로 무엇을 의미하는지
앱 헬스 모니터링은 단순히 충돌 보고만 하는 것이 아닙니다. 앱이 올바르게 작동하고, 수행이 가능하며, 오류가 발생했을 때 안전하게 복구되는지 지속적으로 확인하는 연속적인 관행입니다.
이것을 생각하는 유용한 방법은 자동차의 داش보드입니다. داش보드는 엔진을 고치지만 앱이 정상적으로 작동하는지, 운전을 계속할지, 특정 subsystem을 검사해야 하는지 알려줍니다. 건강한 모니터링 설정도 마찬가지로 앱을 위해 산재된 신호를 운영에 대한 인식을 만듭니다.
앱이 가시성을 유지하는 네 개의 기둥
첫 번째 기둥은 관찰입니다. 실행 중인 앱과 앱이 의존하는 서비스에서 데이터를 수집합니다. 그것은 충돌, 자원 사용, 네트워크 실패, 장치 상태, 릴리스 버전 및 사용자 흐름 컨텍스트를 포함합니다. 충분한 컨텍스트를 수집하지 않으면 실패가 발생했지만 왜 발생했는지 알 수 없습니다.
두 번째 기둥은 탐지Raw data는 이상 패턴을 식별할 수 있는 팀에게만 도움이 됩니다. 새로운 롤아웃 후 예외 증가와 여러 앱 세션 동안 메모리 사용량의 천천히 증가하는 것은 다릅니다. 감지는 임계값, 기준선 및 릴리스 비교가 중요합니다.
세 번째 기둥은 진단, 강력한 팀과 소음 팀을 구분하는 것입니다. 진단은 로그를 읽는 것만으로는 충분하지 않습니다. 예외 클러스터를 앱 버전, 장치 모델, API 지연 시간 또는 기능 플래그 상태와 연관시키면, 실패는 재현 가능한 설명으로 좁혀집니다.
네 번째 기둥은 수정입니다. 모니터링이 행동의 길이만큼이면 비용이 많이 들 것입니다. 팀은 신호에 대한 수정 전략, 롤백 경로 또는 완화 단계가 필요합니다.
반응형 디버깅은 너무 늦습니다
많은 팀이 여전히 모니터링을 생산驚愕의 우편함으로 다룹니다. 충돌이 발생합니다. alguien이 조사합니다. 패치가 대기열에 넣어집니다. 사용자는 기다립니다.
이 패턴은 확대되지 않습니다, 특히 모바일에서 사용자는 혼합 버전과 나쁜 네트워크 조건을 포함할 수 있습니다. 모니터링은 일상적인 엔지니어링 결정에 통합될 때 작동합니다:
- 개발 중: 인스트루먼테이션을 기능이 빌드되는 동안 추가하고, 사고 이후에 추가하지 마십시오.
- 릴리스 중: 새로운 버전과 알려진 기준점을 비교합니다.
- 사고 중: 신호를 처리할 수 있는 사람에게 전달합니다.
- 복구 후: 추적 데이터를 유지하고 업데이트합니다.
실용적인 규칙: 지원 티켓에 포함된 정보가 추적 데이터가 이미 캡처해야 하는 정보와 동일한 경우, 인스트루먼트가 불완전합니다.
좋은 앱 헬스 모니터링은 모든 것을 수집하는 것이 아니라, 시간을 단축하는 신호를 수집하는 것입니다.
필수적으로 추적해야 하는 코어 메트릭스 및 비타민
약한 모니터링 설정을 빠르게 구축하는 가장 빠른 방법은 오직 충돌만 추적하는 것입니다. 충돌은 중요하지만, 그들은 늦은 증상입니다. 건강한 시스템은 종료하기 전에 경고 신호를 보여줍니다. 앱이 안정적이지만, 스트레스를 받고, 차단되거나, 점진적으로 악화되는지 알려주는 메트릭스를 추적해야 합니다.
solid baseline은 7개의 코어 기술 지표에서 나옵니다. 이 애플리케이션의 건강 모니터링 요구 사항에 대한 토론팀은 다음을 추적해야 합니다. 애플리케이션 런타임 상태, CPU, 메모리 및 네트워크 사용량의 급증, 미처리 예외 보고서, 모듈 상태, 외부 구성 요소의 건강, 백그라운드 작업의 대기 중 카운트 및 사용 통계.
모든 대시보드에 속한 7 가지 기술 지표
엔지니어들이 그에 따라 행동할 수 있도록 그룹화하는 실제적인 방법
| 지표 카테고리 | 예시 지표 | 그것이 무엇을 말하는지 |
|---|---|---|
| 안정성 | 실행 중인 상태, 처리되지 않은 예외, 앱 종료 패턴 | 런타임 상태, 미처리 예외, 앱 종료 패턴 |
| Performance | 네트워크 사용량 급증, 느린 요청, 렌더링 차단, 시작 오류 | 사용자가 지연, 멈춤, 또는 감소된 반응성 경험 |
| 리소스 사용량 | CPU 급증, 메모리 성장, 배터리 소모 | 앱이 장치 수준의 스트레스에 처해 종료될 수 있는지 여부 |
| 컴포넌트 건강 | 모듈 상태, API 가용성, 데이터베이스 접근성, 외부 서비스 상태 | 주 앱 셸 외부에서 실패를 유발하는 의존성 여부 |
| 백그라운드 작업 | 대기 작업 수, 큐 백로그, 싱크 리트라이 | 비동기 작업이 지연, 지연, 또는 시간이 지남에 따라 누적되는지 여부 |
| 제품 동작 | 사용 통계, 기능 경로, 중단 지점 | 어플리케이션의 어떤 부분이 최적화나 더 자세한 관찰이 필요한지 |
이 표가 더 유용해질 때는 각 지표가 릴리즈 버전, 플랫폼, 환경, 사용자 흐름의 충분한 Context를 설명할 수 있어야 합니다.
모바일 팀의 가장 쉬운 실수 중 하나는 리소스 신호를 무시하는 것입니다. 어플리케이션이 '자주 충돌하지 않습니다'는 이유로.
메모리 압박, 배터리 소모가 심한 루프, 또는 반복적인 네트워크 재시도는 사용자가 열, 느린 속도, 또는 몇 초 동안 화면이 멈추는 것에 대해 불평하는 것을 먼저 보입니다.
메트릭을 시스템으로 읽는 방법
이 메트릭은 고립되지 않습니다. 그들은 Chain을 형성합니다.
빠른 세 가지 질문에 대한 답변을 제공하는 대시보드를 사용하세요.
- 3 가지 질문에 즉시 답할 수 있는 대시보드를 사용하십시오:
- 어플리케이션이 현재 사용하기에 건강한지 여부
- 릴리즈 또는 의존성 변경이 패턴을 변경한지 여부
영향을 받는 사용자 세그먼트는 무엇인지 여부 이 앱 성능 지표에 대한 안내서. 이 가이드의 목표는 더 많은 차트가 아니라 더 명확한 사고를 줄이는 것입니다.
사용자 경험에서부터 하위 시스템까지의 경로를 추적하세요. "체크아웃이 느려집니다"는 사용자의 불만입니다. "인증을 갱신한 한 앱 버전 이후 체크아웃 지연 시간이 증가합니다"는 팀이 고칠 수 있는 것입니다.
다른 실용적인 트레이드 오프는 세분성입니다. 이벤트당 테레미트로 디버깅 세부 정보를 얻을 수 있지만 비용과 잡음이 증가합니다. 가능한 한 집계하고 위험한 경로인 인증, 결제, 동기화, 오프라인 복구, 시작과 같은 곳에서 샘플링을 철저히 하세요.
만약 모니터링 설정을 필수 요소로 줄이려면, 나는 예외 캡처, 런타임 상태, 메모리 동작, 의존성 건강, 릴리스 구분된 사용 패턴을 유지할 것입니다. 그 다섯 가지가 일반적으로 버그, 성능 회귀, 또는 깨진 의존성을 확인하는 데 도움이 됩니다.
인스트루먼트 및 텔레메트리 아키텍처를 설계하세요.
지표는 프로젝트에 SDK가 추가된 이유로 나타나지 않습니다. 지표는 팀이 관찰할 것을 결정하고, 어디서 캡처할 것인지, 그리고 데이터가 유용한지 여부를 결정하기 위해 얼마나 많은 context를 보존할 것인지에 따라 나타납니다.
아키텍처는 앱 동작이 더 밀집되면서 더 중요해집니다. 건강 관련 모바일 데이터의 더 넓은 범위의 문제를 하나의 예로 들 수 있습니다. 평균 iPhone에 Apple Watch가 pair된 경우 일일 평균 8,000건의 건강 관련 데이터 포인트를 생성합니다.에 따르면 이 건강 앱 데이터 요약앱의 건강 상태와 상관없이, 이 교훈은 여전히 유효합니다. 현대 앱은 많은 팀이 무작위로 캡처할 수 있는 수준보다 훨씬 더 많은 전송 데이터를 생성합니다.
수집 경계에서 시작하세요
인스트루먼테이션은 가장 위험한 경계에서 시작해야 합니다:
- 앱 생명 주기 이벤트: 시작, 전면, 배경, 종료, 재개.
- 네비게이션 경계: 화면 진입, 화면 이탈, 실패한 전환, 예상치 못한 리다이렉트.
- 네트워크 경계: 요청 시간, 재시도 동작, 응답 실패, 직렬화 오류.
- 상태 경계: 인증 갱신, 로컬 캐시 재수화, 마이그레이션, 오프라인 동기화, 기능 플래그 적용.
- Release boundaries: 앱 버전, 자바스크립트 번들 버전, 업데이트 채널, 빌드 환경.
이 점들은 앱이 실패한 것뿐만 아니라 건강에서 불건강으로 넘어간 정확한 시점을 알려줍니다.
자바스크립트 기반 모바일 앱의 경우, 클라이언트 측의 모니터링이 백엔드 측의 모니터링과 함께 작동해야 합니다. 프론트엔드에서 결제 요청이 실패했지만 API 로그가 요청 경로를 추적하지 못한다면, 이슈가 여전히 너무 오래 해결되도록 합니다.
로그, 메트릭, 트레이스: 다른 문제를 해결합니다.
팀들은 종종 모든 것을 '로깅'으로 묶고, 디버깅이 느려지는 이유를 이해하지 못합니다.
- 메트릭 어떤 것이 잘못된 방향으로 흐르는지 여부를 알려줍니다.
- 로그 특정 이벤트에서 무슨 일이 일어났는지 설명하거나 code 경로를 설명합니다.
- Traces 트레이스
모든 세 가지가 필요하지만, 동일한 깊이로 존재하는 것은 아니다. 메트릭은 앱 전체에 걸쳐 넓게 존재해야 한다. 로그는 구조화되고 선택적으로 존재해야 한다. 트레이스는 서비스 경계를 넘거나 비싼 재시도와 관련된 워크플로우에서 가장 중요하다.
만약 벤더를 비교하거나 스택에 포함할 것을 결정하고 있다면, 2026년의 최고의 성능 모니터링 도구 는 실질적인 차이점을 강조하는 유용한 참고 자료가 될 것이다. 도구가 가시성, 경고, 진단에 접근하는 방법에 대한 실제 차이점을 강조한다.
컨텍스트를 위해 빌드하라, 볼륨을 위해 빌드하지 마라
컨텍스트는 수집된 데이터를 증거로 만든다. 모든 이벤트는 첫 번째 디버깅 질문에 대한 답변을 위해 충분한 메타데이터를 포함해야 한다. 일반적으로 플랫폼, OS, 앱 버전, 릴리스 채널, 장치 특성, 화면 또는 기능 이름, 종속성 상태와 같은 정보가 포함된다.
일반적인 트레이드 오프는 자신이 직접 만들기 versus 호스팅된 제품을 사용하는 것이다. 세 번째-party 플랫폼은 더 빠른 대시보드와 경고를 제공한다. 커스텀 PIPELINE은 스키마, 보존, 개인 정보 경계에 대한 더 많은 제어를 제공한다. 많은 팀은 하이브리드 방식을 사용한다. 그들은 상업적 오류 및 추적 제품을 사용하고, 릴리스 이벤트 및 앱 특정 워크플로우에 대한 집중된 인스트루멘테이션을 추가한다. React Native 팀이 이 스택을 생각하고 있다면, React Native에 대한 Sentry 설정 가이드 는 더 넓은 수집 데이터 아키텍처에 한 층이 어떻게 들어가는지에 대한 실제 예시이다.
좋은 아키텍처는 엔지니어가 증거로 대신하는 추측 없이 지원 질문에 대한 답변을 할 수 있어야 한다.
데이터에서 행동으로: 경보 SLO 및 Runbook과 함께
대시보드는 여전히 팀을 어둡게 할 수 있지만 nobody가 주목할 만한 것에 대해 알지 못한다면. SLOsSLO는 단순히 신뢰성 약속을 측정 가능한 것으로 번역한 것입니다.
SLO는 사용자 경험을 반영해야 하며 내부 자랑하는 지표는 아닙니다.
좋은 경보는 사용자 영향력에서 시작됩니다.
경보를 설정할 때 사용자가 차단, 저하 또는 위험에 처한 조건을 기준으로 하십시오.
- 모바일 및 JS 앱의 경우, 일반적으로 조건이 클러스터링되어 다음과 같은 패턴을 따릅니다: 크래시 영향:
- 릴리스가 예외 클러스터를 생성하여 런칭을 방지하거나 주요 흐름을 깨트립니다. 애플리케이션 성능 감시 startup, 화면 전환, 또는 중요한 API 경로가 충분히 저하되어 사용자가 액션을 포기합니다.
- 시작, 화면 전환 또는 중요 __CAPGO_KEEP_0__ 경로가 사용자가 액션을 포기하는 정도로 저하됩니다. 외부 서비스 장애는 인증, 동기화 또는 체크아웃에서 눈에 띄는 끊김을 발생시킵니다.
- 복구 영향: 재시도, 큐, 또는 백그라운드 작업이 자연스럽게 멈추고 지워지지 않습니다.
사용자 영향이 없는 기술적인 잡음에 대해 경고하지 마십시오. 시스템이 무해한 이상치에 대해 엔지니어를 페이지링할 때 엔지니어들은 경고에 신뢰를 잃습니다.
Field note: 의미 있는 패턴에 대해 경고하십시오, 단일 극적인 사건에 대해 경고하지 마십시오. 하나의 타임아웃은 잡음입니다. 수입 경로에 대한 지속적인 타임아웃 패턴은 사고입니다.
다른 어려운 교훈은 소유권입니다. 모든 경고는 명확한 목적지에 있어야 합니다. 경고가 공유 채널에 도착하여 소유주가 없으면 그것은 장식이 됩니다.
Runbooks는 망설임을 제거합니다.
Runbook은 알려진 실패 패턴에 첨부된 짧은 운영 문서입니다. 그것은 엔지니어에게 어떻게 확인할 것인지, 어떤 대시보드를 확인할 것인지, 어떤 완화가 안전한지, 언제 전파할 것인지 알려줍니다.
좋은 Runbook은 일반적으로 다음과 같은 내용을 포함합니다:
- Trigger 정의: 어떤 신호가 발생했는지 및 왜 그것이 중요하다는 것을 설명합니다.
- 즉시 확인: 버전, 의존성 상태, 영향을 받은 플랫폼, 최근 론칭 상태.
- 안전한 대응책: 플래그를 비활성화하거나 론칭을 중지하고 트래픽을 전환하거나 구성 설정을 되돌리기.
- 상향 경로: 백엔드, 모바일 릴리스, 지원 통신, 및 사고 조정.
애플리케이션 알림을 배포 워크플로우와 연결하는 팀은 더 빠르게 복구할 수 있습니다. 왜냐하면 그들은 릴리스 시스템을 프로덕션 건강과 분리하는 것처럼 생각하지 않기 때문입니다. 만약 그桥梁을 만들고자 한다면, CI/CD pipeline에 알림을 추가하는 방법에 대한 이 안내서 이것은 엔지니어링 액션을 프로덕션 신호와 연결하는 모델입니다.
Runbooks도 일관성을 개선합니다. senior 엔지니어가
sync backlog plus rising memory plus one bad release channel
을 진단하는 유일한 사람일 필요가 없습니다. 사고가 아직 свеж한 상태에서 그것을 기록하세요.
앱은 사용자에게 빠르고 안전하게 수정을 전달할 수 없다면 건강하지 않습니다. 릴리스 건강은 앱 건강의 일부입니다.
릴리스 PIPELINE도 건강합니다
많은 모니터링 설정은 배포가 이진 값이라고 가정합니다. 업데이트가 배포되거나 배포되지 않은 경우. 실제로는 배포된 릴리스가 기술적으로 사용할 수 있지만 운영상으로 불건전한 경우가 많습니다.
그것은 중요합니다. 이 기사에서 설명한 것과 같이 릴리스 업데이트 전달 및完整성 모니터링의 빈틈 많은 앱 건강 토론은 업데이트가 배포되었지만 여전히 불건전한 경우를 고려하지 않습니다. 예를 들어 서명 불일치 또는
With live update systems, the recovery model changes. Instead of treating app stores as the only repair path for every JavaScript fix, teams can observe whether the fix package is downloading, verifying, applying, and stabilizing on actual devices.
릴리스 관찰성에 포함되어야 하는 것은 무엇인가?
릴리스 파이프라인은 자신의 운영 신호가 필요하다. 최소한, 다음을 모니터링하라:
- 업데이트 수용 상태: 장치가 의도한修정 버전으로 이동하는가.
- 검증 결과: 서명된 번들 또는 패키지 무결성 검사 결과가 통과하는가.
- 배포 건강: 확산 지연, 캐싱 문제 또는 지역 실패가 배포를 늦추는지 확인하라.
- 롤백 트리거: 장치가 새로운 번들이 유효성 검사에 실패하거나 부서지게 하는지 확인하라.
- 장치당 확인: 지원 및 엔지니어링 팀이 특정 영향을 받은 사용자가 실행 중인 버전을 확인할 수 있는지 확인하라.
이것은 특수한 배송 플랫폼이 실제로 채우기 어려운 한 영역입니다. Capacitor 팀에게는 Capgo 자바스크립트 업데이트를 위한 서명된 번들 전송, 롤백 지원, 버전 기록, 릴리스 관찰성을 제공합니다. 배포 후에 중요한 신호의 구체적인 그림을 원한다면 Capacitor 앱의 실시간 업데이트 메트릭 문제를 잘 설명합니다.
사용자가 "업데이트하고 여전히 실패한다"고 말할 때, 팀은 사용자가 추측하지 않도록 하여도 실행 중인 버전, 전송 시도, 롤백 상태를 확인할 수 있어야 합니다.
회복 속도는 팀의 행동을 변경합니다.
팀이 릴리스 건강을 직접 관찰할 수 있게 되면, 일반적으로 배포 방식을 변경합니다. 더 작은 수정을 푸시합니다. 위험한 변경을 narrower 채널로 대상으로합니다. 롤백 속도가 더 빠릅니다. 지원 팀은 "다음 스토어 릴리스를 기다려 주세요"라는 더 깨끗한 답변을 받을 수 있습니다.
이것은 Live Update가 서명, 명확한 채널 규칙, 감사성, 안전하게 업데이트할 수 있는 것과 전체 바이너리 릴리스가 필요하다는 구분선이 있는 discipline이 필요하다는 것을 의미합니다. 그러나 릴리스 경로가 관찰 가능할 때, 인시던트 리스폰스가 훨씬 더 실용적이게 됩니다.
기존 모델은 모니터링을 진단만으로만 다루었습니다. 더 나은 모델은 감지, 진단, 고치기, 배포 확인, 회복 확인을 포함한 closed loop로 다루어야 합니다.
Capacitor 또는 Electron 앱을 배포하는 팀이 릴리스 건강에 대한 더 chặt한 제어를 원한다면 Capgo 이것은 평가할 가치가 있습니다. 팀은 signed JavaScript, CSS, config, copy 및 asset 수정을 빠르게 배포하고 수용, 실패, 롤백 및 장치별 업데이트 상태를 추적하여 '패치를 배포했다'는 것만으로 회복을 중단하지 않도록합니다.
