Блог Southbridge

Сисадмин, DevOps, SRE — в чём разница?

2021-05-10 12:21
Профессии «девопс» не существует, а приличных инженеров эксплуатации не стоит называть «сисадминами» — сталкивались ли вы с подобными утверждениями? Они звучат регулярно. При этом на сайтах с вакансиями открыты сотни объявлений о поиске DevOps и сисадминов — судя по требованиям, вполне приличных. Более того, иногда содержание этих вакансий совпадает настолько, что в заголовке пишут: «ищем системного администратора (DevOps)», ставя между ними знак равенства.

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

В этой статье постараемся зафиксировать ожидания работодателей. Предмет интереса — специальности системный администратор, DevOps-инженер, SRE.

Системный администратор

По запросу «системный администратор» HeadHunter выдаёт более 5 тыс. вакансий. Все объявления разные, но по некоторым общим чертам их можно разбить на три группы. Стоит предупредить, что разбиение ниже основано на анализе не всех 5 тыс., а примерно 50 вакансий, поэтому вряд ли отражает действительность с максимальной точностью. Делайте скидку.

Level 1: поддержка офисной техники
Зарплата: 250 — 600 USD

Таких сотрудников ещё называют «эникейщиками» — мастерами на все руки (или на все кнопки — any key). Но среди вакансий определение системный администратор распространено больше. Иногда встречается с приставкой «младший».

Обязанности:
  • настройка рабочих мест сотрудников,
  • установка ПО и управление лицензиями,
  • управление доступом, учётными записями и правами,
  • поддержка периферийного оборудования (МФУ, принтеры, гарнитуры, микрофоны, проекторы, WiFi-оборудование),
  • обслуживание и мелкий ремонт компьютерной техники,
  • иногда: управление закупками офисной техники.

Эникейщиков или младших системных администраторов ищут самые разные организации, от небольших фирм на 10-15 человек до средних компаний со штатом в 100-150 сотрудников. В первом случае сисадмин будет отвечать за технику один, во втором — в команде с более опытными администраторами.

Level 2: поддержка собственной инфраструктуры компании
Зарплата: 450 — 950  USD

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

Ниже собраны обязанности системного администратора, которые встречаются в вакансиях чаще всего. Нельзя сказать, что в каждой вакансии есть все перечисленные ниже пункты, но минимум половина — точно. Конкретный стек технологий тоже отличается от компании к компании.

В обязанности типичного системного администратора входят:
  1. Установка и настройка:
  2. серверов;
  3. сетевого оборудования (Cisco, HP и др.).
  4. Администрирование:
  5. операционных систем (на базе Windows или Linux);
  6. систем виртуализации (OpenVZ, Xen, Proxmox, Hyper-V, VMware, VirtualBox);
  7. баз данных (MySQL, PostgreSQL, Microsoft SQL);
  8. сетевых хранилищ;
  9. локальных сетей и VPN (PPTP, SSTP, OpenVPN);
  10. доменной сети (Active Directory, DNS, DHCP);
  11. веб-серверов (Nginx, Apache);
  12. электронной почты (Sendmail, Postfix, MS Exchange, Zimbra и др.);
  13. IP-телефонии (Asterisk);
  14. CMS;
  15. корпоративных IT-систем (1С, Bitrix24 и др.);
  16. ПО для командной разработки (GitLab, Jira, Confluence и др.).
  17. Мониторинг (Zabbix, Dude, Alerta, Prometheus, Grafana).
  18. Резервное копирование и архивирование данных.
  19. Безопасность.
  20. Автоматизация процессов обслуживания (на Bash, Python).
  21. Разработка технической документации и регламентов.

Таких сисадминов ищут самые разные компании, и набор обязанностей зависит от  размеров и задач. Например, если сисадмин нужен в хостинг-провайдер или интегратор, то к задачам добавляется общение с клиентами; если в организацию из отрасли торговли или производства, то настройка 1С, бухгалтерского и криптографического ПО; если в компанию-разработчика софта, то создание сред для разработки и поддержка этого ПО в продакшене.

Вот что говорят действующие инженеры об обязанностях системного администратора.



Классический сисадмин у бизнеса по

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

Василий, DevOps в Piano

Топ 5 обязанностей: выдача прав и доступов юзерам, ребут сервера (от всех бед), настройка ОС под требования какого-то ПО, монтирование дисков, настройка требований информационной безопасности. Топ 5 технологий: unix, bash, виртуализация, Ansible, опыт настройки какой-либо реляционной СУБД. 

Валентина, инженер в МТС



Level 3: создание инфраструктуры для SaaS, поддержка микросервисной архитектуры
Зарплата: 1200 — 2000 USD

Это тот самый уровень, на котором люди просят не называть себя сисадминами. Возможно, всё дело в уровне задач и ответственности: здесь от специалиста требуют обеспечения бесперебойности и доступности распределённой инфраструктуры. Иногда сами себя они называют «инженеры эксплуатации», «системный инженер», «инженер инфраструктуры». Но в вакансиях всё же гораздо чаще встречается старый добрый системный администратор.

К обязанностям из предыдущего уровня добавляется:
  • Работа с системами контейнеризации (Docker, Kubernetes);
  • Работа с брокером сообщений Apache Kafka;
  • Настройка систем мониторинга (Zabbix/Grafana), системы логирования ELK;
  • Работа с системами управления конфигурациями (Ansible).

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

И обычно именно на этом уровне задачи системных администраторов путают с задачами DevOps и SRE. Так что пора перейти к определению этих профессий.

DevOps-инженер

По запросу «DevOps инженер» HeadHunter тоже выдаёт около 3 тыс. вакансий. Подготовленный читатель скажет: «DevOps — это не специальность, DevOps — это философия, набор инструментов». Так и есть!

Что такое DevOps
DevOps — это набор практик для повышения эффективности процессов разработки (Development) и эксплуатации (Operation) софта.

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

Подробно о философии и практиках можно почитать в других статьях, их достаточно. Для целей нашей статьи достаточно понимать два ключевых момента. DevOps предполагает:
  • тесное взаимодействие разработчиков и отдела эксплуатации;
  • настройку и автоматизацию процессов непрерывной интеграции и непрерывной поставки кода (CI/CD).

Второй пункт часто невозможен без перехода на микросервисную архитектуру, как правило, она реализуется с помощью Docker и Kubernetes.

Чем занимается DevOps-инженер
DevOps не профессия, но это слово регулярно используют в значении «специалист, который внедряет практики DevOps». Если вы когда-нибудь открывали сайт с вакансиями, то понимаете, о чём речь. Но цель этой статьи не спор вокруг терминологии, а анализ содержания вакансий. К нему и перейдём.

Исходя из философии DevOps, внедрять его практики могут как разработчики, так и инженеры эксплуатации. Но судя по вакансиям, разработчиков в России на эту роль ищут редко, и требования к DevOps-инженеру во многом пересекаются с требованиями к системному администратору. Смотрите сами.

Требования, совпадающие с требованиям к системным администраторам:
  1. Знание и опыт администрирования:
  2. Linux;
  3. систем контейнеризации (Docker, Kubernetes);
  4. баз данных;
  5. LAMP;
  • Понимание принципов работы TCP/IP;
  • Опыт администрирования SQL и NoSQL баз данных;
  • Опыт настройки систем мониторинга и логирования (Zabbix, ELK, Grafana, Prometheus);
  • Опыт конфигурирования инфраструктуры через код (Ansible);
  • Умение писать скрипты на Bash, Python или Ruby (иногда упоминается Perl);
  • Опыт работы с облачными платформами.

Требования, которые не встречаются в вакансиях системных администраторов, но типичны для вакансий DevOps-инженеров. 
  • Понимание философии DevOps;
  • Понимание и следование подходу «инфраструктура как код»;
  • Понимание жизненного цикла разработки ПО и принципов CI/CD;
  • Тесное взаимодействие с командой разработки.

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

При этом некоторые вакансии DevOps-инженера действительно похожи на вакансии системного администратора. Иногда в объявлении совсем не упоминается настройка CI/CD, а есть только требование построить и поддерживать кластер на Kubernetes. Но чёткой градации между вакансиями нет, разделить их на группы нельзя. 


Ключевой момент, который отличает DevOps-инженера от системного администратора, — это навыки автоматизации и сокращение ручного труда (особенно касается построения CI/CD), понимание процессов со стороны разработки. DevOps должен знать  Linux, Git + CI/CD, Ansible, Docker + Kubernetes, Automation and Scripting (обязательно).

Сергей, СТO в Southbridge

Топ-5 обязанностей: настраивать CI/CD, автоматизировать и поддерживать инфраструктуру тестовых сред и прода, общаться с разработкой и понимать их код. Топ-5 технологий: Gitlab CI, Docker, K8s, Ansible, Python.

Валентина, инженер в МТС


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

Зарплата DevOps инженеров значительно больше, чем системных администраторов: от 1000 до 3500 USD и выше. 

SRE


Site Reliability Engineering (SRE) — это одна из форм реализации DevOps. SRE-подход возник в Google и стал популярен в среде продуктовых IT-компаний после выхода одноимённой книги в 2016 году. 

Цель инженера по SRE — сделать так, чтобы сервис работал с такой надёжностью, которая указана в соглашении о уровне оказания услуг (SLA). Стабильность работы зависит и от инфраструктуры, и от качества кода, поэтому SRE занимается и тем, и другим. Как правило, инженерами по SRE становятся опытные системные администраторы или разработчики. Разработчики даже чаще.

Для России специальность SRE относительно новая, поэтому вакансий немного. Но и немногочисленные открытые объявления показывают, что ожидания от SRE очень высоки. Этот специалист должен знать всё, что знает системный администратор уровня Senior, плюс уметь разрабатывать на одном из языков программирования, желательно не скриптовых.

Пример требований:
  • уверенные знания ОС Linux продвинутого уровня работы в консоли;
  • опыт разработки на C/C++ или Go;
  • понимание работы TCP/IP и HTTP;
  • понимание устройства ОС (процессы, память, синхронизация);
  • опыт настройки различных инструментов для мониторинга и конфигурирования серверов. Инструменты: Zabbix, Puppet, Ansible или подобные.
  • опыт работы с Docker;
  • опыт использования облачных сервисов Amazon: EC2, VPC, S3, Route53;
  • опыт настройки сетей. Инструменты: nginx, haproxy, bind, git, iptables, stunnel, openvpn;
  • опыт настройки виртуальных машин: kvm, xen.

Пример задач: 
  • Оптимизация имеющейся архитектуры и сервисов;
  • Уменьшение нагрузки на сопровождение и обслуживание сервисов за счет автоматизации;
  • Изучение имеющихся сервисов и поддержание актуальных знаний по ним;
  • Активный и проактивный поиск возможных проблем и их устранение;
  • Обеспечивать заданный уровень SLA & SLO;
  • Участвовать в инцидент-менеджменте;
  • Писать postmortem-ы и разрабатывать мероприятия для повышения стабильности сервисов;
  • Создавать, актуализировать DRP (Disaster Recovery Plan), BCP(Disaster Recovery Plan) и проводить регулярные учения по отказам с последующим анализом результатов;
  • Участвовать в проработке архитектуры сервисов и изменений их конфигураций;
  • Оптимизация имеющихся систем observability.


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

Марсель, CТO в Slurm

Я считаю, что в России это скорее хайп, у нас SRE и DevOps-инженер часто имеют одни и те же обязанности. На мой взгляд, SRE — это DevOps с бэкграундом разработки. Тут имеется в виду, что такой инженер может не просто написать скрипт на Go, а разобраться в коде и даже подсказать разработчикам, что с инфраструктурной точки зрения работает плохо и что надо улучшить.

Сергей, СТO в Southbridge


Инженеры по SRE нужны ещё в меньшем количестве компаний, чем DevOps-инженеры, и это организации уровня Яндекса, Mail.ru, Wargaming, Сбербанка и подобных компаний.

Зарплаты SRE часто вообще не указывают, а если указывают, то фигурируют цифры 2000, 2500, 4000 USD.

Так в чём разница между профессиями сисадмина, DevOps и SRE? Максимально коротко

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

Сисадмин настраивает инфраструктуру и заботится о том, насколько стабильно она работает. Если разработчики написали код, который всё сломал, это не его забота.

DevOps-инженер заботится о скорости и качестве поставки кода. Он помогает разработчикам настроить процессы так, чтобы новые фичи выходили быстро и ничего не ломали. Если новый код всё сломал, то это и его ответственность тоже.

SRE думает о выполнении SLA. Он тоже работает с инфраструктурой, но занимается не базовой настройкой, а тонкой — ищет возможности для оптимизации и точки отказа, улучшает архитектуру. Его не заботит скорость поставки кода, его заботит надёжность. Если код потенциально может сломать продакшен, то SRE его не пропустит. 


Когда что-то случается, админ смотрит и говорит: «виноват приклад», то есть ПО, которое пишет команда разработки. На этом работа админа над проблемой заканчивается, а работа DevOps-инженера только начинается. В компаниях, где нет собственной разработки, DevOps-инженеров не бывает, а админы обычно есть.

У админа есть готовое ПО, на которое он не может влиять, если там что-то не так, а только костылить вокруг и углубляться в тонкие настройки, но зато у него есть много инструкций в интернете — installation guide и статьи от других админов, которые уже ставили это же ПО и набили шишки. Пример: админ читает в инструкции, что оптимальнее запускать ПО, например, c файловой системой xfs. 

У DevOps-инженера изначально ПО забаговано и не работает оптимально, и именно его задача довести это ПО до приличного уровня и описать те самые installation guide. Пример: DevOps-инженер должен определить, с какой файловой системой приложение работает лучше всего и максимально увеличить эти показатели. Для улучшений он может влиять на разработку и архитектуру ПО, если что-то не достаточно хорошо или не работает. 

Валентина, инженер в МТС

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

DevOps — это про дружбу разработки и админов (опсов), а SRE — это пожарник, который тушит прод после веселья первых двух. 

Василий, DevOps в Piano




DevOps