Управление ИТ-инфраструктурой: чем это отличается от «чинить, когда сломается»

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

Это работает годами и выглядит вполне разумным решением. Пока серверы не падают, интернет не пропадает, а 1С открывается по утрам — какая разница, как называется то, чем занимается этот человек.

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

Что чаще всего называют управлением инфраструктурой

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

Формально это тоже управление — кто-то же принимает решения, кого вызвать и что покупать. Просто горизонт планирования здесь равен времени между двумя поломками — не кварталу и не году вперёд.

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

Пока компания маленькая, реактивный подход работает

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

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

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

Где реактивная модель начинает давать сбои

Компания растёт: прибавляются сотрудники, увеличивается объём данных, добавляются новые программы и сервисы. Нагрузка на инфраструктуру растёт вместе с этим, но никто её не отслеживает — просто потому, что раньше не было привычки на это смотреть.

Первый звонок обычно связан с производительностью: 1С стала заметно тормозить, файлы открываются дольше обычного, видеосвязь с клиентами периодически рвётся. Реакция стандартная — вызвать того же специалиста, который чинил раньше, и попросить разобраться.

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

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

Один и тот же сбой, разные причины на бумаге

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

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

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

Что не видно без постоянного наблюдения

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

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

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

Цена решений, принятых вслепую

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

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

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

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

Как выглядит управление на практике

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

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

Раз в квартал стоит выделять время на короткий обзор: что менялось за этот период, какие инциденты повторялись, где нагрузка растёт быстрее ожидаемого. Это не масштабное мероприятие — час-два внимания, который экономит недели реактивного тушения пожаров позже.

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

Управление — это дисциплина, не дежурство

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

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

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