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

Интервал:

Закладка:

Сделать

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

В своей книге «Бережливое производство программного обеспечения. От идеи до прибыли» [28]Мэри и Том Поппендик описывают потери и задержки в потоке разработки программного обеспечения как то, что вызывает задержки у клиента, — например, действия, которые можно не выполнять без ущерба для результата.

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

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

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

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

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

Ожидание: любые задержки, требующие ресурсов: приходится ждать, пока они не освободятся. Задержки увеличивают время цикла и не дают клиенту получать ценность.

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

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

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

Геройство: чтобы организация могла достичь своих целей, отдельные лица или группы вынуждены порой выполнять чрезвычайные действия. Они могут даже стать частью повседневной деятельности (например, устранение проблем с производством, возникших в два часа ночи, создание сотен заявок на поддержку как обычную составляющую часть каждого выпуска ПО в производство) [29].

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

Заключение

Улучшение процесса протекания технологического потока создания ценности много значит для получения результатов с помощью DevOps. Это достигается за счет того, что деятельность становится прозрачной, ограничивается НзП, уменьшаются размер партии и количество передач от сотрудника к сотруднику. Затем, в ходе повседневной работы, они устраняются.

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

Глава 3. Второй путь: принципы обратной связи

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

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

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

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

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

Безопасная работа в сложных системах

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

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

Интервал:

Закладка:

Сделать


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

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




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


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


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

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