Как стать автором
Обновить

Хостинг для нагруженного сайта с читателями по всему миру. Быстро и без падений

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров6.8K

У меня несколько сайтов со статьями. Есть трафик и даже какие-то деньги я с них зарабатываю. Как раз тот случай, когда “просто закинуть на хостинг” - уже мало, а нанимать целую команду толковых программистов - ещё дорого.

Пишу о путешествиях. Летом - самый сезон. Солнце припекает, народ едет на море. А заодно от жары разогреваются дата-центры. Надоело “падать” каждый сезон по нескольку часов. Поэтому, пришлось соорудить вот такое чудище Франкенштейна:

Как хостятся мои сайты?
Как хостятся мои сайты?

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

Обо мне и моих сайтах

Не бывает универсальных инструкций, которые подходят абсолютно всем. Что хорошо для редко изменяющегося сайта со статьями, то не подойдёт интернет-магазину или SaaS. Надо накидать немного контекста:

  1. У меня довольно обычные сайты со статьями на WordPress. Нет корзины, товаров, профилей пользователей, форумов и т.д. Почти статика.

  2. Я пишу только о местах, которые сам хорошо знаю. Несколько раз летал в Грузию и облазил эту страну вдоль и поперёк. Никаких копирайтеров.

  3. Сам с нуля написал тему, чтобы мои ресурсы были удобными, красивыми и быстрыми. Если интересно было бы почитать об этом, сообщите в комментариях и я постараюсь написать отдельную подробную статью.

  4. Это уже не просто хобби, а скорее что-то среднее между бизнесом и самозанятостью.

  5. Суммарная аудитория около 250 000 просмотров в месяц. Это примерно с 500-т статей. Как для нынешних времён и ситуации с туризмом - вполне прилично. Раньше было в несколько раз больше.

  6. Я не совсем программист и уж тем более не системный администратор. Но немного повёрнут на скорости и стабильности работы. Физически неприятно когда сайты тормозят или вообще не открываются.

На поддержку и развитие сайтов уходит 2-3 часа в день. Когда-то это начиналось скорее как хобби, но сейчас стараюсь монетизировать. Иначе не хватает мотивации.

Зарабатываю при помощи партнёрских программ вроде TravelPayouts или Myrentacar. Они позволяют получать процент с приведенных мной клиентов. Цена для читателей не меняется. На первый взгляд попахивает МММ или сетевым маркетингом, но по факту всё довольно честно и взаимовыгодно.

Я советую только лично проверенные компании, в которых уверен. Например, сейчас мои родители в Черногории и я бронировал им билеты, жильё, трансфер и экскурсии ровно на тех же сайтах, что и рекомендую у себя в блоге. Аналогично тёщу отправил в Грузию. Здесь главное не врать, так как люди сразу видят фальшь.

Вообще, с партнерскими программами всё очень неоднозначно. По факту, благодаря им цены на туристические услуги падают, а в интернете появляется больше экспертных статей вместо тупого рерайта по 60 рублей за 1000 знаков от людей, которые и не путешествовали то никогда. Я серьёзно. Такой вот парадокс. Если интересно как оно всё работает изнутри, могу когда-то рассказать в отдельной статье. Я не прямо эксперт-эксперт, но уже давно в этом всём варюсь.

Как я методом проб и ошибок выстроил инфраструктуру?

Давайте разбираться с моим чудищем Франкенштена и почему оно получилось именно таким?

Если просто закинуть сайт на хостинг, падение хостинга = полная недоступность сайтов. Падают все. За год несколько часов набегает у любого хостинг-провайдера. Хорошо если это просто техобслуживание зимой да ещё и посреди ночи. Можно пренебречь. А вот полчаса-час простоя летом в разгар рабочего дня - уже весьма неприятно. И с финансовой точки зрения и народ потом жалуется.

Но это лишь вершина айсберга. Иногда, по разным причинам, вполне себе приличные хостинги падают на несколько суток. Парочка историй:

  • Я так почти “попал” с ihor, у которых когда-то по глупости арендовал VPS. У них был собственный дата-центр, резервные каналы связи и т.д. Но собственники разругались и кто-то просто дёрнул рубильник. Я “свалил” буквально за неделю до всех этих событий. Как чувствовал.

  • У одного известного немецкого провайдера на H доблестная полиция просто изъяла сервер, где хранился в том числе и один мой проект. Если правильно помню, только на переписку “а что такое, куда всё делось” ушло несколько недель.

  • У дата-центра одного неплохого провайдера бомжи решили погреться. Крутая ведь идея поджечь в бочке оптоволоконный кабель?

  • Не так давно горел дата-центр OVH. Сейчас непогода в Германии.

  • Недавно в Selectel было что-то с электропитанием. Сайты то падали, то поднимались. Здесь суммарный простой получился около часа-двух, но проблемы наблюдались три дня.

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

Домен

Странно начинать разговор о хостинге и инфраструктуре с домена. Казалось бы - ну при чём он здесь? А вот и нет!

Домены для ценных сайтов желательно покупать у регистраторов. Я никогда не покупаю домен там же, где размещаю сайты. Так дешевле, но если с хостингом что-то случается, будут огромные проблемы. Расскажу на примере ihor. Я как раз помогал коллеге восстановить проект, который она у них хранила:

  1. Огромный простой. Бекапы у нее были. Но какой в них смысл, если нет доступа к DNS записям домена? Зеркало можно развернуть за полчаса, но направить на него трафик не получается.

  2. Узнать регистратора. Сайт хостинга не работал, но регистратора можно узнать через Whois. Большинство хостинговых компаний просто занимаются реселлингом.

  3. Переписка с регистратором. Мы писали иностранному регистратору, объясняли ситуацию и долго доказывали, что домен действительно наш и мы правда хотим перевести его на обслуживание в любую другую компанию. Сложнее всего было объяснить европейцам, что мы никак не можем “обратиться в место, где регистрировали домен”.

  4. Замена DNS. Как только удалось отвоевать домен, сразу же поменяли адреса DNS на актуальные. Но сайты не заработали. Надо было подождать ещё несколько дней пока все провайдеры обновят кеш.

  5. Итоги. Простой 9 с половиной дней. Трафик удалось восстановить только через полтора года. И то ценой невероятных усилий. А должен был быть рост.

В моём же варианте если вдруг что-то случается с хостингом, достаточно просто поменять DNS в CloudFlare и сайты заработают спустя 15-20 секунд. Ну а если упадёт сам CloudFlare, то отвалятся даже некоторые гиганты индустрии. Кому в такой момент будут нужны мои бложики?

Сайтов у меня несколько и переключать всё руками было бы неудобно. Особенно, когда сидишь в кафе и под рукой есть только смартфон. Поэтому, я сделал для себя примитивную утилиту, которая подключается к ним по API и просто переключает одной кнопкой все DNS на резервные.

API у них довольно понятное. Я никогда раньше с такими вещами не работал, но разобрался примерно за час. В интерфейсе надо было создать токены, а дальше всё делается простыми GET и PUT запросами.

Например при помощи такого GET запроса я узнаю какой IP сейчас прописан у них в разделе DNS:

https://api.cloudflare.com/client/v4/zones/a365f1f18dc3ye8a4faa0c04c20eb95s/dns_records?type=A&name=georgia.in-facts.info

Оно на самом деле очень много информации отдаёт, так что нужно использовать json_decode и искать в получившемся массиве нужное значение. Как-то так:

$DNSIP['result']['0']['content']

А таким PUT запросом устанавливаю нужный мне IP:

$data_array =  '{"type":"A","name":"georgia.in-facts.info","content":"172.64.222.41","proxied":true}';
$update_plan = callAPI ('PUT', 'https://api.cloudflare.com/client/v4/zones/a365f1f18dc3ye8a4faa0c04c20eb95s/dns_records/ecfa543133b5f5beb2abb8as2140a008d', $data_array);

В примерах выше:

a365f1f18dc3ye8a4faa0c04c20eb95s это Zone ID, который можно получить в личном кабинете CloudFlare. ecfa543133b5f5beb2abb8as2140a008d это идентификатор конкретной DNS-записи. Получается тем же GET запросом, что и IP.

* Здесь и дальше все пароли, логины и т. д. я заменил на случайные.

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

Само собой, что “хостить” такой сайт надо не на основном сервере. Иначе в случае падения он тоже не будет открываться.

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

Зачем мне CloudFlare?

Казалось бы, польза CDN очевидна - сайты будут работать быстрее. Но по факту, если Ваша основная аудитория из СНГ, то с хорошим хостингом в РФ или Нидерландах время до загрузки страниц будет чуть ли не ниже, чем при проксировании через CloudFlare. Как минимум, такое частенько наблюдается в моём конкретном случае.

Однако сервис очень выручил меня, когда один из сайтов начали DDoS’ить. Не думаю, что это была продуманная и спланированная атака. Скорее всего, я просто стал случайной целью какого-то ботнета. Но в случае хостинга я бы никак не смог отбиться. Меня бы просто отключили да и всё. А при помощи CloudFlare получилось хотя бы быстро заблокировать трафик из всех не целевых стран. Этим я выиграл время на поиски более адекватного решения.

Automatic Platform Optimization for WordPress

Это новая платная опция в CloudFlare. Бесплатно они кешируют картинки и скрипты. За 5 долларов в месяц можно адекватно кешировать и html тоже. Есть варианты как получить тот же результат вообще бесплатно. Но все они немного костыльные и работают не так стабильно, как хотелось бы.

Я для себя вижу два преимущества APO:

Скорость. Сайты начинают открываться гораздо быстрее. Особенно, из “удалённых” от хостинга стран. У меня есть переводы некоторых статей на английский язык. То есть, трафик идёт в том числе и из-за океана. После подключения стало немного, но быстрее:

Сравниваем скорость загрузки по данным Google Analytics
Сравниваем скорость загрузки по данным Google Analytics

На конкретные цифры я бы внимания не обращал. Google Analytics довольно странно считает скорость загрузки сайтов. Я тестировал их даже на очень медленном мобильном интернете в горах и всё открывалось адекватно. Но в аналитике даже в РФ, где находится хостинг, среднее значение около 4 секунд.

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

Условно говоря:

  • В РФ, Украине и Беларуси у меня пользователей много. Поэтому, в кеше лежат почти все страницы, картинки и скрипты. Сайты более-менее загружаются, но иногда бывают ошибки с картинками, когда пользователь запрашивает “редкий” размер на не особо популярной странице.

  • В Европе что-то загружается, а что-то нет. Банально кеш “протух” и CloudFlare нечего отдавать.

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

Если внимательно посмотреть на схему в начале статьи, видно, что 91% запрошенных страниц сразу отдаются из кеша и вообще никак не зависят от работоспособности хостинга. Остальные 9% это админка, которая не кешируется, комментарии, поиск по сайту, недавно обновлённые статьи и запросы из “экзотических” для меня стран.

html-кеширование

Львиная доля времени, которое проходит от запроса пользователя до ответа сервера - работа скриптов php. У меня WordPress с вручную написанной, очень быстрой темой. Но всё равно использую кеширование. Перепробовал много плагинов. В том числе и модный платный WP Rocket. Но остановился на бесплатном WP Super Cache, так как в экспертном режиме он умеет отдавать кеш при помощи правил в .htaccess и вообще не использует php. Это быстрее.

На кеш приходится 8% запросов. В основном, он отрабатывает когда пользователь из условной Германии-Австрии (у меня там мало читателей) впервые запрашивает не особо популярную страницу и её просто нет на ближайшем к нему сервере CloudFlare.

Хостинг

В своё время я прилично так “попрыгал” по разным хостингам и VPS. И пришёл к весьма простому выводу: с точки зрения рядового пользователя они все одинаковые.

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

Если просто нужен хостинг

Новичкам я бы порекомендовал Бегет. Пользуюсь их услугами больше 6-ти лет. Поддержка адекватная, сайты работают более-менее быстро. Платят 40% реферальных. Всё стандартно, в общем.

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

Есть и минусы: мои сайты падают примерно на 2 часа в год. На днях вот не мог весь день зайти в панель, так как проводились какие-то работы. Цены растут.

Ссылки: Простая | Реферальная

Нужен хороший хостинг

Самые ценные проекты я храню на Lite.host. Это детище одного человека. Узнал о нём как раз на Хабре со статьи И один в поле воин. Мы тогда пообщались в комментариях, владелец показался адекватным и я пообещал разместить у него небольшой новый сайт. А в итоге перенёс как раз старые и особо ценные. Давайте расскажу почему:

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

Расскажу забавную детективную историю. По какой-то причине очень-очень редко я получал вот такую ошибку:

Такая ошибка возникала при открытии сайта в браузере. Как в админке, так и на фронтенде.
Такая ошибка возникала при открытии сайта в браузере. Как в админке, так и на фронтенде.

Эмпирически удалось установить, что это иногда происходит если страница загружалась с использованием php. Ошибка была не регулярной и происходила только у меня. Несколько часов всё нормально, потом 2-3 страницы с ошибкой, потом снова всё хорошо. Обновление страницы в браузере помогало. Если здесь есть крутые сисадмины, напишите, пожалуйста, в комментариях как бы Вы решали такую проблему.

Большинство хостингов с такой проблемой меня бы просто “послали”, заявив, что проблема на стороне CloudFlare или маршрутизации трафика. Мы с Евгением периодически искали причину больше месяца. Я клацал галочками в настройках CloudFlare и пробовал править скрипты. Он копал вплоть до кода веб серверов.

Решить удалось только когда я чисто случайно придумал как повысить частоту появления этой проблемы с 1-2 в час до загрузки каждой 4-5 страницы. И вот разгадка:

Отгадка

Я не особо технически грамотный пользователь. Так что попросил Евгения рассказать о решении. Вот его ответ:

522 ошибка возникала только при запросах по HTTP/2.0 от cloudflare.com, если делать прямые запросы (без cloudflare.com, то такой ошибки не было). При активации поддержки этой версии протокола со стороны панели управления DirectAdmin, она настраивает его как для Nginx (fronted), так и для Apache (backend). Отключение HTTP/2.0 со стороны Apache полностью решило проблему. Где истинная проблема (в cloudflare.com, Nginx или Apache) до сих пор непонятно, но главное, что решение было найдено.

Такого уровня поддержки я не встречал больше нигде. Прямо перед ЛайтХостом я арендовал VPS у AdminVPS. Взял как раз потому, что в отзывах народ писал о крутой поддержке. По факту же мы с их ребятами как-то не сошлись характерами. Сервер часто падал. Половина случаев по моей вине, половина - по их. Но ушёл я именно из-за ответов инженеров. Вроде: полные ограничения в VPS можете почитать на нашем сайте. И ищи дальше сам где оно написано и написано ли вообще. Я за полчаса так и не нашёл эту секретную страницу.

Прозрачность. Есть вот такая штука: status.lite.host, где публикуется информация обо всех сбоях, неполадках и проблемах. Если падает хостинг или VPS, больше не надо гадать: на моей стороне что-то отвалилось, или это всё же их косяк. Сразу видно что случилось и когда это будет исправлено.

Выгодные тарифы. Не скажу, что это дешёвый хостинг. Но я перешёл к Евгению с VPS. Долго тестировал и сравнивал. Получилось, что хостинг стоил в 3 раза дешевле, а по скорости был примерно на том же уровне.

Очень быстрый хостинг. Хотя Женя и говорит, что все используют аналогичное оборудование, я ему не верю. Мои сайты открываются объективно быстрее. Когда генерировал картинки WebP, процесс шёл в 3-4 раза быстрее, чем на Бегете.

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

Если прямо совсем честно, то одной из причин по которой я таки решился написать эту статью и было желание устроить небольшую “рекламу” Жене.

Минусы вытекают из плюсов. Раз хостингом занимается всего один человек, то и bus factor = 1. Обязательно надо делать бекапы и иметь “горячий” резерв. Поддержка не всегда оперативная. Так как даже супермену иногда надо спать. Ну и реферальные всего 15%.

Ссылки: Простая | Реферальная

Резервный сервер

У меня есть минимальный VPS на Digital Ocean в Амстердаме. Я арендую его в первую очередь для VPN. Но раз уж плачу, то захотелось хранить там зеркало моих сайтов. Раньше я такое настраивал вручную примерно за 3-4 дня. И оно даже работало!

В этот раз решил просто заплатить Евгению что-то около 20$ за работу “под ключ”. Горжусь собой: научился хоть что-то делегировать.

Синхронизация

Каждую ночь файлы и база наиболее ценных сайтов синхронизируются на запасной сервер при помощи rsync. База автоматически импортируется, так что по факту там крутится полностью функциональная копия моих проектов. Чтобы переключиться на неё достаточно просто поменять DNS в CloudFlare при помощи утилиты, которую я уже упоминал выше.

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

# Синхронизация файлов

rsync -raP --delete grfghtr@geo.lite-host.in:/home/grfghtr/domains/georgia.in-facts.info/public_html/ /home/grfghtr/domains/georgia.in-facts.info/public_html/

# Перенос базы данных

ssh grfghtr@geo.lite-host.in "mysqldump -ugrfghtr_GEORGIA -pedfg45fgh66443dfgy656hfgh grfghtr_GEORGIA | gzip > /home/grfghtr/dumps/grfghtr_GEORGIA.sql.gz"
rsync -raP grfghtr@geo.lite-host.in:/home/grfghtr/dumps/ /home/grfghtr/dumps/
ssh grfghtr@geo.lite-host.in "rm -rf /home/grfghtr/dumps"
zcat /home/grfghtr/dumps/grfghtr_GEORGIA.sql.gz | mysql -ugrfghtr_GEORGIA -pedfg45fgh66443dfgy656hfgh grfghtr_GEORGIA
rm -rf /home/grfghtr/dumps

В идеале, конечно же, было бы купить какой-то Load Balancer, а совсем уж хорошо - настроить ещё и репликацию баз данных master-master, чтобы постоянно иметь актуальную копию. Но, к сожалению, всё это у меня пока не окупается.

Бюджетный Load Balancer будет стоить минимум 5$ в месяц. Это окупилось бы только в том случае, если бы хостинг падал минимум на полчаса раз в месяц. Но настолько некачественную услугу надо ещё поискать.

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

Бекапы

Я уже говорил, что у моего хостинга bus factor = 1? Но вообще от проблем не застрахована любая компания. Мои данные могут потеряться из-за человеческой ошибки, вышедшего из строя оборудования, пожара или стихийного бедствия. Чтобы такая потеря не была критичной, я делаю бекапы в четырёх местах:

  1. Бекапы от хостинга. Их сейчас почти все предлагают. Создаются автоматически, работают. Тестировал их на “призрачность”.

  2. “Горячий” бекап на удалённом сервере. Та самая штука, о которой я уже рассказывал.

  3. Бекап на ноутбуке. Просто примерно раз в месяц вручную копирую все файлы и БД на рабочий ноутбук. У меня сайты меняются редко, так что в случае чего потери будут не очень критичными. Если вношу много правок, то и бекап делаю пораньше.

  4. Бекап на жёстком диске. Также копирую всё на внешний HDD.

Как проверить есть ли эффект?

Я никак не замерял стабильность работы своих сайтов. Так что не могу точно сказать насколько такие “костыли” её улучшили. Субъективно - за это лето я избежал пары часов простоя. Но тут просто не повезло с форс-мажором в дата-центре Selectel. Обычно хостинги не падают на такое продолжительное время.

А вот “скорость работы” сайтов было бы интересно сравнить. Но и тут есть сложности. Легко измерить эффект, если до начала работ сайт дико тормозил и открывался по 5-10 секунд. Тогда банальное подключение кеширования легко даст ускорение на 1000%. Вот он - главный секрет многих красивых рекламных статей.

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

Вот что придумал я:

  1. Есть два сайта, которые “написаны” плюс-минус одинаково. Это мой georgia.in-facts.info и сайт коллег montenegro-travel.info, где я помогал делать только дизайн.

  2. Первый сайт использует описанную выше инфраструктуру. Второй просто “закинули” на Бегет. Количество посетителей - сопоставимое.

  3. Для тестов я выбрал две страницы без сторонних скриптов: никаких вставок Google Maps, рекламных виджетов и т.д. Только картинки и текст. Так сделано потому, что любой рекламный виджет “весит” и влияет на скорость загрузки страницы больше, чем всё остальное вместе взятое.

  4. Тестировал при помощи gtmetrix.com, так как считаю этот сервис одним из лучших. Браузер выбран Chrome, как самый популярный среди моих посетителей.

  5. Тестировал днём, в прайм-тайм. Брал среднее из пяти запусков.

Переходим к результатам:

Локация

georgia.in-facts.info

montenegro-travel.info

Time to First Byte

First Contentful Paint

Time to First Byte

First Contentful Paint

Лондон

71 ms

343 ms

261 ms

674 ms

Ванкувер

89 ms

285 ms

789 ms

≈ 1300 ms

Сидней

113 ms

352 ms

≈ 1200 ms

≈ 1900 ms

Мумбаи

190 ms

646 ms

≈ 1400 ms

≈ 2000 ms

Мой компьютер

132 ms

407 ms

127 ms

573 ms

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

Хочу уточнить, что разброс значений получался довольно большим. Не знаю с чем это связано. Я специально указал адреса сайтов, чтобы Вы могли протестировать всё самостоятельно.

Любопытно, что при попытке тестировать скорость загрузки “редкой” страницы из непопулярной среди моих пользователей локации первый тест georgia.in-facts.info показывал результат 900-1600 миллисекунд, а уже второй - в 3-4 раза ниже. Похоже, APO действительно работает. Жаль, что у них нет серверов в РФ, чтобы получить более точные данные.

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

А как надо было сделать?

Помните, я говорил, что не совсем программист и уж точно не системный администратор? Есть ощущение, что и инфраструктуру я построил далеко не оптимальную. Ну не пишут почему-то о том, как правильно всё настроить для проектов вроде моего. Или “просто закиньте на хостинг” или облака с Docker - контейнерами и парой инженеров на поддержке всего этого зоопарка.

Знаю, что на Хабре много опытных администраторов. Я писал эту статью в том числе и для того, чтобы попросить совета. Если у Вас есть время, подскажите что я сделал не так и где мою “инфраструктуру” можно было бы улучшить.

Как бы Вы решили проблему, если бы на всё про всё было максимум 200$ в месяц в год? Это с учётом оплаты работы людей, которые будут всё это дело поддерживать.

Теги:
Хабы:
Всего голосов 9: ↑8 и ↓1+11
Комментарии24

Публикации

Истории

Работа

Ближайшие события

12 – 13 июля
Геймтон DatsDefense
Онлайн
19 сентября
CDI Conf 2024
Москва