31
Рисунок 14. Схема бизнес-процессов разработки
32
1.2.2 Определение места проектируемой задачи в комплексе задач и ее
описание
Во многих IT-компаниях есть конфликт между отделом разработки и
эксплуатации, который заключается в том, что девелоперам необходимо
доставлять код тактически, тогда как эксплуатация работает, скорее
стратегически, она заинтересована в том, чтобы в рабочем окружении было
минимальное количество ошибок, а постоянные изменения в производственном
окружении могут накапливать проблемы и могут возникать пожары, которые
необходимо постоянно тушить. Соответственно, с обеих сторон растёт
технический долг — термин, предложенный Уордом Каннингемом.
Технический долг — решения, необходимые для ликвидации проблем, с
течением времени становящихся все более трудно разрешимыми при
постоянном уменьшении будущих возможностей для маневра.
Дело в том, что приходится пытаться одновременно достигать сразу двух
целей:
1. Реагировать на быстро меняющийся конкурентный ландшафт, который
связан с постоянно меняющимися требованиями бизнеса.
2. Необходимо производить стабильный, надёжный и, что самое сложное,
безопасный сервис для клиентов.
В нашем случае разработчики берут на себя реагирование на изменения
на рынке и потребности клиентов в короткие сроки. Они работают по спринтам,
которые длятся 2 недели для исправления ошибок и добавления нового
функционала. От них также ожидается, что критические ошибки будут
исправляться немедленно. Эксплуатация при этом заинтересована в том, чтобы
обеспечить предоставление заказчикам стабильной инфраструктуры (пункт 2).
Получается, разработчики и эксплуатация преследуют разные цели.
Элияху Голдратт, который создал методологию управления
производством под названием «Теория ограничений», назвал эту ситуацию
корневым хроническим конфликтом. Этот конфликт провоцирует
возникновение нисходящей спирали, которая приводит к созданию
33
некачественного ПО, а также к поиску большого количества обходных путей для
решения проблем, что также приводит к росту Технического долга и разнице в
производственной и тестовых средах.
Итак, в отделе эксплуатации цель — сохранение работоспособности
приложений и инфраструктуры, чтобы передавать клиентам продукцию. Многие
проблемы здесь связаны с тем, что решения, которые нужны для поддержания
работоспособного состояния, зачастую очень сложные, их сложно
документировать, и они весьма хрупкие. И именно такие хрупкие системы
зачастую носят самый главный функционал, необходимый бизнесу. И это
наносит удар финансам, безопасности данных пользователей, точности отчётов
и т.д. И правки, которые вносятся в инфраструктуру, когда необходимо срочно
что-то починить руками, затем очень сложно воспроизводимы.
Затем необходимо компенсировать невыполненные обязательства, и
всегда появляются новые обещания со стороны руководства по созданию нового
функционала, который зачастую несовместим с хрупкой системой. Поэтому
технический долг неуклонно растёт.
При обилии ручной работы для деплоймента программного обеспечения
это может занимать невероятно длинное количество времени, поэтому доставку
ПО необходимо автоматизировать. И, в связи с вышеописанным, необходимо
сделать так, чтобы результат развёрнутой инфраструктуры всегда был
идемпотентным, а также сделать так, чтобы девелоперская, тестовая и
производственная среды были максимально похожи для того, чтобы иметь
похожие результаты при одинаковых условиях.
1.2.3 Обоснование необходимости использования вычислительной
техники для решения задачи
Основной скоуп задач, связан с тем, чтобы уменьшить Время Выхода на
рынок продукта (Time to Market) и внедрение DevOps практик и инструментов
[11] для улучшения коллаборации, передачи информации между людьми и
машинами и автоматизации работ по деплойменту и тестирования приложений.
34
Для того, чтобы тестирование было максимально эффективным,
необходимо, чтобы тестовая и производственной среды были максимально
приближены друг к другу по составу и характеристикам. Для этого необходимо
использовать подход Инфраструктура как Код (Infrastructure as Code) [3], чтобы
избежать разницы между средами. Изначально регрессивное тестирование
проводилось вручную и занимало продолжительное количество времени,
поэтому запуск тестов сделали по расписанию в автоматическом режиме, это
позволило уменьшить время с 2 недель до часа. Также все этапы деплоймента
были полностью автоматизированы, что позволило значительно ускорить
доставку ПО, избежать ручных операций, и, как следствие, человеческих
ошибок. Соответственно, время выхода продукта на рынок значительно
сократилось, и клиенты могут видеть новый функционал каждые две недели – в
соответствии со временем одного спринта в рамках подхода гибкой разработки
Agile
Рисунок 15. Схема итеративной разработки в рамках Agile подхода
Чем короче цикл поставки программного обеспечения конечному
клиенту, тем быстрее мы можем получать обратную связь, проверять гипотезы и
исправлять ошибки в производственном окружении. Также такой подход
позволяет непрерывно тестировать, собирать телеметрию и другие метрики для
более глубокого понимания состояния системы, её анализа, анализа реакции
рынка и влияния продукта на рынок и наоборот влияния рынка на продукт во
времени. Также очень важно понимать состояние самой системы на каждом
35
этапе её разработки: на этапе разработки, во время тестирования и в
производственной среде. Это один из важных факторов внедрения DevOps
практик.
Рисунок 16. Второй путь DevOps – непрерывная обратная связь
Кроме того, во многих IT-компаниях есть конфликт между отделом
разработки и эксплуатации, который заключается в том, что девелоперам
необходимо доставлять код тактически, тогда как эксплуатация работает, скорее
стратегически, она заинтересована в том, чтобы в рабочем окружении было
минимальное количество ошибок, а постоянные изменения в производственном
окружении могут накапливать проблемы и могут возникать пожары, которые
необходимо постоянно тушить. Соответственно, с обеих сторон растёт
технический долг — термин, предложенный Уордом Каннингемом.
Технический долг — решения, необходимые для ликвидации проблем, с
течением времени становящихся все более трудно разрешимыми при
постоянном уменьшении будущих возможностей для маневра.
Дело в том, что приходится пытаться одновременно достигать сразу двух
целей:
3. Реагировать на быстро меняющийся конкурентный ландшафт, который
связан с постоянно меняющимися требованиями бизнеса.
4. Необходимо производить стабильный, надёжный и, что самое сложное,
безопасный сервис для клиентов.
В нашем случае разработчики берут на себя реагирование на изменения
на рынке и потребности клиентов в короткие сроки. Они работают по спринтам,
которые длятся 2 недели для исправления ошибок и добавления нового
функционала. От них также ожидается, что критические ошибки будут
36
исправляться немедленно. Эксплуатация при этом заинтересована в том, чтобы
обеспечить предоставление заказчикам стабильной инфраструктуры (пункт 2).
Получается, разработчики и эксплуатация преследуют разные цели.
Элияху Голдратт, который создал методологию управления
производством под названием «Теория ограничений», назвал эту ситуацию
корневым хроническим конфликтом. Этот конфликт провоцирует
возникновение нисходящей спирали, которая приводит к созданию
некачественного ПО, а также к поиску большого количества обходных путей для
решения проблем, что также приводит к росту Технического долга и разнице в
производственной и тестовых средах.
Итак, в отделе эксплуатации цель — сохранение работоспособности
приложений и инфраструктуры, чтобы передавать клиентам продукцию. Многие
проблемы здесь связаны с тем, что решения, которые нужны для поддержания
работоспособного состояния, зачастую очень сложные, их сложно
документировать, и они весьма хрупкие. И именно такие хрупкие системы
зачастую носят самый главный функционал, необходимый бизнесу. И это
наносит удар финансам, безопасности данных пользователей, точности отчётов
и т.д. И правки, которые вносятся в инфраструктуру, когда необходимо срочно
что-то починить руками, затем очень сложно воспроизводимы.
Затем необходимо компенсировать невыполненные обязательства, и
всегда появляются новые обещания со стороны руководства по созданию нового
функционала, который зачастую несовместим с хрупкой системой. Поэтому
технический долг неуклонно растёт.
При обилии ручной работы для деплоймента программного обеспечения
это может занимать невероятно длинное количество времени, поэтому доставку
ПО необходимо автоматизировать. И, в связи с вышеописанным, необходимо
сделать так, чтобы результат развёрнутой инфраструктуры всегда был
идемпотентным, а также сделать так, чтобы девелоперская, тестовая и
производственная среды были максимально похожи для того, чтобы иметь
похожие результаты при одинаковых условиях.
37
Рисунок 17. Схема документооборота
1.2.4 Анализ системы обеспечения информационной безопасности и
защиты информации
Необходимость обрабатывать карточные данные клиентов обозначает
необходимость соответствия платформы требованиям PCI DSS, а также GDPR в
связи с наличием клиентов из Европейских стран.
Доступ по SSH к пограничным серверам предоставляется с помощью
бастион (jump) сервера, который является шлюзом для SSH, он расположен
снаружи демилитаризованной зоны. Доступ к пограничным серверам можно
получить с помощью команды следующего вида: ssh -J username1@jump-
server:port username2@destination-server:port
Доступ по портам осуществляется с помощью встроенных в AWS групп
безопасности (Security Groups) [12], который определяет на уровне L4 открытые
38
порты, из какого источника может осуществляться доступ (IP или другая группа
безопасности), и какой протокол используется.
Рисунок 18. AWS Security Groups
Каждый хост находится в одной или нескольких группах безопасности.
Например, для бастион сервера необходимо открыть только 22 порт для доступа
извне и порт 5044 для доступа из внутренней сети для сбора логов с помощью
утилиты Filebeat. Cоздана группа HapiProdBastion_SG и извне разрешён только
SSH трафик:
Рисунок 19. Настройка группы безопасности для бастион сервера
Для web-сервера Nginx [13], через который клиенты получают доступ к
необходимым сервисам открыты порты 443 и 80 извне, на самом Nginx настроен
переброс с HTTP на HTTPS трафик для возможности TLS подключения. И 22
39
порт открыт для внутренней подсети, чтобы на него можно было подключиться
через бастион сервер по протоколу SSH.
Рисунок 20. Настройка группы безопасности для веб-сервера
Все остальные инстансы и сервисы развёрнуты внутри
демилитаризованной зоны (ДМЗ) с политиками безопасности, которые
разрешают только запросы внутри зоны, весь трафик внутри ДМЗ по умолчанию
разрешён в обе стороны по всем портам.
Управление доступом и идентификацией к инфраструктуре
предоставляется с помощью сервиса AWS IAM (Identity and Access Management)
[14] через политики, которые основаны на ролях (Role-based Access Control,
RBAC). Для каждого пользователя создаётся свой IAM юнит с логином и
паролем, и при необходимости для пользователя создаются пара ключ и
секретный ключ, которые позволяют взаимодействовать с AWS API через набор
средств разработки (Software Development Kit, SDK) или через специальную
командную утилиту AWSCLI.
Рисунок 21. Управление доступом и идентификацией в AWS
40
1.3 Анализ существующих разработок и выбор стратегии автоматизации
«КАК ДОЛЖНО БЫТЬ»
1.3.1 Анализ существующих разработок для автоматизации задачи
Внедрение системы интеграции
Выбор для системы интеграции был в удобстве, функциональности,
надёжности, наличие бесплатной версии и поддержки Java. Подходящие
инструменты:
• JetBrains TeamCity — удобный UI интерфейс, низкий уровень входа,
в бесплатной версии доступна установка 3 агентов, есть поддержка UI
тестирования
• Jenkins 2 — не очень удобный интерфейс, но много поддерживаемых
модулей
• Bitbucket CI — поставляется вместе с репозиторием, шаги сборки
описываются в виде кода
• AWS Code Pipeline — плата осуществляется за пайплайны
• GitLab — удобный интерфейс, плохая интеграция с
аутентификацией, конвейеры поставки в виде кода
Так как одна из самых главных составляющих DevOps это понимание
всеми членами команды, как работать с инструментами, мы решили
использовать TeamCity Server от JetBrains: там есть удобный интерфейс с низким
уровнем входа для понимания, а также возможность собирать проекты на Java
12, а также наличие интеграций с AWS и Selenoid для тестирования
пользовательского интерфейса.
Облачная инфраструктура
Исторически инфраструктура развёрнута в AWS, где используются
ресурсы виртуальных машин Elastic Compute Cloud [15]. Документ
ориентированная база данных в облачной платформе https://www.mongodb.com/
, стриминговая база данных Kafka [5] располагается на PaaS (Platform As a
Service) https://aiven.io/ , управление DNS записями осуществляется через