Окажется, что это либо фулстек веб-мастер, либо специалист с четко выраженными компетенциями — например, сисадмин. Тогда его так и нужно называть — инженер, например, по Continuous Integration. Однако пока в головах менеджеров, которые занимаются управлением в IT, это направление еще не разделилось, и они продолжают существовать в сервисной парадигме, а не думать продуктом и потребностями клиента или пользователей. В сервисном подходе к IT это сотворчество было не обязательно — там все фокусируются просто на поддержке отдельных бизнес-функций. Сейчас же все сообщество ищет подходы в формировании творческой продуктовой разработки — в соединении производства и творчества. Для меня именно это является определением термина DevOps.

Разработчики и тестировщики отвечают за Development, а администраторы — за Operations. Вообще, мне иногда кажется, что у нас пол-команды от сырости прибилось из других отделов. Например, мой коллега перешел из отдела инфраструктурщиков – эти ребята занимаются сетями, балансерами, файрволами и поддержкой сетевой инфраструктуры в целом. Когда мы добрались до этапа тестирования я вдруг devops-инженер понял, что проверить-то и нечем. И уже через час-два у меня был в руках готовый инструмент для тестирования задержки репликации, которым мы успешно пользовались еще какое-то время. Дядька-девопс – удивительный человек, к которому можно прийти со словами “я упаль” и грустными-грустными глазами, и, выслушав пару тяжелых вздохов, получить решение любой проблемы в твоей жизни.

И Неужели Devops Настолько Широк И Многогранен?

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

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

То есть или вся компания идёт по пути DevOps, или там и говорить не о чем. Есть теория, описывающая конечное состояние, а есть суровая реальность. DevOps имеет смысл внедрять преимущественно технологическим компаниям, которые разрабатывают цифровой продукт и для которых важен Time-to-Market в своей нише (время от начала разработки идеи, до того момента, как её увидят пользователи). Хороший специалист должен знать виды операционных систем и разбираться, в какой лучше запустить проект и какими инструментами воспользоваться. Если боитесь зайти не туда или не хотите тратить много времени на самостоятельное освоение, можно получить более основательное образование.

Именно системным администраторам делегируется необходимость общения с конечными пользователями. Часто системные администраторы помогают разработчикам в настройке сети, серверов. Непосредственно в процессе разработки системные администраторы участия не принимают. DevOps всё время находится в поиске “узких мест” архитектуры системы и старается оптимизировать их.

Каким Должен Быть Настоящий Devops?

Потом перейти к Ansible, Terraform, Jenkins, Kubernetes. Это книга-проводник, которая учит использовать Kubernetes для развертывания распределенных контейнеризированных приложений. Она рассчитана на новичков и помогает разобраться с такими принципами работы контейнеров, как мониторинг, настройка и масштабирование.

• К примеру, роль билд-инженера можно отдать в руки разработчика.
• Методология позволяет гибко приспосабливаться к меняющимся условиями и снижать стоимость разработки и обслуживания.
• По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.
• Наконец, для непрерывного отслеживания тоже нужны специальные решения.
• Непосредственно в процессе разработки системные администраторы участия не принимают.
• Это про общее формирование подхода к продуктовой разработке.

На самом деле это входит в предыдущий пункт, но я все же решил его вынести отдельно. Поскольку все текущие проекты в любом случае используют базы данных, было бы неплохо уметь писать SQL запросы, использовать explain и понимать, как работают и зачем нужны index‘ы. DevOps — это сокращение от Development Operations, и, на самом деле, это не название профессии. DevOps-движение возникло в 2008 году и было призвано решить накопившиеся проблемы. Очень много компаний видели проблему во взаимодействиях команд разработки и эксплуатации.

∞ Легко Ли Перейти Из Сисадминов/разработчиков В Devops?

Разбираемся, кому подходит профессия, что должен уметь специалист и как им стать. Постоянно совершенствовать свои знания, смотреть на общую картину процессов и отслеживать путь к поставленной цели. Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все.

DevOPS-инженер должен знать пару языков программирования, чтобы прочитать код, написать быстро программу и автоматизировать процессы. Если вы уже разработчик или системный администратор, можно попытаться освоить профессию самостоятельно. Для этого понадобится проникнуть в специфику смежной области, освоить нужные для DevOps инструменты и разобраться в автоматизации и контейнеризации. Сисадминам обычно проще — знаний в языках программирования от DevOps ждут совсем немного, а вот в IT-инфраструктуре нужно разбираться глубже.

В большой команде такое неминуемо станет бомбой замедленного действия и приведет к проблемам. Ведь каждый разработчик развернет свое творение, как и где ему вздумается, и потом такое наследие невозможно будет поддерживать. К примеру, я видел работающие боевые приложения, развернутые на сервере в домашней папке уволившегося разработчика. Идея в том, что вы должны на хорошем уровне разбираться в среде, в которой будут работать ваши приложения. Как они стартуют (init, systemd), что делать, если вы видите ошибку too many open information, использовать или не использовать swap. Все это очень сильно пригодится, когда вы будете запускать реальные проекты.