Кстати, Pagespeed показывает рейтинг по мобильной оптимизации: 75 для DOU и 57 для Хабра :) Конечно, речь не о победах, но это важные показатели, Интернет ускоряется.

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

Если для масштабирования — лучше посмотрите на техники шардинга и репликации.

Хайлоад — это относительное состояние, когда наступает время масштабироваться. Советую почитать Что такое хайлоад

Не хватает конкретики в каждом примере: рефакторинг — это хорошо, команда — это очень важно и т.п. Неправда ли, общие фразы? Есть такой прекрасный сайт http://highscalability.com/, где постоянно разбираются кейсы конкретных систем. Хотелось бы прочитать о чем-то подобном (только на личном опыте или опыте каких-то наших команд, а не в переводе).

Спасибо! Если Вас интересует техническая составляющая, рекомендую блог: http://highload.com.ua. А в этой статье я попытался выделить самые важные компоненты в работе. Понимание того, что важно, а что нет — это уже 50% успеха. Дальше планирую писать о более специфических вопросах.

Какой именно вид рефакторинга вас в таком проекте напрягает больше всего?

Меня не напрягает рефакторинг, совсем наоборот. Я попытался донести правильную практику его проведения — понемногу и постоянно, а не все сразу.

Робота на великому по трафіку проекті (кілька терабайт трафіку в день), це — активний пошук можливих проблем (напр. закритий тікет має містити розділ “можливі проблеми” та пропозиції по їх упередженню чи вирішенню); планування — планування змін, тестування, релізів, навантаження, перездів, замін, і т.д.; фільтрація змін — dev -> testing -> staging -> production; версіонування — поки нова функціональність розробляється і тестується, стара версія того самого коду підтримується паралельно поки не буде оголошена застарілою.

Дитячий садок. Рефакторинг — це зміна коду без зміни функціональності. Якщо в результаті рефакторингу у вас щось у функціональності міняється, то комусь треба за це відірвати яйця. Ви напевно мали на увазі оптимізацію коду?

Якщо тести показують, що через місяць датацентр А не справлятиметься з піковими навантаженнями, що приведе до збільшення часу обробки запитів, то необхідно провести аналіз варіантів вирішення проблеми — збільшення кількості серверів, оптимальніше використання вільних ресурсів (напр. використання європейського датацентру для обробки частини американського трафіку поки не будуть введені в стрій нові потужності). Код пишеться і відлагоджується довго — навіть тривіальна зміна може пройти весь цикл за 1−2 місяці, і немає ніякої гарантії що вдасться викинути частину коду, тому ставити в залежність роботу датацентру від можливого успіху програмістів ніяк не можна.

Не совсем понимаю какое отношение имеет датацентр к вопросу “справляется с нагрузками” — с нагрузками справляется система. Если датацентр не обеспечивает нужную пропускную способность, то в этом виноват уж никак не датацентр, а тот, кто его выбирал. Вы все правильно написали, но люди, которые принимают эти решения — это не саппорт датацентра, а Ваша команда.

Владимир, спасибо... Учтем Ваши суровые замечания, только менеджера учить «что делать с кодом» мы не будем:)