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

Привет, Хабр! На связи команда архитекторов, разработчиков и тестировщиков Рунити, которые внедряли функцию «Мультидоступ» в личный кабинет Руцентра. В этой статье рассказываем, как добавляли ролевые проверки, перестраивали контур авторизации и дорабатывали существующую инфраструктуру личного кабинета доменного регистратора. Проект получился объемным, график — насыщенным, но обо всем по порядку :) 

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

Выбираем архитектуру по кайдзен: на что обратить внимание

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

Предлагаю разобрать на примере подход выбора архитектуры для продукта!

Это третья часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой мы говорили о платформенности и архитектуре, о том, на чем держится система. Во второй – о классическом BI-функционале, который делает систему BI-системой.

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

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

Меня зовут  Ярослав, я data pre-sale в MWS. За долгие годы работы я совершил массу ошибок и однажды чуть не похоронил проект, потому что послушал заказчика и не поговорил с бухгалтером, которому в итоге предстояло пользоваться продуктом. Оказалось, их боли — две огромные разницы. В итоге я вывел для себя два главных правила:

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

— Твоя главная суперсила — не техстек, а синергия. Умение переводить с языка бизнес-хотелок на язык Python и обратно, а потом и на диалект «бухгалтера Галины Ивановны» — вот что определяет успех твоего проекта. 

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

Вчера мой скрипт завис. Процессор горел на 100%. Я убил процесс.

Я Senior Developer с 10 годами опыта. Пишу на Python, знаю Java и много модных фреймворков. Но в этот момент я понял: я не умею программировать. Точнее, я умею использовать инструменты. Но я не понимаю природу вычислений.

Эта статья — о том, как одна математическая задача изменила моё понимание разработки.

И почему через пару лет, когда ИИ будет писать весь код за меня, это понимание станет единственным, что меня спасёт.

Возможно, и тебя тоже.

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

Идеальное ТЗ — утопия, но многие болезненные моменты и конфликты на стадии приемки можно предсказать и минимизировать. Часто они возникают не из-за злого умысла, а из-за слепых зон в документе.

Многие компании запрещают сотрудникам использовать ChatGPT и Claude — инфобез не пропускает иностранные сервисы. При этом российские ИИ-решения от Сбера и Яндекса работают в отечественном правовом поле, проходят аудит и размещены на территории РФ.

В этой статье показываю, как за 20 минут подключить Sber GigaChat к Roo Code — связке, которую мы разбирали в предыдущем материале про автоматизацию рутины аналитика. Понадобится локальный прокси gpt2giga, который принимает запросы в формате OpenAI и транслирует их в облако Сбера.

Пошагово: установка через pip/Docker, получение API-ключа в Sber Studio, настройка .env, подключение в Roo Code. Плюс таблица типичных ошибок и их решений.

Статья для аналитиков, тестировщиков и разработчиков, которым нужен ИИ-инструмент, совместимый с корпоративными политиками безопасности.

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

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

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

ArchiMate в оригинале Architecture‑Animate) — это открытый и независимый язык моделирования архитектуры предприятия для поддержки описания, анализа и визуализации архитектуры внутри и за пределами бизнес‑процессов однозначным способом. Так же это технический стандарт от The Open Group, базирующийся на IEEE 1471. Он поддерживается различными разработчиками инструментов моделирования и консалтинговыми организациями.

Мой путь от простых телефонных заметок к системе персонального знания начался с боли: потеря данных при смене устройств, неудобная синхронизация, отсутствие контроля. Прорыв случился с Obsidian — приложением, которое, как и VS Code, строится вокруг открытого формата (Markdown), локального хранения и расширяемости через плагины. Именно этот принцип «я управляю инструментом, а не наоборот» стал ключевым: Obsidian — не блокнот, а операционная система для мышления.

В этой статье я структурировал весь опыт и подходы к тому, как мониторить и трейсить LLM и AI-агентов на их основе. Это очень большая статья, но мне хотелось полностью закрыть всю тему за раз и создать крепкий бейзлайн для погружения в тему observability и трейсинга агентов.

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

Здесь будет про Langfuse, Phoenix, OpenLIT, Langtrace, LangWatch и Lunary. Про оценку (evaluations или evals) здесь не будет, но обязательно скоро будет отдельная статья и про это.

Поехали!

Вы проектируете масштабируемую систему на System Design интервью в BigTech. Всё идёт хорошо, пока вам не задают неожиданный вопрос. От ответа на который зависит ваше прохождение.

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

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

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

Контроль импеданса - это основа проектирования современных высокоскоростных цифровых и высокочастотных аналоговых схем.

1. Что такое контроль импеданса?

Контроль импеданса (ImpedanceControl) – это совокупность мер при проектировании и производстве печатных плат (ПП), направленных на то, чтобы волновое сопротивление (импеданс) проводников на печатной плате имело строго заданное значение.

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

Зачем это нужно?

Когда-то бизнес-аналитик ассоциировался с человеком, который «пишет ТЗ». Сегодня этого явно недостаточно. Современный БА — это стратег, коммуникатор и системный мыслитель, который одинаково уверенно чувствует себя в бизнес-контексте и технических деталях. Чтобы не застрять в прошлом, важно понимать, как эволюционирует роль аналитика и какие компетенции становятся критически важными.

Привет, Хабр! Я Любовь Кулева, руководитель отдела разработки и методологии Учебного центра IBS. За последний год мы выпустили две полноценные «дорожные карты развития» — для системного аналитика и для архитектора ПО. В этой статье мы с практикующими экспертами собрали навыки, которые превращают бизнес-аналитика в того, за кем бегают рекрутеры.

Привет, Хабр! Я Дмитрий Смотров, тружусь бэкендером в Astra Linux в команде продукта ACM — микросервисной системе, разворачиваемой на клиентских мощностях. Мы позволяем удаленно управлять клиентской инфраструктурой. Сначала я разрабатывал функциональность снятия инвентаризации и удаленного выполнения команд установки и удаления ПО, но в один момент моя жизнь резко изменилась. На проекте возникла необходимость в функциональности красивой и настраиваемой отчетности, в чем я увидел возможность проверить себя в новой для себя области. Я вызвался разобраться и помочь продукту стать еще лучше.

Под катом расскажу о том, с какими трудностями столкнулся в процессе, как я их решал и что в итоге получилось. Приятного чтения :-)

Привет, Хабр! ИИ-агенты и производные от них стремительно вошли в повседневную рутину разработки, зажигая глаза менеджеров и добавляя головной боли архитекторам. И если с одиночным агентом в целом никаких проблем не возникает, то когда агентов становится много, возникает настоящая проблема: как ими управлять? В этой статье попробуем разобраться в основных подходах к созданию управляющего слоя в такой системе, разберём на примере, почему не все очевидные подходы будут работать и какие классические архитектурные паттерны актуальны в новой моде. И, конечно же, расскажу, как это работает на практике в Домклик. Будет интересно!

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

Упрощение процесса разработки за счет No-code и Low-code платформ, стремительное развитие технологий, кардинальным образом меняющих бизнес-процессы и программное обеспечение, покрывающее их, повсеместная автоматизация и возведение софтверных продуктов в ранг цифровых активов, привели к частым проектам перевнедрения. Если раньше предполагалась, что жизненный цикл программного обеспечения завершается его утилизацией, то сейчас об этом не может быть и речи. Отказ от приложений трансформировался в их замену на новые образцы, жизненный цикл же из линейного превратился в спиралевидный, то есть возвращающийся на начальный этап.

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

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

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

Представьте: вам поручили спроектировать систему, обрабатывающую персональные данные. Требования размазаны по пулу статей НПА, а за ошибку грозят миллионные штрафы. Как структурировать эту сложную область и убедиться, что вы ничего не упустили? В этой статье я на примере положений ФЗ «О персональных данных» (далее по тексту – ФЗ) покажу, как язык ArchiMate помогает превратить юридический текст в четкую архитектурную схему. Такой подход помогает выявить пробелы в требованиях, наглядно согласовать их с заказчиком и заложить основу для проектирования ИТ-решений.

Здравствуйте! Я Дина Лакеева, в разработке я с 2012 года. Сейчас я являюсь лидером системного анализа продуктового стрима в команде разработки личного кабинета МегаФона.  Практически на всех своих проектах я сталкивалась с проектированием интеграций, то есть со взаимодействием различных систем или их частей. И именно эта часть проекта меня больше всего увлекала. Интеграции – это то, в чем мне всегда хотелось развиваться, и я вижу в этом большой интерес и по сей день.

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

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

Так вот, представим, что наша система – это корабль... О чем же стоит подумать на берегу?

Нужно ли аналитику машинное обучение? Ответ неоднозначный: всё зависит от места работы и планов в профессии.

Меня зовут Раф, я аналитик ценообразования в Авито (а раньше в Яндекс Лавке), преподаватель машинного обучения в Центральном университете, выпускник факультета компьютерных наук в НИУ ВШЭ и курса «Специалист по Data Science» в Яндекс Практикуме. 

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