Хабрахабр

DevOps LEGO: как мы пайплайн на кубики раскладывали

Поставили мы как-то заказчику на один объект систему электронного документооборота. А потом на другой объект. И еще на один. И на четвертый, и на пятый. Увлеклись настолько, что дошли до 10 распределенных объектов. Мощно получилось… особенно когда мы дошли до поставки изменений. В рамках поставки на продуктивный контур на 5 сценариев системы тестирования в итоге потребовалось 10 часов и 6-7 сотрудников. Такие затраты вынуждали нас выполнять поставки как можно реже. Через три года эксплуатации мы не выдержали и решили приправить проект щепоткой DevOps.

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

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

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

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

Почему бы не поделиться опытом со всеми? Итак, у нас есть набор проблем с одной стороны, есть знания, практики и инструменты DevOps с другой.

Создаем DevOps-конструктор

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

На основе этого выпустила инфографику: К счастью, небезызвестная компания Gartner в 2014 году собрала и проанализировала ключевые DevOps-практики и взаимосвязи между ними.

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

Процессы

В инсталляцию входит 4 сервера: сервер базы данных, сервер приложений, полнотекстовой индексации и управления содержанием. В пресловутом проекте по СЭД система управления технической документацией была развернута по одной и той же схеме на каждом из 10 объектов. Все объекты немного различаются по инфраструктуре, но глобальному взаимодействию это не мешает. В инсталляции они работают в рамках единого узла, размещаются в ЦОД на объектах.

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

Раньше в проекте были тестировщики, которые только и делали, что вручную обновлял стенды. Благодаря такому подходу процесс тестирования сильно упростился. Каждое обновление тестируется автоматически — от поверхностного уровня до автоматизации бизнес-сценария. Сейчас они просто приходят, смотрят, что все заработало и занимаются более полезными делами. Результаты выкладываются в виде отдельных отчетов в TestRail.

Культура

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

Раньше было две противоборствующие стороны — инженеры и разработчики. Теперь о культуре взаимодействия. Вы инженеры, вы умные, сделайте так, чтобы оно эксплуатировалось без сбоев». Разработчики говорили: «Нам все равно как это будет запускаться. Давайте вы будете поаккуратней, а мы будем реже ваши релизы ставить. Инженеры отвечали: «Вы, разработчики, слишком неосторожные. Это проблема культурного взаимодействия, которая с точки зрения DevOps выстраивается иначе. Потому что вы каждый раз дырявый код нам ставите, и как нам взаимодействовать — непонятно». Здесь у тебя и инженеры, и разработчики являются частью единой команды, которая нацелена на постоянно меняющийся, но в то же время надежный софт.

Как было раньше? В масштабах одной команды специалисты настроены на помощь друг другу. Инженер читал ее, что-то не понимал, матерился и просил разработчика в три часа ночи прокомментировать. Готовилась, например, какая-нибудь толстая инструкция по развертыванию, страниц на 50. Плюс естественно были какие-то ошибки, потому что в инструкции все не упомнишь. Разработчик комментировал и тоже матерился — в итоге никто не был рад. И разговаривают они друг с другом уже практически на одном языке. А сейчас инженер вместе с разработчиком пишет скрипт автоматизированного развертывания инфраструктуры прикладного ПО.

Люди

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

Технологии

Так что мы выделим самое интересное. В схеме по технологиям выделено немного пунктов, но под ними находится куча технологий — с их описаниями можно целую книгу выпустить.

Infrastructure as Code

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

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

Благодаря этому легко подключать новых людей к проекту, знакомить их с системой по функциям, описанным, например, в тест-плане, а также заново использовать тест-кейсы. Помимо сценариев инфраструктуры и пайплайнов, подход Documentation as a Code применяют и для документации.

Непрерывная поставка и мониторинг

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

Оба можно перевести как «непрерывная поставка», но по факту между ними есть небольшая разница. В английском языке есть разные понятия, Continuous Delivery и Continuous Deployment. В Deployment же установка происходит автоматически. В нашем проекте по техническому документообороту распределенной энергетической компании используется, скорее, Delivery — когда установка на прод идет по команде. Continuous Delivery в этом проекте вообще стал центральной частью DevOps.

И донести это до руководства, которое очень любит цифры. В целом с помощью сбора определенных параметров можно четко понять, чем полезны DevOps-практики. С внедрением нужных инструментов инженеры получают ценные показатели по почте, а менеджер проекта видит их на дашборде. Общее количество запусков, время выполнения этапов сценария, доля успешных запусков — все это напрямую влияет на всеми любимый time to market, то есть время от коммита в систему контроля версий до выпуска версии на продуктивной среде. А примерить их к своей инфраструктуре можно с помощью DevOps-конструктора. Так можно сразу оценить пользу новых инструментов.

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть