На конференции Container World мне удалось побеседовать со Стивом Ньюманом, основателем и главным управляющим Scalyr (https://www.scalyr.com/), молодой компании, работающей над средством управления журналами, которое поможет ИТ-специалистам разобраться в огромном объеме информации, хранящейся в журналах серверов. Напомню, что в 2004 году Стив Ньюман основал компанию Writely, которая была вскоре приобретена Google и превратилась в Google Docs. Уроки, полученные в Google, он намерен использовать в работе над своим новым проектом.
Тогда, более десяти лет назад, вместе с Ньюманом трудились еще двое: Сэм Шиллас, ныне вице-президент по проектированию Google Maps, и Клаудиа Карпентер, которая работает в Scalyr в качестве программиста и разработчика пользовательского интерфейса.
«Мы были друзьями и решили вместе создать компанию, но не знали, с чего начать, — рассказывает Ньюман. — Мы пытались реализовать другую идею, о которой я даже не буду говорить, но однажды коллега пришел в наш офис, располагавшийся у меня на чердаке, и объявил, что у него есть идея. В сущности, он представил нам Google Docs».
Учитывая успех, который в конечном итоге выпал на долю Docs, вы, вероятно, думаете, что трио немедленно отказалось от неудачной первоначальной идеи? Нет. Как они говорят, это в ретроспективе все ясно. А будущее всегда выглядит более туманным.
«Мне потребовалось более двух недель, чтобы убедить остальных в достоинствах нашей идеи, — вспоминает Ньюман. — Мы подготовили первый прототип за 100 дней. Я точно помню, потому что как раз перед этим прочитал статью, в которой утверждалось, что любой новый продукт необходимо выпустить за 90 дней. И мы поставили такую цель. Однако 90 дней мы пропустили. Нам потребовалось 100 дней, чтобы подготовить первый прототип. Выпуск был очень скромным — прессы не было, присутствовало всего несколько человек».
Выпуск состоялся в 2005 году, когда программное обеспечение как услуга еще не завоевало популярность, и на пять лет раньше, чем Microsoft реализовала интернет-версию Word как часть Office 365 (http://www.itprotoday.com/office-365/six-common-office-365-problems-you-should-know-about). «Проблема, которую, как мы думали, мы решали, заключалась в пересылке файлов Microsoft Word в качестве вложений», — признает Ньюман.
1 сентября 2005 года, примерно через шесть недель после скромного представления Writely, Майкл Аррингтон опубликовал статью о новом текстовом процессоре на основе браузера на TechCrunch (https://beta.techcrunch.com/2005/08/31/writely-process-words-with-your-browser/), «малом» сайте, основанном им всего несколькими месяцами ранее. Ньюман вспоминает, что статья привела к резкому увеличению трафика на сайте.
«Однажды вечером, прежде чем лечь спать, я отметил, что на сайте примерно 90 зарегистрированных пользователей, причем многих из них я знал лично, — рассказывает он. — Когда я проснулся, у нас было около 1000 зарегистрированных пользователей. Изменение произошло за одну ночь благодаря статье TechCrunch. С этого момента дела сразу пошли в гору. Это был классический интернет-взлет. В скором времени мы получили электронное сообщение от Google с предложением приобрести нашу компанию, которое мы чуть не удалили как спам. Одно событие следовало за другим и, наверное, спустя 10 месяцев после блестящей идеи наша компания была куплена».
В результате Ньюман со своей командой переехал из офиса на чердаке в помещение, предоставленное Google, чтобы превратить маленький самодельный текстовый веб-редактор в нечто гораздо более значимое. Google приобрела другую начинающую компанию, которая спроектировала электронную веб-таблицу, и команда Writely сотрудничала с ней в рамках общего проекта, чтобы создать полноценный офисный комплекс для совместной работы Google Docs.
«Работа в Google начиная с 2006 года, выпуск Google Docs, его проектирование и масштабирование были чрезвычайно полезным опытом, — считает Ньюман. — Google прекрасное место, чтобы научиться работать над масштабными проектами, поставлять продукт миллионам пользователей и обеспечивать его работоспособность».
Когда работаешь в таких масштабах, приходится уделять внимание необычным вещам, о которых прежде не приходилось беспокоиться. Как говорят сотрудники Google, если вероятность какого-то события — один шанс из миллиарда, то оно будет происходить каждый день. Это действительно так. Вы начинаете гораздо аккуратнее подходить к проектированию, оформлению продукта и взаимодействию различных компонентов, поскольку непредвиденные события случаются постоянно.
В скором времени Ньюман и его команда поняли, что обеспечение совместной работы всех компонентов выходит далеко за пределы их собственного проекта. Их программный код должен был научиться работать внутри уже существующей инфраструктуры Google.
«Не думаю, что в то время мы пользовались этим термином, но на самом деле мы работали в «облаке», внутреннем «облаке» Google, поэтому вам не приходилось создавать и обслуживать собственную систему, — объясняет Ньюман. — В компании было много других базовых возможностей, на которые можно было опереться, в частности хранилища данных, проверка подлинности пользователей, направление трафика от миллионов посетителей, все это было сделано другими группами разработчиков Google. От нас требовалось воплотить лишь нашу малую часть, а в остальном мы могли полагаться на другие программные компоненты. Это было превосходно, но несколько усложняло дело. Перед приобретением у нас было около 200 000 зарегистрированных пользователей, и нам было трудно справляться с такой аудиторией. В Google число зарегистрированных пользователей быстро достигло миллионов, и достаточно было нажать кнопку, когда требовалось больше серверов, и вся система без проблем масштабировалась. Это невероятная платформа для крупномасштабных проектов, хотя среда была очень сложной».
Препятствия могут возникать в самых неожиданных местах.
«Спустя короткое время после того, как мы перезапустили Writely как Google Docs, произошло 20-минутное отключение, так как Бразилия играла в полуфинале Кубка мира, и в перерыве после первого тайма все жители страны принялись обмениваться мнениями об игре в социальных сетях, — вспоминает Ньюман. — Если вы жили в 2006 году в Бразилии, то вашей социальной сетью была Orkut (http://www.nytimes.com/2006/04/10/technology/a-web-site-born-in-us-finds-fans-in-brazil.html), принадлежавшая компании Google. Резкое увеличение трафика вызвало перегрузку сети в центре обработки данных Orkut, который одновременно обслуживал и Google Docs. Такие случаи показывают, насколько серьезными бывают сложности. Всегда что-то происходит. Это не обязательно перерыв в матче Кубка мира, но кто-то что-то делает, некая компания выпускает новую версию какого-нибудь продукта, и она как-то влияет на то, что вы делаете, и вам приходится разбираться в проблеме. Почему внезапно отказала функция проверки правописания? Почему во второй половине дня замедлилась реакция сайта? Я знаю, что причина отлична от той, что вызвала замедление во второй половине дня вчера, потому что я ее уже проверял.. И такие вещи происходят постоянно».
Как ни странно, проблема масштабирования в сложных средах, с которой Ньюман и его команда столкнулись в Google, в конечном итоге привела к созданию новой компании по разработке средства управления журналами, которой он руководит сегодня.
«Попытки анализировать все собранные сведения из журналов и другие данные приносили сплошное разочарование, — признал Ньюман. — Покинув Google, я разговаривал со многими коллегами из отрасли и слышал много похожих историй. Особенно теперь, когда все перемещаются в «облако», которое, в сущности, является средой такого типа».
Если перед вами сложная система, приходится проводить масштабные исследования, в ходе которых необходимо просматривать журналы серверов, журналы приложений и другие данные, которые вы постоянно собираете из систем. Если вы пытаетесь обнаружить источник сообщений об ошибках в крупномасштабной среде, объем данных становится огромным. Посмотрите на диаграмму, показывающую, сколько времени требуется для загрузки сайта, и постройте такие диаграммы за прошедшую неделю. Вы увидите, когда ситуация начала ухудшаться, и тем самым приблизитесь к источнику проблемы.
Тщательный поиск в журналах сервера почти всегда в конечном итоге позволяет установить причину неполадок, но Ньюман пришел к выводу, что время, необходимое для просмотра огромных объемов данных, почти неприемлемо велико.
«Может потребоваться пять минут, чтобы задать вопрос, например определить, когда впервые возникла ошибка или когда сайт стал работать медленно, и необходимо пять минут, чтобы получить ответ. Ответ ведет к следующему вопросу, потому что вам потребуется восемь шагов, чтобы добраться до первопричины, и на каждом шаге придется проверить десяток догадок, прежде чем вы найдете верный вариант. Итак, вам предстоит задать 80 вопросов, и для ответа на каждый из них требуется пять минут. Пять минут — достаточное время, чтобы упустить последовательность рассуждений, посмотреть электронную почту или выпить чашку кофе. Восемьдесят чашек кофе к тому моменту, когда вы доберетесь до решения проблемы. С этим нам пришлось столкнуться в Google», — продолжает Ньюман.
Подобные задачи он пытался решить шесть лет назад, когда основал платформу для управления журналами Scalyr.
«Исходная идея Scalyr очень проста, — резюмирует Ньюман. Это попытка превратить пять минут в одну секунду».