Scalyr - в «облаке» журналов. Часть III
Содержание:
1. Часть I;
2. Часть II;
3. Часть III (Вы читаете данный раздел).
«Спустя короткое время после того, как мы перезапустили 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 очень проста,— резюмирует Ньюман. Это попытка превратить пять минут в одну секунду».
1. Часть I;
2. Часть II;
3.
«Спустя короткое время после того, как мы перезапустили 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 очень проста,— резюмирует Ньюман. Это попытка превратить пять минут в одну секунду».
