Девопс есть во многих компаниях, но он везде разный. Чтобы понять, что происходит в отрасли, какие есть тренды и какие компетенции будут востребованы, мы провели круглый стол с экспертами. Обсуждаем, где девопс сейчас, каковы тенденции и чего ждать компаниям и девопс-инженерам в будущем.
Эта статья — краткий конспект круглого стола «Куда катится девопс». Если не хотите читать, можно посмотреть запись.
На вопросы про девопс отвечают:
Виктор Попов. DevOps в НЛМК IT.
Кирилл Борисов. Infrastructure Engineer технологического центра Deutsche Bank.
Тимофей Ларкин. DevOps-инженер.
Петр Щербаков. Solution Architect в крупном ритейле.
Спикеры ответят на пять вопросов о девопсе. Где-то их мнения совпадут, где-то нет — выводы для себя делайте сами.
Первый вопрос. Недавно девопс был в тренде — а что сейчас? Сохраняется ли популярность или грядёт что-то новое?
Виктор Попов. На мой взгляд, девопс как внедряли раньше, так и внедряют сейчас. Это не результат, а процесс, в который нужно постоянно подкидывать дровишки. То есть надо постоянно продолжать внедрять девопс, чтобы хаос всё не пожрал.
Изменения будут, конечно. Уже появляются DevSecOps, DevBizOps и прочее, но об этом мы поговорим дальше. А два основных компонента, Dev и Ops, точно останутся.
Кроме того, девопс идёт по пути стандартизации. Когда аутсорс-компания предлагает фирме, условно, одну кнопку, которая им поднимет инфраструктуру. Кому-то это кажется упрощением, но по факту помогает в ситуациях, когда нужно что-то стандартное. А если хочется нестандартного, то, конечно, приходится всё настраивать вручную.
Петр Щербаков. Девопс — действительно итеративный процесс, который никогда не завершается. Как его развитие появляется GitOps, когда мы разворачиваем сервисы полностью из кода.
Кирилл Борисов. Бизнес не стоит на месте — появляются новые требования, продукты и процессы. Поэтому и девопс не стоит на месте — приходится постоянно развиваться технически, чтобы успевать за потребностями бизнеса. Думаю, всё так и будет продолжаться.
Тимофей Ларкин. На мой взгляд, несмотря на то, что все вокруг уже который год говорят про девопс-практики, проводится столько конференций и прочего «всего хорошего против всего плохого», поток компаний, у которых цифровая трансформация выражается в «помогайте нашим разработчикам и пишите им пайплайны» не заканчивается. Казалось бы, все уже за последние пять лет должны были научиться, но нет, начинающих коллег, которые работают по стандартам пятилетней давности, всё ещё хватает.
И это не плохо! Это значит, что тренд и спрос на девопс сохраняются, как пять лет назад. Тогда девопсы были нарасхват, и сейчас на них спрос не иссякает.
Но улучшения, конечно, происходят. Те компании, которые начали активно этим заниматься 2–5 лет назад, уже достигли каких-то результатов. Возможно, они успели не только достичь этих результатов, но и просрать их.
Второй вопрос. Какое развитие возможно для компании, в которой уже есть девопс?
Кирилл Борисов. Совершенству нет предела — нужно, чтобы всё становилось ещё лучше и проще. С точки зрения самого девопса — стоит больше коммуницировать с бизнесом, отталкиваться от их желаний. Ведь технологии не живут сами по себе, они существуют в синергии с бизнесом.
Кажется, что пока очень мало компаний действительно налаживают связь между бизнесом и девопсом. Например, в девопс чаще берут людей по техническим скилам — а на софт-скилы почти не обращают внимания. А ведь девопс во многом о коммуникациях, и одних знаний технологий тут мало.
Виктор Попов. А что значит «уже внедрён девопс»? Берёшь Accelerate, считаешь метрики. Если набрал больше 60%, то внедрён? Или сколько процентов надо? Кажется, никто толком не знает.
Повторюсь, девопс — это процесс, а не результат. Пока вы внедряли одни рекомендации, появились другие. Нужно постоянно анализировать, что из этого подходит именно вам и решает именно ваши проблемы. А если не знаете, чем ещё заняться и где сделать лучше — начните прикручивать security!
Тимофей Ларкин. Я на самом деле тоже не до конца понимаю, что значит «внедрили девопс»? Это какой-то конкретный результат? На мой взгляд, это выстроенная система, в которой разработчики напрямую работают с продакшеном, а не куда-то через забор перекидываются гит-коммитами. И такое не всегда есть даже там, где вроде бы построен девопс.
Петр Щербаков. Внедрение девопс у нас не заканчивается на работе девопс-инженеров. Нужно, чтобы разработчики в том числе разбирались не только в Dev, но и в Ops, были готовы погружаться в operations и хотя бы понимать, какие процессы идут на стороне админов. Общаться, сообщать друг другу о рисках и разбираться в работе друг друга. То есть опять же всё сводится к коммуникации.
Если же говорить именно о развитии девопс, то сейчас есть тенденция ухода инфраструктуры в облако. За границей это уже очень распространено, но и мы в России до этого доросли. Облачные платформы позволяют выстроить девопс-инфраструктуру и обеспечивают её поддержку даже без отлаженных девопс-процессов внутри компании.
Третий вопрос. DevSecOps, DevTestOps и прочее — станет ли это также популярно, как простой девопс?
Виктор Попов. Конкретно DevSecOps я считаю очень правильным явлением. В этом направлении много классных инструментов, но на самом деле оно не про инструменты, а про общий взгляд на вещи. В то время, когда случайный пакет из-за публичного репозитория может лишить вас половины компании, DevSecOps приобретает особое значение. Оторванная от реальности классическая безопасность уже не работает — изменилась модель угроз, поменялись риски и скорость работы. И без DevSecOps уже никуда.
Я DevSecOps вижу как отдельную компетенцию, которую не получится полноценно размазать в девопсе. Скорее всего, это направление станет существовать отдельно, в особой зоне ответственности. И заниматься им станут отдельные люди.
С DevTestOps, на мой взгляд, история примерно такая же. Встраивание тестирования во все процессы, по-моему, попадает, в том числе и в парадигму обычного девопса, но можно выделить это и отдельно. Чтобы дружить не только разработчикам, админам и безопасникам, но и тестировщикам.
Петр Щербаков. В наших реалиях DevSecOps — хороший способ избежать проблем. Но нужно понимать, что добавка Sec — несколько другая по культуре и методологии. И если в девопсе мы опираемся на физические составляющие, то в DevSecOps — на риск-ориентированный подход. DevSecOps даже больше про культуру, чем нынешний девопс.
При этом было бы идеально, если бы каждый инженер или разработчик думал о безопасности продукта. Но, к сожалению, это не так. У меня была история, когда ребята делали обычный трехзвеньевой сервис: фронтенд, бэкенд и база. И вместо реверс-прокси просто напрямую открыли бэкенд публичным адресом — сканируй и делай всё, что хочешь. Пока такое будет происходить, будут нужны безопасники, и одним DevSecOps сыт не будешь.
DevTestOps я воспринимаю не как отдельный термин. Общаться должны все, без тестов нормального конвейера не будет — мы все в цепочке, все повязаны.
Тимофей Ларкин. Мне кажется, что все эти популярные на российских конференциях разговоры про DevSecOps заводятся из-за усталости разработчиков от параноидальных безопасников. Разработчики хотят убедить безопасников ослабить свою железную хватку путём включения тестирования приложений на безопасность в пайплайн вместо изнурительного ручного аудита со стороны инфобезов. И тут DevSecOps играет им на руку.
Четвертый вопрос. Почему девопс везде такой разный? И бывает ли «хороший» и «плохой» девопс?
Виктор Попов. Он разный, потому что у всех разные условия. Конечно, если с нуля создать четыре транснациональных гиперконтинентальных IT-компании с нуля и выстроить в них девопс, он будет практически идентичным. Но в реальности у тебя есть компания с культурой и процессами — и что-то ложится на девопс проще, а что-то сложнее.
Я считаю, что если вы с «плохим» девопсом повысили качество кода и стали быстрее его доставлять, может, он не такой и плохой. В условном Гугле вас бы засмеяли, но у вас всё работает, вы зарабатываете деньги — почему нет?
Вообще мне в этом контексте очень нравится цитата Харуки Мураками про бег: «Боль будет обязательно, а вот страдания — это ваш выбор». Девопс работает так же.
Кирилл Борисов. Такое уже было с Agile, когда в компании прочитали книгу, начали всё делать красиво и по учебнику — а ничего не работает, потому что у компаний свои особенности и возможности. Так и с девопсом — нужно внедрять с умом и правильно всё это накручивать на устоявшиеся процессы. И всегда понимать, какую конкретно проблему ты сейчас решаешь, уметь трансформировать свои знания под текущие особенности. Например, мы как-то прочитали про Kubernetes и попытались его внедрить там, где он не нужен. Сделали всё по книжке, а создали себе 10 тысяч проблем.
Пятый вопрос. Как лично для вас выглядит «идеальный девопс»?
Тимофей Ларкин. Идеальный — это когда нас всех уволят и мы будем не нужны. Чтобы всё работало само. Тогда можно будет переквалифицироваться в разработчика, если их к тому времени тоже не заменят.
Петр Щербаков. С этим я согласен. Когда-то я видел видео от Яндекса, где они говорили про будущее нашего IT и в целом разработки. Кто-то сказал, что мы дойдем до момента, когда даже тракторист будет знать Java, чтобы настроить свой трактор.
Виктор Попов. У меня более приземлённое представление идеального девопса — просто крутой конвейер, который позволяет делать релизы каждые 15–20 минут. Все автоматически тестируется, двигается, деплоится. Идеальный девопс — это когда всё работает, а ты нет.
Кирилл Борисов. Для меня идеальный девопс — это когда в конвейере минимум проблем. Они есть, но нет этих горящих голов и красных глаз, когда ты пытаешься всё починить, а ничего не работает. Меньше проблем — ближе идеальный девопс.
Таким был круглый стол «Куда катится девопс». Для тех, кто хочет вкатиться в профессию и перейти в девопс из администрирования или разработки, мы подготовили курс DevOps Upgrade, старт потока 15 сентября.
