Введение
Сегодня практически все компании, которые имеют собственную ИТ-инфраструктуру: прикладные системы, сервера, сети и т.д., признают необходимость наличия отдельной системы мониторинга, которая позволит им контролировать текущее состояние их ИТ- и бизнес-сервисов и информировать о возникающих проблемах. Если у вас есть в эксплуатации хотя бы несколько серверов, то у вас уже возникает мысль о необходимости автоматизации рутинных процессов наблюдения за их работой и их поддержки.
Принимая решение о выборе или замене системы мониторинга надо учитывать, что в компании разные сотрудники ожидают от системы мониторинга решения разных стоящих перед ними проблем, в зависимости от их положения в компании. Так, на уровне руководства ожидается уменьшение времени простоя сервисов в целом и сокращение расходов на их эксплуатацию, а на уровне исполнителей — помощь в поиске неисправностей в работе сервисов и своевременное оповещение о случившихся авариях и потенциальных проблемах в инфраструктуре.
Давайте посмотрим на систему мониторинга со стороны исполнителя, на примере службы сопровождения бизнес-сервисов и их инфраструктуры — баз данных, серверов приложений, операционных систем. Примерный алгоритм действий по определению проблемы у администратора сервиса таков:
- проверить непосредственно доступность сервиса, причем, по возможности, из разных точек: «У всех не работает? Или только у части пользователей?»;
- проверить непосредственно на системе/сервере наличие ключевых процессов и количество потребляемых ими ресурсов. Сравнить с картиной, которая наблюдается, когда всё работает, чтобы найти аномалию;
- проверить наличие свободных ключевых ресурсов, которых, возможно, не хватает для работы системы под нагрузкой;
- проверить журналы системы/приложений на наличие ошибок или аномальных записей и т.п.
В результате таких действий администратор должен локализовать проблему – понять, в каком месте она возникла. Если сразу ясны причины проблемы, то как можно быстрее устранить их или исключить проблемный компонент из системы, например, переключив его на резерв. Уже потом можно начинать детально разбираться, из-за чего могла возникнуть проблема, как исключить её появление в будущем, как вернуть систему в исходное состояние без деградации сервиса.
Для реализации описанного алгоритма у администратора есть набор инструментов, который позволяет ему посмотреть результаты диагностики и сделать какие-то выводы. Инструментом может быть банальный пинг IP-адреса сервиса, который говорит администратору о недоступности сервера.
Чего же может ожидать администратор от системы мониторинга? Ответ — автоматизации своих действий, т.е. система в цикле будет запускать определенные инструменты, проверять результат их выполнения и выдавать результаты в удобном для администратора виде.
Попробуем для наглядности провести аналогию работы службы сопровождения с работой поликлиники. В поликлинике каждому пациенту назначается общий набор анализов (диспансеризация), которые пациент должен проходить с определённой периодичностью. Если результаты анализов находятся в заданных рамках, то эти результаты вкладываются в карту пациента и хранятся там в течение какого-то времени. Если же результаты анализов показывают отклонение от нормы, то далее могут быть назначены повторные анализы (для исключения случайной ошибки) или дополнительные анализы (для получения более детальной клинической картины). После этого пациент направляется на прием к врачу общей практики, который по совокупности первичного обследования пациента и результатов анализов принимает решение о направлении пациента к нужному специалисту. Если у пациента выявляются хронические заболевания, то ему дополнительно назначаются периодические специализированные анализы, касающиеся именно данных заболеваний. Также поликлиника работает по обращениям самих пациентов, т.е. после обращения пациента с жалобой на здоровье начинается цикл обследования, и так же назначается набор анализов в зависимости от типа жалобы. Ну и, если пациент особенно дорожит своим здоровьем, и ему позволяет страховка, то он может настаивать на более частом и более обширном обследовании своего здоровья .
В данной аналогии система мониторинга и есть та самая система проведения анализов. Она не ставит диагноз, не заменяет собой действия врача и, конечно, не назначает лечение. Ее задача — упростить работу врача: снять часть рутинных операций и, в итоге, позволить ему обслужить большее количество пациентов за то же время. Она не гарантирует, что будут выявлены все проблемы, так как редкие проблемы может не выявить «базовый» набор анализов, а «лечение» начинается уже после обращения пациента с жалобой, т.е. когда нарушена работа самого сервиса и его пользователей. Система мониторинга не обладает собственным интеллектом — набор ключевых параметров и допустимые диапазоны их значений вкладывают в нее люди. Так же как поликлиника сама определяет минимально необходимый набор анализов для проведения диспансеризации пациентов (например, исходя из своих финансовых возможностей), так и заказчик системы мониторинга на этапе ее создания определяет, что на его системах минимально должно отслеживаться.
В соответствии с этими требованиями он определяет, какими возможностями должна обладать его система мониторинга, чтобы выполнять заданный набор тестов. Т.е. компании нет смысла приобретать «навороченную» систему мониторинга, если для нее сейчас нет соответствующих задач. Точно так же, наиболее сложные и дорогостоящие анализы не имеет смысла проводить в лаборатории при поликлинике, их выполняют по направлению поликлиники в специализированных центрах, где есть соответствующее оборудование и специалисты. При этом результат анализов должен быть представлен языком, понятным, в первую очередь, именно врачу, а не пациенту, так как именно врач обладает необходимой компетенцией, чтобы поставить диагноз. Направляя пациента на анализ, врач ожидает получить результат по установленной для этого анализа форме.
По этой причине, возвращаясь к системе мониторинга, на начальном этапе требуется её «обучение», и это обучение делается на основе данных, которые могут быть получены от службы, сопровождающей сервис. Именно она знает, за какими параметрами необходимо следить в первую очередь, и что для сервиса критично. Некоторые современные системы мониторинга могут предварительно собрать по ключевым параметрам текущую статистику и установить в качестве нормы усредненные параметры, а отклонение от этой нормы считать аномалией, т.е. потенциальной проблемой. Но решение о том, действительно ли это реальная проблема, влияющая на работу сервиса, все равно должна принимать служба, отвечающая за работоспособность сервиса. Её решение и является «обратной связью» для службы, настраивающей и поддерживающей систему мониторинга. Наиболее опытные специалисты службы сопровождения сервиса должны поделиться своим опытом со службой сопровождения системы мониторинга, чтобы именно он лег в основу алгоритмов работы системы мониторинга. Всё точно так же, как и для собственно поддержки сервисов.
Для успешного внедрения системы мониторинга нужно ее «принятие» пользователями, т.е. администраторами. Если они будут воспринимать систему мониторинга как инструмент контроля их работы со стороны руководства, то, соответственно, будут подвергать сомнению результаты её работы, стараться избегать её использования. Чтобы этого не произошло, необходимо обучать администраторов работе с системой мониторинга, как на этапе внедрения, так и в дальнейшем, при изменении системы, информировать их о нововведениях. Нужно показать администраторам соответствие результатов работы системы мониторинга и тех инструментов, которыми они привыкли пользоваться в повседневной работе — нужно доказать им, что система показывает те же самые цифры. На этапе внедрения, пока система ещё не настроена, возможны ложные срабатывания. Каждый такой случай необходимо разбирать вместе с администраторами, чтобы избежать таких ситуаций в будущем. Если же подобные ситуации будут часто повторяться, то у пользователей может выработаться «иммунитет» на сообщения от системы мониторинга, и они могут пропустить настоящие аварии. Также имеет смысл на начальном этапе внедрения не использовать механизмы эскалации сообщений о проблемах на руководство без предварительного подтверждения со стороны администраторов.
Поддержка системы мониторинга
Система мониторинга является прикладным сервисом и должна иметь свою службу сопровождения. Неправильно поручать поддержку её работы «в нагрузку» тем же специалистам, которые занимаются поддержкой бизнес-сервисов — они ведь фактически являются пользователями, потребителями этой услуги. И без того количество задач в расчете на одного специалиста службы сопровождения увеличивается, так как со временем увеличивается количество поддерживаемых систем, количество и сложность решаемых ими задач. В этих условиях служба сопровождения будет отдавать приоритет поддержке бизнес-сервисов, а система мониторинга будет рассматриваться как еще одна вспомогательная система, не предоставляющая собственного сервиса, и её задачи будут решаться с отставанием. Как в приведенной выше аналогии — раньше доктор ходил с саквояжем по больным и сам делал все анализы, но с развитием науки и техники данный функционал выделился в отдельное направление медицины со своими специалистами, так и в ИТ функционал мониторинга стал отдельным направлением со своими особенностями и требованиями.
При выборе специалистов, которые будут сопровождать систему мониторинга, наиболее эффективным нам представляется использование администраторов, уже работавших в службе сопровождения. Они изнутри знакомы с задачами, которые должна помогать решать система мониторинга, и могут разговаривать с коллегами на «одном языке» при формулировании технических требований к системе. Другой возможный подход — если уже определен конкретный набор продуктов системы мониторинга, то набираются специалисты с опытом работы по этим продуктам. В этом случае можно ожидать более быстрого внедрения мониторинга за счет детальных знаний о реализации необходимого функционала именно на данном инструменте.
В первом случае (при использовании бывших администраторов) менее важен выбор самих инструментов мониторинга, так как все равно для администраторов потребуется начальное обучение, и в этом случае важно привлечение внешнего ресурса поддержки продукта — либо от производителя, либо от интегратора. Производитель или интегратор в данном случае будет выступать в качестве эксперта, как с помощью возможностей продукта реализовать специфические алгоритмы, использующиеся в данной компании. Также мы считаем разумным привлечение внешнего интегратора на этапе выбора продуктов для системы мониторинга.
Если сделать выбор только на основе рекламных заявлений производителя и формальных опросников по возможности реализации технических требований, то возможна ситуация, когда заявленный функционал имеется, но имеются также и нюансы, не позволяющие с его помощью решить какие-то конкретные задачи. И такие нюансы можно выявить только на этапе внедрения. Интегратор же, скорее всего, имеет опыт внедрения и поддержки систем мониторинга от различных производителей, знает их сильные и слабые стороны, может сравнить их между собой хотя бы качественно. Интегратор не имеет прямой заинтересованности в выборе конкретного продукта, и таким образом, стоит использовать накопленную им экспертизу для определения соответствия продукта сформулированным техническим требованиям.
При выборе системы мониторинга в крупной компании иногда возникает желание со стороны руководства отказаться от использования готовых продуктов мониторинга в пользу системы собственной разработки. В большой компании технические требования к системе мониторинга могут быть очень высокие и разнообразные, и для их удовлетворения могут потребоваться несколько продуктов и большое количество лицензий, что для компании выливается в крупную сумму как на этапе внедрения, так и при дальнейшей поддержке со стороны производителей готовых продуктов. Кроме того, для решения каких-то специфических задач все равно может потребоваться доработка функционала готовых продуктов, а это тоже дополнительные затраты. Поэтому при условии наличия штата разработчиков экономически выгодным нам представляется вариант разработки собственной системы «с нуля» или на основе открытых решений. В этом случае затраты на разработку, внедрение и сопровождение системы останутся внутри компании, и компания сможет контролировать их размер.
В целом всё сказанное выше верно, но, с другой стороны, надо учитывать фактор времени – любая новая разработка проходит через стадию «болезни роста», и это занимает какое-то время. Новой разработке придется пройти по тем же «граблям», на которые уже наступили другие разработчики продуктов мониторинга. К тому же, выше риск получить в итоге вообще нерабочее решение из-за отсутствия практического опыта разработки продуктов в области мониторинга или неверно сформулированных в самом начале технических требований, не позволяющих, например, выполнить необходимое масштабирование системы из-за архитектурных ограничений решения. В случае же приобретения готового продукта уже имеется база пользователей, которые используют его в масштабной инфраструктуре, и, конечно, производитель учитывает их опыт при развитии своих решений.
Заключение
При внедрении в ИТ-инфраструктуру нового сервиса или модернизации существующего, вопросы его мониторинга должны быть включены в проект наряду с вопросами сопровождения. Зачастую об этом задумываются уже после запуска сервиса в эксплуатацию. В лучшем случае, таким образом: «Мы тут запускаем сервис в «продуктив», вы там поставьте всё на мониторинг, как положено, чтобы завтра можно было смотреть, что там и как», а в худшем — таким: «А вы разве не мониторите наш новый сервис «ХХХ», его неделю назад как запустили? Не знали? Ну да, забыли вам сказать, не до этого было. Но могли бы и сами догадаться».
Компаниям следует свыкнуться с мыслью, что при внедрении любого бизнес-сервиса к стоимости его запуска и последующего TCO будет добавляться стоимость внедрения и поддержки средств мониторинга этого сервиса. Даже если это неявная стоимость, она все равно будет присутствовать в виде затраченного времени специалистов, дополнительных вычислительных ресурсов, решения возможных проблем с производительностью при наращивании системы. Хотя система мониторинга и рассчитана на внутреннего потребителя, но ее стоимость все равно должна транслироваться на те бизнес-сервисы, за которыми она наблюдает. Старый подход: «Вот сейчас мы внедрим крутую систему мониторинга, и это позволит компании сэкономить 10-20-30% на поддержке бизнес-систем» на практике работает не так, как ожидается.
Реальная ситуация ближе к следующему: «Мы сейчас потратим энную сумму на систему мониторинга, а также будем ежегодно тратить некую сумму на ее поддержку, и за это мы получаем своего рода «страховку», что мы не потеряем гораздо большую сумму из-за простоя бизнес-сервисов.» И, как у любой страховки, есть условия, при которых она выплачивается. При этом совершенно не важно, вкладываются деньги в собственную систему, в арендованный внешний сервис или в аутсорсинг. Решение о том, каким образом должна быть реализована система мониторинга, влияет на распределение затрат по времени, на формализацию услуги и т.п., но затрат не избежать в любом случае.
Даже если вы экономите, выбирая свободно распространяемую систему мониторинга, вы все равно потратите деньги на ее внедрение и адаптацию к своим задачам или будете тратить больше времени на её поддержку. Чем выше оцениваются возможные потери от простоя бизнес-сервисов, тем выше будут требования к услуге мониторинга и, соответственно, выше затраты на неё. И так же, как и со страховкой — проблема может и не случиться, а деньги, затраченные на мониторинг, не вернутся. Система мониторинга – это необходимая плата за минимизацию рисков.