Как управлять командой, которая предоставляет сложные ИТ-услуги

Спойлер: использовать автоматизацию

Сергей Королёв, директор департамента сервисного сопровождения Rubytech, делится опытом, как успешно руководить ИТ-подразделением в постоянно меняющихся условиях, при кратном росте объёмов услуг и увеличении команды в 5 раз.

Как управлять командой, которая предоставляет сложные ИТ-услуги
Сергей Королёв
Директор департамента сервисного сопровождения Rubytech

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

Кто мы, и чем занимаемся?

Наша команда осуществляет техническую поддержку инфраструктурных решений (серверов, систем хранения данных и резервного копирования, сетевой инфраструктуры) и сопровождение ИТ-ландшафтов, построенных на базе отечественных программно-аппаратных комплексов (ПАК).

В задачи департамента входит:

  • поддержка ИТ-инфраструктуры ушедших с рынка иностранных вендоров;
  • внедрение и эксплуатация совместно с командами заказчиков новых ИТ-ландшафтов на базе оборудования и ПО российских производителей.

Еще два года тому назад рынок был жёстко регламентирован и стандартизирован: западные вендоры диктовали системным интеграторам и заказчикам, как обслуживать решения. После их ухода пришлось в спешном порядке перестраивать процессы, менять подходы, пересматривать списки контрагентов, переобучать ИТ-менеджеров и специалистов. При этом объемы работ кратно увеличились. Взяв на себя услуги поддержки оборудования и инфраструктурного ПО заказчиков без участия зарубежных вендоров, мы начали закрывать заявки 1,2 и 3 линий. Наша команда решает узкоспециализированные задачи, устраняя сложные проблемы и инциденты, разобраться с которыми еще недавно могли только производители оборудования.

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

Эти факторы не могли не отразиться на нашем подразделении. Всего за полтора года команда увеличилась больше чем в 5 раз. Поэтому нам пришлось кардинально перестраивать почти все процессы.

Заметно изменились масштабы и содержание задач. Сейчас приоритетными для нас остаются 3 тренда:

  1. Сервис без участия ушедших иностранных вендоров. Это направление успешно развивается: заручившись поддержкой экс-сотрудников российских представительств зарубежных производителей мы научились ремонтировать, устанавливать обновления и настраивать зарубежное оборудование.
  2. Сервисная поддержка программно-аппаратных комплексов (ПАК) российского производства у заказчиков. Здесь наш департамент выступает в роли связующего звена между заказчиком и техническими специалистами на стороне разработчиков.
  3. Эксплуатация ПАК в ИТ-инфраструктуре заказчиков.

В нашем департаменте работают: пресейл-эксперты, инженеры, проектов (РП) и сервис-менеджеры, архитекторы. Команда постоянно пополняется новым людьми, которых нужно обучать, развивать, адаптировать и мотивировать. Удобнее всего делать это в единой автоматизированной системе с понятным интерфейсом.

Автоматизация, без которой не обойтись

В 2024 мы каждый месяц закрываем такое же количество заявок, как за весь 2023 год. Высокие скорости требуют кардинальных изменений. При этом невозможно быстро и эффективно масштабировать команду, не меняя процессы. Вот почему основной упор было решено сделать на автоматизации. Начали с усовершенствования нашей корневой системы Service Desk. Это позволит не просто оптимизировать процесс управления заявками на техническую поддержку, но и сформировать единую базу знаний для всех сотрудников департамента.

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

Мы уже подготовили и постоянно наполняем единую базу Wiki для инженеров по эксплуатации и системных архитекторов, где публикуем все типовые задачи и выкладываем алгоритмы разрешения инцидентов и проблем. Так мы систематизируем накопленные знания, начиная с рекомендаций по проведению тестирований и преднастройки ПАК непосредственно перед интеграцией у заказчика, и, заканчивая описанием лучших практик по настройке программных компонентов ПАК. В перспективе планируем превратить нашу Wiki в единую, удобную и автоматизированную базу знаний. Вскоре «прикрутим» к ней самообучающийся модуль на базе искусственного интеллекта. Так у наших инженеров и сервис-менеджеров появится возможность осуществлять интеллектуальный поиск описаний решения различных проблем с оборудованием по базе наработанных кейсов. Если задача, с которой столкнулся инженер, ранее не решалась, искусственный интеллект предложит ознакомиться с описаниями похожих проблем.

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

Чтобы создать такой инструмент, ведущие инженеры Rubytech проанализировали все аварии, которые когда-либо происходили в инфраструктуре заказчиков; классифицировали и систематизировали их; правильным образом настроили метрики в системах мониторинга. Анализируя различные факторы, система автоматически рассчитывает вероятность возникновения аварии и в случае высокого риска сигнализирует об этом. При наступлении предаварийной ситуации уведомления автоматически поступают в Service Desk. Дежурная смена видит сигнал и, не дожидаясь аварии, начинает собирать команду из сервис-менеджеров, инженеров и (при необходимости) — архитекторов.

В новой версии платформы, на которой разработана наша система Service Desk, реализованы алгоритмы машинного обучения. В ближайшем времени мы планируем активно развивать и тестировать их.

Первые результаты

Итак, за последний год мы:

  1. Постоянно совершенствовали процесс маршрутизации запросов по различным вендорам. Отлаженные сценарии позволяют нам гораздо быстрее находить решения проблем заказчиков.
  2. Описали и систематизировали сценарии отработки инцидентов инженерами. Скорость обработки входящих заявок заметно повысилась.
  3. Сделали кейсы отчуждаемыми: теперь каждый кейс можно прикрепить к карточке проекта в Service Desk и руководствоваться им при решении вопросов заказчика.
  4. Создали понятный скрипт для диспетчера Service Desk: теперь дежурный специалист может качественно отработать инцидент своими силами.
  5. Регулярно пополняем базу скриптов, которые помогают как нам, так и заказчикам эксплуатировать новые решения.

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

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

88
Начать дискуссию