Я пишу тут редко.  Наверное, потому что не знаю о чем писать, и если кто-то хочет узнать что-то про мониторинге - welcome, предлагайте темы!    А пока тем нет - поделюсь болью в поиске инженера по мониторингу.    Как видно из предыдущего поста, мы в Бургер Кинг очень ищем инженера мониторинга, и вот с чем столкнулись:

• кандидаты не понимают, что такое инженер по мониторингу. Большинство откликов это люди из техподдержки, которые когда-то (а может быть даже регулярно) смотрели в дашборд zabbix/grafana. Видимо, смотрел в дашборд=знаю систему, а все-таки все имеет свои тонкости
• любители курсов. Есть ощущение, что люди пишут все курсы , название которых слышали, но начинаешь задавать вопросы, и оказыватся пустота или уровень знаний прямо скажем небольшой.
• тьма DevOps и SRE. Я очень сочувствую тем, кто ищет людей на эти специальности, все, кто хотя бы слышал про k8s, считают себя DevOps или Sre, модные слова же, сразу пишут название. Используют модные слова по типу "деплоить", к месту и нет. Явно понт, в резюме навыков куча, по факту - ничего.
• запрос огромных зарплат. Да, в IT большие зарплаты. Я на свою не жалуюсь, могла бы быть и больше, но будто бы она в рынке. У меня куча навыков, багаж знаний, опыта, дебагинга ночами. Но как идти в мониторинг, не зная как поправить количество пулеров в заббикс и просить 200+? Загадка. Хотя в целом приходили опытные специалисты с хорошими знаниями, но выходили из бюджета ( опять же реальными знаниями в DevOps)
• я для себя вывел несколько вопросов, которые легко определяют опыт в zabbix. Один из них : " что возращает функция nodata() ?". Она очень популярная и с ней легко запутаться, есть данные 1 или 0?  Ну я думаю, вы знаете. А многие кандидаты не доходят до этого вопроса и это печально.      Закончить хотел тем, что считаю важным для инженера мониторинга:  Важно понимать, что ты ставишь на мониторинг. Знать чуть больше, чем поверхностно все. Powershell, bash если надо, принцип команд на коммутаторах и snmp, распарсить json, обратиться по API куда-то. Написать js для преобразования. Можно прожолжать долго долго. Скажем поставить на мониторинг в условные eltex. И если ты не понимаешь, как раьотает lld, ты и не сделаешь по ним шаблон нормальный. Вторая важная вещь, нужно уметь вытащить от своего заказчика то, что действительно будет ддя него важным и показательным. Например, какой толк смотреть загрузку по озу в %, если 5% свободного ОЗУ  = 16GB и есть еще запас.  Третье, очень важное. Нужно иметь правильный формат ТЗ. Нужно уметь помочь его заполнить и задокументировать в итоге то, что сделано.      P. S. Спасибо всем, кто прочитал. Прошу прощения за ошибки в тексте. К сожалению "сетка" их не подсвечивает, а помимо уровня грамотности у меня еще и толстые пальцы)))