Не тушим пожары: проактивный подход к созданию надежной ИТ-инфраструктуры

Рассматривая компании, которые предоставляют ИТ-поддержку, складывается впечатление, что основными критериями качества обслуживания является:

• скорость реакции на задачу: от 5 минут (как правило, зависит от тарифа);

• наличие системы постановки задач;

• оперативное прибытие техника на объект в случае сбоя;

• дистанционная поддержка, как приоритетный формат работы.

Эти параметры задают сами аутсорсинговые компании. Если описать общую схему такого взаимодействия, то ее можно отразить следующей последовательностью, рисунок 1:

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

Что такое проактивная поддержка?

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

Любая поддержка является систематической работой, в состав которой входят:

• регламентные работы (обновление ПО, антивирусная проверка, проверка соблюдения регламентов по работе с документами и др. операции);

• мониторинг загруженности и потребления ресурсов;

• оперативное управление ресурсами, их расширение;

• отработка триггеров мониторинга для предупреждения сбоев;

• выявление причин потенциальных сбоев и исключение их повторного появления;

• своевременное выполнение задач пользователей;

• периодическое проведение “учений” по моделированию и отработке сбоев.

Для выстраивания работы в формате “Проактивная поддержка”, достаточно придерживаться следующей последовательности.

Путь проактивной поддержки

1. Собираем требования бизнеса — это самые основные вопросы, на базе которых строится работа:

• Какое допустимое время простоя?

Временной период, в который работоспособность инфраструктуры / сервисов должна быть восстановлена.  

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

• Какая целевая точка восстановления данных?

Т.е. время между последним бэкапом и потерей данных при сбое. 

Наглядный пример отражен на рисунке 2:

2. Оценка требований бизнеса и фактического состояния ИТ

• выявление точек потенциального сбоя;

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

Результат, данного этапа:

• подготовлена концепция модернизации (оптимизации) инфраструктуры при необходимости;

• выделены первичные критические задачи. Здесь допускается применять “временные решения”, что позволит оперативно получить результат;

• согласован регламент последовательности действий при “форс-мажорах, предупреждение и реагирование на проблему”.

Важно! Регламент отработки форс-мажоров — один из важнейших документов.

Он отражает:

• перечень критически важных сервисов и аппаратных устройств;

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

• время восстановления критических сервисов, что формирует корректное ожидание у бизнеса;

• порядок уведомления пользователей о происшествии и нормализации деятельности сервисов.

3. Модернизация (внедрение) инфраструктуры и апгрейд

• обеспечить резервирование критически важных узлов. Например, при наличии зависимости компании от Интернета, необходимо иметь резервный шлюз. Реализовать холодный резерв или собрать в стек — вопрос уже второй. Главное — при сбое не придется “бежать в магазин” и потом настраивать новое оборудование;

• провести проверку системы бэкапирования с учетом требований по восстановлению данных;

• внедрить систему мониторинга серверной, сетевой и каналообразующей инфраструктуры;

• сформировать документацию по объекту;

• изъять права администратора у пользователей ПК.

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

4. Передача объекта на поддержку

• назначается ведущий инженер;

• инженер принимает объект согласно сформированной документации (проверяет полноту структуры, роли, доступы и прочее);

• проверка корректности системы бэкапирования.

“Золотое правило” тех поддержки:

Не навреди! Помни, что в рабочее время компания Заказчика зарабатывает деньги и любой простой в работе грозит убытками. Все действия, которые могут привести к сбоям в текущей работе ИТ-инфраструктуры, необходимо выполнять в нерабочее время.

Проактивная поддержка на практике

Рассмотрим на практическом примере, как выстроить ИТ-поддержку на качественном уровне, а “не тушить пожары”.

Примером послужит торгово-производственная компания.

Требования бизнеса:

1. Обеспечить поддержку ИТ инфраструктуры:

• допустимый простой в случае сбоя 15 минут;

• точка восстановления данных 15 минут.

2. Исключить проблемы с периодическим отвалом 1С.

Входящие данные:

• общее количество пользователей: 30;

• учетная система 1С КА и 1С Бухгалтерия на несколько пользователей;

• в основном все работают из офиса, удаленно работают сотрудники финансового блока.

Общая ИТ структура:

• Host 1, носитель ВМ. Основная роль — терминальный сервер;

• Host 2, носитель ВМ. Основная роль — сервер 1С;

• Host 3, выделенный сервер не являющийся критически важным и обеспечивающий работу не основной 1С на 5 пользователей.

Оценим соответствие текущей инфраструктуры и требований бизнеса

Работы состоят из двух направлений:

1. Сбор объективных показателей инфраструктуры

Изучаем потребление ресурсов серверов и стабильности их работы в части доступности сервисов. Поможет в этом мониторинг Zabbix.

Краткие выводы:

• Host 1 достиг предела аппаратной модернизации;

• Host 2 по итогам замеров показал занятость RAM 84%, средняя загруженность процессора 44%.

2. Определение точек сбоя и критически важных сервисов

На рисунке 2, критические точки выделены красным (o).

Серверная инфраструктура

Краткие выводы:

• основным сервисом является 1C:Предприятие Комплексная Автоматизация;

• осуществляется бэкапирование;

• Host 1 расширению не подлежит, исчерпаны аппаратные возможности, занятость ресурсов 85%;

• Host 2 подлежит модернизации. Необходимо увеличить дисковое пространство и оперативную память.

Сетевая инфраструктура

• основной шлюз не зарезервирован, отсутствует ЗИП. Потенциальная точка сбоя;

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

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

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

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

3. Исключить потенциальные риски

Понимая потенциальные точки сбоя, дальнейшие действия по модернизации ИТ-инфраструктуры становятся прозрачными:

1. отказоустойчивость основного шлюза — разворачиваем VRRP кластер на базе Микротика. При падении “Основного” устройства, главным становится второстепенный шлюз;

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

3. модернизация Host 2;

4. модернизация Wi-Fi — разворачиваем бесшовную mesh сеть на базе точек доступа Ubiquiti с выделением гостевой сети;

5. в облачную инфраструктуру выносим резервирование основной учетной системы. Это стало возможным благодаря настройке отказоустойчивости шлюза;

6. настроен мониторинг работы инфраструктуры и сервисов.

Пример целевой инфраструктуры представлен на рисунке 4:

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

4. Передача инфраструктуры на поддержку

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

Инженер на постоянной основе проводит регламентные работы, решает обращения пользователей, а самое главное — отрабатывает триггеры системы мониторинга.

Важно: нельзя поддерживать качество обслуживания при откровенном бардаке в ИТ-инфраструктуре. Поэтому сначала наводим порядок, а далее обеспечиваем поддержку.

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