Зачем ITIL обычному среднестатистическому администратору (10-500 ПК)

Привет. Сразу скажу, что тема применима не только к администраторам, но и к фрилансерам, аутсорсерам.
Прошёл на днях тренинг «HF421S, ITIL Foundation for IT Service Managment», под впечатлением несу Прометеев огонь в массы.
Надеюсь, большинство знает, что такое ITIL, для остальных выдержка из вики:
ITIL (произносится как «айти́л», англ. — библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Бытует мнение, что ITIL это серьёзно, сложно и запутано, необходимо только очень большим компаниям, а большинство справляется со всем «на коленке», держит в памяти, и это нормально и удобно.
Отнюдь.
Следование принципам ITIL помогает в первую очередь администратору компании любого размера работать спокойно, стабильно, спланировано. Это просто.

Библиотеки ITIL — это как делали в других компаниях ИТ лучше всего. Верно и обратное: можно делать ИТ наилучшим образом, используя рекомендации ITIL.
Примечательно, что ИТ везде одинаковые, значит все в разной мере используют ITIL, часто не зная о его существовании.
По сути, если администратор работает не ногами, а головой, он шаг за шагом прийдёт к тому, что описано в ITIL по тем вопросам, которые его волнуют.
У меня именно так и получилось.
Разница между следованием рекомендациям и самостоятельными изобретениям состоит в стоимости полученного опыта (количество ошибочных экспериментов, потраченного времени и денег).
К тому же о многих процессах и решениях не задумываешься, потому что не возникает необходимости (инцидентов, требований) их моделирования.
Со своего опыта я выделил несколько основных примеров популярных проблем администрирования в небольших компаниях:
  1. Работа с инцидентами и заявками пользователей обычно занимает большую часть рабочего времени, наименее результативна (время/задачи), убивает любое планирование и приносит хаос.
  2. Изменения (обновление, установка) в ИТ-инфраструктуре влекут за собой падение всего, и победоносное решение новоиспечённых проблем неоцененными никем ночными сменами администратора.
  3. Смена администратора (часто одного единственного) приводит к новым расходам и простоям в работе ИТ, так как новый админ ничего не знает, всё ищет, переделывает чужие неудобные костыли на свои любимые костыли, и тоже не напишет документацию.
  4. Риски обсуждаются довольно абстрактно, «а вдруг», «авось», «ну я же говорил», «ну сейчас же работает», «нам не нужно супер, лишь бы работало» — основные теги таких рассуждений.
  5. Процедуры резервного копирования и восстановления подлежат обсуждению максимум в течении месяца после серьёзного сбоя, аж пока шеф не увидит счёт для покупки SOHO-коллайдера.
  6. и т.д. администраторы действуют с душой, на совесть, лучше всех, но почему-то так и не могут наладить качественную работу и обслуживание сервисов и всё больше ненавидят людей.

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

Итак. Всё-таки зачем ITIL обычному среднестатистическому администратору (10-500 ПК)?
В ITIL коротко и понятно описаны принципы, следование которым поможет облегчить ваш труд и наладить желаемую работу ИТ в компании.
Варианты для вышеописанных примеров:
  1. Простой работающий Service Desk поможет решить проблемы с инцидентами и сроками их решения. Анализ инцидентов даст понимание узких мест, которые обычно в рамках небольших компаний решаются довольно легко.
  2. Использование Change Management'a позволит избавиться от многих проблем из-за банальных ошибок по глупости, из-за невнимательности или незнания.
  3. Документирование инфраструктуры не так страшно, как кажется на первый взгляд. Поддержание актуальности документов в рамках Change Management'a требует не много усилий и экономит массу времени.
    А ведение внутренней базы знаний на самом простом wiki-движке сэкономит время при решении проблем, или даже предоставит отличную возможность самообслуживания для пользователей.
  4. Понимание рисков и их правильная оценка помогают определить критичные сервисы, оптимизировать инфраструктуру, найти и устранить ошибки и т.д., в итоге избавиться от головной боли через аргументированное привлечение финансирования, или же полную передачу ответственности на высшее руководство.
  5. Резервное копирование может стать простой автоматизированной процедурой, ведь у вас уже всё расписано, распланировано, определены риски, минимизированы случайные поломки, а руководство выделило деньги, потому что уже оценило рентабельность данной операции и выделило необходимые средства.
  6. и т.д. администраторы работают спокойно в запланированные часы, сервисы в вечном апптайме, заказчик/работодатель доволен и соглашается на повышение оплаты труда, освобождаются ресурсы, привлекаются новые клиенты, наконец-то можно заняться собственным бизнесом, а не рутиной и найти время сходить в магазин за новым бентли.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 27

    0
    Ни в коем случае не осуждаю, но я и без знания ITIL следую таким принципам, есть вещи которые приходят с опытом, а есть в ITIL и определенные глупости, которые в России не применимы на практике. Проще говоря ему не нужно слепо следовать, но знать его «большая честь».
      +2
      Видите ли, я тоже был уверен, что всё делаю правильно, всё знаю и т.д.
      Практика показала обратное. Хотя мне есть чем похвастаться из своего опыта.
      +1
      У меня ITIL связанно забавное предсказание преподавателя читавшего курсы — «50% слушателей в течение полугода меняют место работы, дабы раскрыть весь свой потенциал с учётом свежеполученных здесь знаний». Я действительно поменял в срок менее полугода)
        +2
        В итоге компании на 10-500 ПК остаются без ITIL? :)
          0
          смена работы — это амбиции. реализовать их получилось в итоге?
            0
            Да, ушёл на должность зама.по информационным технологиям, а через год открыл своё ооо.
              0
              ооо — услуги саппорта и внедрение?
                0
                да
                  0
                  и как?
                  открыть ооо — это формальность на самом деле.
                  каков итог?
          0
          Отличная статья. Только исправьте «прийдёт»
            0
            ITIL — сборник bast practices, т.е чужого опыта. Не использовать его значит наступать на грабли самому. Не самый здравый подход. Это не догма, и не руководство к действию. Это сборник рассказов о том, что вообше бывает. Хорошо описали.
              +1
              ITIL устарел и зачастую больше вредит. Не все сразу, но большие части. Бизнес слишком быстро развивается и много требует, взгляд на него кардинально поменялся за 20 лет.
              DevOps — вот будущее.

                +1
                Возьмем, например, change management, чтобы не быть голословным.
                Нужно изменить конфигурацию сервера, ввести новый сервис, новую фичу — нужен план, его необходимо утвердить, применить, обновить документацию и прочие бюрократические штуки.
                Разработчики у нас релизятся несколько раз в день. Чтобы поддержать только документацию в актуальном состоянии — нужна прорва времени. Еще время на утверждение, внедрение, тестирование и прочее.

                Времени нет совсем. Если мы будем тратить его на бюрократию, конкуренты нас сомнут и съедят.

                Есть система автодеплоя, инструкции которой и служат собственно документацией, а разработка и эксплуатация работает в таких экосистемах, где все автотестится и автодеплоится. Каждый разработчик немного админ и осознает, что он кодит и как это повлияет на экосистему. Каждый админ осознает, как работает этот код и что будет с экосистемой после релиза. Все автоматизировано. Это работает.
                  0
                  backup — ну, он не нужен. Точнее он почти не нужен, весь код децентрализован и хранится распределенно в системе контроля версии. Исходные данные тоже нужно бекапить. И все ))
                  Упала виртуалка, две, три, сервер, второй, третий. Это неважно. Деплой запускается быстро на других нодах. Нет ноды — он полетит в коммерческое облако. Данные избыточны и легко восстановимы. Вместо 300 единиц всего мы бекапим только две и самое важное там.
                    +4
                    Какие ноды? Какой деплой? Какой код? Милости просим на производство, в торговлю, в мир 1с, офиса, принтеров, клиент-банков с глючными апами. Ваше веяние напоминает ранний линукс. Когда все говорили о чуде, которого не случилось. ИМХО
                      0
                      На этом IT кончается, остальное — баловство? А как же стартапы и новые продукты, например, которые надо успеть сделать вчера.
                        +1
                        Разные направления, разные задачи, разные инструменты. Строителю строительное, электрику электрическое, врачу врачевное.
                          0
                          Время всё решило.
                          В ITILv4 есть раздел DevOps
                    0
                    В ИТ кардинальная смена будущего приходит с изменениями и лидеров рынка и изменениями лидеров рынка.
                    Тоесть, пока НР работает по ITIL и рекомендует его, целесообразно не придумывать велосипед.
                    Дело ведь не в том, американская вилка и розетка лучше, или европейская. Нужна та, которая применима здесь и сейчас.
                      0
                      Нельзя же подойти и сказать бизнесу — извините, мы не можем развиваться так быстро, как вы хотите, потому что HP рекомендует работать по другому плану.
                      Это не велосипед, это — эволюция. Не всем это пока надо, но успешным компаниям, которые развиваются и конкурентноспособны — почему нет )
                        0
                        Я вижу в ITIL оптимизацию и снижение хобота. В размерах тех компаний, с которыми у меня есть опыт работы, ИТ развивается быстрее.
                          0
                          Давайте поговорим об инцидентах.
                          ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, срочность и влияние.

                          У нас есть первая линия, хелпдеск, которая должна объективно определить срочность. Как? Со слов пользователя?

                          У пользователя для всех его заявок всегда один и тот же приоритет. Точнее целый набор: «жить не могу», «сверхсрочно» и «сделать вчера!».

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

                          Среднестатистический helpdesk вообще слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: «рабочее место», «печать» или «электронная почта». Да и не обязан, кстати.

                          Влияние? Та же песня. Зачастую невозможно определить влияние инцидента до полного его расследования.

                          Не работает. Необъективно ) Только для тихой рощицы торговли и чего вы там еще назвали. И то с натяжкой.
                            0
                            Ну да, торговля и производство тихая рощица.
                              0
                              К сожалению, IT на них не заканчивается. И это очень малая часть. И там очень тихо и можно позволить себе ITIL.

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

                              И там тоже есть среднестатистические админы )
                                0
                                вы хорошо понимаете что разработчики и софт это где-то 2, максимум 3% от всего мира? и это очень оптимистическая оценка.
                              +1
                              Улыбнуло.
                              Основываясь на ваших комментариях, я сперва подумал, что DevOps — методология, не так давно придуманная очень маленькой группой людей. Относится по большей части к разработке и тому, что с ней связано, и не касается очень многих процессов ИТ.
                              А потом почитал в инете и понял, что так оно и есть.
                              Предполагаю, что это очень удобная методика и авторы её молодцы.
                              Но глупо сравнивать кирпич, бревно и пенопласт.
                              ITIL — это сборник практик. Рекомендаций. На каждый шаг он даёт советы, основываясь на лучшем опыте.
                              И применять можно и нужно то, что подходит в каждом конкретном случае.
                              Полагаю, со временем DevOps вполне претендует стать одной из книг ITIL.
                      0
                      Правильно написано) Сам постепенно прихожу к некоторым методикам, которые описаны в ITIL. Даже документация в локальной wiki. Просто в один момент задумался о том, что через n-ое количество времени я тупо забуду как настраивал тот или иной сервис.

                      Only users with full accounts can post comments. Log in, please.