0 added
0 removed
Original
2026-01-01
Modified
2026-02-19
1
<h2>Как появились DevOps-инженеры и что нужно сделать, чтобы стать одним из них</h2>
1
<h2>Как появились DevOps-инженеры и что нужно сделать, чтобы стать одним из них</h2>
2
В IT существует такая специальность - DevOps-инженер. Она относительно новая и не так широко известна, как, например, разработчик или системный администратор. В задачах DevOps-инженера особенно сложно разобраться тем, кто только начинает свой путь в IT. <p>Преподаватель курсов "Слёрма" и девелопер адвокат Southbridge Марсель Ибраев рассказывает в статье, что такое DevOps, как он появился, и какие навыки нужны DevOps-инженеру, чтобы получить оффер.</p>
2
В IT существует такая специальность - DevOps-инженер. Она относительно новая и не так широко известна, как, например, разработчик или системный администратор. В задачах DevOps-инженера особенно сложно разобраться тем, кто только начинает свой путь в IT. <p>Преподаватель курсов "Слёрма" и девелопер адвокат Southbridge Марсель Ибраев рассказывает в статье, что такое DevOps, как он появился, и какие навыки нужны DevOps-инженеру, чтобы получить оффер.</p>
3
<h2>А куда мы, собственно, собираемся входить</h2>
3
<h2>А куда мы, собственно, собираемся входить</h2>
4
Давайте сначала разберёмся, куда мы вообще собираемся входить. Можно предположить три варианта:<ul><li>DevOps - это профессия. Как учитель, музыкант или программист. И этой профессии можно обучиться.</li>
4
Давайте сначала разберёмся, куда мы вообще собираемся входить. Можно предположить три варианта:<ul><li>DevOps - это профессия. Как учитель, музыкант или программист. И этой профессии можно обучиться.</li>
5
<li>DevOps - это технология, типа Wi-Fi или 4G. Ей можно обучиться и применять, чтобы стать айтишником.</li>
5
<li>DevOps - это технология, типа Wi-Fi или 4G. Ей можно обучиться и применять, чтобы стать айтишником.</li>
6
<li>DevOps - это закрытое сообщество, секта (например, "Монолит" - привет фанатам S.T.A.L.K.E.R.). Нужно пройти определённые ритуалы, чтобы попасть в это сообщество.</li>
6
<li>DevOps - это закрытое сообщество, секта (например, "Монолит" - привет фанатам S.T.A.L.K.E.R.). Нужно пройти определённые ритуалы, чтобы попасть в это сообщество.</li>
7
</ul>На самом деле, верен четвёртый. DevOps - не профессия, не технология, и уж точно не закрытое общество. Это методология: набор рецептов, методик, инструкций. Если им следовать, мы придём к какой-то цели.<p>Можно сказать, что DevOps-инженер, которого часто ищут на сайтах с вакансиями - это фантастическое, сказочное существо. Потому что быть инженером какой-то методологии невозможно. Инженер-строитель, инженер-энергетик - да, а инженер набора рецептов - даже звучит подозрительно.</p>
7
</ul>На самом деле, верен четвёртый. DevOps - не профессия, не технология, и уж точно не закрытое общество. Это методология: набор рецептов, методик, инструкций. Если им следовать, мы придём к какой-то цели.<p>Можно сказать, что DevOps-инженер, которого часто ищут на сайтах с вакансиями - это фантастическое, сказочное существо. Потому что быть инженером какой-то методологии невозможно. Инженер-строитель, инженер-энергетик - да, а инженер набора рецептов - даже звучит подозрительно.</p>
8
<p>С формулировкой смирились, и слово "DevOps-инженер" стали писать в названиях вакансий. Однако из-за того, что конкретных требований к позиции нет, возник очень серьезный разброс: от DevOps-инженера везде ожидают разного. И чтобы хотя бы примерно понять, чего именно от него хотят, вернёмся немного в прошлое.</p>
8
<p>С формулировкой смирились, и слово "DevOps-инженер" стали писать в названиях вакансий. Однако из-за того, что конкретных требований к позиции нет, возник очень серьезный разброс: от DevOps-инженера везде ожидают разного. И чтобы хотя бы примерно понять, чего именно от него хотят, вернёмся немного в прошлое.</p>
9
<h2>История IT и DevOps</h2>
9
<h2>История IT и DevOps</h2>
10
Начнём разбор с того времени, когда компьютеры были большими, а объемы памяти - маленькими. Тогда за компьютерами работали скорее ученые, часто - военные. Эти люди сами разрабатывали компьютеры, сами их обслуживали: чтобы с ними работать, нужно было знать, как они устроены. Таким образом каждый специалист, работающий на компьютере, был максимально широкопрофильным - мог и детали поменять, и связь наладить, и код написать. А писали тогда, кстати, на низкоуровневых языках, команды в которых отдавали приказ напрямую компьютерному железу и очень тесно взаимодействовали с процессором. То есть без технических знаний о работе систем компьютера программировать бы просто не получилось.<em>Первый в Европе программируемый компьютер МЭСМ</em><p>Отрасль развивалась дальше. Появились простые операционные системы типа Windows 95 и высокоуровневые языки программирования - те, которые работали с железом через другие программы-посредники. Теперь, чтобы работать на компьютере, не нужно было знать все тонкости его внутреннего устройства.</p>
10
Начнём разбор с того времени, когда компьютеры были большими, а объемы памяти - маленькими. Тогда за компьютерами работали скорее ученые, часто - военные. Эти люди сами разрабатывали компьютеры, сами их обслуживали: чтобы с ними работать, нужно было знать, как они устроены. Таким образом каждый специалист, работающий на компьютере, был максимально широкопрофильным - мог и детали поменять, и связь наладить, и код написать. А писали тогда, кстати, на низкоуровневых языках, команды в которых отдавали приказ напрямую компьютерному железу и очень тесно взаимодействовали с процессором. То есть без технических знаний о работе систем компьютера программировать бы просто не получилось.<em>Первый в Европе программируемый компьютер МЭСМ</em><p>Отрасль развивалась дальше. Появились простые операционные системы типа Windows 95 и высокоуровневые языки программирования - те, которые работали с железом через другие программы-посредники. Теперь, чтобы работать на компьютере, не нужно было знать все тонкости его внутреннего устройства.</p>
11
<p>В начале 21 века началось активное развитие железа, операционных систем, языков программирования. Внешне, для пользователя, IT-сфера становится проще, но внутри всё сильно усложняется:один человек уже не в силах разбираться и в железе, и в ПО. В итоге в начале 2000-х отрасль разделилась на два лагеря: разработчики и системные администраторы (по-английски это development и operations). Первые стали заниматься кодом, вторые - настраивать железо.</p>
11
<p>В начале 21 века началось активное развитие железа, операционных систем, языков программирования. Внешне, для пользователя, IT-сфера становится проще, но внутри всё сильно усложняется:один человек уже не в силах разбираться и в железе, и в ПО. В итоге в начале 2000-х отрасль разделилась на два лагеря: разработчики и системные администраторы (по-английски это development и operations). Первые стали заниматься кодом, вторые - настраивать железо.</p>
12
В теории всё стало проще. Но появилась серая зона ответственности - когда проект падал после запуска, то есть после выпуска в продакшен. Разработчики говорили, что у них на компьютере приложение работало, и это админы неправильно настроили сервер. Админы говорили - всё работало, это код у них какой-то плохой, виноваты разработчики. Атмосфера между двумя лагерями накалялась, спецы ругались, а стабильность проектов уменьшалась.Чтобы как-то решить эту проблему, в 2009 году на конференции DevOpsDays в Бельгии собрались IТ-специалисты, закрыли двери и сказали "Пока не разберёмся, что делать, дверь не откроется". В итоге они проработали концепцию Developers and Operations - "Разработка и эксплуатация", или сокращенно DevOps. Основная её идея такова: разработчики и администраторы наконец начали работать дружно, а процесс работы превратился в непрерывную автоматическую доставку кода на сервер и в продакшн, при этом по пути ничего не ломалось и все шло как по маслу.На словах звучит прекрасно - за всё хорошее, против всего плохого. На деле это выросло в ряд инструкций, а впоследствии - в ряд инструментов. И всё ради того, чтобы оптимизировать процессы, увеличить стабильность ПО и сократить time-to-market, то есть время до продажи готового продукта клиенту.<h2>Основные концепции DevOps</h2>
12
В теории всё стало проще. Но появилась серая зона ответственности - когда проект падал после запуска, то есть после выпуска в продакшен. Разработчики говорили, что у них на компьютере приложение работало, и это админы неправильно настроили сервер. Админы говорили - всё работало, это код у них какой-то плохой, виноваты разработчики. Атмосфера между двумя лагерями накалялась, спецы ругались, а стабильность проектов уменьшалась.Чтобы как-то решить эту проблему, в 2009 году на конференции DevOpsDays в Бельгии собрались IТ-специалисты, закрыли двери и сказали "Пока не разберёмся, что делать, дверь не откроется". В итоге они проработали концепцию Developers and Operations - "Разработка и эксплуатация", или сокращенно DevOps. Основная её идея такова: разработчики и администраторы наконец начали работать дружно, а процесс работы превратился в непрерывную автоматическую доставку кода на сервер и в продакшн, при этом по пути ничего не ломалось и все шло как по маслу.На словах звучит прекрасно - за всё хорошее, против всего плохого. На деле это выросло в ряд инструкций, а впоследствии - в ряд инструментов. И всё ради того, чтобы оптимизировать процессы, увеличить стабильность ПО и сократить time-to-market, то есть время до продажи готового продукта клиенту.<h2>Основные концепции DevOps</h2>
13
<strong>Автоматизация.</strong>Автоматизируем все процессы, какие только можно. Да, сначала на это уйдет масса времени, но всё потом вернется с лихвой. Кстати, концепция, когда код автоматически собирается, тестируется и доставляется на продакшн, называется CI/CD (Continuous Integration, Continuous Delivery - непрерывная интеграция и доставка) - это одновременно и методология, и технология.<p><strong>Сотрудничество разработчиков и администраторов.</strong>Разработчики должны быть в курсе, как работает инфраструктура, и понимать, что после отправки кода на серверы происходит не магия, а вполне конкретные технические процессы. Это облегчает взаимодействие.</p>
13
<strong>Автоматизация.</strong>Автоматизируем все процессы, какие только можно. Да, сначала на это уйдет масса времени, но всё потом вернется с лихвой. Кстати, концепция, когда код автоматически собирается, тестируется и доставляется на продакшн, называется CI/CD (Continuous Integration, Continuous Delivery - непрерывная интеграция и доставка) - это одновременно и методология, и технология.<p><strong>Сотрудничество разработчиков и администраторов.</strong>Разработчики должны быть в курсе, как работает инфраструктура, и понимать, что после отправки кода на серверы происходит не магия, а вполне конкретные технические процессы. Это облегчает взаимодействие.</p>
14
<p>С администраторами то же самое: они знают, какие фреймворки используют разработчики, какой пишут код. Получается синергия двух отделов, на стыке которых рождается взаимопонимание и новые инструменты и технологии.</p>
14
<p>С администраторами то же самое: они знают, какие фреймворки используют разработчики, какой пишут код. Получается синергия двух отделов, на стыке которых рождается взаимопонимание и новые инструменты и технологии.</p>
15
<p>А кроме того появляются новые профессии, она из которых - наш мифический DevOps-инженер. Именно он - связующее звено между разработчиками и сисадминами. Он налаживает взаимодействие, обеспечивает автоматизацию, организует всё так, чтобы система доставки кода действительно работала непрерывно.</p>
15
<p>А кроме того появляются новые профессии, она из которых - наш мифический DevOps-инженер. Именно он - связующее звено между разработчиками и сисадминами. Он налаживает взаимодействие, обеспечивает автоматизацию, организует всё так, чтобы система доставки кода действительно работала непрерывно.</p>
16
<h2>Что должен знать DevOps-инженер</h2>
16
<h2>Что должен знать DevOps-инженер</h2>
17
Если зайти на hh и посмотреть вакансии DevOps-инженера, вы увидите широкий разброс требований. Некоторые описания очень размытые: "опыт построения архитектуры инфраструктуры", "анализ текущих решений", "разработка скриптов для Greenplum". Иногда вышеупомянутый CI/CD не требуется, а нужно только собирать готовые решения на базе данных. Иногда вместо операционной системы Linux, который обычно ассоциируется с разработкой, нужно администрировать Windows.<p>Но есть и общие навыки, которые позволят откликаться на 99% вакансий с названием "DevOps-инженер".</p>
17
Если зайти на hh и посмотреть вакансии DevOps-инженера, вы увидите широкий разброс требований. Некоторые описания очень размытые: "опыт построения архитектуры инфраструктуры", "анализ текущих решений", "разработка скриптов для Greenplum". Иногда вышеупомянутый CI/CD не требуется, а нужно только собирать готовые решения на базе данных. Иногда вместо операционной системы Linux, который обычно ассоциируется с разработкой, нужно администрировать Windows.<p>Но есть и общие навыки, которые позволят откликаться на 99% вакансий с названием "DevOps-инженер".</p>
18
<p><strong>Linux.</strong>Это более популярное требование, чем знание Windows. Вариации Linux вроде Debian, Ubuntu, Centos не имеют большого значения - разберётесь с одним и легко перейдёте на другой.<strong>Работа сети.</strong>Модель OSI, TCP/IP, сетевые протоколы. В общем, знать, как работает интернет, что происходит на стороне серверов, какие сетевые пакеты куда идут.</p>
18
<p><strong>Linux.</strong>Это более популярное требование, чем знание Windows. Вариации Linux вроде Debian, Ubuntu, Centos не имеют большого значения - разберётесь с одним и легко перейдёте на другой.<strong>Работа сети.</strong>Модель OSI, TCP/IP, сетевые протоколы. В общем, знать, как работает интернет, что происходит на стороне серверов, какие сетевые пакеты куда идут.</p>
19
<blockquote>В индустрии есть "читеры" - они изучили пару-тройку верхнеуровневых технологий, скакнув вверх, но не знают базовых вещей. Они освоили по инструкциям, в какой последовательности нажимать кнопки, но с плохо понимают, как всё работает.</blockquote>Такие люди часто находят работу, но рано или поздно они попадают впросак, когда показывают полную некомпетентность в простых вещах. Например, не могут понять, почему пропала связь между серверами, потому что не понимают принцип работы сети в Linux. <p><strong>Виртуализация, контейнеризация и оркестрация.</strong>Уметь настраивать виртуальные машины на своих серверах. Например, разобраться с virtualbox и KVM. А ещё разобраться с контейнеризацией: здесь сейчас самый популярный инструмент - это Docker. Для оркестрации, то есть управлении контейнерами, чаще всего пользуются Kubernetes. Правда, это система с высоким порогом входа - требуется разобраться во множестве сложных функций. Так что начать можно и без неё.</p>
19
<blockquote>В индустрии есть "читеры" - они изучили пару-тройку верхнеуровневых технологий, скакнув вверх, но не знают базовых вещей. Они освоили по инструкциям, в какой последовательности нажимать кнопки, но с плохо понимают, как всё работает.</blockquote>Такие люди часто находят работу, но рано или поздно они попадают впросак, когда показывают полную некомпетентность в простых вещах. Например, не могут понять, почему пропала связь между серверами, потому что не понимают принцип работы сети в Linux. <p><strong>Виртуализация, контейнеризация и оркестрация.</strong>Уметь настраивать виртуальные машины на своих серверах. Например, разобраться с virtualbox и KVM. А ещё разобраться с контейнеризацией: здесь сейчас самый популярный инструмент - это Docker. Для оркестрации, то есть управлении контейнерами, чаще всего пользуются Kubernetes. Правда, это система с высоким порогом входа - требуется разобраться во множестве сложных функций. Так что начать можно и без неё.</p>
20
<p><strong>Конкретные приложения.</strong>Просто запускать Linux и контейнеры мало: нужно уметь эксплуатировать приложения, которые будут обслуживать код от разработчиков. Я могу посоветовать в первую очередь освоить приложения для веб-разработки - сегодня это самая популярная технология, и с этими знаниями проще всего найти работу. Есть и другие области, вроде машинного обучения или криптографии: там веб-стек не нужен. Но это узкие области, и в них можно переквалифицироваться потом.</p>
20
<p><strong>Конкретные приложения.</strong>Просто запускать Linux и контейнеры мало: нужно уметь эксплуатировать приложения, которые будут обслуживать код от разработчиков. Я могу посоветовать в первую очередь освоить приложения для веб-разработки - сегодня это самая популярная технология, и с этими знаниями проще всего найти работу. Есть и другие области, вроде машинного обучения или криптографии: там веб-стек не нужен. Но это узкие области, и в них можно переквалифицироваться потом.</p>
21
<p>Если вы выбираете веб, нужно будет разобраться с Nginx и PHP-FPM, хотя бы в базовых вопросах.</p>
21
<p>Если вы выбираете веб, нужно будет разобраться с Nginx и PHP-FPM, хотя бы в базовых вопросах.</p>
22
<p><strong>Работа с Git.</strong>Нужно уметь работать с репозиториями, знать, что такое мерж-реквест и GITLab.</p>
22
<p><strong>Работа с Git.</strong>Нужно уметь работать с репозиториями, знать, что такое мерж-реквест и GITLab.</p>
23
<p><strong>CI/CD.</strong>На базовом уровне нужно строить самые простые пайплайны, то есть конвейеры, по которым код автоматически доставляется на сервер.</p>
23
<p><strong>CI/CD.</strong>На базовом уровне нужно строить самые простые пайплайны, то есть конвейеры, по которым код автоматически доставляется на сервер.</p>
24
<p><strong>Инструменты IaC</strong>. IaC (Infrastructure as Code, инфраструктура как код) - это особый подход к построению IT-инфраструктуры. Суть в том, что мы не заходим на серверы и пишем конфигурации, а делаем всё через специальные текстовые файлы: меняем конфигурации, задаём параметры, отслеживаем версии. Это критично, когда серверов много, их нужно постоянно обновлять и мониторить состояние. В DevOps ситуация обычно именно такая. </p>
24
<p><strong>Инструменты IaC</strong>. IaC (Infrastructure as Code, инфраструктура как код) - это особый подход к построению IT-инфраструктуры. Суть в том, что мы не заходим на серверы и пишем конфигурации, а делаем всё через специальные текстовые файлы: меняем конфигурации, задаём параметры, отслеживаем версии. Это критично, когда серверов много, их нужно постоянно обновлять и мониторить состояние. В DevOps ситуация обычно именно такая. </p>
25
<p>Я рекомендую изучить Ansible и Terraform - это пара самых популярных решений. Можно для начала выбрать один: когда освоите его, переехать на другой будет легко.</p>
25
<p>Я рекомендую изучить Ansible и Terraform - это пара самых популярных решений. Можно для начала выбрать один: когда освоите его, переехать на другой будет легко.</p>
26
<p><strong>Мониторинг и логирование</strong>. Систему недостаточно просто автоматизировать - нужно будет ещё следить за её состоянием, собирать информацию о проблемах, чтобы их можно было быстро устранить и предотвратить дальнейшее появление. Инструментов очень много: Prometheus для микросервисов, Zabbix, VictoriaMetrics, Loki, EFK. Умение настраивать и поддерживать эти вещи даст вам серьёзное преимущество при трудоустройстве.</p>
26
<p><strong>Мониторинг и логирование</strong>. Систему недостаточно просто автоматизировать - нужно будет ещё следить за её состоянием, собирать информацию о проблемах, чтобы их можно было быстро устранить и предотвратить дальнейшее появление. Инструментов очень много: Prometheus для микросервисов, Zabbix, VictoriaMetrics, Loki, EFK. Умение настраивать и поддерживать эти вещи даст вам серьёзное преимущество при трудоустройстве.</p>
27
<p><strong>Софт-скилы.</strong>Если вы хотите получить оффер в крупную компанию, вам понадобится софт-скилы: навыки общения, деловой переписки, переговоров. Вы должны уметь решать конфликтные ситуации, быть тактичным, работать в команде, презентовать свою работу. </p>
27
<p><strong>Софт-скилы.</strong>Если вы хотите получить оффер в крупную компанию, вам понадобится софт-скилы: навыки общения, деловой переписки, переговоров. Вы должны уметь решать конфликтные ситуации, быть тактичным, работать в команде, презентовать свою работу. </p>
28
<h2>Что ещё полезно уметь DevOps-инженеру</h2>
28
<h2>Что ещё полезно уметь DevOps-инженеру</h2>
29
Выше был список того, что вам обязательно понадобится для работы. Но есть и другие полезные навыки, которые станут для вас плюсом на рынке:<p><strong>Знание баз данных: MySQL, PostgreSQL, Redis, MongoDB.</strong>Некоторые считают это обязательным, но в крупных компаниях, где строят DevOps, базами обычно занимаются специальные сотрудники.</p>
29
Выше был список того, что вам обязательно понадобится для работы. Но есть и другие полезные навыки, которые станут для вас плюсом на рынке:<p><strong>Знание баз данных: MySQL, PostgreSQL, Redis, MongoDB.</strong>Некоторые считают это обязательным, но в крупных компаниях, где строят DevOps, базами обычно занимаются специальные сотрудники.</p>
30
<p><strong>Знание языков программирования</strong>, хотя бы на базовом уровне. Это поможет лучше понимать разработчиков. Хотя кодить вам, скорее всего, не придётся.</p>
30
<p><strong>Знание языков программирования</strong>, хотя бы на базовом уровне. Это поможет лучше понимать разработчиков. Хотя кодить вам, скорее всего, не придётся.</p>
31
<p><strong>Знание облачных технологий</strong>. Сейчас почти все компании живут в облаках, поэтому важно уметь с ними работать. Из зарубежных это AWS и Google Cloud. В России тоже есть свои облачные провайдеры, но они преимущественно проще и разберётесь вы с ними быстро.</p>
31
<p><strong>Знание облачных технологий</strong>. Сейчас почти все компании живут в облаках, поэтому важно уметь с ними работать. Из зарубежных это AWS и Google Cloud. В России тоже есть свои облачные провайдеры, но они преимущественно проще и разберётесь вы с ними быстро.</p>
32
<p><strong>Английский.</strong>На мой взгляд фраза "без английского в IT делать нечего" - миф. Для начала вам будет достаточно английского на уровне "могу переводить со словарём". Уметь свободно говорить на английском и на ходу переводить тексты, как правило, не требуется. Если планируете выходить на иностранный рынок, язык пригодится, но стартовать можно и без него.</p>
32
<p><strong>Английский.</strong>На мой взгляд фраза "без английского в IT делать нечего" - миф. Для начала вам будет достаточно английского на уровне "могу переводить со словарём". Уметь свободно говорить на английском и на ходу переводить тексты, как правило, не требуется. Если планируете выходить на иностранный рынок, язык пригодится, но стартовать можно и без него.</p>
33
<h2>В заключение: немного о смене профессии</h2>
33
<h2>В заключение: немного о смене профессии</h2>
34
Когда учишься в школе или вузе, уйти в IT просто - обычно есть время для обучения. Сложнее, когда ты уже взрослый, должен работать, есть финансовые обязательства.<p>Самое главное тут, конечно, - желание. Нельзя переходить только ради высокой зарплаты - если вы не будете кайфовать от того, что делаете, то не сможете ни работать, ни даже выучиться.</p>
34
Когда учишься в школе или вузе, уйти в IT просто - обычно есть время для обучения. Сложнее, когда ты уже взрослый, должен работать, есть финансовые обязательства.<p>Самое главное тут, конечно, - желание. Нельзя переходить только ради высокой зарплаты - если вы не будете кайфовать от того, что делаете, то не сможете ни работать, ни даже выучиться.</p>
35
<p>Если желание есть, то нужно учиться. И тут одной теории не хватит - обязательно нужна практика. Пробуйте разворачивать операционную систему Debian на своем ноутбуке, работать в системе управления версиями кода Git, изучать конкретные приложения. И обязательно даже в начале обучения найдите стажировку или работу, чтобы решать реальные прикладные задачи и получать коммерческий опыт.</p>
35
<p>Если желание есть, то нужно учиться. И тут одной теории не хватит - обязательно нужна практика. Пробуйте разворачивать операционную систему Debian на своем ноутбуке, работать в системе управления версиями кода Git, изучать конкретные приложения. И обязательно даже в начале обучения найдите стажировку или работу, чтобы решать реальные прикладные задачи и получать коммерческий опыт.</p>
36
<p>Не переживайте, что вы ничего не умеете. От начинающих специалистов этого обычно не ждут - важны готовность учиться и понимание базовых вещей. И тогда всё получится.</p>
36
<p>Не переживайте, что вы ничего не умеете. От начинающих специалистов этого обычно не ждут - важны готовность учиться и понимание базовых вещей. И тогда всё получится.</p>
37
<p>Если вы прочитали эту статью и поняли, что DevOps не для вас, то можно выбрать другое направление в IT. В этой сфере есть огромное количество профессий, причём некоторые из них даже "гуманитарные". Например, можно быть менеджером продукта или HR-oм - они всегда нужны.</p>
37
<p>Если вы прочитали эту статью и поняли, что DevOps не для вас, то можно выбрать другое направление в IT. В этой сфере есть огромное количество профессий, причём некоторые из них даже "гуманитарные". Например, можно быть менеджером продукта или HR-oм - они всегда нужны.</p>
38
<p>А если вы осознали, что DevOps как раз для вас - приходите к нам в "Слёрм" на</p>
38
<p>А если вы осознали, что DevOps как раз для вас - приходите к нам в "Слёрм" на</p>
39
<a>курс DevOps Upgrade</a>. Там будет и теория, и практика - кейсы, основанные на реальных задачах.
39
<a>курс DevOps Upgrade</a>. Там будет и теория, и практика - кейсы, основанные на реальных задачах.