Ни для кого не секрет, что сегодня практически все аспекты работы крупного, среднего и даже совсем небольшого предприятия критически зависят от его корпоративной информационной системы (КИС). Её отказы и сбои оборачиваются всё большими финансовыми и репутационными издержками. Для разных отраслей характер и размеры убытков могут быть разными, иногда оценить их относительно просто (как в случае сорвавшейся сделки или простоя точки продаж по причине нарушения работы касс), иногда очень сложно (как в случае упущенного окна возможностей на меняющемся рынке или выпадения предприятия из перспективного развивающегося отраслевого, проектного или территориального кластера). Но общая тенденция налицо: риски, связанные с плохой работой ИТ-систем, уже сейчас велики и будут только повышаться — в связи с совокупным действием множества тенденций. При этом и на рынке, и внутри большинства российских компаний, и в самих ИС постоянно идут изменения. Как же бизнесу следует организовывать обработку данных о состоянии ИС в новых условиях? Кто и как должен принимать решения о том или ином воздействии на них? Что лучше - создавать диспетчерские центры или полностью автоматизировать/роботизировать процесс обработки поступающих данных? На эти вопросы в своей статье для GlobalCIO - сообщества российских ИТ-директоров, отвечает Светлана Гацакова - директор департамента КИС ALP Group.
Следующий (неполный) перечень трендов, влияющих и на рынок, и на компании, и, соответственно, на сами ИТ-системы, по мнению Светланы, дает представление о масштабе и глубине происходящих изменений:
- предстоящая цифровизация экономики и модернизация производственного оборудования и технологий производства;
- всё большая простота переключения на альтернативных поставщиков товаров и услуг;
- углубляющаяся интеграция предприятий, входящих в деловые сети и кластеры разных типов (проектные, территориальные, отраслевые, корпоративные), что позволяет им снижать издержки и риски, расширять практику аутсорсинга, повышать гибкость;
- усиливающееся регулирование отраслей ИТ и ИБ;
- придание юридической значимости все большему набору сценариев применения ИТ-систем;
- внедрение новых методов менеджмента, опирающихся на анализ объективных данных (data-driven management, или ddm);
- постепенное расширение практики управления ресурсами предприятия (включая производство) в режиме реального времени;
- усложнение информационных систем, появления в них новых элементов — как на уровне ИТ-инфраструктуры, так и на уровне бизнес-систем;
- появление в ландшафте ИС российского ПО и программных продуктов и информационных технологий, развиваемых международным сообществом Open Source (работа с таким ПО имеет глубокие особенности, особые сложности создает и совместная эксплуатация замещаемого и замещающего ПО).
Качественно изменившаяся роль и усложнение информационных систем в бизнесе и госуправлении вступили в противоречие с сохраняющимися старыми практиками управления ими. И это уже создает массу проблем. Требуется устранить этот разрыв, а для этого — вывести на совершенно новый уровень управление ИТ-системами, которые существенно влияют на основную деятельность предприятий, их адаптивность и способность меняться — быстро, практически постоянно и без создания коллапсов.
В указанной статье много внимания уделено системам ИТ-мониторинга как технологическому фундаменту всей новой системы управления корпоративными ИС. Безусловно, функция мониторинга важна, т.к. отвечает за сбор огромного объема объективных данных о работе оборудования, системного, инфраструктурного и прикладного ПО. Большой практический интерес представляет совместное использование низкоуровневых универсальных систем ИТ-мониторинга и близких по назначению инструментов, встроенных в различные технологические платформы (особенно, в платформу 1С:Предприятие). Это существенно обогащает картину состояния ИС, например, за счет наложения на информацию о потреблении ресурсов (полученную из универсальной системы мониторинга) данных о фактической длительности тех или иных действий пользователей (в соответствии со стандартом APDEX), которые выполнялись в тот же момент. Мы еще вернемся к этой теме в следующих колонках, а сейчас я хочу привлечь внимание к более фундаментальному вопросу.
Два пути
Предположим, предприятие выбрало и запустило систему мониторинга (или какой-то иной механизм сбора и консолидации данных о критически важных бизнес-приложениях и ИТ-инфраструктуре). Данные появились в изобилии, но что теперь с ними делать, как организовать их обработку, кто и как должен принимать решения о том или ином воздействии на ИС?
Принципиально возможны два совершенно разных пути. Первый — это создание диспетчерского центра (ДЦ) или сети таких центров, где специально натренированные операторы будут непрерывно следить за индикаторами, характеризующими состояние информационной системы и ее элементов. Они самостоятельно принимают решения на основе инструкций и своих знаний или привлекают каких-либо специалистов (если на это есть время).
Второй путь предполагает полную автоматизацию и роботизацию процесса обработки поступающих данных, рекомендации или даже выполнения корректирующих воздействий на контролируемую ИС.
Казалось бы, первый подход выигрывает по всем статьям, ведь именно он десятилетиями успешно применяется для управления сложнейшими техническими системами: электростанциями, транспортом, сложным производственным оборудованием и т.д. Причем, большинство таких объектов потенциально опасны: выйдя из под контроля, они могут наделать немало бед. Более того, распространению ДЦ в корпоративной среде способствует появление продуктов, позволяющих создавать ДЦ меньшего масштаба, например, для управления современными зданиями. Естественно, это гораздо более бюджетные решения. Они доступны даже среднему бизнесу, малые же предприятия могли бы пользоваться SaaS-сервисами. И, наконец, главная особенность диспетчерских центров: решения в них принимают люди, в той или иной степени понимающие закономерности работы контролируемой системы, логику связи показателей, возможные сценарии развития событий. И это зачастую позволяет им своевременно принимать даже такие решения, для которых поступающие данные не дают бесспорного и однозначного основания.
На этом фоне второй подход кажется крайне ограниченным. Ведь здесь проводится лишь примитивный по своей сути анализ данных и принимаются достаточно простые решения, в которых нет ничего нетривиального.
Кажется, выбор ясен. Однако картина меняется, стоит внимательнее присмотреться к обоим подходам. Я ограничусь лишь несколькими моментами, которые считаю наиболее важными.
Картина меняется, если присмотреться к деталям
Начнем с первого пути:
Во-первых, ДЦ хорошо справляются со своими задачами только для полностью контролируемых, тщательно спроектированных и протестированных систем, в конструкцию которых не могут вноситься частые (тем более, постоянные!) изменения. Сравните это с технологией SCRUM, где продуктивная ИС обновляется практически постоянно — без возможности предварительно оценить последствия каждого обновления. Но и без всякого Agile и DevOps ясно, что неопределенность и изменчивость ландшафта современных и будущих ИТ-систем несопоставима с жизненным циклом и практикой развития классических объектов управления с помощью ДЦ.
Во-вторых, ДЦ создаются для слежения за техническими объектами, конструкция и работа которых основаны на проверенных научных теориях, моделях поведения, наборах нештатных ситуаций, сценариях развития событий.
Это позволяет обоснованно выбрать наборы показателей и зоны риска для них, заранее выявить ситуации, когда автоматика должна задействовать экстренные сценарии предотвращения аварий и техногенных катастроф. Ясно, что корпоративные информационные системы совершенно не соответствуют этой картине. Теоретических основ нет, показатели выбираются достаточно общие (загрузка процессоров, занятая память, интенсивность ввода-вывода данных, число пользователей, длительность выполнения важных операций — последнее лишь при использовании APDEX). Влияние систем друг на друга может быть чрезвычайно многогранным, а комплексные показатели вводятся достаточно произвольно, как и границы «зеленых», «желтых» и «красных» зон для них. Когда информационная система начинает вести себя странно, требуется настоящий «мозговой штурм» с привлечением множества сильных специалистов разного профиля. Без этого просто невозможно понять причины происходящего и изменить траекторию развития событий в нужную сторону. Что в этих условиях может сделать диспетчер?
В-третьих, персонал для работы в диспетчерских центрах отбирают в соответствии с четкими критериями (например, способностью долгое время следить за приборами, не ослабляя внимания, а в случае чего — мгновенно собраться и, не впадая в панику, с холодной головой действовать на основании инструкций и понимания ситуации). При этом диспетчер осознает исключительную важность своей роли, что позволяет ему работать, даже если возникает угроза его жизни. Отбор, обучение и контроль этих людей — дорогой и сложный процесс, опирающийся на тщательно проработанные методики, не раз проверенные и в эксперименте, и на практике. Ничего этого для ИТ-систем нет, и большинству компаний просто не по силам создать и поддерживать полную инфраструктуру подготовки диспетчеров. И дело здесь не только в кадровом голоде или масштабах затрат. Гораздо важнее отсутствие методической проработки и нестыковка с корпоративной культурой.
Второй путь набирает очки
Теперь посмотрим на альтернативный путь.
Здесь цель иная. Автоматизированная система контроля должна убрать «человека с красными глазами» от мониторов и видеостен, заменив его на ИТ-систему, не подверженную никаким проявлениям «человеческого фактора» и способную следить за корпоративной ИС, перерабатывать огромные объемы поступающих данных, выявлять в них отклонения и на основе заданных алгоритмов решать, реагировать ли на них автоматически (тем или иным способом) или запустить бизнес-процесс с участием нужных людей и следить соблюдением его регламента и за изменениями, происходящими в ИС на основе принятых специалистами решений. При неблагоприятном развитии событий (которое заметно по динамике регистрируемых параметров или прогнозируется по матрицам вероятности дальнейших событий) автоматизированная система контроля может вернуть себе управление и выполнить экстренные действия.
Конечно, такая автоматизированная система не обладает столь же глубокими знаниями о контролируемой ИС, как профильные специалисты. Она не способна (по крайней мере, на современном уровне развития искусственного интеллекта) к принятию творческих решений. Но на ее стороне есть немало преимуществ, перевешивающих эти ограничения:
- защищенность от всех проявлений человеческого фактора, в частности, безошибочность, неутомимость и неослабность внимания;
- возможность в режиме реального времени перерабатывать весь массив поступающих данных и использовать при его анализе и интерпретации результатов архив ранее накопленных первичных данных и принятых по ним решений, чтобы обнаружить аналогии и применить лучшие решения к новой ситуации, а также защититься от повторения ошибок;
- способность опираться на прошлый опыт, а не на произвольно заданные границы зеленых, желтых и красных областей для отдельных показателей;
- способность системы контроля к эффективному самообучению и отсутствие риска потери приобретенных знаний;
- повышение доли предложенных или автоматически примененных системой контроля корректирующих действий, селекция удачных воздействий;
- простота масштабирования (по числу показателей и количеству контролируемых ИС), а также модификации алгоритмов.
Технологической основой для таких автоматизированных систем контроля служат три кита: Big Data, Machine Learning и Process Mining. Технологии обработки «больших данных» позволяют управиться с накоплением и анализом информации о состоянии оборудования, работе сервисов, активности пользователей. И о том, к чему это приводило в прошлом. На этой основе, в частности, можно формировать и корректировать матрицы вероятностей дальнейших событий. Process Mining позволяет анализировать, какие еще совокупности событий могут произойти и к чему это может привести.
А технологии «слабого ИИ» нужны, чтобы понять, на какой прошлый опыт мы можем опереться, реагируя на возникшую ситуацию. Так, ML выявляет, что по совокупности характеристик новая ситуация очень похожа на какие-то определенные ситуации в прошлом. Тогда на них реагировали определенным образом, что приводило к успеху. И теперь есть основания поступить сходно. При этом речь не идет о точных совпадениях, ИИ обеспечивает достаточную гибкость. Естественно, фактический результат каждого такого воздействия анализируется. Если действие вновь привело к успеху, шансы его повторения в похожей ситуации возрастают, а если ситуация ухудшилась, поиск решения продолжается, а использованное корректирующее действие помечается как неудачное, что позволяет в дальнейшем проанализировать этот опыт. И всё это делается очень быстро — с недоступной для людей скоростью.
Отмечу, что все указанные технологии — достаточно зрелые и доступные, а их совместное применение даёт синергический эффект. В итоге, степень автоматизации и качество корректирующих воздействий, рекомендованных или выполненных самой автоматизированной системой контроля ИС, нарастают во времени — по мере накопления архива данных и самообучения системы контроля.
Как видим, именно второй путь ведет к созданию систем контроля ИС, не страдающих из-за их кардинальных отличий от классических технических объектов, для управления которыми по-прежнему идеально подходят диспетчерские центры.
Заключение
Полное противопоставление рассмотренных двух подходов к контролю за информационными системами оправдано, когда мы пытаемся сравнить их, чтобы понять сильные и слабые стороны. И на этой основе выбрать главные направления и приоритеты в развитии контуров контроля какой-либо реальной ИС.
В реальной жизни вполне может быть, что для какой-либо обособленной и исключительно важной части своей ИС организация сделает основной упор именно на создании диспетчерского центра и соответствующей службы — с полным пониманием рисков, издержек и ограничений этого подхода. Например, это может быть уместно для контроля за самой системой контроля за другими частями корпоративной ИС. Однако, по отношению к бизнес-системам (ERP, CRM, BPM и мн. др.), которые сегодня должны быть максимально интегрированы, адаптивны и изменчивы, такой выбор может быть оправдан лишь в исключительных случаях (при этом на уровне MES и АСУ ТП ситуация может в корне отличаться.)
Однако принципы построения ДЦ могут быть с пользой применены при построении фронтэнда к роботизированной системе контроля. Количество графиков и отдельных показателей, за которыми может следить человек, эффективные способы визуализации данных разного типа и привлечения внимания к нештатным ситуациям, организация работы диспетчеров, борьба с монотонностью, принятие решений, по которым в группе диспетчеров нет согласия, правила обращения к специалистам и передачи им информации… — всё это темы, где не надо изобретать велосипед. Кроме того, надо учитывать, что роботизация контроля ИС требует предварительного накопления больших объемов данных, а также сценариев реагирования на них в прошлом, которые оказались эффективными или ошибочными. Первоначально эти решения принимаются специалистами. И лишь со временем становятся паттернами, которые искусственный интеллект (например, обученная нейронная сеть) должен распознавать в поступающем потоке данных.
Иными словами, на протяжении жизненного цикла системы контроля роль различных подходов и технологий меняется. Создавать такие системы пока очень трудно, т.к. для этого нужно редкое сочетание компетенций. Думаю, сегодня лучше привлекать к этому ИТ-компании, для которых и эта деятельность, и вообще применение технологий, на которые опирается роботизированная система контроля ИС, входит в число основных специализаций. Желательно, чтобы такая ИТ-компания уже обладала серьезными собственными наработками и «ноу-хау» в таких областях, как применение APDEX к ПО и процессам, построение матриц вероятности дальнейших событий, ddm (применительно к контурам контроля за ИС) и тонкий анализ выявленных отклонений от нормы, работа с метаданными для извлечения нужной информации из архива, роботизация процессов, управление жизненным циклом систем контроля и др. Всё это очень непростые темы.
Но, несмотря на все эти сложности, иного пути у предприятий сегодня уже нет. Риски дальнейшего увеличения разрыва между уровнями развития ИС и системами управления ими слишком велики.
Автор: Гацакова Светлана Владимировна, директор департамента корпоративных информационных систем ALP Group.
Источник: Global CIO
Дата публикации: сентябрь 2018
