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

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

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

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

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

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

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

Когда на Flickr возникали проблемы, администраторы включали кэширование в системе полнотекстового поиска; это давало некоторое время для выявления и исправления проблем.

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

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

Конечно, преобразование страницы в статический код HTML нарушает работу многих функций, свойственных современным динамическим веб-сайтам, но у статических страниц есть свои преимущества:

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

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

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

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

Здесь перечислены лишь некоторые меры, которые спасут ваши серверы, «погребенные» под лавиной трафика.

Отключение «тяжеловесных» функций

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

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

В идеале набор функций, к которым могут применяться включение/отключение, должен выявляться и согласовываться с группами разработки, проектирования, управления продуктом и текущих операций. В настоящее время Flickr имеет 195 различных компонентов, которые могут быть отключены в экстренной ситуации. К их числу относится отправка фотографий, поиск по сайту и второстепенные функции типа обмена Flickr-сообшениями между пользователями.

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

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

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

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

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

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

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

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