목요일 저녁, CapacitorJS 쇼핑 앱은 Android 14 사용자에게 빈 대시보드를 보여주기 시작했습니다. iOS 고객은 정상적으로 브라우징을 하고 있습니다. Electron 데스크톱 사용자는 아무런 문제를 보고하지 않았습니다. 온콜 엔지니어는 WebView 회귀를 가정하고 Android Studio를 열어, 장치 간 렌더링 동작을 비교하기 위해 몇 시간을 보냈습니다. 최종 원인은 렌더링 버그가 아니었습니다. 스테이징 API 키가 캐시 무효화가 실패하여 모바일 클라이언트에 도달하지 못했기 때문입니다.
이런 사고는 익숙합니다. 모바일 실패는 일반적으로 저장소의 경계를 존중하지 않습니다. 새로운 자바스크립트 변경이 무죄처럼 보일 수 있지만 배포, 구성 값, 권한 상태, 서비스 종속성 또는 네트워크 경로가 사용자 경험을 깨트릴 수 있습니다. 마이크로소프트의 사고 분석 결과 생산 중단 사고의 40%는 code 또는 구성 오류에서 발생했으며, 60%는 인프라, 배포 및 서비스 의존성에서 발생했다.실용적인 교훈은 간단하다: 앱 문제 해결은 스택 추적에 시작하지 않고 전체 실패 도메인에서 시작해야 한다.. (Microsoft의 사고 분석)
이 플레이북은 CapacitorJS 및 Electron 릴리스를 배포한 후 사용하는 워크플로우를 따릅니다: 사용자가 실행한 것을 정확히establish, 프로덕션 테스트 메트릭을 검사하기 전에 재현을 시도하기 전에, code 외의 원인 확인, 그리고 증상과 일치하는 가장 좁은 층을 디버그합니다. 7 가지 움직임은 사고 범위 설정, 층별 로그, 웹 및 네이티브 디버깅, 네트워킹 및 상태 검사, CI 경계석, 라이브 업데이트 복구 및 사고 후 검토가 예방 조치를 할당하는 것입니다.
목차
- 대시보드가 어둡게 된 밤
- 웹뷰, 네이티브 및 OS에서 로그를 읽기
- 웹 Layer와 Native Layer를 디버깅하는 방법
- 네트워크, 저장소 및 권한 첫 번째 확인
- 자동화된 테스트 및 CI를 조기 경보 시스템으로 사용
- 실시간 업데이트:緊急 복구 채널
- 사고 후 분석:다음 사고를 방지
Android 사용자가 화면이 어두운 대시보드를 보고 Electron 데스크톱 사용자는 정상적으로 작동했습니다.
목요일 저녁, Android 사용자가 화면이 어두운 대시보드를 보고 Electron 데스크톱 사용자는 정상적으로 작동했습니다. 첫 번째 가정은 Android 14 또는 WebView 회귀였습니다. 그 클루는 검색을 좁혔지만 실패를 식별하지 못했습니다. 영향을 받은 사용자도 릴리스 채널, 캐시된 구성 경로, API 환경, 및 특정 대시보드 요청 시퀀스를 공유했습니다.
온콜 엔지니어는 WebView 버전을 비교하기 시작했습니다. 결과가 가능성이 있었지만 아무런 결과도 얻지 못했습니다. 화면이 어두운 대시보드는 렌더링 예외, 빈 API 응답, 거부된 요청, 유효하지 않은 토큰, 기능 플래그 또는 세션 복원에 방해되는 저장소 읽기와 같은 여러 가지 원인으로부터 발생할 수 있습니다. code을 변경하기 전에 영향을 받은 사용자가 받은 바이너리, 웹 번들, 구성, 및 백엔드 경로를establish하십시오.
정확한 실패 표면을establish하십시오.
개발자 노트북이 아닌 프로덕션 테스트메트리와 시작하십시오. Google의 Android 충돌 및 ANR 지침은 이벤트를 기기, 운영 체제, 및 시간 창으로 좁히는 것을 권장합니다. ( Google의 Android 비트랄 트러블 슈팅 지침다음 필드를 하나의 영향을 받은 세션에서 캡처하십시오:빌드 식별자:)
원본 앱 버전, 빌드 ID, 웹 번들 해시, 및 릴리스 타임스탬프를 기록하십시오.
- __CAPGO_KEEP_0__ __CAPGO_KEEP_1__
- 배포 채널: 사용자가 카나리, 베타, 스테이지, 또는 안정 버전의 콘텐츠를 받았는지 확인합니다.
- 런타임 컨텍스트: 안드로이드 또는 iOS 버전, 기기 모델, 네트워크 유형, 권한 상태, 앱이 백그라운드에서 재개되었는지 여부를 기록합니다.
- 최근 성공적인 액션: 정확한 탭 시퀀스, 요청, 응답 상태, 그리고 표시된 결과를 보존합니다.
- 설정 스냅샷: API 기본 URL, 기능 플래그, 인증 설정, 플러그인 구성과 알려진 좋은 기기의 설정을 비교합니다.
Capacitor은 네이티브 버전과 WebView 내에서 실행되는 웹 콘텐츠를 분리합니다. 두 사용자는 설치된 바이너리를 공유할 수 있으며 다른 JavaScript 번들을 받을 수 있습니다. 또한 웹 번들을 공유할 수 있으며 네이티브 플러그인을 사용하는 다른 사용자도 있습니다. Electron은 릴리스 매니페스트, 메인 프로세스 버전, 렌더러 번들, 업데이트 채널에 대한 동일한 확인이 필요합니다. 렌더러 패키지 메타데이터만으로는 사용자가 실행한 것을 결정할 수 없습니다.
재현하기 변수 제거
식별자들을 수집한 후 사건을 분류합니다. 카나리 전용, 스테이지, 또는 완전히 배포된 것으로 분류합니다.A canary-only failure points to a specific bundle, flag, or channel assignment. A staged failure suggests audience or device-selection logic. A fully rolled-out failure raises the priority of shared configuration, backend behavior, and native compatibility.
Compare the affected device with a known-good one. Check native plugin versions, web hash, channel, API environment, authentication state, and permission grants. Replay the user’s last action sequence locally before reaching for an emulator. If one flag controls the failure, hold the other variables steady and bisect that flag’s behavior.
Practical rule: Do not call a reproduction “the same bug” until the build ID, channel, web bundle, operating system, and configuration match.
The Android dashboard incident turned on configuration correction. The team compared snapshots, confirmed that the native binary was valid, and verified that the WebView and dashboard code were unchanged. Production clients were requesting an environment with a staging credential because the earlier cache invalidation had not reached every mobile client. The recovery work therefore focused on correcting the configuration, setting appropriate cache invalidation headers, and verifying the CDN purge from affected regions and client paths.
그 시퀀스는 성공적인 정리 명령이 모든 사용자가 수정된 값을 가져올 수 있는지 증명하지 않기 때문에 중요합니다. CDN 응답, 캐시 나이, 패키지 또는 구성 해시, 그리고 새 클라이언트 세션을 확인하기 전에 복구를 선언하지 마십시오. 원본 빌드는 실패가 발생한 원인에 대한 변경이 없으면 롤아웃 시간을 추가로 추가했을 것입니다.
미래의 사고에 대해 동일한 discipline를 사용하십시오: 사용자의 artifact를 식별하고 실패 표면을 찾고 환경 차이를 제거하고 나서 code를 디버그하십시오.. 모바일 팀의 작성된 사고 대응 지침
사용자 체크를 포함하여 on-call runbook, 전송 지표, 롤아웃 소유권, 정리 확인, 그리고 원본 바이너리가 실패하는 구성 요소가 아닌 경우 live 업데이트 사용 여부를 결정하는 지침이 함께 있어야 합니다.
A CapacitorJS or Electron application produces evidence at several layers, and each layer answers a different question. The WebView can show JavaScript exceptions and failed requests, but it won’t explain every plugin failure. Native logs expose bridge and lifecycle behavior, while the operating system records memory pressure, permission denials, and process termination that application code may never observe.
로깅을 위한 3개의 층면을 보여주는 다이어그램: 웹뷰, 네이티브, 및 OS
증거에 해당하는 증상과 일치하십시오 웹뷰 층면console 오류, 미처리된 프로미스 거부, 네비게이션 이벤트, 요청 URL, 응답 상태, 요청 시간을 수집합니다. silent plugin 거부는 특히 위험합니다. UI는 이미 카메라, 파일 시스템, 보안 저장소, 알림 연산이 실패한 경우에도 렌더링을 계속할 수 있습니다.
The 자연어 layer native layer os_log contains Android logcat 출력, iOS
기록, 플러그인 브리지 예외, 활동 또는 뷰 컨트롤러 라이프 사이클 이벤트, 그리고 네이티브 크래시 트레이스. Electron은 메인 프로세스 로그 스트림, 자동 업데이트 이벤트, 창 생성 실패, IPC 메시지를 추가합니다. 렌더러 오류는 반드시 메인 프로세스에 나타나지 않으며, 메인 프로세스 크래시도 렌더러 콘솔 출력에 나타나지 않습니다. The OS layer
OS layer는 애플리케이션의 제어 밖의 이벤트를 설명합니다. 메모리 압박, 배경 종료, 배터리 제한, 거부된 권한, 프로세스 종료, 시스템 수준 크래시 보고서를 찾으십시오. 이 layer는 명백한 '랜덤 크래시'가 유용한 자바 스크립트 스택을 갖지 않는 경우를 설명합니다.
Correlate before you filter
모든层에서 동일한 context field를 저장하십시오: 앱 버전, 웹 번들 해시, 채널, 장치, OS, 세션, 그리고 기능 플래그 상태. 중앙 집중화된 수집은 사용자의 증거와 비교할 수 있는 재현 시도에 도움이 됩니다. 실제로 모바일 디버깅을 위한 로그 분석 도구 엔지니어에게 각 장치에서 스크린샷을 수집하도록 강요하지 않고도 그 필드를 검색하는 도구
웹 레이어와 네이티브 레이어 디버깅
증상이 있는 레이어를 디버깅하십시오. FREEZEN 화면이 여전히 네이티브 라이프 사이클 이벤트에 반응한다면 WebView에서 시작됩니다. 프로세스 종료, 플러그인 예외, 또는 시작 실패는 네이티브 도구 또는 Electron의 메인 프로세스에 속합니다. 레이어를 이동하는 규칙이 없으면 활동이 생기지만 원인에 대한 좁은 범위가 없습니다.
WebView부터 시작하십시오
안드로이드에서 Chrome에 연결 가능한 Capacitor 빌드를 연결하고 chrome://inspect콘솔, 네트워크 패널, 저장소, 그리고 성능 타임라인을 검사하십시오. iOS에서 Safari Web Inspector를 사용하여 연결된 장치 또는 시뮬레이터를 사용하십시오. Electron의 경우 렌더러에 대한 DevTools 포트에 연결하거나 BrowserWindow.webContents.openDevTools() 수사 중에 호출하십시오.
생산 스택 추적은 소스에 매핑되면 유용합니다. 웹 번들을 위해 소스 맵을 업로드하고 유지하고 정확한 번들 해시와 기호화된 항목이 일치하는지 확인하세요. 중요한 작업에 대해 제어된 콘솔 인터셉터를 추가하세요. 그러나 로그인 자격증명, 토큰 또는 개인 데이터를 피하세요. 작업 이름, 요청 ID, 응답 클래스 및 상태 전환을 캡처하세요.
네이티브 도구로 이동할 때 증거가 지시합니다.
Android Studio Logcat에서 애플리케이션 패키지를 필터링하고 가장 작은 가능한 액션 시퀀스와 함께 재현하세요. npx cap run android --livereload 웹뷰 변경의 반복 루프를 단축하지만, 패키지된 네이티브 항목을 검증하지 않습니다. iOS에서 Xcode에서 실행하고 디바이스 로그를 위해 디바이스 창을 사용하세요. Instruments의 Time Profiler는 지속적인 CPU 작업에 도움이 되며, Allocations는 메모리 성장에 도움이 됩니다.
Electron에는 두 가지 디버깅 대상이 있습니다. 렌더러 DevTools를 사용하여 DOM, JavaScript 및 네트워크 동작을 확인하세요. 사용자 인터페이스 요소의 경우 --inspect 또는 --inspect-brk 메인 프로세스에 대해 사용하고 시작 및 자동 업데이트 테스트 중에 스타더드 에러 출력을 보존하세요.
증상에 따라 라우팅하세요. UI 동작은 WebView에서 시작되며 Android Studio 또는 Xcode에서 네이티브 종료가 시작됩니다. Electron 시작 오류는 메인 프로세스에서 시작됩니다.
이 분할이 중요한 이유에 대한 유용한 설명은 Capacitor의 WebView 및 네이티브 브리지 모델 . 연결은 경계이며 단일 디버깅 표면이 아닌 것입니다. 그 방식으로 처리하면 각 로그 라인이 질문에 더 좋은 답변을 할 가능성이 있습니다.
네트워크, 저장소 및 권한
팀은 네트워크 오류가 기술적이고 익숙해 보이기 때문에 API를 먼저 확인하는 경향이 있습니다. 그러나 이러한 습관은 상태가 오래되어 있는 경우, 권한 선언이 변경된 경우 또는 플랫폼 업그레이드가 샌드박스 동작을 변경한 경우에 실패를 유발하는 오류를 놓치게 됩니다. 가장 빠른 확인은 실패 도메인에 따라 달라집니다.
| 실패 도메인 | 일반 증상 패턴 | 가장 빠른 확인 |
|---|---|---|
| 네트워크 | 비어 있는 데이터, 로그인 루프, 타임아웃, 업로드 실패, 또는 하나의 네트워크에서 작동하는 요청이 다른 네트워크에서 작동하지 않는 경우 | 실행 curl 같은 네트워크에서 실행하고 실패한 WebView 요청을 검사하고 CORS 프리 플라이트, 인증서 핑징, 캡티브 게이트웨이, 프록시 동작을 확인하십시오. |
| 저장소 | 컨텍스트: Capgo Builder / 네이티브 클라우드 빌드 제품 페이지. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 보이는 곳: native-build.astro 페이지. 메시지 키 `native_build_v2_trust_stor_lbl` (네이티브 빌드 V2 트러스트 스토어 레이블). | 제품/가격 페이지. 역할: 짧은 UI 레이블 또는 네비게이션 아이템. 보이는 곳: enterprise.astro 페이지. 메시지 키 `enterprise_plugins_legacy_storage` (엔터프라이즈 플러그인 레거시 저장소). | 저장소 예상 크기 검사, IndexedDB 할당량 오류 확인, 암호화 키 비교, Electron의 userData 경로를 확인하고 깨끗한 샌드박스 테스트 |
| 권한 | 카메라, 파일, 알림, 위치, 또는 백그라운드 동작이 명확한 애플리케이션 예외 없이 실패하는 경우 | iOS 사용 설명서를 확인하고 Android ACCESS_* 선언, Electron의 권한 처리기, 그리고 холод 시작 권한 타이밍 |
저장소 문제에 대해 storage.estimate() 할당량 압박을 드러낼 수 있지만 모든 데이터베이스 문제를 진단하지는 못합니다. 수동으로 청소된 애플리케이션 샌드박스를 테스트하고 기존 프로필과 동작을 비교합니다. Capacitor userData Preferences 암호화 키 회전은 이전에 유효한 값이 읽을 수 없게 만들 수 있으며 SQLite 쓰기 앞서 로깅은 갑작스러운 종료 후 손상된 상태를 남길 수 있습니다. Electron 애플리케이션은 또한 운영 체제 업그레이드가 해결된 경로를 변경할 때 데이터를 잃어버릴 수 있습니다.
권한도 같은 관심을 받을 가치가 있습니다. iOS 사용 설명서가 요청 중인 기능과 일치해야 합니다. Android 권한 동작은 변경 후 SDK이 드리프트할 수 있으며 알림 프롬프트는 холод 시작 초기화와 경쟁할 수 있습니다. Electron의 권한 처리기는 렌더러가 유용한 설명을 받기 전에 요청을 거부할 수 있습니다.
사용자가 "어제는 작동했다"고 말하는 경우 저장소와 권한을 검사하기 전에 네트워크가 변경된 것으로 가정하지 마십시오.
자동화된 테스트 및 CI를 조기 경보 시스템으로 사용하십시오
CI는 사용자가 실행할 artifact를 테스트할 때 regressions를 가장 저렴하게 잡을 수 있습니다. 개발 서버에 대한 녹색 테스트 스위트는 signed Android package, iOS archive, 또는 Electron installer가 시작, bundle을 로드하고, 실제 인증된 작업을 완료할 수 있는지 증명하지 않습니다.
공유 논리와 셸을 테스트하세요
사용하세요 공유 웹 논리를 위해 Vitest Electron main-process 동작을 위해 for Electron main-process behavior. For Capacitor plugins, test the JavaScript contract and the native implementation separately, then add integration coverage for permission denial, unavailable hardware, malformed responses, and lifecycle interruption.
__CAPGO_KEEP_0__ 플러그인에 대해 JavaScript 계약과 네이티브 Implementation을 별도로 테스트하고, 권한 거부, unavailable hardware, malformed responses, lifecycle interruption에 대한 통합 커버리지를 추가하세요.
Playwright는 빌드 웹 번들을 실행할 수 있습니다. Electron의 경우, packaged binary에 대한 Playwright Electron 또는 동등한 셸 테스트를 사용하세요. 로컬 개발 프로세스가 제공하는 렌더러만 테스트하는 것보다. 패키지 테스트는 미스팅 asset, 잘못된 경로, 서명 오류, 시작 가정 중 일부를 감춰버리는 브라우저 테스트를 잡을 수 있습니다.
디바이스 커버지는 실제 설치 기반을 반영해야 합니다. BrowserStack 또는 Sauce Labs는 의도적으로 선택한 디바이스 프로파일, 운영 체제, 권한 상태, 네트워크 조건을 사용하여 디바이스 커버지를 실행할 수 있습니다. 목표는 최대 행렬 크기입니다. 대표적인 실패 커버리지입니다.
실패가 병목 현상이 되도록 하세요
- 명시적인 체크를 추가하세요: 예기치 않은 번들 크기 델타와 소스 맵 누락을 거부합니다.
- 자연적인 정렬: 플러그인 버전이동 및 불일치하는 설정을 감지합니다.
minSdkVersion아티팩트完整성: - 서명, 패키지 식별, 임베디드 자산 및 릴리즈 매니페스트를 검증합니다. 시작 동작:
- 패키지된 앱을 부팅하고 인증된 엔드포인트 요청을 완료합니다. 업데이트 동작:
- 이전 버전의 번들을 설치하고 후보 업데이트 적용, 재시작, 롤백 동작 확인합니다. 모든 결과를 하나의 __CAPGO_KEEP_0__ 상태 체크를 통해 빨간 신호로 머지를 막습니다. 단위 테스트를 통과한 빌드지만 서명된 아티팩트 검증에 실패한 빌드는 실패로 처리되어야 합니다. "대부분 초록"이 아닌.
Publish every result through one GitHub status check so a red signal blocks the merge. A build that passes unit tests but fails signed-artifact verification should be treated as failed, not “mostly green.”
The Capacitor 릴리스에 대한 Capacitor 지속 통합 설정 CI를 반복 가능한 pipeline에 통합하는 데 유용합니다. CI는 프로덕션 모니터링의 대체가 아니지만, 스테이징에 도달하는 결함의 수를 줄여서 인시던트 중에 온콜 엔지니어에게 알려지지 않은 항목이 적어집니다.
실시간 업데이트: 비상 복구 채널
프로덕션 버그가 항상 새로운 네이티브 빌드를 요구하는 것은 아닙니다. JavaScript, CSS, 복사본, 구성, 또는 다른 웹 자산에 결함이 존재하는 경우, 실시간 업데이트 사용자는 사용자 경험을 복원할 수 있습니다. 팀은 적절한 릴리스를 준비하는 동안. 실시간 업데이트 배포는 단순히 외관 변경을 위한 편의 기능이 아닌, 운영 복구 채널입니다.안전성 요구 사항은 제어입니다. 카나리, 베타, 그리고 안정적인 사용자들을 위한 별도의 이름이 지정된 채널을 유지하고, 네이티브 앱 ID와 호환 가능한 런타임 제약 조건을 명확히하고, 각 사용자에게 받은 번들을 기록하세요. 실시간 업데이트에서는 네이티브 권한 추가, 네이티브 플러그인 교체, 이레クト론 메인 프로세스 변경, 또는 업데이터 초기화 전에 발생하는 실패를 修復할 수 없습니다. 이 경우는 여전히 스토어 또는 설치 프로그램 릴리스가 필요합니다.
애플리케이션 프로덕션 버그에 대한 실시간 업데이트 사용하는 비상 복구 프로세스 다이어그램
비상 흐름은 다음과 같이 나타나야 합니다:
범위 확인:
- 영향을 받는 네이티브 버전, 채널, 번들 해시, 그리고 실패 신호를 식별하세요. __CAPGO_KEEP_0__
- 작업을 위한 가장 작은 패치 준비: 실패하는 경로를 복원하기 위해 필요한 웹 동작만 변경하십시오.
- 대상자 선정: 실패하는 경로를 복원하기 위해 필요한 웹 동작만 변경하십시오.
- 추적: 실패하는 계열에 대한 충돌, 로드, 요청, 업데이트 실패 신호를 확인하십시오.
- 업데이트 또는 롤백: 신호가 건강한 경우에만 확장하십시오. 패치가 새로운 실패를 유발하는 경우에는 즉시 롤백하십시오.
자동 롤백은 팀이 선택한 실패율 또는 로드 실패 임계값을 사용해야 합니다. 롤백은 업데이터가 실패를 감지하고 이전 버전이 사용 가능한 경우에만 사용자 보호를 제공합니다. 버전 기록과 채널 보호대책은 지원 팀이 특정 장치에 무슨 일이 일어났는지 설명할 수 있도록 유지해야 합니다.
Capgo은 CapacitorJS 및 Electron 애플리케이션에 대한 서명된 웹-배ंडल 전송, 대상 채널, 장치별 로그, 채택 및 실패 메트릭, 버전 기록 및 자동 롤백 보호를 제공합니다. 실질적인 결정 규칙은 다음과 같습니다: fix가 웹 배ंडल에 국한되어 업데이터가 안전하게 시작할 수 있는 경우에는 실시간 업데이트 사용하고, 런타임, 플러그인, 권한, 패키지 또는 메인 프로세스가 관련된 경우에는 네이티브 핫픽스를 예약하십시오.. Capacitor live-update flow __CAPGO_KEEP_0__ live-update flow
사고 후 분석
사고 후 분석은 시스템을 바꾸면 그 자리에서 자리한다. 기록을 남기기 위해 로그, 배포 환경, 운영자 결정이 남아 있는 동안 기록을 남겨라. 기록은 사실에 근거하고 비난하지 말고, 다른 엔지니어가 전체 사고를 재구성하지 않고 누락된 경계를 식별할 수 있도록 충분히 구체적이어야 한다.
5개의 구체적인 블록
시간대별로 시간대별로 기록하는 시각화 첫 번째 실패한 요청, 영향을 받은 릴리즈, 경보 생성, 조사 단계, 조치, 복구를 기록한다. Android 대시보드 사고의 경우, 시각화는 iOS가 유효한 응답을 받으면서도 빈 뷰가 나타난 후 구성 요소 롤아웃이 발생했다는 것을 보여줄 수 있다.
사용자에게 보이는 실패 모드 고객이 경험한 것을 설명하라, code가 무엇을 했는지 설명하지 말라. "Android 사용자는 인증 후 빈 대시보드를 보았다"는 설명은 "API 키 불일치"보다 더 많은 지시를 제공한다. 첫 번째 설명은 깨진 여행과 신호를 감지해야 하는 곳을 지시한다.
감지 불일치 팀이 늦게 배웠던 이유를 설명하라. 앱이 성공적으로 렌더링되었기 때문에 크래시 모니터링이 녹색을 유지했을 수 있고, 인증된 요청 실패나 빈 대시보드 페이로드를 추적하는 경보가 없을 수 있다. 누락된 신호와 신호가 어디에서 발생해야 하는지 기록하라.
비 code 요인 생산 중단, 캐시 동작, 배포 시간, 서비스 의존성, 권한 변경, 또는 Electron 자동 업데이트 경쟁을 목록화합니다. 이러한 도메인은 애플리케이션 code의 결함이 없이는 생산 중단이 발생할 수 있기 때문에 초기 검사를 deserving합니다.
예방적 경계. 문제를 잡아내는 테스트 또는 제어를 assign합니다. 예를 들어, 배포 중에 프로덕션 자격증명을 유효성 검사하거나 대표적인 클라이언트에서 전달된 구성 확인, 또는 패키지된 Electron 시작 테스트를 추가하는 것과 같은 것들입니다. 경계는 주로 회고록에 있는 문장만으로는 충분하지 않습니다. 경계는 주인과 실패 조건이 필요합니다.
通知 경로는 동일한 검토에 속합니다. 팀에 메일 알림이 도달하지 못한다면 Gmail에서 이메일이 스팸으로 간다는 방법에 대한 실용적인 리소스를 사용합니다. 메일 알림이 도달하지 못하는 경우, 알림 경로를 확인합니다. 알림 경로가 성공적으로 생성되었다는 것은 운영자에게 알림이 도달했다는 것을 증명하지 않습니다. 작업 assign하기 전에 incident를 닫지 마세요.
각 블록에 대해, 이름을 하나, due date를 하나, 그리고 verification method를 하나 assign하세요. incident를 다시 검토하세요.
24시간 내에 incident를 다시 검토하세요. context: HTML text fragment from a longer Capgo UI string (parent key `low_priority_response`). Page/area: Capgo marketing website. Role: Website copy sentence. Seen in: page sla.astro. Message key `low_priority_response` (Low Priority Response). | HTML text fragment from a longer Capgo UI string (parent key `urgent_team_response`). Page/area: Capgo marketing website. Role: Website copy sentence. Seen in: page sla.astro. Message key `urgent_team_response` (Urgent Team Response).engineers가 조사에서 가정에 대한 도전을 계속할 수 있도록 하세요. 새로운 테스트, 대시보드, 구성 확인, 또는 롤아웃 규칙이 성공적으로 실행되기 전까지 item을 닫지 마세요.
이 마지막 체크리스트를 사용하세요.
- native build와 web bundle의 정확한 것을 indentified했나요?
- 우리는 code , 설정 , 배포 , 인프라 및 의존성 원인과 구별했습니까?
- 사용자 눈에 띄는 오류는 단지 충돌뿐만 아니라 테스트웨어가 보여주었습니까?
- 우리는 영향을 받은 채널과 알려진 좋은 채널을 테스트했습니까?
- 우리는 프로덕션 이전에 실패하는 가드레일을 추가했습니까?
- 우리는 실시간 업데이트 또는 네이티브 릴리스가 적합한지 문서화했습니까?
- 한 명의 소유자가 수정을 확인했습니까?
사용자 불만은 리뷰가 단지 충돌을 다루는 것 이상이어야 한다는 것을 보여줍니다. 6,634 앱 감사에서 결제 오류가 28.6% 장치 호환성 28.4%UI 및 UX 마찰 25.4%구독 문제 21.8%, 로그인 오류 17.2%, 충돌이 7위에 랭크된 10.3%. (모바일 앱 불만을 조사한 Bright App Data) 앱이 충돌하는 이유만 물어보는 트러블 슈팅 프로세스는 결제, 로그인, 제품 사용이 정상적으로 이루어지지 않는 실패를 놓치게 된다.
안정성 데이터는 동일한 운영 모델을 지지한다. 벤치마크는 중간 앱이 99.95% 충돌이 없는 세션, 최적화된 앱이 99.99% , 약화된 앱이 99.77% 이하의 . 또한 ANR 발생률의 중간값은 10,000 세션당 , 이는 OOM 세션당 1.12, 그리고 앱 hang 비율 10,000 세션당 64에서 103 품질 등급에 따라 달라집니다. (모바일 안정성 벤치마크) 안정성이 높아도 의미 있는 실패가 남아 있습니다. 팀은 실패한 요청, 빈 상태, hang, 업데이트 오류 및 사용자에게 나타나는 다른 증상에 대한 테스트 데이터가 필요합니다.
2026년 보고서에 따르면 사용자는 기본적인 기능이 깨진 것에 대해 신규 기능에 대한 요청보다 보고서에 따르면 . (단일 충돌 후 15.4%의 사용자가 2-3 번의 충돌 후 반 이상의 사용자가 εγκα하셨습니다.
사용 Capgo Capgo로 PR 제출
