Дмитрий Энтелис

В целом правильные ответы очень сильно зависят от проекта, я напишу то что на мой взгляд common sense и применимо всегда:

1. Не надо заливать по FTP. Делайте pull из bitbucket после получения hook от них.
Учтите что строго говоря hook может и не придти, предусмотрите какой то лог выкладок и возможность дернуть руками снаружи. Есть большие готовые решения, в том числе умеющие и деплоить: jenkins, teamcity, phpci - но можно и свой простенький скриптик собрать, дел на час максимум если без красивостей.

1.2 Если хочется отказоустойчивости - не нужно разделять на master и slave, сервера должны быть независимы друг от друга и эквивалентны.

2. Если простой у одиночных клиентов в N часов допустим:
Amazon route53 в качестве dns + 2 шт amazon health check.
2 A-записи на один домен указывающие на 2 сервера привязанные каждый к своему health check.
TTL ставить поменьше, 1-5 минут. К сожалению все равно будут посетители у которых провайдер кеширует.

Если простой недоспустим совсем - простых решений нет к сожалению :)
Можно смотреть на failoverip у hetzner (2 железных сервера на 1м IP с возможностью быстрого переключения), но не снимает вопроса что делать если упал дц у самого хецнера.
* и да, в нормальной ситуации сервера лучше держать у разных хостеров

3. Всю систему целиком бекапить imho не нужно. Бекапить нужно пользовательские данные если они у вас есть.
SQL неплохо себя показал galera cluster (master-master), но там есть нюанс с транзакциями если вы их используете. Файлы можно каким нибудь rsynk таскать, а можно просто положить их сразу в S3 и забыть навсегда (если у Вас их не очень много - см тарифы)

Если есть некий контент, на котором планируется зарабатывать, решение - прятать его под замок после оплаты.
Оплату брать либо за доступ к каждой единице контента, либо если абонемент - с ограничением на количество контента в период времени (что бы условно купив 10-15-20 учеток Вас не просканили)
Пример такой реализации www.nesprosta.ru/?type=show_home&id=65810 (первая ссылка которая пришла в голову)

Если непосредственно зарабатывать на контенте желания нет, то любые попытки защититься от парсинга априори обречены на неудачу. Любой контент который Вы отдаете поисковику остается в его кеше. Даже если Вы воткнете лимиты на доступ к сайту(что само по себе проблемно - прокси бесплатных существует великое множество, не говоря про возможность в любой момент поднять сотню-другую на амазоне) - любой желающий Вас спарсить всегда может парсить не Вас напрямую, а кеш поисковика ( webcache.googleusercontent.com/search?q=cache:YMI-... )

Не вижу проблемы. У меня в одном из проектов ~1500 миграций в phinx (с августа 2014). Все отлично работает.
Миграции покрывают весь проект начиная с создания первой таблицы.

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

PS Отдельно не вижу смысла в какой то дополнительной организации структуры миграций, т.к уже созданные миграции очевидно никто не правит.

PPS Если Вам так нужна поддержка папок - откройте исходники и допишите :) Вряд ли это сильно сложно сделать будет.

Правильное решение в данном случае: поднять на новом сервере какой нибудь vagrant / docker с окружением максимально идентичным исходному.
В остальные решения от лукавого, полноценный дебаг приложения со сложной логикой это гарантированные человеко-месяцы.

Если таблицы условно большие ( > 1 000 000), а в результатах запроса ожидается мало данных ( < 1 000 ) заметно быстрее будет делать 3 запроса вида where id in (1,2,3) явно перечисляя в запросах нужные id

Из объективных замечаний

1. Открыть ООО стоит 15 т.р. Его отсутствие выглядит несколько дико, если Вы хотите делать бизнес.
   Инвестировать согласятся только пацаны в адидасе, а ROI будут из Вас получить с помощью бейсбольной биты (или клюшки для гольфа если Вы в СПБ).
   
2. Вы хотите отдать 80% прибыли. Не понятно как это фиксируется и в течении какого периода времени.
   Если Вы говорите про 80% всего продукта - это также выглядит крайне сомнительно - или Вы не верите в успех проекта в принципе, или не понимаете на что хотите подписаться, или просто хотите освоить бюджет и исчезнуть. Далее см п 1.
   
3. Вообще стартапы не взлетают на рекламе. Если есть виральность - должно взлетать само. Нет виральности - суммы на рекламу должны быть в сотни раз больше (при условии наличия серьезного продукта)
   Исходя из этого 400 тысяч рублей на рекламу несерьезная сумма что бы кто то что то инвестировал.
   Ну или у Вас должна быть какая то дикая отбиваемость рекламы (вдруг Вы скрытые гении) но тогда это можно проверить существенно меньшими суммами.
   

1. Поставьте себе прокси какой нибудь типа чарльза, помониторьте запросы.
По большому счету вариантов всего 2: или сокет открытый в который шлются данные, или просто запросы от водительского приложения на сервер. Сокет imho правильнее.

2. Дополнительно используется прогнозирование/постобработка с учетом дорожного графа. Это позволяет строить красивые линии в туннелях где gps не ловит по определению.

Так может Leopandro/yii2-user все таки?

stackoverflow.com/questions/22423717/mysql-general...

Универсальный сценарий: берете любого крупного поставщика/интегратора в регионе, звоните голосом, просите переключить на корпоративный отдел.

select state, group_concat(city separator ",") from ... group by state

dev.mysql.com/doc/refman/5.7/en/group-by-functions...

Если я Вас правильно понял - у вас уже есть некие списки number в таблице number_table, inn в таблице contragents и есть отдельный список записей в csv которые нужно нормализовать.
IMHO самое простое и правильное решение - написать на любом ЯП маленький скриптик.
В зависимости от количества данных в существующих таблицах, можно как их честно дергать каждый раз, так и загрузить в память.

После первых N жалоб на однотипные сообщения, Вашу группу забанят пожизненно.
Дешевых и быстрых способов привлечения аудитории не существует.

UPD: отличный пост сколько стоит SMM https://www.facebook.com/l0gin0vskaya/posts/112657...

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

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

Wordpress не причем.
Могу предположить что у Вас myisam таблицы - они ломаются достаточно легко по куче причин - могло место на диске кончиться, мог сервер ребутнуться в ненужный момент.
Решение а) перейти на innodb б) посмотреть что в логах железа

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