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

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

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

В настоящее время наша команда в Neoflex выполняет работы по реализации нескольких проектов миграции данных, в рамках которых появляется потребность построения маппинга. Наш опыт основан на проекте крупнейшего в России банка по миграции витрин из СУБД Oracle в СУБД PostgreSQL в рамках импортозамещения отечественным ПО.

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

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

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

Материала вышло многовато, поэтому разбил его на 2 части. В части 1 (этой статье) рассмотрим, почему и зачем вообще публичным API нужна документация, есть ли у нее какие-то отличия от документации внутренних API, а также проанализируем и детально разберем различные подходы к ведению такой документации, попутно познакомившись поближе с полезными инструментами.

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

Часто, в обзорах видов баз данных упоминают реляционные и “другие”, “NoSQL” и т.д., либо приводят самые основные типы СУБД (базы данных), забывая о редких. В данной статье я постараюсь описать максимально полно виды баз данных и привести примеры конкретных реализаций. Разумеется, статья не претендует на всеохватность и классифицировать базы данных можно по разному, в том числе по типам оптимальной нагрузки и т.д., но надеюсь, она даст базовое представление о видах СУБД и принципах их работы.

В статье мы рассмотрим следующие типы баз данных:

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

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

Разработчику с проектированием и документированием решения задачи помогает аналитик.

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

Хочу поделиться с вами Key skils Systems Analyst которые нашла и сформировала для себя, чтобы в дальнейшем можно было легко оценить свой знания по всем пунктам.

Внедрение практически любой ERP-системы требует как ее донастройки, так и доработки. Важное место в ходе имплементации имеют именно программные доработки, занимающие львиную долю проекта по сравнению с активностями кастомизации. От того, как правильно вы подойдете к вопросу планирования и реализации доработок, зависит успех ERP-проекта. Согласно статистике проектов внедрения, более 40% бизнес-потребностей пользователей требуют программной доработки, следовательно качественное планирование работ на проекте немыслимо без унифицированного подхода к оценке плановых трудозатрат на реализацию [1]. В связи с этим, в этой статье хотелось бы затронуть вопрос плановой оценки трудозатрат доработок и донастроек корпоративной информационной системы.

Начнем с основ: потребности заказчика в информационной системе покрываются или ее доработкой, или ее донастройкой, или уже реализованы и не требуют дополнительных усилий. Первые два исхода задают Gap-область, последняя – Fit (рис. 1). Все доделки Gap-области можно классифицировать согласно RICEFS подходу [2], что представляет собой сокращение от англоязычных слов: Report, Interface, Conversion, Enhancement, Form и S (отчет, интерфейс, программа обработки данных, расширение, печатная форма и настройка). Введя термин сложности (низкая, средняя, высокая и очень высокая), можно построить элементарный Оценщик (от английского Estimate, оценивать) [3]. В нем для каждой пары «Тип разработки – сложность» эмпирически задаются плановые трудозатраты для этапов проектирования и разработки, то есть ресурсы функциональных консультантов на фазе дизайна и разработчиков для этапа разработки (табл. 2). Более сложные формы оценщика включают дополнительные параметры: новая разработка или модификация имеющейся, %-переиспользования, а также оценку трудозатрат не только для фаз проектирования и реализации, но и этапов анализа, теста и перехода.

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

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

Документ бизнес-требований (BRD) является отправной точкой для любого программного проекта или бизнес-решения. Благодаря такому документу члены команды приходят к единому мнению о том, что нужно создать, зачем это делать и как этого добиться.

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

Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем. Если кратко, то когда у вас в компании есть бизнес-процесс  регулярно повторяющиеся действия приводящие к нужным и прогнозируемым результатам, и вы хотите (или собственник бизнеса), чтобы эти результаты были лучше, потерь меньше и вообще все были счастливы и купили по ламбаргини, то вам нужна такая команда как наша. Мы помогаем частично или полностью автоматизировать бизнес-процессы компании. 

Эта статья о чек-листе анализа полноты бизнес-требований для проектов цифровой трансформации.

Чем больше людей работает в процессе, тем больше будет эффект от внедрения bpm-системы. Представим, что операционный бизнес – это грузоперевозки,  в бизнесе около 100 000 вагонов. У вас тысячи клиентов и сотни сотрудников. И допустим, что один из процессов – это согласование с клиентом маршрута, по которому пойдет груз. Результат: маршрут согласован, вагоны готовим под погрузку. В процессе участвует несколько отделов, выполняющих различные роли, и ежедневно сотрудники компании делают сотни действий, чтобы добиться результата – такие процессы называют сквозными, они большие, сложные, но жизненно важные для бизнеса. Экономические эффекты в таком проекте можно достичь упростив процесс, сложные или редко используемые шаги сделать понятными для сотрудников. Самый яркий пример – это “Вкусно и точка” *). Они не делают самые вкусные бургеры, зато они делают их быстро и с гарантированным уровнем качества. Сложные процессы упрощены и там, где это возможно, автоматизированы. Поэтому за 5 минут мы можем купить дешевый бургер, а компания на этом зарабатывает миллионы – все счастливы (особенно акционеры))). 

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

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

Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.

Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.

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

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

Идеальная документация должна выполнять две основные функции...

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

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

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