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

Кратко:

- Гонка за трендами, как обычно, заставляет пихать ИИ туда, куда бы он сам не полез, обладая хоть каким-то интеллектом.
- Модели основываются на прошлом. Новые знания не будут отражены, если об этом не заботиться. А у людей много уже заданного контекста и встроенное умение учиться.
- Отсутствие влияния на физический мир. События, происходящие в реальном мире, будут иметь последствия. Даже лучшая модель не может убрать конус с капота автомобиля.
- Алгоритмичность. Человек часто идёт тем путём, который считает коротким или правильным, но не тем, на который ему указывают.

Я люблю когда все просто и понятно (оригинальный текст картинки)

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

Слой «орг-стурктура» в пирамидке компании иногда рисуют выше процессов, а иногда ниже (процесс-центричный взгляд на компанию), но это всегда важный элемент «Архитектуры» (Enterprise Architecture) любого предприятия.

Часто говорят, что процессная и функциональная орг-структура – это условность и в чистом виде таковых не бывает. Ниже - попытка показать «чистые» конфигурации и четкую логику их идентификации (классификации), т.е. раскрыть содержание (идею, формулу) соответствующего орг-концепта и его противопоставление другому.

История орг-диаграмм начинается с МакКаллума (1855), принципы изложены Файолем (14 принципов менеджмента, 1916), Вебером (концепция рациональной бюрократии) и другими (как минимум пол сотни). В интернете лежат сотни статей по теме с разной классификацией орг-структур. Более того, не нашел даже сопоставлений типов из одной классификации с другой (например, Минцберга).

Ниже изложены критический анализ и обобщение классификаций организационных структур организации из теории менеджмента, BPM (Business Process Management), бережливого производства и военного дела. Классификация ориентирована на организации с культурой «синего цвета» (главенство норм и правил, бюрократия и регламентация) по спиральной динамике.

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

Всем привет, меня зовут Влад и я запилил собственный IT стартап в одиночку потратив $100. Я давно хотел проверить свои силы и показать самому себе на что я способен, смогу ли я дойти от: создания идеи, проработки ui/ux, разработки frontend & backend, до публикации продукта и его маркетинга.

Для общего понимания я постараюсь кратко описать свой background. В 14 лет я увлёкся веб разработкой поскольку у меня была команда по игре counter strike и для того чтобы заявляться на турниры, нам требовался сайт, по мере его поддержания, я освоил исскуство владения фотошопом. Этот сайт я начал монетезировать и смотрел как его можно продвигать.

Дальше был универ, где я много писал код на c++, python, c#, писал свои нейронки, программировал роботов, проходил алгоритмы и структуры данных. В это самое время вместе с друзьями начали развивать ивент стартап, который помогал пользователям узнавать расписание, изменения, следить за интересными спикерами. Я занимался ui/ux проектированием и frontend разработкой. В это самое время я изучил первые в своей жизни методологии дизайна: google material design guidelines and Apple Human Interface Guidelines.

Писал диплом на тему: примерка мебели в дополненой реальности на свифте.

Потом был момент, когда мы с партнёрами открыли it outsource компанию на 40 человек разработки, где я был CTO и следил за технологиями в компании на стеке: JS, Typescript, React, Vue, Php, python, nodejs, reactnative.

И весь свой накопленный опыт я хотел применить для создания продукта.

Веб-серверы могут обрабатывать только ограниченное количество запросов одновременно. Кроме того, есть ограничения на скорость передачи данных между сервером и интернетом. Когда число запросов превышает возможности любого компонента системы, веб-сайт может полностью перестать работать. Это называется отказом в обслуживании или Denial-of-Service (коротко DoS).

DDoS-атака, или Distributed Denial of Service, — это распределенная атака типа «отказ в обслуживании». Максим Филатов, аналитик, работавший в антифрод-команде Яндекса и сейчас занимающий должность в FAANG-компании, расскажет о том, как работают DDoS-атаки и как можно защитить свой бизнес от подобных угроз.

Привет, Хабр! Меня зовут Ольга Матушевич, я наставница на курсе «Аналитик данных» в Практикуме. Чтобы актуализировать программы и формулировать более точные обещания относительно трудоустройства, мы исследуем как кейсы выпускников, так и ситуацию на рынке.

Я проанализировала 1 239 вакансий аналитиков данных, размещённых на сайте hh.ru с февраля по май 2024 года включительно, и хочу поделиться с вами полученными результатами.

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

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

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

Рассмотрение эволюции корпоративных информационных систем целесообразно вести не столько с событийной точки зрения, сколько функциональной. Так в работе [1] предложена градация информационных систем на основе стратегического, тактического и оперативного уровней, что, собственно говоря, является классическим подходом к управлению. Данная категоризация не исчерпывает всевозможные способы деления систем [2]: существуют аналитические (OLAP), транзакционные (OLTP) и технические системы (назовем последние OLTeP).

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

В 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 как к технологии. Хочу показать, что находится под капотом у таких систем на примере платформы, которую сами разрабатываем.

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