|
Что ограничивает быстродействие ERP - Часть 2
Анализ и выводы
Начало см. Что ограничивает быстродействие ERP (Часть 1. Словарь проблем и решений)
Цепная реакция
Сложность диагностики: Из нескольких причин надо выявить причины по критериям: наибольшего влияния на замедление и те, которые устранить наиболее просто.
Решение: Последовательное выявление и устранение причин замедления системы.
Эксперты установили, что к аварии, скорее всего, привели действия экипажа, допустившего сразу несколько ошибок при заходе на посадку.
Время новостей
Чаще в сего к аварии приводит не одна а целая серия ошибок. Например может быть так: плохая настройка системы вызывает тяжелый select внутри наиболее используемой операции. Не отключены счетчики производительности на сервере. Это усугубляется недостатком оперативной памяти. Транзакции становятся долгими по времени. Результатом длинных транзакций становятся блокировки. Учащаются взаимные блокировки. И т.д. Эта страшилка является обычно ситуацией.
Заметное расширение рынка ERP и увеличению количества внедрений привело к существенному падению среднего качества проектов (см. статью Проблемы быстродействия ERP - системный кризис).
Если система тормозит
Надо провести диагностику. По ряду параметров определяется вероятная причина торможения. Затем надо проверить - действительно ли найдена реальная причина. Часто невозможно полностью смоделировать работу всей системы. Но хотя бы часть параметров протестировать можно и нужно. Недопустимо проводить все эксперименты на работающей системе, ведь результат может оказаться отрицательным, а не все изменения обратимы.
Когда диагноз поставлен можно сделать изменения, например: изменить топологию сети, поменять оборудование сети, изменить настройку сетевой системы, внести изменения в код ERP, изменить структуру данных СУБД, изменить настройку ERP, добавить индексы в СУБД, увеличить мощность сервера (добавить процессоры, поставить более быстрые диски), добавить оперативной памяти, проверить по журналу после каких изменений система стала тормозить, найти забытые пассатижи, изменить настройки СУБД.
Некоторые действия, сравнительно простые, почти не несут риска и могут быть выполнены и без диагностики.
Есть надежный способ
Еще одно действие с помощью которого многие решаю проблему быстродействия - это очистка данных системы. Проблем здесь тоже не мало.
Далеко не во всех системах есть встроенная функция очистки данных оперативных таблиц. Чаще всего это надо делать вручную. Такая операция является длительной, и требует остановки системы. Она требует тщательной подготовки. Ошибка может привести к нарушению целостности данных и неправильной работе ERP. Иногда проще повторить внедрение, чем экспериментировать с данными системы: взять систему на момент внедрения, ввести в нее начальные финансовые и складские остатки, и начать работу. Это не совсем внедрение, т.к. все уже умеют работать с ERP и уже хорошо знают ее особенности и возможности.
Главная же проблема чаще всего остается вне поля зрения. Накопленные в системе данные представляют собой знания о бизнесе. Корректный учет позволяет получать осмысленную историческую статистику о практике бизнеса в привязке к конкретным специалистам, клиентам, товарам, сезонам, складам, городам и другим сущностям. Чем больше интервал времени за который эта статистика накоплена, тем более достоверным будет анализ.
При очистке нужно оставить старую версию системы для анализа. Но это все равно не решение. Любой серьезный анализ потребует собрать данные из двух систем - новой и старой, и это существенно усложнит процесс.
С чего начать
А сосед горе-ученика тоже был слепой <…> подмастерье приготовил в точности такие же лепешки и положил ему на глаза. На следующий день у незрячего соседа глаза вообще вытекли <…> "Как же так. Учитель, я сделал, как ты сказал в прошлый раз!" <…> мудрец ответил: "Слепота бывает от разных причин: от сухости организма, от влажности, от жары, от холода и т.д. У тысячи слепых бывает тысяча причин. Иди, сынок. Тебе работать только пекарем".
Мирзакарим Норбеков "Опыт дурака, или ключ к прозрению".
Описанные здесь источники проблем - это еще не их решение, а только подсказка. Не такой уж и бесконечный набор. Попробуем классифицировать операции, которые можно провести с системой для увеличения быстродействия. Каждая операция состоит из подготовки и реализации. Реализация (апгрейт) может подразумевать остановку системы (остановку бизнеса) на время ее проведения.
При самой тщательной подготовке есть риск ошибки. Значит важным критерием является возможность отменить выполненные изменения. Если вы надставили оперативную память, то вынуть ее не сложно. Если же вы внесли изменения в структуру данных, и пользователи начали работать, и через некоторое время выяснилось, что стало хуже, то вернуть все назад не так то просто. Восстановить версию системы до изменений из резервной копии можно, но пользователям придется забивать все заново с момента изменений. А внести обратные изменения в структуру данных без потери данных не всегда возможно.
Выделим следующие факторы влияющие на выбор конкретного способа борьбы с торможением:
- ограничения на операцию - в каком случае операцию сделать не возможно;
- время, сложность и стоимость подготовки - определяется квалификацией и стоимостью специалистов, которые это могут сделать, а также необходимым объемом работы (стоимость оборудования не учитывается);
- возможность протестировать результаты операции до установки на работающую систему;
- время операции - время на которое бизнес будет остановлен;
- риск не получить желаемого эффекта - обратно пропорционален п.3;
- возможность откатить нежелательные последствия неправильных изменений (плохая оценка по данному пункту может быть скомпенсирована хорошей оценкой по п. 5);
Каждую характеристику (кроме п.1) оценим по пятибалльной шкале, но чтобы не возникло путаницы для отрицательных характеристик будем указывать отрицательные значения. Значение -5 для п.2 и п.4. может означать, что время заранее определить не возможно. Аналогично -5 для п.2 означает непредсказуемость стоимости/сроков подготовки операции.
Данные таблицы 1 отражают наш опыт решения указанных проблем. Каждый проект индивидуален, и его конкретные показатели могут отличаться. Здесь указана наиболее вероятная оценка ожидаемых показателей, которая получились из экспертных оценок специалистов.
| . |
ограничения |
время /
слож-
-ность
под-
готовки |
Возмож-
ность протес-
тировать |
Останов-
ка
системы
при
апгрейте |
риск
бес-
полез-
ности |
Возмож-
ность
вернуть
все
назад |
| очистить данные системы |
. |
-5 |
+2 |
-4 |
-1 |
+2 |
| изменить структуру данных ERP |
не во всех ERP структура доступна |
-5 |
+4 |
-2 |
-1 |
+2 |
| внести изменения в код ERP |
не во всех ERP код доступен |
-5 |
+3 |
-1 |
-2 |
+4 |
| изменить настройку ERP |
. |
-4 |
+3 |
-1 |
-2 |
+4 |
| добавить индексы в ERP |
. |
-3 |
+2 |
-2 |
-2 |
+3 |
| добавить оперативной памяти |
. |
-1 |
+1 |
-1 |
-3 |
+5 |
| изменить настройки СУБД |
. |
-3 |
+3 |
-2 |
-3 |
+4 |
| изменить настройки сетевой системы |
. |
-2 |
+2 |
-1 |
-4 |
+4 |
| увеличить мощность сервера |
. |
-1 |
+1 |
-1 |
-4 |
+5 |
| изменить топологию сети |
. |
-2 |
+1 |
-1 |
-5 |
+5 |
| поменять оборудование сети |
. |
-2 |
+2 |
-1 |
-5 |
+5 |
| проверить по журналу кто испортил |
следует вести журнал работ с КИС |
-1 |
+1 |
-5 |
-5 |
+1 |
| найти забытые пассатижи вручную |
. |
-5 |
+1 |
-5 |
-5 |
+1 |
Таблица 1. Вероятные показатели операций по оптимизации КИС.
Т.к. нам нужны действия, которые дают гарантированный результат, то они отсортированы по показателю "Риск бесполезности".
Важно, что те же самые действия можно сделать до начала внедрения системы, когда указанные проблемы быстродействия еще не появились. Надо наполнить систему большим количеством искусственных данных, и выполнить тестирование. Затем внести изменения в настройки системы, в код системы, в структуру данных системы, в индексы, в настройки СУБД.
| . |
ограничения |
время /
сложность
подготовки |
возможность
протес-
тировать |
риск
бесполез-
ности |
| изменить структуру данных ERP |
не во всех ERP структура доступна для редактирования |
-4 |
+4 |
-2 |
| внести изменения в код ERP |
не во всех ERP код доступен для редактирования |
-4 |
+4 |
-2 |
| изменить настройку ERP |
. |
-4 |
+4 |
-2 |
| добавить индексы в ERP |
. |
-2 |
+4 |
-3 |
| изменить настройки СУБД |
. |
-2 |
+4 |
-3 |
Таблица 2. Что можно сделать до начала внедрения ERP.
Т.к. проект подготовки является длительным, то в данном случае характеристика время / сложность / стоимость не является очень существенной, важен результат.
Подведем итог
Можно выделить 3 категории операций. Первая это операции, которые не требуют остановки системы, и в случае ошибки могут быть отменены: изменение настроек сетевой системы, увеличение мощности сервера, изменение топологии сети, замена сетевого оборудования, добавление оперативной памяти, изменение настроек СУБД. Эти операции можно выполнять в первую очередь, но нет гарантии, что они дадут результат.
Из первой категории следует выделить добавление оперативной памяти для сервера СУБД, как наиболее эффективную операцию.
Ко второй категории отнесем операции, которым надо уделить внимание до начала внедрения: изменение структуры данных ERP, изменение кода ERP, изменение настроек ERP. При работающей системе их реализация затруднительна и непредсказуема, по этому лучше позаботиться о правильной подготовке ERP заранее.
К третьей отнесем поиск закладок, подробных логов, журналов операций, счетчиков производительности и других неотключенных инструментов потребляющих ресурсы сервера. Несмотря на то, что время поиска и результат трудно-предсказуем, это может оказаться единственной причиной торможения системы. Помочь тут может только ведение журнала операций ИТ специалистов с КИС.
ДМИТРИЙ МАРТЫНОВ 2007 г.
Экспертная оценка: Мартынов Дмитрий, Мольков Вячеслав
Экспериментальная проверка: Мартынов Дмитрий
|
|
