Технічний аудит сайту: що перевірити спочатку і до яких висновків не стрибати

Зазвичай про аудит згадують не тоді, коли все спокійно. Хтось у команді вже не довіряє цифрам у CRM, менеджери не можуть пояснити, куди поділася частина звернень, а новий виконавець пропонує велике переписування ще до першої перевірки. У такому стані бізнесу потрібен не рейтинг і не загальний висновок про «якість платформи», а зрозумілий список фактів.

Корисний розбір починається з однієї дії, яку можна пройти від початку до кінця. Треба вибрати операцію, де є втрата грошей, часу або довіри, зафіксувати її поведінку, знайти слід у журналах чи даних і лише після цього говорити про зміни. Якщо рекомендація не прив’язана до перевіреного епізоду, це ще не висновок, а припущення.

1. Один маршрут заявки, без пропусків

Найкраще починати з форми, запису чи оплати, від яких залежить щоденна робота. Надішліть один тест із помітним значенням, яке легко відшукати пізніше. Потім перевірте, що побачив відвідувач на сайті, де саме шукає результат співробітник і чи з’явилися там ті самі дані. Це проста дія, але вона швидко показує різницю між «нібито все працює» і реальною доставкою звернення.

Точку призначення треба називати без туману: лист у конкретній скриньці, запис у таблиці, картка в CRM або подія в календарі. Формула на кшталт «пішло в систему» не допомагає нікому. Якщо між формою і CRM людина вручну переносить поля, цей ручний крок теж входить до маршруту. Саме такі місця часто пояснюють, чому заявка ніби була, але в роботі її немає. Суміжні збої вже розібрані в матеріалах чому заявка не доходить і що ламається між формою і CRM.

2. Одна затримка, виміряна в секундах

Коли люди кажуть, що сайт повільний, цього замало для рішення. Потрібно взяти одну сторінку або одну задачу, на якій уже є очікування, і заміряти її на цій системі. Секунди слід записати поруч із URL, назвою джоба або конкретною дією. Після цього коло причин різко звужується: це може бути один важкий запит, серія дрібних повторів, надто велика відповідь або блокування ресурсу.

Якщо є slow log за потрібний проміжок, його варто читати не як список страшних рядків, а як джерело повторюваного шаблону. Однакові запити треба згрупувати, порівняти Rows_examined і Rows_sent, подивитися, що саме повторюється. Навіть коли окремий виклик не перевищує поріг журналу, цикл таких викликів може забирати весь час. Тому відсутність гучного запису ще не доводить, що сторінка працює швидко. Порядок такого читання описаний у нотатці що дивитись у slow log до рефакторингу.

Буває й інша картина: процес розростається, пам’ять не повертається, а після перезапуску все ненадовго поліпшується. Це вже окрема перевірка. Тут треба зняти показники до дії, на піку та після завершення, а не одразу купувати більше RAM. Додаткова пам’ять може лише відкласти повторення тієї самої ситуації. Що саме варто перевірити перед таким рішенням, зібрано в матеріалі що перевірити перед купівлею пам’яті.

3. Чи можна перевірити зміну до появи її на бойовому сайті

Далі треба розібратися, як код узагалі доходить до продакшену. Це може бути гілка, команда, кнопка в пайплайні або ручне копіювання файлів. Важливо знати, хто запускає цей крок, чи є окреме середовище для перевірки і чи можна відтворити попередню викладку. Якщо єдине місце для проби — живий сайт, це не дрібна технічна незручність, а прямий ризик для кожної наступної зміни.

До цього ж розділу належать резервні копії та секрети. Копія, яку ніколи не відновлювали, не дає впевненості; вона лише створює відчуття запасного плану. Треба записати, чи було відновлення, коли воно відбувалося і скільки тривало. Окремо слід перевірити, де лежать паролі, ключі та дампи. Якщо секрет опинився в репозиторії, чаті чи на ноутбуці, це варто назвати як факт, але не дублювати самі значення у звіті. Чому небезпечно вносити зміни одразу на проді через відсутність тестового місця, пояснено в нотатці не правити прод через те, що немає тестового середовища.

4. Спільний продукт означає спільний ризик

Якщо одна система обслуговує кількох клієнтів, перевірка ізоляції даних стає обов’язковою. Потрібно взяти два акаунти й подивитися не лише на очевидні сторінки, а й на пошук, звіти, експорт, фонові задачі та нічні процеси. Один чужий рядок у таблиці — це вже не косметичний дефект, а бізнес-інцидент із наслідками для довіри та договорів.

Поруч із цим варто відкрити журнал помилок хоча б за останній тиждень і знайти повтори. Регулярний збій у нічній задачі — це не абстрактна «якість коду», а конкретна невиконана дія: лист не пішов, файл не зібрався, картка не створилася. Повторювані записи треба зв’язати з операціями, а не складати в безформний список. Типові місця витоку між клієнтами розібрані в матеріалі де ламається ізоляція даних.

5. Чого аудит не повинен робити

Поганий аудит поспішає з великим висновком раніше за перевірку. Він може одразу вимагати переписати весь сайт, поставити чергу, додати кеш або розписати десятки оновлень залежностей, не показавши, яка саме операція від цього виграє. Такий документ створює рух, але не дає ясності.

Охайність коду сама по собі ще не дорівнює сьогоднішньому інциденту. Заплутаний модуль може працювати прийнятно, якщо він виконує один індексований запит і не ламає маршрут заявки. І навпаки, зовні акуратне рішення може щодня губити звернення. Те саме стосується черг і кешу: фоновий джоб із тим самим циклом не прибирає витрату, а лише переносить її в інше місце. Кеш корисний після розуміння, що саме варто зберігати, а черга — коли роботу справді треба винести з HTTP-запиту й контролювати повтори побічних ефектів. Межу для такого рішення описано в нотатці коли черга доречна поруч із застосунком.

6. Яким має бути підсумок

Результат, яким може користуватися бізнес, зазвичай коротший, ніж очікують. Для кожної знахідки достатньо назвати операцію, показати доказ, сформулювати наслідок і запропонувати наступний крок. Наслідок має звучати просто: загублена заявка, затримка в секундах, ризик викладки, поява чужих даних. Пункти треба впорядковувати не за красою інструмента, а за тим, що варто робити спочатку.

• Шлях заявки пройдений один раз, місце призначення назване.
• Секунди повільної операції, а також текст запиту або розмір відповіді, якщо причина в них.
• Як викладається зміна і чи є окреме місце не на проді.
• Відновлення з копії: було або не доведено.
• Секрети: де саме витекли, без копіювання в нотатку.
• Якщо продукт спільний для кількох клієнтів — перевірка двома акаунтами.
• Повторювані помилки за останній тиждень, прив’язані до операції.
• Що ви не будете переписувати, доки цих рядків немає.

Передавати таку нотатку краще тим, хто відчуває наслідок у щоденній роботі. Приклади не повинні містити клієнтських значень, а SQL — зайвих літералів. Якщо документ сам розкриває дані, які мав допомогти захистити, він не виконав своєї ролі.

Коли другий погляд справді потрібен

Команда, яка має доступ до журналів і вміє пройти одну операцію від початку до кінця, часто може зробити такий розбір самостійно. Зовнішній погляд стає корисним тоді, коли ніхто не може відкрити потрібний лог, коли перевіряти доводиться лише на бойовій базі або коли підрядник пропонує велике рішення без секунд, без маршруту заявки й без перевіреного місця збою. У такому випадку достатньо надіслати сторінку, симптом, час очікування та результат однієї тестової відправки. Сирі журнали з даними клієнтів надсилати не треба.

Саме уважне читання фактів і зміна, що випливає з них, і становлять основну цінність роботи. Послуги охоплюють швидкодію, відновлення систем, які вже працюють у продакшені, і зв’язки навколо них. Обрані роботи показують результат поруч з операцією, яка його дала, а не як гасло про всю платформу. Якщо у вас є сторінка і симптом, надішліть саме їх. Дані клієнтів залиште у себе.