Какой-либо формальной границы, естественно, не существует: кто-то называет таковыми только всем известных интернет-гигантов, а кто-то – любой сайт, с которым перестал справляться хостинг за 5$ в месяц. Реальная граница находится между этими крайностями, можно попробовать сформулировать её следующим образом: высоконагруженным интернет-проектом можно считать тот, которому потребовалось прибегнуть к нетривиальным техническим решениям для удовлетворения текущих или ожидаемых в ближайшем будущем потребностей своей аудитории.

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

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

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

Второй критерий – специфика проекта. Как часто и кем обновляется информация? Как много информации будет одновременно находиться в системе? Структурирована она или нет? Устаревает ли она? Какие основные типы запросов? Нужен ли полнотекстовый поиск? Аудитория – живые люди, автоматизированные внешние системы или и то и другое? И многие другие вопросы, на которые нужно понять ответ и сделать выводы.

Третий критерий – план развития проекта в целом. Архитектура проектируется на много шагов вперед, план её реализации должен быть поэтапным и соответствовать развитию остальных, не технических, аспектов интернет-проекта.

Технологии подбираются индивидуально, но некоторые «связки», которые чаще используются вместе, чем остальные, все же существуют. В частности это LAMP и стеки технологий от Mi***oft и Oracle. Но, как известно, не смотря на то, что встретить в природе их можно чаще, все они относятся к «тривиальным» решениям и требуют постоянной частичной или кардинальной переработки при росте проекта.

Способов всего три: распределение, кэширование и откладывание на потом. На основе их комбинации строятся основные используемые на практике решения, с наиболее распространенными можно ознакомиться в статье «10 известных масштабируемых архитектурных шаблонов».

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

• Зарплата: для большинства интернет-проектов (за исключением проектов, где все создается основателями и сотрудники как таковые отсутствуют) это практически самая основная статья расходов. Очень сильно зависит от географии сотрудников, могу посчитать приблизительную сумму для Москвы, например у нас будет средняя команда из 25 человек, из которых 3 менеджера (которые сами себя назвали директорами) с зарплатой в 120 тыс.р., 1 тим лид с зарплатой 130 тыс. р., 2 системных архитектора с зарплатой 100 тыс. р., 10 разработчиков с зарплатой 80 тыс. р., 3 системных администратора с зарплатой 70 тыс. р., 2 тестировщика по 40 тыс. р. и 4 не-технических сотрудника с зарплатой 50 тыс. р. После несложной математики выходит 2 миллиона рублей в месяц, что очень прилично.
• Налоги: не знаю платит ли сейчас кто-то зарплату официально, но с зарплаты сотрудников по-хорошему нужно платить 50% налогов, добавляем еще 1 миллион рублей в месяц.
• Оборудование: скорее всего арендуется и расходы по сравнению с зарплатой практически не заметны. Например 50 серверов будут стоить порядка 100 тыс. р. в месяц в Европе (по 50 евро) или порядка 150 тыс. р. в США (по 100$). При удачной архитектуре количество серверов (и расходов на них) будет расти линейно относительно размера аудитории.
• Офис: еще одна незначительная статья расходов, которая врядли будет превышать 100-150 тыс. р. в месяц, с учетом закупок офисной техники и мебели, компьютеров и расходных материалов.
• Программное обеспечение: в большинстве случаев ноль ибо opensource. Исключения: дизайнеры, бухгалтеры и юристы, но их обычно все же не держат в штате. Mi***oft и Oracle также не рассматриваем.
• Маркетинг: очень сильно зависит от тематики и ниши, может быть как практически нулевым (люди сами рассказывают знакомым о проекте), так и неограниченно большим (телевидение, наружка, баннерная реклама). Для большинства проектов примерно соответствует сумме остальных расходов.

Итого для этого гипотетического проекта расходы составили бы порядка 5 миллионов рублей в месяц, из которых лишь около 2-3% на аппаратное и программное обеспечение.

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

Возможны и другие сценарии, например с отсутствующим инвестором и существенно меньшим штатом, но общая картина (пропорции) приблизительно останется прежней.

В целом по больнице – определенно да,  но если учесть поправку на ограниченность русскоговорящей аудитории по сравнению с мировой, то ситуация вполне закономерная и нормальная.

Да, может, так как DDoS атаки чаще всего нацелены на поглощение интернет-канала, доступного веб-серверам интернет-проекта, а не на его внутреннюю архитектуру. Даже если злоумышленник решит воспользоваться уязвимостью в одном из компонентов системы (например в SSL-handshake HTTP-серверов), архитектура в данной ситуации тоже не спасет.

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

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

Если в общем случае, то нужно определить с насколько многочисленной аудиторией может столкнуться проект и с насколько большим и сложноструктурированным массивом данных придется работать.

Но лучше здесь отталкиваться от типа проекта:

• Информационные ресурсы: в подавляющем большинстве случаев ответ — заранее планировать архитектуру не нужно, очень небольшое количество информационных ресурсов перерастает возможности одного сервера при грамотно настроенной системе управления контентом. А даже если это и случится, добавление новых серверов пройдет безболезненно из-за широких возможностей по кэшированию контента и отсутствия необходимости сложных решений на уровне СУБД.
• Интернет-магазины: здесь все упирается в широту ассортимента, если ассортимент теоретически не может разрастись до сотен тысяч наименований, то особых решений точно не потребуется. В противном случае — надо задуматься об эффективном кэшировании часто посещаемых товаров и категорий, а также минимизации «тяжелых» запросов к базе данных.
• Социальные сети: основной критерий — теоретически возможное количество участников и связей между ними. Если речь идет о маленькой региональной или узкотематической социальной сети, то можно не заморачиваясь сложить все в реляционную базу данных, но для чего-то большего потребуется масштабируемое решение.
• Технологические проекты: основанные на техническом ноу-хау проекты напрямую от него и зависят, как правило уже при проектировании самой «изюминки» проекта становится понятно какая архитектура для него больше подходит и как её развивать в дальнейшем.

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

Если же проект в каком-то виде уже реализован и запущен, но из-за стремительного роста аудитории перестал полноценно справляться со своими задачами, то ответ очевиден — «вчера».

Если же он как-то реализован, нормально работает и никаких признаков приближающейся катастрофы не видно, то определенно этот вопрос можно отложить.

Прототип в той или иной форме появляется у любого интернет-проекта и обычно эволюционирует по мере его формирования и развития. Самый примитивный вариант прототипа – на салфетке или просто на бумаге, он появляется на очень раннем этапе для обсуждения проекта внутри команды, а еще лучше – для демонстрации и получения обратной связи от целевой аудитории. Создается, как не трудно догадаться, основателем(ями) проекта и особых специалистов не требует. Про использование подобных бумажных макетов в целях юзабилити исследований – отдельная тема.

В дальнейшем прототип может приобрести форму набросков страниц (mockups), что по сути представляет собой оцифровку и детализацию того, что раньше было на бумажках. Проще всего это делать специальным софтом, рекламировать не буду. Далее прототип уже передается «специалистам»: дизайнер предаст наброскам приемлемый внешний вид, верстальщик превратит макеты в понятный браузерам вид, а разработчик предаст им жизни и вот, собственно, проект уже практически готов к запуску и статус прототипа постепенно теряет.

Одна из побочных (вспомогательных) функций прототипа для стартапа – демонстрация проекта инвесторам, бизнес-ангелам и менторам. Для этого может сгодиться любая его инкарнация, но чем более он проработан, тем меньше придется взывать к воображению собеседников.

Этот вопрос скорее финансовый, чем технический. Если стартап находится на ранней стадии, то его основная задача – проверить идею, зачастую с очень примитивным прототипом, при минимальных финансовых вложениях. В таком случае выбор стоит между обычным (shared) хостингом (если прототип статичен или написан на PHP) и виртуальным (VPS, VDS или один инстанс «в облаках»). Выбор не сложный, так как нагрузки как таковой не предвидится и все определяет использование в прототипе технологий, не доступных на shared хостинге.

На поздних же стадиях, когда проект получил финансирование или уже начал зарабатывать самостоятельно, да, стоит задумываться о более долгосрочном «месте жительства» проекта. Первое о чем стоит подумать это не тип хостинга, а страна, где он будет располагаться. Основные аспекты, которые стоит учитывать: близость к целевой аудитории проекта (по сети, а не географически, что не всегда одно и то же), а также особенности законодательства страны в области ИТ. Именно из-за юридических, правоохранительных и прочих национальных особенностей многие (я в их числе) предпочитают хостинг в Европе для русскоязычных интернет-проектов.

Покупку серверов с colocation за границей провернуть не так просто именно с организационной точки зрения (не говоря о финансовой), так что у большинства выбор сводится к dedicated vs cloud. Облака удобны для тех, кто не способен спрогнозировать изменение спроса аудитории, но способен автоматизировать запуск и остановку дополнительных серверов и подключение их к обслуживанию интернет-проекта, плюс нужно быть готовыми переплачивать за данное удобство, особенно при размещении на территории США. Арендуемые железные сервера же хороши, когда у проекта стабильная предсказуемая нагрузка или когда идет работа с данными, существенно превышающими по объему доступную оперативную память.

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

В качестве общей рекомендации стоит сказать, что будущие коллеги всегда имеют больше шансов определить уровень кандидата, чем любой HR-специалист, так что по возможности именно они должны проводить собеседование (по крайней мере задавать вопросы и оценивать адекватность ответов).

Давайте пройдемся по основным позициям и рассмотрим на что стоит обратить внимание при найме:

• Лицо Принимающее Технические Решения: официально такого человека в зависимости от ситуации могли бы обозначить как «технически директор», «системный архитектор», «начальник отдела/департамента разработки», «ИТ-менеджер», «тим лид», просто «программист» — суть от этого не меняется. Это тот человек, который собственно будет отвечать за то, как будет [технически] выглядеть проект в дальнейшем, он может даже и не быть начальником, а просто говорить «вот так надо», а начальник, ничего толком не понимая, со всем соглашаться — даже такое бывает. От него будет зависеть архитектура проекта, план развития, выбор технологий, масштабируемость, отказоустойчивость и безопасность, а также многое и многое другое. Не всегда заранее понятно кто в команде окажется в итоге этим человеком, но руководству компании очень желательно как можно раньше его выявить (желательно до найма) и максимально пристально обратить на него внимание. К нему стоит относиться как к юристу — проверить именно знания и навыки достаточно сложно, а вот ознакомиться с его историей, прошлыми проектами, мнением о нем коллег и просто других профессионалов в отрасли необходимо в любом случае. Посмотреть его в деле можно обсуждая виртуальные (придуманные) проекты с конкретными особенностями, ограничениями и проблемами; нужно просить кандидата порассуждать вслух о возможных вариантах решения трудностей, в чем преимущества каждого их них, каким он отдал бы предпочтения и почему.
• Разработчики: в интернет-проектах их принято делить на клиентских и серверных.
  • Серверный разработчик обычно отвечает в первую очередь бизнес-логику проекта, во вторую — за генерацию шаблонов, взаимодействие с СУБД, обработку файлов и многое другое, что могут на него повесить. Так или иначе его роль заключается (но не ограничивается) в написании кода проекта на одном из  языков программирования (в большинстве проектов на серверной стороне используется один ЯП, реже — два, и совсем редко — больше). Помимо кода он отвечает за выбор деталей реализации проекта: алгоритмов, библиотек, вспомогательных инструментов и пр. Из всего этого напрямую следует процесс его найма: нужно просить писать код и обсуждать алгоритмы, библиотеки, базы данных, шаблонизаторы и т.п. тоже на примере вымышленных ситуаций. Прямо на собеседовании код лучше писать не на компьютере (бумага, маркерная доска, печатная машинка), а также можно попросить посмотреть написанный им старый код и проверить на адекватность читабельность и соответствие общепринятым стандартам (это лучше доверить его будущему коллеге по возможности).
  • Клиентский разработчик занимается всем тем, что происходит в браузере пользователя. Уклон бывает в две стороны: внешний вид (верстальщик, HTML+CSS) и динамика (JavaScript разработчик). На собеседовании также основное внимание стоит уделять коду, плюс принципам работы браузера и особенностям основных реализаций и их версий. Для верстальщика стоит попросить несколько примеров работы и проверить на валидность и кроссбраузерность, для обоих проверок существуют автоматизированные сервисы, но и глазами посмотреть тоже стоит на предмет читабельности и по возможности отсутствия неудачных решений (табличная верстка, стили внутри HTML, отсутствие семантики). С JavaScript разработчиками стоит обсудить опыт работы с различными библиотеками, понимание основных событий, происходящих внутри браузере, принципы организации кода, полезным навыком будет опыт организации навигации без перезагрузок страницы и постоянного поддержания с сервером для обновлений страницы в реальном времени.
• Системные администраторы: как ни странно, они тоже должны уметь программировать, так как при соотношении серверов к сисадминам больше чем 1 к 3 ключевую роль в их работе начинает играть автоматизация. Обычно это самое основное на что стоит обратить внимание на собеседовании: обсудить с какими подходами к автоматизации в системном администрировании кандидат знаком, что предпочитает, попросить написать пару-тройку скриптов (обычно на bash, Python или Ruby, хотя это не так важно) для параллельного выполнения каких-то действий на кластере из >100 серверов. Вторая по важности тема, пожалуй, мониторинг и реагирование в случае проблем. Собственно понимание серверных операционных систем и основных сетевых протоколов также должно быть на очень высоком уровне, причем желательно чтобы человек мог объяснить все это так, чтобы даже не технарю все стало понятно. На тему почты, DNS, LDAP и прочих подобных стоит общаться только кандидату и правда предстоит ими заниматься.
• Тестировщики: бывает три основных типа тестирования, применительно к интернет-проектам и, соответственно, три типа тестировщиков.
  • Автоматическое тестирование кода — по сути своей работы и требованиям очень похож на серверного разработчика, разница в том, необходимо понимание основных типов тестирования и сопутствующих инструментов. На собеседовании, естественно, стоит спрашивать как кандидат протестировал бы ту или иную часть (воображаемого) проекта, порой бывает интересно пообсуждать тестирование внутри браузера посредством Selenium или аналогов.
  • Нагрузочное тестирование — проверка поведения сайта в целом при определенном уровне нагрузки (потоке входящих пользовательских запросов). Кандидат должен понимать как максимально точно воспроизвести поведение пользователей в системе, предложить варианты сбора данных и построения на их основе сценариев, уметь определять узкие места в системе, те, которые являются причиной неполадок.
  • Ручное тестирование — такое тоже порой встречается, иногда писать автоматизированные тесты сложно, долго или лень, и проще вручную понажимать все кнопочки и посмотреть что будет. Но специально для этого людей нанимать не надо, можно напрячь, например, секретаршу или еще кого-нибудь, а еще лучше — не лениться и автоматизировать процесс тестирования.

На самом деле какого-то особого секрета, который непременно нужно знать, здесь нет.

Тем не менее, помимо качественного исполнения своих прямых обязанностей, от техспециалистов следует ожидать понимания основных принципов, которые используются или могут использоваться в интернет-проекте, в частности:

• Как устроены и работают основные веб-протоколы, как минимум TCP/IP, HTTP, SSL, DNS, остальные менее важны.
• Основные принципы работы браузеров, особенности основных пяти и их версий, HTML, CSS, JavaScript,»водопад» загрузки ресурсов, процесс отрисовки страниц, AJAX.
• Новые стандарты и возможности, которые обычно называют «HTML5» (WebSockets, History API, различные варианты хранения данных на клиенте и др.) — как минимум быть в курсе их существования и понимать в каких случаях целесообразно их использовать.
• Серверные операционные системы: минимальными навыками работы с Linux и общим представлении о схеме их работы стоит обладать даже клиентским разработчикам и верстальщики, если человек знаком только с Wi***ws — это тревожный знак. Процессы, потоки, сигналы, файловые системы и основные демоны.
• Базы данных — это тема уже более узкая и не нужна совсем всем, но понимать как они работают, какие бывают основные типы, их преимущества и недостатки определенно стоит. Аббревиатуры CAP и ACID должны что-то говорить.
• Основные принципы масштабируемости (распределение работы, кэширование, отложенные задачи), отказоустойчивости (единственные точки отказа, DDoS, сбои оборудования) и сетевой (без)опасности (инъекции, XSS, уязвимости ПО, человеческий фактор и др.). Особенности, варианты реализации, готовые решения.

Соответственно, если Вы прочитали этот ответ с точки зрения специалиста — рекомендую пройтись по вышеизложенный списку перед трудоустройством в крупный интернет-проект или стартап, который планирует стать таковым.

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

Если же говорить о трендах, то многие считают модным использование Ruby on Rails и node.js, «NoSQL» баз данных и других относительно новых технологий. Лично мой выбор в последние годы часто падает на Python, Redis и PostgreSQL.