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

Управление производительностью с помощью DevOps

В Edmunds.com очень ярко выраженная культура DevOps. Для Мартина это означает, что, при возникновении проблем, команда разработчиков полагается на получение четких, актуальных данных от IT Ops. «Наша команда разработчиков напрямую зависит от данных» – заявил Мартин, «поэтому крайне важно, чтобы в случае инцидентов в продуктивной среде, команды IT Ops могли собрать данные и передать разработчикам».

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

«Сначала мы использовали Wily Introscope для глубокого мониторинга», рассказал Мартин, «Одной из причин, по которой это решение нас не устраивало, была необходимость самостоятельно уведомлять этот инструмент о том, что именно сейчас происходит инцидент и нам трубуется узнать больше о данном инциденте». Проблема заключалась в том, что команда Мартина, как и любая другая команда IT Ops, не могла предвидеть события, которые повлияют на производительность критических бизнес-приложений, и таким образом не могла собрать релевантные данные, чтобы предоставить их разработчикам. Настало время найти новое средство для мониторинга производительности.

Умное и «легкое» решение

Мартин рассматривал несколько инструментов мониторинга, включая Dynatrace и AppDynamics. «Ограничения Dynatrace были похожи на те, что есть в Wily – нам по-прежнему нужно было указывать в программе, когда и что мониторить», поделился Мартин. В то же время у AppDynamics есть встроенная аналитика, которая автоматически определяет возникновение сбоя в приложении и сразу же начинает сбор релевантных данных. «Аналитика AppDynamics просто говорит нам «Эй, смотрите, происходит что-то интересное, и я соберу для вас больше данных»», рассказал Мартин. «Это решение было куда лучше, чем когда нам самим приходилось указывать APM, что именно мониторить».

AppDynamics также отвечает требованиям Мартина для инструментов мониторинга продуктивных систем. «У нас было очень четкое условие: накладные расходы на любое выбранное нами решение для мониторинга производительности приложений должны быть минимальными», сказал Мартин. «Идея средства мониторинга приложений в том, чтобы наблюдать, а не вмешиваться».

Повышение производительности с целью защиты доходов

Спустя несколько месяцев Мартин убедился, что AppDynamics существенно повлиял на работу команды по обнаружению и решению проблем производительности в их производственной среде. Поскольку у команды IT Ops появилась возможность практически сразу предоставлять разработчикам релевантную информацию, время на поиск неисправностей существенно сократилось, а время безотказной работы повысилось. «Раньше нам приходилось задействовать около 10 специалистов, которые работали несколько дней над одной проблемой. Это обходилось очень дорого как с точки зрения потерянного времени, так и с точки зрения потерянных доходов», сказал Мартин. «Сейчас же нам требуется всего несколько часов».

Комбинация увеличения продуктивности и защиты доходов (сокращение потери клиентов из-за медленной скорости работы или сбоев в работе) сберегли Edmunds более $800,000 за первый год использования AppDynamics. Если тенденция сохранится и на следующий год, Edmunds сэкономят более миллиона долларов США уже к середине года .

Мартин отметил, что AppDynamics показал себя как очень эффективный инструмент для траблшутинга в его команде и его среде. «AppDynamics – это правильное решение для всех, у кого: 1) нет четкой картины того, что происходит с приложением; 2) слишком большая или разрозненная инфраструктура» – сказал Мартин. «В таком случае без подобного инстумента не обойтись, чтобы избежать ручного мониторинга множества конечных точек с помощью примитивных инструментов как JConsole или VisualVM. Эти программные продукты отлично подходят для простой архитектуры, но при сложной архитектуре перед компанией стоят совсем другие задачи, и AppDynamics отлично справляется».

Примеры использования: До AppDynamics           

Прямой ROI

• Доступность – 99.91%
• Определение MTTR на инцидентах Severity-1 – 5 человеко-дней
• Время на определение ошибок на стадии разработки – 2,5 человеко-дня

Косвенный ROI

• Удовлетворение потребителей – Медленная работа и сбои, раздражающие клиентов
• DevOps сотрудничество – Dev интуитивно работают на решение проблем

После AppDynamics:

• Сокращение времени простоев – Доступность – 99.95%.
  Преимущество: Сэкономили $ 167 475 упущенных потерь

• Сокращение MTTR на инцидентах Severity-1 – Сокращение на 45%
  Преимущество: Сэкономили $307,521 на производственных затратах
• Сокращение времени на определение ошибок на стадии разработки  – Сокращение на 35%
  Преимущество: Сэкономили $320,170  на производственных затратах

Косвенный ROI

• Удовлетворение потребителей – Меньшее к-во инцидентов, большая удовлетворенность конечных пользователей
  Преимущество: Среднее время отклика меньше 150 мс
• DevOps сотрудничество – Ops предоставляют актуальные данные Dev
  Преимущество: Сокращение MTTR на 45%

Суммарная экономия после 1-го года использования: $795,166
Прогнозируемый ROI после 2х лет использования: $1,217,334