Администрирование

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

Обычно мы, ИТ-инженеры, что-то создаём: вводим в эксплуатацию системы, ставим новое железо, настраиваем ПО, добавляем память в серверы и диски в СХД.
Но иногда жизнь подкидывает прямо-таки противоположные задачи — и тогда бывает нужно аккуратно разобрать то, что строилось годами. Или разделить монолитную инфраструктуру на части так, чтобы бизнес даже не заметил этого хирургического вмешательства без анестезии.

Такие проекты требуют не только технической экспертизы, но и инженерного творчества.
И, что важнее, — человеческой выдержки. Потому что отключать то, что ты сам когда-то запускал и поддерживал, бывает эмоционально больно.

Эта история — про локализацию московского офиса крупного международного банка. Она будет особенно близка тем, кто уже участвовал в «разводе» инфраструктур. А тем, кому это только предстоит, — может сэкономить пару нервных клеток.

Глава 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

Глоссарий терминов | Postgres DBA | Дзен

Программист часто копирует и вставляет, переименовывает и рефакторит. Выделил (подсветил) мышкой переменную или функцию и вот бы сразу видеть их количество в статусной строке. Увы, стандартный поиск (Ctrl+F) требует лишние клики.

Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.

Много раз проскакивало желание у многих получить простой инструмент, позволяющий следить за истекающими сертификатами SSL. Ниже представляю инструмент для самостоятельного развертывания в среде docker.

Код написан для python14, но работать будет и на других версиях (12, 13, 14 и т.д.).

Что включает проект (все в одном):

Что такое двухфакторная аутентификация

Двухфакторная аутентификация (2FA) — это способ проверки подлинности пользователя, при котором для входа в систему требуется не только пароль, но и дополнительное подтверждение. Таким образом, личность пользователя подтверждается сразу по двум независимым факторам.

Необходимость 2FA возникла из-за уязвимости паролей. Их могут подобрать, перехватить с помощью фишинга или получить из утёкших баз данных. Даже сложный пароль не гарантирует безопасности при компрометации.

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

Из чего состоят два фактора аутентификации

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

Первый тип — фактор знания. Это информация, которую знает только пользователь, например пароль, PIN-код или ответ на секретный вопрос.

Второй тип — фактор владения. Он подтверждает, что у пользователя есть физический или цифровой объект: смартфон с приложением-аутентификатором, SIM-карта для получения SMS, аппаратный токен или USB-ключ безопасности.

Третий тип — биометрический фактор. К нему относятся уникальные характеристики человека, такие как отпечаток пальца, распознавание лица или радужки глаза.

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

Используете Emby в домашней сети, но не хотите покупать Emby Premier ради iOS-клиента? Разбираю простой и легальный способ пользоваться Emby на iPhone и iPad без подписки.

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

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

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

Переезд всегда застаёт врасплох. Врасплох застал и переезд на облако. Опыт подсказывал, что потребуется неделька, чтобы освоиться на VMware'вской платформе, но ничто так легко не недооценивается, как трудозатраты.

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

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

Cегодня мы поговорим об очередном этапе развития нашего продукта — о его эволюции и мутации.

В последний рабочий день декабря мы решили выпустить новую версию 2025H2 «Приём», преумножив шутку про релиз в пятницу. Главными обновлениями стали появление модуля «Ресурсно-сервисная модель (PCM)» и трансформации данных. Под катом рассказываем подробнее и делимся скриншотами.

TL;DR Раздаем «Графиню» и отвечаем на вопросы в TG-сообществе.

Полное руководство по развертыванию высокодоступного кластера Kubernetes 1.35 на Ubuntu 24.04

Эта подробная техническая статья представляет собой пошаговое руководство по созданию отказоустойчивого кластера Kubernetes версии 1.35 с использованием утилиты kubeadm. В руководстве рассматривается развертывание производственного кластера с тремя master-нодами и тремя worker-нодами, что обеспечивает высокую доступность и отказоустойчивость.

В статье исследуется процесс автоматизированной централизованной установки средств электронной подписи в доменной инфраструктуре с использованием платформы ALD Pro версии 3.0.0. Проанализированы и реализованы на практике различные сценарии развертывания программных продуктов КриптоАРМ ГОСТ, КриптоПро CSP и КриптоАРМ, посредством групповых политик и встроенных механизмов политик установки ПО. Исследование охватывает архитектурные и функциональные аспекты реализации, процедуры распространения и активации лицензий. Отмечены ограничения существующих подходов к централизованному распределению индивидуальных лицензий и предложены направления совершенствования процедур и архитектуры для повышения надежности, управляемости и предсказуемости эксплуатации в IT‑инфраструктурах.