Что на самом деле делает DevOps, а не как пишут во многих вакансиях❌

Если читать вакансии, DevOps это человек, который:
1️⃣Настраивает CI/CD
2️⃣Работает с Kubernetes
3️⃣Пишет Terraform
4️⃣Чинит серверы
5️⃣Дежурит ночью
и этот список можно продолжать практически до бесконечности. Не дохера ли всего делает 1 человек?

Звучит как суперспециалист. В реальности все проще и сложнее одновременно.

DevOps это не отдельная профессия. Это роль в команде. Хотя если быть прям на 100% честным это вообще Философия (можете почитать про это отдельно) в РФ и СНГ сложилось устоявшееся мнение DevOps-инженер, тут я придерживаюсь именно этой парадигмы. 😑

Если совсем просто:
DevOps отвечает за то, чтобы изменения в программе доходили до конечных пользователей продуктом. В наше время каждый занимается четко своим делом (в идеальном мире, да-да) разработчик разрабатывает, DevOps деплоит, тестировщик все ломает (шутка)

1️⃣Изменения это новый код.
2️⃣Момент, когда код уже работает для пользователей и генерирует полезную нагрузку, называется продакшен. Часто говорят просто прод. (Для тех кто не знал, что называют Продом)
3️⃣Про Деплой будет ниже, не бойтесь :)

Что DevOps делает на самом деле, DevOps в первую очередь следит за процессом.

1. Как изменения попадают к пользователям

Разработчик написал код.
Его нужно:
собрать
проверить
запустить на серверах

Этот процесс называется деплой.
Если деплой ручной и каждый раз разный, начинаются проблемы.

DevOps делает так, чтобы деплой был:
повторяемым
предсказуемым
без ручных действий

2. Как система работает после запуска

Когда программа уже запущена, важно понимать:
она вообще работает или нет, не тормозит ли не упала ли часть системы после внесения изменений в софт и так далее. (там все сложнее)

Для этого используют:
логи это записи о работе программы
метрики это цифры о нагрузке и состоянии
алерты это уведомления о проблемах

DevOps настраивает все это. Чтобы о проблеме узнавали быстро, а не от клиента или руководства.

3. Что будет если что то сломается

Любая система ломается.
Вопрос не если, а когда.

DevOps думает заранее:
что сломается первым
как быстро восстановить работу
кто получит уведомление
что делать по шагам

Это и есть инженерное мышление.

Чего DevOps обычно не делает

Но от него часто этого ждут.

DevOps обычно:
не пишет бизнес код
не заменяет разработчиков
не чинит все в одиночку
не обязан знать все технологии мира

Если в вакансии требуют все подряд, это не DevOps. Это признак хаоса в компании.

Почему DevOps часто крайний

DevOps находится между:
разработчиками
серверами
бизнесом

Если что то не работает:
Разработчики говорят: "Локально у нас все работало, задеплоили не дев и тест, там тоже ок, на проде чет свалилось, мы не знаем"
Бизнес спрашивает: "Почему простой и когда проблема будет устранена?"

И отвечать приходится DevOps. Не потому что мы виноваты или из-за нас что-то упало(такое тоже может быть, человеческий фактор еще никто не отменял). А потому что он видит всю картину.👀

Что важно понять новичку кто хочет погрузить в этот дивный и чудный мир:

DevOps это не набор инструментов. Это образ мышления, по другому и не скажешь. DevOps не только должен уметь думать как инженер, но еще и уметь разговаривать и доносить между командами правильно информацию, объяснять бизнесу простым языком сложные технические вещи и почему очередная "мудрая" вещь очередного "мудрого" Манагера полная хуита и не будет работать.

А так же, всегда должен уметь задавать вопросы себе, внутри команды, архитекторам и так далее при внедрение что либо нового в процесс.
как это будет работать у пользователей (если их это касается)
что будет если упадет (наша новая IMBA фича)
как мы узнаем о проблеме(хреново если с вертухи от Руководства)
как быстро восстановимся(Бекапы да, помним все про бекапы?)

Если есть это мышление, инструменты придут сами.

Что должен уметь DevOps
Разрабатывать и упрощать процессы
Делать систему стабильной
Помогать команде работать спокойно(пожалуй и очень часто для многих это самое сложное, а иногда это еще и самое важное)