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

Хочется затронуть фактор людской психологии в принятии решений, его недооценку и важность влияния на конечный результат.
Внизу статьи есть тезисное изложение, кому не хочется читать.

Как обычно происходит и почему

Действительно, существует такое распространенное мнение, что железо купить проще и надежнее, чем оптимизировать код.
Другой вопрос, а проводились ли достоверные исследования на эту тему? Думаю, нет, и это только подтверждает тезисы статьи «Программирование, как новый вид человеческой деятельности»

Однако, попробуем построить мысленный эксперимент с некоторыми допущениями. Рынок — это место для естественного отбора. Компании отбираются по признаку выживаемости. Кто обслужил клиента лучше, заработал денег больше и сумел удержаться на рынке, обойти конкурентов — тот и выжил. Обратная связь обеспечивает эволюцию компаний.
И, судя по тому, что компании как инвестируют миллионы долларов как в человеческий потенциал, так и в сервера, имеют место оба подхода, возможно даже их комбинация. О чем было сказано в исходной статье в комментах (комбинации подходов нередки и в других случаях в жизни, например, ястребы и голуби)

Из чего можно заключить, что оба подхода существуют, и есть третий — составляющий пропорцию. И успешность их применения определяется выживанием компании в текущих условиях на рынке, что, разумеется, нельзя свести к простой формуле «что дешевле».

Достаточно только вспомнить, например, фразу «Стратегические просчеты невозможно компенсировать тактическими успехами» фон Клаузевица, а также примеры стратегических решений компаний, не приведших к моментальным сокращениям издержек (Apple: iPad, iPhone, Google: PR, etc), но обеспечивших убедительный успех на рынке.

Проблема замкнутых циклов

Многие вещи к бизнесе и управлении проектами, однако, сводятся к простым моделям. Что, разумеется, не отменяет ограниченность таких моделей.

Смысл простой — у вас есть две и более сущностей, одна из которых не может быть существенно развита без другой. Своеобразный deadlock.
Например, вы — стартапер. Вам нужно нанять программистов, а клиентов еще нет. А клиентов нет, потому что нет продукта, который создает программист свои трудом. И пока не получила распространение идея решения темы через инвесторов, такого обилия стартапов не было.

А вот более сложный пример — выбор архитектуры проекта на незнакомом рынке. Чтобы спроектировать архитектуру, вам нужно получить реальные бизнес-требования. А бизнес-требования появятся, как аппетит, приходящий во время еды, лишь в процессе эксплуатации. Решением является «херак, херак и в продакшн», в более благозвучных названиях у разных специалистов — Agile, Continuos Integration, BDD и тд.

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

Паттерном решения является взять одну из сторон за базовую, и выразить другую через нее с какой-то формулой.

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

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

Эффект упрощения

Существует момент, который я вскользь затронул выше. Дело в том, что мы, по сути дела, моделируем ситуацию в голове. И всегда есть некая ошибка, разница между реальностью и моделью в голове. Об этом нужно помнить, и не сводить проблему ни к принятию однозначного решения, а-ля серебряная пуля, ни к одноразовости применения мер.

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

Равно как и важность труда администраторов (и наем дорогих, хороших, годных админов), без которых плохо настроенные сервера также могут сослужить плохую службку. Например, плохо настроенная БД Постгрес способна убить все плюсы, которая она дала бы при масштабировании.

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

А это вообще не относится ни к оптимизации кода, ни к закупке новых серверов, а при этом может закрыть львиную долю проблем.
Кстати, вы знали, что хороший админ — это обычно великолепный программист, специалист по автоматизации процессов и много в чем еще добрая фея?

Эффект Даннинга-Крюгера

Как уже было отмечено, немаловажным является психология участников процесса.

А точнее, когнитивные искажения

Можно отметить, например, проблему, когда люди тяготеют к уже проверенным решениям, а также то, что в среднем человек не любит рисковать.

Но огромный вред, который лично я отношу к проблемам первого порядка, в переоценке своих возможностей и способностей.
Есть даже специальный эффект, который находится в заголовке, который говорит, что чем умнее и опытнее человек, тем больше он сомневается в своих способностях. А чем он более дилетант — тем более самоуверен и склонен делать неверные выводы и поступки в заданной области деятельности.

Для меня типичным примером является фраза про рефакторинг. Как известно, многое в природе имеет нормальное распределение, в том числе, по некоторым данным — и таланты людей. Как пишет Брукс, способные и рядовые программисты отличаются в производительности в десятки раз.
Можно предположить, что и в качестве работы имеется тоже большой разлет. Правда, в силу отсутствия объективных метрик качества таких исследований мало.

Тем не менее, достаточно типична такая ситуация. Выбор делается в пользу тотальной оптимизации кода. Программистам нечетко ставится задача управленцем, который уверен в своих способностях — просто сказать «сделай рефакторинг, чтобы летало» хватит.
Программисты уламывают управленца «переписать все на ООП на последней версии фреймворка/стандарта» (какой-нибудь простой на красивый, но монструозный и тяжелый Symfony, или переписать старый сишный код на плюсах с демонстрацией знания всего stl), чтобы было «все как в книгах/у гуру» (навтыкаем паттернов).
В итоге пишется код, который тормозит в 10 раз больше, жрет память, процессорное время, но зато который легче поддерживать в разы.

Провалив сроки, начальство приводит более компетентных PMов и архитектора, которые либо делают срочные фиксы и докупают железо, либо переписывают с нуля (как позволяет время).

Для бизнеса ситуация выглядит понятным образом — программисты и ПМы обманули, ничего не улучшили. Пришлось привлекать гуру, а те задорого что-то изменили быстро и купили серверов. Значит, можно и из моих ребят что-то выжать быстро и заставить купить серверов.
При этом, уверенный в себе бизнесмен не слушает слов гуру про «необходимость четкой постановки требований, найма дорогих специалистов, привлечения архитектора для выбора стека технологий в проработке, выделения специальных этапов оптимизации под масштабирование», считая непонятные ему слова очередной уловкой людей на отвлечение ресурсов и потенциально упущенные возможности.

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

Выводы

Изначальная проблема не сводится к простому фактору «что дешевле». А, как и писали и Демарко, и Ашманов, многое лежит в плоскости человеческих отношений, и в плоскости психологи личности участников процесса.

Которой, на мой взгляд, уделяется недостаточное внимание.

Если подытожить

Нижесказанное не касается случаев, например, когда у вас один сайт, который стал тормозить при 1000 посетителей в день, потому что это CMS ***, ****** или *******, и в компании один человек (то есть вы).

1. Перед принятием решения нужен research с участием технических специалистов высокого класса
2. В результате research нужно понять текущую ситуацию и получить от лиц, принимающих решения, дальнейший вектор развития проекта и бизнеса
3. После этого должно появиться понимание:
— какие ресурсы в данный момент могут быть выделены (денежные, людские, временные) на преодоление проблемы
— какие сроки устранения проблемы и внедрения решения
— какие риски и как с ними работать, если текущую проблему преодолеть не удастся
4. Отдельно нужно четкое обозначение требований для исполнителей — программистов, админов. Иногда админы могут спасти ваш проект без закупки серверов или оптимизации кода, просто платите им хорошо. Как и программистам.
5. После этого нужно выполнить итерационное решение проблемы, с каждым разом подбирая оптимальное соотношение ресурсов на оптимизацию кода приложения, тюнинга серверов админами и закупки железа.
6. После достижения требуемых показателей создать бизнес-процесс (или улучшить), направленный на стратегическую работу по качеству для заданных метрик (ожидаемый рост трафика, рост занимаемого места на винтах, и так далее). Процесс должен допускать иногда и полную смену стека технологий при необходимости.

Автор:

Источник