Rodion

Подними Gitlab или Jenkins или Teamcity

есть.
1/2 в зависимости от бука.
конечно удобно. иначе смысла в их подключении не было бы.

и дело вообще не в диагонали бука: несколько экранов удобнее и продуктивней.

вообще на рабочем месте есть дополнительный моник. но когда нужно куда нибудь взять бук куда нибудь(на улицу или на учебу) тогда вприцнипе и без монитора нормально. Но на рабочем месте очень удобен 2 монитор для программирования.

Тоже два монитора. Очень удобно. На одном играю, на другом кино смотрю)

Если пробелы есть в основах, то Лутц. Если надо углубится, то "Fluent Python" Ромальо. Если надо подтянуть стандартную библиотеку, то официальная документация. Если понять нюансы работы CPython, то можно почитать "Inside The Python Virtual Machine".

Добавьте название для логгеров
log_left = logging.getLogger('left')
log_right = logging.getLogger('right')
Если не передавать название, то будет приходить root - логгер, который один

Какие-то больно странные пути.
А вообще да - тут всё POST-ами должно быть, тк нельзя отменить отменённую операцию.
Ну и имхо, такая логика плохо на rest кладётся, так что вполне ок сделать

На создание новой задачи
POST /api/machines/{machineId}/jobs
И в теле указать, что это start/stop/reset

На отмену
POST /api/machines/{machineId}/jsobs/{jobId}/cancel
Не DELETE, тк по семантике, после DELETE ресурс должен исчезнуть.

На получение списка
GET /api/machines/{machineId}/jobs

На получение инфы по конкретной задаче
GET /api/machines/{machineId}/jobs/{jobId}

Если нужно получить список задач на включение:
GET /api/machines/{machineId}/jobs?type=start

По именованию, кмк, лучше выглядит слово "machine" и "job", а не "computer" и "operation"

Потому что uvicorn - это не менеджер процессов. Он запускает ровно один процесс, в котором будет один ивент луп, который будет всё крутить на одном ядре. Если у тебя 4ядерный проц на сервере, то для полной утилизации ресурсов нужно запустить как минимум 4 таких uvicorn’ов. Для этого gunicorn здесь и нужен.

Скорее всего files принимает список, исходя из 's на конце.

Имел аналогичный опыт пару лет назад. CHR фактически только частично использует проц для шифрования, а хэши считает софт. 30 мегабит/с удалось выжать, не больше. Но как выснил тогда, хостинг не позволял полноценно иметь AES passthrough в виртуалку с CHR.
Так что, нужно уточнить у вашего хостинга, в котором будете размещать CHR, есть ли полноценный проброс аппаратного шифрования физического процессора в виртуальную машину. Если есть, скорее всего взлетит, но возможно с танцами с бубном вокруг вариантов настроек протоколов шифрования.
А вот на стороне железного микротика при условии, что модель будет с аппаратным шифрованием, проблем с шириной полосы не будет (там всё будет соотвествовать спецификации к вашей железке).
Виртуалку выбирайте по принципу "больше 2,2 гигагерц", на количество ядер забейте, так как будет задействовано только одно ядро.
В общем-то лучше купить второй аппаратный микротик и воткнуть к какому нить ДЦ, где у вас уже есть что-то.
Еще вариант - забить на шифрование. :)