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

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

Выявите пользовательские операции, требующие ускорения с точки зрения бизнеса.

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

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

Перейдите к шагу 1.

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

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

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

Одно из наиболее значительных достижений Голдрата (Goldratt) в об­ласти оптимизации систем заключается в наглядной иллюстрации то­го, что локальная оптимизация совсем не обязательно ведет к оптими­зации глобальной [Goldratt (1992)].

Модель «дымовых труб» заразительна. Даже в кратких заявках на уча­стие в конференциях на тему Oracle от нас требуют выбрать такую

Одним из толчков к созданию Метода R послужила история, рассказан­ная Эли Голдратом в книге « The Goal» (Та самая цель ) [Goldratt (1992)]. В книге описана победа нового революционного метода оптимизации производительности над старым, глубоко укоренившимся методом, да­вавшим худшие результаты. Метод Голдрата применяется в оптимиза­ции производства, но рассказанная история до боли напоминает сего­дняшнюю ситуацию в сообществе специалистов по Oracle: ниспроверже­ние метода оптимизации, основанного на неверной системе измерений.

Эта книга опровергает массу ложных идей, на которых были основаны «знания» об оптимизации многих аналитиков. Вот два наиболее ярких урока, которые я усвоил из этой книги:

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

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

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

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

Лучший специалист по производительности

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

Имея честь общаться с десятками аналитиков по производительности, я заметил, что большинство из них обладает общим набором качеств, которые, как мне представляется, и лежат в основе их успеха. Лучшая из известных мне характеристик этих талантливых специалистов при­надлежит Джиму Кеннеди (Jim Kennedy) и Анне Эверест (Anna Eve­rest) [Kennedy and Everest (1994)], выделившим четыре группы лич­ных качеств:

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

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

В области межличностных отношений хороший аналитик должен обладать определенным набором качеств. Доброжелательность слу­жит ключом к получению достоверной информации от пользовате­лей, владельцев бизнеса и персонала, обслуживающего компонен­ты системы. Самообладание требуется для поддержания порядка в кризисные моменты, особенно с наступлением неизбежной «па­нической» стадии проекта. Уверенность в себе необходима для под­держания среди жертв и виновников проблемы правильного мо­рального духа, вселяющего уверенность в выполнимости проекта. Хороший аналитик обладает тактом и умением объединять уси­лия для достижения поставленной цели.

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