sperr0w Sep 11 2018 at 17:06

Семь «НЕ» мониторинга ИТ-инфраструктуры

8 min

23K

Сбер corporate blogIT Infrastructure*System Analysis and Design*Server Administration*System administration*

+16

Comments 20

rjhdby Sep 12 2018 at 10:33

5. НЕ заставляйте сотрудников работать с системой мониторинга

Это «НЕ», фактически, предполагает, что сотрудники сами дойдут до понимания, что мониторинг им нужен. К сожалению, процесс этого понимания может быть крайне болезненным и убыточным для компании. Так что как бы ни хотелось следовать этому принципу, но какими-то базовыми метриками(доступность, CPU, RAM, FS) таки необходимо заставлять пользоваться всех администраторов.

sperr0w Sep 13 2018 at 00:11

Не правильно заставлять. Не правильно. Если создать такие условия, что подразделениям будет выгодно пользоваться системой мониторинга, они сами начнут ее использовать. Самый банальный пример. Поставьте в kpi подразделения целевой показатель по количеству критических аварий. И аварии эти считайте по системе мониторинга. В этом случае подразделения очень быстро сами, добровольно запросят оповещения, которые предвещают критические аварии. Это и есть мотивация в моем понимании.

rjhdby Sep 13 2018 at 09:22

Самый банальный пример. Поставьте в kpi подразделения целевой показатель по количеству критических аварий. И аварии эти считайте по системе мониторинга. В этом случае подразделения очень быстро сами, добровольно запросят оповещения

И произойдет это, скорее всего, после былинного отказа, когда бизнес потеряет деньги, а сопровождение девственность.

speshuric Sep 16 2018 at 17:57

Не-не-не. Просто с такими KPI подразделения быстро научатся перекладывать ответственность и искать виноватых. И тут мониторинг скорее помеха, чем профит. Админы приложения: "Это не у нас, это у DBA", DBA: "А чо мы-то? Это проблема админов сервера.", админы сервера: "У нас проблем не было, спросите у админов СХД", админы СХД: "ничо не знаем, у нас SLA latency 20 мс при 1000 IOPS".

speshuric Sep 16 2018 at 18:00

Ах, да, а разработчики после этого внедрить вообще ничего не могут потому что у админов KPI на сбои, а любое новое — риск сбоя.

rjhdby Sep 19 2018 at 10:26

Обычно происходит расследование причин сбоя и серьгами одариваются те сёстры, которые причастны.

rdbkzn Sep 12 2018 at 12:06

Наверное, вы правы: для «сбербанка» интегратор не сможет выполнить работу сотрудников «сбербанка».
Молоток не способен забивать гвозди фактом своего наличия.
А где практические рекомендации ? Или текст применим только для заказчиков размера сбербанка?

rjhdby Sep 12 2018 at 13:05

Собственно в статье даны довольно неплохие практические рекомендации. Только это не рекомендации по настройке zabbix, а рекомендации по настройке процесса.

klauss_z Sep 12 2018 at 13:23

Практическая часть была в прошлом материале автора, про развитие мониторинга в Сбертехе — habr.com/company/sberbank/blog/420731

sperr0w Sep 13 2018 at 00:14

Для описания организации процесса все довольно конкретно. Считаю, что рекомендации применимы для любой компании, которая хочет организовать мониторинг, приносящий реальную пользу.

amarao Sep 12 2018 at 14:15

Все разы, когда я имел дело с запуском мониторинга чего-либо в продакшен, основной проблемой был не сам мониторинг, а два извечных вопроса:
* Кто это читает?
* Кто это исправляет и как он знает что фиксить?

Главной драмой мониторинга является то, что лучше всего проблемы может диагностировать techlead или его аналог. Но обычно это человек, который меньше всего хочет получать сообщения «на сервере srv3455 у диска /dev/sdzb появились сбойные сектора» в час ночи.

А дальше мы вообще заканчиваем с мониторингом (как ИТ) и начинаем с организационной работой. Откуда саппорт знает, что надо делать в этой ситуации? Кто саппорт научил, кто следит за актуальностью этих знаний и их воспроизводимостью при текучке кадров?

И из абстрактной задачи «predictive monitoring» мы получаем практическую дилемму «надо бы сотрудников подешевле — значит, кто-то за них, заранее, должен знать все сценарии отказа» VS «надо набрать толковых людей, которые разберутся».

На практике получается смешанный подход, и документация и практики (схемы что где как менять и что делать) нарабатываются со временем.

Более того, из моего опыта, за вычетом пары-тройки тривиальных сценариев, попытка придумать сценарии до реальных отказов чаще всего приводит к тому, что сценарии есть, но в жизни всё не так как запланировано.

sperr0w Sep 13 2018 at 00:18

См. Седьмое НЕ из моей статьи. Там как раз про это.

amarao Sep 13 2018 at 12:48

«кто и как» не раскрыто. Т.е. «кто» — кого назначат, «как» — в соответствии с должностными обязанностями (поддерживать работоспособность информационных систем Компании). Типа, вопрос закрыт.

А на самом деле его даже не начинали раскрывать.

sperr0w Sep 13 2018 at 16:17

Вопрос регламентов очень сильно завязан на специфику и орг структуру конкретной компании. Не существует универсальных рецептов. В 7 пункте я лишь хочу подчеркнуть, что правила, регламенты, инструкции и прочее должны существовать к моменту начала работы системы. Любые, пусть даже не оптимальные регламенты лучше, чем их их полное отсутствие.

rjhdby Sep 13 2018 at 16:50

Единственно надо понимать, что эти инструкции и регламенты не должны быть отлиты в граните. Они должны постоянно улучшаться и меняться, подстраиваясь под текущие реалии.

sperr0w Sep 13 2018 at 20:09

Да, конечно. В том числе к этих регламентных должно быть зафиксировано порядок и периодичность их пересмотра.

amarao Sep 13 2018 at 18:11

вот в этом месте у нас и разногласия. Если у вас регламенты уже есть, то они не о том, что случилось.

Точнее, можно иметь регламент о том, кто пишет клиенту «извините, ваших данных больше нет», но если мы про техническую часть (как чинить? какие сервера можно ребутать, какие нет? Можно ли накатывать бэкап базы и по каким случаям?), то регламенты «заранее» нифига хорошего не сделают. Можно прогнать несколько искусственных аварий, но мой опыт говорит, что они не похожи на аварии настоящие.

Так что алгоритм тут другой — в пусконаладке и тестовом внедрении ответственные люди (архитекторы) участвуют в разборах полётов, и эти разборы и становятся основой для мониторинга. Дальше в продакшене каждый раз, когда непонятно что делать, это исправляют «самые умные», а по итогам второй раз такое уже исправляет линейный персонал по готовой инструкции.

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

AntoniusFirst Sep 13 2018 at 19:45

Некоторое, что можно загнать в регламент — можно и автоматизировать.

Если причины известной проблемы рандомные, но примерно известно где копать, к системе алертинга/мониторинга привязывается база знаний/CMDB, которая обогащает события специальным полем с описанием «где копать и кому звонить, если раскопать не получилось». В более простом случае, в событие автоматически добавляется информация с телефоном ответственного.

sperr0w Sep 13 2018 at 20:56

Собственно, у нас как раз такая интеграция с CMDB и реализована. См. Предыдущую статью.

sperr0w Sep 13 2018 at 20:52

В этой компании до внедрения сервиса мониторинга никогда аварий не происходило? Или их не решали никак?
Сомневаюсь.
Вот "самые умные" должны сесть и оформить в виде регламентов свое видение того, кто и что должен делать в случае, если мониторинг зафиксировал аварию (с учетом опыта решения проблем, которые были до...). А потом эти регламенты дорабатывать на основе ситуаций, когда в процессах взаимодействия произошёл сбой.