Сисадмин или DevOps: чем на самом деле отличаются задачи, инструменты, ответственность и дежурства
Команда KAI Lab · · 8 мин чтения
Сисадмин отвечает за то, чтобы инфраструктура работала сегодня: серверы, учётные записи, сеть, бэкапы. DevOps-инженер отвечает за то, как изменения доходят до продакшена и как прод их переживает: пайплайны, контейнеры, инфраструктура как код и надёжность релизов. Навыки у ролей сильно пересекаются, а главная разница — в способе работы: админ чаще настраивает и чинит руками, DevOps описывает систему кодом и автоматизирует всё, что повторяется.
Ниже — сравнение по задачам, инструментам, ответственности и дежурствам, реальные смешанные вакансии и вопросы, которые помогут выбрать. Если вы уже решили переходить, план — в статье из сисадмина в DevOps.
Сравнение в одной таблице
| Системный администратор | DevOps-инженер | |
|---|---|---|
| Главный вопрос | Работает ли инфраструктура прямо сейчас | Как изменения быстро и безопасно доходят до прода |
| Для кого работает | Сотрудники компании и внутренние сервисы | Разработчики и пользователи продукта |
| Типичные задачи | Серверы, учётные записи, почта, сеть, бэкапы, рабочие места | Пайплайны, контейнеры, Kubernetes, инфраструктура как код, мониторинг сервисов |
| Инструменты | Windows Server и Active Directory, Linux, виртуализация, Zabbix, скрипты | Git, GitLab CI или GitHub Actions, Docker, Kubernetes, Terraform, Ansible, Prometheus |
| Как вносит изменения | Чаще руками: консоль, RDP, веб-интерфейс | Через код: коммит, merge request, ревью, пайплайн |
| Чем меряют работу | Доступность систем, закрытые заявки, сроки по SLA | Частота выкладок, время от коммита до прода, доля неудачных выкладок, время восстановления |
| Дежурства | Часто «по звонку», без формального графика | Обычно график on-call с алертами, эскалацией и постмортемами |
| Связь с разработкой | Эпизодическая | Ежедневная |
| Вакансий на hh.kz по названию, 25.09.2026 | 101 | 35 |
Это типичная картина, а не закон. В маленькой компании админ может выкатывать релизы, а DevOps — разбираться с принтером. Но направление работы таблица передаёт точно.
Один и тот же сбой глазами двух ролей
Разница в способе лучше всего видна на обычной аварии: на сервере кончилось место, сервис встал.
Сисадмин заходит на сервер, находит разросшийся лог, чистит его, настраивает ротацию и ставит порог в мониторинге. Сервер починен.
DevOps-инженер делает то же самое, а потом чинит класс проблем. Ротация логов уходит в Ansible-роль и приезжает на все серверы. Алерт срабатывает на скорость заполнения диска, а не на 95%. У контейнеров появляются лимиты логов, а после сбоя пишется короткий постмортем с задачами, чтобы история не повторилась. Как искать причину в таких случаях, разобрано в статье закончилось место на диске в Linux.
Второй пример — «нужен новый сервис». Админ создаёт виртуальную машину, ставит пакеты и настраивает её по инструкции. DevOps описывает машину в Terraform, настройку — в Ansible или в образе, выкатку — в пайплайне, а мониторинг включается сам. Через полгода первый вариант помнит только автор, второй читается из репозитория.
Ответственность
Сисадмин отвечает за доступность внутренних систем, сохранность данных, учётные записи и безопасность рабочих мест. Его результат — ничего не сломалось и заявки закрыты вовремя.
DevOps-инженер отвечает за путь кода до прода и за платформу, на которой продукт работает. Результат здесь чаще меряют метриками DORA: время от коммита до выкладки в прод, частота выкладок, доля выкладок, после которых понадобилось срочное вмешательство, и время восстановления после неудачной выкладки. Хороший DevOps выкатывает чаще и при этом ломает реже — не за счёт осторожности, а за счёт автоматических проверок и быстрого отката.
Дежурства
Дежурят обе роли, но по-разному. У админа это часто звонок в любое время без графика и замены. В DevOps обычно есть формальный on-call: ротация, алерты, эскалация, runbook и разбор после каждого серьёзного инцидента. Как это устроено, разбираем в статьях что такое on-call и первое дежурство DevOps.
Полезный ориентир — книга Google о SRE. Там дежурствам отводят не больше 25% времени инженера, а инженерным проектам — не меньше 50%. Нагрузка считается нормальной, если за 12-часовую смену случается не больше двух инцидентов. Это практика одной компании, а не норма рынка, но хороший вопрос на собеседовании: сколько инцидентов бывает за смену и сколько людей в ротации?
Следующий уровень той же логики — договорённость о том, какая надёжность вообще нужна сервису: SLO, SLI и бюджет ошибок. В классическом администрировании таких договорённостей обычно нет: сервис должен работать всегда, а цена этого «всегда» не обсуждается.
Рутина, которую надо убивать
В книге Google SRE есть слово для большей части админской рутины — toil. Это ручная, повторяющаяся работа, которую можно автоматизировать, которая не оставляет долговременной пользы и растёт вместе с сервисом. Создать учётку по заявке, поправить конфиг на десяти серверах по очереди, перезапустить зависший процесс — всё это toil.
Сисадмину рутина часто и есть работа. Для DevOps и SRE это враг: её держат под контролем и тратят время на то, что сокращает её в будущем. Если вы в пятый раз делаете одно и то же руками и уже пишете для этого скрипт, вы думаете как DevOps.
Можно ли совмещать
Можно, и в Казахстане такие вакансии есть. 25 сентября 2026 года на hh.kz по Казахстану было три вакансии со «системным администратором» и DevOps в названии, все с опытом 3–6 лет. Как выглядит смесь на практике:
- Астана, вакансия от 4 сентября 2026. Настройка Linux-серверов с нуля, Docker и Docker Compose, Nginx как reverse proxy, автоматический выпуск сертификатов Let's Encrypt, скрипты ежедневных бэкапов баз, мониторинг и реакция на инциденты.
- Алматы, вакансия от 6 сентября 2026. Кластеры Kubernetes на RKE2, K3s и Rancher, CI/CD в GitLab, отказоустойчивый PostgreSQL на Patroni и HAProxy, хранилище MinIO и автоматизация конфигураций смешанного парка на Linux и Windows Server.
Первая вакансия ближе к админству с контейнерами, вторая — почти чистый DevOps с админской базой. Для сисадмина со стажем такие роли — самый естественный мост.
Главный риск совмещения — рутина съедает время на автоматизацию. Помогает простое правило: заранее бронировать часы в неделе под задачи, которые уменьшают ручную работу, и считать, сколько её стало меньше.
Как выбрать
Ответьте себе на четыре вопроса.
- Что вам важнее: чтобы всё стабильно работало для людей рядом или чтобы продукт менялся быстро и безопасно?
- Готовы ли вы каждый день работать с кодом и разработчиками: читать их пайплайны, спорить о релизах, ревьюить изменения?
- Как вы относитесь к формальным дежурствам с графиком, алертами и разбором каждого инцидента?
- Что есть в вашей компании: своя разработка и релизы или в основном офисная инфраструктура?
Если на большинство вопросов ответ тянет к коду и релизам, смотрите в сторону DevOps. Если нет — у сисадмина тоже есть куда расти: в сети, SOC или SRE. Карта всех вариантов — в статье куда расти сисадмину и helpdesk.
Понять, нравится ли вам ритм DevOps, можно и до смены работы. В симуляторе DevOps KAI Lab вы год работаете DevOps-инженером в выдуманной компании: тикеты от коллег, дежурства, постмортемы. Бесплатно доступны тест навыков и первые задания.
А что с деньгами
Честно: сравнимых открытых данных по зарплатам сисадминов и DevOps в Казахстане мы не нашли. В исследовании Kolesa Group за 2025 год DevOps есть среди специализаций, а системных администраторов нет. Поэтому цифр здесь нет. Сравнивайте сами — по вакансиям с указанной вилкой в своём городе и для своего опыта.
Частые вопросы
DevOps — это просто сисадмин с новым названием? Нет. Навыки пересекаются — Linux, сети, инциденты, — но объект работы другой: не отдельные серверы, а путь изменений до прода. И способ другой: вместо ручной настройки — код, ревью и пайплайн.
Кто больше дежурит — сисадмин или DevOps? Зависит от компании. У DevOps дежурства чаще формальные, с графиком и алертами, у админа — чаще неформальные, «когда позвонят». На собеседовании спрашивайте, сколько человек в ротации и сколько инцидентов бывает за смену.
Где больше вакансий в Казахстане? По срезу hh.kz на 25.09.2026 по названию вакансии: «системный администратор» — 101, DevOps — 35. При этом 21 вакансия DevOps из 35 требует опыт от трёх лет, поэтому сисадмины переходят чаще через смешанные роли.
Можно ли вернуться из DevOps в администрирование? Можно, и это несложно: навыки переносятся. Админ, который умеет описывать инфраструктуру кодом и строить мониторинг, сильнее админа, который этого не умеет.
Нужно ли DevOps-инженеру знать Windows и Active Directory? Обычно нет, но в компаниях со смешанным парком — да. В алматинской вакансии выше рядом с Kubernetes прямо требуется базовое администрирование Windows.
Источники
- hh.kz — поиск по названию вакансии, весь Казахстан, 25.09.2026: системный администратор — 101, DevOps — 35 (из них опыт от трёх лет — 21), системный администратор DevOps — 3.
- hh.kz. Системный администратор Linux / DevOps-инженер, KOVENANTA, Астана, 04.09.2026; DevOps-инженер / Системный администратор, АО «Евразия», страховая компания, Алматы, 06.09.2026.
- Google. Site Reliability Engineering: Eliminating Toil, Being On-Call.
- DORA. Метрики доставки программного обеспечения — определения метрик.
- Kolesa Group. Сколько зарабатывают разработчики и QA-инженеры. Исследование Kolesa Group за 2025 год, 04.03.2026.