Saboteur

Варианта два.
1. Переразбить каталоги в репозитории таким образом, чтобы общие вещи было /common, разные вещи были в /prod1 /prod2 и при сборке соответсвенно собирать разные дистрибутивы из (common+prod1) или (common+prod), каждый со своим набором фич. Для этого и джобы в CI разные сделать. Можно даже девелоперов в разные команды распределить. Зависит от того, насколько далеко будут расползаться ваши продукты

2. Сделать, чтобы включение фич зависело от конфигов. Тогда дистрибутив будет один, но в конфиге prod1 будет feature1=enabled, feature2=disabled и в prod2 будет наоборот.

Выбирайте что вам подходит больше. Может какая-то смесь.

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

START TRANSACTION;
   INSERT ...
   INSERT ...
   ...
   COMMIT;

Отключи проверку уникальности ключей перед восстановлением

SET FOREIGN_KEY_CHECKS = 0;
   SET UNIQUE_CHECKS = 0;

после включи ее назад

SET UNIQUE_CHECKS = 1;
  SET FOREIGN_KEY_CHECKS = 1;

Это то, что навскидку.
А так - сам mysql достаточно хорошо оптимизирован и под Линукс и под Виндовс. Думаю у тебя все же винда и линукс имеют либо разные спецификации железа либо настройки самой mysql..

1. Насколько сложно получить удаленную работу для начинающего iOS разработчика позиции Junior? Получить удалёнку, хотя бы, на самое первое время, с последующим переездом и работы в офисе на компанию?

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

2. Являются ли вообще те самые объявления, немалое количество которых я нашел на HH - настоящими, подлинными, действующими? Т.е. те объявления где работодатели или компании действительно ищут начинающего разработчика iOS уровня junior, с возможностью удаленной работы?

Никто не знает, пока вы не позвоните по объявлению и не выясните. Вряд ли кто-то возьмется сейчас исследовать все объявления на HH чтобы выяснить там предлагают работу или берут в плен и продают в рабство.
Нужно понимать, что у более-менее стабильных компаний, зачастую список вакансий можно найти на сайте этих компаний, поэтому рекомендуется поискать такие вакансии.
А на аггрегаторах типа HH обычно будут и менее стабильные и известные компании, и вакансии могут быть устаревшими, так как не всегда после приема человека на работу, вычищают за собой закрытые вакансии.
Поэтому чтобы не мудрить с процентами, всегда ставь 50% или да или нет.

3. Отдельно хочу поинтересоваться насчёт прописанной в некоторых объявлениях по поиску junior(!) iOS developer'а возможности релокации из регионов и довольно отдаленных мест, в которых живёт тот, кто хочет начать работать начинающим специалистом, в офисы компаний, но без удаленной работы. Релокация из другого места ios junior'a, подходящего и соответствующего требованиям из объявления - такое тоже может быть возможно?

Релокация в пределах страны - вещь не самая сложная, но даже ее обычно предлагать может компания с офисом, а не с подвалом. Поэтому для релокации можно конечно смотреть и перебирать HH, но надежнее будет найти топ-50 компаний и поискать список вакансий на их официальных сайтах.

Все советы по поводу попасть в приличную компанию нужно естественно умножать на коэффициент вашей квалификации - от нее зависит почти все.

Если выдает ошибку, то ее надо исправить.
Самый простой способ - загуглить текст ошибки и почитать первые 10-15 ссылок.

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

Стандартные системные операции - копирование файлов, удаление файлов, переименование файлов, проверка наличия файлов, создание ссылок, директорий и скачивание по https (сейчас почти все репозитории уже уехали на https)

Ну и в зависимости от упаковщика - может быть просто zip юзать..

performance тесты.

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

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

В общем плохая задача, неправильная.

Дали домашку: параллельно пользоваться Linux Debian и Windows на одном компьютере

А почему нельзя поставить виртуалбокс с линуксом?

Какой язык программирования учить?

Любой.

за сколько я его выучу так, чтобы можно было осуществить выше сказанное?

Frostok, А за сколько ты выучил, например, английский с нуля?

Или думаешь все люди одинаково учат?
Если бы так было, в школе все бы получали одинаковые оценки, но все получают разные.

загибсовали в положении как будто держу ручку

Джойстик? =)

grep -oP '\(SYN\), \K[0-9.]+' file.log > only_addresses.txt

Вообще-то, по грамотному надо расширять API для выполнения bulk запросов...
Или такой вариант вообще не рассматривается?

делать пуш в один репозиторий и в другой репозиторий.

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

Разработчиков у вас у всех есть бэкап. А QA если уйдет в отпуск или на больничный?

Кто выполняет функции аналитика? Или разработчики точно знают что хочет клиент?

Микросервисы пишут не для того, чтобы просто переделать API.

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

А уже исходя из этой точки зрения:

1. Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?

А если нужно много экземпляров, будете одним nginx-ом раскидывать по 10 локейшенам? Микросервисы в современном мире предполагается запускать в докере на собственном легковесном веб-сервере (типа Jetty), поднимать нужное количество экземпляров и балансировать чем-нибудь на входе, но не по локейшенам.

2. Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?

РаббитMQ или kafka позволяют множеству экземпляров вашего сервиса обрабатывать сообщения, с гарантией того, что из очереди ничего не пропадет, и если какой-то экземпляр сдохнет, то этот запрос обработает другой экземпляр. Именно ждать ответ наверное не самое правильное, но это можно смотреть как вам удобнее - периодически опрашивать очередь, или настроить чтобы message service сам пушил по событию.

3. Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных? Как например в админке обращаться к пользователям, чтобы их добавить или заблокировать, я должен запрашивать пользователей с микросервиса? Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля?

Это как вы хотите. Если у вас очень много пользователей и авторизация тормозит, но можно сделать микросервис с авторизацией, сделать кластер базы данных с репликацией. Дальше можете балансировать пользователей и там уже решать как их раскидывать. Или база мощная и все экземпляры могут работать с кластером. Или делите базу на части, и раскидываете пользователей по алфавиту (база юзеров от A* до H*, база юзеров от I* до M*, по региону или как вам нравится).

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

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