DeepEdit!

Я хочу, чтобы уверенность в своих способностях к диагностике про­блем производительности, приобретенная вами после прочтения этой книги, позволила вам ни на секунду не испугаться сценария, подобно­го приведенному ниже:

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

Старший менеджер отдела системного администрирования («Системный менеджер»): «В течение двух недель мы намерены увеличить производи­тельность процессоров; стоимость нового оборудования и дополнительных лицензий составит 65 000 долларов. Благодаря удвоению мощности ЦПУ наши пользователи получат заметное повышение производительности».

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

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

Системный менеджер: «Я не согласен. Я считаю, что в представленных ва­ми данных о времени отклика слишком много необъяснимых противоре­чий, чтобы делать такие выводы».

Вы: «Давайте обсудим это отдельно. Я объясню вам, как я пришел к этим выводам».

(Позже, на повторно созванном совещании.)

Системный менеджер: «Хорошо, я согласен. Он прав. Замена процессора не даст нужного прироста производительности, как мы надеялись».

Вы: «Зато, перераспределив нагрузку способом, который я могу изложить, мы сократим время отклика при формировании заказа не менее чем на 95%, не тратя денег на новые процессоры. Как видно из приведенного профиля времени отклика формы, замена ЦПУ никак нам не помогла бы».

Я был свидетелем множества обсуждений, в которых персонаж «Вы» получает первое слово, после чего дискуссия так и не возвращается в верное русло. Результат зачастую бывает ужасен. Компания пости­гает азы в поисках решения, способного поднять производительность. Иногда она останавливается, лишь полностью исчерпав отведенное время или деньги, или и то и другое.

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

Преодоление общего неодобрения

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

Однако более вероятно, что повышение производительности системы потребует коллективных усилий. Скорее всего, реализация рекомен­даций аналитика потребует участия коллег. Действия, рекомендуе­мые им в результате применения Метода R, зависят от следующих об­стоятельств:

Коллеги знакомы с этими идеями и не разделяют их.

Они никогда раньше не слышали об этом.

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

Вот самый эффективный из найденных мною способов доказательства:

Нет лучшего способа доказательства результата, чем его демонстра­ция. Дэйв Энсор (Dave Ensor) описал это как «Метод Ювелира». Любой хороший ювелир, продавая товар, как можно раньше даст потенциальному покупателю подержать его. Когда покупатель дер­жит изделие в руках, он может гораздо полнее оценить его красоту и достоинство. Пока он мечтает, как изменится к лучшему его жизнь (стоит только ему стать обладателем этой вещицы), вообра­жение покупателя работает на продавца. Этот метод прекрасно ра­ботает для дорогого товара: драгоценностей, автомобилей, домов, яхт и производительности систем. Пожалуй, нет лучшего способа заручиться поддержкой своих предложений, чем дать пользовате­лям на деле почувствовать, насколько улучшится их жизнь в ре­зультате предлагаемых мероприятий.

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

Местная валюта

Величина, на которую будет уменьшено время отклика

Количество бизнес-операций в единицу времени, на которое воз­растет производительность для какого-либо пользователя

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

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

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

«Но вся система работает медленно»

«Надо настраивать всю систему, а не только одного пользователя»

«Когда вы перейдете к методу, который позволит настраивать систему вцелом?»

Мы слышали это везде, где бы мы ни были.

Что делать, если вся система работает медленно? Специалисты обычно нервно реагируют на метод повышения производительности, если он основан на анализе выполнения только одной операции в данный мо­мент. А если пользователи замечают, что «вся система тормозит», возникает сильное искушение начать анализ со сбора общесистемной ста­тистики. Причина заключается в опасении упустить что-то важное, ограничившись анализом части системы. Да, действительно, сосредо­точившись на приоритетных пользовательских операциях, вы действительно пренебрежете некоторыми вещами:

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

Вот почему Метод R эффективен независимо от происхождения пробле­мы - порождена ли она отдельной пользовательской операцией или же набором различных операций. На рис. 1.3 показана информация, в пер­вую очередь получаемая аналитиками, когда они приступают к изуче-

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

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

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

• Первый крайний случай (а) предполагает, что все симптомы, заме­ченные пользователем системы, вызваны единственной «универ­сальной» причиной.

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

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

Конечно, легко рисовать картинки с причинно-следственными связя­ми источников проблем и их симптомов. Совсем другое дело - выявить такие связи в реальности. В способности к этому, как мне представля­ется, и заключается основная мощь, выделяющая метод R. Сейчас объясню почему.

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

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

Рассмотрим для сравнения эффективность метода C для каждого из трех описанных случаев. Как вы помните, на первом этапе метода C требуется Построить гипотезу о несоответствующем значении некоторой метрики x.

В контексте рис. 1.4 этот этап аналогичен выявлению заштрихованных кругов в той части, которая называется основные причины. После обна­ружения вероятных источников проблем метод C предлагает аналити­ку установить причинно-следственные связи между причинами и их проявлениями. Изъян метода C в том, что, поскольку нет плана для по­иска причинно-следственных связей, приходится действовать наугад. Обычно такой подход состоит в том, чтобы что-нибудь «поправить», а потом посмотреть, к чему это привело. Это метод проб и ошибок.

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

По-настоящему метод C начинает пробуксовывать при попытке при­менить его в ситуациях (б) и (в). В обоих случаях движение «снизу вверх» приводит к необходимости выбора из нескольких потенциаль­ных источников проблем. Как узнать, какой из них требует первооче­редного внимания? Наилучшим способом расстановки приоритетов будет «проход по стрелкам» назад - от наиболее критичных для бизне­са симптомов к порождающим их причинам. Претендентами на первоочередное внимание будут те причины, которые способны вызвать наиболее неприятные симптомы.

Однако здесь притаилась очередная трудность метода C:

Общесистемные показатели производительности не содержат информации о причинно-следственных связях.

Невозможно достоверно установить причинно-следственные связи, показанные на рис. 1.4, пока не определена структура времени откли­ка для каждой пользовательской операции - «сверху вниз» в контек­сте этого рисунка. Понимая, какая информация необходима для уста­новления причинно-следственных связей, мы ясно видим как недо­статки метода C, так и силу метода R. Нельзя достоверно определить связи в направлении от причин к симптомам (снизу вверх). В то же время не составляет труда провести стрелки от симптомов к причинам (сверху вниз), т. к. профиль ресурсов для выбранной пользователь­ской операции точно указывает их местоположение.

Проект, в котором не установлены причинно-следственные связи, не­управляем. Выбор приоритетов при повышении производительности всегда должен основываться на экономических приоритетах бизнеса. Не нарисовав такие стрелки, нельзя правильно организовать свои дей­ствия, основанные на внутренних показателях производительности, полученных из отчетов Statspack. Без этих стрелок едва ли не единст­венной возможностью для вас останется «калькуляция стоимостей», в частности коэффициентов попаданий. К сожалению, такие величины плохо коррелируют с экономическими показателями бизнеса. В рас­смотренном выше примере с платежной ведомостью ситуация три ме­сяца оставалась неопределенной. Проект завершился в тот день, когда команда получила данные, приведенные в примере 1.3.