Переосмысление роли ИТ-службы при переходе в облако

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

▪ услугами облачных поставщиков пользуется 96% предприятий;

▪ многие предприятия применяют не меньше пяти облачных служб;

▪ компании продолжают наращивать расходы на услуги корпоративных публичных облаков;

▪ растет популярность частных облачных служб.

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

Как облако повлияет на внутреннюю структуру и стратегические приоритеты ИТ-отделов? Что нужно сделать ИТ-директорам, чтобы подготовиться к смене вычислительной парадигмы? Ответы на эти вопросы на портале InformationWeek дает CEO консалтинговой фирмы Transworld Data Мэри Шаклет.

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

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

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

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

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

Задача: контроль теневых ИТ. В 2015 г. Cisco провела исследование, которое выявило, что сотрудники предприятий для хранения критически важных данных задействуют в 15 раз больше облачных служб, чем это предусмотрено требованиями внутренних регламентов, не уведомляя ИТ-директоров. Облако — это один из инструментов теневых ИТ, предполагающий заключение индивидуальным пользователем договора/соглашения с облачным провайдером с последующей передачей ему части служебной информации, а также установку на свой рабочий компьютер программ без ведома ИТ-службы. Последняя, однако, в любом случае несет ответственность за соблюдение контрактных обязательств с облачными провайдерами, занимается отслеживанием активов, следит за производительностью рабочего окружения предприятия. Так как же взять под контроль теневые ИТ?

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

Задача: соблюдение мер безопасности. Предприятия как никогда уязвимы перед лицом угроз в виде теневых ИТ, повсеместно применяемых бизнес-пользователями. Это связано с тем, что они подписываются на облачные сервисы в обход процесса проверки SaaS на соответствие корпоративным политикам безопасности, чем могут нанести вред организации.

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

Задача: видоизменить операции по ликвидации аварий и управлению рисками. Исследование, проведенное в марте этого года 451 Research, показало, что около трети компаний не обладают набором политик, инструментов и процедур, позволяющих восстановить жизненно важную технологическую инфраструктуру и системы после аварий. Еще треть компаний хоть и имели подготовленные процедуры восстановления данных (Disaster recovery, DR), сообщили, что не уверены в своей катастрофоустойчивости. Большинство опрошенных компаний обладают планами для восстановления работоспособности систем во внутренних ЦОДах, говорится в исследовании, но они практически не предусматривают схем для восстановления систем и данных, которые хранятся в облаках.

Об этой проблеме заявил ИТ-директор консалтинговой фирмы West Coat: «Мы не тестировали ни один из DR-планов с нашим облачным провайдером, хотя знаем, что в контрактах мелким шрифтом прописано, что поставщики услуг не несут ответственности за сбои в работе систем или данных». Очевидно, что отсутствие DR-планов и управления рисками в облачной среде ставит предприятия в невыгодное положение.

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

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

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

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

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

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

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

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