2.1. Мы работаем только с проблемами
Для начала хотелось бы уточнить, какие именно задачи решают 1С:Эксперты по технологическим вопросам. Иногда случается, что задачи, которые нам присылают, формулируются так: провести аудит нашей системы управления торговлей, оценить:
- Быстродействие системы. Анализ аппаратных и программных средств, поиск узких мест. Рекомендации по увеличению быстродействия.
- Степень соответствия программного кода стандартам «1С». Возможно, дать рекомендации по исправлению, с расчетом стоимости работ.
- Степень востребованности доработок функционала в системе.
- Оптимальность реализации написанного функционала с точки зрения методологии (оптимальность бизнес-процессов) и с точки зрения программирования.Дать рекомендации по оптимизации.Дать рекомендации по развитию системы; в ближайшей перспективе планируется подключение баз пятнадцати филиалов
Можно высказать ряд догадок , откуда именно берется подобная постановка задач, однако есть смысл сказать сразу: задача в подобной постановке решена быть не может. Хотя бы просто потому, что в ней не задано ни начальное, ни конечное состояние системы, ни само пространство состояний. Давать же рекомендации по переходу из одного неизвестного состояния в другое неизвестное состояние в пространстве неопределенной размерности, а также оценивать стоимость работ по такому переходу как-то затруднительно, потому что потом за свои рекомендации придется отвечать.
Тем не менее, если люди к вам обратились, значит, определенная потребность в ваших работах есть, и надо как-то выяснить, что именно их к вам привело и какую задачу нужно решить на самом деле.
Для этого надо определить:
- пространство состояний системы,
- текущее состояние и мнение заказчика о нем,
- желаемое состояние и мнение о нем.
Обычно бывает, что задача сводится к двум вариантам:
- Работающая система. Заказчик обратился к вам, потому что текущее состояние системы его не устраивает. Это можно переформулировать так: пользователи, работающие в базе, сталкиваются с какими-либо проблемами.
- Существенно изменяемая или проектируемая система. Заказчик обратился к вам, потому что у него есть ожидания, что после некоторых изменений в системе пользователи, работающие в базе, начнут сталкиваться с какими-либо проблемами. Текущее состояние системы его устраивает, но сама система находится на пороге изменений либо уже изменяется.
В обоих случаях существует важный объект, называемый проблемой. Введение этого В обоих случаях существует важный объект, называемый проблемой. Введение этого объекта позволяет определить пространство состояний системы и задать количе- ственные характеристики, определяющие желательные и нежелательные состояния.
Существует частный случай варианта 1.
У нас все медленно работает. Сколько стоит посмотреть и исправить?
Хотя пространство состояний определено (это время выполнения каких-то операций) Хотя пространство состояний определено (это время выполнения каких-то операций) и текущее состояние обозначено как нежелательное, для такого варианта бывает характерно, что по разным причинам более подробной детализации получить не удается. В таком случае, если требуется назвать сроки и стоимость работ, лучше договориться об экспресс-диагностике (см. раздел 4.22) и уже по итогам анализа данных, полученных о системе, попробовать самостоятельно сформулировать проблемы, требующие решения.
Итак, что такое проблемы. Это те симптомы, которые видит (или потенциально увидит, если речь об изменениях системы) пользователь и которые определяют для него текущее состояние системы как нежелательное. К ним относятся:
- медленная работа,
- зависания,
- сообщения об ошибках.
Это означает, например, что участок кода, при написании которого никто и не думал ни о каких стандартах и при написании которого оптимизировали затраты на его создание, а не время его выполнения, совершенно не обязательно надо дорабатывать, потому что может иметь место следующее:
- Этот код работает всегда с очень малым объемом данных и поэтому всегда выполняется быстро. Поясню: очень плохой код может выполняться за 0,1 с. Если его оптимизировать, он станет выполняться в 10 раз быстрее, т. е. за 0,01 с. Но поскольку абсолютное значение в 0,1 с мало само по себе, то такой код, скорее всего, оптимизировать не надо, даже если он написан совершенно ужасно.
- Этот код никогда не вызывается или вызывается раз в год.
- Любой другой пример, почему совершенно неоптимальный, в спешке написанный код может не создавать пользователям никаких проблем. Увидев такой код, совершенно не надо начинать его оптимизировать просто по факту его выявления.
То, что пользователь «видит» проблемы, не обязательно означает, что он «жалуется» на них. Желание жаловаться является субъективным, подвержено изменениям и формализации не поддается, а это означает, что «наличие жалоб» в качестве формальной границы, отделяющей желательное состояние системы от нежелательного, не годится совершенно.
И хотя очень многие службы поддержки на практике используют количество обращений и жалоб в качестве одного из основных показателей своей деятельности, качественный мониторинг проблем при таком подходе весьма затруднителен.
Поэтому надо понять, что проблема – это симптом, который пользователь видит. А реагирует он на него или нет – нас не интересует, так как система содержит средства, позволяющие нам наблюдать эти же симптомы. Нас интересует, вышли ли некоторые объективно измеряемые характеристики этого симптома из зоны желательных значений или нет, а получать эти сведения можно и без привлечения пользователей.
Однако, несмотря на наше стремление определить пространство состояний исключительно в объективно измеряемых показателях, этого сделать не удается. Есть две вещи, определяющие размерность и границы пространства состояний, являющиеся по определению субъективными, поскольку они не измеряются, а назначаются человеком:
- важность проблемы: количеством важных проблем определяется размерность пространства состояний, относительная важность (приоритет) определяет порядок осей координат этого пространства;
- разделение количественных значений характеристик на желательные и нежелательные (а также в некоторой степени желательные, если допускается нечеткость подмножеств): этим определяются границы областей пространства состояний, в которых мы будем работать.
Несмотря на такую субъективность и, возможно, нечеткость, существует единственный разумный способ формализовать важность и желательность – зафиксировать список важных проблем, их относительную важность (приоритеты) и желательные значения количественно измеряемых показателей этих проблем в договоре. – Много шума из НИЧЕГО, но деньги надо зарабатывать хоть из воздуха…
Если важная проблема возникает вследствие превышения допустимого значения длительности выполнения системой некоторого действия, такое действие называют ключевой операцией.
То есть, говоря наоборот: ключевая операция – это операция (действие) системы, у которой количественной характеристикой, определяющей наступление нежелательного состояния, является время выполнения этой операции, и наступление этого нежелательного состояния является важной проблемой.
Обычно ключевая операция – это однократное нажатие пользователем какой-то кнопки на форме или выбор пункта меню, а время выполнения – это время, за которое система это нажатие отрабатывает. Иногда разные кнопки могут интерпретироваться как одна и та же ключевая операция (но обычно при этом системой выполняются одни и те же действия: проведение документа, формирование отчета, открытие формы и т. п.) .
Когда таких действий выполнено много, имеет смысл как-то сворачивать в число совокупность всех полученных значений длительности их выполнения (получать интегральную характеристику). Фирмой «1С» в качестве способа такой свертки применяется методика APDEX. Подробнее о понятии ключевой операции и интегральной характеристике APDEX.
Если важная проблема возникает вследствие реакции системы, не позволяющей продолжить выполнение действия (единичной или некоторого количества за период), такую реакцию системы называют критичной ошибкой.
То есть, говоря наоборот: критичная ошибка – это операция (действие) системы, у которой количественной характеристикой, определяющей наступление нежелательного состояния, является фактическое количество таких действий за период, и наступление этого нежелательного состояния является важной проблемой.
Все проблемы таким образом оказываются поделенными на два класса, и обычно в договорах по повышению технологического качества информационных систем «1С» их выделяют как:
- коэффициент производительности: значение показателя APDEX, являющееся сверткой времени выполнения ключевых операций;
- количество критичных ошибок, обычно за какой-то период, к которым относят:
- □ ошибки блокировок;
- □ системные ошибки;
- □ ошибки защиты;
- □ падение кластера серверов «1С:Предприятия»;
- □ зависание кластера серверов «1С:Предприятия».
Надо отметить, что часть критичных ошибок в проектной документации на создание центров обработки данных и в других похожих задачах интерпретируется как устой- чивость системы, а также как процент доступности системы. Что это и как осущест- вляется расчет таких показателей, см. главу «Теория», раздел 3.4.
Также следует обратить внимание на то, что при работах по оптимизации системы и при работах по повышению технологического качества системы не уделяется внимания несистемным, функциональным и прикладным ошибкам, в т. ч.:
- синтаксическим ошибкам кода;
- неправильной, с точки зрения пользователя, реакции системы без сообщения об ошибке (при нажатии кнопки не заполняется табличная часть);
- неправильным расчетам (НДС считает 17 % вместо 18 %) и т. п.
Связано это с тем, что такие ошибки относятся к другим областям знаний и обычно требуют от сотрудника несколько (а иногда и существенно) иных знаний и умений, чем те, которые предъявляются к 1С:Экспертам по технологическим вопросам.
В итоге в договор должен попасть список ключевых операций и критичных ошибок, формально определяющий пространство состояний системы. Критерий включения в список – важность возникающей проблемы и ее практическая значимость.
По каждому из компонентов списка должно быть указано целевое состояние, в которое надо привести этот компонент:
- приемлемая стабильность,
- целевое значение APDEX для каждой из ключевых операций.
В совокупности это даст целевое состояние всей системы. Существует опасность задать слишком большой список ключевых операций. Это может привести к следующему: обычное время решения одной проблемы – дня три; 20 проблем = 60 рабочих дней – это 3 месяца. С учетом того, что при работах по оптимизации существует необходимость устанавливать мораторий на внесение изменений в определенную область конфигурации (а если операций много, то на всю конфигурацию), устранение даже 20 проблем потребует трехмесячного моратория на доработки функционала. В реальности даже такой срок предоставить никто не может, не говоря уже о большем.
Поэтому список ключевых операций надо ограничивать, и совершенно точно нет смысла включать в него свыше 20 позиций. Впоследствии (после завершения оптимизации этих 20 операций) можно будет составить новый список из следующих по приоритету операций.
Целевое состояние, которое мы описанным выше образом формализовали, определяет требования к производительности, доступности и работоспособности системы, которым она должна удовлетворять либо в ее нынешнем состоянии, либо с учетом ее планируемых изменений.