Проведите простой эксперимент. Спросите знакомого менеджера о том, какие информационные технологии используются в бизнесе его компании, и как именно они работают. Ответ будет уверенным, но, скорее всего, абстрактным. Вряд ли он сможет рассказать о конкретном бизнес-процессе через описание используемых ИТ-решений. И не потому, что он некомпетентен, а потому что количество используемых ИТ-решений велико, а взаимодействие их зачастую нетривиально даже в небольших компаниях. А в крупных — даже CIO на деле видит и контролирует только верхушку айсберга. От этой избыточной сложности и фрагментированности страдают и сами ИТ-специалисты. Разработчики приложений не очень понимают (да и не особо интересуются), что происходит в серверных. Те, кто отвечают за сетевую инфраструктуру, вряд ли сталкиваются на работе с администраторами баз данных. А инженер систем хранения не поймет беседу тестировщиков. Повышенная сложность привела к тому, что специалистам техподдержки не хватает знаний, чтобы решать проблемы, их роль все чаще сводится к маршрутизации запроса на профильного специалиста. Решение же реальной проблемы может лежать и как правило лежит на стыке нескольких специализаций.
Если мы пристальнее посмотрим вглубь мира корпоративных информационных технологий, то заметим две тенденции. И они, как ни странно, противоположны. На уровне прикладного ПО продолжается усложнение подходов к его разработке и технологической «обвязке» этого процесса. Например, разработчику недостаточно в совершенстве владеть одним или двумя языками, он должен хорошо знать десяток-другой сопутствующих решений и инструментов. Стремительно развивается направление DevOps. Компании вынуждены зачастую уходить от стандартизированных решений и строить сложные, часто уникальные ИТ-платформы для основного бизнеса. Все это логично: прикладное ПО ложится в основу цифровых платформ и бизнес-моделей, а значит может являться реальным конкурентным преимуществом.
В то же время на уровне ИТ-инфраструктуры задан другой вектор: грядет упрощение как архитектуры, так и механизмов управления. И чтобы понять, почему оно неизбежно, давайте вернёмся на шаг назад и вспомним, как компании пришли к нынешнему состоянию. Здесь большой вклад вносят так называемые «унаследованные системы» вместе с их трехуровневой архитектурой и обширным серверным парком. Ведь идеология «каждому приличному приложению — свой сервер» почиталась в ИТ-среде еще относительно недавно. Так же, как и правило «работает — не трогай», которое, правда, весьма актуально и сейчас. Так или иначе, все это приводит к накоплению разнородных серверов и систем хранения, которые нужно поддерживать.
Задача их поддержки тем более сложна и трудоёмка, чем больше решений разных поставщиков вы используете. И вот почему. Рынок серверов и СХД давно поделен крупными игроками, и каждый из них стремится привязать клиента к себе. Для этого они предлагают широкий набор решений и принудительно встроенной функциональности, но интеграция с решениями других производителей зачастую страдает или требует использования решений третьих сторон для управления и мониторинга. Поэтому мы получаем тяжёлые, функционально избыточные и к тому же плохо совместимые с точки зрения управления платформы. Кстати, именно желание иметь более лёгкие и универсальные средства управления вычислительными ресурсами породило целую волну стартапов и разработок на открытых платформах. Они хотя и облегчают «боль» системных администраторов, но не способны устранить ее причину. Ведь даже «староверы» понимают, что уже невозможно под каждую нагрузку держать отдельный сервер.
Сокрушительный удар по старому укладу нанесли технологии виртуализации, гиперконвергенции и облачных сервисов. С их появлением эпоха «романтиков» железа — времени, когда серверам давали красивые и необычные имена, — похоже, ушла навсегда. А стремительный и всеобщий переход на архитектуру х86 привел к неожиданному результату: все вдруг стали смотреть на вычисления как на сервис. И да, имена виртуальных серверов теперь просты и генерятся автоматически. В целом это можно сравнить с автомобилестроением: когда-то наличие ABS было огромным конкурентным преимуществом. Такие технологии предлагали всего
Сегодня создание виртуальной машины похоже на бесконтактную оплату покупки. Конечно, эта простота обманчива. И в том, и в другом случае запускается крайне сложный процесс, в котором в автоматическом режиме взаимодействуют множество систем. Однако процесс отлажен, протоколы стандартизированы, все происходит без нашего участия — как бы само собой. На самом деле за этой процедурой все еще стоит упорная работа ИТ-команды. Один из опросов Nutanix выявил, что администраторы в компаниях с количеством виртуальных машин в
Поэтому следующим очевидным шагом является автоматизация рутинных процедур, подобных описанным выше. Скажем, система программно отслеживает по заданным параметрам утилизацию ресурсов и сама же выполняет настройку в случае необходимости. Среди других функций, которые будут автоматизированы — обновления, управление жизненным циклом встроенного ПО, развёртывание и удаление виртуальных машин, мониторинг производительности и надёжности и даже автоматическое исправление ошибок. Такие возможности доступны за счет встроенных компонентов машинного обучения и автоматизированного принятия решений. Что к тому же сильно снижает риск пресловутой «человеческой ошибки». Для современных систем управления виртуальной инфраструктурой это — неотъемлемые компоненты
Высокий уровень автоматизации позволяет перейти на следующий уровень и предложить сервисы самообслуживания для некоторых категорий ИТ-пользователей. Например, это может быть очень актуально для DevOps-команд, чьи запросы на выделение вычислительных ресурсов динамичны, а сроки сжаты. В этом случае взаимодействие может выглядеть следующим образом: инфраструктурная команда формирует и публикует список доступных сервисов на портале самообслуживания. Разработчик, который хочет получить виртуальный сервер, скажем, для тестирования релиза бизнес-приложения, заходит на портал, выбирает нужный сервис и подаёт заявку. Она принимается в работу и выполняется, включая конфигурирование, настройку и выделение доступа, с минимальным участием человека (или даже полностью без его вмешательства). Сами разработчики называют такой подход Infrastructure as Code.
Он по сути повторяет на локальном уровне принципы функционирования публичных облаков. Автоматизация рутинных процедур, упрощение управления и реализация сервисного подхода внутри в итоге приведут компании к схожему отношению к собственной ИТ-инфраструктуре. Инфраструктуре, которая достаточно продвинута, чтобы обеспечивать высокую производительность и надёжность, но при этом проста в управлении и работает незаметно даже для ее администраторов, не говоря уже о фактической «невидимости» для бизнеса.
