Анализ и проектирование систем *

Ранее в "Надёжность, устойчивость, доступность" провели введение в терминологию надежности. В этой статье рассмотрим типовые модели отказоустойчивого кластера.   

К сожалению, в текущих публикациях ИТ-изданий с заголовками «надежность, отказоустойчивость, доступность» и т.п. не встречал ни моделей надежности, ни расчетов этих самых (показателей) «надежность, отказоустойчивость, доступность», а только качественные критерии: «более надежный», «очень отказоустойчивый» и т.п. Инженерная надёжность (например, «Надежность в технике») из научной (инженерной) дисциплины в публикациях ИТ-журналов (хабр и т.п.) превратилась в некую менеджерскую дисциплину пусть и с техническими подробностями \ описаниями, например, механизмов переключения резерва, но без математического аппарата (теории вероятности \ теории надежности).  С целью популяризации расчетов надежности отказоустойчивых резервируемых структур вычислительной и сетевой инфраструктур ниже предлагается несколько базовых подходов \ моделей \ надёжностных схем.

Семь зон IT-риска, которые бизнес обычно игнорирует

В ноябре 2021 года я выступал на конференции про IT-риски. Я был краток: нужен был вид с высоты птичьего полёта.

Для бизнеса ИТ часто выглядит как поддержка, удобство и новые сервисы. А что, если система остановиться? Что будет с бизнесом?

Я намеренно взял «обратную сторону ИТ»: персонал, серверы, сеть, разработка, проекты, эксплуатация, информационная безопасность. То, как это выглядит «под капотом». Семь зон, где обычно копятся сюрпризы. И тогда, и сейчас, в 2026-м, я смотрю на эти зоны через призму непрерывности бизнеса, оценивая хрупкость, устойчивость, управляемость.

Если вы об этом даже не задумывались, то риск уже есть. Просто он ещё не выставил счёт.

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

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

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

Обо мне:

«Всем привет, меня зовут Артём, и я архитектор».

Архитектор я уже давно и много раз. На протяжении долгого времени проектированием каких только систем я не занимался. Сначала системы мультимедиа и ВКС, немного сетей (пока всё логично), далее комплексные проекты с инфраструктурой серверов, пользовательских устройств и прикладного ПО. Дальше резкий сюжетный поворот: проектирование аналитических и BI‑систем в специфике ИБ, резко обратно к «железу» — я главный инженер по слаботочным сетям в крупной строительной компании (гражданское строительство в части всего, что управляется токами ниже 220 В).

Наши дни: Сбер... я четвёртый год корпоративный архитектор инфраструктуры, включающей в себя слои аппаратного обеспечения, виртуализации, операционных систем, серверов приложений, прикладных шлюзов безопасности, Wi‑Fi сетей и многого другого.

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

В Сбере у меня всё плавно начиналось с проектирования отдельных продуктов и их окружения, документирования «наследия» и проверки его на соответствие стандартам банка. Но в один момент все начало меняться, и я, «лёжа на теплом песочке пляжа» под названием «архитектура отдельных продуктов» сначала начал ощущать «брызги волн», а потом «надвигающийся шторм», рождаемый хаосом динамичного, постоянно меняющегося ландшафта банка, в котором крутилась нормативка, стандарты, методики, legacy‑системы, новые стратегии и другие вызовы.

Задача звучала как задача из учебника: перенести кредитный домен банка с Oracle на PostgreSQL. 70+ таблиц, чуть больше терабайта данных, 500–3000 RPS на чтение и 50–300 на запись в пике. Одно ограничение: система обслуживает клиентов и не может остановиться. Ни на ночь, ни на выходные, ни «на 15 минут на переключение».

Эта статья — не туториал «как мигрировать за 10 шагов». Таких на Хабре десятки, и половина из них сводится к «запустите ora2pg». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «об этом мы узнали за неделю до переключения».

Если вы планируете такую миграцию, читайте как чеклист. Если уже прошли — сверьте, сколько совпало.

Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин и сами проблемы — настоящие.

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

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

Решил посчитать, сколько раз языковые модели отзываются плохо о конкретной компании. Вроде простая задача: прогнать запросы через несколько моделей, разметить тональность ответов, поделить негативные на общее число. У меня получилось три негативных ответа из 358 — 0,8%. Число выглядело спокойным, и я чуть не отправил его в отчёт как есть.

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

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

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

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

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

Доминирующий стиль координации назывался хореографией: сервисы не общаются друг с другом напрямую. Вместо этого они генерируют события (например, заказ размещён, платёж подтверждён, товар зарезервирован), а другие сервисы независимо реагируют на эти события. Таким образом, не нужен центральный координатор и, возможно, даже не нужно задавать явную последовательность. Каждый сервис занимается своим делом, в результате чего получается слабо связанная архитектура (спойлер: слабо связанной она не была — как я разобрал в докладе под названием «Слабая или паршивая связанность? Понимаем паттерны коммуникации в микросервисных архитектурах»).

Медицинская организация одновременно работает с электронными медицинскими картами, результатами исследований, врачебными заключениями, клиническими рекомендациями, внутренними регламентами, отчётностью и аналитическими витринами. Проблема состоит не только в объёме информации. Эти данные имеют разную структуру, обновляются с разной скоростью и доступны разным группам пользователей.

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

Здесь появляется RAG, или Retrieval-Augmented Generation. Но в медицинской среде я бы рассматривал его не как чат-бота и тем более не как автономного медицинского советника. Более полезная модель - управляемый слой между данными, документами, аналитическими системами и пользователями.

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

Есть сотрудник. Есть автомобиль. Есть объект заказчика. Нужно проверить документы и оформить допуск.

Что здесь вообще автоматизировать?

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

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

Этим вопросам будет посвящена секция «Решения 1С: архитектура, учет и кейсы автоматизации» на INFOSTART A&PM EVENT 2026, который пройдет 12–14 ноября в Санкт-Петербурге.

В 2024 году исследователи провели простой эксперимент: взяли тесты с вариантами ответа и начали менять варианты местами. Сами вопросы и содержание ответов оставались прежними.Казалось бы, какая разница, находится правильный вариант под буквой A или под буквой C?

Оказалось, разница есть. В работе Large Language Models Sensitivity to The Order of Options in Multiple‑Choice Questions авторы показали заметный разброс качества моделей при перестановке вариантов. На разных сочетаниях моделей и датасетов разрыв оказался очень большим.Уже неприятно. Но дальше становится интереснее.

Ответы LLM часто оценивают с помощью другой LLM. Такой подход называют LLM‑as‑a‑Judge: модель получает вопрос, эталон или критерии, ответ тестируемой системы и выставляет оценку. Однако и такой судья не идеально объективен. В исследовании Judging LLM‑as‑a‑Judge with MT‑Bench and Chatbot Arena описаны, в частности, позиционное смещение и предпочтение более подробных ответов.

Получается любопытная конструкция: поведение одной модели зависит от формулировки и порядка элементов, а проверяем мы её другой моделью — со своими особенностями.Для исследователей это интересный эффект. Для команды, которая выпускает AI‑функцию в продакшен, — обычная инженерная проблема.

Лицензия на корпоративное ПО давно перестала быть просто ключом «введите и активируйте». Пользователи перераспределяются между инсталляциями, появляются новые кластеры, меняется состав ресурсов, лицензии продлеваются, а вся история изменений постепенно расползается между CRM, договорами, заявками и переписками.

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

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

Всем привет! Меня зовут Анатолий, я работаю ИТ-архитектором в Сбере. Занимаюсь развитием направления клиентской лояльности. Сразу же отмечу, что в этой статье не идёт речь о фундаментально правильных решениях. Скорее, наоборот, речь идёт о решениях компромиссных.

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

Если в вашей компании уже живёт полноценная система для архитектурных решений в виде Aris, Sparx Enterprise Architect или их аналог, и она умеет всё, что нужно: описывать бизнес-сценарии, собирать связанные с ними решения, показывать и согласовывать их с заказчиками, а потом аккуратно складывать в единый архитектурный репозиторий, то тогда, скорее всего, эта статья не для вас. Вы и так всё это проходили.

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

«Мы не пишем ТЗ, — гордо сказал мне руководитель агентства. — Мы работаем только по Agile». Хочется порассуждать на тему того, нужно ли в 2026 году писать техническое задание на разработку информационного продукта и в каком виде. Или это все замшелые водопадные технологии, которые уже давно прогрессивным разработчикам и вайбкодерам никуда не уперлись.

Вообще, сам термин «техническое задание» для разработки в последнее время стал встречаться реже — и в обсуждениях и в профильных статьях. Чаще его заменяют словом «требования» (reqirements) или Product vision и это действительно ближе к истине — в таком документе мы фиксируем требования заказчика и видение того, каким должен быть создаваемый продукт, что он должен уметь и как выглядеть. Вне зависимости от подхода к разработке такой документ на старте проекта должен быть обязательно, и при этом быть хорошо проработанным — хотя бы для создания MVP. Потому что и у заказчика проекта и у его разработчика перед глазами должен быть так сказать единый «образ победы» — того продукта, который они совместными усилиями делают. Без такого документа вы не сможете ни бюджет спрогнозировать даже примерно, ни сроки готовности, да и функционал самого продукта может в итоге оказаться совсем не таким, как его представлял себе заказчик. Сколько раз приходилось наблюдать ситуацию, когда не только отдельные фичи, но даже использованные в постановке задачи термины понимались сторонами по‑разному, что приводило к спорам на приемке очередного этапа работ. Поэтому кстати, считаю раздел с терминами обязательным и всегда включаю его в свою документацию — чтобы у всех было единое понимание того, что такое «Заказ», из чего состоит «Заявка», кто такой «Администратор» и тому подобное

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

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

В этой статье разберу более устойчивый вариант: отдельный API‑слой между мобильным приложением и существующей системой. Без полной переработки монолита и без попытки сразу перейти на микросервисы.

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

У вас, скорее всего, уже открыт десяток разнообразных вкладок: какая‑нибудь платформа с бесплатными недельными лимитами, вроде Kaggle; что‑нибудь с бесплатными возобновляемыми кредитами, на подобии Lightning AI; возможно, пара площадок со спотовыми машинами по цене чашки кофе, например Vast, но с оговоркой — никто не обещает, что машину не заберут, или у ее владельца не отвалится сеть.

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

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

Итак, приступаем...

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

Собрать Lakehouse на слайде несложно. Берём S3-совместимое хранилище, добавляем Iceberg, Spark, Trino, Kafka, Airflow и каталог данных. Получается современно, масштабируемо и архитектурно красиво. Гораздо сложнее сделать так, чтобы эта конструкция работала в определенных корпоративных сценариях. В статье попробуем отделить архитектурную концепцию от маркетинга и разобраться, как на самом деле идут проекты внедрения Data Lakehouse в России: какие решения доступны на рынке, какие проблемы платформа не решает, когда её внедрение имеет смысл и как выбрать подход к миграции.

Полтора года назад разговор про AI и архитектуру обычно сводился к одному вопросу: насколько быстрее теперь пишется код. Сейчас вопрос звучит иначе. Если значительная часть проектирования и реализации переходит к AI‑агентам — что происходит с самой системой принятия архитектурных решений?

Я успел побывать по обе стороны. Сначала несколько лет разбирал алерты в SOC — сидел на потоке срабатываний и решал, что из этого инцидент, а что шум. Потом ушёл в разработку и последние годы пишу сами детекты — те правила, которые генерируют эти срабатывания. И вот что забавно: пока не начал писать алерты сам, я был уверен, что понимаю про них всё. Оказалось — почти ничего.

Эта статья — про несколько вещей, которые выглядят совершенно по-разному в зависимости от того, с какой стороны экрана ты сидишь. Будет полезно и аналитикам, которые ругают «криворуких вендоров», и разработчикам, которые не понимают, почему их идеальное правило ненавидят в SOC.