Планы по развитию ITIL в 2017-м году

Планы по развитию ITIL в 2017-м году

Вот размышления по развитии ITIL, который были «набрейнштормлены» во время визита Романа Журавлева в Москву.

Это видение собравшихся специалистов о том:
* что есть сейчас (желтое в середине);
* как мы к этому пришли (красная цепочка слева);
* вариант положительного будущего (голубые);
* отрицательного будущего (желтое);
* как к этим двум вариантам можно прийти (красные цепочки сверху и снизу). Read more

IT4IT — кратко и впечатления

IT4IT — кратко и впечатления

Первое. Текущая версия — 2.0.
Полное официальное название (чтобы гуглить) — «IT4IT™ Reference Architecture Version 2.0», стандарт «Open Group».
Второе. IT4IT — это стандарт (хотя на «стандарт», ИМХО, не тянет) архитектуры и операционной модели, создающей «цепочку ценности» для управления ИТ-бизнесом или ИТ внутри другого бизнеса.
Третье. Состав. Выделяем 4 потока (стрима). Даже не просто «стрима», а «Стрима ценности ИТ». Зачем? «Для эффективности и гибкости». В чем именно состоит гибкость и эффективность, не сказано. В общем, стримы следующие:
* Strategy to Portfolio (превратить стратегию в портфолио проектов и услуг).
* Request to Fulfill (запросы — исполнить).
* Requirement to Deploy (требования — внедрить). Огровный пласт работы типа бизнес-анализа, архитектурной проработки, разработки, тестирования, планирования внедрения и интеграции, подразумевается — здесь. Read more

Составляющие надежности

Составляющие надежности

Чтобы определить общую надежность ИТ-системы, необходимо определить составляющие ИТ-систем, по которым можно повышать надёжность.
Существуют три основные составляющие:
* люди;
* процессы;
* технологии.
В случае современных информационных технологий, последний пункт следует разделить на две части, и рассматривать их отдельно:
* аппаратное обеспечение;
* программное обеспечение.
К каждой части (аппаратной и программной) применимы свои методы повышения надежности.
Принципиальная разница в том, что аппаратное обеспечение – это технологии, на которые имеет воздействие физический мир. К этой части можно применять различные теории по надежности физических объектов, включая время наработки на отказ, износ материалов, влияние окружающей среды и т.п. Read more

Классификация ошибок персонала. Часть 2.

Классификация ошибок персонала. Часть 2.

В продолжение предыдущей части, рассмотрим классификацию ошибок персонала немного в другом разрезе.

Ошибки бывают:
1) Ошибка случайная – неверные команды/адреса/параметры при проведении работ в ПРОД. Опечатки. Это – чистый человеческий фактор, снизить который – главная управленческая цель эксплуатации.
2) Недостаточно протестированное решение, которое все таки попало в ПРОД. В данном случае следует считать это не ошибкой персонала, а ошибкой процесса.
3) Излишне долгое время сбора информации и принятия решения о необходимости работ. Также ошибка процесса.
4) Отсутствие сотрудника на месте (когда должен там находиться). Ошибка дисциплины и организации, которую можно отнести к недостаточному управлению (ошибка менеджера).
5) Ошибки вендоров. Слишком долгий ответ 3-й линии поддержки. Ошибки контрактования. Read more

Классификация ошибок персонала

Классификация ошибок персонала

1. Категории ошибок персонала
Ошибки персонала разделяются на уровни управления и исполнения. Уровень управления, в свою очередь, разделяется на линейное и процессное.

В «линейное управление» входят следующие вопросы:
* Управление ресурсами (наличие и квалификация Исполнителей);
* Организация работ;
* Наличие и актуальность инструкций и другой документации технического уровня.
Целевые документы, ожидаемые на уровне линейного управления:
* Инструкция;
* План работ.

В «процессное управление» входят вопросы:
* Процессы планирования, разработки и эксплуатации;
* Регламентация; Read more

Макрос для бюрократов

Макрос для бюрократов

Очень. Очень! ОЧЕНЬ! Полезный макрос. Натравливается на документ и делает отдельный документ с таблицей из комментариев и замечаний, найденных в исходном документе.
Незаменим при подготовка презентаций к совещаниям с разбором вопросов к документу.
Качать здесь.

О разделении инженеров и менеджеров

О разделении инженеров и менеджеров

У нормального инженерного работника, не имеющего подчиненных, должен быть один интерфейс управления: список входящих задач. И кнопка на каждой задаче «Сделал».
А снизу на этот интерфейс еще можно добавить две кнопки: «Взять отпуск» и «Уволиться». Всё.

Всем остальным должны заниматься те, кто носит гордое звание «Менеджер» или «Руководитель».
И как только хоть один этот «менеджер» пристанет к инженеру со словами «предоставьте отчет» или «вы должны были согласовать» или «ознакомьтесь с регламентом», такого «менеджера» нужно тут же расстрелять попросить заняться своей непосредственной работой, а именно, в первую очередь: построением модели взаимодействия между сотрудниками.

Как ломаются сложные системы

Как ломаются сложные системы

Очень жаль, что я не прочитал эту статью лет 5 назад.
Всем строящим Управление Проблемами и Управление Рисками — обязательно к прочтению.
И особенно тем, кто рассказывает о том, как «дайте бесконечные деньги, и получите доступность 99,(9)%». Кратко — шиш.
Автор статьи, кстати, не ИТ-шник, а медик.
Роману Журавлеву из Cleverics — низкий поклон за перевод.

1) Опасность – неотъемлемый атрибут сложных систем
Все интересные системы (транспорт, здравоохранение, энергетика…) естественно и неминуемо опасны по своей природе. На частоту опасных явлений в ряде случаев можно влиять, но процессы, входящие в состав этих систем, сами по себе являются источником неотвратимой опасности. И именно присутствие этой опасности приводит к созданию многочисленных средств защиты, столь характерных для этих систем. Read more

Инциденты по производительности

Инциденты по производительности

Инциденты по производительности могут быть двух типов:
Тип 1. Трендовые инциденты. Связанные с ростом тренда нагрузки, который мы не обнаружили вовремя (поддержание запаса мощности на, например, 6 месяцев). Подобный инцидент, скорее всего, не будет одиночным – это будет серия однотипных инцидентов с возрастающей частотой проявления и с единой корневой причиной.
Инциденты этого типа подразумевают, что все компоненты ИТ-системы находятся в работоспособном состоянии, и нам необходимо обеспечить запас производительности исправных компонент.
При этом, дополнительно, компоненты работают в штатном режиме. То есть нет внеплановой нагрузки, такой, как например, выполнение резервного копирования в период высокой нагрузки. Read more

Надежность ИТ-процессов: доступ в ПРОМ

Надежность ИТ-процессов: доступ в ПРОМ

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