Яка різниця між Sysadmin та DevOps Engineer?

Подаючи заявку на роботу, зазвичай можна знайти два типи подібних робіт: Sysadmin Engineer та DevOps Engineer .

Обидва вони мають справу з налаштуванням сервера та забезпечують надійну роботу комп'ютерних систем. Різницю між ними може бути важко сказати. Які основні відмінності між ними?

В основному DevOps не є роллю (при використанні як такої це швидше модна мова, ніж реальна роль).

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

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

Коротка версія

DevOps поєднує організаційну культуру, Agile / Lean способи роботи та автоматизацію програмного забезпечення, що при застосуванні до системного адміністрування та операцій дозволяє цим функціям працювати з тим же рівнем спритності, як і Agile або Lean Development Teams.

Довга версія

Ідеї ​​DevOps з'явилися у спільнотах системного адміністрування, операцій та Agile, зокрема Патрік Дебой виступив з доповіддю на Agile2008 під назвою "Agile Infrastructure", де підкреслив розбіжність між способом функціонування трьох функцій в організації:

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

Пропозиція Дебуа полягала в об'єднанні трьох способів спільної роботи, зокрема, переміщення команд системного управління та операційних команд від моделі водоспаду до зручної моделі. З цією метою Debois налаштував DevOpsDays 2009 у Генті, Бельгія, ненароком увівши словосполучення DevOps .

Ідея DevOps перегукувалася з авторами серії книг VisibleOps: Джин Кім, Джордж Спаффорд та Кевін Бер; який продовжував писати проект Phoenix та довідник DevOps . Обидві книги досліджують, як Agile та Lean можуть позитивно впливати на команди адміністрування систем та операцій.

Будучи інженером DevOps, що виходить з фону Operations, ви перейдете від створення та розгортання серверів та програмного забезпечення вручну до створення сценаріїв встановлення програмного забезпечення на ваших серверах, як BASH, PowerShell, Python тощо. Через деякий час ви зрозумієте, як крутим сценарієм є і почніть вивчати більш складні способи автоматизації розгортання .

Врешті-решт, ви б оселилися на шеф-кухарі, ляльці, Ansible чи іншому інструменті управління конфігурацією , щоб допомогти керувати станом вашого парку систем. По мірі дозрівання ваших навичок автоматизації розгортання додатків та управління системою, разом з вашими інструментами, ви нещодавно перейшли до царини « Інфраструктура як код » і використовуєте її не тільки для автоматизації розгортання програмного забезпечення, але й необхідної інфраструктури та середовища. керувати програмним забезпеченням під час переходу бізнесу на хмару.

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

Коли ви перейшли в команду DevOps, ви піддалися життєвому циклу розробки програмного забезпечення та концепції постійної інтеграції . Хлопчик, ці розробники швидко випускали зміни, і щоб не відставати, ви виявили, що ви більше працюєте з розробниками! Ви відчули настійність команди розробки змінити ВСЕ-ВРЕМЕ, що суперечить старій оперативній парадигмі " якщо вона не зламається, не виправляйте ". Більше не вихваляючись системою часу роботи, ви перебуваєте в одноразовій інфраструктурі.

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

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

По мірі того, як новий код пробивається через етапи CICD, ви, розробники та бізнес отримуєте впевненість, що оновлення не вийде з ладу після виходу у виробництво. Існує певний шлях до того, як команда дістанеться до " постійного розгортання ", вам все-таки потрібно зупинитися на точних питаннях автоматизації синьо / зелених можливостей розгортання, і рішення здебільшого ділове. Наразі ви задоволені тим, що кількість дзвінків о 3 годині ночі зменшилася, а sev-1 та sev-2 зменшилися.

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

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

Sysadmin vs. DevOps (особистий погляд)

Деякі компанії говорять про Dev, Ops та Test. Якщо щось потрібно перевірити, вони кажуть: "Тест повинен це зробити". Якщо щось потрібно розробити, Dev зробить це, і якщо програмне забезпечення потрібно буде розгорнути, Ops зробить це.

На мою думку, і те, що я пережив у кількох компаніях, це те, що це спричиняє менталітет «кинути його через стіну», що призводить до тертя між людьми та командами. Особисто я інколи відчуваю, що люди працюють індивідуально і кажуть, що це я зробив, мені нічого робити, а не працювати як команда.

По-моєму, DevOps означає, що всі в команді відповідальні та зайняті розробкою, тестуванням та операціями. У команді немає і немає окремих відділів. Усі повинні звільнитись. Звичайно, є спеціальності, але, на мою думку, кожен повинен мати можливість зробити щонайменше 25% якоїсь роботи у кожній галузі. Наприклад, якщо хтось був розробником ще в той день, тоді слід мати можливість змінити якийсь код управління конфігурацією, наприклад, шеф-кухар та розгорнути програмне забезпечення.

Список літератури

Сисадмін

За даними Вікіпедії :

Системний адміністратор або sysadmin - це людина, відповідальна за обслуговування, конфігурацію та надійну роботу комп'ютерних систем; особливо багатокористувацькі комп'ютери, такі як сервери.

Системний адміністратор прагне забезпечити, щоб час роботи, продуктивність, ресурси та безпека комп'ютерів, якими він керує, відповідали потребам користувачів, не перевищуючи бюджет.

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

DevOps

За даними Вікіпедії :

DevOps (відрізана сполука "розробка" та "операції") - це процес розробки та доставки програмного забезпечення, який наголошує на спілкуванні та співпраці між керівництвом продуктом, розробкою програмного забезпечення та фахівцями з операцій. Він підтримує це шляхом автоматизації та моніторингу процесів інтеграції програм, тестування, розгортання та зміни інфраструктури шляхом створення культури та середовища, де побудова, тестування та випуск програмного забезпечення може відбуватися швидко, часто та надійніше.

DevOps

DevOps Toolchain

Системний адміністратор несе відповідальність за підтримку та налаштування серверів, і їх відповідальність полягає в тому, щоб забезпечити користувачеві продуктивність, час роботи та безпеку, яку він шукає. Визначити роль інженера DevOps трохи складніше, оскільки офіційного шляху кар'єри немає, а сам DevOps може мати багато форм.

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

Багато людей навіть заперечують, що цей перехід від системного адміністратора до інженера DevOps є важливим, оскільки позиція системного адміністратора в майбутньому застаріла. Навіть незважаючи на те, що існує багато застарілих серверів, які потребують технічного обслуговування, а системні адміністратори мають багато "племінних знань", позиція sysadmin стане в майбутньому дефіцитнішою.

Там будуть сервери, які ви не чуєте, як працює в центрах обробки даних. Все буде програмним забезпеченням. Зберігання, мережа, системи, безпека, центри обробки даних; SDN, брандмауері, NFV, сховище, сервери тощо. Системи управління без програмного забезпечення, досвід SDLC (я навіть не маю на увазі сценарії Perl, Powershell тощо), ймовірно, зникнуть. Розподілене, масштабоване та віртуалізоване середовище, яке переважно є хмарним, зростає горизонтально, а не вертикально.

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

Оскільки операційна / системна команда просто виконує те, що будує команда програмного забезпечення.

• Sysadmins не створює / компілює Linux / FreeBSD / ядро ​​Windows тощо, як і інженери програмного забезпечення будують / компілюють програми.
• Sysadmins не проходить життєвий цикл розробки програмного забезпечення (SDLC).
• Сисадміни не входять у виробничий конвеєр (процес CI / CD).

• Sysadmin починає працювати після закінчення CI / Постійної доставки / розгортання.

  І якщо ви порушите та призначите розгортання / доставку, це може бути зламаний конвеєр,
  команда програмного забезпечення - це система розробників / операційна команда - це переважно бігуни / доглядачі.

Це здається, що немає сервера / системи для адміністрування, і немає ніякої потреби в системі.

Обчислення без сервера - це модель виконання хмарних обчислень, в якій хмарний постачальник функціонує як сервер, динамічно керуючи розподілом машинних ресурсів. Ціноутворення базується на фактичній кількості ресурсів, що споживаються додатком, а не на попередньо придбаних одиницях потужності обчислень без сервера.

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

Цікаво, чому його називають DevOps, але не OpsDev? це пов’язано з напрямком між ними?

* У середині нізвідки я не почав писати про визначене програмним зберіганням, це є реакцією на видалений коментар про це *

Про певне програмне забезпечення

• Забезпечене програмним забезпеченням зберігання даних (SDS) - це маркетинговий термін для програмного забезпечення для зберігання даних на комп'ютері для надання на основі політики забезпечення та управління зберіганням даних незалежно від базового обладнання. Програмно-визначене зберігання

• EMC оголосила про свій перший в історії продукт із відкритим кодом: Project CoprHD. CoprHD - це контролер автоматизації та управління програмним забезпеченням, визначений програмним забезпеченням, і нещодавнє рішення EMC про відкриття вихідного коду є основою нашої стратегії надання більшої цінності світовому бізнесу, коли ми входимо в область зростання та екстремальних змін. Будучи світовим лідером у галузі управління сховищами та інформацією, компанія EMC зобов'язує лідирувати на шляху до програмного забезпечення з визначеним зберіганням даних (SDS) .

• CoprHD - це програмний контролер зберігання даних та платформа API з відкритим кодом. Це дозволяє керувати політикою на основі політики та хмарною автоматизацією ресурсів зберігання для постачальників даних CoprHD для блоку, об'єктів та файлів