Как Правильно Составить Тз Для Администрирования: Наши Грабли

В общем, тема неисчерпаемая.

Лёшка (наш инженер) как-то ковыряется в стойке строго защищённого дата-центра, где находится несколько банков.

В следующем ряду он наблюдает совершенно дикую картину: к лезвию подошел парень.

Вытащил жесткий диск, что-то записал, ПОДКЛЮЧИЛ СНОВА, вытащил второй, записал, установил, вытащил третий.

Лёша ему: «Пссст, парень, что ты делаешьЭ» Он: «Ну это же инвентарь!» И как-то сразу всё стало понятно.

Я работаю в отделе компьютерных систем в КРОК, мы поддерживаем всё, что можно кинуть в стенку.

То есть серверы, системы хранения данных и другое дорогостоящее оборудование в дата-центрах.

Ну и тот факт, что он содержит операционные системы и базовую инфраструктуру.

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

Более сложные – это замена системных администраторов заказчика.

Самый страшный момент договора – это составление технического задания.

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

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



Как правильно составить ТЗ для администрирования: наши грабли



Поднимите свою статистику

Самая первая проблема всех технических характеристик — это банальное незнание того, какое у вас среднемесячное количество заявок.

Выглядит это так: вы хотите передать администрирование на аутсорсинг, тогда вам нужно понять, сколько это будет стоить.

Если вы просто прикрепите описание парка техники, то мы, как участник конкурса, оценим объемы работ, поездок, если потребуется, и поставим ее с некоторым резервом.

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

Кто-то, например, добавляет виртуальные машины каждый день, а кто-то раз в год — цена будет такая же, как в первом приближении.

Часто задача заказчика выглядит так: «Теперь администрируйте все за нас».

Что это такое? Поставщик услуг (то есть мы) не понимает объемов, все перезалогается по трудозатратам.

Если мы перекредитуем, вы переплатите.

Если в ходе действия контракта ценник вдруг вырастет, возникнут конфликты.

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

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

И просто если это ветка и вы туда давно не заглядывали.

В этом случае нужно сделать аудит в самом начале.

Аудит, конечно, сам по себе стоит денег, но зато позволяет неплохо сэкономить на последующем договоре.

А результаты аудита можно показать на конкурсе, если вы хотите сравнить поставщиков по цене за единицу услуги.

Мы так думаем: есть цена за работу (ремонт, проезд), есть понимание сколько и каких устройств.

Дальше смотрим: у такого-то агрегата будет столько-то отказов в месяц, столько-то времени мы на него потратим.

Ну или взять резервную систему.

Здесь кому-то просто нужно один раз настроить и только проверять, чтобы все резервные копии проходили.

А кто-то бесконечно меняет политику, добавляет, удаляет, снова добавляет. Мы администрируем с 90-х годов и накапливаем статистику по всему, поэтому прогнозируем достаточно точно.

А когда «там столько серверов с непонятным содержимым, такое количество виртуальных машин, непонятная ОС и еще что-то, что нужно администрировать, парень уволился» — вы гарантированно получите негуманные ценники.

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

Далее нужно разбить договор на регулярную и нечастую работу.

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

Для редких задач мы создаем список систем решения, для которых нужны компетенции (даже если они нужны раз в год).

Подрядчик подготовит специалистов.

И это не будет включено в основную стоимость.

Он просто пропишет расценки на такую работу.

Мой любимый пример — когда заказчик решил, что администрация включила полную миграцию сервисов, на которых работал сайт, в другой дата-центр за 1000 км вместе с серверами.

Мол, заберите сервера и всё вместе с ними (сеть, хранилище, данные на них.

) и заберите, мы платим за их администрирование.

Но это скорее из ряда вон выходящее.

Обычно мы выделяем такие вещи в отдельные проекты и детально прорабатываем миграцию.



Время реакции

Я регулярно вижу клиентов, которые неправильно или вообще не указывают время реакции.

Здесь лучше все зафиксировать, чтобы ожидания совпадали с реальностью.

Очень важно написать строгие соглашения об уровне обслуживания для критически важного оборудования: обычно время ответа составляет 15 минут, время замены — четыре часа.

Но если сделать это для всего оборудования в дата-центре, ценник снова окажется негуманным.

Есть и более сложные контракты.

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

Потому что производственный цикл завязан на этих узлах.

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

Обычно продакшн, когда хочет разовой работы (так как бывают сбои), пытается поставить SLA в 15 минут, не понимая, что за этим стоит. Чтобы отправить инженера с таким разрешением, ему нужно весь год дежурить, а не пить под Новый год (или пить строго по шахматным правилам с коллегами).

А это стоит денег – и вовсе не как разовая услуга.

Был контракт, когда нужно было поддерживать 99% аптайма, и за это платили штрафами за выход за пределы показателя.

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

Нас в контракт не включили, но мы знаем тех, кто решил, что прокатит. Это не сработало.



Составление отчетов

Третьи любимые грабли — заказчик не задает формат отчетности.

Разработайте формат отчетности, который вы хотите видеть.

И укажите его периодичность в договоре.

Если все ваши задачи выполняются по расценкам, то подрядчику лучше перед началом работ сообщить вам предварительную оценку продолжительности работ. Это на вопрос «Почему у вас здесь два часа, а не полтораЭ» - это вечный спор.

Решаем так: перед ремонтом выдаем заказчику смету с погрешностью плюс-минус 10% в каждую сторону.

Включаем в проекты крупные задачи с планом работ и сроками выполнения этапов.

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

Потому что мы заинтересованы в продлении на год, два, три и пять.

И мы знаем, что если не будет ощущения полного контроля и предсказуемости, то и контракт не будет продлен.

Также полезно планировать регулярные встречи.

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

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

Они не слушают заказчика и делают все, как и пять лет назад. То есть без учета его новых бизнес-требований.

Заказчик пытался это донести, но потом сдался и начал искать нового подрядчика.



Документация

Грабли номер четыре — фактическое отсутствие документации на сайте.

Да, я знаю, что никто не любит вносить изменения в инфраструктурную документацию.

Если вы этого не оговариваете в договоре, значит, вы там что-то сделали, здесь что-то поменяли, но забыли это сказать – это распространенная ситуация.

Альтернативный вариант — нанять кого-то, кто будет поддерживать его в актуальном состоянии (что-то менял, что-то отражал).

Сменить исполнителей или передать поддержку обратно внутренним специалистам будет легко.

Мы сотни раз приезжали туда, где все документы показывают, что это ДРП примерно 2011 года.

И воспользоваться им нельзя.

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

Мне помогли разобраться в чем дело, но оказалось, что DRP не работает, потому что IP поменялись.



Не забудьте забрать свою разгрузку в конце периода

Продвинутые аутсорсеры ведут CMDB: установили новое оборудование и добавили его в базу данных.

Все поддерживается в актуальном состоянии.

Если у вас нет собственной базы данных CMDB, то у обслуживающих организаций она всегда есть.

Ну а если он не ваш, попросите доступ к нему.

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

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

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

Это была наша первая услуга вместе с аудитом — предыдущий контрагент не захотел делиться данными.



Не бойтесь включать в договор высокие штрафы

Нормальный исполнитель к ним относится хорошо.

Готовность подписать их — показатель того, что поставщик уверен в соблюдении SLA. Единственный момент: если вы напрямую передаете контроль над падением производительности и фиксируете процент готовности, сделайте, например, месяц для переходного периода, когда штрафы не применяются.

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

Если кто-то зарегистрируется без этого, ваша инфраструктура будет под угрозой в течение первого месяца.

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

Тогда будет с чем сравнить и предъявить исполнителю, что производительность снизилась.

Иначе вы этого не докажете.



Незамедлительно привлеките к процессу разработки специалиста по информационной безопасности

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

Если вы вдруг этого не сделали, ждите неприятностей.

Чаще всего администрирование осуществляется удаленно, поэтому поставщику необходимо понимать, какие будут требования.

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

Банки еще серьезнее — у них есть прямые стандарты ГОСТ и требования ЦБ.

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

У нас был случай, мы три месяца не могли подписать договор, и ИТ-директор повесился.

Чекист хотел внедрение ГОСТа, мы хотели, чтобы он показал, как это реализовано на данный момент (подозревая, что оно вообще не реализовано), и предложили прислать вариант. Он не отправил его.

В итоге написали, что «если в течение трех дней вы не получите замечаний по предложенному тексту технического задания, то мы считаем его согласованным», и скопировали его руководителю компании.

«Информационная безопасность» прислала одну фразу: «Установку обновлений и патчей, устраняющих критические уязвимости информационной безопасности, необходимо провести не позднее 48 часов».

Вот и все.

Можно сказать, прошло.

В общем, тема информационной безопасности жирная и скользкая.

Охранники живут в своем мире.

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

И вот они сидят на табуретке и задают вопросы, потому что никто не обратил их внимание на то, что что-то происходит. Ах да, и не забудьте отметить, что администраторы должны иметь доступ к объекту.

В противном случае удаленно заменить запчасти на сервере затруднительно.

На одном из проектов у нас были ожидания по пять-шесть часов из-за того, что глобальной команде компании (ИТ-руководителю в Индии) нужно было одобрить запросы на физический доступ для инженера.



Служба поддержки – это важно

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

Таким образом, вы можете прозрачно контролировать выполнение.

Многие клиенты, работающие через почту, получают лишь сообщение «Ваш билет очень важен для нас, и мы скоро с ним разберемся».

И все, дальше черный ящик.

А если случай критический, все хотят видеть приоритет, хотят видеть, кто работает, микростатусы.

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

К счастью, нам его дали.

Там было 300 страниц, написанных ещё в 2005 году и дополненных в 2018 набором костылей.

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

Ночью всем желающим нужно позвонить и записаться туда.

А вот Скайп не очень живой.

Мне пришлось переустановить его.



Сертификаты должны быть не в компании, а у специалистов вашего проекта.

Простой совет: убедитесь, что исполнитель профессионален, это сертификаты и опыт работы в компании.

Совет посложнее: убедитесь, что это именно те люди, которые будут участвовать в вашем проекте.

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

Написать можно так: «Тестирование специалистов нашими специалистами».

Я видел, как к железной дороге подошел мужчина со стопкой инструкций.

Он говорит: «Меня нашли на Юде за 5 тысяч рублей».

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

Я знаю, что на рынке были случаи, когда команды менялись трижды.

В финансах процедура проста: есть списки тех, кто может прикасаться к инфраструктуре.

Просто так никого не пускают, только по белому списку.



Окончательно

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

Потому что очень часто поставщики пытаются вписать что-то свое, и дальше сравнивать невозможно.

Я знаю, что это простой совет, но им редко кто пользуется.

А потом много времени тратится на то, чтобы выяснить, кто что обещал и у кого лучшая цена.



Пример проекта

Поддерживаем розничную компанию, имеющую магазины во всех регионах России (количество магазинов за год увеличилось на 13%).

Инфраструктура состоит из 1400 позиций от разных производителей; на его основе функционирует критически важная для бизнеса функциональность.

Перед ИТ стоит огромное количество задач развития.

Даже инфраструктурная поддержка там уже настолько велика, что в одиночку ИТ-отдел не справится.

Оборудования много, нужно как-то управлять его жизненным циклом.

В целом они уже пять лет отдают рутинные задачи на аутсорсинг.

Мы с ними уже два года.

В задачах:

  • Мониторинг вычислительной инфраструктуры и среды виртуализации 24 x 7.
  • Информирование ответственных о проблемах по результатам мониторинга, в критических случаях в течение 15 минут.
  • Подача заявок на замену запчастей от производителей, замена, информирование о восстановлении работы.

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

  • Управляйте инвентарем из 1400 единиц оборудования во внутренней базе данных CMDB.
  • Установка нового оборудования по запросу, внесение данных в CMDB.
У нас есть команда: первая линия отвечает за мониторинг и подачу заявок от вендоров, вторая за полевые работы, третья за смежные направления (когда не работает прикладное ПО и непонятно, где проблема).

Есть выделенный технический менеджер, он контролирует и координирует работу всех технических специалистов; отдельно ответственный за CMDB; отдельный сервис-менеджер, отвечающий за общую координацию проекта.

По поводу контракта.

Скажу сразу, что там есть SLA на все работы, а также штрафы за невыполнение.

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

Результат — экономия для заказчика 5500 часов в год, которые его собственные сотрудники потратили на проекты развития.

99,9% выполнения SLA (за первый месяц по сроку уведомления было два нарушения, исправлено благодаря регулярной обратной связи).

Количество оповещений от системы мониторинга сократилось на 30% благодаря оптимальной настройке.

На вопрос ИТ-директора, как мы работаем, он ответил: «Мы о вас ничего не слышим».

Он понимает, насколько это важно.

Шаблон технической спецификации Здесь .

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

Теги: #it инфраструктура #Системное администрирование #администрирование #It #tz

Вместе с данным постом часто просматривают: