Разработка
Разработчик
Пять уровней от Junior до Principal и шесть компетенций — от разработки и выпуска до развития команды.
- 5 уровней
- 6 компетенций
Шаблон карьерной лестницы
Грейды DevOps-инженера: шаблон карьерной лестницы
Четыре уровня от Junior до Staff DevOps-инженера и шесть компетенций — от инфраструктуры до помощи разработчикам.
Бесплатный тариф · Банковская карта не нужна
Эта карьерная лестница написана для DevOps-, платформенных и инфраструктурных инженеров в компаниях примерно на 20–200 человек. При таком размере инфраструктурная команда обычно состоит из одного–шести человек: они отвечают за облачные аккаунты, пайплайны сборки и выпуска, мониторинг и дежурства и тратят на помощь разработчикам не меньше времени, чем на серверы. В ней четыре уровня — от человека, который вносит небольшие изменения в инфраструктуру, до того, кто определяет направление развития платформы компании. Верхний уровень, Staff DevOps-инженер, — экспертный: руководство инфраструктурной командой — отдельная работа.
Каждый уровень описан через то, что человек делает и какую часть системы ему доверяют, а не через стаж или длину списка инструментов в резюме. Читайте строку матрицы компетенций слева направо, чтобы увидеть, как растёт одно ожидание, или раздел уровня — чтобы увидеть всё, что ожидается на нём. С её помощью удобно объяснять, что значит следующий уровень, проводить чек-ины и принимать решения о повышении, которые можно обосновать.
Адаптируйте её перед публикацией. Замените общие формулировки своим стеком и практиками и уберите то, что относится к другой команде, — например, если безопасностью или базами данных занимается кто-то ещё.
Уровни коротко
Junior DevOps-инженер
Вносит небольшие изменения в инфраструктуру и пайплайны через ревью и разбирается, как устроен продакшен.
- Масштаб
- Отдельные изменения в существующем инфраструктурном коде и пайплайнах, которые планирует и проверяет кто-то опытнее.
Middle DevOps-инженер
Полностью отвечает за части инфраструктуры и наравне с остальными участвует в дежурствах.
- Масштаб
- Сервисы, окружения или пайплайны одной–двух продуктовых команд — от проектирования до повседневной эксплуатации.
Senior DevOps-инженер
Проектирует и ведёт инфраструктурные проекты, от которых зависят несколько команд, и поднимает планку надёжности.
- Масштаб
- Общая инфраструктура, которой пользуется большая часть разработки, и проекты вроде миграций, затрагивающие все команды.
Staff DevOps-инженер
Задаёт направление развития платформы компании и отвечает за её надёжность, безопасность и стоимость.
- Масштаб
- Вся продакшен-платформа, её развитие на несколько лет вперёд и её бюджет — для всех команд разработки.
Матрица компетенций
Строки — компетенции, столбцы — уровни. Читайте строку слева направо, чтобы увидеть, как растёт ожидание.
Что означает каждая компетенция
- Инфраструктура как код
- Создавать и менять инфраструктуру через проверенный, воспроизводимый код, а не вручную.
- Сборка и пайплайны выпуска
- Доставлять код от смёрженного пул-реквеста до продакшена быстро и безопасно.
- Надёжность и реагирование на инциденты
- Поддерживать доступность продакшена и быстро восстанавливать его, когда что-то ломается.
- Мониторинг и наблюдаемость
- Давать возможность видеть, что происходит в продакшене, и узнавать, когда что-то идёт не так.
- Безопасность и доступы
- Защищать системы и данные через безопасные настройки по умолчанию, минимальные права и быстрые обновления.
- Помощь разработчикам и взаимодействие
- Помогать разработчикам самим эксплуатировать свои сервисы и делиться знаниями, чтобы платформа не зависела от одного человека.
| Компетенция | Junior DevOps-инженер | Middle DevOps-инженер | Senior DevOps-инженер | Staff DevOps-инженер |
|---|---|---|---|---|
| Инфраструктура как код | Меняет существующий инфраструктурный код по уже принятым образцам, проверяет план изменений перед применением и никогда не правит продакшен вручную, не спросив сначала. | Пишет переиспользуемые инфраструктурные модули для новых сервисов и окружений, безопасно обращается со стейтом и секретами и удаляет ресурсы, которые больше не используются. | Проектирует структуру инфраструктурного кода и окружений компании, ведёт изменения вроде обновления сети или кластеров с проверенным планом отката и делает расходы на облако видимыми в разрезе команд. | Выбирает базовые компоненты и провайдеров платформы на несколько лет вперёд, задаёт стандарты, которым следует инфраструктура всех команд, и вместе с руководством отвечает за инфраструктурный бюджет. |
| Сборка и пайплайны выпуска | Чинит сломанные шаги пайплайнов и добавляет простые джобы в существующие пайплайны, а также объясняет разработчику, почему упала его сборка. | Строит и поддерживает полный пайплайн сервиса — сборку, тесты, артефакты, деплой во все окружения — и ускоряет медленные шаги, на которые жалуются разработчики. | Проектирует общие шаблоны пайплайнов для всех команд, внедряет более безопасные способы выпуска вроде canary- или blue-green-деплоя и отслеживает частоту деплоев и долю неудачных выкаток. | Определяет, как вся компания выпускает софт — от ветвления до отката, — и устраняет узкие места, которые замедляют выпуск во всех командах. |
| Надёжность и реагирование на инциденты | Дежурит в паре с опытным коллегой, действует по ранбукам для известных алертов и быстро эскалирует, передавая информацию, которая понадобится следующему. | Дежурит наравне с остальными, сам разбирается с большинством инцидентов в своей зоне, пишет ранбуки по тому, что починил, и проверяет бэкапы, реально восстанавливаясь из них. | Руководит реагированием на крупные инциденты, проводит постмортемы без поиска виноватых и доводит итоговые задачи до конца, планирует мощности и отказоустойчивость критичных систем. | Вместе с продуктом и руководством задаёт целевые показатели надёжности, выстраивает процесс дежурств и работы с инцидентами для всей разработки и готовит компанию к авариям вроде потери региона или провайдера. |
| Мониторинг и наблюдаемость | Добавляет дашборды и алерты по существующим примерам и, когда что-то выглядит странно, первым делом смотрит логи и метрики. | Настраивает логирование, метрики и алерты для новых сервисов, доводит алерты до состояния, когда каждое срабатывание требует действия, и помогает разработчикам находить нужное в данных. | Проектирует подход к наблюдаемости для основных систем компании, определяет сигналы здоровья сервисов, по которым оценивают команды, и снижает шум алертов во всех командах. | Выбирает инструменты наблюдаемости для компании и модель их стоимости и добивается, чтобы руководство видело состояние платформы, не спрашивая инженеров. |
| Безопасность и доступы | Соблюдает правила команды по секретам и доступам, ставит плановые обновления и сразу сообщает обо всём, что похоже на проблему безопасности. | Управляет доступами и секретами своих сервисов по принципу минимальных прав, закрывает уязвимости в порядке их критичности и исправляет находки сканеров безопасности. | Проектирует сетевые границы, управление идентификацией и секретами на всей платформе, готовит материалы для проверок безопасности со стороны клиентов и руководит реагированием на инциденты безопасности. | Вместе с руководством отвечает за уровень защищённости платформы, задаёт меры контроля, которых требует комплаенс (например, SOC 2 или ISO 27001), и делает безопасный путь самым простым для каждой команды. |
| Помощь разработчикам и взаимодействие | Отвечает на вопросы разработчиков об окружениях и пайплайнах, документирует сделанные исправления и рано просит ревью. | Пишет понятные инструкции для типовых задач, вместе с разработчиками деплоит и отлаживает их сервисы и вводит новых коллег в инфраструктуру. | Создаёт инструменты самообслуживания, с которыми команды заводят сервисы и окружения без заявок, менторит других DevOps-инженеров и участвует в найме. | Развивает платформу как внутренний продукт, пользователи которого — разработчики, решает, за что отвечают команды, а за что — платформенная команда, и выращивает следующих senior-инженеров. |
Прокрутите таблицу вбок, чтобы увидеть все уровни.
Скачать в CSV Открывается в Excel, Google Таблицах и Numbers.
Junior DevOps-инженер: что ожидается
Вносит небольшие изменения в инфраструктуру и пайплайны через ревью и разбирается, как устроен продакшен. Отдельные изменения в существующем инфраструктурном коде и пайплайнах, которые планирует и проверяет кто-то опытнее.
- Инфраструктура как код
- Меняет существующий инфраструктурный код по уже принятым образцам, проверяет план изменений перед применением и никогда не правит продакшен вручную, не спросив сначала.
- Сборка и пайплайны выпуска
- Чинит сломанные шаги пайплайнов и добавляет простые джобы в существующие пайплайны, а также объясняет разработчику, почему упала его сборка.
- Надёжность и реагирование на инциденты
- Дежурит в паре с опытным коллегой, действует по ранбукам для известных алертов и быстро эскалирует, передавая информацию, которая понадобится следующему.
- Мониторинг и наблюдаемость
- Добавляет дашборды и алерты по существующим примерам и, когда что-то выглядит странно, первым делом смотрит логи и метрики.
- Безопасность и доступы
- Соблюдает правила команды по секретам и доступам, ставит плановые обновления и сразу сообщает обо всём, что похоже на проблему безопасности.
- Помощь разработчикам и взаимодействие
- Отвечает на вопросы разработчиков об окружениях и пайплайнах, документирует сделанные исправления и рано просит ревью.
Middle DevOps-инженер: что ожидается
Полностью отвечает за части инфраструктуры и наравне с остальными участвует в дежурствах. Сервисы, окружения или пайплайны одной–двух продуктовых команд — от проектирования до повседневной эксплуатации.
- Инфраструктура как код
- Пишет переиспользуемые инфраструктурные модули для новых сервисов и окружений, безопасно обращается со стейтом и секретами и удаляет ресурсы, которые больше не используются.
- Сборка и пайплайны выпуска
- Строит и поддерживает полный пайплайн сервиса — сборку, тесты, артефакты, деплой во все окружения — и ускоряет медленные шаги, на которые жалуются разработчики.
- Надёжность и реагирование на инциденты
- Дежурит наравне с остальными, сам разбирается с большинством инцидентов в своей зоне, пишет ранбуки по тому, что починил, и проверяет бэкапы, реально восстанавливаясь из них.
- Мониторинг и наблюдаемость
- Настраивает логирование, метрики и алерты для новых сервисов, доводит алерты до состояния, когда каждое срабатывание требует действия, и помогает разработчикам находить нужное в данных.
- Безопасность и доступы
- Управляет доступами и секретами своих сервисов по принципу минимальных прав, закрывает уязвимости в порядке их критичности и исправляет находки сканеров безопасности.
- Помощь разработчикам и взаимодействие
- Пишет понятные инструкции для типовых задач, вместе с разработчиками деплоит и отлаживает их сервисы и вводит новых коллег в инфраструктуру.
Senior DevOps-инженер: что ожидается
Проектирует и ведёт инфраструктурные проекты, от которых зависят несколько команд, и поднимает планку надёжности. Общая инфраструктура, которой пользуется большая часть разработки, и проекты вроде миграций, затрагивающие все команды.
- Инфраструктура как код
- Проектирует структуру инфраструктурного кода и окружений компании, ведёт изменения вроде обновления сети или кластеров с проверенным планом отката и делает расходы на облако видимыми в разрезе команд.
- Сборка и пайплайны выпуска
- Проектирует общие шаблоны пайплайнов для всех команд, внедряет более безопасные способы выпуска вроде canary- или blue-green-деплоя и отслеживает частоту деплоев и долю неудачных выкаток.
- Надёжность и реагирование на инциденты
- Руководит реагированием на крупные инциденты, проводит постмортемы без поиска виноватых и доводит итоговые задачи до конца, планирует мощности и отказоустойчивость критичных систем.
- Мониторинг и наблюдаемость
- Проектирует подход к наблюдаемости для основных систем компании, определяет сигналы здоровья сервисов, по которым оценивают команды, и снижает шум алертов во всех командах.
- Безопасность и доступы
- Проектирует сетевые границы, управление идентификацией и секретами на всей платформе, готовит материалы для проверок безопасности со стороны клиентов и руководит реагированием на инциденты безопасности.
- Помощь разработчикам и взаимодействие
- Создаёт инструменты самообслуживания, с которыми команды заводят сервисы и окружения без заявок, менторит других DevOps-инженеров и участвует в найме.
Staff DevOps-инженер: что ожидается
Задаёт направление развития платформы компании и отвечает за её надёжность, безопасность и стоимость. Вся продакшен-платформа, её развитие на несколько лет вперёд и её бюджет — для всех команд разработки.
- Инфраструктура как код
- Выбирает базовые компоненты и провайдеров платформы на несколько лет вперёд, задаёт стандарты, которым следует инфраструктура всех команд, и вместе с руководством отвечает за инфраструктурный бюджет.
- Сборка и пайплайны выпуска
- Определяет, как вся компания выпускает софт — от ветвления до отката, — и устраняет узкие места, которые замедляют выпуск во всех командах.
- Надёжность и реагирование на инциденты
- Вместе с продуктом и руководством задаёт целевые показатели надёжности, выстраивает процесс дежурств и работы с инцидентами для всей разработки и готовит компанию к авариям вроде потери региона или провайдера.
- Мониторинг и наблюдаемость
- Выбирает инструменты наблюдаемости для компании и модель их стоимости и добивается, чтобы руководство видело состояние платформы, не спрашивая инженеров.
- Безопасность и доступы
- Вместе с руководством отвечает за уровень защищённости платформы, задаёт меры контроля, которых требует комплаенс (например, SOC 2 или ISO 27001), и делает безопасный путь самым простым для каждой команды.
- Помощь разработчикам и взаимодействие
- Развивает платформу как внутренний продукт, пользователи которого — разработчики, решает, за что отвечают команды, а за что — платформенная команда, и выращивает следующих senior-инженеров.
Как адаптировать эту лестницу
Назовите свой стек в ожиданиях
С общими фразами вроде «инфраструктурный код» или «пайплайны» легко согласиться, но по ним трудно оценивать. Замените их своими реальными инструментами и практиками, чтобы junior-инженер точно знал, что ему нужно освоить в первую очередь.
Не спешите вводить уровень Staff
Когда DevOps-инженеров один–три, обычно хватает уровней junior, middle и senior. Добавляйте Staff, когда кто-то действительно задаёт направление развития платформы и отвечает за её бюджет для всей разработки, а не как должность для самого опытного человека в маленькой команде.
Пропишите правила дежурств в лестнице
Укажите, с какого уровня человек входит в график дежурств, когда начинает руководить инцидентами и как компенсируется время на дежурстве. Неписаные ожидания по дежурствам — одна из самых частых причин, по которым инфраструктурные инженеры выгорают и уходят.
Сопоставьте уровни с лестницей разработчика
Привяжите каждый уровень DevOps к уровню разработчика с тем же масштабом и зарплатой. Платформенная работа — это инженерная работа, и согласованные лестницы упрощают переходы между продуктовыми и платформенными командами.
Вопросы и ответы
Вопросы об этой лестнице
Чем DevOps-инженер отличается от SRE и платформенного инженера?
Строго говоря, DevOps — это способ работы, а не должность; на практике в компаниях на 20–200 человек эти названия чаще всего описывают одну и ту же работу с разными акцентами: SRE сосредоточены на целевых показателях надёжности — обычно SLO и бюджетах ошибок — и инцидентах, платформенные инженеры — на инструментах самообслуживания для разработчиков, DevOps-инженеры — на пайплайнах и инфраструктуре. Обычно всех троих покрывает одна лестница: поправьте формулировки компетенций, а не заводите отдельные лестницы.
Когда стартапу нужен первый DevOps-инженер?
Обычно — когда разработчики тратят заметную часть недели на деплои, окружения и проблемы в продакшене вместо фич или когда клиенты начинают просить гарантий доступности и проверок безопасности. Во многих компаниях это происходит примерно при 15–30 разработчиках.
Должны ли дежурства учитываться при повышении DevOps-инженера?
Да, но учитывайте то, чему человек научился и что улучшил, а не число отвеченных алертов. Хорошо проведённый крупный инцидент, постмортемы, задачи из которых действительно выполнены, и снижение шума алертов — явные аргументы в пользу следующего уровня. Частые дежурства сами по себе — нет.
Влияют ли облачные сертификаты на грейд DevOps-инженера?
Они помогают освоить платформу, но не должны определять уровень. Оценивайте то, что человек построил и эксплуатирует в вашей инфраструктуре, по матрице компетенций. Сертификат без таких примеров не доказывает следующий уровень, а такие примеры без сертификата — доказывают.
Сколько грейдов нужно DevOps-инженеру?
Три–четыре, потому что инфраструктурные команды в компаниях такого размера небольшие. В этом шаблоне четыре — Junior, Middle, Senior и Staff, — и он хорошо сочетается с пятиуровневой лестницей разработчика, если выровнять уровни Staff.
Соберите эту карьерную лестницу в LadderKit — бесплатно
Задайте её уровни и навыки для своей команды, оценивайте людей по ним на чек-инах и принимайте решения о повышении по единым правилам.
Бесплатный тариф · Банковская карта не нужна
Похожие шаблоны
Разработка
QA-инженер
Четыре уровня от Junior QA до Lead QA и шесть компетенций — от тест-дизайна до практик качества в команде.
- 4 уровня
- 6 компетенций
Разработка
Руководитель разработки
Четыре уровня от Engineering Manager до VP of Engineering и шесть управленческих компетенций.
- 4 уровня
- 6 компетенций