ИТ-инфраструктура

В конце марта этого года X5 Retail Group объявила о внедрении системы управления ИТ-мощностями. Автоматизация процессов, спроектированных на базе методик ITIL, помогли реформировать управление ИТ-инфраструктурой, состоящей из 173 тыс. конфигурационных единиц в трех дата-центрах и более 14,5 тыс. магазинов (сейчас уже более 15 тыс. магазинов – Н.С.). Как результат, за прошедший год расходы на закупку оборудования удалось сократить более чем на 300 млн руб. О реализации проекта в рамках форума «Инфраструктура 2019», который 18 июня проведет издательство «Открытые системы», расскажет Наталья Ким, начальник управления инфраструктурных решений ИТ X5 Retail Group.

- Как исторически в X5 управляли инфраструктурой? Какие были проблемы?

По сути управления как такового не было. Скорее это был учет инфраструктурных мощностей, размещенных в ЦОДе, который велся вручную в Excel. При этом невозможно было оценить критичность каждой конкретной единицы оборудования, их взаимосвязи с ИТ-системами. В компании порядка 300 ИТ-систем и изменения в конфигурациях инфраструктуры происходят ежедневно. Мы не знали достоверно, какая из систем сколько ресурсов потребляет, реальную загрузку оборудования с учетом индивидуального режима функционирования каждой ИТ-системы. Увеличение мощностей происходило реактивно – например, при снижении производительности приложения мы просто срочно добавляли ему ресурсов. Если такие были в резерве. Если нет – инициировалась длительная закупка. Иногда владелец системы мыслил проактивно и, зная о планируемых изменениях в ней, заранее заботился о добавлении ресурсов, основываясь на собственной экспертной оценке.

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

- В чем заключался переход на методику ITIL, как он был произведен?

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

- Как в общих чертах это все работает?

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

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

- Планировалось ли изначально автоматизировать работу по новой методологии, или эта идея пришла уже в ходе проекта?

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

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

- Что сейчас представляет собой система управления ИТ-инфраструктурой? Из чего состоит, какие решения используются?

Построенное нами решение состоит из четырех важных компонентов.

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

- Какой достигнут бизнес-эффект и за счет чего?

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

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

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

- Как определяется оптимальный размер резерва?

Резерв формируется исходя из статистики запросов бизнеса за предыдущий период. Она обновляется раз в квартал и, в зависимости от полученных показателей объёма тактического резерва мощностей, динамически меняется.

- Что внесло больший вклад: «наведение порядка» по ITIL или автоматизация процессов?

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

- Есть ли планы по развитию управления инфраструктурой?

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

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

В АО «Медицина» (клиника академика Ройтберга) стремятся использовать весь арсенал информационных технологий для повышения клиентоориентированности бизнеса. Это стремление находит отражение и в инфраструктурных проектах. О самом последнем из них Максим Петухов, ИТ-директор АО «Медицина» (клиника академика Ройтберга), расскажет на форуме ИНФРАСТРУКТУРА 2019, которую издательство «Открытые системы» проведет 18 июня. А пока он ответил на несколько вопросов CIO.ru.

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

- Клиника создавала инженерную и ИТ-инфраструктуру с запасом, но мир с каждым днем меняется все динамичнее. Хватает ли сегодня того «запаса», чтобы поддержать дальнейшее развитие бизнеса?

Бесконечный запас расширения создать невозможно, он ограничен средним временем жизни технологий. Если для софта можно все время поддерживать актуальную версию, то «железо» однозначно стареет.

Тот запас, который мы закладывали при проектировании инфраструктуры, по-прежнему играет свою роль. Мы спокойно увеличили там, где нужно было, количество компьютеров, которые подключаются к проводной сети. Возможности, которые были заложены в ЦОДе по размещению оборудования, нас устраивают.

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

И мы очень внимательно следим за сервисным обслуживанием оборудования ЦОДа, которым занимается внешний подрядчик. Возникающие небольшие проблемы устраняются как можно быстрее, это и служит залогом долгого срока службы.

1.  
2.  
3.  
4.  

Пред.След.

Года через три потребует замены система охлаждения. Тут мы рассчитываем на новый ЦОД в нашем онкологическом центре, который сейчас строится в Химках. Он будет аналогичен по возможностям нынешнему ЦОДу, и мы получим географически распределенную, отказоустойчивую и даже катастрофоустойчивую инфраструктуру. Все информационные системы, которые сейчас работают на оборудовании действующего ЦОДа, смогут мигрировать и продолжить работу там. Эта мера позволит установить новое оборудование, провести модернизацию системы охлаждения, замену стоек. Инфраструктурные возможности нового онкологического центра будут служить всей клинике в целом. При его проектировании мы закладываем возможности расширения и плавной замены ИТ-оборудования.

- Как часто бизнес ставит перед ИТ-службой клиники задачи, требующие модернизации инфраструктуры?

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

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

- Какими подходами вы руководствуетесь в управлении инфраструктурой? Много ли внимания вы ей уделяете?

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

Мы используем две системы мониторинга. Первая, приобретенная вместе с сетевым оборудованием Hewlett-Packard, служит для его мониторинга, контроля изменений конфигураций. Вторая, Zabbix, более универсальна и позволяет отслеживать параметры всего оборудования и информационных систем. Недели не проходит, чтобы мы не ввели в нее какой-то новый параметр или сценарий работы оповещений. Это та система, которую мы все время наращиваем.

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

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

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

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

- Что вы расскажете участникам конференции «Инфраструктура» и что вам самому будет интересно?

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

Мне на конференции будет интересно подтвердить свой опыт и расширить свои знания. А также увидеть, как другие компании применяют технологии, к которым мы относимся осторожно из-за крайне серьезного подхода к защите персональных данных. Посмотреть на удачный опыт коллег по переносу в облако сервисов с учетом всех аспектов защиты персональных данных и удобства доступа внешних и внутренних заказчиков, по модернизации ЦОДа c использованием гиперконвергентной архитектуры. Это очень полезно, чтобы мы могли учиться не только на своих ошибках.

Faberlic – российская косметическая компания, работающая по модели прямых продаж, одна из самых крупных в мире – в 2017 году в мировом рейтинге компаний, ведущих бизнес по этой модели, Faberlic занимала 38-е место. Представительства Faberlic открыты в 20 странах, с компанией сотрудничают более миллиона консультантов, ее продукцией пользуется около 8 млн потребителей.

Активно развивающийся бизнес Faberlic требует и соответствующей ИТ-инфраструктуры. При реализации новой версии основной учетной системы в компании взяли за основу облачную микросервисную архитектуру. Почему именно ее, как осуществляется проект и какие еще задачи в Faberlic доверяют облакам, рассказал Валерий Капленко, директор по ИТ компании. А на форуме ИНФРАСТРУКТУРА 2019, который издательство «Открытые системы» проводит 18 июня, о деталях использования облаков и гибридной инфраструктуры в Faberlic можно будет узнать от CTO компании Романа Варникова.

По словам Валерия Капленко, активно развивающийся бизнес Faberlic требует и соответствующей ИТ-инфраструктуры; при реализации новой версии основной учетной системы в компании взяли за основу облачную микросервисную архитектуру

- Расскажите о бизнесе компании, какие требования он предъявляет к ИТ-инфраструктуре?

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

Наша учетная система создавалась, когда у компании было 200 маленьких складов. Для каждого такого склада велась небольшая база данных на Oracle Express, информация из этих баз собиралась и реплицировалась в центральную базу данных.

Это был не очень эффективный подход. Наши дистрибьюторы объединены в так называемое MLM-дерево (Multi Level Marketing), и продажа в конце «ветки» дерева, скажем, в Монголии, влияет на бонусы дистрибьютора, который является «наставником» этой ветки. Такую информацию необходимо собирать онлайн; в первоначальной же версии системы это делалось путем закачки файлов, а репликация работала не всегда, иногда приходилось использовать почту для обмена данными.

Поэтому было решено создать систему, которая объединила бы все данные о маркетинговых бонусах всех консультантов во всех странах, где работает Faberlic. Такая система разрабатывалась около десяти лет полностью on-premise на основе базы данных Oracle с надстройкой в виде веб-клиента.

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

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

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

- В чем основные особенности новой архитектуры?

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

Компания выбрала облако Oracle Cloud, поскольку предыдущая версия основной учетной системы реализована на базе решений Oracle, и у нас большой опыт работы с продуктами этого вендора и его партнерами.

- Почему именно микросервисы, что дает такой подход?

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

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

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

Пример для нашей системы – подключение службы доставки. Микросервисная архитектура позволяет создать для этого отдельный сервис, подключить его через механизм Discover API и быстро начать с ним работать. Такая гибкость очень важна для бизнеса.

- На какой стадии находится переход к микросервисной архитектуре?

Сейчас проходит пилотное развертывание. Мы «отправили» в облако контейнеры, начали трансляцию данных, в облачных средах разработки ведется работа над различными сервисами. Первые сервисы планируем запустить в июле, до конца года намечено перевести в облако наиболее критичные сервисы и в течение 2020 года – полностью развернуть всю архитектуру.

Облачная архитектура микросервисов – часть большого проекта обновления корпоративной системы «Партнер 2.0», в который входит также фронт-офисная часть на SAP Hybris, разработка мобильного приложения и другие взаимосвязанные компоненты.

- Микросервисы в Oracle Cloud – не единственный облачный компонент ИТ-инфраструктуры компании?

Мы любим облака и работаем с разными их вариантами. Мы первыми в России развернули в Microsoft Azure бизнес-приложение в стадии эксплуатации – BI-систему, которую продолжаем развивать на облачной платформе. Есть свое частное облако, для ряда проектов используем публичные облачные сервисы «Ростелекома».

- Стыковка многочисленных облаков не создает проблемы?

Это сложная, интересная и многогранная задача, которая возложена на наше инфраструктурное подразделение.

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

Участники дискуссии оказались единодушны во мнении, что интерес к цифровой трансформации в России очень высок и у многих он уже переходит во вполне практическую плоскость. «Самая заметная тенденция последнего времени – то, что компаний, которые хотят быть в ’цифровом тренде’, все больше», — считает Шамиль Хайретдинов, директор департамента логистики МТС. При этом больше становится и тех, кто разочаровывается в определенных технологиях цифровизации, например в Больших Данных, но это «разочарование в хорошем смысле», полагает Хайретдинов, поскольку свидетельствует о более осмысленном подходе к тому, как работать с Большими Данными, чтобы получать от них реальный результат. В департаменте логистики МТС создается озеро данных и тестируются инструменты машинного обучения для оценки перспектив выполнения заказов в зависимости от разных факторов. Эти решения обещают стать хорошим подспорьем для сотрудников департамента в их повседневной работе.

При этом часть процессов по закупкам в компании скоро будет вообще обходиться без участия человека. Хайретдинов высоко оценивает потенциал RPA: тестирование продемонстрировало высокую эффективность роботизации бизнес-процессов, и в 2019 году планируется охватить этой технологией более 20 процессов департамента. «'Пилоты' показывают, что с помощью RPA можно ускорить операционные процессы закупок и логистики на 30-60%», — рассказал он.

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

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

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

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

Ильин рассказал, что переход от таблиц Excel к облачной версии Hyperion обеспечил полную прозрачность бюджетного планирования и позволил охватить им каждого из 32 тыс. страховых агентов, что открывает новые возможности повышения мотивации персонала.

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

Разумеется, у ИТ-инфраструктуры есть много других свойств, наличие которых помогает проведению цифровых трансформаций на предприятии (например, система управления ИТ на основе объективных данных), но вышеперечисленные три свойства — это необходимый минимум. Если какого-то из них нет, то цифровую трансформацию начинать нельзя. К сожалению, сегодня именно эта ситуация характерна для подавляющего большинства российских организаций. Первым делом им нужно привести в порядок «технологический фундамент». С чего же начать и что именно сделать, чтобы подготовка прошла легче и быстрее? А сделать нужно немного.

Шаг № 1. Почистить ИТ-организм — провести входной аудит

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

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

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

Шаг № 2. Обеспечить простую и недорогую масштабируемость ИТ-инфраструктуры: гибридные схемы и сайзинг ресурсов в IaaS

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

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

Однако тут заказчика подстерегает еще одна проблема. Поставщики ресурсов в IaaS традиционно нацелены на то, чтобы продавать как можно больше (overselling). Это приводит к тому, что покупатели столь же традиционно переплачивают за ресурсы вдвое-втрое, а то и вчетверо. Причем из-за нехватки информации переплачивать приходится за все виртуальные ресурсы (процессоры, память и др.). Наиболее крупные и дорогие IaaS-провайдеры смягчают эту ситуацию, позволяя крупным клиентам отслеживать реальное потребление мощностей. Но для среднего бизнеса такие инструменты слишком дороги, да они и не продаются отдельно от платформ. А привязка к платформе — это тоже риск. Однако эффективные решения есть: например, услуга автоматизированного сайзинга ресурсов позволяет при работе с любыми IaaS-провайдерами точно, без переплат, спланировать потребление ресурсов и платежи за мощности в облаке.

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

Шаг № 3. Поддержать высокую изменчивость — начать непрерывный ИТ-аудит

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

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

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

Шаг № 4 (дополнительный). Обеспечить постоянное взаимодействие команд на проектах по цифровой трансформации

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

Сегодня наилучшим способом преодолеть этот давний «камень преткновения» является выстраивание горизонтальных связей между командами в виде системы процессов, дополненной современными средствами коммуникации «для данного случая» (ad hoc). Если организация решает внедрить технологии управления Agile, нужно тщательно выбрать конкретную методику, настроить соответствующие процессы (чемпион здесь — Scrum) и уделить большое внимание компетенциям участников. В любом случае (даже если перехода на Agile нет) помогает формирование небольших рабочих DevOps-групп под проекты (в том числе и по цифровой трансформации). В эти группы входят представители каждой из вышеперечисленных команд. Однако всем им нужна общая информационная среда и доступ к постоянно обновляющейся информации в ней — о состоянии всего проекта и его составных частей. Чтобы каждый мог наблюдать и анализировать одни и те же тренды, осуществлять правильные и своевременные корректирующие действия. И не каждая команда — только по своему участку, а совместно, по общему ходу проекта. DevOps-группы в проектах цифровой трансформации должны стать потребителями объективных данных об информационных системах и инфраструктуре, чтобы своевременно принимать взвешенные и правильные для компании решения.

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

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

Из чего состоят гиперконвергентные решения

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

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

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

• Гипервизор и виртуальные машины

Гипервизоры бывают разными, и в зависимости от потребностей компании можно использовать различные решения. Сегодня существуют проприетарные гипервизоры, такие как Microsoft Hyper-V или VMware vSphere, а также решения с открытым исходным кодом, например KVM с хорошим потенциалом и качественной архитектурой. В недавнем прошлом наша компания приняла решение создать свой собственный гипервизор именно на базе KVM. Тем самым удалось получить прирост производительности и эффективности утилизации ресурсов для целого ряда распространенных задач, а также обеспечить совместимость с open-source-экосистемой KVM.

• Контейнеры приложений

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

• Хранилище данных

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

Реальная экономия от применения гиперконвергенции

Популярность гиперконвергентных решений продолжает расти: только за 2016 год аналитики зафиксировали рост на 80%, и, по оценкам Gartner, системы нового класса займут около четверти рынка интегрированных систем уже в 2019 году (в 2012 году их доля была практически нулевой).

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

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

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

Но и это еще не все: гиперконвергентные системы позволяют экономить средства на обеспечение соответствия требованиям регуляторов. С 1 июля в России вступил в силу «закон Яровой», при этом никто не отменял закон «О персональных данных» и другие нормативные акты. Все компании, обслуживающие в том числе европейские рынки, обеспокоены на сегодняшний день требованиями GDPR, выполнить которые без обеспечения высокой доступности данных оказывается просто невозможно.

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

Перспективы развития систем

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

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

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

Автор – Алексей Кобец, старший вице-президент по разработке Virtuozzo.

Черные пятницы и киберпонедельники – источники радости для покупателей и периоды наибольшей занятости для многих продавцов. В компании Hudson’s Bay Company (HBC), которой принадлежат торговые марки Lord & Taylor, Saks 5th Avenue и ряд других, прошлогодняя предпраздничная лихорадка стала самым подходящим поводом для испытания новых функций веб-сайтов.

HBC использует типичный сервер приложений Oracle WebLogic и платформу электронной коммерции Blue Martini, предлагаемую разработчиками RedPrairie. Общий ее стек создавался и совершенствовался на протяжении многих лет. «Она работала, но были проблемы с ее развертыванием, сложно было вносить изменения и обновления», – указал Мэтью Пик, управляющий в HBC командой инженеров по инфраструктуре.

Инженеры HBC стали выяснять, как можно решить эти вопросы. Для решения проблемы были предложены микросервисы и контейнеры.

Для начала реализации своего проекта по смене платформы Пик выбрал Product Detail Page (PDP). PDP представляет собой часть приложения электронной коммерции, в котором содержатся описания и фотографии товаров. Вместо того чтобы встраивать PDP в приложение, разработчики из HBC разбили его на 12 отдельных микросервисов, размещавшихся в контейнерах приложения (один из них загружал изображения, другой обслуживал текстовую часть и т. д.).

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

Запуская PDP в прошлогодние черную пятницу и киберпонедельник, HBC решила подстраховаться и направила на микросервисы PDP лишь часть трафика. В случае возникновения нештатных ситуаций их можно было бы отключить и вернуть весь трафик в традиционное русло. «Мы не стали рисковать всем сайтом, – вспоминал Пик, следивший за ситуацией на протяжении всего запуска новых технологий, с пятницы и до понедельника. – Но рано или поздно настает момент, когда нужно просто сказать: “Давайте попробуем”».

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

Что такое микросервисы?

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

Звучит знакомо? Несложно предположить, что микросервисы восходят к модному термину прошлых лет – сервисно ориентированной архитектуре (SOA), воплощавшей идею создания независимых отдельных компонентов приложения.

«Заинтересованность предприятий в микросервисах объясняется поиском нового подхода к построению сервисно ориентированной архитектуры, а также к использованию микросервисов с контейнерами», – пояснил старший вице-президент консультационной компании Cloud Technology Partners Дэвид Линтикум.

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

Преимущества

Микросервисный подход дает следующие преимущества:

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

Частичные нарушения. Если какой-то компонент приложения перестает работать, нет опасности того, что откажет все приложение полностью. «Цель заключается в том, чтобы сузить круг неисправностей и минимизировать их последствия», – пояснил аналитик 451 Research Донни Беркхольц. Например, если банковский сайт создан с использованием микросервисного подхода, при отказе функции перевода денег возможность проверить свой баланс у клиентов все равно остается.

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

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

Задачи

По мнению Беркхольца, у команд, исповедующих agile-проектирование или концепцию DevOps, больше шансов преуспеть в создании микросервисов. DevOps – это объединение функций разработчиков и операционных функций, повсеместное или в каких-то отдельно взятых командных проектах.

В таких средах код пишется, тестируется и внедряется быстрее. Многие предприятия, придерживающиеся концепции DevOps, имеют автоматизированную инфраструктуру с самообслуживанием – например, виртуализированные или облачные среды для тестирования и разработки или для поставки уже готовых приложений. Исследования, проведенные 451 Research, показывают, что две трети организаций применяют при разработке приложений методологию agile-проектирования, а около 40% – концепцию DevOps. Именно в таких организациях вероятность успешного внедрения микросервисов наиболее высока. У компаний, не придерживающихся тенденции разработки следующего поколения, процесс перехода к микросервисам будет протекать сложнее.

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

Инфраструктура оказывает на микросервисы и другое воздействие. Аналитик Forrester Дэйв Бартолетти утверждает: когда разработчики в организациях начинают следовать новым тенденциям, роль ИТ-инфраструктуры меняется.

«Разработчики, выстраивающие микросервисы, не идут в ИТ-службу оформлять заявку на новую виртуальную машину, – пояснил он. – При agile-проектировании разработчики вправе ожидать, что инфраструктурные ресурсы будут автоматически выделяться им по требованию через API и эластичное масштабирование».

Для поддержки инфраструктурной среды такого рода существует множество различных инструментов. Строить внутреннее облако можно при помощи программного обеспечения для частных облаков, предлагаемого VMware или OpenStack. Если ИТ-служба не хочет заниматься построением инфраструктуры самостоятельно, она может обратиться к платформам публичных облаков Amazon, Microsoft, Google и других поставщиков. Автоматизировать управление инфраструктурой можно при помощи платформ PaaS Cloud Foundry или Red Hat. Для приложений, управляемых событиями (например, для сценариев Интернета вещей), идеально подходят так называемые бессерверные вычислительные платформы. Каждая такая платформа меняет роль ИТ-службы – теперь перед ней могут ставиться разные задачи, начиная от поставок инфраструктуры и заканчивая построением среды, где разработчики самостоятельно будут развертывать микросервисы.

Для чего микросервисы подходят лучше всего

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

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

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

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

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

– Brandon Butler. What you need to know about microservices. Network World. November 9, 2016

Данные о состоянии окружающей среды, собранные на территории нашей страны, накапливаются гидрометеорологической службой России многие десятилетия. На их основе строятся прогнозы климата, проектируются инженерные сооружения, формируются долгосрочные планы развития территорий, разрабатываются экономические программы. Сейчас эта важная информация аккумулируется в архивах ФГБУ «Всероссийский научно-исследовательский институт гидрометеорологической информации – Мировой центр данных», точнее, в одном из его подразделений – в Центре гидрометеорологических данных, расположенном в Обнинске Калужской области. Исторически сложилось так, что почти все данные центр хранил на магнитных лентах.

От перфокарт – к лентам

В 1964 году правительство СССР постановило создать в Обнинске отделение хранения и статистической обработки гидрометеорологических данных Мирового метеорологического центра. С тех пор именно здесь сконцентрированы работы по сбору, учету и хранению материалов наблюдений и исследований в области метеорологии, аэрологии, агрометеорологии и морской гидрометеорологии. На базе этого подразделения приказом Госкомгидромета в январе 1979 года собственно и был организован Центр гидрометеорологических данных. «До 1970-х годов долговременное хранение и машинная обработка гидрометеорологических данных осуществлялись на перфокартах, но работать с ними при накоплении больших объемов данных было сложно, неудобно, требовались большие площади для хранения, и уже тогда было ясно, что их нельзя рассматривать как долговременный носитель информации», – рассказывает начальник Центра гидрометеорологических данных ВНИИГМИ-МЦД Владислав Шаймарданов.

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

Почти до 1997 года все поступающие в центр данные записывались на бобины с магнитными лентами. Затем архив был перенесен на более компактные носители с высокой плотностью записи – магнитоленточные картриджи. Но эти системы долговременного хранения еще не были роботизированными.

Архитектура для библиотек

В 2010 году в институте был в целом завершен многолетний проект модернизации ИТ-инфраструктуры и переноса гидрометеорологических данных на современные носители информации.

Как пояснил Шаймарданов, сейчас главным звеном в архитектуре системы хранения центра является пара роботизированных ленточных библиотек максимальной емкостью 4 Пбайт каждая. Это два ряда устройств хранения, в одном из которых 17 библиотечных шкафов, а в другом – 14. Управляет работой библиотек мэйнфрейм с операционной системой Linux. Он сопряжен с дисковым массивом общей емкостью порядка 100 Тбайт. Массив используется по сути как «внешний диск» для мэйнфрейма. Запись данных на картриджи с целью резервного копирования осуществляется специализированным ПО.

«Лента – наиболее подходящий инструмент долговременного хранения. Удельная стоимость хранения данных на ней оптимальна. Использовать для создания архива жесткие диски – дорого и не очень ненадежно. Мы также присматривались к оптическим библиотекам, но возникли опасения, что через некоторое время DVD могут выйти из строя и данные на них будут потеряны. К тому же у нас просто нет необходимости скоростной потоковой записи и чтения данных. Мы записываем их постепенно и последовательно, скорость для нас – не главное», – сообщил Шаймарданов.

Нюансы хранения и доступа

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

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

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

По регламенту данные из гидрометеорологического фонда не могут быть доступны напрямую любому потребителю. Поэтому, если необходимо предоставить к ним доступ, часть архивов выгружается либо в СУБД, либо в другие средства для работы с файлами на жестких дисках. Затем пользователь формирует запрос, получает одобрение и доступ к нужным данным.

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

С другой стороны, и библиотека не целиком используется для архивных нужд. Часть ее отрезана логически и представляет собой отдельную подсистему, которая тоже нужна для оперативной работы, прежде всего для создания цифровых копий документов уже из бумажного архива. Он, к слову, насчитывает более 352 тыс. единиц хранения в самом институте, а в целом российской службой по гидрометеорологии накоплено более 2 млн единиц хранения, рассредоточенных в подразделениях по всей России. Поэтому вопрос оцифровки бумажных источников данных является актуальным для Росгидромета.

***

По словам Шаймарданова, в настоящий момент возможности, заложенные в архитектуре системы, достаточно широки, поэтому в ближайшие десять лет она должна полностью обеспечить все нужды Росгидромета в надежном хранении данных. При этом по-прежнему актуальна задача развития структурных элементов системы: отдельные узлы нуждаются в обновлении, необходимо постоянно повышать скорость доступа к сохраненным материалам и инструментам для обработки метеоданных. Развивать систему в центре планируют эволюционным путем. Устаревшие диски или элементы библиотек будут меняться на более совершенные версии по мере их появления на рынке. А вот от мэйнфрейма в центре, скорее всего, откажутся и перейдут на альтернативную платформу управления библиотеками. Задачи, которые он решает, уже могут быть перенесены на устройства стандартной архитектуры x86. В этой связи центр ведет активные программные разработки под системы Linux и Unix.

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

Санкт-Петербургский государственный университет – старейший вуз России, он основан в 1724 году. За почти триста лет существования СПбГУ аккумулировал в архивных и библиотечных фондах огромное количество научных и исследовательских материалов, книг, периодики. Когда-то их просто складывали на полки. В нынешний век электронных медиа и информационных технологий задачи архивного хранения в университете усложняются – фонды пополняются терабайтами данных, полученных в ходе научных изысканий, цифровыми копиями с бумажных носителей и тысячами часов записей видеоконтента. Одним из вариантов повышения эффективности систем долговременного хранения в СПбГУ считают применение оптических технологий. Несколько месяцев назад ИТ-служба университета приступила к тестированию роботизированной библиотеки на дисках Blu-ray.

Список задач

Как пояснил исполняющий обязанности начальника Управления-службы информационных технологий СПбГУ Андрей Жамойдо, одна из наиболее актуальных задач, которую сейчас решают в университете, связана с долговременным хранением видео: «Существует ряд законодательных требований к продолжительности хранения некоторой видеоинформации, и мы должны соблюдать эти требования. В частности, мы обязаны сохранять все записи защит диссертаций (а за год это почти триста событий). Этот объем данных довольно большой. Кроме того, уже начиная с этого года по инициативе ректора СПбГУ мы будем публиковать в открытом доступе все дипломные работы наших студентов до даты защиты. Это большой и важный проект, он будет реализован в СПбГУ в рамках проекта “Открытое образование”».

Кроме того, СПбГУ реализует долгосрочный проект, в рамках которого будет записываться весь процесс обучения студентов с первого курса до завершения учебы. Разумеется, видеоконтент будет адаптирован и обработан, для того чтобы можно было воспользоваться этими записями и получить готовый образовательный продукт (в том числе для формирования курсов дистанционного обучения). Но университету придется хранить и сырые видеоданные. Это позволит при необходимости вернуться к исходным материалам и убедиться в том, что во время редактирования ничего не было потеряно.

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

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

К выбору оптимального решения

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

Летом 2014 года компания Panasonic предложила СПбГУ рассмотреть вариант внедрения системы долговременного хранения данных на основе роботизированной оптической библиотеки LB-DH8 на дисках Blu-ray.

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

Библиотека имеет модульную конструкцию, и ее емкость может быть легко увеличена. Данные хранятся в картриджах, каждый из которых содержит 12 оптических дисков и может хранить в совокупности до 1,2 Tбайт данных. В систему входят базовый модуль (устройство записи картриджей), модуль расширения и загрузчик картриджей. Максимальная загрузка каждого модуля – 76 картриджей. Таким образом, в одном модуле можно хранить до 91,2 Tбайт данных. В зависимости от требуемого объема хранения в 19-дюймовую стойку устанавливается нужное число дополнительных модулей расширения. В максимальной конфигурации с семью модулями в стойке емкость библиотеки увеличивается до 638,4 Tбайт.

В модулях чтения-записи установлены по 12 приводов, это позволяет системе одновременно работать с 12 оптическими дисками и очень быстро считывать и записывать данные (со скоростью до 216 Мбайт/с). Заявленный производителем ресурс хранения данных на дисках составляет не менее 50 лет.

Притягательная экономичность

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

Жамойдо указывает на преимущества этой системы долговременного хранения: «Прежде всего у нее очень низкие операционные расходы. В режиме Stand-by, когда система не производит операций чтения-записи, модуль потребляет всего 7 Вт. Для архивного хранения это как раз характерный режим использования. Ведь к части накопленных архивных видеоматериалов обращаются довольно редко – например, из видеозаписей защит диссертаций для просмотра запрашивается одна из сотни».

Когда система на дисках Blu-ray не производит операций чтения-записи, модуль хранения потребляет всего 7 Вт электроэнергии Источник: Panasonic

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

Также, по оценкам специалистов СПбГУ, библиотека Panasonic производит операции записи и чтения значительно быстрее, чем имеющаяся ленточная библиотека.

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

Если результаты тестирования библиотеки Panasonic удовлетворят СПбГУ, на ней планируется разместить прежде всего видеоархив, затем архив служебных документов, возможно, мастер-копии сканов научной библиотеки им. М. Горького СПбГУ, результаты научных экспериментов – то есть все виды данных, которые генерируются в больших объемах, но востребованы бывают спорадически. Это позволит университету решить основные задачи длительного хранения, а заодно высвободить емкость более дорогой и более быстрой системы хранения данных IBM XIV, чтобы использовать ее для других приложений.

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

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

Непредвиденные обстоятельства

Еще в 2008 году компанией было принято решение создать специальный Центр хранения сейсмической информации (ЦХСИ) на базе научно-исследовательского и проектного института «РН-КрасноярскНИПИнефть» (хотя сама идея создания подобного банка данных вынашивалась давно). Центр должен был решить важнейшие задачи по сбору, обработке и интерпретации полевых данных, полученных в ходе сейсмических исследований, а также обеспечить их длительную сохранность и предоставление оперативного доступа к ним пользователей «Роснефти».

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

Созданию технологического комплекса ЦХСИ препятствовали некоторые внезапно возникшие обстоятельства, с которыми в тот период, вероятно, столкнулись многие российские компании.

«Изначально мы планировали построить комплекс на базе оборудования компании Sun Microsystems. Но, поскольку стоимость проекта была высокой, приобретение оборудования затормозилось, а за это время произошли серьезные изменения на рынке – Oracle приобрела Sun, и было неясно, как в дальнейшем станет развиваться ее продуктовая линейка и обеспечиваться техническая поддержка», – рассказывает Леонид Афанасьев, главный специалист – заместитель начальника отдела технологий ГРР и проектирования «РН-КрасноярскНИПИнефти».

Из планируемого списка оборудования (пять серверов, три дисковые системы хранения и две ленточные библиотеки) были приобретены лишь один сервер Sun для СУБД Oracle и одна система хранения данных Sun.

«В результате мы приняли решение отказаться от построения комплекса на базе серверов и систем хранения Sun и перенести систему на платформу x86 и оборудование компании IBM», – пояснил Афанасьев.

Таким образом, комплекс был построен на базе серверов IBM System X и рабочих станций на базе процессоров x86-архитектуры. Также в системе используются: ленточная библиотека IBM TS3200 и ленточные приводы IBM и HP; система хранения данных IBM. Сеть хранения данных построена на коммутаторах SAN компании IBM (Brocade), а сеть передачи данных (Ethernet) – на коммутаторах Cisco.

То есть собственно система долговременного хранения данных ЦХСИ не работает отдельно – она тесно интегрирована с другими элементами построенного комплекса. Поэтому каждый из них следует рассмотреть подробнее.

Интегрированный комплекс

Первый элемент – система ввода исходной информации – это не что иное, как специализированные рабочие станции с подключенными к ним устройствами ввода-вывода различных форматов: Exabyte (ленты 8 мм), DAT (ленты 4 мм), DLT, LTO разных поколений, IBM TS и др. В состав системы ввода-вывода также включены оптические приводы DVD; пока встречается даже такая экзотика, как диски ZIP.

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

Второй элемент – система хранения данных – включает в себя ленточную библиотеку, серверы баз данных Oracle и сервер хранения, играющий роль сетевого хранилища (NAS), а также сервер обработки (облачных вычислений).

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

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

Для хранения больших объемов обработанных сейсмических данных (кубов 3D) используется другой подход: данные регистрируются в системе и помещаются на дисковый массив в виде объекта базы данных BFILE (внешний двоичный файл External Binary File). Такой объект хранится вне базы данных как файл операционной системы, но он доступен из таблиц БД.

А вот результаты обработки сейсмических профилей 2D хранятся непосредственно в базе данных Oracle в файлах данных типа BLOB (Binary Large Object).

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

Что касается системы предоставления доступа к данным, то она представляет собой кластер из двух веб-серверов Аpache.

Предпочтение – лентам

Большая часть данных ЦХСИ хранится на лентах. Основным носителем данных являются ленты LTO третьего, четвертого и пятого поколений. В следующем году центр планирует начать использовать ленты шестого поколения.

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

На жесткие диски системы хранения отправляются файлы данных СУБД Oracle и BFILE (которые по сути тоже являются объектами Oracle). Есть также отдельная категория данных – результаты работ с сейсмической информацией. Это отчеты и графические приложения к отчетам. До недавнего времени такие материалы записывались на оптические носители CD и DVD, сейчас же они переносятся в базы данных и доступны уже не в виде краткого описания, а в виде полноценного файла отчета, содержащего графические приложения. Это стало возможным благодаря увеличению объема дискового массива системы хранения.

***

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

Также в настоящее время в ЦХСИ тестируется технология автоматизации переноса исходных полевых данных на ленты LTO. А в отдаленной перспективе специалисты «РН-КрасноярскНИПИнефти» рассчитывают построить полностью автоматизированное хранилище, где основное обслуживание системы хранения сейсмических данных «Роснефти» будут выполнять роботизированные системы.