Джин Ким - Руководство по DevOps
- Название:Руководство по DevOps
- Автор:
- Жанр:
- Издательство:Манн, Иванов и Фербер
- Год:2018
- Город:Москва
- ISBN:9785001007500
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джин Ким - Руководство по DevOps краткое содержание
Руководство по DevOps - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Согласно Спиру, цель такого объединения — ограничить проявление проблем, прежде чем они широко распространятся, диагностировать и решить их, чтобы они не смогли появиться снова. «Поступая так, — говорит он, — мы создаем глубокое знание того, как управлять системами, чтобы они делали нашу работу, превращая неизбежное имеющееся вначале незнание в знание».
Пример — шнур Toyota Andon (далее в качестве равнозначного будет использоваться термин «шнур-андон»). На заводах Toyota на каждом рабочем месте натянут сигнальный шнур, всех работников и менеджеров учат дергать за него, когда что-то выходит из строя, например деталь имеет дефект, нужная деталь отсутствует или работа занимает больше времени, чем положено по графику [32].
Когда кто-то дергает шнур-андон, руководитель команды или подразделения получает сигнал тревоги и немедленно начинает работать над устранением проблемы. Если ее не удается решить за определенное время (например, за 55 секунд), то конвейер останавливается и весь цех приходит на помощь, чтобы решить проблему, пока не будет разработано эффективное средство ее преодоления.
Вместо того чтобы ходить вокруг да около или планировать поиск решения проблемы на тот момент, «когда у нас будет больше времени», мы объединяемся, чтобы исправить ситуацию немедленно, — это практически полная противоположность описанной выше ситуации на заводе General Motors во Фримонте. Объединиться, решая проблему, необходимо по следующим причинам.
• Это предотвращает такое развитие событий, когда усилия, требуемые на решение проблемы, и стоимость решения растут по экспоненте и накапливается технический долг.
• Это предотвращает начало выполнения новых заданий на рабочих местах, а эти новые задания могут внести в деятельность системы новые ошибки.
• Если проблема не будет решена, то на следующей операции (например, спустя 55 секунд) могут возникнуть те же проблемы на тех же рабочих местах. Однако они потребуют больше исправлений и дополнительной работы (см. приложение 6).
Подобную практику можно противопоставить общепринятой, поскольку мы намеренно позволяем локальным проблемам нарушить общий ход выполнения операции. Однако объединение вокруг решения проблемы дает возможность проводить обучение. Это предотвращает потерю критически важной информации из-за забывчивости или изменения обстоятельств. Это особенно важно в сложных системах, где многие проблемы возникают по причине неожиданного и прихотливого сплетения взаимодействия людей, процессов, продукции, места и обстоятельств. И через некоторое время практически невозможно определить, что же именно произошло, когда возникла проблема.
Как отмечает Спир, объединиться вокруг проблемы — это часть программы «учиться распознавать проблемы в реальном времени, определять их причины… и лечить (принимать контрмеры или корректировать производственный процесс). Это обычная практика цикла Стюарта (планирование — действие — проверка — корректировка), популяризированного Эдвардсом Демингом, но форсированного до сверхзвуковой скорости».
Исправить ситуацию до того, как произойдет катастрофа, можно, только объединившись вокруг небольшой проблемы, обнаруженной на раннем этапе. Другими словами, если атомный реактор начал плавиться, уже поздно пытаться избежать неблагоприятных последствий.
Чтобы обеспечить быструю обратную связь в технологическом потоке создания ценности, мы должны создать эквивалент шнура-андон и соответствующей обратной связи. Это требует также формирования производственной культуры, делающей использование шнура неопасным для того, кто за него потянул. Наоборот, поощряется сигнал, что нечто выходит из строя, будь то сбой в производстве или обнаружение ошибки, возникшей на предыдущих этапах, например, если кто-то вносит изменение, нарушающее непрерывный процесс сборки или тестирования.
Когда срабатывает триггер вышеупомянутого шнура-андон, мы собираемся вместе, чтобы решить проблему и предотвратить переход к новой фазе, пока сбой не будет устранен. Это обеспечивает быструю обратную связь для всех, кто задействован в потоке создания ценности (особенно для работника, повинного в сбое), позволяет быстро локализовать и диагностировать проблему, предотвращает дальнейшее накопление усложняющих факторов, скрывающих причину и следствие.
Предотвращая переход к новой фазе, мы осуществляем непрерывную интеграцию и развертывание — единый процесс в технологическом потоке создания ценности. Все изменения, проходящие непрерывную проверку сборки и интеграции, развертываются в производство, а любые изменения, заставляющие наши тесты «дернуть за шнур-андон», объединяют вокруг себя работников.
Мы можем поневоле закрепить небезопасную систему, если не будем активно реагировать на аварии и происшествия. В сложных системах добавить проверок и этапов утверждения — значит увеличить и вероятность будущих сбоев. Полезность процессов утверждения уменьшается, если мы принимаем решение не там, где выполняем проект. Это не только снижает качество, но и увеличивает время, и ослабляет обратную связь между причиной и следствием, и уменьшает нашу способность извлекать уроки из успехов и неудач [33].
Подобное можно наблюдать даже в небольших и не очень сложных системах. Обычно иерархическая бюрократическая система управления неэффективна, когда несовпадение того, «кто должен это сделать», и того, «кто в действительности это делает», воздействует слишком сильно из-за недостаточной прозрачности и несвоевременности действий.
В качестве примеров неэффективного контроля качества можно привести следующие ситуации:
• требование к другой команде — выполнение трудоемких, подверженных ошибкам и исполняемых вручную задач, хотя их легко автоматизировать и запускать по мере необходимости, когда первая команда нуждается в выполненной работе;
• требуется утверждение результата другим человеком, занятым другими задачами и находящимся далеко от места выполнения работы, что вынуждает его принимать недостаточно компетентные решения или просто автоматически завизировать присланный документ;
• создание больших объемов документации с ненужными подробностями, устаревающими практически сразу после того, как записаны;
• раздача больших объемов работы в группы и специальные комитеты для утверждения и обработки и затем длительное ожидание ответа.
Вместо этого нужно, чтобы каждый человек, занятый в потоке создания ценности, искал и исправлял проблемы в своей зоне ответственности в рамках повседневной работы. Тем самым мы передаем исполнителю ответственность за качество и безопасность труда, чтобы работа фактически выполнялась, а не полагаемся на утверждение документов руководителями, находящимися на отдалении.
Читать дальшеИнтервал:
Закладка: