Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

«Эрик рассказал мне во время MRP-8, как время ожидания зависит от использования ресурсов. По его словам, время ожидания — это процент времени занятости, поделенное на процент свободного времени. Другими словами, если ресурс занят половину времени, другую половину он свободен. Время ожидания тогда — 50 % делить на 50 %, то есть одна единица. Будем считать ее равной одному часу.

Значит, в среднем наша задача будет ждать в очереди один час, прежде чем сможет выполниться.

С другой стороны, если ресурс занят 90 % времени, время ожидания — 90 %, деленное на 10 %, или девять часов. Другими словами, наша задача будет ждать в очереди в девять раз дольше, чем если бы ресурс был занят наполовину.

Я завершаю мысль. Все это значит, что при условии, что передача задачи между инстанциями у нас происходит семь раз и что каждый из ресурсов занят 90 % времени, задачи проведут в очереди в сумме девять часов умножить на семь шагов.

“Что? Шестьдесят три часа только на ожидание в очереди? — недоверчиво говорит Уэс. — Невозможно!”

Патти с усмешкой отвечает: “О, ну конечно. Это ведь всего лишь тридцать секунд ввода команды, да?”»

Билл и команда отдают себе отчет, что «простое задание на полчаса» на самом деле требует семи передач по разным инстанциям (например, командам по серверам, по сетевым соединениям, по базам данных, команде виртуализации и, конечно же, Бренту, «звездному» инженеру).

При условии, что все производственные участки были заняты 90 % времени, на рисунке видно, что среднее время ожидания на каждом участке — девять часов. А поскольку задача должна пройти через семь участков, суммарное время ожидания в семь раз больше: это целых шестьдесят три часа.

Другими словами, суммарная доля полезного времени (также известного как длительность процесса) составляла всего 0,16 % от затраченного времени (тридцать минут, поделенных на шестьдесят три часа). Это значит, что 99,8 % всего времени задача бессмысленно провела в очереди ожидания.

Приложение 5

Мифы об индустриальной безопасности

Десятилетия изучения сложных систем свидетельствуют о том, что контрмеры часто основываются на нескольких мифах. Они описаны в книге Дени Беснара и Эрика Холлнагела Some Myths about Industrial Safety.

• Миф 1: «Ошибки людей — главная причина неполадок и инцидентов».

• Миф 2: «Системы в безопасности, если следовать инструкции».

• Миф 3: «Системы можно улучшить с помощью барьеров и ограничений: чем больше уровней защиты, тем выше безопасность».

• Миф 4: «Анализ сбоев может выявить истинную причину сбоя».

• Миф 5:

«Расследование сбоя — логичное и рациональное определение его причин, основанное на фактах».

• Миф 6: «Безопасность всегда имеет высший приоритет, она никогда не оказывается под угрозой».

Разница между мифами и реальностью показана ниже (табл. 5).

Таблица 5. Две истории

Приложение 6

Шнур-андон компании Toyota

Многие спрашивают: как работа вообще выполняется, если за шнур-андон дергают больше 5000 раз в день? Если быть точным, не каждое срабатывание системы андон приводит к остановке конвейера. Когда кто-нибудь дергает шнур, у руководителя группы, отвечающего за конкретный производственный участок, есть 50 секунд, чтобы разобраться. Если за это время проблема не была решена, собираемый автомобиль пересечет нарисованную на полу линию, и конвейер остановится.

Рис. 48. Шнур-андон компании Тойота

Приложение 7

Коммерческое готовое программное обеспечение