Привет! Меня зовут Михаил Голованов, в Сбертехе я занимаюсь технической архитектурой и перспективными разработками. У нас, как и у любого современного банка, есть множество систем, которые поддерживают разные стороны работы банка: вклады, счета, зачисление денег, кредитование, финансовые рынки, акции и т.д. Всякий раз, когда появляется какая-то новая система, мы начинаем следующий уровень увлекательной игры под названием «Интеграция». И каждый следующий уровень сложнее предыдущего — ведь систем нужно охватывать все больше и больше. Этот пост — то, что в геймерских кругах именуется walkthrough: сначала мы пробежимся по локальным сетям и затем через очереди сообщений перейдем к масштабному этапу потоковых вычислений посредством Apache Kafka в широко распределенных сетях.
Рубрика «Анализ и проектирование систем» - 71
Дао интеграции Сбербанка: от локальных сетей к Kafka и потоковой разработке
2018-04-26 в 6:00, admin, рубрики: big data, Анализ и проектирование систем, Блог компании Сбербанк, потоковая обработка данных, Разработка систем передачи данных, Сбербанк
О бизнес-процессах по-человечески
2018-04-25 в 8:34, admin, рубрики: CRM, CRM-системы, regionsoft crm, Анализ и проектирование систем, бизнес-модели, бизнес-процессы, бизнес-процессы в crm, Блог компании RegionSoft Developer Studio, Терминология ITЧто только не писали на Хабре про бизнес-процессы: про общую философию, про программирование процессов, про многочисленные BPM-системы, про нотации и т.д. В принципе, вендору всё понятно: взял процесс, очистил его от очисток, смоделировал, автоматизировал и запускай экземпляры, когда нужно. Дел-то. Между тем, бизнес, которому статьи адресованы, зачастую не понимает главного — зачем ему эти бизнес-процессы? Он ведь не Газпром какой и не концерн Калашников. Тут бы главные дела решить: чтобы сроки не срывались, сотрудники бы не теряли документы и не валили бы вину друг на друга, а то среди этого бардака уже и прибыли не видно…
Мы решили исправить ситуацию и рассказать о бизнес-процессах максимально просто — так, чтобы каждый смог понять, во благо они бизнесу или ну их, и так нормально сидели. Поэтому сегодня без нотаций, сложных схем и рекламных обзоров. Итак, вводные: «Всё есть процесс», «Процессы есть у всех», «Если вы не любите бизнес-процессы, вы просто не умеете их готовить». Поехали.
Picabu.ru. Типичная организация процесса в компаниях любого уровня: «Лебедь рвется в облака, Рак пятится назад, а Щука тянет в воду. Кто виноват из них, кто прав, — судить не нам; Да только воз и ныне там».
Читать полностью »
История про хранилище изображений. Или как велосипед спас от костыля
2018-04-25 в 4:52, admin, рубрики: Анализ и проектирование систем, Блог компании 2ГИС, высокая производительность, Программирование, Проектирование и рефакторинг, проектирование систем, работа с изображениями, хранение изображений
На днях мы порелизили новую фичу — Дорожные события в навигаторе. Теперь пользователи мобильных приложений могут не только посмотреть на дорожные пробки и места расположения скоростных камер, но и участвовать в обмене информацией на дорогах: указать места ДТП, дорожных работ, перекрытий, а также просто пообщаться. Помимо указанных мест сориентироваться в ситуации помогут добавленные фотографии.
В статье расскажу, как мы разработали сервис, способный хранить миллионы фотографий и обслуживать тысячи запросов в секунду.
Читать полностью »
А не спроектировать ли нам систему для управления производством ИТ продуктов. Часть 1
2018-04-23 в 17:01, admin, рубрики: анализ, Анализ и проектирование систем, проектирование систем, Промышленное программирование, разработка приложений, управление задачами, управление проектами, управление разработкойI Вступление
Ставишь себе невозможную цель и развлекаешься этим, если можешь. Ведь такое занятие интересно само по себе, поскольку изначально перед тобой заведомо невыполнимая задача, а что может быть увлекательней, чем невозможное
Иосиф Александрович Бродский.
За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воотчую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.
Читать полностью »
Go: Хороший, плохой, злой
2018-04-20 в 6:32, admin, рубрики: Go, golang, Анализ и проектирование систем, Блог компании Mail.Ru Group, никто не читает теги, параллельное программирование, Программирование
У Go есть некоторые замечательные свойства, которым посвящён раздел «Хороший». Но когда речь заходит о применении этого языка не для создания API или сетевых серверов (для чего он и был разработан), а для реализации бизнес-логики, то я считаю Gо слишком неуклюжим и неудобным. Хотя даже в рамках сетевого программирования найдётся немало подводных камней как в архитектуре языка, так и в реализации, что делает Go опасным, несмотря на его кажущуюся простоту.
Концепции распределенной архитектуры, с которыми я познакомился при построении крупной системы платежей
2018-04-19 в 17:36, admin, рубрики: uber, Анализ и проектирование систем, высокая производительность, высоконагруженные проекты, проектирование систем, распределенные системыЯ присоединился к Uber два года назад в качестве мобильного разработчика, имеющего некоторый опыт разработки бекенда. Здесь я занимался разработкой функционала платежей в приложении — и по ходу дела переписал само приложение. После чего я перешёл в менеджмент разработчиков и возглавил саму команду. Благодаря этому я смог гораздо ближе познакомиться с бэкендом, поскольку моя команда несёт ответственность за многие системы нашего бэкенда, позволяющие осуществлять платежи.
До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости — такие, например, как согласованность (consistency), доступность (availability) или идемпотентность (idempotency).
В данном посте я собираюсь рассказать про несколько концепций, которые мне потребовалось изучить и применить на практике при построении крупномасштабной высокодоступной распределённой системы платежей, которая сегодня работает в Uber. Это система с нагрузкой до нескольких тысяч запросов в секунду, в которой критическая функциональность платежей должна работать корректно даже в тех случаях, когда перестают работать отдельные части системы.
Полный ли это список? Скорее всего, нет. Однако, если бы лично я сам узнал про эти концепции раньше, это сделало бы мою жизнь гораздо проще.
Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.
Читать полностью »
Архитектура кода
2018-04-18 в 6:11, admin, рубрики: Анализ и проектирование систем, архитектура приложений, интерфейсы, красивый код, Проектирование и рефакторингВ этой статье я хочу поделиться своим личным опытом, связанным с правильной организацией кода (архитектурой). Правильная архитектура существенно упрощает долгосрочную поддержку.
Это очень философская тема, поэтому я не могу предложить ничего более, чем мой субъективный анализ и опыт.
Проблемы, симптомы
Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.
Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.
У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.
Читать полностью »
Книга «Безопасность в PHP» (часть 5). Нехватка энтропии для случайных значений
2018-04-17 в 11:11, admin, рубрики: entropy, php, security, Анализ и проектирование систем, Блог компании Mail.Ru Group, информационная безопасность, никто не читает теги, Программирование
Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)
Книга «Безопасность в PHP» (часть 3)
Книга «Безопасность в PHP» (часть 4)
Случайные значения в PHP повсюду. Во всех фреймворках, во многих библиотеках. Вероятно, вы и сами написали кучу кода, использующего случайные значения для генерирования токенов и солей, а также в качестве входных данных для функций. Также случайные значения играют важную роль при решении самых разных задач:
- Для случайного выбора опций из пула или диапазона известных опций.
- Для генерирования векторов инициализации при шифровании.
- Для генерирования непредсказуемых токенов или одноразовых значений при авторизации.
- Для генерирования уникальных идентификаторов, например ID сессий.Читать полностью »
Пространство состояний в задачах проектирования систем оптимального управления
2018-04-16 в 19:42, admin, рубрики: LQR контроллер, Matlab, python, Анализ и проектирование систем, математика, пространство состояний, разработка под windows, система оптимального управления
Введение
Исследование системы управления во временной области с помощью переменных состояния широко используется в последнее время благодаря простоте проведения анализа.
Состоянию системы соответствует точка в определённом евклидовом пространстве, а поведение системы во времени характеризуется траекторией, описываемой этой точкой.
При этом математический аппарат включает готовые решения по аналоговому и дискретному LQR и DLQR контролерам, фильтра Калмана, и всё это с применением матриц и векторов, что и позволяет записывать уравнения системы управления в обобщённом виде, получая дополнительную информацию при их решении.
Целью данной публикации является рассмотрение решения задач проектирования систем оптимального управления методом описания пространства состояний с использованием программных средств Python.
Читать полностью »
Мясорубка, супер-роботы и НИИ (Не Искусственный Интеллект)
2018-04-16 в 12:51, admin, рубрики: Анализ и проектирование систем, Занимательные задачки, изобретательство, истории из жизни, Проектирование и рефакторинг, рационализация, управление разработкойЕсли вы уже не первый год ведете какой-то проект, поверьте не похож ли он на нож мясорубки из истории №1 или на тарелку из истории №2
Это поможет вам оптимизировать свой проект выкинув из него все лишнее, что только тормозит его.
История №1
Дело было достаточно много лет назад на одном из отечественных заводов. Кроме всего прочего завод выпускал мясорубки, обычные ручные, которые были в каждой советской семье. Выпускались эти мясорубки уже много лет, по одной технологии. Но всегда была одна проблема при их производстве: операция заточки ножа с тыльной стороны, была очень сложной и опасной.
Дело в том, что по технологии нож затачивался с двух сторон, во-первых, со стороны, которая прилегает к сетке (параллельно сетке), во-вторых, с тыльной стороны под углом к сетке. И если с первой частью проблем не было (на наждак укладывали сразу несколько ножей и точили), то вот вторая операция выполнялась исключительно вручную, что было низкопроизводительно и крайне опасно для рабочего.
В 1987 году отдел роботизации и автоматизации завода «Электросила» разработал безумно дорогого супер-робота, который точно повторял движение рук рабочего (напоминаю, что это было 30 лет назад (!)), но его производительность оказалась столь малой, что рабочего вернули на заточку, чуть ли не на следующий день.
Для решения проблемы, был вызван внешний консультант из одного НИИ. Консультант начал свою работу, естественно с анализа….
Читать полностью »