Розробка
Розробник
П’ять рівнів від 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 компетенцій