Хостинг

Удобство облачных сервисов лишает нас контроля над цифровой жизнью. Все файлы лежат у одного Большого брата (корпорация) под наблюдением другого Большого брата (государство). Если провайдер лишит аккаунта — человек потеряет всё. Что ж, ради ежедневного комфорта многие готовы мириться с таким риском.

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

• доступ к файлам с любого устройства;
• автоматическая синхронизация файлов и резервное копирование;
• расшаривание файлов;
• совместная работа с документами.

Сегодня такое «локальное облако» можно поднять на собственном сервере или VPS в качестве альтернативы корпоративным экосистемам типа Apple, Google и «Яндекс».

Нам надо было закупить High-CPU, но так, чтобы это было одинаковое корпоративное железо для всех наших дата-центров по миру.

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

Так вот, нам надо было тоже завести такое большое число, потому что так порешал рынок.

Мы давно придерживаемся принципа использовать только настоящее серверное железо, то есть корпоративный класс. У нас в основной линейке стоят проверенные серверные Intel, которые в пике выдавали 3,7 ГГц. И мы-то знали, что наши 3,7 ГГц по реальной производительности легко обгоняют многие разогнанные решения конкурентов.

Но как это донести до человека, который просто сравнивает цифры на лендинге?

Поэтому мы стали искать серверный процессор с высокой тактовой частотой, чтобы соответствовать нашей внутренней политике и при этом не проигрывать в слепом сравнении.

Решили затестить AMD Epyc. Нашли модель с отличными ТТХ: много ядер, высокая частота. Купили партию железа.

Думали, что сейчас включим, и он просто разорвёт наш текущий Intel.

Это наш первый опыт с AMD. Нас немного смущал тренд на Реддите «Почему тормозят AMD Epyc», но казалось, что всё должно пойти хорошо.

Конечно же, хорошо не пошло, иначе я этого не писал бы.

Хостинг — рынок конкурентный. Чтобы выделиться, нужно не только предлагать пользователям качественные сервисы, но и грамотно их продвигать. BILLmanager предоставляет провайдерам целый арсенал маркетинговых инструментов: от CRM с сегментацией клиентов до email-рассылок, реферальных программ и рекламных механизмов.

Но сегодня поговорим об одном из ключевых маркетинговых инструментов платформы — скидках и акциях. Функциональные возможности BILLmanager позволяют запускать промоакции любой сложности: от простых скидок на тарифы до многоуровневых акций с промокодами и сегментированием аудитории. Причем все это — без сторонних сервисов и интеграции, прямо в панели управления.

Привет, Хабр!

Если ваша компания работает на российском рынке, то вы наверняка сталкивались с запросами клиентов на «вход через Госуслуги». В нашем BILLmanager за это отвечает модуль «Авторизация через ЕСИА». Он позволяет клиентам входить в BILLmanager через аккаунт на Госуслугах, упрощает регистрацию и проверку данных.

Сегодня мы рассмотрим, как настроить авторизацию через ЕСИА в BILLmanager 6. Разберём этот процесс шаг за шагом, чтобы сделать его максимально простым и понятным. Разложили все по полочкам — от установки самого модуля до работы с сертификатами. Сохраняйте, чтобы не потерять!

На VPS нет проблем с выбором любой ОС. Самые популярные варианты устанавливаются вместе с сервером. Как только сделан заказ, сразу выделяется виртуальный ресурс и начинается инсталляция, а через несколько минут всё готово к работе. И Linux (на нашем хостинге это Debian), и Windows Server ставятся автоматически.

Вопрос только в том, что выбрать? Или можно спросить иначе: зачем вообще нужен Windows Server, если весь серверный софт работает под Linux, казалось бы?

К сожалению, не весь.

Есть объективные факторы роста цен в ИТ — инфляция, кредитные ставки (их никто не снизил вслед за ставкой рефинансирования!), повышение страховых взносов для сотрудников и НДС. Как минимум это всё вместе уже обеспечит подорожание ИТ-услуг и инфраструктуры.

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

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

И у меня есть ощущение, что начало процесса мы уже наблюдаем по отмене части льгот для ИТ-компаний.

Год назад я писал пост «Готовьтесь к росту цен», и так получилось, что в меня в профессиональной среде сначала кидались помидорами, потом начали цитировать, а потом текст скопировали для личных блогов от своего имени чуть ли не все топы сферы. Приятно, что мы запустили такую волну в рынок, но тема, конечно, печальная.

Прошёл год, и пора снова посмотреть, что нас ждёт.

Спойлер: вы, кажется, уже привыкли к плохим новостям, но жесть от этого никуда не делась.

Простой или не простой, вот в чём вопрос… Звучит философски, но в жизни сисадмина философии мало — куда важнее чёткие показатели. Например, сколько минут (или секунд) сервис может быть недоступен, прежде чем начнутся убытки и паника. Ответ на этот вопрос обычно можно найти в SLA, в котором все хотят увидеть побольше заветных «девяток» аптайма. Но что именно стоит «99,99%», откуда вообще берутся эти «девятки» и зачем SLA нужно ИТ-отделу? Давайте разбираться.

Для системного администратора оболочка (shell) — это не утилита, а среда, в которой проходит большая часть рабочего дня. Часто работа идёт на удалённых серверах, например на виртуальных машинах UltraVDS, где удобная оболочка экономит часы настройки и отладки. Здесь настраиваются сервисы, правятся конфиги, запускаются скрипты и отлавливаются ошибки, и от того, как она себя ведёт, напрямую зависит скорость работы.

Пока задачи простые, хватает и того, что стоит по умолчанию. Но со временем начинаешь замечать мелочи: неудобное автодополнение, непредсказуемая история, странное поведение алиасов. Один раз промахнулся с rm, другой раз команда не сохранилась — и вот ты уже ищешь альтернативу.

Сегодня чаще всего выбор стоит между Bash, Zsh и Fish. Все они решают одну и ту же задачу — запуск команд — но делают это с разной философией. Разберёмся, как они устроены, где их сильные и слабые стороны, и какую оболочку стоит выбрать под конкретные задачи.

Как защитить свой VDS сервер: 53 000 попыток взлома за 5 дней

Представьте себе: вы арендовали скромный VDS, чтобы поэкспериментировать. Ничего грандиозного — пара тестовых сайтов, простенький веб-сервер на nginx, пара скриптов в cron для автоматизации рутины, SSH для удалённого доступа. Обычная песочница для разработчика, никому, казалось бы, не интересная. Сервер тихо живёт своей жизнью где-то в облаке, отдаёт странички, выполняет задачи, ждёт ваших команд. Вы даже не подозреваете, что за этой тишиной уже разворачивается настоящая цифровая охота.

За два года работы в технической поддержке облачного хостинга я видел множество взломов, помогал клиентам с восстановлением серверов. Видел всё: от примитивных майнеров до полностью стёртых проектов без бэкапов. Сейчас я работаю инженером технической поддержки в компании CleverData (входит в холдинг LANSOFT).

Однажды, ради чистого любопытства, я решил заглянуть в логи свежеиспечённого VDS, созданного всего пять дней назад...

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

Представьте, что вы написали скрипт, разместили его как serverless-функцию и неожиданно получили счёт на 75 000$ из-за самой простой ошибки обработки исключений. Представить страшно, а ведь это реальная история.

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

Я устал вести таблички с серверами и сделал сервис, который теперь помогает другим.

В последние 8 лет я работал над множеством IT проектов и стартапов: от телеграм ботов, до высоконагруженных Web-сервисов. От ТЗ до MVP — в роли разработчика, тимлида, и даже продакта. И для всех этих проектов нужна была инфраструктура, которую, как правило, выбирал и поддерживал я в одиночку.

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

Хостинг - это десятки тысяч сайтов и пользователей находящихся под управлением одного сервера.

Зачастую пользователь хостинга не погружается в детали настроек сервера, а знает только основное — на сервере есть PHP, Ruby, Python, MySQL и Apache, чтобы его сайт успешно функционировал . Ему не интересно, как и что настроено на сервере, главное, чтоб все работало и не создавало ему проблем.

Иногда после запуска VDS/VPS проходит всего несколько минут, как в логах появляются десятки попыток входа или перебора паролей. В этом случае на защиту провайдера надеяться нельзя, потому что он отвечает только за изоляцию гипервизора, а всё, что происходит внутри гостевой ОС, — это ваша зона ответственности. Под катом собрал десять базовых правил по безопасности VDS, но лучше всего они работают в связке. 

Многие энтузиасты разворачивают open source-инструменты у себя дома и экспериментируют с «домашним облаком», решая личные задачи.

Мы в Beeline Cloud подобрали примечательные материалы, которые помогут погрузиться в тему, познакомиться с кастомными сборками.

Помните ту историю про дом на песке? С хостингом та же логика.

Три года работы с клиентом. Контент идеальный. Ссылки качественные. Техническая оптимизация безупречная. Но сайт еле ползёт. TTFB — 2300 мс. Google Search Console кричит «Медленная загрузка страниц». Отказы — 72%. И вот Вы понимаете: всё дело в shared-хостинге за 199 рублей, где сервер отвечает как уставший госслужащий в пятницу вечером.

Переезд на VPS за 890 рублей. Месяц — и сайт в топ-5.

Google официально подтверждает: Core Web Vitals влияют на ранжирование с 2021 года (источник: Google Search Central). Это не «может повлиять». Это влияет. Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS) — все эти метрики завязаны на то, где и как работает Ваш сайт.

Google использует Core Web Vitals как фактор ранжирования для оценки пользовательского опыта, и сайты с хорошими показателями получают преимущество в поисковой выдаче.

TTFB в 200 миллисекунд или в 1500? Эта разница — пропасть. Для пользователя. Для Google. Для Вашего бизнеса.

Эта статья — для тех, кто запускает стартап, ведёт клиентские проекты или продвигает собственный бизнес. Мы разберём три типа хостинга без маркетинговой шелухи. С реальными цифрами российского и белорусского рынка. С кейсами. С рисками, о которых провайдеры предпочитают молчать.

Знаете, что бесит больше всего? Когда Вы делаете всё правильно с точки зрения контента, семантики, ссылочной массы — а сайт всё равно проваливается в выдаче. Открываете PageSpeed Insights, а там красные цифры LCP: 4.2 секунды. И вдруг понимаете: проблема не в вашем коде. Проблема в сервере, который думает три секунды, прежде чем отдать первый байт HTML.

С мая 2021 года Google официально включил Page Experience в факторы ранжирования, и это изменило правила игры. Теперь недостаточно просто написать хороший текст и собрать ссылки — нужно, чтобы сайт загружался за считанные секунды, иначе Google просто не покажет его в топе. Даже если контент идеален.

По данным исследований, увеличение времени загрузки с 1 до 10 секунд повышает bounce rate на 123%. Каждая секунда задержки — это минус 20-22% конверсии. Каждые 100 миллисекунд — минус 2.4% на десктопе и минус 7.1% на мобильных. Цифры жестокие, но реальные.

И вот что интересно: по моему опыту работы с несколькими десятками e-commerce проектов, в 60-70% случаев узким местом оказывается именно инфраструктура. Не JavaScript. Не картинки. А сервер, который медленно отвечает, или отсутствие кэширования, или shared hosting с перегруженными соседями.

Сегодня я расскажу, как инфраструктура влияет на Core Web Vitals, покажу реальные кейсы с цифрами и дам чек-лист для аудита. Без воды, только практика.

Когда технические сбои прерывают работу, Kasm Workspaces становится спасением, превращая устаревшие устройства в полноценные рабочие станции через браузер. В статье рассматривается, как платформа решает проблемы сломанных ноутбуков и дефицита оборудования, сравниваются версии (Community, Starter, Enterprise, Cloud), анализируются требования к ресурсам и результаты тестирования на VPS.

99.9% аптайма.

Три невинные цифры, которые хостинг‑компании размещают по всем своим маркетинговым материалам как знаки отличия. Звучит впечатляюще, не так ли? Почти идеальная надежность. Ваш сайт работает стабильно 999 минут из каждой 1000.

Но вот что они вам не говорят: 99.9% аптайма означает, что ваш сайт недоступен 8 часов 46 минут каждый год.

Если хотите проверить математику, таблицы доступности конвертируют 99.9% в ~8ч 46м/год, а 99.99% в ~52.6м. В 30-дневном месяце 99.9% допускает около 43м 49с простоя, в то время как 99.99% около 4м 23с.

Это целый рабочий день. Исчез. Клиенты видят страницы ошибок, продажи испаряются, email‑сообщения возвращаются обратно. Пока вы платите премиальные цены за «корпоративную надежность».

И становится хуже. Разница в 0.1% между 99.9% и 99.8% аптайма? Она представляет удвоение времени простоя с 8.77 часов до 17.53 часов в год. Тем не менее хостинг‑компании ценят эти тарифы так, будто разница незначительна.

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

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