ALP Group

Уже больше года мы видим явное подтверждение того, что призыв «сверху» к цифровой трансформации экономики накладывается на взрывную тенденцию по созданию собственного ПО, идущую «снизу». Более половины компаний из ретейла, медицины и финансового сектора стали в три раза чаще, чем год назад, запускать микропроекты по цифровой трансформации, основанные на непрерывной адаптивной внутренней разработке ПО, организованной по принципам (а зачастую и методикам) Agile и DevOps.

Особенность такого ПО – глубокое отражение отраслевой специфики, насыщенность собственными ноу-хау компании и прямая связь между функциями приложений и конкурентными преимуществами компании. Кроме того, идут постоянные эксперименты: если компания верит в какую-то новую идею, но новые «фишки» не сработали, их тут же переделывают (иногда не по одному разу), добиваясь в конце концов задуманного результата.

Это принципиально отличается от стандартной практики неторопливого создания универсального корпоративного ПО, которое при каждом внедрении должны подолгу настраивать консультанты и которое развивается в направлении, на которое компания не может даже влиять, не говоря уже о том, чтобы его контролировать. Например, сети медицинских лабораторий начали активно дорабатывать личные кабинеты, добавляя нужные пациентам онлайн-сервисы. Торговые сети заговорили о работах над «умными» терминалами, умеющими узнавать постоянных покупателей по лицу и голосу, чтобы предложить им именно те кроссовки и футболки, которые они почти наверняка купят.

Радует не только и не столько рост числа таких обращений, сколько то, что находясь в начале проекта по цифровой трансформации, заказчики уже обращаются за компетенциями в ИТ-инфраструктуре. Не «задним числом», когда сервис уже заработал и начались проблемы эксплуатации. И даже не в момент, когда разработка подходит к концу и пора бы задуматься о том, как приложение будет работать, а еще при планировании проекта – заблаговременно. Значит, в подходе компаний к созданию систем, управляющих их бизнесом, что-то сильно изменилось.

Революция без жертв: смешанные команды в проектах Agile+DevOps

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

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

Очевидно, сегодня далеко не все компании хотя бы идейно готовы так работать – без заседаний всевозможных комитетов, бесконечных процессов согласования и утверждения ТЗ, но это новый долгосрочный тренд. И новый перспективный рынок для смешанных ИТ-команд, объединяющих разработчиков, экспертов из сервисных компаний, специалистов по ИБ. Этот рынок возник ради большей гибкости и адаптивности прикладных решений, которые (наконец-то!) действительно способны поддержать постоянные изменения и внутри компании, и снаружи – в ужесточившейся конкурентной среде и меняющемся технологическом ландшафте.

Самостоятельная разработка и поддержка микросервисов: что и как

В таких проектах господствует agile-подобная разработка. Есть заказчики, от которых идут задачи, есть координаторы проектов и аналоги спринтов Scrum. Под проекты оперативно выделяются «компактные», но достаточные бюджеты. И, главное – на таких проектах работают смешанные трансграничные команды. Строго внутри организации остаются стратегия и целеполагание (бизнес-лидеры), тактика разработки (технические лидеры), «ядро» разработки и информационная безопасность. Снаружи – написание мобильных версий основных ИТ-сервисов, интеграция и обмен новых систем с внешними сервисами, эксплуатация систем.

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

Как этого добиться? Здесь только один путь – необходимо с самого начала включать в состав DevOps-команд специалистов по ИТ-инфраструктуре и эксплуатации готовых решений, хорошо знающих принципы, особенности и практики эксплуатации облачных бизнес-приложений, постоянно или время от времени работающих в высоконагруженном режиме. Они определят, что именно в данном проекте (с учетом специфики существующего ИТ-ландшафта и особенностей создаваемого ПО) надо сделать, чтобы готовое решение действительно смогло поддержать отказоустойчивость и горизонтальное масштабирование, чтобы оно справлялось с пиковыми нагрузками, не создавая раздражающих задержек. Именно для этих специалистов такая работа – профильная, в отличие от разработчиков.

ИТ-инфраструктурщики на DevOps-проектах: чем полезны

Быстро создают и развертывают сразу несколько разных сред

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

Кроме того, есть множество задач, которые разработчики могут передать «системным администраторам 2.0», работающим на стыке программирования и администрирования. Это позволит не отвлекаться от главного – работы над функционалом решения, и сократить издержки на разработку и сопровождение. Ведь если у «инфраструктурщиков» на своем поле есть набор готовых решений, то приложение и обойдется компании дешевле, и будет готово быстрее, а качество разработки при этом не пострадает. Среди таких задач, например, централизованное управление средами. Оно нужно для того, чтобы разработчики испробовали все гипотезы, а новые системы и приложения, выйдя в продуктивную эксплуатацию, гарантированно заработали бы без сбоев. При этом затраты разработчиков на хостинг тестовых сред не должны быть очень большими. «Cисадмины 2.0» помогают и с этим.

Помогают выбрать площадку для сервисов и рассчитать ресурсы под проект

В DevOps-проекте инженеры сервисной компании очень часто помогают разработчикам приложений заранее определить, какую вычислительную мощность нужно выделить под сам проект (для каждой из трех сред). Позже их услуги нужны при тиражировании на новые подразделения, ИТ-инфраструктура которых практически всегда имеет особенности, а иногда и принципиальные отличия. Также эти специалисты правильно и эффективно по затратам организуют ИТ-инфраструктуру для работы приложений в облаках (AWS, GCE, Azure), чтобы впоследствии, когда число пользователей и объем задач будут возрастать, не пришлось тратить время и ресурсы на авральный «переезд» на более подходящую площадку.

Развертывают ИТ-инфраструктуру для запуска приложений

ИТ-специалисты заранее готовят и настраивают средства автоматизированного управления конфигурациями(Puppet, Ansible и др.), резко снижающие сложность оперативного развертывания и настройки серверов, снижают количество ошибок и зависимость от квалификации администратора. Такая подготовка сокращает время на развертывание приложений для клиента в 3-10 раз.

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

Автоматизируют управление инфраструктурой

«Сисадмины 2.0», опираясь на ИТ-инфраструктуру, с которой можно работать как с ПО, оформляют все рутинные операции по управлению ею (обновление, подготовка нового сервера) в виде задач для систем управления конфигурациями. И уже эти системы устанавливают и настраивают ПО, приводя его в оговоренное целевое состояние и обеспечивая целостность ИТ-решения любой сложности. Это позволяет до предела упростить обслуживание ИТ-инфраструктуры – например, перегрузить «зависший» виртуальный сервер, просто зайдя в консоль и нажав кнопку Reset. Или моментально восстановить информацию, которая, казалось, была потеряна (технология моментальных снимков).

Работают с контейнеризированными приложениями

Также инфраструктурщики автоматизируют установку, масштабирование и управление контейнеризированными приложениями с помощью кластеров Kubernetes. Благодаря их настройке (включая правила доступа к API и правила межсетевого взаимодействия для приложений), разработчики могут сделать свое приложение доступным даже во время пиковых нагрузок. А также в любой момент расширить или сжать кластер – буквально за пару секунд. Это экономит время и силы разработчиков, спасает их от многочисленных сложностей и ошибок.

Выполняют требования к SSO

Зачастую новые системы работают на разных СУБД (PostgreSQL, MySQL), а при разработке приложений используются разные платформы. Естественно, у разработчиков, а потом и у пользователей, должен быть простой и безопасный доступ ко всем нужным им сервисам и инструментам, а также сквозная аутентификация (Single Sign-On, SSO). Кроме того, над проектом работают разные команды – здесь обязательно нужно разделять права доступа к сервисам, инструментам, задачам, делать технически невозможным такое совмещение прав, которое создает высокие риски для бизнеса. К сожалению, об этом функционале думают не всегда.

Отслеживают «здоровье» информационной системы

Тиражируя и масштабируя новые приложения, важно следить за их состоянием, желательно в режиме реального времени. Специалисты по ИТ-инфраструктуре могут предоставить разработчикам приложений доступ к данным, помогающим анализировать возникающие ошибки в работе приложений с помощью инструментов open source (Graylog и Elasticsearch). Они также организуют сбор всех нужных разработчикам метрик с элементов инфраструктуры и приложений, на всех уровнях (Zabbix, Prometheus, TICK Stack). Также «инфраструктурщики» могут настроить удобную визуализацию и умные предупреждения о возможных ИТ-проблемах и авариях, отслеживать и корректировать поведение разных модулей приложения при высоких нагрузках.

Налаживают резервное копирование

Правильное хранение и быстрое восстановление потерянной информации крайне важно для любого бизнеса – это уже давно аксиома. Здесь «сервисники» могут сделать очень многое. Например, провести серию интервью с представителями заказчика и выяснить, какая глубина резервных копий нужна компании, пользующейся новым приложением. Как долго нужно хранить ту или иную информацию, данные за какой отрезок времени можно потерять, и это не окажется смертельным. На основании глубокой аналитики «сервисники» выстроят для разработчиков и их заказчиков правильную систему резервного копирования. Наладят организационно-технический контроль за правильным и своевременным выполнением резервного копирования, гарантирующие сохранность данных и возможность их восстановления в оговоренные сроки. Без этого самая совершенная система легко может стать бомбой замедленного действия.

Подведем итоги

Специалистов по ИТ-инфраструктуре необходимо вводить в новые DevOps-проекты, потому что они способны уберечь разработчиков от дорогостоящих и бьющих по репутации ошибок, связанных с эксплуатацией готовых решений. При этом важны индивидуальные рекомендации, основанные на понимании, куда организация ведет разработку, какие технологии и подходы предполагает применять. «Одна инструкция на все случаи жизни» тут не поможет, тем более, что сегодня очень много направлений разработки: кто-то занят big data, кто-то – искусственным интеллектом, а кто-то – исключительно «традиционными» информационными системами.

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

Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group

Несколько последних лет все дружно говорили о стагнации рынка ERP-систем. Ситуация выглядела настолько безнадежно, что появились мнения о бесперспективности ERP как класса решений. Но недавно вышел отчет IDC, согласно которому объем российского рынка корпоративных систем за 2017 год вырос в долларовом выражении почти на 30% и составил 819 млн долл. При этом решения по управлению ресурсами предприятия (ERP) стали не только крупнейшим сегментом рынка, но и самым динамичным. Под воздействием каких факторов произошел столь заметный рост и насколько длительным он окажется? Мы поинтересовались мнением нескольких заметных игроков рынка.

Не «отскок», а тенденция

Светлана Гацакова, директор департамента корпоративных информационных систем ALP Group: «Первый по значимости фактор – это смена поколения заказчиков ERP-систем. В крупных организациях становится все больше руководителей высшего звена, получивших современное бизнес-образование в сильных школах управления»

«Сегодня падение в большом сегменте ИТ-рынка не может смениться масштабным “отскоком”, даже если вдруг общее состояние экономики резко улучшится. Пока происходит падение рынка, потребности предприятий во многом меняются. Но еще быстрее меняются технологии, и, когда возникает возможность роста, старые проекты, как правило, либо уже не востребованы, либо воплощать их в жизнь нужно иначе», – уверена Светлана Гацакова, директор департамента корпоративных информационных систем ALP Group. Масштабный рост могут дать только большие долгосрочные изменения потребностей заказчиков – в сочетании с существенно изменившимся технологическим ландшафтом, который позволяет решать классические и новые задачи организаций иначе и лучше. Сегодня все эти условия есть, и поэтому на российском ИТ-рынке наблюдается начавшийся рост сегмента ERP. Это действительно долгосрочная тенденция.

В IBS наблюдающийся рост во многом связывают с восстановлением рынка масштабных проектов внедрения ERP-систем. «В 2017 году сразу несколько крупных компаний начали масштабные ERP-программы. Поскольку такие программы, как правило, длятся не один год, они будут значимо влиять на рынок и в последующие периоды», – полагает Семен Данилов, директор департамента корпоративных решений в IBS. При этом продолжает сохраняться устойчивый спрос на консалтинг в области развития ERP-решений.

Факторы роста

«Мы также видим рост направления ERP, он связан с двумя факторами. Во-первых, появились недорогие ERP-решения российских разработчиков, в частности компании “1С”. Поэтому многие компании, у которых не хватало средств на покупку зарубежных решений, внедряют ERP сейчас. Во-вторых, мы отмечаем рост спроса со стороны производственных предприятий», – говорит Евгений Завьялов, директор по бизнес-приложениям «Крок». Если совсем недавно производственные компании выбирали ERP-системы для автоматизации закупок или управления складом, то сейчас серьезное внимание направлено на автоматизацию главного процесса – производства. Такой интерес тоже вполне объясним: в текущей экономической ситуации многим компаниям довольно сложно расти и развиваться. Поэтому руководство смещает фокус на внутреннюю эффективность как источник прибыли.

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

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

Участники рынка ERP, которые своевременно заметили эту тенденцию и успели перестроить свою работу, ощущают новый всплеск интереса к ERP и начинающийся подъем этого рынка – настолько мощный, что его можно назвать вторым рождением российского рынка ERP. А остальные ощущают катастрофическое сужение того же самого рынка.

Интеллектуализация систем

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

Евгений Завьялов, директор по бизнес-приложениям «Крок»: «Если совсем недавно производственные компании выбирали ERP-системы для автоматизации закупок или управления складом, то сейчас серьезное внимание направлено на автоматизацию главного процесса – производства»

 Нынешний кадровый голод вызван сразу несколькими серьезнейшими причинами: демографической ситуацией, трудностями интеграции поколений Y и Z в систему работы современных предприятий, отмиранием одних специальностей и зарождением других, по которым вообще нет сложившегося рынка труда. В то же самое время появляются доступные технологии роботизации, уже способные заменить человека там, где требуется выполнение стандартизованных операций. И кадровый голод, и роботизация – это масштабные долгосрочные тенденции.

«Особо подчеркну, что глубокая автоматизация и даже роботизация отдельных участков хорошо согласуются с ростом интереса к ERP и управлению на основе объективных данных», – отмечает Гацакова. Качественная роботизация позволяет эффективно бороться с ситуацией, когда высококвалифицированные специалисты должны значительную часть времени заниматься рутинными делами.

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

Западные вендоры вновь стали подогревать интерес к системам управления предприятием. Теперь – опираясь на концепцию «интеллектуальных ERP» (iERP) и пытаясь создать вокруг нее новую товарную категорию. Но здесь перспектива зависит от того, как поведут себя заказчики. Пойдут ли они на новый круг закупки импортного ПО или дадут российским ИТ-компаниям возможность создать свои модули?

И конечно, нельзя не отметить мощный фактор, воздействующий на российский рынок ERP, – цифровизацию российской экономики, на которой уже второй год делает акцент президент России. Здесь что ни тезис, то масса управленческих задач, которые надо решать средствами цифровой трансформации. Более того, речь идет даже о целевых кредитах под очень низкий процент малому и среднему производственному бизнесу на смену технологий.

Нехватка кадров может стать барьером

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

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

«Что касается сдерживающих факторов, то в производственном секторе я бы таковым назвал дефицит квалифицированных ресурсов. Сегодня мало профессионалов в области автоматизации производства, и это, в свою очередь, может погубить потенциал рынка ERP», – считает Завьялов. Спрос на решения высокий, высококлассных кадров не хватает, поэтому появляются некачественные проекты. Однако похожая ситуация наблюдалась лет 15 назад в финансовом секторе, поэтому в целом понятно, что именно следует предпринять ИТ-компаниям и интеграторам.

«Основная проблема – потенциальная нехватка квалифицированных специалистов по внедрению», – согласен Данилов. В предыдущие три-четыре года многие интеграторы, учитывая неопределенную ситуацию на рынке и нестабильный спрос, не вкладывались серьезно в развитие персонала, а предпочитали набирать под проекты уже опытных специалистов. Это может оказаться барьером, сдерживающим быстрый рост рынка в последующие годы.

Рост продолжится

Семен Данилов, директор департамента корпоративных решений в IBS: «В ближайшие пять лет можно ожидать появления большого количества проектов перевнедрений ERP. Не миграций, а именно перевнедрений, которые дадут возможность серьезно трансформировать бизнес-процессы компаний с учетом новейших возможностей систем»

Все факторы, влияющие на рынок, – долговременные и уже начавшие действовать. Поэтому можно быть уверенными в том, что рынок ERP продолжит количественный рост, меняясь при этом структурно и порождая новые рыночные ниши.

«Думаю, на рынке ERP сейчас начнется “гонка новых решений”: компания, которая раньше и более качественно внедрит их у себя, получит мощные конкурентные преимущества, – полагает Гацакова. – Именно такие компании будут постепенно занимать все большую долю рынка, налаживать взаимодействие и совместными усилиями устанавливать новые правила игры. Основной фактор сейчас – это время, и его нельзя упустить».

«Если производственные проекты покажут свою эффективность, то рост, безусловно, продолжится. Если же проекты снова окажутся “тяжелыми”, то можно ожидать стагнации, поскольку производственные компании уже не в первый раз обращаются за подобными решениями», – выражает опасение Завьялов.

«Мы ожидаем уверенного роста рынка. Многие функционирующие сейчас ERP-системы были внедрены в нулевых годах. За прошедшие 10 лет эти системы в большинстве своем устарели технологически. Они становятся все более сложными и нестабильными. Необходимы изменения, а они либо невозможны, либо сроки их реализации недопустимо велики», – говорит Данилов.

Кроме того, производители постоянно развивают и совершенствуют свои ERP-системы, выпускают новые версии, которые все дальше уходят в своем развитии от текущих клиентских инсталляций. Наконец, несмотря на сложную экономическую ситуацию, возрастает здоровая деловая активность в России в целом.

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

Заказчики стали другими?

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

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

«Кроме того, появляется все больше проектов, в которых ERP работает в связке с другими технологиями: это и чат-боты, которые облегчают процесс взаимодействия конечных пользователей с системой, и Интернет вещей, дающий возможность не заносить данные вручную, а автоматически собирать их с датчиков», – констатирует Завьялов. Кроме того, он выделяет внедрение электронных подписей и документооборота, а также работу с большими данными, которая позволяет быстрее и эффективнее анализировать накопленную в системах информацию.

Для заказчиков одна из самых сложных проблем – это получение объективных данных, причем все чаще в реальном времени, и не только внутренних, но и внешних. Фактически сформировалась потребность в системах, способных прогнозировать события и даже проактивно рекомендовать заказчикам соответствующие действия. На эти тренды все больше и ориентируются компании.

«Послушаем, пощупаем, понюхаем…» – примерно так в фильме «Берегись автомобиля» отвечал автомеханик-умелец на жалобы владельца новенькой неправедно нажитой «Волги». На ранних этапах развития все сложные технические системы – будь то трактор, станок или самолет – требуют для своей работы мастеров, которые буквально чувствуют «подопечного» и по каким-то только им понятным сигналам могут определить, что с ним не так. Но по мере роста сложности, стоимости и мощности технических систем, а также рисков, возникающих при нарушении их работы, технология управления полностью меняется. Системы обрастают индикаторами состояния, контурами обратной связи, и в итоге мы видим диспетчерский центр, в мельчайших деталях информирующий о том, как работает система. Он привлекает внимание к тем параметрам, которые входят в зону риска, предоставляет инструменты разностороннего воздействия на контролируемую систему, а порой и автоматически предпринимает корректирующие действия. На смену интуитивным догадкам приходит управление на основе объективных данных, автоматизация и роботизация.

Удивительно, но информационные системы организаций, несмотря на свою изначально компьютерную и кибернетическую природу, с точки зрения способа управления все еще пребывают на ранних этапах развития. Сегодня ИТ-персонал в большинстве случаев лишь реагирует на те или иные проблемы или аварийные ситуации: отказы в обслуживании, снижение производительности, неожиданные задержки с поступлением необходимых данных и т.д. Не имея точных показателей развития ситуации, ИТ-специалисты по-прежнему «слушают, щупают, нюхают», чтобы как можно скорее восстановить работу системы. Но чем сложнее система, чем быстрее она меняется, чем больше в ней появляется незнакомых элементов (например, российского и открытого ПО), тем менее эффективен этот способ, тем чаще он дает сбой.

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

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

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

Чем «болеют» информационные системы?

Определить понятие нормы для информационной системы не так сложно, как для природной. Норма – это соответствие системы требованиям, сформулированным при ее создании или добавленным на более поздних этапах жизненного цикла. А «болезнь» – это нарушение одного или нескольких таких требований. Болезнь тем тяжелее, чем существеннее нарушенные требования, чем их больше и чем сильнее реальные характеристики отклоняются от приемлемых, то есть выходят из «зеленой зоны».

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

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

Хорошая современная система мониторинга непрерывно и автоматически получает, консолидирует и доставляет в аналитический центр, а также визуализирует информацию о множестве характеристик ИТ-объектов – серверов, рабочих станций, файловых систем, СУБД, прикладных программ, пользователей. Первичные данные поступают непосредственно из различных элементов системы, а значит, по определению точны (вероятность ошибок в модулях сопряжения очень мала, поскольку такие модули просты и применяются во множестве организаций). Принципиальных технических ограничений на количество параметров и число объектов мониторинга практически нет, а все фазы сбора и обработки могут происходить очень быстро – вплоть до режима реального времени. Ограничивающим фактором обычно является способность ИТ-службы осмыслить полученную информацию.

1. Нарушения функциональных требований и технические ошибки

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

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

Ошибки второго типа (технические) прерывают нормальное поведение системы, но она при этом сообщает о причине и предоставляет дополнительную информацию. Например, некорректно сформирован запрос к системе или клиент не получил ответ за отведенное время. На такую ошибку ИТ-службам надо реагировать быстро, так как, с точки зрения пользователя, причина понятна (хотя это и не всегда так), а значит, ее легко устранить (а это часто совсем не так). Если такие ошибки имеют место, необходимо сразу узнавать о них, не дожидаясь, пока к недоумению пострадавшего пользователя добавятся масштабные следствия: снизится производительность системы и зависящих от нее подразделений, нарушится их работа, а возможно – и работа предприятия. Здесь, так же как и при ошибках первого типа, ценно понимание связи между фактом возникновения ошибки и тем, что происходит с системой.

2. Доступность и производительность

Требования к производительности в совокупности должны гарантировать, что будет достигнут запланированный при внедрении рост эффективности работы сотрудников. Например, время на заведение в системе приходного кассового ордера снизится с десяти до одной минуты. И если по факту эта операция стала занимать более пяти минут, то это не успех, а выход в «красную зону». Ведь ожидания не оправданы – сотрудник просто не успевает выполнять работу, которая отводится ему после внедрения приложения и которая закладывается в KPI. Более того, страдает не один сотрудник, а все, кто выполняют данную операцию. А значит, падает производительность отдела, департамента, а то и всей компании. Если меры своевременно не принимаются, то найти источник проблемы очень сложно. И делается вывод, что внедренная система неэффективна.

Чтобы исключить подобную ситуацию, система мониторинга должна постоянно отслеживать время выполнения операций, оценивать среднее время выполнения операций и сверять его с эталонными значениями. Если выявлено достаточно сильное отклонение – это важный сигнал: «Что-то не так, это очень подозрительно!» Рост средней длительности операции говорит о снижении производительности; желательно еще до усугубления ситуации найти причину, понять, как с ней бороться, и принять меры по восстановлению производительности.

Но, даже если средняя длительность не возросла, а уменьшилась, это тоже повод поволноваться! Почему система вдруг стала работать быстрее – может быть, перестали выполняться какие-то важные функции?

Крайний случай – полная недоступность системы, когда она не отвечает ни на один запрос пользователей. Сегодня это означает, что сотрудник полностью лишен возможности выполнить свои должностные обязанности. Блокирование одного звена легко может привести к каскадной остановке многих (а то и всех) процессов предприятия, что неотвратимо ведет к финансовым и репутационным потерям.

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

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

А высокая оперативность получения, аналитической обработки и осмысления информации об ошибке позволяет, не оттягивая время, идти на проблему. Получив информацию о первой ошибке, специалист службы эксплуатации может самостоятельно связаться с пользователем и выяснить обстоятельства, а иногда и сразу понять причину ошибки, помочь с решением до того, как пользователь потеряет терпение.

3. Информационная безопасность

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

4. Отсутствие гибкого и оперативного внесения изменений

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

Но есть и объективные технологические ограничения, многое зависит от платформы и реализации. Чтобы воплотить новое требование, иногда достаточно только настроить систему – это идеальный вариант. Но порой требуется ее серьезная доработка. Доработка создает не только ожидаемые, но и побочные изменения. И если первые эффективны и направлены на достижение результата, то побочных эффектов обычно никто не ждет и не просчитывает. Иногда это просто ошибки, и очень нехорошо, когда любые ошибки при изменениях выявляются на продуктивной среде, где размещены основные рабочие базы.

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

В любом случае перед выпуском изменений, касающихся продуктивной системы, необходимо убедиться в том, что они не повлекут за собой негативных последствий: система не перестанет работать, существенно не снизится ее производительность, не отключатся отдельные функции. Естественно, все изменения необходимо тестировать на отдельном контуре, а не на рабочей базе. И без системы мониторинга, объективного контроля здесь не обойтись, ведь он позволяет отследить поведение системы на тестовом контуре, выявить несоответствия, спрогнозировать поведение системы после распространения изменений на продуктивный контур и после переноса изменений на рабочую базу. Система мониторинга собирает показатели «здоровья» системы непрерывно. А это позволяет сразу по многим показателям сравнить состояния до и после обновления, выявить отклонения и принять соответствующие меры.

Подняться на новый уровень

Мониторинг информационных систем – пока недооцененная технология, достойная самого пристального внимания. Приведенные примеры показывают, что при переходе к управлению состоянием системы на основе объективных данных ИТ-подразделения сталкиваются с задачами, родственными тем, с которыми имеют дело современные управленцы, внедряющие отдельные практики и целые системы менеджмента на основе анализа данных (data-driven management, DDM).

При этом ИТ-подразделения находятся в более выгодном положении. Во-первых, у них есть (по крайней мере, должны быть) достаточно четкие требования к работе систем, что позволяет определить набор показателей для мониторинга, ввести метрики для отдельных показателей и их сочетаний (как минимум «зеленая», «желтая» и «красная» зоны). Во-вторых, у них есть достаточно широкий выбор систем мониторинга, существенно различающихся не только функциональными возможностями, но даже принципиальными подходами к самому мониторингу. В-третьих, организовать и автоматизировать сбор первичных данных об информационной системе, как правило, существенно проще, чем об организации. Наконец, у ИТ-службы имеется положительный опыт создания методики измерения пользовательской удовлетворенности ИТ-решениями (APDEX) и ее принятия участниками ИТ-рынка в качестве фактического стандарта, на который опираются и заказчики, и исполнители проектов. Однако APDEX – это пока, скорее, ориентир для оценки других аспектов работы систем, где подобные методики еще только предстоит создать.

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

Разумеется, на эффективный мониторинг в ИТ, способный решить вышеперечисленные задачи, должно быть нацелено не только ПО, но и служба эксплуатации, которая в эпоху DDM должна работать иначе, чем прежде. Да и не всякие информационные системы полностью готовы к новой роли на современном предприятии. Важна также методическая составляющая – например, эксперименты, расширяющие воздействие на объект мониторинга за рамки типичных сценариев использования. Без этого невозможно аккуратно оценить поведение инфраструктурного и прикладного ПО перед масштабными изменениями в организации (включая внедрение новых методик менеджмента или, скажем, переход на незнакомое российское ПО в проектах импортозамещения). Однако все перечисленное нисколько не умаляет роли мониторинга и основанных на нем инструментов в информационных системах ближайшего ИТ-будущего. Система мониторинга – это не прихоть и не баловство. Это необходимость.

– Александр Жданюк, руководитель практики информационных технологий и корпоративных сервисов поддержки ALP Group, aleksandr.zhdanyuk@alp.ru