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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

Управление доступностью

Всё об управлении и измерении доступности

Проектирование услуг как управление рисками

Вот еще одна модель с минимальной прикладной ценностью, зато для меня обеспечивающая полное понимание вопроса. В процессных моделях ITIL, COBIT 5, ISO 20000, MOF 4, CMMI for Services присутствуют одни и те же слова: доступность, мощность, непрерывность и, конечно, безопасность. Если брать за основу идеологию ITIL, то это — четыре равноправных и обязательных составляющих качества ИТ-услуг (есть еще функциональность, но я не о ней пока). И вот, в ITIL всё понятно: есть четыре процесса, которые оперируют ими: проектируют и контролируют. А вот в других источниках всё по-другому, по-разному. Во всех перечисленных моделях эти слова комбинируются в произвольном порядке. Стандарт —  объединяет, и управляет вместе доступностью и...

Вопрос из зала: доступность и её команда

Алексей Тюрин спрашивает на нашей страничке в Фейсбуке: Добрый день! Помогите пожалуйста разобраться в чем разница между reliability и dependability (нет в глоссарии). И то и другое согласно ГОСТУ — надежность — т.е. свойство объекта сохранять во времени в установленных пределах значения всех параметров... Тем не менее в другом контексте говорится, что depentability — это reliability и availability. В этом случае, если reliability — надежность, то что такое dependability? Безотказность? Т.е. безотказность это надежность и доступность (способность объекта выполнять согласованную функцию, когда это требуется). Правильным ли будет такой вывод? Спасибо! Давайте распутаем эту терминологическую красоту в комментариях.

Точно и адресно

  Как и многие пользователи техники ASUS, сегодня я получил письмо с уведомлением о предстоящем перерыве в работе сервиса ASUS WEB storage. Этим сервисом я не пользуюсь (припоминаю, что когда впервые попробовал, был поражен неудобством интерфейса и низким качеством локализации и не стал продолжать), поэтому мне, в общем-то, все равно. Но само письмо показалось мне просто замечательным. Вот оно: Уважаемые пользователи! Чтобы улучшить качество предоставляемых услуг, мы планируем выполнить модернизацию наших систем. Продолжительность вынужденного отключения системы: система будет отключена для модернизации на 4 часов 17.12.2012 г. с 10:00 до 20:00 (GMT+8). Во время указанного периода доступ ко всем службам ASUS...

Недоступная доступность

На прошлой неделе, во время курса «Основы ITIL V3», мы разговорились со слушателями про доступность ИТ-услуг. Спор завязался вокруг тех сервисных инцидентов, в которых, в самом широком смысле, «виноват пользователь». Если конкретнее: считать ли ИТ-услугу недоступной, если пользователь просто не знает, как ею правильно воспользоваться? Ответ коллег был следующим. Услуга конечно же доступна, ведь у нас есть процессная модель управления, мы отлично взаимодействуем между собой, и все ИТ-компоненты работают слаженно. Нам за это платит заказчик. Он же платит своим сотрудникам, чтобы те делали свою работу используя компьютеры, а, следовательно, это он обязан их обучить всем аспектам рабочего процесса, и в...

Смотрим на инциденты расширенными глазами

Хочу написать про еще одну технику управления рисками, незаслуженно забытую в книгах ITIL V3 2007 года, но восстановленную ("по чертежам" ITIL V2) в прошлогоднем обновлении. Я говорю о расширенном жизненном цикле инцидента (the Expanded Incident Lifecycle). Это раздел в описании процесса управления доступностью (Availability Management), где предлагается разделять каждый инцидент (незапланированный перерыв в нормальном предоставлении ИТ-услуг) на обязательные последовательные этапы. Момент возникновения инцидента, то есть, момент, когда пользователь ощутил снижение качества ИТ-услуги Обнаружение, то есть промежуток времени от возникновения до момента получения поставщиком ИТ-услуг информации об инциденте Диагностика, то есть время на поиск причины инцидента Исправление, то есть время на...

Мониторинг инфраструктуры, что кроме автоматизации?

На днях закинули в CleverTEST очередной пробный экзамен по ITIL, пока кидали, на глаза попался вопрос:   Что из перечисленного лучше всего описывает назначение управления событиями?   Способность обнаруживать события, толковать их и определять подходящий способ реагирования Способность внедрять средства мониторинга Способность отслеживать и контролировать работу технического персонала Способность формировать отчетность об успешном предоставлении услуг на основе данных о времени бесперебойной работы устройств Вспомнился недавний разговор с одним знакомым, который жаловался на несовершенство используемой им системы мониторинга, "которая заваливает их спамом, а толку никакого". В моем понимании, идеальная схема работы с большими объемами информации заложена в процессе управления конфигурациями. А...

Мониторинг ИТ-сервисов

Как обычно, тему навеяло не книгами, а внешними событиями, происходящими вокруг меня. В течение продолжительного времени я регулярно использовал единственный предсказуемо перемещающийся по нашему городу транспорт — метро. В связи с этим посещал одну из станций, где в ожидании поезда смотрел по сторонам. Как и любому человеку, имеющему отношение к ИТ, мне не чуждо чувство любопытства, которое начинаешь испытывать при виде окна с сообщением об ошибке. Особенно если это окно обнаруживается в неожиданном месте. Например, на мониторе рекламной стойки. Следует отметить, что рекламные ролики при этом продолжали крутиться, но на 60% они были перекрыты данным окном. Почитав надписи в окне, гласившие...

Думать о клиенте

Мне казалось, что та байка давно осталась в прошлом. Помните, когда ИТ-служба запрашивает по электронной почте подтверждение о восстановлении работы той самой электронной почты? Оказывается, мир ещё не ушёл вперёд. Свежий случай приключился сегодня при общении с известной компанией, предоставляющей беспроводной доступ в Интернет почти по всей Москве и большой части Подмосковья. Высокие технологии, высокая скорость, всё как положено. Только вот скорость неожиданно упала до 10 кбит/с, с постоянными разрывами соединения. На этот случай техническая поддержка предложила замечательное решение — скачать и установить обновление размером 21 мегабайт. Желающие могут сопоставить размер обновления и скорость, получив время решения проблемы, измеряемое почти уже...

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

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

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM