В ответ вот на эту статью, про выбор покупки серверов или оптимизации.
Хочется затронуть фактор людской психологии в принятии решений, его недооценку и важность влияния на конечный результат.
Внизу статьи есть тезисное изложение, кому не хочется читать.
Действительно, существует такое распространенное мнение, что железо купить проще и надежнее, чем оптимизировать код.
Другой вопрос, а проводились ли достоверные исследования на эту тему? Думаю, нет, и это только подтверждает тезисы статьи «Программирование, как новый вид человеческой деятельности».
Однако, попробуем построить мысленный эксперимент с некоторыми допущениями. Рынок — это место для естественного отбора. Компании отбираются по признаку выживаемости. Кто обслужил клиента лучше, заработал денег больше и сумел удержаться на рынке, обойти конкурентов — тот и выжил. Обратная связь обеспечивает эволюцию компаний.
И, судя по тому, что компании как инвестируют миллионы долларов как в человеческий потенциал, так и в сервера, имеют место оба подхода, возможно даже их комбинация. О чем было сказано в исходной статье в комментах (комбинации подходов нередки и в других случаях в жизни, например, ястребы и голуби).
Из чего можно заключить, что оба подхода существуют, и есть третий — составляющий пропорцию. И успешность их применения определяется выживанием компании в текущих условиях на рынке, что, разумеется, нельзя свести к простой формуле «что дешевле».
Достаточно только вспомнить, например, фразу «Стратегические просчеты невозможно компенсировать тактическими успехами» фон Клаузевица, а также примеры стратегических решений компаний, не приведших к моментальным сокращениям издержек (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. После достижения требуемых показателей создать бизнес-процесс (или улучшить), направленный на стратегическую работу по качеству для заданных метрик (ожидаемый рост трафика, рост занимаемого места на винтах, и так далее). Процесс должен допускать иногда и полную смену стека технологий при необходимости.
Хочется затронуть фактор людской психологии в принятии решений, его недооценку и важность влияния на конечный результат.
Внизу статьи есть тезисное изложение, кому не хочется читать.
Как обычно происходит и почему
Действительно, существует такое распространенное мнение, что железо купить проще и надежнее, чем оптимизировать код.
Другой вопрос, а проводились ли достоверные исследования на эту тему? Думаю, нет, и это только подтверждает тезисы статьи «Программирование, как новый вид человеческой деятельности».
Однако, попробуем построить мысленный эксперимент с некоторыми допущениями. Рынок — это место для естественного отбора. Компании отбираются по признаку выживаемости. Кто обслужил клиента лучше, заработал денег больше и сумел удержаться на рынке, обойти конкурентов — тот и выжил. Обратная связь обеспечивает эволюцию компаний.
И, судя по тому, что компании как инвестируют миллионы долларов как в человеческий потенциал, так и в сервера, имеют место оба подхода, возможно даже их комбинация. О чем было сказано в исходной статье в комментах (комбинации подходов нередки и в других случаях в жизни, например, ястребы и голуби).
Из чего можно заключить, что оба подхода существуют, и есть третий — составляющий пропорцию. И успешность их применения определяется выживанием компании в текущих условиях на рынке, что, разумеется, нельзя свести к простой формуле «что дешевле».
Достаточно только вспомнить, например, фразу «Стратегические просчеты невозможно компенсировать тактическими успехами» фон Клаузевица, а также примеры стратегических решений компаний, не приведших к моментальным сокращениям издержек (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. После достижения требуемых показателей создать бизнес-процесс (или улучшить), направленный на стратегическую работу по качеству для заданных метрик (ожидаемый рост трафика, рост занимаемого места на винтах, и так далее). Процесс должен допускать иногда и полную смену стека технологий при необходимости.
