Как вы работаете: по наитию или по науке? Наверное, никто не даст однозначного ответа: работа в ИТ-сфере предполагает сочетание опыта и технологий, точных указаний, норм и красивых, даже талантливых, инженерных находок. В любом случае, опыт решает. А как насчёт чужого опыта? В мире создано множество сводов и правил, предназначенных для работы ИТ-служб, которые объединяет понятие с маркетинговым оттенком — «лучшие практики». Это опыт, сформированный множеством компаний и позволяющий довольно просто решать стандартные проблемы.


В посте мы расскажем, что такое ITIL, ITSM, CobiT, DevOps, как они связаны и почему даже системные администраторы небольших компаний должны что-то знать об этих аббревиатурах.

Зоопарк методологий: очень краткий обзор


ITIL и ITSM


ITIL (IT Infrastructure Library) — набор публикаций (библиотека), содержащий лучшие практики в области управления ИТ-услугами. ITIL содержит рекомендации по предоставлению качественных ИТ-услуг, процессов, функций, а также других средств, необходимых для их поддержки. Структура ITIL основана на жизненном цикле услуги, который состоит из пяти стадий (стратегия, проектирование, преобразование, эксплуатация и постоянное совершенствование). Также существуют дополнительные публикации, входящие в ITIL и содержащие специфичные рекомендации по индустриям, типам компаний, моделям работы и технологическим архитектурам. Это каноническое определение ITIL.

На самом деле, эта библиотека породила целую парадигму управления ИТ-инфраструктурой компании, основанную на SLA (соответствие обещаний поставщика услуги ожиданиям клиента) и ITSM (IT Service Management, управление ИТ-услугами). ITSM — это концепция организации работы ИТ-подразделения и его взаимодействия с внешним или внутренним заказчиком, а также внешними контрагентами.


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

Теперь о рисках. Понятно, что стандарты ITSM и библиотека ITIL описывают лучшие практики и при ознакомлении с ними кажется, что всё логично и именно так работать и должно.

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

  • Опять же, перед изменением подхода к управлению следует провести глубокий анализ процессов, происходящих внутри ИТ-инфраструктуры — если всё работает и очевидных путей и потребностей улучшения нет, лучше подойти к ITSM избирательно и внедрять самые ценные и нужные принципы: управление лицензиями (SAM), управление конфигурациями или просто наладить мониторинг.

  • Если нет внятной цели использования принципов ITIL, то лучше отказаться от затеи. Внятные цели — это, например, изменение политики управления лицензиями или решение проблемы использования сотрудниками пиратского софта. Невнятная цель — внедрить и применить то, что навязали сверху, потому что услышали на конференции.

Собственно говоря, это именно ITIL мы с вами обязаны созданием и развитием удобных систем тикетов, управления инцидентами и Service Desk. Большинство разработчиков подобного софта (и Alloy Software не исключение) при разработке модулей опирались именно на рекомендации ITIL.

CobiT


CobiT (Control Objectives for Information and Related Technologies, задачи управления для информационных и смежных технологий) — сбор стандартов и руководств в области управления ИТ-аудита и безопасности; руководство и сборник практик по управлению ИТ-процессами. Связанный с ITIL инструмент, который непрерывно обновляется и предназначен для того, чтобы между руководством компании, ИТ-специалистами и аудиторами (внешними и внутренними) царили мир и взаимопонимание. Проще говоря, управляющий менеджер должен понимать все ИТ-риски, в том числе связанные с бездействием в ситуациях, требующих коррекции, а также потенциальные риски, связанные с использованием того или иного элемента ИТ-инфраструктуры компании.

Рассмотрим две распространённые ситуации.

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

Ситуация вторая, свойственная компаниям любого уровня: от микробизнеса до транснациональных корпораций, — неадекватная оценка рисков. Почти каждый из нас хоть раз встречался с рисками завышенного масштаба: например, страх перед DDoS в небольшой компании или всем известная и так и не ставшая реальностью «проблема 2000». Это риски, которым придают огромное значение и которые не несут объективной угрозы. С другой стороны, существуют недооценённые риски, на которые никто не обращает внимание, но именно они способны положить весь рабочий процесс или принести коммерческий ущерб: неограниченный срок действия учётных записей и паролей пользователей от рабочих ПК и корпоративных информационных систем, клиент-банков; передача коммерчески значимых данных по незащищённым каналам; отсутствие антивирусов и проч. Чтобы классифицировать риски и грамотно их оценить, необходимо проводить внутренний и/или внешний ИТ-аудит. Он, в свою очередь, должен быть не проверкой соответствия правилам и не толчком к соблюдению правил, а именно соблюдением правил. Поэтому аудит должен быть регулярным и сопряжённым с мониторингом системным процессом получения и оценки объективных данных о текущем состоянии информационной системы, действиях и событиях, происходящих внутри неё.

В свете этих ситуаций вернёмся к CobiT. В нём описаны цели, задачи и принципы управления, объекты управления, ИТ-процессы, инструменты работы с ИТ-инфраструктурой, а также вопросы ИТ-безопасности. Актуальную версию CobiT и статьи по нему можно почитать на сайте ISACA (есть платные и бесплатные материалы). CobiT можно определить как методологию корпоративного управления ИТ, которая:
  • ориентирована на реальные бизнес-требования;
  • поддерживает процессный подход к управлению ИТ-инфраструктурой и контролирует процессы;
  • оценивает эффективность ИТ в компании.

Кроме того, CobiT соответствует стандартам ISO 9000 и ISO/IEC 17799, стандарту информационной безопасности и менеджмента ИБ. С помощью принципов CobiT можно минимизировать риски и контролировать отдачу инвестиций в ИТ. Что нам нравится в CobiT, так это то, что он хорошо структурирован и поле зрения этого свода правил попадают планирование, организация, приобретение, внедрение, эксплуатация и сопровождение, а также мониторинг и оценка пяти важнейших элементов каждой компании (согласно определения CobiT, ресурсов ИТ).

  1. Данные — информация внутри компании в любом виде, медиафайлы, внешняя информация.
  2. Приложения — множество автоматизированных и ручных процедур.
  3. Технология — программное обеспечение, аппаратное обеспечение, СУБД, СУ сетями, ОС.
  4. Оборудование — ресурсы, поддерживающие технологию.
  5. Люди — персонал с навыками и умениями, в том числе контроля и мониторинга.


То есть фактически CobiT исходит из понимания того, что ИТ-инфраструктура — это управление информацией, а согласно своду информация оценивается по нескольким критериям:

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

Так как же соотносятся CobiT и ITIL? ITIL — библиотека лучших практик предоставления услуг в сфере ИТ, а CobiT — больше по части управления и аудита ИТ. Соответственно, все процессы, описанные в ITIL, могут управляться и подвергаться аудиту стандартом CobiT.

DevOps


Связан с ITIL (в некоторых источниках считается прямым следствием), покрывается CobiT, но имеет совершенно другую парадигму подход к системному администрированию DevOps. Впрочем, сама расшифровка названия указывает на то, что это гибрид на стыке администрирования и разработки (development и operations). Методология DevOps соединяет в себе труд разработчиков и ИТ-инженеров (это могут быть сформированные команды, отдельные люди или даже один человек), тем самым обеспечивая быстрые темпы развёртывания, надёжность и безопасность production-среды (включая тестирование). Говоря проще, эта методология исключила распространённую фразу, ставшую мемом: «Проблема на стороне железа/софта».


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

Как методология DevOps даёт множество преимуществ, среди которых:
  • стандартизация и автоматизация окружения
  • высокая скорость разработки, разворачивания и тестирования
  • возможность часто выпускать обновления
  • минимизация проблем при внедрениях у заказчика и т.д.

Как видите, DevOps не является подходом чисто к системному администрированию, соответственно, о его применении идёт речь, в основном, в компаниях-девелоперах.

Предупреждение о Visible Ops
Вы можете услышать термин Visible Ops. Он не имеет прямого отношения к DevOps, однако имеет отношение к ITIL, а именно — это книга (с развитием технологий превратившаяся в серию книг) Visible Ops Handbook, которая является отличным пошаговым руководством по использованию ITIL в компании. В книгах есть интересные практические примеры крупных корпораций. Первая, ставшая классикой книга, простым английским языком раскрывает проблемы ИТ в компании и цели изменений. В любом случае, хотя бы пролистать PDF-ку стоит.

Ок, моя компания не входит в топ-100 мира, что мне делать с этой информацией?


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

  • Распределение ответственности в команде и понимание взаимосвязей всех подразделений. Так, например, отдел продаж не может жить отдельно от ИТ-службы, поскольку является пользователем услуг и информации, которая обеспечивается ИТ. Особенно это заметно в тех компаниях, где данные собираются в централизованной базе, а затем распределяются по запросу (например, компании, имеющие биллинг, информацию из которого выгружают с помощью специальных отчётов согласно правам доступа). Плюс ко всему, внутри самой команды ИТ-службы также стоит чётко распределять обязанности — это обеспечит скоординированность действий.

  • Рост внимательности и ответственности. В случае, если персоналу известно о непрерывном мониторинге и периодическом ИТ-аудите, многих инцидентов удаётся избежать, поскольку пользователю становится очевидно, что любые ухищрения будут выявлены.

  • Рост скорости реакции на проблемы. Если в компании существует система тикетов и заявок, то эффективность обслуживания внутренних заказчиков значительно повышается, а скорость решения проблемы контролируется самим инициатором заявки.

  • Простота и прозрачность выявления проблем. Система работы с инцидентами в сочетании с программным обеспечением, позволяющим осуществлять мониторинг сети, помогает быстро устанавливать причину возникновения проблемы и объекты, задействованные в проблеме. А, значит, получать достоверные сведения для поиска решения.

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

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

  • Управление лицензиями ПО, проверка наличия свободных лицензий — одна из ощутимых статей экономии на ИТ-инфраструктуре. Установление профиля использования лицензий помогает скорректировать объём закупаемых или арендуемых продуктов, перераспределить ПО по реальным потребностям. Классический пример: отдел продаж из 7 человек, трое из которых постоянно «в полях», а ещё один — выгружает данные раз в месяц для анализа. В отделе семь лицензий CRM, а можно было бы обойтись пятью. Такая же история повторяется и в отделах логистики и дизайна, где установлено и нередко простаивает дорогостоящее ПО.

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

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

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

В принципе, практически каждый системный администратор сталкивался с отдельными элементами методологий и активно использовал их в своей практике. Однако комплексный подход и постепенное внедрение новых практик непременно даст свой эффект, вне зависимости от размера компании. Мы это испытали на себе — и в процессе разработки наших систем, и в процессе управления компанией. Своим клиентам мы всегда повторяем: да, наши системы спроектированы с учётом принципов ITIL, но их использование и внедрение вовсе не обязывает слепо подчиняться принципам. Напротив, мы всегда отмечаем, что программы Alloy Software гибко настраиваются практически для любой инфраструктуры:

Alloy Navigator — комплексное средство управления работой ИТ-инфраструктуры предприятия. Продукт представляет собой простую и многофункциональную систему Service Desk, с широкими возможностями по управлению активами и поддержкой всего спектра задач подразделения IT. Нацелен на потребность среднего и крупного бизнеса. Для малого бизнеса есть Alloy Navigator Express.

Alloy Discovery — система сбора и обработки информации о компьютерном оборудовании и программном обеспечении компании. Продукт разработан специально для сетевых администраторов и поставщиков услуг, подходит для малого и среднего бизнеса. Для совсем небольшого бизнеса есть Alloy Discovery Express.

Помня предыдущие комментарии на Хабре, выделим цены на продукты прямо в посте:
Alloy Navigator
Alloy Navigator Express — от 20 000 руб. / пользователь, от 150 руб. / хост
Alloy Navigator Enterprise — от 83 000 руб. / пользователь, от 150 руб. / хост
Подробности тут
Пост об Alloy Navigator на Хабре живёт здесь.

Alloy Discovery
Alloy Discovery Express — от 12 000 руб. / пользователь, от 150 руб. / хост
Alloy Discovery Enterprise — от 19 000 руб. / пользователь, от 150 руб. / хост
Подробности тут
Пост об Alloy Discovery на Хабре живёт здесь.

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

Комментарии (8)


  1. Sergey-S-Kovalev
    28.12.2015 13:59
    +2

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

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

    ну так вот… что бы все это обеспечить и нужно понимание ITIL и иже с ними


    1. VolCh
      28.12.2015 14:08
      +7

      Вы реально считаете это простым действием?


      1. Sergey-S-Kovalev
        30.12.2015 06:48
        +1

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


  1. shuron
    28.12.2015 20:19

    Как хорошо что мне не надо больше связываться с ITIL…
    DevOps рулит.


    1. erthad
      28.12.2015 21:13
      +1

      Если немного пойти вглубь, devops — это во многом способ переложить всю бюрократию ITIL на роботов.
      Управление конфигурациями — в git.
      Документация (RTFS) — в git.
      Управление изменениями — в git, тестах и мониторинге (если devops дозревший, а не зачаточный).
      Опционально заменяем везде выше git на service discovery и контейнеры.

      А кое-какие вещи никуда не исчезают типа управления инцидентами и проблемами, и подход ITIL в этом вполне неплох. Главное — его упростить так, чтобы пользоваться можно было без тормозов и не задумываясь, (например, не плодить сущности больше, чем минимально необходимо).


      1. shuron
        29.12.2015 02:46

        Может у нас разные определения ДевОпс…
        Но у нас от проекта зависит гит или шмидт… Ну технологии и методы…

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


    1. varnav
      30.12.2015 12:09

      Dev-а в организации может вообще не быть


      1. shuron
        30.12.2015 17:17

        Да, я не спорю…