Ну вот мы и приходим к тому, что есть некие общие правила (типа тюнинга сетевой подсистемы, или установки reverse proxy), а есть индивидуальные под задачу.
И в рамках абстрактной темы выбрать CMS невозможно :)
И я бы акцентировал внимание не на ТЗ, а на ТТ.
Большая часть интернета это простые сайты:
а) личные страницы (блог + контент) — и тут решения лучше wordpress мне неизвестно;
б) «личные странички» бизнесов — для них тоже прекрасно подходит wordpress;
в) интернет-магазины — тут я не подскажу;
г) специализированные ресурсы — и вот тут выбор широк. И без конкретного ТЗ обсуждать что-либо бесполезно.
Но самая распространенная CMS сейчас это wordpress. Так что если уж начинать обсуждение без конкретного заказчика с конкретным ТЗ, то разумно считать что речь идет о запуске wordpress обеспечивая хорошую масштабируемость (т.е. дешевый VPS на запуске сайта, и возможность выдержать тысячи хитов в секунду с минимальными усилиями при необходимости). В идеале, при использовании облачных хостингов — полностью автоматически.
Кстати самая большая проблема в плане безопасности — отнюдь не получение root, а банальные SQL injections.
А защита от них — это уже задача на уровне админа решаемая плохо, а вот на уровне требований к коду — вполне тривиально. Благо в нынешнем PHP модули для работы с БД таки писали куда более умные люди, чем те кто ими пользуются.
LAMP и отказоустойчивый сервис как-то плохо сочетаются. Из всей аббревиатуры стоит оставить только первую букву, ну и, может быть, последнюю (просто потому что PHP-разработчика найти проще).
1. С тех пор как появился nginx, его использование становится обязательным.
Даже если в качестве бэкенда стоит апач, нагрузочная способность сервера только за счет reverse proxy вырастает в несколько раз (а то и более чем на порядок, если раздается много статики).
2. Вынос статики в отдельный поддомен или отдельный каталог, который обрабатывается nginx напрямую, без обращения к бэкенду.
3. Используемая БД это самая большая тема для флейма. На простейших операциях выигрывает MySQL, но при сколь-нибудь сложных запросах PostgreSQL начинает его заметно обгонять.
Также стоит обратить внимание на MongoDB. Сложность в том, что для использования документоориентированных БД надо совсем по-другому думать (другие подходы к построению структуры БД и оптимизации). Но он действительно очень шустрый, плюс репликация и шардинг из коробки без напряга со стороны разработчика.
4. В качестве бэкенда, если уж используется php, стоит посмотреть на php-fpm.
Главная сложность при этом в том, что .htaccess обрабатывать в таком случае некому, а значит придется его переписывать уже в виде конфига nginx. Это, очевидно, сломает все скрипты, которые динамически модифицируют htacces (как некоторые плагины к wordpress, к примеру).
5. Если нам нужно делать навороченную систему, но при этом обеспечить небольшое latency — стоит также посмотреть на SSI в nginx. Благодаря нему можно собирать страничку по частям из нескольких кусков, каждый из которых формируется на своем сервере.
Но это все базовые, очевидные вещи.
Отдельные темы — это настройка в ядре параметров для сети, тюнинг дисковой подсистемы, грамотный подбор оборудования с учетом роли узла в кластере.
Например грамотная оценка количества требуемого RAM — задачка нетривиальная.
Еще отдельный пласт проблем в организации кэширования (которое, вообще-то, должно учитываться на уровне архитектуры самого ПО — кэшировать сам результирующий html не всегда реально, а вот часть данных для его формирования — вполне).
Еще интересное решение — использование темплейтного движка ctpp в виде модуля для nginx. Тогда PHP-приложение выплевывает лишь json с данными для заполнения темплейта. Но это уже мелкий тюнинг.
Конфликт творца и дельца возникает по двум простым причинам:
1. Клиенту продаем не то, что собираемся делать. Если делаем задачу обобщенную, и это дает преимущества клиенту — то надо продавать клиенту именно это. И тогда клиент будет понимать, за что он платит такие деньги.
2. Из-за непонимания клиента. То есть попытки решать абстрактную техническую задачу, вместо того чтобы стать «партнером» клиента в решении его бизнес задачи.
В результате оптимизируется код, а не решение бизнес задачи. Естественно что с точки зрения клиента это выглядит как «этот программер развлекатся за мой счет» (и это ведь чистая правда!). Отсюда и нежелание платить.
Обе причины имеют решения:
1. Работая в одиночку без команды все равно придется научиться продавать. И продавать именно то, что хочешь и любишь делать (продавать то что делать не хочешь — не выгодно, ибо усилий на нелюбимое дело требуется больше, качество хуже, следовательно прибыль — меньше).
Для того чтобы что-то продать клиенту, нужно сначала ответить самому себе на вопрос «а зачем клиенту это нужно?». И если очевидно, что не нужно — и для его бизнеса будет выгоднее сделать решение на коленке студентом-чайником (а бывает и так что это выгоднее в данном конкретном случае), то надо честно такому клиенту обхяснять что вот с этой задачей ему лучше идти к студенту, а вот если задача посложнее — то с удовольствием ее решишь.
Если клиент из тех кто экономит на всем, даже создавая себе гемор (а это геморный клиент, и от таких надо держаться подальше) — он просто уйдет и не вернется. И хорошо.
2. А вот это решается сложнее.
Надо таки поставить себя на место клиента, и осознать что решение бизнес-задачи это ровно такая же инженерная задача как оптимизация ПО. И помочь клиенту решить его задачу. Те кто решают бизнес-задачу, а не кодят — гораздо ценнее. И это автоматически увеличивает оплату. Потому как «модификация 1С» для бизнеса — просто статья расходов. Которую, естественно, очень хочется уменьшать любыми путями.
А вот «сэкономить время бухгалтера настолько, что при нынешнем росте объема операций не придется нанимать второго бухгалтера» (следовательно получить экономию на ЗП бухгалтера столько-то денег), «исключить такие-то ошибки в учете, которые приводят к таким-то потерям денег с такой-то вероятностью», и прочее — это, очевидно, живые деньги для владельца бизнеса.
А когда ты приходишь и предлагаешь клиенту получить денег, поделившись небольшим их количеством с тобой — он будет счастлив. И не будет искать конкурентов способных сделать дешевле (ибо это потребует затрат его времени и нервов).
И вообще, в B2B все просто (кроме крупного бизнеса, где больше политики чем бизнеса). Если ты приносишь фирме деньги и не создаешь гемора — она с радостью ими поделиться. Если же просто хочешь с них денег за непонятную для них работу — они посылают лесом.
И в рамках абстрактной темы выбрать CMS невозможно :)
И я бы акцентировал внимание не на ТЗ, а на ТТ.
Большая часть интернета это простые сайты:
а) личные страницы (блог + контент) — и тут решения лучше wordpress мне неизвестно;
б) «личные странички» бизнесов — для них тоже прекрасно подходит wordpress;
в) интернет-магазины — тут я не подскажу;
г) специализированные ресурсы — и вот тут выбор широк. И без конкретного ТЗ обсуждать что-либо бесполезно.
Но самая распространенная CMS сейчас это wordpress. Так что если уж начинать обсуждение без конкретного заказчика с конкретным ТЗ, то разумно считать что речь идет о запуске wordpress обеспечивая хорошую масштабируемость (т.е. дешевый VPS на запуске сайта, и возможность выдержать тысячи хитов в секунду с минимальными усилиями при необходимости). В идеале, при использовании облачных хостингов — полностью автоматически.
А защита от них — это уже задача на уровне админа решаемая плохо, а вот на уровне требований к коду — вполне тривиально. Благо в нынешнем PHP модули для работы с БД таки писали куда более умные люди, чем те кто ими пользуются.
1. С тех пор как появился nginx, его использование становится обязательным.
Даже если в качестве бэкенда стоит апач, нагрузочная способность сервера только за счет reverse proxy вырастает в несколько раз (а то и более чем на порядок, если раздается много статики).
2. Вынос статики в отдельный поддомен или отдельный каталог, который обрабатывается nginx напрямую, без обращения к бэкенду.
3. Используемая БД это самая большая тема для флейма. На простейших операциях выигрывает MySQL, но при сколь-нибудь сложных запросах PostgreSQL начинает его заметно обгонять.
Также стоит обратить внимание на MongoDB. Сложность в том, что для использования документоориентированных БД надо совсем по-другому думать (другие подходы к построению структуры БД и оптимизации). Но он действительно очень шустрый, плюс репликация и шардинг из коробки без напряга со стороны разработчика.
4. В качестве бэкенда, если уж используется php, стоит посмотреть на php-fpm.
Главная сложность при этом в том, что .htaccess обрабатывать в таком случае некому, а значит придется его переписывать уже в виде конфига nginx. Это, очевидно, сломает все скрипты, которые динамически модифицируют htacces (как некоторые плагины к wordpress, к примеру).
5. Если нам нужно делать навороченную систему, но при этом обеспечить небольшое latency — стоит также посмотреть на SSI в nginx. Благодаря нему можно собирать страничку по частям из нескольких кусков, каждый из которых формируется на своем сервере.
Но это все базовые, очевидные вещи.
Отдельные темы — это настройка в ядре параметров для сети, тюнинг дисковой подсистемы, грамотный подбор оборудования с учетом роли узла в кластере.
Например грамотная оценка количества требуемого RAM — задачка нетривиальная.
Еще отдельный пласт проблем в организации кэширования (которое, вообще-то, должно учитываться на уровне архитектуры самого ПО — кэшировать сам результирующий html не всегда реально, а вот часть данных для его формирования — вполне).
Еще интересное решение — использование темплейтного движка ctpp в виде модуля для nginx. Тогда PHP-приложение выплевывает лишь json с данными для заполнения темплейта. Но это уже мелкий тюнинг.
1. Клиенту продаем не то, что собираемся делать. Если делаем задачу обобщенную, и это дает преимущества клиенту — то надо продавать клиенту именно это. И тогда клиент будет понимать, за что он платит такие деньги.
2. Из-за непонимания клиента. То есть попытки решать абстрактную техническую задачу, вместо того чтобы стать «партнером» клиента в решении его бизнес задачи.
В результате оптимизируется код, а не решение бизнес задачи. Естественно что с точки зрения клиента это выглядит как «этот программер развлекатся за мой счет» (и это ведь чистая правда!). Отсюда и нежелание платить.
Обе причины имеют решения:
1. Работая в одиночку без команды все равно придется научиться продавать. И продавать именно то, что хочешь и любишь делать (продавать то что делать не хочешь — не выгодно, ибо усилий на нелюбимое дело требуется больше, качество хуже, следовательно прибыль — меньше).
Для того чтобы что-то продать клиенту, нужно сначала ответить самому себе на вопрос «а зачем клиенту это нужно?». И если очевидно, что не нужно — и для его бизнеса будет выгоднее сделать решение на коленке студентом-чайником (а бывает и так что это выгоднее в данном конкретном случае), то надо честно такому клиенту обхяснять что вот с этой задачей ему лучше идти к студенту, а вот если задача посложнее — то с удовольствием ее решишь.
Если клиент из тех кто экономит на всем, даже создавая себе гемор (а это геморный клиент, и от таких надо держаться подальше) — он просто уйдет и не вернется. И хорошо.
2. А вот это решается сложнее.
Надо таки поставить себя на место клиента, и осознать что решение бизнес-задачи это ровно такая же инженерная задача как оптимизация ПО. И помочь клиенту решить его задачу. Те кто решают бизнес-задачу, а не кодят — гораздо ценнее. И это автоматически увеличивает оплату. Потому как «модификация 1С» для бизнеса — просто статья расходов. Которую, естественно, очень хочется уменьшать любыми путями.
А вот «сэкономить время бухгалтера настолько, что при нынешнем росте объема операций не придется нанимать второго бухгалтера» (следовательно получить экономию на ЗП бухгалтера столько-то денег), «исключить такие-то ошибки в учете, которые приводят к таким-то потерям денег с такой-то вероятностью», и прочее — это, очевидно, живые деньги для владельца бизнеса.
А когда ты приходишь и предлагаешь клиенту получить денег, поделившись небольшим их количеством с тобой — он будет счастлив. И не будет искать конкурентов способных сделать дешевле (ибо это потребует затрат его времени и нервов).
И вообще, в B2B все просто (кроме крупного бизнеса, где больше политики чем бизнеса). Если ты приносишь фирме деньги и не создаешь гемора — она с радостью ими поделиться. Если же просто хочешь с них денег за непонятную для них работу — они посылают лесом.