Строка из документации n8n про возобновление с места остановки читается как гарантия перезапуска с точки сбоя. Проверка привела в ветку форума 2021 года, где смысл настройки объясняют иначе, - и дальше ещё в пять вопросов к движку автоматизации перед необратимым шагом. Все ссылки и даты сверки (27 августа 2026 года) - в тексте.
Или как получить полный доступ к изнанке CPU через скремблирование DRAM — PSP, C6, микрокоду, среде SMM и всему остальному, что не попало на страницы спецификации.
Всё-таки не всегда &x == &x...
Через вмешательство в работу контроллера DRAM можно сделать так, что обращение по определённому адресу будет вести в любую нужную область памяти. skitter-creek-bath-salts изменяет нижние слои структуры памяти, перестраивая трансляцию физический адресов DRAM. Такой скрэмблинг раскрывает защищённые области памяти, в том числе изолированные зоны, которые не видит даже само ядро. Когда ломается трансляция памяти, следом рушатся построенные на ней механизмы безопасности, и мы получаем доступ буквально ко всему.
Компьютер начал тупить в середине дня. VS Code переставал отвечать, новые вкладки редактора не открывались по минуте, а лимит подписки на ИИ-ассистента сгорал к обеду вместо конца недели. Виноватым оказался не ассистент, а плагин, который ведёт для него память между сессиями.
В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин.
Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM — собственная система управления виртуализацией.
Когда приложение перестает справляться с растущей нагрузкой, появляется желание «залить» ресурсами виртуальную машину. Однако производительность не всегда упирается в количество vCPU или объем памяти, поэтому в этом случае увеличение конфигурации приведет лишь к росту затрат. Давайте разберемся, почему увеличение ресурсов виртуальной машины не помогает и всегда ли «соседи по виртуалке» влияют на работающее приложение.
В первой части был инструмент, который снимает схему Firebird и раскладывает её деревом файлов: один объект — один файл. Он отлично отвечает на вопрос «как эта процедура выглядит сейчас» и совершенно беспомощен в вопросе «кто её поменял в среду вечером». Дамп — это фотография, а нам нужен ещё и вахтенный журнал.
Вторая часть — про журнал. Про то, какие факты об изменении схемы имеет смысл хранить прямо в базе, чем за это платишь и где закопаны грабли, на которые я наступил, чтобы вы могли их обойти.
От HAProxy до VLESS+Reality: все грабли одного MTProto-прокси
Если вы когда-нибудь поднимали свой MTProto-прокси для Telegram и он у вас "работает, но как-то не очень" — эта статья для вас. Я прошёл путь от "просто добавить relay" до "переписать всю цепочку на VLESS+Reality с нуля", и по дороге собрал приличную коллекцию граблей. Расскажу всё по порядку, чтобы вам не пришлось наступать на те же.
Исходная ситуация
Была задача простая на первый взгляд: поднять MTProto проксю для Telegram на сервере в РФ. Причина стандартная — хочется, чтобы телега работала
Взял mtg (ghcr.io/9seconds/mtg:2 — отличная реализация MTProto-прокси с поддержкой fake-TLS), поднял на сервере — и оно не работает. Точнее, работает, но еле-еле: то подключается, то нет, на мобильном интернете почти всегда фейл.
Первая мысль, которая приходит в голову почти всем в такой ситуации: "провайдер блокирует адреса Telegram". И это отчасти правда — но, как выяснилось, правда не вся.
Первая попытка: спрятать Telegram за релеем
Логика была такая: раз провайдер режет соединения именно к IP Telegram, то уберу эти IP из виду. Арендую второй сервер за границей, туда ставлю настоящий mtg, а на RU-сервере — просто TCP-релей (HAProxy или голый iptables DNAT), который прозрачно перекидывает байты дальше.
Клиент → RU-сервер (HAProxy, чистый TCP passthrough) → Зарубежный сервер (mtg) → Telegram
Казалось бы, логично: сервер в РФ теперь физически ничего не знает про Telegram, он просто гоняет байты во внешний IP. Провайдер не должен видеть ничего подозрительного.
Сложная ИТ-инфраструктура неизбежно вызывает множество проблем: нужно обеспечивать её масштабируемость и работоспособность, сдерживать рост затрат на сопровождение и поддержку, повышать прозрачность использования инфраструктуры и работающего на ней ПО.
Привет, Хабр! Меня зовут Юрий Самойлов, я директор по продукту MWS B2B Store. Сегодня поговорим о том, как управлять сложными инфраструктурными и ИТ-ландшафтами в целом, обсудим проблемы стандартизации, упаковки и развёртывания ПО, а также вопросы контроля лицензий, в том числе уже приобретённых у разных вендоров. Кроме того, мы посмотрим, как эти задачи решаются в MWS.
За помощь в подготовке материала спасибо Евгению Тетенчуку, техлиду команды MWS B2B Store. Эта статья — текстовая версия вебинара.
Многие сервисы сегодня выдают клиенту не один конкретный конфиг для подключения, а VLESS/Trojan-подписку — ссылку, за которой стоит целый пул из десятков серверных конфигураций сразу. Провайдеру это удобно (не нужно вручную вести отдельный конфиг под каждого клиента), но у пользователя тут же встаёт главная практическая проблема: подключить роутер именно через такую подписку так, чтобы соединение работало стабильно. Один конкретный сервер из пула сегодня быстрый, завтра перегружен, послезавтра вообще не отвечает — а подписка в целом при этом продолжает исправно работать, просто нужно каждый раз заново находить, какой именно из десятков серверов сейчас реально живой.
Решает это балансировщик — механизм, который сам, постоянно, в фоне проверяет каждый сервер пула подписки и автоматически выбирает самый быстрый живой, без участия человека.
Об этом и статья: что такое точечная (доменная) маршрутизация на роутере, зачем нужна автоматическая балансировка между серверами одной VLESS/Trojan-подписки, и как это устроено в нашем универсальном проекте SmartRoute — для роутеров на OpenWrt и KeenticOS (через xkeen), который умеет и то, и другое из коробки.
restart-hook вернул 202, а сервис всё ещё не отвечает. Повторить запрос — рискнуть вторым перезапуском; закрыть инцидент — записать восстановление, которого не было. На этом конфликте построен recovery в Vigil: система проверяет сервис до и после действия, отсекает устаревшие задачи и останавливает автоматизацию, когда пора звать человека.
Когда я только пришел на должность помощника DBA, я заметил, что все production базы фиксируют изменения странным образом, а именно каждый день в 00:00 вызывался скрипт, который выгружает схему БД Firebird, в виде файла script.sql, созданный встроенной утилитой isql. Далее делил весь файл на объекты (файлы), по группам (директориям) принадлежности, объясняю: есть кусок скрипта создания таблицы, он помещается в директорию 01_TABLES в виде отдельного файла названного в честь названия объекта который он содержит, и так далее. Чем же это плохо? А суть в том что разработчиков много, правки анонимны, история тяжело воспроизводимая. В такой каше сразу не разберешься.
Изначально с Capabilities я лично столкнулся в своем проекте ServeHub-2, когда настраивал контейнеры в docker-compose. Если быть более конкретным, я настраивал WG-easy с использованием AmneziaWG, которому нужны были привилегии, связанные с загрузкой модулей ядра и настройками интерфейсов. До этого я слышал о Capabilities, но не знал что это такое, поэтому решил подробнее в этом разобраться.
Сначала разберу общее понятие, что вообще такое Capabilities (далее буду кратко писать CAP), потом постепенно перейду к примерам.
В конце статьи приведу дополнительные материалы, на которые я опирался при написании этой статьи, их также будет полезно почитать/посмотреть, если остались какие-то вопросы или если просто интересно разобрать тему грубже.
Начиная примерно с вечера 26 августа, на ТСПУ стали перехватывать DNS запросы к крупным DNS серверам CloudFlare и Google (1.1.1.1, 8.8.8.8), ранее блокировали DoH сервера от данных корпораций.
Результат DNS резолвинга выглядит следующим образом:
Про публичный Wi-Fi принято говорить одно из двух. Либо «там воруют пароли, не подключайтесь», либо «сейчас везде HTTPS, всё в порядке». Обе формулировки неточные, и обе мешают понимать, что происходит на самом деле.
Пароли при работающем HTTPS действительно не украдут — с этим всё в порядке. А вот список сайтов, куда вы ходите, виден любому, кто сидит на том же канале — владельцу точки доступа, провайдеру, соседу с ноутбуком, если сеть открытая. Причём видно его в открытом виде, никакого взлома для этого не требуется.
Вокруг macOS сложилась, пожалуй, уникальная для корпоративного мира экосистема бесплатных админских инструментов. Сообщество MacAdmins (Slack на десятки тысяч участников, конференции JNUC и MacAdmins PSU) годами создаёт и поддерживает утилиты, которые закрывают пробелы между тем, что даёт Apple «из коробки», и тем, что действительно нужно администратору. Причём многие из этих инструментов написаны инженерами Jamf, SAP и других крупных компаний и выложены в opensource.
В этой статье мы собрали 12 утилит, которые чаще всего встречаются в арсенале администраторов macOS. Почти все они бесплатны и с открытым исходным кодом, работают независимо от того, каким MDM вы пользуетесь, и решают конкретные задачи: от выдачи TCC-разрешений до принуждения пользователей к обновлениям.
31 июля 2026 года Паван Давулури, который отвечает в Microsoft за Windows и устройства, отчитался о работе над системой и назвал несколько направлений работы на остаток 2026 года. Звучит как обычное корпоративное обещание, которых с весны набралось достаточно. Но в разделе про память он назвал три конкретных технических рычага, а в них видно признание того, что тормоза на восьми гигабайтах — это не проблема пользователя, который пожадничал на планке. Просто так устроена сама Windows.
За первое полугодие 2026 года мы проанализировали 7,79 млн SQL-запросов с нескольких тысяч серверов. В статье описали распределение по семействам СУБД и major-версиям.
Файл /dev/null есть в каждой Linux-системе. Он весит ноль байт, но именно туда ежедневно сливаются терабайты ненужного вывода, а если его удалить, то вовсе падут cron, ssh и половина ваших bash-скриптов. Под катом расскажу, откуда взялась эта «чёрная дыра», почему это не обычный файл, а псевдоустройство, и что на нём завязано.
Разбираем 22 альфа-фичи Kubernetes 1.37. Спойлер самого крутого и долгожданного:
- Больше не нужно с нуля перезапускать приложения после каждого сбоя — появились снапшоты подов.
- «Костыли» для планирования сложных нагрузок в прошлом — K8s научился работать с иерархией групп подов.
- Проблемы с хранилищем можно отловить сразу, а не когда приложение упадёт с ошибкой — теперь K8s мониторит здоровье PV.
Подробнее об этих и других фичах с примерами — читайте в статье.
В последнее время всё чаще прилетают вопросы и просьбы о консультации после самых разных инцидентов: кого‑то зашифровали, где‑то поломали инфраструктуру, где‑то увели корпоративную почту или получили доступ к учёткам.
Ниже — не попытка рассказать опытным администраторам или DevOps, как им делать свою работу. В зрелых с точки зрения ИБ компаниях такие ситуации обычно уже разобраны в процедурах реагирования, а у команд есть понимание, кто и что делает в первые минуты и часы инцидента.
Но довольно часто с серьёзным инцидентом компания сталкивается впервые. И вот там начинается самое сложное: всё лежит, бизнес нервничает, информации мало, а делать что‑то надо прямо сейчас.
В такой момент очень легко начать действовать слишком активно: перезагрузить сервер, удалить подозрительный файл, почистить логи, начать восстановление из бэкапа — и тем самым случайно усложнить дальнейший разбор ситуации.
Поэтому ниже — семь базовых правил о том, что стоит сделать и чего, наоборот, лучше не делать в момент инцидента, пока ситуация ещё не локализована, не определён дальнейший план действий и не понятно, кто именно будет заниматься разбором последствий и восстановлением.
Это именно база. Для кого‑то очевидная, для кого‑то уже давно формализованная во внутренних процедурах. Но если организация столкнулась с таким впервые, эти несколько действий могут сильно повлиять на то, сколько информации удастся сохранить и насколько быстро потом получится разобраться в произошедшем.