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

Интервьюер: Исходя из того, что ты рассказал ранее, получается, что у вас есть разделение на первую и вторую линию поддержки. Есть более слабые инженеры, которые работают в 24 на 7 и есть более квалифицированные, которые решают более сложные задачи. Отсюда вопрос: есть у вас разделение по группам знаний или отделам специалистов второй линии, то есть более квалифицированных сотрудников?

TeamLead: Дело в том, что в нынешних реалиях у нас уже нет таких специалистов, как администратор в привычном понимании этого слова. И мы не отделяем таких людей от DevOps, так как им постоянно приходится поддерживать такие вещи, как CI, Jenkins, Git, то есть напрямую связанные с деплойментом. У нас все люди, которые поддерживают какую-либо часть инфраструктуры должны понимать, как работает процесс деплоймента, процесс CI и так далее. Плюс надо сказать, что эскалация бывает разная.

Интервьюер: Ты имеешь ввиду прямую эскалацию на разработчиков?

TeamLead: Да, я к этому и веду. Если, например, инженер поддержки авторизовался и видит проблему, которая не связана с апачем или какими-то веб-серверами, то есть он видит, что это явно программный сбой, он сразу передает это программисту и не пытается эскалировать на команду поддержки проекта. Потому что не имеет смысла подключать еще одного инженера, который увидит те же ошибки и все-равно передаст на программистов. Поэтому мы сразу эскалируем это на разработчиков, которые могут зайти и отдебажить код, который дал сбой.

Интервьюер: А как такие ситуации прописаны у вас во Flow?

TeamLead: Для работы, эскалации, нотификации, расписаний мы используем Pagerduty, для запоминания, что произошло и что мы сделали мы используем RedMine и Jira. Redmine – это наш internal tool, который используется для 24 на 7 и для запросов от наших внешних привлеченных специалистов. Jira используется для девелопмента.

Разные инструменты используем, потому что все сейчас пытаются работать по SCRUM и Agile. Таким образом, есть какие-то спринты, которые идут по девелопменту и в рамках которых мы, как ИТ-команда, должны вовлекаться внутрь этих процессов. Поэтому все они (процессы) проходят внутри Jir-ы, а помимо этого поступают тикеты, обработка которых имеет другие процессы и вот это у нас реализовано в Redmine.

Интервьюер: А вы как-то описывали свои flow по поддержке. То есть какие входы и выходы? Откуда может прийти заявка? Что с ней делать и т.д.

TeamLead: У нас этот flow прописан по проектам, а все проекты очень разные.

Интервьюер: И что, на каждый проект свой flow?

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

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

Рисунок 1-Разные источники оповещения для разных проектов

Есть так же специальные почтовые ящики. Письмо, попавшее в такой ящик, автоматически генерирует смс-ку для специалистов 24 на 7 команды. И они по нему так же должны работать.

То есть по каждому проекту flow разные и один универсальный не получается сделать.

Интервьюер: Но постоянное наблюдение за чатом может быть целой проблемой.

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

Интервьюер: Но дежурный, так или иначе, постоянно должен контролировать skype-чаты, системы, мониторинга, Jira и так далее? На это уходит его основное время?

TeamLead: По skype -чатам у нас организовано проще. Заявки в skype -чате не являются срочными или приоритетными. Мы проверяем такие чаты в определенное время. Skype -чат – это метод нотификации о тех событиях, которые произошли, но мониторинг их не зафиксировал или мы что-то упустили. Кроме того, эти источники проверяются только в дневные смены, когда на работе много наших специалистов и так же много людей присутствуют на рабочем месте у заказчика. У нас есть договоренность о том, что если надо срочно привлечь внимание поддержки, то не рассчитывайте на skype -чат, а напишите письмо на определенную почту, создайте тикет или запустите определенный процесс и тогда вы получите быструю поддержку.

Интервьюер: Если клиент хочет полностью отказоустойчивое решение, вы предлагаете ему дополнительные сервисы?

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

Интервьюер: Какие soft-skills вы развиваете у своих инженеров? Как работаете с культурой и клиент ориентированностью?

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

Интервьюер: Как я понимаю, это неписанные правила компании?

TeamLead: Да, это правила сформированные, скорее, на уровне самоорганизации, на уровне контроля со стороны тимлида, PM-а проекта.

Интервьюер: А как насчет hard-skills? Какие технологии поддерживаете, в какую сторону идете? Есть ли какие-то стандарты в этом поле или считаешь это бесполезным?

TeamLead: Это полезно. Но по поводу развития этих навыков нужно упомянуть о том, что многое зависит от заказчика, его культуры и его знаний в ИТ. То есть, если клиент — человек, сведущий в бизнесе, но несведущ в ИТ, то он может не понимать необходимость QA, тестов, автоматизации деплоймента и, даже, бэкапов в своем проекте. Поэтому наша команда сначала должна донести до него эту информацию. Показать необходимость всего этого. И внедрять решение мы будем только после того, как клиент готов к этому решению. Но в принципе мы используем Git, GitLab, GitHub, Jenkins и иногда Docker.

Интервьюер: Мы уже касались этого вопроса, но все же расскажи подробнее, почему вы делаете разделение специалистов по проектам/заказчикам, а не по технологиям?

TeamLead: Во-первых, так исторически сложилось. А, во-вторых, это обусловлено тем, что заказчику удобнее общаться с одним человеком, а не думать с каким инцидентом, к какому специалисту обращаться. То есть мы даем клиенту единую точку входа. А уже этот специалист разберется, кому можно передать задачу.

Интервьюер: Спасибо за интересное интервью.

TeamLead: Желаю удачи.

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