В этой статье мы расскажем о том, как используем принципы DevOps в своих проектах по поддержке крупных систем. Усложняется все тем, что в системах много Legacy и построены системы на не самых модных сейчас технологиях. 

Немного теории: что такое DevOps

DevOps – это сочетание культурных принципов, подходов и средств, которые помогают компаниям быстро создавать приложения и сервисы.  

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

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

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

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

В компаниях, которые используют модель DevOps, независимо от их организационной структуры, сотрудники рассматривают весь цикл разработки и эксплуатации как часть своих обязанностей.

Это был небольшой экскурс в теорию.

DevOps подходит только для небольших команд?

Есть мнение, что это все очень здорово, но подходит только для небольших команд. И только на новых проектах.   

Но, это не совсем так или даже совсем не так!

Перейдем к примерам

Итак, один из наших проектов: заказчик передаёт нам на обслуживание крупное решение – высоконагруженную систему юридически значимого документооборота. 

На момент старта (лето 2018 года) ежемесячно обрабатывалось около 20 тысяч документов. В системе постоянно работали немногим более 100 пользователей. Была реализована работа с квалифицированными электронными подписями: подписание документов, проверка подлинности КЭП. 

Проблемы клиента

Были введены не все требуемые форматы документов. Стабильность и производительность систем оставляли желать лучшего: документы открывались очень медленно, систему приходилось перезагружать практически ежедневно. Стек технологий: Java 8, Grails 2.5, WebLogic 12c, Oracle 12c.

Решение представляло из себя классический “монолит” из микросервисов. Вроде бы микросервисы были, но:

• независимо друг от друга их невозможно было запустить; 

• база одна – и все микросервисы работали с ней; 

• набор библиотек, которые переплетались взаимными зависимостями. 

Доработки выполнялись, но запуск занимал месяцы. И даже после такой подготовки каждый запуск становился катастрофой. 

Итак, с чего мы начали?

Первая мысль: взять больше разработчиков и тестировщиков. Но бюджет уже был утверждён –не разгуляешься.

Вторая мысль: используя существующие ресурсы, сократить сроки запуска и повысить качество выпускаемых доработок.

Все эти оптимизации проходили болезненно: аварии, «разборы полетов», бессонные ночи и снова аварии. Временами казалось, что из этого круга невозможно выйти. Очень живописно описан этот этап в книге «Проект “Феникс”. Роман о том, как DevOps меняет бизнес к лучшему» (авторы: Спаффорд Джордж, Ким Джин, Бер Кевин). 

В результате мы выработали для себя следующие принципы DevOps.

Первый принцип – единое информационное поле

В работе мы используем веб-инструмент GitLab. При появлении нового проекта, в первую очередь, мы подключаем к GitLab представителей заказчика. Разработчики получают возможность уточнять детали напрямую у заказчика.  

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

Второй принцип – единая команда сопровождения и развития

Даже при единых репозитории и правилах разработки мы регулярно сталкивались с проблемами совместимости доработок.  

Изначально у нас были две отдельные команды: команда развития и команда поддержки. Первая занималась новыми разработками, вторая – устраняла ошибки. Подобный подход приводил к проблемам с синхронизацией изменений в коде. Например, при слиянии кодов двух команд возникали ошибки, и приходилось тратить время на их решение. Другая проблема – из-за одной из команд откладывался выпуск всего релиза. А чаще всего возникали обе эти проблемы: сначала – ошибки из-за слияния, а потом ожидание командами друг друга. Результат один – запуск откладывался. 

Решением было объединение команд.

Третий принцип – постепенное развертывание и решение проблем на ранних этапах

Это самый технический и объемный принцип. Тут мы выстроили следующие правила. 

а) Автоматическая сборка

Первым делом настраиваем автоматическую сборку проекта целиком или определённого модуля. Тут на помощь приходит docker. Даже если нельзя (или нет смысла) использовать docker в продуктиве, он отлично подходит для задач сборки. 

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

б) Автоматизация деплоя

Автоматизируем деплой в тестовую среду. Тут тоже помогает docker. Наша тестовая среда максимально приближена к «боевой» – в ней нет места docker. Но именно из контейнера мы запускаем все деплои модулей WebLogic. Все это гарантирует одинаковый результат. 

в) Автоматизация тестирования

 Для автотестов используем Selenium.

г) Оптимизация задач

Далее идут организационные подходы. Задачи разбиваем как можно мельче. Как только разработчик выполняет задачу (или ее часть), он делает Merge Request (MR). Разработчик разбивает задачи на части так, чтобы каждая такая часть была готова к запуску в продуктив.

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

По каждому MR запускается сборка модуля, выполняются деплой в тестовую среду и прогоняются автоматические тесты.  

Как только возникает ошибка при сборке, деплое или тесте, разработчик, запустивший MR, получает уведомление и видит, что его код что-то сломал. 

Мелкие задачи позволяют значительно сократить время обнаружения проблемы.

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

Итоги работы

Как и в книге Спаффорда Джорджа, Кима Джина, Бера Кевина, через тернии мы пробились к звёздам – за 2 года объем электронного документооборота увеличился более чем в 50 раз! Сейчас ежемесячно компания обрабатывает около 1 миллиона документов. Работают с системой более 2 тысяч пользователей. На данный момент в системе реализованы все требуемые законодательством РФ формы и форматы документов.

Бонус: нормализовав работу системы, мы помогли Заказчику спокойнее перейти на удаленку в начале пандемии.