Техподдержка на стероидах: как Jenkins помог ускориться в 10 раз

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

Вручную приходится работать с:

- получением логов;

- запуском и выключением приложений;

- обновлением приложений.

Как следствие имеем:

- Значительное влияние человеческого фактора на доступность системы - «закрытый» монолит, все операции администрирования производятся вручную;

- Приложение - монолит, артефакт докера занимает примерно 1.5 Гб;

- Неэффективное использование человеческих ресурсов - 100% времени сотрудников поддержки расходуется на функции администрирования систем.

Кроме того:

  • Техническая поддержка вендора может изменять файлы конфигураций без логирования;
  • Если в конфигурацию добавлен новый параметр, то нет гарантий, что приложение будет корректно работать;
  • Логирование оставляет желать лучшего (ежедневно в логи пишется 10 - 30 Гб неструктурированной информации).

Для решения описанных проблем было решено перенять функции сопровождения системы от вендора на сторону банка. Для поддержки процесса перехода мы использовали Jenkins. Данное ПО позволяет автоматизировать рутинные, регламентные и административные операции.

Начну с итогов проекта внедрения Jenkins и полученного бизнес-эффекта: введено в эксплуатацию 30 пайплайнов, из них 6 полностью автоматические.

Данные инструменты покрывают бОльшую часть задач команды технической поддержки банка:

- оповещения о недоступности сервисов (было 7 мин, стало 1 мин);

- получение логов (было 10 мин / стало 20 сек);

- снятие дампов памяти (было 50 мин, выполняла только платформенная команда / стало 20 мин, выполнить может любой пользователь, получаем 2 дампа + архивирование);

- перезапуск приложений (было 7 мин / стало 1 мин);

- резервное копирование (автоматическая задача, не тратит ресурс, ранее не было использовано);

- сбор ошибок в логах приложения (было 5 минут / стало 10 секунд);

- запуск обновления приложения (было 10 мин / стало 1 мин);

Критерии выбора Jenkins:

- Инструмент с открытым исходным кодом;

- Более 1000 плагинов для автоматизации рутинных операций;

- Бесплатное использование;

- Разработано на Java и, следовательно, применимо для поддержки множества систем;

- Два способа контроля доступа: проверка подлинности пользователя и авторизация;

- Соответствует требованиям информационной безопасности.

Пример использования Jenkins для автоматизации обновления приложений.

Процедура ручного обновления стенда выглядит так:

1. ssh user@host - открыть PUTTY и зайти на сервер приложения

password: - ввести пароль

2. sudo - поднять привилегии до рута

3. docker login vendor.repository.com - залогиниться в репозиторий вендора

4. docker pull vendor.repository.com:/image:2 - скачать артефакт

5. docker tag ... - перемаркировать полученный артефакт

6. docker login bank.repository.com - залогиниться в репозиторий банка

7. docker push bank.repository.com/image:2 - закачать перемаркированный артефакт в репозиторий банка

8. cd /home/web/ - перейти в директорию приложения

9. docker-compose rm -sf - остановить приложение

10. vi docker-compose.yml - внести изменения в конфигурационный файл приложения

11. docker-compose up -d - запустить приложение

Техподдержка на стероидах: как Jenkins помог ускориться в 10 раз

Структура пайплайна по обновлению стенда с помощью Jenkins:

========== пайплайн проверки артефакта ============

========== пайплайн получения артефакта ===========

docker login vendor.repository.com

docker pull vendor.repository.com:/image:2

docker tag ...

========== пайплайн сохранения артефакта ==========

docker login bank.repository.com

docker push bank.repository.com/image:2

cd /home/web/

========== пайплайн остановки/чистки стенда ========

docker-compose rm -sf

========== пайплайн редактирования конфига ========

vi docker-compose.yml

- image: bank.repository.com/image:1

+ image: bank.repository.com/image:2

========== пайплайн запуска стенда ================

docker-compose up -d

===============================================

Визуальное сравнение после:

Техподдержка на стероидах: как Jenkins помог ускориться в 10 раз

Результат:

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

Стоит отметить основные преимущества Jenkins для нашей команды:

- Исключение ошибок под влиянием человеческого фактора в 99 случаях из 100;

- Повторяемость операций и предсказуемое поведение, а также идемпотентность, как свойство системы принимать одно и то же состояние при одинаковых условиях вызова;

- Уменьшение затрат на команду административного сопровождения системы АС и инфраструктуры;

- Исключение bus-фактора в виде высококвалифицированного администратора для поддержки системы.

Итог

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

Более того, автоматизированные задачи работают быстрее, чем традиционный подход к администрированию (вход на сервера вручную через клиент ssh и выполнение ручных операций), но не несут с собой рисков совершить ошибку (опечатка, недостаточная квалификация, проблемы доступа).

Главный бенефит - возможность исключить платформенную команду из решения мелких задач (проблем), сконцентрироваться на решении важных.

В дальнейшем планируется рефакторинг кода пайплайнов с целью создания общей библиотеки для эффективного переиспользования.

Jenkins подобно конструктору позволяет создавать пайплайны, которые могут взаимодействовать между собой - как базовые утилиты Линукс, создавая некий "конвейер".

Мы бы рекомендовали создавать атомарные пайплайны, которые решают одну задачу и объединять их между собой. Такие пайплайны просты и понятны, не требуют документации, в них сложно совершить ошибку, но, при этом, универсальны. Их можно объединять между собой для решения разных задач.

1.6K1.6K показов
334334 открытия
Начать дискуссию