지원팀에는 동일한 버그에 대한 3개의 티켓이 있습니다. 한 사용자는 결제를 눌렀을 때 체크아웃이 멈추는 것을 보고 있습니다. 다른 사용자는 로그인 후 화면이 검은색이 된 것을 보고 있습니다. 세 번째 사용자는 앱이 업데이트된 후 런칭 시 충돌하는 것을 보고 있습니다. 팀의 누구도 로컬에서 이를 재현할 수 없습니다. QA 팀도 테스트 디바이스에서 이를 재현할 수 없습니다. 분석 결과는 감소하는 것을 보여주지만, 그 이유는 알려지지 않았습니다.
그것이 조직들이 앱 문제가 아니라고 깨닫는 지점입니다. 그들은 앱 문제가 아니라 앱 헬스 모니터링 문제.
건강한 앱은 우연히 건강하지 않다. 건강한 앱은 팀이 실제 장치에서, 실제 네트워크 조건에서, 실제 릴리스에서 일어나는 모든 것을 볼 수 있기 때문에 건강하다. 이것은 모든 제품 카테고리에서 중요하지만, 특히 고위험 소프트웨어에서尤其 그렇다. 전 세계 mHealth 앱 시장 규모는 2024년 37.5억 달러로 평가되었으며, 2030년까지는 86.37억 달러에 이를 것으로 예상된다. 2024년 2030년까지 USD 86.37 billion그랜드 뷰 리서치의 mHealth 앱 시장 분석에 따르면. 팀이 모니터링에 투자하면 일반적으로 다른 곳에서 더 나은 결정을 내릴 수 있다. 릴리스 규율을 강화하고 소유권을 명확히하고 디버깅에서 추측의 양을 줄일 수 있다. 좋은 도구가 도움이 되지만, 더 큰shift는 운영적이다. 사용자가 앱이 깨졌다고 말할 때까지 기다리지 않는다.현재 설정이 콘솔 로그, 앱 스토어 리뷰, 지원 상향 조정으로 대부분 구성되어 있다면, 그거 먼저 고쳐라. 그런 다음 개발자 워크플로우를 개선하라. 좋은 시작점은 앱 팀이 구조화된 도구와 피드백 루프를 갖춘 현대 개발자 경험 설정을 보는 것이다.
USD 37.5 billion
목차
- 소개 앱의 건강은 지금 더 중요합니다.
- 앱 건강 모니터링이 실제로 무엇을 의미합니까?
- Core Metrics and Vitals을 추적해야 하는 이유
- 인스트루멘테이션 및 텔레메트리 아키텍처를 설계하는 방법
- Alerting SLOs와 Runbooks를 통해 데이터에서 행동으로
- 실시간 업데이트 및 릴리스 관찰성을 통해 회복 속도를 높여라
소개: 앱의 건강은 지금 더 중요해졌다
생산 중단은 드문 경우지만, 일반적인 작업 중에 시작된다. 사용자는 업데이트된 앱을 열고 느린 화면을 마주한다. Android 빌드에서 백그라운드 동기화가 하나의 빌드에서 멈춘다. 백엔드 변경은 이전 클라이언트 버전을 깨트린다. 아침 QA에서 건드리지 않은 경로다.
지원 팀은 결과를 보게 되지만, 원인은 보지 못한다. 사용자는 작업을 중단하고, 다시 시도하여 중복 상태를 만들거나, 신뢰를 잃고 떠난다.
앱 건강 모니터링은 이제 기본적인 엔지니어링 분야이다. 모바일 또는 데스크톱으로 자바스크립트를 배포하는 팀은 장치, 네트워크, OS 버전, 백엔드 의존성, 릴리스 채널을 포함한 라이브 시스템을 운영한다. 시각화는 앱이 프로덕션에서 무엇을 하고, 팀이 행동이 변경될 때 얼마나 빠르게 수정할 수 있는지 커버해야 한다.
건강한 소프트웨어는 팀이 추측하지 않고 관찰, 진단, 회복할 수 있는 소프트웨어이다.
그 마지막 부분은 대부분 놓치게 됩니다. 많은 팀은 충돌, 지연, API 오류를 모니터링하고, 그 다음으로 고치는 방법을 별도의 문제로 다룹니다. 실제로, 배포 PIPELINE도 건강을 가지고 있습니다. 만약 regressions를 감지할 수 있지만, 앱 스토어 리뷰를 통해 고치는 데 며칠이 걸리면, 사용자는 여전히 폭파 영역에 있습니다. 만약 빠르게 타겟된 패치를 배포할 수 있다면, 프로덕션 문제는 작게 유지됩니다.
이것이 강력한 모니터링이 엔지니어링 속도뿐만 아니라 신뢰도 향상에 기여하는 이유 중 하나입니다. 클리어한 테레미트리와 신뢰할 수 있는 배포 경로를 가진 팀은 작은 변경을 배포할 수 있고, regressions를 더 일찍 감지하고, 올바른 버전을 고치기 보다는 무의식적으로 롤백하는 대신에, 올바른 버전을 고칠 수 있습니다. 배포 및 디버깅 워크플로우를 위한 개발자 경험 도구 문제를 발견한 후 프로덕션에서 수정하는 시간을 줄이는 데 도움이 됩니다.
사용자가 반복적으로 의존하는 제품에서 압박이 가장 높지만, 패턴은 UNIVERSAL입니다. 의료, 상업, 금융, 내부 운영 도구 및 고객 포털은 오류가 가시성이 없거나 고치는 속도가 느리면 신뢰를 잃습니다. 모니터링은 uptime을 보호하는 것 외에도, 배포 신뢰, 지원 품질 및 팀이 드라마 없이 복구할 수 있는 능력을 보호합니다.
App Health Monitoring이 실제로 무엇을 의미하는지
앱 헬스 모니터링은 단순히 충돌 보고만 하는 것이 아닙니다. 앱이 올바르게 작동하고, 수행이 가능하며, 잘못된 경우 안전하게 복구되는지 지속적으로 확인하는 ongoing practice입니다.
A car dashboard를 생각하는 좋은 방법은 앱의 건강한 모니터링을 위해 모니터링 설정이 하는 일입니다. 모니터링 설정은 흩어져 있는 신호를 운영 상태에 대한 인식으로 변환합니다.
앱의 건강한 모니터링을 유지하는 네 개의 기둥입니다.
앱의 건강한 모니터링을 유지하는 네 개의 기둥 중 첫 번째 기둥은 관찰입니다.실행 중인 앱과 앱이 의존하는 서비스에서 수집하는 모니터링 데이터입니다. 그것은 충돌, 자원 사용, 네트워크 오류, 장치 상태, 릴리스 버전, 사용자 흐름 컨텍스트를 포함합니다. 충분한 컨텍스트를 수집하지 않으면 실패가 발생했지만 왜 발생했는지 알 수 없습니다.
앱의 건강한 모니터링을 유지하는 네 개의 기둥 중 두 번째 기둥은 탐지입니다.raw 데이터는 팀이 비정상적인 패턴을 식별할 수 없기 때문에 도움이되지 않습니다. 새로운 롤아웃 후 예외의 급증은 메모리 사용량이 여러 앱 세션 동안 느리게 증가하는 것과는 다릅니다. 탐지는 임계값, 기준선, 릴리스 비교가 중요합니다.
앱의 건강한 모니터링을 유지하는 네 개의 기둥 중 세 번째 기둥은 진단입니다.진단은 증거를 연결하는 것이며, 강력한 팀과 소음 팀을 구분하는 것입니다. 진단은 로그를 읽는 것만으로는 충분하지 않습니다. 예외 클러스터와 앱 버전, 장치 모델, API 지연 시간, 또는 특징 플래그 상태를 연결하여 실패가 재현 가능한 설명으로 좁혀지도록 합니다.
네 번째 기둥은 수정.
모니터링이 행동의 길을 제공하지 않으면 비용이 많이 드는 기록 보관소가 됩니다.
팀은 신호에 연결된 수정 전략, 롤백 경로 또는 완화 단계가 필요합니다.
반응형 디버깅은 너무 늦습니다.
- 많은 팀이 여전히 모니터링을 생산驚愕의 우편함으로 다룹니다. 사고가 발생합니다.
- 누군가 조사합니다. 패치가 대기열에 넣어집니다.
- 사용자는 기다립니다. 그 패턴은 특히 모바일에서 확대되지 않습니다. 사용자가 혼합된 버전과 나쁜 네트워크 조건을 사용할 수 있기 때문입니다. 모니터링은 일상적인 엔지니어링 결정에 통합될 때만 작동합니다:
- 회복 후: 테스트 데이터와 업데이트 하세요.
실용적인 규칙: 지원 티켓에 포함된 정보가 테스트 데이터가 이미 캡처해야 하는 정보라면, 인스트루먼트가 불완전합니다.
좋은 앱 헬스 모니터링은 모든 것을 수집하는 것이 아니라, 이해 시간을 단축하는 신호를 수집하는 것입니다.
필수적으로 추적해야 하는 코어 메트릭스 및 비타리얼
약한 모니터링 설정을 빠르게 구축하는 가장 빠른 방법은 오류만 추적하는 것입니다. 오류는 중요하지만, 그들은 늦은 증상입니다. 건강한 시스템은 종료되기 전에 경고 신호를 보여줍니다. 앱이 안정적이지만, 스트레스가 가중되거나, 차단되거나, 점진적으로 감소하는지 알려주는 메트릭스를 원합니다.
강한 기반을 만드는 것은 7개의 코어 기술 지표에서 시작합니다. 이 애플리케이션 헬스 모니터링 요구 사항에 대한 토론에 따르면, 팀은 다음을 추적해야 합니다.애플리케이션 런타임 상태, CPU, 메모리, 네트워크 사용량 스파이크, 미처리 예외 보고서, 모듈 상태, 외부 구성 요소 상태, 백그라운드 작업 대기열 수, 사용 통계 모든 대시보드에 속해야 하는 7개의 기술 지표.
The seven technical indicators that belong on every dashboard
실무자들이 그들에 대한 행동을 취할 수 있도록 그들에 대한 실질적인 방법입니다.
| 지표 카테고리 | 예시 지표 | 그것이 무엇을 말하는지 |
|---|---|---|
| 안정성 | 컨텍스트: Enterprise 제품/가격 페이지. 역할: UI 레이블. 표시되는 곳: enterprise.astro 페이지. 메시지 키 `enterprise_hero_stability_label` (Enterprise Hero Stability Label). | 런타임 상태, 처리되지 않은 예외, 앱 종료 패턴 |
| 앱이 사용 가능하거나 완전히 실패하는지 여부 | 성능 | 컨텍스트: 홈페이지 문제/해결 섹션. 역할: 섹션 또는 페이지 제목. 표시되는 곳: page premium-support.astro. 메시지 키 `ps_help_performance_title` (Ps Help Performance Title). |
| 네트워크 사용량 급증, 느린 요청, 렌더링 차단, 시작점 회귀 | 사용자가 지연, 멈춤, 또는 감소된 반응성 경험하는지 여부입니다. | 앱이 장치 수준의 스트레스로 인해 종료될 수 있는지 여부 |
| 컴포넌트 상태 | 모듈 상태, API 가용성, 데이터베이스 접근성, 외부 서비스 상태 | 주 앱 쉘 외부에서 실패를 일으키는 의존성 여부 |
| 배경 작업 | 대기 작업 수, 큐 백로그, 싱크 리트라이 | 비동기 작업이 지연되거나 누적되는지 여부 |
| 제품 동작 | 사용 통계, 기능 경로, 드롭 오프 지점 | 앱의 어떤 부분이 최적화나 더 자세한 관찰이 필요한지 |
그 표가 더 유용해질 때는 각 지표가 릴리스 버전, 플랫폼, 환경, 사용자 흐름 컨텍스트와 함께 태그가 되어야 한다. 실패가 발생한 곳을 설명할 수 있어야 한다.
모바일 팀에게는 가장 쉬운 실수 중 하나가 리소스 신호를 무시하는 것이다. 앱이 '종종 충돌하지 않는다'는 이유로. 메모리 압박, 배터리 가중 루프, 또는 반복적인 네트워크 리트라이가 먼저 사용자에게 열대성, 느려짐, 또는 몇 초 동안 화면이 멈추는 것에 대한 불만을 나타낸다.
애플리케이션의 건강한 상태를 읽는 방법
이러한 메트릭은 고립되지 않습니다. 그들은 chain으로 연결됩니다.
메모리 사용량이 증가하면 예외 빈도가 증가할 수 있습니다. 백그라운드 작업이 대기 중이면 네트워크 경쟁이 증폭될 수 있습니다. 외부 서비스가 저하되면 모듈이 재시도 루프에 들어가서 사용자 측면에서 인터페이스가 멈춘 것처럼 보일 수 있습니다. 대시보드가 이러한 원인-효과 연결을 보여주지 못하면 대시보드는 계속해서 노이즈가 될 것입니다.
다음 세 가지 질문에 대한 답변을 제공하는 대시보드를 사용하십시오:
- 현재 앱이 사용하기에 건강한 상태인가?
- 어떤 릴리스 또는 의존성이 패턴을 변경했는가?
- 어떤 사용자 세그먼트가 영향을 받고 있는가?
기본선에 대한 팀이 앱의 성능 지표에 대한 더 좁은 지표 프레임워크를 비교하는 데 도움이 되는 것은 앱 성능 지표에 대한 이 안내서를 참조하십시오. 목표는 더 많은 차트가 아니라 더 많은 모호한 사고를 줄이는 것입니다.증상에서 서브시스템까지의 경로를 추적하십시오. '체크아웃이 느려진다'는 불만입니다. '인증 리프레시 후에 특정 앱 버전에서 체크아웃 지연이 증가한다'는 팀이 고칠 수 있는 것입니다.
또한 실질적인 트레이드 오프는 granularity입니다. 이벤트당 테레미트로 디버깅 세부 정보를 제공하지만 비용과 노이즈를 증가시킵니다. 가능한 한 집계하고 위험한 경로인 인증, 결제, 동기화, 오프라인 복구 및 시작과 관련하여 충분히 샘플링하십시오.
애플리케이션의 건강한 상태를 읽는 방법
만약 모니터링 설정을 필수 요소로 줄이면, 나는 예외 캡처, 런타임 상태, 메모리 동작, 의존성 건강, 릴리스 구분된 사용 패턴을 유지할 것입니다. 일반적으로 이 다섯 가지가 버그, 성능 회귀, 또는 깨진 의존성을 확인하는 데 사용됩니다.
인스트루먼트이션 및 텔레메트리 아키텍처 설계
SDK를 프로젝트에 추가한 이유로 메트릭이 나타나지 않는다. 그들은 팀이 관찰할 것을 결정하고, 어디서 캡처할 것인지, 그리고 데이터가 유용한지 보장하기 위해 얼마나 많은 context를 보존할 것인지에 따라 나타난다.
앱 동작이 더 밀도가 높아질수록 아키텍처는 더 중요해진다. 건강 관련 모바일 데이터의 더 광범위한 규모의 문제를 하나의 예로 들 수 있다. 평균 iPhone와 Apple Watch pair가 하루에 approximately 8,000건의 건강 관련 데이터 포인트를 생성한다라고 health app data summary에 따르면. 앱이 건강 관련이 아니더라도, 이 교훈은 유지된다. 현대 앱은 많은 팀이 무작위로 캡처할 수 있는 텔레메트리 기회보다 훨씬 더 많은 텔레메트리 기회를 생성한다.
수집 경계를 시작한다
인스트루먼트이션은 가장 높은 위험 경계에서 시작해야 한다:
- 앱 라이프 사이클 이벤트: 시작, 전면, 배경, 종료, 재개.
- 네비게이션 경계: 화면 진입, 화면 이탈, 실패한 전환, 예상치 못한 리다이렉트.
- 네트워크 경계: 요청 시간, 재시도 동작, 응답 실패, 직렬화 오류.
- 상태 경계: 인증 갱신, 로컬 캐시 재수용, 마이그레이션, 오프라인 동기화, 기능 플래그 적용.
- 릴리스 경계: 앱 버전, 자바스크립트 번들 버전, 업데이트 채널, 빌드 환경.
이 점들은 앱이 건강에서 불건강으로 넘어간 시점을 알려줍니다.
자바스크립트가 많은 모바일 앱의 경우, 클라이언트 측 추적은 백엔드 측 추적과 함께 작동해야 합니다. 프론트엔드에서 결제 요청 실패를 기록했지만 API 로그가 요청 경로를 추적하지 못한다면, 이슈는 여전히 너무 오래 해결됩니다.
로그, 메트릭, 트레이스 문제를 해결하는 서로 다른 방법입니다.
팀들은 종종 모든 것을 "로깅"에 포함시키고, 디버깅이 느려질 것을 의아해한다.
- 메트릭스 로그
- context: Capgo Builder / native cloud build product page. Role: Short UI label or navigation item. Seen in: page native-build.astro. Message key `native_build_v2_trust_logs_lbl` (Native Build V2 Trust Logs Lbl). 특정 이벤트나 code 경로에서 무슨 일이 일어났는지 알려준다.
- 트레이스 요청이나 작업이 서비스와 컴포넌트를 가로질러 이동하는 것을 알려준다.
모두가 필요하지만, 같은 깊이에서 모든 곳에 존재할 필요는 없다. 메트릭스는 앱 전체에 걸쳐야 한다. 로그는 구조화되고 선택적으로 있어야 한다. 트레이스는 서비스 경계를 넘어가는 워크플로우나 비싼 리트라이가 포함된 경우 가장 중요하다.
만약 벤더를 비교하거나 스택에 무엇을 합치려는 경우, 이 연간 성능 모니터링 도구 리뷰는 2026년 실제로 도구가 가시성, 경고, 진단에 접근하는 방법의 실질적인 차이를 강조하기 때문에 유용한 참조점이다.
컨텍스트에 맞게 빌드하라, 볼륨에 맞게 빌드하지 마라.
이벤트를 증거로 바꾸는 건 컨텍스트야. 모든 이벤트에 대해 중요하다고 생각하는 모든 이벤트는 첫 번째 디버깅 질문에 대한 답변을 위해 충분한 메타데이터를 포함해야 한다. 그게 일반적으로 플랫폼, OS, 앱 버전, 릴리스 채널, 장치 특성, 화면 또는 기능 이름, 의존성 상태를 의미한다.
빌드 대부분을 직접 만들거나 호스팅된 제품에 의존하는 건 일반적인 트레이드 오프야. 세 번째 파티 플랫폼은 더 빠른 대시보드와 알림을 제공한다. 커스텀 PIPE라인은 스키마, 보존, 개인 정보 경계에 대한 더 많은 제어를 제공한다. 많은 팀은 하이브리드 방식을 사용한다. 그들은 상업적 오류 및 추적 제품을 사용하고 릴리스 이벤트 및 앱 특정 워크플로에 집중된 인스트루먼테이션을 추가한다. React Native 팀이 이 스택을 생각하고 있다면 이 React Native에 대한 Sentry 설정 가이드 은 하나의 층이 더 넓은 테러미터 아키텍처에 어떻게 들어가는지 실제적인 예시야.
엔지니어가 지원 질문에 대한 증거로 답변할 수 있는 아키텍처는 좋다.
데이터에서 액션으로: 알림 SLO 및 런북
대시보드는 여전히 팀을 어둡게 둘 수 있다. 왜냐하면 nobody가 무엇이 주목할 만한지 알지 못하기 때문이다. 유용한 모니터링과 알림 피로의 차이는 일반적으로 SLO, 알림 라우팅 규칙, 런북이 사람들에게 다음 단계를 알려주는지 여부에 있다. SLO는 단순히 내러빌리티 프로미스를 측정할 수 있는 것으로 번역한 것뿐야. 사용자 경험을 반영해야 한다. 내부 자랑하는 메트릭이 아닌.사용자가 로그인할 수 있는지에 대한 보장은 유용하다. 어플리케이션이 오늘 하루에 더 적은 경고를 내보냈다는 건 아니다.
이벤트를 증거로 바꾸는 건 컨텍스트야. 모든 이벤트에 대해 중요하다고 생각하는 모든 이벤트는 첫 번째 디버깅 질문에 대한 답변을 위해 충분한 메타데이터를 포함해야 한다. 그게 일반적으로 플랫폼, OS, 앱 버전, 릴리스 채널, 장치 특성, 화면 또는 기능 이름, 의존성 상태를 의미한다.
좋은 알림은 사용자 영향력으로 시작됩니다.
사용자가 차단, 저하, 또는 위험에 처해 있을 때 알림을 설정하세요. 모바일 및 JS 앱의 경우, 그 조건은 일반적으로 몇 가지 패턴으로 클러스터됩니다:
- 사용자 영향도: 릴리스가 예외 클러스터를 생성하여 런칭을 방지하거나 주요 흐름을 깨뜨립니다.
- 성능 영향: 시작, 화면 전환, 또는 중요 API 경로가 사용자가 액션을 취하지 않도록 충분히 저하됩니다.
- 의존성 영향: 외부 서비스 실패가 인증, 동기화, 또는 체크아웃에서 눈에 띄는 깨끗이 깨뜨립니다.
- 복구 영향: 재시도, 큐, 또는 백그라운드 작업이 자연스럽게 지워지지 않습니다.
기술적인 잡음에 대한 알림을 피하세요. 사용자가 영향이 없는 이상치에 대한 시스템이 페이지를 보내면 엔지니어들은 알림에 신뢰를 잃습니다.
Field note: __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__ 백엔드, 모바일 릴리즈, 지원 통신 및 사고 조정에 대한 소유권.
앱 알림을 배달 워크플로우와 연결하는 팀은 더 빠르게 복구할 수 있습니다. 왜냐하면 릴리즈 시스템을 프로덕션 건강과 분리하는 것으로 간주하지 않기 때문입니다. 그 다리 건너기를 위해 빌드하고 있다면 CI/CD pipeline에 알림을 추가하는 방법에 대한 이 안내서 엔지니어링 액션을 프로덕션 신호와 연결하는 유용한 모델입니다.
Runbooks도 일관성을 개선합니다. 주니어 엔지니어가 'sync 백로그 플러스 오르는 메모리 플러스 하나의 나쁜 릴리즈 채널'을 진단하는 유일한 사람일 필요는 없습니다. 사고가 아직 свеж한 동안 그 내용을 적어두세요.
실시간 업데이트 및 릴리즈 관찰성으로 복구를 가속화하세요.
기존 앱 건강 모니터링은 일반적으로 감지까지만 멈춥니다. 앱이 충돌했으며 팀이 왜 그런지 알고 있으며 이제 모든 사람들이 스토어 검토 릴리즈 또는 단계별 롤아웃을 기다리기만 하면 됩니다. 그런 경계는 자바스크립트 기반 모바일 앱을 배포하는 팀에게 더 이상 의미가 없습니다.
앱은 고쳐지지 않는다면 건강하지 않습니다. 릴리즈 건강은 앱 건강의 일부입니다.
릴리즈 pipeline도 건강합니다.
많은 모니터링 설정은 배포가 이진으로 간주합니다. 업데이트가 배포되거나 배포되지 않은 경우입니다. 실제로는 배포가 기술적으로 가능하지만 기능적으로 불건강한 상태가 있습니다.
그 격차는 중요합니다. 위에서 언급한 것과 같이 이 기사에서는 업데이트 전달 및完整성에 대한 모니터링의 빈틈에 대해 다룹니다.많은 앱 헬스(Dashboard) 토론에서 업데이트가 배포되었지만 여전히 불건강한 이유에 대한 경우를 놓치고 있습니다. 예를 들어, 서명 불일치 또는CDN 전파 지연
. 규제 환경에 있는 팀에게는 이것이 작은 경계 사례가 아닙니다. 그것은 릴리즈 신뢰성의 일부입니다.
실시간 업데이트 시스템에서 회복 모델이 바뀌게 됩니다. 앱 스토어만으로 모든 자바스크립트修정의 수리 경로로 간주하는 대신, 팀은 실제 장치에서修정 패키지가 다운로드, 검증, 적용, 안정화되는지 관찰할 수 있습니다.
릴리즈 관찰성에 대해 무엇을 포함해야 하나요?
- 릴리즈 PIPELINE은 자신의 운영 신호가 필요합니다. 최소한, 다음을 모니터링하세요: 업데이트 수용 상태:
- 장치가 의도한修정 버전으로 이동하는지 여부입니다. 배포 상태:
- 배포 상태: 배포 속도:
- 롤백 트리거: 장치가 롤백되는지 여부: 새로운 배포가 유효성 검사에서 실패하거나 장애를 일으키는지 여부.
- 장치별 확인: 특정 영향을 받은 사용자가 실행 중인 것을 확인할 수 있는지 여부.
이것은 전문적인 배포 플랫폼이 실제로 채우기 어려운 한 가지 영역입니다. Capacitor 팀에게는 Capacitor이 제공하는 signed bundle delivery, rollback support, version history, version history, release observability가 필요합니다. Capgo 자바스크립트 업데이트에 대한 signed bundle delivery, 롤백 지원, 버전 기록, 릴리스 관찰성을 제공합니다. 배포 후에 관심 있는 신호의 구체적인 그림을 원한다면 __CAPGO_KEEP_0__ 앱의 실시간 업데이트 메트릭이 문제를 잘 설명합니다. Capacitor 앱의 실시간 업데이트 메트릭이 문제를 잘 설명합니다. __CAPGO_KEEP_0__ 앱의 실시간 업데이트 메트릭이 문제를 잘 설명합니다.
사용자가 "업데이트하고도 여전히 실패한다"고 말할 때, 팀은 사용자가 추측하지 않도록 하여 실행 중인 버전, 배포 시도, 롤백 상태를 확인할 수 있어야 합니다.
회복 속도가 팀의 행동을 변경합니다.
팀이 직접 릴리스 건강을 관찰할 수 있게 되면, 그들은 일반적으로 릴리스 방식을 변경합니다. 그들은 더 작은 수정 사항을 푸시합니다. 그들은 위험한 변경 사항을 좁은 채널로 대상으로합니다. 그들은 롤백 속도가 더 빠릅니다. 지원 팀은 "다음 스토어 릴리스를 기다려 주세요"라는 더 깨끗한 답변을 얻습니다.
이것은 릴리스 경로가 관찰 가능해지면 사고 대응이 훨씬 더 실용적인 것을 의미합니다.
기존 모델은 모니터링을 진단만으로 다루었습니다. 더 나은 모델은 감지, 진단, 수정, 배달 확인, 회복 확인을 모두 포함하는 닫힌 루프로 다루어야 합니다.
팀이 Capacitor 또는 Electron 앱을 배포하고 릴리스 건강에 대한 더 chặt한 통제를 원한다면 Capgo 팀이 signed JavaScript, CSS, config, copy, 및 asset 수정 사항을 빠르게 배포하고 수용, 실패, 롤백, 및 장치별 업데이트 상태를 추적할 수 있는 방법을 제공합니다.
