Привет, Хабр! Расскажу, как мы спасли крупный новостной сайт ugra-news.ru от постоянных падений — без покупки нового железа и переписывания с нуля. Только точечные оптимизации, знание архитектуры Битрикс и немного детективной работы. Приступим.
Однажды вечером, листая объявления на самом известном сайте, я наткнулся на курс по DevOps за слишком скромную стоимость. Я подумал, что, наверное, это будет сборник ссылок на YouTube и мотивирующих цитат. Но нет. По описанию оказалось, что автор предлагает своего рода методичку — как с нуля вкатиться.
Отзывов на профиле нифига, решил от скуки написать автору. На первый взгляд всё оказалось прозрачно. Он расписал пример того, как устроен один из блоков. Подумал немного и получил заветный PDF-файлик.
Представьте себе классический кошмар системного администратора или SRE: три часа ночи, в управлении огромный кластер Greenplum на сотню сегмент-хостов, и вам нужно запустить тяжелый ETL-процесс или проверить доступность gpfdist строго одновременно на всех узлах.
Вы начинаете перебирать инструменты. Стандартный Cron? Он локальный, замучаешься синхронизировать конфиги. Ansible или SaltStack? Хороши, но требуют центрального «мастера» и стабильного SSH-соединения в момент старта. А если в дата-центре «моргнула» сеть и часть сегментов оказалась изолирована? Команда просто не дойдет.
Я решил, что миру нужен инструмент, который ведет себя как «умный почтовый ящик»: вы закидываете в него зашифрованную команду, а она сама расползается по всей сети и ждет своего часа, чтобы «выстрелить» точно в срок. Так появилась Gorgona.
В этой статье я расскажу о тернистом пути создания распределенной системы на чистом C, о том, как я боролся с «сетевым эхо» и почему это решение заставляет админов больших баз данных спать спокойнее.
В предыдущей статье я рассказал о том с какими проблемами столкнулся при создании своего решения для управления прокси. Как я понял из комментариев, прокси довольно быстро отлетали не только из-за того что я что-то не так делал, но в том числе из-за проблем телеги. Но РКН не стоит на месте и появилась новая проблема - на горизонте показался лимит в 15Гб зарубежного трафика. Как я понял, по слухам в начале он будет распространяться на мобильный интернет, так что я сразу решил добавить в свою панель возможность создания цепочки подключений.
Когда ваше приложение состоит из нескольких сервисов, например бэкенда, БД и кэша, невольно возникает вопрос — а как гарантировать, что они запустятся в правильно порядке и вообще увидят друг друга? В Docker это решается с помощью depends_on, тут ничего нового. А вот в Podman подход немного другой. Ну кто бы сомневался!
Привет! Меня зовут Данил, я разрабатываю прикладное ПО для радиочастотных систем YADRO. В этой статье я расскажу об одном из вариантов сбора данных AXI-Stream для обработки на CPU, рассмотрю в этом контексте возможности и требования блока AXI DMA, а напоследок порассуждаю о когерентности кешей и о том, что на самом деле здесь требуется от драйвера ядра.
В последнее время мне захотелось вернуться к проекту игровой консоли. Правда, он забуксовал, но ничего страшного: это долгоиграющий проект, и буду его разбирать по чуть-чуть. А вернулся к нему всё потому, что захотелось программировать. Потом я стал размышлять, что необязательно делать свою консоль — можно достать готовую. И везде я слышал упоминания про ретро-консоли, а у меня такой не было! Выбрал для себя Anbernic RG35XX Pro и заказал.
В этой статье будет небольшой обзор и впечатления от этой приставки. Но больше всего меня интересовал вопрос: допустим, я разрабатываю игры — могу ли я использовать ретро-консоль для моих нужд? Как легко запустить мою игру на ней? Может быть, игровые движки поддерживают опцию экспорта для таких консолей? И похожие вопросы — в основном из-за непонимания того, как это происходит.
Всё будет рассмотрено на примере PortMaster и написания Hello World на C/C++ (SDL2, SDL3, raylib), но также поговорим про Unity, Godot и HTML5 (Phaser).
«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы.
Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл.
Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование.
Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер.
Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку.
Мы пройдем путь от бинарных логов AIX до journald, а в конце разберемся, как практически использовать journalctl с популярными инфраструктурными службами.
В инфраструктурных проектах цена ошибки может измеряться миллионами и репутацией компании. Но практика показывает: поиск виноватых редко помогает избежать повторения проблем, гораздо эффективнее работает культура постмортем-разборов — честный анализ инцидентов без наказаний, который превращает ошибки в системные улучшения.
В инфраструктурных проектах цена ошибки редко бывает символической. Это может быть простой систем, финансовые потери, штрафы, иногда репутационные риски для клиента и подрядчика. В такой среде логично ожидать жесткой культуры поиска виноватых. Но практика показывает обратное: чем сложнее технологическая среда, тем бесполезнее модель «найти виновного и наказать». Она не снижает количество ошибок. Иногда она даже увеличивает их. За годы работы в инфраструктурных проектах я убедился, что единственный способ реально повышать качество, это культура разбора ошибок без наказаний. В инженерной среде это часто называют постмортем.
Почему поиск виноватых не работает
В ИТ есть старая поговорка: «Быстро поднятое не считается упавшим». Почти каждый инженер слышал её ещё в начале карьеры. В этой фразе есть важный инженерный принцип: в момент инцидента главная задача — не выяснять, кто виноват, а максимально быстро восстановить систему.
Когда что-то падает, инфраструктура, сервис или интеграция, время становится главным фактором. Клиенту не важно, кто допустил ошибку, ему важно, чтобы система снова работала. Поэтому в инженерных командах почти инстинктивно действует правило: сначала поднимаем систему, потом разбираемся.
Я решил погрузиться в мир собственных VPN серверов, после того как очередной раз сервис, за который я платил деньги перестал качественно работать, а поддержка из-за перегруженности отвечала шаблонами, в духе "Надо подождать, мы скоро все починим".
Набрав в поиске "VDS в Германии аренда" я с удивлением обнаружил, что арендовать такой сервер можно с российской карты и за вполне вменяемые деньги. Арендовав сервер на неделю, я принялся поднимать собственный MTProto для телеги. Использовал я образ https://github.com/telemt/telemt
Я поднял свой контейнер с прокси, проверил, что все работает и обрадовался. Но сразу же встал следующий вопрос - CLI это хорошо, но хотелось бы какой-то GUI для управления прокси. Я перепробовал несколько панелей и остановился на https://github.com/MaksimTMB/mtg-adminpanel. её суть в том, что панель можно установить на любой сервер или вообще локально, а на сервер, где будет развернут прокси ставится агент, который будет выполнять команды панели. Такое решение мне понравилось, так как в будущем можно будет расширить сеть до нескольких узлов, во избежание тотальной блокировки.
Использовали Cloud DNS, всё работало штатно.
В марте 2026 года мы столкнулись с неприятной ситуацией: в облачном DNS, который использовался для одной из наших публичных зон, начался резкий всплеск публичных авторитетных DNS‑запросов, причём основную массу составляли ответы NXDOMAIN.
На практике это привело сразу к двум проблемам:
В сети достаточно информации о настройке аутентификации 1С при публикации базы на веб‑сервере.
Наиболее полная из найденных расположена по адресу https://infostart.ru/1c/articles/2440678
Информация в комментариях к статье достойна ознакомления.
Однако для сценария когда:
Введение: Наткнулся на Reddit на крик о помощи: пользователь описывал странную схему «обучения трейдингу»,
Когда мы запускаем контейнер, в большинстве случаев предварительно нужно указать настройки: порт, пароль, режим работы, адрес базы и т. д. Зачастую такие параметры жестко прописывают в самом коде, но это плохой стиль и вообще идея так себе. В будущем вы можете «затроить» и все это слить в git-репозиторий. А как мы знаем, хранить чувствительные данные в там нельзя.
Удобнее и гибче использовать переменные окружения. Те самые, которые environment variables. С помощью переменных можно настраивать поведение контейнера, использовать разные конфигурации (dev/stage/prod), безопасно передавать чувствительные данные. Как видите, одни плюсы.
Работа с переменными в Podman строится практически так же, как в Docker. Есть некоторые нюансы, но о них расскажу чуть позже. Сейчас давайте потыкаем на практике и посмотрим, что же происходит.
Stratum 1 NTP-сервер на Raspberry Pi в 2025 году: DCF77 + GPS/PPS, chrony, libgpiod v2, когда все туториалы по «точному времени на Raspberry Pi» сломаны на современных системах. Разбираю почему — и показываю как сделать правильно.
Я не собирался делать этот проект.
Просто однажды сломал систему — и понял, что rollback на ext4 не такая простая вещь, как кажется.
В итоге собрал своё решение на rsync: быстрый и предсказуемый откат без смены файловой системы.
Кода тут минимум — он на GitHub. В статье — про сам подход: проблему, попытки решения и итог.
Сегодня я займусь совершенно неизведанной и, как мне кажется, мало изученной многими линуксоидами темой — сборкой Tauri-приложения под Windows. Почему мало изученной? Потому что я практически не программировал под эту систему и тем более никогда не собирал .exe-приложение под неё.
Я знаю лишь то, что Tauri поддерживает сборку приложений под Windows, поэтому это не должно стать серьёзной проблемой.
Также в предыдущей статье не поместилось добавление рецепта PKGBUILD в AUR, поэтому я включу его в эту статью.
Заваривайте чай, доставайте вкусняшки — пора «снимать урожай помидоров сорта Windows и выставлять на "витрину" сорт Arch»! 🍅
С 1947 года, когда появилась первая память с произвольным доступом — трубка Уильямса, — базовый принцип хранения данных в оперативной памяти фундаментально почти не изменился. За это время процессоры стали на порядки быстрее, но по-прежнему значительную часть времени они тратят на ожидание данных. Этот разрыв известен как «стена памяти» (Memory Wall), и именно он всё сильнее влияет на экономику современной инфраструктуры. Достаточно посмотреть, какую долю в стоимости сервера сегодня занимает RAM.
Мы покупаем терабайты памяти, но существенная её часть нередко остаётся «холодной»: ресурсы зарезервированы, потребляют энергию и стоят дорого, но используются далеко не полностью. В эпоху дефицита памяти, in-memory-приложений, искусственного интеллекта и других высоконагруженных систем такая неэффективность обходится слишком дорого.
А что, если эффективный объём доступной памяти можно заметно увеличить за считаные минуты — без замены оборудования?
В этой статье я коротко пройду по истории RAM, объясню, почему проблема Memory Wall стала особенно острой именно сейчас, и покажу, к какой новой вехе может привести подход, который условно можно назвать Software-Defined Memory. Разберем, как технологии MEXT используют AI для оптимизации инфраструктуры под AI- и data-intensive-нагрузки.
Спойлер: иногда, чтобы «увеличить» память, не нужно покупать новую — достаточно радикально лучше использовать ту, что уже установлена.
Попробуем переделать старый ADSL роутер в принт-сервер, который позволит подключить не менее старый принтер Samsung SCX-3200 в локальную сеть
Привет, Хабр! На связи Александр Усов, системный инженер в K2Tex. В своей предыдущей статье я уже делал подробный обзор фич ALD Pro и их особенностей, с которыми регулярно сталкиваюсь. Сегодня хочу поделиться тем, чему мы учим администраторов заказчиков: как реально эксплуатировать эту систему, а не просто развернуть и оставить на холостом ходу. Разберу, как устроены «расширенные атрибуты» и почему следует избегать одинаковых названий отделов в оргструктуре, какую функциональность ALD Pro унаследовал от FreeIPA, а в чем превзошел, и каким образом эффективнее организовать журналирование событий.
