Аудит производительности ИТ-систем

Постепенное снижение производительности является общей проблемой растущих информационных систем любых масштабов, от small office до крупных ERP-решений, построенных на самых современных платформах. Причины тут могут быть разными, и решать эту проблему также можно различными способами. Единственный неверный выбор — бездействие, ведь сама по себе проблема не решится...

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

В разной степени на производительность информационной системы влияют скорость исполнения кода, быстрота обмена данными и доступа к ним (см. рисунок).

Приведем простой пример, показывающий, как постепенное падение производительности делает информационную систему нежизнеспособной. Допустим, ваша система локализована в двух часовых поясах и не обслуживает клиентов с 22:00 до 10:00 по местному времени — это значит, что вы можете выделить «сервисное окно» продолжительностью в десять часов для операций обслуживания. И если в первый год жизни системы все необходимые операции выполнялись в течение двух часов, то к концу третьего года вы обнаружите, что на её обслуживание требуется уже шесть часов, а к концу четвертого выяснится, что эти задачи занимают всё сервисное окно и риск перебоев в обслуживании стал совершенно реальным.

Все, кто сталкивался с такими проблемами хотя бы единожды, понимают, что их нужно решать еще до их появления! И часто первой превентивной мерой становится наращивание мощностей серверов, рабочих станций, оперативной памяти, пропускной способности сети — т. е. увеличение инвестиций в уже сформированную информационную инфраструктуру...

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

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

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

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

Кто поможет?

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

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

Пример. Крупная компания в течение нескольких лет искала причину периодических блокировок работы отдела продаж. Обмен данными по сети фактически отсутствовал, так как все пользователи базы данных работали с сервером через терминал Citrix. Самостоятельные проверки информационной системы, проводимые ИТ-отделом, показывали, что производительность сервера базы данных превышает реальные потребности компании и не может быть причиной задержек. По результатам аудита, выполненного в соответствии с методологией, было выявлено, что проблема проявляется при печати документов пользователями из регионов. Дело в том, что в этих случаях при печати в терминальном режиме начинался активный обмен данными с регионами через слабый Интернет и система ждала завершения передачи каждого документа, блокируя работу остальных пользователей совершенно неочевидным и трудноопределимым образом.

Как это выглядит?

Аудит — это стандартный, но весьма объемный набор процедур, который позволяет локализовать проблемы на различных участках информационной системы. ERP-система представляет собой необъятную среду со множеством таблиц и колоссальным программным кодом, и конкретное место, порождающее проблемы, может находиться где угодно. Для проведения аудита используется определенный код, который внедряется в рабочую систему и ведет специальные журналы выполнения различных задач и функций. Аналогичным образом изучают серверы баз данных и системы документооборота. При этом важную роль играет правильная работа пользователей информационной системы, что тоже исследуется. Системные интеграторы, предлагающие услуги аудита производительности и оптимизации информационных систем, имеют собственные наработки, которые могут быть оформлены даже в виде отдельных программных пакетов.

По наблюдениям консультантов аудит одной базы данных на одном сервере занимает около 80 человеко-часов (40 человеко-часов уходит на обследование и 40 человеко-часов — на анализ результатов и подготовку отчета). Все этапы последовательны, поэтому работа выполняется, как правило, одним специалистом уровня ведущего консультанта или ведущего архитектора, который хорошо знает модули ERP-системы и их взаимосвязи, серверы СУБД, инфраструктуру и взаимное влияние всех факторов.

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

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

Дороги, которые мы выбираем

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

Вариант 1. Расширение штата показало, что «узким местом» в системе был не оператор склада, а складской контур, скорость работы которого упала по причине увеличения объема данных в системе. Было принято решение модернизировать складской сервер за счет расширения объема оперативной памяти и установки дорогостоящей системы хранения данных; это помогло, но ненадолго. Компания была вынуждена внедрить новую складскую систему.

Вариант 2. Прежде чем принимать кадровые или инвестиционные решения, компания провела аудит производительности и комплексную оптимизацию; в результате повышения продуктивности складской системы оказалось, что единственный оператор склада в состоянии обрабатывать в три раза больше документов.

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

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