Поддръжката на сайт не е телефон, на който звъните когато нещо се счупи
Ако сайтът носи запитвания, продажби, резервации или обслужва клиенти, той вече е част от операциите на бизнеса. Това означава, че въпросът не е само кой ще оправи проблема, когато го забележите. По-важно е кой следи системата достатъчно добре, за да види проблема преди клиентът.
Затова добрата поддръжка е operating model: наблюдение, превенция, възстановяване, контролирани промени и ясен процес за развитие. Тя не гарантира, че никога няма да има бъг. Гарантира, че има собственик, сигнал, приоритет и повторяем начин да се стигне от проблем до проверено решение.
Това разграничение е важно и при сравняване на оферти. Два пакета могат да се казват „поддръжка на сайт“, но единият да съдържа само updates и backup, а другият да включва monitoring, QA, performance, малки разработки и месечен backlog.
Maintenance, support и development са три различни неща
Maintenance пази техническата основа в работно състояние: обновявания, зависимости, сертификати, backups и базови проверки. Support е реакцията и диагностиката, когато възникне проблем или бизнесът има оперативна нужда. Development е промяна на продукта: нова функция, нов flow, интеграция, redesign на компонент или по-сериозна оптимизация.
Трите могат да бъдат в един договор, но не трябва да бъдат смесвани като понятия. Ако пакетът обещава „неограничена поддръжка“, попитайте дали това означава неограничено отстраняване на дефекти, неограничени промени по съдържание или неограничена разработка. Това са напълно различни ангажименти.
Ясният scope не е бюрокрация. Той пази и клиента, и екипа от ситуация, в която всяка промяна е спешна, а никой не знае кое всъщност е включено.
- Maintenance: updates, certificates, dependencies, backups и routine checks.
- Support: диагностика, инциденти, content/operational assistance и bug fixing.
- Development: нови функции, интеграции, UX промени и продуктово развитие.
Monitoring: добрата поддръжка трябва да знае, че има проблем
Първият слой е наблюдението. Самото отваряне на началната страница веднъж месечно не е monitoring. Следим дали критичните endpoints отговарят, дали формите изпращат, дали важни jobs и integrations завършват, дали има необичаен ръст на 404/500 грешки и дали сертификат или външна зависимост наближава проблем.
За eCommerce и custom системи health check-ът трябва да следва реалния бизнес flow. Магазинът може да показва homepage с HTTP 200 и едновременно checkout callback-ът да е счупен. Клиентският портал може да се зарежда, но синхронизацията с ERP да е спряла.
Най-полезните alerts са тези, които водят до действие. Сто нотификации дневно, които никой не чете, не са по-добри от липса на monitoring.
- Uptime и критични HTTP/API endpoints.
- Forms, checkout, payments и ключови integrations.
- 404/500 spikes и application errors.
- SSL certificates, scheduled jobs и background queues.
- Дисково пространство, database/backup failures и инфраструктурни лимити, когато са релевантни.
Backup има стойност само ако можете да възстановите от него
Фразата „правим ежедневен backup“ звучи успокояващо, но е половин отговор. Трябва да е ясно какво се архивира, къде се съхранява, колко версии се пазят и как се възстановява сайтът при реален инцидент.
При динамичен сайт кодът, базата данни и uploads имат различен lifecycle. При магазин или портал възстановяването на стара база може да означава загуба на нови поръчки или клиентски действия. Затова recovery plan-ът трябва да отчита вида на продукта, а не просто да има ZIP файл.
Добра практика е процесът за restore да бъде познат и периодично проверяван. Backup, който никога не е бил тестван, е предположение.
- Какво точно се архивира: code, database, uploads, configuration?
- Къде стои копието и отделено ли е от production?
- Какъв е retention периодът?
- Колко време би отнело възстановяването?
- Кой взема решение за restore при активни транзакции?
Security и updates: „обновено“ не означава автоматично „безопасно“
CMS core, plugins, frameworks, libraries и server packages се променят. Но production update не трябва да означава натискане на бутон без контекст. Важното е как се оценява промяната, как се прави backup, има ли staging или друг начин за проверка и какъв е rollback plan-ът.
Същото важи за security. Поддръжката трябва да знае кои компоненти са критични, кой получава известия за уязвимости, как се управляват admin достъпите и какво се прави при подозрителна активност.
При custom приложения security ownership включва и dependencies, permissions, secrets, API keys и логика за достъп. Това не може да се сведе до „обновяваме WordPress всеки месец“.
Bug fixing без QA просто мести риска
Бързото поправяне е важно, но production не трябва да бъде тестовата среда по подразбиране. Дори малка промяна може да засегне mobile layout, analytics event, checkout validation или integration, която не се вижда на екрана.
Затова support процесът трябва да има минимална QA дисциплина: как се възпроизвежда проблемът, как се проверява корекцията, кои свързани flows се тестват и как се връща предишната версия при regression.
Колкото по-критичен е продуктът, толкова по-малко приемливо е „качихме го и вижте дали вече работи“.
- Reproduction на проблема преди промяна, когато е възможно.
- Staging/preview или контролирана проверка преди production.
- Smoke test на критичните flows след deployment.
- Rollback path за промени с реален риск.
- Запис какво е променено и защо.
Performance и SEO health са част от техническата поддръжка
Сайтът може да остане „онлайн“ и постепенно да стане по-бавен, по-тежък и по-труден за обход. Нови scripts, изображения, plugins, third-party widgets и съдържание натрупват технически дълг.
Затова при бизнес сайт има смисъл да се следят Core Web Vitals, crawl/indexing проблеми, sitemap и canonical конфигурация, 404 patterns и важни Search Console сигнали. Това не означава всеки support договор да включва пълна SEO стратегия. Означава техническите проблеми да не остават невидими.
Разликата е между „сайтът отваря“ и „сайтът продължава да работи като добър acquisition канал“.
Малките подобрения трябва да живеят в backlog, не в чат история
След launch започват реалните наблюдения: форма, която може да е по-кратка; CTA, който хората пропускат; нов sales въпрос, който трябва да стане FAQ; поле в admin-а, което екипът попълва ръчно всеки ден.
Ако тези неща стоят в имейли и чатове, продуктът се развива според това кой последно е писал. По-здравият модел е един backlog с контекст, приоритет и приблизителен effort.
Това позволява месечният retainer да не се изразходва само в произволни задачи. Първо се решават проблемите с най-голям риск или бизнес стойност, после удобствата.
SLA: време за реакция и време за решение не са едно и също
Когато сайтът е важен за бизнеса, трябва да е ясно какво се случва при инцидент. SLA или поне ясно описани service levels определят канал за сигнал, работно време, приоритети и очаквана реакция.
Response time е времето, в което екипът поема и започва диагностика. Resolution time зависи от причината. Проблем в CSS и прекъсване на външен payment provider не могат честно да имат еднакво обещание за окончателно решение.
По-полезно е да има ясни severity нива: production down, блокиран checkout, важна функция с workaround, нормален bug и improvement request.
- Кой канал се използва за критичен инцидент?
- Кога започва да тече response time?
- Как се определя severity?
- Какво се случва извън стандартното работно време?
- Кой комуникира статуса, ако решението зависи от трета страна?
Какво обикновено не трябва да се крие вътре в думата „поддръжка“
Нов checkout, нов customer portal, ERP integration или пълен redesign не са естествено „малка поддръжка“. Те могат да бъдат изпълнени от същия екип и дори да използват retainer capacity, но scope-ът и рискът трябва да бъдат оценени отделно.
Същото важи за голяма content migration, нов език, сериозна SEO програма или промяна на platform architecture. Ако договорът не поставя граница, клиентът очаква всичко да е включено, а екипът започва да пази часовете. Това е лош модел и за двете страни.
Добрата поддръжка не казва „не“ на развитието. Тя прави ясно кое е operational support и кое вече е mini-project или roadmap item.
Колко струва поддръжката на сайт и защо няма една честна универсална цена
Цената зависи по-малко от броя страници и повече от риска и отговорността. Статичен фирмен сайт с една контактна форма има различен support profile от WooCommerce магазин, който приема плащания, синхронизира склад и издава документи. Custom B2B portal с роли и ERP връзка е трети тип продукт.
При оферта гледайте какво реално се купува: гарантиран капацитет, response window, monitoring, routine maintenance, включени development часове, QA и reporting. Евтин пакет без ownership може да е напълно достатъчен за brochure site. За revenue-critical продукт може да е грешната икономия.
Най-често моделите са месечен retainer, предплатен пакет часове или договор с по-строг SLA и отделен development capacity. Няма един правилен модел — трябва да съответства на това колко често продуктът се променя и каква е цената на downtime.
Сайт, онлайн магазин и custom система имат различна нужда от support
При фирмен сайт фокусът често е uptime, forms, security, CMS updates, SEO health и content changes. При eCommerce се добавят catalogue feeds, checkout, payments, couriers, stock sync, transactional emails и много повече failure states.
При custom система support-ът вече е близо до software operations: application logs, database, queues, roles, APIs, background jobs, release process и regression testing. Една и съща дума „поддръжка“ не може да описва еднакъв пакет за трите продукта.
Затова добрата оферта започва с кратък технически audit. Преди да обещаем SLA, трябва да знаем какво точно поемаме.
Как изглежда полезният месечен отчет
Отчетът не трябва да е списък „обновихме 7 plugins“. Полезният report показва състояние и решения: имало ли е инциденти, какво е променено, какво се е влошило, какви рискове се виждат и какво предлагаме да се направи следващо.
При сайт с organic acquisition може да има технически Search Console и performance сигнали. При магазин — checkout/integration incidents. При custom продукт — backlog, releases и recurring errors.
Целта не е да докажем, че екипът е бил зает. Целта е собственикът на бизнеса да разбере дали продуктът е здрав и къде си струва да инвестира следващия ресурс.
- Инциденти, downtime и значими errors.
- Updates, deployments и направени промени.
- Backup/recovery и security статус.
- Performance/SEO health сигнали, когато са релевантни.
- Използван support/development capacity.
- Приоритетен backlog за следващия период.
Седем въпроса преди да подпишете договор за поддръжка
Добрият договор не трябва да е огромен документ, но трябва да даде практически отговори. Ако доставчикът не може да обясни тези седем неща конкретно, вероятно и ежедневният support процес ще остане неясен.
- Какво наблюдавате автоматично и как разбирате, че сайтът има проблем?
- Как се правят и тестват backups и кой носи отговорност за restore?
- Как updates стигат до production и има ли rollback?
- Какви са response times за различните severity нива?
- Колко development/change capacity е включен и какво е извън scope?
- Как се управляват достъпи, security incidents и third-party dependencies?
- Какъв отчет и backlog review получаваме всеки месец?
Кога поддръжката трябва да се превърне в product roadmap
Ако всеки месец има повече improvement задачи, отколкото аварии, това е добър знак: сайтът вече не се нуждае само от maintenance, а от управлявано развитие.
Тогава преминаваме от „какво се счупи“ към „коя промяна ще има най-голям ефект“. Backlog-ът се подрежда по бизнес стойност, риск и effort, пускат се малки контролирани releases и ефектът се проверява.
Покажете ни сайта и как се поддържа днес. Ще кажем кои проверки имат смисъл, какво трябва да е автоматизирано, какво да влиза в месечния backlog и къде плащате за дейност без реална стойност.