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

Интервал:

Закладка:

Сделать

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

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

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

Постоянно выявлять затруднения и стремиться их разрешать

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

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

• обнаружить затруднения в работе системы;

• определить, что следует улучшить в месте затруднения;

• подчинить все остальные задачи решению проблемы;

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

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

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

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

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

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

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

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

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

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

Исключить затруднения и потери в потоке создания ценности

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

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

Интервал:

Закладка:

Сделать


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

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




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


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


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

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