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

Интервал:

Закладка:

Сделать

Доктор Чарльз Перроу изучал аварию на АЭС Three Mile Island и отметил: никто не сумел бы предположить, как реактор поведет себя во всех обстоятельствах, каким образом он может выйти из строя. Проблема скрывалась в одном элементе, который было сложно отделить от других, и быстро и непредсказуемо распространялась.

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

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

Доктор Стивен Спир, защитивший в Гарвардской школе бизнеса диссертацию, посвященную расшифровке механизма производственной системы Toyota, заявил: разработка абсолютно безопасных систем лежит, скорее всего, за пределами наших способностей, но мы можем сделать сложные системы более безопасными при выполнении следующих четырех условий [30]:

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

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

• знания, полученные в одном из подразделений, используются во всей организации;

• лидеры готовят других лидеров, и возможности организации постоянно увеличиваются.

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

Видеть проблемы сразу после появления

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

Мы можем сделать это, создав петли обратной и прямой связи в системе работы. Доктор Питер Сенге в книге «Пятая дисциплина. Искусство и практика самообучающейся организации» [31]описал петли обратной связи как чрезвычайно важную часть процесса обучения мышлению в категориях организаций и систем. Петли обратной и прямой связи дают возможность компонентам системы взаимно усиливать или нейтрализовать друг друга.

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

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

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

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

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

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

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

Как сказала Элизабет Хендрисон, технический директор компании Pivotal Software и автор книги Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing, «когда я возглавляла подразделение тестирования, я описывала свою работу как “создание циклов обратной связи”. Обратная связь — важнейший фактор, поскольку она позволяет управлять разработкой. Мы должны постоянно сверять нужды клиентов с нашими стремлениями и тем, что у нас получается. Тестирование — это лишь одна из форм обратной связи».

Объединиться вокруг проблемы и решить ее, добывая новое знание

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

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

Интервал:

Закладка:

Сделать


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

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




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


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


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

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