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

Интервал:

Закладка:

Сделать

В результате мы оказываемся далеко от желаемых целей. Все в организации недовольны уровнем производительности IT-подразделений. Итог — бюджет урезан, все разочарованы, но понимают, что бессильны изменить ход процесса разработки и добиться заметных результатов [7] Это всего лишь небольшой пример проблем, встречающихся в типичной IT-организации. Прим. авт. . Каким же должно быть решение? Необходимо изменить методы работы, и DevOps — это наилучший способ продвижения вперед.

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

Раньше среднее время выполнения заказа заводом-изготовителем составляло шесть недель, причем без нарушения сроков выполнялось менее 70 % заказов. К 2005 г. благодаря широкому внедрению методов бережливого производства временной показатель сократился менее чем до трех недель, и 95 % заказов выполнялись точно в срок. Организации, не внедрившие принципы бережливого производства, потеряли долю на рынке, а многие вообще ушли из бизнеса.

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

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

Но к 2010 г. в связи с внедрением DevOps и непрекращающейся коммодитизацией [8] Коммодитизация — превращение изделий в обезличенный товар. Прим. перев. компьютерного оборудования, программ, а теперь и облачных технологий новые функции (и даже целые компании-стартапы) могут создаваться за недели и быстро — за часы или даже за минуты — внедряться в производство. Для таких организаций развертывание стало рутинной операцией, практически не содержащей рисков. Появилась возможность проводить эксперименты для проверки бизнес-идей, выясняя, какие из них наиболее ценны для клиентов и самой организации и какие можно быстро превратить в «фичи», а уже их, в свою очередь, быстро и без рисков развернуть на производстве.

Таблица 1. Тенденция к более быстрой, дешевой и имеющей мало рисков поставке программного обеспечения

Источник Презентация Быстрота и объем Скорость выигрывает Адриана Кокрофта - фото 1

Источник: Презентация «Быстрота и объем (Скорость выигрывает)» Адриана Кокрофта на конференции FlowCon в Сан-Франциско, ноябрь 2013 г.

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

Сегодня независимо от того, к какой отрасли относится компания, приобретение клиентов и предоставление им создаваемой ценности зависит от технологичности канала поставки этой ценности. Джеффри Иммелт, исполнительный директор компании General Electric, выразил эту мысль сжато и точно: «Каждая отрасль промышленности и каждая компания, не желающие делать программное обеспечение центром бизнес-стратегии, не имеют будущего». Или, как сказал Джеффри Сновер, технический специалист корпорации Microsoft, «в предыдущие экономические эпохи коммерческие предприятия создавали ценности, перемещая атомы. Теперь они делают это, перемещая биты».

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

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

Проблема: кое-что в вашей организации должно быть улучшено (иначе вы не стали бы читать эту книгу)

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

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

Коренной, хронический конфликт

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

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

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

Интервал:

Закладка:

Сделать


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

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




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


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


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

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