Для выбора первого сервера понадобятся сведения о программах, пользователях, данных и условиях работы компании. Одного списка характеристик здесь мало: комплектация должна соответствовать реальным задачам, учитывать рост нагрузки и возможности обслуживания. Чтобы обсудить все это с поставщиком, руководителю полезно заранее подготовить техническое задание.
По одному и тому же ТЗ можно сравнивать новую платформу и сервер б/у: проверять совместимость с нужными программами, доступные ресурсы и условия восстановления после сбоя. Разберем, какие сведения собрать внутри компании, что поручить ИТ-специалисту и как задать критерии приемки готовой системы.
Какие задачи и нагрузки нужно описать
Запрос «сервер для двадцати сотрудников» оставляет слишком много неизвестного. У одной компании сотрудники открывают общие документы, у другой одновременно работают в учетной системе, формируют отчеты и загружают данные с сайта. Численность одинаковая, но объем работы сервера различается. Поэтому начните с перечня сервисов, которые планируется на него перенести.Для каждого сервиса соберите исходные сведения:
- Программы и версии: учетная система, база данных, общие папки, удаленные рабочие места. Укажите, где они работают сейчас.
- Пользователи: сколько человек имеют доступ, сколько обычно работают одновременно и сколько подключаются в часы пик.
- Операции: что происходит в течение дня, какие отчеты и обмены занимают больше всего времени, совпадают ли они с резервным копированием.
- Данные: сколько занимают базы и файлы, насколько увеличились за последний год, что предстоит добавить.
- Планы: новые сотрудники, филиалы и сервисы на ближайшие два-три года.
Если программы уже работают на офисном компьютере или арендованном сервере, попросите администратора снять показатели нагрузки в обычные дни и в периоды отчетности. Средняя загрузка за неделю может скрыть короткий, но критичный пик. Когда измерять пока нечего, требования уточняют с внедренцем программы и проверяют на тестовой конфигурации.
Отдельно определите, сколько времени компания может обходиться без каждого сервиса и за какой период допустимо потерять последние изменения. Например, заново внести документы за последний час и восстановить работу за четыре часа — два разных требования. Они определяют порядок резервного копирования и восстановления. Для бухгалтерской базы и архива старых сканов эти условия могут различаться.
Как определить требования к ресурсам
Собранное описание передают специалисту, который знает используемое ПО. В документации «1С» прямо отмечено: минимальные системные требования обеспечивают запуск приложения с пустой базой, а требования для реальной работы зависят от объема данных, конфигурации и одновременной нагрузки. Поэтому переносить минимальные гигабайты из справки в заказ рискованно.При обсуждении комплектации удобно пройти четыре группы ресурсов:
- Процессор. Опишите операции, которые должны выполняться параллельно, и допустимое время их завершения. Обоснованием выбора послужит проверка на вашей задаче или сопоставимой нагрузке; одного числа ядер для вывода недостаточно.
- Оперативная память. Учтите операционную систему, приложения и базу данных. Если на одном физическом сервере будут работать несколько виртуальных машин — изолированных программных серверов, — память нужна каждой из них и управляющему ПО.
- Накопители. Зафиксируйте полезную емкость, характер работы с данными и требования к скорости. Для базы с частыми обращениями к небольшим записям и для редко используемого файлового архива условия различаются.
- Сеть. Укажите размер передаваемых файлов, число одновременных обращений и оборудование офиса. Пропускную способность согласуют для всего пути данных: серверного адаптера, коммутатора и рабочих мест.
Запас емкости можно оценить расчетом. Допустим, файлы занимают 1 ТБ и прибавляют по 25 ГБ в месяц. За два года получится 1 ТБ + 25 ГБ × 24 = 1,6 ТБ при десятичном счете единиц. Дополнительно учтите систему, служебные данные и запас свободного места; хранилище резервных копий рассчитывают отдельно.
В спецификации просите указывать доступную емкость после создания дискового массива. RAID объединяет накопители; уровни с избыточностью позволяют пережить определенные отказы дисков. При этом RAID не заменяет резервную копию: случайно удаленный файл или поврежденную базу нужно восстанавливать из отдельной сохраненной версии. Сам факт успешного копирования также стоит подтверждать пробным восстановлением.
Что учесть при выборе платформы
Новую и восстановленную платформу сравнивают по одному набору требований. Если рассматривается восстановленная платформа, в предложение включают точный состав сборки, состояние накопителей, результаты диагностики и условия гарантии на компоненты. Для нового оборудования тоже проверяют фактическую комплектацию и доступное обслуживание: название модели не описывает все содержимое корпуса.Совместимость подтверждают для конкретной модели, ее компонентов и выбранных версий операционной системы, программ и среды виртуализации. Нужны поддерживаемые драйверы и прошивки. Если планируется расширение, уточните число свободных отсеков и слотов, допустимые модули памяти и условия установки дополнительных устройств. Возможность модернизации должна относиться именно к предлагаемой сборке.
До заказа определите место установки. Для стойки проверяют глубину корпуса, крепления и доступ для обслуживания; для офиса — шум и условия охлаждения. Укажите доступное электропитание и требования к источнику бесперебойного питания: какую нагрузку он должен поддерживать и сколько времени потребуется для штатного завершения работы. Эти параметры проверяют по документации выбранного оборудования.
Назначьте ответственного за обновления, контроль резервных копий и обращения в сервис. Гарантия на оборудование и восстановление работы бизнеса — отдельные вопросы. В условиях обслуживания уточняют время ответа, порядок диагностики, отправки замены и ее установки. При жестком ограничении простоя заранее обсуждают резервный сервер или другой способ продолжить работу на время ремонта.
Как оформить итоговое техническое задание
Первую версию ТЗ руководитель составляет вместе с ответственным за программы. Поставщик или системный администратор уточняет характеристики оборудования. В ТЗ фиксируют исходные условия, результат и способ проверки. Ниже — условный пример для компании с учетной системой и общими файлами.
| Раздел ТЗ | Пример формулировки |
|---|---|
| Рабочие задачи | Учетная система и общие папки. Приложить перечень программ, их версий и необходимых лицензий. |
| Одновременная нагрузка | 20 сотрудников; до 10 одновременно работают в учетной системе. Учесть формирование отчета во время ввода документов. |
| Данные и рост | База — 80 ГБ, файлы — 1 ТБ. Рост файлов — 25 ГБ в месяц. Расчетный период — два года. |
| Восстановление | Для учетной системы: допустима потеря изменений не более чем за час; работа должна возобновиться в течение четырех часов после отказа. |
| Комплектация и развитие | Предоставить состав сборки, полезную емкость дисков и подтверждение совместимости. Указать варианты расширения памяти и хранилища. |
| Документы и приемка | Передать спецификацию, гарантийные условия и протокол диагностики. Выполнить согласованные рабочие операции и пробное восстановление из копии. |
По такому перечню можно сконфигурировать сервер и сопоставить предложения поставщиков. К выбранной сборке приложите обоснование ресурсов и смету запуска: оборудование, лицензии, перенос данных, резервное копирование и настройка.
Критерии приемки согласуют до оплаты. Вместо «программы должны работать быстро» задайте проверяемый сценарий: например, выбранный отчет строится не дольше 60 секунд при десяти одновременных пользователях на согласованной копии базы. Число и сложность операций тоже фиксируют. Это условный показатель: допустимое время согласуют с исполнителем.
Аппаратная диагностика и проверка рабочих задач дополняют друг друга. Первая помогает обнаружить неисправности компонентов, вторая показывает, отвечает ли система требованиям компании. При приемке проверьте также доступ к файлам с нужными правами и восстановление данных из копии. Результаты, выявленные замечания и порядок их устранения внесите в протокол.
Когда нагрузка понятна и есть план обслуживания, первый сервер можно выбирать по проверяемым требованиям. Если же компания пока не определила программы, объем данных или допустимый простой, стоит сначала уточнить эти условия. Готовое ТЗ станет основой и для закупки, и для дальнейшего расширения системы.