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

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

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

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

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

Шаблон описания кейсов

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

Кейс 1

Название: Замена аппаратного обеспечения системы хранения данных.
Версия: 1.1.
Число: Ноябрь 21, 2004.
Краткое описание: Аппаратные компоненты, поддерживающие сервер 24x7, иногда выходят из строя и нуждаются в замене. Данное описание показывает, как SAN-система поддерживает замену компонентов без прерывания поставки сервисов.
Сценарии: Системный администратор обнаруживает, что жесткий диск в системе хранения данных не работает, и заменяет его на рабочий.
Основная роль: Системный администратор.
Дополнительная роль: Пользователь системы хранения данных, которому требуется непрерывный доступ к услуге. Менеджер, требующий замены компонентов системы.
Цель: Найти правильное решение обеспечению замены вышедшего из строя элемента системы хранения, не прерывая поставку основных услуг.
Выходные условия: Извещение посылается системным администраторам ответственным за поддержание ресурса с указанием компонента, вышедшего из строя. Новый компонент замещает старый, данные с которого автоматически сохранены посредством RAID-алгоритмов.
Триггеры: Это событие запускается при выходе из строя некоего аппаратного компонента системы. В этом случае выход из строя специфических компонентов маркируется, и системный администратор принимает меры по их замене.
Предварительные условия: Системный администратор должен быть зарегистрирован в SAN-системе.
Структура события:

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

Кейс 2

Название: Интеграция администрации серверных ресурсов.
Версия: 1.1.
Дата: Ноябрь 23, 2004
Краткое описание: Распределенные ресурсы хранения администрируются различными департаментами компании. Они объединяются в единую систему на основе SAN, имеющей централизованное управление.
Сценарий: Сервер под Windows с подключенными напрямую дисками добавлен в структуру SAN. После подключения сервера к SAN файловая система диска реплицирована в SAN, и ей придан статус первичной.
Основная роль: Администратор SAN.
Дополнительная роль: Администраторы серверов в отделах, которые ответственны за мониторинг производительности сотрудников и доступности услуг. Менеджмент бизнес-отделов, который должен заверить документацию о передаче контроля над дисковыми мощностями центральному управлению ИТ.
Цель: Интегрировать новый сервер в SAN, так чтобы размеры файлов и использование ресурсов могли мониториться с одной консоли одним администратором.
Выходные условия: Все перемены структуры организации хранения должны оставаться прозрачными для конечных пользователей. Все доступные пользователям сервисы, предоставляемые сервером, должны поставляться непрерывно и в том же виде, в котором поставлялись до перехода. Дисковые ресурсы сервера должны управляться SAN. Перенос файловой системы и порядок использования ресурсов определяются администратором SAN.
Триггеры: Это событие запускается, когда сервер некоего отдела наталкивается на проблемы, которые не могут быть решены усилиями ИТ-администратора отдела, - например, жесткие диски выходят из строя, или ИТ-администратор на уровне отдела недоступен.
Предварительные условия: SAN должен быть соответствующим образом сконфигурирован, чтобы интегрировать распределенные серверы требуемого типа. Менеджмент отделов должен работать над тем, чтобы передать административные обязательства централизованно администратору SAN.
Структура события:

  • распределенный сервер должен иметь специально приобретенный адаптер;
  • адаптер должен быть инсталлирован и сконфигурирован;
  • сервер подсоединен через адаптер к SAN;
  • необходимо убедиться, что дисковые ресурсы сервера доступны для SAN;
  • серверная файловая система должна быть замещена SAN;
  • необходимо убедиться, что мониторинг производительности системы показывает хорошие результаты на протяжении заданного промежутка времени;
  • событие считается закрытым, после того как менеджер отдела удостоверяет своей подписью, что сервис работает и соответствует бизнес-запросам.
Альтернативные пути: Для данного случая альтернативного хода событий не существует.
Исключительные ситуации: Если инсталляция адаптера не проходит успешно, ее прекращают. Причина несовместимости должна быть прояснена и скорректирована для того, чтобы завершить процедуру.
Отношение к другим событиям: Может возникнуть после заключения договоров на сервисное обслуживание системы.
Технические требования, Открытые проблемы, Замечания: ...

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

Шаблон обоснования проекта

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

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

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

Пример использования данного шаблона

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

Условия. Любое из предлагаемых решений должно:

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

Существующая ситуация. Сервер Microsoft Exchange 2000 был недоступен 10 и 23 сентября в совокупности в течение 4 часов в связи с недостатком дискового пространства. Это привело к необходимости приобретения нового жесткого диска 23 сентября, так как даже очистка логов, а также всех временных и вспомогательных файлов после первого переполнения диска не привели к долгосрочному результату. Exchange Server, кроме того, поддерживает базу данных Access, используемую в отделе продаж, которая также была недоступна в течение всего времени простоя.

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

Предлагаемые решения. ….

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

Стандарты. Отдел или комитет по стандартизации в компании должен рекомендовать менеджменту ИТ-отдела выработать стандарты резервного копирования и процедур восстановления критических данных.

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

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

Общие доходы. Количественные: в настоящий момент на ставке находятся семь администраторов на уровне отделов, в должностные обязанности которых входит на 20% обеспечение функции системной администрации. Высвобождая их для других задач, компания получает эквивалент 1,4 полной ставки. Неколичественные: качественное администрирование серверов, своевременные апгрейды и надежное резервирование данных снизят время простоя и увеличат время непрерывного доступа к сервисам. (Примечание: данный момент отнесен к неколичественным показателям по той простой причине, что хотя его и можно выразить некой цифрой, эту цифру достаточно тяжело предсказать. Предотвращение или сокращение времени простоя довольно тяжело отразить в цифрах. Поэтому наличие неколичественных преимуществ в документе и важно. Основным неколичественным преимуществом в данном случае является то, что посредством репликации достигается высокая степень защиты данных. Кроме того, в связи с созданием центральной копии базы данных системы могут быть восстановлены в случае катастрофических потерь данных.)

Ожидаемые затраты. ПО удаленного администрирования потребует приобретения семи дополнительных лицензий общей стоимостью $21.000. Тренинг и сертификация CSA (Central Services Administrator) в Microsoft 2000 Exchange - $7.500. (Примечание: мы не разворачивали в деталях финансовую информацию, поскольку это тема для отдельной статьи. Понятно, что вопросы устранимых, накладных и текущих расходов должны быть понятны ИТ-директору перед стартом работы над проектом. Эти вопросы ИТ-директор так или иначе должен будет обсуждать со специалистами из финансового отдела. Терминология здесь также может быть другая, свойственная специфике данной конкретной компании.)

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

Заключение

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