как реализовано, если не секрет?

👍

свое внутреннее название софта. есть шлюзы через которые подключаются сессии рдп и ссх. они все и пишут. подключение выглядит стандарное рдп на: ипшлюза@ипконечное

а запись экрана через что реализована?

как внутри шлюз и его сервера пишут, хз. конкретно я не занимаюсь ими. и не интересны эти пограмистские изощрения

записи и логи в веб мордашке

при этом ссх очень забавно. пишешь в поиск команду: он тебе выдает записи сгенерированные видосиком прям типо путти запущен и как что вводилось в конкретной консоли в данную минуту. и на какой секунде эта команда упоминалась

страшные вы люди

за кем следите?

как на windows server можно уменшить количество потоков чтения файлов с hdd ? Может есть какая-то прога балансировки нагрузки ? подскажите плз. Прога открывает количество потоков чтения с диска, пока все не повиснет.

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

Бэкапы делались на уровне виртуальной машины. Когда умер гипервизор (а подменного точно такого же не было), восстановление на другой не увенчалось успехом. Виртуальная машина не стартовала. Я оперативно починил это, так как часто сталкивался с различными проблемами такого рода. Конкретно тут нужно было накатить другое ядро и обновить initramfs.

Как должен быть организован бэкап:
1. Бэкап виртуальной машины. К нему должна быть инструкция по восстановлению, где будет подробно указано, что и в какой последовательности делать, на какое железо восстанавливать. Соответственно, железо это должно быть. Инструкция должна быть проверена.
2. Бэкап на уровне данных. Делать обязательно в дополнение к бэкапу виртуальной машины. Обычно бэкап виртуальной машины это огромный файл. С ним могут быть различные проблемы. Он может долго копироваться, он может побиться при копировании или создании (сталкивался). Его восстановление может длиться часами. Если у вас есть сырые данные, вы можете оперативно их предоставить и запустить в работу, либо скопировать на подменный сервер из резерва.
3. Для бэкапов должен быть настроен мониторинг. Как его сделать, решать по месту. Обычно это проверка на дату изменения файлов в бэкапе и его объем. Статьи на эту тему есть у меня на сайте.

Когда все три пункта выполнены, можно более ли менее спокойно жить. Я еще по возможности настраиваю хранение бэкапов в двух различных локациях. Более подробно обо всем этом писал не так давно в статье - https://serveradmin.ru/kak-pravilno-delat-bekapy-i-sledit-za-nimi/

сами за собой админы за админами

Фетиш

нет. просто полный запрет на любую отсебятину

и разбор полетов при косяках

Админ СБ?

нет

Насколько админы не очень что за ними следят?

ну например нельзя просто так залезать в ядро сети, даже тем у кого туда есть доступ

Это фиксится обычным договором о трудоустройстве