Для сокращения времени простоя ИТ-систем требуются активная автоматизация, мониторинг в режиме реального времени и четкая коммуникация для обеспечения бесперебойной работы и быстрого восстановления, считают опрошенные порталом InformationWeek эксперты.

Сокращение времени простоя ИТ-систем имеет решающее значение для обеспечения бесперебойной работы бизнеса, минимизации потерь производительности и предотвращения финансового ущерба. Внедрение инструментов мониторинга, регулярного обслуживания и автоматизированных систем реагирования на инциденты позволяет организациям значительно сократить количество незапланированных простоев и время восстановления.

Чтобы улучшить взаимодействие между отделами и предотвратить простои ИТ-систем, установите четкие границы ответственности и разработайте план, направленный на устранение основных причин простоев. Не менее важно, чтобы каждая команда знала свои конкретные обязанности и то, как эффективно реализовать решения для устранения этих причин. «Важно понимать, что скорость реагирования на сбои зависит от наличия четких каналов связи и эффективного сотрудничества между операционными службами и службами безопасности», — говорит Дерек Эшмор, директор по трансформации приложений Asperitas Consulting.

По его словам, для минимизации времени простоя и поддержания устойчивости системы важны активные ИТ-практики: «Автоматизация изменений в инфраструктуре и развертывания приложений — это ключ к снижению количества человеческих ошибок».

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

Он также рекомендует регулярно проводить учения по реагированию на инциденты, такие как хаос-инжиниринг, в ходе которого устраиваются неполадки для проверки устойчивости системы.

По словам Эшмора, после инцидента следует провести анализ первопричин для их устранения или смягчения. «Доски изменений могут помочь командам прозрачно сообщать о предстоящих изменениях и выявлять зависимости», — добавляет он.

Планы реагирования на инциденты имеют решающее значение

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

Джон Гордон, президент и генеральный директор HP Managed Solutions, считает, что для предотвращения простоев ИТ-систем необходимо в первую очередь отказаться от традиционного мышления «реактивной поддержки», когда проблемы решаются только после их возникновения. «Благодаря современным инструментам искусственного интеллекта, телеметрии и проактивным инсайтам, мы можем и должны решать ИТ-проблемы проактивно, — говорит он. — Это означает постоянный мониторинг, чтобы мы могли предотвращать проблемы до того, как они получат широкое распространение».

При наличии правильных решений команды ИТ-безопасности и операционных служб должны иметь возможность отслеживать состояние своего ИТ-парка или прибегать к услугам надежного партнера, который будет управлять им за них. «Мой совет CIO — выделять ресурсы на предотвращение проблем до их возникновения», — говорит Гордон.

Показатели для измерения результатов

По словам Эшмора, концентрация на ключевых метриках успеха помогает ИТ-командам сохранять эффективность и минимизировать время простоя.

Среднее время наработки на отказ (MTBF) и среднее время восстановления (MTTR) очень важны для понимания того, как часто происходя поломки и как быстро их можно устранить.

Время реагирования на инциденты также имеет решающее значение, поскольку быстрая реакция снижает последствия сбоев, а время безотказной работы системы является основным показателем надежности. «Чем выше время безотказной работы, тем лучше», — говорит Эшмор.

Наконец, показатели удовлетворенности клиентов могут дать представление о том, как время простоя влияет на пользователей, помогая командам оценить эффективность своих усилий.

Гордон отмечает, что еще одним показателем, позволяющим оценить окупаемость инвестиций в сокращение времени простоя, является количество обращений в службу поддержки. «Если оно снижается, велика вероятность того, что вы действительно увеличиваете время бесперебойной работы сотрудников», — говорит он.

Коммуникация, инвестиции в профилактику

Стив Уотт, CIO компании Hyland, считает что коммуникация и устранение ошибок — это ключ к операционной эффективности. «Ваша группа реагирования должна с самого начала представлять собой единую команду, состоящую из специалистов по безопасности, инфраструктуре, технических и нетехнических специалистов, а также руководителей, — говорит он. — В то же время необходимо правильно подобрать размер команды, чтобы она могла работать быстро и эффективно».

Уотт добавляет, что здесь нет магического числа, поэтому размер нужно определять в расчете на создание команды, которая сможет работать как можно более независимо и быстро. «Ключевым моментом здесь является то, что команда должна быть способна работать автономно, — объясняет он. — Если для получения информации она должны согласовывать свои действия с различными заинтересованными сторонами, то вы уже проиграли битву».

По словам Уотта, важно, чтобы команды реагирования четко понимали приоритеты бизнеса и то, чем следует руководствоваться при принятии решений. Например, если произошел крупный сбой, важнее, чтобы сначала были запущены бухгалтерские системы или системы поддержки клиентов. «Понимание этих приоритетов и потоков вашего бизнеса очень важно при масштабном реагировании», — говорит он.

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

Внедрение автоматизации и искусственного интеллекта

Уотт объясняет, что раньше автоматизация больше походила на модель «если это, тогда то» (IF This Then That, IFTTT), когда у компании были жестко заданные критерии состояния ошибки, которые могли запустить автоматическое действие — например, низкий объем дискового пространства, низкий объем памяти или служба перестала отвечать на запросы. «В будущем автономные инструменты смогут абстрагировать информацию из систем и помогать диагностировать и устранять гораздо более сложные системные взаимодействия, которые могли бы потребовать вмешательства инженера», — говорит он.

Эшмор прогнозирует, что помимо автоматизации будет расширяться и станет повсеместным в ИТ использование ИИ для прогнозирования сбоев. «ИИ выйдет за рамки простых алгоритмов прогнозирования на основе машинного обучения и станет самообучающимся, что позволит нам предсказывать сбои в ситуациях, которые еще только предстоит увидеть», — говорит он.

Эшмор поясняет, что системы также будут использовать ИИ для обеспечения самовосстановления за счет автоматического восстановления, устранения неполадок, масштабирования и интеллектуального распределения рабочей нагрузки. «ИИ будет использоваться для поддержки принятия решений, автоматической генерации сводок происшествий, реагирования на инциденты и анализа первопричин», — поясняет он.