Настольная книга эксплуататора. Всё, что вы хотели знать о повседневной жизни датацентров, но боялись спросить - Алексей Жумыкин

• регулярный эксплуатационный аудит (внутренний или внешний);

• аудит состояния сооружений и территории (строительный);

• аудит пожарной безопасности объекта;

• аудит физической безопасности;

• внешние аудиты заказчиков и специальные (PCI DSS[29] и т. п.);

• инвентаризация;

• реестр инцидентов за прошедший период;

• окончание срока полезного использования оборудования;

• запросы на развитие (например, переход на новые типы ИБП);

• введение нового процесса в отделе.

Наладить сбор информации довольно просто: для начала достаточно составить регулярный календарь по каждому из аудитов и определить окна поступления информации по другим источникам, если это возможно. За аудит должен быть назначен ответственный, который готовит программу и координирует организационную часть. Важно понять, что после каждого аудита обязательно необходима итоговая встреча, на которой не только обсуждается перечень несоответствий и замечаний (для которых есть такой интересный термин, как near-miss[30]), но и обязательно утверждается план дальнейших действий с указанием ответственных и сроков. Вот этот отчет с пларом действий и становится входным документом для проектов.

Проекты в свою очередь тоже объединяются в конечный список – реестр проектов. Его можно вести в Excel, в трекинговой системе или сделать частью CMMS – важно, чтобы выбранный формат был удобен и понятен всем участникам процесса, иначе они будут испытывать неприятие к использованию инструмента, отказываться от него и таким образом снижать эффективность процесса.

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

• стадия, на которой сейчас находится проект;

• возникшие новые обстоятельства (опционально);

• план по срокам (укладываемся в прогноз или меняем что-то);

• план по бюджету (включая распределение затрат по кварталам);

• следующий шаг и контрольная точка – для синхронизации на следующих встречах.

Для поддержания исторических данных выполненные проекты удалять не следует – лучше переводить их в состояние «завершен» и скрывать для регулярного обозрения.

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

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

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

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

Итого, в общем случае процесс управления проектами может быть описан так:

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

Этапы:

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

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

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

• Проектирование. Если для достижения результата требуется привлечение проектной команды.

• Закупка. Если проект подразумевает поставку услуг или материалов контрагентами. Чтобы не плодить лишних статусов, процедуру тендера можно отнести сюда же.

• Реализация. Основная часть проекта.

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

• Закрытие. Перевод проекта в архив.

Параметры:

• дата создания;

• источник изменения;

• принадлежность к подсистеме;

• локация (если процесс работает на несколько площадок);

• ответственный;

• бюджетная оценка по периодам и фактические данные;

• плановый (первоначальный) срок завершения;

• текущая оценка срока завершения.

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

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

Глава 12

Привлекать ли подрядчиков, или справляться самим?

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

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

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

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

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

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

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

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

Кроме этого, производители часто предлагают программы повышения квалификации как для своих,