Дмитрий Шумов

Если нужна именно циска и уровень CCNA, то packettracer. Если вы уже это знаете, то GNS. Если и GNS мало (нужно лабу из 50 роутеров с MPLS, BGP и IP фабрикой), то eveng. Если и этого мало (нужно, например, ознакомиться с особенностями работы Cisco ASR9000), то qemu.

Тут зависит от того, какого уровня знания хотите получить.
Если вы ничего не знаете, и в сетях 0. ТО Packet tracer будет в самый раз.
Нужно учитывать что Pacet Tracer не эмуляция устройств , а симуляция.
Он дает возможно ознакомиться с cli. Плюс какие то базовые возможности по построению сетей.
Так же все это работает из коробки и не надо ничего докачивать. Поставил и сел изучать.

Если вам нужен продвинутый уровень обучения, то выбор для Вас GNS , iOY и прочие решения.
Так как они предоставляют виртуализацию устройств. Вы запускаете реальный образ устройства.
И в принципе все будет выглядеть так как будто у вас настоящее устройство Cisco.
Однако для этого нужно найти образы , поковыряться с настройкой самой среды.
Плюс в старых версиях GNS не поддерживал коммутацию. Нормально поработать с свичами и их функциями у вас не получиться.

На каждую виртуалку надо минимум 2 гига оперативки и 50 Гб дискового пространства, лучше на SSD.
Хорошо, если ядер 4 или выше, но виртуалкам хватит по 2 шт (каждой).
Для изучения AD вполне достаточно Hyper-V, во всяком случае не будет проблем с автозапуском машин и интеграции с хостовой ОС. Hyper-V можно поставить из компонентов в Windows, если она как минимум версии Pro.

1. Заблокировать учетку в AD
2. Выгрузить почту, заархивировать профиль, настроить перенаправление почты (обычно дает руководитель. Если не дает - перенаправить в помойку, чтобы почтовые роботы не устраивали конференций)
3. Переместить учетку в OU для уволенных (иногда они возвращаются :) )
4. Принять железо

Архив писем хранится не менее пяти лет - сталкивался, когда возникала необходимость достать письмо двух- трех- летней давности.

С опытом пришло понимание, что должно быть вот так:

1) Идёшь в бухгалтерию, берешь там список имущества, которое числится на тебе / на отделе, проходишь по всем -- сверяешь, вплоть до старой гарнитуры, всё должно сойтись. Лицензии на ПО точно также. Ты должен в любой момент времени точно сказать -- где, что и сколько у тебя стоит, сколько на складе, что ты заказал, что пришло и то ли пришло. Для бухгалтерии это всё коробочки с лампочками. ОБЯЗАТЕЛЬНО! должны биться серийные номера. Если их нет требуй присвоить инвентарный. Даже на картридже для принтера. Если условная Света из логистики принесла свою мышь, у тебя должно быть это отображено. Всё с парком машин происходить только с твоего ведома.
Не бойся обращаться к руководству -- оно оценит, что ты экономишь их деньги.
Всё, что ты выдаешь -- выдавай под роспись. Это дисциплинирует.

2) Схема сети. Видеонаблюдение и телефония. Как нарисованная, так и WeatherMap в Cacti. Многие ей пренебрегают, почем зря. Ты всегда должен знать что у тебя происходит с каналами связи. Все вланы, все адреса, местоположение должно быть отражено и подписано. Все стойки и шкафы должны быть сфотографированы, так чтобы было чёткое понимание, что-куда-зачем.
Поверь, в случае аварии тебе это очень сократит время на восстановление.


3) Маркировка оборудования. Всё, нет не так -- ВСЁ!!! должно быть подписано. Все розетки, все патчи. Вообще всё!

4) Делаешь себе локальную вики, пох на чем и пишешь туда АБСОЛЮТНО всё. Как настроить порт на коммутаторе, набор основных команд, диагностика, версия прошивки, какая-то основная конфигурация. Бэкапы конфигурации храни в текстовом виде, не доверяй всяким .cfg, как настроить vlan на микроте, как поднять VPN до соседнего офиса.
Тебе это очень сильно сократит время, особенно некоторые операции надо проводить довольно редко.

5) Пиши скрипты для рутины. Скрипты тоже должны быть в вики.
Допустим обновить 5 коммутаторов или поправить ACL ненапряжно. А если их 50? 150?

6) В вики не должно быть ни одной ссылки на сторонние ресурсы. Завтра страница переедет, а ты на нее надеялся.

7) У тебя должны быть контакты всех поставщиков услуг, что касается твоего отдела: провайдеров, заправщиков, инженеров, горсетей, номера договоров, и прочая херня Если что-то случилось, ты должен очень быстро получить ответы, а не ждать на горячей линии. Держи контакты актуальными.

8) Чтобы это всё имело хоть какой-то смысл -- трать 1 час в день, чтобы заняться документацией. Иначе всё это херня.

Системный администратор должен уметь находить и читать документацию.
Любую, какая понадобится.
Это всё.

В остальном, чем больше общий багаж ИТ, тем лучше, даже программирование зайдёт. Хотя основное, конечно, это сети.

чтобы не хранить файлы локально на ПК, а хранить все на СХД и снимать бекап только с одной железки, где все размещено.

это вполне себе повод. но не далеко не единственный, далеко не всегда главный.

все зависит от особенностей работы в компании. на одной из прежних работ, было принципиальным требование, что бы сотрудник, в случае необходимости, мог сесть за любое свободное рабочее место (своего отдела, а некоторые вообще за любое в офисе), залогиниться, и получить свой профиль

в том числе, в случае выхода из строя компа, по любой причине, было принято снимать с полки резервный, залитый и преднастроенный системник, заменять неисправный комп, и в течении считанных минут реанимировать рабочее место. а со сбойнувшим системником, разбираться не спеша у себя в отделе (ИТ), а так же пополнять резерв ))

при таких требованиях, технология перемещаемых профилей, не зависит от календаря в принципе

ps а еще, кроме бекапов, мы использовали DFS для прозрачной миграции с сервака на сервак (или смены дисковой полки), и фоновое зеркалирование, на случай креша сервера, несущего данную нагрузку. типа 24/7, с повышенным уровнем отказоустойчивости, и минимальным временем восстановления.. как то так

Можно установить все и сразу. Здравый смысл подсказывает, что в управлении оптимально - один хост, одна роль. Реальность говорит - ищи компромиссы. Практика - держи ДК отдельно от всего.

Присоединяюсь ко всем, кто высказывает я в пользу наличия аккуратно документации. Ниже приведу принципы, которыми успешно пользуюсь сам. Надеюсь, они помогут вам сформировать свое мнение и встать на "светлую сторону" силы.

Сначала скажу о плюсах документации:
- она помогает вам учиться грамоно структурировать информацию
- есть хорошая вероятность, что в будущем вы сами сможете ею воспользоваться и скажете себе "спасибо" (проверено)
- ею сможет воспользоваться ваш преемник или коллега/руководитель. И, если от преемника вы маловероятно получите какую-либо выгоду кроме морального удовлетворения, то ваш во 2-ом случае это сыграет вам на пользу. Вам будет проще объяснить своему коллеге (да и руководителю) принцип работы, чтобы втянуть его в работу. Руководитель сможет увидеть один из результатов вашей работы, и вы станете более ценным сотрудником в его глазах.
Тут ещё куча плюсов может нарисоваться, но это самые главные.

Принципы:
- пишите документацию так, чтобы человек с минимальными знаниями по теме мог разобраться о чем идёт речь
- в большинстве статей вы скорее всего будете описывать решение конкретной задачи
- остальные статьи, верятно, будут иметь описател ный характер (схема сети, расмещение серверов, список доменов, список можете продолжить сами)
- описывайте только главное, не углубляйтесь в подробности и основы. Для этого есть официальная документация. Вместо описывания основ, дайте ссылку на документацию и пометьте какую информацию там можно найти.
- ведите структурированную документацию там, где возможно. Введите минимал ные разделы: "описание", "ссылки", "инструкция". "Описание" - здесь пишите какую проблему решаете и что получаете на выходе. "Ссылки" - собираете тут все ссылки, которые указали в статье. "Инструкция" - тут непосредственно сами шаги, которые привели вас к нужному результату. Также в начале этого раздела можно привести список требований (наличие root/админского доступа, наличие нестандартных настроек приложенияя/веб-сервера/системных настроек и тд).
- в описании или в начале инструкции дайте пару основных определений, которыми будете оперировать в статье.
- не стесняйтесь приводить иностранную документацию и ссылки, а также не забывайте сами её читать. Сегодня есть отличные инструменты для этого, даже если вы не знаете другой язык. Встроенный переводчик в Google Chrome может перевести сразу всю страницу. Расширение для Google Chrome - LinguaLeo может перевести конкретное слово (пр двойном нажатии на слово)

Хорошая документация не обязательно требует наличия красивых схем и скриншотов. В большинстве случаев достаточно аккуратного описания. Но в некоторых случаях могут понадобится схемы. Тут можно использовать как скриншоты, так и сделать схему самому. Очень гибкий бесплатный веб инструмент для разных схем - draw.io

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