| Рубрикатор |  |
 |
| Статьи |  |
ИКС № 03 2014 | |
|
| Заурбек АЛЕХИН Дмитрий БАСИСТЫЙ | 11 марта 2014 |
Служба эксплуатации российского ЦОДа. Портрет в интерьере XXI века. Ч. 1
Вооружившись как инструментом операционной моделью процессов эксплуатации инженерной инфраструктуры ЦОДа, авторы попытались написать «среднестатистический портрет», для которого им позировали несколько десятков реальных дата-центров.
О портретной технике
Дата-центр представляет собой сложный комплекс зданий и сооружений, инженерных систем и сетей, ИТ-инфраструктуры и прикладных программных систем. Но нет технических систем, которые были бы вечны и не требовали к себе внимания. Для любой системы необходим правильный уход – правильная эксплуатация.
Суть эксплуатации с точки зрения нормативной документации (стандартов) заключается в следующем*:
Эксплуатация – стадия жизненного цикла изделия, на которой реализуется, поддерживается и восстанавливается его качество. Эксплуатация изделия включает в себя в общем случае использование по назначению, транспортирование, хранение, техническое обслуживание и ремонт.
Для любой последовательности операционных процессов, в том числе и для эксплуатации, можно и нужно создавать, а впоследствии – анализировать модели этих последовательностей, позволяющие объединить их в логически связанные структуры, направленные на достижение целей деятельности. Для модели набора операционных процессов, к которым относится и эксплуатация, применяется термин «операционная модель» или «операционная модель эксплуатации».
Наиболее точное, на наш взгляд, определение термина operating model приведено в Википедии**:
Операционная модель – это абстрактное представление применяемых способов и порядка реализации корпоративной стратегии в повседневной деятельности компании; она объясняет, каким образом компания организует и использует имеющиеся у нее ресурсы для того, чтобы изо дня в день выполнять текущие операции, наилучшим образом воплощая свою бизнес-стратегию.
Существует и понятие подхода к эксплуатации – это совокупность приемов и способов ведения дел, используемых для эксплуатации конкретной организацией. В отличие от модели, являющейся по сути неким упрощением реальной ситуации, служащим для ее анализа и изучения, подход – это сама реальная ситуация, собственно объект анализа и изучения в контексте данной статьи.
Обсуждая подход к эксплуатации, следует учитывать и сложность объекта эксплуатации в целом. По этой причине невозможно представить применяемый подход просто и кратко, приходится использовать такие приемы, как упрощение, обобщение и моделирование.
Подчеркнем, что речь в статье пойдет только о той части эксплуатации ЦОДа, которая относится к комплексу инженерно-технических систем. Впрочем, эксплуатация ИТ-инфраструктуры ЦОДа в целом, на уровне модели, ей аналогична.
В базовой операционной модели мы выделяем три ключевых направления, или группы элементов (см. рисунок):
• группа элементов организационной структуры характеризует положение службы эксплуатации в структуре организации – оператора ЦОДа;
• группа бизнес-процессов включает две подгруппы: процессов управления и взаимодействия и процессов обслуживания;
• группа ресурсов подразделяется на четыре подгруппы: персонала, технологий и инструментов, информации и финансов.
|
Рисунок с натуры Летом 2013 г. агентство «ИКС-Консалтинг» вместе с авторами статьи впервые в российской практике провели исследование, посвященное причинам отказов инженерных систем и методам снижения частоты отказов обору-дования (см. аналитический отчет «Организация эксплуатации и причины отказов в ЦОД»). Обе эти темы напрямую связаны с орга-низацией эксплуатации ЦОДа. Опросом, проведенным в ходе исследования, были охвачены несколько десятков российских ЦОДов. Полученные результаты представляют большой интерес для понимания того, как совреме-нные менеджеры ЦОДов подходят к организации эксплуатации инже-нерно-технических систем, каковы их взгляды по всем основным группам элементов операционной модели эксплуатации. |
Организационная структура
В российской действительности практически абсолютизирован подход, согласно которому службы эксплуатации инженерных систем ЦОДа отделены от ИТ-подразделений компаний. Это в первую очередь результат обычной для большинства российских компаний практики – разделять ИТ-инфраструктуру и инженерно-техническую инфраструктуру ЦОДа в силу исторически сложившегося антагонизма между подразделениями, отвечающими за ИТ, и подразделениями, сопровождающими хозяйственные задачи, к которым в большинстве случаев все еще относят инженерные системы как зданий, так и дата-центров.
Вместе с тем стоит отметить явную тенденцию к выделению совмещенных служб эксплуатации ЦОДа в организационно самостоятельные подразделения, что нельзя не приветствовать, поскольку такое «сращивание» во всех отношениях идет на пользу как самой службе эксплуатации, так и владельцу дата-центра. Но стандартом де-факто эта тенденция пока не стала.Бизнес-процессы
Процессы управления и взаимодействия
Для службы эксплуатации ЦОДа это в первую очередь организация взаимодействия и контроля действий различных участников процесса эксплуатации, направленных на поиск причин отказов и их устранение. К этой же категории можно отнести процессы управления подрядчиками, обслуживающими инженерные системы дата-центра. Неотъемлемая часть группы – процессы управления инженерными системами.
Одним из основных компонентов реализации процессов управления эксплуатацией ЦОДа является диспетчерская служба. К сожалению, нельзя сказать, что в российских дата-центрах существуют полноценные диспетчерские службы. Подавляющее большинство ЦОДов обходится тем, что делегирует ответственность за оркестрацию событий эксплуатации тому, кто отвечает за работу инженерной инфраструктуры (или его подчиненным). Даже наличие, пусть и неформализованного, процесса отработки инцидентов и прочих событий никак не приближает такую конструкцию к превращению в полноценную диспетчерскую службу: с четкими и детерминированными процессами регистрации событий, их маршрутизации и эскалации, ролевыми инструкциями и предельно понятными схемами поведения в любого рода ситуациях.
Стоит отметить, что система мониторинга работы оборудования инженерных систем и ответственных за наблюдение еще не есть полноценная диспетчерская структура, хотя на сегодняшнем уровне развития отрасли ЦОДов наличие средств мониторинга считается стандартом де-факто. Но основная проблема заключается в том, что этот класс систем при создании дата-центра финансируется по остаточному принципу. Эффективная система мониторинга и управления сложной инженерной инфраструктурой стоит немалых денег, и нередко именно за ее счет сокращают общий бюджет строительства ЦОДа.
Надо также понимать, что система мониторинга и управления – это средство автоматизации определенных процессов. Если сами эти процессы управления не спроектированы, то внедрение системы во многом теряет смысл, она перестает быть эффективным инструментом управления. А именно такова ситуация в большинстве российских дата-центров.
Отметим непреходящую ценность соглашений об уровне обслуживания (SLA). Этот инструмент эффективен и полезен как при формировании взаимоотношений с внешним подрядчиком, так и при заключении внутрикорпоративных соглашений с конечными клиентами ЦОДа. Необходимость серьезного отношения к SLA следует из сложившейся сегодня тенденции: в подавляющем большинстве российских ЦОДов используется смешанный метод технического обслуживания, при котором ответственность за ТО комплекса инженерных систем разделена между собственной службой эксплуатации и внешними сервисными подрядчиками. Операторы ЦОДов склонны отдавать внешним организациям обслуживание тех систем, для которых у них недостаточно квалифицированного персонала или просто не хватает сотрудников. Экономическая целесообразность в этом вопросе, как правило, большой роли не играет. Надо сказать, что подготовка и содержание собственного высококвалифицированного персонала чаще всего обходятся дороже, чем внешний сервисный контракт.
Общая печальная тенденция, характерная для современных российских дата-центров, – игнорирование необходимости серьезно заниматься проектированием процессов эксплуатации еще на стадии разработки технических решений для инженерной инфраструктуры. Большинство ЦОДов работают в старой парадигме: построение процессов эксплуатации – забота самой службы эксплуатации. Поэтому традиционно разработка процедур (не процессов!) и построение этой службы начинаются тогда, когда «на носу» передача объекта в постоянную эксплуатацию, и продолжаются в первый год настоящей, боевой эксплуатации, что не может не сказываться на качестве проработки процедур и мешает серьезно отнестись к эксплуатации в целом. Противовесом, придающим эффективность (пока что относительную) такому подходу, служит то, что в большинстве российских ЦОДов руководитель службы эксплуатации принимает непосредственное участие в процессе создания объекта эксплуатации. Но это не слишком надежная опора.
Процессы обслуживания
К ним относятся регламентное, профилактическое и другие виды обслуживания инженерной инфраструктуры ЦОДов. При выполнении сервисных процедур персонал службы эксплуатации должен соблюдать правила обслуживания, рекомендованные производителями. Подчеркнем: должен... Понимание этого присутствует повсеместно и в теории не оспаривается. Более того, в большинстве служб эксплуатации поддерживают идею формирования специальной программы профилактического обслуживания инженерных систем ЦОДа – некоего аналога программы профилактического обслуживания основных фондов производственного предприятия. При составлении такой программы следует не только опираться на нормативы и требования к обслуживанию отдельных экземпляров оборудования, но и учитывать особенности объекта обслуживания в целом, а также заложенные при проектировании специфичные решения.
Практика текущего момента, похоже, все же несколько иная. Например, нам известны лишь единичные случаи, когда в ходе строительства ЦОДа в явном виде было предусмотрено формирование программы профилактического обслуживания. Кроме того, в профессиональном сообществе преобладает мнение, что разрабатывать такую программу должна сама служба эксплуатации дата-центра. Понятно, что в этих условиях сложно говорить не только о качественном наполнении программы, но и о самом факте ее существования.
С учетом сказанного выше от собственно исполнения профилактического обслуживания в российских дата-центрах не стоит ожидать чего-то сверхъестественного. Обслуживание проводится для наиболее критичных систем, в большинстве случаев – на основании требований, сформулированных руководителями службы эксплуатации. Для остальных систем плановая и регулярная работа, скорее всего, не ведется, присутствуют лишь отдельные мероприятия, инициируемые в рамках иных активностей или под влиянием внешних факторов. Например, причиной профилактики могут быть работы в рамках проекта. Или же выполняется профилактика на критичной системе, а «заодно» – и на ряде некритичных систем, которые «давно уже не обслуживали».
Риски такого подхода очевидны, но они принимаются большинством служб эксплуатации, поскольку стоимость полноценной программы профилактического обслуживания высока и пока остается наиболее существенным препятствием для изменения подхода.
Обеспечивающие процессы
К этой категории относят процессы, не вошедшие в первые две группы. Из наиболее часто используемых здесь можно назвать процессы контроля качества и документирования.
К сожалению, в большинстве служб эксплуатации российских ЦОДов процедуры контроля качества не формализованы в достаточной степени. Обычно все сводится к персонализации ответственности конкретных предметных специалистов, ведущих в службе эксплуатации свою тему или отвечающих за отдельные инженерные системы и комплексы.
Контроль качества должен применяться к работам, проводимым как собственными силами, так и силами привлеченных сервисных организаций. Фактически контроль ведется, но формальных правил, требований, шаблонов для оценки полноты и качества проведенных работ в большинстве российских служб эксплуатации ЦОДов не существует.
Процесс документирования – это фиксация проведенных изменений любого свойства в работающих системах ЦОДа. Исходным, эталонным набором должна быть исполнительная документация, которая появляется как результат пусконаладочных работ и комплекса испытаний инженерных систем. К сожалению, в российской практике еще редко встречается процедура документирования (фиксации) базовых значений и показателей работы оборудования инженерных систем и включение полученных коллекций данных в исполнительную документацию. Про процедуры определения состояния наилучшего функционирования и говорить не приходится.
Сам процесс ведения документации на системы ЦОДа, как правило, либо вообще не поставлен, либо существует на неформальной основе – каждый источник внесения изменений решает, каким образом проведенные изменения зафиксировать. В отдельных случаях возможна «фиксация» в недокументальной форме.
О других составляющих операционной модели и о том, каковы же основные черты среднестатистической службы эксплуатации, читайте в следующем номере «ИКС».
__________________________________________________
* См. ГОСТ 25866-83. Эксплуатация техники. Термины и определения.
** См. Wikipedia. The Free Encyclopedia. http://en.wikipedia.org/wiki/Operating_model.
***См. З. Алехин, Д. Басистый. Классификация подходов к организации эксплуатации инженерной инфраструктуры ЦОД. ЦОДы.РФ,. №4’2013.
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3