Главная страница Публикации Статьи Время — деньги. Измерение внутренней производительности. Тамми Эвертс

Время — деньги. Измерение внутренней производительности. Тамми Эвертс

«Измерение внутренней производительности» (Тамми Эвертс)

Перевод подготовлен:
Лавлинский Д. Е., генеральный директор ООО «Метод Лаб»
к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»

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

В исследовании 2008 года, проведенном Aberdeen Group («The Performance of Web Applications: Customers Are Won or Lost in One Second,» Aberdeen Group, 2008) выяснилось, что проблемы со скоростью могут сократить корпоративную выручку до 9%. Этот вывод относится не только к типичным целевым показателям, например конверсии и доход. Низкая скорость работы приложений может повредить компаниям множеством способов, включая следующие:

  • Совместная работа и обмен информацией
  • Выполнение задач
  • Обслуживание клиентов (управление заказами, учет покупателей, решение проблем, эффективность call-центров и т. д.)
  • Скорость внедрения внутренних систем
  • Стоимость инфраструктуры в дата-центрах
  • Затраты на интернет-каналы

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


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

— Ori Livneh, главный инжеренер по разработке, Wikimedia foundation


Удовлетворённость работников

[Клиентская оптимизация] значительно улучшает скорость работы нашего приложения, в результате мы не только повышаем продуктивность сотрудников, но и улучшаем финансовые показатели.

— Alan Ruth, управляющий директор, корпоративные приложения, Graebel

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

В Graebel, глобальном поставщике услуг по перемещению сотрудников и бизнеса, задали этот вопрос внутри собственной компании, и ответ всех удивил. Они посчитали, что всего лишь в одном небольшом департаменте из 20 человек, сотрудники тратили 130 часов в месяц — другими словами, почти целый рабочий месяц одного человека — на ожидание загрузки страниц единственного внутреннего веб-приложения («For Graebel, a Faster Web Application Equals Happier, More Productive Employees,» Radware, 2013).

Сотрудников можно точно назвать «внутренними клиентами» вашего бизнеса. Если они ждут ответа от внутренних приложений более двух секунд, это снижает доходы вашей организации. Ещё в 1982 году в IBM (Ben Shneiderman, «Response Time and Display Rate in Human Performance with Computers,» Computing Surveys, Vol.16, No.3, September 1984) провели исследование, которое показало тесную связь между временем ответа приложения и продуктивностью работника. В одном исследовании, количество выполненных задач удвоилось, когда время ответа приложения сократилось всего на 2.7 секунды.

Также в IBM выяснили, что время ответа приложения влияет не только на количество выполненных задач, но «по мере увеличения отзывчивости приложения, работник становится экспоненциально продуктивнее».

Вспомните выводы эксперта по юзабилити Якова Нильсена о времени ответа и поведении человека: около 10 секунд задержки это предел возможности концентрации внимания на задаче в случае взаимодействия с системой. После 10 секунд даже самый эффективный сотрудник должен будет заставлять себя повторно сконцентрироваться на текущей задаче.

Плохая производительность снижает боевой дух

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

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

Другими словами, мы можем убедить себя, что у нас всё в порядке — или, если вы работодатель, что ваши работники в порядке, хотя на самом деле это не так.

Веб-приложения для потребителей подняли планку производительности

Ожидания сотрудников по скорости, надёжности и юзабилити установлены потребительскими веб-приложениями, которые мы используем каждый день. Мы, люди, не очень хорошо умеем разделять наши требования в зависимости от ситуации. Так как Twitter, Pinterest и Facebook работают быстро, мы ожидаем такой же скорости от других инструментов и систем: от CRМ до информационной системы компании.

Корпоративные ИТ должны соответствовать этим ожиданиям. Без должного внимания к пользовательскому опыту, многомиллионные затраты на ИТ могут уйти в корзину, по мере того как работники перестанут работать на медленных, сложных в использовании новых инструментах и вернутся к старым, изученным, более дорогостоящим путям выполнения задач.

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

  • Увеличением количества задач в веб-приложениях в заданный промежуток времени.
  • Сокращением веб-стресса и раздражения.
  • Увеличением удовлетворённости и уверенности сотрудника.
  • Повышением скорости внедрения внутренних приложений.

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

Пропускная способность

«Пропускная способность никого не волнует.»

Сложно поверить, но эта идея всё еще активно блуждает в кругах веб-разработчиков (хотя уже реже, чем это было раньше). С повсеместным проникновением быстрых каналов, люди наивного полагают, что вопрос трафика больше не важен. Отчасти это объясняется агрессивным маркетингом провайдеров Интернета: постоянно растущая пропускная способность в тарифных планах и сетях. Люди и СМИ цепляются за эти цифры, потому что они звучат круто. «Вдвое шире канал» звучит сказочно круто, если считать, что это значит «вдвое быстрее». (На самом деле нет. В реальности, увеличение канала на 1000% улучает время загрузки страниц только на 50% — но этого вам провайдер не скажет. Более подробно я остановлюсь на этом факте дальше.)

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

Когда с вас регулярно снимают по $20 это неприятно и раздражает, но это всё капля в море по сравнению с затратами на передачу тяжелых страниц для бизнеса. Канал в Интернет все ещё ценный ресурс. Для высоконагруженных сайтов затраты канал могут стать основным источником затрат, легко опережая затраты на хостинг и хранение данных.

Разбухание страниц (или, когда средняя страница перевалит за 3 Мб)

Раздутые страницы часто являются пожирателями трафика, при этом они становятся всё жирнее. В 2015 году средняя веб-страница весила около 2 Мб (по данным HTTP Archive, который собирает данные по 500 000 самых посещаемых ресурсов по всему миру). Это рост с 1 до 2 Мб всего за три года. В 2012 году многие были бы шокированы размером страницы в 1 Мб. Удивительно, как мы быстро привыкаем к таким значениям.

Важно понимать, что все эти цифры являются усреднёнными значениями. Хотя многие страницы весят меньше 2 Мб, часто можно встретить страницы больше 5 или даже 10 Мб.

С такими темпами роста, может ли средняя страница в 2017 году весить 3 Мб? Время покажет, но одно точно понятно: рост веса страниц неизбежен (см. рисунок 3-1).

Рисунок 3-1

Рисунок 3-1. Если нарисовать график изменения веса страниц, используя данные HTTP Archive, ясно, что средняя страница может перевалить за 3 Мб к концу 2017 года.

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

Кейс: Wikipedia ускоряет загрузку на 66% и радикально сокращает расходы на сервера

По иронии судьбы «wiki» на гавайском языке означает «быстрый», при этом Wikimedia Foundation умудрились довести свой сайт до такого состояния, когда среднее время сохранения страницы для редакторов составляло 7.5 секунд.

Как знает каждый пользователь Википедии, редакторы это кровь и плоть сайта. Они главные создатели и кураторы контента. В то время, как большинство пользователей Википедии получают страницы относительно быстро с узлов CDN, для редакторов страницы отдаются напрямую с серверов MediaWiki, что значительно замедляет загрузку. То есть, обычные посетители Википедии загружали быстрые версии страниц из кэша, редакторы получали постоянное замедление скорости работы Википедии.

Чтобы разобраться с этой проблемой, Wikimedia Foundation внедрили новую технологию HipHop Virtual Machine или HHVM, которая ускоряла MediaWiki, то есть PHP-код за счет которого работает Википедия. HHVM сократила медианное время сохранения страницы с 7.5 до 2.5 секунд (Рисунки 3-2, 3-3 и 3-4).

Рисунок 3-2

Рисунок 3-2. В Википедии сократили медианное время сохранения страницы с 7.5 до 2.5 секунд.

Рисунок 3-3

Рисунок 3-3. Среднее время загрузки страниц Википедии сократилось с 1.3 до 0.9 секунды.

Рисунок 3-4

Рисунок 3-4. В результате оптимизации загрузка ЦПУ для Википедии сократилась с 50% до 10%.

В результате внедрения HHVM, для Википедии были получены сразу несколько улучшений метрик для пользователей и бекэнда (Ori Livneh, «How we made editing Wikipedia twice as fast,» Wikimedia Blog, December 29, 2014), например:

  • Среднее время загрузки для авторизованных пользователей сократилось на 30%, с 1.3 до 0.9 секунды.
  • Нагрузка на ЦПУ для серверов приложений сократилась с 50% до 10%.
  • Радикально сократились планы по закупке новых серверов.

Кейс: компания Hydro-Québec сократила время загрузки на 90% и увеличила скорость внедрения новых процессов проектирования

Hydro-Québec, главный поставщик электроэнергии с ГЭС в Квебеке (Канада), испытывал серьёзные проблемы с производительностью CAD-приложения, которое использовалось через корпоративную сеть и Интернет. В компании использовалось CAD-приложение под названием CATIA, в котором создавались цифровые модели размером до 600 Мб. В компании начались серьёзные проблемы со скоростью работы приложения, когда они попытались перейти на процесс одновременной разработки из разных офисов, который подразумевает почти мгновенный доступ к общим файлам проектов.

«Время отклика было отвратительным», так оценивал ситуацию Daniel Brisebois, консультант компании по ИТ. При замере скорости работы в компании выяснили, что открытие небольшого файла CATIA на 14 Мб занимает более 15 минут по стандартному каналу 10 Мбит/с с задержками 15 мс. Кроме того, люди в удалённых офисах не могли нормально работать в CATIA из-за задержек от 30 до 60 секунд после каждого клика мышью.

Главным преимуществом одновременной работы над проектами являлась совместная работа в реальном времени, но с такими проблемами по скорости это было практически невозможно.

После оптимизации своей корпоративной сети и каналов в Интернет, в Hydro-Québec получили множество преимуществ («Concurrent Engineering Is Possible over a WAN,» Riverbed Case Study, 2011), например сокращение количества ошибок, более короткий цикл разработки и повышение целостности данных. К примеру, файл в 17 Мб раньше загружался за 85 секунд, теперь уже загружается за 8 секунд после оптимизации сети. Другие достижения включали следующее:

  • CATIA файлы загружаются на 90% быстрее
  • Повысилась скорость внедрения процесса одновременной разработки
  • Сокращение ошибок по процедурам
  • Меньше ошибок проектирования из-за несоответствия документов
  • Уменьшились ошибки из-за использования устаревших файлов
  • Сокращены циклы проектирования
  • Улучшена целостность данных
  • Офисные приложения работают от 10 до 25 раз быстрее
  • Сокращение трафика на 90%

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

Кейс: в Netflix получили сокращения счета за интернет-канал на 43% после одной простой оптимизации

Если вы хотите сделать свои страницы быстрее, ваша цель должна быть в сокращении их размера и сложности. Это значит удаление лишних ресурсов и обеспечении их минимального размера при передаче. Таким образом вы не только ускорите загрузку страниц, но и сократите затраты на трафик.

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

Когда Bill Scott, глава разработки интерфейсов в Netflix начал работать в компании, он заметил, что gzip был отключён. Естественно, он включил его (Bill Scott, «Improving Netflix Performance,» June 23, 2008). Как видно на рисунке 3-5, результатом стало резкое сокращение исходящего трафика.

Рисунок 3-5. Включение gzip в Netflix.

Сокращение исходящего трафика принесло несколько выгод, включая:

  • Размер ресурсов в некоторых случаях сократился в 15 раз (в среднем в 2 раза)
  • Улучшение скорости загрузки на 13%-25%
  • Сокращение трафика на 43%

Кейс: Shopzilla сократили время загрузки на 5 секунд, сократили затраты на инфраструктуру на 50%

Компания Shopzilla (сейчас Connexity) это ведущий сервис по сравнению интернет-магазинов, который стал символом оптимизации производительности в интернете после публикации впечатляющего кейса в 2009 году.

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

После 16-месячного реинжиниринга, в Shopzilla ускорили среднюю загрузку страниц с 6 до 1.2 секунд и получили дополнительные выгоды (Phil Dixon, «Shopzilla Site Redesign: We get what we measure,» 2009) в различных бизнес-метриках:

  • Повышение конверсии на 7%-12%
  • Увеличение выручки на 5%-12% (за счет ускорения сайта внутри сессий и за счет увеличения поискового трафика)
  • Увеличение просмотров на 25%
  • Сокращение инфраструктурных затрат на 50%

Кейс: Hilton ускоряет внутреннее приложение, получая сокращение затрат на трафик, повышает доверие клиентов и удовлетворённость сотрудников

Hilton Grand Vacations Club это отделение компании Hilton, которое занимается продажей таймшеров клиентам по всему миру. В компании были серьёзные проблемы с задержками до 30 минут при использовании критичного для бизнеса приложения по работе с договорами.

Старший директор по технологиям Hilton сказал следующее:

Подтверждение договоров это затратный по времени процесс, который включает в себя отправку большого количества данных в наш центральный офис в Орландо. В Азии процесс заключения договора намного сложнее и требует больше трафика, чем в США. Так как мы не могли продублировать наши основные бизнес-системы и процесс в Японии, мы тратили до 30 минут на техническую часть заключения договора.

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

В Hilton решили внедрить технологию оптимизации Интернет-канала, которая ускорила приложение по работе с договорами. После этого ускорения процесс заключения договора сократился с 30 до 1–2 минут. В результате оптимизации получены следующие преимущества:

  • Сокращение данных снизило нагрузку на каналы компании до 80% (особенно эта экономия была актуальна в Японии, где каналы очень дорогие)
  • «Время ожидания при обработке договора сильно сократилось, что дало радикальное улучшение удовлетворённости клиентов и сотрудников».

Выводы

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

Или давайте перефразирую мысль: неважно, что вы бессердечный Скрудж Макдак и вас волнует только сокращение издержек на инфраструктуру и стоимость интернет-канала. Если вы будете заниматься производительностью с этими целями, вы всё равно сделаете своих пользователей значительно счастливее. (Извини, дядя Скрудж!)

Экспертное ускорение сайтов

Ускорение сайтов

Цена от 9 900 Р