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. Все будут иметь разные мнения что важно для того, чтобы начать

Во первых задумайтесь, нужна ли вам эта помойка
Чтобы сломить (пусть даже и немного) политику "экономим на всем кроме гелика гендира" нужно время и терпение:
Первое: разводим бюрократию, фиксируем все проблемы пользователей, замены компов, количество походов к пользователям в неделю на человека, особо отмечаем проблемы с безопасностью - сколько времени потребовалось чтобы вычистить комп менеджера Васи от вирусни которую он нахватал, какие риски могут возникнуть если менеджер Петя откроет письмо от "дяди Мнглуи" из Южной Африки.
Сколько простаивал складской комп пока вы удаляли с компа кладовщика Иннокентия порнографию.
Сколько литров чая было выпито за общением с бухгалтером Таней, пока показывали как печатать на новом принтере и т.п.
Это, по сути - работа начальника IT отдела, но одновременно - деньги бизнеса, потому что именно бизнес платит вам вашу зарплату (за которую вы почему то держитесь)

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

Как быстрые решения:
- ставьте агент удаленного управления на каждую машину - поможет меньше между ними бегать
- стандартизируйте ПО и способы его установки (пусть это будуть хоть cmd скрипты, пофиг - лишь бы вы не сидели и не ждали очередного окошка визарда с кнопкой "NEXT" пока он там что-то затупил
- в общем и целом придумывайте как минимизировать всю беготню чтобы заняться самообразованием и улучшением ситуации качественно, а не количественно

скайп в 10-ке, как и многие другие приложения, умеет работать в фоновом режиме
(вспоминаем телефоны, где в фоне вы можете получать уведомления от вайбера\скайпа\телеграма и прочая не выводя их на передний фон).
Нажимаете пуск, вводите в поле поиска фон и выбираете пункт "выберите какие приложения могут запускаться в фоновом режиме".
Откроется пункт меню настроек windows, где вы можете запретить фоновый режим в принципе, а можете - только определенным приложениям.
Проверено - после этого вайбер перестал беспокоить бессмысленными сообщениями (потому что скайп нужен :D а вайбер - нет)