Решение о передаче инфраструктуры подрядчику упирается в два числа: как часто выполняется операция и во сколько обходится час простоя системы, которую она обслуживает. Функция, которую штатный инженер выполняет раз в год, обходится дороже переданной, потому что оплачивается не сама работа, а поддержание квалификации между этими разами.
Ниже разобрано, чем измеряется покрытие инфраструктуры собственными силами, приведена таблица разделения функций между штатом и подрядчиком с критерием выбора по каждой строке, перечислены признаки того, что команда перестала закрывать парк, и то, что не передаётся ни при каком договоре. В конце порядок проверки границы зон, который проходят до подписания.
В неделе 168 часов. Команда, работающая пять дней по восемь часов, закрывает 40 из них, оставшиеся 128 часов инфраструктура живёт без дежурного. Ночью и в выходные она не простаивает: в это время идут резервное копирование, пакетная обработка и репликация, поэтому сбой ночного окна обнаруживается утром вместе с несделанной копией.
Закрыть все 168 часов своими силами означает 4,2 ставки только на дежурство, если делить 168 на 40. С отпусками, больничными и обучением это пять человек на одну линию, и каждый из них должен знать то же оборудование, что и остальные, иначе смена сводится к приёму звонков. Для парка размером в две стойки такая линия не окупается: дежурный будет занят несколько часов в месяц, а платить придётся за все смены.
Отсюда следует механизм ценообразования у подрядчика. Он продаёт не время инженера, а долю сменного графика, который уже собран и оплачен несколькими заказчиками сразу. По этой же причине круглосуточное покрытие снаружи выходит дешевле собственной линии дежурства, а разовая настройка в рабочие часы чаще дешевле внутри. Как из этих двух крайностей собираются рабочие схемы, разобрано в материале про аутсорсинг ИТ-инфраструктуры.
Таблица построена по функциям, а не по моделям обслуживания. Одна и та же функция почти всегда делится на две части, и спор о зонах ответственности возникает внутри неё, а не между ними. В последнем столбце указан механизм, по которому проходит граница, чтобы строку можно было проверить на своей инфраструктуре.
| Функция | Держим в штате | Отдаём подрядчику | Критерий выбора |
|---|---|---|---|
| Политики информационной безопасности | формулировка правил: кто, куда и с какими правами ходит | настройка правил на межсетевом экране, установка обновлений с закрытием уязвимостей | правило описывает организацию, конфигурация описывает устройство |
| Учётные записи и доступы сотрудников | решение, кому что положено, и отзыв прав при увольнении | техническое исполнение заявок в каталогах и на сетевом оборудовании | основание для права лежит в кадровых документах, а не в настройках |
| Сеть ядра и ЦОД | постановка задач на новые сегменты и на расширение полосы | настройка коммутаторов и маршрутизаторов, разбор аварий, обновление микрокода | операция редкая, цена ошибки высокая, навык держится только практикой |
| Серверы и системы хранения | планирование ёмкости и производительности под свои задачи | замена компонентов, обновление прошивок, разбор отказов контроллеров и дисков | число отказов на одном парке ниже того, что нужно для поддержания навыка |
| Резервное копирование | решение, что копируем и на какую глубину храним | выполнение заданий, контроль ошибок, регулярная проверка восстановления | ценность данных знает владелец, восстановление отрабатывает тот, кто делает его часто |
| Первая линия поддержки пользователей | приём обращений, знание внутренних процессов и людей | подключение на пиковый поток заявок и на нерабочие часы | работа опирается на знание процессов компании, а не оборудования |
| Круглосуточное дежурство | эскалация внутри компании и контроль отчётности | сменный график, приём событий мониторинга, первичная локализация | 168 часов в неделю своими силами дороже доли в чужой смене |
| Внутренние системы и данные | разработка, настройка, владение учётными данными | обслуживание платформы, на которой они работают | логика процессов не переносится наружу и уходит вместе с внешней командой |
Строки распадаются по одному признаку. В штате остаётся то, что требует знания компании: кто чем пользуется, что нельзя останавливать в отчётный период, какие данные восстанавливают первыми. Подрядчику уходит то, что требует знания оборудования и повторяемости. Разница в частоте видна при первом же нештатном исходе: у того, кто выполняет операцию каждую неделю, есть отработанный порядок действий и опыт неудачных вариантов, у редкого исполнителя есть инструкция производителя и первая попытка.
Признаки проверяются документами, а не опросом сотрудников. Попросите схему сети, перечень учётных записей с правами и журнал обращений за квартал. Если это приходится собирать заново, знания действительно лежат в одной голове. Полная опись парка с состоянием оборудования и сроками поддержки собирается в ходе аудита ИТ-инфраструктуры, и без неё граница между зонами проводится наугад.
Отдельная строка это запас компонентов. Расстояние до склада запчастей входит в фактическое время восстановления независимо от того, что записано в договоре, поэтому состав запаса на площадке считают заранее. Как это делается, разобрано в материале про склад ЗИП в серверной.
Граница проверяется прогоном аварии на бумаге. Возьмите сценарий, который стоит дороже прочих: ночью отказал контроллер системы хранения, тома доступны по одному пути. Дальше по шагам, кто получает событие мониторинга, кто принимает решение о переключении, откуда берётся плата на замену, кто уведомляет пользователей и в какой момент заказчик узнаёт об инциденте. Несогласованность вскрывается на этом разборе за одну встречу.
Раздельные сроки на реакцию и на восстановление, классы обращений и порядок эскалации разобраны в статье про сервисное обслуживание по SLA. Там же видно, почему одинаковые на бумаге условия дают разное фактическое время простоя.
С двух списков. Первый это опись оборудования и систем с указанием, что снято с поддержки производителя. Второй это перечень операций за прошедший год с частотой каждой. Функции из второго списка, выполненные один или два раза, и есть кандидаты на передачу: навык по ним внутри команды не набирается.
Техническую часть можно, содержательную нет. Внешняя команда настроит правила на межсетевом экране, закроет уязвимости обновлениями и разберёт события, но решение о том, какому отделу открыт доступ к какой системе, принимает владелец процесса внутри компании. Подрядчик не знает, кто с кем работает и какие данные считаются критичными.
Сравнивают полную стоимость покрытия, а не фонд оплаты труда с суммой договора. В свою часть входят ставки на все смены, обучение и подтверждение сертификатов, тестовый стенд, запас компонентов и время руководителя на управление отделом. В часть подрядчика входит своё время на постановку задач, приёмку работ и разбор отчётов.
Смотрят не на график сотрудников, а на то, что происходит с системами ночью. Если в ночном окне идут резервное копирование, обмен с внешними системами и пакетная обработка, отказ в это время срывает работу следующего дня. Если ночью нагрузки нет, покрытия рабочих часов достаточно, а на выходные закладывают дежурство по вызову.
Забрать знания до последнего рабочего дня. Схема сети и адресный план, список учётных записей и паролей, перечень обслуживаемых систем с контактами производителей, порядок действий при типовых отказах. Дальше меняются все пароли, которые он знал, и отзываются его доступы, включая удалённые подключения и учётные записи на оборудовании.
То, что записано в разделе о прекращении: актуальные схемы, выгрузки конфигураций, пароли, история обращений и перечень открытых работ. Формат и срок передачи фиксируют при подписании. Если этого раздела нет, при расставании компания получает работающую инфраструктуру, устройство которой придётся восстанавливать заново.
Меню
Каталог
