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-сервера. Некоторые действия, сравнительно простые, почти не несут риска и могут быть выполнены и без диагностики. Один надежный способЕсли ты в своем кармане Очистка данных системы гарантирует повышение скорости ее работы. Главная проблема в том, что все данные нужны и отправить в архив нечего. Эти данные – это знания о бизнесе, которые позволяют получать историческую статистику на основе которой принимаются важные решения. Чем больше интервал времени за который эта статистика накоплена, тем более достоверным будет анализ. Есть и технические проблемы очистки. Далеко не во всех системах есть встроенная функция очистки данных оперативных таблиц. Чаще всего это надо делать вручную. Такая операция является длительной, и требует остановки системы. Она требует тщательной подготовки. Ошибка может привести к нарушению целостности данных и неправильной работе системы. При очистке нужно сохранить копию старой версии системы и данных для анализа. Но это все равно не решение. Любой серьезный анализ потребует собрать данные из двух систем – новой и старой, и это сделать, заметно сложнее, чем в случае, когда вся информация находится в одном месте. С чего начатьБейте лампочки в подъездах — Описанные здесь источники проблем, это подсказки к их решению. Их список не является полным, но он отражает наиболее типичные проблемы. Попробуем классифицировать операции увеличения быстродействия. Каждая такая операция состоит из подготовки и реализации. Реализация (апгрейт) может подразумевать остановку системы (т.е. остановку бизнеса) на время ее проведения. Даже при очень тщательной подготовке есть риск ошибки. Значит важным критерием является возможность отменить выполненные изменения. Если вы надставили оперативную память, то вынуть ее не сложно. Если же вы внесли изменения в структуру данных, и пользователи начали работать, и через некоторое время выяснилось, что стало хуже, то вернуть все назад не так то просто. Восстановить версию системы до изменений из резервной копии можно, но пользователям придется забивать все заново с момента изменений. А внести обратные изменения в структуру данных без потери данных не всегда возможно. Выделим следующие факторы влияющие на выбор конкретного способа борьбы с торможением:
Каждую характеристику (кроме п.1) оценим по пятибалльной шкале, но чтобы не возникло путаницы для отрицательных характеристик будем указывать отрицательные значения. Значение -5 для п.2 и п.4. может означать, что время заранее определить не возможно. Аналогично -5 для п.2 означает непредсказуемость стоимости/сроков подготовки операции. Данные таблицы отражают наш опыт решения указанных проблем. Каждый проект индивидуален, и его конкретные показатели могут отличаться. Здесь указана наиболее вероятная оценка ожидаемых показателей, которая получились из экспертных оценок специалистов.
Т.к. нам нужны действия, которые дают гарантированный результат, то они отсортированы по показателю "Риск бесполезности".
Т.к. проект подготовки является длительным, то в данном случае характеристика время / сложность / стоимость не является очень существенной, важен результат. Итоги сравненияРукам никогда нигдеНапоминаем, что все эпиграфы взяты из книги «Вредные советы» Григория Остера Среди всех возможных операций стоит выделить две особенные категории. Первая это операции, которые не требуют (почти) остановки системы, и в случае ошибки могут быть отменены: изменение настроек сетевой системы, увеличение мощности сервера, изменение топологии сети, замена сетевого оборудования, добавление оперативной памяти, изменение настроек СУБД. Эти операции можно выполнять в первую очередь, но нет гарантии, что они дадут результат. Из первой категории следует выделить добавление оперативной памяти для сервера СУБД, как наиболее эффективную операцию. Ко второй категории отнесем операции, которым надо уделить внимание до начала внедрения: подготовку правильной (не сильно нормализованной) структуры данных, изменение кода ИТ системы, изменение настроек ПО. При работающей системе их реализация затруднительна и непредсказуема, по этому лучше позаботиться о правильной подготовке системы заранее.
ДМИТРИЙ МАРТЫНОВ 2013 г.
Экспертная оценка: Мартынов Дмитрий, Мольков Вячеслав
|
полная версия С т а т ь иo ПО ДАТАМ o ПО ЖУРНАЛАМ ==== >> ERP o УПРАВЛЕНИЕ o СИСТЕМЫ () Методология (+) ЭКСПЛУАТАЦИЯ, ПОДДЕРЖКА |