Минимальная IT-инфраструктура компании на 10–30 сотрудников

Минимум определяется последствиями, а не числом сотрудников

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

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

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

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

Три разумных профиля вместо одного рецепта

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

Гибридный профиль нужен при локальном специализированном приложении, больших файлах, периферии или слабом канале. Тогда часть идентичности и совместной работы остаётся облачной, а локальный сервер или NAS решает конкретную задачу. Его нельзя покупать «про запас»: заранее описывают нагрузку, RAID, резервные копии, ИБП, обновления и замену.

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

Идентичность и доступ — первый инфраструктурный слой

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

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

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

1. Выбрать основной каталог идентичностей и формат корпоративных адресов.
2. Создать группы по функциям и назначать приложения группам, а не людям.
3. Включить MFA и проверить резервное восстановление доступа.
4. Разделить обычные и административные учётные записи.
5. Настроить процесс приёма, изменения роли и увольнения с владельцами и сроками.
6. Провести пробное отключение тестового пользователя: сеансы, VPN, почта, файлы и SaaS.

Рабочие устройства без ручной уникальности

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

Базовая конфигурация включает поддерживаемую ОС, автоматические обновления, шифрование диска, защиту конечной точки, блокировку экрана, обычные права пользователя и управляемый набор приложений. MDM или RMM выбирают по нужным действиям: инвентаризация, политики, удалённая помощь, патчи и отзыв устройства. Наличие агента не означает, что кто-то обрабатывает его предупреждения.

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

Сеть офиса: просто, но не плоско

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

Корпоративный Wi‑Fi лучше связывать с персональной или управляемой аутентификацией, когда это соразмерно. Общий пароль требует смены после ухода сотрудника и не определяет пользователя. Гостевая сеть имеет только интернет, изоляцию клиентов и разумные лимиты. Административные интерфейсы маршрутизатора, коммутатора, NAS и точек доступа не открывают гостям и напрямую из интернета.

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

• Актуальная схема портов, VLAN, подсетей, DHCP и провайдерских параметров.
• Отдельная зона управления с доступом только администраторам.
• Резервная копия конфигурации после каждого утверждённого изменения.
• DNS-фильтрация и firewall с запретом неожиданных входящих соединений.
• Мониторинг доступности, загрузки канала, ошибок портов и состояния VPN.
• Документированный способ локального доступа при отказе удалённого управления.

Данные, совместная работа и резервное копирование

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

История версий и корзина удобны, но не всегда заменяют независимую копию. Сценарии включают ошибочное удаление, шифрование, компрометацию администратора, сбой приложения и потерю площадки. Копия должна пережить тот отказ, от которого защищает: резерв на том же NAS не помогает при краже, пожаре или полном отказе устройства. Правило 3-2-1 полезно как отправная эвристика, но конкретная схема определяется RPO, RTO, объёмом и возможностями сервиса.

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

1. Составить карту данных и указать официальное хранилище каждого набора.
2. Согласовать допустимую потерю изменений и время возврата для критичных процессов.
3. Выбрать копию, административно и физически отделённую от оригинала.
4. Включить шифрование и разместить ключи восстановления отдельно.
5. Настроить контроль успешности, объёма, срока хранения и неизменяемости, если она используется.
6. Восстановить тестовый набор, измерить время и получить подтверждение владельца.

Поддержка и мониторинг без круглосуточной иллюзии

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

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

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

Порядок внедрения на первые девяносто дней

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

Приоритет зависит от обнаруженного риска. Если сервер работает на отказавшем RAID, резервирование данных важнее красивого Wi‑Fi. Если все сервисы оформлены на бывшего подрядчика, сначала возвращают административный контроль. План содержит критерий готовности каждого этапа и возможность отката. Закупка оборудования без владельца эксплуатации не считается завершённым проектом.

1. Дни 1–15: инвентаризировать сервисы, данные, устройства, сеть, лицензии и ответственных.
2. Дни 16–30: защитить ключевые аккаунты MFA, разделить администраторов и проверить увольнение.
3. Дни 31–45: настроить резервные копии критичных данных и выполнить первое восстановление.
4. Дни 46–60: стандартизировать рабочие устройства, патчи, шифрование и удалённую поддержку.
5. Дни 61–75: разделить корпоративную, гостевую и управляющую сети, сохранить конфигурации.
6. Дни 76–90: настроить полезный мониторинг, инструкции и аварийную проверку.

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