Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Вообще, в исходной статье почти не упоминаются, например, админы.
Админы это тоже люди. Люди и их время всегда дороже.
Если мы точно знаем, что железо нас сейчас спасёт, а конкуренты рядом, вот они, то покупаем железо.
Если у нас «тысячи серверов», то наверное мы уже большая контора и с конкурентами у нас не так напряжённо. Здесь уже можно подумать.
Лично я яростный сторонник рефакторинга/улучшалок, ибо быть «без сапог» напрягает, но опять же надо меру знать — это как сахар или шоколад или алкоголь. Его должно быть в меру.
ps: Простые решения всегда пугают своей простотой и необходимостью взять на себя ответственность.
Специально интересовался. В штатах сервер 24 ядра 48гб памяти 300гб диск стоит грубо $2500. Содержание такого сервера в датацентре в течение года стоит грубо $1000. Исходя из этих цифр, а также зарплаты программиста, можно прикинуть насколько оправдана та или иная оптимизация.
А почему вы не учитываете зарплату админа? БОльшее количество железа требует мониторинга и решения «железных» проблем (замена поломанного, перепрошивка, различные инфраструктурные заботы), плюс ещё рано или поздно понадобиться софт для быстрого разворачивания своего продукта или сервисов необходимых для его работы на все эти серверы.
P.S. хорошие админы тоже недёшевы, а хорошее железо может медленно работать с плохим админом.
P.S. хорошие админы тоже недёшевы, а хорошее железо может медленно работать с плохим админом.
Увеличение занятости админа не линейное.
Скорее, как y=sqrt(x).
Много времени тратится на первоначальную настройку мониторинга и автоматизации.
А потом каждый новый сервер добавляет существенной работы только на старте.
Скорее, как y=sqrt(x).
Много времени тратится на первоначальную настройку мониторинга и автоматизации.
А потом каждый новый сервер добавляет существенной работы только на старте.
Это если админ неглупый и умеет автоматизировать свою работу, я считаю что таких не большинство, а вот большинство как раз делают всё вручную и занятость у них очень даже линейная.
Т.е. большинство админов глупые? :)
Дело не в админах, большинство любых наёмных работников работает неэффективно и этому есть много причин.
Со временем стал замечать, что большинство админов из виденных мной, не стараются «думать вперед».
Как пример, принято решение о закупки нового сервера для БД, Админ активно участвует в обсуждении конфигурации, все прекрасно! Но через какое то время (весьма не долгое) выясняется, что он «Не думал, что база данных будет так быстро расти». Не смотря на неоднократные предупреждения об этом. И даже прямые объяснения. На все был ответ — «Я админ мне лучше знать» и «Ну подумаешь, будет мало увеличим».
В реальности через полгода месячный геморрой с постоянным отсутствием места под базу, и шести часовой простой сайта из за замены винта. А делов-то было, с самого начала подумать и заказать не сто гигабайтный винчестер а терабайтный (хватило бы года на три).
Как пример, принято решение о закупки нового сервера для БД, Админ активно участвует в обсуждении конфигурации, все прекрасно! Но через какое то время (весьма не долгое) выясняется, что он «Не думал, что база данных будет так быстро расти». Не смотря на неоднократные предупреждения об этом. И даже прямые объяснения. На все был ответ — «Я админ мне лучше знать» и «Ну подумаешь, будет мало увеличим».
В реальности через полгода месячный геморрой с постоянным отсутствием места под базу, и шести часовой простой сайта из за замены винта. А делов-то было, с самого начала подумать и заказать не сто гигабайтный винчестер а терабайтный (хватило бы года на три).
Применительно к вашему случаю, я подозреваю что 100 гигабайтный был выбран скоростной, а террабайтный вы только медленный сможете использовать. Так что вы в любом бы случае случае были бы недовольны.
«Ну подумаешь, будет мало увеличим» — правильный подход, если всё правильно заказали, то с этим не должно быть проблем, обычно проблема в том, что «сверху» не выделяют денег на покупку дополнительных дисков для увеличения.
«Ну подумаешь, будет мало увеличим» — правильный подход, если всё правильно заказали, то с этим не должно быть проблем, обычно проблема в том, что «сверху» не выделяют денег на покупку дополнительных дисков для увеличения.
После замены скорость террабайтного винчестера вполне устраивала.
И в конкретном описываемом случае не в деньгах было дело. Да и случай если честно достаточно типичен…
По конкретно тому случаю, скорость диска была не сильно важна. база использовалась как хранилище статистики, то есть в нее писали в 90% случаев, но писали много и храниться оно должно было долго.
Ну и никто никогда не отменял скажем рейд 0 из двух полутерабайтников… если скорость критична, и бекапы два раза в день…
И в конкретном описываемом случае не в деньгах было дело. Да и случай если честно достаточно типичен…
По конкретно тому случаю, скорость диска была не сильно важна. база использовалась как хранилище статистики, то есть в нее писали в 90% случаев, но писали много и храниться оно должно было долго.
Ну и никто никогда не отменял скажем рейд 0 из двух полутерабайтников… если скорость критична, и бекапы два раза в день…
У админов всё тоже весело. До определённого предела добавление серверов бесплатно с точки зрения админского времени. Потом начинает создавать линейную прогрессию, потом оказывается, что когда возникают странные эффекты при авариях и слишком много серверов — это слишком длинный даунтайм. Начинаются супертехнологии управления конфигурациями и автоматизации управления серверами, в которых тоже есть баги, боттлнеки, за которым тоже надо следить, а мониторинг тоже кто-то должен конфигурировать…
Я бы сказал, что рост сложности конфигурации по мере роста числа серверов вообще описывается не в числовых параметрах, а в «эволюционном» виде — когда в какой-то момент сложность оказывается такой, что «админы попроще» могут быть либо на побегушках, либо не подходят, и нужно искать людей.
… Ах, да, админские конфигурации тоже надо рефакторить и тестировать.
Я бы сказал, что рост сложности конфигурации по мере роста числа серверов вообще описывается не в числовых параметрах, а в «эволюционном» виде — когда в какой-то момент сложность оказывается такой, что «админы попроще» могут быть либо на побегушках, либо не подходят, и нужно искать людей.
… Ах, да, админские конфигурации тоже надо рефакторить и тестировать.
В России похожие цифры.
У нас железо подороже, а в штатах зп программистов повыше.
Поэтому в штатах сильнее склоняются в сторону железа, а у нас ещё могут подумать.
У нас железо подороже, а в штатах зп программистов повыше.
Поэтому в штатах сильнее склоняются в сторону железа, а у нас ещё могут подумать.
Отличное дополнение моего первоначального посыла!
В своем посте я сознательно все покрасил в черное и белое, чтобы вызвать у читателей желание подискутировать. И, как мне кажется, я добился своих целей. Как результат, данный пост.
В своем посте я сознательно все покрасил в черное и белое, чтобы вызвать у читателей желание подискутировать. И, как мне кажется, я добился своих целей. Как результат, данный пост.
Нужно не забывать, что если требовать от программистов оптимизировать код, то постепенно они к этому привыкают и начинают писать оптимизированный код автоматически и за то же время.
Просто нужно учитывать сложность алгоритма по памяти, если там какой-нибудь N!, то тут никакого железа не хватит
Вообще-то Agile и Continuous Integration как раз и призваны решить проблемы, цитирую:
Если вместо итерационного решения проблемы, о котором Вы говорите, получается «херак, херак и в продакшн», это довольно грустно… но разве не очевидны выводы? Видимо я Вашу точку зрения не вполне уловил. Решения по технологическому выбору, по выбору алгоритмов в любом случае должны делаться квалифицированными людьми и с осознанием последствий.
А вот итог статьи — абсолютно правильный.
- «бизнес-требования появятся, как аппетит, приходящий во время еды».
- «нужно выполнить итерационное решение проблемы, с каждым разом подбирая оптимальное соотношение ресурсов на оптимизацию кода приложения, тюнинга серверов админами и закупки железа».
Если вместо итерационного решения проблемы, о котором Вы говорите, получается «херак, херак и в продакшн», это довольно грустно… но разве не очевидны выводы? Видимо я Вашу точку зрения не вполне уловил. Решения по технологическому выбору, по выбору алгоритмов в любом случае должны делаться квалифицированными людьми и с осознанием последствий.
А вот итог статьи — абсолютно правильный.
Если упростить (что неверно), то я противопоставил «херак, херак и в продакшн» классическим «сделаем сразу хорошо и правильно» waterfall а-ля RUP.
Ибо первое часто возникает, когда одни хотят запилить мегакрутую реализацию, а злой Тимлид или Скраммастер говорит какие-то слова про эволюционное проектирование, рефакторинг и заставляет выкладывать «неидеальный код». И отсюда и пошла эта тема.
В то же время даже когда спутники и корабли в космос запускали, было много неизвестных. Возможно напишу про это статью, но вкратце суть такова.
1. Делали поэтапно — опытный образец, потом Белки и Стрелки, только потом человек
2. Было много неизвестных, которые определяли проектирование. Например, фраза из википедии
Но — см. эффекты, описанные в статье — в наше время многие упорно полагают, что можно раз и навсегда просчитать «все правильно» и сделать «все хорошо». И любые экспериментальные вещи, сделанные на быструю руку, или же реализации фич для получения денег воспринимаются именно как «вот уроды, херак-херак», без планирования рефакторинга дальше и спокойного отношения к этому.
Я на каждом шагу это встречаю.
Ибо первое часто возникает, когда одни хотят запилить мегакрутую реализацию, а злой Тимлид или Скраммастер говорит какие-то слова про эволюционное проектирование, рефакторинг и заставляет выкладывать «неидеальный код». И отсюда и пошла эта тема.
В то же время даже когда спутники и корабли в космос запускали, было много неизвестных. Возможно напишу про это статью, но вкратце суть такова.
1. Делали поэтапно — опытный образец, потом Белки и Стрелки, только потом человек
2. Было много неизвестных, которые определяли проектирование. Например, фраза из википедии
В связи с этим в ОКБ разгорелись бурные споры и появилось два подхода к созданию спускаемой части станции. Первый подход предполагал толстый слой лунной пыли на поверхности и разработку средств посадки и передвижения по такому слою (например, пылевые катера на архимедовых винтах). Второй — что Луна была захвачена Землёй сравнительно недавно (несколько десятков тысяч лет назад, о чём говорили и легенды некоторых народов, в частности, догонов и о чём было известно С. П. Королёву), поэтому поверхность Луны, соответственно, твёрдая, на что и можно рассчитывать при посадке. Поскольку имела место явная нехватка подтверждённых научных данных, ни один подход не мог взять вверх, а разумно учесть оба по техническим причинам было невозможно. Известно, что в этих условиях С. П. Королёв принял волевое решение считать поверхность Луны твёрдой и рассчитывать станцию соответственно.
Но — см. эффекты, описанные в статье — в наше время многие упорно полагают, что можно раз и навсегда просчитать «все правильно» и сделать «все хорошо». И любые экспериментальные вещи, сделанные на быструю руку, или же реализации фич для получения денег воспринимаются именно как «вот уроды, херак-херак», без планирования рефакторинга дальше и спокойного отношения к этому.
Я на каждом шагу это встречаю.
Технология «херак, херак и в продакшн» звучит более благозвучно в варианте «херак, херак и на продакшн» (меньше согласных подряд).
Судя по комментариям, я придерживаюсь какой-то непопулярной точки зрения — я просто не понимаю актуальности этой проблемы. Мне кажется, что в настоящее время проблема «железо vs. оптимизации» слишком преувеличивается по инерции. Я вокруг себя вижу такую картину.
1. Пилим фичи A, B, C.
2. Нагрузка вырастает, поднимаем новые машины (или запускаем более мощные вместо старых).
3. Через некоторое время приходит финансово заинтересованная сторона и говорит: «Мужики, в этом периоде чек вырос, надо чото делать»
4. Временно откладываем фичи D и E, идем уменьшать чек.
При чем тут админы или программисты — не понимаю, честно говоря, вообще. Уверен, что они не должны иметь отношения к данному выбору.
1. Пилим фичи A, B, C.
2. Нагрузка вырастает, поднимаем новые машины (или запускаем более мощные вместо старых).
3. Через некоторое время приходит финансово заинтересованная сторона и говорит: «Мужики, в этом периоде чек вырос, надо чото делать»
4. Временно откладываем фичи D и E, идем уменьшать чек.
При чем тут админы или программисты — не понимаю, честно говоря, вообще. Уверен, что они не должны иметь отношения к данному выбору.
Ну не скажите… опять же из собственной практики.
Небольшая оптимизация загрузки JS и CSS файлов позволила сократить трафик на 12 гигабайт в сутки… Работы было чуть-чуть… где-то на пару часов. А эффект был огромный. Сайт вдруг перестал тормозить! (Тормозил он из за забитости канала.)
Небольшая оптимизация загрузки JS и CSS файлов позволила сократить трафик на 12 гигабайт в сутки… Работы было чуть-чуть… где-то на пару часов. А эффект был огромный. Сайт вдруг перестал тормозить! (Тормозил он из за забитости канала.)
Это вполне укладывается в тот вариант, который я описал =) Просто тогда бы финансово заинтересованная сторона пришла бы со словами «Чото тормозит», а не «Чото дорого». Я лишь про то, что программистам и опсам не нужно брать на себя лишнее, и не решать за финансово ответственных людей, что нужно им. Сейчас, когда виртуализация и всякие облака перестали быть чем-то диковинным и пугающим, вопрос «покупки железа» воникает гораздо реже, чем раньше. Написали максимально приемлемо на данный момент. Не тянет? Увеличили машину. Трафик не пролазит? Напрягли CDN. Дорого получилось? Начинаем новую итерацию.
Логично, и тут я с Вами полностью согласен!
Но не стоит сбрасывать со счетов некоторую паранойю… «Как так мои данные будут храниться неизвестно где? А если их там будут читать (кто нужное подставить)»
В таком случае начинается беготня с обычными железками… Тоже бывало к сожалению…
Но не стоит сбрасывать со счетов некоторую паранойю… «Как так мои данные будут храниться неизвестно где? А если их там будут читать (кто нужное подставить)»
В таком случае начинается беготня с обычными железками… Тоже бывало к сожалению…
Я всегда называю это не «паранойей», а технологическим варварством и вспоминаю такую аргументацию как страшный сон.
Боюсь Вас разочаровать, это именно психическое заболевание той или иной степени тяжести.
Самый тяжёлый случай был когда заказчик, заказывая сайт передал дизайн в котором ВСЕ реальные сообщения были заменены на аналогичные по количеству символов наборы букв… Я несколько месяцев программировал этот сайт (вполне успешно и за хорошие деньги) но так и не узнал о чем он будет.
Формулировка — «Что бы конкуренты идею не украли»
Кстати заказчик оказался несколько щедрее чем я сам оценил работу над сайтом. Видимо понимал, как это смотрится со стороны…
Самый тяжёлый случай был когда заказчик, заказывая сайт передал дизайн в котором ВСЕ реальные сообщения были заменены на аналогичные по количеству символов наборы букв… Я несколько месяцев программировал этот сайт (вполне успешно и за хорошие деньги) но так и не узнал о чем он будет.
Формулировка — «Что бы конкуренты идею не украли»
Кстати заказчик оказался несколько щедрее чем я сам оценил работу над сайтом. Видимо понимал, как это смотрится со стороны…
Пути заказчика неисповедимы. Насчет всихического расстройства — все-таки соглашусь, потому как сам наблюдал достаточно интересные вещи. Обычно, когда звучит фраза «как это мы будем хранить данные 'неизвестно где'», предпочитаю бежать от заказчика куда глаза глядят. Потому что потом, скорее всего, последуют оригинальные предложения, типа:
1. Мы не будем использовать тут никакую стороннюю библиотеку. Это надо написать с нуля самостоятельно. Вдруг потом нашим программистам понадобится что-то поменять? Как они потом будут разбираться в коде какой-то сторонней библиотеки? (на вопрос: «А какая разница, в каком коде разбираться?», почему-то обижаются).
2. Для того, чтобы использовать эту технологию, нам нужно учить своих инженеров. Зачем нам это надо? А вдруг они выучатся и уйдут к конкурентам?
Ну и так далее. В общем-то, легко догадаться, что в итоге эти горе-заказчики так и остались на том месте, где были.
Короче, каша в головах может быть у всех. И у управленцев, и у программистов. С этим можно жить с горем пополам, но смешивать эти каши не нужно.
1. Мы не будем использовать тут никакую стороннюю библиотеку. Это надо написать с нуля самостоятельно. Вдруг потом нашим программистам понадобится что-то поменять? Как они потом будут разбираться в коде какой-то сторонней библиотеки? (на вопрос: «А какая разница, в каком коде разбираться?», почему-то обижаются).
2. Для того, чтобы использовать эту технологию, нам нужно учить своих инженеров. Зачем нам это надо? А вдруг они выучатся и уйдут к конкурентам?
Ну и так далее. В общем-то, легко догадаться, что в итоге эти горе-заказчики так и остались на том месте, где были.
Короче, каша в головах может быть у всех. И у управленцев, и у программистов. С этим можно жить с горем пополам, но смешивать эти каши не нужно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему нет простых решений о том, что лучше — купить серверов или оптимизировать код