Сегодня готовность ИТ-инфраструктуры к цифровой трансформации предприятия зависит от наличия у нее трех главных свойств. Во-первых, это отсутствие «костылей» в виде исторически сложившихся и уже не выполняющих свою функцию ИТ-решений. А также в виде заложенных в основу информационных систем ошибочных архитектурных решений, которые принимались в период «лоскутной информатизации» и не только не были исправлены, но и повлияли на конструкцию всей корпоративной информационной системы и сегодня не дают ей развиваться. Во-вторых — это простая и быстрая масштабируемость, а также высокая надежность и отказоустойчивость. Третье свойство ИТ-инфраструктуры, показывающее ее готовность к цифровой трансформации, — способность очень быстро меняться и поддерживать высокую изменчивость ПО, находящегося на более высоких этажах информационной системы. Это свойство исключительно важно, поскольку именно от него зависит, сможет ли компания технологически успевать за требованиями бизнеса.
Разумеется, у ИТ-инфраструктуры есть много других свойств, наличие которых помогает проведению цифровых трансформаций на предприятии (например, система управления ИТ на основе объективных данных), но вышеперечисленные три свойства — это необходимый минимум. Если какого-то из них нет, то цифровую трансформацию начинать нельзя. К сожалению, сегодня именно эта ситуация характерна для подавляющего большинства российских организаций. Первым делом им нужно привести в порядок «технологический фундамент». С чего же начать и что именно сделать, чтобы подготовка прошла легче и быстрее? А сделать нужно немного.
Шаг № 1. Почистить ИТ-организм — провести входной аудит
Комплексный ИТ-аудит позволяет, не «ныряя» на огромную глубину, получить общий срез «здоровья» информационной системы или только ее инфраструктурной части. Посмотреть на архитектуру системы, выявить ошибки, возникающие в ней чаще всего, и проследить их связь с особенностями архитектуры. Важно, что выводы этого аудита (если он сделан профессионально и компетентно) понятны бизнес-руководителям, а потому можно содержательно обсудить с ними (а не только со службой эксплуатации) выявленные проблемы, пути их преодоления и, главное, дальнейшие требования к ИТ-инфраструктуре.
Серия интервью, проведенных в ходе аудита с сотрудниками компании, топ-менеджерами и внутренней ИТ-службой, позволяет выяснить главное: контекст возникновения и «жизни» инцидентов и проблем. И найти оптимальные способы их устранения.
Отличие ИТ-аудита, проходящего как «нулевой этап» цифровой трансформации, от обычного анализа состоит в том, что команда, отвечающая за такой ИТ-аудит, изначально выясняет у бизнеса (генеральных, коммерческих, финансовых директоров, директоров по продажам, производству, логистике), какого эффекта бизнес ждет от намеченных цифровых трансформаций, какие именно информационные системы будут меняться в ходе этого процесса. И на что заказчик возлагает наибольшие надежды на данном этапе. Если, например, на модернизацию системы управления работой с клиентами и партнерами, то как именно он рассчитывает это делать? Если, скажем, на базе этой системы предполагается разработать личный кабинет для пяти-семи тысяч внешних пользователей с гарантированным приростом в 30–40% в течение следующего года, то ИТ-аудиторы будут, помимо прочего, тщательно проверять, выдержит ли ИТ-инфраструктура внедрение и работу такого решения. Правильно ли она спроектирована под него (от архитектуры СУБД до сервера приложений, веб-сервисов и терминальных сервисов)? Сможет ли она быстро и просто масштабироваться, отвечая запланированному притоку пользователей?
Шаг № 2. Обеспечить простую и недорогую масштабируемость ИТ-инфраструктуры: гибридные схемы и сайзинг ресурсов в IaaS
Недорогая и легко масштабируемая ИТ-инфраструктура уже не просто нужна, а жизненно необходима быстро меняющемуся среднему и даже крупному бизнесу. Сегодня самый простой и уже вполне доступный на отечественном ИТ-рынке путь реализации этих возможностей — аренда ресурсов в IaaS. Однако дублирование всей ИТ-инфраструктуры в облаках — дорогое удовольствие, учитывая текущие цены у крупных облачных провайдеров. Часто среднему предприятию дешевле построить собственную ИТ-инфраструктуру и работать на ней лет пять без всяких проблем, чем два года оплачивать ее аренду. Кроме того, как бы ни было удобно облако, с ним тоже случаются проблемы: например, с доступом (очень часто — на уровне местных провайдеров в российских регионах), с надежностью, иногда — с безопасностью. Эти риски становятся особенно значимыми, если ориентация на облачные сервисы приводит к нарушению принципа «не складывать все яйца в одну корзину».
Более выгодным для среднего и даже крупного заказчика способом обеспечить простую и недорогую отказоустойчивость (в режиме «теплого» или «горячего» резерва ресурсов) является «гибридная» ИТ-инфраструктура. Если все нормально, работу предприятия обеспечивает инфраструктура традиционного типа, которая у него уже есть. И только если возникает нештатная ситуация, пользователи до момента ее устранения автоматически переводятся на работу с сервисами из облака. Причем за счет поддерживаемого гибридной инфраструктурой резервирования данных пользователи продолжают прерванную работу. При этом компания платит не за абстрактную надежность и отказоустойчивость (что может ни разу не потребоваться на практике), а за потребление ресурсов облака в периоды конкретных ИТ-инцидентов и «обрушений». И только если они действительно происходят. К тому же, если потребуется докупить у IaaS-провайдера ресурсы (скажем, под крупный проект), то делается это максимально быстро и просто — «в один клик».
Однако тут заказчика подстерегает еще одна проблема. Поставщики ресурсов в IaaS традиционно нацелены на то, чтобы продавать как можно больше (overselling). Это приводит к тому, что покупатели столь же традиционно переплачивают за ресурсы вдвое-втрое, а то и вчетверо. Причем из-за нехватки информации переплачивать приходится за все виртуальные ресурсы (процессоры, память и др.). Наиболее крупные и дорогие IaaS-провайдеры смягчают эту ситуацию, позволяя крупным клиентам отслеживать реальное потребление мощностей. Но для среднего бизнеса такие инструменты слишком дороги, да они и не продаются отдельно от платформ. А привязка к платформе — это тоже риск. Однако эффективные решения есть: например, услуга автоматизированного сайзинга ресурсов позволяет при работе с любыми IaaS-провайдерами точно, без переплат, спланировать потребление ресурсов и платежи за мощности в облаке.
Эти ИТ-сервисы дают возможность собрать и проанализировать объективные данные о том, хватает ли ресурсов. А если уже не хватает или не будет хватать через какое-то время (скажем, через две недели), то каких именно и сколько. Необходимая для этого информация автоматически стекается в сервис в режиме реального времени, а на выходе появляются рекомендации: какие ресурсы и когда надо докупить, а от каких можно безболезненно отказаться. Это позволяет предприятию своевременно и оптимально перераспределять затраты на облако и гарантированно избегать неприятной ситуации, когда ресурсов вдруг не хватило и бизнес начал простаивать. Также можно получить представление о том, когда и на сколько сократить потребление ресурсов, если, скажем, произошел сезонный или внезапный спад деловой активности. Или если часть пользователей либо какие-то сервисы были переброшены в другой ЦОД.
Шаг № 3. Поддержать высокую изменчивость — начать непрерывный ИТ-аудит
Любые технологические изменения порождают если не рост, то почти всегда — перераспределение нагрузки на ИТ-инфраструктуру. Например, компания решила объединить два сервера баз данных в один отказоустойчивый экземпляр и слить в него все базы. Но, сделав это, организация должна быть уверена в том, что ее веб-сервисы и другие ИТ-системы, работающие с этими базами, справляются с нагрузкой и что сервер приложений при этом «чувствует себя» совершенно нормально. Кроме того, предприятию нужно детально знать, как в результате такого изменения поменялась нагрузка на дисковую подсистему, сети, сопутствующие компоненты. Если поменялась, то на каком участке и как именно. От этих знаний зависит сама возможность своевременно выявить «бутылочные горлышки», которые будут ограничивать производительность тех или иных информационных систем и бизнес-приложений, и перегрузка которых почти наверняка будет чревата целой цепочкой ИТ-инцидентов и проблем!
Непрерывный ИТ-аудит призван отслеживать именно такие вещи в режиме реального времени. Это, конечно, не делается вручную. Здесь нужна автоматизация — в данном случае дополнительный аналитический модуль, на оперативность, надежность и компетентность которого организация может положиться.
Такие решения могут собирать, консолидировать и подвергать аналитической обработке десятки тысяч всевозможных параметров систем. Эксперты, опираясь на поступающую информацию и на архив прошлых данных, используя специальные инструменты, интерпретируют потоки данных и выдают адресные рекомендации, позволяющие своевременно устранить или не допустить перегрузок опасных и дорогостоящих «бутылочных горлышек» в ИТ-инфраструктуре. Тем самым не на словах, а на деле поддерживается ее высокая изменчивость.
Шаг № 4 (дополнительный). Обеспечить постоянное взаимодействие команд на проектах по цифровой трансформации
Занимаясь приведением в порядок ИТ-инфраструктуры, бизнес должен задуматься едва ли не о самом опасном узком месте цифровой трансформации — о налаживании взаимодействия участвующих в ней независимых команд. Так, служба разработки должна уметь действовать в связке со службой эксплуатации ИТ-инфраструктуры и со службой внедрения (это взаимодействие совершенно необходимо при использовании связки Agile и DevOps). А все они — с подразделениями, отвечающими за информационную безопасность. И конечно — с бизнес-заказчиком. Как правило, ничего этого сейчас нет, но такая ситуация недопустима, когда в организации осуществляется широкая цифровая трансформация.
Сегодня наилучшим способом преодолеть этот давний «камень преткновения» является выстраивание горизонтальных связей между командами в виде системы процессов, дополненной современными средствами коммуникации «для данного случая» (ad hoc). Если организация решает внедрить технологии управления Agile, нужно тщательно выбрать конкретную методику, настроить соответствующие процессы (чемпион здесь — Scrum) и уделить большое внимание компетенциям участников. В любом случае (даже если перехода на Agile нет) помогает формирование небольших рабочих DevOps-групп под проекты (в том числе и по цифровой трансформации). В эти группы входят представители каждой из вышеперечисленных команд. Однако всем им нужна общая информационная среда и доступ к постоянно обновляющейся информации в ней — о состоянии всего проекта и его составных частей. Чтобы каждый мог наблюдать и анализировать одни и те же тренды, осуществлять правильные и своевременные корректирующие действия. И не каждая команда — только по своему участку, а совместно, по общему ходу проекта. DevOps-группы в проектах цифровой трансформации должны стать потребителями объективных данных об информационных системах и инфраструктуре, чтобы своевременно принимать взвешенные и правильные для компании решения.
Автор — Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group.
