Saboteur

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

Вообще вопрос немного неясен. Ответ как бы элементарный - установка и настройка бота.
Детальный ответ тут больше будет как выполненная за вас работа, а в этом случае вам на фриланс

Нет, докер не работает с системой на которой установлен. Он использует ее ядро, а дальше - зависит от докер образа.

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

В глаза кидаются мелочи типа

В каждом сервисе подключен бутстрап конфиг, в котором подключены 4-5 конфигмапов дополнительно

А почему у вас несколько конфигмапов на одно приложение, а не один конфигмап?

При выдаче изменений версионных, в основном, требуется к примеру в 10-и конфигах сделать изменения

Почему из-за изменения версии, нужно делать изменения в конфигмапах, тоже неясно. Что-то себе придумали, и при масштабировании оно оказалось неудобным.

По итогу можно провтыкать изменить на каком-то окружении параметр, и всё..окружения уже не одинаково настроены.

Делать статические параметры, и в конфигмапы выносить исключительно environment-related опции.

По вашему вопросу никто не скажет решения. Это нужно сесть и переделать.
У меня свыше 100 компонентов, десяток енвайрнментов. Конфигмап один на неймспейс, секрета два на неймспейс, в принципе достаточно.

Сперва стать сисадмином.
Настрой мониторинг, подучи парочку скриптовых языков, автоматизируй задачи.
Разберись с основными продуктами - базы данных, билд системы, гит+код ревью.
Начни изучать контейнеры и облачные сервисы.
Для начала хватит.

Я бы замутил велосипед на ансибл.
настроить все sshd, чтобы ключи читались только из /etc/ssh/keys/%user/, чтобы никто себе руками ничего не ковырял. И все. Раз в сутки по всем машинам пробежался, обновился и готово

Там и питон не обязательно знать... базового вполне может хватить.
Девопс должен уметь админить и автоматизировать администрацию и оркестрацию.

Если ты можешь написать на питоне скрипт, который получит по веб какой-то json, распарсит его и конвертнет в нужный формат, например в sql query или хотя бы cvs - уже полдела сделано

Обычно в таких случаях я лезу на сервер и делаю `pt-online-schema-change`, но что делать для "правильного" CI/CD?

В правильном CI/CD таких изменений быть не должно. Задача архитектора - создать приложение, которое легковесно и без проблем как деплоится, так и откатывается.
Задача девопс инженера - автоматизировать деплой и откат разными инструментами.
Понятно, что все могут работать вместе и разрабатывать какой-то флоу, но если разработчики приходят с такими процессами, тут нет волшебных ci/cd инструментов которые сделают тяжелую задачу мгновенной.

Если вы не можете повлиять на решение девелоперов и архитекторов, то не важно - любое рабочее решение, которое вы придумаете в пределах вашей инфраструктуры будет норм. И две базы, и релиз по ночам и что-нибудь еще.
Но DevOps как культура как раз и говорит, что надо менять подход к работе, а не взять крутого человека, который возьмет весь бардак, засунет его в какой-нить ансибл/дженкинс, подключит плагин с AI и все порешается без изменений.

Да все пишется скриптами.
Любой инструмент, который может подключиться по ssh или имеет свой агент.
Начиная от дженкинс/ансибл и заканчиваая какими-нить ентерпрайзными IBM uDeploy/Octopus

Нужно понимать, что bare metal или просто виртуалки не умеют откатываться автоматически - им просто руками нужно прописать откат, а для этого во время деплоя просто делать бэкап (fs snapshot, tar.gz, или версионирование как сам придумаешь).

В подавляющем большинстве случаев, проблема отката больше с тем как базу назад откатить.

В вашем случае было бы удобнее всего работать с докером.
При этом все тесты должны быть автоматическими и запускаться на localhost

Любым CI инструментом настраиваете триггер на коммит или пулл реквест, чтобы собрать проект, сбилдить докер образ, запустить его и внутри запустить автотесты.

Для ручных тестов, конфигурация будет гораздо, гораздо сложнее, тут уже не вопрос на тостер, а масштабная работа.

Сертификаты не должны быть частью docker image, и должны монтироваться снаружи. Тогда обновление сертификата не будет требовать нового билда продукта.
Прокидывать снаружи их можно через mount
Тогда обновил сертификат на маунте и перезапустил контейнер.
Если жить в кубере/опенщифте - там сертификат можно в секрете хранить и монтировать как файл.

ls -1 *.yml | xargs -n1 kubectl -f apply

Те переменные, которые могут часто меняться, храните прямо на сервере или configmaps в кубере
Те переменные, которые секреты - в хашикорп или другом хранилище секретов.

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

1. Реальные кейсы написания и использования Bash скриптов, какие задачи они решают?

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

2. Сколько часов, ориентировочно, потребуется на изучение и практику написания скриптов на Bash, как глубоко погружаться?

можно всю жизнь учить любой язык программирования и все равно узнавать новое. bash не исключение, особенно еще и потому что все самое лучшее в bash глубоко завязано на понимание архитектуры Линукс.
Вдобавок, если ты что-то можешь сделать на bash, а потом найдешь какой-нить декларативный оркестратор, ты будешь хорошо понимать что происходит под капотом и интуитивно понимать где что может пойти не так и как это починить.

3. Что должен уметь написать на Bash junior/middle/senior DevOps?

Слово все тут подойдет.

4. Возможно для на Bash скрипты стоит потратить день-другой, уметь писать базовые скрипты и переходить к изучению Python?

Возможно их стоит учить парралельно. Решая одни и те же задачи на питон и баш быстро поймешь, какие задачи конкретно тебе удобнее решать так или иначе. Опять же бывает разная инфраструктура, разный доступ, где-то ты можешь поставить python3, а где-то вообще нет прав доступа что-либо устанавливать.

Python:

1. Где и для чего используется Python на практике DevOps, реальные, повседневные кейсы использования?

Автоматизация, мониторинг, универсальные скрипты. Питон очень неплох в автоматизации вебзапросов. Все можно сделать чере curl, но многое через питон может быть удобнее. Плюс обработка исключений.

2. Каким уровнем знаний Python должен обладать junior/middle/senior DevOps? (Знакомый middle DevOps и Python не знает от слова совсем).

Если ты знаешь питон на уровне сеньор, то не факт что тебе будет интересно работать на позиции девопс. Можно работать девелопером на питоне.
Поэтому знания питона на уровне джуниора обычно достаточны. Но нужно понимать, что джуниор - это не тот, кто знает две команды. Это полноценный разработчик, который знает и структуры данных и стандартные библиотеки и все конструкции. Уровень джуниор в языке программирования должен позволять устроиться на позицию джуниор разработчика.
Девопс инженер, который знает язык программирования на уровне джуниор разработчика - полезный человек, который сам решил углубиться в питон. И в айти области часто людям что-то нравится и они этим занимаются и углубляются вне зависимости от рабочих задач.
Поэтому у большинства именно девопс инженеров знания именно о языках программирования немного отрывочные, но их хватает для написания универсальных скриптов и небольших утилит.
Я в свое время писал простые и не очень вещи на ANSI C/С++/java/python/perl/actionscript. Сейчас почти все делаю на bash и иногда python, и все предыдущие знания мне помогают выбрать чем воспользоваться - написать что-то свое, найти готовую реализацию на другом языке, попросить в проекте, чтобы написали задачу (это тоже вполне себе способ для рабочих нужд договориться с разработчиками о написании нужного функционала для автоматизации/тестирования). Но главное, что я сам могу оценить примерный выхлоп от того, чем делать.

3. Сколько часов, ориентировочно, потребуется на изучение и практику под каждый уровень, как глубоко погружаться?

Сколько часов нужно ориентировочно футболисту, чтобы стать таким как Месси?
Сколько часов нужно музыканту, чтобы стать таким как Фредди Меркури?

Это глупейший вопрос. ВСЕ люди разные. Никто не знает с какой скоростью ты обучаешься, какая у тебя на текущий момент база.
С одинаковым количеством времени за всю школу одни выходят отличниками, другие двоечниками.
С одинаковым количеством усилий одни делают работу, другие выпускают шедевры.

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

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

Идти в девопсы с нуля - это нахвататься теоретических знаний, нахвататься практики только на курсах и пытаться оркестрировать что-то? Понимание архитектуры никакое, понимание зачем нужны инструменты и нужны ли они в данном конкретном случае - никакое.
Такой инженер может выполнять только задачи по указке, если есть другой специалист в проекте.
Поэтому джуниор девопс может существовать либо в проектах, где есть команда девопсов, которая готова взять человека на вырост и нагрузить его мелочевкой а то и вообще бюрократией. Либо если в проекте кто-то из разработчиков занимается всей этой задачей и хочет сгрузить на другого человека, которого опять таки он будет полностью контролировать.

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

Выбор инструмента - это частности. Понимание какой должен быть результат - важен.
Те же самые вещи можно делать и башем и питоном и ансиблом и чефом и перлом и не так важно что было выбрано, разве что стоит вопрос расширения и поддержки. А вот что именно делать и как это все увязывать...
почитайте например git flow, и важно не сам гит - это вообще базово должно быть само собой, а зачем git flow нужен и прикинуть какой вариант подойдет в нужном проекте. Это уже как раз задача которую решают совместно девопс инженер и архитектор/тимлида.

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

В сложном проекте конфигурация может выглядеть так:
Мастер крутится в своем более-менее стабильном контейнере и рулит исключительно задачами, воркеров не запускает.
Есть несколько видов подготовленных контейнеров для слейвов - для сборки и для тестов, с разной конфигурацией. В некоторых случаях можно даже тут сделать разные контейнеры для сборки nodejs, сборки питона, тестов, и например контейнер для performance тестов.
Во время пайплайна нужные шаги выполняются на нужном слейве, а слейвы динамически поднимаются, если очередь вырастает и также автоматически уничтожаются, когда они не нужны. Например если контейнер поднимается за 1-2 минуты, то при простое в 20-30 минут его можно тушить. Так вы и сократите время билдов, когда их много, и сэкономите деньги на ресурсах, когда они простаивают.

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

Если просто обнулить файл, то обычный
echo "" > file
если нужно сохранить часть файла, то можно считать кусок из файла и записать в него же

tmp=$(tail -n 1000 file)
echo "$tmp" > file

Так спросите у тех, кто задал задание, ибо неизвестно что они себе придумали.

А как вы впервые стали сисадмином, вы же тогда не были сисадмином?

Вот откуда такой вопрос?
Неужели сложно поискать вакансии, почитать в них требования?

Познакомься со следующим:

1. Система мониторинга. На хайпе сейчас prometheus/grafana, но можно посмотреть любые другие системы + графана.
2. оркестрация, например ansible для управления своими серверами
3. изучи баш на уровне "быстро напишу скрипт который что-то скачает, развернет, скопирует, подчистит, получит текст по curl и распарсит из него нужные строки, запустит приложение и убедится что оно успешно запустилось"
4. Можно также подучить python/groovy на базовом уровне.
5. Все свои наработки храни в git, а еще лучше поставить какой-нить gitlab и почитать о парочке git workflow
6. После этого настойчиво рекомендуется ознакомиться с контейнерами docker/kubernetes/openshift

Если за год осилишь, можно пробовать поискать что-то начальное, где есть команда девопс инженеров.