목요일 저녁, Android 14 사용자를 위한 CapacitorJS 쇼핑 앱이 비어 있는 대시보드를 표시하기 시작했습니다. iOS 고객은 정상적으로 브라우징을 했습니다. Electron 데스크톱 사용자는 아무런 문제를 보고하지 않았습니다. 온콜 엔지니어는 WebView 회귀를 가정하고 Android Studio를 열어, 장치 간 렌더링 동작을 비교하기 위해 몇 시간을 보냈습니다. 최종 원인은 렌더링 버그가 아니었습니다. 스테이징 API 키가 캐시 무효화가 실패하여 모바일 클라이언트에 도달하지 못했기 때문입니다.
이 사고는 익숙한 이유입니다. 모바일 실패는 일반적으로 저장소의 경계를 무시합니다. 새로운 자바스크립트 변경이 무죄일 수 있지만 배포, 구성 값, 권한 상태, 서비스 종속성 또는 네트워크 경로가 사용자 경험을 깨트릴 수 있습니다. 마이크로소프트의 사고 분석 결과 생산 중단 사고의 40%는 code 또는 구성 오류에서 발생했으며, 60%는 인프라, 배포 및 서비스 의존성에서 발생했다.실용적인 교훈은 간단하다: 앱 문제 해결은 스택 추적에 시작하지 않고 전체 실패 도메인에서 시작해야 한다.. (Microsoft의 사고 분석)
이 플레이북은 CapacitorJS 및 Electron 릴리스를 배포한 후 사용하는 워크플로우를 따릅니다: 사용자가 실행한 정확한 것을establish, 프로덕션 테마 트리미터를 검사하기 전에 재현을 시도하기 전에, code 외의 원인 확인, 그리고 증상과 일치하는 가장 좁은 층을 디버그합니다. 7 가지 움직임은 사고 범위 설정, 층별 로그, 웹 및 네이티브 디버깅, 네트워킹 및 상태 검사, CI 경계석, 라이브 업데이트 복구 및 사고 후 검토가 예방 작업 assign입니다.
목차
- The Night the Dashboard Went Dark
- 웹뷰, 네이티브 및 OS에서 로그를 읽기
- 웹 Layer와 Native Layer를 디버깅하는 방법
- 네트워크, 저장소 및 권한을 먼저 확인하세요
- 자동화된 테스트 및 CI를 조기 경보 시스템으로 사용하세요
- 실시간 업데이트:緊急 복구 채널로 사용하세요
- 사고 후 분석:다음 사고를 예방하세요
다시 시작된 대시보드
목요일 저녁까지 안드로이드 사용자는 빈 대시보드를 보고 있었고, 전자 데스크톱 사용자는 정상적으로 작동하고 있었다. 첫 번째 가정은 안드로이드 14 또는 WebView의 회귀였다. 그 단서가 검색 범위를 좁혔지만, 실패를 식별하지는 못했다. 영향을 받은 사용자들은 또한 릴리스 채널, 캐시된 구성 경로, API 환경, 그리고 특정 대시보드 요청 시퀀스를 공유했다.
온콜 엔지니어는 WebView 버전을 비교하기 시작했다. 결과가 합리적이고도 아무런 결과도 내지 못했다. 빈 대시보드는 렌더링 예외, 빈 API 응답, 거부된 요청, 유효하지 않은 토큰, 기능 플래그, 또는 세션 복원에 방해되는 저장소 읽기와 같은 여러 가지 원인으로부터 발생할 수 있다. code을 변경하기 전에, 영향을 받은 사용자가 받은 바이너리, 웹 번들, 구성, 그리고 백엔드 경로를establish해야 한다.
정확한 실패 표면을establish
생산 환경의 전송에서 시작하라. 개발자 노트북이 아닌. Google의 안드로이드 충돌 및 ANR 지침은 이벤트를 기기, 운영 체제, 그리고 시간 창으로 좁히는 것을 권장한다.실패 위치가 불분명한 경우 로그캣을 사용하는 동안 재현을 하라.Google의 안드로이드 비트랄 트러블 슈팅 지침)
다음 필드를 하나의 영향을 받은 세션에서 캡처하라:
- 빌드 식별자: 자연어 앱 버전, 빌드 ID, 웹 번들 해시, 그리고 릴리스 타임스탬프를 기록하라.
- 배포 채널: 사용자가 카나리, 베타, 스테이징, 또는 안정적인 콘텐츠를 받았는지 확인합니다.
- 런타임 컨텍스트: 안드로이드 또는 iOS 버전, 기기 모델, 네트워크 유형, 권한 상태, 앱이 백그라운드에서 재개되는지 여부를 기록합니다.
- 최근 성공적인 액션: 정확한 탭 시퀀스, 요청, 응답 상태, 그리고 표시된 결과를 보존합니다.
- 구성 스냅샷: API 기본 URL, 기능 플래그, 인증 설정, 플러그인 구성과 알려진 좋은 기기의 구성과 비교합니다.
Capacitor은 네이티브 버전과 WebView 내에서 실행되는 웹 콘텐츠를 분리합니다. 두 사용자는 설치된 바이너리를 공유할 수 있으며 서로 다른 JavaScript 번들을 받을 수 있습니다. 또한 웹 번들을 공유할 수 있으며 네이티브 플러그인을 서로 다르게 사용할 수 있습니다. Electron은 릴리스 매니페스트, 메인 프로세스 버전, 렌더러 번들, 업데이트 채널에 대한 동일한 확인이 필요합니다. 렌더러 패키지 메타데이터만으로는 사용자가 실행한 것을establish할 수 없습니다.
재현하기 변수 제거:
식별자들을 수집한 후 사건을 분류합니다. 카나리 전용, 스테이징, 또는 완전히 배포된 것으로 분류합니다.Canary 배포에서 오류가 발생하면 특정 패키지, 플래그, 또는 채널 할당에 문제가 있는지 확인합니다. 준비된 배포에서 오류가 발생하면 사용자 또는 장치 선택 논리와 관련이 있습니다. 전체 배포에서 오류가 발생하면 공유 구성, 백엔드 동작 및 네이티브 호환성의 우선순위를 높입니다.
영향을 받은 장치와 알려진 좋은 장치 간의 차이를 확인합니다. 네이티브 플러그인 버전, 웹 해시, 채널, API 환경, 인증 상태 및 권한 부여를 확인합니다. 사용자의 마지막 액션 시퀀스를 로컬에서 재생하기 전에 에뮬레이터를 찾기 전에. 만약 하나의 플래그가 오류를 제어한다면 다른 변수를 안정적으로 유지하고 플래그의 동작을 이분법적으로 확인합니다.
실용적인 규칙: 재현을 '같은 버그'라고 부르지 마세요. 빌드 ID, 채널, 웹 패키지, 운영 체제 및 구성이 일치할 때까지.
Android 대시보드 사고는 구성 수정을 활성화했습니다. 팀은 스냅샷을 비교하고 네이티브 바이너리가 유효한지 확인하고 WebView 및 대시보드 code가 변경되지 않았는지 확인했습니다. 생산 클라이언트는 이전 캐시 무효화가 모든 모바일 클라이언트에 도달하지 않았기 때문에 스테이징 인증을 요청하는 환경을 요청했습니다. 따라서 복구 작업은 구성 수정, 적절한 캐시 무효화 헤더 설정 및 영향을 받은 지역 및 클라이언트 경로에서 CDN 정리 작업을 확인했습니다.
그 순서가 중요하다. 성공적인 정리 명령이 모든 사용자가 수정된 값을 가져올 수 있는지 증명하지는 않는다. CDN 응답, 캐시 나이, 패키지 또는 구성 해시, 그리고 새로운 클라이언트 세션을 확인하기 전에 복구를 선언하지 마라. 네이티브 재구축은 실패한 원인에 영향을 미치지 않고 롤아웃 시간을 추가했을 것이다.
미래의 사건에 대해 동일한 discipline를 사용하라: 사용자의 artifact를 식별하고, 실패하는 표면을 찾고, 환경적 차이를 제거하고, 그리고 다음으로 디버그 code. 모바일 팀의 작성된 사고 대응 지침
사고 대응 지침은 호출 중인 runbook에 alongside에 유지해야 하는 확인을 포함해야 한다. 이에는 텔레메트리 쿼리, 롤아웃 소유권, 정리 확인, 그리고 네이티브 바이너리가 실패하는 구성 요소가 아닌 경우 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 오류, 미처리된 promise 거부, 네비게이션 이벤트, 요청 URL, 응답 상태, 요청 시간을 수집합니다. silent plugin 거부는 특히 위험합니다. UI는 이미 카메라, 파일 시스템, 보안 저장소 또는 알림 연산이 실패한 경우에도 렌더링을 계속할 수 있습니다.
The 자연어 layer contains Android logcat 출력, iOS os_log 기록, 플러그인 브리지 예외, 활동 또는 뷰 컨트롤러 라이프 사이클 이벤트 및 네이티브 크래시 트레이스. Electron은 메인 프로세스 로그 스트림, 자동 업데이트 이벤트, 창 생성 실패 및 IPC 메시지를 추가합니다. 렌더러 오류는 반드시 메인 프로세스에 나타나지 않으며 메인 프로세스 크래시도 렌더러 콘솔 출력에 나타나지 않습니다.
The OS layer 외부 애플리케이션의 제어 밖의 이벤트를 설명합니다. 메모리 압박, 배경 종료, 배터리 제한, 거부된 권한, 프로세스 종료 및 시스템 수준 크래시 보고서를 찾으십시오. 이 layer는 apparent 'random crash'가 유용한 자바 스크립트 스택이 없는 경우가 많습니다.
Correlate before you filter
웹뷰, 네이티브 브리지, 백엔드 및 중앙 로그 싱크에서 공유된 요청 또는 연산 ID를 사용하십시오. 사용자 액션 시작 전에 ID를 추가하고 네트워크 요청과 네이티브 콜백을 통해 보존하십시오. 일관된 형식의 타임스탬프를 상관하고 장치 시계 드리프트를 고려하고 프레임워크 노이즈를 필터링하기 전에 원래 이벤트를 보존하십시오.
모든层에서 동일한 context field를 저장하십시오: 앱 버전, 웹 번들 해시, 채널, 장치, OS, 세션, 그리고 기능 플래그 상태. 중앙 집중화된 수집은 사용자의 증거와 비교할 수 있는 재현 시도에 도움이 됩니다. 대안으로 가정치 않도록. 모바일 디버깅을 위한 실용적인 로그 분석 도구 로그 분석 도구는 엔지니어를 각 장치에서 스크린샷을 수집하도록 강요하지 않고도 그 필드를 검색하는 데 도움이 됩니다.
웹 레이어와 네이티브 레이어 디버깅
증상이 있는 레이어를 디버깅하십시오. FREEZEN 화면이 여전히 네이티브 라이프 사이클 이벤트에 반응한다면 WebView에서 시작됩니다. 프로세스 종료, 플러그인 예외, 또는 시작 실패는 네이티브 도구 또는 Electron 메인 프로세스에서 속합니다. 레이어를 이동하는 규칙이 없으면 활동이 발생하지만 원인에 대한 좁은 범위가 없습니다.
WebView부터 시작하십시오
안드로이드에서 Chrome에 디버깅 가능한 Capacitor 빌드를 연결하고 chrome://inspect콘솔, 네트워크 패널, 저장소, 그리고 성능 타임라인을 검사하십시오. iOS에서 Safari Web Inspector를 사용하여 연결된 장치 또는 시뮬레이터를 사용하십시오. Electron의 경우 렌더러에 대한 DevTools 포트에 연결하거나 BrowserWindow.webContents.openDevTools() 수사 중에 호출하십시오.
생산 스택 추적은 소스에 대한 매핑이 되면 유용합니다. 웹 번들을 위해 소스 맵을 업로드하고 유지하고, 정확한 번들 해시와 매칭되는 symbolication artifact를 확인하세요. 중요한 작업에 대해 제어된 콘솔 인터셉터를 추가하세요. 그러나 로그인 자격증명, 토큰, 또는 개인 데이터를 피하세요. 작업 이름, 요청 ID, 응답 클래스, 및 상태 전환을 캡처하세요.
네이티브 도구로 이동하세요. 증거가 네이티브 쪽을指向하면
Android Studio Logcat에서 애플리케이션 패키지를 필터링하고, 가장 작은 가능성의 액션 시퀀스와 함께 재현하세요. npx cap run android --livereload 웹뷰 변경의 반복 루프를 단축하지만, 패키지된 네이티브 아티팩트를 검증하지 않습니다. iOS에서 Xcode에서 실행하고, 디바이스 로그를 위해 Devices 창을 사용하세요. Instruments의 Time Profiler는 지속적인 CPU 작업에 도움이 되며, Allocations는 메모리 성장에 도움이 됩니다.
Electron에는 두 가지 디버깅 대상이 있습니다. 렌더러 DevTools를 사용하여 DOM, JavaScript, 및 네트워크 동작을 캡처하세요. 사용자 인터페이스 동작을 캡처하려면 --inspect 또는 --inspect-brk Capacitor live-update alternatives comparison page에서 사용되는 HTML 텍스트 프래그먼트.
메인 프로세스에 대해 사용하고, 시작 및 자동 업데이트 테스트 중에 stderr 출력을 보존하세요.
증상에 따라 라우팅하세요. UI 동작은 WebView에서 시작되며, 네이티브 종료는 Android Studio 또는 Xcode에서 시작됩니다. Electron 시작 실패는 메인 프로세스에서 시작됩니다. 디버깅 프로세스에 대한 유용한 설명이 나타납니다. Capacitor의 WebView 및 네이티브 브리지 모델에서. . 브릿지는 한 개의 디버깅 표면이 아닌 경계입니다. 그 방식으로 행동하면, 각 로그 라인은 질문에 더 좋은 대답을 할 가능성이 있습니다.
네트워크, 저장소 및 권한
팀은 네트워크 오류가 기술적이고 익숙해 보이기 때문에 API를 먼저 확인하는 경향이 있습니다. 그러나 이러한 습관은 상태가 오래되어 있는 것, 권한 선언이 변경된 것, 또는 플랫폼 업그레이드가 샌드박스 동작을 변경한 것에 의해 발생하는 실패를 놓치게 됩니다. 가장 빠른 확인은 실패 도메인에 따라 달라집니다.
| 실패 도메인 | 일반 증상 패턴 | 가장 빠른 확인 |
|---|---|---|
| 네트워크 | 다른 네트워크에서 요청이 작동하는 경우에도 업로드가 실패하거나 로그인 루프, 타임아웃, 또는 빈 데이터가 발생하는 경우 | Run curl 같은 네트워크에서 실행하고 실패한 WebView 요청을 검사하고 CORS 프리 플라이트, 인증서 핀닝, 캡티브 게이트웨이, 프록시 동작을 확인합니다. |
| 저장소 | 업데이트, 재시작, 또는 운영 체제 변경 후 이전에 작동하던 기능이 실패하는 경우 | 저장소 추정치를 검사하고 IndexedDB 할당량 오류를 확인하고 암호화 키를 비교하고 Electron의 userData 경로를 확인하고 깨끗한 샌드박스를 테스트하십시오 |
| 권한 | 카메라, 파일, 알림, 위치, 또는 백그라운드 동작이 명확한 애플리케이션 예외 없이 실패하는 경우 | iOS 사용 설명서를 확인하고 Android ACCESS_* 선언, Electron의 권한 처리기, 그리고 차갑게 시작된 권한 타이밍 |
저장소 문제에 대해 storage.estimate() 할당량 압력을 드러낼 수 있지만 모든 데이터베이스 문제를 진단하지는 않습니다. 수동으로 정리된 애플리케이션 샌드박스를 테스트한 후 기존 프로필과 동작을 비교하십시오. Capacitor userData Preferences 암호화 키 회전은 이전에 유효한 값이 읽을 수 없게 만들 수 있으며 SQLite 쓰기 앞서 로깅은 갑작스러운 종료 후에 손상된 상태를 남길 수 있습니다. Electron 애플리케이션은 또한 운영 체제 업그레이드가 해결된 경로를 변경할 때 데이터를 잃어버릴 수 있습니다.
권한도 같은 관심을 받을 가치가 있습니다. iOS 사용 설명서는 요청 중인 기능과 일치해야 합니다. Android 권한 동작은 변경 후에 SDK drift할 수 있으며 알림 프롬프트는 차갑게 시작된 초기화와 경쟁할 수 있습니다. Electron의 권한 처리기는 렌더러가 유용한 설명을 받기 전에 요청을 거부할 수 있습니다.
사용자가 "어제는 작동했다"고 말하는 경우 저장소와 권한을 검사하고 네트워크가 변경된 것으로 가정하지 마십시오.
자동화된 테스트 및 CI를 조기 경보 시스템으로 사용하십시오
CI는 사용자가 실행할 artifact를 테스트할 때 regressions를 가장 저렴하게 잡을 수 있습니다. 개발 서버에 대한 녹색 테스트 스위트는 signed Android package, iOS archive, 또는 Electron installer가 시작, bundle을 로드하고 실제 인증된 작업을 완료할 수 있는지 증명하지 않습니다.
공유 논리와 셸을 테스트하세요
사용하세요 Vitest 공유 웹 논리와 Jest 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.
For __CAPGO_KEEP_0__ 플러그인, JavaScript 계약과 native implementation을 별도로 테스트하고, 권한 거부, unavailable hardware, malformed responses, lifecycle interruption에 대한 통합 커버리지를 추가하세요.
Playwright는 빌드 웹 번들을 실행할 수 있습니다. Electron의 경우, packaged binary에 대한 Playwright Electron 또는 등価 셸 테스트를 사용하고, 로컬 개발 프로세스가 제공하는 렌더러만 테스트하지 마세요. 패키지 테스트는 미스된 asset, 잘못된 경로, 서명 오류, 브라우저 테스트가 숨기는 시작 가정과 같은 문제를 잡을 수 있습니다.
디바이스 커버지는 실제 설치 기반을 반영해야 합니다. BrowserStack 또는 Sauce Labs는 의도적으로 선택한 디바이스 프로파일, 운영 체제, 권한 상태, 네트워크 조건을 사용하여 디바이스 커버지를 구현하세요. 목표는 최대 행렬 크기가 아닙니다. 대표적인 실패 커버리지입니다.
실패가 병목이 되도록 하세요
- 명시적인 체크를 추가하세요: 예상치 못한 번들 크기 변동과 소스 맵 누락을 거부합니다.
- 자연스러운 정렬: 플러그인 버전이동과 불일치하는
minSdkVersion설정들을 감지합니다. - 아티팩트完整성: 서명, 패키지 식별, 임베디드 자산 및 릴리스 매니페스트를 검증합니다.
- 시작 동작: 패키지된 앱을 부팅하고 인증된 엔드포인트 요청을 완료합니다.
- 업데이트 동작: 이전 버전의 번들을 설치하고 후보 업데이트 적용, 재시작, 롤백 동작 확인을 수행합니다.
결과를 하나의 GitHub 상태 체크를 통해 모두 공개합니다. 단, 실패한 빌드는 단순히 "주로 초록"이 아닌 "실패"로 처리되어야 합니다.
The Capacitor 릴리스에 대한 Capacitor 연속 통합 설정 CI를 반복 가능한 pipeline에 통합하는 데 유용합니다. CI는 프로덕션 모니터링의 대체품이 아니지만, 스테이징에 도달하는 결함의 수를 줄여서 인시던트 중에 온콜 엔지니어에게 알려지지 않은 항목이 적어집니다.
실시간 업데이트: 비상 복구 채널
프로덕션 회귀가 항상 새로운 네이티브 빌드를 필요로 하는 것은 아닙니다. JavaScript, CSS, 복사본, 구성, 또는 다른 웹 자산에 결함이 존재하는 경우, 실시간 업데이트에서는 사용자 경험을 복원할 수 있습니다. 팀이 적절한 릴리스를 준비하는 동안. 실시간 업데이트 배포는 운영 회복 채널입니다. 단순히 외관 변경을 위한 편의성만이 아닙니다.안전성 요구 사항은 제어입니다. 카나리, 베타, 그리고 안정적인 사용자들을 위한 별도의 이름이 지정된 채널을 유지하고, 네이티브 앱 ID와 호환 가능한 런타임 제약 조건을 명확히 하며, 각 사용자에게 받은 번들을 기록하세요. 실시간 업데이트에서는 네이티브 권한을 추가할 수 없으며, 네이티브 플러그인을 교체할 수 없으며, Electron 메인 프로세스를 변경할 수 없으며, 업데이터가 초기화될 수 있는지 여부를 확인할 수 없는 실패를 복구할 수 없습니다. 여전히 스토어 또는 설치 프로그램 릴리스가 필요합니다.
애플리케이션 프로덕션 회귀를 위한 실시간 업데이트 비상 복구 프로세스의 흐름 차트
비상 흐름은 다음과 같이 나타나야 합니다:
범위 확인:
- 영향을 받는 네이티브 버전, 채널, 번들 해시, 그리고 실패 신호를 식별하십시오. scope
- 작업을 시작하기 전에 가장 작은 패치를 준비하세요: 실패하는 경로를 복원하기 위해 필요한 웹 동작만 변경하세요.
- 대상자에게 패치를 전달하세요: 실패하는 설치를 전부 대상으로 하지 말고, 제어된 채널로 패치를 전달하세요.
- 트래픽을 모니터링하세요: 실패하는 계층에 대한 충돌, 로드, 요청, 업데이트 실패 신호를 확인하세요.
- 업데이트를 승격하거나 롤백하세요: 신호가 건강한 경우에만 확장하세요. 패치가 새로운 실패를 유발하는 경우에는 즉시 롤백하세요.
자동 롤백은 팀이 선택한 실패율 또는 로드 실패 임계값을 사용해야 합니다. 롤백은 업데이터가 실패를 감지하고 이전 버전이 사용 가능한 경우에만 사용자에게 보호됩니다. 버전 기록과 채널 보호대책을 유지하여 지원 팀이 특정 장치에 무슨 일이 일어났는지 설명할 수 있도록 하세요.
Capgo은 CapacitorJS 및 Electron 애플리케이션에 대한 서명된 웹-버블 전달, 대상 채널, 장치별 로그, 채택 및 실패 메트릭, 버전 기록 및 자동 롤백 보호를 제공합니다. 실질적인 결정 규칙은 다음과 같습니다: fix가 웹 버블에 국한되어 업데이터가 안전하게 시작할 수 있는 경우, live 업데이트 사용하세요. 런타임, 플러그인, 권한, 패키지 또는 메인 프로세스가 관련된 경우에는 네이티브 핫픽스를 예약하세요.. Capacitor live-update flow __CAPGO_KEEP_0__ live-update flow
사고 후 분석으로 다음 사고를 예방하는 방법
사고 후 분석은 시스템을 변경할 때만 의미가 있습니다. 로그, 배포 컨텍스트, 운영자 결정이 남아 있는 동안 기록하세요. 기록은 사실에 기반을 두고, 비난하지 말고, 다른 엔지니어가 전체 사고를 재구성하지 않고 누락된 경계를 식별할 수 있도록 충분히 구체적이어야 합니다.
5개의 구체적인 블록을 사용하세요
시각화된 시간대와 텔레메트리 타임스탬프 첫 번째 실패한 요청, 영향을 받은 릴리즈, 경보 생성, 조사 단계, 완화, 복구를 기록하세요. Android 대시보드 사고의 경우, 타임라인은 iOS가 유효한 응답을 받으면서도 빈 뷰가 나타난 후 구성 롤아웃이 수행된 것을 보여줄 수 있습니다.
사용자에게 보이는 실패 모드 Describe what customers experienced, not what the code did. “Android users saw an empty dashboard after authentication” gives responders more direction than “API key mismatch.” The first description points toward the broken journey and the signals that should have detected it.
감지 단계 팀이 늦게 배웠던 이유를 설명하세요. 앱이 성공적으로 렌더링되었을 때 크래시 모니터링이 녹색으로 유지되었을 수 있고, 인증된 요청 실패나 빈 대시보드 페이로드를 추적하는 경보가 없었을 수 있습니다. 누락된 신호와 신호가 발생해야 하는 곳을 기록하세요.
code가 아닌 기여 요인 code
예방 경계선 문제를 잡은 테스트 또는 제어를 할당하세요. 예를 들어, 배포 시 프로덕션 인증을 검증하거나 대표적인 클라이언트에서 전달된 구성 확인 또는 패키지된 Electron 시작 테스트를 추가하세요. 경계선은 주인과 실패 조건이 필요하며 retrospection의 단순한 문장만으로는 충분하지 않습니다.
알림 경로는 동일한 검토에 속해야 합니다. 팀에 메일 알림이 도달하지 못하는 경우 Gmail에서 이메일이 스팸으로 이동하는 방법에 대한 실용적인 리소스를 사용하세요. 알림 경로 확인 중에 이메일이 성공적으로 생성된다는 것을 증명하는 것은 운영자가 알림을 받았다는 것을 증명하는 것이 아닙니다. 작업 assign하기 전에 incident를 닫지 마세요.
각 블록에 대해 이름을 하나, 마감일을 하나, 검증 방법을 하나 할당하세요. incident를 다시 검토하세요.
24시간 engineers는 여전히 조사에서 가정에 대한 도전을 할 수 있습니다. 새로운 테스트, 대시보드, 구성 확인 또는 롤아웃 규칙이 성공적으로 실행된 후에만 아이템을 닫으세요.이 마지막 체크리스트를 사용하세요:
native 빌드와 웹 번들을 정확하게 식별했나요?
- context
- 우리는 code , 설정 , 배포 , 인프라 및 의존성 원인과 구별했습니까?
- 사용자 눈에 띄는 오류가 아닌 오로지 충돌만 보여주는지 telemetry가 보여주었습니까?
- 영향을 받은 채널과 알려진 좋은 채널을 테스트했습니까?
- 생산 전에 실패하는 가드레일을 추가했습니까?
- 실시간 업데이트 또는 네이티브 릴리스가 적절한지 문서화했습니까?
- 한 명의 소유자가 고치기를 확인했습니까?
리뷰는 오로지 충돌만을 다루지 않아야 한다는 것을 사용자 불만이 보여줍니다. 6,634 앱을 대상으로 한 감사에서 결제 오류가 28.6% 장치 호환성 28.4%UI 및 UX 마찰 25.4%구독 문제 21.8%앱 오류 및 로그인 오류 17.2%앱이 충돌하는 동안 10.3%. (모바일 앱 불만을 조사한 Bright App Data) 앱이 충돌하는 이유만 물어보는 트러블 슈팅 프로세스는 결제, 로그인, 또는 정상적인 제품 사용을 방해하는 실패를 놓치게 됩니다.
안정성 데이터는 동일한 운영 모델을 지지합니다. 벤치마크는 중간 앱을 99.95% 충돌이 없는 세션위에 위치시키고, 상위 앱은 99.99% 및 하위 앱은 99.77% 이하. 또한 ANR 발생률의 중간값은 10,000 세션당 입니다. OOM 세션당 1.12의 비율및 앱 hang 비율 64에서 103까지의 10,000 세션당 품질 등급에 따라 달라집니다.모바일 안정성 벤치마크안정성이 높아도 의미 있는 실패가 남아 있습니다. 팀은 실패한 요청, 빈 상태, hang, 업데이트 오류 및 사용자에게 나타나는 다른 증상에 대한 테스트 데이터가 필요합니다.
2026년 보고서에 따르면 사용자는 기본적인 기능이 깨진 것에 대해 새로운 기능에 대한 요청보다 보고서에 따르면 . (단일 충돌 후 2-3 번 충돌 후 반쪽 이상이 포기합니다.
사용 Capgo Capgo로 PR 제출
