# Секретные костыли гигантов: как Gmail, Facebook и Google выживали на старте

Источник: https://www.youtube.com/watch?v=TCPjk8Tpb5c
Канал: Y Combinator
Опубликовано: 16.02.2022

---

В среде стартапов часто обсуждают «делание вещей, которые не масштабируются» в контексте маркетинга или продаж, но этот же принцип критически важен и в разработке программного обеспечения. Майкл Зайбель и Далтон Колдуэлл из Y Combinator на примерах Gmail, Facebook и Twitch разбирают, как «грязные» инженерные хаки и отказ от преждевременной оптимизации позволяют великим компаниям выживать на старте и находить соответствие продукта рынку (PMF).

## 🛠 Решение 90/10: как появился Gmail
[[JUMP:00:52]]

Одним из главных идеологов «немасштабируемых» программных решений в Y Combinator является Пол Бакхайт (Paul Buchheit) — создатель Gmail и автор термина «решение 90/10» [00:52]. По словам Майкла Зайбеля, суть этого подхода в вопросе: «Как получить 90% пользы, затратив всего 10% усилий?» [01:05]. Основатели стартапов часто ненавидят этот совет, так как он заставляет их жертвовать чистотой кода ради скорости.

История Gmail — классический пример такого подхода:

*   **Использование чужого UI:** Первый прототип Gmail Пол Бакхайт собрал, буквально «засунув» свою почту в интерфейс Google Groups (сервиса для рассылок и форумов) [02:12]. 
*   **Итеративная разработка:** Бакхайт начал пользоваться этим UI сам и достраивал только те функции, которых ему не хватало в моменте. Например, он добавил возможность писать письма лишь после того, как несколько дней только читал их [02:38]. 
*   **Физический ремонт серверов:** Когда Gmail (тогда еще внутренний продукт Google) упал, Бакхайт лично пошел в серверную с отверткой, чтобы заменить сбойный жесткий диск [03:56]. По мнению спикеров, этот случай доказал Полу, насколько важным сервисом стала почта для пользователей.
*   **Инвайты как костыль:** Знаменитая система приглашений в Gmail, которую многие считали гениальным маркетинговым ходом для создания дефицита, на самом деле была техническим ограничением [05:00]. У команды просто не хватало серверных мощностей и места на дисках, чтобы открыть доступ всем желающим [05:25].

## 💾 Архитектура Facebook: одна школа — один сервер
[[JUMP:05:37]]

Далтон Колдуэлл поделился воспоминаниями о временах, когда облачных сервисов вроде AWS не существовало, и основатели стартапов вручную устанавливали серверы в дата-центрах [05:52]. Соседним арендатором его компании Imeem в дата-центре Санта-Клары был проект `thefacebook.com` [07:22].

Техническое устройство раннего Facebook, по наблюдениям Колдуэлла, было предельно простым и «немасштабируемым»:

1.  **Физическая изоляция:** Каждый сервер имел наклейку с названием университета (Stanford, Harvard и т.д.) [07:47].
2.  **Копирование кода:** Для каждой новой школы запускался отдельный экземпляр PHP, своя база данных MySQL и свой экземпляр Memcache [08:26]. 
3.  **Отсутствие глобальной базы:** Общей таблицы пользователей не существовало годами. Если вы учились в Гарварде, вы заходили на `harvard.thefacebook.com`, и этот запрос шел в конкретную базу данных именно этого вуза [09:18].

Спикеры сошлись во мнении, что если бы Марк Цукерберг пытался сразу построить единую масштабируемую базу на миллионы пользователей, проект мог бы никогда не запуститься из-за несовершенства технологий того времени [09:05].

## 📉 Twitch и Justin.tv: борьба с пиками в 20x
[[JUMP:10:12]]

Майкл Зайбель, будучи сооснователем Twitch (ранее Justin.tv), рассказал, что главной технической проблемой было не среднее потребление трафика, а непредсказуемые пики [10:25]. Если обычные сайты проектируются под нагрузку в 2–4 раза выше средней, то на стриминговой платформе появление звезды могло вызвать мгновенный скачок в 20 раз [10:37].

Для решения этой проблемы использовались два «грязных» хака:

*   **Кнопка «Статический сайт»:** Когда наплыв зрителей грозил обрушить серверы приложений, инженеры нажимали кнопку, которая превращала страницу трансляции в статичную [11:29]. Все динамические функции (отображение имени пользователя, счетчик просмотров) отключались. Оставались только плеер и чат (работающий на другой системе), зато сайт выдерживал любой наплыв [11:42].
*   **Задержка трансляции ради масштабирования:** Чтобы распределить поток видео на нужное количество серверов при внезапном старте эфира знаменитости, команда внедряла искусственную паузу [13:50]. Стример думал, что он уже в эфире, но зрители видели видео только через несколько секунд, когда система успевала «раскопировать» поток по мощностям [14:41].

## 🎵 Imeem: видеохостинг без видео
[[JUMP:15:08]]

Компания Далтона Колдуэлла Imeem столкнулась с проблемой воспроизведения музыки в браузере в эпоху до HTML5. В то время для этого требовались тяжелые плагины вроде RealPlayer, которые часто приводили к сбоям [15:20]. 

Решением стал «софтверный угон» технологий YouTube [15:33]. Вместо того чтобы писать свой музыкальный плеер, команда Imeem:

1.  Взяла открытые инструменты для работы с Flash Video (FLV).
2.  Конвертировала все аудиофайлы в видеофайлы с нулевым битрейтом видеоряда (черный экран) [16:12].
3.  Использовала стандартные видеоплееры для прослушивания музыки [16:25].

Этот «грязный» трюк позволил сервису быстро запустить инновационный для того времени продукт, не тратя месяцы на разработку уникальной аудиотехнологии [16:38].

## 📡 Трюки с провайдерами и народный перевод
[[JUMP:17:05]]

Когда Twitch столкнулся с нехваткой денег на оплату трафика (пиринг), Майкл Зайбель применил тактику агрессивного маркетинга против интернет-провайдеров [17:18]. Один из шведских провайдеров отказывался от бесплатного обмена трафиком, что делало обслуживание пользователей из этой страны убыточным. 

Команда Twitch внедрила блокировку: после 10 минут просмотра шведский пользователь видел заглушку с текстом: «Ваш провайдер отказывается сотрудничать с нами, поэтому мы не можем показывать вам видео. Если хотите пожаловаться — вот их телефон и почта» [18:38]. По словам Зайбеля, это сработало на удивление быстро [18:50].

Еще одним примером экономии стала локализация. Вместо того чтобы платить агентствам «бесконечные деньги» за перевод интерфейса на 40 языков, Twitch заимствовал решение у Reddit [19:16]. Они создали краудсорсинговую платформу, где сами пользователи-волонтеры бесплатно переводили строки интерфейса на свои языки [19:43].

## 🔍 Сломанный Google и рождение MapReduce
[[JUMP:20:23]]

Далтон Колдуэлл пересказал историю (со ссылкой на очевидцев) о тяжелом периоде в жизни Google около 2001 года [21:02]. В то время индекс интернета обновлялся не в реальном времени, а огромными пакетами (batch process). Скрипт переиндексации всей сети выполнялся около трех недель [21:41].

В какой-то момент процесс начал постоянно давать сбой. По утверждению Колдуэлла, в течение 3–4 месяцев поисковая выдача Google оставалась «замороженной»: пользователи видели старые результаты, а новые сайты не попадали в поиск [22:07]. 

Именно под этим экстремальным давлением (duress) инженеры Google разработали MapReduce — технологию распределенных вычислений, которая легла в основу Hadoop и всей современной работы с Big Data [22:34]. Google не закрылся, пока все было сломано; они продолжали работать, пока не создали масштабируемое решение [23:14].

## 💡 Философия «включенного крана»
[[JUMP:23:39]]

В завершение дискуссии спикеры предложили аналогию с водопроводными трубами в доме. Вместо того чтобы пытаться заранее угадать, какая труба потечет, и проверять их все, стартапу стоит «просто включить воду» [23:51]. Только когда вода польется из щелей, станет ясно, какой участок требует ремонта [24:06].

Основные выводы выпуска:

1.  **Масштабируемость — это привилегия:** Сначала нужно создать то, что нужно людям, и только потом оптимизировать код [24:32].
2.  **Не делайте «лучшее» врагом «хорошего»:** Если у вас есть выбор между идеальной архитектурой и работающим костылем, выбирайте костыль, который даст результат сегодня [25:26].
3.  **Учитесь у гигантов:** Даже Apple начинала с ручной пайки плат Стива Возняка, что было абсолютно немасштабируемым процессом [24:44].