С подключением, хабровчане! Меня зовут Роман Волков, я Senior DevOps в MТС Web Services. Кроме своей основной деятельности в роли инженера, я провожу собеседования и всегда задаю вопросы кандидатам о том, как они видят пользу, которую их роль приносит бизнесу, как могут оценить свою деятельность, какой у них метод ведения работы. Как многие, я читаю профильные чаты, тематические ресурсы. И... кажется, в ИТ‑сообществе до сих пор бытует мнение, что DevOps и SRE — это следующие этапы развития системного администратора.
Это наблюдение подтверждают и открытые вакансии: практически каждая дает список используемых технологий и бонусов для будущего кандидата, но не раскрывает специфику работы. Если бизнес не транслирует пользу от вакансии — сотрудники подбираются исходя из используемой технологии. А ведь есть разница в том, чтобы, например, администрировать Kubernetes, разворачивать полезную нагрузку в Kubernetes или обеспечивать высокую доступность приложению, развернутому в Kubernetes.
Ситуацию можно сравнить с подбором стоматолога по навыку работы специалиста с бормашиной. В такой клинике у вас высокий шанс попасть как к ювелиру, так и к мастеру маникюра.
Попробую внести ясность!
Дисклеймер
Все нижесказанное — мои наблюдения и собирательный опыт. Они не отражают положение дел в MWS или другой реальной компании.
Кто есть кто?
Системный администратор
В нашем сообществе сисадмины почему-то воспринимаются как «а, это те самые, которые принтер чинят?». Или как суровые мужики из ЦОД-ов, занимающиеся чем-то магическим вокруг серверных стоек.
Но в реальности они не про ЦОД, принтер, SIP-телефонию и даже не про сети — это разные роли с разным уклоном теоретической подготовки.
Как сравнить?
��истемные администраторы отвечают за:
установку, настройку, обновление корневой инфраструктуры (ПО);
поддержку, мониторинг инфраструктурных приложений;
проектирование, развитие, внедрение программных компонентов ИТ-инфраструктуры.
В зависимости от квалификации фокус смещается.
Если совсем просто:
Админы — это те самые люди, которые строят и поддерживают инженерную базу для всех остальных.
В чем польза для бизнеса:
Оптимальное расходование вычислительных мощностей = сэкономленные деньги.
Актуальный инфраструктурный стек снижает риски по безопасности и повышает конкурентоспособность.
Метрики оценки:
SLA — соглашение об уровне обслуживания с обязательным пунктом об актуальности программного обеспечения;
SLO — соглашение о рамках SLA с клиентом, то есть пользователями сервисов и инфраструктуры;
SLI — фактический показатель качества и надежности сервиса с точки зрения пользователя.
Если метрики показались вам знакомыми...
Так оно и есть :) Но админам нужны четыре девятки, только если ваши сотрудники работают 24 часа.
DevOps
Специально для зануд: DevOps — это методология, а DevOps-инженер — это тот, кто ее внедряет и использует.
Джин Ким, автор «Проекта Феникс», давал такое определение:
«DevOps — это набор культурных норм и технологических практик, которые обеспечивают быстрый поток запланированной работы, в том числе от разработки, через тестирование к эксплуатации, сохраняя при этом надежность, работу и безопасность мирового уровня».
Что это за уровень, можно оценить по отчетам DORA и express42 — смотря на кого хотите ориентироваться.
Немного об отчетах:
Выше я говорил, что в вакансиях делается излишний упор на инструменты. Косвенно об этом искажении восприятия говорят и отчеты: RussianDevOpsReport (будут ли свежие?) и отчет от express42 — здесь куда бо��ьший акцент на инструментах, чем в DORA. Учитывая свою предвзятость в вопросе, я взял похожие по структуре отчеты express42 и DORA и сравнил их с помощью нейросети. Результат подтвердил перевес первого в пользу инструментов примерно на 10%.
Повторить сравнение можно так:
— Берём устройство с MacOs.
— Качаем textra.
— Качаем отчеты (ссылки выше).
— Запускаем:
~/.textra/bin/textra ~/Downloads/DORA.pdf -o eu_report.txt
~/.textra/bin/textra ~/Downloads/express42.pdf -o ru_report.txt
— Открываем нейросеть:
У меня есть отчет о DevOps. Хочу понять, чему больше уделяется внимание инструментам или методологии. Для оценки не используй количество страниц и оглавление, таблицы сравнения. Только то, о чем написано.
Не пиши ничего лишнего, только соотношение в процентах.
Текст:
``{Вставьте содержимое полученного выше файла}``
Обновляем страницу, повторяем несколько раз для каждого. Балуемся, пока не надоест :)
Коротко можно объяснить так:
Зона ответственности DevOps-инженера — это автоматизация производственной цепочки.
Что тут с финансовым эффектом:
быстрая разработка = сэкономленные деньги;
актуальный бэклог и быстрая обратная связь потребителя = выше конкурентоспособность.
Метрики оценки (да-да, DORA-метрики):
DF (Deployment frequency) — как часто готовы релизить;
MLT (Mean lead time for changes) — время, затраченное на релиз;
CFR (Change failure rate) — процент релизов, которые привели к проблемам;
MTTR (Mean time to recovery) — сколько времени нужно, чтобы восстановиться после ошибки в релизе.
Перевод может отличаться в зависимости от источника. Как правило, я объясняю эти метрики именно так.
DevOps-инженера характеризует желание автоматизировать производственную цепочку.
SRE
SRE (Site Reliability Engineering) — это о проде и особенностях эксплуатации в нем. Например, предугадывание инцидентов, улучшение релизного процесса, обучение на каждом инциденте (ретроспектива), мониторинг удовлетворенности клиентов. Эти инженеры обеспечивают надежность релизов и делают их безболезненными.
Простыми словами:
Зона ответственности SRE — это максимизация доступности производственных сред.
Финансовый эффект:
меньше инцидентов, выше доступность = больше денег;
больше удовлетворенных клиентов = выше конкурентоспособность.
Метрики оценки (да, вы видели это выше):
SLA — соглашение об уровне обслуживания;
SLO — соглашение о рамках SLA с клиентом, то есть пользователями сервисов и инфраструктуры;
SLI — фактический показатель качества и надежности сервиса с точки зрения пользователя.
SRE характеризует именно желание работать «на передке» — в продуктивном окружении. А еще — сочетание быстроты принимаемых решений с высокой скоростью действий.
Делаем выводы ✍️
На мой взгляд, сотрудники выгорают, когда не видят смысла в своей работе. Чтобы этот сценарий не повторялся, в одной точке должны сойтись ожидание от занимаемой должности и мотивация за полученную пользу со стороны бизнеса.
Если желания не сходятся с мотивацией, сотруднику кажется, что развиваться незачем: бизнес не оценит старания, а значит, силы будут потрачены впустую. Если ожидания не оправдываются, сотрудник пытается найти «место по душе».
Со стороны бизнеса это выглядит как субпассионарность специалистов и текучка кадров.
Может ли DevOps поднять для себя условный kubernetes? Может. Как и разработчик — 1С. Ждать продакшн-уровня от таких развертываний не стоит, как и ответственности за актуальность и сохра��ность такого кластера. Лучше уж пойти к поставщикам «Готовых облачных решений» или «Партнерам Kubernetes», как того и рекомендует документация. Это справедливо и для хранилищ кода, и для хранилищ контейнеров и артефактов. Безусловно, непрофильному специалисту это по плечу, но на выходе у нас проблема погони за двумя зайцами.
В идеальном мире системные администраторы, DevOps-инженеры и SRE образуют своего рода лестницу, где труд одних специалистов становится основой для остальных. Коллеги по профилю объединяются в гильдии, центры практик и сообщества, где делятся опытом. А дальше, из обмена лучшими практиками, формируют основу для IDP — платформы одного окна для разработчиков и друг друга. Для этого есть методология Platform Engineering, но это уже совсем другая история.
Да, все три роли часто используют одни и те же инструменты. Но как бормашина не делает ювелира стоматологом, так и навык конфигурации Nginx или работа с Ansible не превращает DevOps-ов в SRE или кого-то еще.
Специалиста определяют не используемые инструменты, а потребность для бизнеса, которую он закрывает своими компетенциями. Нужна инфраструктура — системный администратор. Оптимизация производственной цепочки — DevOps. Промышленная эксплуатация — SRE. В противном случае мы получаем рынок, где бизнес ищет специалистов 3 в 1, но получает выгоревших сотрудников и текучку кадров. А в инфраструктуре и бизнес-процессах, бесконечно догоняющих лучшие отраслевые практики, инженерам придётся делать все за всех — не ожидая качественного сервиса от коллег смежных профессий.
Хочется верить, что более формализованное разделение труда окажет положительное влияние на наше сообщество и лучшие практики станут формироваться именно в отечественном ИТ.
Что думаете?
