Сергей Сашкин

Прошу помочь с оптимизацией данного скрипта.

Избавиться от цикла, перенеся логику внутрь команды передаваемой в --msg-filter. Примерно так:

#!/bin/bash

fille="$1"

cmd=

while read -r line; do
  source=$(echo "$line" | awk 'BEGIN { FS = "," } { print $1} ');
  target=$(echo "$line" | awk 'BEGIN { FS = "," } { print $2} ');
  cmd="${cmd}s,$source,$target,g;"
done < "$file"

git filter-branch -f --msg-filter "sed -e '$cmd'"

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

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

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

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

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

https://3proxy.ru/howtor.asp#ERRORS
это значит, что клиент не передал имя пользователя. Скорей всего, вы пытаетесь в браузерах протестировать, а они не поддерживают авторизацию по паролю в SOCKS.

Использовать autoscaling, основываясь на параметрах утилизации ресурсов. Например, при утилизации процессора или памяти в 75% добавляем ещё один инстанс в балансировщик и распределяем так нагрузку.

Почитайте как это работает в облаках

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