Передовые методики DevOps: Разработка надежного программного обеспечения с помощью DevOps

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

Боб Айелло, консультант и главный редактор, CM Best Practices Consulting (Division of Yellow Spider, Inc)

Боб Айелло - консультант, главный редактор Web-сайта для разработчиков CM Crossroads и соавтор книги "Передовой опыт управления конфигурациями: методики, работающие на практике" (Addison-Wesley Professional, 2010 год (cmbestpractices.com)). Более 25 лет работал в качестве технического менеджера в нескольких ведущих финансовых компаниях Нью-Йорка, отвечая за управление конфигурациями в корпоративных масштабах и часто осуществляя практическую техническую поддержку инструментов управления корпоративным исходным кодом, соблюдения требований SOX/Cobit, инжиниринга сборок, непрерывной интеграции и автоматизированного развертывания приложений. Боб был заместителем председателя рабочей группы по разработке стандартов IEEE 828 (CM Planning) и является членом управленческого совета комитета IEEE Software and Systems Engineering Standards Committee (S2ESC). Имеет степень магистра по промышленной психологии в Нью-Йоркском университете и степень бакалавра по вычислительной технике и математике в университете Хофстра. С ним можно связаться по электронной почте или на LinkedIn.



Лесли Сакс, главный операционный директор, Yellow Spider, Inc.

photo of Leslie SachsЛесли Сакс является сертифицированным школьным психологом штата Нью-Йорк и главным операционным директором компании Yellow Spider, Inc. Лесли является соавтором книги "Передовой опыт управления конфигурациями: методики, работающие на практике", Addison-Wesley Professional. Она имеет более чем 20-летний опыт работы в области клинической и бизнес-психологии, заключающийся в реализации эффективных мер, направленных на совершенствование социальной и образовательной деятельности отдельных индивидуумов и групп. Г-жа Сакс получила степень магистра школьной психологии в Университете Пейс и прошла практику в центре Bellevue Psychiatric Hospital в Нью-Йорке. Твердо веря в уникальность каждого человека, она недавно реализовала программу повышения квалификации совместно с институтом Мела Левина "All Kinds of Minds". С ней можно связаться по электронной почте или через сеть LinkedIn



13.03.2014

Введение

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


Компьютерные сбои с катастрофическими результатами

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

Пример корпорации Knight Capital Group

В августе 2012 года в корпорации Knight Capital Group, Inc. произошел катастрофический компьютерный сбой, который оказался роковым для самого существования компании как независимой организации. Опубликованные отчеты показали, что неудачная попытка обновить программное обеспечение для работы на Нью-Йоркской фондовой бирже (NYSE) Euronext привела к непреднамеренной продаже акций на сумму семь миллиардов долларов, чего корпорация делать не планировала.

Ей пришлось немедленно ликвидировать эти акции, что привело к потере более 440 миллионов долларов. Убытки еще больше выросли, когда некоторые клиенты прекратили бизнес с корпорацией, причиной чего, по мнению некоторых экспертов, была потеря уверенности в ее возможностях. Knight Capital Group была приобретена другой компанией. Она потеряла бизнес в первую очередь потому, что не имела адекватных процедур по управлению обновлением ПО. Этот получивший широкую огласку драматический инцидент является лишь одним из многих сбоев ПО недавнего времени, которые затрагивали банковские системы, торговые фирмы, фондовые биржи, а также критически важные государственные системы, такие как система аварийного энергоснабжения службы 911 Нью-Йорка.

Аналогичные примеры на фондовом рынке

К аналогичным по масштабам последствиям приводил и ряд других недавних сбоев ПО. В мае 2013 года из-за программного сбоя была прекращена работа торговой системы Чикагской биржи опционов (CBOE), что, по сообщениям, было связано с изменением системной конфигурации для продления операционного дня. Этот инцидент поднял вопрос о том, должна ли CBOE быть единственным источником опционов, основанных на индексе S&P 500 и индексе волатильности VIX. Инцидент произошел потому, что исключительное право CBOE на управление индексами создало проблемы для других компаний, и продемонстрировал, что фондовые биржи могут оказаться неспособны и далее выступать в роли единственного источника таких опционов.

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


Отраслевые стандарты и инфраструктуры

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

В качестве примера можно привести библиотеку Information Technology Infrastructure Library (ITIL) – набор методик управления ИТ-сервисами (ITSM), позволяющих настраивать ИТ-сервисы на потребности бизнеса. ITIL V3, одна из самых популярных инфраструктур, предоставляет рекомендации по поддержке и обновлению ИТ-сервисов без риска нарушения обслуживания. ITIL описывает систему управления конфигурацией (CMS), которая используется для отслеживания изменений всех элементов конфигурации (CI). Она также описывает базу данных управления конфигурацией (CMDB), которая поддерживает CMS, предоставляя точную и актуальную информацию о состоянии элементов CI в выполняющихся системах.


Поддержка требований Configuration Management Database

CMDB является важным компонентом CMS: она предоставляет точную актуальную информацию с помощью автоматизированных процедур обнаружения. Методология DevOps помогает поддерживать актуальность CMDB с помощью процедур проверенной сборки. На практике код приложения можно обнаружить и достоверно идентифицировать, только если он скомпонован с использованием встроенных неизменяемых идентификаторов версий. Поэтому в процесс сборки должна входить процедура встраивания идентификатора версии в сам элемент конфигурации и в манифест контейнера, упакованный, например, в jar-, war- или ear-файл.

DevOps реализует это требование путем автоматизации процессов сборки, выпуска и развертывания, что позволяет CMDB предоставлять CMS точную информацию о коде приложения.

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


DevOps обеспечивает качество с помощью инжиниринга выпуска

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

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

У каждой группы есть конкретная цель:

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

Авторитетный специалист по качеству У. Эдвардс Деминг говорит, что использование методологии DevOps для сборки, пакетирования и развертывания приложений позволяет организациям обеспечить качество с самого начала. Если мы знаем, как предотвратить проблемы, имевшие место в Knight Capital, почему бы не использовать эти лучшие отраслевые методики в других организациях?


DevOps позволяет экономить деньги

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

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


DevOps минимизирует сложность разработки ПО

Еще одним распространенным оправданием низкого качества программного обеспечения является его чрезмерная сложность.

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

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


DevOps управляет зависимостями сборки, пакетирования и развертывания

Реализация автоматизированных процессов сборки, пакетирования и развертывания является одной из главных задач DevOps. Многие разработчики ПО сосредоточены исключительно на работе в интегрированных средах разработки (IDE), таких как Eclipse и Visual Studio.

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


DevOps повышает надежность и улучшает конвейер развертывания

Написание сценариев и автоматизация сборки гарантируют выявление и документирование важной информации о зависимостях компиляции и времени исполнения. Разработчик может не помнить настройки параметров в IDE, но сценарии сборки, написанные с помощью Ant, Maven или Make, обеспечат четкую и точную конфигурацию, необходимую для сборки, пакетирования и развертывания кода.

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


Применение шифрования и базовых версий в развертывании

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

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


Перемещение функций сборки, упаковки и развертывания в начало процесса

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

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

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

DevOps определяет развертывание инфраструктуры (и серверов в облачной среде) как задачу кодирования и разработки. Безопасное и надежное конфигурирование серверов также является задачей кодирования.

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


DevOps совершенствует процесс DevOps

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

Многие ранние последователи DevOps называют эти методики гибким администрированием систем. Это определение является наглядным и уместным, но многие из нас имеют опыт применения этих методик и при каскадной разработке. Независимо от подхода к разработке в вашей организации (гибкий, каскадный или гибридный) методология разработки ПО является основополагающим фактором.


Методология разработки ПО на практике

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


Заключение

Разработчики занимаются созданием новых функций. Группы эксплуатации занимаются предоставлением надежных систем. Инженеры DevOps занимаются принципами, методиками и практическими процедурами разработки ПО, обеспечивающими качество с самого начала жизненного цикла поставки ПО и систем. Эти подходы отвечают передовым методикам, описанным в отраслевых стандартах и инфраструктурах. Для разработки надежных систем требуются именно такие методики и принципы, которые создает революция DevOps.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=965683
ArticleTitle=Передовые методики DevOps: Разработка надежного программного обеспечения с помощью DevOps
publish-date=03132014