а просто DevOps - это методология

Что значит DevOps инженер? Инженер соблюдающий принципы DevOps? А остальные в компании что делают? Не соблюдают? ))

Вообще интересно, что у компании с капитализацией в 2 ярда, нет плана действий по восстановлению, нет  контактов сервисов от которых зависят. Мрак какой-то.

нет, я бы охарактеризовал инженера - как людей или группу людей, которые согласовывают с эксплуатацией процесс разработки и поставки по. Остальные в компании, тоже поддерживают методологию (вероятно), но вряд ли можно назвать DevOps-ом HR-а, который работает в компании, которая поддерживает данную методологию)

Эффективные менеджеры они такие))

но это занудство и философия, если честно)

сорян)

Т.е. прослойка между Dev и Ops?

простым языком думаю да

Это как бы не правильно... Вот сегодня как раз в тему писали коллеги:

https://express42.com/news/4-devops-antipatterns-lead-to-disaster/

TL;DR: Основная проблема поиска канадидата на российском IT рынке, в области DevOps кроется в следующих причинах:
1) отсутствие понимания что такое этот DevOps есть на самом деле
2) отсутствие понимания специфики области
3) отсутствие интереса и мотивации к саморазвитию
4) Поиск не SRE, а DevOps-инженера

Long read:
Давайте разбирать теперь по пунктам:
1) отсутствие понимания что такое этот DevOps есть на самом деле

Если мы копнем чуть глубже, то можно заметить что большинство компаний не работают по DevOps т.к. не была произведена бизнес-трансформация. Они просто создали отдел, наняли человека и назвали его DevOps (при этом в трудовой у него будет какой-нибудь главный ведущий старший системный администратор).
Таким образом компании не понимают кто же им собственно нужен и как итог они увольняют системных администаторов и нанимают системных администаторов.
При этом, стоит отметить, что отсутствие понимания что такое DevOps есть не только среди компаний, но и среди самих специалистов.
Для понимания ситуации досаточно проследить базовый пусть от сис.админа до девопса. Человек был системным администраторлм, но платили мало. Он нашел работу, где делает ровно тоже самое, но шильдик другой и платят хорошо. Все)
Таким образом наполнение ни у бизнеса, ни у сотрудника не поменялось, а витрина поменялась.

2) отсутствие понимания специфики области

На мой субъективный взгляд начать работать в DevOps области может любой специалист не ниже уровня middle. Будь то виндовый админ, линуксовый или разработчик.
Причина почему я так думаю, так это заключается в том, что человек начиная работать в новой для себя отрасли, начинает ее изучать. Он изучает ее инструменты и технологии, подходы, а самое главное изучает ее теоретическо-философские подходы и аспекты.
В противном случае он или найдет себе работу как п.1 или просто выучит набор технологий и станет таким же специалистом из п.1 т.к. он будет знать набор инструментов, но не будет понимать специфику, а значит не сможет делать выбор среди инструментов и будет вечно следовать за трендами.

3) отсутствие интереса и мотивации к саморазвитию

Если мы начнем изучать DevOps правильно, а именно что это методология, то мы рано или поздно прочтем "DevOps уменьшает время до рынка, что позволяет вам деплоить ваше приложение несколько раз в день".
Отсюда у меня возникает вопрос, если ты работаешь в динамической среде, которая меняется каждый день, иногда каждый час. То как ты собираешься в ней работать при высоких темпах, если ты не заинтересован в сосбственном развитии?
Если у тебя нет стимула к саморазвитию, то рано или поздно ты превратишься в админа из п.1

4) Поиск не SRE, а DevOps-инженера

Самая главная проблема, что ищут людей из п.1, которые прошли какие-либо курсы по девопс за 21 день час. Знают как работать с ансиблом, как работать с кубером, но не знают как эти инструменты сами по себе работают, а также не знают почему конкретно эти инструменты завоевали рынок.
Данные люди знают хард скиллы, но не на знают как работает методология. Какие бенефиты она несет и чем может помочь бизнесу и какие задачи вообще призвана решить.
Зато они могут обернуть ваше приложение в контейнер докер и запустить его в кубере, который был развернут as is без какого-либо тюнинга или оглядки на иб)

блин, спасибо большое, крайне подробно)

например мыло test@example.com  и в метрики оно не идёт

Если по английски читаешь, то вот тут ещё посмотри:

https://web.devopstopologies.com/

Там и ссылка на книжку от авторов есть.

Спасибо)

получается, что подход в том, чтобы статистику "чистить"?

А зачем? Не проще ли мониторить логи вебсервера на ошибки и отсутствие записей, условно час

Пожалуйста! )

Да. Как конкретно зависит от системы. Мы сейчас делаем поле is-test чтобы только его смотреть, а определение тест-не тест делать перед записью, в миддлаваре например

Это если вопрос про снятие бизнес-метрик типа сколько продали )