Digsecman

Задержки меньше когда все на одном кристалле. Перенос контроллера памяти в процессор имеет ту же причину.

1. для начала git плюс какая-нибудь система управления (подойдет знакомство с github)

2. Во-вторых CI Инструмент - Jenkins или Teamcity.
Попробуйте для начала установить локальный дженкинс, и какие-нибудь задачи перенести из cron в Jenkins, посмотреть как это работает

3. Виртуальные машины не должны быть проблемой, vmware и virtualbox сейчас потихоньку замещаются облаками и контейнерами. То есть было бы неплохо иметь базовое представление о том, как работать с docker, aws, kubernetes. Этого будет достаточно, чтобы прийти помощником девопса.

4. Деплой это вопрос отдельный, зависит от проекта. Их множество.

5. Неплохо бы знать что примерно делает maven - это поможет в java проектах.

Saboteur неплохо ответил(что не отменяет того что все остальные ответившие тоже правы)
Девопс - это практики. Это не набор инструментов( инструменты используются на определенных этапах, реализация которых необходима для приближения к идеалу), однако определенные необходимые инструменты опять же есть.
Про девопс можно прочитать очень много информации, но я, как админ (win-админ :D) вижу ситуацию для вас, как и любого, с опсовой основой, примерно так:

1. Жирным вы выделили вопросы который для вас вот конкретно сейчас не играют ни малейшей роли. Дмитрий Шицков и Saboteur написали почему: зависит от проекта.
   
2. Завет любого ops-а: автоматизируй всё что можно
   Если выбор между configuration management (chef, ansible, puppet и тд) и скриптами - то лучше первое. Хотя и тут можно поспорить, у меня в проекте chef-ом автоматизированное не очень-то используется на последнем этапе доставки в прод, поскольку мы все равно запечатываем машину и запускаем в AWS с asg без пост-конфигурации. Тут можно до посинения спорить хорошо это или нет, но скрипты в идеальном мире проигрывают DSL
   
3. Вы пишете код для автоматизации
   Вам понадобится git (который тянет за собой git-хостинг: bitbucket, github, gitlab и тп.) и навыки правильной работы с гитом. Для отслеживания и планирования изменений - понадобится какой-нибудь таск трекер (jira, таск трекер встроенный в gitlab, что-то другое).
   
4. Инфраструктура как код
   Автоматизируй всё означает автоматизацию развертывания инфраструктуры
   Здесь уже вступают в силу особенности вашего окружения - в облаках вы скорее всего захочете использовать terraform или, например, CloudFormation в AWS - встроенное средство оркестрации, или же будете сразу все запускать в контейнерах - docker , kubernetes используя соответствующие инструменты.
   
5. Мониторинг
   Без правильного и подходящего вашему продукту мониторинга(+логирования) жить нельзя. И это было еще до DevOps тренда - это классика администрирования. Здесь ничего не посоветую, с Zabbix-ом сам не ужился, переехал на influx и прилегающие (TICK stack). Для логирования - graylog, ELK. В некоторых частях используется prometheus который в том числе и для кубера удобен. В общем - с чем подружитесь.
   

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

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


P.S. Еще раз хочу отметить что описанное выше основано на личном опыте и это - движение в devops со стороны ops. Есть те, кто сразу пытаются строить все по девопсу параллельно обучаясь опсовой части и девелоперской( видел таких, не у всех получалось ). Есть те, кто двигается в девопс со стороны Dev. Все будут иметь разные мнения что важно для того, чтобы начать

Сисадмин сисадмину рознь. Причем очень большая рознь.
Есть еще такая профессия как devops, это такие отдельные сисадмины.
Есть сисадмины, которые железа в глаза не видят, администрируя удаленно сервера у хостеров.
Есть сисадмины, которые диагностируют или даже сами чинят железо.
Есть сисадмины, хорошо разбирающиеся в сетях, маршутизации, шейперах, VPN и пр.
А есть такие которые в сетях ни в зуб ногой (разумеется базу: IP, шлюз, dns должны знать все), но при этом хорошо зарабатывают, оптимизируя производительность БД.
Есть такие, которые про БД знают только основы.
Есть такие, которые знакомы с консолью поверхностно, что не мешает им.
Есть отдельная специализация - desktop в средних и крупных фирмах. Всяческие полиси и active directory это вам не хухры мухры в больших масштабах.
А есть админы, решающие проблемы домашних пользователей.

Уточните на чем вы желаете специализироваться? Какой род работ у вас будет, кто ваши заказчики?

В обычном принтере есть процессор, ОЗУ, ПЗУ, по сути это отдельный (и довольно мощный) компьютер с дополнительной механикой, который обрабатывает задание на печать, преобразует, например PS в понятный принтеру формат, подбирает шрифты и прочее, и прочее. Это довольно требовательный к ресурсам процесс.

В Win-принтере вместо компьютера просто шутка и все операции по подготовке и обработке задания на печать берёт на себя драйвер на пользовательском ПК. Драйверы, как вы понимаете, только под Windows, потому что Linux производителю исключительно не интересен.

Вот и всё.

Понятнее чем здесь, нигде не написано. Смысла просто копировать сюда нет - там все шаг за шагом подробно описано.