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

В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.

Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.

Эта история началась с того, что и мы с проблемами масштабирования столкнулись. Под хабракатом вы узнаете, как мы прошли через отрицание проблемы, гнев на Ceph, торг с CTO и разработку собственного решения. Как выбирали технологии, на какие грабли наступили, и что в итоге получилось.

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

Также потребуется внимательнее относиться к тренду на изменение лицензий популярных open source продуктов и разобраться с его предпосылками. Последний аспект имеет отношение к так называемому жизненному циклу open source решений и соответствующим рискам: смены лицензии в силу выбора иной бизнес-модели, прекращения распространения решения по open source лицензии или полного ухода с рынка компании-разработчика. Как раз о подобных ситуациях мы и поговорим в этом материале: обсудим, почему open source разработки откладывают в «долгий ящик» или вовсе бросают без какой-либо надежды на дальнейшее развитие.

Disclaimer: В материале речь не идет о сравнении открытого и проприетарного ПО, а о частном случае сложностей с open source проектами, которые в целом встречаются и у проприетарных решений. Также относительно open source специфики — удалось взять комментарии у представителей российского рынка.

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

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

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

ISO/IEC/IEEE 12207-2017

Вот что говорит стандарт ISO/IEC/IEEE 12207-2017 «Systems and software engineering — Software life cycle processes» - см. примечание к п. 2.3. радела 6.4.

«Некоторые заинтересованные стороны имеют интересы, которые противоречат интересам заказчика (например, рыночные конкуренты, хакеры, террористы) или противоречат друг другу. 

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

Намерения или желания тех, кто противостоит заказчикам или является противниками системы, решаются через 

·      процесс управления рисками, 

·      процесс анализа угроз в рамках системного анализа или 

·      cистемные/программные требования по безопасности, адаптируемости или устойчивости. 

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

Всем привет!
Меня зовут Дима Савелко, я лид команды нейро-сети.рф. Зачастую на старте создания сервисов люди концентрируются на вещах, которые стоит делать в самую последнюю очередь, после чего теряют кучу времени на расхлёбывание проблем.

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

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

Управление функциональной архитектурой становится актуальным в больших проектах, в которых внедряется несколько сложных информационных систем и работает несколько команд внедрения.

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

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

Мы в компании «Магнит» много лет строим и эксплуатируем корпоративное хранилище данных и занимаемся различными задачами, связанными с этим. В частности, разрабатываем инструмент для конечного пользователя — систему отчётности и BI.

В статье рассмотрим вопросы оптимизации производительности системы.

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

Здесь мы будем говорить именно о покупателе интернет-магазина ( Customer Journey ), а не о потенциальном покупателе или посетителе. С точки зрения функциональной модели, это разделение я вообще не использую. Покупатель – это человек, который приходит в магазин, изучает информацию и, в конце концов, совершает покупку.

В этом тексте я написал о некоторых подходах к организации кода для микроконтроллеров.

Основная идея - массив наша основная скрепа.

Главные достоинства представленной архитектуры - это простота поддержки, сопровождения и масштабирования кодовой базы.

Привет! Меня зовут Павел, я DevOps-инженер в YADRO. Где бы я ни работал, я был девопсом и использовал Ansible — где-то активнее, где-то меньше. В YADRO с этим инструментом работают почти все департаменты — от enterprise, где разрабатывают серверы, СХД и другое оборудование, до телекома. 

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

В статье я расскажу, с какими проблемами мы столкнулись (признаюсь, их было немало), какие варианты решения рассматривали и к чему в итоге пришли.

Иногда типичная IT-инфраструктура крупной компании выгляд так: PostgreSQL для аналитики, и Oracle для корпоративных данных, и MySQL для каких-нибудь микросервисов. В таких условиях взаимодействие между различными системами становится настоящим мастхевом. И тут может помочь герой нашей статьи - dblink.

dblink позволяет нам безболезненно дергать данные из одной базы в другую, будь то PostgreSQL или что-то вроде Oracle или MySQL.

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

Привет Хабр!

Меня зовут Алексей Пушкарёв, я – архитектор продуктовых решений компании ELMA. Наша команда разрабатывает одноименную Low-code платформу.  В этой статье я расскажу, почему мы выбрали микросервисную архитектуру для Low-code системы вместо классической монолитной, которой до этого занимались много лет. Поясню, почему использовали именно такие технологии и решения, с какими недостатками сами столкнулись. Поговорим, как такая архитектура сказалась на Low-code разработчиках.

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

Добро пожаловать под кат!

Статья будет полезна для тех, кто поддерживает приложения на Java, так как большая ее часть посвящена анализу работы G1 GC, знакомству с соответствующими инструментами и особенностями тюнинга GC, в частности для очень больших heap`ов. А также тем, кто пытается разобраться, на что способен Hazelcast, и для чего его можно применить.

Так исторически сложилось, что на проекте уже использовался Hazelcast, и мы решили попробовать переиспользовать его под новую задачу. Она заключалась в хранении объектов в БД с одним специфичным требованием – данные нельзя записывать на диск, что сильно сужало доступные варианты. Безусловно, мы понимали, что надежность такого хранилища будет низкой, но выбора не было. И, хотя, у нас были мысли развернуть для этого Redis или VoltDB, мы решили опробовать Hazelcast, так как в его возможности, помимо прочего, так же входит in-memory хранилище.

Что из этого получилось – читайте под катом.

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

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

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

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

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

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

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

«Баннерная крутилка» —  один из самых высоконагруженных сервисов в Яндексе. Он умеет переживать 700 тысяч RPS, а иногда и больше. Каждый раз, когда приходит запрос, крутилка должна просмотреть базу из миллиарда документов и выбрать из них самые релевантные для пользователя. При этом выдерживаются весьма жесткие временные рамки: 99% всех запросов обрабатываются менее чем за 200 миллисекунд.

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

Однажды ко мне пришли с запросом. Нужно было поднять горячую линию, в которую могли бы обращаться люди и получать ответы на свои вопросы, переписываясь с волонтёрами. Звучит как саппорт-система? Да, потому что это она и есть.

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

Так у меня на руках оказался прототип системы, которая отлично справилась с поставленной задачей и которую я в качестве упражнения аккуратно переписал в open-source проект, который представляю вам сегодня — Suppgram. В статье я расскажу, чем оказались удобны Telegram-боты, как я подошёл к архитектуре проекта и как мне (не?) помогло знание паттернов проектирования.

Всем привет!

Меня зовут Сергей Максимов и я руковожу разработкой в Центре Управления Процессами (ЦУП) Московской Биржи. В статье я хочу рассказать о нашем опыте автоматизации бизнес-процессов (БП), когда система должна быть не только удобной бизнес-пользователям снаружи, но и надежной внутри.

Бизнес Биржи, с одной стороны, похож на обычный банковский финтех, но имеет ряд важных особенностей. Чтобы лучше представить специфику нашей работы, я приведу метафору. Представьте, что каждое утро с вашего корпоративного космодрома в космос отправляется ракета. В течение дня космический корабль автономно выполняет работу на орбите, а вечером возвращается на базу. В полёте связь с кораблем очень ограничена и успех его полёта на 99% определяется качественной подготовкой. Всё должно отработать точно и в срок. Досрочный спуск корабля с орбиты технически возможен, но влечет за собой огромные репутационные потери с отчетом регулятору и новостями в федеральных СМИ.

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

В этой статье мы разберем:

— Что это за практика и какую пользу для бизнеса приносит;
— Чем она отличается от других методик поддержания информационной безопасности;
— Почему важно проводить Compromise Assessment;
— Каким компаниям и когда целесообразно прибегать к этой практике.