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

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

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

1. Масштабируемость / Scalability

• Масштабируемость — это способность системы поддерживать возросшую нагрузку путем добавления дополнительных ресурсов
• Примером является добавление дополнительных серверов для обработки увеличившегося веб-траффика
• Что такое масштабируемость и как ее достичь?

2. Балансировка нагрузки / Load Balancing

• Балансировка нагрузки — это разделение входящего сетевого траффика между несколькими серверами для снижения нагрузки на каждый из них (во избежание того, чтобы на один сервер приходилось слишком много траффика)
• Примером является распределение веб-траффика между несколькими экземплярами EC2 с помощью сервиса AWS Elastic Load Balancer (ELB)
• Понимание балансировки нагрузки

Первая часть статьи была опубликована тут: Как вести ИТ-проект если ты не айтишник? (часть 1)

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

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

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

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

Разработку модуля начнем с определения цели, очень тривиально, но правильно поставленная цель, значительно упрощает реализацию. Основной целью модуля будет создание инструмента удобного для пользователя. Легко добавлять, изменять значения аргументов, легко перебирать значения.

Опишем функционал модуля.

Рассмотрим, как может выглядеть работа по созданию ТЗ на несложную программу.

Возьмём калькулятор, который будет выполнять базовые арифметические операции (+, -, *, /).

Работу можно построить в 2 этапа:

Стремительный прогресс больших языковых моделей значительно изменил сферу разработки программного обеспечения с момента появления ChatGPT в конце 2022 года. В 2023 году я модерировал панель с участием Максима Фатеева, соучредителя и генерального директора Temporal IO , «надежной» системы выполнения с открытым исходным кодом для разработки приложений, и Ананда Кулкарни, генерального директора Crowdbotics , платформы для безопасной разработки приложений с использованием систематического повторного использования кода. Оба поделились своими взглядами на влияние ИИ на роль инженеров-программистов.

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

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

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

В этой статье на примере JSON-схемы и спецификации OpenAPI рассматривается проектирование метода REST API с пагинацией, предназначенного для запроса данных из БД.

Данный текст преимущественно ориентирован на начинающих системных аналитиков и всех, кто интересуется проектированием IT-систем.

Я описал свой путь в предыдущей статье https://habr.com/ru/articles/813239/, но если коротко, то моя карьера в сфере информационной безопасности началась, как и у многих, с работы в ИТ-инфраструктуре. Поначалу моя компания занималась тем, что поддерживала стабильность сетей и систем для различных компаний, и регулярно сталкиваясь с типичными проблемами, связанными с кибератаками. Однажды в компании, где штат ИБ был минимален, мы внедрили SIEM — решение, которое, как считалось, должно было кардинально улучшить безопасность. Однако это был дорогостоящий и трудоёмкий процесс. SIEM не только не оправдал ожиданий, но и породил кучу инцидентов, большинство из которых не представляли реальной угрозы. Специалисты тратили время на анализ множества событий, которые, по сути, были незначительными. С каждым новым ложным срабатыванием доверие к системе падало. В конце концов, люди просто начали игнорировать предупреждения, считая, что система безопасна, хотя это было далеко не так.

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

1 Терминология

В «Надежность в процессах. Часть 1» [OpRes24-1] были определены (упрощены): надежность, процесс и надежность в процессах. Надежность – это способность безотказно работать (работать без отказов). Надежность процесса – это как способность безотказно работать («главное процесс»), так и выдавать требуемый результат («главное результат»). Количественно – это вероятность безотказной работы (вероятность застать процесс работоспособным) и вероятность требуемого результата на выходе процесса.

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

Это относится как ИТ-системе (кластер серверов) и не ИТ-системе (сейф), так и к системе процессов (операций) и составных частей процесса, включая его ресурсы.

Если в классической теории надёжности (Надёжность в технике [27.002]) обычно рассматриваются внутренние воздействующие деструктивные факторы на техническую систему типа отказ \ сбой оборудования \ ПО, то «Надежность в процессах и операциях» (операционная надёжность) рассматривает также непреднамеренные ошибки персонала (операционные риски) и внутреннее мошенничество, внешние атаки на процессы компании, клиентов компании (социальная инженерия), стихийные бедствия (техногенные катастрофы). В конечном счете неважно: «система процессов» отказала (не выполнила задачу) из-за какой-либо поломки или из-за ее перегрузки (от нежданного «наплыва клиентов» до DDoS-атаки), поэтому в состав показателей Надежность в процессах добавляем «доступность»:

Эпоха современных хранилищ данных началась с появления реляционных баз данных (далее БД). С появлением бизнес‑аналитики следствием развития БД стала концепция Data Warehouse (корпоративное хранилище данных, DWH).

Дальнейший рост объемов данных, введение термина «большие данные» и разнообразие требований к обработке привели к эволюции архитектур данных.

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

Привет, Хабр! Меня зовут Павел Панкратов, я ведущий инженер-программист в дивизионе искусственного интеллекта YADRO. Этим текстом я запускаю цикл статей — экскурс в особенности работы с SoC, комбинирующей в себе реализованные в «железе» аппаратные блоки (Hard IP’s) и программируемую логику (Soft IP’s). Основная задача, которая объединит все три статьи, — параллельный запуск встраиваемой операционной системы на двух различных по архитектуре процессорах, представленных в виде Hard и Soft IP-блоков.

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

Привет! Меня зовут Кермен, я — аналитик на второй линии SOC. Наша команда исследует данные от инфраструктуры и сервисов Ozon для выявления нелегитимной активности: от нарушения политик информационной безопасности до целенаправленных атак.

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

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

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

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

С ростом объёмов данных и увеличением популярности распределённых систем необходимость в анализе распределённых данных становится всё более актуальной. PostgreSQL, благодаря своему мощному функционалу и гибкости, предлагает инструмент, который значительно облегчает эту задачу — Foreign Data Wrappers (FDW).

FDW позволяет подключаться к удалённым базам данных, как если бы они были локальными таблицами. Это удобно для аналитики, интеграции данных из различных источников и упрощает работу с распределёнными системами. FDW поддерживает не только PostgreSQL, но и другие базы данных, такие как MySQL, SQLite и даже API.

Хочу поделиться своим опытом организации и построения корпоративной базы знаний для продуктовой ИТ-разработки. В конце статьи подведу итоги внедрения такой системы.

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

Привет, Хабр! Меня зовут Анастасия Лестова, я социальный антрополог с техническим бэкграундом. Сегодня я хочу поделиться с вами серией историй о том, как сложный карьерный путь делает исследователей сильнее, и попробую взглянуть на это с позиции антропологии.

Один раз мне задали вопрос: чем бизнес‑аналитик отличается от секретаря? Казалось бы, разработке ПО в России уже больше 2х десятков лет, но роль бизнес‑аналитика до сих пор вызывает вопросы.

В принципе, вместо секретаря можно добавить любую другую профессию и спросить: а чем БА отличается от бухгалтера, от юриста или технического писателя?

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

Кому предложат ЗП 200-, а кому 400+? Собеседование расставит всё на свои места.

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