До запуска прикладной системы дефекты и скрытые опасности можно значительно уменьшить с помощью интенсивного тестирования, но поскольку среда симуляции теста не может быть точно такой же, как реальная после запуска системы, тестовая работа не может охватить все сценарии производства и работы ИТ-прикладной системы, и сложно избежать возникновения сбоев ИТ-прикладной системы в конкретном сценарии.
Поскольку скрытая опасность неудачи неизбежна, очень важно уметь справляться с неисправностью спокойно! Лучше знать заранее, предсказывать возможные проблемы IT-системы и принимать меры, когда проблема не возникает, чтобы устранить неисправность на зародыше. Как бы ни было тяжело, мы должны как можно скорее знать, какие проблемы возникли в системе и где они возникли, и решать их вовремя до их распространения, чтобы избежать эскалации ситуации. На самом деле, поскольку эти два момента всё ещё сложно реализовать, нагрузка на эксплуатацию и обслуживание беспрецедентна!
Если посмотреть на современные предприятия с высоким уровнем информационной конструкции, представленной банками, развитие бизнеса становится всё более зависимым от ИТ, сложность их ИТ-приложений растёт и выше, а управляемость — всё хуже. Но головная боль в том, что в столь интенсивной ситуации погони и перехвата системы всё равно случаются, риски повторяются снова и снова, и часто мелкие проблемы в итоге перерастают в серьёзные сбои, в чём причина? Почему всегда есть задержка в открытии? Почему различные методы мониторинга не могут выявить аномалии с первого раза? Необходимо разобрать это.
По основным аспектам компьютерная комната делится на две категории: базовые ресурсы и ИТ-прикладные системы. Долгое время мы придавали большое значение базовым ресурсам, таким как сеть, хост, хранилища, температура и влажность компьютерной комнаты, а методы мониторинга можно назвать «вооружёнными до зубов».
Для мониторинга ИТ-прикладных систем в настоящее время отечественные и зарубежные производители и поставщики услуг предоставляют множество продуктов или решений, содержание мониторинга имеет собственную направленность: комплексный анализ, их практика в основном заключается в мониторинге производительности ИТ-прикладной системы на базовом уровне ресурсов через сетевой трафик, производительность системы, загруженность процессора, заполнение памяти, доступ к базе данных, состояние промежуточного ПО и другие индикаторы, в сочетании с анализом журналов, исследованием зондов, доступом к симуляции и извлечением прокси, а также другими методами получения определённой информации о работе системы. Если примерно оценить общее состояние работы системы, эти продукты или решения не имеют постоянного отслеживания и мониторинга деталей работы системы, поэтому они не могут понять детали состояния работы каждого модуля в ИТ-приложении и даже функциональных точек модуля; эти детали включают: Какие транзакции обрабатывает система? Что сработало? Что проблематично? Кто инициирует транзакцию? Когда он будет запущен? Чем вы занимаетесь? Какой модуль системы задействован? Какая функциональная точка отвечает за обработку? Во сколько возвращается ответ? Есть ли какие-то аномалии в производительности? Если это не удаётся, в чём же вина? Они очень важны для оценки операционного состояния ИТ-системы заявок.
На практике, в начале сбоя ИТ-прикладной системы, когда точка отказа мало влияет на базовые ресурсы или ещё не была передана на базовый уровень ресурсов, либо сбой возникает в промежутке между использованием журналов, зондов, прокси и других средств, хотя риск системы был «скрытым», но часто существующие методы мониторинга не могут сыграть роль, а внешнее представление также означает «отсутствие аномалии». Это также основная причина, почему обнаружение неисправностей отстаёт и с этим сложно справляться! Видно, что своевременное выявление сбоев системы «в первый раз» является недостатком текущих ИТ-эксплуатационных и технических работ, и имеет большое значение для компенсации эксплуатации и обслуживания ИТ.
Что такое «первый раз»? То есть в процессе реагирования ИТ-прикладной системы на запросы доступа, в момент сбоя или аномального произошедшего транзакции она должна быть точно зафиксирована! Всем известно, что раннее обнаружение можно решить вовремя, и чтобы обратить текущую пассивную ситуацию в ИТ-работе и компенсировать недостатки работы и обслуживания, необходимо технически решить проблему обнаружения сбоев системы «с первого раза». Благодаря сравнительным исследованиям и практике работы большого числа ИТ-прикладных систем эта идея технически осуществима, но сотрудники бюро могут подвергаться влиянию инерциального мышления, не выходить из исходного мышления и даже думать, что это невозможно в субъективном сознании, что не приведёт к существенному прорыву в этом аспекте работы, а операционные риски ИТ-приложений всегда находятся в пассивной ситуации фрагментарного ответа.
Ключ к «первому» обнаружению сбоев системы — быть «внимательным» к ИТ-прикладной системе, овладевать каждым её движением, а именно проводить глубокое наблюдение за деталями работы ИТ-прикладной системы и подвергать строгий контроль за работой каждого модуля и функциональной точки, при этом этот мониторинг должен быть непрерывным и непрерывным, только таким образом не упускать ни одной аномалии системных транзакций, чтобы работа ИТ-прикладной системы находилась в контролируемом состоянии.
Поскольку этот процесс может получать и накапливать подробную информацию о состоянии работы системы, создавать очень ценный файл операций системы, благодаря своему анализу и использованию, он не только служит ориентиром для оценки качества каждого модуля и каждой функциональной точки, но и базой для анализа развития и изменения рабочего статуса системы, что позволяет предсказывать тенденцию состояния ИТ-прикладной системы.
|
Опубликовано 13.10.2014 10:36:01
|
|
|
