брутальный ITIL

  Не стану вдаваться в описание всех красивостей и полезностей ITIL для среднестатистической службы IT, отдельно взятого it-директора или простого сисадмина, не буду вставлять и большие копипасты с wikipedia и прочих крайне популярных ресурсов, хотя без этого тоже не обойдется. А попытаюсь рассказать о практике внедрения iTIL в отдельно взятой компании, которая по мере своего роста пришла к нему. Так же напомню, всем джедаям, которые особо увлекаются чтением стандартов, но не практикой внедрения, что таких компаний большинство и опыт внедрения ITIL в компании в 20.000 человек, пригодится только 1%,  а опыт внедрения в компании с числом около 1.000 сотрудников будет интересен многим.

    Итак, черный ящик открывается и из него появляется великий и ужасный ITIL, встречайте!

ITIL (произносится как «айти́л», IT Infrastructure Library — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

    Честно говоря не лучшее определение, но для начала сойдет. Да действительно это набор библиотек, которые рекомендуют нам best practices. ITIL не единственна в своем роде. Существует еще много различных документов, продумывающих работу IT службы, от того же cobit и до метода сисадмина Васи Пупкина, организовавшего работу в своей организации в соответствии со своими лучшими практиками и видением мира.

Мой выбор остановился на ITIL, и объяснять ее преимущества и недостатки я не стану, потому как они есть везде, а их обсасывание является пустейшей тратой времени, не ведущей не к чему.

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

А вот и мои исходные данные. Компания, в которой я работаю и где на мою долю выпало внедрение ITIL, в полном его объеме, состоит из примерко 1500 сотрудников, 50 % из них является активными пользователями. IT инфраструктура включает в себя 3 домена и неисчислимое множетсво маленьких, но очень гордых филиалов и филиальчиков, разбросанных на растоянии до 300 км. друг от друга (не так уж и много)). С точки зрения айтишника, бизнес-процессы компании выглядят зрелыми и довольно отработанными.

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

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

Таким вот инструментом и оказался ITIL вкупе с программными средствами.

    Итак попытаюсь разобрать по пунктам разделы ITIL. оговорюсь сразу - т.к. это только лучшие практики и руководство к действию, но никак не инструкция по применению, внедряем ITIL v.2 c вкраплениями в него ITIL v.3 и, местами, своих личных заморочек. Все недовольные и пытающиеся бросать в меня тапком - идут лесом и ищут правды в других местах. Здесь представлен только краткий обзор, подробнее о каждом пунтке в отдельности и серьезно - позже.

 Ну, что ж, пошли по порядку

Поддержка услуг (Service Support)- один из самых простых во внедрении, но самых неприятых в ежедневной работе моментов. Включает в себя процесс упарвления инциндентами - собственно, это есть в любом отделе IT и рассматривается, как его главная задача - появилась проблема - решили ее - ждем следующей)) формы могут быть разные от продвинутого helpdesk cо штатными сотрудниками оного, до эникейщика-студента, приходящего три раза в неделю и решающего проблемы. Суть не в этом, а в том, что среднестатистический отдел IT на этом и заканчивает. ITIL же писали грамотныю люди, придумавшие наличие в оном слудющего пункта поддержки услуг - процесс управление проблемами, куда более мощная вещь, и присутствует она обычно только в крупном helpdesk. Управление проблемами заключается в анализе инциндентов и вычленении из них проблем. Ведь как бывает, сервер упал, его подняли и ждут следующего падения, несмотря на то, что это уже пятое падение за два месяца, устранено следствие, а не проблема, которая все еще ждет своего звездного часа. Не менее полезной вещью становится и следующий пункт - процесс управление конфигурациями. Многие знаю Nagios, мониторят им сервера и акативное сетевое оборудование. А как вам идея глобального активного мониторинга всей сети, всех серверов и рабочих станций, всего ПО и всех лицензий, пользователей, доменной структуры собранных в одном месте? Согласитесь, привлекательно? Еще бы! А ITIL от нас требует этого напрямую и неукоснительно, здесь и сейчас. А чтоб закрепить дисциплину просит еще воспользоваться и процессом управления изменениями, который позволит стандартизировать внесение изменений в IT-инфраструктуру, и сделает этот процесс менее болезненным. Добавление нового филиала, отдела, сервера, не всегда приятная и развлекательная процедура, чаще это поиск резервов, места куда же воткнуть, так, чтоб не отвалилось завтра же.  Грамотное планирование, основанное на анализе и сборе статистических данных, таки позволяют решить этот вопрос. Ну и завершает Поддержку услуг процесс управления релизми. Это полезно. Чтобы доказать это сразу и без всяких доказательств, спрошу у Вас - сколько версий одного ПО использует ваша компания, как часто Вы не можете понять, почему здесь стоит не то оборудовани, которое Вы представляли? Когда мы провели полную инвентаризацию, оказалось, что было до 9 разных версий одного ПО. Очень, кстати, неприятно для службы поддержки.

   Идем дальше, перед поддержкой услуг нам нужно их предоставить,  поэтому ITIL включает  Предоставление услуг (Service Delivery). А он включает в себя не менее интересные подпункты.

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

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

 Процесс управления непрерывностью, так же входящее в предоставление услуг, является ключевым моментом, который нужно измерять, так чтобы не быть виноватым. во всех смертных грехах IT. Составление грамотного SLA и каталога услуг, помогут нам (но об этом позже). Управление непрерывностью - по сути, ключ к успеху IT. Если Вы сможете всегда обосновать что все ваше оборудование, все сервисы работыли в штатном режиме, т.е. не нарушая SLA, Вам не страшен никто.

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

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

Управление приложениями ( Application Management) является крайне полезным инструментом в управлении ИТ, если Вы хотите действительно делать все хорошо. Основная мысль заключается в том, чтоб процесс внедрения приложения с момента его разработки и до окончания эксплуатации находился под полным контролем и управлением. Обычно ведь как получается, планирование сервиса или программного продукта это одно, его разработка и ввод в эксплуатацию совсем другое, ну а дальнейшее сопровождение третье. Комплексно на весь жизненный цикл приложения никто не смотрит. А зря. Согласованность между ТЗ, разработчиком и службой поддержки крайне полезная вещь, особенно, когда устранить главные проблемы получается на момент проектирования, а не в ходе эксплуатации. Ну а у инженера техподдержки, поверьте, практического опыта работы с программными обеспечением и в особенности с пользователями ит-сервисов гораздо больше чем у любого менеджера проекта или разработчика. Так что, основная мысль сведена к глобальному и всестороннему участию все, кто будет как-либо использовать сервис к привлечению обменом опытом и мнениями.

  Еще одним достойным внимания элементом ITIL является управление безопасностью. Здесь впринципе все ясно, и интерес она состовляет в основном для сотрудников подразделений информационной безопасности, которые обычно несколько абстрагированы от ит-подразделения.

Такие элемента ITIL как Управление инфраструктурой информационно-коммуникационных технологий (ICT Infrastructure Management) и Бизнес-перспектива (The Business Perspective) особого внимания к себе не привлекают, т.к. их элементы, в необходимом для среднестатистической компании объеме, присутствуют в предыдущих разделах.

Вот так в общем, можно описать ITIL v.2 которого по моему скромному мнению хватит для нужд практически любой компании, и нужды во внедрении ITIL v.3 я откровенно не вижу. Еще раз повторю основную мысль вложенную мной во внедрение данного процессного подхода - ITIL этот только каркас, сам же инструмент управления ИТ Вам придется создавать самостоятельно. Если Вы, конечно, хотите разбираться в вопросе полностью, а не быть от кого-то зависимым.