Техническая поддержка IT-систем — это регулярная работа по договору, которая удерживает сайт, CRM, ERP и сервисы компании в рабочем состоянии: мониторинг, разбор обращений в согласованные сроки, обновления, резервные копии и отчёт о сделанном. Поддержка рабочих систем начинается от 700 $ в месяц, поддержка сайта — от 250 $ в месяц.
Коротко
Поддержка отличается от вызова специалиста после поломки тем, что объём работ описан заранее и часть из них выполняется до того, как что-то сломалось. Приходящий администратор появляется по факту аварии; поддержка работает по регламенту.
Отдельно от поддержки стоит развитие: новые функции, интеграции и отчёты — это не поддержка, а работа по оценке или отдельный пакет с фиксированным объёмом часов. Сайт со своим набором задач — домен, сертификат, мониторинг страниц — разобран в статье о поддержке сайта после запуска.
Поддержка начинается не с мониторинга, а с описи: какие системы есть, на каких серверах они живут, кто ими пользуется и что случится с бизнесом, если каждая из них остановится. Без этой карты любые договорённости о сроках повисают в воздухе — непонятно, что считать критичным.
Критичность определяют по последствиям для работы, а не по мнению о том, какая система «важнее».
Уже из этой карты вырастает мониторинг: для критичных систем — проверки сценариями и оповещения дежурному, для остальных — базовые проверки доступности и ресурсов. Автоматический мониторинг не зависит от времени суток, а вот время реакции людей — предмет договора.
SLA — соглашение об уровне сервиса, то есть письменные обязательства подрядчика: по каким каналам принимаются обращения, как определяется приоритет, за какое время команда берётся за задачу и что происходит, если срок нарушен. Разница с устными обещаниями в том, что у заказчика появляется формальный инструмент, а не повод для обиды.
| Приоритет | Пример обращения | Что фиксируют в договоре |
|---|---|---|
| Критичный | CRM недоступна, оплаты не проходят, данные потеряны | Немедленное начало работ, порядок эскалации и способ связи вне рабочих часов |
| Высокий | Не работает функция, но есть обходной путь | Время реакции в рабочие часы и ориентировочный срок решения |
| Обычный | Вопрос сотрудника, мелкая правка, настройка отчёта | Очередь и плановый срок, объём мелких работ в месяц |
| Изменение | Новая функция, интеграция, новый отчёт | Отдельная оценка: сроки и стоимость согласуются до начала |
Важно Универсальных цифр в SLA не бывает: конкретные часы реакции зависят от состава систем, режима работы компании и цены простоя. Мы фиксируем их в договоре по типам обращений, а не обещаем «быстро» на словах.
Отчёт нужен, чтобы абонентская плата не выглядела платой за тишину. В нём видно, за что вы платите и что изменилось в инфраструктуре за месяц.
Отдельная строчка — разбор повторяющихся сбоев. В инженерной практике это называется разбором инцидента без поиска виноватых: книга Google по SRE описывает его как письменную запись о происшествии, его последствиях, действиях по устранению, корневых причинах и шагах, которые не дадут ему повториться. Смысл в том, чтобы менять систему и процессы, а не назначать виновного.
Выбор зависит не от размера компании, а от того, сколько у неё систем, насколько дорог простой и есть ли кому ставить задачи внешней команде. Аутсорсинг — это передача части работ подрядчику по договору; он не отменяет необходимости иметь внутри человека, который понимает, чего компания хочет от IT.
| Критерий | Штатный администратор | Аутсорсинг | Смешанная модель |
|---|---|---|---|
| Знание вашей специфики | Максимальное: человек внутри процессов | Нарабатывается при приёмке и фиксируется в документации | Внутренний сотрудник объясняет контекст, подрядчик закрывает технику |
| Отпуск, болезнь, увольнение | Работа останавливается или ложится на других | Обязательства остаются за компанией-подрядчиком | Подстраховка с двух сторон |
| Набор компетенций | Ограничен опытом одного человека | Шире за счёт разных специалистов подрядчика | Узкие задачи уходят наружу, ежедневные остаются внутри |
| Затраты | Зарплата, налоги, рабочее место, обучение | Фиксированная сумма по договору | Зарплата и абонентская плата одновременно, зато нагрузка распределена |
| Ответственность | Трудовой договор | Договор с оговорёнными сроками реакции | Делится по зонам, это описывают заранее |
| Кому подходит | Много техники на местах и постоянные задачи внутри офиса | Ключевые системы работают удалённо, нужна предсказуемая реакция | Компания выросла, но своя IT-служба ещё не собрана |
Считать выгоду честно — значит сравнивать не «зарплата против абонентской платы», а полную стоимость: налоги и оборудование, обучение, время руководителя на постановку задач и цену простоя, которого не случилось.
Приёмка — это отдельный этап до начала абонентского обслуживания. Он нужен, чтобы подрядчик отвечал за то, что действительно понимает, а не подписывался под чужим наследством вслепую.
По итогам приёмки честный ответ звучит так: вот это можно поддерживать как есть, а вот это дешевле переделать, чем чинить каждый месяц. План на случай серьёзной аварии — тема отдельной статьи о восстановлении IT-систем после сбоев.
Внешняя команда получает доступ к системам, где лежат данные клиентов и сотрудников, поэтому правила доступа описывают до начала работ. В Узбекистане это не только вопрос доверия: закон «О персональных данных» (№ ЗРУ-547 от 02.07.2019) требует, чтобы правовые, организационные и технические меры защиты принимали и собственник, и оператор, и третье лицо, а требование конфиденциальности распространяется на всех, кто получил доступ к данным.
Как это устроено внутри систем с клиентской базой — роли, ограничения и журнал событий — разобрано в статье о правах доступа в CRM.
Ключевой признак зрелого подрядчика — он сам предлагает описать границы работ до подписания договора, а не обещает решить всё. Проверьте по списку, прежде чем соглашаться.
Цена зависит от того, что берётся под присмотр и насколько дорог простой этих систем. На странице технической поддержки три пакета с разным составом работ.
Syntra Systems берёт проекты, сделанные другими: изучаем код, инфраструктуру и настройки, фиксируем риски и только потом соглашаемся на обслуживание. Повторяющиеся сбои разбираем до корня — иначе поддержка превращается в тушение одних и тех же пожаров. Документацию ведём и передаём вместе с доступами, чтобы при смене команды проект не оказался чёрным ящиком.
Серверная часть при необходимости закрывается вместе с поддержкой: сервер под сайт или CRM в дата-центре Узбекистана начинается от 30 $ в месяц, состав работ описан на странице серверов и облака.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Да, форматы совместимы. Штатный специалист закрывает ежедневные задачи и знает специфику компании, а внешняя команда берёт мониторинг, сложные инциденты и направления, где нужна узкая экспертиза. Зоны ответственности при этом описывают заранее, иначе задачи начинают теряться между двумя сторонами.
Это определяется договором. Автоматический мониторинг работает независимо от времени суток и присылает оповещение, а время реакции людей фиксируется по типам обращений: критичное берём в работу сразу, остальное — в согласованные окна. Круглосуточное дежурство инженеров отдельной услугой мы не заявляем.
Безопаснее, чем общий пароль администратора, известный половине офиса, — при условии, что доступы персональные, выданы в минимальном объёме и отзываются при завершении работ. Требование конфиденциальности распространяется на всех, кто получил доступ к персональным данным, а ответственность подрядчика закрепляется договором и NDA.
Да, для этого и нужна приёмка: мы изучаем код, инфраструктуру и настройки, собираем доступы и фиксируем риски. После этого говорим, что можно поддерживать как есть, а что дешевле переделать. Без приёмки ответственность за чужое решение брать нельзя — это нечестно по отношению к заказчику.
Поддержка удерживает систему в рабочем состоянии: мониторинг, инциденты, обновления, копии, мелкие правки в согласованном объёме. Доработка меняет возможности системы — новые функции, интеграции, отчёты — и оценивается отдельно или выполняется в пакете развития с фиксированным объёмом часов в месяц.
Доступы ко всем системам, оформленные на компанию, документация по инфраструктуре, резервные копии и исходный код с историей изменений. Это стоит записать в договор с самого начала: тогда смена команды остаётся рабочей задачей, а не поводом собирать проект заново.
По ежемесячному отчёту: сколько было обращений, какие обновления поставлены, прошли ли проверки восстановления, какие риски закрыты. Отсутствие аварий — результат этой работы, а не совпадение, и отчёт показывает, какими действиями он достигнут.