На этот раз в студии разбирают спорные тезисы о DevOps программист Стас Михайлов и инженер Ильнур Халилов. За 15 минут они успели обсудить, кто такой DevOps-инженер и за что он отвечает, насколько глубоко разработчику нужно разбираться в инфраструктуре проекта, нужен ли для каждого сервиса свой специфичный CI/CD и многое другое.
Посмотреть выпуск можно на YouTube, Rutube и VK. Где больше нравится.
А ниже — расшифровка встречи по каждому пункту для тех, кому удобнее прочитать.
Нет такой профессии «DevOps-инженер»
Программист: Нет, но…
Мне кажется, что всё-таки профессия есть. Если просто, то DevOps-инженер — это такой человек, который обычным инженером программистом объясняет, как это всё правильно делать. Как деплоить, как пайплайн писать. По крайней мере, я на это надеюсь.
DevOps: Да, но…
Раньше часто можно было услышать, что DevOps — это культура, набор практик, а не человек. Говорили: «Перестаньте админов называть девопсами!» И первое время действительно было много сопротивления. Но сейчас это стало определённым именем нарицательным. И когда говорят, что этот человек — DevOps, то уже в голове выстраивается нужная концептуальная модель, чем он занимается. Так что, можно сказать, что как будто бы эта профессия появилась.
Инженеры придумали слишком сложные инструменты, типа Kubernetes, а большинству продуктов это не нужно
Программист: Конечно нет!
Kubernetes — замечательная штука, которая помогает тебе деплоить, разворачивать приложение и видеть его у себя на экране! Без таких инструментов а программисту пришлось бы закапываться куда-то в дебри. И вместо того, чтобы делать свою бизнес-задачу, он бы разбирался с этим.
DevOps: Нет, но…
Инфраструктурные инструменты направлены на то, чтобы делать хороший продукт для конечных клиентов, которые платят деньги. То есть вся наша деятельность с классными, сложными, простыми инструментами выстраивается вокруг удовлетворения клиента. И тут нужно отталкиваться от какой-то конъюнктуры в момент времени. Если у нас команда из 10 человек, а никто не знает, как пользоваться тем же Kubernetes, а зарелизиться нужно через пару дней, чтобы наш конечный клиент получил некую степень удовлетворённости… То тут иногда можно пренебречь и не очень красиво всё это сделать с точки зрения эксплуатации, зато удовлетворить клиента.
При этом нужно понимать, что чем дальше мы, скажем так, встаем на тёмную сторону, копим технический долг, то однажды можем себя просто похоронить под всей этой сложностью, которую придумывали, чтобы не заезжать на какой-то готовый инструмент. И тут нужно понимать, что это просто вопрос времени, когда стоит этими технологиями пользоваться, а когда не стоит.
Продуктовые разработчики должны сами настраивать деплой своего сервиса
DevOps: Да, но…
Это было бы неплохо, потому что зачастую бывает сценарий, когда мы что-то хотим задеплоить, и есть некая очередность выкатывания сервиса, которая обусловлена бизнес-логикой сервиса. И никто лучше, чем разработчик сервиса, не знает, как всё устроено. Ему проще будет понять, если что-то пойдёт не так: где стрельнуло, в чём случилась проблема.
Но мы уже говорили про большой объём инструментов, который в современных реалиях используется для того, чтобы быстро выкатывать код на продакшн. И может быть такая ситуация, что у разработчика просто недостаточно знаний в этой области, он испытывает сложности. Допустим, он быстренько должен сделать proof of concept, а тут ему на голову валится эта вся история с пайплайном. В этом случае он вполне может попросить помощи — это адекватно.
Программист: Да, но…
Мне кажется, в этот момент и нужны DevOps-инженеры. Когда программист смотрит на TeamCity и не понимает, как это всё работает, то приходит добрый девопс и говорит: «Смотри, он работает так-то и так-то!» И всё сразу хорошо.
Дальше Стас и Ильнур вновь стали рассуждать на тему того, кто же такой DevOps-инженер и должен ли именно он настраивать DevOps-инструменты на компанию или на конкретную команду.
CI/CD не может быть одинаковым для всех сервисов — каждый сервис требует своей специфики
Программист: Нет, но…
У нас в Контуре есть удобные CI/CD шаблоны, которые написаны и для С#, и для Python, и для других языков. То есть какая-то база есть. Но распространить эту базу на все 70+ сервисов, мне кажется, что нереально, потому что всех запросов разработчика невозможно учесть. Ту же базу данных поменяли и всё — надо пайплайн менять.
DevOps: Нет, но…
Если компания занимается разработкой однотипных сервисов, например, в большей части веб-сервисами, то можно сделать общие рельсы. Но если мы понимаем, что набор технологий может отличаться, кто-то использует базу данных, где миграции нужны, а кто-то где эти миграции не нужны, то тут уже возникнет разница.
Так что, отвечая на вопрос про одинаковый для всех процесс, то всё зависит от того, какие технологии используются в командах. Если подходы и инструменты у команды разношёрстные, то достаточно проблематично будет для всех выстроить какие-то одинаковые шаблоны. Но если сам тип приложений очень схож между различными командами, пусть и даже с незначительными отличиями, например, написано на разных языках программирования, то это можно выровнять более-менее общими шаблонами.
За работу сервиса в продакшне должны отвечать не программисты, а специальный сисадмин
DevOps: Конечно нет!
Сам вопрос звучит так, как будто бы мы пытаемся ответственность за результат всей команды замкнуть на одного человека. Допустим, я как продуктовый разработчик схалявил и сделал сервис, скажем так, плохим, подучим. Но я знаю, что это не моя проблема, потому что в субботу ночью разбудят сисадмина Васю. По мне так это совершенно нерабочий и лукавый подход, который снимает ответственность за коллективную работу. За результат должна отвечать вся команда. У всех должен быть интерес, чтобы никто не просыпался по ночам, чтобы всё было классно сделано на всех участках сервиса.
Программист: Нет, но…
По ночам вообще не круто просыпаться, на самом деле. Поэтому давайте делать всё хорошо. А плохо не делать.
Посмотреть выпуск можно на YouTube, Rutube и VK. Пишите в комментариях, как культура DevOps устроена в вашей компании?
Источник: habr.com