Разработка
Софтуерен разработчик
Пет нива от Junior до Principal и шест компетенции — от писането и пускането на код до развитието на екипа.
- 5 нива
- 6 компетенции
Шаблон на кариерна стълбица
Кариерна стълбица за DevOps инженер: шаблон
Четири нива от Junior до Staff DevOps инженер и шест компетенции — от инфраструктурата до подкрепата за разработчиците.
Безплатен план · Без банкова карта
Тази кариерна стълбица е за DevOps, платформени и инфраструктурни инженери в компании с около 20–200 души. При такъв размер инфраструктурният екип обикновено е от един до шест души, които поддържат облачните акаунти, CI/CD конвейерите, мониторинга и дежурствата и отделят толкова време за помощ на разработчиците, колкото и за сървърите. Тя описва четири нива — от човек, който прави ясно очертани промени в инфраструктурата, до човека, който отговаря за посоката на платформата в компанията. Най-високото ниво, Staff DevOps инженер, е експертно ниво; управлението на инфраструктурния екип е отделна работа.
Всяко ниво е описано чрез това, което човек прави, и каква част от системата му се поверява, а не чрез години опит или броя инструменти в автобиографията. Четете ред от матрицата на компетенциите отляво надясно, за да видите как расте едно очакване, или раздела на дадено ниво, за да видите всичко, което се очаква на него. Използвайте я, за да обяснявате какво означава следващото ниво, да структурирате чек-ините и да вземате решения за повишение, които можете да защитите.
Адаптирайте я, преди да я публикувате. Заменете общите формулировки с вашия стек и практики и махнете частите, които принадлежат на друг екип — например ако сигурността или базите данни са отговорност на някой друг.
Нивата накратко
Junior DevOps инженер
Прави ясно очертани промени в инфраструктурата и конвейерите с преглед и учи как работи продукционната среда.
- Обхват
- Отделни промени в съществуващия инфраструктурен код и конвейери, планирани и преглеждани от по-опитен колега.
Mid DevOps инженер
Отговаря изцяло за части от инфраструктурата и поема пълен дял от дежурствата.
- Обхват
- Услуги, среди или конвейери за един-два продуктови екипа — от проектирането до ежедневната експлоатация.
Senior DevOps инженер
Проектира и води инфраструктурни проекти, от които зависят няколко екипа, и вдига летвата за надеждност.
- Обхват
- Обща инфраструктура, която използва по-голямата част от инженерството, и проекти като миграции, които засягат всеки екип.
Staff DevOps инженер
Задава посоката на платформата на компанията и отговаря за нейната надеждност, сигурност и цена.
- Обхват
- Цялата продукционна платформа, посоката ѝ за няколко години напред и бюджетът ѝ за всички инженерни екипи.
Матрица на компетенциите
Всеки ред е компетенция, а всяка колона — ниво. Четете реда отляво надясно, за да видите как растат очакванията.
Какво означава всяка компетенция
- Инфраструктура като код
- Изграждане и промяна на инфраструктурата чрез прегледан и повторяем код, а не на ръка.
- CI/CD конвейери
- Кодът да стига от слят pull request до продукция бързо и безопасно.
- Надеждност и реакция при инциденти
- Продукционната среда да е достъпна и да се възстановява бързо, когато не е.
- Мониторинг и наблюдаемост
- Да може да се види какво прави продукционната среда и да се разбере кога нещо се обърква.
- Сигурност и достъп
- Защита на системите и данните чрез безопасни настройки по подразбиране, минимални права и бързо прилагане на корекции.
- Подкрепа за разработчиците и сътрудничество
- Помощ на разработчиците сами да поддържат услугите си и споделяне на знание, така че платформата да не зависи от един човек.
| Компетенция | Junior DevOps инженер | Mid DevOps инженер | Senior DevOps инженер | Staff DevOps инженер |
|---|---|---|---|---|
| Инфраструктура като код | Прави промени в съществуващия инфраструктурен код, като следва вече установените модели, проверява планираните разлики, преди да ги приложи, и никога не променя продукционната среда на ръка, без първо да попита. | Пише модули за многократна употреба за нови услуги и среди, грижи се състоянието и тайните да се обработват безопасно и премахва ресурсите, които вече не се използват. | Проектира структурата на инфраструктурния код и средите на компанията, води промени като надграждане на мрежата или клъстерите с тестван план за връщане назад и поддържа облачните разходи видими за всеки екип. | Избира основните градивни елементи и доставчици на платформата за следващите няколко години, задава стандартите, които следва инфраструктурата на всеки екип, и отговаря за инфраструктурния бюджет заедно с ръководството. |
| CI/CD конвейери | Поправя счупени стъпки в конвейерите, добавя прости задачи към съществуващите конвейери и обяснява на разработчика защо билдът му се е провалил. | Изгражда и поддържа целия конвейер за една услуга — build, тестове, артефакти, deploy във всяка среда — и съкращава бавните стъпки, от които се оплакват разработчиците. | Проектира общи шаблони за конвейери, които използва всеки екип, въвежда по-безопасни методи за релийз като canary или blue-green deploy и следи честотата на внедряванията и дела на неуспешните. | Определя как цялата компания пуска софтуер — от разклоняването до връщането назад — и премахва тесните места, които забавят реализацията във всички екипи. |
| Надеждност и реакция при инциденти | Наблюдава дежурствата заедно с опитен колега, следва наръчниците за познатите аларми и ескалира бързо с информацията, от която следващият човек има нужда. | Поема пълен дял от дежурствата, решава сам повечето инциденти в своята област, пише наръчници за това, което е поправил, и тества резервните копия, като реално ги възстановява. | Води реакцията при големи инциденти, провежда post-mortem анализи без търсене на виновни и довежда последващите действия докрай и планира капацитета и превключването при отказ за критичните системи. | Задава целите за надеждност заедно с продукта и ръководството, проектира процеса за дежурства и инциденти за цялото инженерство и планира за бедствия като загуба на регион или доставчик. |
| Мониторинг и наблюдаемост | Добавя табла и аларми по съществуващи примери и първо проверява логовете и метриките, когато нещо изглежда нередно. | Настройва логове, метрики и аларми за новите услуги, калибрира алармите така, че всяко повикване да изисква действие, и помага на разработчиците да намерят в данните това, което им трябва. | Проектира подхода към наблюдаемостта за основните системи на компанията, определя сигналите за здравето на услугите, по които се измерват екипите, и намалява шума от аларми във всички екипи. | Избира инструментите за наблюдаемост на компанията и модела на разходите за тях и се грижи ръководството да вижда здравето на платформата, без да пита инженер. |
| Сигурност и достъп | Спазва правилата на екипа за тайни и достъп, прилага рутинните корекции и незабавно съобщава за всичко, което прилича на проблем със сигурността. | Управлява достъпа и тайните за своите услуги по принципа на минималните права, отстранява уязвимостите според сериозността им и поправя откритията от сканиранията за сигурност. | Проектира мрежовите граници, управлението на идентичности и тайни в цялата платформа, подготвя доказателства за прегледите на сигурността от клиенти и води реакцията при инциденти със сигурността. | Отговаря за нивото на сигурност на платформата заедно с ръководството, задава контролите, които изисква съответствието (например SOC 2 или ISO 27001), и прави безопасния път най-лесния за всеки екип. |
| Подкрепа за разработчиците и сътрудничество | Отговаря на въпросите на разработчиците за средите и конвейерите, документира поправките, които прави, и иска преглед рано. | Пише ясни ръководства за честите задачи, работи в двойка с разработчиците по внедряването и отстраняването на грешки в услугите им и въвежда новите колеги в инфраструктурата. | Изгражда инструменти за самообслужване, с които екипите създават услуги и среди, без да пускат тикет, е ментор на други DevOps инженери и участва в наемането. | Оформя платформата като вътрешен продукт, чиито потребители са разработчиците, решава за какво отговарят екипите и за какво платформеният екип и развива следващите Senior инженери. |
Превъртете таблицата хоризонтално, за да видите всички нива.
Изтеглете като CSV Отваря се в Excel, Google Sheets или Numbers.
Junior DevOps инженер: какво се очаква
Прави ясно очертани промени в инфраструктурата и конвейерите с преглед и учи как работи продукционната среда. Отделни промени в съществуващия инфраструктурен код и конвейери, планирани и преглеждани от по-опитен колега.
- Инфраструктура като код
- Прави промени в съществуващия инфраструктурен код, като следва вече установените модели, проверява планираните разлики, преди да ги приложи, и никога не променя продукционната среда на ръка, без първо да попита.
- CI/CD конвейери
- Поправя счупени стъпки в конвейерите, добавя прости задачи към съществуващите конвейери и обяснява на разработчика защо билдът му се е провалил.
- Надеждност и реакция при инциденти
- Наблюдава дежурствата заедно с опитен колега, следва наръчниците за познатите аларми и ескалира бързо с информацията, от която следващият човек има нужда.
- Мониторинг и наблюдаемост
- Добавя табла и аларми по съществуващи примери и първо проверява логовете и метриките, когато нещо изглежда нередно.
- Сигурност и достъп
- Спазва правилата на екипа за тайни и достъп, прилага рутинните корекции и незабавно съобщава за всичко, което прилича на проблем със сигурността.
- Подкрепа за разработчиците и сътрудничество
- Отговаря на въпросите на разработчиците за средите и конвейерите, документира поправките, които прави, и иска преглед рано.
Mid DevOps инженер: какво се очаква
Отговаря изцяло за части от инфраструктурата и поема пълен дял от дежурствата. Услуги, среди или конвейери за един-два продуктови екипа — от проектирането до ежедневната експлоатация.
- Инфраструктура като код
- Пише модули за многократна употреба за нови услуги и среди, грижи се състоянието и тайните да се обработват безопасно и премахва ресурсите, които вече не се използват.
- CI/CD конвейери
- Изгражда и поддържа целия конвейер за една услуга — build, тестове, артефакти, deploy във всяка среда — и съкращава бавните стъпки, от които се оплакват разработчиците.
- Надеждност и реакция при инциденти
- Поема пълен дял от дежурствата, решава сам повечето инциденти в своята област, пише наръчници за това, което е поправил, и тества резервните копия, като реално ги възстановява.
- Мониторинг и наблюдаемост
- Настройва логове, метрики и аларми за новите услуги, калибрира алармите така, че всяко повикване да изисква действие, и помага на разработчиците да намерят в данните това, което им трябва.
- Сигурност и достъп
- Управлява достъпа и тайните за своите услуги по принципа на минималните права, отстранява уязвимостите според сериозността им и поправя откритията от сканиранията за сигурност.
- Подкрепа за разработчиците и сътрудничество
- Пише ясни ръководства за честите задачи, работи в двойка с разработчиците по внедряването и отстраняването на грешки в услугите им и въвежда новите колеги в инфраструктурата.
Senior DevOps инженер: какво се очаква
Проектира и води инфраструктурни проекти, от които зависят няколко екипа, и вдига летвата за надеждност. Обща инфраструктура, която използва по-голямата част от инженерството, и проекти като миграции, които засягат всеки екип.
- Инфраструктура като код
- Проектира структурата на инфраструктурния код и средите на компанията, води промени като надграждане на мрежата или клъстерите с тестван план за връщане назад и поддържа облачните разходи видими за всеки екип.
- CI/CD конвейери
- Проектира общи шаблони за конвейери, които използва всеки екип, въвежда по-безопасни методи за релийз като canary или blue-green deploy и следи честотата на внедряванията и дела на неуспешните.
- Надеждност и реакция при инциденти
- Води реакцията при големи инциденти, провежда post-mortem анализи без търсене на виновни и довежда последващите действия докрай и планира капацитета и превключването при отказ за критичните системи.
- Мониторинг и наблюдаемост
- Проектира подхода към наблюдаемостта за основните системи на компанията, определя сигналите за здравето на услугите, по които се измерват екипите, и намалява шума от аларми във всички екипи.
- Сигурност и достъп
- Проектира мрежовите граници, управлението на идентичности и тайни в цялата платформа, подготвя доказателства за прегледите на сигурността от клиенти и води реакцията при инциденти със сигурността.
- Подкрепа за разработчиците и сътрудничество
- Изгражда инструменти за самообслужване, с които екипите създават услуги и среди, без да пускат тикет, е ментор на други DevOps инженери и участва в наемането.
Staff DevOps инженер: какво се очаква
Задава посоката на платформата на компанията и отговаря за нейната надеждност, сигурност и цена. Цялата продукционна платформа, посоката ѝ за няколко години напред и бюджетът ѝ за всички инженерни екипи.
- Инфраструктура като код
- Избира основните градивни елементи и доставчици на платформата за следващите няколко години, задава стандартите, които следва инфраструктурата на всеки екип, и отговаря за инфраструктурния бюджет заедно с ръководството.
- CI/CD конвейери
- Определя как цялата компания пуска софтуер — от разклоняването до връщането назад — и премахва тесните места, които забавят реализацията във всички екипи.
- Надеждност и реакция при инциденти
- Задава целите за надеждност заедно с продукта и ръководството, проектира процеса за дежурства и инциденти за цялото инженерство и планира за бедствия като загуба на регион или доставчик.
- Мониторинг и наблюдаемост
- Избира инструментите за наблюдаемост на компанията и модела на разходите за тях и се грижи ръководството да вижда здравето на платформата, без да пита инженер.
- Сигурност и достъп
- Отговаря за нивото на сигурност на платформата заедно с ръководството, задава контролите, които изисква съответствието (например SOC 2 или ISO 27001), и прави безопасния път най-лесния за всеки екип.
- Подкрепа за разработчиците и сътрудничество
- Оформя платформата като вътрешен продукт, чиито потребители са разработчиците, решава за какво отговарят екипите и за какво платформеният екип и развива следващите Senior инженери.
Как да адаптирате тази стълбица
Назовете стека си в очакванията
С общи фрази като „инфраструктурен код“ или „конвейери“ всички лесно се съгласяват, но по тях трудно се оценява. Заменете ги с реалните си инструменти и практики, така че Junior инженерът да знае точно какво се очаква да научи първо.
Не бързайте с нивото Staff
С един до трима DevOps инженери нивата Junior, Mid и Senior обикновено са достатъчни. Добавете Staff, когато някой наистина задава посоката на платформата и отговаря за бюджета ѝ за цялото инженерство, а не като титла за най-опитния човек в малък екип.
Впишете правилата за дежурствата в стълбицата
Посочете от кое ниво хората влизат в графика за дежурства, кога водят инциденти и как се компенсира времето на дежурство. Неписаните очаквания за дежурствата са една от най-честите причини инфраструктурните инженери да прегорят и да напуснат.
Съпоставете нивата със стълбицата за разработчици
Съпоставете всяко DevOps ниво с нивото на софтуерен разработчик със същия обхват и заплащане. Платформената работа е инженерна работа и подравнените стълбици правят преминаването между продуктови и платформени екипи лесно.
Въпроси
Въпроси за тази стълбица
Каква е разликата между DevOps инженер, SRE и платформен инженер?
Строго погледнато, DevOps е начин на работа, а не длъжност; на практика в компании с 20–200 души тези длъжности най-често описват една и съща работа с различен акцент: SRE се фокусират върху целите за надеждност — обикновено SLO и бюджети за грешки — и инцидентите, платформените инженери върху инструменти за самообслужване на разработчиците, а DevOps инженерите върху конвейерите и инфраструктурата. Обикновено една стълбица покрива и трите; коригирайте формулировките на компетенциите, вместо да създавате отделни стълбици.
Кога стартъпът има нужда от първия си DevOps инженер?
Обикновено когато разработчиците прекарват забележима част от седмицата си в deploy-ове, среди и проблеми в продукция вместо във функционалности или когато клиентите започнат да искат ангажименти за достъпност и прегледи на сигурността. За много компании това става при около 15–30 инженери.
Трябва ли дежурствата да се зачитат при повишението на DevOps инженер?
Да, но зачитайте наученото и подобреното, а не броя на повикванията, на които човекът е отговорил. Добре воден голям инцидент, post-mortem анализи, чиито действия се изпълняват, и по-малко шум от аларми са ясни доказателства за следващото ниво. Честите дежурства сами по себе си не са.
Имат ли значение облачните сертификати за нивото на DevOps инженер?
Те могат да помогнат на човек да научи дадена платформа, но не бива да определят нивото. Оценете какво човекът е изградил и поддържал във вашата среда спрямо матрицата на компетенциите. Сертификат без такива доказателства не показва следващото ниво; такива доказателства без сертификат — показват.
Колко нива са нужни на кариерната стълбица на DevOps инженер?
Три или четири, защото инфраструктурните екипи в компании с такъв размер са малки. Този шаблон използва четири — Junior, Mid, Senior и Staff — и работи добре заедно с петстепенна стълбица за софтуерни разработчици, като нивата Staff са подравнени.
Изградете тази кариерна стълбица в LadderKit — безплатно
Настройте нивата и уменията ѝ за вашия екип, оценявайте хората спрямо тях в чек-ините и вземайте последователни решения за повишения.
Безплатен план · Без банкова карта
Сродни шаблони
Разработка
QA инженер
Четири нива от Junior до Lead QA инженер и шест компетенции — от тест дизайна до практиките за качество.
- 4 нива
- 6 компетенции
Разработка
Engineering Manager
Четири нива от Engineering Manager до VP of Engineering и шест управленски компетенции.
- 4 нива
- 6 компетенции