Методология DevOPs

Принципы и практическое применение

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

На самом деле, эта библиотека породила целую парадигму управления ИТ-

инфраструктурой компании, основанную на SLA (соответствие обещаний
поставщика услуги ожиданиям клиента) и ITSM (IT Service Management, управление
ИТ-услугами). ITSM — это концепция организации работы ИТ-подразделения и его
взаимодействия с внешним или внутренним заказчиком, а также внешними
контрагентами.
Обзор методологий
 Обзор методологий
ITSM сам по себе ИТ-проект, поэтому, как и все остальные проекты, имеет свои
преимущества и недостатки. Использование методов ITSM даёт возможность делать сервис
дешевле и оперативнее, а работу ИТ-подразделения прозрачнее, что особенно ценно в
многофилиальных и холдинговых организациях. Также есть ещё один момент, который в век
стартапов и буквально молниеносного роста новых типов бизнеса вышел за пределы
интересов крупных организаций — это возможность сертификации по ISO 20000,
международному стандарту для управления и обслуживания ИТ-сервисов. Полезная штука,
если вы претендуете на кусок рынка и ищете себе инвестора.
Теперь о рисках. Понятно, что стандарты ITSM и библиотека ITIL описывают лучшие практики
и при ознакомлении с ними кажется, что всё логично и именно так работать и должно.
 Если принимать все положения как есть, без привязки к текущему положению дел в
бизнесе в целом и в ИТ-службе в частности, можно прийти к излишней формализации и
значительному нарушению работы. Процесс внедрения принципов ITIL должен быть
избирательным и адаптивным.
 Опять же, перед изменением подхода к управлению следует провести глубокий анализ
процессов, происходящих внутри ИТ-инфраструктуры — если всё работает и
очевидных путей и потребностей улучшения нет, лучше подойти к ITSM избирательно и
внедрять самые ценные и нужные принципы: управление лицензиями (SAM), управление
конфигурациями или просто наладить мониторинг.
 Если нет внятной цели использования принципов ITIL, то лучше отказаться от затеи.
Внятные цели — это, например, изменение политики управления лицензиями или
решение проблемы использования сотрудниками пиратского софта. Невнятная цель —
внедрить и применить то, что навязали сверху, потому что услышали на конференции.
Обзор методологий
CobiT (Control Objectives for Information and Related Technologies, задачи
управления для информационных и смежных технологий) — сбор
стандартов и руководств в области управления ИТ-аудита и безопасности;
руководство и сборник практик по управлению ИТ-процессами. Связанный с
ITIL инструмент, который непрерывно обновляется и предназначен для того,
чтобы между руководством компании, ИТ-специалистами и аудиторами
(внешними и внутренними) царили мир и взаимопонимание. Проще говоря,
управляющий менеджер должен понимать все ИТ-риски, в том числе
связанные с бездействием в ситуациях, требующих коррекции, а также
потенциальные риски, связанные с использованием того или иного элемента
ИТ-инфраструктуры компании.
Обзор методологий
Рассмотрим две распространённые ситуации.

Ситуация первая. У руководства компании может отсутствовать понимание

того, что происходит в ИТ-пространстве, но при этом быть полное понимание
целей и миссии бизнеса, процессов, продукта и услуг. И наоборот, ИТ-
директор может фанатично строить идеальную ИТ-инфраструктуру,
практически не интересуясь тем, как она вписывается в стратегию развития
компании. И случается такое нередко именно в самом уязвимом слое —
среднем бизнесе, который ещё не достиг нового уровня управления (как
гигант), но уже пережил разрастание служб и разрыв простых и внятных
внутрифирменных коммуникаций, присущих малому бизнесу. А между тем,
такое положение вещей не снимает с руководителя ответственность
абсолютно за все процессы в компании, в том числе происходящие в ИТ.
Обзор методологий
Ситуация вторая, свойственная компаниям любого уровня: от
микробизнеса до транснациональных корпораций, —
неадекватная оценка рисков. Почти каждый из нас хоть раз
встречался с рисками завышенного масштаба: например,
страх перед DDoS в небольшой компании или всем известная
и так и не ставшая реальностью «проблема 2000». Это риски,
которым придают огромное значение и которые не несут
объективной угрозы. С другой стороны, существуют
недооценённые риски, на которые никто не обращает
внимание, но именно они способны положить весь рабочий
процесс или принести коммерческий ущерб:
неограниченный срок действия учётных записей и паролей
пользователей от рабочих ПК и корпоративных
информационных систем, клиент-банков; передача
коммерчески значимых данных по незащищённым каналам;
отсутствие антивирусов и проч.
Обзор методологий
В свете этих ситуаций вернёмся к CobiT. В нём описаны цели, задачи и
принципы управления, объекты управления, ИТ-процессы, инструменты
работы с ИТ-инфраструктурой, а также вопросы ИТ-безопасности. Актуальную
версию CobiT и статьи по нему можно почитать на сайте ISACA (есть платные
и бесплатные материалы). CobiT можно определить как методологию
корпоративного управления ИТ, которая:
 ориентирована на реальные бизнес-требования;
 поддерживает процессный подход к управлению ИТ-инфраструктурой и
контролирует процессы;
 оценивает эффективность ИТ в компании.
Кроме того, CobiT соответствует стандартам ISO 9000 и ISO/IEC 17799,
стандарту информационной безопасности и менеджмента ИБ. С помощью
принципов CobiT можно минимизировать риски и контролировать отдачу
инвестиций в ИТ.
Обзор методологий
CobiT хорошо структурирован и в поле зрения этого свода правил попадают
планирование, организация, приобретение, внедрение, эксплуатация и
сопровождение, а также мониторинг и оценка пяти важнейших элементов
каждой компании (согласно определения CobiT, ресурсов ИТ).
 Данные — информация внутри компании в любом виде, медиафайлы,
внешняя информация.
 Приложения — множество автоматизированных и ручных процедур.
 Технология — программное обеспечение, аппаратное обеспечение,
СУБД, СУ сетями, ОС.
 Оборудование — ресурсы, поддерживающие технологию.
 Люди — персонал с навыками и умениями, в том числе контроля и
мониторинга.
Обзор методологий
 Обзор методологий
То есть фактически CobiT исходит из понимания того, что ИТ-инфраструктура —
это управление информацией, а согласно своду информация оценивается по
нескольким критериям:
 продуктивность — обеспечение доступности информации с помощью
максимально экономичного и продуктивного использования ресурсов
 эффективность — актуальность и своевременность информации
 конфиденциальность — обеспечение защиты информации от
несанкционированного доступа
 целостность — достоверность, полнота и точность информации
 согласованность — соответствие законодательству, подзаконным нормативно-
правовым актам и локальным нормам (указам, договорам, уставу и т.д.)
 пригодность и простота доступа — возможность получения и использования
информации для управления бизнес-процессами
 надёжность — свойство информации отражать реальное положение дел,
необходимое для принятия управленческих (в т.ч. финансовых) решений.
Так как же соотносятся CobiT и ITIL? ITIL — библиотека лучших практик
предоставления услуг в сфере ИТ, а CobiT — больше по части управления и аудита
ИТ. Соответственно, все процессы, описанные в ITIL, могут управляться и
подвергаться аудиту стандартом CobiT.
Обзор методологий
DevOps связан с ITIL (в некоторых источниках считается прямым следствием),
покрывается CobiT, но имеет совершенно другую парадигму подход к
системному администрированию DevOps. Впрочем, сама расшифровка
названия указывает на то, что это гибрид на стыке администрирования и
разработки (development и operations). Методология DevOps соединяет в
себе труд разработчиков и ИТ-инженеров (это могут быть сформированные
команды, отдельные люди или даже один человек), тем самым обеспечивая
быстрые темпы развёртывания, надёжность и безопасность production-среды
(включая тестирование). Говоря проще, эта методология исключила
распространённую фразу, ставшую мемом: «Проблема на стороне
железа/софта».
 Обзор методологий
DevOps отлично вписался в Agile-методологию с частыми билдами и релизами,
хорошо работает в случае развития и тестирования облачных сервисов, а также
непрерывно развивающихся пользовательских приложений (корпоративных
систем, игр, планировщиков, агрегаторов и т.д.), именно поэтому с 2009 года он
хорошо развился и прижился во многих командах как своеобразный тип айтишной
кооперации. Дополнительное преимущество DevOps-методологии ощущается
при использовании разработчиками и инженерами по тестированию виртуальных
машин, конфигурационных файлов, интеграционного и непрерывного
тестирования. Например, при тестировании сервисов IP-телефонии тестировщик
пишет и использует автоматические тесты, сам настраивает схему, виртуальные
машины, репликацию базы данных — фактически это и есть DevOps.
Как методология DevOps даёт множество преимуществ, среди которых:
 стандартизация и автоматизация окружения
 высокая скорость разработки, разворачивания и тестирования
 возможность часто выпускать обновления
 минимизация проблем при внедрениях у заказчика и т.д.
Как видите, DevOps не является подходом чисто к системному
администрированию, соответственно, о его применении идёт речь, в основном, в
компаниях-девелоперах.
Обзор методологий
Идея DevOps состоит в организации постоянного сотрудничества между
командами разработки и операционной работы на основе общих
принципов, руководств и процессов и при поддержке соответствующих
средств автоматизации. Аналитики Forrester определяют DevOps как «набор
процессов, методов и систем для коммуникаций, совместной работы и
интеграции между сотрудниками ИТ-служб, ответственными за разработку
приложений, инфраструктуру и операции и обеспечение качества с целью
современного выпуска программных продуктов и сервисов, отвечающих
поставленным требованиям». Технологический портал Technopedia.com дает
следующее определение: «Термин DevOps в общем смысле означает
комбинацию подходов разработки и операционной работы. Он используется
для обозначения ролей или процессов, которые объединяют команды
разработки и операций для формирования определенной философии
проектного управления, которая обеспечивает более эффективные
взаимосвязи между разработчиками и другими подразделениями».
Место DevOps в жизненном цикле
(традиционное представление)
 Области внедрения DevOps
Модель 1: Углубление процессов разработки в поставку: это включает
расширение непрерывной интеграции и выпуска на боевые сервера, интеграция
тестирования и информзащиты в рабочие процессы, что дает готовый к поставке
код, настроенные среды, и так далее.
Модель 2: Создание обратной связи от прода до разработки: включает создание
полной хронологии событий в разработке и администрировании, с целью помощи
в разрешении проблем, а так же предоставление доступа команде разработки к
анализу проблем на проде, одновременно с созданием разработчиками
сервисов самообслуживания, везде где это возможно, и создание
информационных радиаторов, показывающих изменение в поведении системы
при вносе изменений.
Модель 3: Объединение разработки и администрирования: состоит во включении
команды разработки в цепочку разрешения проблем, назначение разработчиков
на разрешение проблем на проде, а так же взаимные тренинги между
разработчиками и администраторами, чтобы уменьшить количество эскалаций.
Модель 4: Включение ИТ команды в разработку: состоит во включении или тесной
связью между IT и разработкой, создание многоэтапных пользовательских историй
(включая развертывание, управление кодом в производстве и т.д.), и определение
нефункциональных требования, которые могут быть использованы во всех
проектах.
Место DevOps в жизненном цикле
(новый подход)
Инструментальная поддержка
Ускорение процессов выпуска новых решений, стимулирующее адаптацию
принципов DevOps, поддерживается эволюцией инструментальных средств,
которые используют специалисты каждой из групп. Разработчики имеют
широкий спектр инструментария для «скорой» разработки. Для обеспечения
динамики операционной поддержки, соответствующей современной
разработке, нужны инструменты, автоматизирующие выделение системных
ресурсов и управление ими. На это работают развитые средства управления
конфигурациями, виртуализации на разных уровнях, автоматизации
операционных процессов (run book automation), облачные инструменты
выделения ресурсов по требованию. Однако ключевую роль в реализации
DevOps играет интероперабельность и интегрируемость инструментария для
разных групп. Обеспечивая необходимый каждой группе профессиональный
взгляд на задачи жизненного цикла приложения, именно инструментарий
способен при этом предоставить общий язык для их эффективного
сотрудничества и поддержать реализацию общих процессов.
 Инструментальная поддержка
 CASE-средства
 IDE – интегрированная среда разработки
 Elastic, Logstash и Kibana (ELK) – централизованный контроль журналов
 Git – система контроля версий
 Jenkins – система непрерывной интеграции.
 Puppet/Ansible – система управления конфигурациями
 Redmine – система учета требований и багтрекер
 Junit/Nunit – автоматизация создания юнит-тестов
 HP FunctionalTest – система автоматизации функционального
тестирования
 HP LoadRunner – система нагрузочного тестирования
Culture, Automation, Measurement, knowledge Sharing
 Непрерывная поставка ПО
Термин «Непрерывная поставка ПО» (Continuous Delivery, CD) прочно вошел в
обиход в конце 2010 году, после выпуска одноименной книги.
В книге описываются достаточно простые идеи о том, как сделать процесс
поставки ПО таким, чтобы его можно было выкатывать после каждого коммита.
Основная идея CD в том, чтобы построить конвейер (Deployment Pipeline),
позволяющий каждому изменению в системе контроля версий попасть в боевое
окружения стандартным и полностью автоматизированным способом.
Приблизительно это может выглядеть следующим образом:
 Изменения вносятся в систему контроля версий (СКВ).
 Запускается система непрерывной интеграции (Continuous Integration, CI),
собирается билд (если это компилируемый язык), прогоняются все
необходимые тесты.
 В случае успешности предыдущего шага, билд выкатывается на окружение
тестирования (QA).
 После успешного тестирования билд выкатывается на stage окружение (pre-
production), которое максимально приближено к боевому окружению.
 Если все прошло хорошо, то билд попадает в боевое окружение.
Подходы к виртуализации вычислительных ресурсов