Вы слышали про DevOps, но слабо представляете что это такое? Может быть, вы QA-инженер и вас пугает, что спрос на вас может упасть из-за DevOps? Или вы разработчик и хотите прокачать себя и свою команду до внедрения DevOps-а, но не знаете, с чего начать? Ответы под капотом.

На вопросы отвечает Full-stack Engineer в компании ZeroTurnaround, со-ведущий русскоговорящего DevOps подкаста «Two Devs One Ops» Сергей bsideup Егоров (twitter.com/bsideup).

Сергей Егоров:

«… Деплой, изменение инфраструктуры, недостаток знаний о разных частях системы, прозрачность доставки изменений, сложность локальной разработки, “борьба с огнём” после выкатывания на боевые сервера… по каждому из них DevOps даёт ответы и рекомендации»

Развёртывание приложения — это целая наука

– Для начала поговорим о DevOps. Почему эта идеология стала популярной за относительно короткий промежуток времени? Каковы ее главные принципы?

– Я не считаю, что DevOps — это что-то принципиально новое и взявшееся из ниоткуда. Люди и раньше занимались тем, что сейчас считается канонами DevOps подхода. Другое дело — охват, ведь если раньше большие компании на предложение разработчиков участвовать в инфраструктуре предлагали им пойти на X Server, так как это звучало безумно и риски были крайне велики, то сейчас, у тех же самых людей, есть очень большой козырь в рукаве, и этот козырь — опыт. Опыт других команд, больших команд, уровня IT гигантов. Правда, риски никуда не ушли, и шансов «надевопсить» — полно. Но, в целом, тренд очень хороший, решающий реальную проблему — проблему взаимодействия команды, занимающейся разработкой и доставкой одного и того же продукта.

Сложно сказать о главных принципах DevOps. Помогайте друг другу, что ли. Развёртывание приложения — это целая наука, и Вы, как разработчики, должны быть заинтересованы в том, чтобы Ваша разработка нашла своего конечного пользователя, не свалившись по пути. Возьмите рукодельников — они отлично знают о почте, пересылке посылок, нюансах этого процесса. Потому что одна только мысль, что их изделие по пути кто-то швырнёт, придавит, или потеряет, приводит их в ужас. Так почему мы должны к нашим сервисам, которые мы и разрабатываем, относиться плохо и не заботиться о процессе доставки?

… о главных принципах DevOps. Помогайте друг другу, что ли...

– QA считается одной из составляющих DevOps. Корректно ли сравнивать их между собой как две различные методологии и почему?

– Тёплое с мягким. DevOps — это методология, в то время как QA — всё же процесс получения раннего фидбека о Вашем продукте и верификации, что продукт удовлетворяет требованиям, которые к нему поставили. Поэтому и не корректно говорить «DevOps инженер», в то время как «QA инженер» — вполне себе должность. На такие вопросы очень легко ответить, если слово «DevOps» заменить на «Agile». Согласитесь, глупо звучит: «Давайте найдём аджайла!», «А сколько у вас в компании аджайлов?». Нанимают Agile тренеров. Команда следует Agile подходу. И тут так же.

– В чем же принципиальное отличие DevOps подхода от стандартного подхода в QA?

– Из моей собственной практики — в DevOps подходе люди начинают больше писать интеграционных тестов, сокращают циклы разработки. Continuous Delivery — вполне естественный процесс доставки изменений в DevOps среде, а это косвенно улучшает ситуацию для QA, уменьшая количество изменений в билдах, которые ему требуется протестировать. Конечно, ценой увеличения количества этих самых билдов, но тут уже вопрос баланса.


DevOps-методология

Работа разработчика не заканчивается коммитом, она там только начинается

– Как DevOps влияет на жизнь инженеров QA?

– Чаще всего, к QA приходит билд, который уже прошёл какое-то автоматическое тестирование. А ведь интеграционное тестирование позволяет протестировать очень хитрые случаи, которые QA воспроизвести было бы трудно. DevOps очень выделяется всевозможным tooling-ом, и QA в этом вопросе также не обходят стороной. Всевозможные распределённые билд системы, параллелизация тестов. Я точно знаю, что некоторым QA инженерам возможность поднимать окружения для тестирования, максимально близкие к боевым — на вес золота, а ведь это вполне естественно для DevOps подхода, то, к чему стремишься.

– Чаще всего в DevOps используется Continuous Delivery, для которого характерен быстрый темп выкатывания новых релизов и деплоя. Не превращается ли это в итоге в «крысиные бега», когда один человек занимается и написанием кода, и тестированием, и административными функциями?

– Ну, если Вы у себя в команде нанимаете «DevOps-инженера» — то превращается. До тех пор, пока DevOps будут связывать с конкретными людьми — то ситуация будет выглядеть примерно так, ведь спрос будет идти с этих конкретных людей. А вот когда у вас уже команда «пропиталась» DevOps-ом — то выкатыванием занимаются все вместе. Ведь, напоминаю, работа разработчика не заканчивается коммитом, она там только начинается. Довести свои изменения до конечного пользователя — вот это цель каждого.

– Основным инструментом DevOps является всевозможная автоматизация. Как результат — запуск такого процесса становится дорогим. Существует ли граница, до которой использование DevOps не оправдывает себя? От чего это зависит?

– Думаю, наоборот. DevOps позволяет сделать быстрый старт, а потом закрутить гайки. Деплоить прототип продукта через час после хакатона руками с машины разработчика простым скриптом, а потом уже настраивать автоматизацию, например. Тут очень важно следовать подходу MVP — Minimum Viable Product. Это не когда «мы настроили крутой CI сервис, скалируемый, красивые пайплайны нарисовали, но сборка у нас идёт через shell скрипт и вызовы javac». Надо всего понемножку, и улучшать, когда один из слоёв доставки продукта начинает сильно отставать от других.

Главное, чтобы команда в целом была способна справиться с любой ситуацией

– Повышает ли DevOps требования к квалификации участников процесса?

– Боюсь, что да. DevOps вобрал в себя очень много лучших практик, но не все их понимают на достаточном уровне. Например, откройте 12factor.net/ru/ от 2012 года и пройдитесь по этим 12-ти простым пунктам. Очень хорошо определяет готовность разработчика перейти на DevOps процесс, его способность писать современные сервисы, естественные для DevOps.

Но, есть и хорошие новости — благодаря популяризации DevOps, материала просто немеряно, и поднимать квалификацию в данном гораздо проще чем, например, лет 10 назад.

– DevOps — это «бесшовное» соединение нескольких отделов. Означает ли это упрощение логистики внутри компании? Как это сказывается на работе компании в целом?

– Я, честно говоря, плохо себе представляю DevOps команду из 100 человек, например. Гораздо эффективней разбивать отделы на маленькие команды, человек по 10, но при этом команды должны быть кросс-функциональны, то есть иметь всех нужных людей для выполнения поставленной задачи. Кто-то часто путает это с тем, что «в каждой команде должно быть по человеку каждого направления» — это не так. Люди многогранны по своей натуре, и DevOps только лишь подтверждает это, поэтому один и тот же человек в команде может разрабатывать и настраивать инфраструктуру, например. А другой — любитель покодить плагины для Jenkins-а, и вообще хорошо разбирается в системах сборки. Главное, чтобы команда в целом была способна справиться с любой ситуацией, будь то создание репозитория для хранения кода, настройка билд системы, развёртывание кластера в продакшене, реагирование на нотификации систем мониторинга.

– DevOps сильно выделяется своим набором необходимых инструментов? Что в них особенного?

– Ну, дай разработчику заниматься серверами, и он не будет ими заниматься. Он будет разрабатывать для серверов. Разработчики… они ленивые, а значит хотят всё автоматизировать, вот и выходит что с популяризацией DevOps появилось огромное множество всевозможных систем, либо их реинкарнации. Вот возьмите Kubernetes — лидер оркестрации сервисов, практически ни один разговор про DevOps (включая этот) не обходится без его упоминания. Но разве это что-то новое? Нет, Google лишь реализовали «для всех» свой Borg, который они использовали более десятка лет.

Нельзя не упомянуть Docker — ведь тоже, ничего нового, контейнеры существовали очень давно, но именно простота использования таких сложных систем сделала его таким популярным на волне DevOps.

Универсальных инструментов не существует как таковых. DevOps — он не только про инструменты же, нельзя просто сказать «возьмите это, это и это — и будет вам DevOps».

Зависит от Вашего продукта и окружения, в облаке Вы или на своих серверах. Могу лишь сказать, что явный лидер инструментов DevOps — это автоматизация, как разработки и тестирования, так и доставки изменений. Появилось много систем оркестрации вроде Mesos, Kubernetes, Docker Swarm и других, которые позволяют вам работать с Вашей инфраструктурой через API, они очень помогают автоматизировать ту часть, которую часто ошибочно считают «вот это и есть DevOps». Инструменты, превращающие ваши сервера в безликое «стадо», где проблемный сервер проще пересоздать, вместо заботы о каждом сервере отдельно.

– Какие проблемы существуют в современном DevOps-е?

– Думаю, legacy приложения — это одна из самых больших проблем. «Мы тут наш монолитный EAR пытались запихнуть в Docker-контейнер с WebSphere, и чего-то не пошло, не работает Ваш DevOps» — вполне популярное высказывание. DevOps помогает избежать многих проблем в разработке, но он не решает большинство из них, если они уже есть.

Думаю, также нелегко найти людей, которые организовали бы DevOps-команду эффективно. От таких людей требуется идти в ногу с современными технологиями (а без этого никуда, т.к. большинство DevOps-технологий — молодые), при этом иметь опыт организатора. Помните фразу про 10х-разработчика? «Тот, кто поможет остальным 5-ти быть в 2 раза продуктивней». Думаю, это очень хорошо описывает людей, которые продвигают DevOps в своей команде. И это порой очень нелегко, менять подходы других людей, доносить до них значимость тех изменений в процессе, что несёт с собой DevOps. Правда, результат чаще всего оправдывает средства, и успешные DevOps-команды чаще всего вспоминают свой старый процесс «как в страшном сне».

– Расскажи о том, как происходит внедрение DevOps в работу компании? С чего все начинается и как понять, что все «заработало»?

– Каждая команда знает проблемы своего процесса. В конце концов, DevOps как концепция возник из-за проблем процесса, одинаковых проблем, в разных компаниях.

Проанализируйте свой процесс разработки и доставки продукта, найдите узкие места. Деплой, изменение инфраструктуры, недостаток знаний о разных частях системы, прозрачность доставки изменений, сложность локальной разработки, «борьба с огнём» после выкатывания на боевые сервера — думаю, каждый найдёт в этом списке знакомый пункт, а может, и несколько. И по каждому из них DevOps даёт ответы и рекомендации. Успешно решённая подобная проблема — хороший индикатор того, что DevOps начал работать на Вас, а не Вы на него.

– В июне 2016 года на сайте devops.com вышла статья «How DevOps is Killing QA», в которой говорится, что DevOps не нуждается в QA. Как вы можете прокомментировать такую точку зрения?


Статистика поисковых запросов в Google «sqa jobs» и «devops jobs»

– QA как процесс никуда не денется. Да, появляется всё больше и больше автоматизации тестирования, становится проще делать A/B тестирование на реальных пользователях, но вот какое дело… Программист всегда ожидает, что код должен работать. Поэтому, когда программист тестирует свой код, он не ожидает от него другого поведения, он пишет тесты чтобы убедиться, что его код работает. Хороший QA инженер, в свою очередь, не видит код, он видит продукт, он думает о том, что с продуктом можно сделать, что нельзя, и проверяет, что продукт соответствует спецификации. Так что сколько бы тысяч тестов у вас не было написано, если они все написаны программистами — у вас всегда будут баги. Так что QA, админы и все остальные, Вы можете спать спокойно, ведь Вы нужны DevOps, при этом в нём от Вас ожидают делать именно то, в чём Вы так хороши и уникальны.

---

А пока DevOps не пропитал все команды в мире, советуем посетить конференцию Гейзенбаг 2016 Moscow, на которой будем обсуждать всевозможные проблемы тестирования, не только для тестировщиков. Интересно будет и разработчикам, и техлидам:

Список докладов:

• No Such Thing as Manual Testing and Other Confusions
• Appium: Automation for Apps
• Как научить роботов играть в игры?
• Hero’s Journey to Perfect System Tests — Eight Assessment Criteria for Tests’ Architecture Design
• Page Objects — лучше меньше, да лучше
• Тестирование распределенных систем
• Тестирование Android–приложения Juno с ?: CI, Unit, Integration и Functional (UI) тесты. 100% Kotlin, 90%+ RxJava, Spek, JUnit, DSL для UI тестов
• Combining manual and automated testing: process and tools
• Список покупок: что нужно не забыть при запуске JMeter-тестов
• Статический вынос мозга: что скрывают анализаторы кода?