Космическая Сова

Сам использую вот такой вариант

tcpdump -i any port 80 -A | grep -A 10 -P  '(GET|POST|OPTIONS|PUT|DELETE).*?HTTP/1.[01]' |  perl -ne 's/^.*?(?=(GET|POST|OPTIONS|PUT|DELETE))//g; print;'

Рекомендую для сниффинга http использовать tcpflow, там все более грамотно сделано. Пример для использования

tcpflow -p -c -i eth0 port 80

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 - это пишущий код админ. То есть, администрирование широкого профиля, плюс написание своих продуктов вплоть до модулей ядра. Например, Игор Сысоев, автор nginx - вполне себе DevOps, написавший веб-сервер под свои нужды.
Управление конфигурациями - это Chef, Puppet, Ansible - автоматизация конфигураций. Централизованное хранилище, которое позволяет подробно описать всё хозяйство - конфигурации машин, набор приложений, конфиги самих приложений, вплоть до того, что ты запускаешь клиент и идёшь пить чай. Через какое-то время у тебя полностью настроенный хост, готовый войти в продакшен.
Continuous integration - это слегка из другой оперы. Подразумевает средство тестирования и выкладки кода, багтрекер, контроль версий и автоматизацию всего как единый процесс, это всякие Jenkins, Teamcity, Hudson и так далее .
И да, первые два направления очень желательны. Без chef/puppet вообще сложно представить себе серьёзный проект, так или иначе он будет обмазан автоматизацией - мелкими скриптами и прочей наколеночной хренью. DevOps как промежуточное звено между кодером и админом - тоже очень серьёзная штука. Когда админ понимает как работает код, видит как применить тот или иной вызов системы, что такое COW и как тот же ruby гадит в память - это хороший админ.
Параллельно DevOps есть такая штука как эксплуатация. Это более "обычные" админы, которые не пишут сложные вещи, предпочитая python и bash с perl, решая задачи автоматизации низкого уровня.
Вообще, конечно, всё это дико размазано и в России не очень стандартизировано.

Если на пальцах, то:

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

Управление конфигурацией, вообще-то говоря, не всегда (и скорее - не) связано с DevOps, так как тот же Amazon позволяет успешно обходится без нее, если собирать AMI образы системы и катить их. Это в частности является еще одним доводом за DevOps, дескать благодаря SaaS и облачным хостингам администрирование стало слишком простым, чтобы держать админов на фултайм.

CI - это одна из "хороших практик" которая цена и сама по себе, не как часть DevOps. Когда ваша ветка мержится в development, запускается автоматическая сборка билда и прогона тестов (например, в Jenkins). Если после успешной сборки и прогона тестов билд еще и сам выкатывается в dev или stage окружение, это называется continuous delivery.

На мой взгляд, как вектор развития следует рассматривать бесспорно, так как хороший админ должен всем этим владеть и в любом случае уметь программировать хотя бы небольшие программы на Ruby / Python.

Вы сами ответили на свой вопрос

16 гб USB TOSHIBA

Ставьте на нормальный диск и глюки пропадут. Либо используйте нормальную быструю флешку с USB3.0

Итак. Stepic не для начинающих.
Для совсем начинающих, на торрентах курс ITVDN. Изумительный курс. С ним лучше параллельно читать Шилдта «Java 8. Руководство для начинающих», а уже потом можно stepic.
Очень понравился курс Петра Арсеньева, также торрент.
Есть ещё классный курс, но он для продвинутых OTUS, на торрентах их два.
JavaRush не рекомендую, но для детей самое то, и он уже не бесплатный.
В любом случае нужно прорешать задачник Златопольского "Сборник задач по программированию", руку набить и прочитать книгу по алгоритмам Седжвика, и книгу «Чистый код». Курсы же должны быть платные, чтобы проверяли задания, в этом их суть.