Интерлюдия Перед группой «Данные и сервисы» ~5 минут чтения

Хорошее железо само по себе не делает инфраструктуру хорошей

Можно купить сервер за полмиллиона, дорогой NAS и умные коммутаторы — и получить ровно те же проблемы, что были до покупки. Потому что железо — это коробки. А система — это то, как они связаны: где живут данные, где бэкапы, кто к чему имеет доступ и что произойдёт, когда что-то сломается.

Где мы сейчас

Всё железо — уже разобрано

За предыдущие главы мы прошли всю «железную» часть инфраструктуры. Сначала сеть: роутер, коммутаторы, кабели, Wi-Fi, интернет-канал. Потом технику на рабочих местах: компьютеры, компоненты, ИБП. И наконец серверы — своё железо, виртуализация, облако.

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

Потому что само по себе железо — это просто набор коробок. Сервер не знает, где должны жить файлы компании. NAS не знает, как должны быть устроены бэкапы. Коммутатор не в курсе, кто к чему должен иметь доступ. И ни одна из этих коробок не подскажет, что произойдёт, когда она сама однажды сломается.

Главная мысль раздела
Коробка — это ещё не система
Хорошее железо бардак не лечит — оно просто делает бардак дороже. Плохую систему легко собрать и на сервере за полмиллиона. Архитектура начинается не с покупки железа, а с понимания: где данные, где сервисы, где бэкапы, кто к чему имеет доступ и что происходит, когда что-то идёт не по плану.
С чего начинается архитектура

Пять вопросов, на которые обычно нет ответа

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

01
Где живут файлы?
В одном понятном месте — или раскиданы по двадцати компьютерам, рабочим столам и папкам «Разобрать» и «Важное старое»?
02
Где живёт 1С?
На сервере, в облаке, на компьютере бухгалтера? И если этот компьютер завтра умрёт — через сколько минут вы об этом узнаете?
03
Где лежат бэкапы?
Они вообще есть? Когда последний раз кто-то проверял, что из них реально можно восстановиться — а не «вроде настроено»?
04
Кто к чему имеет доступ?
Если завтра уволится ключевой сотрудник — вы сможете за час закрыть все его доступы? Или начнётся неделя «а где-то у него ещё был пароль»?
05
Что будет, когда умрёт сервер?
Если прямо сейчас откажет сервер — вы заранее знаете, что именно перестанет работать, в каком порядке это восстанавливать и сколько это займёт? Или каждый раз это лотерея с элементами археологии?

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

А дальше

Пять глав про то, где живут данные и сервисы

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

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

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

Принцип, выходящий на первый план
Управляемость
Тот самый принцип из наших основ — здесь он становится главным. Если для серверов на первый план выходила доступность, то для данных и сервисов это управляемость: система должна вести себя предсказуемо, а не превращать каждый сбой в квест «где это лежало и кто настраивал». Умер сервер — знаете порядок восстановления. Уволился сотрудник — одна кнопка, а не неделя поисков его доступов. Всё, о чём пойдёт речь дальше, работает на эту управляемость.