Martin Donadieu

금요일 오후 자바스크립트 업데이트 루틴이 진행되었습니다. 앱이 열리고, 인증이 정상적이고, 충돌 카운터는 특별하지 않습니다. 그러나 일부 장치에서 체크아웃이 실패하고, 앱 스토어 및 플레이 콘솔 대시보드는 롤백을 확신할 수 있는 신속한 결정을 지원하지 못합니다.

그 사건은 앱 헬스 체크를 앱 헬스 체크 대시보드 리뷰로만 다루는 약점을 드러냈습니다. 건강한 릴리스는 단순히 충돌을 피하는 것이 아닙니다. 앱이 빠르게 시작되어야 하며, 중요한 화면을 렌더링하고, 중요 journey를 완료하고, 올바른 백엔드 버전에 도달하고, 온콜 엔지니어가 지연된 스토어 데이터가 따라잡을 때까지 행동할 수 있는 충분한 테레미트를 제공해야 합니다.

목차

• 금요일 오후 사건이 이 플레이북을 시작하는 이유
• 사용자 고통을 예측하는 건강 기준 정의
  • 릴리스 게이트와 진단 신호를 분리하세요
• 이번 주에 연결할 수 있는 런타임 체크
  • 결정에 영향을 미치는 신호부터 시작하세요
  • 알람만 아니라 행동을 측정하세요
• 애플리케이션 건강 점검과 CI 검사
  • 사용자에게 문제가 발생하기 전에 문제를 잡아내는 엔드포인트와 CI 검사
  • 응답이 유용하고 한계가 있는지 확인하십시오
• 업데이트, 업데이터, 그리고 스토어와 디바이스 사이의 블라인드 스팟
  • 채널을 안전한 경계로 다루십시오
• 자바스크립트 앱의 보안, 권한, 및 수집 데이터의 위생
• 건강 신호가 트리ップ했을 때 복원 및 롤백

금요일 오후 사고가 이 플레이북을 시작합니다

첫 번째 보고서는 다음과 같이 звItemClick합니다: "체크아웃이 일부 사용자에게 깨졌습니다." 지원 팀은 몇 장의 스크린샷을 가지고 있고, 엔지니어 팀은 최근 배포본을 가지고 있으며, 스토어 콘솔에서는 명백한 백서가 없습니다. 팀은 로그를 비교하고, 최근 배포본을 사용하여 흐름을 재현하고, 업데이트 상태, 백엔드 응답 형태, 및 더 오래된 네이티브 셸에 의존하는 결함을 발견합니다.

그것은 디버깅 세션이 아닙니다. 그것은 릴리스 시스템의 실패입니다.

대부분의 KPIs는 24시간에서 72시간까지의 시간 차이가 있습니다. 애플리케이션 스토어 대시보드는 대부분의 KPIs가 24시간에서 72시간까지의 시간 차이가 있습니다.실시간 사고 중에 rollback 트리거로만 사용하기에는 너무 느립니다.

실용적인 규칙: 스토어 콘솔은 보고 지연 후에 무슨 일이 일어났는지 알려줍니다. 업데이터와 런타임 테스트 데이터는 현재 릴리스가 현재 무엇을 하는지 알려줘야 합니다.

반복적인 건강 검사는 팀에게 세 가지 증거 layer를 제공합니다:

• 런타임 품질: crash, ANR, 시작 동작, 화면 렌더링, 오류 및 자원 압박.
• 사용자 결과: 로그인 완료, 체크아웃 성공, 결제 확인 및 사용자가 성공 또는 실패로 인식하는 다른 여행.
• 릴리스 전달: 수용, 실패한 설치, 차단된 장치, 채널 동작 및 롤백 상태.

각 layer는 해당 운영적 레버와 일치해야 합니다. Crash regression은 배포 중단 또는 자바스크립트 번들의 재배포가 필요할 수 있습니다. 실패한 백엔드 종속성은 앱 롤백이 아닌 서비스 수리 필요합니다. 깨진 업데이트 경로는 채널 제어 및 장치 수준의 조사 필요합니다.

실용적인 대응은 시간표에서 시작해야 합니다. 배포 시점, 채널, 첫 번째 실패한 여행, 영향을 받은 버전을 기록하고 다음에 사용해야 합니다. 모바일 팀의 사고 대응 가이드 사고 대응 시 주인공을 지정하고 증거를 보존하며 가장 안전한 조치가 채널 일시 중단, 롤백, 또는 원본 배포인지 결정하는 방법

이 프로세스의 목적은 간단합니다: 침묵적인 실패를 줄이고 나쁜 신호와 안전한 조치를 연결하는 거리를 단축하는 것입니다.. 나머지 건강 검사 절차는 그 결과에 따라 설계되어야 합니다.

사용자 고통을 예측하는 건강 기준 정의

금요일 배포는 사용자가 로그인, 결제, 업데이트 수신에 실패하는 동안 녹색 스토어 대시보드를 보여줄 수 있습니다. '건강한' 상태를 정의하세요. 그 전에 사고가 발생하기 전에 각 신호를 배포, CI, 또는 롤백 결정과 연결하세요. 플랫폼 보고가 신뢰할 수 있는 것으로 되기까지 24시간에서 72시간 동안 스토어 테스트 데이터가 눈에 띄지 않는다는 점을 고려하세요.

첫 번째 계층은 사용자가 의미 있는 작업을 완료할 수 있는지 여부를 설명합니다:

1. 비정상 종료가 없는 세션. iOS의 경우 99.93%Android의 경우는 99.81%로 문서화되어 있습니다. 앱 건강 프레임워크 참조. 이 값을 검토 기준으로 사용하십시오. UNIVERSAL 보장은 아닙니다. 릴리스, 운영 체제, 장치 패밀리, 론칭 코호트에 따라 구분하십시오. 릴리스별 드롭은 확장 중단 또는 번들 리버트를 트리거합니다.
2. ANR 동작. 로그인, 체크아웃, 결제 확인과 같은 UI가 블록되면 시스템이 멈추지 않더라도 사용자에게 불편을 주는 상황입니다. 버전과 흐름에 따라 ANR를 그룹화하고 WebView 작업, 플러그인 호출, 네이티브 브리지를 확인하십시오. 해결 방법은 code 또는 CI에 있지만 론칭을 중단하는 것은 롤백을 트리거합니다.
3. 시작 및 화면 준비. UI가 준비되기까지의 시간을 측정하십시오. 프로세스가 빠르게 시작되지만 첫 번째 유용한 화면이 비어 있는 경우 여전히 불건강합니다. CI에서 회귀를 검사하는 기준을 설정하고 실패 시 장치 로그를 검사하십시오.
4. 중요한 여행 성공. 로그인, 검색, 체크아웃, 결제, 동기화, 로그아웃과 같은 사용자 여행에 성공 이벤트를 명시적으로 정의하십시오. HTTP 응답은 사용자가 확인에 도달했는지 증명하지 않습니다. 드롭은 롤백을 선택하기 전에 영향을 받은 흐름을 식별해야 합니다.

릴리스 게이트와 진단 신호를 분리하십시오.

릴리스 게이트 일반적으로 시스템이 멈추지 않는 세션, ANR, 시작, 인증, 가장 높은 가치의 사용자 여행을 포함합니다. 진단 신호 메모리 압박, 배터리 영향, 저장 공간 증가, 네트워크 지연, HTTP 오류 클래스 및 WebView 렌더링을 포함합니다. 그들은 실패를 설명하고 개선 방법을 안내하지만 모든 배포를 자동으로 차단하지 않아야 합니다.

각 기준을 네 개의 field로 작성하세요:

이것을 사용하세요 앱 헬스 모니터링 지침 시작점으로 사용하여 모든 신호를 사람이나 회전에 할당하고 결과를 바꾸는 레버를 문서화하세요. 원본 신호를 보존하세요. 단일 점수는 건강한 배경 활동 뒤에 심각한 결제 실패를 숨길 수 있습니다.

건강한 릴리스는 안정적이고 반응성이 있고 관찰 가능하며 사용자가 가치하는 작업을 완료할 수 있습니다. 또한 온콜 엔지니어가 수행할 수 있는 동작과 연결되어 있습니다.

런타임 체크를 이번 주에 연결할 수 있는 항목

앱에서 사용자가 작업을 경험하는 곳에서만 아니라 프로세스가 생명체라고 보고하는 곳에서만 인스트루먼트를 하세요. Capacitor 앱은 자바스크립트 예외, 네이티브 충돌, 브리지를 실패, 네비게이션 타이밍, 여행 이벤트를 캡처할 수 있습니다. 이 전자 앱은 렌더러 프로세스 실패, 메인 프로세스 오류, 로드 실패, 윈도우 준비, 리소스 관찰을 추가할 수 있습니다.

실용적인 앱 헬스 체크는 안정성과 성능을 함께 측정합니다, 포함하여 충돌률, ANR률, 시작 시간, 화면 렌더링 시간, 오류률, 리소스 활용도를 포함합니다. 모바일 성능 헬스 체크 지침 또한 릴리스 버전과 롤아웃 코호트에 따라 구분합니다. 그 구분이 없으면 건강한 오래된 버전은 실패하는 새로운 버전을 숨길 수 있습니다.

Start with the signals that change a decision

애플리케이션의 상태를 체크하는 동안 세션 식별자, 앱 버전, 네이티브 셸 버전, 플랫폼, 장치 클래스, 지역, 롤아웃 채널과 같은 정보를 기록하십시오. 개인 정보를 포함하지 않도록 하십시오. 이 정보는 디버거를 열기 전에 "누구에게 영향을 미치는가?"라는 질문에 대한 답변을 제공하는 데 도움이 됩니다.

각 신호에 대해, 목표와 응답을 정의하세요.

• Crashes: 플랫폼 기준 위 표를 통해 충돌 없는 세션을 비교하세요. 출시별로 감소하는 경우에는 영향받는 그룹을 일시 중단시키고, 엔지니어들이 스택 또는 플러그인 경계를 식별할 때까지 기다려야 합니다.
• ANRs: 스크린과 작업에 따라 이벤트를 그룹화하세요. 브리지 호출 중 반복적인 멈춤은 데이터베이스 마이그레이션 중 멈춤과 다른 해결책을 필요로 합니다.
• 런칭 시간: 첫 번째 인터랙티브 화면이 사용 가능해지는 지점을 표시하세요. 느린 결과는 oversized web assets, synchronous initialization, certificate checks, 또는 navigation 이전에 실행되는 플러그인과 같은 요인으로부터 발생할 수 있습니다.
• 스크린 렌더링: 체크아웃, 로그인, 검색, 기타 주요 화면에서 시작 및 준비 이벤트를 발생시킵니다. 준비 이벤트가 누락된 경우 종종 silent failure로 나타나고 이는 리포팅되지 않는 충돌로 이어집니다.
• 에러율: __CAPGO_KEEP_0__
• 리소스 사용량: 메모리, 저장소, 배터리 동작, 네트워크 오류를 감시하여 증거로 사용하세요. 리소스 트렌드가 가장 중요할 때는 실패한 여행이나 ANR와 연관이 있을 때입니다.

아래 표는 의도적으로 보수적입니다. 브리프에서 벤치마크가 제공되는 경우에는 포함됩니다. 다른 밴드는 자신의 안정된 기준점에서 선택하여 UNIVERSAL LIMITS로 만들지 마세요.

알람만 아니라 동작을 측정하십시오

크래시 이벤트는 릴리스와 롤백 경로로 연결되어야 합니다. 체크아웃 실패는 실패한 단계와 응답 클래스로 연결되어야 합니다. 런칭 리그レ션은 초기화 단계가 시간을 소비한 단계로 연결되어야 합니다.

Capacitor 팀은 자바스크립트 및 네이티브 경계 근처에서 측정기를 가까이 두고, 물리적 장치에서 검증하세요. Electron의 경우 렌더러와 메인 프로세스 컨텍스트를 별도로 수집하세요. 하나의 프로세스가 실패할 수 있지만 다른 프로세스는 건강해 보일 수 있습니다. Capacitor 성능 모니터링 설정 팀은 이러한 신호를 릴리스 수준의 조사에 연결할 수 있습니다.

사용자보다 문제를 잡아내는 CI 검사와 헬스 엔드포인트

실행 중인 프로세스는 애플리케이션이 준비된다는 증거가 아닙니다. 백엔드는 TCP 연결을 수락할 수 있지만 데이터베이스 풀은 고갈되었을 수 있고 캐시는 사용할 수 없거나 외부 서비스가 타임아웃이 될 수 있습니다.

다음과 같이 사용할 수 있는 전용, 인증되지 않은 준비 엔드포인트를 사용하십시오. /healthz. 이 엔드포인트는 애플리케이션과 중요 의존성이 건강할 때 200을 반환하고 그렇지 않으면 503을 반환해야 합니다. 위의 헬스 엔드포인트 구현 지침을 따르십시오.지침은 500 ms 이하로 유지하고 데이터베이스, 캐시, 중요 외부 서비스를 확인하며 모든 의존성에 타임아웃을 설정하는 것을 권장합니다. 응답을 유용하고 제한된 것으로 만들십시오.CI 검사와 헬스 엔드포인트 500 ms백엔드는 TCP 연결을 수락할 수 있지만 데이터베이스 풀은 고갈되었을 수 있고 캐시는 사용할 수 없거나 외부 서비스가 타임아웃이 될 수 있습니다.

사용자에게 유용하고 제한된 응답을 제공하십시오.

작업을 위한 작은, 안정적인 응답 형태를 반환하십시오. 전체 상태와 기계적으로 읽을 수 있는 구성 요소 상태를 포함하십시오. 그러나 자격 증명, 스택 추적, 내부 호스트 이름, 또는 sensitive 구성 정보를 노출하지 마십시오. 필요한 의존성이 unavailable일 때 준비성 검사 should fail 명확히 하십시오. 반면 옵션 서비스는 앱이 여전히 핵심 기능을 제공할 수 있는 경우에만 진단적이어야 합니다.

상태 code를 포함하는 것보다 더 많은 유효성을 검사하십시오:

• 응답이 예상 필드와 함께 유효한 JSON인지 확인하십시오.
• endpoint가 의도한 백엔드 버전까지 도달하는지 확인하십시오.
• 관련 지역과 네트워크 경로에서 경로를 테스트하십시오.
• independant timeout을 설정하여 하나의 느린 의존성이 전체 프로브를 지연시키지 못하도록 하십시오.
• 인프라가 프로세스 실패와 의존성 실패를 구분할 수 있도록 live와 ready를 분리하십시오.

사용자 관점에서 malformed JSON 또는 만료된 인증서와 함께 200 응답은 건강한 애플리케이션이 아닙니다.

체크를 릴리스 경로 내에 두십시오.

CI에서 배포된 미리보기 환경에 endpoint를 실행하십시오. 그런 다음 앱에 사용되는 API 연산을 실행한 후, 에뮬레이터 또는 디바이스 팜에서 작은 세트의 крит적 UI 흐름을 실행하십시오. 환경이 프로덕션에서 요구하는 동일한 준비성 계약을 만족하지 못하는 경우 빌드는 실패해야 합니다.

GitHub Actions 작업은 간단할 수 있습니다:

• 웹 번들 및 네이티브 셸을 빌드하세요.
• 격리된 환경으로 배포하세요.
• Poll /healthz 시간 제한을 걸어
• 상태와 응답 형태를 검증하세요.
• 로그인 및 수익 중추적인 여행을 위한 통합 테스트를 실행하세요.
• 모든 게이트가 통과한 후에만 배포하세요.

엔드포인트는 쓰기나 파괴적인 마이그레이션을 수행하지 말고, 자주 호출할 수 있는 비용이 저렴하고 안전한 상태로 유지하세요. 엔드포인트는 릴리스 게이트이기 때문에 두 번째 애플리케이션이 아닙니다.

업데이트, 업데이터, 스토어와 디바이스 사이의 블라인드 스팟

릴리스는 기술적으로 완벽할 수 있지만, 장치가 업데이트를 받지 못하거나 설치하지 못하거나 상태를 보고하지 못하는 경우, 운영상으로 실패할 수 있습니다. 따라서 업데이터는 앱 헬스에 포함되어야 하며, 배포 세부사항이 아닙니다.

체크아웃 유효성 검증을 변경하는 자바스크립트 번들을 고려하세요. 스토어에 설치된 네이티브 셸은 여전히 사용 가능하지만, 업데이트 채널은 새로운 웹 자산을 일부 장치로 전달합니다. 일부 장치는 성공적으로 설치되지만, 다른 장치는 유효성 검증을 통과하지 못하거나 네이티브 버전이 호환되지 않아 블록되기도 합니다. 스토어 대시보드는 이러한 상태의 차이를 즉시 표시하지 못합니다.

보고하는 격차는 중요한 문제입니다. 스토어 대시보드는 약 24시간 내에 대부분의 KPI와 72시간 내에 충돌 및 ANR 비율에 대해, 모바일 릴리스 가시성 참조. 근사 실시간 업데이터 테스트 메트릭이 시간 간격을 채우며, 어떤 기기에서 패키지를 받았는지, 설치가 실패했는지, 롤백했는지, 어떤 기기에서 체크인하지 않았는지 보여줍니다.

스크린샷

채널을 안전한 경계로 다루세요

운영 관련 조작 장치들은 구체적이다:

• 운영적 조절 장치들은 구체적입니다: 보호대:
• 비호환 패키지를 지원되지 않는 쉘에 도달하지 않도록 방지하세요. 대상 롤아웃:
• Differential delivery: 업데이트를 지원하는 경우에만 변경된 자산만 전송하여 업데이트에 필요한 작업량과 데이터 양을 줄입니다.
• 롤백 보호: 설치 또는 시작 유효성 검사 실패 시 이전에 알려진 좋은 버전으로 복원합니다.
• 버전 비교: 새로운 계열과 안정적인 대조군에 대한 새로운 버전의 크래시, 런칭, WebView, 및 여행 건강을 비교합니다.

Capgo은 Capacitor 및 Electron 팀이 서명된 자바스크립트, CSS, 구성, 및 자산 업데이트, 대상 채널, 장치별 로그, 수용 및 실패 메트릭, 및 롤백 제어를 필요로 하는 옵션입니다. 그 Capacitor의 라이브 업데이트 개요 __CAPGO_KEEP_0__ 업데이터 모델과 팀이 배포 상태를 릴리스 결정과 연결할 수 있는 방법을 설명합니다.

중요한 원칙은 공급업체가 아니라 feedback 루프입니다. 론롤아웃은 증거를 생성해야 하며, 그 증거는 다음 계열이 버전을 받을지 여부를 결정해야 합니다.

자바스크립트 앱의 보안, 권한, 및 텔레메트리 하이진

앱은 권한, 업데이트 신뢰, 또는 텔레메트리에서 불가피한 위험을 지니고도 안정적으로 보일 수 있습니다. Capacitor 및 Electron 릴리스와 함께 플러그인 및 임베디드 웹 콘텐츠를 공격 표면의 일부로 감사해야 합니다.

시작하기:

• 플러그인 허용 목록: 사용하지 않는 플러그인을 제거하고, 네이티브 기능을 검토하고, 연락처, 파일, 위치, 카메라, 마이크, 또는 외부 인텐트에 대한 접근을 확인하세요.
• 깊은 링크 검토: URL 스킴과 Android 인텐트를 테스트하세요. 신뢰되지 않은 링크는 특권된 흐름을 열거나 인증을 무시하지 않아야 합니다.
• 배포물 확인: 업데이트를 적용하기 전에 서명 확인, 불완전하거나 예상치 못한 페이로드를 거부하고, 마지막으로 알려진 좋은 배포물을 복구하기 위해 보관하세요.
• 토큰 저장: 플랫폼 보안 저장소에 자격 증명을 유지하고, 자바스크립트에 접근할 수 있는 파일 또는 제한된 로컬 저장소에 저장하지 마세요.
• 전자 화면 경계: 주 프로세스에서 특권된 API를 유지하고, 좁은 로드 프리로드 인터페이스를 노출하고, 원격 API에 도달하는 네이티브 API를 방지하세요.

추적은 일치하는 제어를 필요로 합니다. 이벤트 이름, 릴리스 식별자, 작업 클래스, 실패 카테고리 기록하세요. 토큰, 결제 정보, 전체 사용자 입력 텍스트, 정확한 위치, 또는 원본 응답 본체를 제외한 경우 문서화된 보안 검토가 허용하는 경우에만.

운영 필요에 따라 보존 기간을 설정하고 역할에 따라 접근을 제한하십시오. 개인 정보 요구 사항이 적용되는 경우 삭제 또는 삭제 경로를 제공하십시오. 건강 이벤트는 릴리스 회귀를 분리하여 사용자 행동의 두 번째 데이터베이스가 되지 않도록 하십시오.

스토어 대시보드는 즉시 전체 그림을 제공할 수 없습니다. 앱 스토어 및 플레이 콘솔의 전송 데이터는 24-72 시간의 보고 간격을 남길 수 있으므로, 업데이터 상태, 릴리스 식별자 및 장치 측정 오류 이벤트와 함께 스토어 신호를 pair 하십시오. Google Play Console 보고서 문서 보고서 문서는 지연된 결과를 해석할 때 고려해야 하는 보고서 컨텍스트를 설명합니다.

릴리스 전에 새로운 권한이 명확한 목적을 가지고 있는지 확인하고, 로그된 field가 소유자가 있는지 확인하고, 업데이터가 신뢰되지 않는 또는 불일치한 배ंडल을 거부하십시오. 불분명한 경계는 릴리스 차단입니다. 신호가 신뢰 또는 개인 정보 실패를 노출할 때, 먼저 배포를 중단하고 그 다음에 문제를 일으킨 릴리스 또는 구성으로 이동하십시오.

Health Signal이 트리거되면 Remediation 및 Rollback

Health Signal은 안전한 액션을 수행할 때만 중요합니다. 사고가 발생하기 전에 팀이 명확하게 생각할 수 있는 동안 결정 tree를 작성하십시오.

• 한 릴리스 또는 계열에서 크래시 또는 ANR 회귀: 해당 채널을 중단하고, 영향을 받은 버전과 안정 계열을 비교하고, 원본 shell이 호환되는 경우 배ंडल을 롤백하십시오.
• Health endpoint가 503을 반환할 때: 앱 배포를 중단하고 실패한 крит적 의존성을 고치십시오. 서비스를 재시작하는 것이 도움이 될 수 있지만, 백엔드 오류를 숨기기 위해 앱 롤백을 사용하지 마십시오.
• 중요한 여행 중 오류가 발생하는 동안 충돌은 정상입니다: 영향을 받은 기능이나 채널을 비활성화하고, 응답 형태와 설정을 검사한 후 수정된 패키지를 배포하세요.
• 설치 또는 시작 유효성 검사에 실패하는 경우: 이전의 패키지를 활성화하여 유지하고, 출시를 비정상으로 표시한 후, 서명, 호환성 또는 자산 무결성과 관련된 문제를 조사하세요.
• 네이티브 권한 또는 플러그인 동작이 잘못된 경우: 실시간 자바스크립트 업데이트만으로는 충분하지 않을 수 있습니다. Fix가 네이티브 code, 매니페스트 변경, 권한, 또는 새로운 권한 선언이 필요할 때, 스토어 릴리즈를 준비하세요.

The Capacitor live update 롤백 전략 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 롤백 전략은 런북에 포함되어야 하며, 위기 상황 중에 페이지를 발견하는 것이 아닙니다. 업데이터가 설치 또는 시작 실패를 신뢰롭게 감지할 수 있는 경우 자동 보호가 적절합니다. 사용자가 런칭을 완료할 수 있지만 중요한 여행 중 오류가 발생하는 경우 전체 사고가 여전히 필요합니다.

이 프로세스를 공식화하는 데 대한 商業 압박은 분명합니다. 모바일 앱 테스트 서비스 시장은 2025 년에 $7.70 억 달러 그리고 2031년까지 17.09%의 연간 성장률을 달성할 것으로 예상됩니다. $19.84 억 달러를 달성할 것으로 예상됩니다.애플 앱 스토어의 거부율은 2024년 약 24.9%로 보고되었습니다. 시장 및 스토어 리뷰 데이터에 따르면.그것은 품질 검사에 대한 선택사항으로 다루는 비용을 강조하는 것입니다. 각 사고 후, 시간선, 가장 먼저 작동할 수 있는 신호를 식별하고, 누락된 검사를 릴리스 게이트로 만들고, 이전 사고를 더 쉽게 감지, 제어 및 역전할 수 있도록 합니다.품질 검사에 대한 선택사항으로 간주하는 비용을 강조합니다.

__CAPGO_KEEP_0__를 방문하여

Capgo gives Capacitor and Electron teams signed live updates, targeted channels, rollout and failure telemetry, per-device logs, and rollback protection so runtime health signals can drive release decisions. Visit Capgo __CAPGO_KEEP_0__