Привет, Хабр! На связи команда «Гравитон». В этой небольшой статье мы собрали подборку практических приемов для эффективной работы с bash, которые помогут упростить интерактивное взаимодействие, а также повысить надежность и читаемость скриптов.
За почти десять лет, прошедших с момента выхода MySQL 5.7, в мире баз данных многое изменилось. Появились новые подходы к обработке данных, ужесточились требования к безопасности, и даже сам характер приложений стал совершенно иным. MySQL 8.0, увидевший свет в 2018 году, попытался ответить на все эти вызовы, привнеся не только новую функциональность, но и фундаментально иной подход к хранению и обработке данных.
Тем не менее, большое количество команд остаются верны MySQL 5.7, и на то есть веские причины. Для этой статьи мы в команде платформы данных Yandex Cloud постарались непредвзято посмотреть на производительность обеих версий и протестировать её на реальных нагрузках облачной платформы, а не в рамках стерильного тестового стенда. После прочтения вы сможете обоснованно решить, обновляться ли в ближайшем будущем, или точно понять, почему именно в вашем случаем этого делать не стоит.
Безопасная эксплуатация ноутбуков, или Защита пользовательского ключа с помощью алгоритмов ГОСТ Р 34.10-2012
В третьей части мы настроили защиту мастер-ключа с помощью USB-токена, используя RSA, но теперь мы перейдем на алгоритмы ГОСТ Р 34.10-2012. Жаркие. Зимние. Твои. А еще они основаны на более перспективных эллиптических кривых, которым не нужны такие большие ключи, чтобы обеспечить более высокий уровень безопасности.
У компаний, которые работают в облаке, каждый новый месяц начинается с сюрприза. Его преподносят счета, которые почему-то всегда оказываются процентов на 30-40 больше прогноза. И тут начинается. Финдир смотрит на тимлида. Тимлид — на команду. Команда — в логи. А в логах — тишина. Ничего же не меняли. Или меняли?
В прошлой статье мы собрали типовые сцены из жизни. Помните наших героев?
Добрый день! Меня зовут Роман Помазанов, я руковожу командой Global Network Fabric в MWS Cloud Platform. Сегодня я хочу рассказать о фундаменте, который обычно остаётся в тени, когда говорят об облачных платформах. Речь пойдёт не о виртуальных машинах, контейнерах или системах хранения, а о том, что заставляет всю эту сложную машинерию работать как единое целое, — о сети.
Если представить облако как живой организм, то сеть — это его кровеносная система. Это та самая инфраструктура, которая связывает вычислительные ресурсы, системы хранения, сервисы безопасности и подключает всё это к внешнему миру — к интернету. Без её бесперебойной и предсказуемой работы ни один сервис, ни одна виртуальная машина просто не смогут функционировать. Хотя я, конечно, лукавлю — функционировать-то сможет, но только диск будет в read-only режиме, он же сетевой :)
В этой статье я подробно расскажу об Underlay-сети — том самом физическом фундаменте нового облака MWS. Мы разберём, почему мы приняли стратегическое решение спроектировать её с чистого листа, отказавшись от следования традиционным, зачастую излишне сложным вендорским подходам. Поговорим о принципах, которые легли в основу архитектуры: простоте, отказоустойчивости и масштабируемости. И наконец, заглянем «под капот»: посмотрим на leaf-spine фабрику, на протоколы BGP и IPv6, которые стали её нервной системой, и на то, как мы управляем этой сложной распределённой системой с помощью автоматизации и мониторинга.
Этот материал — попытка объяснить сложные инженерные решения без излишнего упрощения, но и без «магии». Важно помнить, что надёжное облако начинается с правильно спроектированной сети. Ок, давайте начнём с самого главного вопроса: почему мы не стали копировать проверенную на практике сетевую архитектуру, а пошли своим путём?
Сегодня публикуем материал для тех, кого интересуют современные инструменты и протоколы управления ИТ-инфраструктурой. В своей статье по мотивам доклада с HighLoad++ 2025 технический руководитель компании «Прегель» Никита Австрийский рассказывает о том, как построить систему для управления тысячей серверов на базе протокола DMTF RedFish, как понять, чем неудобен его предшественник IPMI и как справиться с несовершенствами RedFish.
Вероятно, вы знаете, что если запустить ядро Linux без корневой файловой системы или файла initramfs, то оно упадет с сообщением о панике ядра.
Но возможна ли работа ядра Linux без этих, вроде бы обязательных компонентов? Ответ на вопрос — да, возможна, но использовать такие возможности в конечном продукте не стоит.
При запуске ядра ему могут передаваться параметры через командную строку. Одним из параметров является rootwait, указывающий ядру на то, что нужно подождать появление корневой файловой системы. В этом случае ядро ожидает появление корневой системы, а не завершается выполнение ядра с ошибкой.
Формально ничто не мешает написать модуль ядра, который взаимодействует с клавиатурой и дисплеем и временно выполняет функции пользовательского приложения, пока ядро ожидает корневую файловую систему.
Пользовательским приложением может быть, например, игра Тетрис. Она из-за своей простоты в реализации и зрелищности добавляет наглядности в изучении темы и дает чувство завершенности. А мысль о том, что тетрис, работает в ядре, усиливает эффект.
Привет, Хабр!
Обычно мы, ИТ-инженеры, что-то создаём: вводим в эксплуатацию системы, ставим новое железо, настраиваем ПО, добавляем память в серверы и диски в СХД.
Но иногда жизнь подкидывает прямо-таки противоположные задачи — и тогда бывает нужно аккуратно разобрать то, что строилось годами. Или разделить монолитную инфраструктуру на части так, чтобы бизнес даже не заметил этого хирургического вмешательства без анестезии.
Такие проекты требуют не только технической экспертизы, но и инженерного творчества.
И, что важнее, — человеческой выдержки. Потому что отключать то, что ты сам когда-то запускал и поддерживал, бывает эмоционально больно.
Эта история — про локализацию московского офиса крупного международного банка. Она будет особенно близка тем, кто уже участвовал в «разводе» инфраструктур. А тем, кому это только предстоит, — может сэкономить пару нервных клеток.
Глава 1. Постановка задачи
Однажды меня вызвали на разговор и поставили задачу: помочь ИТ-подразделению московского филиала международного финансового института отделиться от «материнской» компании.
Сразу стало понятно: проект будет сложным, а никаких приятных перспектив на горизонте не маячит. Но отказаться было нельзя — такие задачи не выбирают, они выбирают тебя.
NB: В подобных проектах решающую роль играют отношения между командами заказчика и исполнителя.
Я ожидал атмосферы тотального недоверия. Но ошибся — команда заказчика оказалась профессиональной и адекватной. Пользуясь случаем, ещё раз передаю им респект.
Формально задача выглядела просто: в нужный день рубим кабель, режем трафик на firewall — и всё, офис независим.
Есть типичная боль: ты вроде всё сделал правильно — контейнеры поднялись, API отвечает, UI открывается… а потом оказывается, что «не работает». Причём не «сломано в пепел», а именно «почти»: где‑то 404, где‑то таймаут, где‑то UI открывается, но вкладки пустые, где‑то один запрос проходит, другой — молчит.
И самое неприятное: когда начинаешь чинить «по ощущениям», можно потратить часы, а потом выяснить, что причина была не в коде, а в порте, origin, IPv6, миграциях или в том, что UI ходит не туда.
Я перестал спорить с реальностью и сделал себе простой подход evidence-first:
DNS — один из самых недооценённых компонентов инфраструктуры. Он есть везде, но по умолчанию почти всегда небезопасен: запросы ходят в открытом виде, легко подменяются, логируются провайдерами и могут использоваться для атак.
В этой статье покажу, как настроить безопасный и приватный DNS-резолвер на базе Unbound:
Технология коммутируемого доступа до сих пор вызывает чувство ностальгии — характерный звук модема сложно забыть. Но телекомы по всему миру продолжают отказываться от dial-up — и следом от сетей 3G. Процесс, который начался еще нулевых, набирает обороты. Обсудим ситуацию и поговорим о том, как идеи коммутируемой связи находят новую жизнь.
pgAdmin4 - де-факто стандартный GUI для PostgreSQL.
И при этом на Arch Linux его Desktop-версия годами находится в полурабочем состоянии.
Я разобрался, почему pgAdmin4 так плохо ложится на Arch, какие подходы стабильно ломаются,
и какой компромиссный, но реально рабочий вариант в итоге получился.
Если вам тоже надоело чинить pgAdmin после каждого обновления Python или Electron - это для вас.
В проекте часто бывает некий data-flow, который идет через ETL или даже отдельные серверы обогащения данных. Собственно и наш проект не исключение. Что было нужно? Данные из интернета летят в PostgreSQL, но только если в Redis не валяется хэш таких же. Далее несколько ETL проводит стандартный OLTP - OLAP преобразование и складывает все это в MongoDB — откуда клиент дергает эти данные и сравнивает их со своей PostgreSQL попутно складируя кэш в Redis. Все это периодически летает через RabbitMQ.
Что бесило? DBeaver + MongoExpress + redis‑cli все это в разных местах с разными учетками, экспресс постоянно падал по невыясненной причине, неправильный запрос в редиску подвисал, а затем улетал в космос. Мелькнула мысль: «ну почему никто не написал чего‑то более стабильного и удобного?», — собственно это и стало драйвером выходного дня.
Спасибо древним грекам, над названием долго думать не пришлось: Паноптикум — в оригинале «место откуда видно все», но также «сборище жутких и необычных артефактов».
Собственно дальше все очень просто, можно читать, можно искать, можно обновить отдельную запись (если DevOps разрешит) собственно это не production‑ready софт, а простой и надежный инструмент для QA и разрабов. Примитивная basic‑auth которую обязательно надо прятать под TLS и желательно за корп‑VPN, чтобы только свои могли запороть. Для прода и около можно сделать READ_ONLY — но тут каждый сам решает надо оно вообще ему или нет.
Наконец‑то можно проследить все преобразования данных и найти кто потерялся, можно открывать несколько вкладок, можно давать ссылку на конкретный объект. Ставится самым стандартным образом: берем образ — разворачиваем, ничего необычного.
Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.
Контейнеры давно стали стандартом современной разработки. Согласно отчету Docker State of Application Development 2025, они используются примерно в 92% IT-организаций и фактически стали универсальным способом упаковки и запуска приложений независимо от платформы и окружения. Это тот случай, когда инфраструктура перестает мешать и начинает экономить время.
Именно поэтому Digital Q.DataBase доступна, в том числе, в виде Docker-образа. Это позволяет за несколько минут попробовать Oracle- и MS SQL-совместимую СУБД на Windows, Linux и macOS, ограничившись несколькими командами, без сложной установки и длительного онбординга. Полноценная рабочая среда готова к использованию сразу после старта контейнера.
По сути, после того как вы скачали архив и подготовили директорию, для запуска Digital Q.DataBase достаточно четырех команд.
Ранее в статье я рассказывал про решение, которое позволяет обеспечить доступ к некоторым сайтам сети интернет, находящимся в зарубежном сегменте, доступ к которым был прекращен или ограничен.
Со времени публикации статьи, благодаря, в том числе, комментариям к статье, техническое решение получило развитие.
Дополнительно потребовалось:
Традиционный подход к диагностике производительности PostgreSQL зачастую опирается на эвристики, «типовые чек‑листы» и интуицию администратора. Администратор видит всплеск ожиданий, находит самый массовый тип события и принимает решение: «увеличить shared_buffers» или «выключить параллельные запросы». Такой метод работает в очевидных случаях, но оказывается бессилен, когда система находится в состоянии сложного баланса между разными механизмами, а первопричина торможения скрыта за вторичными эффектами.
Статистический подход, реализованный в методике pg_expecto, принципиально меняет логику расследования. Вместо субъективного выбора «самого громкого» типа ожиданий во главу угла ставятся количественные критерии, основанные на реальном поведении системы во времени.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL
Программист часто копирует и вставляет, переименовывает и рефакторит. Выделил (подсветил) мышкой переменную или функцию и вот бы сразу видеть их количество в статусной строке. Увы, стандартный поиск (Ctrl+F) требует лишние клики.
Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.
Много раз проскакивало желание у многих получить простой инструмент, позволяющий следить за истекающими сертификатами SSL. Ниже представляю инструмент для самостоятельного развертывания в среде docker.
Код написан для python14, но работать будет и на других версиях (12, 13, 14 и т.д.).
Что включает проект (все в одном):
Что такое двухфакторная аутентификация
Двухфакторная аутентификация (2FA) — это способ проверки подлинности пользователя, при котором для входа в систему требуется не только пароль, но и дополнительное подтверждение. Таким образом, личность пользователя подтверждается сразу по двум независимым факторам.
Необходимость 2FA возникла из-за уязвимости паролей. Их могут подобрать, перехватить с помощью фишинга или получить из утёкших баз данных. Даже сложный пароль не гарантирует безопасности при компрометации.
Использование двухфакторной аутентификации значительно снижает риск несанкционированного доступа. Даже если пароль стал известен злоумышленнику, без второго фактора вход в систему остаётся невозможным.
Из чего состоят два фактора аутентификации
Двухфакторная аутентификация опирается на использование двух различных категорий факторов, каждая из которых подтверждает личность пользователя по разному принципу. Классически выделяют три типа факторов.
Первый тип — фактор знания. Это информация, которую знает только пользователь, например пароль, PIN-код или ответ на секретный вопрос.
Второй тип — фактор владения. Он подтверждает, что у пользователя есть физический или цифровой объект: смартфон с приложением-аутентификатором, SIM-карта для получения SMS, аппаратный токен или USB-ключ безопасности.
Третий тип — биометрический фактор. К нему относятся уникальные характеристики человека, такие как отпечаток пальца, распознавание лица или радужки глаза.
Двухфакторная аутентификация использует комбинацию факторов из разных категорий, что делает подмену личности существенно сложнее.