«Послушаем, пощупаем, понюхаем…» – примерно так в фильме «Берегись автомобиля» отвечал автомеханик-умелец на жалобы владельца новенькой неправедно нажитой «Волги». На ранних этапах развития все сложные технические системы – будь то трактор, станок или самолет – требуют для своей работы мастеров, которые буквально чувствуют «подопечного» и по каким-то только им понятным сигналам могут определить, что с ним не так. Но по мере роста сложности, стоимости и мощности технических систем, а также рисков, возникающих при нарушении их работы, технология управления полностью меняется. Системы обрастают индикаторами состояния, контурами обратной связи, и в итоге мы видим диспетчерский центр, в мельчайших деталях информирующий о том, как работает система. Он привлекает внимание к тем параметрам, которые входят в зону риска, предоставляет инструменты разностороннего воздействия на контролируемую систему, а порой и автоматически предпринимает корректирующие действия. На смену интуитивным догадкам приходит управление на основе объективных данных, автоматизация и роботизация.
Удивительно, но информационные системы организаций, несмотря на свою изначально компьютерную и кибернетическую природу, с точки зрения способа управления все еще пребывают на ранних этапах развития. Сегодня ИТ-персонал в большинстве случаев лишь реагирует на те или иные проблемы или аварийные ситуации: отказы в обслуживании, снижение производительности, неожиданные задержки с поступлением необходимых данных и т.д. Не имея точных показателей развития ситуации, ИТ-специалисты по-прежнему «слушают, щупают, нюхают», чтобы как можно скорее восстановить работу системы. Но чем сложнее система, чем быстрее она меняется, чем больше в ней появляется незнакомых элементов (например, российского и открытого ПО), тем менее эффективен этот способ, тем чаще он дает сбой.
Разумеется, от самих инцидентов и от такого способа реагирования на них страдают бизнес-подразделения. А из-за того что буквально любой аспект работы современного предприятия полностью зависит от компьютерных систем, ущерб при сбоях в ИТ становится сопоставим с масштабом рисков, угрожающих основной деятельности и репутации организации.
Итог известен: ИТ-службы хронически загружены, а бизнес-подразделения хронически недовольны. Преодолеть эту крайне болезненную ситуацию не помогает ни обучение, ни штрафы, ни даже увольнения. Эффекта или совсем нет, или он быстро пропадает. Истинная причина осознается топ-менеджерами и руководителями ИТ-служб далеко не всегда. А дело в том, что привычная схема слежения за «здоровьем» современных информационных систем уже не справляется с тем уровнем сложности, которого они достигли.
Пришло время полномасштабного перехода к управлению важными ИТ-системами на основе объективных данных. Задача эта весьма сложная, но для начала уточним, что же стоит за «здоровьем» информационной системы.
Чем «болеют» информационные системы?
Определить понятие нормы для информационной системы не так сложно, как для природной. Норма – это соответствие системы требованиям, сформулированным при ее создании или добавленным на более поздних этапах жизненного цикла. А «болезнь» – это нарушение одного или нескольких таких требований. Болезнь тем тяжелее, чем существеннее нарушенные требования, чем их больше и чем сильнее реальные характеристики отклоняются от приемлемых, то есть выходят из «зеленой зоны».
Мы рассматриваем жизнеспособные ИС, которые одно время хорошо работали (находились в норме), а потом что-то пошло не так. В подобной ситуации нарушения требований (ошибки) можно отнести к одной из следующих категорий: функциональные, технические, касающиеся доступности и производительности, информационной безопасности, а также отсутствие гибкости и оперативности при внесении изменений.
Прежде чем рассмотреть эти ошибки детальнее, надо отметить, что выявление ошибок и проверка факта их устранения (не по принципу «послушаем, пощупаем, понюхаем», а на основе объективных данных) опираются на функцию мониторинга системы, для реализации которой существует не только множество разных программных продуктов, но и принципиально разные подходы к самой организации мониторинга.
Хорошая современная система мониторинга непрерывно и автоматически получает, консолидирует и доставляет в аналитический центр, а также визуализирует информацию о множестве характеристик ИТ-объектов – серверов, рабочих станций, файловых систем, СУБД, прикладных программ, пользователей. Первичные данные поступают непосредственно из различных элементов системы, а значит, по определению точны (вероятность ошибок в модулях сопряжения очень мала, поскольку такие модули просты и применяются во множестве организаций). Принципиальных технических ограничений на количество параметров и число объектов мониторинга практически нет, а все фазы сбора и обработки могут происходить очень быстро – вплоть до режима реального времени. Ограничивающим фактором обычно является способность ИТ-службы осмыслить полученную информацию.
1. Нарушения функциональных требований и технические ошибки
С функциональными требованиями, казалось бы, все просто – ведь они описывают предполагаемое поведение системы, ее способность решать определенный круг задач. Но есть нюансы. Пусть, например, требуется вести учет кассовых операций. Как в любом процессе, не обходится без ошибок. И здесь важно различать те ошибки, которые не выдают никакого оповещения, и те, из-за которых происходит оповещение пользователя о нештатной ситуации.
Ошибку первого типа можно выявить только по искажению данных, по неверным результатам расчетов – по параметрам, заметить которые могут только бизнес-подразделения, но не ИТ-специалисты. Исправить такую ошибку можно только посредством изменения кода или содержательных настроек программы: повторной разработки, тестирования и внедрения. И здесь архив данных мониторинга иногда способен сильно помочь, так как помогает понять, нет ли связи между возникновением ошибки и тем, что происходит с системой.
Ошибки второго типа (технические) прерывают нормальное поведение системы, но она при этом сообщает о причине и предоставляет дополнительную информацию. Например, некорректно сформирован запрос к системе или клиент не получил ответ за отведенное время. На такую ошибку ИТ-службам надо реагировать быстро, так как, с точки зрения пользователя, причина понятна (хотя это и не всегда так), а значит, ее легко устранить (а это часто совсем не так). Если такие ошибки имеют место, необходимо сразу узнавать о них, не дожидаясь, пока к недоумению пострадавшего пользователя добавятся масштабные следствия: снизится производительность системы и зависящих от нее подразделений, нарушится их работа, а возможно – и работа предприятия. Здесь, так же как и при ошибках первого типа, ценно понимание связи между фактом возникновения ошибки и тем, что происходит с системой.
2. Доступность и производительность
Требования к производительности в совокупности должны гарантировать, что будет достигнут запланированный при внедрении рост эффективности работы сотрудников. Например, время на заведение в системе приходного кассового ордера снизится с десяти до одной минуты. И если по факту эта операция стала занимать более пяти минут, то это не успех, а выход в «красную зону». Ведь ожидания не оправданы – сотрудник просто не успевает выполнять работу, которая отводится ему после внедрения приложения и которая закладывается в KPI. Более того, страдает не один сотрудник, а все, кто выполняют данную операцию. А значит, падает производительность отдела, департамента, а то и всей компании. Если меры своевременно не принимаются, то найти источник проблемы очень сложно. И делается вывод, что внедренная система неэффективна.
Чтобы исключить подобную ситуацию, система мониторинга должна постоянно отслеживать время выполнения операций, оценивать среднее время выполнения операций и сверять его с эталонными значениями. Если выявлено достаточно сильное отклонение – это важный сигнал: «Что-то не так, это очень подозрительно!» Рост средней длительности операции говорит о снижении производительности; желательно еще до усугубления ситуации найти причину, понять, как с ней бороться, и принять меры по восстановлению производительности.
Но, даже если средняя длительность не возросла, а уменьшилась, это тоже повод поволноваться! Почему система вдруг стала работать быстрее – может быть, перестали выполняться какие-то важные функции?
Крайний случай – полная недоступность системы, когда она не отвечает ни на один запрос пользователей. Сегодня это означает, что сотрудник полностью лишен возможности выполнить свои должностные обязанности. Блокирование одного звена легко может привести к каскадной остановке многих (а то и всех) процессов предприятия, что неотвратимо ведет к финансовым и репутационным потерям.
Даже если нарушение требования доступности не приведет к полной остановке деятельности, оно очень сильно снизит производительность. Если сотрудник не сможет выполнить операцию с первого, второго, третьего раза, но в какой-то момент ему все-таки повезет, это будет означать, что он потратил гораздо больше времени на выполнение своей функциональной обязанности.
Наличие системы мониторинга помогает своевременно выявить ошибку и не допустить ее разрастания в большую проблему. Более того, постоянный мониторинг позволяет идентифицировать момент, когда появилась ошибка, у кого и при каких условиях. Эта информация исключительно важна для расследования и оперативного устранения ошибки. Располагая архивом мониторинга и достаточно мощными аналитическими инструментами, нетрудно выяснить, единичная ли это ошибка или регулярная, страдают ли от нее отдельные пользователи или она имеет массовый характер.
А высокая оперативность получения, аналитической обработки и осмысления информации об ошибке позволяет, не оттягивая время, идти на проблему. Получив информацию о первой ошибке, специалист службы эксплуатации может самостоятельно связаться с пользователем и выяснить обстоятельства, а иногда и сразу понять причину ошибки, помочь с решением до того, как пользователь потеряет терпение.
3. Информационная безопасность
Требования по безопасности – это, конечно, особая тема. Но и при выявлении и расследовании инцидентов ИБ данные мониторинга, охватывающие всю систему, могут оказаться полезным дополнениям к специфическим инструментам, с которыми работают ИБ-специалисты. А иногда даже одним из главных инструментов. Особенно в ситуации, когда злоумышленник, выдав себя за легитимного пользователя, стал фактически невидим для средств защиты. Важно также знать, кто подключался, когда и откуда. Если эта информация собирается регулярно, то можно, например, оперативно выявлять попытки подбора пароля с целью несанкционированного проникновения в систему. А если знать, откуда обычно подключается определенный пользователь, какова нормальная последовательность его действий, то попытка подключения с другого ресурса или нарушение этой последовательности могут послужить сигналом для проверки.
4. Отсутствие гибкого и оперативного внесения изменений
Все чаще дальновидные заказчики предъявляют требования к гибкости и оперативности внесения изменений. Это и понятно: системы меняются все быстрее, изменения происходят постоянно, и если каждое изменение требует очень долгой подготовки или тянет за собой длинный шлейф тестирования и других технических работ, то бизнес-подразделениям приходится ждать результатов неприемлемо долго. Поэтому максимально быстрое получение результатов изменений системы, ее быстрая адаптация под меняющиеся потребности пользователя стали необходимостью.
Но есть и объективные технологические ограничения, многое зависит от платформы и реализации. Чтобы воплотить новое требование, иногда достаточно только настроить систему – это идеальный вариант. Но порой требуется ее серьезная доработка. Доработка создает не только ожидаемые, но и побочные изменения. И если первые эффективны и направлены на достижение результата, то побочных эффектов обычно никто не ждет и не просчитывает. Иногда это просто ошибки, и очень нехорошо, когда любые ошибки при изменениях выявляются на продуктивной среде, где размещены основные рабочие базы.
Необходимо стараться выявить и устранить эти ошибки на этапах разработки и тестирования, а для этого процессы тестирования должны быть выстроены соответствующим образом. Например, при использовании подхода Agile сокращается не только время между появлениями новых версий, но и объем вносимых в каждую версию изменений. Это упрощает как разработку и тестирование, так и формирование обратной связи между тестировщиками и разработчиками, а также между службой эксплуатации и разработчиками (последнее – при использовании подхода DevOps).
В любом случае перед выпуском изменений, касающихся продуктивной системы, необходимо убедиться в том, что они не повлекут за собой негативных последствий: система не перестанет работать, существенно не снизится ее производительность, не отключатся отдельные функции. Естественно, все изменения необходимо тестировать на отдельном контуре, а не на рабочей базе. И без системы мониторинга, объективного контроля здесь не обойтись, ведь он позволяет отследить поведение системы на тестовом контуре, выявить несоответствия, спрогнозировать поведение системы после распространения изменений на продуктивный контур и после переноса изменений на рабочую базу. Система мониторинга собирает показатели «здоровья» системы непрерывно. А это позволяет сразу по многим показателям сравнить состояния до и после обновления, выявить отклонения и принять соответствующие меры.
Подняться на новый уровень
Мониторинг информационных систем – пока недооцененная технология, достойная самого пристального внимания. Приведенные примеры показывают, что при переходе к управлению состоянием системы на основе объективных данных ИТ-подразделения сталкиваются с задачами, родственными тем, с которыми имеют дело современные управленцы, внедряющие отдельные практики и целые системы менеджмента на основе анализа данных (data-driven management, DDM).
При этом ИТ-подразделения находятся в более выгодном положении. Во-первых, у них есть (по крайней мере, должны быть) достаточно четкие требования к работе систем, что позволяет определить набор показателей для мониторинга, ввести метрики для отдельных показателей и их сочетаний (как минимум «зеленая», «желтая» и «красная» зоны). Во-вторых, у них есть достаточно широкий выбор систем мониторинга, существенно различающихся не только функциональными возможностями, но даже принципиальными подходами к самому мониторингу. В-третьих, организовать и автоматизировать сбор первичных данных об информационной системе, как правило, существенно проще, чем об организации. Наконец, у ИТ-службы имеется положительный опыт создания методики измерения пользовательской удовлетворенности ИТ-решениями (APDEX) и ее принятия участниками ИТ-рынка в качестве фактического стандарта, на который опираются и заказчики, и исполнители проектов. Однако APDEX – это пока, скорее, ориентир для оценки других аспектов работы систем, где подобные методики еще только предстоит создать.
Это значит, что ИТ-департаменты должны и действительно могут подняться на новый уровень управления и быстрее, чем бизнес-подразделения, перейти к управлению на основе объективных данных. И тогда ИТ-службы могут стать понятнее и интереснее для топ-менеджеров и владельцев предприятий.
Разумеется, на эффективный мониторинг в ИТ, способный решить вышеперечисленные задачи, должно быть нацелено не только ПО, но и служба эксплуатации, которая в эпоху DDM должна работать иначе, чем прежде. Да и не всякие информационные системы полностью готовы к новой роли на современном предприятии. Важна также методическая составляющая – например, эксперименты, расширяющие воздействие на объект мониторинга за рамки типичных сценариев использования. Без этого невозможно аккуратно оценить поведение инфраструктурного и прикладного ПО перед масштабными изменениями в организации (включая внедрение новых методик менеджмента или, скажем, переход на незнакомое российское ПО в проектах импортозамещения). Однако все перечисленное нисколько не умаляет роли мониторинга и основанных на нем инструментов в информационных системах ближайшего ИТ-будущего. Система мониторинга – это не прихоть и не баловство. Это необходимость.
– Александр Жданюк, руководитель практики информационных технологий и корпоративных сервисов поддержки ALP Group, aleksandr.zhdanyuk@alp.ru