Що насправді має входити в план підтримки сайту
План підтримки сайту — одна з небагатьох регулярних витрат, які бізнес підписує, так і не побачивши, що саме купує. У рахунку написано «обслуговування», і він приходить щомісяця. Що відбувається натомість, коливається від справжньої операційної служби до того, що хтось раз на квартал натискає «оновити все», — і ззовні ці два варіанти виглядають однаково рівно доти, доки в якийсь місяць щось не зламається.
Розкид цін на ринку достатньо великий, щоб ця невизначеність коштувала дорого. Опубліковані на 2026 рік цифри розміщують типові плани для малого бізнесу приблизно в діапазоні 200–600 доларів на місяць, агентські ретейнери — від приблизно 500 до 2500, а корпоративні домовленості значно вище. Десятикратна різниця означає, що сама по собі ціна не говорить майже нічого. Говорить опис обсягу.
Чотири складові, з яких насправді складається план
Майже будь-який чесний план підтримки розкладається на чотири окремі служби. Продають їх зазвичай одним рядком — звідси й плутанина, бо підрядник може бути відмінним в одній і бути відсутнім у решті.
- Тримати в безпеці. Патчинг, оновлення залежностей, керування доступами, сканування на шкідливий код, поновлення сертифікатів.
- Тримати живим. Моніторинг доступності, бекапи, які хоча б раз відновлювали, і визначена реакція, коли сайт лежить.
- Тримати актуальним. Правки контенту, невеликі зміни, нові сторінки. Саме це клієнти й думають, що купують.
- Тримати в розвитку. Робота над швидкістю, виправлення доступності, розбір аналітики. За замовчуванням майже ніколи не входить і зникає першим, коли годин починає бракувати.
Попросіть потенційного підрядника оцінити ці чотири речі окремо, навіть якщо збираєтеся купувати їх разом. Вправа діагностична: той, хто думав про обслуговування, розкладе їх за кілька хвилин, а той, хто не може, продавав вам невизначену обіцянку.
Що має бути в обсязі, рядок за рядком
| Пункт | Як виглядає добре | Типовий пропуск |
|---|---|---|
| Патчинг безпеки | Названий відповідальний, заявлений інтервал, критичні фікси поза графіком | «Щомісячні оновлення» без винятку за критичністю |
| Бекапи | Копія поза сервером, заявлений строк зберігання, регулярна перевірка відновленням | Бекапи є, але їх ніколи не відновлювали |
| Моніторинг доступності | Зовнішня перевірка, сповіщення людині, визначений час реакції | Моніторинг, який бачить підрядник і ніколи не бачить клієнт |
| Час реакції | Рівні за критичністю, визначені робочі години, названа ескалація | Одне розмите «ми швидко реагуємо» |
| Включені години | Число, ставка понад нього і чи переносяться години | «Невеликі правки включено» без визначення «невеликих» |
| Ліцензії | Хто платить, у чиєму акаунті лежать, що буде при розставанні | Ліцензії в акаунті агенції, для вас невидимі |
| Стейджинг | Копія, де зміни тестують до виходу в бій | Правки одразу на продакшені |
| Звітність | Що зроблено, що знайдено, що потребує рішення | Автоматичний звіт плагіна, який ніхто не читає |
Час реакції: пункт, який вирішує все інше
Плани підтримки живуть або вмирають на цьому, і саме цей розділ клієнти проглядають по діагоналі. Галузева практика усталилася на рівнях: типова домовленість обіцяє одну робочу годину на першу реакцію при критичному інциденті й 24 години на звичайний запит, за цільової доступності 99,9% на місяць. Для критичних систем зобовʼязання підіймають до 99,95% або 99,99%.
Дві речі варто зрозуміти, перш ніж приймати будь-яку з цих цифр.
По-перше, час реакції — це не час усунення, і підрядники рідко пояснюють різницю самі. Зобовʼязання «одна година» означає, що хтось підтвердить отримання заявки протягом години. Про те, коли сайт запрацює, воно не говорить нічого. Просіть обидва показники й приймайте те, що зобовʼязання щодо усунення буде ширшим і умовним.
По-друге, відсотки доступності менші, ніж звучать. 99,9% дозволяють близько 43 хвилин простою на місяць. 99,5%, які трапляються в чималій кількості договорів, дозволяють близько трьох з половиною годин. Чи має це значення, залежить винятково від того, чи приходить ваш дохід через сайт, — а це той самий розрахунок, що стоїть за питанням, скільки сайт вартий на годину.
Чому патчинг — частина, яку не можна пропустити
Із чотирьох служб патчинг — та, де відсутність дає бінарний результат, а не поступове погіршення. Дані про вразливості за 2026 рік однозначні щодо того, де саме ризик: переважна більшість розкритих дірок WordPress припадає на плагіни, а не на ядро, і вікно між розкриттям і масовою експлуатацією вимірюється годинами, а не тижнями.
Цей темп ламає поширену схему, за якою оновлення ставлять під час щомісячного візиту. Місячний цикл прийнятний для функціональних релізів і неприйнятний для критичних виправлень безпеки, тож у плані потрібні обидва режими: регулярний інтервал і позаплановий тригер із заявленою максимальною затримкою. Якщо договір не розрізняє ці дві речі, він описує прибирання, а не безпеку, і решта ваших базових заходів захисту тягне навантаження, на яке не була розрахована.
Бекапи: пункт, який найчастіше присутній і найрідше працює
Бекапи є майже в кожному плані. Значно рідше в ньому вказані три властивості, які роблять їх корисними.
- Поза сервером. Бекап на тому самому сервері, де сайт, захищає від помилки, але не від зламу й не від відмови хостингу.
- Глибина зберігання. Сім днів бекапів нічого не варті проти компрометації, виявленої на третьому тижні, а власники сайтів зазвичай виявляють такі речі пізно.
- Перевірені. Відновлення, яке ніколи не виконували, — це гіпотеза. Питайте, коли востаннє його робили, на чому і скільки часу воно зайняло. Відповідь на «скільки часу» і є вашим справжнім часом відновлення, що б не було написано в договорі.
Варто знати й де фізично лежать ці копії: бекапи — одне з місць, куди сайт тихо розсіює дані по юрисдикціях, які ніхто свідомо не обирав, і в цьому суть питання, де насправді живуть дані вашого сайту.
Що не входить і має оцінюватися окремо
Саме ці пункти перетворюються на суперечки на четвертому місяці, бо кожна сторона припустила своє.
- Новий функціонал. Нова форма — це зміна. Нова система бронювання — це проєкт. Межу треба записати, бажано порогом у годинах, а не прикметником.
- Робота з редизайну. Підтримка тримає працездатним чинний дизайн. Змінювати його — окрема історія, і це рішення належить річному плану, а не ретейнеру.
- Поломки на боці третіх сторін. Коли платіжний провайдер змінює API, хтось має полагодити інтеграцію. Ця робота реальна і в ній ніхто не винен — саме тому їй потрібен окремий пункт.
- Виробництво контенту. Опублікувати наданий текст — це обслуговування. Написати його — ні.
- Аварійні роботи поза графіком. Або вони покриті за заявленою ставкою, або не покриті. Обидва варіанти прийнятні; неприйнятна невизначеність.
Як порівняти ціну з «не робити нічого»
Чесне порівняння — не план А проти плану Б. Це план проти вартості подій, які він запобігає, а це невелика кількість великих і нечастих втрат.
Три цифри роблять аргумент конкретним для конкретного бізнесу: дохід за день через сайт, вартість прибирання після компрометації разом із втраченим торговим часом і вартість аварійного розробника, який ніколи не бачив вашого коду. Для більшості малих бізнесів уже третя цифра наближається до річної вартості скромного ретейнера, бо незнайомість коштує дорого, а терміновість знищує будь-яку переговорну позицію.
Саме тому найдешевший план часто виявляється найгіршим за співвідношенням. Ретейнер без включених годин і без моніторингу коштує менше, ніж здається, рівно до першого інциденту — коли зʼясовується, що ви купуєте аварійну роботу за аварійними ставками в підрядника, який не заглядав у сайт від дня запуску.
Аудит плану, за який ви вже платите, за годину
Більшість тих, хто це читає, уже мають план і хочуть зрозуміти, чи він справжній. Пʼять запитів це вирішують, і жоден із них не потребує технічних знань для тлумачення. Надішліть їх одним листом і оцінюйте відповіді як за змістом, так і за тим, скільки часу вони йшли.
- «Надішліть перелік оновлень за останні три місяці з датами». Підрядник, який робить роботу, має це в журналі. Той, хто не робить, складе зведення вже після отримання вашого листа.
- «Коли востаннє відновлювали бекап і скільки це зайняло?» Єдине питання в цьому переліку з фактичною відповіддю, яку неможливо вигадати на ходу.
- «У яких акаунтах лежать ліцензії й моніторинг?» Це показує, що лишиться у вас, якщо стосунки завершаться завтра.
- «Що ви вирішили не робити і чому?» У будь-якого обслуговуваного сайту є відкладені пункти. Підрядник, у якого їх немає, просто не дивиться.
- «Хто закриває це, коли звична людина у відпустці?» Залежність від однієї людини — найпоширеніша структурна слабкість малих ретейнерів і найлегша до виправлення, щойно її назвали.
Відповіді, що приходять протягом дня, з конкретикою й хоча б одним незручним визнанням, описують робочу службу. Відповіді через тиждень і загальними словами описують рахунок.
План, який варто підписати, одним абзацом
Названий відповідальний за патчинг, регулярний інтервал і правило для позапланових критичних виправлень. Бекапи поза сервером із заявленим строком зберігання і перевіркою відновленням із заявленою періодичністю. Зовнішній моніторинг доступності, що будить людину, з рівнями реакції, відділеними від часу усунення. Визначена кількість включених годин, ставка понад них і письмова межа між зміною та проєктом. Ліцензії в акаунтах, які належать вам. Копія-стейджинг. Щомісячна записка про те, що зроблено і що потребує рішення. Якщо ці пункти є і вони конкретні, ціна — комерційне питання. Якщо їх немає, ціна не має значення, бо ви купуєте не послугу, а намір.
Коротко
Плани підтримки коштують приблизно від 200 до 2500 доларів на місяць за роботу, яка може відрізнятися на порядок, тож єдине осмислене порівняння — за обсягом. Розкладайте будь-який план на чотири служби: безпека, доступність, зміни, розвиток. Наполягайте на розрізненні реакції й усунення, а відсотки доступності читайте як хвилини, а не як девʼятки. Патчинг не обговорюється, бо вікно експлуатації вразливостей у плагінах вимірюється годинами, а отже цикл «тільки раз на місяць» — це діра в безпеці, а не графік. Бекапи мають бути поза сервером, зберігатися достатньо довго, щоб пережити пізнє виявлення, і хоча б раз відновлені, щоб час відновлення був фактом, а не припущенням. Запишіть, що не входить, — особливо новий функціонал і поломки третіх сторін. І порівнюйте ціну з вартістю аварії, а не з дешевшим планом, який тихо виключає ту саму роботу.
