Регламент технического обслуживания ИТ-инфраструктуры: разработка и внедрение

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

Обычно регламент обслуживания охватывает:

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

Для серверов отдельно описывают проверку загрузки процессора и памяти, состояния служб, журналов событий, свободного места и дисковой подсистемы. Диагностика дисков должна учитывать предупреждения S.M.A.R.T., состояние RAID и признаки деградации накопителей. Замена дисков выполняется по согласованной процедуре: с проверкой совместимости, резервной копии и последующим контролем восстановления массива.

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

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

Примерный график обслуживания можно построить следующим образом:


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

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

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

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

Календарный график. Для каждого вида работ задают периодичность, продолжительность, допустимое окно обслуживания и резерв по времени. Здесь же отражают сроки установки обновлений, плановой замены дисков, проверки ИБП и проведения тестов восстановления.

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

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

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

Формы отчётности. Журнал ТО содержит дату и время работ, исполнителя, объект, выполненные действия, обнаруженные проблемы и результат проверки. К записи прикладывают данные мониторинга, чек-лист, сведения о замене компонентов и рекомендации. Такой журнал позволяет контролировать исполнение и оценивать повторяемость инцидентов.

Разработка начинается не с шаблона, а с обследования текущей среды. Аудит ИТ-инфраструктуры помогает выявить серверы и сервисы без ответственных, устаревшие версии ПО, ошибки конфигурации, уязвимости, точки отказа и непроверенные резервные копии. На основании результатов можно оценить объём работ и расставить приоритеты.

Внедрение проходит в несколько этапов:

1. Инвентаризация. Собирают сведения о серверах, дисках, рабочих станциях, сетевом оборудовании, системах, приложениях и лицензиях. Отдельно отмечают критические сервисы и зависимости между ними.
2. Оценка рисков. Определяют возможные причины сбоев, влияние остановки на бизнес, целевое время восстановления и допустимую потерю данных.
3. Разработка процедур. Составляют график, инструкции, чек-листы, правила установки обновлений, замены оборудования, создания копий и восстановления.
4. Назначение ответственных. Закрепляют роли, права доступа, порядок согласования и эскалации. Если участвует подрядчик, требования включают в договор и SLA.
5. Пилотный запуск. Регламент проверяют на нескольких серверах или одном сервисе. Исполнители оценивают понятность заданий, реальное время проведения работ и достаточность контрольных действий.
6. Полное внедрение. Утверждают документ, настраивают календарь заданий и автоматические предупреждения, обучают специалистов и начинают вести записи.
7. Актуализация. Регламент пересматривают после изменений архитектуры, установки новых серверов, переноса приложений, серьёзных инцидентов и плановой модернизации.

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

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

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

Задания на обслуживание удобно вести в Service Desk или ITSM-платформе. В системе настраивают регулярные задачи, сроки, ответственных, уведомления и эскалации. CMDB связывает записи об оборудовании с сервисами и помогает оценить последствия остановки сервера до проведения работ. Отчёты показывают процент выполненных заданий, число сбоев, среднее время устранения и восстановления, а также повторяющиеся проблемы.

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

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

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

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

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

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

Если в компании нет собственной команды или требуется специализированный центр компетенций, разработку регламента технического обслуживания и дальнейшее сопровождение можно передать Zerobit. Специалисты проведут аудит, подготовят инструкции, настроят мониторинг, резервное копирование и управление обновлениями, а затем будут поддерживать ИТ-инфраструктуру в рамках согласованного SLA.