#devops-инженер #длиннопост

Долгое вступление. Допустим, у вас есть проблема - вы хотите попасть из точки А в точку Б. Как этого добиться?
Если отбросить идею самовнушения "мне не нужно в точку Б", то решение довольно простое - нужен способ для перемещения. Какой? Мы можем пройтись пешком. Или на машине. Или на самолете. Какой из способов передвижения мы выберем? Зависит, например, от расстояния между А и Б.
В этой простой аналогии прогулка пешком, машина или самолет - это конкретные "продукты". У каждого есть плюсы и минусы. Они требуют обслуживания и навыков использования. Но все эти продукты одного и того же "класса инструментов" - это инструменты передвижения.

Мы много говорим про DevOps. Обсуждаем, имплементируем, распространяем идею и в конце концов полностью теряем изначальный смысл.

"CI - это девопс! Тесты - это девопс! Гит - это девопс!"

Все эти лозунги очень быстро превращаются в:
"Девопс - это гит, тесты и дженкинс!"

Теряется информация о том, что девопс - это культура, идеология, средство. Инструмент, но не в смысле какого-то конкретного продукта, а как способа решения конкретных проблем.
И получается, что человек-который может применять конкретные "продукты" вроде того же Дженкинса, внезапно становится devops-инженером.
- Ну, он же инженер?
- Инженер!
- ДевОпс?
- Ну, дженкинс - это же девопс??? Вот!

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

- Ну, у нас же Дженкинс! 1С в Кубернетесе! У нас нет этих проблем!

Ага, щщщаз...

Как-то получается, что понятие DevOps от идеи и культуры перешло к навыку применения конкретных продуктов. Так было с Аджайлом, так происходит с ДевОпсом, так будет и с любой методологией. Имплементации вытесняют изначальную идею.

К чему я это всё. Google распространяет идею (и название) Site Reliability Engineering. Инженеры обеспечения надежности сайта. Или сервиса. Это свод принципов и конкретных практик, по которым Google "имплементирует" DevOps. В отличие от большинства попыток имплементаций девопса в 1с, Гугл все же уделяет внимание всем семи ключевым аспектам разработки приложений по DevOps. И/или 12 факторам "хорошего приложения" из The twelve-factor App, как вам удобнее.

На мой взгляд, SRE или SRE-инженер, если так угодно, это намного более точное и правильное название для тех, кто называет себя "девопс-инженерами". Естественно если этот девопс-инженер занимается или хотя бы контроллирует все 12 факторов.
Под издательством O'Reilly выпущена книга про SRE, доступная к чтению онлайн - https://landing.google.com/sre/sre-book/toc/index.html

Термин SRE потихоньку начинает появляться на сайтах вроде hh.ru, надеюсь, что он получит широкое распространение взамен косноязычному девопс-инженеру.

В заключение. Пробегитесь по оглавлению книги. Или по статье про девопс хотя бы на вики. Подумайте, действительно ли то, чем вы занимаетесь, имеет хоть какое-то отношение к термину DevOps. Обратите внимание на пункты, которыми на вашем проекте/продукте не занимаются. И особенно на те пункты, которые вызывают у вас удивление. Вспомните, что вы не CI-CD внедряете, а решаете вполне определенную проблему. И можете ли вы честно ее сами себе сформулировать?