От хаоса к системе: как повысить зрелость IT-службы вашей компании? (заключение)

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

Всем привет! На связи генеральный директор компании ALP ITSM Дмитрий Бессольцев.

Будем подводить итог последних публикаций:

А сегодня будем разбираться, как внедрить управление изменениями и создать работающий SLA-договор, а также реализовать управление регламентными работами.

Наведение порядка с регламентными работами IT-руководитель начинает или после внедрения «управления инцидентами», или после «управления проблемами». Если в компании накопился «технический долг», которые провоцирует сбои – проблемами нужно заняться в первую очередь. Кроме, пожалуй, резервного копирования – его надо внедрить или починить максимально быстро. Приоритеты расставляет IT-руководитель.

Регламентные работы похожи на регулярное ТО для автомобиля. Они не устраняют сбои или причины, а позволяют не довести до них. В регламентные работы входят: антивирусная защита, резервное копирование, установка обновлений, мониторинг. Резервное копирование – приоритет номер 1. Антивирусная защита – приоритет 1,5. Остальное потом.

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

Допустим, сервер «падает». У компании есть резервные копии, но нет дополнительного сервера, куда можно восстановить данные. Это нужно предусмотреть заранее. Например, заключить контракт с каким-нибудь облачным провайдером, чтобы в случае форс-мажора быстро развернуть у него IT-инфраструктуру. Это частный случай, но он показывает, насколько важно грамотное планирование процесса.

Один из важнейших факторов – оценка объема данных. От этого зависит продолжительность их копирования и размер необходимого дискового или облачного пространства.

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

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

Например, топ-менеджер говорит: наш склад должен работать всегда. Окей, но это будет стоить миллион рублей, поскольку для обеспечения бесперебойной работы понадобится как минимум дополнительный сервер (впрочем, он все равно не гарантирует 100% доступность).

Как правило, оказывается, что простои в работе допустимы. И, например, система, которая «поднимается» за час из резервной копии, обойдется в два раза дешевле. А если допускается простой в три часа – то в 5 раз дешевле, и т.д. Владелец бюджета должен определить, какой вариант будет для него оптимальным.

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

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

Регламент должен содержать следующие моменты:

Последний пункт незрелые ИТ-службы часто игнорируют. Но это ошибка: копии могут делаться, но по разным причинам быть неконсистентными, т.е. из них ничего нельзя будет восстановить. Тестовое восстановление (выборочное) на 90% поможет избежать этой проблемы.

Хорошая практика – сделать автозадания в ServiceDesk-системе, чтобы у ответственного сотрудника в назначенное время появлялась задача по проверке системы резервного копирования. Создание таких «напоминалок» не даст забыть о выполнении тех или иных регламентных заданий.

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

Главная ответственность IT-руководителя – не пустить этот процесс на самотек. Даже при наличии системы эффективного антивируса действия незрелой IT-службы могут привести к тому, что защита со временем «развалится». Чтобы этого не произошло, нужно также разработать регламент, назначить отвечающего за антивирус специалиста и прописать его действия.

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

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

Не самый сложный, но тоже важный процесс. IT-служба должна позаботиться о том, чтобы плановое обновление программ и компонентов было не реже, чем раз в месяц (а критичных – чаще).

Критичные обновления лучше устанавливать не в первый день, а после «периода охлаждения» – от 2-х до 5-ти дней. Бывает, что апдейты выпускаются вендором в спешке, плохо тестируются и «роняют» серверы. За несколько дней можно узнать, что пишут про эти обновления в IT-СМИ, на том же Habr. Если с апдейтом проблем нет, то его можно устанавливать.

Чаще всего установку обновлений планируют в конце недели. Например, в пятницу вечером, чтобы не мешать рабочему процессу компании. Мы, айтишники, не в восторге от такого вечера пятницы (а потенциально и ночи с пятницы на субботу!) – но что делать.

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

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

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

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

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

Перенесли сервер 1С в облако, но он оказался доступен только половине пользователей (остальным забыли выслать новые ярлыки). Или построили отказоустойчивый кластер, перенесли на него сервис, а он стал работать медленнее. А если тормозит IT-система, то будет тормозить и производственный процесс, и бизнес в целом.

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

Но стоит один раз серьезно ошибиться в управлении изменениями, и работа компании может приостановиться на несколько часов и даже дней, что может быть критично для бизнеса. Как же лучше действовать?

Что касается подхода к написанию регламента для управления изменениями, то он абсолютно такой же, как и в остальных процессах. Важно сообщить сотрудникам компании обо всех планируемых изменениях и зарегистрировать их в системе ServiceDesk.

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

Важный шаг – создание и подписание SLA (Service Level Agreement) – соглашения об уровне сервиса между IT-подразделением и бизнесом. Такие документы чаще всего подписывают внешние IT-команды и компании-заказчики. Однако считаю отличной практикой заключение подобного соглашения между штатной IT-службой и бизнесом.

За свою практику я видел разные соглашения об уровне сервиса: и простые на листе А4, и огромные на 50-100 листах у крупных компаний уровня нефтянки. При этом свою эффективность показывали скорее лаконичные SLA-соглашения. Ведь главное, чтобы они были составлены понятно и грамотно. Были попроще, но работали.

SLA будет исполняться в том случае, если документ:

В соглашении можно закрепить следующие моменты:

Например, систему контроля и управления доступом (СКУД) и пожарную сигнализацию часто передают на аутсорсинг. Это нужно зафиксировать в SLA, чтобы к айтишникам не возникало лишних вопросов. Как вариант, IT-служба может принимать заявки в качестве «единого окна» и отправлять их подрядчику.

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

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

Например, если IT-служба (в зависимости от своих возможностей и состояния IT-инфраструктуры) способна закрывать 80-90% обращений в установленный период, то можно сказать, что она работает хорошо. Этот процент также прописывается в SLA. Кроме того, заявкам назначаются приоритеты (низкий, средний или высокий) в зависимости от влияния инцидента на бизнес.

Параметры качества можно измерять следующими метриками.

На практике базово достаточно вести 2 метрики: время реакции на заявку и время ее решения.

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

Именно поэтому подписывать SLA на начальных этапах сотрудничества не стоит. Грамотнее будет понаблюдать некоторое время за работой выстроенных процессов – например, в течение 3-6 месяцев. После этого периода нужно собрать статистику и посмотреть, каковы фактические возможности IT-службы.

Часто бывает так, что бизнес говорит примерно следующее: «Мне надо, чтобы любая задача решалась за пять минут». Идея, конечно, классная. Но можно ли реализовать ее на практике? Скорее всего, нет, и статистика это подтвердит.

Важная роль SLA – синхронизировать ожидания бизнеса с возможностями IT-службы, закрепив это «на бумаге». При этом SLA можно и нужно корректировать с учетом актуальных изменений. Например, когда компания поменяет парк техники, которая тормозила работу сотрудников, то SLA можно ужесточить, учитывая новые технические возможности.

Важно контролировать качество работы IT-службы, поскольку неизменяемый процесс – это мертвый процесс, который в определенный момент перестает соответствовать реалиям бизнеса и IT. Хороший инструмент здесь – встречи по обсуждению уровня сервиса, или Service Review.

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

Также важен фидбек пользователей – насколько они удовлетворены качеством службы поддержки. Проще всего делать опросы пользователей с предложением оценить работу IT по шкале от 1 до 5 по нескольким параметрам – например, скорость, качество, вежливость.

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

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