IT-инфраструктура *

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

Многие до сих пор воспринимают собеседования примерно одинаково. Кажется, что всё решает техническая часть: насколько быстро ты соображаешь, как пишешь код, помнишь ли теорию, можешь ли объяснить сложность алгоритма или нарисовать архитектуру на доске.

На практике всё часто работает чуть иначе.

Да, техничка важна. Никто с этим не спорит. Но оффер нередко ломается не на алгоритмах, не на лайвкодинге и даже не на ошибке в каком-нибудь ответе. Очень часто всё решают вопросы, которые на первый взгляд выглядят максимально безобидно. Из серии: “кем вы видите себя через пять лет?”, “что вас мотивирует?”, “почему хотите уйти?” или “какой у вас был самый большой косяк?”.

И вот именно на них люди регулярно сыпятся.

Не потому что они глупые. И не потому что не умеют разговаривать. А потому что воспринимают эти вопросы как формальность. Как будто это просто обязательный HR-блок, который надо пережить перед чем-то действительно важным.

Хотя на деле именно там интервьюер часто и пытается понять главное: как вы мыслите, насколько вы устойчивы, чего хотите от работы и совпадает ли это с реальностью конкретной команды.

Сразу уточню важный момент. Я не пытаюсь доказать, что такие вопросы идеальны или что именно так и нужно проводить собеседования. У многих к ним вполне обоснованные претензии, и я их понимаю. Но пока рынок продолжает их задавать, полезно хотя бы понимать, что именно через них пытаются считать и почему на seemingly простом ответе иногда тихо умирает оффер.

Почему вообще такие вопросы так важны

Потому что технические ответы очень часто показывают только верхний слой.

Можно хорошо помнить теорию. Можно неплохо выступить на лайвкодинге. Можно уверенно пройти по стеку. Но при этом оставить после себя ощущение, что с человеком дальше будет тяжело: он быстро выгорит, упрётся в потолок роли, не совпадёт по темпу или просто уйдёт через полгода.

Именно поэтому рынок так любит эти странные вопросы, которые вроде бы не про технологии.

Они не проверяют знания. Они проверяют совместимость.

В своем Telegram-блоге я регулярно пишу про рынок IT, тестирование, автоматизацию и карьеру в индустрии.

Всегда рад новым читателям!

Я с командой пишу один большой C++ проект. У каждого свой Claude Code, у некоторых по два-три параллельно. Все они правят один и тот же репозиторий в одно и то же время.

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

Я построила им координацию - и по дороге переизобрела обычную почту. Восемьдесят второго года. Адрес получателя, тема для быстрой сортировки, In-Reply-To для цепочек, у каждой сессии свой ящик, broadcast через папку all/.

Каждый Claude при старте заглядывает в свой ящик и, если есть непрочитанное, докладывает это себе в контекст до первого промпта. Ответ падает в sent отправителю, подтверждение доставки - в квитанциях. Ни брокера, ни опросов, ни централизованного сервиса - только markdown-файлы.

Сверху ещё два слоя: append-only передача смены между своими сессиями и атомарные файлы-замки с heartbeat’ом на общие ресурсы.

mclaude, open source, зависимостей в ядре - ноль.

Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущих частях мы разобрали, что же такое Terraform, осознали границу между ответственностью HashiCorp и вендора и сформировали примерный облик решения — провайдера инфраструктуры.  

Третья статья этого цикла будет посвящена обзору достижений (и злоключений) других людей — тех, кто уже попытался привнести IaC в oVirt и не достиг успеха. Что у них получилось? А что не получилось и почему? Ответим на эти вопросы чуть ниже. 

Статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера. Работа с унаследованным API, попытки натянуть одну модель управления ресурсами на абсолютно другую и необходимость предусматривать гораздо больше, чем изначально вложено в систему, — все это серьезно сказалось на terraform-provider-ovirt.

В марте–апреле 2026 разговор об AI-агентах резко перестал быть разговором только о новых интерфейсах и демо. На уровне инструментов произошел синхронный сдвиг: Cursor 3 переехал в agent-first интерфейс, OpenAI и Anthropic перестроили SDK вокруг агентных паттернов, а Claude Computer Use из «прикольной фичи» превратился в рабочий инструмент для длинных сценариев взаимодействия с компьютером. На этом фоне идеи Karpathy перестали выглядеть как частные наблюдения одного инженера и начали работать как язык, через который индустрия объясняет происходящее.

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

Юрий Подгорбунский, Security Vision

Введение

Требования к безопасности критической информационной инфраструктуры (далее – КИИ) установлены Федеральным законом от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (далее – Федеральный закон).

Цель Федерального закона заключается в предъявлении требований безопасности для обеспечения устойчивого функционирования КИИ при проведении в отношении ее компьютерных атак.

Основные понятия

Компьютерная атака представляет собой целенаправленное воздействие программных и (или) программно-аппаратных средств на объекты КИИ, сети электросвязи, используемые для организации взаимодействия таких объектов, в целях нарушения и (или) прекращения их функционирования и (или) создания угрозы безопасности обрабатываемой такими объектами информации.

А компьютерный инцидент – это факт нарушения и (или) прекращения функционирования объекта КИИ, сети электросвязи, используемой для организации взаимодействия таких объектов, и (или) нарушения безопасности, обрабатываемой таким объектом информации, в том числе произошедший в результате компьютерной атаки.

Остальные основные понятия в статье будут рассматриваться ниже последовательно. 

Что же такое КИИ?

В целом КИИ – это объекты КИИ, а также сети электросвязи (сети операторов связи), используемые для взаимодействия таких объектов.

А сами объекты КИИ — это следующие системы и сети:

В первой части мы разобрали, как устроены DORA-метрики и что стоит за каждым из пяти показателей. Сложнее другое: одни используют их как инструмент улучшения процессов, другие – как универсальную шкалу зрелости. Разбираемся, почему контекст здесь важнее любого бенчмарка – и с чего начать команде, которая хочет считать метрики осмысленно. 

Иногда доступ во внутреннюю сеть — это не начало атаки, а тупик. Именно в такой ситуации я оказался в самом начале.

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

Кратко напомню отправную точку: в ходе тестирования внешней инфраструктуры заказчика нам удалось получить доступ во внутреннюю сеть через туннелирование. Чтобы не дублировать материал, отмечу лишь, что схема была реализована по подходу, описанному у моих друзей из компании «Deiteriy Lab» в статье - https://habr.com/ru/companies/deiteriylab/articles/920064/. Способ отличный и полностью рабочий, советую взять на вооружение. Для общего представления приведу схему подключения, которую мы использовали (так же взята из статьи).

Вышел Kubernetes 1.36 — релиз, который наконец-то закрывает старые боли админов и разработчиков. Больше не нужно пересобирать образы ради одного сигнала остановки: его теперь можно прописать прямо в манифесте. А «зомби-томы», которые висят мёртвым грузом и жрут место, стало легко находить по дате последнего использования. Собрали в статье разбор всех 68 изменений на русском языке.

Интернет для избранных, рынок для своих: как Минцифры готовит зачистку связи в России

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

Формально всё выглядит прилично и даже бюрократически скучно: предлагается новая система лицензирования операторов связи. Федеральная лицензия, универсальная лицензия, базовая лицензия. На бумаге — очередная регуляторная перестройка. На деле — механизм выдавливания с рынка тех, кто мешает крупным игрокам окончательно поделить страну между собой.

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

Это и есть настоящая суть происходящего. Не реформа. Не модернизация. Не упрощение правил. А зачистка.

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

Одна ошибка в выборе GPU может стоить двукратной переплаты за каждую задачу — каждый день, пока вы не смените карту. Десять моделей NVIDIA, пять архитектур, разброс памяти от 24 до 288 ГБ. Разбираем, какая карта для чего создана и где рубль работает эффективнее всего.

Мы десятилетиями строим IT-системы, но до сих пор не можем ответить на элементарный вопрос: кто за что платит? Теги есть, аллокация настроена, но в отчетах — хаос. Затраты разбросаны по разным системам (биллинг облака, CMDB, Excel-таблицы у финансистов), и все это приходится собирать вручную перед каждым советом директоров.

В этой статье мы разберем почему классические подходы к распределению затрат дают сбой, и предложим практическую дорожную карту перехода от «гаданий на кофейной гуще» к прозрачной системе учета.

AI-агент на OpenClaw слил $441 000 за один твит. Разбор шести катастроф и архитектуры, которая меня пока спасает

Один твит про «лечение столбняка для дяди» — и автономный агент Lobstar Wilde переводит незнакомцу 5% всего предложения криптопроекта. Это не сценарий киберпанк-триллера, а реальность февраля 2026 года.

Если вы используете OpenClaw или любой другой фреймворк для self-hosted агентов, эта история касается вас напрямую. Почему одни инстансы раздают бюджет первым встречным, а другие остаются в безопасности?

Внутри статьи:

Анатомия 6 крупнейших провалов: от «Тахо за $1» в Chevrolet до разбитых витрин в Чикаго и краха GPT-5 на криптобирже.

Где у агента дыры: разбираем уязвимости на уровнях Input, Reasoning, Tools и Memory.

Архитектура выжившего: четыре конкретных принципа и конфиги, которые отделяют полезного помощника от «заряженного пистолета без предохранителя».

У меня на сервере сейчас крутится OpenClaw-агент. Он может читать, писать, перезагружать контейнеры, лезть в базы, выполнять shell-команды. У него куча прав. Но у него нет доступа к платёжным API. У него нет ключей от криптокошельков. У него нет возможности инициировать что-то, чего нельзя откатить одним git reset или docker restart.

Разбираемся, как не попасть на рекламный плакат с извинениями за разбитую инфраструктуру.

Привет, Хабр! Меня зовут Сергей, я разработчик облачной платформы в Selectel. В прошлой статье я рассказал об использовании Terraform для создания глобального роутера и настройки сетевой связности между разными регионами облака. Сегодня продолжим тему и объединим в сеть выделенный и облачный серверы.

1000 устройств, 5 офисов, 1 Excel. Разбираем, где ломается учёт оборудования при росте компании и как перестать терять технику между филиалами.

Развитие цифровых сервисов, облачных платформ, распределённых корпоративных систем и API-инфраструктуры приводит к существенному усложнению задач обеспечения информационной безопасности. В современных условиях защита информации уже не может ограничиваться только периметровыми средствами, такими как межсетевые экраны и системы фильтрации трафика. Существенное значение приобретают механизмы идентификации субъектов доступа, централизованного управления правами, а также мониторинга и аудита действий пользователей и сервисов.

Одним из перспективных подходов к решению указанных задач является внедрение систем класса Identity and Access Management (IAM), обеспечивающих централизованную аутентификацию, авторизацию и управление учётными данными. Среди свободно распространяемых решений данного класса важное место занимает Keycloak - платформа с открытым исходным кодом, предназначенная для организации единого входа, федерации пользователей и управления доступом на основе стандартных протоколов безопасности.

Актуальность применения Keycloak обусловлена тем, что данная система позволяет унифицировать процессы аутентификации в гетерогенной ИТ-среде, обеспечить поддержку многофакторной аутентификации, интеграцию с LDAP/Active Directory, а также централизованное управление ролями и политиками доступа. При этом архитектурные особенности внедрения Keycloak требуют отдельного анализа, поскольку речь идёт о критически важном компоненте сетевой системы защиты информации.

Место Keycloak в архитектуре сетевой защиты информации

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

Меня зовут Артём Болтов, я ведущий специалист в отделе сопровождения разработки YADRO. Наша команда связывает проектирование и разработку с реальной эксплуатацией оборудования. Мы находимся между схемами, репозиториями, задачами в таск-менеджере и реальностью серверных стоек, стендов и лабораторий. В статье расскажу, какие задачи решают специалисты отдела разработки, какими навыками должен обладать такой инженер и при чем тут тонкое инженерное искусство.

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

Случалось ли вам покупать новые лицензии или технику просто потому, что найти старые оказалось сложнее и дольше? Если да, добро пожаловать в клуб.

В знаменитом мысленном эксперименте Эрвина Шрёдингера кот в стальном сейфе/камере (там ещё счётчик Гейгера с радиоактивным веществом, молоток и флакон с ядом) находится в суперпозиции — жив и мёртв одновременно, пока мы не откроем крышку и не произведём наблюдение. В этот момент волновая функция коллапсирует, и реальность обретает одно конкретное состояние.

В корпоративном ИТ всё работает точно так же. Пока вы не заглянете в серверную, не проведете инвентаризацию и не сверитесь с бухгалтерией, ИТ-инфраструктура находится в суперпозиции: ноут уволившегося разработчика одновременно сдан на склад и потерян; дорогая лицензия всё еще действует и уже просрочена; сервер выполняет критически важную бизнес-задачу и вхолостую жжёт электричество. Драгоценная табличка в Excel с гордым названием Оборудование_финал_v4_Копия.xlsx не связана с реальностью — она всего лишь описывает вероятности. И управлять многомиллионным бюджетом на основе таких вероятностей — путь к финансовой катастрофе, седым волосам по всему телу и хаосу.

В 1981 году IBM PC 5150 поставлялся с 16 или 64 КБ оперативной памяти, а максимальная конфигурация ограничивалась 640 КБ — архитектурным барьером в IBM PC.

За это время сменилось больше десятка стандартов: 30-контактные SIMM, которые нужно было устанавливать парами, продуваемые EDO-модули, провалившаяся RIMM для Pentium 4 и пять поколений DDR. В этой статье постараемся разобраться, как менялась оперативная память для десктопов и серверов.

Знаете, бывают технологии, которые изучаешь — и сразу понятно, куда шли и чем закончили, но OpenStack — это не просто технология, это целая эпоха. Причём такая, где на одной временной шкале у тебя NASA, Rackspace, Mirantis и Red Hat и десятки других крупных компаний, каждая из которых решила, что надо объединиться чтобы сделать свой, «домашний» AWS.

Кстати, да, меня зовут Эдгар Сипки, я девелопер-адвокат в MWS Cloud Platform, и сегодня мы поговорим об OpenStack.