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

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

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

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

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

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

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

Основы процессного управления. (видеозапись тренинга, часть вторая)

Продолжение первой части тренинга «Основы процессного управления» для консультантов Microsoft Consulting Services и сотрудников Microsoft Premier Support. Ноябрь 2010 года.
Специфика — читалось не для конечного потребителя (Заказчика), так что некоторые моменты описывают работу консультантов.

На встроенном видео изображение, возможно, мелковато. Рекомендую смотреть прямо на YouTube. Continue reading

Модели мотивации: Ford vs IBM

При всем разнообразии нынешних моделей и принципов мотивации персонала, существуют две противоположные крайности, которые можно рассмотреть в применимости к ИТ: модель «по Форду» и подель «по IBM».
Модель «по Форду» гласит, что ни один сотрудник на производстве не совершает дважды одну и ту же ошибку. Потому что его увольняют после первого раза. «Увольняют», это, возможно, образно, но смысл сохраняется.
Данная модель (абстрактно, конечно: не думаю, что где-то ещё остались такое крайности) накладывает очень большие требования к руководству фирмой: должна быть налажена четкая, стандартизированная и регламентированная деятельность. Это не означает, что компания (или подразделение) не должно развиваться и не предусматривать инициативы. Просто следует разделить, что является стабильной частью, а что – инновационными составляющими. Continue reading

Основы процессного управления (видеозапись тренинга, часть первая)

Давно собирался выложить, наконец руки дошли. Ноябрь 2010 года, тренинг «Основы процессного управления» для консультантов MCS и сотрудников Premier Support.
Данная запись тренинга имеет небольшую специфику — читалось не для конечного потребителя (Заказчика), так что некоторые моменты описывают работу консультантов.

На встроенном видео изображение мелковато. Рекомендую смотреть прямо на YouTube. Continue reading

Всем, кто пишет документы

Как говорил писатель Стивен Кинг — «Писательство это телепатия. Я что-то представляю или вижу, и описываю это на бумаге, словами. Потом Вы, через расстояние и время, берете написанное мною, читаете, и, если я хороший писатель, у Вас в голове возникает та же самая картина, которая была у меня в момент написания».
Отличные слова! А теперь «внимание, вопрос». Continue reading

Снижение человеческого фактора

Самой ненадежной частью функционирования любой системы является человек. Эта истина была известна еще задолго до возникновения информационных технологий и во все времена активно использовалась политиками, разведками и управленцами всех уровней.
Если вопрос стоит о серьезном повышении надежности системы, то человеческий фактор из неё нужно убирать полностью.
Разумеется, убрать полностью человеческий фактор невозможно. Поэтому рассмотрим методы снижения его влияния на функционирование системы.
Замена исполнения ручных операций на скрипты. Это простой способ, который иногда применяется в современных компаниях. Смысл этого способа заключается в том, что все операции, которые необходимо провести на продуктивной среде, сначала записываются в виде скрипта и прогоняются через тестовую среду. После прохождения успешного тестирования, тот же самый скрипт выполняется по «боевым» системам. Continue reading

Надежность аппаратных и программных компонент

Какую бы статистику не приводили вендоры по надежности своих решений, какие бы гарантии они не давали, железо всё равно будет выходить из строя. При работе некритичных приложений, где допустимое время простоя может достигать несколько часов, вполне допустимо иметь запасное оборудование в холодном резерве, а также набор программного обеспечения для быстрого развертывания системы «с нуля». Для этого поможет качественно организованные библиотеки DHS и DSL (Definitive Hardware Store и Definitive Software List), которые позволяют иметь в готовности протестированное аппаратное обеспечение и полный комплект системного и прикладного ПО.
Для критических информационных систем такого решения будет недостаточно. Если разговор идет про планируемую доступность более 99,9%, то здесь необходимо рассчитывать на то, сбой аппаратной компоненты не должен приводить к прерыванию предоставления бизнес-сервиса. В этом случае рассматриваются решения следующих типов: Continue reading

Структура процессной документации

Рассмотрим структуру документов, из которых состоит процесс, для максимально удобного формирования и обновления. Необходимо разделить три уровня документов.
Четвертый уровень: записи объектов процесса: журналы и реестры, здесь не рассматриваем.
Первый уровень — «Положение о процессе». Это общий «обвязочный» документ. Количество — один на каждый процесс. Состав: Continue reading