(Продолжение перевода, первая часть здесь)
Высокие темпы развертывания обычно ассоциируемые с DevOps, часто оказывают огромное давление на QA и Infosec. Рассмотрим случай, когда разработчики делают десять развертываний в день, в то время как безопасники требуют четырехмесячного тестирования безопасности приложения. На первый взгляд, все это выглядит как тотальное несоответствие между темпами разработки и тестирования безопасности.
Примером риска, связанного с недостаточно проверенным процессом развертывания, является известная проблема Dropbox в 2011, когда аутентификация была отключена на четыре часа, что позволило неавторизованным пользователям получить доступ ко всем хранимым данным.
Хорошая новость для QA и Infosec состоит в том, что если команды разработки способны поддерживать высокие темпы развертывания, то вероятно они используют практики непрерывной интеграции и поставки, что говорит о том, что они используют практики непрерывного тестирования. Иными словами, всякий раз, когда код отправляет в репозиторий, автоматически запускаются тесты, и ошибки должны быть устранены сразу же, как и в случае если бы разработчик отправил в репозиторий код, который не компилируется.
Благодаря использованию функциональных, интеграционных тестов и тестов на информационную безопасность в повседневной деятельности разработчиков, дефекты обнаруживаются и исправляются быстрее, чем когда-либо.
Становится все больше инструментов Infosec, как например Gauntlet и Security Monkey, которые помогают тестировать безопасность, встраивая этот этап в процессы разработки и поставки.
Ключевой проблемой является то, что инструменты статического анализа кода требуют слишком много времени для запуска, чтобы встроить их в непрерывную интеграцию и тестирование, так как часто требуется несколько часов или даже дней для завершения их работы. В этих случаяъ infosec должны выделять специфичные модули, которые содержат ключевой функционал завязанный на безопасность (например, шифрование, модули аутентификации и так далее). Всякий раз, когда эти модули изменяются, требуется полное перетестирование запуска, в противном случае развертывание может продолжиться.
И последнее замечание: как мы видим, задачи DevOps часто больше связаны с обнаружением проблем и восстановление работоспособности, в отличие от стандартного функционального тестирования. Иными словами, при разработке коробочного продукта, когда очень трудно выкатить обновления и патчи, QA опирается на функциональное тестирование перед поставкой. С другой стороны, когда программное обеспечение поставляется как сервис и дефекты могут быть исправлены очень быстро, в таком случае QA может уменьшить свою зависимость от тестирования, а вместо этого больше полагаться на мониторинг для обнаружения дефектов в производстве, поскольку патчи могут быть быстро установлены.
Быстрое восстановление после сбоев может стать проще при использовании «feature flag», которые включают и отключают функциональность прямо в коде с помощью параметров конфигурации, что позволяет избежать полного разветывания.
И для QA переход на подход обнаружения и починки, вполне применим в тех случаях, когда самое худшее, что может случиться это потеря функциональности или требуемой производительности. Однако, когда есть риск, что ошибка приведет к потере конфиденциальности или целостности системы и данных, то в этом случае нельзя полагаться только на обнаружение и восстановление — вместо этого, требуется полный цикл тестирования, до того как код будет развернут, потому ошибка в проде может привести к непоправимым последствиям.
Слишком часто в проектах разработки программного обеспечения, разработчики используют все время исключительно на написание кода. Это оставляет недостаточно времени для адекватного решения проблем в администрировании. А затем пытаются найти простейший способ в определении и тестирования всего, с чем связан код, что включает в себя базы данных, операционные системы, сети, виртуализацию, и так далее.
Это, безусловно, одна из основных причина для постоянного разлада между разработкой и ИТ отделом, что естественно не ведет к повышению эффективности их работы. Последствия этого хорошо известны: недостаточно определены и конкретизированы среды, нет процедур их развертывания, несовместимость между развернутым кодом и средой запуска, и так далее.
В описываемом паттерне, мы создаем среды на ранних стадиях разработки, и устанавливаем правило, согласно которому код и среда должны тестироваться совместно. При разработчики используют Agile процессы, мы можем сделать что-то очень простое и элегантное.
Согласно Agile, мы должны иметь рабочий, поставляемый код в конце каждого спринта (как правило, раз в две недели). Мы изменим Agile правило, так что вместо того, чтобы в конце каждого спринта просто иметь поставляемый жизнеспособной код, вы также будете иметь среду, в которую он развертывается, начиная с самого первого спринта (0 или 1).
Operations вместо того, чтобы отвечать за создание спецификации производственной среды, будут вместо этого настраивать автоматизированный процесс создания этой самой среды. Этот механизм будет создавать среду для боевого запуска, а так же для Dev и QA.
Делая среды (и инструменты, которые их создают) доступными в начале, возможно, даже до того, как проект начнется, разработчики и QA смогут запускать и тестировать свой код в стабильном окружении, с управляемым отклонением от боевого.
Кроме того, поддерживая минимальную разницу между различными видами окружений (например, для разработчиком, тестирования, интеграционного тестирования, реальным запуском), мы будем находить и устранять проблемы взаимодействия между кодом и окружением задолго до развертывания.
В идеале, механизм развертывания должен быть полностью автоматизирован. Инструменты, которые могут быть использованы, включают скрипты, Puppet, Chef, Solaris Jumpstart, Redhat Kickstart, Debian Preseed и т.д.
Одна из моих любимых цитат Patrick Lightbody, бывшего генерального директора BrowserMob, звучит так: «Мы обнаружили, что, когда мы будем разработчиков в 2 часа ночи, то получаем феноменальную обратную связь. Дефекты исправляются быстрее, чем когда-либо ».
Это говорит о проблеме, когда разработчики чекинят своем код в пятницу в 5 вечера, прощаются друг с другом на стоянке, а затем идут домой, оставив админов, чтобы наводили порядок весь уик-энд. Хуже того, дефекты и известные ошибки повторяющиеся в производстве, заставляют админов постоянно тушить пожар, а не искать его причину, потому что разработчики ориентированы на создание нового функционала.
Важным элементом Второго пути является сокращение и усиление обратной связи, чтобы разработчики стали ближе к клиенту.
Обратите внимание на симметрию: паттерн № 1 говорит о создании сред как можно раньше и встраивании ops в разработку, в то время как паттерн # 2 говорит о вводе разработчиков в ops.
Смотрите, мы встраиваем команду разработки в цепь информирования админов, например как техподдержку 3 уровня или даже делая их полностью ответственными за успех поставки, в том числе за откат на предыдущую версию и починку проблем, включая информирование заказчика.
Цель не состоит в том, чтобы заменить админов разработчиками. Вместо этого, мы хотим дать понять команде разработчикам какой эффект может иметь их небрежная работа, и дать походить в обуви ops`ов достаточно долго, чтобы быть мотивированным для быстрого устранения проблем и достижения глобальных целей.
Другая постоянная проблема, которая возникает в DevOps что задачи между разработкой и админами не являются достаточно стандартизированными. Например, когда каждое развертывание происходит по-другому и все среды отличается друг от друга как снежинки. Когда такое происходит, это говорит о том, что никто не пытался поставить на колеса процесс конфигрурирования.
В этом паттерне мы поговорим о многоразовых процедурах развертывания, которые можно использовать в разных проектах. Для этого существует очень элегантное решение в Agile методологиях, когда задача по развертыванию превращается в пользовательскую историю. Например, мы хотели бы построить многоразовую история пользователю для ИТ отдела под названием «Развертывание в среде высокой готовности», которая затем определяет именно шаги нужны для создания среды, а также, сколько времени это займет, какие ресурсы необходимы, и т.д.
Эта информация затем может быть использована руководителями проектов, чтобы точно встроить задачи по развертыванию в план проекта. Например, мы бы были уверены в графике развертывания, если бы мы знали, что история «Развертывание в среде высокой доступности» была выполнена пятнадцать раз в прошлом году, занимая в среднем три дня, плюс-минус один день.
Кроме того, мы также будем уверены, что задачи развертывания в настоящее время должным образом интегрированы в каждом проекте. Делая это, мы получаем преимущества от стандартизации окружений (например, меньше завала в производстве, расширение возможностей для ИТ отдела, направленных на поддержку, и т.д.).
На протяжении последних двух лет мы видели беспрецедентное число всевозможных вариантов решения этой проблемы и бесчисленные предложения по поиску новых путей взаимодействия отделов разработки и администирования.
Мы знаем, что нынешняя система не работает. Мы знаем, что есть лучший путь. Мы знаем, что решение позволит показать настоящий потенциал IT. Сто лет спустя историки будут оглядываться на это десятилетие и говорить: «это был кембрийский взрыв для ИТ, когда мы, наконец, выяснили, как нужно организовать работу IT управления чтобы побеждать».
За последние пять лет мы видели беспрецедентный рост и конвергенцию инновационных идей и технологий. Некоторые из них являются положительными, такие как Agile, облачные вычисления, Big Data, движение DevOps, и Lean Startup. Некоторые были отрицательными, такие, как глобализация и аутсорсинг, рост утечки данных и безопасности, а также наибольший экономический спад со времен Великой депрессии.
Мы стремимся положительно влиять на жизнь 1 миллиона человек в IT в течение ближайших 5 лет. Чтобы это произошло, мы объединяем лидеров во всех соответствующих областях, которые обладают здравым смыслом, чтобы помочь нам достичь нашей цели и улучшить IT для будущих поколений.
8. Как Infosec и QA интегрируются в поток работ DevOps?
Высокие темпы развертывания обычно ассоциируемые с DevOps, часто оказывают огромное давление на QA и Infosec. Рассмотрим случай, когда разработчики делают десять развертываний в день, в то время как безопасники требуют четырехмесячного тестирования безопасности приложения. На первый взгляд, все это выглядит как тотальное несоответствие между темпами разработки и тестирования безопасности.
Примером риска, связанного с недостаточно проверенным процессом развертывания, является известная проблема Dropbox в 2011, когда аутентификация была отключена на четыре часа, что позволило неавторизованным пользователям получить доступ ко всем хранимым данным.
Хорошая новость для QA и Infosec состоит в том, что если команды разработки способны поддерживать высокие темпы развертывания, то вероятно они используют практики непрерывной интеграции и поставки, что говорит о том, что они используют практики непрерывного тестирования. Иными словами, всякий раз, когда код отправляет в репозиторий, автоматически запускаются тесты, и ошибки должны быть устранены сразу же, как и в случае если бы разработчик отправил в репозиторий код, который не компилируется.
Благодаря использованию функциональных, интеграционных тестов и тестов на информационную безопасность в повседневной деятельности разработчиков, дефекты обнаруживаются и исправляются быстрее, чем когда-либо.
Становится все больше инструментов Infosec, как например Gauntlet и Security Monkey, которые помогают тестировать безопасность, встраивая этот этап в процессы разработки и поставки.
Ключевой проблемой является то, что инструменты статического анализа кода требуют слишком много времени для запуска, чтобы встроить их в непрерывную интеграцию и тестирование, так как часто требуется несколько часов или даже дней для завершения их работы. В этих случаяъ infosec должны выделять специфичные модули, которые содержат ключевой функционал завязанный на безопасность (например, шифрование, модули аутентификации и так далее). Всякий раз, когда эти модули изменяются, требуется полное перетестирование запуска, в противном случае развертывание может продолжиться.
И последнее замечание: как мы видим, задачи DevOps часто больше связаны с обнаружением проблем и восстановление работоспособности, в отличие от стандартного функционального тестирования. Иными словами, при разработке коробочного продукта, когда очень трудно выкатить обновления и патчи, QA опирается на функциональное тестирование перед поставкой. С другой стороны, когда программное обеспечение поставляется как сервис и дефекты могут быть исправлены очень быстро, в таком случае QA может уменьшить свою зависимость от тестирования, а вместо этого больше полагаться на мониторинг для обнаружения дефектов в производстве, поскольку патчи могут быть быстро установлены.
Быстрое восстановление после сбоев может стать проще при использовании «feature flag», которые включают и отключают функциональность прямо в коде с помощью параметров конфигурации, что позволяет избежать полного разветывания.
И для QA переход на подход обнаружения и починки, вполне применим в тех случаях, когда самое худшее, что может случиться это потеря функциональности или требуемой производительности. Однако, когда есть риск, что ошибка приведет к потере конфиденциальности или целостности системы и данных, то в этом случае нельзя полагаться только на обнаружение и восстановление — вместо этого, требуется полный цикл тестирования, до того как код будет развернут, потому ошибка в проде может привести к непоправимым последствиям.
9. Мой любимый DevOps Pattern# 1:
Слишком часто в проектах разработки программного обеспечения, разработчики используют все время исключительно на написание кода. Это оставляет недостаточно времени для адекватного решения проблем в администрировании. А затем пытаются найти простейший способ в определении и тестирования всего, с чем связан код, что включает в себя базы данных, операционные системы, сети, виртуализацию, и так далее.
Это, безусловно, одна из основных причина для постоянного разлада между разработкой и ИТ отделом, что естественно не ведет к повышению эффективности их работы. Последствия этого хорошо известны: недостаточно определены и конкретизированы среды, нет процедур их развертывания, несовместимость между развернутым кодом и средой запуска, и так далее.
В описываемом паттерне, мы создаем среды на ранних стадиях разработки, и устанавливаем правило, согласно которому код и среда должны тестироваться совместно. При разработчики используют Agile процессы, мы можем сделать что-то очень простое и элегантное.
Согласно Agile, мы должны иметь рабочий, поставляемый код в конце каждого спринта (как правило, раз в две недели). Мы изменим Agile правило, так что вместо того, чтобы в конце каждого спринта просто иметь поставляемый жизнеспособной код, вы также будете иметь среду, в которую он развертывается, начиная с самого первого спринта (0 или 1).
Operations вместо того, чтобы отвечать за создание спецификации производственной среды, будут вместо этого настраивать автоматизированный процесс создания этой самой среды. Этот механизм будет создавать среду для боевого запуска, а так же для Dev и QA.
Делая среды (и инструменты, которые их создают) доступными в начале, возможно, даже до того, как проект начнется, разработчики и QA смогут запускать и тестировать свой код в стабильном окружении, с управляемым отклонением от боевого.
Кроме того, поддерживая минимальную разницу между различными видами окружений (например, для разработчиком, тестирования, интеграционного тестирования, реальным запуском), мы будем находить и устранять проблемы взаимодействия между кодом и окружением задолго до развертывания.
В идеале, механизм развертывания должен быть полностью автоматизирован. Инструменты, которые могут быть использованы, включают скрипты, Puppet, Chef, Solaris Jumpstart, Redhat Kickstart, Debian Preseed и т.д.
10. Мой любимый DevOps Pattern # 2:
Одна из моих любимых цитат Patrick Lightbody, бывшего генерального директора BrowserMob, звучит так: «Мы обнаружили, что, когда мы будем разработчиков в 2 часа ночи, то получаем феноменальную обратную связь. Дефекты исправляются быстрее, чем когда-либо ».
Это говорит о проблеме, когда разработчики чекинят своем код в пятницу в 5 вечера, прощаются друг с другом на стоянке, а затем идут домой, оставив админов, чтобы наводили порядок весь уик-энд. Хуже того, дефекты и известные ошибки повторяющиеся в производстве, заставляют админов постоянно тушить пожар, а не искать его причину, потому что разработчики ориентированы на создание нового функционала.
Важным элементом Второго пути является сокращение и усиление обратной связи, чтобы разработчики стали ближе к клиенту.
Обратите внимание на симметрию: паттерн № 1 говорит о создании сред как можно раньше и встраивании ops в разработку, в то время как паттерн # 2 говорит о вводе разработчиков в ops.
Смотрите, мы встраиваем команду разработки в цепь информирования админов, например как техподдержку 3 уровня или даже делая их полностью ответственными за успех поставки, в том числе за откат на предыдущую версию и починку проблем, включая информирование заказчика.
Цель не состоит в том, чтобы заменить админов разработчиками. Вместо этого, мы хотим дать понять команде разработчикам какой эффект может иметь их небрежная работа, и дать походить в обуви ops`ов достаточно долго, чтобы быть мотивированным для быстрого устранения проблем и достижения глобальных целей.
11. Мой любимый DevOps Pattern № 3:
Другая постоянная проблема, которая возникает в DevOps что задачи между разработкой и админами не являются достаточно стандартизированными. Например, когда каждое развертывание происходит по-другому и все среды отличается друг от друга как снежинки. Когда такое происходит, это говорит о том, что никто не пытался поставить на колеса процесс конфигрурирования.
В этом паттерне мы поговорим о многоразовых процедурах развертывания, которые можно использовать в разных проектах. Для этого существует очень элегантное решение в Agile методологиях, когда задача по развертыванию превращается в пользовательскую историю. Например, мы хотели бы построить многоразовую история пользователю для ИТ отдела под названием «Развертывание в среде высокой готовности», которая затем определяет именно шаги нужны для создания среды, а также, сколько времени это займет, какие ресурсы необходимы, и т.д.
Эта информация затем может быть использована руководителями проектов, чтобы точно встроить задачи по развертыванию в план проекта. Например, мы бы были уверены в графике развертывания, если бы мы знали, что история «Развертывание в среде высокой доступности» была выполнена пятнадцать раз в прошлом году, занимая в среднем три дня, плюс-минус один день.
Кроме того, мы также будем уверены, что задачи развертывания в настоящее время должным образом интегрированы в каждом проекте. Делая это, мы получаем преимущества от стандартизации окружений (например, меньше завала в производстве, расширение возможностей для ИТ отдела, направленных на поддержку, и т.д.).
Будущее IT
На протяжении последних двух лет мы видели беспрецедентное число всевозможных вариантов решения этой проблемы и бесчисленные предложения по поиску новых путей взаимодействия отделов разработки и администирования.
Мы знаем, что нынешняя система не работает. Мы знаем, что есть лучший путь. Мы знаем, что решение позволит показать настоящий потенциал IT. Сто лет спустя историки будут оглядываться на это десятилетие и говорить: «это был кембрийский взрыв для ИТ, когда мы, наконец, выяснили, как нужно организовать работу IT управления чтобы побеждать».
За последние пять лет мы видели беспрецедентный рост и конвергенцию инновационных идей и технологий. Некоторые из них являются положительными, такие как Agile, облачные вычисления, Big Data, движение DevOps, и Lean Startup. Некоторые были отрицательными, такие, как глобализация и аутсорсинг, рост утечки данных и безопасности, а также наибольший экономический спад со времен Великой депрессии.
Мы стремимся положительно влиять на жизнь 1 миллиона человек в IT в течение ближайших 5 лет. Чтобы это произошло, мы объединяем лидеров во всех соответствующих областях, которые обладают здравым смыслом, чтобы помочь нам достичь нашей цели и улучшить IT для будущих поколений.
