Мобильная        
   PDA-версия  


интеллектуальная группа

KIBORG . net



@   О КОМПАНИИ

@   УСЛУГИ

@   КОНТАКТЫ

      AXAPTA / 1С

      MRP / CRM

      УПРАВЛЕНИЕ

-   ОБУЧЕНИЕ

V   СТАТЬИ

-   ПУБЛИКАЦИИ

#   ЛУЧШИЕ

-   ИССЛЕДОВАНИЯ

-   ТЕРМИНОЛОГИЯ




С т а т ь и



o   ПО ДАТАМ
o   ПО ЖУРНАЛАМ

==== >>   ERP
o   УПРАВЛЕНИЕ
o   СИСТЕМЫ





() Предпроект ERP

() Методология

() Внедрение ERP

(+) ЭКСПЛУАТАЦИЯ, ПОДДЕРЖКА






СУБД

 
 

ERP   /\/   Управление   /\/   Системы     (Лучшие)


Предпроект - Методология - Внедрение - Эксплуатация



Решение проблемы быстродействия


Что ограничивает быстродействие ИТ систем на основе баз данных

 

Главным делом жизни вашей
Может стать любой пустяк.
Надо только твердо верить,
Что важнее дела нет.
Все эпиграфы к статье взяты из книги «Вредные советы» Григория Остера

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

С технической точки зрения все можно было сделать и иначе: сделать отдельную табличку с информацией про пароходы, отдельную про характеристики товара и отдельную про операции (как велит теория баз данных). Однако игра не стоила свечь, в год мы работали не более чем с 20 кораблями и ни каких задачь оптимизации не ожидалось даже в самой далекой перспективе.

Увы, таких компаний и таких замечательных простых задач очень мало. Чаще приходится работать с бизнесом сущетвующим на конкурентных рынках, и предлагающим широкий ассоримент товаров (для привлечения покупателя). Ассортимент тянет за собой накладные по 100 строк в каждой. Экономия оборотных средств заставляет покупателей покупать маленькими партиями. А уж про розницу и говорить не приходится – это миллионы штучных покупок.

Большой объем данных под силу не всем типовым бизнес-приложениям. Почему? Такие объемы можно было успешно и качественно обрабатывать и на компьютерах пятнадцатилетней давности. С каждым годом скорости процессоров, памяти, жестких дисков и сетей растут. Но информационные технологии это не копание ямы, а сложные системы с большим количеством, нелинейных взаимосвязей. И случается, что даже установка более мощного сервера приводит к еще большему замедлению операций. Ценность ИТ специалиста в том, что он может разобраться с конкретным примером торможения, поставить диагноз и найти решение. Каждый случай уникален, и все же, реальных источников плохого быстродействия не так уж много.

Файл-серверные технологии мы пока оставим за бортом нашего исследования, т.к. возможности совершенствования работы с файлами почти исчерпаны производетелями системного софта. В промышленных ИТ системах для хранения данных используются базы данных (БД). Вариантов их настройки и способов реализации собственных задачь очень много и именно здесь часто совершаются недопустимые ошибки, которые затем тормозят и губят ИТ системы в разработку и внедрение которых были вложены немалые деньги .

Коммутаторы и концентраторы (топология сети)

Диагностика: сложно определить где именно застревает пакет при передачи информации между компьютерами
Решение: изменение топологии сети, сегментирование сети
Но если хочешь довести
Людей до горьких слез,
Их безопаснее всего
По радио дразнить.

Внутри офиса компьютеры связаны в локальную сеть. А как связать между собой несколько офисов? Протащить свою сеть через город – дорогое удовольствие, а когда офисы находятся в разных городах – тем более. По этому сеть офисов, обычно, это несколько локальных сетей объединенных в общий пул, через интернет (с использований технологий шифрованных каналов). Проблему со скоростью интернета, к сожалению, прийдется оставить в покое. Конечно надо определить необходимый размер канала и выбрать провайдера, который его гарантирует, с запасом на рост объема данных. Еще полезно обзавестись резервным каналом и другим провайдером на случай сбоев. Но, к сожалению, провайдер гарантирует не весь интернет, а только канал до определенных узлов, а дальше все зависит от факторов, на которые мы сейчас повлиять не сможем: от топологии и загруженности территориальных интернет-сетей.

А на что можем? Нередко встречаются ошибки в организации собственных локальных сетей, и их стоит разобрать, чтобы не допустить торможения. Чаще всего причина в неправильной топологии (структуре) сети. Есть два ключевых компонента топологии: коммутаторы (switch) и концентраторы (hub). Концентратор это простое устройство быстро рассылающее пришедший пакет на все подключенные к нему компьютеры (не только туда куда нужно). Т.е. пакет размножается. При неправильном использовании концентраторов мы получим сеть с большим количество лишних пакетов. Каждый компьютер будет тратить кучу времени на их фильтрацию. Коммутатор же наоборот умный, и тратит заметное время на обработку пакета, но отправляет его только нужному адресату. Несколько коммутаторов стоящих друг за другом приводят к большой задержке при доставки пакета на нужный компьютер.

Зоопарк устройств

Диагностика: иногда устройства разных производителей не понимают друг-друга, несмотря на то, что используют стандартные протоколы, хуже если это происходит не постоянно а с непредсказуемой периодичностью
Решение: по возможности, использовать устройства одного производителя
И, от грохота спасаясь,
Разлетятся комары,
А испуганные мухи
Стаей кинутся на юг.

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

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

Оперативная память

Диагностика: многие не отдают себе отчет в том, что скорость жесткого диска в сотни тысяч раз медленнее скорости оперативном памяти
Решение: Увеличение количества оперативной памяти.
Никогда вопросов глупых
Сам себе не задавай,
А не то еще глупее
Ты найдешь на них ответ.

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

То, что по объему жесткие диски больше оперативной памяти – это понимают все, а вот зачем вообще нужна оперативная память и почему ее должно быть много – только избранные. Современные дисковые системы выгодно отличаются от своих более молодых собратьев, однако они работают медленнее чем оперативная память десятилетней давности. Оперативка работает со скоростью электрического взаимодействия, т.е. со скоростью света, с поправкой на сложность электрической схемы, и ограничена только тактовой частотой взаимодействия с процессором (это миллиарды операций в секунду). А дисковый накопитель работает со скоростью вращения диска (это, максимум, десятки тысяч оборотов в секунду). Работу с диском ускоряют быстрые каналы и кэш память, но по сути это костыли, которые помогают лишь в редких случаях. Многие диски имеют движущуюся головку, механическое движение которой еще сильнее замедляет процесс. Прогресс не стоит на месте и появляются новые технологии. Сейчас активно развивается флеш-память и твердотельные жесткие диски, которые работаю в десятки раз быстрее обычных. Это пока еще дорогие устройства, но их качество растет а стоимость падает. И всеже даже они работают в сотни раз медленнее оперативной памяти.

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

Кстати, надо понимать, что оперативную память не получится нарасщивать бесконечно, т.к. любой стандартный софт умеет использовать ее только до определенного предела. Например, Windows Server 2008 понимает максиму 64 Гб, подобные ограничения есть и у других систем и в частности SQL-серверов. Да и само серверное оборудование имеет архитектурные ограничения.

Нормализация данных

Сложность исправления: Если в системе уже есть данные, то изменение структуры данных – это длительная операция, которая возможна только при остановке системы.
Решение: Иногда тяжелый запрос можно заменить более легким или двумя легкими
Если гонится за вами
Слишком много человек,
Расспросите их подробно
Чем они огорчены?
<...>
Но снижать при этом скорость
Совершенно ни к чему.

В отличии от текстов в книгах и в интернете, в базах данных информация жестко структурирована. Она хранятся в таблицах. Основным инструментом работы с БД является оператор select предназначенный для получения информации из таблиц. Например чтобы узнать, сколько было пробито чеков за определенный период нужно с помощью оператора select обратиться к таблице со списком чеков задав при этом ограничения по дате и времени. Быстро работает select по одной таблице, особенно, если система сможет использовать индексы. Но нередко для решения наших задач нам требуются более сложные запросы по нескольким таблицам. Например нормализованная база данных имеет две таблицы с информацией по чекам: в первой (назовем ее «шапкой») храниться список чеков с общей суммой, номером кассы, фамилией кассира и временем покупки, в другой (назовем ее «строки») хранится информация о товарах в каждом чеке. Допустим мы хоим выяснить, действительно ли люди купив шоколадку люди сразу идут в кассу. Если это так, то (при низкой загрузке касс) они идут сразу в ближайшую кассу (пусть это будет касса №3). Чтобы это проверить надо получить информацию о том, сколько шоколада продается через кассу №3, а потом сравнить с тем сколько шоколада продается через кассу №1 и №2. Для этой цели нам надо связать две таблицы и взять номер кассы из «шапки» (т.е. из списка чеков), а код товара из «строк».

Select по нескольким таблицам – это перемножение матриц, Например выборка из двух таблиц в каждой из которых по 10 записей (в нашем случае 10 чеков по одной строки в каждом) превратиться в 100 элементарных операций, несмотря на то, что результатом будет одна, нужная нам, строчка (т.е. продали одну шоколадку). А если в каждой таблице по миллиону записей, то мы получим триллион элементарных операций. Без заметных глазу задержек с такими задачами справятся только суперкомпьютеры. Правильные индексы на таблице должны ускорить процесс, однако, даже теоретически, оптимизация запроса на двух таблицах ограничена использованием двух индексов, а нам нужно три: один для ограничения по первой таблице (номеру кассы), второй для связи таблиц (номер чека), третий для ограничений по второй таблице (код товара). На практике же, порой, системы не делают даже возможную оптимизацию из за технических особенностей и из за ошибок программистов.

Нормализация данных, которую рекомендует «Теория реляционных баз данных», упрощает программирования за счет снижения вероятности некорректных ситуаций. Но приводит к выборкам (select) по нескольким таблицам, которые, трудно оптимизировать. Например, если бы в нашем случае мы хранили номер кассы в «строках», то для каждого чека номер кассы хранился бы несколько раз. Это не только занимает больший объем памяти, но еще к тому же и не корректно: а вдруг в двух строчках по одному чему появятся разные кассы (произойдет нарушение целостности данных). Зато при этом выборку по шоколаду и по кассе №3 мы бы выполняли по одной таблице, и имея в этой таблице нужные индексы мы бы получили МГНОВЕННЫЙ РЕЗУЛЬТАТ (это звучит несколько фантастично, но чтобы понять что это возможно, следуте прочитать раздел «Индексы» ниже). Так что стоит порой пожертвовать красотой базы данных (в смысле теории), объемом данны и объемом кода, чтобы получить качественую скорость работы системы.

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

Временные таблицы внешних систем

Диагностика: неожиданное торможение на таблицах с небольшим объемом данных ставит специалистов в тупик.
Решение: не использовать временные таблицы внешних систем если количество записей может превысить 1000; аккуратно использовать операторы и инструменты языка для управления данными: массивы, контейнеры, сеты; внимательно относиться к механизмам буферизации (например, использовать мягкую буферизацию одной записи).
Чтобы самовозгоранья
В доме не произошло,
Выходя из помещенья
Уноси с собой утюг.

Системы и приложения, такие как ERP, CRM и другие типы ПО содержащего полезную логику (назовем их внешними), хранят данные на SQL-серверах баз данных и используют для взаимодействия с ними язык SQL запросов (работа с оператором select описана в главе «Нормализация данных»). Впрочем такое ПО (внешнее по отношению к SQL серверу), часто, содержит собственные встроенные механизмы управления данными: временные таблицы, контейнеры, сеты и инструменты буферизации данных. Эти механизмы предназначены для ускорения работы. Данные временных таблиц хранятся на локальном компьютере в оперативной памяти (нет потерь времени на сетевые запросы, на считывание данных с диска, на перевод данных из одного формата в другой). Для обработки данных используются мощности локального процессора (это разгружает процессор сервера).

Однако, далеко не все такие инструменты эффективно обрабатывают информацию. Проблемы со скоростью их работы нередко проявляются на незначительных объемах данных. Не помогает даже наличие правильных (соответствующих условиям фильтрации) индексов. Слово «незначительный» в данном контексте обозначает, что любой SQL-сервер с такими объемами данных и даже с объемами на порядки больше справляется прекрасно.

Часто нужно делать выборку объединяя две и более таблицы (подробно этот вопрос описан в разделе «Нормализвация данных»). Для временных таблиц внешних программных систем, такие выборки работают особенно медленно.

Блокировки данных

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

Механизм транзакция можно объяснить на следующем примере: если данные о чеке мы храним в двух таблицах (как это описано в разделе «Нормализация данных»), то при фиксации чека в системе сохраняется сумма чека в «шапке», а затем информация о товарах в «строках». Что будет если в процессе произойдет разрыв сетевого кабеля по какой то нелепой случайности? Ведь информация о чеке сохранена не полностью. Инструмент транзакций гарантирует нам правильность данных. Если информация о чеке сохранена вся, то чек зафиксирован в системе. Если же разрыв произошел по середине операции, то отменяется вся операция. Гибкость и удобство транзакций побуждает программистов регулярно (к месту и не к месту) использовать этот механизм, в то время как он таит в себе большую опасность, которая называется «блокировка».

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

В каждой системе есть сотни и даже тысячи типов операций, каждая из которых формирует разные транзакции, использующие различные таблицы. Заранее предсказать потенциальные блокировки очень сложно – каждый проект индивидуален. При накоплении данных в системе скорость работы падает, а время выполнения операций (транзакций) увеличивается и блокировки начинают вносить свою дополнительную лепту в падение быстродействия. Таблиц и типов операций много, и заранее предсказать блокировки сложно.

Сперва поможет увеличение мощности сервера, но если процессор, оперативную память и каналы данных наращивать уже некуда, то придется искать наиболее длительные операции и разбираться с ними отдельно: исправлять ошибки в select (см. раздел «Нормализация данных»), добавлять или убирать индексы (см. раздел «Индексы») и т.д....

Индексы

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

Решая проблему по ускорению операций за счет использования индексов, многие не редко создают себе новую проблему, но не замечают этого. Чтобы правильно использовать индексы, надо знать как они устроены. А по сути (не в даваясь в детали B-tree и других решений) индексы в БД устроены одинаково.

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

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

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

Инструменты мониторинга потребляют ресурсы системы

Диагностика: Источником торможения могут стать нестандартные инструменты о существовании которых ни кто в команде не знает.
Решение: Ведение журнала операций ИТ персонала с КИС в департаменте ИТ, постоянный мониторинг изменения скорости работы.
Если вы окно разбили,
Не спешите признаваться.
Погодите, — не начнется ль
Вдруг гражданская война.

У администраторов и программистов есть целый набор программных инструментов для мониторинга и анализа происходящего в системе. Эти программы собирают и анализируют специальную информацию (трафик, загрузку, особенности определенных операций), которая позволяет устранить ошибки или найти решение каких либо сложных проблем. Иногда это не типовые программы, а дополнительный код (скрипт, джоб) написанный для поиска решений специфичных для данного проекта. Не редко эти инструменты сами становятся причиной замедления. Выполняя свои действия они берут на себя часть ресурсов системы, и в некоторых случаях часть может оказаться значительной. Ошибки в настройках делают замедление непредсказуемым. Бывает что специалист завершив свою работу забывает отключать часть инструментов мониторинга. Хуже всего если специалист перевелся в другой отдел, или уволился, тогда поиск причин торможения может затянуться. Это не только логи, снифферы, различные журналы операций, счетчики производительности, которые накапливают информацию о деятельности приложения. Хуже если это нестандартные инструменты написанные под конкретную задачу. Для них не существует описания, и ни кто не знает как ими пользоваться.

Бороться с этой проблемой можно только ведением журнала операций который ИТ персонал выполняет работая с системой. Следует обязать каждого специалиста ИТ департамента регулярно писать отчет о производимых работах и используемых для этого программных и прочих инструментов. Анализируя записи журнала можно существенно быстрее найти проблему и ее устранить. Например, опрос свидейтелей показал, что первые признаки замедления появились в начале прошлой недели. Отлично, открываем журнал со списком исправлений на нужной странице и...

Суммарный эффект

Диагностики: Из нескольких причин надо выявить те, которые оказывают наибольшее влияние на замедление и те, которые устранить наиболее просто.
Решение: Последовательное выявление и устранение причин замедления системы.
Если твой сосед по парте
Стал источником заразы,
Обними его — и в школу
Две недели не придешь.

Чаще в сего к аварии приводит не одна а целая серия ошибок. Например, может быть так: плохая настройка системы вызывает тяжелый select внутри наиболее используемой операции. Не отключены счетчики производительности на сервере. Это усугубляется недостатком оперативной памяти. Транзакции становятся долгими по времени. Результатом длинных транзакций становятся блокировки. Учащаются взаимные блокировки. И т.д. Эта страшилка является обычно ситуацией и нередко проявляется в ИТ системах с большим объемами данных. Заметное расширение рынка ИТ привело к увеличению количества систем, что в свою очередь привело к существенному падению среднего качества проектов.

Что же делать если система тормозит? Надо провести диагностику. По ряду параметров определяется вероятная причина торможения. Затем надо проверить – действительно ли найдена реальная причина. Часто невозможно полностью смоделировать работу всей системы. Но часть параметров протестировать можно и нужно. Недопустимо проводить эксперименты на работающей системе, ведь результат может оказаться отрицательным, а возможность вернуть все назад существует не всегда. Нужно сделать полную копию действующей системы, на которой без риска пробовать менять параметры системы и проверять новые средства от замедления.

Когда диагноз поставлен можно сделать изменения, например: изменить топологию сети, поменять оборудование сети, изменить настройку сетевой системы, внести изменения в код ПО, изменить структуру данных, добавить или убрать индексы, увеличить мощность сервера (добавить процессоры, поставить более быстрые диски), добавить оперативной памяти, проверить по журналу после каких изменений система стала тормозить, изменить настройки SQL-сервера. Некоторые действия, сравнительно простые, почти не несут риска и могут быть выполнены и без диагностики.

Один надежный способ

Если ты в своем кармане
Ни копейки не нашел,
Загляни в карман к соседу, —
Очевидно, деньги там.

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

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

С чего начать

Бейте лампочки в подъездах —
Люди скажут вам «спасибо».
Вы поможете народу
Электричество беречь.

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

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

Выделим следующие факторы влияющие на выбор конкретного способа борьбы с торможением:
  • ограничения на операцию – в каком случае операцию сделать не возможно;
  • время, сложность и стоимость подготовки – определяется квалификацией и стоимостью специалистов, которые это могут сделать, а также необходимым объемом работы (стоимость оборудования не учитывается);
  • возможность протестировать результаты операции до установки на работающую систему;
  • время операции – время на которое бизнес будет остановлен;
  • риск не получить желаемого эффекта – обратно пропорционален п.3;
  • возможность откатить нежелательные последствия неправильных изменений (плохая оценка по данному пункту может быть скомпенсирована хорошей оценкой по п. 5);

Каждую характеристику (кроме п.1) оценим по пятибалльной шкале, но чтобы не возникло путаницы для отрицательных характеристик будем указывать отрицательные значения. Значение -5 для п.2 и п.4. может означать, что время заранее определить не возможно. Аналогично -5 для п.2 означает непредсказуемость стоимости/сроков подготовки операции. Данные таблицы отражают наш опыт решения указанных проблем. Каждый проект индивидуален, и его конкретные показатели могут отличаться. Здесь указана наиболее вероятная оценка ожидаемых показателей, которая получились из экспертных оценок специалистов.

. ограничения время /
слож-
-ность
под-
готовки
Воз-
мож-
ность протес-
ти-
ровать
Останов-
ка
системы
при
апгрейте
риск
бес-
полез-
ности
Воз-
мож-
ность
вернуть
все
назад
очистить данные системы . -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.
Т.к. проект подготовки является длительным, то в данном случае характеристика время / сложность / стоимость не является очень существенной, важен результат.

Итоги сравнения

Рукам никогда нигде
Не трогай ничего.
Не впутывайся ни во что
И никуда не лезь.
Напоминаем, что все эпиграфы взяты из книги «Вредные советы» Григория Остера

Среди всех возможных операций стоит выделить две особенные категории. Первая это операции, которые не требуют (почти) остановки системы, и в случае ошибки могут быть отменены: изменение настроек сетевой системы, увеличение мощности сервера, изменение топологии сети, замена сетевого оборудования, добавление оперативной памяти, изменение настроек СУБД. Эти операции можно выполнять в первую очередь, но нет гарантии, что они дадут результат. Из первой категории следует выделить добавление оперативной памяти для сервера СУБД, как наиболее эффективную операцию.

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

 

 

 

ДМИТРИЙ МАРТЫНОВ 2013 г.

Экспертная оценка: Мартынов Дмитрий, Мольков Вячеслав
Экспериментальная проверка: Мартынов Дмитрий

 

КОПИРАЙТ

Статья разрешена к копированию любыми средствами без изменения содержания с обязательным указанием автора, источника и гиперссылки на оригинал:

гиперссылка html:
гиперcсылка для форума/блога:

 

Консалтинг по управлению ИТ проектами.
-  Аудит, анализ и тренинги


Экспертиза ....
Интеграция ERP, MRP, CRM, SCM систем
-  Настройка, обучение, доработка.



Внедрение ....
Бизнеспроцессы: описание в стандартах IDEF, ARIS, EPC, On-Target



Бизнес-анализ ....
Оптимизация бизнеса. Внедрение, электронного документооборота
-  Управление ответственностью и рисками.



Мотивация ....
Разработка регламентов управления с использованием ИТ.
-  Повышение стабильности и эффективности работы отделов.


Реорганизация ....
Гарантии качества подтверждены опытом наших экспертов.
-  Все наши специалисты сертифицированы.



Сотрудничество ....


 
  О компании    Услуги    Контакты    Axapta        Обучение    Управление   

СУБД     © 2005, ООО "Интеллектуальная группа Киборг"   PDA-версия