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

Знакома ли вам ситуация, когда задачи теряются и не выполняются по причине того, что они нигде системно не ведутся? Что интересно: с такой ситуацией сталкивается не только ИТ, а вообще любой сотрудник офиса. Конечно хорошо, когда задача одна, но что если их 10, и новые прибавляются каждый день? Неизбежно приходится записывать задачи, вести их статус. Потом появляется понимание, что задачи должны быть еще и связаны друг с другом, что нужно хранить артефакты в виде документов. И когда появляются статус и возможность делится этими задачами — начинается поиск системы, которая автоматизирует эту работу.

Есть довольно простой вопрос, который стоит задать ИТ-архитектору: «Что произойдёт, если сервер, на котором расположена служба каталогов, решит прилечь?». Если ответ начинается со слов «ну, вообще-то у нас есть бэкап», это не совсем отказоустойчивая архитектура.

Бэкап помогает восстановить систему. Но он не помогает пользователю войти в корпоративный сервис прямо сейчас.

Поэтому в новой версии MULTIDIRECTORY мы развиваем архитектуру службы каталогов в сторону мультиконтроллерной установки: несколько контроллеров домена, локальные (автономные) копии данных, репликация файлов и балансировка запросов.

В этой статье разберём, что происходит внутри такой системы и почему поставить второй сервер — ещё не значит получить отказоустойчивое решение.

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

Для тех, кто держит или собирается держать LLM внутри контура: тимлидов, DevOps, архитекторов. Здесь конфиги, цифры и грабли, а не введение в трансформеры.

Что вы унесёте: историю пяти последовательных конфигураций с тем, что каждая дала и чего стоила; рабочий набор флагов vLLM под одну карту Blackwell; три неочевидных бага и обходы; разбор реального счёта с отношением вход/выход 452:1.

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

Если вы хоть раз пользовались LLM, то почти наверняка сталкивались с двумя ее классическими болячками: галлюцинациями и устаревшими знаниями. А когда дело доходит до рабочих задач, появляется еще одна проблема — как использовать внутренние документы компании, не выкладывая их в открытый доступ. 

В этой статье разберем метод RAG (Retrieval-Augmented Generation) и подробно посмотрим на один из самых интересных open-source инструментов для его реализации — RAGFlow. Попробуем понять, насколько он подходит для внутреннего использования.

Всё началось с желания организовать и автоматизировать работу с Terraform, впоследствии с Terragrunt, выстроить управляемый процесс, централизовать, настроить понятный RBAC, в общем, сделать так, «чтобы было красиво». Было сделано несколько подходов, и были рассмотрены разные варианты. Отправной точкой стало структурирование кода, его декомпозиция и рефакторинг, и постепенно дошло до автоматизации самого процесса применения (или просто plan/apply). К этому моменту основная часть кода сконцентрировалась в монорепозитории в self-hosted GitLab, общая и повторяемая логика отделилась во внутренние приватные модули, а сам код вырос в объёмах: более 4 000 .tf файлов, не учитывая внешних и внутренних модулей, более 900 проектов (каталогов), более 30 000 ресурсов, более 30 уникальных провайдеров Terraform. Конечно, все эти условия в той или иной степени повлияли на конечный выбор.

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

Разработчики описывают изменения кодом, инфраструктура — декларативными манифестами, а архитектура до сих пор часто живёт в draw.io и PNG. Почему диаграмма без модели быстро устаревает и как собрать архитектурный control plane из знакомых деталей: API server, графа, CMDB, diff/review и operator pattern? А может нам нужно решение с ResourceDefinition, типизированными связями, Temporal workflows и change sets.

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

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

Корпоративные мессенджеры, порталы, супераппы — эти термины сегодня звучат едва ли не на каждом совещании. Но что они на самом деле означают, и главное, что из этого действительно нужно вашей компании? Разберемся по порядку.

Привет, Хабр! На снова команда Research & Insights Центра стратегии цифровых продуктов МТС. Мы уже разобрали мировой рынок 5G и объяснили, почему в России нельзя взять и «включить» эту технологию. В этой статье поговорим о том, кто и за что будет платить…

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

Документация Яндекс 360 API на 20 августа 2026 года перечисляет 17 сервисов, и раздела о вебхуках или подписке на события среди них нет; аудит-лог организации документирует 26 типов событий — двенадцать почтовых и четырнадцать дисковых. Кадровых и оргструктурных событий не документировано ни одного. Разбираю, что из этого следует тем, кто строит провижининг: чем располагает UserService_List для поллинга, почему isDismissed нельзя записать и что документация обещает при создании пользователя с занятым логином.

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

Какой подход выбрали коллеги и причем тут бог Солнца? Давайте выясним.

Привет! Меня зовут Ренат Ахмеров, я один из руководителей направления по работе с виртуальными сетями и сетевыми функциями в MWS Cloud Platform. В этой статье я рассказываю про сетевые возможности нашей облачной платформы, приправляя рассказ своей личной историей взаимоотношений с компьютерными сетями. 

Чтобы наглядно объяснить, как работают сети в нашем облаке, мы рассмотрим по шагам построение некой e-commerce системы: от примитивного решения в одной «коробочке» до полноценной Enterprise Grade-архитектуры.

В первые месяцы внутренняя система заявок обычно решает главную задачу: обращения перестают теряться, сотрудники знают, куда писать, а исполнители — что делать. Кажется, что процесс наконец-то заработал.

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

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

Вопрос, который я задал себе и своей команде: что произойдёт, если по одному сотруднику из кадровой системы прилетят два запроса на входящий вебхук? Ответ у меня есть с 20 августа 2026 года, и он укладывается в строку: два независимых запуска, движок их между собой не связывает, ключа дедупликации нет. Ниже — что из этого следует тому, кто прямо сейчас рисует схему обмена 1С с облачным офисом.

Компанию +Альянс основал я. Руковожу ею тоже я, а по существу занимаюсь одним: тем, чтобы кадровое решение доезжало до облачного офиса без человека посередине. Инструменты в тексте остаются безымянными, и наши, и сторонние: речь про требования к приёмнику входящих запросов. Яндекс 360 упомянут как платформа, на которой живут учётные записи, и как источник, который читатель откроет сам.

Сразу про слабое место текста. Всё, что сказано ниже про поведение движка автоматизации, — моя собственная фиксация ответов, а не публичный документ, на который можно дать ссылку. Проверить это можно только на стенде, поэтому такие утверждения я даю вместе с процедурой проверки. Зато про саму платформу есть открытая документация, и на неё я опираюсь дословно. Даты такие. Каталог триггеров и действий зафиксирован 30 июля 2026, история запусков 3 августа, контракт вебхука 20 августа, страницы документации Яндекс 360 API сверены тоже 20 августа 2026.

Любые серьёзные изменения инфраструктуры начинаются с одного вопроса: что именно у нас есть сейчас?

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

За последние годы мы участвовали в нескольких проектах по переносу оборудования — от перемещения отдельных стоек внутри дата-центра до миграции инфраструктуры между площадками. Масштаб проектов отличался, но первая проблема практически всегда была одинаковой.

Документация существует, но её актуальность вызывает вопросы. В одном документе устройство называется одним образом, в другом — другим, а на самой стойке используется третье обозначение. В таблице порт отмечен как свободный, хотя в него включён рабочий линк. На схеме uplink уходит в один коммутатор, а LLDP показывает другой. Какие-то подключения давно не используются, но продолжают числиться в документации. Какие-то, наоборот, работают много месяцев и нигде не описаны.

Привет, Хабр! Меня зовут Дмитрий, я руководитель проектной практики ГК «Юзтех» в области индустриального ИИ. 

За последние несколько лет наша команда участвовала во внедрении десятков ИИ-проектов для разных отраслей. И почти в каждом проекте мы наблюдали одну и ту же закономерность. Компании уже хорошо понимают, какие задачи можно решать с помощью искусственного интеллекта, и все чаще запускают первые пилоты. Однако именно после успешного PoC многие проекты начинают терять темп. На первый взгляд кажется, что самая сложная часть уже позади. На практике все оказывается наоборот. Почему так происходит — давайте разберемся.

Хабр, привет! 30 июля во второй раз прошла инженерная конфа Kuber Community Day. 400 специалистов встретились в Москве, чтобы послушать о вызовах в Kubernetes, обменяться опытом, завести новые знакомства. Мероприятие объединило 26 спикеров в разных форматах: доклады, круглые столы, мастер-класс, научпоп и стендап. Еще конференция запомнилась экспериментальным форматом Arch Dating, в рамках которого с опытными менторами можно было обсудить технические и карьерные вопросы.

Под катом мы собрали подборку всех выступлений с Kuber Community Day'26. Скоро вернемся с новыми анонсами, первыми о них узнают участники K8s-сообщества.

Судя по многочисленным публикациям в России и за рубежом внедрение новаций в сфере информационных технологий (новые программы, ИИ‑ассистенты, ИИ‑агенты) в деятельность компании чаще всего не приносят тот эффект, на который руководители и разработчики рассчитывали. Почему так происходит и что руководители (владельцы) компании делают не так? Попробуем с этим разобраться.

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

Привет, Хабр! Это снова Евгений Шилкин и Степан Татауров, эксперты дивизиона инфраструктуры Группы Rubytech. В прошлой статье мы разобрали подходы к миграции, посмотрели, какие есть альтернативные решения, и обмолвились парой фраз про MIND Migrate Guest. 

В этой статье — практическая часть, проверим MIND в деле и протестируем его. Что из себя представляет процесс миграции с точки зрения алгоритма и чем он отличается от простого переноса между серверами? В процессе обнаружили несколько интересных находок. Давайте разбираться.