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

Telegram: @pg_expecto

MAX: PG_EXPECTO

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL

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

Может ли ИИ заменить эксперта по PostgreSQL?

С учетом существующих точек зрения о потенциале полного замещения человека искусственным интеллектом в задачах оптимизации баз данных, в данном исследовании проведен анализ работы нейросетевой модели DeepSeek при оценке производительности СУБД PostgreSQL с применением статистического метода «majority vote» на выборках из пяти и одиннадцати независимых прогонов. Результаты подтверждают, что даже при эффективном выявлении закономерностей и диагностике узких мест с помощью ИИ, окончательная интерпретация выводов остается прерогативой специалиста, что позиционирует нейросеть не как замену эксперту, а как инструмент для фильтрации случайных ошибок и оптимизации рутинных процессов.

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

После блокировки Telegram в России потребовалась альтернатива для уведомлений из Zabbix. Разбираемся, как интегрировать отечественный мессенджер Max через Webhook, с какими проблемами столкнулся и как их решил.

VACUUM в PostgreSQL принято считать универсальным средством поддержания порядка: он очищает мёртвые кортежи, обновляет статистику и вроде бы держит базу «в форме». Но с индексами всё сложнее. В какой-то момент они начинают расти и деградировать так, что это уже влияет на планы запросов и поведение оптимизатора — при том, что формально всё обслуживается корректно.

Разберёмся, где именно возникает это расхождение между ожиданиями и реальностью и что на самом деле происходит внутри B-дерева.

Привет, я Александр Хренников, руководитель DevOps-юнита в KTS.

Нам тут, оказывается, 5 лет стукнуло. Точнее, нашему блогу на Хабре. Подарков мы не дождались, так что решили сами вручить их вам. Дарить будем футболки с нашим фирменным принтом — Котзиллой. Это как Годзилла, только кот.

Но подарок получат не все, а десять DevOps-инженеров, которые справятся с нашим испытанием быстрее остальных. Суть проста: мы даем вам тестовый стенд с кластером Kubernetes с ArgoCD и отдельный GitLab-сервер. В ArgoCD добавлено приложение — простой Nginx, обернутый в Helm-чарт. И оно не запускается. Надо запустить.

DevOps-челленджи мы проводим не впервые: уже были этот, этот и еще несколько до них. Опытные участники уже знают механику, а для новых энтузиастов я расскажу ниже, как все устроено.

Когда счет за облако приходит в конце месяца, а финдир молча передает вам распечатку с суммой на 40% больше прошлого месяца, это верный признак того, что проблемы начались и сами собой не решатся. Не будет такого, что сегодня перерасход есть, а завтра все вдруг придет в норму. Не придет. Данных со временем становится больше, пайплайны запускаются чаще, хранилище разрастается, а понимания куда уходят деньги из ниоткуда не появляется. И, чтобы навести порядок, используют практики DataOps и FinOps.

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

Привет, Habr!

Меня зовут Максим Юрченко, я руководитель группы DevOps-инженеров в Lenta tech («Группа Лента»). В статье я расскажу о том, как за последние четыре года менялась наша система логирования, какие решения мы принимали по ходу роста инфраструктуры и к какому результату в итоге пришли (спойлер — без подводных камней и граблей не обошлось).

Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Мы продолжаем погружение в глубины конфигурации /etc/config/wireless. В прошлой статье - Тонкая настройка Wi-Fi в OpenWrt — достигаем максимальной стабильности и покрытия мы подробно разобрали секцию wifi-device, которая отвечает за физическое радио — частоты, мощность, каналы. Но, как вы помните, в wireless-конфиге есть ещё один тип секций: wifi-iface. Именно они создают те самые виртуальные интерфейсы, которые позволяют реализовать: точки доступа, клиентские подключения, mesh-сети и даже сервисы мониторинг эфира.

Именно здесь задаётся имя сети (SSID), методы шифрования, правила доступа, изоляция клиентов и многое другое. Казалось бы, что тут сложного? Указал SSID, выбрал шифрование, ввёл пароль — и всё работает. Но и здесь есть свои «подводные грабли», мифы и возможности, о которых многие даже не догадываются.

В промышленной сети обрыв кабеля — это не локальная неприятность, а сбой, который может повлиять на весь технологический процесс. Поэтому здесь особенно важны отказоустойчивость и предсказуемое поведение сети при авариях. Media Redundancy Protocol решает эту задачу за счёт кольцевой топологии с контролируемым резервированием: в штатном режиме он предотвращает образование петли, а при сбое быстро восстанавливает связность. В статье разберём, как устроен MRP, какие роли выполняют устройства в кольце, как происходит переключение и какие ограничения нужно учитывать на практике.

Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.

С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).

В моменте идея развертывания дома почтового сервера может показаться излишеством, ведь вполне для отправки различного рода уведомлений можно использовать Telegram или любой другой мессенджер, а для переписок со своего домена почту можно завернуть на какой-нибудь почтовый сервис, предлагающий возможность использования своего домена бесплатно, например mail.ru. Однако с учетом последних телодвижений РКН в сторону блокировки Telegram и ограничение в 5 ящиков на mail.ru (а с недавнего времени и использование сторонних почтовых клиентов только на платных тарифах), вариант использования собственного почтового сервера кажется все более интересной альтернативой.

В прошедшие выходные меня посетило непреодолимое желание. Желание наконец повысить свой сисадминский скилл. И перестать расстраиваться при отправке фото, а тем более видео в наш любимый мессенжер. Чудесно, что эта реальность так мотивирует к саморазвитию.

Недавно на глаза попалась интересная статья про новый проект TeleMT. И я бы наверно не стал заморачиваться. И тоже настроил бы его за 5 минут. По шагам из статьи. Если бы не пара «но». Во‑первых, я болен хроническим неприятием засовывания докера где следует и где не следует. А во‑вторых — 443 порт на моем подопытном сервере уже занят предыдущим «экспериментом».

На нестандартный порт вешать второй «эксперимент» мне не хотелось. Покупать второй айпишник или хостинг — тем более. Требовалось сотворить чутка новой дичи магии. О результатах сего докладываю в этой статье. Вдруг кому‑то пригодится.

На Хабре нередко появляются статьи типа "я хотел настроить <черный ящик>, не углубляясь в доки подергал за рычаги и у меня всё получилось, сейчас я научу вас как надо". Не смотря на неэкспертный технический уровень они нередко вызывают интерес и бурные дискусии. Поэтому я решил вам рассказать про сисадмина Васю, который решил настроить себе двухзвенный VPN из подручных средств не выходя далеко за пределы Хабра.
UPD: добавил настрокий policy based routing, без nginx/network namespace

Интернет-радио никуда не исчезло, оно просто ушло в сеть. В этом руководстве показываем, как за 15 минут поднять собственную радиостанцию на VPS с AzuraCast: загрузить музыку, настроить эфир, подключить домен и получить API для интеграций.

Сейчас очень часто в вакансиях на ДевОпс ищут людей которые, понимают и могут в Helm чарт.

Как правило, собеседование это не просто экзамен знаю/не знаю - это еще и проверка на понимание принципов работы какой-то технологии, умение решать задачи.

Я решил поделиться с вами своим опытом и понял что тут как никогда пригодится метод понимания процессов через визуализацию. О принципах работы метода «Дворца памяти» можно прочитать тут же на Хабр.

Привет, Хабр! На связи Илья Мартысь из Рег.облака. Сегодня расскажу, как мы переезжали в новый московский дата-центр, почему именно DataHouse «Магистральный-1» и при чем здесь серверы с NVIDIA H200.

В девяностых CGI сделал интернет интерактивным, но чуть не убил его. Это не удивительно, ведь каждый клик пользователя порождал новый тяжеловесный процесс на сервере. Под катом разберу, из-за чего такой подход оказался бомбой замедленного действия, и почему именно технология FastCGI спасла веб от инфраструктурного коллапса.

Большинство руководств по MTProto прокси написаны под Linux. Но что если ваш сервер на Windows? В статье разберём полный цикл настройки приватного MTProto прокси с Fake TLS на Windows Server + Docker: выбор образа, подводные камни (BOM в конфиге, порт 443 и HTTP.sys, флаги которых нет в v2), изоляция на отдельном IP и PowerShell-скрипт для пересоздания прокси с новым секретом одной командой. Все грабли — собраны на практике.

Привет, друзья!

Сегодня поговорим о кластерном режиме в Pilot – линейке продуктов, на базе которых организуют совместную работу над строительными проектами, сборку и проверку BIM-моделей.

Кластерный режим Pilot обеспечивает отказоустойчивость и горизонтальное масштабирование её центрального компонента — Pilot-Server. Для хранения данных в кластере используется PostgreSQL, а для взаимодействия между узлами — Redis.

Примечание: На данный момент кластеризация доступна только для Pilot-Server. Pilot-BIM-Server и Pilot-Web-Server работают как отдельные сервисы без возможности горизонтального масштабирования.

Какие преимущества мы получаем по сравнению с подходом, где используется один компонент Pilot-Server?

1. Аппаратный сбой на сервере Pilot-Server. При падении машины, на которой расположен единственный экземпляр Pilot-Server, работа пользователей парализуется, никакие действия с системой в режиме онлайн невозможно совершить. При нескольких компонентах на разных серверах, в случае падения одного из них, мгновенно назначается новый активный узел из оставшихся рабочих. Для пользователей это будет кратковременный разрыв соединения, после которого они переподключатся к новому узлу.

2. Обновление ПО. При обновлении Pilot-Server с единственным экземпляром, пользователи не могут подключаться в этот момент. В кластерном режиме обновление можно произвести в режиме “Последовательного обновления”.

3. Рост нагрузки на Pilot-Server. Большое количество запросов к одному компоненту Pilot-Server может превысить пропускную способность одного сервера. В кластерном режиме за счёт нескольких узлов с Pilot-Server  нагрузка будет распределяться между ними через балансировщик.

Привет Хабр! Меня зовут Алексей и я Системный Администратор.

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