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

Интервал:

Закладка:

Сделать

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

Практический пример
Автоматизированные изменения инфраструктуры как стандартные изменения в компании Salesforce.com (2012 г.)

Компания Salesforce.com была основана в 2000 г., ее целью было сделать управление взаимоотношениями с клиентами легкодоступным и легко поставляемым сервисом. Предложения организации были широко востребованы на рынке, результатом чего стало успешное IPO [172]в 2004 г. К 2007 г. у компании было более 59 000 клиентов, в день ее сервисы обрабатывали сотни миллионов транзакций, а годовой доход достиг 497 миллионов долларов.

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

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

На конференции DevOps Enterprise Summit в 2014 г. Дэйв Мангот и Рина Мэтью описали занявшую много лет DevOps-трансформацию компании, начавшуюся в 2009 г. Согласно Манготу и Мэтью, применяя принципы и методики DevOps, в 2013 г. организация сократила среднее время развертывания с шести дней до пяти минут. В результате стало легче масштабировать ресурсы, что позволило их сервисам обрабатывать более миллиарда транзакций в день.

Одной из главных тем трансформации компании Salesforce было стремление сделать качество ответственностью всех сотрудников, вне зависимости от того, работали ли они в разработке, эксплуатации или информационной безопасности. Для этого встроили автоматизированное тестирование во все стадии создания приложений и сред, а также во все процессы непрерывной интеграции и развертывания и создали инструмент с открытым кодом под названием Rouster, чтобы проводить функциональное тестирование своих модулей Puppet.

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

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

Для Мангот и Мэтью одним из важнейших результатов этого сурового процесса было то, что группа по управлению изменениями сказала им, что «изменения инфраструктуры, сделанные с помощью Puppet, теперь будут классифицироваться как “стандартные изменения”, для их внедрения не нужно будет одобрения комитета». Кроме того, было отмечено, что «изменения, вносимые в инфраструктуру вручную, все равно должны будут проходить процедуру одобрения».

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

Уменьшите зависимость от разделения обязанностей

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

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

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

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

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

Практический пример
Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)

[173]

Билл Мэсси работает руководителем разработки в компании Etsy и отвечает за приложение оплаты под названием ICHT (аббревиатура от I Can Haz Tokens [174]). ICHT проводит заказы клиентов через набор внутренних приложений обработки платежей: они принимают онлайн-заказ, выделяют информацию о платежной карте клиента, маркируют ее, отсылают платежной системе и завершают транзакцию [175].

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

Интервал:

Закладка:

Сделать


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

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




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


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


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

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