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

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

В августе 2019 года, за несколько недель до выборов в Московскую городскую думу, Пьерик Годри из исследовательского института INRIA опубликовал результаты анализа кода московской системы дистанционного электронного голосования. Вывод был однозначным: параметры шифрования слабы настолько, что расшифровать голоса избирателей в режиме реального времени можно было за двадцать минут на стандартном ноутбуке с помощью общедоступного программного обеспечения Gaudry, Golovnev, 2019. Не взломал — математически решил задачу, которую разработчики системы, судя по всему, считали нерешаемой за разумное время. Ключ шифрования был построен на 256-битных параметрах ElGamal: при таком размере задача дискретного логарифма решается за минуты на обычном ноутбуке.

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

Если смотреть на СССР не только через политику и экономику, а через оптику инженера, то это была огромная «машина» по сборке крупных систем: от энергосети страны до космических программ, от ядерной отрасли до научных школ, которые сформировали язык современной физики. В этой статье я собрал 15 наиболее важных достижений и продуктов, созданных в СССР в 1917–1991, и постарался удержать фокус на людях и институтах, которые сделали их возможными.

Коротко, что вы увидите дальше:

Недавно мы в Beeline Cloud писали о том, как гонка за «общим ИИ» вывела дата-сайентистов и специалистов по машинному обучению в топ самых высокооплачиваемых профессий. Не отстают от них и инженеры данных: рассказываем, за что компании высоко ценят таких специалистов и какую литературу можно почитать начинающим дата-инженерам и продвинутым специалистам — чтобы «держать руку на пульсе».

30+ движков за две недели, реальные замеры на Apple M4, и почему ElevenLabs за $5.57/час — это приговор для бизнеса

Сижу на очередном рабочем созвоне. Обсуждаем архитектуру нового сервиса. Технически я всё понимаю — документацию на английском читаю без словаря, код ревьюю, в слаке переписываюсь нормально. А вот когда надо открыть рот и сказать что‑то сложнее «I agree» — начинается цирк. Пауза. Подбираю слова. Коллега уже ответил за меня.

Знакомо?

Я CTO, серийный предприниматель, последние годы плотно работаю с AI‑интеграциями. И вот парадокс: могу собрать систему автоматического обзвона клиентов с клонированием голосов, а сам на созвоне звучу как иностранец с разговорником.

Решил наконец закрыть этот гештальт. Полез искать real‑time переводчик. Что‑то типа: я говорю по‑русски, собеседник слышит английский. И наоборот. В реальном времени, без пауз на 10 секунд.

И тут началось интересное.

Всем привет! Меня зовут Саша, я тимлид в DWH MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

Недавно ребята из Datalens проводили вебинар в честь выпуска Public API, в котором я принял участие. Эта статья — развернутая версия моего доклада об интеграции Datalens с OpenMetadata.

TLDR: https://semagram.io/

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

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

Я брейнштормил идеи с ИИ, первые проекты были не особо примечательными...

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

Меня зовут Елизавета Колесникова, и вот уже 4 года я работаю системным аналитиком СПАО «Ингосстрах»

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

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

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

Сталкивались уже с EvaTeam (российский аналог Jira)? Чувствуете боль при работе с бизнес-процессами (workflow)? Думаю я могу вам немного помочь

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

Я техлид группы разработки шины обмена данных в компании «Передовые Платежные Решения». И помимо этого, неформальный лидер команды внутренних ИИ проектов. В статье хочу поделиться нашим опытом внедрения ИИ с нуля: как за 6 месяцев команда из 12 разработчиков (backend, без опыта с ML/ AI) создала и вывела в пилот голосового ИИ-ассистента.

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

Подавляющее большинство вредоносного ПО использует DNS-протокол для связи с командными серверами, эксфильтрации данных или перенаправления трафика. При этом почти 60% организаций не осуществляют мониторинг DNS-трафика на регулярной основе. Между тем защита DNS это довольно крупный продуктовый домен в сфере информационной безопасности. Мировой рынок DNS Security уже оценивается в $1,6–2,0 млрд и растёт на 10–14% ежегодно. Разбираемся, что стоит за этой технологией, кто её развивает за рубежом и в России, и чего от нее ждать в ближайшие годы.

40 000+ записей без пагинации, 200 OK вместо 400 Bad Request, SQL-запросы в ответах клиенту. Собрал 10 ошибок API из реальных проектов: монолитов, микросервисов, стартапах и энтерпрайза.

Большинство знают базу: создал схему компоновки, написал запрос, перетащил поля в настройки — получил отчёт. Но СКД умеет гораздо больше! И многие задачи, которые решают кодом в модуле отчёта, на самом деле решаются средствами самой компоновки — проще, надёжнее и с бонусом в виде пользовательской настройки.

Разберём механизм и приёмы, которые экономят время и код.

Если вы только начинаете работать с требованиями, эта статья для вас.

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

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

Обычно документацию делают по одному из двух путей – либо используют стандарты, описывающие требования к составу, структуре и содержанию документов (например, ГОСТ 19-й и 34-й серий – ЕСПД и КСАС), либо самостоятельно разрабатывают документ, создавая его на основе собственного опыта или по существующим образцам, в т.ч. взятых из интернета.

Но как же её правильно сделать?

Мой ответ - начинать надо с синопсиса документов.

Хотите научиться предсказывать продажи, цены на недвижимость или спрос на товары, учитывая сразу несколько факторов? Вам поможет множественная регрессия.

В этой статье вы узнаете:

• Математическую основу множественной линейной регрессии – от уравнения гиперплоскости до метода наименьших квадратов;
• Разбор полного кода на Python с использованием scikit-learn на реальном датасете Advertising (200 наблюдений);
• Как интерпретировать коэффициенты модели;
• Сравнение с простой линейной регрессией – насколько лучше работает множественная модель;
• Расширение до полиномиальной регрессии, когда линейности недостаточно.

Почему требований нет (и это нормально).

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

Требования очень редко полностью попадают под характеристики...

Мы часто думаем, что плохой интерфейс — это про кнопки, цвета или сетку. Но чаще он ломается не из-за пикселей. А из-за того, что дизайнер не учитывает, как на самом деле работает мозг.

Пользователь — не машина. Он устает. Спешит. Тревожится. Делает выводы на основе первых впечатлений.

И вот здесь включаются когнитивные искажения. Разберём 5 самых опасных для UX.

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

В этой статье – сразу два пути: от простой Excel-сезонки, которая неожиданно обыграла Prophet и классику на длинном горизонте, к ансамблю на базе TSMixer и от наивной веры в средний MAPE – к нормальной системе оценки качества с rolling backtest, bias, EOM и деградацией по горизонту.

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

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

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

Мы представляли себе идеальную картинку: загружаем исходники, документацию, ТЗ в модель, нажимаем кнопку и на выходе получаем JSON с описанием архитектуры, связей, интеграций и методов. Вишенкой на торте должен был стать умный чат, в котором можно спросить что-то вроде «как у нас реализованы выплаты по убыткам?» и почти мгновенно получить ответ.

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

Но не тут-то было. Идея разбилась о суровую реальность enterprise-разработки. За несколько месяцев мы собрали коллекцию из 12 ошибок, которые едва не похоронили наш проект Code Scope (именно так мы назвали решение). Сегодня расскажу о пяти, на мой взгляд, самых показательных. Спойлер: в итоге наш код на 99% состоит из «инженерии», и только 1% – это тексты промптов.

Ошибка 1: Один запрос обо всём

Мы начали красиво. Взяли внутреннюю систему, написали «классный» промпт и попросили LLM вернуть все возможные факты о коде в виде структурированного JSON-объекта: описание методов, интеграции, точки входа, расчёт метрик и так далее.