Почему нет простых решений о том, что лучше — купить серверов или оптимизировать код

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

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

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


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

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

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

    Достаточно только вспомнить, например, фразу «Стратегические просчеты невозможно компенсировать тактическими успехами» фон Клаузевица, а также примеры стратегических решений компаний, не приведших к моментальным сокращениям издержек (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. После достижения требуемых показателей создать бизнес-процесс (или улучшить), направленный на стратегическую работу по качеству для заданных метрик (ожидаемый рост трафика, рост занимаемого места на винтах, и так далее). Процесс должен допускать иногда и полную смену стека технологий при необходимости.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 37

      +5
      Вообще, в исходной статье почти не упоминаются, например, админы.


      Админы это тоже люди. Люди и их время всегда дороже.

      Если мы точно знаем, что железо нас сейчас спасёт, а конкуренты рядом, вот они, то покупаем железо.

      Если у нас «тысячи серверов», то наверное мы уже большая контора и с конкурентами у нас не так напряжённо. Здесь уже можно подумать.

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

      ps: Простые решения всегда пугают своей простотой и необходимостью взять на себя ответственность.
        +4
        нет ничего более долговечного чем временное решение :)
          0
          Согласен, что тоже потенциальный минус этого варианта, но на то и нужны ответственные люди, которые понимают что делают.

          Волков бояться — шампанцкого не пить. (с)
          0
          На моём предприятии, оставшийся жить ещё в советской эпохе, время и желания людей не имеют значения. Могут купить железо на миллионы, а потом удивиться, что нет людей, могущих обслужить её.
          Идиотизм? Вот так и живём.
            0
            Здесь как раз клинический случай. Можем только посочувствовать. Такому болоту только осушение помогает.
              0
              У меня наоборот
              Железо ни когда не купят, ну либо спустя год после заказа этого железа (в идеале)
          0
          Специально интересовался. В штатах сервер 24 ядра 48гб памяти 300гб диск стоит грубо $2500. Содержание такого сервера в датацентре в течение года стоит грубо $1000. Исходя из этих цифр, а также зарплаты программиста, можно прикинуть насколько оправдана та или иная оптимизация.
            –1
            А почему вы не учитываете зарплату админа? БОльшее количество железа требует мониторинга и решения «железных» проблем (замена поломанного, перепрошивка, различные инфраструктурные заботы), плюс ещё рано или поздно понадобиться софт для быстрого разворачивания своего продукта или сервисов необходимых для его работы на все эти серверы.

            P.S. хорошие админы тоже недёшевы, а хорошее железо может медленно работать с плохим админом.
              –1
              Увеличение занятости админа не линейное.
              Скорее, как y=sqrt(x).
              Много времени тратится на первоначальную настройку мониторинга и автоматизации.
              А потом каждый новый сервер добавляет существенной работы только на старте.
                –1
                Это если админ неглупый и умеет автоматизировать свою работу, я считаю что таких не большинство, а вот большинство как раз делают всё вручную и занятость у них очень даже линейная.
                  –1
                  Т.е. большинство админов глупые? :)
                    –1
                    Дело не в админах, большинство любых наёмных работников работает неэффективно и этому есть много причин.
                      0
                      Со временем стал замечать, что большинство админов из виденных мной, не стараются «думать вперед».
                      Как пример, принято решение о закупки нового сервера для БД, Админ активно участвует в обсуждении конфигурации, все прекрасно! Но через какое то время (весьма не долгое) выясняется, что он «Не думал, что база данных будет так быстро расти». Не смотря на неоднократные предупреждения об этом. И даже прямые объяснения. На все был ответ — «Я админ мне лучше знать» и «Ну подумаешь, будет мало увеличим».
                      В реальности через полгода месячный геморрой с постоянным отсутствием места под базу, и шести часовой простой сайта из за замены винта. А делов-то было, с самого начала подумать и заказать не сто гигабайтный винчестер а терабайтный (хватило бы года на три).
                        0
                        Применительно к вашему случаю, я подозреваю что 100 гигабайтный был выбран скоростной, а террабайтный вы только медленный сможете использовать. Так что вы в любом бы случае случае были бы недовольны.
                        «Ну подумаешь, будет мало увеличим» — правильный подход, если всё правильно заказали, то с этим не должно быть проблем, обычно проблема в том, что «сверху» не выделяют денег на покупку дополнительных дисков для увеличения.
                          +1
                          После замены скорость террабайтного винчестера вполне устраивала.
                          И в конкретном описываемом случае не в деньгах было дело. Да и случай если честно достаточно типичен…
                          По конкретно тому случаю, скорость диска была не сильно важна. база использовалась как хранилище статистики, то есть в нее писали в 90% случаев, но писали много и храниться оно должно было долго.
                          Ну и никто никогда не отменял скажем рейд 0 из двух полутерабайтников… если скорость критична, и бекапы два раза в день…
                            0
                            Тогда больше не доверяйте выбор железа вашему админу =)
                              0
                              К сожалению по железкам у программиста очень часто голос только совещательный. Если вообще его спрашивают.
                    0
                    У админов всё тоже весело. До определённого предела добавление серверов бесплатно с точки зрения админского времени. Потом начинает создавать линейную прогрессию, потом оказывается, что когда возникают странные эффекты при авариях и слишком много серверов — это слишком длинный даунтайм. Начинаются супертехнологии управления конфигурациями и автоматизации управления серверами, в которых тоже есть баги, боттлнеки, за которым тоже надо следить, а мониторинг тоже кто-то должен конфигурировать…

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

                    … Ах, да, админские конфигурации тоже надо рефакторить и тестировать.
                  0
                  В России похожие цифры.
                  У нас железо подороже, а в штатах зп программистов повыше.
                  Поэтому в штатах сильнее склоняются в сторону железа, а у нас ещё могут подумать.
                  +1
                  Отличное дополнение моего первоначального посыла!
                  В своем посте я сознательно все покрасил в черное и белое, чтобы вызвать у читателей желание подискутировать. И, как мне кажется, я добился своих целей. Как результат, данный пост.
                    –3
                    Нужно не забывать, что если требовать от программистов оптимизировать код, то постепенно они к этому привыкают и начинают писать оптимизированный код автоматически и за то же время.
                      +4
                      Мне казалось, что оптимизация — это всегда относительно чего-то. Если сразу написать оптимизированный код, то относительно чего он будет оптимизирован?
                      0
                      Просто нужно учитывать сложность алгоритма по памяти, если там какой-нибудь N!, то тут никакого железа не хватит
                        0
                        /dev/null :)
                        0
                        Вообще-то Agile и Continuous Integration как раз и призваны решить проблемы, цитирую:

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


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

                        А вот итог статьи — абсолютно правильный.
                          0
                          Если упростить (что неверно), то я противопоставил «херак, херак и в продакшн» классическим «сделаем сразу хорошо и правильно» waterfall а-ля RUP.
                          Ибо первое часто возникает, когда одни хотят запилить мегакрутую реализацию, а злой Тимлид или Скраммастер говорит какие-то слова про эволюционное проектирование, рефакторинг и заставляет выкладывать «неидеальный код». И отсюда и пошла эта тема.

                          В то же время даже когда спутники и корабли в космос запускали, было много неизвестных. Возможно напишу про это статью, но вкратце суть такова.
                          1. Делали поэтапно — опытный образец, потом Белки и Стрелки, только потом человек
                          2. Было много неизвестных, которые определяли проектирование. Например, фраза из википедии
                          В связи с этим в ОКБ разгорелись бурные споры и появилось два подхода к созданию спускаемой части станции. Первый подход предполагал толстый слой лунной пыли на поверхности и разработку средств посадки и передвижения по такому слою (например, пылевые катера на архимедовых винтах). Второй — что Луна была захвачена Землёй сравнительно недавно (несколько десятков тысяч лет назад, о чём говорили и легенды некоторых народов, в частности, догонов и о чём было известно С. П. Королёву), поэтому поверхность Луны, соответственно, твёрдая, на что и можно рассчитывать при посадке. Поскольку имела место явная нехватка подтверждённых научных данных, ни один подход не мог взять вверх, а разумно учесть оба по техническим причинам было невозможно. Известно, что в этих условиях С. П. Королёв принял волевое решение считать поверхность Луны твёрдой и рассчитывать станцию соответственно.


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

                          Я на каждом шагу это встречаю.
                          +1
                          Технология «херак, херак и в продакшн» звучит более благозвучно в варианте «херак, херак и на продакшн» (меньше согласных подряд).
                            +1
                            отлично, теперь меня все устраивает
                            0
                            Судя по комментариям, я придерживаюсь какой-то непопулярной точки зрения — я просто не понимаю актуальности этой проблемы. Мне кажется, что в настоящее время проблема «железо vs. оптимизации» слишком преувеличивается по инерции. Я вокруг себя вижу такую картину.

                            1. Пилим фичи A, B, C.
                            2. Нагрузка вырастает, поднимаем новые машины (или запускаем более мощные вместо старых).
                            3. Через некоторое время приходит финансово заинтересованная сторона и говорит: «Мужики, в этом периоде чек вырос, надо чото делать»
                            4. Временно откладываем фичи D и E, идем уменьшать чек.

                            При чем тут админы или программисты — не понимаю, честно говоря, вообще. Уверен, что они не должны иметь отношения к данному выбору.
                              0
                              Ну не скажите… опять же из собственной практики.
                              Небольшая оптимизация загрузки JS и CSS файлов позволила сократить трафик на 12 гигабайт в сутки… Работы было чуть-чуть… где-то на пару часов. А эффект был огромный. Сайт вдруг перестал тормозить! (Тормозил он из за забитости канала.)
                                0
                                Это вполне укладывается в тот вариант, который я описал =) Просто тогда бы финансово заинтересованная сторона пришла бы со словами «Чото тормозит», а не «Чото дорого». Я лишь про то, что программистам и опсам не нужно брать на себя лишнее, и не решать за финансово ответственных людей, что нужно им. Сейчас, когда виртуализация и всякие облака перестали быть чем-то диковинным и пугающим, вопрос «покупки железа» воникает гораздо реже, чем раньше. Написали максимально приемлемо на данный момент. Не тянет? Увеличили машину. Трафик не пролазит? Напрягли CDN. Дорого получилось? Начинаем новую итерацию.
                                  0
                                  Логично, и тут я с Вами полностью согласен!
                                  Но не стоит сбрасывать со счетов некоторую паранойю… «Как так мои данные будут храниться неизвестно где? А если их там будут читать (кто нужное подставить)»
                                  В таком случае начинается беготня с обычными железками… Тоже бывало к сожалению…
                                    0
                                    Я всегда называю это не «паранойей», а технологическим варварством и вспоминаю такую аргументацию как страшный сон.
                                      0
                                      Боюсь Вас разочаровать, это именно психическое заболевание той или иной степени тяжести.
                                      Самый тяжёлый случай был когда заказчик, заказывая сайт передал дизайн в котором ВСЕ реальные сообщения были заменены на аналогичные по количеству символов наборы букв… Я несколько месяцев программировал этот сайт (вполне успешно и за хорошие деньги) но так и не узнал о чем он будет.
                                      Формулировка — «Что бы конкуренты идею не украли»
                                      Кстати заказчик оказался несколько щедрее чем я сам оценил работу над сайтом. Видимо понимал, как это смотрится со стороны…
                                        0
                                        Пути заказчика неисповедимы. Насчет всихического расстройства — все-таки соглашусь, потому как сам наблюдал достаточно интересные вещи. Обычно, когда звучит фраза «как это мы будем хранить данные 'неизвестно где'», предпочитаю бежать от заказчика куда глаза глядят. Потому что потом, скорее всего, последуют оригинальные предложения, типа:
                                        1. Мы не будем использовать тут никакую стороннюю библиотеку. Это надо написать с нуля самостоятельно. Вдруг потом нашим программистам понадобится что-то поменять? Как они потом будут разбираться в коде какой-то сторонней библиотеки? (на вопрос: «А какая разница, в каком коде разбираться?», почему-то обижаются).
                                        2. Для того, чтобы использовать эту технологию, нам нужно учить своих инженеров. Зачем нам это надо? А вдруг они выучатся и уйдут к конкурентам?
                                        Ну и так далее. В общем-то, легко догадаться, что в итоге эти горе-заказчики так и остались на том месте, где были.
                                        Короче, каша в головах может быть у всех. И у управленцев, и у программистов. С этим можно жить с горем пополам, но смешивать эти каши не нужно.
                                          0
                                          Кстати, да. Контора из пункта 2 занималась торговлей и интересовалась одной системой исключительно для внутренней автоматизации =(
                                          Так что паранойя, да.
                                            0
                                            Не знаю реальное объявление или нет, но иногда хочется повесить у заказчика перед глазами — «Больным, просьба не обмениваться симптомами, так как это затрудняет постановку диагноза»

                            Only users with full accounts can post comments. Log in, please.