Сайт після запуску: оновлення, бекапи, поломки

Сайт живе — це інший режим роботи

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

Звідси базове правило цього уроку: не редагувати сайт у тому самому місці, куди заходять відвідувачі. Спочатку зміна перевіряється окремо, і лише потім потрапляє на основну адресу. Далі в уроці — конкретно, як це зробити, навіть якщо ти не розробник і працюєш через AI-асистента.

Порада Якщо AI-асистент коду вже підключений до GitHub і хостингу (Vercel, Netlify) — така «чернетка» найчастіше вже існує автоматично, просто про неї не знали. Про це — у наступному кроці.

Вноси зміни через тестову версію, а не напряму

Деплой — це публікація готової версії сайту на адресу, яку бачать відвідувачі. Більшість сервісів деплою (Vercel, Netlify) при кожній зміні коду автоматично створюють окреме тестове посилання — прев'ю — де нову версію видно тільки тобі, а основна адреса сайту лишається незмінною, доки зміну не підтверджено.

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

Хочу внести зміну на сайт, який уже працює: [опиши зміну своїми словами]. Перш ніж її робити, скажи: чи підключений цей проєкт до системи, де зміни можна спершу перевірити на окремому тестовому посиланні (preview), не публікуючи одразу на основну адресу сайту? Якщо так — покажи покроково, як це зробити. Якщо ні — запропонуй, як перевірити зміну локально, перш ніж вона стане видимою відвідувачам.

Порада Якщо зміна дрібна (виправити одне слово в тексті) — можна публікувати одразу. Правило «спочатку тестова версія» найважливіше для змін, що торкаються форм, кнопок і логіки сайту.

Версії й відкат: як повернути «було нормально вчора»

Уяви документ Google Docs з увімкненою історією версій: кожне збереження — окремий знімок тексту, і в будь-який момент можна відкрити список і повернутись до того, що було годину чи день тому. З кодом сайту працює той самий принцип, просто називається інакше.

Репозиторій — це папка з кодом сайту, у якій зберігається не тільки поточний стан, а й уся історія змін. Коміт — це один такий збережений «знімок»: стан коду в конкретний момент, з коротким описом, що саме змінилось. Якщо AI-асистент і хостинг підключені до git (а після уроків «Сайт без коду за вечір» і «Форма і база» це, найімовірніше, вже так), кожна опублікована зміна — це окремий коміт, і до кожного з них можна повернутись.

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

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

Порада Постав за звичку: щойно якась частина сайту запрацювала так, як треба, — одразу зберегти цей стан (зробити коміт), а не чекати «поки все буде готово». Тоді відкат — це одна дія, а не відновлення коду з пам'яті.

Дані — не те саме, що код. Бекап потрібен окремо

Код сайту завжди можна відновити: повернути попередню версію (крок вище) або навіть переписати з нуля разом з AI. А от дані — заявки з форми, список підписників, оплати, коментарі — якщо вони зникли, їх ніхто не відновить, тому що вони ніде більше не існували. Це найдорожча частина сайту, і саме її найчастіше забувають зберігати окремо.

Що саме бекапити:

• Дані з форм і бази — усе, що залишають відвідувачі (заявки, email, повідомлення). Це пріоритет номер один.
• Файли, які завантажують користувачі — фото, документи, якщо сайт таке приймає.
• Код — теж варто мати копію поза основним хостингом, але він другий за важливістю, бо його можна відтворити.

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

Допоможи мені зробити регулярний бекап даних із мого сайту: [опиши, де зберігаються дані — форма, база, таблиця]. Поясни покроково, як експортувати ці дані у звичайний файл (наприклад CSV) і де його варто зберігати окремо від хостингу сайту, щоб не втратити, якщо із сайтом щось станеться.

Порада Найпростіший бекап — це файл, збережений у власній хмарі (Google Drive, Dropbox) поза сайтом. Головне — щоб копія лежала не в тому самому місці, що й оригінал.

Оновлення залежностей: чому воно ламає і як не боятись

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

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

Як оновлювати без страху:

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

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

Порада Якщо після оновлення щось зламалось — це той самий випадок, що й у кроці про відкат: спочатку поверни попередній робочий стан, а вже потім розбирайся, яка саме залежність винна.

Домен і сертифікат теж мають термін дії

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

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

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

Сайт впав: перші 5 хвилин по порядку

Коли сайт недоступний, паніка змушує хапатись за все одразу. Натомість пройди чекліст по порядку — здебільшого причина знаходиться на одному з перших пунктів:

1. Чи були зміни в коді нещодавно? Якщо так — це найімовірніша причина. Переходь одразу до кроку про відкат. 2. Чи не закінчився термін домену або сертифіката? Перевір у панелі реєстратора домену (попередній крок). 3. Чи це проблема саме сайту, чи сервісу хостингу загалом? Перевір сторінку статусу хостингу (status page) — якщо там позначена загальна проблема, це не пов'язано з кодом, і лишається тільки чекати. 4. Чи це справді сайт, чи локальна проблема? Перевір з іншого пристрою або мережі (наприклад, з телефону через мобільний інтернет) — інколи «сайт впав» насправді означає проблему з кешем браузера чи інтернетом. 5. Що каже лог останнього деплою? Якщо перші чотири пункти нічого не дали — дивись лог публікації на явні помилки (детально про читання помилок — в уроці «Лагодимо код разом з AI»).

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

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

Коли задача вже не для AI, а для живої людини

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

• Гроші — підключення чи зміна платіжної системи, суперечки з платежами, повернення коштів.
• Персональні дані — витік чи підозра на витік даних клієнтів (email, номери телефонів, платіжні дані).
• Юридичні наслідки — умови використання, авторські права на контент чи код, договірні зобов'язання перед клієнтами.
• Дані, які не можна втратити, а відкат чи бекап не допомагає — ситуація незрозуміла, а ставки високі.

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

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