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

Интервал:

Закладка:

Сделать

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

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

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

Фокус на времени развертывания

В остальной части книги сосредоточимся на такой составной части потока создания ценности, как сокращенное время развертывания. Начинается оно тогда, когда некий инженер [22]из команды потока создания ценностей (включающей разработчиков, тестировщиков, отделы эксплуатации и информационной безопасности) получает изменения от системы контроля версий. А заканчивается, когда изменение начинает успешно работать в производственной среде, создавая продукт для клиентов и генерируя обратную связь и телеметрию.

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

Мы не любители больших порций работы, последовательно проходящих через такие части потока создания ценности, как «проектирование и разработка», а затем через поток «тестирование и производство» (например, когда используется большой водопадный процесс или долго живущая функциональная ветвь кода). Напротив, мы стремимся, чтобы тестирование и производство выполнялись одновременно с проектированием и разработкой. Так обеспечиваются быстрый ход потока и высокое качество. Этот метод успешен, если исполнение осуществляется по небольшим частям и качество обеспечивается на каждом этапе потока создания ценностей [23].

Определения: «время выполнения заказа» и «время производства»

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

Если отсчет времени выполнения заказа начинается в момент оформления и заканчивается при выполнении, то время производства отсчитывается с момента, когда мы начинаем работу над заказом, точнее, не засчитывается тот период времени, когда заказ стоял в очереди на выполнение (рис. 2).

Рис 2 Время выполнения заказа и время производства Поскольку время выполнения - фото 3

Рис. 2. Время выполнения заказа и время производства

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

Обычный сценарий: развертывание требует месяцев

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

Рис 3 Поток технологической ценности при продолжительности внедрения длиной в - фото 4

Рис. 3. Поток технологической ценности при продолжительности внедрения длиной в три месяца (пример взят из вышедшей в 2015 г. книги Дэмона Эдвардса DevOps Kaizen)

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

Идеал DevOps — развертывание за минуты

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

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

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

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

Интервал:

Закладка:

Сделать


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

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




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


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


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

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