Портал №1 по управлению цифровыми
и информационными технологиями

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Эксплуатация ИТ

Всё про операционный сегмент ИТ и службу эксплуатации ИТ

Доступность, готовность?

Вопрос прислан посетителем портала. Возник он (вопрос) при подготовке документа, который описывает ПО, позволяющее: собирать информацию об отказах в сети, вычислять значения коэффициента готовности отдельных компонент сети вычислять интегральный коэффициент готовности сети  вычислять некоторые финансовые показатели (потери от простоев…). Как видно из второго пункта в списке, речь в документе первоначально велась о "готовности". И не просто потому что слово понравилось, а потому, что автор давно и привычно основывает свою работу в этой области на ГОСТ 27.002-89 «Надежность в технике» (ныне действующий ГОСТ Р 53480-2009 «Надёжность в технике. Термины и определения»). С другой стороны расчет метрик велся в целях повышения степени управляемости…

Конфигурационные единицы, которых нет

После прочтения курса по управлению конфигурациями есть еще пара мыслей, которыми хочется поделиться. Например, обязательно конфигурационные единицы в CMDB это нечто реально существующее, или можно для упрощения картинки вводить некие "суррогатные конфигурационные единицы", которых на самом деле нет, но которые могут внести в картинку ясность и указать на реальное положение дел: взаимосвязь конфигурационных единиц, влияние друг на друга и т.д. Давайте рассмотрим пример. Ниже привожу тоже самое, но в текстовом виде. Для примера предлагаю рассмотреть следующую схему: Есть ИТ-сервис (например, электронная почта) ИТ-сервис зависит от работы ИТ-системы (например, "Почтовый сервер") ИТ-система установлена на сервер  Теперь представим, что ИТ-системы две и они располагаются на двух серверах, при этом сервера…

Почему они возвращаются? Интересная метрика для службы поддержки

Один из авторов портала ERP4IT, alphasong, предлагает интересную метрику для оценки работы службы поддержки. Цель метрики – выявить и свести к минимуму случаи неполного выполнения заявок.  Действительно, часто оказывается, что стремление службы поддержки закрывать обращения как можно скорее стимулирует специалистов поддержки объявлять завершенными работы, которые выполнены не полностью, или работы, выполнение которых оказалось по каким-то причинам прервано или отложено. Автор приводит такие примеры: Пользователь запросил установку MS Excel. Excel был установлен, заявка закрыта. Пользователь обращается вновь, теперь уже с запросом на установку Excel PowerPack. Пользователь обратился с каким-либо запросом. После чего заболел. Чтобы заявка не висела, мы ее закрыли с…

CSI и управление проблемами: кто сверху?

Michael Crooon в своей колонке на ITSMPortal, озаглавленной "Что общего у ITIL и Камасутры?" рассуждает о практике постоянного улучшения услуг (ИТ-услуг, разумеется).  Основная идея такова: для реализации на практике постоянного улучшения услуг можно и нужно использовать механизмы управления проблемами. Для этого нужно расширить перечень процессов, поставляющих процессу управления проблемами информацию для анализа и расследования. Обычно основным источником такой информации оказывается управление инцидентами; автор же предлагает варианты использования управления проблемами в интересах SLM, управления информационной безопасностью, управления жизненным циклом (приложений?)…    Полный текст колонки с таблицами и картинками – на ITSMPortal'е.   Ответ автора на вопрос из заголовка его колонки: ITIL and…

ИТ “за стеклом”

Портал SmartSourcing.ru запустил и поддерживает интересный проект, в котором ИТ-руководитель небольшой компании делится своими проблемами, решениями и идеями с сообществом в рамках специального блога. Виктор Таланов, ведущий этого блога, работает в компании Русбал, основной бизнес которой заключается в производстве аэростатов, надувных рекламных конструкций и аналогичных изделий. По словам Виктора, состояние ИТ в данной компании весьма печальное, поэтому есть большой простор для улучшений. В блоге уже сформулированы и описаны: общая ситуация в компании цели проекта выбор поставщика реализация первого этапа проекта Читать блог "Большой ИТ-проект в небольшой не ИТ компании"

Управление конфигурациями – не вещь, а практика

  ИТ-скептик опубликовал небольшую заметку об управлении конфигурациями и роли CMDB в этом процессе. Для удобства обсуждения мы публикуем ее полный перевод.  ITIL определеяет управление конфигурациями как предоставление информации, но затем на множестве страниц описывает его как сопровождение статичного хранилища данных, а не как активную деятельность по предоставлению информации заинтересованным в ней получателям. Давайте все же договоримся: управление конфигурациями – это процесс, а не вещь. («Процесс» – в  том вульгарном понимании этого слова, в котором его использует ITIL. Если вы не согласны с ним, замените «процесс» на «практику» или «деятельность».) Совершенствование управления конфигурациями – это совершенствование предоставления информации другим практикам…

Опять ИТ ломают бизнес

Недавно ИТ-скептик разместил в своем блоге заметку о том, как ИТ-проекты разрушают нормальную работу бизнеса. Вкратце ее основные тезисы таковы: Раньше большие проекты предполагали привлечение внешних ресурсов для формирования временных команд. Сейчас мы все больше отвлекаем для этих целей персонал операционных служб. Результат – снижение качества на обоих фронтах и нехватка ресурсов. Бизнес требует внедрения новейших технологий независимо от их полезности. Мы не осознаем всего объема выполняемых ИТ-проектов, не видим полной картины и, следовательно, не управляем ИТ-проектами. Бизнес также не учитывает сложности и критичности современной ИТ-архитектуры. ИТ не имеет возможности сказать бизнесу "НЕТ!". Неоправданным спросом на инновации никто не управляет….

Управление мощностями, как оно есть

На днях опять вспомнилась тема управления мощностями. Столько всего понакручено вокруг нее. Решил немного про это порассуждать. Например, выяснилось, что иногда под управлением мощностями понимают мониторинг ИТ-ресурсов ("всякие железяки"). В лучшем случае, с определением пороговых значений и правил реагирования на их нарушение. И тут появляются вопросы и типичные ошибки: 1. Откуда взяться требованиям к мониторингу? 2. Откуда взяться пороговым значениям?3. Как реагировать? Что значит для нас превышение того или иного порога? Бывает, что на эти вопросы отвечают так (конечно утрирую): "собираем все важное, пороги поставили разумные, если жахнет, то разберемся". При таком подходе, есть риски: 1. За грудой данных не увидеть…

Развязали руки? Держите себя в руках!

Еще недавно в России было не так много средств автоматизации ITSM процессов. Я, например, начинал проектировать процессы имея ввиду, что автоматизировать их придется на HP OV SD. Т.е. процессы конечно же проектировались, и отличались друг от друга, и подгонялись под задачи и возможности заказчика, но все равно на них (на нас при проектировании) давило то, что продукт не многое позволит. И поэтому полет фантазии приходилось загонять в угол и откладывать на потом. Что мы имеет теперь? Руки развязали, все продукты, по заявлениям производителей, супер-мега-гибкие движки – делай что хочешь, никто тебя не ограничивает. Сбылась мечта, можно доставать из углов идеи…

Облачные вычисления такие облачные

Это, конечно, сейчас тема номер один. Модно, интересно, раскручено. И, вроде бы, понятно массам. Все – в виртуализацию! Все – в облака! Коммодитизация информационных технологий как неизбежное будущее! Меня несколько пугает и обнадёживает такое будущее, и вот почему. Попробуйте найти в России вменяемый хостинг для сайта. Не ЦОД Tier Level 4 (понятно, что это у нас пока утопия), не аутсорсинг бизнес-процессов, ничего сложного – обычный хостинг, самая простейшая услуга, которая может быть отнесена к облачным вычислениям. Вопрос, который актуален для почти 3 миллионов доменов в одной только зоне RU. Я, например, такого не знаю. Вот наш хостер – вроде нормальные…

Правда ли это облако?

По мнению Дейла Виля (Dale Vile), если убрать всю истерию, маркетинговый шум, догадки и предположения, то всё, что останется от идеи облачных вычислений – неясность. Для иллюстрации этой проблемы Дейл провёл небольшое исследование и составил список предложений, которые в то или иное время преподносились как примеры облачных вычислений. Результирующий список стал основой опроса ИТ-профессионалов для выяснения правды про облака. Читать далее на сайте ITSM Portal.

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM