Руководство по DevOps - [143]
«Эрик рассказал мне во время MRP-8, как время ожидания зависит от использования ресурсов. По его словам, время ожидания — это процент времени занятости, поделенное на процент свободного времени. Другими словами, если ресурс занят половину времени, другую половину он свободен. Время ожидания тогда — 50 % делить на 50 %, то есть одна единица. Будем считать ее равной одному часу.
Значит, в среднем наша задача будет ждать в очереди один час, прежде чем сможет выполниться.
С другой стороны, если ресурс занят 90 % времени, время ожидания — 90 %, деленное на 10 %, или девять часов. Другими словами, наша задача будет ждать в очереди в девять раз дольше, чем если бы ресурс был занят наполовину.
Я завершаю мысль. Все это значит, что при условии, что передача задачи между инстанциями у нас происходит семь раз и что каждый из ресурсов занят 90 % времени, задачи проведут в очереди в сумме девять часов умножить на семь шагов.
“Что? Шестьдесят три часа только на ожидание в очереди? — недоверчиво говорит Уэс. — Невозможно!”
Патти с усмешкой отвечает: “О, ну конечно. Это ведь всего лишь тридцать секунд ввода команды, да?”»
Билл и команда отдают себе отчет, что «простое задание на полчаса» на самом деле требует семи передач по разным инстанциям (например, командам по серверам, по сетевым соединениям, по базам данных, команде виртуализации и, конечно же, Бренту, «звездному» инженеру).
При условии, что все производственные участки были заняты 90 % времени, на рисунке видно, что среднее время ожидания на каждом участке — девять часов. А поскольку задача должна пройти через семь участков, суммарное время ожидания в семь раз больше: это целых шестьдесят три часа.
Другими словами, суммарная доля полезного времени (также известного как длительность процесса) составляла всего 0,16 % от затраченного времени (тридцать минут, поделенных на шестьдесят три часа). Это значит, что 99,8 % всего времени задача бессмысленно провела в очереди ожидания.
Десятилетия изучения сложных систем свидетельствуют о том, что контрмеры часто основываются на нескольких мифах. Они описаны в книге Дени Беснара и Эрика Холлнагела Some Myths about Industrial Safety.
• Миф 1: «Ошибки людей — главная причина неполадок и инцидентов».
• Миф 2: «Системы в безопасности, если следовать инструкции».
• Миф 3: «Системы можно улучшить с помощью барьеров и ограничений: чем больше уровней защиты, тем выше безопасность».
• Миф 4: «Анализ сбоев может выявить истинную причину сбоя».
• Миф 5: «Расследование сбоя — логичное и рациональное определение его причин, основанное на фактах».
• Миф 6: «Безопасность всегда имеет высший приоритет, она никогда не оказывается под угрозой».
Разница между мифами и реальностью показана ниже (табл. 5).
Таблица 5. Две истории
Многие спрашивают: как работа вообще выполняется, если за шнур-андон дергают больше 5000 раз в день? Если быть точным, не каждое срабатывание системы андон приводит к остановке конвейера. Когда кто-нибудь дергает шнур, у руководителя группы, отвечающего за конкретный производственный участок, есть 50 секунд, чтобы разобраться. Если за это время проблема не была решена, собираемый автомобиль пересечет нарисованную на полу линию, и конвейер остановится.
Рис. 48. Шнур-андон компании Тойота
На данный момент, чтобы встроить сложное коммерческое готовое программное обеспечение (commercial off-the-shelf, COTS; например SAP, IBM WebSphere, Oracle WebLogic) в систему контроля версий, придется, возможно, прекратить использовать графические инструменты установки, предоставляемые поставщиком. Для этого нужно разобраться, что именно делает установщик. Возможно, потребуется сделать установку на чистый образ сервера, сравнить файловые системы и ввести добавленные файлы в систему контроля версий. Файлы, не меняющиеся в зависимости от среды, помещаются в одно место («базовая установка»), тогда как специфичные для разных сред помещаются в отдельные папки («тест» или «эксплуатация»). Так установка программ становится просто операцией в системе контроля версий. Прозрачность, повторяемость и скорость операций улучшаются.
Также, вероятно, придется изменить настройки конфигурации приложений, чтобы они были в системе контроля версий. Например, можно преобразовать конфигурации приложений, хранящихся в базе данных, в XML-файлы, или наоборот.
Ниже приведен простой план совещания по разбору для послеаварийной ретроспективы.
• В самом начале руководитель встречи или координатор произносит небольшую вступительную речь, подчеркивая, что сегодня никто не будет искать виноватых, сосредоточиваться на прошедших событиях или рассуждать о том, что могло бы или должно было быть. Координатор может прочитать главную директиву разбора ошибок (Retrospective Prime Directive)[184] с сайта Retrospective.com.
Кроме того, координатор должен напомнить всем, что у контрмер должен быть конкретный исполнитель. Если по окончании совещания контрмера не оказывается приоритетной, то это не контрмера (так делается, чтобы не создавать длинный список хороших идей, которые никогда не воплотятся в жизнь).
