Троє розробників за п’ять років: як оновлювати сайт без страху

2021 рік: компанії створили сайт на десять сторінок. За наступні п’ять років з’явилися каталог, онлайн-оплата, особистий кабінет і CRM, а над проєктом попрацювали троє розробників. Тепер власник просить змінити форму замовлення й чує: «Тільки нічого зайвого не чіпайте, бо невідомо, що перестане працювати».

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

У 2021 році це був сайт на десять сторінок. Що змінилося за п’ять років

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

Звичайна форма тепер не просто надсилає лист. Вона зберігає замовлення в базі, створює угоду в CRM і передає дані службі доставки. Якщо без перевірки перейменувати поле, сторінка може виглядати справною, а менеджери перестануть отримувати заявки. Помилку помітять не під час редагування, а коли зникнуть продажі.

Почати можна навіть без доступу до коду: виписати функції, від яких залежать замовлення та робота менеджерів, і вказати пов’язані сервіси. Так стане видно, де невелика правка зачіпає одразу кілька процесів.

Чому нова функція часто означає ще один шар залежностей

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

«Це тимчасово, потім переробимо»

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

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

Два модулі роблять майже те саме

Один плагін може обробляти заявки, інший надсилати повідомлення про них. Якщо видалити «зайвий» навмання, форма залишиться, але листи зникнуть. Перед очищенням системи перевіряють список розширень, власні зміни коду та файли залежностей composer.json, composer.lock чи package.json, якщо вони є.

Не поспішайте вимикати незрозумілі компоненти. Спершу визначте, що саме вони роблять, хто від них залежить і як перевірити результат заміни на тестовій копії.

Сім сигналів, що оновлення сайту стало ризиком

Оновлення стає ризикованим, коли команда не знає всіх залежностей і не може перевірити наслідки до публікації. Для сайту з оплатою та CRM це вже питання не лише коду: збій може залишити менеджерів без замовлень.

1. Оновлення CMS відкладають місяцями. Не перевірено сумісність теми, модулів або власних правок.
2. PHP роками не оновлюють. Невідомо, чи працюють старі бібліотеки та розширення з новою версією.
3. Кажуть: «Цей плагін краще не оновлювати». Причину заборони не описали й не відтворили на тестовій копії.
4. Після дрібної зміни ламається інша функція. Компоненти пов’язані сильніше, ніж здається.
5. Немає окремого staging. Частину змін доводиться перевіряти безпосередньо на робочому сайті.
6. Призначення cron або API невідоме. Ніхто не може сказати, що станеться після вимкнення.
7. Backup є, але відновлення не перевіряли. Невідомо, чи вдасться повернути файли й дані в потрібний час.

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

		Що перевірити перед оновленням
Симптом	Перевірка	Можливий наслідок
Оновлення відкладають	Сумісність CMS та модулів	Накопичення непідтримуваних залежностей
PHP не змінюють	Вимоги бібліотек і розширень	Помилки після переходу
Незрозумілі cron-завдання	Команди, розклад, журнали	Зупинка імпорту чи розсилок
Немає staging	Де перевіряють зміни	Збої на робочому сайті
Backup не відновлювали	Тест відновлення файлів і БД	Невизначений час простою

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

Що зникає разом із розробником: карта знань про сайт

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

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

Що записати про проєкт

Для початку достатньо кількох сторінок із такими відомостями:

• реєстратор домену, керування DNS, власники основних акаунтів;
• хостинг або сервер, CMS чи framework, розташування репозиторію;
• версії PHP або Node.js, СУБД та важливих розширень;
• платіжні системи, CRM, пошта, API й вебхуки;
• cron, черги та інші фонові процеси;
• місце й періодичність резервного копіювання, порядок відновлення;
• адреса staging, інструкція з розгортання, відповідальні за зміни.

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

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

Як тестувати зміни, не ризикуючи замовленнями: staging і резервні копії

Backup допомагає повернути дані після збою, а staging дає змогу перевірити зміни до публікації. Це різні засоби захисту: резервна копія не покаже заздалегідь, що після оновлення форма перестане передавати заявки в CRM.

На робочому сайті купують, на тестовому перевіряють

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

Після оновлення форма може показувати «Заявку надіслано», хоча запис у CRM не створився. Тому перевіряють не лише сторінку, а й появу тестової заявки в CRM, повідомлення та журнали помилок. Це частина коротких перевірок критичних сценаріїв, або smoke tests.

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

Backup існує. А відновити сайт із нього можна?

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

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

Серверні налаштування, які теж успадковує новий підрядник

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

Сайт залежить від версій PHP, MySQL чи MariaDB, встановлених модулів, правил Nginx або Apache, SMTP, змінних середовища та фонових служб. Окремі файли конфігурації розташовані поза каталогом сайту. Тому скопіювати код і базу недостатньо: треба відтворити умови, у яких вони працювали.

У технічному паспорті варто зазначити не лише назву хостинг-провайдера, наприклад UkrLine, а й версії PHP, параметри бази даних, розклад фонових завдань та порядок відновлення. Саме ці відомості допоможуть новому підряднику відтворити середовище без пошуку налаштувань навмання.

Для PHP команди php -v та php -m показують версію й модулі командного рядка. Вебсервер може використовувати іншу версію PHP та інший набір розширень, тому треба перевірити й фактичне середовище обробки вебзапитів. Якщо проєкт використовує Composer, команда composer check-platform-reqs допоможе звірити платформні вимоги встановлених пакетів у тому середовищі, де її запускають.

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

Лагодити поступово чи перебудовувати: критерії рішення

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

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

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

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

Передача сайту без прихованих залежностей: чек-лист для власника

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

До завершення співпраці перевірте, що нова команда фактично отримала:

• репозиторій з актуальним кодом та історією змін;
• потрібні адміністративні права в CMS;
• контроль над доменом, DNS і акаунтом реєстратора;
• доступи до хостингу, сервера та бази даних;
• захищений спосіб отримання секретів, .env і ключів API;
• перелік інтеграцій, вебхуків та їхніх власників;
• опис cron, черг і фонових обробників;
• резервні копії та перевірений порядок відновлення;
• доступ до staging і порядок тестування змін;
• інструкцію з розгортання, оновлення та повернення версії;
• контакти постачальників критичних послуг;
• план відкликання зайвих прав попереднього підрядника.

Паролі та ключі змінюйте послідовно. Спочатку з’ясуйте, де вони використовуються, потім оновлюйте доступи й перевіряйте інтеграції. Раптове вимкнення старого API-ключа може зупинити обмін замовленнями.

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

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