Сегодня много говорят о DevOps, обычно рассматривая эту методологию как набор практик для развертывания систем и операционного мониторинга (рис. 1). Эти практики поддерживаются конкретным инструментарием, предназначенным для организации, мониторинга и управления жизненным циклом приложений. В портфеле компании Microsoft для этого предлагается система Team Foundation Server, а также группа продуктов System Center.

 

Рис. 1. Структура DevOps
Рис. 1. Структура DevOps

 

На основе Team Foundation Server и System Center можно реализовать основные сценарии DevOps, в первую очередь автоматизации развертывания релизов приложений и их быстрой диагностики в «боевой среде» с целью предоставления корректирующих данных команде разработки. Однако на самом деле DevOps позволяет улучшить процессы разработки и эксплуатации в целом, затрагивая все важные фазы проектирования, программирования, тестирования, развертывания и эксплуатации. В этой методологии описаны средства продолжения работы над продуктом, уже вышедшим в свет, способы улучшения его качества, ускорения ввода в эксплуатацию новых возможностей и снижения времени на фиксацию найденных проблем.

Разработка программных продуктов — сложный процесс, немыслимый без ведения «типовой бухгалтерии»: перечней требований, задач, найденных ошибок, рисков, тестов и других артефактов, которые обычно появляются в ходе реальных проектов. Team Foundation Server позволяет формировать наглядные списки из этих артефактов (например, в виде древовидной структуры требований и подчиненных задач), структурируя планируемую работу. C помощью различных запросов эти списки могут быть отфильтрованы по нужным критериям и затем представлены, например, в виде перечня требований к очередному релизу. Инструменты, встроенные в Team Foundation Server, позволяют планировать итерации разработки на основе опыта и сроков реализации предыдущих итераций.

Уже на стадии проектирования и планирования важным шагом является фиксация требований, связанных с будущей эксплуатацией разрабатываемых систем. Это могут быть требования к готовности операционной среды (версия ОС, наличие заранее предустановленных библиотек, параметры скорости сетевых интерфейсов, наличие свободного места на диске) и критерии приемки (максимальное количество пользователей, которое одновременно должно быть обслужено системой, время отклика каких-либо функций). На основе этой информации проще планировать и разрабатывать методы и инструментарий для развертывания разрабатываемой системы, так как у команды появляется возможность быстро получить по запросу информацию, связанную с эксплуатационными требованиями, а также отслеживать историю их изменений. Важным шагом при этом является расстановка приоритетов. Очевидно, что требования по эксплуатации системы должны иметь приоритет, позволяющий заранее спланировать работы по их реализации, а назначение низких приоритетов может привести к росту «технического долга», когда очевидные, но рутинные задачи оставляются на потом. Впоследствии команда разработки может сильно потерять в темпе внедрения, казалось бы, готовой системы, когда реализованы все нужные функции, но еще нет операционной среды и процедур, которые бы позволили ее быстро развернуть. Одним из удобных инструментов для управления эксплуатационными требованиями и критериями готовности в Team Foundation Server является электронная доска Kanban. В Visual Studio 2012 также входит ряд инструментов для решения задач отслеживания критериев готовности — например, инструменты нагрузочного тестирования по различным сценариям, средства профилировки нагрузки на память и т. п.

Далее команде разработки совместно с командой эксплуатации предстоит создать и настроить инструментарий автоматического развертывания создаваемой системы как обязательный механизм DevOps. Методы agile предполагают короткие циклы реализации — итерации продолжительностью одну-две недели, и без средств автоматизированного развертывания администраторы просто не справятся с установкой новых релизов. Автоматизация подразумевает не только создание некоего инсталляционного пакета, но и, например, автоматическое развертывание операционных систем, установку нужных компонентов и библиотек, конфигурирование интерфейсов и вспомогательного ПО. Подсистемы автоматической сборки Team Foundation Server позволяют использовать технологии Windows Workflow Foundation для создания сценариев развертывания из уже существующих компонентов. Например, компоненты управления лабораторией тестирования (Virtual Lab Management) помогают выполнить все тесты в различных типах окружений и для различных вариантов развертывания. У группы разработки и тестирования есть возможность определить параметры основных конфигураций с помощью Microsoft Test Manager, а затем создать шаблоны виртуальных машин. После этого возможен сценарий, когда после компиляции проекта сразу создается среда выполнения на основе готовых образов виртуальной машины, производится инсталляция скомпилированных компонентов, а тестировщики сразу имеют возможность проверять работоспособность системы. Как правило, на этапе тестирования функциональных требований создаются необходимые «чистые» виртуальные среды, которые затем используются как эталонные при эксплуатации и могут послужить основой для более детального планирования операционной среды. Дополнительно можно использовать возможности продукта System Center 2012 Orchestrator, позволяющего проектировать и создавать частную облачную инфраструктуру для эксплуатации системы, автоматически ее развертывать или возвращаться к предыдущей конфигурации в случае возникновения сбоев.

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

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

Очевидно, какие-то инциденты могут быть разрешены усилиями операционного подразделения, но чаще всего возникают проблемы именно в разработанном программном обеспечении, поэтому скорость передачи информации об инциденте команде разработки и скорость реакции на инцидент — важные метрики DevOps, что предполагает автоматизацию этих механизмов. Одной из полумер, которая часто применяется для автоматизации информационного взаимодействия между командами разработки и эксплуатации, является создание неких промежуточных систем заявок. Однако это ведет к дублированию информации о возникшем инциденте как в эксплуатационных информационных системах, так и в системах управления разработкой, что увеличивает время на подготовку отчетов и отслеживание состояний и порождает ошибки в синхронизации. В System Center 2012 Operations Manager и Team Foundation Server 2012 предусмотрено прямое взаимодействие между командами разработки и эксплуатации. Операционные инженеры могут создавать инциденты по дефектам в разработанном программном обеспечении — полная информация сразу же поступает разработчикам и видна в Visual Studio 2012. После обработки инцидента статусы передаются обратно в команду эксплуатации, тем самым достигается прозрачный общий документооборот, становятся возможнымм планирование и расстановка приоритетов на основе актуальной информации.

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

Одним из интересных свойств интеграции System Center 2012 и Team Foundation Server является поддержка запросов программиста на получение дополнительной информации об инциденте — возникший инцидент, который уже передан в группу разработки, может недостаточно иллюстрировать возникшую проблему и не позволит понять, как быстро можно устранить неисправность. В этом случае программист может поменять статус инцидента на «Требуется дополнительная информация», и тогда системный администратор включает дополнительную диагностику или режим исследования приложения с помощью технологии исторической отладки IntelliTrace — своеобразного «цифрового магнитофона», детально записывающего все нужные события, происходящие с приложением в заданный промежуток времени. Изначально эта технология использовалась только при разработке и была встроена в Visual Studio 2012, но затем ее удобства были оценены как при тестировании, так и при диагностике сложных ошибок в эксплуатационной среде. Простейший сценарий который может быть достигнут с помощью технологии IntelliTrace, выглядит следующим образом. Допустим, в приложении возникает ошибка, которая не приводит к краху приложения, не видно явных исключительных ситуаций, но что-то идет не так — например, неправильно рассчитывается скидка. В этом случае с помощью IntelliTrace можно включить режим диагностики, позволяющей получать дамп (*.itrace) с детальной информацией о всех событиях в момент проверки, который затем можно будет посмотреть с помощью Visual Studio 2012 (Рис.2).

 

Рис. 2. Пример диагностики на основе дампа времени выполнения приложения
Рис. 2. Пример диагностики на основе дампа времени выполнения приложения

 

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

***

Управление эксплуатационными требованиями, автоматическое развертывание и интеграция документооборота команд разработки и эксплуатации проверены на практике многими организациями — например, компания Xerox на 40% снизила затраты на разработку, применив принципы DevOps и внедрив продукты Visual Studio 2012 и System Center 2012. Для знакомства со сценариями и возможностями продуктов Team Foundation Server 2012, Visual Studio 2012 и System Center 2012 Operations Manager нет необходимости их развертывать — имеются готовая виртуальная машина и пошаговая лабораторная работа (aka.ms/TFSSCOMVM), позволяющая получить реальный опыт работы с комплексом, реализующим идеи DevOps.

Дмитрий Андреев (Dmitry.Andreev@microsoft.com) — эксперт по разработке информационных систем, Microsoft (Москва).