[Из песочницы] Как мы внедряли GLPI
Действие происходит в одной из стран Центральной Азии, называть страну, компанию и область ее деятельности я не буду. Надеюсь, заинтриговал. Хотя, на самом деле это несущественно. Мне хотелось бы рассказать как мы начали с пустого места и выстроили достаточно адекватную и управляемую структуру, в которой все разложено по полочкам. Так что это рассказ не столько о возможностях платформы, сколько об опыте ее использования в качестве системы управления департаментом в реальных условиях.
Компания, в которой трудится наш доблестный ИТ департамент, — дочка Корпорации, входящей в Fortune 500. В родной стране Корпорации, за тридевять земель от нас, есть решительно все: ИТ стратегия, ИТ политики-стандарты-процедуры, своя ИТ компания полного профиля, свой Tier 3 ЦОД, прямые контакты и ценовые соглашения с основными производителями ИТ оборудования и ПО, быстрые и дешевые поставщики оборудования и услуг, ловкие интеграторы, толковые консультанты по внедрению, и т.д. и т.п. — в общем, там рай. От нас ждут и требуют того же уровня, но повторюсь, мы работаем в Центральной Азии и у нас тут пока сплошная стройка.
Первое время Компания в плане ИТ обходилась услугами субподрядчиков. Я в качестве айтишника-фрилансера обслуживал офисы 2–3 их субподрядчиков. Кончилось тем, что один из моих клиентов выкупил все мое время и откомандировал меня на удаленный сайт, где они строили для Компании промышленный объект. Проработав там 3 года, я узнал, что Компания решила взять штатного координатора ИТ в стране. У меня к тому времени было уже 4 координатора от разных контор и структур Центра, так что еще одного я бы не перенес. Перешел на работу в Компанию. Инфраструктура росла очень быстро, штат Компании рос еще быстрее, а вся работа по части ИТ теперь выполнялась контракторами. Помимо ИТ контракторов, у меня появились подчиненные, со временем нас выделили в отдел, которым я теперь руковожу.
К чему я все это рассказываю и причем тут GLPI? Я просто люблю рассказывать истории с подробностями. Можете спокойно пропустить пару абзацев.
Нашим первым контрактором по техподдержке был филиал британской ИТ компании. Буду называть их британцами. У них был откатанный на многих клиентах по всему миру хелпдеск, под них написанный софт, обученные операторы, дисциплинированные инженеры и строгие правила в отношении оформления заявок.
Вторым контрактором оказалась местная компания, неожиданно выигравшая тендер демпинговыми ценами. Они пусть будут временщики — без обид, они знали что подписываются на короткий промежуточный период в надежде проявить себя и без особых шансов выиграть следующий долговременный контракт. В технических условиях контракта требовалось наличие системы регистрации заявок, соответственно, компания купила какой-то недорогой софт, посадила девочку со знанием английского языка, набрала техников и инженеров — и, несмотря на апокалиптические прогнозы британцев, мы без особых потрясений пережили сначала 3 месяца контракта, а потом и 6 месяцев продления.
Все очень старались. Работы было много: пока временщики отбивались от рутины, мы, то есть немногочисленный собственный ИТ персонал компании, координировали работы по обустройству нового офиса (4 этажа, около 2 тыс кв.м., около 400 рабочих мест) и с минимальным даунтаймом для основного бизнеса переехали и продолжили работу на новом месте. На самом деле, было не до хелпдеска, так что я даже не помню что у них там стояло и как оно работало. Особых проблем с техподдержкой тоже не припоминаю. А про глобальные проблемы мы и так не забывали…
И вот пришел третий — нынешний — контрактор. К этому времени нам уже поднадоело объяснять новой команде что и как у нас устроено и как все это должно работать, но что было делать — у нас есть только финальный отчет прежнего контрактора, разрозненная документация по системе и мы только на словах можем описать рабочие процессы. Вот бы всегда иметь эту информацию под рукой и не повторять от раза к разу новым людям. И даже просто база данных хелпдеска — это кладезь информации, причем информации о нас. И ноу-хау, причем наши ноу-хау. И почему мы не храним эту информацию у себя?
Контракт предстоял длинный — на 5 лет — так что новые ребята были полны решимости все делать правильно и основательно. И, конечно же, лучше предшественников. Хотя они тоже были, что называется, first-timer’ы. Но хелпдеск они заявили особо еще на этапе тендера и хотели даже развивать его как коммерческую услугу. Благодаря им, кстати, хелпдеск при промышленном объекте у нас стал стал работать в режиме 24×7.
Среди прочего, завязалась дискуссия о выборе платформы хелпдеска. Британцы свой хелпдеск забрали. Хелпдеск временщиков даже не рассматривался. Естественно, я запросил у головного офиса информацию по поводу их хелпдеска. Выяснилось, что они используют CA Service Desk Manager от CA Technologies, их лицензия на нас никак не транслируется, внедрять хелпдеск у нас в обозримом будущем никто не собирается. И вообще, у них масштабная реорганизация. Но по крайней мере, мы теперь знаем чего хотим! Так что совершаем звонок монопольному продавцу софта в стране. Тут начинается, как обычно: что именно вам нужно, где техзадание, почему именно это… Ну, почитали описания продуктов на сайте CA, составили wish list. Через какое-то время получаем коммерческое предложение — там было столько нулей, что продавцы несколько раз перепроверяли их количество со своим поставщиком. И это только за лицензию, сказали они, а что будет стоить внедрение и кто будет внедрять — неизвестно. Обычно, сказали они, лицензия составляет ¼ часть от общей стоимости проекта —, но тут вообще сложно что-то обещать. Ну, стало быть, не судьба… А время-то ушло. А операторы-то пишут тикеты в Экселе.
Лезу в Гугл. Узнаю про GLPI. Ставлю на свободную машину — работает, ну нифига себе! Показываю новым контракторам… Вот за что я не люблю инженеров, так это за то, что они во всем видят проблемы и не способны разделить радость коллеги. Конечно же, мой GLPI какой-то левый, а вот они нашли систему — так это система. Правда, платная, но мы ж по-любому готовы были купить CA? Зато она может то, се, пятое и десятое. А мне-то уже обидно, это что же я, зря ставил GLPI? К тому же было не столько жалко денег, сколько не хотелось связываться с нудной системой согласований и закупки через тендер. А GLPI уже стоит и работает. Почитал, поковырялся в настройках — оказывается, GLPI может это все + прикрутил инвентаризацию, которая мне тоже была очень нужна. Инженеры пошли читать про свой софт и, конечно же, обнаружилось, что легко можно докупить инвентарный модуль. В общем, я выиграл. Пока они искали дополнительные контр-аргументы, я научил операторов пользоваться GLPI и со временем они перестали даже (по крайней мере, при мне) параллельно записывать заявки в Эксель. Но все равно, сначала все заявки аккуратно записывали на бумагу.
В общем, в течение примерно 2 лет у нас работала связка GLPI+OCS. Все это время системой пользовались только операторы хелпдеска — регистрировали заявки в режиме 24×7, эпизодически — главный инженер контракторов, потому что тоже считал такой подход правильным, ну и я. За это время я успел перенести сервера OCS+GLPI на виртуальную машину с переходом на новую версию и Ubuntu и OCS и GLPI. OCS постепенно расставлял агентов через GPO, а я использовал административный ресурс, заставляя техников вносить бухгалтерские инвентарные номера в OCS и GLPI. Помимо этого, я настоял на том, чтобы содержимое складов было внесено в базу GLPI. Таким образом, мы получили связку пользователь/местоположение-серийный номер-бухгалтерский инвентарный список.
Пользуясь плагином File Injection я списком добавил в GLPI рации, радиостанции и остальное барахло строгой отчетности. Прямо в радиостанции добавил сканы разрешений, лицензии, анкеты и письма. Я принципиально не стал вносить изменений в структуры данных и просто сунул все в категорию Devices. Лицензии и разрешения со сроками действия я оформил как контракты — и получил готовые плановые уведомления об истечении сроков действия таких документов. Удобно, но никому кроме меня это было не нужно. У них всегда можно спросить и они ответят. Вот только надо помнить кого о чем спрашивать.
Система здорово выручила во время проверки, устроенной головным ИТ. Это был чуть ли не первый случай, когда наши тикеты кто-то заинтересованно почитал, затребовал выборки по критериям, посмотрел статистику закрытия заявок, выборочно проверил как работает связка юзер-тэг-серийник. По этой части никаких претензий не было.
Пройдя проверку, я расслабился, так что какое-то время в этой области ничего существенного не происходило.
Самое интересное началось, когда Компания внезапно решила нанять напрямую почти весь персонал контрактора — нужно было срочно улучшить статистику по национализации Компании в рамках соглашения с правительством. ИТ отдел внезапно разросся в разы, сломался привычный уклад при котором собственные ИТ техники Компании осуществлял общее руководство персоналом контрактора, теперь все оказались в равном положении. Неминуемо появились терки по поводу неравномерного рераспределения обязанностей между ветеранами и новым персоналом, персоналом Компании и старшими инженерами контрактора, которые к нам не перешли. Образовались новые центры силы, сформировалась оппозиция. Раньше чуть что — можно было пойти и предъявить претензию контрактору и их руководство быстро решало вопросы, вплоть до замены персонала. А теперь я за них отвечаю.
Ввели ротацию персонала внутри команды. Решались 2 задачи: 1) взаимозаменяемость внутри команды, 2) нехватка специалистов на удаленных объектах. Тут бы очень помог общий календарь или расписание дежурств, но ничего такого в GLPI или для GLPI я не нашел.
Внутри команды расписали обязанности. Список обязанностей у нас складывался постепенно. Я уже упомянул ротацию, так вот, мы постарались чтобы каждая роль (или обязанность) исполнялась по крайней мере двумя людьми в разных сменах, так чтобы они меняли друг друга. Обязанности можно отразить в системе либо через группы техников, либо через entities (мы пользуемся английским интерфесом, я не знаю как это слово переведено в русской версии) — это что-то типа OU, организационной единицы в активной директории.
Наша работа состоит из неизбежной рутины и интересных проектов. Рутины должно быть как можно меньше, а проектов — чем больше, тем лучше. Часть проектов предложил я исходя из потребностей конторы, часть народ выдвинул сам. Договорились, что проекты и необходимые ресурсы (время, люди, материалы, деньги, …) будут согласовываться со мной заранее. Не хочешь заниматься рутиной — бери нужные мне проекты. Нет проектов — занимайся рутиной. Для разделения времени между занятием рутиной и выполнением проектов или планового тех обслуживания задействовали планирование GLPI. Теперь в календаре видно, кто в данное время занят. Для контроля исполнения проектов в GLPI нашелся простой, но симпатичный плагин для проектов с отрисовкой диаграм Ганта. На проект можно навесить массу системных объектов. Мы только начинаем вписывать проекты в GLPI — и, опять-таки, это пока нужно только мне, потому что народу много, проектов много, а склероз прогрессирует.
Чтобы добиться справедливого распределения заявок, собрали команду в одном месте: до этого техники были распределены по разным офисным блокам. При этом слегка потеряли во времени реагирования на заявки, но добились-таки своего. Договорились, что все заявки и задания раздаются через хелпдеск — так никому не было обидно. Установили простую очередь при назначении заявок свободным техникам. Проанализировали данные по количеству отработанных заявок за единицу времени — появились аргументы для серьезного разговора с некоторыми техниками. И, наконец-то, удалось заставить техников регистрировать все заявки. Не удалось пока заставить их закрывать заявки самостоятельно: это продолжает делать хелпдеск. В свою очередь, хелпдеску объяснили, что теперь не получится записывать заявки на листочек и вносить их в систему в конце смены — иначе совпадет время открытия и закрытия заявки. Хелпдеск вообще у нас — молодцы. Стоило только показать им как можно использовать шаблоны для автоматизации и стандартизации наиболее частых заявок — и они стали самыми благодарными адептами GLPI и лучшими помощниками в дальнейшем развитии системы. Как мне кажется, с минимальными подсказками системы операторы стали чувствовать себя гораздо уверенней. Я планирую использовать высвободившееся у хелпдеска время на присмотр за NMS, на удаленную поддержку, да на что угодно: мне нужно вывести их из-под риска сокращения персонала в кризис, чтоб даже мысли такой у начальства не возникало…
Заявок, кстати, стало больше. И оформлены они стали гораздо лучше. Если раньше раньше заявка выглядела примерно так: что-то случилось у пользователя такого-то — заявка открыта/заявка закрыта, то теперь для доброй половины заявок достаточно выбрать категорию заявки и из шаблона заполняются нужные поля, заявка назначается определенному технику либо группе техников в соответствии с их специализацией, в описании появляется подсказка для оператора. Это может быть типовое описание проблемы, ссылка на документ в базе знаний, список информации, которую необходимо уточнить у пользователя, порядок действий оператора — все, что угодно. Я даже не знаю, стоит ли выдавать все наши блестящие идеи безвозмездно. С одной стороны очень хочется похвастаться, а с другой закрадываются мысли о монетизации… Впрочем, как выясняется, рынок услуг еще уже, чем нам представлялось совсем недавно, ниже расскажу почему.
Благодаря наглядной демонстрации на примерах из заявок народ понял, зачем нужен SLA, как осуществляется эскалация и все это автоматом через категории и шаблоны заявок. А у меня теперь есть живой и работающий список SLA, то есть мной установленных нормативов выполнения определенных работ.
Business rules мы пока не осилили — смысл ясен, функционал нужен, но пока не проходят критерии так, как мы хотим. Не страшно, разберемся.
Нарисовали карту сети в плагине Network architecture. Красиво. Центру иногда хочется зачем-то знать с точностью до порта что куда подключено. Мне однозначно нужно, чтоб такая карта была, чтоб она лежала в определенном месте и была доступна отовсюду (доступ мы, естественно, контролируем). Для Центра, для презентаций, для взаимодействия команд, для полноты охвата системы, и просто на всякий случай. А так у наших сетевиков есть карты в Visio, в Cisco Prime —, но это надо у кого-то запрашивать, ждать пока ответят, а вы же знаете этих инженеров — от них сплошной негатив.
Бюджет — можно расписать бюджет вплоть до стоимости отдельных единиц оборудования или материалов или услуг. С привязкой финансовой информации к оборудованию и контрактам. Как по мне, так у нас очень сложный бюджетный цикл. Примерно каждые 2 месяца разные инстанции требуют отчетов с разной степенью детализации. Я обязательно распишу в деталях свой бюджет на следующий год в GLPI. Пока там только 2 статьи: CAPEX и OPEX.
Контакты — сюда я вписал все телефоны/адреса, на поиск которых раньше уходило время. Вплоть до ресторанов, где мы иногда заказываем еду с доставкой. Народ всегда улыбается, но по сути мы экономим время и облегчаем себе жизнь.
Контракты — тут все ясно. Любая информация о контрактах. С напоминаниями об истечении. С привязкой к оборудованию — я уже упоминал, что использую эту категорию для лицензий на эксплуатацию радиооборудования, разрешений на ввоз и т, д.
Кажется, ничего из применяемых нами функций не забыл.
Суммируя наш опыт, — Система управления видимо все-таки не нужна технику/инженеру. Им категорически не хочется делиться знаниями, а тем более выкладывать информацию в письменном виде. Даже если кто-то вдруг поделился — зачем вообще нужна база знаний, если он и так все знает, а если не знает, то это проблема начальства, а если вдруг захочется разобраться — спросит Гугл. Учет заявок тоже не нужен, в любом случае он перерабатывает, а остальные недорабатывают и пусть начальство разбирается.
Только регламенты, только инструкции, только контроль —, а они у меня в разной форме размещены в GLPI. Мне кажется правильным для руководства держать открытой обратную связь, придерживаться здравого смысла, быть предсказуемым и соблюдать справедливость —, но это не обязательно. Главное помнить кто что обещал —, а это опять-таки можно зафиксировать в GLPI.
Система управления не нужна была мне как руководителю департамента, пока основной объем работ выполнял аутсорс. Аутсорс всегда можно поставить в зависимое положение. При необходимости сменить поставщика услуг, конечно же, возникают проблемы, но при наличии финансовых рычагов давления это несущественно.
Имея же систему, мы владеем информацией, при смене контрактора мы ничего не забудем выяснить у бывшего и очень быстро введем в курс дел нового.
Система управления нужна руководителю в том случае, когда свалить ответственность не на кого. В корпоративной среде очень важно на любой «вызов» отреагировать оперативно и аргументированно, а «вызов» могут «бросить» самым неожиданным образом. Это может быть просто требование очередного отчета из центра, а может быть и приглашение в прокуратуру. То есть лучше быть готовым. И коллеги это понимают. Но когда я попытался во время подходящего по теме обсуждения «продать» свое решение своим аналогам в других странах, мне сказали, типа: «Да, прикольно… у нас есть что-то вроде… Но это же freeware или opensource? Его же нельзя использовать в среде enterprise? Все должно быть строго enterprise-grade. Ты на всякий случай GLPI аудиторам не показывай.» А я так на него рассчитывал при прохождении аудита! Главное, это прозвучало из уст «бирманца», который только с месяц назад сам отправил длинное открытое письмо про то, что в условиях мирового кризиса надо переосмыслить корпоративные стандарты, искать новые пути и вообще «think outside the box»…
То есть, казалось бы, вот оно — нашел я GLPI целевую аудиторию, своим уже сказал, что в Бруней поедем GLPI ставить, но и тут засада — если, конечно, мне не подскажут чем ответить на это «вызов»… Поэтому я и сказал, что рынок для GLPI уже, чем мы ожидали. Хотя я лично не вижу никаких нарушений GPL2/GNU, мы даже ничего не меняем в коде — это если озабоченность вызвана типом лицензии.
Что бы ни решил Центр в отношении допустимости использования GLPI в нащей Компании, я буду и впредь использовать автоматизированную систему управления. По крайней мере, я теперь точно знаю что мне нужно от системы, вся необходимая информация собрана, связана и готова к экспорту. Посоветую ли я GLPI другу? Ответ однозначно положительный. GLPI вполне может быть как окончательным так и временным или промежуточным решением. Бесплатным, что должно быть немаловажно в условиях кризиса.
Мне показалось глупым помещать благодарности в начале статьи, но, по-хорошему, с этого нужно было начать. Раз я решил не разглашать информацию о компании, то и имен членов команды вы не узнаете. Я искренне благодарен всем, кто участвовал на всех этапах работы. Без вас ничего бы не произошло.
И вам спасибо за внимание.
