Size: a a a

Software Design/Architecture/Zen

2021 June 11

JF

Jorik Fat in Software Design/Architecture/Zen
а с ней что не так?
источник

JF

Jorik Fat in Software Design/Architecture/Zen
но это позже. Сейчас давайте не отклоняться от задачи "поиск решений"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
задача менеджера определить лиц которые могут проблему решить, поиск решений на них
источник

JF

Jorik Fat in Software Design/Architecture/Zen
все в один голос "больше серверов"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
может пойти к админам, может пойти к разработчикам которые укажут как одну из опций на админов
источник

SP

Sergey Protko in Software Design/Architecture/Zen
пойдет к админам спросит стоимость и варианты как уменьшить.
источник

JF

Jorik Fat in Software Design/Architecture/Zen
либо: "это не моя задача, я в этом не разбираюсь"
источник

JF

Jorik Fat in Software Design/Architecture/Zen
это какой-то коммуникатор/посыльный, а не менеджер
источник

SP

Sergey Protko in Software Design/Architecture/Zen
например - довольно часто люди разворачивают on-demand инстансы в AWS и не знают что если им инстанс нужен на год можно сделать reserved и платить существенно меньше. Или для CI за 30-40% стоимости можно spot инстансы делать
источник

SP

Sergey Protko in Software Design/Architecture/Zen
это в тебе говорит разработчик который привык что у него сервисы-менеджеры чето делают)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
координация это тоже работа
источник

JF

Jorik Fat in Software Design/Architecture/Zen
ну тогда выходит что менеждеры отвечают чисто за коммуникацию, а не за принятие решение (и как следстие ответственности)?
источник

JF

Jorik Fat in Software Design/Architecture/Zen
согласен. Выступал в роли координатора (вне it)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
если люди не могут договориться - менеджер может разрулить конфликт и указать на решение на основе экономических факторов. Если команда и так в состоянии придти к консенсусу - решение команды че
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Д - делегирование
источник

JF

Jorik Fat in Software Design/Architecture/Zen
а если команда выбирает легкий путь решения (больше серверов), а не правильный (оптимизация)?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
правильная или не правильное определяется экономическими соображениями. Если "больше серверов" это на $500/month больше расходы при профите сокращения сборки в два раза и уменьшении времени ожидания всех (что тоже можно посчитать) а оптимизации сборки это доп риски и непросчитываемые сроки - можно сделать простое решение сейчас и возможно оптимизации если вдруг кто будет простаивать
источник

SP

Sergey Protko in Software Design/Architecture/Zen
железо как правило дешевле.
источник

JF

Jorik Fat in Software Design/Architecture/Zen
т.е. заниматься оптимизацией или нет решает менеджер?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
есть ситуации когда железо не влияет - например ты можешь заскейлиться с какого-нибудь медленного t2.large на c5.4xlarge где CPU быстрее в полтора раза и получишь ускорение в полтора раза, а можно было распаралелить пайплайн что тоже делается дешево
источник