Saboteur

ну изучи

1. какую-то систему мониторинга, чтобы мог развернуть, настроить какие-то метрики и смотреть за ними. Возможно + графану для визуализации
2. Какой-нить инструмент для CI (Jenkins, Gitlab CI...)
3. Какой-нить инструмент для CD (можно реализовать на базе тех же Jenkins, Gitlab CI)
4. собственно сам git и систему код ревью (Gitlab, Bitbucket, Github, Gerrit)
5. системное администрирование на уровне установки и базовой настройки пакетов - все что вам нужно, типа кафки, раббит, elastic search и др
6. bash маст хев для автоматизации установок. Питон на базовом уровня для простых вещей, возможно кусков мониторинга

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

ddns это не для того, чтобы обойти проблему белого айпи. ddbs это для того, чтобы решить проблему динамического белого IP

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

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

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

Мне также очень нравится то, что БД пишет данные в volume, который потом можно сжать и скопировать на другой сервер, а не охреневать когда надо перенести базу на сотни гигов.

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

Либо использовать Докер только в крупных проектах которые размещаются на отдельных VPS.

IMHO докер вообще для сайтов не лучшее решение. А самое крутое преимущество докер получает вместе с оркестрацией типа kubernetes/openshift, когда десятки и сотни приложений/микросервисов.

Есть оборудование требующее отправку сообщений умеет только через почту и без авторизации. ( насколько я понимаю оно немного древнее до той эпохи когда появились спамы и тд ;)

SMTP вообще без авторизации может работать, главное слать правильные заголовки домена. Другой вопрос как сейчас сделать быстро SMTP, почта с которого дойдет хоть куда-нибудь.
Но можно слать на локалхост, а с него уже дальше ловить скриптом и пересылать или через нормальный SMTP или например в телеграм

nohup yourprogram &

Там не обязательно есть "файлы". Готовый html/css/js код может генерироваться на ходу прошивкой принтера, а не лежать в виде файлов, даже запакованных файлов, хотя часть возможно и лежит.
Но вряд ли оно лежит на доступной к изменению файловой системе.

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

Реверсишь сетевую активность между сервером и клиентом. Вычисляешь все необхоимые пакеты. Пишешь свой сервер.
Но работа эта может быть огромная.

Свой сервер для Lineage 2 писали несколько лет множество команд добровольцев. Он смог покрыть примерно 60-70% основного функционала. Потому что на сервере и 3д геодата мира, и АИ для монстров и обработка всех событий, заклинаний, навыков с их формулами, и квесты и так далее.
Свой сервер Battlenet для starcraft/diablo писали за месяц, потому что там в общем только авторизация и лобби для старта игры.

В зависимости от того, что делает сервер Мафии (не играл), может быть что угодно. Ну и реверсинг, если сейчас сервер уже нерабочий - КРАЙНЕ затруднен.

По идее в expect должны быть не цифры, а текст который получаешь с сервера, после чего в ответ на этот текст шлется команда

gzip не лучшее решение, ибо он stream, и для случайного доступа к конкретному файлу лучше хотя бы zip

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

Если не файлы, то я думаю s3 (который внутри объектно-ориентированная база) либо другая объектно ориентированная база (ибо s3 бывает медленный)

если они попадают в stderr, перенарпавить его, например
telnet .... 2>/dev/null

а какая разница в экселе или в базе данных хранить данные?

Кто мешает в базе данных считать значения от первого дня месяца?

можно так

import sys
sys.path.append('../folder1')

from name  import функция

Зачем так усложнять?
Сперва разделите на подстроки с разделителем "вертикальная черта", затем пишите регулярку для первой подстроки

Поставь веб сервер на своем компе, и ходи на него. Не будет промежуточных серверов.

Известно, что желательно иметь сервер физически поближе. Но хотелось бы знать цифры. Как задержка запроса зависит от расстояния до сервера? Сколько промежуточных серверов проходит запрос, какая средняя задержка на каждом сервере.

в общем случае, базовую инфу можно получиьт через команду tracert или traceroute (смотря какая ОС). Она показывает пинг ко всем промежуточным хостам (если они отвечают) вплоть до вашей цели.

Как задержка запроса зависит от расстояния до сервера?

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

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

Нужно понимать как работает многозадачность и распределение процессорного времени по ядрам.
В Линукс довольно сложно посчитать реальную занятость процессора.
В сам свитчинг ничего упираться не может, точнее нет каких-то специальных лимитов. Это обычная процессорная занятость, относящаяся наверное к system cpu usage, но это неточно. Чем быстрее процессор, тем быстрее он может выполнять свитчинг и тем больше свитчингов в секунду может быть выполнено, это просто выполнение инструкций процессора вне рамках процессов, а внутри ядра системы, точнее process scheduler.

Но проблема в том, как именно распределяется процессорное время. process scheduler в ядре линукса выделяет слайсы примерно по 10-15 милисекунд на процесс, потом переключает на другой. Для процессов, которые что-то активно вычисляют (например архивация), после анализа деятельности может быть выделен более длинный слайс или несколько подряд, то есть уменьшается свитчинг. При этом оценка времени, которая нужна на сам свитчинг - она довольно сложная, ведь для подсчета количество потраченного cpu нужно потратить cpu, и эти 10-15% может на самом деле не существовать.

Если парралельных процессов очень много и все хотят что-то делать (чекнуть load average), то машина просто не успевает обработать их все, и тратить на переключение приличное количество ресурса, вместо того чтобы непосредственно выполнять код ваших программ.
Таким образом какого-то определенного лимита на context switching нет, это просто еще одна метрика, которая может подсказать что слишком много одновременно запускаете, можно попробовать оптимизировать.

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

Линукс на самом деле не так уж детально может посчитать точное количество ресурсов. Там выполняется все очень просто - на входе в контекст засекается timestamp, на выходе из контекста засекается таймстамп, и потраченное время дописывается в метаданные процесса (для каждого ядра, если процесс многопоточный). Исторические значения не записываются, в метаданных процесса есть только вот это - сколько всего cpu usage с момента старта процесса.
Если запустить какой-нить top, он будет каждые 1-2 секунды бегать по списку процессов, сравнивать этот параметр и показывать результат загруженности за последние 1-2 секунды, но вот уточнить процесс занял свои 25% cpu плавно в течение секунды, или он занимал 100% cpu первую четверть секунды или третью - вы уже не сможете.

Ну и само ядро считает свои внутренние потоки так же само.
И только активность самого process scheduler (то есть cpu затраченное на анализ и переключения процессов) не может быть красиво подсчитана.

p.s. я не разработчик линукс, поэтому это мое IMHO основанное на наблюдениях и обзорных статьях о работе современного планировщика, если будут гуру которые меня поправят или подтвердят сказанное - будет круто.

для js есть готовые библиотеки, которые определяют разрешение в зависимости от браузера и ОС (вычисляет мобильные и десктопные версии).