ps. перевод на монголошумерский для тех кто не понял: одни уважаемые реддиторы обыгрывают созвучие названия с запрещенным словом на букву NIGGER, другие уважаемые реддиторы говорят "чего еще ждать от программистов страны третьего мира".
Картинка из оригинального псто:
nginx
15 лет назад работал я в одном стартапе, который занимался ad-media trading. Так вот, в качестве базы для наших серверов использовался исходный код тогдашнего nginx.
Что вообще такое ad-media trading?
Представьте любой крупный новостной сайт, на который вы заходите. Обычно там сверху и по бокам находятся рекламные баннеры. Если сравнивать один день с другим, то баннеры меняются. Иногда в течение дня. Иногда несколько раз. Как это работает?
Существуют электронные биржи рекламы. Крупнейшими являются Google Ads, Yahoo7 и AppNexus/Xandr, принадлежащая Microsoft.
Размер электронной рекламной биржи определяется количеством сайтов с большим потоком посетителей в сутки, с которыми у этой биржи есть договор на размещение её рекламы. Если на главной странице такого сайта было 3 баннера, то в HTML странице на их месте вставлялись ссылки на сервер электронной биржи с информацией о геометрии баннера.
Далее media trading агентство, типа того стартапа, в котором работал я, заключает контракт с такой биржей, на показ своей рекламы. Оно, в свою очередь, заключает контракты уже с рекламодателями. Например крупными банками или производителями товаров. Агентство получает от рекламодателей собственно баннеры для показа, деньги на рекламную кампанию и описание целевой аудитории, на которую эта рекламная кампания рассчитана.
Далее media trading агентство загружает свои баннеры в систему электронной рекламной биржи и та подтверждает, что баннеры не содержат 18+ контента и подходят под описание рекламируемого продукта или услуги.
Когда Вы заходите на вебсайт, на котором есть подобные рекламные места для баннеров, то, при начале загрузки страницы в Вашем браузере, сработают те самые ссылки на месте баннеров, которые отправят запросы на сервер биржи. Кроме зашитой геометрии баннера сервер извлечёт из запроса:
Ваш IP-адрес
Язык браузера по умолчанию
Если это Google Ads, то также Ваш возраст и пол
Всю собранную информацию + название исходного веб-сайта биржа рассылает в виде запроса всем своим ad-media trading агентствам - делайте ставки! С этого момента включился таймер!
Со стороны ad-media trading агентства находится сервер. В нашем случае он был сделан на основе nginx. Инженеры, в числе которых был и я, писали на C++ код к nginx, который выполнял распаковку запроса, вычисление местоположения по IP-адресу, заполнение запроса к внутренней базе данных, прогонку входной информации о зашедшем на сайт пользователе через цепочку фильтров рекламодателя, проверку бюджета рекламной кампании и вычисление размера bid - ставки, которую мы готовы сделать и заплатить в случае выигрыша торгов за рекламный баннер. В итоге мы подготавливаем ответ бирже - сумма ставки и идентификатор баннера для показа. Ответ должен быть отправлен в течение 10 миллисекунд с момента отправки запроса биржей!!! Отправлять ответ "pass"/пропускаю нет никакого смысла - достаточно не отвечать 10 мс!
Дальше биржа сравнивает полученные ставки, выбирает победителя, извлекает его баннер из своей базы и отправляет его на веб-страницу, на которую Вы зашли.
По своему опыту скажу, что средний размер ставки за показ одного баннера колеблется в районе 1-2 цента. Процент выигранных нами бидов на Yahoo7 и AppNexus/Xandr был в районе 25%, а на Google Ads - 10%. На Google Ads конкуренция гораздо выше из-за того, что у них было гораздо больше биддеров вроде нас. Средний бюджет от рекламодателя на рекламную кампанию - 2 миллиона долларов.
Некоторые популярные веб-страницы, на которые Вы заходите, собираются из примерно 15 источников перед тем как быть Вам показанными...
Наши сервера располагались в облачных датацентрах в Европе, Азии и США, чтобы быть как можно ближе к серверам электронных рекламных бирж и иметь минимальную задержку на коммуникацию.
nginx позволял на своей базе сделать быстрый, масштабируемый сервер с расширяемым функционалом.
P.S.: После работы в этом стартапе мне довелось поработать ещё и c другим легковесным веб-сервером - Lighttpd. Это было уже в проекте разработки firmware для семейства Интернет-маршрутизаторов. Как-нибудь расскажу, если кому будет интересно.
В России действительно придумали Nginx. А ещё много чего в ИТ. И Тетрис тоже придумали, и крутой банкинг сделали, и крутой телеком, который не существует без ИТ-школы. Огромное количество у нас крутых ребят, причём их корни идут из энтузиастов, которые находили новые решения, учили английский, общались с такими же людьми на западе. И устроили главную "пиратскую" гавань в мире, ломая всякие программы защиты. Многие из нас тянули сети между домами и кварталами. Любой чел до ± 2000 года рождения обменивался данными путём прихода к другу со своим HDD, который перемычками ставился в позицию "раба" и на него качал контент. Потом так делал другой. СНГ дал ИТ миру очень многое, причём, без желания получить что-то взамен.
В чём была причина этого? Любознательность. Желание что-то сделать, чего не делали. Желание меняться, развиваться. Молчу уже о том, что это была сильная база математики у людей и эффект низкого старта. Нам свойственно очень быстро вникать в технологии и уметь их улучшать.
Что же изменилось? Мир изменился. Политически, экономически. Технологии стали определять мировую политику. Причём везде. Во всех сферах. Конечно, можно надрачивать на гиков Дуровых или Цукерберга, которые сделали соцсети. Но нельзя обходить те факты, что эти соцсети из прикола для поиска баб из универа стали средством массовой информации. Создатели ютуба, когда выложили первый ролик из зоопарка даже думать не знали, что их дурацкий, по их мнению, сайт станет мощнейшим инструментом пропаганды. И далее по списку. Даже, блин, Яндекс - это был в своё время акроним от английского "yet another search indexer" или вроде того. То есть, Волож и ко сделали просто "ещё один поисковик из многих". Они все относились к этому иронично. А потом внезапно стали миллиардерами.
Результат: любое государство - это не только монополия на насилие, но и ещё - монополия на информацию. То, что сейчас происходит - всего лишь исторический процесс сегментирования средств доставки информации. Скоро об этом все забудут, а восприниматься это будет как телек или радио в принципе. Никакого свободного Интернета уже давным давно нет. Нет нигде. Вопрос в охватах аудитории. Я расскажу ещё детям и внукам, что был такой странный Интернет, где было всё подряд. Мой ребенок уже не расскажет. Господа, это просто ход истории. И я не понимаю тех, кто думает, что Интернет чем-то отличается от прочих СМИ по своей сути.
В апреле 2023 года мы запустили необычный для нас проект - ремонтный сервис нового формата. Первого клиента нашли только в начале лета, но уже с первого проекта удалось достичь запланированной прибыли. Расскажу, как мы создали современную компанию для поколения "новых денег", которые не готовы к тому, что прораб будет класть половину стоимости ремонта себе в карман, а сроки растягиваются без ограничений и почему это оказалось прибыльным бизнесом.
Как всё начиналось
Конец 2022 года. Я работал менеджером проектов в крупной IT-компании, мой друг Антон - тимлидом в другой известной технологической компании, а Дима занимал позицию backend-разработчика в третьей. У всех стабильные зарплаты, интересные проекты - жизнь шла своим чередом, пока Антон не решил купить квартиру в новостройке.
После долгих поисков он остановился на 85-метровой квартире в ЖК около метро Саларьево - современный комплекс с подземным паркингом и зелёным двором. Как типичный программист, к поиску ремонтников он подошёл педантично: изучил десятки предложений, провёл собеседования с кандидатами. В итоге выбрал бригаду с Авито с "15-летним опытом работы".
Денис (это я:) - один из создателей сервиса
За время ремонта у Антона мы с Димой часто приезжали к нему - помочь, посоветовать, и просто поржать над очередными косяками строителей. У нас обоих за плечами был серьёзный опыт управления командами, внедрения процессов, автоматизации и контроля качества. И знаете что? Нам казалось, что главное в ремонтном бизнесе - это грамотный менеджмент и организация процессов. И на самом деле, все примерно так и есть.
День когда мы решились
Если честно, мысли о собственной ремонтной компании появились у нас задолго до этого случая. В IT-тусовке часто шутят, что в России есть три верных пути: вебкам, айти и стройка. И мы, насмотревшись на хаос в ремонтной сфере, не раз обсуждали возможность открытия своей “фирмы”.
Мы выделили основные проблемы, которые должны были исправить с помощью своего сервиса
Первое - это постоянно растущие сметы и "задранная стоимость" на работы. Ну вы серьезно? Почему для меня ремонт в квартире должен чем-то отличаться от заказа носков на Вайлдберриз? Почему-то там нет такого, что цена носков может вырасти в 2 раза за время доставки. А тут начальная смета в 1 миллион превратилась почти в 1,7! И каждый раз это "ой, тут стены кривые", "ой, а тут придется докупить", "ой, а это мы не учли".
Второе - это бесконечно растущие сроки. Это еще хуже. Как люди с опытом в менеджменте, мы прекрасно знали, что растущие сроки – это всегда раздолбайство управления и ленивые рабочие. Но тут было чуть посложнее, об этом чуть позже. У Антона обещали сделать за 4 месяца, а в итоге растянули на 8.
Третье - хитрые прорабы. Это вообще отдельная история. Когда прораб говорит "давайте я сам закуплю материалы, у меня скидки", знайте - он накинет сверху процентов 30-40. А еще есть "срочные работы", которые почему-то не были учтены в смете. И конечно, вечная классика - экономия на материалах: заказываешь одно, а привозят что-то попроще, но по той же цене.
Целевая аудитория
А параллельно с этим мы определили нашу целевую аудиторию. Чтобы выделиться на конкурентном рынке, мы решили ориентироваться на молодых IT-специалистов и представителей “современных” профессий, живущих в Москве в возрасте 30-40 лет. Тех, кто покупает квартиру в новостройке и привыкших к хорошему сервису. Кто не готов, что его будут водить за нос и разводить на деньги.
Что с ценой?
При этом очень важно было держать цены НИЖЕ, чем у других компаний, иначе на рынке просто не выжить. В премиум сегмент нужен "пропуск" в виде большого количества работ для определенного типа клиентов, поэтому нам было понятно, что "брать" много - пока что, непозволительно. Но мы нашли способ: автоматизация процессов, прямые поставки материалов, четкое планирование работ и никаких скрытых накруток. Но несбыточной мечтой это покажется только обывателю: на самом деле сервис и правда должен быть таким, вообще любой.
История первого заказа летом 2023 года
А теперь самое интересное - наш первый заказ. Это была отдельная эпопея. Начало лета 2023, звонок от потенциального клиента.
Первый клиент оказался прямо "в яблочко" - тоже айтишник (пришедший из первой контекстной рекламы в яндексе запущенной на 20 тыс.), работал в крупной компании, купил двушку в панельке 80-х годов. Причем достаточно убитую - стены местами с дырками, старый паркет, трубы помнящие еще Горбачева... Но нам, если честно, даже повезло что первый объект был не новостройкой. На старом фонде учиться легче - там хотя бы есть на что посмотреть, в отличие от новостроек, где все "сюрпризы" спрятаны в голых стенах.
Дырка в стене была ДО демонтажа. Клиент купил квартиру с "убитым" ремонтом подешевле, в надежде сэкономить
Как мы мастеров искали
Начали с поиска бригады. Вот тут был первый холодный душ - оказалось, что найти классных специалистов без своей наработанной базы очень сложно. Мастера хорошего уровня либо уже при деле, либо просят космос. А те, кто сразу соглашается - ну, вы понимаете. За две недели провели больше 10 собеседований (назовем их так😊). Причем процесс собеседования мы сразу сделали "как в айти" - тестовые задания, проверка портфолио, разбор технологий работы. Бригадиры были в шоке - некоторые прямо уходили с собеседований, когда мы начинали распрашивать про технологии укладки плитки и показывали фотографии косяков с объектов с форумов.
В итоге нашли бригаду - два брата, которые до этого работали в крупной ремонтной компании, но ушли потому что устали от "серых" схем – по отношению К НИМ ЖЕ. В основном - задержки з/п и прорабы.
В том же санузле, но уже после демонтажных и некоторых черновых работ. Братья очень помогли нам с первым ремонтом, кроме этого, они дали нам контакты проверенных рабочих, которые впоследствии делали ремонт вместе с ними
Купили первый комплект инструмента - это отдельная история на 100 тысяч рублей. Ещё сразу купили свою тепловую пушку - это из необычного. Большинство компаний привлекают "потолочников" на субподряд. Мы захотели сразу начать формировать свой инструментарий для будущих сотрудников. Зато потом эта закупка очень помогла - не зависели от того, что принесет с собой бригада. Позже, когда начали расширяться купили свою штукатурную станцию. Это, на удивление, было самой выгодной покупкой.
Первые сложности
Начали ремонт. И тут поехало... Первый сюрприз - когда начали снимать старую штукатурку, оказалось что стены буквально рассыпались. Плюс под старым линолеумом в коридоре нашли деревянный пол с насыпью под ним.
Тут был первый серьезный разговор с заказчиком. Объяснили ситуацию, показали все фотки, рассказали что сколько будет стоит в соответствии с прайс-листом. Тут очень помогло то, что мы сразу взяли за правило - фотографировать вообще все. Каждый этап, каждый слой, каждую трубу.
С материалами тоже было весело. Первый месяц я лично объездил все крупные строительные магазины в радиусе 30 км. Искал поставщиков, договаривался о скидках. Помню, как чуть не купили партию плитки по "супер-выгодной" цене, а потом выяснилось что это условно "второй сорт" - брак, который продают через "серые" схемы.
Cделали систему закупок: (Первый заказ полностью сделан из материалов, купленных в Петровиче и на маркетплейсах). Бригада присылает список - мы проверяем цены у 3-4 поставщиков и заказываем где дешевле.
Мы сразу внедрили систему ежедневных фото-отчетов и еженедельных созвонов. Плюс сделали чат в телеграме, куда скидывали все чеки, все накладные, все фотки. Такая прозрачность очень помогла - клиент видел, что мы не химичим с ценами и не пытаемся на нем нажиться.
В итоге сделали.
Братья советовали нам недостающих специалистов по ходу ремонта и постепенно, укладываясь в срок мы сдавали клиенту новый и новый этап. Честно, это было не так сложно как казалось в начале, но нужно понимать, что на самом деле, проблем по ходу ремонта и мелких трудностей было ОЧЕНЬ много, просто мы как люди привыкшие, понимали что сейчас это и есть наша работа , за которую нам платит клиент - взять на себя все заботы по ремонту. Но серьезных форс-мажоров не возникало, максимум понервничали, когда внесли предоплату потолочникам, которых нашли по объявлению, после чего они явно начали задерживать сроки, но в итоге, все обошлось. Нам и до этого было ясно, что чем быстрее мы соберем свой , хотя бы, небольшой штат, тем лучше и выгоднее. Но для этого надо быть уверенным в постоянном потоке заказов, что мы на тот момент, не могли себе позволить.
Главное - мы поняли как надо и как не надо. Все закупки только через нас. Все договоренности - только в письменном виде.
По деньгам первый проект получился условно в ноль - не считая наших вложений в инструмент и рекламу. Но мы получили бесценный опыт, наработали связи с поставщиками (если это можно назвать так пафосно) и главное - поняли, что наша модель рабочая, хотя на тот момент не были в этом до конца уверены. Наши сомнения развеяло лето 2023 года.
Наша первая работа, которую нам помогли закончить "братья", советуя недостающих мастеров на каждый этап работ. Цена работ для заказчика вышла 750 000 рублей. Летом 2023 года, за аналогичный объём работ авитовские бригады просили до миллиона(!)
Сайт и маркетинг или как мы общаемся с клиентами ещё до первого звонка
Кстати, про сайт. Первую версию мы сделали за пару вечеров на Тильде - максимально простую: фотки, цены, контакты. Знаете что? Он у нас до сих пор такой – но с значительно изменённым UI/UX. Я иногда ловлю себя на мысли - вот мы же, можем сделать что-то крутое, с личным кабинетом, онлайн-сметами... Но потом смотрю вордстат, статистику и думаю - а зачем? Клиенты находят нас, звонят, все работает. Иногда лучшее решение - самое простое.
На главной странице "в лоб" о том кто мы, наши конкурентные преимущества, специализация и примеры работ
Сразу "ярко" заявляем о действующих скидках. Кроме этого, простым текстом пытаемся общаться с клиентом и убедить его в нашем сервисе, пока что, не общаясь с ним лично - конверсия в лиды увеличилась значительно, но важно, чтобы все предложения были реальны
А вот ворд стат. За последний месяц нас искали 680 раз не считая статистики переходов по прямой ссылке. Доказательство того, что дорогой сайт не нужен. Наш стоит 6 000 рублей в год, а сделан за 20 часов
Примеры лучших работ как маркетинговый инструмент
Оставляли подобные фото с примерами работ и вотермаркой в отзывах к жилым комплексам. Отличный маркетинговый инструмент - сразу определяем нужную ЦА и бесплатно заявляем о себе. Точно знаем, что минимум один клиент был из отзывов яндекс - поэтому работает
Как мы масштабировались и разбирались в проблемах ремонта
Теперь про то, как мы начали разбираться в проблемах ремонта и потихоньку расти. Знаете, за этот год мы много думали - почему вообще ремонтные компании задерживают сроки и не могут сделать работу по первоначальной цене? И нашли несколько интересных моментов.
Первое - сроки. Тут даже копать глубоко не пришлось - сам рынок сформирован так, что клиенты просто привыкли к задержкам. "А, ну это ремонт, тут всегда так" - классическая фраза. Благо тут нам помог опыт организации процессов из айти. Четкие спринты, ежедневные отчеты, календарный план. Работает как часы, если не филонить.
Второе - вечно растущая цена. Вот это было сложнее. В новостройках еще можно точно посчитать, а во вторичке... Но благодаря наработкам этот вопрос стал гораздо яснее. При правильно организации процессов, непредвиденные работы лучше оплатить из своих средств, чем терять клиента. Только так и делается сервис.
Третье - больная тема - воровство на материалах. Тут мы конкретно закрутили гайки. Завели строгий учет, до последнего мешка штукатурки. Прорабам сразу сказали - любая жалоба от клиента на нечестность - это конец сотрудничества. Знаете что самое смешное? Когда начали работать честно, оказалось что маржа все равно хорошая. Просто многие привыкли что надо обязательно накручивать еще и еще.
Неприятные особенности прозрачного сервиса
Большинство компаний, которые начинают работать честно, быстро сдуваются. Потому что сам потребитель привык к плохому сервису. Приходишь к клиенту, говоришь "мы все сделаем четко по смете и в срок", а он смотрит с недоверием - "да ладно, так не бывает". Сейчас в 2024-м ситуация получше, но рынок все еще очень консервативный.
Продвижение или как мы брали “Новую Москву”
Наш любимый Прокшино в Новой Москве - в 2024 году, это самый перспективный район в котором покупатели - наши потенциальные клиенты
Расти начали потихоньку. Сначала сделали специальные цены для новой Москвы - там как раз много новостроек, где мы хорошо научились работать. Потом пошли заказы по рекомендациям. Когда я говорю “пошли” заказы нужно понимать, что это 1-3 заказа в месяц стабильно, что на самом деле, тогда казалось не мало. С рекламой экспериментировали забавно - оставляли визитки в подъездах (да, просто старые добрые визитки!), ставили рекламные ящики у офисов продаж в дни выдачи ключей.
Был случай, когда на одном ЖК поставили такую стойку, а через неделю риелтор оттуда сам позвонил и предложил взять себе процент, если клиент пойдет к нам.
Сейчас берем 2-5 заказов в месяц, (летом было 5 в месяц, если разделить). Большинство клиентов приходят по рекомендациям. Штат за год работы постепенно собрали свой. Трудоустроено 14 сотрудников. Если их не хватало (как летом), привлекали мастеров с которым уже работали раньше, по договору ГПХ. Просили всех регистрировать самозанятость или ИП – это было тяжело, но зато честно платим налоги по Доходы – расходы.
Как устроен процесс
Знаете, что самое сложное в ремонтном бизнесе? Нет, не поиск клиентов и не работа с материалами. Самое сложное - это выстроить систему, которая будет удовлетворять запросы клиента и при этом позволит компании зарабатывать. Мы долго думали над этим и придумали несколько интересных решений.
Начнем с оплаты. Если посмотреть на московский рынок, там забавная система - вроде бы без предоплаты, но это только за первый, самый дешевый этап. А потом - бац, и клиент должен внести 50% от всей суммы. И попробуй не внеси - бригада уйдет на другой объект. Мы сделали иначе: разбили весь ремонт на этапы (их получилось 12 для капитального ремонта), и берем предоплату только за текущий этап. То есть клиент всегда понимает, за что именно платит, и может контролировать процесс.
С договорами тоже интересно получилось. Сначала делали один стандартный, а потом поняли - люди разные, запросы разные. Сейчас у нас три варианта: просто на работы (для тех, кто сам хочет закупать материалы), на работы плюс материалы (самый популярный), и полный пакет с дизайн-проектом. Кстати, про дизайн - мы не держим штатных дизайнеров, работаем с фрилансерами. Так получается и дешевле для клиента, и качество выше - каждый дизайнер специализируется на своем стиле.
Первый образец договора, который ставили на сайт
Расчёт стоимости
Расчет стоимости работ - отдельная история. Когда начинали, было очень сложно. На рынке нет четких цен - один мастер берет 3 тысячи за квадрат стяжки, другой - тысячу, третий вообще говорит "ну давайте посмотрим по факту". Сначала работали по среднему прайсу, но часто уходили в минус по отдельным этапам - то бригада дороже встанет, то материала больше уйдет. Сейчас, когда появились постоянные сотрудники, стало проще - мы точно знаем их расценки и можем давать фиксированную цену.
Материалы
Выяснилось, что в крупных магазинах часто дешевле в сравнении с рынками стройматериалов, особенно если ловить акции. Плюс появились маркетплейсы - там вообще красота по ценам. И главное - полная прозрачность, клиент сам видит все позиции. Если находим материал дешевле - возвращаем разницу. Был случай, когда на керамограните сэкономили клиенту почти 30 тысяч - просто потому что, нашли ту же плитку в другом магазине по акции.
Как работаем сейчас
Сейчас берем 2-5 заказов в месяц, зависит от сезона и сложности объектов.
Процесс обкатан до мелочей: сначала выезд на замер, потом предварительная смета. Если клиента все устраивает - детальный расчет и договор. Дальше начинается самое интересное - согласование материалов, закупки, работа.
Особенности продвижения и подводные камни
С продвижением интересно получилось. Сначала, как все, полезли на Авито. И знаете что? Не зашло. Там своя специфическая аудитория и конкретно у нас, с Авито “ не пошло”.
Свежий пример страницы с авито в категории "Ремонт квартир". Как клиенты определяются с подрядчиком среди тысяч однотипных объявлений - хороший маркетинговый вопрос, который мы решаем, после чего полноценно "зайдём" на авито
Пробовали контекстную рекламу яндекс - тоже так себе результат. Клики дорогие, конверсия низкая. Зато отлично зашла таргетированная реклама в Instagram* (*запрещен в РФ) и реклама в районных пабликах ВКонтакте. Особенно в группах новостроек в ТГ - там как раз наша целевая аудитория.
Но главный канал - сарафанное радио. Причем работает оно интересно. Всегда знаешь , от кого пришли заказчики и проще выстраивать коммуникацию. Есть клиент - он доволен, рассказал коллегам - и понеслось. За три месяца получили еще два заказа от сотрудников той же компании. Выходит такой “корпоративный ремонт”)))
Были, конечно, и провалы в продвижении. Пытались работать с риелторами - предлагали им комиссию за клиентов. Не пошло - у них свои схемы, свои бригады. Пробовали давать рекламу в лифтах, входных группах - тоже мимо, ни одного обращения, но тут скорее из-за того что эта реклама буквально на день.
ИТОГ
Сейчас мы существуем уже чуть больше года и в целом смотрим на ремонтный рынок не так, как раньше. За это время мы сделали несколько важных заметок для себя:
Оказывается, большинство проблем в ремонте - это не технические сложности, а банальная организация процессов. Когда все четко спланировано и каждый знает что делать - даже самый сложный ремонт идет как по маслу.
Мы поняли, почему многие компании "химичат" с ценами и сроками - просто потому что не умеют нормально считать и планировать. Когда все процессы выстроены правильно, можно работать честно и все равно оставаться в плюсе.
Самое сложное - это не найти клиентов или научиться делать ремонт. Самое сложное - это переломить привычку рынка работать "по-серому". И заказчики, и исполнители настолько привыкли к непрозрачным схемам, что честный подход вызывает удивление.
Мы до сих пор учимся. Каждый объект - это новый опыт и новые вызовы (особенно по части коммуникаций с клиентами). Но главное - мы видим, что наша модель работает и пока что, нам удается держать ценник немного ниже рыночного, за счёт того что до сих пор не имеем в найме маркетологов, IT, отдела продаж и менеджеров по продажам. Стараемся нанимать именно рабочих, все остальное можно отдать на аутсорс.
Уважаемые пикабушники, были рады составить для вас эту статью! С любовью, СК Комната
Чёт все забыли, все уверены, что абсолютно всё в интернете придумала США и вообще РФ отсталая страна в IT...
Игорь Сысоев начал писать Nginx примерно в 2002 году, когда работал системным администратором в Rambler. Проект изначально создавался как решение проблемы масштабирования при высоких нагрузках — чтобы сервер мог эффективно обслуживать десятки тысяч одновременных соединений.
Релиз: вышел осенью 2004 года. Это окно видели ВСЕ!!!!!!
По оценкам на 2026 год (например, W3Techs) Nginx используют примерно 30–31% всех сайтов, для которых удалось определить веб-сервер. Но важно не запутаться: если смотреть на все когда-либо созданные домены, доля будет ниже (около 14–20%), а если брать топ самых посещаемых ресурсов — тут Nginx часто лидирует (больше трети из миллиона лучших сайтов). В российском сегменте разрыв ещё заметнее: в зоне .ru доля Nginx доходит до 85–89%.
Вот вам русское изобретение - прям мирового масштаба!
Настройка VPS Ubuntu и Debian проверяется простой перезагрузкой. Сайт открылся на новом сервере, а после перезагрузки перестал отвечать, ведь веб-сервер не был добавлен в автозапуск. Проверка после каждого шага настройки помогает обнаружить такую ошибку до того, как сервер понадобится в работе.
Статья рассчитана на новый VPS с Ubuntu 24.04 LTS или Debian 13. На нём будет работать веб-сервер Nginx. Нужен чистый образ без панели управления, Docker и своих сетевых правил.
Для первоначальной настройки хватит SSH-сервера, sudo для работы администратора, ca-certificates для проверки сертификатов и curl для проверки веб-сервиса. Сетевой экран UFW пригодится, если правила доступа ещё не настроены другим инструментом. Состав образа у провайдеров различается, поэтому часть этих пакетов может уже стоять.
До заказа VPS стоит проверить в документации приложения, какие выпуски ОС и архитектуры оно поддерживает. Готовые программы для amd64 и arm64 различаются, поэтому нужен вариант под процессор вашего сервера.
Ubuntu 24.04 LTS получает стандартные обновления безопасности до мая 2029 года. Условия для отдельных пакетов зависят от раздела репозитория. У Debian 13 полная поддержка заявлена до августа 2028 года. Затем часть пакетов и архитектур продолжит получать исправления безопасности до июня 2030 года. Сроки опубликованы на страницах Ubuntu и Debian. В апреле 2026 года вышла Ubuntu 26.04 LTS со стандартной поддержкой до мая 2031, и если собираетесь выбирать её, для нового сервера стоит проверить, поддерживает ли её ваше приложение. Пример ниже собран на 24.04, потому что под неё чаще готовы сторонние репозитории.
Как установить Ubuntu на VPS, решает панель провайдера, так как новый сервер создаётся из готового образа. Переустановка может удалить данные работающего сервера, поэтому мы берём пустой VPS. После первого входа две команды покажут ОС и архитектуру:
cat /etc/os-release
dpkg --print-architecture
Название образа, версия ОС, архитектура и дата создания пригодятся при восстановлении.
Настройка VPS сервера на Ubuntu начинается с доступа: без рабочего SSH остальные шаги проверить нечем. SSH даёт доступ к командной строке сервера. Имя пользователя и адрес выдаёт провайдер. В примерах ниже USER и SERVER_IP нужно заменить своими значениями. Команда для подключения выполняется на вашем компьютере, а остальные команды – на VPS, если не указано иное:
ssh USER@SERVER_IP
Если SSH использует нестандартный порт, к команде нужен параметр -p с его номером. При первом входе клиент покажет отпечаток ключа сервера. Его нужно сверить через панель провайдера или аварийную консоль. Если отпечатка в панели нет, консольная команда ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub покажет отпечаток ключа Ed25519. В клиенте для сравнения должен быть выбран тот же тип ключа.
Для установки пакетов обычному пользователю нужны права администратора. Команда sudo -l покажет разрешённые действия. На новом VPS у администратора обычно есть разрешение ALL на запуск любых команд. Если провайдер выдал только root, отдельного администратора можно создать с помощью этих команд:
apt update
apt install sudo
adduser admin
usermod -aG sudo admin
Если SSH-ключей ещё нет, создайте пару на своём компьютере: ssh-keygen -t ed25519. Закрытый ключ остаётся у вас. Открытый ключ из файла с расширением .pub нужно добавить в ~/.ssh/authorized_keys выбранного пользователя на VPS. Знак ~ означает его домашний каталог. При доступном входе по паролю утилита ssh-copy-id USER@SERVER_IP перенесёт ключ с компьютера автоматически. Если её нет, ключ можно добавить вручную через консоль. У каталога ~/.ssh должны быть права 700, у файла – 600, владельцем должен быть выбранный пользователь.
Для проверки входа по ключу откройте на компьютере новый терминал:
ssh -S none -o PreferredAuthentications=publickey USER@SERVER_IP
Эта команда создаёт отдельное соединение и проверяет именно ключ. Если при входе спросят парольную фразу, это фраза от самого ключа, а не пароль пользователя на сервере. После входа sudo -l должен показать прежние права. Старый сеанс пока оставьте открытым, а аварийная консоль поможет исправить ошибку, если SSH станет недоступен.
APT устанавливает программы из репозиториев – источников пакетов для выбранной ОС. Их адреса обычно уже есть в образе. Файл с настройками в Ubuntu 24.04 можно прочитать так:
cat /etc/apt/sources.list.d/ubuntu.sources
В Debian 13 часто используется файл debian.sources:
cat /etc/apt/sources.list.d/debian.sources
Если файла нет, команда ls /etc/apt/sources.list.d/ покажет другие имена. Образ провайдера также может хранить источники в старом формате /etc/apt/sources.list.
В записях Ubuntu 24.04 ожидается кодовое имя noble, у Debian 13 – trixie. Суффикс -security обозначает обновления безопасности. Замена кодового имени подключит пакеты другого релиза и может нарушить работу системы при обновлении.
После проверки источников обновление выполняется одинаково в обеих системах:
sudo apt update
sudo apt upgrade
Первая обновляет сведения о пакетах, вторая устанавливает доступные обновления. После успешного apt update команда apt-cache policy покажет источники и их приоритеты. Если APT сообщает об ошибке подписи или недоступном источнике, сначала нужно устранить её. Проверку подписей отключать нельзя, без неё APT не проверит подлинность пакетов.
Для примера хватит штатных репозиториев. Адрес стороннего источника и его ключ берите только из документации того, кто его выпускает, и только в разделе для вашей ОС. PPA собирают под конкретный выпуск Ubuntu: на Debian такие пакеты могут не встать или потянуть за собой чужие зависимости, хотя APT в обеих системах одинаковый.
Для нашей страницы не нужны ни графическая оболочка, ни база данных. Перед установкой Nginx добавим три вспомогательных пакета:
sudo apt install ca-certificates curl ufw
dpkg-query -W ca-certificates curl ufw
Пакет ca-certificates содержит доверенные корневые сертификаты, они нужны программам для проверки HTTPS-соединений. curl поможет отправить запрос к сайту из терминала. UFW управляет сетевыми правилами, его настройкой займёмся до установки Nginx, поскольку пакет веб-сервера может сразу запустить службу.
Вторая команда выводит версии пакетов. Её результат пригодится для сравнения после обновления.
Утилиты вроде htop для просмотра процессов можно добавить позже. Здесь нужна команда ss, а если её нет, поможет sudo apt install iproute2.
Чтобы сервис был доступен извне, программа должна принимать соединения на нужном порту, а сетевой экран – пропускать их. Разрешение в UFW само по себе ничего не запускает. Команда sudo ss -lntp показывает программы, которые ждут TCP-соединений, и адреса, на которых они доступны.
Адрес 127.0.0.1 означает доступ только внутри VPS, 0.0.0.0 – все локальные IPv4-адреса, [::] – все локальные IPv6-адреса. У SSH нужно проверить номер порта. Ниже используется стандартный 22, если у вас другой, замените его до выполнения команд.
Понять, как открыть порт на VPS сервере Ubuntu, помогает разделение на два слоя: программа должна принимать соединения, а сетевой экран – пропускать их. Поэтому в экране оставляют разрешения только для используемых портов, а остальные входящие запрещают по умолчанию. Исключение – отдельный сетевой экран провайдера, там доступ нужно разрешить ещё раз.
Перед включением правил разрешите текущий порт SSH и подготовьте аварийную консоль. В примере UFW будет единственным инструментом управления правилами внутри VPS. На сервер с уже настроенными nftables, Docker или панелью управления этот набор команд без проверки переносить нельзя. Порядок для чистой машины:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw enable
sudo ufw status verbose
Порт 80 предназначен для тестовой страницы по HTTP. Статус UFW должен быть active, а в списке разрешений – порты SSH и HTTP. При включённом IPv6 нужны и соответствующие правила с пометкой v6. Настройка VPS Debian на этом шаге не отличается: UFW ставится из тех же репозиториев, и команды совпадают. Подробнее о правилах – в руководстве UFW.
Теперь повторите проверочный вход с параметром -S none. Старый сеанс продолжит работать, даже если правило закрыло порт, поэтому проверять нужно новым подключением. Сайт проверим после запуска Nginx.
Если часы сервера спешат или отстают, программы могут отвергать действующие сертификаты. При разных часовых поясах на серверах труднее сопоставлять события в журналах. Время и синхронизацию покажет timedatectl status, имя машины – hostnamectl status.
Единый часовой пояс UTC задаётся командой sudo timedatectl set-timezone UTC. Она меняет часовой пояс, не настраивая синхронизацию. Если синхронизации нет, нужно проверить службу времени образа: например, systemd-timesyncd или chrony.
Локаль задаёт язык сообщений, формат дат и чисел. Команда locale покажет её настройки, locale -a – доступные варианты. Рабочую C.UTF-8 можно оставить.
Команда export меняет окружение только текущей оболочки, а системная служба под управлением systemd стартует со своим набором переменных. Задают его директивами Environment и EnvironmentFile в юните службы. Пароли и токены в командную строку не вписывают, так как строка запуска видна в выводе ps любому пользователю системы и оседает в истории оболочки. Секреты выносят в отдельный файл, который читает приложение или сам юнит через EnvironmentFile, с правами 600 и владельцем – учётной записью приложения.
1. Источники пакетов: у релизов разные кодовые имена и адреса репозиториев; чужие записи APT переносить нельзя.
2. Версии программ: нужный пакет или способ его настройки может отличаться, поэтому инструкция должна соответствовать выбранному выпуску.
3. Состав образа: начальная учётная запись, наличие sudo, служба времени и сетевые настройки зависят также от провайдера.
Пакет Nginx содержит готовую службу. Системный менеджер systemd запустит её сейчас и при следующей загрузке VPS:
sudo apt install nginx
dpkg-query -W nginx
sudo nginx -t
sudo systemctl enable --now nginx
Команда nginx -t проверяет конфигурацию. При ошибке запускать следующие команды рано: в сообщении обычно указаны файл и строка, требующие внимания. Ключ --now запускает службу сразу, enable включает её автозапуск.
В стандартной конфигурации пакета файлы сайта лежат в /var/www/html. Этот путь указан в параметре root файла /etc/nginx/sites-enabled/default. Перед созданием страницы его стоит сверить. При другом каталоге сайта путь в командах ниже нужно заменить. Мы добавим отдельный файл с коротким текстом:
printf 'vps-ok\n' | sudo tee /var/www/html/health.txt
sudo chown root:root /var/www/html/health.txt
sudo chmod 644 /var/www/html/health.txt
curl --fail --show-error http://127.0.0.1/health.txt
для статической страницы, рабочим процессам Nginx не требуется право менять её. Ожидаемый ответ на запрос – vps-ok.
Теперь можно перезапустить Nginx и посмотреть, вернулся ли он к работе:
sudo systemctl restart nginx
systemctl status nginx --no-pager
sudo journalctl -u nginx -n 30 --no-pager
Статус active (running) подтверждает, что служба работает. Журнал помогает найти ошибки запуска. Ошибки обработки запросов ищите в /var/log/nginx/error.log. После перезапуска нужен тот же запрос curl. Затем команда sudo reboot перезагрузит VPS и разорвёт SSH-сеанс. После загрузки должны снова работать вход по SSH и запрос к странице, ожидаемый статус Nginx – active (running).
Если локальный запрос вернул vps-ok, Nginx отдаёт файл. Проверка с вашего компьютера покажет, доступен ли он через интернет. В команде нужен внешний IPv4-адрес сервера:
curl --fail --show-error --max-time 10 http://SERVER_IP/health.txt
Ожидается тот же текст vps-ok. Если снаружи ответа нет, стоит проверить адрес, порт в ss, правила UFW и сетевой экран провайдера, если он есть. Для доступа по IPv6 нужна отдельная проверка, так как запрос по IPv4 его не проверяет.
Эта тестовая страница работает по HTTP без шифрования. Перед публикацией сайта с авторизацией или личными данными нужны домен, сертификат и настройка HTTPS. После этого нужен доступ к порту 443 и запрос по имени сайта с проверкой сертификата.
Обновления лучше назначать на время, когда допустим короткий перезапуск. До обновления сохраняйте /etc/nginx и файлы сайта вне VPS. В копию стоит включить настройки UFW, список репозиториев и версии из dpkg-query -W. Секретные файлы в такой копии тоже требуют защиты. Базу данных, если она есть, копируют её собственными средствами резервного копирования.
После обновления повторяется уже знакомая проверка: nginx -t, состояние службы, новое соединение по SSH и запрос к странице с компьютера. Время запуска автоматических обновлений покажет systemctl list-timers --all. Настройки установленного unattended-upgrades находятся в /etc/apt/apt.conf.d/. История операций APT хранится в /var/log/apt/history.log. Пришедшие обновления ядра могут потребовать перезагрузки, это стоит учитывать на сервере с работающими приложениями.
В инструкции восстановления стоит указать версию образа, источники пакетов и расположение копий конфигурации. Рядом запишите, как подключиться к серверу после восстановления: пользователь, адрес, порт и место хранения ключа. Сам закрытый ключ должен оставаться в защищённом хранилище.
Пробное восстановление на отдельном VPS покажет, хватает ли сохранённых файлов и записей. После перезагрузки должны работать SSH и страница сайта, а правила сетевого экрана – совпадать с исходными. Успешный результат подтвердит, что настройку можно повторить.
Хорошая настройка VPS Ubuntu – та, которую можно повторить на чистом образе и проверить тем же smoke test после обновления. Если после переустановки из того же образа сервер отвечает на SSH, тестовая страница отдаёт условный vps-ok, а правила сетевого экрана совпадают с записанными, окружение воспроизводимо. Всё, что нельзя повторить по своей же инструкции, при следующем сбое придётся собирать заново и по памяти.
Вы арендовали VPS, получили IP и пароль от root. Между этим моментом и рабочим сервисом в продакшене лежит десяток шагов, которые важно пройти в правильном порядке. Пропустить один из них означает оставить сервер уязвимым или потратить часы на отладку в самый неподходящий момент. И здесь встаёт вопрос: как подготовить свой VPS к реальной работе?
Этот материал проведёт вас от первого SSH-подключения до полноценного окружения с безопасным доступом, настроенным firewall и рабочим стеком приложений. Руководство написано для Ubuntu 22.04 LTS: проверенного LTS-релиза, который часто используют для серверов и небольших проектов. В конце вас ждёт чек-лист, который удобно держать под рукой при каждой новой установке.
Перед тем как приступить к установке VPS и первичной настройке, убедитесь, что у вас есть всё необходимое.
Во-первых, данные для подключения: IP-адрес сервера, имя пользователя (обычно root) и пароль или SSH-ключ. Всё это провайдер высылает на email сразу после создания машины. Если провайдер вместо пароля сразу добавил публичный ключ, убедитесь, что соответствующий приватный ключ есть у вас локально.
Во-вторых, терминал на локальной машине. На macOS и Linux SSH встроен по умолчанию. На Windows удобно использовать PowerShell со встроенным OpenSSH-клиентом.
Заранее найдите в панели провайдера KVM/VNC-консоль, она понадобится в случае потери SSH-доступа после изменений в конфигурации сети или firewall.
Подключитесь к серверу из терминала. Замените YOUR_IP на IP-адрес сервера:
ssh root@YOUR_IP
При первом подключении терминал покажет предупреждение с отпечатком (fingerprint) сервера (уникальным идентификатором хоста) и предложит добавить его в список доверенных. Перед подтверждением сверьте fingerprint с данными в панели провайдера или документации к инстансу. Если он совпадает, введите yes. SSH сохранит ключ хоста в ~/.ssh/known_hosts. Если отпечаток изменится при повторном подключении, это может указывать на атаку посредника или на переустановку сервера.
Если провайдер настроил аутентификацию по SSH-ключу, а не по паролю, укажите путь к приватному ключу:
ssh -i ~/.ssh/id_rsa root@YOUR_IP
Возможные ошибки при первом подключении:
• Connection refused: SSH-сервис не запущен или порт закрыт. Проверьте состояние сервера через панель провайдера, иногда образ ещё инициализируется.
• Permission denied (publickey): ключ не добавлен на сервер или указан неверный путь к файлу ключа.
• Connection timed out: IP указан неверно или сервер ещё загружается. Подождите минуту и повторите.
Для удобства при частых подключениях настройте алиас в файле ~/.ssh/config на локальной машине:
Host myserver
HostName YOUR_IP
User root
IdentityFile ~/.ssh/id_rsa
После этого достаточно набрать ssh myserver. При необходимости подключаться под другим пользователем добавьте второй блок Host с другим значением User.
Сразу после входа обновите список пакетов и сами пакеты.
apt update && apt upgrade -y
После обновления установите базовый набор инструментов:
apt install -y curl wget htop ufw fail2ban
Назначение каждого пакета:
• curl и wget: загрузка файлов и скриптов из сети;
• htop: интерактивный мониторинг процессов и потребления ресурсов;
• ufw: управление правилами firewall поверх iptables;
• fail2ban: автоматическая блокировка IP при многократных неудачных попытках входа.
Если после обновления терминал выводит System restart required, было обновлено ядро. Выполните reboot, дождитесь восстановления SSH-соединения (обычно 30–60 секунд) и продолжайте.
Безопасная работа на своём VPS начинается с отказа от постоянной работы под root. Любая ошибка в команде или скомпрометированный пакет, запущенный с правами root, получает неограниченный доступ к системе. Создайте отдельного пользователя с правами sudo.
Если у вас ещё нет SSH-ключа, сгенерируйте его на локальной машине. Алгоритм ed25519 предпочтительнее RSA:
ssh-keygen -t ed25519 -C "myserver"
Публичный ключ находится в ~/.ssh/id_ed25519.pub. Его нужно добавить на сервере в файл ~/.ssh/authorized_keys того пользователя, под которым вы будете подключаться по SSH.
Создание пользователя и добавление в группу sudo:
adduser admin
usermod -aG sudo admin
Проверьте, что пользователь добавлен корректно:
id admin
В выводе должна присутствовать группа sudo. Зайдите под новым пользователем и проверьте работу sudo: выполните sudo whoami, вывод root подтверждает корректную конфигурацию. Скопируйте SSH-ключи из root-окружения:
mkdir -p /home/admin/.ssh
cp /root/.ssh/authorized_keys /home/admin/.ssh/authorized_keys
chown -R admin:admin /home/admin/.ssh
chmod 700 /home/admin/.ssh
chmod 600 /home/admin/.ssh/authorized_keys
Важно: откройте вторую сессию и убедитесь, что вход под admin работает, прежде чем вносить следующие изменения. Потеря доступа на этом этапе потребует входа через KVM/VNC-консоль провайдера.
Откройте конфигурацию SSH:
nano /etc/ssh/sshd_config
Найдите и задайте параметры:
PermitRootLogin no
PasswordAuthentication no
Перезагрузите конфигурацию через reload, а не restart: активные сессии при этом не прервутся.
systemctl reload ssh
Опционально: смена стандартного порта SSH с 22 на нестандартный снижает объём шума от автоматических сканеров в логах. Если решите изменить порт, сначала разрешите новый порт в UFW, затем внесите изменения в sshd_config и только после этого перезагрузите SSH.
Свежий сервер без firewall попадает под сканирование портов в первые минуты после выдачи публичного IP. UFW (Uncomplicated Firewall) снижает этот риск без необходимости работать с iptables напрямую. По умолчанию UFW блокирует весь входящий трафик и разрешает исходящий трафик.
Важный порядок действий: сначала создайте разрешающие правила, и только потом включайте firewall. Иначе вы заблокируете SSH и потеряете доступ к серверу.
Разрешите нужные порты:
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
Если используете нестандартный порт SSH, добавьте его вместо или дополнительно к 22 на период перехода. Включите firewall и проверьте статус:
ufw enable
ufw status
Вывод Status: active и список разрешённых портов подтверждают корректную работу. Все остальные входящие соединения будут отклоняться.
Настройка fail2ban. На Ubuntu 22.04 SSH-события пишутся в systemd journal, поэтому создайте файл /etc/fail2ban/jail.local с указанием backend:
[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h
Перезапустите сервис и проверьте статус:
systemctl restart fail2ban
fail2ban-client status sshd
В выводе строки Currently banned и Currently failed покажут число заблокированных адресов и количество неудачных попыток за текущий период. Снять блокировку вручную можно командой fail2ban-client set sshd unbanip IP. Если fail2ban не видит попыток входа при реальных ошибках, проверьте значение backend = systemd в конфиге.
Состав стека целиком зависит от задач проекта. Для большинства веб-приложений достаточно трёх компонентов: веб-сервер, база данных и runtime языка. Устанавливайте только то, что действительно нужно: каждый лишний запущенный сервис потребляет ресурсы сервера.
Nginx в роли веб-сервера и reverse proxy – стандартный выбор для большинства проектов:
apt install -y nginx
systemctl enable nginx
PostgreSQL для реляционных данных:
apt install -y postgresql
MySQL как альтернатива:
apt install -y mysql-server
Node.js. Версия в стандартном репозитории Ubuntu 22.04 может быть старее актуальной LTS-версии. Для установки свежей LTS-версии можно использовать NodeSource, предварительно сверив номер версии на nodejs.org:
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
apt install -y nodejs
Python 3 уже предустановлен в Ubuntu 22.04. Для работы с виртуальными окружениями добавьте:
apt install -y python3-pip python3-venv
Если проект допускает контейнеризацию, Docker избавляет от ручного управления зависимостями: приложение с окружением упаковывается в образ и запускается одинаково на любом хосте. Для продакшен-среды предпочтительнее установка через официальный apt-репозиторий Docker: так проще контролировать источник пакетов и обновления. Официальный скрипт тоже добавляет репозиторий Docker Engine и ставит актуальную версию, но его лучше использовать для быстрого старта или тестового окружения:
curl -fsSL https://get.docker.com | sh
Добавьте пользователя в группу docker, чтобы команды выполнялись без sudo:
usermod -aG docker admin
Изменения применятся при следующем входе в сессию. Docker Compose v2 устанавливается как плагин и вызывается без дефиса:
apt install -y docker-compose-plugin
docker compose up -d
Пример минимального docker-compose.yml для сервиса с автоперезапуском:
services:
app:
image: myapp:latest
ports:
- "8080:8080"
restart: unless-stopped
Проверьте, что Docker установлен корректно и может запустить тестовый контейнер:
docker run hello-world
Привязка домена. В DNS-настройках у регистратора добавьте A-запись, указав IP сервера:
@ → YOUR_IP
www → YOUR_IP
Обновление DNS-записей занимает от нескольких минут до 24 часов. Проверить это можно командой dig yourdomain.com или через онлайн-сервисы вроде dnschecker.org. Не запускайте certbot до того, как запись распространится: это приведёт к ошибке валидации.
HTTPS через Let's Encrypt. Установите Certbot с плагином для Nginx:
apt install -y certbot python3-certbot-nginx
Получите сертификат:
certbot --nginx -d yourdomain.com -d www.yourdomain.com
Certbot изменит конфигурацию Nginx, добавит HTTPS-блок с путями к сертификату и предложит настроить редирект с HTTP на HTTPS. Обновление сертификата происходит через cron или systemd timer без вашего участия. Сертификат Let's Encrypt действует 90 дней. Проверьте, что продление пройдёт без ошибок:
certbot renew --dry-run
Автозапуск сервисов. Пакеты, установленные через apt, как правило, включаются в автозапуск автоматически. Для собственного приложения создайте unit-файл:
nano /etc/systemd/system/myapp.service
Минимальное содержимое:
[Unit]
Description=My Application
After=network.target
[Service]
ExecStart=/usr/bin/node /home/admin/app/index.js
User=admin
Restart=on-failure
[Install]
WantedBy=multi-user.target
Подключите и запустите:
systemctl daemon-reload
systemctl enable myapp
systemctl start myapp
Каждая установка VPS проходит по схожему маршруту. Сохраните этот список и проходитесь по пунктам при каждой новой настройке.
1. Система обновлена: apt update && apt upgrade выполнены
2. Создан непривилегированный пользователь с правами sudo
3. Root-вход отключён: PermitRootLogin no в /etc/ssh/sshd_config
4. Аутентификация только по SSH-ключу: PasswordAuthentication no
5. UFW активен: ufw status показывает Status: active с нужными правилами
6. fail2ban работает: fail2ban-client status sshd показывает активный jail
7. HTTPS настроен: certbot renew --dry-run выполняется без ошибок
8. Сервисы добавлены в автозапуск: проверьте systemctl is-enabled nginx и другие
9. Настроены бэкапы или снапшоты через панель провайдера
10. Запланированы регулярные обновления безопасности: настройте unattended-upgrades для security-обновлений или другой контролируемый процесс обновления.
От первого ssh root до продакшен-среды вполне можно дойти за один рабочий день. Настройка VPS-сервера с нуля требует внимания прежде всего на этапе безопасности: шаги, пропущенные здесь, могут позже дать о себе знать. Не жалейте времени на проверку каждого пункта чек-листа до открытия сервиса пользователям.
VPS куплен, SSH-сессия открыта. У многих здесь возникает пауза: непонятно, с чего начать и под какую задачу настраивать VPS-сервер. Разберём пять практических сценариев того, как использовать VPS: хостинг сайтов, запуск ботов, размещение API, мониторинг и автоматизация. У каждого – конкретный стек, ориентиры по ресурсам и нюансы, которые лучше знать до начала настройки, а не в процессе. Реальные требования зависят от сложности проекта, нагрузки, выбранного стека и числа одновременно работающих сервисов.
VPS-сервер отличается от shared-хостинга тремя вещами. Первое – у вас есть заявленные параметры тарифа: CPU, RAM, диск и сетевой канал. На качество работы всё ещё может влиять общая инфраструктура хоста, но изоляция здесь выше, чем на shared-хостинге. Второе – root-доступ: можно установить любой софт, выбрать версию PHP, настроить nginx под конкретную задачу. Третье – VPS-сервер работает круглосуточно без вашего участия, независимо от состояния вашего компьютера или интернета. На shared-хостинге чужая нагрузка может повлиять на соседние сайты, если провайдер плохо ограничивает ресурсы аккаунтов.
От облачных функций (AWS Lambda, Yandex Cloud Functions) VPS отличается предсказуемостью: нет cold-start задержек, нет тарификации за каждый вызов функции, нет ограничений по времени выполнения. Для задач с постоянными процессами: баз данных, ботов, мониторинга – VPS часто проще и предсказуемее, чем serverless-архитектура с оплатой за вызов. При низкой или нерегулярной нагрузке serverless может оказаться дешевле.
Настройка VPS начинается не сразу с рабочего проекта, а с базовой конфигурации. Базовая настройка снижает риск классических проблем: открытого SSH, устаревших пакетов, лишних портов и нехватки памяти при пиковых нагрузках. Пропуск таких шагов может увеличить риск потерять сервер из-за брутфорса или случайной команды от root.
• SSH-ключи. Сгенерируйте пару через ssh-keygen, передайте публичный ключ через ssh-copy-id, отключите аутентификацию по паролю в sshd_config.
• Пользователь без root. Создайте аккаунт с правами sudo. Работа от root в продакшене – плохая практика. Одна ошибка может стоить всей системы.
• Firewall. Откройте в UFW SSH-порт, 80 и 443, если они нужны вашему сценарию. Если используется стандартный SSH-порт, это 22. Fail2ban добавит защиту от брутфорса на SSH.
• Swap. Если RAM меньше 2 ГБ, добавьте swap-файл на 1–2 ГБ. Он снижает риск OOM при пиковой нагрузке, но при активном использовании может ухудшить производительность.
• Обновления. Запустите sudo apt update && apt upgrade сразу после входа на сервер, до начала любой работы.
Хостинг на VPS оправдан, когда shared-хостинг перестал справляться: нет нужной версии PHP или Python, не хватает памяти, несколько доменов требуют разных настроек или нестандартного ПО. На VPS больше свободы в настройке: можно выбрать версии ПО, настроить веб-сервер, подключить нужные модули и управлять несколькими проектами независимо. Именно поэтому многие переезжают сюда с первого же конфликта с техподдержкой shared-хостинга.
Стек: Nginx как веб-сервер и reverse proxy, PHP-FPM для WordPress или других CMS, MySQL или PostgreSQL как база данных. Для статических сайтов (Hugo, Astro, Next.js SSG) Nginx работает без интерпретатора, нагрузка минимальная. SSL – Let’s Encrypt через Certbot, бесплатно и с автообновлением. Один Nginx обслуживает несколько доменов через server blocks.
Порты СУБД (3306, 5432) наружу не открывайте: приложение обращается к базе внутри сервера. Для сайта с умеренным трафиком часто хватает 1 vCPU и 1–2 ГБ RAM; для тяжёлых CMS с кешированием, большим числом плагинов или высокой посещаемостью лучше закладывать 2 vCPU и 2–4 ГБ. Добавьте Redis для кеша сессий: это может снизить нагрузку на базу данных и улучшить отклик WordPress при росте трафика.
Боту часто нужно работать круглосуточно и хранить состояние: настройки пользователей, историю диалогов, очереди задач. Локальная машина для этого не подходит, а облачные функции удобны в основном для коротких команд без постоянного процесса. VPS решает обе задачи: бот постоянно запущен, а база данных может работать рядом на том же сервере.
Стек для Telegram: Python + aiogram, управление процессом через systemd, хранение состояния в SQLite или PostgreSQL. SQLite подходит для небольших ботов с умеренной нагрузкой, но при высокой конкуренции запросов или запуске нескольких экземпляров приложения лучше сразу выбирать PostgreSQL. Для Discord – Node.js + discord.js, для управления процессом удобен PM2. Redis подойдёт для быстрого хранения временных данных и очередей.
Для большинства продакшен-сценариев с Telegram-ботами удобен webhook-режим: сервер сам получает обновления, не опрашивая API Telegram. Для webhook нужен домен с HTTPS. Polling тоже остаётся корректным вариантом для небольших проектов: он проще в запуске и не требует домена с HTTPS. Простой бот без базы данных умещается на 1 vCPU и 1 ГБ RAM. Бот со сложными очередями, вызовами внешних API и ML-моделями потребует минимум 2 ГБ RAM. Через systemd настраивается автозапуск: после перезагрузки сервера бот поднимется сам.
VPS-сервер даёт API постоянный адрес, свою базу данных и полный контроль над окружением, без vendor lock-in и без ограничений по времени выполнения запросов. Это важно для бэкендов с длительными операциями: обработкой файлов, парсингом, генерацией отчётов.
Стек: FastAPI (Python) или Express.js (Node.js) для REST, Docker для изоляции сервисов, Nginx или Traefik как reverse proxy. Приложение слушает на localhost, наружу открыты только 80 и 443. GraphQL – Strawberry (Python) или Apollo Server (Node.js). Для автодеплоя – GitHub Actions: пуш в main запускает пересборку и перезапуск контейнера.
Порты базы данных держите внутри Docker-сети, не открывайте наружу: бэкенд обращается к базе по имени сервиса внутри сети. Для API с базой данных начинайте с 2 vCPU и 2–4 ГБ RAM. При росте нагрузки Docker и reverse proxy позволяют масштабировать сервисы без переписывания архитектуры. Traefik автоматически получает и обновляет SSL-сертификаты через Let’s Encrypt при настроенном ACME, поэтому отдельная настройка Certbot не нужна.
Сервер мониторинга должен работать независимо от мониторируемой инфраструктуры. Если основной сервер упал, система мониторинга должна увидеть это первой и отправить алерт, а не упасть вместе с ним. Отдельный небольшой VPS для мониторинга решает эту задачу.
Uptime Kuma – удобный инструмент с веб-интерфейсом: отслеживает HTTP-статусы, время ответа, порты TCP, отправляет алерты в Telegram, Slack и другие каналы. Разворачивается через Docker за несколько минут и обычно помещается в небольшой VPS. Для лёгкого мониторинга часто достаточно 512 МБ RAM, но потребление зависит от числа проверок и их типа.
Prometheus + Grafana – полный стек для сбора метрик, построения дашбордов и настройки алертов. Prometheus собирает данные с exporters, Grafana строит графики. Оба сервиса вместе могут потреблять примерно 600–1000 МБ RAM в покое, но фактическое потребление зависит от retention, числа targets и объёма метрик. Под этот сценарий обычно стоит закладывать не меньше 2 ГБ RAM. Node Exporter собирает системные метрики хоста – CPU, RAM, диск, сеть; добавьте его на каждый наблюдаемый сервер. Алерты в Telegram настраиваются через Alertmanager за несколько минут.
Сервер не выключается. Это главное преимущество VPS для автоматизации: cron-задачи запускаются по расписанию в любое время суток, скрипты работают столько, сколько нужно, без ограничений по времени выполнения и без зависимости от того, включён ли ваш компьютер.
n8n – self-hosted инструмент для визуальной автоматизации, аналог Zapier на вашем сервере. Разворачивается через Docker, а потребление памяти может начинаться примерно от 500 МБ RAM и расти с числом workflow, интеграций и выбранной БД. Данные о задачах хранятся в БД, поэтому volume для персистентности обязателен. Настроенный VPS с n8n заменяет подписку на облачные сервисы автоматизации и не передаёт данные третьим сторонам.
Для простых задач достаточно cron: бэкап файлов, отправка отчётов, очистка временных директорий, синхронизация данных между сервисами.
Примерные ориентиры по ресурсам под основные задачи:
• Сайт или бот без тяжёлых фоновых задач: 1 vCPU, 1–2 ГБ RAM
• API с базой данных: 2 vCPU, 2–4 ГБ RAM
• Prometheus + Grafana: 2 vCPU, 2–4 ГБ RAM
• n8n плюс несколько сценариев одновременно: 2–4 vCPU, 4–8 ГБ RAM
Несколько сценариев на одном VPS совместить возможно, но требования зависят от сложности проекта, выбранного стека, объёма трафика и числа одновременно работающих сервисов. Для простого сайта, небольшого бота и лёгкого мониторинга 2 ГБ RAM могут быть достаточны, если нет тяжёлых фоновых задач. Docker упрощает совмещение: каждый сервис в своём контейнере, порты не конфликтуют, ресурсы лимитируются. Постоянная загрузка CPU или RAM выше 80% может стать сигналом для апгрейда. Начните с минимального тарифа и расширяйте по мере роста – большинство провайдеров позволяют сделать это без пересоздания сервера.
1. SSH-ключи настроены, аутентификация по паролю отключена
2. Создан sudo-пользователь, работа от root прекращена
3. Система обновлена: sudo apt update && apt upgrade
4. UFW включён: открыты только нужные входящие порты, например SSH-порт, 80 и 443 для веб-сценариев
5. Swap настроен при RAM < 2 ГБ
6. Автоматические снапшоты или бэкапы настроены
7. Домен привязан, HTTPS работает через Let’s Encrypt
8. Базовый мониторинг: uptime и диск под контролем
VPS это не готовый продукт, а платформа для разных задач: сайта, бота, API, мониторинга или автоматизации. Начните с одного сценария, не пытайтесь запускать всё сразу. Сначала закройте базовую настройку из чек-листа: SSH-ключи, firewall, обновления, бэкапы и мониторинг. После этого разверните минимальную рабочую версию сервиса и расширяйте конфигурацию по мере роста нагрузки.
Сидишь за reverse proxy, CDN или балансировщиком - открываешь access-лог, а там один и тот же IP на всех запросах. Обычно 127.0.0.1, адрес ingress-контроллера или внутренний IP прокси.
На этом фоне ломаются rate limiting, fail2ban, аудит и любые расследования: Nginx честно пишет адрес своего непосредственного соседа, а не исходного клиента.
Почему так.
$remote_addr - это адрес узла, который напрямую установил соединение с Nginx. Если перед ним стоит прокси, то для Nginx клиентом является именно прокси.
Настоящий IP пользователя обычно приезжает отдельно:
в X-Real-IP;
в X-Forwarded-For;
в заголовке конкретного CDN;
через PROXY protocol, если перед нами L4-балансировщик.
Но просто взять значение HTTP-заголовка и записать его в лог - плохая идея:
log_format main '$http_x_real_ip - $request';
Любой клиент может сам отправить:
X-Real-IP: 1.1.1.1
и подложить в ваши логи произвольный адрес.
Правильная схема - не доверять заголовку самому по себе, а доверять конкретному прокси, который этот заголовок формирует.
Для этого в Nginx есть штатный ngx_http_realip_module.
Проверяем, собран ли он в текущем бинарнике:
nginx -V 2>&1 | tr ' ' '\n' | grep -- --with-http_realip_module
Если Nginx собираете сами, понадобится флаг:
--with-http_realip_module
В пакетах популярных дистрибутивов модуль обычно уже включён, но проверять лучше конкретный установленный бинарник.
Настраиваем доверенный прокси:
set_real_ip_from 10.42.0.10;
set_real_ip_from 10.42.0.11;
real_ip_header X-Real-IP;
После этого Nginx будет заменять $remote_addr адресом из X-Real-IP, но только если соединение пришло от узла из set_real_ip_from.
Важно: указывайте точные адреса или минимальную подсеть балансировщиков.
Вот так делать нежелательно:
set_real_ip_from 10.0.0.0/8;
Этой настройкой вы разрешаете любому узлу из всей сети 10.0.0.0/8 подменять клиентский IP. Лучше доверять конкретным адресам прокси или выделенному сегменту.
Сам origin при этом желательно закрыть от прямого доступа извне через firewall, security group или network policy. Иначе клиент сможет обойти прокси и прийти непосредственно к Nginx.
На самом прокси X-Real-IP должен перезаписываться, а не слепо передаваться от клиента:
proxy_set_header X-Real-IP $remote_addr;
Не так:
proxy_set_header X-Real-IP $http_x_real_ip;
Во втором случае прокси просто протащит значение, которое прислал пользователь.
В чём ловушка с X-Forwarded-For
Этот заголовок содержит цепочку адресов через запятую:
X-Forwarded-For: client, proxy-1, proxy-2
Если в инфраструктуре несколько доверенных прокси, можно настроить Nginx так:
set_real_ip_from 10.42.0.10;
set_real_ip_from 10.42.0.11;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
Тогда Nginx будет разбирать цепочку справа налево, пропуская доверенные адреса из set_real_ip_from, и выберет последний недоверенный адрес.
Например:
X-Forwarded-For: 1.1.1.1, 203.0.113.25, 10.42.0.10
Если 10.42.0.10 - доверенный внутренний прокси, а 203.0.113.25 - адрес клиента, добавленный доверенным edge-прокси, Nginx выберет 203.0.113.25, а не подставленный пользователем 1.1.1.1.
Но это работает безопасно только тогда, когда вся доверенная цепочка прокси известна и перечислена в set_real_ip_from.
После обработки модулем:
$remote_addr - восстановленный адрес клиента;
$realip_remote_addr - исходный адрес узла, который подключился к Nginx;
$http_x_forwarded_for - заголовок в том виде, в котором он приехал.
Для диагностики удобно логировать всё сразу:
log_format main
'client=$remote_addr '
'peer=$realip_remote_addr '
'xff="$http_x_forwarded_for" '
'request="$request" '
'status=$status';
Так можно понять не только какой IP выбрал Nginx, но и от какого прокси пришло соединение и какую цепочку тот передал.
Rate limiting после этого тоже сможет работать по реальному клиентскому адресу - если ключ зоны построен на $remote_addr или $binary_remote_addr:
limit_req_zone $binary_remote_addr
zone=per_ip:10m
rate=10r/s;
Использовать для лимитов сырой $http_x_forwarded_for не стоит: это строка с цепочкой адресов, которую при неправильной настройке прокси можно подделать или постоянно менять.
С fail2ban та же логика: он увидит реальный адрес только в том случае, если анализирует поле лога, в котором записан обработанный $remote_addr.
Если перед Nginx стоит TCP-балансировщик, HTTP-заголовков может не быть вообще. Тогда обычно используется PROXY protocol:
server {
listen 443 ssl proxy_protocol;
set_real_ip_from 10.42.0.10;
real_ip_header proxy_protocol;
}
PROXY protocol также нельзя принимать от кого угодно: источник соединения должен быть ограничен доверенными балансировщиками.
После изменения конфигурации:
nginx -t && systemctl reload nginx
Проверяем:
tail -f /var/log/nginx/access.log
Смотрим одновременно на client, peer и xff. Проверка только первого поля лога мало что доказывает: важно видеть всю цепочку и понимать, почему Nginx выбрал именно этот адрес.
Очень краткий вывод
Не доверяйте заголовку с IP.
Доверяйте конкретному прокси, который этот заголовок сформировал.
