Представьте: Один неоптимизированный запрос от неопытного коллеги - и вот уже 40 ТБ SPILL-файлов парализуют систему.
Срабатывает лимит на уровне Greenplum, запрос завершён. Никто ничего не знает.
Создаются заявки, пишутся письма, пользователь недоволен.
Это не какая-то выдуманная история, а обычный будний день в большом Greenplum. Вернее, так было раньше.
Привет, Хабр! В этой статье хочу рассказать об основных модулях нашего приложения для развертывания больших инфраструктур и киберполигонов на основе Ansible. Эти модули мы называем A-services (сокращенно от Ansible services). Они содержат все сценарии подготовки, развертывания и настройки ИТ-инфраструктуры.
Общая архитектура приложения на основе Ansible описана в предыдущей статье. Здесь хочу поделиться особенностями архитектуры модулей А-services.
Сегодня расскажу историю о том, как мы еще в 2017 году решили поменять инфраструктурную платформу. Мы расшифровали мой доклад с DevOpsConf21, много всего уточнили, переписали и дополнили с учетом опыта следующих четырех лет, прошедших после того выступления.
8 лет назад у нас было 40 сред, 15 разработчиков, 2 монолита, 10 сервисов и свое железо в трех серверных стойках. С такими исходными данными мы решили перейти с Puppet на Ansible. Окружений много, потому что с 2010-го мы поставляли разработчикам и тестировщикам маленькие копии нашего приложения — это делало задачу еще интереснее.
Путь был непростой. О нем расскажу в хронологическом порядке, не забывая о косяках и ошибках. По ходу повествования я выделил инсайты, которые могли бы сильно помочь мне в прошлом. В конце оформил их в виде письма для себя образца 2017-го 🙂. А если вы решитесь проделать нечто столь же безумное (ну там, не знаю, переехать с микросервисов на монолит, с linux на windows и так далее), надеюсь, мои заметки уберегут вас от сложностей, с которыми мы столкнулись.
Всем привет, с вами снова Смирнов Илья. Напомню, что я архитектор решений из Cloud.ru. На этот раз предлагаю погрузиться в тему мультикластеров. Сначала разберем, зачем они нужны и когда целесообразны — для тех, кто только начинает изучать вопрос. Ну и, конечно, детально разберем «что там по технике» — посмотрим, как создать рабочую мультикластерную инфраструктуру для одновременного и унифицированного управления приложениями, на какие подводные камни можно наткнуться и как расчистить себе этот путь.
У нас 1С развёрнут на Linux и PostgreSQL. Всё началось с запроса клиента на развёртывание 1С в Linux-среде. Мы создали первый кластер, а затем перевели всю облачную 1С на open source.
В этой статье расскажем о нашем пути, сложностях и результатах. Больше подробностей об особенностях работы облачной 1С вы узнаете на вебинаре — запись эфира открыта по ссылке.
За последние два года ландшафт киберугроз изменился кардинально. Мы наблюдаем парадоксальную ситуацию: компании инвестируют в безопасность больше чем когда-либо, но количество успешных атак продолжает расти. Когда каждый день приносит новые угрозы, стандартного антивируса и фаервола недостаточно. Современная защита требует многоуровневого подхода — от сетевого периметра до систем виртуализации. Разберем ключевые технологии, которые должны быть в арсенале каждого сисадмина.
Сетевой уровень: NGFW и IDS как основа защиты
Next-Generation Firewall (NGFW) — это эволюция традиционных фаерволов. В отличие от предшественников, NGFW анализирует трафик на уровне приложений, а не только по портам и протоколам. Например, можно заблокировать передачу данных через мессенджеры или доступ к фишинговым сайтам, даже если они используют стандартные HTTPS-порты.
Системы обнаружения вторжений (IDS) дополняют NGFW, выявляя аномальную активность. Suricata в связке с SecurityOnion позволяет детектировать:
Команды разработки и DevOps начинают совместную работу с энтузиазма и взаимного уважения. Но со временем отношения превращаются в холодную войну. В ней нет победителей — только выгоревшие. Разработчики не понимают инфраструктуру, тестировщики хотят странного, безопасники закручивают гайки, DevOps окапываются в обороне, процессы тормозят работу, а CTO хватается за голову. Все стараются, но становится только хуже. Но есть способы это изменить и превратить конфликты в полезное сотрудничество.
DevOps-команды сегодня — это внутренние поставщики сервисов: от пайплайнов и окружений до документации и архитектурных решений. В этой статье поговорим о том, как выстроить эту работу так, чтобы было удобно и разработчикам, и самим девопсам. Как выйти из роли «пожарной команды», навести порядок в ожиданиях и инструментах, построить платформу и не сгореть.
Чтобы разобраться, где вообще рождаются платформенные практики и кто их использует, давайте посмотрим на разные типы компаний и что конкретно происходит на поле боя.
Рассказываю про еще одну коварную подлость, встроенную в современные технологии беспроводной связи — WiFi. Про это знают все приличные сетевые инженеры, но почему-то не рассказывают простым пользователям.
Мы с тобой, коллега — Системные Администраторы.
Не “инфраструктурные инженеры”, не “DevOps-практики”, не “cloud-специалисты”.
Просто — сисадмины.
Это звание не выдают по результатам онлайн-курсов и не прикрепляют в LinkedIn. Его зарабатывают в душных, перегретых серверных, где запах пыли вперемешку с озоном от ИБП становится запахом профессии. Где вместо open-space — кладовка с розеткой на три киловатта и проводами, похожими на гнездо безумного питона.
Наш путь — это не просто карьера. Это живая эволюция техники, прошедшая через наши руки и нервы: от скрежета SCSI-дисков и светящегося экрана CRT-монитора до кластеров Kubernetes, которые даже потрогать нельзя — всё спрятано в облаке.
Мы — свидетели и участники самой стремительной технологической трансформации последних двадцати пяти лет. Когда-то мы тянули первые «витухи» по потолкам советских зданий, пробивая стены перфоратором, потому что «завтра сдавать сеть в бухгалтерии».
Теперь мы нажимаем пару клавиш в Terraform и поднимаем целые дата-центры. А ведь тогда облаком мы называли сигаретный дым в серверной после ночного релиза.
Мы знаем, что такое физическая боль — тащить 4U сервер без тележки, спотыкаясь о кабель-канал, потому что «сейчас, только вот этот один, и домой». И что такое ментальная боль — когда забыл поставить setlocal enabledelayedexpansion, и кривой .bat-файл превратил NT-домен в цифровой ад.
Наш возраст измеряется не годами, а версиями операционных систем.
Мы взрослели вместе с Windows NT 4.0, Windows 2000, XP, Server 2003… потом 2008, 2012, 2016… А где-то между ними — Slackware, Debian Potato и FreeBSD 4.10, которые учили нас терпению, вниманию и вере в консоль.
Попробуйте как-нибудь чисто из спортивного интереса объяснить жене, почему в прошлом месяце ваш интернет стоил не 900 рублей, как обычно, а 90 000. Аттракцион, прямо скажем, диковатый, но примерно в таком же положении оказывается ваш ИТ-дир, когда видит счета от всех облачных сервисов одновременно. Что не так? Да примерно все. Каждый провайдер считает по своим правилам, выставляет счет в собственном формате, из-за чего объяснить, за что именно платим, оказывается просто супер-сложно. Но ведь не будешь складывать все яйца в одну корзину. Значит, нужно решать этот вопрос как-то по-другому.
Запускаем на ноутбуке учебный кластер ClickHouse — шардированный (sharding) и реплицируемый (replication) — на Docker Compose.
Это не один сервер в контейнере, а стенд из 2 шардов × 2 реплики, с координацией через ZooKeeper и балансировкой HAProxy — поднимается за несколько минут.
Зачем: на практике разобрать репликацию и распределение по шардам, увидеть базовую отказоустойчивость и спокойно экспериментировать — всё в контейнерах, всегда можно снести и развернуть заново.
Кому: новичкам, кто хочет «пощупать» кластер; тем, кто знает базовый синтаксис ClickHouse, но не пробовал шардирование/репликацию; тем, кто готовится к собеседованию или приценивается к архитектуре перед продом.
В комплекте — готовые конфиги и docker-compose.yml в репозитории; всё, что нужно, — Docker и несколько команд.
Главной темой и проблемой IT является, необходимость набора софта для осуществления тех или иных целей. Например - графический редактор, редактор/читалка документов, локальный DNS-сервер, система мониторинга, почтовый сервер или вовсе доменный контроллер - зачастую с этого всё и начинается. Всё это вероятнее всего, имеет закрытый код - проприетарный.
В дополнение, многие делают очень весёлую ошибку, пытаясь используя знания и/или специфичную терминологию NT-мира (Windows*) полноценно работать/судить в/о *nix среде. Естественно, ничего не получается, но некоторые особенно упёртые, пытаются заставить работать, например AD (Active Directory) в Linux. В итоге сохраняется базовая функциональность в лице пароль+логин+сертификаты/билеты и не более, потому что закрытый остров Windows, сильно отличается от открытого света.
Собственно, а почему так? А потому что “удобно”, "быстро", "красиво", "едино" и ещё сотня подобных слов, где будет оправдываться монополия Microsoft, а так же зависимости, проприетарность, закрытость и невозможности внесений изменений. Всё это и так же отсутствие стандартизации между проприетарными проектами (Не только в Microsoft), без установки дополнительного софта или даже костылей - не решается. Ну и ещё цена неадекватно большая была примерно... Всегда, за лицензию Windows и уж тем более серверного издания.
Собрал в одной статье весь практический опыт настройки засыпания этой системы на разных ноутбуках. Если хотите попробовать FreeBSD на ноутбуке — точно стоит прочитать.
29 сентября 2025 года Линус Торвальдс объявил о выходе ядра Linux 6.17. За два месяца работы 2 118 разработчиков внесли 14 334 патча. В общей сложности затронут 12 841 файл. В ядро добавлено 646 тысяч строк кода, удалено около 399 тысяч, а общий объем изменений составил 46 МБ.
Основной фокус релиза — драйверы (43% изменений), сетевой стек (14%), файловые системы (4%) и поддержка архитектур (10%). Собственно, все как всегда. Ну и обновление добавляет поддержку нового оборудования, оптимизацию производительности и исправления, которые делают систему стабильнее. В статье разберем, что нового в Linux 6.17, как улучшения повлияют на работу и почему этот релиз стоит вашего внимания.
Поиск собственных файлов как в браузере (Google поисковике).
Даже при аккуратной структуре папок и нейминге найти нужный файл часто было непросто. Рано или поздно все превращалось в большой хаос из набора файлов и папок.
Я пробовал программы по типу Everything, которые ищут по названию файла, пробовал obsidian и xyplorer, которые дают возможность добавлять теги, но хотелось простой возможности описать то, что ищешь, и получить результат - как в браузер поисковике. Затем я подумал - ведь все может быть контекстом...
Привет, постоянные и не очень читатели!
CXL (Compute Express Link) — свежий стандарт интерконнекта, появившийся в 2019 году. Его главная фича — новый подход для работы с памятью и вычислениями: поддержка когерентного кэша и трафика между процессорами и ускорителями, возможность собирать инфраструктуру как конструктор, гибко распределяя ресурсы, и другой функционал.
В этой статье я подробно расскажу про CXL (и при чём тут PCIe вообще). Кратко пройдёмся по истории этой технологии, посмотрим, что такое интерконнект, разберёмся, как и на чём CXL работает, на каком этапе развития находится и чего ждать в ближайшие годы.
Здесь будет всё, что вы хотели знать про CXL, но лень было искать, так что заваривайте чайничек листового — и приятного чтения! :)
Информационная безопасность, Разработка ПО, VirusTotal, Гайд, Reverse Engineering
![Иллюстрация: разработчик в отчаянии смотрит на монитор с вердиктом VirusTotal "15/71", а вокруг него летают красные значки тревоги]
Привет, Хабр!
Вы — разработчик. Вы ночами не спали, пили литры кофе, писали чистый и элегантный код. И вот, ваше детище — полезная утилита, инди-игра или хитрый скрипт для автоматизации — готово. Вы с гордостью выкладываете его на сайт, делитесь с друзьями, и тут... в чат прилетает сообщение: «Эй, а твой экзешник — троян! VirusTotal ругается».
Знакомая боль? Если вы пишете под Windows, особенно на языках вроде AutoIt, Python (с PyInstaller), Go или используете коммерческие протекторы, то наверняка сталкивались с этой несправедливостью. Ваш абсолютно легитимный софт помечается красным флажком из-за эвристики, слишком "подозрительного" поведения или просто потому, что звёзды так сошлись.
Это называется ложное срабатывание, или False Positive (FP). И это не просто обидно. Это бьет по репутации, отпугивает пользователей и может похоронить ваш проект.
Сегодня мы разберем, что с этим делать. Как не просто смириться, а дать бой, доказать невиновность своей программы и помочь антивирусным вендорам стать немного умнее.
Привет, Хабр!
Представьте ситуацию: вам на почту падает «супер-важный» архив от контрагента. Или вы нашли в сети ту самую утилиту, которую искали полгода, но лежит она на каком-то noname-файлообменнике. Или друг в Telegram кидает ссылку с комментарием «зацени, умора». Сердце ёкает. А вдруг там?..
В такие моменты у большинства из нас в голове проносится одна мысль: надо бы проверить. И тут на сцену выходит герой нашей сегодняшней статьи — VirusTotal.
Многие о нем слышали, многие пользуются, но, как показывает практика, большинство использует лишь 10% его возможностей. Сегодня мы это исправим. Разберем, как выжать из этого бесплатного сервиса максимум, как правильно читать его вердикты и каких подводных камней стоит опасаться.
Еще до открытия для себя практик Dev-ops я использовал Docker для упаковки и быстрой доставки кода на сервера (всё делалось ручками, я еще не знал про CI/CD xD). Со временем мои приложения становились больше, появлялись микросервисы, убирался монолит. И управлять ручками или через Portainer всей архитектурой было слегка сложновато. Простой, куча вопросов, падение контейнеров, рост нагрузки и все в этом духе. Тогда-то я и открыл для себя кубер.
Помните ту историю про дом на песке? С хостингом та же логика.
Три года работы с клиентом. Контент идеальный. Ссылки качественные. Техническая оптимизация безупречная. Но сайт еле ползёт. TTFB — 2300 мс. Google Search Console кричит «Медленная загрузка страниц». Отказы — 72%. И вот Вы понимаете: всё дело в shared-хостинге за 199 рублей, где сервер отвечает как уставший госслужащий в пятницу вечером.
Переезд на VPS за 890 рублей. Месяц — и сайт в топ-5.
Google официально подтверждает: Core Web Vitals влияют на ранжирование с 2021 года (источник: Google Search Central). Это не «может повлиять». Это влияет. Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS) — все эти метрики завязаны на то, где и как работает Ваш сайт.
Google использует Core Web Vitals как фактор ранжирования для оценки пользовательского опыта, и сайты с хорошими показателями получают преимущество в поисковой выдаче.
TTFB в 200 миллисекунд или в 1500? Эта разница — пропасть. Для пользователя. Для Google. Для Вашего бизнеса.
Эта статья — для тех, кто запускает стартап, ведёт клиентские проекты или продвигает собственный бизнес. Мы разберём три типа хостинга без маркетинговой шелухи. С реальными цифрами российского и белорусского рынка. С кейсами. С рисками, о которых провайдеры предпочитают молчать.