Однажды мы поставили систему электронного документооборота заказчику на один объект. А затем к другому объекту.
И еще один.
И на четвертом, и на пятом.
Мы настолько увлеклись, что дошли до 10 распределенных объектов.
Это получилось мощно.
особенно когда мы приступили к внесению изменений.
В рамках поставки на производство 5 сценариев тестирования системы в конечном итоге потребовали 10 часов и 6-7 сотрудников.
Такие затраты заставили нас делать поставки как можно реже.
После трёх лет работы мы не выдержали и решили оживить проект щепоткой DevOps. 
Теперь все тестирование происходит за 3 часа, и в нем участвуют 3 человека: инженер и два тестировщика.
Улучшения четко выражены в цифрах и приводят к снижению столь любимого ТТМ.
По нашему опыту, клиентов, которые могут получить выгоду от DevOps, гораздо больше, чем тех, кто даже знает о нем.
Поэтому, чтобы сделать DevOps ближе к людям, мы разработали простой конструктор, о котором подробнее поговорим в этом посте.
Теперь расскажем подробнее.
Одна энергетическая компания внедряет систему технического документооборота на 10 крупных объектах.
Без DevOps ориентироваться в проектах такого масштаба непросто, поскольку большая доля ручного труда сильно затягивает работу, а также снижает качество — вся ручная работа чревата ошибками.
С другой стороны, есть проекты, где установка всего одна, но все должно работать автоматически, постоянно и без сбоев — например, те же системы документооборота в крупных монолитных организациях.
Иначе кто-то сделает настройки вручную, забудет об инструкции по развертыванию — и в результате в продакшене настройки потеряются и все рухнет. Обычно мы работаем с заказчиком по договору, и в этом случае наши интересы несколько расходятся.
Заказчик смотрит проект строго в рамках бюджета и технического задания.
Ему может быть сложно объяснить преимущества различных DevOps-практик, не включенных в технические спецификации.
Что, если он заинтересован в быстрых выпусках с добавленной ценностью для бизнеса или в построении конвейера автоматизации? Увы, при работе с заранее утвержденной стоимостью этот интерес встречается не всегда.
В нашей практике был случай, когда нам пришлось забрать разработку у недобросовестного и нерадивого подрядчика.
Это было ужасно: не было актуальных исходников, кодовая база одной и той же системы была разной на разных установках, частично отсутствовала документация, частично ужасного качества.
Разумеется, заказчик не имел контроля над исходным кодом, сборкой, релизами и т. д. Пока о DevOps знают не все, но как только мы говорим о его преимуществах, о реальной экономии ресурсов, у всех клиентов загораются глаза.
Таким образом, количество запросов, включающих DevOps, со временем увеличивается.
Здесь, чтобы легко говорить с клиентами на одном языке, нам необходимо быстро соединить бизнес-задачи и практики DevOps, которые помогут построить подходящий конвейер разработки.
Итак, с одной стороны у нас есть набор проблем, с другой — у нас есть DevOps-знания, практики и инструменты.
Почему бы не поделиться своим опытом со всеми?
Создание конструктора DevOps
У Agile есть свой манифест. ITIL имеет собственную методологию.DevOps повезло меньше — он еще не обзавелся шаблонами и стандартами.
Хотя некоторый пытается определяют зрелость компаний на основе оценки их развития и практики работы.
К счастью, известная компания Gartner в 2014 г.
собранный и проанализировали ключевые практики DevOps и взаимосвязь между ними.
На основе этого я выпустил инфографику: 
Мы взяли его за основу дизайнер .
В каждом из четырех направлений есть набор инструментов — мы собрали их в базу, определили самые популярные, определили точки интеграции и подходящие механизмы оптимизации.
В общей сложности получилось 36 практик и 115 инструментов , четверть из которых — это программное обеспечение с открытым исходным кодом или бесплатное программное обеспечение.
Далее мы поговорим о том, чего мы достигли по каждому направлению и в качестве примера о том, как это было реализовано в проекте по созданию технического документооборота, с которого мы начали пост.
Процессы
В нашумевшем проекте S&D система управления технической документацией была развернута по одной и той же схеме на каждой из 10 площадок.
В установку входят 4 сервера: сервер базы данных, сервер приложений, полнотекстового индексирования и управления контентом.
В установке они работают в рамках одного узла и располагаются в дата-центре на объектах.
Все объекты незначительно отличаются по инфраструктуре, но это не мешает глобальному взаимодействию.
Сначала, согласно практикам DevOps, мы автоматизировали инфраструктуру локально, затем вывели поставку на тестовую схему, а затем на продукт заказчика.
Каждый процесс был отработан шаг за шагом.
Настройки среды фиксируются в исходной системе системы, с учетом чего компилируется дистрибутив для автоматического обновления.
В случае изменения конфигурации инженерам достаточно внести соответствующие изменения в систему контроля версий — и тогда автоматическое обновление пройдет без проблем.
Благодаря такому подходу процесс тестирования значительно упростился.
Раньше в проекте были тестировщики, которые только и делали, что вручную обновляли стенды.
Сейчас они просто приходят, видят, что всё работает и делают больше полезных дел.
Каждое обновление тестируется автоматически — от поверхностного уровня до автоматизации бизнес-сценариев.
Результаты публикуются в виде отдельных отчетов в TestRail.
Культура
Непрерывное экспериментирование лучше всего объяснить на примере проектирования тестов.
Тестирование системы, которой еще нет, — это творческая работа.
При написании плана тестирования нужно понимать, как правильно тестировать и каким ветвям следовать.
А также найти баланс между временем и бюджетом, чтобы определить оптимальное количество проверок.
Важно выбрать именно необходимые тесты, продумать, как пользователь будет взаимодействовать с системой, учесть окружение и возможные внешние факторы.
Без постоянных экспериментов обойтись невозможно.
Теперь о культуре взаимодействия.
Раньше было две противоборствующие стороны — инженеры и разработчики.
Разработчики сказали: «Нас не волнует, как это будет запущено.
Вы инженеры, вы умные, сделайте так, чтобы оно работало без сбоев» .
Инженеры ответили: «Вы, разработчики, слишком небрежны.
Давайте будем внимательнее и реже будем играть ваши релизы.
Потому что каждый раз, когда вы даете нам дырявый код, непонятно, как нам взаимодействовать».
.
Это проблема культурного взаимодействия, которая с точки зрения DevOps структурирована иначе.
Здесь и инженеры, и разработчики — часть единой команды, ориентированной на постоянно меняющееся, но в то же время надежное программное обеспечение.
В рамках одной команды специалисты полны решимости помогать друг другу.
Как было раньше? Например, готовилась какая-то толстая инструкция по развертыванию, страниц 50. Инженер прочитал, что-то не понял, выругался и попросил разработчика в три часа ночи прокомментировать.
Разработчик комментировал и тоже ругался — в итоге никто не остался доволен.
Плюс, естественно, были ошибки, потому что в инструкции всего не упомнишь.
И сейчас инженер вместе с разработчиком пишет сценарий автоматизированного развертывания инфраструктуры прикладного программного обеспечения.
И они говорят друг с другом практически на одном языке.
Люди
Размер команды определяется объемом обновления.
Команда набирается при формировании поставки; в него входят заинтересованные лица из общей команды проекта.
Затем вместе с ответственными за каждый этап пишется план обновления, и команда сообщает о его ходе.
Все члены команды взаимозаменяемы.
В составе команды у нас также есть резервный разработчик, но ему практически никогда не приходится подключаться.
Технологии
На технологической схеме выделено несколько точек, но под ними находится куча технологий — с их описаниями можно издать целую книгу.
Итак, выделим самое интересное.
Инфраструктура как код
Сейчас, наверное, эта концепция никого не удивит, но раньше описания инфраструктур оставляли желать лучшего.Инженеры с ужасом посмотрели на инструкцию , испытательные среды были уникальными, их берегли и лелеяли, с них сдували пылинки.
Сегодня никто не боится экспериментировать.
Есть базовые образы виртуальных машин, и готовые сценарии развертывания сред. Все шаблоны и скрипты хранятся в системе контроля версий и оперативно обновляются.
Раньше, когда нужно было доставить посылку на стенд, появлялся пробел в конфигурации.
Теперь вам просто нужно добавить строку в исходный код. Помимо инфраструктурных сценариев и конвейеров, для документирования также используется подход «Документация как код».
Благодаря этому к проекту легко подключать новых людей, знакомить их с системой на основе функций, описанных, например, в плане тестирования, а также повторно использовать тест-кейсы.
Непрерывная доставка и мониторинг
В предыдущей статье про DevOps мы рассказали о том, как выбирали инструменты для реализации непрерывной доставки и мониторинга.Часто нет необходимости что-либо переписывать — достаточно использовать ранее написанные скрипты, правильно выстроить интеграцию между компонентами и создать общую консоль управления.
И все процессы можно запустить одной кнопкой или расписанием.
В английском языке есть разные понятия Continuous Delivery и Continuous Deployment. Оба можно перевести как «непрерывная доставка», но на самом деле между ними есть небольшая разница.
В нашем проекте по техническому документообороту для компании распределенной энергетики используется, скорее, Delivery — когда установка на производство происходит по команде.
При развертывании установка происходит автоматически.
Непрерывная доставка в этом проекте вообще стала центральная часть DevOps .
В общем, собрав определенные параметры, можно наглядно понять, чем полезны практики DevOps. И донесите это до руководства, которое очень любит цифры.
Общее количество запусков, время выполнения этапов скрипта, доля успешных запусков — все это напрямую влияет на всеми любимое время выхода на рынок, то есть время от коммита в систему контроля версий до выпуска версии на сервере.
производственная среда.
При внедрении необходимых инструментов инженеры получают ценные показатели на почту, а руководитель проекта видит их на дашборде.
Таким образом, вы сможете сразу оценить преимущества новых инструментов.
И вы можете опробовать их в своей инфраструктуре с помощью DevOps-конструктора.
Кому понадобится наша DevOps-дизайнер ?
Не будем притворяться: для начала он нам пригодился.Как мы уже говорили, с заказчиком нужно говорить на одном языке, и с помощью DevOps-дизайнера мы можем быстро наметить основу для такого разговора.
Специалисты бизнеса смогут сами оценить, что им нужно, и таким образом развиваться быстрее.
Мы постарались сделать конструктор максимально подробным, добавив кучу описаний, чтобы любой пользователь понимал, что он выбирает. Формат конструктора позволяет учитывать существующие разработки компании в области построения процессов и автоматизации.
Нет необходимости все сносить и перестраивать, если вы можете выбирать только решения, которые хорошо интегрируются с существующими процессами и могут просто заполнить пробелы.
Возможно, ваше развитие уже перешло на более высокий уровень и наш инструмент покажется вам слишком «капитанским».
Но мы считаем это полезным для себя и надеемся, что кому-то из читателей оно окажется полезным.
Мы напоминаем вам связь проектировщику - если что, схему вы получаете сразу после ввода исходных данных.
Будем признательны за ваши отзывы и дополнения.
Теги: #Управление проектами #DevOps #Анализ и проектирование систем #Тестирование ИТ-систем
-
Агентства Веб-Разработки: Информация
19 Oct, 24 -
Новости Фронтенда №1
19 Oct, 24 -
О Системах Голосования
19 Oct, 24 -
Cloud4Y Теперь Доступен В Нидерландах
19 Oct, 24 -
Кривая Планировка
19 Oct, 24
