Поставили мы как-то заказчику на один объект систему электронного документооборота. А потом на другой объект. И еще на один. И на четвертый, и на пятый. Увлеклись настолько, что дошли до 10 распределенных объектов. Мощно получилось… особенно когда мы дошли до поставки изменений. В рамках поставки на продуктивный контур на 5 сценариев системы тестирования в итоге потребовалось 10 часов и 6-7 сотрудников. Такие затраты вынуждали нас выполнять поставки как можно реже. Через три года эксплуатации мы не выдержали и решили приправить проект щепоткой DevOps.
Теперь все тестирование проходит за 3 часа, и в нем участвует 3 человека: инженер и два тестировщика. Улучшения четко выражаются в цифрах и ведут к сокращению всеми любимого TTM. По нашему опыту, заказчиков, которым может помочь DevOps, гораздо больше, чем тех, кто о нем вообще знает. Поэтому, чтобы сделать DevOps ближе к людям, мы разработали простой конструктор, о котором расскажем подробнее в этом посте.
Теперь расскажем подробней. В одной энергетической компании на 10 крупных объектах развертывается система технического документооборота. В проектах такого масштаба без DevOps выплыть непросто, ведь большая доля ручного труда сильно затягивает работы и к тому же снижает качество — все ручные работы чреваты ошибками. С другой стороны, есть проекты, где инсталляция одна, но нужно, чтобы все работало автоматически, постоянно и безотказно — например, те же системы документооборота в крупных монолитных организациях. Иначе внесет кто настройку вручную, забудет про инструкцию по развертыванию — а в итоге на проде настройка потеряется и все рухнет.
Обычно мы работаем с заказчиком через контракт, и в этом случае наши интересы немного расходятся. Заказчик смотрит на проект строго в рамках бюджета и ТЗ. Бывает сложно объяснить ему пользу различных DevOps-практик, не входящих в ТЗ. А если он заинтересован в быстрых релизах с добавленной ценностью для бизнеса, в выстраивании конвейера по автоматизации?
Увы, в работе с заранее утвержденной стоимостью этот интерес не всегда удается нащупать. В нашей практике был случай когда пришлось подхватить разработку за нечистоплотным и неаккуратным подрядчиком. Это был ужас: актуальных исходных кодов нет, кодовая база одной и той же системы на разных инсталляциях разная, документация частично отсутствовала, частично была ужасного качества. Разумеется, у заказчика при этом не было управления исходным кодом, сборкой, релизами и т.п.
Пока что о DevOps знают далеко не все, но стоит заговорить о его преимуществах, о реальной экономии ресурсов, глаза загораются у всех заказчиков. Так что запросов, включающих DevOps, со временем становится все больше. Здесь, чтобы легко заговорить на одном языке с заказчиками, нам нужно быстро связывать проблемы бизнеса и практики DevOps, которые помогут выстроить подходящий конвейер разработки.
Итак, у нас есть набор проблем с одной стороны, есть знания, практики и инструменты DevOps с другой. Почему бы не поделиться опытом со всеми?
Свой манифест есть у Agile. Своя методология есть у ITIL. DevOps повезло меньше — шаблонами и стандартами он пока не оброс. Хотя некоторые пробуют определять степень зрелости компаний, исходя из оценки их методик разработки и эксплуатации.
К счастью, небезызвестная компания Gartner в 2014 году собрала и проанализировала ключевые DevOps-практики и взаимосвязи между ними. На основе этого выпустила инфографику:
Ее мы взяли за основу своего конструктора. В каждой из четырех сфер есть набор инструментов — мы собрали их в базу, выделили наиболее популярные, определили точки интеграции и подходящие механизмы оптимизации. Всего получилось 36 практик и 115 инструментов, четверть из которых — открытое или свободное ПО. Далее мы расскажем про то, что у нас получилось в каждой сфере и для примера — про то, как это реализовано в проекте по созданию технического документооборота, с которого мы начали пост.
В пресловутом проекте по СЭД система управления технической документацией была развернута по одной и той же схеме на каждом из 10 объектов. В инсталляцию входит 4 сервера: сервер базы данных, сервер приложений, полнотекстовой индексации и управления содержанием. В инсталляции они работают в рамках единого узла, размещаются в ЦОД на объектах. Все объекты немного различаются по инфраструктуре, но глобальному взаимодействию это не мешает.
Сначала мы согласно практикам DevOps автоматизировали инфраструктуры локально, потом доводили поставку до тестового контура, а потом до продуктива заказчика. Каждый процесс отработали пошагово. Настройки окружений зафиксированы в системе исходных кодов, с учетом которых собирается дистрибутив для автоматического обновления. В случае изменений в конфигурации инженерам нужно просто внести в систему контроля версий соответствующие изменения — и тогда автоматическое обновление пройдет без проблем.
Благодаря такому подходу процесс тестирования сильно упростился. Раньше в проекте были тестировщики, которые только и делали, что вручную обновлял стенды. Сейчас они просто приходят, смотрят, что все заработало и занимаются более полезными делами. Каждое обновление тестируется автоматически — от поверхностного уровня до автоматизации бизнес-сценария. Результаты выкладываются в виде отдельных отчетов в TestRail.
Непрерывное экспериментирование лучше всего объяснить на примере дизайна тестов. Протестировать систему, которой еще нет — творческая работа. При написании тест-плана нужно понять, как протестировать правильно, по каким веткам пройти. А еще найти баланс между временем и бюджетом, чтобы определить оптимальное количество проверок. Важно выбрать именно необходимые тесты, продумать, как пользователь будет взаимодействовать с системой, учесть окружение и возможные внешние факторы. Без непрерывного экспериментирования не обойтись.
Теперь о культуре взаимодействия. Раньше было две противоборствующие стороны — инженеры и разработчики. Разработчики говорили: «Нам все равно как это будет запускаться. Вы инженеры, вы умные, сделайте так, чтобы оно эксплуатировалось без сбоев». Инженеры отвечали: «Вы, разработчики, слишком неосторожные. Давайте вы будете поаккуратней, а мы будем реже ваши релизы ставить. Потому что вы каждый раз дырявый код нам ставите, и как нам взаимодействовать — непонятно». Это проблема культурного взаимодействия, которая с точки зрения DevOps выстраивается иначе. Здесь у тебя и инженеры, и разработчики являются частью единой команды, которая нацелена на постоянно меняющийся, но в то же время надежный софт.
В масштабах одной команды специалисты настроены на помощь друг другу. Как было раньше? Готовилась, например, какая-нибудь толстая инструкция по развертыванию, страниц на 50. Инженер читал ее, что-то не понимал, матерился и просил разработчика в три часа ночи прокомментировать. Разработчик комментировал и тоже матерился — в итоге никто не был рад. Плюс естественно были какие-то ошибки, потому что в инструкции все не упомнишь. А сейчас инженер вместе с разработчиком пишет скрипт автоматизированного развертывания инфраструктуры прикладного ПО. И разговаривают они друг с другом уже практически на одном языке.
Размер команды определяется масштабами обновления. Команда набирается при формировании поставки, в нее входят желающие из общей проектной команды. Затем пишется план обновления с ответственными за каждый этап, по мере выполнения команда отчитывается. Все участники команды взаимозаменяемы. В составе команды у нас также есть разработчик на подстраховке, но ему практически никогда не приходится подключаться.
В схеме по технологиям выделено немного пунктов, но под ними находится куча технологий — с их описаниями можно целую книгу выпустить. Так что мы выделим самое интересное.
Сейчас, наверное, этой концепцией никого не удивишь, но раньше описания инфраструктур оставляли желать лучшего. Инженеры с ужасом смотрели на инструкции, тестовые среды были уникальны, их холили и лелеяли, с них сдували пылинки.
Сейчас никто не боится экспериментировать. Есть базовые образы виртуальных машин, есть готовые сценарии по развертыванию сред. Все шаблоны и сценарии хранятся в системе контроля версий и оперативно обновляются. Раньше, когда нужно было доставить какой-то пакет на стенд, при этом появлялся конфигурационный разрыв. Сейчас нужно просто дописать строчку в исходном коде.
Помимо сценариев инфраструктуры и пайплайнов, подход Documentation as a Code применяют и для документации. Благодаря этому легко подключать новых людей к проекту, знакомить их с системой по функциям, описанным, например, в тест-плане, а также заново использовать тест-кейсы.
В прошлой статье о DevOps мы рассказали, как выбирали инструменты для реализации непрерывной поставки и мониторинга. Зачастую не нужно ничего переписывать — достаточно использовать ранее написанные скрипты, правильно выстроить интеграцию между компонентами и сделать общую консоль управления. И все процессы можно будет запускать по одной кнопке или расписанию.
В английском языке есть разные понятия, Continuous Delivery и Continuous Deployment. Оба можно перевести как «непрерывная поставка», но по факту между ними есть небольшая разница. В нашем проекте по техническому документообороту распределенной энергетической компании используется, скорее, Delivery — когда установка на прод идет по команде. В Deployment же установка происходит автоматически. Continuous Delivery в этом проекте вообще стал центральной частью DevOps.
В целом с помощью сбора определенных параметров можно четко понять, чем полезны DevOps-практики. И донести это до руководства, которое очень любит цифры. Общее количество запусков, время выполнения этапов сценария, доля успешных запусков — все это напрямую влияет на всеми любимый time to market, то есть время от коммита в систему контроля версий до выпуска версии на продуктивной среде. С внедрением нужных инструментов инженеры получают ценные показатели по почте, а менеджер проекта видит их на дашборде. Так можно сразу оценить пользу новых инструментов. А примерить их к своей инфраструктуре можно с помощью DevOps-конструктора.
Не будем кривить душой: для начала он стал полезен нам. Как мы уже сказали, с заказчиком нужно говорить на одном языке, и с помощью конструктора DevOps мы можем быстро набросать основу для такой беседы. Специалисты из бизнеса смогут сами оценивать, что им нужно, и таким образом быстрее развиваться. Мы постарались сделать конструктор максимально подробным, добавили кучу описаний, чтобы любой пользователь понимал что выбирает.
Формат конструктора позволяет учесть уже имеющиеся в компании наработки по выстраиванию процессов, автоматизации. Не нужно все ломать и строить заново, если можно выбрать только решения, которые нормально интегрируются в существующие процессы, которые могут просто восполнить пробелы.
Возможно, ваша разработка уже перешла на более высокий уровень и наш инструмент покажется чересчур «капитанским». Но мы находим его полезным для себя и надеемся, что он пригодится кому-нибудь из читателей. Напоминаем ссылку на конструктор — если что, схему вы получаете сразу после ввода исходных данных. Будем благодарны за отзывы и дополнения.
Теперь все тестирование проходит за 3 часа, и в нем участвует 3 человека: инженер и два тестировщика. Улучшения четко выражаются в цифрах и ведут к сокращению всеми любимого TTM. По нашему опыту, заказчиков, которым может помочь DevOps, гораздо больше, чем тех, кто о нем вообще знает. Поэтому, чтобы сделать DevOps ближе к людям, мы разработали простой конструктор, о котором расскажем подробнее в этом посте.
Теперь расскажем подробней. В одной энергетической компании на 10 крупных объектах развертывается система технического документооборота. В проектах такого масштаба без DevOps выплыть непросто, ведь большая доля ручного труда сильно затягивает работы и к тому же снижает качество — все ручные работы чреваты ошибками. С другой стороны, есть проекты, где инсталляция одна, но нужно, чтобы все работало автоматически, постоянно и безотказно — например, те же системы документооборота в крупных монолитных организациях. Иначе внесет кто настройку вручную, забудет про инструкцию по развертыванию — а в итоге на проде настройка потеряется и все рухнет.
Обычно мы работаем с заказчиком через контракт, и в этом случае наши интересы немного расходятся. Заказчик смотрит на проект строго в рамках бюджета и ТЗ. Бывает сложно объяснить ему пользу различных DevOps-практик, не входящих в ТЗ. А если он заинтересован в быстрых релизах с добавленной ценностью для бизнеса, в выстраивании конвейера по автоматизации?
Увы, в работе с заранее утвержденной стоимостью этот интерес не всегда удается нащупать. В нашей практике был случай когда пришлось подхватить разработку за нечистоплотным и неаккуратным подрядчиком. Это был ужас: актуальных исходных кодов нет, кодовая база одной и той же системы на разных инсталляциях разная, документация частично отсутствовала, частично была ужасного качества. Разумеется, у заказчика при этом не было управления исходным кодом, сборкой, релизами и т.п.
Пока что о DevOps знают далеко не все, но стоит заговорить о его преимуществах, о реальной экономии ресурсов, глаза загораются у всех заказчиков. Так что запросов, включающих DevOps, со временем становится все больше. Здесь, чтобы легко заговорить на одном языке с заказчиками, нам нужно быстро связывать проблемы бизнеса и практики DevOps, которые помогут выстроить подходящий конвейер разработки.
Итак, у нас есть набор проблем с одной стороны, есть знания, практики и инструменты DevOps с другой. Почему бы не поделиться опытом со всеми?
Создаем DevOps-конструктор
Свой манифест есть у Agile. Своя методология есть у ITIL. DevOps повезло меньше — шаблонами и стандартами он пока не оброс. Хотя некоторые пробуют определять степень зрелости компаний, исходя из оценки их методик разработки и эксплуатации.
К счастью, небезызвестная компания Gartner в 2014 году собрала и проанализировала ключевые DevOps-практики и взаимосвязи между ними. На основе этого выпустила инфографику:
Ее мы взяли за основу своего конструктора. В каждой из четырех сфер есть набор инструментов — мы собрали их в базу, выделили наиболее популярные, определили точки интеграции и подходящие механизмы оптимизации. Всего получилось 36 практик и 115 инструментов, четверть из которых — открытое или свободное ПО. Далее мы расскажем про то, что у нас получилось в каждой сфере и для примера — про то, как это реализовано в проекте по созданию технического документооборота, с которого мы начали пост.
Процессы
В пресловутом проекте по СЭД система управления технической документацией была развернута по одной и той же схеме на каждом из 10 объектов. В инсталляцию входит 4 сервера: сервер базы данных, сервер приложений, полнотекстовой индексации и управления содержанием. В инсталляции они работают в рамках единого узла, размещаются в ЦОД на объектах. Все объекты немного различаются по инфраструктуре, но глобальному взаимодействию это не мешает.
Сначала мы согласно практикам DevOps автоматизировали инфраструктуры локально, потом доводили поставку до тестового контура, а потом до продуктива заказчика. Каждый процесс отработали пошагово. Настройки окружений зафиксированы в системе исходных кодов, с учетом которых собирается дистрибутив для автоматического обновления. В случае изменений в конфигурации инженерам нужно просто внести в систему контроля версий соответствующие изменения — и тогда автоматическое обновление пройдет без проблем.
Благодаря такому подходу процесс тестирования сильно упростился. Раньше в проекте были тестировщики, которые только и делали, что вручную обновлял стенды. Сейчас они просто приходят, смотрят, что все заработало и занимаются более полезными делами. Каждое обновление тестируется автоматически — от поверхностного уровня до автоматизации бизнес-сценария. Результаты выкладываются в виде отдельных отчетов в TestRail.
Культура
Непрерывное экспериментирование лучше всего объяснить на примере дизайна тестов. Протестировать систему, которой еще нет — творческая работа. При написании тест-плана нужно понять, как протестировать правильно, по каким веткам пройти. А еще найти баланс между временем и бюджетом, чтобы определить оптимальное количество проверок. Важно выбрать именно необходимые тесты, продумать, как пользователь будет взаимодействовать с системой, учесть окружение и возможные внешние факторы. Без непрерывного экспериментирования не обойтись.
Теперь о культуре взаимодействия. Раньше было две противоборствующие стороны — инженеры и разработчики. Разработчики говорили: «Нам все равно как это будет запускаться. Вы инженеры, вы умные, сделайте так, чтобы оно эксплуатировалось без сбоев». Инженеры отвечали: «Вы, разработчики, слишком неосторожные. Давайте вы будете поаккуратней, а мы будем реже ваши релизы ставить. Потому что вы каждый раз дырявый код нам ставите, и как нам взаимодействовать — непонятно». Это проблема культурного взаимодействия, которая с точки зрения DevOps выстраивается иначе. Здесь у тебя и инженеры, и разработчики являются частью единой команды, которая нацелена на постоянно меняющийся, но в то же время надежный софт.
В масштабах одной команды специалисты настроены на помощь друг другу. Как было раньше? Готовилась, например, какая-нибудь толстая инструкция по развертыванию, страниц на 50. Инженер читал ее, что-то не понимал, матерился и просил разработчика в три часа ночи прокомментировать. Разработчик комментировал и тоже матерился — в итоге никто не был рад. Плюс естественно были какие-то ошибки, потому что в инструкции все не упомнишь. А сейчас инженер вместе с разработчиком пишет скрипт автоматизированного развертывания инфраструктуры прикладного ПО. И разговаривают они друг с другом уже практически на одном языке.
Люди
Размер команды определяется масштабами обновления. Команда набирается при формировании поставки, в нее входят желающие из общей проектной команды. Затем пишется план обновления с ответственными за каждый этап, по мере выполнения команда отчитывается. Все участники команды взаимозаменяемы. В составе команды у нас также есть разработчик на подстраховке, но ему практически никогда не приходится подключаться.
Технологии
В схеме по технологиям выделено немного пунктов, но под ними находится куча технологий — с их описаниями можно целую книгу выпустить. Так что мы выделим самое интересное.
Infrastructure as Code
Сейчас, наверное, этой концепцией никого не удивишь, но раньше описания инфраструктур оставляли желать лучшего. Инженеры с ужасом смотрели на инструкции, тестовые среды были уникальны, их холили и лелеяли, с них сдували пылинки.
Сейчас никто не боится экспериментировать. Есть базовые образы виртуальных машин, есть готовые сценарии по развертыванию сред. Все шаблоны и сценарии хранятся в системе контроля версий и оперативно обновляются. Раньше, когда нужно было доставить какой-то пакет на стенд, при этом появлялся конфигурационный разрыв. Сейчас нужно просто дописать строчку в исходном коде.
Помимо сценариев инфраструктуры и пайплайнов, подход Documentation as a Code применяют и для документации. Благодаря этому легко подключать новых людей к проекту, знакомить их с системой по функциям, описанным, например, в тест-плане, а также заново использовать тест-кейсы.
Непрерывная поставка и мониторинг
В прошлой статье о DevOps мы рассказали, как выбирали инструменты для реализации непрерывной поставки и мониторинга. Зачастую не нужно ничего переписывать — достаточно использовать ранее написанные скрипты, правильно выстроить интеграцию между компонентами и сделать общую консоль управления. И все процессы можно будет запускать по одной кнопке или расписанию.
В английском языке есть разные понятия, Continuous Delivery и Continuous Deployment. Оба можно перевести как «непрерывная поставка», но по факту между ними есть небольшая разница. В нашем проекте по техническому документообороту распределенной энергетической компании используется, скорее, Delivery — когда установка на прод идет по команде. В Deployment же установка происходит автоматически. Continuous Delivery в этом проекте вообще стал центральной частью DevOps.
В целом с помощью сбора определенных параметров можно четко понять, чем полезны DevOps-практики. И донести это до руководства, которое очень любит цифры. Общее количество запусков, время выполнения этапов сценария, доля успешных запусков — все это напрямую влияет на всеми любимый time to market, то есть время от коммита в систему контроля версий до выпуска версии на продуктивной среде. С внедрением нужных инструментов инженеры получают ценные показатели по почте, а менеджер проекта видит их на дашборде. Так можно сразу оценить пользу новых инструментов. А примерить их к своей инфраструктуре можно с помощью DevOps-конструктора.
Кому пригодится наш DevOps-конструктор?
Не будем кривить душой: для начала он стал полезен нам. Как мы уже сказали, с заказчиком нужно говорить на одном языке, и с помощью конструктора DevOps мы можем быстро набросать основу для такой беседы. Специалисты из бизнеса смогут сами оценивать, что им нужно, и таким образом быстрее развиваться. Мы постарались сделать конструктор максимально подробным, добавили кучу описаний, чтобы любой пользователь понимал что выбирает.
Формат конструктора позволяет учесть уже имеющиеся в компании наработки по выстраиванию процессов, автоматизации. Не нужно все ломать и строить заново, если можно выбрать только решения, которые нормально интегрируются в существующие процессы, которые могут просто восполнить пробелы.
Возможно, ваша разработка уже перешла на более высокий уровень и наш инструмент покажется чересчур «капитанским». Но мы находим его полезным для себя и надеемся, что он пригодится кому-нибудь из читателей. Напоминаем ссылку на конструктор — если что, схему вы получаете сразу после ввода исходных данных. Будем благодарны за отзывы и дополнения.
