athacker

Почитайте "Тайм-менеджмент для системных администраторов" Томаса Лимончелли. Хорошая книга, и отчасти даёт ответы на вопрос "как организовать приём и обработку пользовательских заявок".

Нужно внедрить тикетную систему, и всех вежливо склонять к заведению заявок именно через неё. Если не хотят заводить заявки пользователи -- заводите за них сами. Т. к. это позволит не терять заявки, и заодно будет видно, сколько времени потрачено на каждую заявку. Для заявок типа "сами нажали кнопку DND" можно сделать специальную отметку, чтобы при выгрузке отчёта по времени можно было отличать заявки по делу от вот такой хрени, и потом показать начальству, какой процент времени вы решаете проблемы совсем не профильного характера.

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

Начать продвижение в массы тикетницы можно с молодёжи. Они более обучаемы, им легче разобраться с интерфейсами. Когда народ поймёт, что заявки через тикетницу выполняются быстрее, то сарафанное радио это постепенно разнесёт по всей конторе.

И главное оружие админа -- это вежливость :-)

-- У меня там проблема такая-то и такая-то!
-- Извините, я сейчас занят такой-то проблемой. Создайте, пожалуйста, заявку, а то меня сейчас отвлекут, и я про ваш вопрос забуду.

Ну и медленно, но неуклонно гнуть процесс именно к этому. Чтобы мысль "заведёная заявка а) выполняется и б) быстро, а озвученная на бегу в коридоре выполняется либо медленно либо забывается" постепенно дошла до всех.

С новыми пользователями ещё проще, их можно сразу подсаживать на эту схему, мотивируя тем, что "у нас так принято, так построен процесс, вот тут инструкция, почитайте, пожалуйста. Если будут вопросы -- готов ответить".

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

Вариант хранения всех файлов в облаке с монтированием локально по WebDAV вам не подойдёт? Винда умеет WebDAV-хранилища монтировать как локальный диск.

В конфиге сквида параметр tcp_outgoing_address.

Ну, видимо, когда вы локально создаёте файл и когда загружаете на сервер, вы делаете это под разными учётками. Отсюда разные права на файл. Сравните права доступа у созданного и у залитого.

Возможно, проблема с драйвером. Попробуйте более свежий драйвер адаптера поставить. Также я встречал упоминания, что такая проблема появляется, если на системе установлен антивирус McAffe.

mRemoteNG юзаю. Нет проблем ни с SSH, ни с RDP.

Хостнейм у вас резолвится в сети этот? vcenter.vmware.local ?

А разлогинить пользователя и подождать какое-то время, прежде чем зайти снова, пробовали? Я бы поставил на то, что к первому перелогину изменения ещё не отреплицировались, а пока пользователь выходит и заходит второй раз -- всё уже долетает.

Так может, ничего не происходит, из того, что должно логироваться? Поэтому и в логах ничего нет.

Исходя из описания следует, что оповещения будут отправляться только на триггеры с уровнем warning и выше. Может, вы information-триггеры дёргали, вот по ним и не отрабатывали оповещения? :-)

Private VLAN, он же port isolation для микрота: https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_...

Например, вот: https://habr.com/ru/company/webzilla/blog/227927/

Во время теста в blktop наблюдалось что-то странное: часть дисков загружена в потолок, часть почти простаивает. Причём загружены в потолок те, кто показывает низкую производительность, а «быстрые» диски простаивают. Более того, диски иногда меняются местами — то есть раньше загруженный на 100% диск вдруг показывает бОльшую скорость и меньшую загрузку, и наоборот, диск, который был загружен на 50%, вдруг оказывается загружен на 100% и при этом показывает меньшую скорость. Почему?

И тут до меня дошло.

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

Отсюда, в частности, следует, что на рабочих станциях документов быть не должно. Никаких. Ни при каких условиях. Вся рабочая информация -- только на серверах. И бэкапятся только сервера. Рабочие станции -- это расходники, сломалась -- выкинул и новую поставил. Потом из трёх сломаных рабочих станций можно в свободное время собрать одну, например, но ценных данных там быть не должно. Кто хранит документа на локальном диске -- того вывести в чисто поле, поставить лицом к стенке и пустить пулю в лоб, чтобы на всю жизнь запомнил к директору на ковёр, с объяснительной на тему "почему подвергает риску данные компании".

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

Не очень понял, почему вам RDP не очень помогает. Может, вы его готовите неправильно?

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

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

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

Сегментация сети -- это не просто правила хорошего тона, это необходимость, особенно в свете развития малвари/вирусов и прочих угроз ИБ. Принтеры/телефоны -- легко уязвимые устройства, поэтому их нужно изолировать. Плоская сеть, где все компы организации находятся в одном влане/сетевом сегменте приведёт к тому, что любой залётный NotPetya распространится по всей сети в считанные минуты. И будет как здесь. Или мамкины хакеры какие-нибудь начнут ковырять компы соседнего отдела по сети. Так что сгементация и настроенные правила хождения трафика между подсетями -- это must have в современных условиях.

В случае с gmirror -- нет, расширить RAID не удастся. Нет такого функционала. Только бэкап всех данных, потом разбивка массива в RAID10, потом возврат всех данных из бэкапа.

Можно перейти на ZFS, там можно расширять ZMIRROR, добавляя зеркала.

1) фольгированная витая пара -- только между этажами. С обязательным заземлением, иначе толку от неё не будет. В остальном можно разводить обычной UTP без экранирования;

2) Коммутаторы должны быть на каждом этаже. Не хватает 16 портов -- ставьте 24-портовые. Не хватает 24-портовых -- ставьте по 48. Но реально жить будет проще, если у вас коммутаторы доступа будут стоять на каждом этаже. Потому что тогда вам можно будет купить менее ёмкие коммутаторы агрегации и поставить их в серверной. Менее ёмкие -- потому что туда не все на свете компы будут сведены, а только коммутаторы доступа. Подключение каждого коммутатора доступа к агрегации -- двумя линками, в ether-channel, для резервирования;

3) Citrix XenServer... Ну такое... Посмотрите на картинку и найдите там XenServer:


4) "SSD в рейд-массивах не дает преимуществ" -- шта? О_о Собирать SSD в RAID10 -- несколько расточительно. Хотя, конечно, если у вас бюджеты не ограничены... Я бы собирал массив так -- как можно бОльшее количество дисков небольшого объёма, которые бы уже собирал в RAID6 или RAID60 (в зависимости от количества дисков и потребных объёмов). Вот шпиндельные диски -- их имеет смысл в RAID10 собирать, т. к. больно медленные. Но подход тот же самый -- диски меньшего объёма, но в большем количестве. В последние годы я постоянно наблюдаю ситуации -- есть до фига объёмов, но не хватает производительности. Обратное -- производительность есть, но мало объёмов, пока не попадалось. Отсюда рекомендация брать диски поменьше, но количеством побольше. Хотя всё зависит от задач, конечно. И от бюджетов.

Да, и "RAID-массив в стойку" не поставить. Поставить можно железку. Какую-то. Промышленную СХД, например. Или самосборное хранилище (считай, обычный сервер, с линукс или FreeBSD на борту, настроенный на отдачу объёмов по какому-то storage-протоколу). Или корзину DAS. Или NAS. Перечислены в порядке предпочтения. Опять-таки, всё зависит от бюджета.

5) ИБП нужно брать с запасом не 50%, а 100% или даже 200%. Потому что когда вы докинете ещё серверов, то ваши 50% будут съедены моментом. Или когда у вас нагрузка поднимется, то тоже начнёте упираться в потолок мощности ИБП. А то, что нагрузка будет расти и сервера придётся добавлять -- это к бабке не ходи. Поэтому брать нужно с большим запасом, не менее 100%. Как вариант -- брать ИБП, к которым можно подключать внешние блоки батарей. Но мощность ИБП всё равно должен иметь с запасом не менее 100%.

6) Датчики влажности, температуры без регистрации и SMS и возможность отправки SMS-сообщений лучше реализовать с помощью устройств типа UniPing server v3/SMS. Датчиков там отдельно можно докупить всеразличных, вплоть до инфракрасных управлялок для кондиционеров в серверной.

7) RAID-ы в виртуалках -- это бред, конечно же. Достаточно обеспечить отказоусточивое дисковое хранилище. Лучше всего с отказоустойчивостью дела обстоят у промышленных СХД, конечно же. HPE MSA, Dell MF -- вот это вот всё.

8) Правила распределения сервисов по виртуалкам очень простое -- один выстрел -- один труп сервис -- одна машина. Т. е. под почтовый сервер -- одна виртуалка. Под DNS -- ещё машина. Даже две. Под контроллеры доменов -- две виртуалки (минимум). Под DHCP -- ещё машина.

XXX) Если заказчик хочет, чтобы всё работало хорошо -- то лучше, конечно, пригласить профессионалов. Потому как судя по вашим вопросам, вы пока ещё таковым не являетесь. Если же он готов терпеть и пожинать плоды экспериментов в течение довольно долгого времени -- тогда конечно.

XXX+1) Да, и про резервное копирование не забудьте. Чем бэкапить, и куда складывать. Hint: складывать на ту же хранилку, на которой виртуалки работают -- моветон и чревато печальными последствиями.