#

Техподдержка сайта 24/7: ищем равновесие в вариантах организации

Блог
Чисто офлайновых бизнесов сейчас единицы, для остальных непрерывная работа сайта компании — необходимость и способ не проиграть конкурентам. Разбираем, что может пойти не так и чем поможет техническая поддержка. И попутно выясняем, какие варианты организации техподдержки существуют и где затаились "подводные камни" в каждом из них.

Цифровизация всего и вся — тренд не этого года, но в пандемию освоение онлайн идёт ускоренными темпами. Почти все новые бизнесы теперь с самого начала присутствуют в интернете, а существующие всё больше мигрируют в онлайн — чтобы продукция была доступна в любой точке в любое время. Но для этого нужно не просто представить свои товары и услуги на сайте, нужно, чтобы сайт работал как часы — каждый день без выходных и перерывов на обед. То есть 24/7.

При этом современные онлайн-сервисы и приложения устроены сложно, они состоят из многих компонентов, каждый из которых может выйти из строя. Даже если кажется, что сейчас всё хорошо, проблемы могут настигнуть неожиданно и, если не отреагировать как можно скорее, то финансовых и репутационных потерь не избежать.

Свести к минимуму риск внезапных сбоев и застраховаться от долгих простоев помогает техническая поддержка. Но как её организовать? Перевести своих айтишников на круглосуточную работу? Или отдать на откуп стороннему подрядчику? Мы собрали возможные схемы и расскажем о тонкостях, подводных камнях и примерной стоимости каждого варианта.

Что может пойти не так

У вас есть сайт. Он работает. О чём беспокоиться? К сожалению, есть много разных и вполне вероятных сценариев падения в бездну. Причины тоже могут быть различными, но одна из основных — ваш сайт не справился с нагрузкой.

К примеру, интернет-сми публикует «горячую новость». На портал резко приходит много посетителей. Сайт не справляется с таким трафиком, и большая часть читателей вместо новости видит сообщение об ошибке. Аудитория — вместе с возможностью заработать на рекламе — потеряна, а работа журналиста пропадает зря.

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

Или возьмём инфобиз — например, онлайн-курсы по веб-дизайну. Когда выходит новый курс, его материалы обычно дублируются на несколько серверов раздачи контента, чтобы обеспечить надежность и скорость доступа к ним. Если в этот момент что-то пойдет не так, то студенты вместо лекций получат сообщение о 404-й ошибке. Это приведет, как минимум, к репутационным потерям.

И такие примеры есть в любой отрасли. В каждой из них проблемы с сайтом приводят к упущенной прибыли, а то и прямым убыткам. Поэтому у собственника, по сути, простая развилка: надеяться, что «со мной никогда такого не случится», или заранее подумать о том, что сайт, как и любой сложный механизм, нуждается в «присмотре». Второй вариант — это и есть организация техподдержки.

На бытовом уровне мы привыкли, что техподдержка — это колл-центр, но с точки зрения IT её организация принципиально иная.

По распределению ролей и квалификации сотрудников обычно выделяют три уровня технической поддержки.

Первая линия технической поддержки — это сотрудники, ответственные за сбор и локализацию информации об инциденте, возможное решение проблем по готовым шаблонам, эскалацию инцидентов. Именно этот уровень технической поддержки по своей функциональности в чём-то может быть похож на работу колл-центра (подробнее об организации первой линии читайте в другой нашей статье).

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

И уже сотрудники третьей линии специализируются на «необычных», технически сложных или впервые встречающихся проблемах, анализе и устранении причин возникновения систематически повторяющихся инцидентов.

Распределение задач прояснили, теперь разберёмся с собственно задачами. Во-первых, техническая поддержка в обязательном порядке должна обеспечивать мониторинг: доступности сервиса, системных метрик (нагрузки на процессор/оперативную память), интеграции с внешними системами, такими как платежные системы или сервисы email-рассылок и т. д.

О том, что ваш сервис не работает как следует, вы должны узнавать от системы мониторинга или первой линии техподдержки, а не от посетителей сайта.

 

Во-вторых, техподдержка реагирует на инциденты, устраняет ошибки и исследует причины произошедших сбоев, чтобы не допустить их повторения. А также может взаимодействовать с хостинг-провайдером, проводить плановые работы с оборудованием и заниматься резервированием данных и конфигураций серверного ПО.

Какие есть варианты организовать техподдержку

Итак, мы поняли, что означает техподдержка онлайн-сервиса и разобрались, зачем она нужна для надежного функционирования бизнеса. Теперь выясним, какие бывают способы организации технической поддержки. 

Полноценный инхаус: все сотрудники техподдержки у вас в штате. С одной стороны, этот вариант считается максимально надежным, так как тут вы полностью контролируете своих сотрудников, самостоятельно занимаетесь предоставлением доступов к внутренним системам и серверам. Вместе со своей командой прорабатываете схемы эскалации, прописываете различные регламенты действий в тех или иных случаях, прорабатываете так называемые «ранбуки» (runbook — инструкции по действию в определенных ситуациях). Но и все процессные проблемы, включая составление расписания дежурств и организацию менеджмента, на вас.

Частичная передача технической поддержки на аутсорс: например, в вашем штате будут третья линия и менеджер (техлид) отдела, а организацию первой и второй линии вы доверите внешнему подрядчику. В этом варианте не надо заботиться о составлении круглосуточного расписания и жонглировать сменами. Но, к сожалению, нужно будет очень тщательно продумать систему документации, эскалации, информирования о различных изменениях в структуре проекта и т.д., чтобы взаимодействие штатных и внешних специалистов было эффективным и качественно решало поставленную задачу.

Полная передача круглосуточной технической поддержки на аутсорс. В таком сценарии, во-первых, полностью снимается проблема построения правильного рабочего графика и ротации специалистов. Во-вторых, вам как заказчику достаточно убедиться в надежности подрядчика, но не нужно задумываться об обучении отдельно взятых членов команды — их компетентность гарантирует исполнитель. В-третьих, аутсорс-команда возьмет на себя проблемы постоянной актуализации схем проекта, мониторинга и аудита всех компонентов системы. И в целом команда, которая уже специализируется на поддержке и предоставляет такую услугу, вероятнее всего владеет более широким набором инструментов и имеет больший опыт в обеспечении бесперебойной работы. Конечно, если вы вдумчиво подошли к выбору партнёра, а не связались с «шарашкиной конторкой».

Какой из сценариев выбрать

У каждого из описанных вариантов есть плюсы и минусы. Обратим внимание на подводные камни каждого из них.

Инхаус

Этот вариант при должном подходе наиболее надёжный с точки зрения безопасности, коммуникаций, контроля над сотрудниками и планирования. Однако есть ряд вопросов, с которыми вы скорее всего столкнетесь при его реализации.

  1. Как организовать расписание, какой выбрать график, как сочетать дневные / вечерние / ночные смены.

  2. Как обеспечить бесперебойную работу на время отпуска или внезапной болезни сотрудников — для снижения так называемого bus-фактора. 

  3. Как быть с риском “выгорания” сотрудников техподдержки из-за сложного и зачастую плавающего графика дежурств — особенно, если много ночных смен. 

  4. Как уравновесить нагрузку и сделать её более равномерной, если обычно в пиковые часы днём все в мыле и ресурсов не хватает, а ночью задач слишком мало.

  5. Как всегда держать в актуальном состоянии систему и компоненты мониторинга, регулярно проводить аудит всей инфраструктуры проекта, систематически актуализировать базу знаний и строить процессы обмена знаниями между сотрудниками.

Инхаус-аутстаф 50/50

Самое явное преимущества смешанного варианта — то, что большую часть работы по инцидентам, мониторингу, аудитам можно отдать компании-подрядчику, а штатные сотрудники могут заниматься развитием проекта практически всё время, кроме редких критических нештатных случаев. 

Главное, чтобы при этом коммуникации и обмен знаниями между вашей командой и аутсорс-командой была выстроены очень чётко и не давали сбоев. Иначе может произойти что-то в таком роде: штатная третья линии поддержки в свой обычный рабочий день внедрила новый инструмент или, например, внесла изменения в конфигурацию веб-сервера и не предупредила об этом аутсорс-команду. В ночное время с этим компонентом произошел критический инцидент, а удалённая команда не знает всей картины и не может ничего сделать — простой сайта как минимум на одну ночь обеспечен.

100% аутсорс

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

Как будет организовано общение с подрядчиком. В компаниях, которые предоставляют техническую поддержку сайтов «как сервис», в штате может быть 50−100 технических специалистов разного уровня. В разные моменты времени к вашему проекту могут подключаться разные люди. Это удобно, потому что в случае чего легко усилить команду или найти нужную редкую экспертизу. Но, если со стороны подрядчика не будет выделенного аккаунт- или проектного менеджера, который максимально погрузится в ваши задачи, то вряд ли работа будет продуктивной. Без менеджмента на стороне исполнителей вам придётся самостоятельно общаться со всей технической командой, контролировать качество работ, а также решать проблему «передачи контекста».

SLA (service level agreement) — время реакции на инцидент. Из нашей практики, оптимально, если компания-подрядчик обязуется приступить к разбору аварии или выполнению вашей заявки за 15 минут. Предложения, которые находятся ниже этого порога, либо будут стоить очень дорого (в рамках индивидуального подхода к клиенту), либо сделаны только для привлечения внимания. Если SLA в договоре больше или вообще не прописан, то, возможно, у аутсорсера просто-напросто нет ресурсов на оперативную реакцию и в случае чего работоспособность вашего сайта восстановят… когда-нибудь.

Безопасность. Работая с внешним подрядчиком, вы будете вынуждены предоставить доступ к своим информационным ресурсам удалённой команде. Поэтому очень важно заранее узнать, как будет организован доступ на ваши серверы — используется ли бастион-сервер, двухфакторная аутентификация, ведется ли логирование каждого действия сотрудника на сервере и пр.

А деньги?

Для того чтобы представить стоимость реализации каждого из способов, сделали оценку в виде минимально необходимого найма специалистов или сопоставимых затрат на аутсорс (исходя из опыта работы с каждым из кейсов в ITSumma). Абсолютные цифры будут отличаться в зависимости от региона и локальной ситуации на рынке. Но если ориентироваться на околостоличные территории и — теоретически — принять зарплату одного штатного сотрудника техподдержки, скажем, за 100 000 рублей, прибавить налоги и прочие отчисления, то получится около 135 000. Просто умножьте эту цифру на примерное количество сотрудников, которых нужно нанять, в каждом из столбцов таблицы ниже.   

Вывод

Если вас удивляет, что инхаус получается самым дорогим и вы думаете, что можно дешевле, то в принципе вы правы. Можно попробовать ограничиться штатом в 3−4 человека, переведя сотрудников в режим работы on-call (случись что хоть ночью, человек должен быть на связи, ответить и взяться за работу). Но частые ночные звонки отлично способствуют «выгоранию», этот риск нужно иметь в виду и не рассчитывать на то, что в долгосрочной перспективе удастся сохранить такой распорядок. 

А если вы с подозрением относитесь к заманчиво выгодным вариантам и ждёте от аутсорсеров подвоха, то мы вас понимаем и призываем смотреть не только на цену работ, но и на: условия, договор, отзывы клиентов, опыт в вашей или близкой сфере, наличие подтверждающих сертификатов (например, Certified Kubernetes Administrator), выступления на профильных конференциях, статьи на IT-ресурсах и в блоге компании и т.д.

Наш опыт показывает, что, когда клиенты отдают нам рутину и могут больше не беспокоиться о том, что их сайт будет всегда доступен и справиться с любой нагрузкой, это помогает им сосредоточиться на развитии бизнеса и с большей отдачей использовать освободившиеся финансовые, временнЫе и человеческие ресурсы.

Мы используем cookies для быстрой и удобной работы сайта. Продолжая пользоваться сайтом, вы даёте согласие и принимаете политику обработки персональных данных