Три категории IT рисков
- Риски, которые угрожают текущему бизнесу (11:00)
- риски остановки критичной инфраструктуры
- риски в области ПО (остановка поддержки, непредоставление патчей)
2. Риски для развития, реализации текущих планов развития. В условиях экспоненциального развития технологий, “чтобы оставаться на месте, надо бежать изо всех сил, а чтобы двигаться вперед, нужно бежать еще быстрее”. Этот риск накроет нас не сегодня, но уже завтра он будет ощутим.
3. Риски отставания в “новой нормальности”.
В момент кризиса разумно думать в трех горизонтах:
- обеспечение текущей выживаемости
- подготовка к возврату в нормальное состояние
- приспособление к “новой нормальности”, извлечение выгод из кризиса
Что снижает остроту рисков?
Во-первых, многие компании успели создать себе запас необходимых устройств в самом начале кризиса. А самые грамотные подготовили комплексные планы обеспечения непрерывности, которые включали и санкционные риски широкого спектра.
Во-вторых, вычислительных ресурсов у предприятий вполне хватит на полгода-год. А это будет одной из главных проблем.
В-третьих, возможно, что дефицит вычислительных ресурсов ускорит переход в облака и приведет к повышению эффективности ПО. И эти стратегические развилки нам нужно эффективно пройти.
Развитие облачных вычислений
Возможно у нас сложится новая модель обеспечения вычислительными ресурсами. Изменится соотношение между облачными сервисами и внутренними ресурсами. Крупные отечественные облачные провайдеры должны первыми научиться поддерживать и наращивать свои вычислительные мощности. Возможно, это будет задача государства, всего сообщества провайдеров облачных услуг. В России темпы перехода в облака будет беспрецедентно высокими.
Повышение эффективности ПО
Есть глобальная проблема: рост вычислительных ресурсов, их избыточность приводили к снижению эффективности программного обеспечения. Общего экспоненциального роста функциональности ИТ решений, в отличие от вычислительных ресурсов, не произошло.
ПО, которое создавалось 20-30 лет назад было эффективнее, чем современный код, современная архитектура.
Сейчас есть возможность повысить эффективность кода. ПО, чтобы компенсировать дефицит вычислительных ресурсов. Здесь мы можем сделать рывок за счет интенсивного развития, а не экстенсивного - роста вычислительных мощностей.
Риски в промышленном IT, меры по их снижению
В “тяжелых” индустриях есть угрозы, которые могут реализоваться быстро. В решениях АСУТП (ОТ) потенциально есть возможность со стороны производителей помешать вносить изменения в эти системы, и даже потенциальная возможность дистанционного вмешательства (вплоть до отключения) в производственные проблемы.
Нужно сделать оценку таких угроз и разработать план действий в различных сценариях.
Второе - это замена специфичных систем (таких как CAD, MES и пр.). Такие системы экономически оправдано создавать, только если есть большой рынок. Но если такие системы критичны для наших производств, значит надо инвестировать в них на государственном уровне.
Третий уровень - системное ПО, На уровне системного ПО (OC, PaaS, middleware, баз данных) 80% всего стека может быть построено на open source ПО.
Унификация платформенных решений
Нецелесообразно каждой организации разрабатывать свою собственную архитектуру IT систем, как на уровне АСУП, так и на уровне АСУТП. Нужно разделить это на слои и создавать унифицированную архитектуру для слоев. Сейчас все создают свои сервисы для DevOps Tool Chain, CI/CD платформы, PaaS и так далее. Нужно объединить инсорс и аутсорс проекты и создавать такие вещи сообща. Это может консолидировать и “зажечь” программистское сообщество.
В крупных организациях есть несколько отличных команд, которые могут это реализовать. Архитекторы из этих компаний могут войти в некий “совет конструкторов” таких платформ.
Необходимо идентифицировать интересы всех участников и создать систему, учитывающую эти интересы. Технологические лидеры должны получать свое признание и свои преимущества. Надо решить, как будет перераспределяться ценность внутри такой модели. Те, кто вносят свой вклад в такое сообщество, должны получать выгоды от этого участия.
Нужны будут административные меры, как ограничивающие, так и стимулирующие.
Конкуренцию сейчас мы должны “приморозить”, чтобы объединить имеющиеся ресурсы.
Ситуация с ERP
Проблемы с ERP - не самые сложные. У нас ERP внедрялись далеко не так эффективно, как хотелось бы. Эталонная ценность ERP состояла в том. что вместе с ними внедрялись лучшие практики, процессы, например, в финансовом планировании, и в управлении производственными ресурсами.
Часто внедрение превращалось в тяжелые проекты, где система полностью переделывалась до полной неузнаваемости.
Здесь есть возможность перейти на новую компонуемую (композитную) архитектуру, когда отдельные фрагменты могут встраиваться в наши платформы и приложения.
Это хорошая возможность постепенно сделать миграцию к новой архитектуре.
Нужно сделать оценку тех проектов ERP, которые были проведены в компаниях, желательно - внешнюю. Посмотреть, насколько действительно используются все функции купленных пакетов.
Может оказаться, что система была уже настолько кастомизирована, что уже нет смысла гнаться за импортными решениями. И есть возможность ускоренными темпами мигрировать ERP в более современную архитектуру. Тем более, что и базы данных, и платформенный слой сегодня можно сделать на open source.
Создание общей платформы для тестирования решений
Сегодня насущной задачей является обмен информацией о возможностях замены вендорских решений на решения open source. Многие сегодня введут пилотные внедрение, тестируют продукты. У ЛПР в этой ситуации появляется желание получить независимую оценку, независимое мнение.
Проблема создания общей информационной базы по таким тестам заключается в том. что методика тестирования у всех разная. Их сложно однозначно сопоставить. и сегодня роль разного рода ассоциаций, платформ в разработке общепризнанных методик таких тестов: протоколов, наборов испытаний, требований к результатам таких испытаний и т.п. Это вполне практическая работа.
Затем нужно было бы создать среду для проведения таких тестов и обмена результатами. Такая единая среда позволила бы сэкономить усилия.
И, наконец, нужно, чтобы появилась доверенная организация, которая могла бы предоставлять свое заключение IT директорам. Такое заключение необходимо им для тендерных комитетов, внутренних и внешних аудиторов.
Максим Григорьев - эксперт в области IT архитектуры, соучредитель консалтинговой и тренинговой компании в сфере управления ИТ – IT Expert, лично обучал и консультировал многих IT-руководителей. Руководил Центром финансовых технологий в Банке России. Работал исполнительным партнером компании Gartner
Читайте наш телеграм-канал "IT-совет" https://t.me/sandbox_ru