Согласен. Ну в 20 раз могут сеньоры ближе к архитектору, или архитекторы с ИИ в качестве разработчика. Я лично в состоянии жанглировать 5 агентами на одном проекте, каждый из который решает задачи минимум в 5 раз быстрее моих разработчиков. в итоге Я + 5 агентов работают, ну как 25 разработчиков. Если вычесть отсюда мою ЗП в пересчёте на разработчика получается что, ну вот ИИ рядом со мной работает за 20 человек.
В целом история с тем, как создавать среду в которых инженеры расцветают растут и развивается не такой уж и большой секрет. А скрам в целом работает только под свои задачи.
Но если у вас водопад, горящие задние места и нет никакой оценки, а из людей ногами выбивают сроки в которые они никогда не попадают, а потом пинают их этими же ногами из-за того что они в выбитые сроки не попали, то мотивированной команды не будет никогда. То есть даже хуже - если в такую среду поместить мотивированную команду она через некоторое время станет немотивированной.
Так что тут не "пререквизиты", а скорее "постреквизиты". В хорошой среде немотивированные становятся мотивированным, в плохой - всё тонет что туда не брось.
Именно так. Просто есть иллюзии в индустрии, о том что можно взять AI и засунув в не мотивированную команду получить прирост в производительности. Так вот нельзя.
Да! Я тоже стараюсь давно максимально мягко общаться с нейросетью, иначе она пугается и начинает творить такую дичь... Мягкое обращение действительно помогает, но не решает проблему полностью. Особенно когда ты хочешь чтобы ты ушёл на час, пришёл обратно и всё работает без скрытых косяков и проблем заметенных под ковёр.
На оракле был рак из 2х узлов 4TB RAM 192 ядра 8 сокетов с гипертрейдингом 382 на каждом сервере. На шардмане 19 узлов по 48 ядер (2 сокета, с гирертредингом 96) с 1.5TB RAM. По ресурсам на новом кластере с запасом, но он стоит почти не нагруженный. То есть фактическое потребление ресурсов не то чтобы увеличилось.
А в каком месте не хватает документации по c2g НСПК, на стороне интеграции с НСПК? Я знаю людей в центробанке которые заведуют проектом, могу передать весточку если есть возможность ее предметно сформулировать.
РТЛабс является давним партнером ФК по разработке и эксплуатации, ставит минимальные цены и честно выигрывает контракты на конкурсах без откатов. На самом деле мы работаем четко в рамках зафиксированных возможностей ФК и пытаемся поставить максимум возможного в рамках их не гибких бюджетов. Поскольку мы ничего не завышаем нет ни торга ни отскоков, потому что отскакивать нам собственно некуда, цены и так минимальные.
Почему минимальные? Потому что нам важнее крепкое долгосрочное партнерство и репутация, чем сиюминутная выгода. Мы же дочка Ростелекома как-никак, у нас стратегические цели и подходы в безусловном приоритете.
Как показывает печальная практика совмещать апгрейд архитектурный системы с крупной миграцией всегда плохая рискованная затея.
Даже несмотря на то, что иногда кажется это единственный момент для этого.
В это проекте мы даже пытаясь этого не делать, даже то немного концептуально переписанное что включили, после первого переключения (я упоминал первый не до конца удачный запуск) отключили и откатили на стабильную старую версию со старым подходом чтобы завершить миграцию.
Не смотря на то, что софт который не взлетел был не наш, а нашего субподрядчика, все равно было очень больно.
К сожалению когда архитектура системы развивается год за годом без переосмысления получаются вот такие монстры, я согласен. Есть некоторая вероятность, что мы такое переосмысление запустим в следующем году с ФК.
Хотели бы собрать рабочую группы для выработки концептуально новой версии форматов? Это могло бы быть очень интересно!
Shardman уже взрослый и стабильный и это наша отечественная разработка. Вы бы хотели увидеть на рынке РФ нашу собственную с первого байта БД которая готова впитать 200ТБ данных?
Активные начисления в данный момент не отделены от архива, потому что такое разделение повлечет за собой переработку всей системы, ФК пока что не готовы на это идти.
Была идея переложить все начисления (включая активные) в DataLake, а в БД держать исключительно только активные. Это открыло бы большие возможности для анализа и снизило бы количество данных в активной базе. Но пока что это остается только проектом.
Вы знаете не смотря на то, что Казначейство "ворочяет" триллионами наших суверенных финансов, финансирование развитийных проектов у них проходит весьма сдержанно и осознанно. Сейчас в подобной оптимизации большой потребности нет и по этому ФК в это не вкладываются.
Второй момент: первоначально в Оракл база данных была сильно нормализована и каждый атрибут каждого начисления и каждого платежа хранился отдельной записью. Ну и записей таких на примерно 13 миллиардов начислений и платежей (Вы правы в порядках) было несколько сотен миллиардов строк атрибутов. Ну и конечно же индексы атрибутов нещадно тормозили. По итогу мы эту нормализацию убрали и положили атрибуты в jsonb прямо в объекты начислений и платежей. Места мы не сэкономили, но бутылочное горлышко убрали.
А какое количество данных и на каких мощностях вы реконсилировали в продакшне? Поставили ли этот подход на поток, как отображаете результаты реконсиляции?
Я думаю можно было еще указать в статье, что при наличии адаптеров при расхождении, можно потом по id этих записей выбрать их из адаптеров и глазами на них посмотреть (если сделать в адаптере поддержку не только выборку по диапазону дат, но еще и по массиву id).
Информация
В рейтинге
573-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Согласен. Ну в 20 раз могут сеньоры ближе к архитектору, или архитекторы с ИИ в качестве разработчика. Я лично в состоянии жанглировать 5 агентами на одном проекте, каждый из который решает задачи минимум в 5 раз быстрее моих разработчиков. в итоге Я + 5 агентов работают, ну как 25 разработчиков. Если вычесть отсюда мою ЗП в пересчёте на разработчика получается что, ну вот ИИ рядом со мной работает за 20 человек.
Дело в том, что оператор станка такого или другого не может уйти и открыть свой завод.
А хороший ИИ инженер может.
В целом история с тем, как создавать среду в которых инженеры расцветают растут и развивается не такой уж и большой секрет. А скрам в целом работает только под свои задачи.
Но если у вас водопад, горящие задние места и нет никакой оценки, а из людей ногами выбивают сроки в которые они никогда не попадают, а потом пинают их этими же ногами из-за того что они в выбитые сроки не попали, то мотивированной команды не будет никогда. То есть даже хуже - если в такую среду поместить мотивированную команду она через некоторое время станет немотивированной.
Так что тут не "пререквизиты", а скорее "постреквизиты". В хорошой среде немотивированные становятся мотивированным, в плохой - всё тонет что туда не брось.
И такое бывает. Согласен.
Именно так. Просто есть иллюзии в индустрии, о том что можно взять AI и засунув в не мотивированную команду получить прирост в производительности. Так вот нельзя.
Как говорится, у плохому (немотивированному) танцору всегда что-то мешает.
А мотивированному не мешает.
Потому что мотивированный ищет способы, а не мотивированный отговорки.
И проблема не в том, что не мотивированный - "плохо". Проблема в том какая среда его окружает.
Да! Я тоже стараюсь давно максимально мягко общаться с нейросетью, иначе она пугается и начинает творить такую дичь... Мягкое обращение действительно помогает, но не решает проблему полностью. Особенно когда ты хочешь чтобы ты ушёл на час, пришёл обратно и всё работает без скрытых косяков и проблем заметенных под ковёр.
Отличный инструмент! По началу непривычно, хочется личного сервиса, но предпосылки ясны и быстро привыкаешь.
На оракле был рак из 2х узлов 4TB RAM 192 ядра 8 сокетов с гипертрейдингом 382 на каждом сервере. На шардмане 19 узлов по 48 ядер (2 сокета, с гирертредингом 96) с 1.5TB RAM. По ресурсам на новом кластере с запасом, но он стоит почти не нагруженный. То есть фактическое потребление ресурсов не то чтобы увеличилось.
А в каком месте не хватает документации по c2g НСПК, на стороне интеграции с НСПК? Я знаю людей в центробанке которые заведуют проектом, могу передать весточку если есть возможность ее предметно сформулировать.
РТЛабс является давним партнером ФК по разработке и эксплуатации, ставит минимальные цены и честно выигрывает контракты на конкурсах без откатов. На самом деле мы работаем четко в рамках зафиксированных возможностей ФК и пытаемся поставить максимум возможного в рамках их не гибких бюджетов. Поскольку мы ничего не завышаем нет ни торга ни отскоков, потому что отскакивать нам собственно некуда, цены и так минимальные.
Почему минимальные? Потому что нам важнее крепкое долгосрочное партнерство и репутация, чем сиюминутная выгода. Мы же дочка Ростелекома как-никак, у нас стратегические цели и подходы в безусловном приоритете.
Как показывает печальная практика совмещать апгрейд архитектурный системы с крупной миграцией всегда
плохаярискованная затея.Даже несмотря на то, что иногда кажется это единственный момент для этого.
В это проекте мы даже пытаясь этого не делать, даже то немного концептуально переписанное что включили, после первого переключения (я упоминал первый не до конца удачный запуск) отключили и откатили на стабильную старую версию со старым подходом чтобы завершить миграцию.
Не смотря на то, что софт который не взлетел был не наш, а нашего субподрядчика, все равно было очень больно.
К сожалению когда архитектура системы развивается год за годом без переосмысления получаются вот такие монстры, я согласен. Есть некоторая вероятность, что мы такое переосмысление запустим в следующем году с ФК.
Хотели бы собрать рабочую группы для выработки концептуально новой версии форматов? Это могло бы быть очень интересно!
Shardman уже взрослый и стабильный и это наша отечественная разработка. Вы бы хотели увидеть на рынке РФ нашу собственную с первого байта БД которая готова впитать 200ТБ данных?
Спасибо за вопрос! Тут есть два момента.
Активные начисления в данный момент не отделены от архива, потому что такое разделение повлечет за собой переработку всей системы, ФК пока что не готовы на это идти.
Была идея переложить все начисления (включая активные) в DataLake, а в БД держать исключительно только активные. Это открыло бы большие возможности для анализа и снизило бы количество данных в активной базе. Но пока что это остается только проектом.
Вы знаете не смотря на то, что Казначейство "ворочяет" триллионами наших суверенных финансов, финансирование развитийных проектов у них проходит весьма сдержанно и осознанно. Сейчас в подобной оптимизации большой потребности нет и по этому ФК в это не вкладываются.
Второй момент: первоначально в Оракл база данных была сильно нормализована и каждый атрибут каждого начисления и каждого платежа хранился отдельной записью. Ну и записей таких на примерно 13 миллиардов начислений и платежей (Вы правы в порядках) было несколько сотен миллиардов строк атрибутов. Ну и конечно же индексы атрибутов нещадно тормозили. По итогу мы эту нормализацию убрали и положили атрибуты в jsonb прямо в объекты начислений и платежей. Места мы не сэкономили, но бутылочное горлышко убрали.
Не могли бы вы утонить что вы имеете в виду более подробно?
На данном проекте нет. В Госуслугах смотрели на него, решение понравилось, цена не понравилась.