Мы только что закончили одну систему, которую разработали и развернули в инфраструктуре AWS, используя определенные методы DevOps. Проект имел настоящий успех: мы создали AWS Infra с нуля (был предоставлен только VPC) и разработали систему (2 остальных приложения и 4 приложения интеграции) примерно за 5 месяцев с 1 менеджером проекта и 3 разработчиками.

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

Архитектура

У нас не было времени изобретать колесо, поэтому мы приняли AWS в максимально возможной степени со стратегией: Используйте сервисы AWS в качестве строительных блоков для реализации вашей корпоративной системы », которую мы описали в первая статья AWS. AWS предоставляет все аспекты инфраструктуры корпоративной системы в виде сервисов (сеть, серверы, база данных, очереди, уведомления, хранилище, журналы, сигналы тревоги…). Мы использовали эти сервисы в максимально возможной степени и объединили различные сервисы вместе, чтобы реализовать сложную корпоративную систему, которая потребовала бы гораздо больше времени, чтобы реализовать сбор частей здесь и там и сделать больше адаптации. Все сервисы AWS очень хорошо интегрируются друг с другом, и это сэкономило много времени на проекте.

Автоматизация

При плотном графике у вас нет времени делать что-то дважды, поэтому вам следует автоматизировать абсолютно все. Мы автоматизировали, например,

  • Построить конвейер. Мы использовали Jenkins Pipeline (см. Главную картинку в начале), чтобы все организовать. Когда в Git появлялся новый коммит, запускался конвейер Jenkins; который строит систему, запускает тесты (модульные тесты + интеграционные тесты), запускает статический анализ и отправляет результаты в Sonar, а затем начинает создание AMI (Amazon Machine Image).
  • Изображения. Мы использовали Packer и Ansible для создания AMI, который затем был автоматически развернут в среде разработки для приемочных испытаний. Мы использовали Стратегию сервера Phoenix - вся инфраструктура сервера, приложения и конфигурация были выполнены для образа, и только некоторая информация, относящаяся к среде, была доставлена ​​в AMI при работе в AWS. Если возникла необходимость в другой конфигурации, мы просто создавали новый образ. AWS хорошо поддерживает эту стратегию с помощью репозитория AMI на основе учетной записи AWS.
  • Тесты. Мы автоматизировали все аспекты тестирования: модульные тесты, интеграционные тесты и приемочные тесты. Мы использовали фреймворк Junit с отличным фреймворком для тестирования Spring Boot, а для автоматизации приемочного тестирования - Robot Framework. Покрытие кода было очень хорошим, в некоторых приложениях даже более 90%. Хорошее покрытие кода и автоматизация обеспечили хорошую уверенность в регрессионных тестах для поддержки гибкой работы и непрерывного рефакторинга для улучшения структуры кода.
  • Управление ресурсами. Мы использовали стратегию Инфраструктура как код в отношении ресурсов AWS - все ресурсы и конфигурации AWS управлялись кодом Terraform, версия которого была версирована в Git (см. Более подробное описание стратегии в нашей второй статье AWS «Как создавать ресурсы в инфраструктуре веб-сервисов Amazon и управлять ими? »). Эта стратегия сделала возможным непрерывный рефакторинг в отношении инфраструктуры AWS, а также сделала различные среды (среды разработки, тестирования, среды тестирования производительности и производственной среды) копиями друг друга - различные типы, используемые в разных средах, были параметризованы в коде Terraform (например, RDS / EC2 типы инстансов).
  • Мониторинг. Все аспекты системы отслеживались, а все тревоги настраивались и управлялись с помощью скриптов Terraform. Мониторинг был особенно важен, поскольку после 4 месяцев бурного внедрения мы отправили систему в производство, и члены команды в ближайшие месяцы отслеживали производство, используя наши собственные инструменты мониторинга (настоящий DevOps!). Все приложения отправляют журналы приложений в Cloudwatch. Все экземпляры EC2, очереди, сегменты S3, RDS и т. Д. Имеют различные показатели аварийных сигналов, которые отслеживаются. Если срабатывают сигналы тревоги, Cloudwatch отправляет уведомления темам социальных сетей, разработчики которых подписались на получение сигналов тревоги по электронной почте / SMS. Возможно, благодаря очень хорошей практике автоматизации и всестороннему мониторингу мы могли бы проактивно реагировать на различные ситуации, так что на производстве до сих пор не было никаких инцидентов - заказчик был очень доволен производственной системой.

Методология, люди и культура

  • Межфункциональная команда. У нас была очень маленькая команда: 1 руководитель проекта и 3 разработчика. Все занимались всем: проектированием архитектуры, анализом требований, внедрением инфраструктуры AWS, разработкой и тестированием приложений и т. Д. Все члены команды были разработчиками / архитекторами высшего уровня, использующими проверенные в боевых условиях фреймворки (например, Spring Boot).
  • Свободное общение. Первый месяц мы провели в помещении заказчика, сотрудничая с заказчиком и собирая основные требования для начала работы. Остальная часть проекта все члены команды сидели в военной комнате, предназначенной для проекта.
  • Низкая церемония. Церемония была очень низкой (церемония означала, сколько бюрократических процессов и хлопот возникает в программном проекте). Было меньше бюрократии и бумажной работы, а больше реальной работы по внедрению. Например. Мы использовали стену военного помещения для быстрого проектирования, быстро отрисовывая различные идеи на стене, а затем реализовали их в коде.
  • Очень весело. Было очень весело работать вместе. Сотрудничество с заказчиком было оперативным и легким. Все члены команды высоко оценили большой опыт обучения, полученный в ходе проекта. Поэтому моральный дух на работе был высоким и продуктивным.

Оба автора являются сертифицированными специалистами по архитектуре решений AWS, занимаются проектированием и реализацией проектов AWS в Tieto CEM Finland. Если вы заинтересованы в запуске нового проекта AWS в Финляндии, вы можете связаться с нами, используя имя / имя на tieto.com.

Кари Марттила и Тимо Тапанайнен