В чем разница между системным администратором и инженером DevOps?

При подаче заявления на работу обычно вы можете найти два типа похожих работ: Sysadmin Engineer и DevOps Engineer .

Оба они имеют дело с конфигурацией сервера и обеспечивают надежную работу компьютерных систем. Может быть трудно различить разницу между ними. Каковы основные различия между ними?

В основном DevOps - это не роль (при использовании как таковое это скорее модное слово, чем реальная роль).

DevOps - это пример организации, целью которой является преодоление разобщенности между разработчиками и системными администраторами.
Основная цель состоит в том, чтобы создать группы с разработчиками и системными администраторами (вместе с обычно тестировщиками), ответственными за продукт (приложение) от его определения, архитектурных решений до поддержки в работе этого продукта.
Каждый член команды будет принимать участие в принятии решения по всему жизненному циклу продукта, разработчик будет выполнять некоторые задачи системного администратора в процессе производства, а системный администратор будет участвовать в фазе проектирования продукта, чтобы избежать предостережений с точки зрения инфраструктуры. например.

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

Укороченная версия

DevOps сочетает в себе организационную культуру, Agile / Lean способы работы и автоматизацию программного обеспечения, которые при применении к системному администрированию и эксплуатации позволяют этим функциям работать с тем же уровнем гибкости, что и Agile или Lean Team.

Длинная версия

Идеи, лежащие в основе DevOps, пришли из сообществ системного администрирования, операций и гибкой разработки, в частности, Патрик Дебойс выступил с докладом на Agile2008 под названием «Гибкая инфраструктура», где подчеркнул несоответствие между функционированием трех функций в организации:

1. Agile Development Teams - Agile команды, пишущие код.
2. Команды системных администраторов - Создание инфраструктуры для запуска программного обеспечения.
3. Операционные команды - Поддержка приложений и инфраструктуры в Production / Live.

Предложение Дебуа состояло в том, чтобы объединить три способа совместной работы, в частности, перевести группы системного администрирования и группы операций из модели водопада в гибкую модель. Для этого Debois настроил DevOpsDays 2009 в Генте, Бельгия, по неосторожности придумав фразу « DevOps» .

Идея DevOps нашла отклик у авторов серии книг VisibleOps: Джина Кима, Джорджа Спаффорда и Кевина Бера; который продолжал писать проект «Феникс» и «Руководство DevOps» . Обе книги исследуют, как Agile и Lean могут положительно повлиять на команды системного администрирования и эксплуатации.

Как инженер DevOps, пришедший из опыта эксплуатации, вы перешли от создания и развертывания серверов и программного обеспечения вручную к созданию сценариев установки программного обеспечения на свои серверы с помощью BASH, PowerShell, Python и т. Д. Через некоторое время вы поймете, как Крутые сценарии есть и начинайте изучать более сложные способы автоматизации развертывания .

В конце концов, вы бы выбрали Chef, Puppet, Ansible или другой инструмент управления конфигурацией , который поможет вам управлять состоянием систем вашего парка. По мере того, как ваши навыки в области автоматизации развертывания приложений и управления системой развивались вместе с вашими инструментами, вы совсем недавно перешли в сферу « Инфраструктура как код » и используете ее не только для автоматизации развертывания программного обеспечения, но и для инфраструктуры и необходимых сред. управлять программным обеспечением во время перехода бизнеса в облако.

Теперь вы готовите с газом. Со временем вы познакомились с преимуществами использования инструментов, ориентированных на разработчиков, таких как управление исходным кодом, для управления модулями, рецептами и шаблонами, составляющими ваш арсенал средств развертывания и управления.

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

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

Вы взяли свои навыки в автоматическом развертывании и ввели их в конвейер « CICD », организованный « сервером непрерывной интеграции », таким как Jenkins , Bamboo или Code Pipeline . Теперь, когда разработчики внедряют новый код, ваши скрипты, инструменты и шаблоны поддерживают новые среды по требованию, запускают среды тестирования, чтобы выполнить свою задачу, и разрушают подготовительные среды после того, как в выпуске горят зеленые индикаторы, придерживаясь идеи " непрерывной доставки ".

По мере того, как новый код будет проходить через этапы CICD, вы, разработчики и весь бизнес обретаете уверенность в том, что обновление не прекратится после выпуска в производство. Прежде чем команда перейдет к « непрерывному развертыванию », нужно еще кое-что сделать , но вам все же нужно остановиться на более тонких моментах автоматизации возможности сине-зеленого развертывания, и решение по большей части является деловым. На данный момент вы довольны тем, что количество звонков в 3 часа ночи уменьшилось, а количество sev-1 и sev-2 сократилось.

Даже если вы получите sev-1, вы больше не будете тянуть всю ночь, пока менеджеры дышат вам в спину - вы можете легко выпустить предыдущую версию через конвейер CICD и снова запустить систему в оперативном режиме. Бизнес заметил, что стабильность ИТ-систем улучшилась, несмотря на скорость изменений .

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

Сисадмин против DevOps (личное мнение)

Некоторые компании говорят о Dev, Ops и Test. Если что-то нужно проверить, тогда говорят: «Тест должен сделать это». Если что-то нужно разработать, Dev сделает это, а если потребуется развернуть программное обеспечение, Ops сделает это.

По моему мнению, и то, что я испытал в нескольких компаниях, это то, что это приводит к мышлению «брось через стену», которое приводит к трению между людьми и командами. Лично я иногда чувствую, что люди работают индивидуально и говорят, что это то, что я сделал, мне нечего делать вместо работы в команде.

По моему мнению, DevOps означает, что все в команде ответственны и заняты разработкой, тестированием и эксплуатацией. В команде нет я и нет отдельных отделов. Каждый должен отпустить. Конечно, есть специальности, но, на мой взгляд, каждый должен иметь возможность выполнять не менее 25% работы в каждой области. Например, если кто-то был разработчиком в те времена, тогда можно было бы изменить некоторый код управления конфигурацией, например, chef и развернуть программное обеспечение.

Ссылки

Сисадмин

Согласно Википедии :

Системный администратор, или системный администратор, - это человек, который отвечает за поддержку, настройку и надежную работу компьютерных систем; особенно многопользовательские компьютеры, такие как серверы.

Системный администратор стремится обеспечить, чтобы время безотказной работы, производительность, ресурсы и безопасность компьютеров, которыми он или она управлял, отвечали потребностям пользователей, не превышая бюджет.

Для удовлетворения этих потребностей системный администратор может приобретать, устанавливать или обновлять компьютерные компоненты и программное обеспечение; обеспечить рутинную автоматизацию; поддерживать политики безопасности; устранения неполадок; обучать или контролировать персонал; или предложить техническую поддержку для проектов.

DevOps

Согласно Википедии :

DevOps (сокращенное соединение «разработка» и «эксплуатация») - это процесс разработки и поставки программного обеспечения, который подчеркивает связь и сотрудничество между специалистами по управлению продуктами, разработке программного обеспечения и операциям. Он поддерживает это, автоматизируя и отслеживая процесс интеграции программного обеспечения, тестирования, развертывания и изменений инфраструктуры, создавая среду и среду, в которой создание, тестирование и выпуск программного обеспечения могут происходить быстро, часто и более надежно.

DevOps

DevOps Toolchain

Системный администратор отвечает за обслуживание и настройку серверов, а его обязанность - обеспечить пользователю ту производительность, время работы и безопасность, которые он ищет. Определить роль инженера DevOps немного сложнее, поскольку формального пути карьеры не существует, а сам DevOps может иметь множество форм.

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

Многие люди даже утверждают, что этот переход от системного администратора к инженеру DevOps важен, поскольку в будущем положение системного администратора устареет. Несмотря на то, что существует множество устаревших серверов, которые нуждаются в обслуживании, а системные администраторы обладают большим «знанием племен», положение сисадмина в будущем станет более скудным.

Будут серверы, которые вы не слышите в центрах обработки данных. Все будет программно. Хранение, сеть, системы, безопасность, дата-центры; SDN, брандмауэры, NFV, хранилище, серверы и т. Д. Системные администраторы без опыта разработки программного обеспечения, опыта работы с SDLC (я даже не имею в виду сценарии Perl, Powershell и т. Д.), Вероятно, исчезнут. Распределенные, масштабируемые и виртуализированные среды, в основном облачные, растут горизонтально, а не вертикально.

Смею сказать, что системные администраторы растут вертикально, DevOps (или OpsDev) растут горизонтально. Вы можете увидеть ту же картину, как микросервисы развивались из монолитов. Я бы предпочел выбрать инженера DevOps из команды разработчиков программного обеспечения, а не из команды операций / системы.

Потому что команда операций / системы просто запускает то, что строит команда программного обеспечения.

• Системные администраторы не создают / компилируют ядро ​​Linux / FreeBSD / windows и т. Д., Как инженеры-программисты создают / компилируют приложения.
• Сисадмины не проходят жизненный цикл разработки программного обеспечения (SDLC).
• Сисадмины не являются частью производственного конвейера (процесс CI / CD).

• Системный администратор начинает работать после завершения CI / Continuous Delivery / Deployment.

  И если вы прервете и назначите Deployment / Delivery, это может быть прерванный конвейер,
  команда разработчиков программного обеспечения - это система создателя / операционная команда, в основном, бегуны / смотрители.

Похоже, что нет сервера / системы для администрирования, нет необходимости сисадмина.

Бессерверные вычисления - это модель выполнения облачных вычислений, в которой поставщик облачных услуг выступает в качестве сервера, который динамически управляет распределением ресурсов машины. Ценообразование на основе фактического объема ресурсов , потребляемого приложением, а не на предварительно оплаченные единицах мощности бессерверных вычислений

Кто-то из команды разработчиков программного обеспечения уже знает, как создавать, поддерживать и даже программировать (SRE vs DevOps / OpsDev).

Интересно, почему он называется DevOps, а не OpsDev? это связано с направлением между ними?

* В середине нигде я не начал писать о программно-определяемом хранилище, это реакция на уже удаленный комментарий об этом *

О программно-определяемом хранилище

• Программно-определяемое хранилище (SDS) - это маркетинговый термин, обозначающий программное обеспечение для хранения компьютерных данных, для предоставления на основе политик и управления хранилищем данных независимо от базового оборудования. Программно-определяемое хранилище

• EMC анонсировала свой первый продукт с открытым исходным кодом: Project CoprHD. CoprHD - это контроллер автоматизации и управления программно-определяемым хранилищем, и недавнее решение EMC открыть его исходные тексты лежит в основе нашей стратегии обеспечения большей ценности для глобального бизнеса по мере того, как мы вступаем в область роста и экстремальных изменений. Являясь мировым лидером в области хранения и управления информацией, EMC должна стать лидером в области программно-определяемого хранилища (SDS) .

• CoprHD - это программно-определяемый контроллер хранилища с открытым исходным кодом и платформа API. Он обеспечивает управление на основе политик и облачную автоматизацию ресурсов хранения для провайдеров хранилищ блоков, объектов и файлов CoprHD