Как показал опрос, проведенный в 2015 год IT Revolution Press и Puppet Labs, организации, применяющие DevOps, вводят код в эксплуатацию в 30 раз быстрее, чем остальные, — развертывания осуществляются по несколько раз в день. А прерывания работы, обусловленные неудачными изменениями, происходят вдвое реже, поскольку обслуживание можно восстановить на порядки быстрее, чем в организациях, не пользующихся DevOps.
DevOps: более быстрое восстановление после сбоев
Результаты опроса указывают на то, что переход на DevOps окупается с точки зрения восстановления после катастрофических сбоев, поскольку инструменты и методы, используемые для перевода приложений со стадии тестирования на этапы рабочего применения и дальнейшей разработки можно также применять для аварийного переключения и восстановления после сбоев и прерываний обслуживания. Те же системы, которые автоматизируют цикл DevOps, позволяют задействовать имеющиеся ресурсы для нужд восстановления.
Для такой автоматизации существует немало инструментов с открытым кодом, прежде всего это Chef и Puppet, которые могут автоматически создавать и запускать новые экземпляры виртуальных машин, конфигурируя их необходимым образом. Эти инструменты можно развернуть где угодно, от собственного ноутбука пользователя до корпоративного центра обработки данных и публичного облака: Chef и Puppet, в частности, поддерживаются такими операторами облаков, как Amazon Web Services и Microsoft Azure. С помощью этих инструментов можно не только автоматизировать развертывание нового кода путем клонирования конфигурации среды разработки, развернутой на компьютерах программистов, но и в считанные минуты обеспечивать оркестровку и запуск резервной среды в облаке. Если в средах виртуализации на основе VMware или KVM пользоваться Puppet или Chef совместно с решением вроде Oracle Ravello (поддерживаемом в общедоступных облаках AWS и Google), можно «вложить» гипервизоры друг в друга, что позволит в автоматическом режиме перенести вашу среду в публичное облако без изменений — вместе с настройками сети, адресации и не только. Данные инструменты предоставляют широкие возможности с точки зрения не только DevOps, но и аварийного восстановления. С помощью одних и тех же средств можно быстро выполнять сборку, тестировать и развертывать ПО, устранять ошибки и обеспечивать надежные механизмы аварийного переключения и восстановления. По сути, процесс непрерывного развертывания легко превращается в перманентное решение для восстановления при катастрофических сбоях.
Один из главных принципов DevOps — в том, что писать код и тестировать приложение следует в полной копии рабочей среды, в которой оно будет использоваться. Часто это достигается с помощью виртуальных машин и контейнерных решений наподобие Docker, работающих на индивидуальных ноутбуках или настольных компьютерах. Это, конечно, гораздо лучше, чем просто «вслепую» писать код в Xcode или Visual Studio и затем передавать ПО для развертывания сисадминам, однако при таком способе виртуализации не удается полностью повторить особенности реальной рабочей среды. Сложно тестировать реальную нагрузку на контейнеризованном микросервисе, работающем, к примеру, на Apple MacBook Air. Если же сервис функционирует в облаке Azure с полным набором зависимостей, такое тестирование будет более приближенным к реальным условиям.
Среды аварийного восстановления как рабочие пространства DevOps
В некоторых компаниях по мере расширения использования DevOps разработчики начинают требовать доступа к средам аварийного восстановления, поддерживаемым в режиме возможности мгновенного запуска. Это требование обусловливается необходимостью обхода ограничений, свойственных тестированию на одиночном компьютере. В организациях средних и крупных размеров обычно вкладывают немалые средства в создание резервных инфраструктур, являющихся практически «клонами» основной, где выполняются критически важные нагрузки. Запасные среды находятся в режиме ожидания на случай необходимости переноса основных нагрузок, могущей возникнуть в результате серьезной аварии.
Как правило, эти среды большую часть времени не используются за исключением учебных операций восстановления, проводимых несколько раз в год. Получается, что значительные мощности по сути простаивают в ожидании события, которое может продлиться лишь несколько часов в году. Можно ли с помощью технологий виртуализации, SAN и программно-конфигурируемых сетей задействовать эти мощности в качестве рабочего пространства DevOps для нужд тестирования с сохранением основной функции — приема рабочих задач при аварийных переключениях?
Ответ — да. Гипервизоры и виртуальные машины можно запускать и останавливать за считанные секунды, а программно-конфигурируемые сети можно перестраивать в зависимости от потребностей в соединениях и маршрутах с помощью скриптов в автоматическом режиме. К тому же в большинстве случаев в среде восстановления уже доступны рабочие данные, благодаря чему тестирование можно выполнять на реальных данных без длительных операций копирования. Можно ли требовать большего, чем тестирование работоспособности кода в реальных условиях в среде, которая по сути является полной копией рабочей инфраструктуры? А в случае возникновения потребности в аварийном переключении система мониторинга запустит скрипты, которые необходимым образом изменят оконечные точки хранения и отключат виртуальные машины. Когда резервная среда выполнит свою роль, она снова будет доступна программистам. Когда аварийная ситуация разрешится, можно вручную восстановить сервисы, отменив все изменения, автоматически внесенные скриптами. В средах Windows, Hyper-V и VMware это удобно делать с помощью PowerShell, а для Xen и других гипервизоров используются скрипты Bash. Разумеется, в подобных случаях хорошим подспорьем станут Puppet, Chef и Ravello.
Задача в том, чтобы задействовать неиспользуемые мощности, сохранив те возможности, ради которых среда создавалась изначально. Разработчикам нужен доступ к этим обширным ресурсам для тестирования и обнаружения проблем с производительностью в условиях большей мощности и нагрузки, чем это возможно на компьютерах, где выполняется программирование. Инфраструктура, простаивающая в режиме горячего резерва, это по сути полное противоречие идеям DevOps, но если ее задействовать, возможно, удастся убить сразу двух зайцев.
Первоочередные вопросы
Как тестировать процедуры аварийного восстановления? Кто отвечает за ведение контрольного списка процедур, которому надо следовать? Кто запускает скрипты и отвечает за автоматизацию? Как имитировать сбой одиночного приложения, всей программной системы и инфраструктуры? Какие события могут стать причиной таких сбоев?
Какие навыки нужны для аварийного восстановления? Идея DevOps — в объединении ролей разработчиков и специалистов по эксплуатации, но само собой разумеется, что у кого-то в последнем будет больше опыта, и именно этих сотрудников лучше назначать ответственными за операции аварийного восстановления. Разработчики же должны нести ответственность, если их код будет виноват в событии, спровоцировавшем аварийное переключение, и возможно, тестированием стоит заниматься программистами с более развитыми навыками отладки.
Еще вопросы для обсуждения: можно ли воспользоваться уже существующей в организации инфраструктурой аварийного восстановления? Можно ли в ней легко организовать необходимую виртуализованную среду? Если нет, что нужно сделать, чтобы обеспечить такую возможность?