А откуда возьмётся трёхлетняя поддержка у предсерийных образцов Эльбруса, что вы её учитываете в сравнении? Сервер на свежайшем ксеоне (тот же dell r940) будет стоить
а) 12-30 тысяч долларов без поддержки вообще,
б) +$500 баксов челноку
в) +$500 баксов челноку, +примерно по $1000 с каждого сервака Лихачёву, Карчаа и прочим ворам.
Скорей всего, из-за отсутствия рыночной цены у эльбрусов, в пункте В на них можно нагреть намного больше, чем по $1000 с процессора.
Конечно, хотелось бы иметь нужный техпроцесс в России, но с другой стороны, мы же не укоряем Apple и другие fabless компании за то, что они производят свои процессоры и чипы на той же TSMC. «Эльбрус» при этом всё-таки остается отечественной разработкой.
TSMC, это проблема Байкала и его конкуренции с вычислительной мощностью телефонов 2016 года. У Эльбруса же есть проблема посеръёзнее: отсутствие эффективно решаемых ним прикладных задач.
Дык, это было более двадцати лет назад, мир сильно изменился за это время.
Изменился, потребители давно опытным путём узнали, какие задачи VLIW-архитектура решает, какие не решает и сделали выводы о её применимости в своей инфраструктуре.
К слову, после января 2018 г. и череды громких уязвимостей в процессорах, «Эльбрус» внезапно оказался в выигрышной позиции, т.к. ошибки в компиляторе исправлять значительно проще, дешевле и быстрее, чем в кремнии
К слову, та "череда громких уязвимостей" так никем и не была эксплуатирована, патчи на ОС отъели примерно 10% производительности, тем не менее, оставшихся 90% хватает, чтобы Эльбрус внезапно остался там где и был: в рубрике "неликвид".
Производительности же современных «Эльбрусов» вполне достаточно не только для ведомственного применения в условной оборонке, но и чтобы комфортно играть в Doom 3 и другие игры.
Doom 3 вышел в 2004 году. А вот с другими играми уже нюансы:
GTA V 2013г работал в среднем при 23 fps во время езды по городу. Однако в процессе постоянно возникали подтормаживания, а спустя некоторое время игра зависала на длительный период. По словам тестировщика, это может быть как аппаратная проблема самого инженерного образца «Эльбруса», так и баг в Lintel.
ПК с процессором «Эльбрус-16С» обеспечил в Cyberpunk 2077 около 24 fps в закрытом помещении, однако спустя некоторое время игра зависла, как и GTA V. Показатель частоты кадров во встроенном бенчмарке составил 17 fps.
Комфортностью тут и не пахнет, графика в potato mode в виде слайдшоу.
Где гебня и её миньоны, а где рынок? Китай сам начал разворот от рынка назад в пещеру коммунизма - скатертью дорожка, раз мозги не импортозаместили.
Когда Ху Цзиньтао выводили под руки, никто не вникал, что это было. А под руки по сути вывели последнего последователя рыночных реформ Дена Сяопина, развернувших Китай в капиталистическую экономику, открывших дверь к американским и европейским технологиям и вывевшим Китай на второе место в мире по обьему экономики. По сути, на том заседании под руки вывели экономику Китая.
Это какой же адаптивный круиз-контроль может в опережение? Может какой-то может резко обьехать на скорости выскочившего кабана? Или остановиться на светофоре первым (не в зад первому)? Проехать кольцо? Дать общественному транспорту выехать с остановки? Привезти по маршруту на гуглокартах?
На моем Q3 sportback позапрошлого года есть отдельно круиз-контроль, есть даже отдельно детектор дорожных знаков, дублирующий ограничения скорости возле спидометра (правда, ловит знаки с соседней платной трассы, если ехать по левому ряду параллельной бесплатной, но я себя успокаиваю тем, что по пдд нефик в левом ряду все время ехать) но это небо и земля по сравнению с тем "sensor fusion" и юзкейсов, который этот sensor fusion открывает в Тесле.
Как это за тормозами не нужно следить? Автопилот тоже должен быть исправен и багов в нём не должно быть. Предсказуемость автопилота для водителя обуславливается общим контекстом ПДД для автопилота и водителя, что закрепляется взаимным рулепожатием.
Усилитель устроил ДТП - производитель авто ответил за последствия ДТП. Именно так и должно быть.
Но это так не работает. Только если массово много усилителей по одной и той же причине. По такой статье и за автопилот прилетит.
Бойтесь колдоёбин, в отличие от грязи и гололёда они могут выскочить там, где час назад её еще не было. Плюс прокол на скорости вообще не предугадать, если шины не беспрокольные. Даже на банальном аквапланировании можно иной раз нечаянно поседеть.
Замените автопилот на гидроусилитель руля или тормозную систему, к примеру. Поломка в них точно также может привести к смертельной аварии. Получается, после тотала можно сразу сотне производителей претензии высылать?
Вы ударились в параллельный оффтопик, скажу лишь что бывают одиночные эксцессы, а бывают регулярные системы - так можно отличить мух от котлет.
А инженеров сажать нет смысла, в этом был мой изначальный посыл. я скорее ушел в рассуждения на тему именно рук на руле и что они погоды никакой в плане компенсаций не делают.
В целом, я не против компенсаций и более того: ремарка про руки на руле никак не блокирует возможность хоть сейчас подавать на автопилот Теслы в суде. Просто доказать это будет фактически нереально (что с руками на руле, что без них), в отличие от строгой иерархической цепочки отдачи приказов в ВС. Инженер и его коммит нужны только для того, чтоб припереть Теслу к стенке, поэтому, Тесла его просто покроет.
Эм, нет. В любом, думаю, государстве исполнение законного приказа командира не является преступным деянием.
Эм, да. Вы путаете государства с хунтами. В государствах криминальный кодекс выше устава и за выполнение преступного приказа легко пришьют соучастие, если приказ был заведомо преступный.
Никто никогда не судит солдат своей армии за то, что они убивали пришедших к ним в страну солдат противника
Мы вроде как про гражданский самолёт говорим, не перекручивайте.
В 2001г хунта замяла своё преступление своим карманным МАКом.
И да - стрельба по неидентифицированной цели, это преступление.
Тесла, это что-то типа сервала. У неё есть свои комфортные прерии обитания, где её родная экосистема и привычные пищевые цепочки, но любители "понтов" и в Советскую Гавань сервала припрут, чтоб только "дорохо бохато" было, пусть и в клетке. Ей нужна и разметка качественная, и дороги, и культура вождения остальных неавтоматизированных участников пдд.
Не совсем релевантный пример, так как вооруженные силы не являлись изготовителем самолёта в данной схеме. Сбить самолёт, это уже умышленное убийство, гражданский или нет, это уже влияет только на степень вины и наказания.
Здесь же жертвы не в результате умышленного убийства, а в результате намного менее доказуемой статьи, причинение вреда по неосторожности. Особенно сложно доказать, если вред был причинен по неосторожности в одном месте, а действия, приведшие к этому вреду, в другом месте и другое время. Компенсации же завязаны именно на это доказательство, а не на историю с руками за рулём. Если Маск уберет требование держать руки на руле, то это совершенно не будет означать, что тогда можно станет подать на автопилот в суд: всего лишь начнут штрафовать за езду на авто "без рук".
И не иметь ответственности за ДТП под управлением автопилота.
Всё это с руками, на руле и отключениеи за несколько секунд до неизбежной аварии, - лишь подтверждает алчность в сочетании с безответственностью.
Вы так ярко описываете, как-будто разработчики опасных для жизни устройств сплошь и рядом отвечают головой за работу своего продукта. Всё это всего лишь для соответствия нормативной практике эксплуатации средства повышенной опасности в рамках правил дорожного движения, чтобы Тесла оставалась равноценным автомобилем на дороге юридически.
Не сажать никого? Я бы выбрал этот вариант, в случае если машины под управлением автопилота хотя бы в 10 раз реже попадают в аварии, чем машины вообще им не оборудованные.
Здесь непонятно откуда взялась дискриминация, так как машина хоть под управлением автопилота, но при этом и под внимательным контролем водителя ровно также, как и другие участники пдд. Вот когда в пдд введут правила для автопилотов - тогда можно будет снять руки с руля.
Я вот не помню точной модели, но в одном из первых гамма-ножей в начале 90х кто-то из кодеров допустил ошибку, приведшую к переполнению буфера и в результате то время на точке, которое он должен был проводить с минимальной, проводилось на максимальной (стремившейся в бесконечность) мощностью, на столе сгорел минимум один пациент из-за этого. Системы контроля версий тогда еще не придумали, кодера фиг найдешь, вот кого садить? Менеджеров, которые словосочетание "переполнение буфера" от "хливкие шорьки" не отличают? Или если всё-таки найдём того самого low level инженера - посадим его на пятнашку? Как вы это всё себе представляете?
в условиях ограниченности/ложности информации, на основании своего уникального и не релевантного прошлого опыта и под воздействием других таких же людей
Решения можно принимать не только иррационально, но и рационально. Чем больше бизнес принимает иррациональных решений, тем короче и беднее живёт.
либо их наняли под влиянием иррациональных решений (или по злому умыслу)
или же в данный момент их уволили иррациональным решением
Это ложная дихотомия. На самом деле, ничего нерационального скорее всего нет ни в первом, ни во втором решениях - оба эти действия совершены радикально на разных этапах становления Твиттера и принимались с учётом совершенно разных вводных.
Смею предположить, что перед поднятием ставки ФРС Маск не угадал с кредитами, попытался соскочить, когда понял, как сильно рентабельность этого кредита понизится, но не вышло. На мой скромный взгляд, Маск перешёл к простому плану Пи (или Пэ) - людоедское урезание костов по всем возможным направлениям, децимация сервисов и персонала, печенек и work/life баланса, чтобы выдоить из неудачной покупки побыстрее максимум. О удалении ненужного речь идёт только в контексте "под нож всё то, что из нужного у нас ненужнее всего".
При всём этом, проблема рефакторинга процесса взаимодействия приложения из-за кучи (фигурально выражаясь "тысяч и тысяч") RPC запросов, может даже к одному и тому же микросервису, возможно таки и стоит и решать её возможно действительно надо. Решением может быть даже переработка архитектуры ресурсов с rpc на rest и тогда не понадобится ловить колбеки rpc. Количество запросов станет не "тысяча", а "сотни", допустим, но это не камень преткновения настолько серъёзный, чтобы СЕО лез и пытался его разрешить. СЕО должен иметь команду, в которой есть другие люди, которые этим непублично займутся без него. Вся эта публичная возня конкретно с архитектурой и кодом больше похожа на классический маскопиар.
коллективный разум который в своих решениях опирается исключительно на факты и метрики, однако в реальности так никогда не бывает: метрики могут представить в нужном ключе
Мы наверное о каких-то разных метриках говорим, давайте сразу уточним. Есть метрики, собираемые с самих микросервисов, есть аггрегированные метрики, собираемые с бизнес-процессов, в которых участвуют эти самые микросервисы, есть аггрегации бизнес-процессов в более высокоуровневые вплоть до совета директоров (для взаимодействия с ними уже тоже есть специальные микросервисы, как бы смешно это ни звучало) и на определенных уровнях эти метрики превращаются в деньги, а в другой колоночке стоят планы. Как только планы проседают - начинается декомпозиция этих метрик вплоть до конкретных бизнес-процессов или задействованных в них компонентах ПО/микросервисах, которые всю малину держателям бюджета портят.
нормально выкинуть несколько миллионов денег и лет на проект
В компаниях, оперирующих определёнными порядками бюджетов выкинуть несколько миллионов денег и лет на невыстреливший R&D это не "нормально", а "ппц, как легко отделались".
просто потому что кому-то что-то показалось
Чем больше компания, тем сложнее такое провернуть. По опыту работы в разных транснациональных вендорах 5G и телеком операторах, думаю, в Твиттере такое не пройдет 100500 кругов матрицы согласований.
На разных этапах развития продукта бизнес-кейс считается в разных приближениях. После первого года продакшена бизнес-кейс становится наиболее точным, однако взлетит/не взлетит однозначно видно уже после первых пары апдейтов (раз в три месяца). Он может перестать сходиться сразу после запуска, тогда фичу вырезают или проект закрывают.
"просто кому-то что-то показалось" - если в бизнесе допускается такое принятие решений, бизнес долго не просуществует.
по опыту могу сказать что большинство принимаемых решений иррациональны
Я работаю в телекоме с 2001, в мобильном с 2008, сейчас в разработке managed kubernetes продукта для телеком операторов. По опыту, могу сказать что в подавляющем большинстве случаев, когда мне казалось, что кто-то принял иррациональное решение, в результате оказывалось, что я не владел достаточным объемом информации и/или опыта, и/или принятых обязательств, которые имелись в момент принятия решения у принимающего.
Проблема не поддерживать, проблема развивать. Если попытаться формализовать проблему на пальцах, то маркетинг (развитие продукта, владельцы бюджета, заказчики фич) регулярно валят новые маркетинговые запросы на доработку продукта. В режиме нон-стоп продакт овнеры и продакт архитекты разбирают эти запросы и растаскивают по своим продуктам или закрепленными за ними компонентами. За компонентами закреплено по несколько команд и продакт овнер раскидывает по ним фичи, внедрение которых может включать доработку уже существующих сервисов или создание новых.
В код постоянно вносятся изменения и растет-копится технический долг. Это черная дыра технических доделок, которые невозможно продать заказчику, которые или невозможно было предусмотреть заранее или это ожидаемый этап развития, когда надо сменить архитектуру итп. Кодеры кранчат на этот техдолг, в итоге нездоровая история, которую если не контролировать, то она может порвать продукт в кашу.
Специфический комментарий, описывает ситуацию, применимую больше к НКО или госкомпании. В коммерческих компаниях инициатором развития своего продукта является маркетинг, никаких проектов там нет, Твиттер, это продуктовая компания. Появлению сервиса предшествуют корпоративные хороводы десятков разноуровневых, иногда конфликтующих между собой, иногда джуниоров, иногда спецов, маркетинг->бизнес аналитики->солюшен архитекторы продакт овнеры и девелоперы с тестерами все участвуют в обсуждении необходимости новой фичи, это дает понимание команде, как её лучше внедрить, тестерам - на чем расставлять акценты при тестировании итд. Это ещё надо очень постараться найти бюджет, набрать и удержать такую толпу балбесов, чтобы развивать десять никому не нужных сервисов.
Самое сложное в этом - начать, надо убедить окружающих, что ты делаешь что-то полезное
У заказчика новых продуктовых фич, которые могут породить новые сервисы, этот процесс формализован. NPV, IRR, ROI всё это считается в бизнес-кейсе развития продукта. Если сильно упростить: коммерческая компания не может себе позволить развивать ненужные сервисы и скрыть растраты бюджета на это не выйдет. Ненужный сервис тебе просто зарубят прямо на всяких кикоффах и питчингах, так как ты не сможешь сказать, сколько бабла ты инвесторам сделаешь на нем, как это рассказывает маркетинг. А если расскажешь - тебе прийдется это бабло из фичи (и порожденных нею новых сервисов) высосать к концу отчетного периода. Без маркетинговой потребности в развитии продукта новый сервис создать не выйдет по одной простой причине: деньги никто не даст.
ставите себе подходящие планы, получаете премии, выступаете на паре мероприятий - все
и выглядите успешнее, чем
которые таким не занимаются
Эээ, ну откровенный глум же. Все ставят планы которые подходят руководству, и этот мифический менеджер-пройдоха тоже отчитывается своему руководству за деньги деньгами, за расходы доходами, ну. Причем тут премии, которые все получают согласно колдоговору или индивидуальному договору (для топов), а также выступления на непонятных мероприятиях - неясно.
чтобы они выглядели как важная экосистема, но на самом деле обслуживали бы пару запросов в секунду и не требовали бы серьезной квалификации для их развития
Какой-то зашоренный критерий важности. Есть совершенно разные процессы, не все из них внутри твиттера являются хайлоад, у многих разный профиль трафика, есть наверняка и пару запросов в сутки которые обслуживают, тем не менее, важные. И могут быть простыми, не требующими квалификации. Но они должны составлять легитимный, используемый заказчиком в своих экономически измеряемых бизнес-процессах компонент продукта.
Так и появляются команды, увольнения которых никто не заметил.
Какая-то Нарния, если честно. Команда разработчиков, это мягко говоря недешёвое удовольствие, которое очень влетает в копеечку уже в первый месяц их работы и рекуррентно влетает в ту же копеечку каждый последующий месяц, с необходимостью её периодического (пусть и раз в год-два) повышения..
А откуда возьмётся трёхлетняя поддержка у предсерийных образцов Эльбруса, что вы её учитываете в сравнении? Сервер на свежайшем ксеоне (тот же dell r940) будет стоить
а) 12-30 тысяч долларов без поддержки вообще,
б) +$500 баксов челноку
в) +$500 баксов челноку, +примерно по $1000 с каждого сервака Лихачёву, Карчаа и прочим ворам.
Скорей всего, из-за отсутствия рыночной цены у эльбрусов, в пункте В на них можно нагреть намного больше, чем по $1000 с процессора.
TSMC, это проблема Байкала и его конкуренции с вычислительной мощностью телефонов 2016 года. У Эльбруса же есть проблема посеръёзнее: отсутствие эффективно решаемых ним прикладных задач.
Изменился, потребители давно опытным путём узнали, какие задачи VLIW-архитектура решает, какие не решает и сделали выводы о её применимости в своей инфраструктуре.
К слову, та "череда громких уязвимостей" так никем и не была эксплуатирована, патчи на ОС отъели примерно 10% производительности, тем не менее, оставшихся 90% хватает, чтобы Эльбрус внезапно остался там где и был: в рубрике "неликвид".
Doom 3 вышел в 2004 году. А вот с другими играми уже нюансы:
Комфортностью тут и не пахнет, графика в potato mode в виде слайдшоу.
Это ж смотреть, че там с хвостом, догоняет или не.
Где гебня и её миньоны, а где рынок? Китай сам начал разворот от рынка назад в пещеру коммунизма - скатертью дорожка, раз мозги не импортозаместили.
Когда Ху Цзиньтао выводили под руки, никто не вникал, что это было. А под руки по сути вывели последнего последователя рыночных реформ Дена Сяопина, развернувших Китай в капиталистическую экономику, открывших дверь к американским и европейским технологиям и вывевшим Китай на второе место в мире по обьему экономики. По сути, на том заседании под руки вывели экономику Китая.
Это какой же адаптивный круиз-контроль может в опережение? Может какой-то может резко обьехать на скорости выскочившего кабана? Или остановиться на светофоре первым (не в зад первому)? Проехать кольцо? Дать общественному транспорту выехать с остановки? Привезти по маршруту на гуглокартах?
На моем Q3 sportback позапрошлого года есть отдельно круиз-контроль, есть даже отдельно детектор дорожных знаков, дублирующий ограничения скорости возле спидометра (правда, ловит знаки с соседней платной трассы, если ехать по левому ряду параллельной бесплатной, но я себя успокаиваю тем, что по пдд нефик в левом ряду все время ехать) но это небо и земля по сравнению с тем "sensor fusion" и юзкейсов, который этот sensor fusion открывает в Тесле.
Как это за тормозами не нужно следить? Автопилот тоже должен быть исправен и багов в нём не должно быть. Предсказуемость автопилота для водителя обуславливается общим контекстом ПДД для автопилота и водителя, что закрепляется взаимным рулепожатием.
Но это так не работает. Только если массово много усилителей по одной и той же причине. По такой статье и за автопилот прилетит.
Бойтесь колдоёбин, в отличие от грязи и гололёда они могут выскочить там, где час назад её еще не было. Плюс прокол на скорости вообще не предугадать, если шины не беспрокольные. Даже на банальном аквапланировании можно иной раз нечаянно поседеть.
Замените автопилот на гидроусилитель руля или тормозную систему, к примеру. Поломка в них точно также может привести к смертельной аварии. Получается, после тотала можно сразу сотне производителей претензии высылать?
Вы ударились в параллельный оффтопик, скажу лишь что бывают одиночные эксцессы, а бывают регулярные системы - так можно отличить мух от котлет.
А инженеров сажать нет смысла, в этом был мой изначальный посыл. я скорее ушел в рассуждения на тему именно рук на руле и что они погоды никакой в плане компенсаций не делают.
В целом, я не против компенсаций и более того: ремарка про руки на руле никак не блокирует возможность хоть сейчас подавать на автопилот Теслы в суде. Просто доказать это будет фактически нереально (что с руками на руле, что без них), в отличие от строгой иерархической цепочки отдачи приказов в ВС. Инженер и его коммит нужны только для того, чтоб припереть Теслу к стенке, поэтому, Тесла его просто покроет.
Эм, да. Вы путаете государства с хунтами. В государствах криминальный кодекс выше устава и за выполнение преступного приказа легко пришьют соучастие, если приказ был заведомо преступный.
Мы вроде как про гражданский самолёт говорим, не перекручивайте.
В 2001г хунта замяла своё преступление своим карманным МАКом.
И да - стрельба по неидентифицированной цели, это преступление.
Тесла, это что-то типа сервала. У неё есть свои комфортные прерии обитания, где её родная экосистема и привычные пищевые цепочки, но любители "понтов" и в Советскую Гавань сервала припрут, чтоб только "дорохо бохато" было, пусть и в клетке. Ей нужна и разметка качественная, и дороги, и культура вождения остальных неавтоматизированных участников пдд.
Не совсем релевантный пример, так как вооруженные силы не являлись изготовителем самолёта в данной схеме. Сбить самолёт, это уже умышленное убийство, гражданский или нет, это уже влияет только на степень вины и наказания.
Здесь же жертвы не в результате умышленного убийства, а в результате намного менее доказуемой статьи, причинение вреда по неосторожности. Особенно сложно доказать, если вред был причинен по неосторожности в одном месте, а действия, приведшие к этому вреду, в другом месте и другое время. Компенсации же завязаны именно на это доказательство, а не на историю с руками за рулём. Если Маск уберет требование держать руки на руле, то это совершенно не будет означать, что тогда можно станет подать на автопилот в суд: всего лишь начнут штрафовать за езду на авто "без рук".
У комиссии это право неотъемлемо и так.
Мимо кассы. Подконтрольные антирыночной гебне организации не имеют отношения к рынку и свободе торговли.
Вы так ярко описываете, как-будто разработчики опасных для жизни устройств сплошь и рядом отвечают головой за работу своего продукта. Всё это всего лишь для соответствия нормативной практике эксплуатации средства повышенной опасности в рамках правил дорожного движения, чтобы Тесла оставалась равноценным автомобилем на дороге юридически.
Здесь непонятно откуда взялась дискриминация, так как машина хоть под управлением автопилота, но при этом и под внимательным контролем водителя ровно также, как и другие участники пдд. Вот когда в пдд введут правила для автопилотов - тогда можно будет снять руки с руля.
Я вот не помню точной модели, но в одном из первых гамма-ножей в начале 90х кто-то из кодеров допустил ошибку, приведшую к переполнению буфера и в результате то время на точке, которое он должен был проводить с минимальной, проводилось на максимальной (стремившейся в бесконечность) мощностью, на столе сгорел минимум один пациент из-за этого. Системы контроля версий тогда еще не придумали, кодера фиг найдешь, вот кого садить? Менеджеров, которые словосочетание "переполнение буфера" от "хливкие шорьки" не отличают? Или если всё-таки найдём того самого low level инженера - посадим его на пятнашку? Как вы это всё себе представляете?
Всё же
Решения можно принимать не только иррационально, но и рационально. Чем больше бизнес принимает иррациональных решений, тем короче и беднее живёт.
Это ложная дихотомия. На самом деле, ничего нерационального скорее всего нет ни в первом, ни во втором решениях - оба эти действия совершены радикально на разных этапах становления Твиттера и принимались с учётом совершенно разных вводных.
Смею предположить, что перед поднятием ставки ФРС Маск не угадал с кредитами, попытался соскочить, когда понял, как сильно рентабельность этого кредита понизится, но не вышло. На мой скромный взгляд, Маск перешёл к простому плану Пи (или Пэ) - людоедское урезание костов по всем возможным направлениям, децимация сервисов и персонала, печенек и work/life баланса, чтобы выдоить из неудачной покупки побыстрее максимум. О удалении ненужного речь идёт только в контексте "под нож всё то, что из нужного у нас ненужнее всего".
При всём этом, проблема рефакторинга процесса взаимодействия приложения из-за кучи (фигурально выражаясь "тысяч и тысяч") RPC запросов, может даже к одному и тому же микросервису, возможно таки и стоит и решать её возможно действительно надо. Решением может быть даже переработка архитектуры ресурсов с rpc на rest и тогда не понадобится ловить колбеки rpc. Количество запросов станет не "тысяча", а "сотни", допустим, но это не камень преткновения настолько серъёзный, чтобы СЕО лез и пытался его разрешить. СЕО должен иметь команду, в которой есть другие люди, которые этим непублично займутся без него. Вся эта публичная возня конкретно с архитектурой и кодом больше похожа на классический маскопиар.
Мы наверное о каких-то разных метриках говорим, давайте сразу уточним. Есть метрики, собираемые с самих микросервисов, есть аггрегированные метрики, собираемые с бизнес-процессов, в которых участвуют эти самые микросервисы, есть аггрегации бизнес-процессов в более высокоуровневые вплоть до совета директоров (для взаимодействия с ними уже тоже есть специальные микросервисы, как бы смешно это ни звучало) и на определенных уровнях эти метрики превращаются в деньги, а в другой колоночке стоят планы. Как только планы проседают - начинается декомпозиция этих метрик вплоть до конкретных бизнес-процессов или задействованных в них компонентах ПО/микросервисах, которые всю малину держателям бюджета портят.
В компаниях, оперирующих определёнными порядками бюджетов выкинуть несколько миллионов денег и лет на невыстреливший R&D это не "нормально", а "ппц, как легко отделались".
Чем больше компания, тем сложнее такое провернуть. По опыту работы в разных транснациональных вендорах 5G и телеком операторах, думаю, в Твиттере такое не пройдет 100500 кругов матрицы согласований.
На разных этапах развития продукта бизнес-кейс считается в разных приближениях. После первого года продакшена бизнес-кейс становится наиболее точным, однако взлетит/не взлетит однозначно видно уже после первых пары апдейтов (раз в три месяца). Он может перестать сходиться сразу после запуска, тогда фичу вырезают или проект закрывают.
"просто кому-то что-то показалось" - если в бизнесе допускается такое принятие решений, бизнес долго не просуществует.
Я работаю в телекоме с 2001, в мобильном с 2008, сейчас в разработке managed kubernetes продукта для телеком операторов. По опыту, могу сказать что в подавляющем большинстве случаев, когда мне казалось, что кто-то принял иррациональное решение, в результате оказывалось, что я не владел достаточным объемом информации и/или опыта, и/или принятых обязательств, которые имелись в момент принятия решения у принимающего.
Проблема не поддерживать, проблема развивать. Если попытаться формализовать проблему на пальцах, то маркетинг (развитие продукта, владельцы бюджета, заказчики фич) регулярно валят новые маркетинговые запросы на доработку продукта. В режиме нон-стоп продакт овнеры и продакт архитекты разбирают эти запросы и растаскивают по своим продуктам или закрепленными за ними компонентами. За компонентами закреплено по несколько команд и продакт овнер раскидывает по ним фичи, внедрение которых может включать доработку уже существующих сервисов или создание новых.
В код постоянно вносятся изменения и растет-копится технический долг. Это черная дыра технических доделок, которые невозможно продать заказчику, которые или невозможно было предусмотреть заранее или это ожидаемый этап развития, когда надо сменить архитектуру итп. Кодеры кранчат на этот техдолг, в итоге нездоровая история, которую если не контролировать, то она может порвать продукт в кашу.
Специфический комментарий, описывает ситуацию, применимую больше к НКО или госкомпании. В коммерческих компаниях инициатором развития своего продукта является маркетинг, никаких проектов там нет, Твиттер, это продуктовая компания. Появлению сервиса предшествуют корпоративные хороводы десятков разноуровневых, иногда конфликтующих между собой, иногда джуниоров, иногда спецов, маркетинг->бизнес аналитики->солюшен архитекторы продакт овнеры и девелоперы с тестерами все участвуют в обсуждении необходимости новой фичи, это дает понимание команде, как её лучше внедрить, тестерам - на чем расставлять акценты при тестировании итд. Это ещё надо очень постараться найти бюджет, набрать и удержать такую толпу балбесов, чтобы развивать десять никому не нужных сервисов.
У заказчика новых продуктовых фич, которые могут породить новые сервисы, этот процесс формализован. NPV, IRR, ROI всё это считается в бизнес-кейсе развития продукта. Если сильно упростить: коммерческая компания не может себе позволить развивать ненужные сервисы и скрыть растраты бюджета на это не выйдет. Ненужный сервис тебе просто зарубят прямо на всяких кикоффах и питчингах, так как ты не сможешь сказать, сколько бабла ты инвесторам сделаешь на нем, как это рассказывает маркетинг. А если расскажешь - тебе прийдется это бабло из фичи (и порожденных нею новых сервисов) высосать к концу отчетного периода. Без маркетинговой потребности в развитии продукта новый сервис создать не выйдет по одной простой причине: деньги никто не даст.
и выглядите успешнее, чем
Эээ, ну откровенный глум же. Все ставят планы которые подходят руководству, и этот мифический менеджер-пройдоха тоже отчитывается своему руководству за деньги деньгами, за расходы доходами, ну. Причем тут премии, которые все получают согласно колдоговору или индивидуальному договору (для топов), а также выступления на непонятных мероприятиях - неясно.
Какой-то зашоренный критерий важности. Есть совершенно разные процессы, не все из них внутри твиттера являются хайлоад, у многих разный профиль трафика, есть наверняка и пару запросов в сутки которые обслуживают, тем не менее, важные. И могут быть простыми, не требующими квалификации. Но они должны составлять легитимный, используемый заказчиком в своих экономически измеряемых бизнес-процессах компонент продукта.
Какая-то Нарния, если честно. Команда разработчиков, это мягко говоря недешёвое удовольствие, которое очень влетает в копеечку уже в первый месяц их работы и рекуррентно влетает в ту же копеечку каждый последующий месяц, с необходимостью её периодического (пусть и раз в год-два) повышения..