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

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

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

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

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

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

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

Обычно происходит расследование причин сбоя и серьгами одариваются те сёстры, которые причастны.
Наверное, вы правы: для «сбербанка» интегратор не сможет выполнить работу сотрудников «сбербанка».
Молоток не способен забивать гвозди фактом своего наличия.
А где практические рекомендации ? Или текст применим только для заказчиков размера сбербанка?
Собственно в статье даны довольно неплохие практические рекомендации. Только это не рекомендации по настройке zabbix, а рекомендации по настройке процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

12 декабря 1841

Местоположение

Россия

Сайт

www.sber.ru

Численность

свыше 10 000 человек

Дата регистрации

8 февраля 2011

Блог на Хабре