В продолжение серии статей о реальном опыте организации DevOps отделов на предприятиях привожу интервью с cloud архитектором Максимом Козиненко.
В: Добрый день! Сегодня я хочу начать наше интервью сразу с главного вопроса: как оценить работу DevOps-инженера или каким должен быть хороший DevOps-инженер?
- М: Здравствуй! И давай начнем с того, что DevOps-инженеров как профессии не существует, так как DevOps – это идеология. И в понятие DevOps входит пять различных направлений, начиная от релиз-инженера и заканчивая архитектором. И, соответственно критерии оценки для каждого направления будут свои. В любом случае, главная цель «девопса» – это реализация business values. То есть – это сотрудники, которые отвечают за успешность бизнеса.
В: А можешь привести пример?
- М: Конечно! Например, бизнес ставит задачу увеличения количества посетителей сайта в два раза за полгода. Задача DevOps в данном случае суметь организовать процессы, создать платформу, наладить взаимодействие между командами, которые отвечают за релиз софта таким образом, чтобы бизнес имел возможность добиться этих показателей. Понятно, что сам DevOps не имеет никакого отношения к маркетингу или привлечению клиентов, он отвечает за техническую возможность бесперебойно обслуживать клиентов.
В: Позволь уточнить, это специалист DevOps должен всё обеспечить?
- М: Безусловно. Повторюсь, задача DevOps – обеспечить техническую и процессную возможность достижения бизнес-показателей.
В: То есть можно сказать, что DevOps – это скорее менеджер, который отвечает за конечный результат и занимается, в том числе, операционным менеджментом.
- М: Нет. Смысл здесь в другом. Необходимо создать платформу, обеспечивающую нужную масштабируемость, уложиться в рамки отказоустойчивости, которых требует бизнес, наладить релиз процесс, который позволяет делать daily-релизы – вот это все является сутью работы.
В: Понятно. Ну, а если говорить, с точки зрения технических знаний, то кто этот человек?
- М: Здесь нет однозначного ответа. Я уже говорил, что целых пять специальностей укладываются в рамки DevOps. Разные компании видят функции этих специалистов по-разному. Для кого-то это просто automation-инженеры, занимающиеся написанием скриптов, для кого-то – это релиз-инженеры, которые отвечают за build-процесс и так далее. Но, есть, скажем так, каноническое понимание. Мы в рамках DevOps-комьюнити часто спорим на эту тему, и уже сложили общее мнение. По-хорошему, DevOps – это пересечение технологий, которые относятся к следующим областям: automation (как на уровне инфраструктур, так и на уровне управления конфигурациями), automation релиз-процесса, технологии для мониторинга, которых очень много, СУБД. Ну и самое ценное – так называемое Big Picture View, то есть способность видеть всю картину целиком.
В: Ты хочешь сказать, что на украинском рынке на данный момент востребованы два самых просты варианта DevOps: автоматизация и работа с релизами?
- М: В крупных аутсорсерах – да, но в небольших продуктовых компаниях эту тематику знают шире. Там ресурс обычно очень ограничен, соответственно в идеале один специалист должен покрывать как можно больше областей.
В: Но, если вернуться к автоматизации и релизам, задача этих специалистов – максимально быстро поставить код в продакшн. Тогда основными критериями работы являются скорость и качество работы без повторных доработок, правильно?
- М: И да, и нет. Без повторных доработок – это все-таки ближе в QA. С другой стороны – DevOps должен организовать релиз процесс и fallback на крайний случай таким образом, чтобы человеческий фактор как можно меньше влиял на качество релиза. Но на практике не бывает идеальных реализаций.
В: А если представить, что в компании нет DevOps совсем, с чего бы ты посоветовал начинать?
- М: С описания процессов.
В: Каких именно?
- М: В широком смысле процессов. Если DevOps нету, но компания пришла к пониманию необходимости идеологии – значит что то бизнес не устраивает, правильно? А без изменения реализации бизнес задач пытаться сделать кнопку «сделай все хорошо» вряд ли получится. А если и получится, то будет выглядеть, как ребята говорят, «на костылях и распорках». Надежность системы стремится к нулю, внесение изменений превращается в головную боль, ну и прочие радости.
В: Это хорошо звучит в теории.
- М: Так должно быть в идеале. Приведу пример. Я сейчас работаю над проектом, в котором бизнес-показатели напрямую зависят от количества посетителей сайта. Сайт входит в мировой ТОП по посещаемости, соответственно инфраструктура весьма чувствительна к скорости масштабирования. Пики посещаемости предсказать практически невозможно из-за множества влияющих факторов, но нам надо сдерживать этот поток. Проведя анализ, мы выяснили, что масштабирование инфраструктуры в течение двух-трёх минут вполне решает наш вопрос. То есть изначально мы отталкиваемся от бизнес-показателя. И подбираем решение, оптимально соответствующее данной задаче, в том числе и по стоимости.
И еще: задача была поставлена в виде «одна фича в день». Мы должны были построить процесс так, чтобы избежать ситуации, когда во время релиза приложения не отвечают на запросы пользователей.
Но собственно процессы в компании налажены увы не были. Поэтому периодически для обеспечения работы бизнеса в рамках его запросов приходилось «тушить пожар деньгами». Например создавать оверхед по размерам инфраструктуры.
В: А какой стек технологий использовался?
- М: AWS, Terraform, Chef, OpenShift Origin, естественно Docker, сами приложения ввиде микросервисов на Node.JS+Angular, Jenkins, Groovy, JFrog.
В: А почему вы не используете, например, Kubernetes?
- М: Дело в том, что нам изначально нужен был именно PAAS. А Kubernetes – это только основа для такого решения. Да, мы создавали обвязки из Jenkins+Groovy и это в итоге создавало проблемы при необходимости внесения изменений в релиз процесс для какого-либо продукта. Поэтому в итоге перешли на OpenShift (он как раз вокруг Kubernetes написан).
В: Давай от технологий вернемся к вопросам организации. Допустим, есть организация. У неё есть какие-то процессы разработки. Например, они выкладывают релиз каких-то фрагментов, предположим, один раз в неделю. Решили внедрять у себя идеологию DevOps. Просмотрели процессы, которые приносят им больше всего денег. Что дальше?
- М: Нужно смотреть, что технически влияет на эти бизнесс-процессы.
В: Начиная от скорости разработки и заканчивая скоростью деплоя.
- М: Я не зря упоминаю важность анализа процессов. Например, разработчики выдали несовместимый релиз. Что в таком случае может сделать DevOps-инженер?
В: Только откатить назад. Но, это ведь не проблема DevOps.
- М: Когда менеджер придет к разработчику, то разработчик ответит, что на его компе все работает и это не его проблема.
В: Так начинать надо с процесса стандартизации инструментов?
- М: Как вариант. Но важно помнить, что иногда, начиная внедрять новые инструменты (тот же Kubernetes) сталкиваешься с проблемой, что разработчиков надо знакомить с ним с нуля. Часто разработчики просто не знают каких-то сопутствующих технологий, поэтому приходится пересматривать и процессы разработки в том числе. Например, использовать упрощенные среды типа Docker Compose и так далее.
В: То есть ты хочешь сказать, что администраторы или техническая поддержка не могут повлиять на эту ситуацию и все подобные изменения надо внедрять фундаментально, «с головы»?
- М: Да, именно так. Без этого, как показывает практика, сколько бы не проводилось обучений, сессий, эффект от этого околонулевой. Очень сложно научить людей, которые не хотят учиться.
В: Здесь я с тобой согласен. А что по поводу поддержки ваших же больших проектов? Поддержка – это же тоже ваша задача?
- М: Нет. DevOps может быть вовлечен в процесс технической поддержки платформы и сопутствующих решений автоматизации релиза на какое-то время. Это называется «пилотный период».
В: А что после «пилотного периода»?
- М: Дальше происходит knowledge transfer. То есть заказчику передаются определенные масштабы и объемы знаний. Или не заказчику, а выделенной команде поддержки. Хотя распространена и практика поддержки платформ собственно DevOps ребятами. Которые занимаются мониторингом, скрипты по необходимости переписывают и тд.
В продолжении интервью в следующей статье мы обсудим, каким образом осуществляется передача проекта на поддержку.
About The Author
Виктор Карабедянц
ИТ директор (CIO), руководитель нескольких DevOps команд. Профессиональный руководитель проектов по внедрению, поддержке ИТ систем и обслуживанию пользователей.