runprogr, любую, говорите... Ну сравните, например, Росатом, и любую другую корпорацию в мире по масштабам строительсва АЭС. Будете неприятно удивлены. Росатом -- мировой лидер по масштабам и количеству заказов на строительство и обслуживание АЭС.
Вы выдыхайте иногда. Возможность прослушки, конечно, зависит от технологических решений, но далеко не так прямо, как вы думаете. И довольно простыми мерами можно обеспечить CIA triad, независимо от технического оснащения потенциального противника.
Saboteur, это вы просто малость не в курсе. Одной автоматизации мало, для нормального управления большими инфраструктурами понадобятся выстраивать процессы доставки конфигураций. И тут нам пригождаются понятия CI/CD. А это как раз DevOps.
1С -- тупиковый путь, соглашусь. А вот практики DevOps очень даже относятся к системному администрированию. В какой-то момент размер инфраструктуры достигает таких размеров, что админить руками уже просто невозможно -- потребуется либо штат IT конских размеров, либо конское же количество времени. Тогда на сцену выходят автоматизация и построение процессов управления инфраструктурой. И вот тут-то методы DevOps очень даже пригождаются.
АртемЪ, я про то, что "Низкая очередь или ее отсутствие характерна для работы пользователя" вообще не показатель ничего, т. к. современные системы даже в самых простых операциях генерят более 1 конкурирующего IO. Т. е. даже если рассматривать сценарий одного пользователя с печатью документов в ворде, то и в этом сценарии длина очереди будет больше в среднем.
wawawa, всё от задач и бюджетов зависит. Есть класс решений (т. е. конвергентные системы), которые расширяются путём добавления серверов. Это, например, VMware vSphere + vSAN или Hyper-V + Storage Spaces Direct или KVM + Ceph storage. Т. е. вычислительные мощности и storage презентуются с одних и тех же серверов, а построение отказоустойчивой распределённой системы хранения возлагается на софт (VSAN, Ceph или кто там есть ещё).
СХД можно покупать, когда вам бюджет позволяет. Профит СХД -- бОльшая устойчивость по сравнению с распределёнными софтверными решениями (даже вендорскими, т. к. с VSAN, например, мы уже поимели ряд серьёзных проблем, которые нам всё облако укладывали на бок).
Валентин, это неважно, что там за розеткой. Стандарт не просто так придуман, эти схемы определены порядком следования пар и шагом витков. По обжатому "как попало" кабелю запросто может даже сотка не запуститься, не говоря уже про гигабит. Либо дикие потери будут при передаче.
Если скорость по кабелю -- не более 10 мбит, и кабель короткий, то да, можно как угодно провода раскидывать в коннекторе, и будет работать нормально. Если же нужны скорости выше и длина более 2-3 метров -- надо пользоваться стандартным разведением.
АртемЪ, сегментация обязательна, точка. Если делать, то сразу делать по уму, а не копить технический долг, в надежде что "потом разберёмся". Практика показывает, что чаще всего "потом" никогда не наступает.
Если у вас опенспейс или три комнаты подряд - откуда там левые DHCP-сервера?
Да легко -- любой сотрудник поднял виртуалку/загрузился с LiveCD/поставил tftp32/воткнул в розетку вместо компа WiFi-роутер -- и вот вам левый DHCP-сервер. А то и не один.
АртемЪ, "обойтись" можно вообще без коммутаторов, и даже без маршрутизатора. Только работать это будет так себе.
Беготня к железу нужна только в одном случае -- когда нужно коммутировать оборудование. В остальных случаях беготня не требуется, управляемое там сетевое железо или нет. А вот настраивать грамотную сегментацию и исключить, например, появление левых DHCP-серверов -- тут без управляемого железа никуда.
