Джин Ким - Руководство по DevOps

Тут можно читать онлайн Джин Ким - Руководство по DevOps - бесплатно ознакомительный отрывок. Жанр: Интернет, издательство Манн, Иванов и Фербер, год 2018. Здесь Вы можете читать ознакомительный отрывок из книги онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.
  • Название:
    Руководство по DevOps
  • Автор:
  • Жанр:
  • Издательство:
    Манн, Иванов и Фербер
  • Год:
    2018
  • Город:
    Москва
  • ISBN:
    9785001007500
  • Рейтинг:
    2.5/5. Голосов: 21
  • Избранное:
    Добавить в избранное
  • Отзывы:
  • Ваша оценка:
    • 60
    • 1
    • 2
    • 3
    • 4
    • 5

Джин Ким - Руководство по DevOps краткое содержание

Руководство по DevOps - описание и краткое содержание, автор Джин Ким, читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru
Профессиональное движение DevOps зародилось в 2009 году. Его цель — настроить тесные рабочие отношения между разработчиками программного обеспечения и отделами IT-эксплуатации. Внедрение практик DevOps в повседневную жизнь организации позволяет значительно ускорить выполнение запланированных работ, увеличить частоту релизов, одновременно повышая безопасность, надежность и устойчивость производственной среды. Эта книга представляет собой наиболее полное и исчерпывающее руководство по DevOps, написанное ведущими мировыми специалистами.

Руководство по DevOps - читать онлайн бесплатно ознакомительный отрывок

Руководство по DevOps - читать книгу онлайн бесплатно (ознакомительный отрывок), автор Джин Ким
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Согласно Спиру, цель такого объединения — ограничить проявление проблем, прежде чем они широко распространятся, диагностировать и решить их, чтобы они не смогли появиться снова. «Поступая так, — говорит он, — мы создаем глубокое знание того, как управлять системами, чтобы они делали нашу работу, превращая неизбежное имеющееся вначале незнание в знание».

Пример — шнур Toyota Andon (далее в качестве равнозначного будет использоваться термин «шнур-андон»). На заводах Toyota на каждом рабочем месте натянут сигнальный шнур, всех работников и менеджеров учат дергать за него, когда что-то выходит из строя, например деталь имеет дефект, нужная деталь отсутствует или работа занимает больше времени, чем положено по графику [32].

Когда кто-то дергает шнур-андон, руководитель команды или подразделения получает сигнал тревоги и немедленно начинает работать над устранением проблемы. Если ее не удается решить за определенное время (например, за 55 секунд), то конвейер останавливается и весь цех приходит на помощь, чтобы решить проблему, пока не будет разработано эффективное средство ее преодоления.

Вместо того чтобы ходить вокруг да около или планировать поиск решения проблемы на тот момент, «когда у нас будет больше времени», мы объединяемся, чтобы исправить ситуацию немедленно, — это практически полная противоположность описанной выше ситуации на заводе General Motors во Фримонте. Объединиться, решая проблему, необходимо по следующим причинам.

• Это предотвращает такое развитие событий, когда усилия, требуемые на решение проблемы, и стоимость решения растут по экспоненте и накапливается технический долг.

• Это предотвращает начало выполнения новых заданий на рабочих местах, а эти новые задания могут внести в деятельность системы новые ошибки.

• Если проблема не будет решена, то на следующей операции (например, спустя 55 секунд) могут возникнуть те же проблемы на тех же рабочих местах. Однако они потребуют больше исправлений и дополнительной работы (см. приложение 6).

Подобную практику можно противопоставить общепринятой, поскольку мы намеренно позволяем локальным проблемам нарушить общий ход выполнения операции. Однако объединение вокруг решения проблемы дает возможность проводить обучение. Это предотвращает потерю критически важной информации из-за забывчивости или изменения обстоятельств. Это особенно важно в сложных системах, где многие проблемы возникают по причине неожиданного и прихотливого сплетения взаимодействия людей, процессов, продукции, места и обстоятельств. И через некоторое время практически невозможно определить, что же именно произошло, когда возникла проблема.

Как отмечает Спир, объединиться вокруг проблемы — это часть программы «учиться распознавать проблемы в реальном времени, определять их причины… и лечить (принимать контрмеры или корректировать производственный процесс). Это обычная практика цикла Стюарта (планирование — действие — проверка — корректировка), популяризированного Эдвардсом Демингом, но форсированного до сверхзвуковой скорости».

Исправить ситуацию до того, как произойдет катастрофа, можно, только объединившись вокруг небольшой проблемы, обнаруженной на раннем этапе. Другими словами, если атомный реактор начал плавиться, уже поздно пытаться избежать неблагоприятных последствий.

Чтобы обеспечить быструю обратную связь в технологическом потоке создания ценности, мы должны создать эквивалент шнура-андон и соответствующей обратной связи. Это требует также формирования производственной культуры, делающей использование шнура неопасным для того, кто за него потянул. Наоборот, поощряется сигнал, что нечто выходит из строя, будь то сбой в производстве или обнаружение ошибки, возникшей на предыдущих этапах, например, если кто-то вносит изменение, нарушающее непрерывный процесс сборки или тестирования.

Когда срабатывает триггер вышеупомянутого шнура-андон, мы собираемся вместе, чтобы решить проблему и предотвратить переход к новой фазе, пока сбой не будет устранен. Это обеспечивает быструю обратную связь для всех, кто задействован в потоке создания ценности (особенно для работника, повинного в сбое), позволяет быстро локализовать и диагностировать проблему, предотвращает дальнейшее накопление усложняющих факторов, скрывающих причину и следствие.

Предотвращая переход к новой фазе, мы осуществляем непрерывную интеграцию и развертывание — единый процесс в технологическом потоке создания ценности. Все изменения, проходящие непрерывную проверку сборки и интеграции, развертываются в производство, а любые изменения, заставляющие наши тесты «дернуть за шнур-андон», объединяют вокруг себя работников.

Продолжайте, улучшая качество кода

Мы можем поневоле закрепить небезопасную систему, если не будем активно реагировать на аварии и происшествия. В сложных системах добавить проверок и этапов утверждения — значит увеличить и вероятность будущих сбоев. Полезность процессов утверждения уменьшается, если мы принимаем решение не там, где выполняем проект. Это не только снижает качество, но и увеличивает время, и ослабляет обратную связь между причиной и следствием, и уменьшает нашу способность извлекать уроки из успехов и неудач [33].

Подобное можно наблюдать даже в небольших и не очень сложных системах. Обычно иерархическая бюрократическая система управления неэффективна, когда несовпадение того, «кто должен это сделать», и того, «кто в действительности это делает», воздействует слишком сильно из-за недостаточной прозрачности и несвоевременности действий.

В качестве примеров неэффективного контроля качества можно привести следующие ситуации:

• требование к другой команде — выполнение трудоемких, подверженных ошибкам и исполняемых вручную задач, хотя их легко автоматизировать и запускать по мере необходимости, когда первая команда нуждается в выполненной работе;

• требуется утверждение результата другим человеком, занятым другими задачами и находящимся далеко от места выполнения работы, что вынуждает его принимать недостаточно компетентные решения или просто автоматически завизировать присланный документ;

• создание больших объемов документации с ненужными подробностями, устаревающими практически сразу после того, как записаны;

• раздача больших объемов работы в группы и специальные комитеты для утверждения и обработки и затем длительное ожидание ответа.

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

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать


Джин Ким читать все книги автора по порядку

Джин Ким - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




Руководство по DevOps отзывы


Отзывы читателей о книге Руководство по DevOps, автор: Джин Ким. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x