Опус о том, как не стоит выбирать и внедрять систему мониторинга Здравствуйте уважаемые хабровчане.
Позвольте мне рассказать вам о длинной истории одной компании с очень маленькой хостинговой командой, которая внезапно захотела обновить свою систему мониторинга.
Мы поговорим о долгом и тернистом пути.
То, как только сейчас, почти два года спустя, приближаются к такому замечательному и противоречивому понятию, как режим технического обслуживания.
Если эта история покажется вам интересной, добро пожаловать под кат. Итак, два года назад было принято решение, что SolarWinds ipMonitor, которым мы успешно пользуемся уже довольно много лет, исчерпал свои возможности.
Компания росла, росло количество серверов в ячейках, росло и количество самих ячеек, и было решено, что пинга, телнета и поиска слов в исходнике недостаточно.
Помимо этой системы существовало еще великое множество скриптов, написанных разными инженерами и, естественно, без документации.
Скрипты регулярно ломались, иногда неочевидным образом, в результате чего страдало качество предоставляемых услуг.
На одной из презентаций vmWare мой начальник заметил систему мониторинга с «огромным потенциалом».
Куча индикаторов и кнопок.
графики, инструменты анализа, в общем много всего красивого и приятного для неиспорченного руководителя хостингового отдела из пяти человек.
Этот чудо-инструмент получил название Quest Foglight Monitoring System (далее FMS).
Без дальнейшего промедления старшему инженеру было предложено связаться с поставщиком и провести тестовое развертывание.
После нескольких недель «напряженной работы» инженер дал добро.
Разумеется, начальник предложил нам всем ознакомиться с системой перед покупкой и попросил высказать свое мнение.
Вот и наступила точка невозврата – мы согласились с доводами старца вслепую, так как от основной работы нас никто не освобождал и тратить время на то, где старец сказал «зер гут», казалось, не имело особого смысла.
Итак, была объявлена цена, естественно, нам хотелось получить абсолютно всю возможную функциональность, а цена была довольно высокой.
Продавец пытался убедить нас купить у них профессиональные услуги на несколько месяцев, но некоторым они показались слишком дорогими.
В конце концов, мы как-то справились с тем, что уже произошло, справимся и с этим, правда? О Великий Вишну, насколько ошибочным оказалось это мнение.
Для всей группы был куплен трехдневный пакет обучения, а также неделя ПС, а также заказаны «некоторые доработки».
Опытные айтишники довольно крупного среднего бизнеса, наверное, уже хихикают и крутят пальцами у висков.
Хостеры, вероятно, просто вздыхают и, возможно, удивляются огромной недальновидности всего вышеперечисленного.
Проблемы начались через минуту после того, как время консультанта истекло и нас перевели в отдел поддержки клиентов.
Все началось с того, что наш руководитель предоставил поставщику план развертывания, в котором была указана его тестовая песочница.
Вендор, наверное, был рад продать людям с тремя десятками виртуальных машин и одной базой данных топовую систему мониторинга, но на самом деле речь шла о нескольких сотнях виртуальных машин на нескольких шасси, с несколькими кластерами серверов баз данных, да еще территориально на разных Концы континента.
На тот момент мы и представить себе не могли, насколько прожорливой будет ФМС в плане ресурсов.
После создания всех агентов базы данных, vCenter и инфраструктуры мы вдруг поняли, что всё висит намертво.
Письмо поддержки, нам тыкают носом в план развертывания и говорят, что если бы мы заранее сообщили о размерах наших потребностей, то речь шла бы о других требованиях.
Через два дня старший инженер уволился.
Вот я и выхожу на сцену – я в принципе еще далеко не старший и не имею права голоса в выборе для себя проектов.
Моя первая мысль была: «А не уйти ли мне сейчасЭ» Но русские не сдаются, верно? Сначала я настроил для этого развлечения выделенные сервера.
Два старых Dell 2950 с ESXi. Я не смог настроить отдельный сервер для базы данных, поэтому мне пришлось использовать для этого еще и виртуальную машину на них.
Краткое описание архитектуры FMS
ФМС состоит из: 1. Сервер управления.Таких серверов может быть несколько в активно-пассивном кластере собственной реализации; это центральная точка, которая управляет всем.
2. Менеджер противотуманных агентов.
Менеджер агентов — это служба Windows (демон, если вы умеете и хотите), несколько из которых можно установить для разных нужд. Мы разделили vmWare, SQL-продукцию, SQL-продукцию и ОС таким образом, чтобы в случае возникновения проблемы с одним типом агента нам не приходилось прерывать все наблюдения.
3. Агент противотуманных фар.
Агенты могут быть на все случаи жизни: как купленные у вендора, так и написанные самостоятельно.
4. База данных.
Здесь все понятно — у нас SQL Server 2008. Довольно быстро я понял, что работать с тем, что есть, просто невозможно.
Во-первых, система тормозила даже при наличии достаточных ресурсов.
Страница с менеджером правил могла загружать список правил на произвольное время от пяти до пятнадцати минут. Обращение в поддержку дало неожиданный результат - о проблеме узнали и пообещали исправить в следующей версии.
через квартал.
Между тем власти требовали результатов, и никакие обоснования того, что наша версия тормозит, не принимались – ведь деньги были потрачены очень немалые.
Скрежетая зубами и придумывая обходные пути, все более-менее заработало еще через шесть недель, а потом часы перевели.
При чем здесь летнее время, спросите вы? Дело в том, что в этой системе, которая была разработана довольно давно, была ошибка.
Нет, этого не происходит. Ведь ТАКИЕ баги не попадают в продакшен.
Когда время изменилось, база данных начала бесконтрольно разрастаться.
Уже через два дня, достигнув пределов диска, сообщения о наблюдениях внезапно перестали приходить, и именно здесь произошло ЧП, о котором мы узнали от наших клиентов.
Было очень неприятно, был разбор полетов, лишение премий и прочие приятные вещи.
Звонок в поддержку, еще раз «Да, конечно мы знаем об этой проблеме, вот вам скрипт».
Служба поддержки не смогла дать внятного ответа на вопросы о том, когда будет патч и патч так и не вышел до следующей смены, хотя теперь мы знали и ждали проявления этой проблемы и это не разочаровало.
Попользовавшись системой некоторое время, мы начали понимать, что заказанные нами настройки, во-первых, просто не работают, а во-вторых, они просто не нужны.
Нужны другие, но вот незадача — вендора купила Dell и ценовая политика несколько изменилась.
Начальство требует, чтобы я срочно сам написал необходимые настройки.
Мысль о том, что неплохо было бы бросить, снова пришла ко мне, ведь я никогда не был программистом.
Мое сердце не принадлежит этому, вот и все.
Но русские не сдаются, верно? Я изучаю отличный сценарий, благодаря которому все это работает. В процессе обучения я понимаю, что почти половина купленного нами функционала могла бы работать лучше, если бы я просто переписал его под наши конкретные нужды.
Я переписываю и при этом перестаю говорить начальству, что ненавижу этот продукт, потому что это уже на 30% мой собственный продукт: ведь за весь период внедрения ни один инженер, кроме меня, к нему вообще не прикасался, хоть я и просил для помощи.
И вот настал заветный час - вышла новая версия, в которой, о Великий Вишну, исправлены и проблема с загрузкой многих страниц, и ненавистный баг с переходом на летнее время.
Признаюсь, я праздновал этот день.
Конец постоянным нервным тикам и походам за кофе «пока загружается страница».
Именно это событие наконец-то приблизило заветный режим технического обслуживания.
Теперь я лишь иногда по просьбе воркеров меняю пороги срабатывания оповещений и изредка пишу новые агенты, которые не имеют никакого отношения к инфраструктуре, а просто уведомляют о вполне клиентских проблемах: типа блокировки аккаунтов пользователей нашего продукта.
.
Теперь я лид и теперь точно знаю, как не надо выбирать и внедрять ПО.
Попробую изложить свои, казалось бы, очевидные выводы.
1. Нельзя купить сразу полный функционал без твёрдой уверенности в том, что он вам нужен.
Убедиться, что оно вам действительно нужно, несложно, ведь вы можете нанять консультанта, имеющего опыт работы именно с этим программным обеспечением.
Поверьте, это гораздо дешевле, чем то, что мы заплатили за картриджи, которые уже не используются.
2. Нельзя спешить.
Ничего страшного не произошло бы, если бы мы еще полгода сидели на том, что уже есть.
Несколько старых серверов всегда можно найти и никто, кроме менеджера по продажам от вендора, не заставляет платить здесь и сейчас.
3. Вам необходимо понимать специфику имеющегося персонала.
Не следует доверять анализ одному человеку, особенно если он слабо мотивирован.
4. Не стоит экономить на стоимости внедрения.
Действительно, оно того не стоит. Вендор обычно очень хочет как можно скорее вывести вас на производство, потому что именно тогда ему заплатят в полном объеме, а у консультантов тоже есть своя выгода, если все пойдет хорошо.
Если поставщик говорит, что с его персоналом на это уйдут месяцы, это означает, что, скорее всего, так и будет. Если в бюджете на это нет денег, остановитесь, ведь платить вы все равно будете, но больше.
Теги: #Сетевые технологии #ит-инфраструктура #Администрирование серверов #мониторинг
-
Авиаторговля: Новый Виток
19 Oct, 24 -
Никто Не Любит Флэша
19 Oct, 24 -
Tdd В Стиле Volkswagen
19 Oct, 24 -
Firefox 4B1
19 Oct, 24 -
Робот Имитирует Поведение Лабораторной Крысы
19 Oct, 24 -
Новка.нет, Talkstream.ru
19 Oct, 24
