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

Задачи оптимизации

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

• непрерывность обслуживания;
• наращивание производительности (вычислительных мощностей);
• снижение стоимости поддержки;
• обеспечение информационной безопасности компании.

Данные задачи решаются за счёт достаточно широкого набора методов, которые можно условно объединить в группы:

Однако, прежде чем перейти к более детальному анализу вышеуказанных подходов, необходимо сделать одно важное замечание.

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

Зачем нужно обследование?

На рисунке ниже изображена классическая схема зависимости бизнес-процессов от IT-инфраструктуры.

Как вы можете видеть, прямой зависимости нет, поскольку автоматизируются бизнес-процессы за счёт различных программных управляющих комплексов (например, различные ERP-, CRM-системы). А вот уже сами программные комплексы зависят от существующей инфраструктуры напрямую.

Для одной системы наиболее критичными могут являться, к примеру, сети передачи данных, для другой – количество выделенных виртуальному серверу объёмов памяти и дискового пространства, для третьей – не столько объёмы выделенной памяти, сколько её быстродействие.

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

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

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

Подходы для решения задач оптимизации ИТ-инфраструктуры

Отказоустойчивость

Поддержание непрерывности работы всех автоматизированных бизнес-процессов, а значит, выход из строя какого-либо компонента IT-инфраструктуры не должен приводить к их деградации или же полной остановке. Это, в свою очередь, значит, что в IT-инфраструктуре не должно присутствовать единичных точек отказа (англ. SPOF – Single Point Of Failure).

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

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

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

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

Катастрофоустойчивость

Часто бывает так, что отказоустойчивой инфраструктуры недостаточно для непрерывной работы бизнеса. Если, к примеру, ваш основной вычислительный кластер расположен в сейсмоопасном регионе, а построенный на нём программно-аппаратный комплекс управляет географически распределённым производством, то сам ЦОД (центр обработки данных) целиком становится единичной точкой отказа.

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

Создание запасного ЦОДа всегда связано с серьёзными вложениями и высокими операционными расходами, поэтому необходимо чётко понимать, насколько данные инвестиции будут соизмеримы с возможными потерями, связанными с простоем в работе программно-аппаратного комплекса (ПАК) на основном объекте. По этой причине в качестве резервного ЦОДа очень часто используются арендованные вычислительные мощности специализированных сервис-провайдеров, а реально защищаются от возможных катастроф только самые необходимые сервисы и приложения.

Виртуализация IT-инфраструктуры

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

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

• повышение отказоустойчивости и катастрофоустойчивости;
• изоляция служб;
• возможность гибкого распределения ресурсов между службами;
• использование операционных систем, которые наилучшим образом подходят для решения конкретных задач;
• экономия места в стойках;
• снижение энергопотребления и тепловыделения;
• упрощение администрирования;
• широкие возможности по автоматизации развертывания и управления серверами;
• снижение вынужденных и запланированных простоев системы за счет failover-кластеров и live migration.

Организация «частных облаков»

Дальнейшим развитием технологий виртуализации является концепция «частного облака» (англ. Private Cloud), когда серверы объединяются в пул, из которого на решение определённых задач выделяются вычислительные ресурсы, не привязанные к конкретным физическим серверам. Такие облака строятся на базе ЦОДа компании, что позволяет сделать IT-услуги ещё более «эластичными», при этом, в отличие от использования публичных облачных сервисов, остаются полностью закрытыми все вопросы безопасности и соблюдения конфиденциальности данных, расположенных в частных облаках.

Гибридная IT-инфраструктура

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

Главным преимуществом данного подхода является возможность сэкономить (причём иногда весьма существенно) на развитии собственной IT-инфраструктуры.

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

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

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

Автор:

Источник