Есть у меня два хостинга у разных провайдеров. И один сервер по сценарию стучится в другой для определенных операций. Всё работало прекрасно, но вдруг (как обычно) перестало. Проверяю руками коннект прямо из терминала одного сервера (Linux) - другой недоступен, таймаут соединения. Проверяю с других виртуалок, со всех доступно, с этой нет. Пишу в поддержку обоих хостингов: так, мол и так, работало, а теперь сломалось, на чьей стороне проблема и как починить? Привожу логи проверок, там видно - таймаут. Отвечает мне хостер, чей сервер исходящий: "А вы пробовали для теста подключиться через другого интернет провайдера?" Отвечает мне хостер, чей сервер недоступен: "Поставьте программу для Windows и пришлите нам ее результат работы". Такого подвоха от тех. поддержки хостеров я не ожидал. Чего вот мне с ними делать теперь? 😳 #life

Самые неприятные баги — это те, из-за которых система работает, потом не работает, а через пять минут снова работает, будто ничего не произошло. 😬 Именно такой баг жил на YHub целый месяц. Сегодня я наконец нашёл его причину, но сначала дам немного контекста. Уже месяц на YHub можно создавать собственные базы данных.

То есть если вы написали какое-то фронтенд-приложение и вам нужна база, то вместо того чтобы прикручивать сложные сторонние сервисы или пытаться хранить всё в Local Storage, вы можете прямо в админке своего сайта включить базу данных, создать необходимые таблицы и получить полноценный API для работы с ними.

Плюс можно создать таблицы, необходимые для аутентификации пользователей, и получить весь нужный функционал для регистрации, авторизации и так далее. 👌 В целом всё это работает хорошо. Я сам построил на этом несколько сайтов, моя игра тоже использует эту базу данных, а жена сделала несколько приложений, которые так или иначе с ней работают. 🤔 И вот как раз жена первой начала мне репортить, что иногда у неё просто пропадает таблица с рейтингом. Но после перезагрузки всё снова появляется и данные приходят. На тот момент я счёл этот баг не очень интересным. 🤷‍♂️ Подумал, что, может быть, произошла какая-то сетевая задержка или что-то было не так в её клиентском JavaScript. Я спросил: — Сейчас работает? Она сказала: — Сейчас работает. И мы такие: — Ну, работает — не трожь. Значит, всё хорошо. 👀 Но относительно недавно я прикрутил полноценный мониторинг ко всем функциям YHub. Раньше я мониторил только сам YHub и его основные модули: работает ли приложение, отвечает ли сервер. А теперь начал дополнительно проверять отдельные фичи, чтобы убедиться, что они тоже работают и ничего не отвалилось. И вот мониторинг начал ловить нестабильные ошибки. Условно, сначала он получает 200 OK: всё хорошо, база работает, данные записываются. ✅ Через пять минут приходит 404, будто база данных вообще не включена. ❌ А ещё через пять минут снова 200 OK, и всё опять прекрасно работает. ✅ Такое поведение — когда что-то работает, через пять минут не работает, а потом снова работает — это, наверное, самое неприятное, что может произойти при отладке. 😩 Баг не воспроизводится стабильно, поэтому непонятно, за что вообще цепляться. Но, вооружившись Codex, своими наблюдениями и несколькими теориями, я пошёл дебажить архитектуру и нашёл очень интересный момент. 🤔 На моём хостинге используется PHP Runtime. Чтобы всё это было безопасно, я изолирую сайты на уровне операционной системы. Для каждого окружения создаётся отдельный PHP-FPM-пул, который работает внутри собственного chroot. Благодаря этому процессы разных пользователей не должны видеть файлы друг друга. 😬 Но, когда я настраивал эту изоляцию, я пропустил одну важную настройку в OPcache. OPcache хранит в общей памяти уже скомпилированный байткод PHP-скриптов, чтобы не разбирать и не компилировать их заново при каждом запросе. Проблема была в том, что внутри каждого изолированного окружения сгенерированный API-скрипт находился по одному и тому же пути. А настройка opcache.validate_root, которая заставляет OPcache учитывать конкретный chroot, у меня была выключена. 🤦‍♂️ В результате для OPcache скрипты разных пользователей могли выглядеть как один и тот же файл. OPcache мог взять скомпилированный скрипт из одного окружения и использовать его при запросе к другому. 🤷‍♂️ В какой-то момент в кэше оказывалась скомпилированная версия скрипта сайта, на котором база была отключена. Поэтому мой сайт внезапно получал 404, хотя у него самого всё было включено и настроено. 💡 Это интересный пример того, как кэширование становится источником проблем в разработке. Кэширование — это, конечно, хорошо. Я не говорю, что его нужно избегать. Оно ускоряет работу системы и часто действительно необходимо. Но кэшировать тоже нужно с умом. В моём случае я просто забыл указать в настройках, что кэширование должно учитывать chroot пользователя, и получил вот такую интересную проблему. Причём именно мониторинг помог мне с ней разобраться. У меня были конкретные даты и время, когда всё работало, а когда отваливалось. Без мониторинга я вообще не представляю, как бы это отдебажил. 😅 Но теперь всё исправлено. После изменения настройки ошибка больше не повторялась, а мониторинг снова стабильно зелёный. 💪 Свята место | 10МДК | ВЕБМастер | YHub

Как российские хостинги знатно штормило в мае-июне, и почему некоторые теперь не пишут на Хабре Четверг, 11 июня, утро. У хостинга резко пропадает аптайм на части казанского оборудования. Первая мысль про дурацкую неполадку сети, звонок оператору, тот отвечает, что в ЦОДе просто техработы. На самом деле в гермозоне сидела большая опергруппа, запретившая связь с внешним миром до конца выемки данных. Забрали всё подчистую, физически, из-за одного-единственного клиента, который держал VPN-сервер. Дальше начинается то, о чём хостеры предпочитают молчать. Серверы не выключили с кнопки, а выдернули из розеток, а RAID-массив на резком обесточивании теряет структуру дисков. Железо в итоге вернули. Два сервера не запустились. Выясним, как хостинг вытаскивал клиентов, когда физику уже не обмануть.

Вам, фанаты Lovable, Vercel и прочих конструкторов сайтов, аппов и ботов под ключ, с использованием ИИ и, самое главное, с встроенным хостингом проектов. Только что разбирал кейс подруги, которая запустила лендинг через лавабл, а он у людей не открывается. бОльшая часть не отсекает, или отсекает не сразу, что подавляющее большинство модных облачных сервисов для создания всего, либо защищены Cloudflare, либо хостятся в OVH/Digital Ocean/Hetzner и других облачных провайдерах, существенная часть из которых в РФ заблокированы давным давно. Lovable тут идеальный пример. К нему еще и свой хостинг не прикрутить, только домен (а это никак не повлияет на доступность), и по сути единственный вариант — сделать экспорт кода, развернуть у себя и забыть про использование их конструктора. Недоступность ваших вайб-кодерских ресурсов в РФ может составлять до 60-80%. С ВПН еще можно зайти, а без него — никак. И люди даже не знают, что дело в нем — нет такой привычки, проверять, ни у кого, кроме совсем поехавших гиков. Так что для РФ только собственный хостинг, никаких западных облачных платформ, или отдельный сервер под РФ и так далее. Ну, если не хотите терять до 80% аудитории.

Кстати, вот небольшой ИИ-рисерч по поводу цен на VDS и ИИ-компьют в РФ и "на Западе". Он быстрый и вот тут в табличке открыто — можно посмотреть самостоятельно. Я там даже комментарии открыл, но модерировать не буду. Лень. Общий вывод: уже сейчас, если не считать откровенно маркетинговые тарифы "минимальный вход" в РФ в два-три раза дороже по сопоставимых параметрах. Смотрите особенно на конфигурации с числом vCPU больше двух. И это без учета того, что в тот же Hetzner, например, "из коробки" входят всякие допуслуги, типа "20Тб трафика", "защиты от DDoS" и всякие бэкапы. По ИИ ситуация даже хуже - в РФ просто нет адекватного предложения. На втором листе смотрите