Привет, меня зовут Владимир Кононенко и я – руководитель управления внедрения в Группе компаний ОТР. Всем, кто работает с информационными системами (ИС), знакома такая история: на определенном этапе жизненного цикла ИС возникают ситуации, когда заказчик, использующий ИС, высказывает недовольство, что все тормозит, пользователи не могут работать, софт не выдерживает нагрузку, и так далее. В данной статье я бы хотел пошагово рассказать, как я решаю проблемы с производительностью и стабильностью ИС, созданных нашей компанией.
Я буду опираться на личный опыт и практику в недавних проектах ОТР – у нас много крутых специалистов с высоким уровнем экспертизы, есть центр компетенций PostgreSQL – а также на собственные знания: в свое время я окончил с отличием Ростовский государственный университет по специальности «Математические методы и исследование операций в экономике», а также получил сертифицированный черный пояс по программе «Шесть сигм» Государственного университета штата Аризона, США. На примерах из моей практики вы увидите, какие я выбираю инструменты и как они работают на каждом этапе.
С чего начать
Как меня научили еще в ВУЗе, практики без теории не бывает. Это значит, что для решения практической задачи нам нужна методология, на основе которой мы и будем действовать. Я для себя выбрал концепцию и инструменты бережливого производства и 6 сигм. Суть концепции – выявление и исключение не добавляющих ценности продукту затрат и повышения стабильности рабочих процессов.
Итак, что мы имеем в начале нашего пути:
- ИС, к которой есть претензии;
- Клиента, который эти претензии выставляет, – в подавляющем большинстве случаев – на условно бытовом уровне, без четкого описания и метрик, которые бы характеризовали проблему;
- Команду наших спецов по оптимизации.
Собрав эти три элемента, мы делаем первый шаг.
Шаг 1. Убеждаемся, что проблема реально есть
В этом нам помогает один из принципов бережливого производства, который гласит: оцени проблему своими глазами – не доверяй только отчетам. То есть, я, как руководитель команды оптимизации, встречаюсь с пользователем, у которого наиболее ярко воспроизводится проблема, и лично смотрю, какие действия он выполняет и к каким последствиям это приводит.
Не часто, но бывают случаи, когда на данном этапе проблема и решается! Например, у одного из наших заказчиков – финансовой организации – в одном из самых крупных подразделений, обслуживающих клиентов, как раз возникла неприятная ситуация – клиенты не могли подключиться к системе финансового документооборота в моменты пиковой активности. И вот, посетив одного из крупных клиентов подразделения, я наблюдаю картину, как бухгалтер подключается к аппаратно-программному комплексу шифрования (АПКШ) для обеспечения защищенного канала, получает отказ в подключении, и с гордым видом заявляет: «Вот видите, у меня не получается подключиться к вашей программе»!
АПКШ к созданной нами ИС никакого отношения не имеет, но помочь клиенту нужно – поэтому возвращаемся в подразделение заказчика, где стоят АПКШ, и начинаем разбор. Выясняем, что в подразделении установлены 2 модуля АПКШ, их суммарная производительность равна количеству клиентов данного подразделения. Вот только распределение клиентов по данным модулям выглядело так: на одном – 3 vip-клиента, а все остальные – на другом. Это и приводило к тому, что в момент пиковой активности клиентов на одном модуле просто не хватало пропускной способности.
Эх, если бы все проблемы решались так просто, но, к сожалению, это не так. Поэтому после того, как мы убеждаемся у конечного пользователя, что проблема реальна и действительно относится к нашей ИС, мы переходим к следующему шагу.
Шаг 2. Наводим порядок
После разбора проблем, с которыми столкнулись пользователи ИС, мы обращаемся к инструменту бережливого производства 5S – наведение порядка. В нашем случае – это наведение порядка в инфраструктуре заказчика, в его ЦОДе.
Вернемся к нашему клиенту – финансовой компании и ее крупному подразделению. После решения проблемы с организацией защищенного канала в виде перераспределения пользователей по модулям АПКШ, мы перешли к разбору причин медленной работы, а также длительного входа уже в нашей системе документооборота. И начинаем этот анализ мы с двух направлений:
а) Анализ настроек выделения ресурсов java-приложению сервера аутентификации в части длительного входа в ИС
Здесь нас ожидал очередной сюрприз – в настройках выделения памяти мы обнаружили значение, меньше чем у самого маленького подразделения данной организации. Ответ на вопрос «А почему так мало?» нас удивил еще больше – «А на сервере больше нет…». То есть модуль аутентификации работал на старом и очень слабом сервере в самом крупном подразделении организации – как так? Результат разбора показал, что еще несколько лет назад для данного модуля были закуплены очень мощные сервера, которые смонтировали и установили в ЦОД подразделения, включили и… они уже несколько лет просто греют воздух – перенести на них модуль аутентификации просто забыли! Ну что же делать, мы помогли перенести наш модуль аутентификации на его законное место и проблема с длительным входом была решена.
б) Сбор и анализ статистики Nmon по работе железа в части медленной работы приложения
Собрав статистику работы сервера СУБД, мы обнаружили, что скорость ввода-вывода на дисковом хранилище оставляет желать лучшего – она в разы меньше нормативной. Разбор показал, что RAID-массив дискового хранилища собран из дисков разной скорости, но самым интересным оказалось то, что рядом с таким промышленным дисковым хранилищем располагалась СХД с флэш-памятью – не эксплуатируемая, а существующая как резерв. Думаю, вы догадываетесь, что очень скоро данное резервное СХД стало промышленным, и проблема медленной работы прикладного программного обеспечения (ППО) на этом была решена.
Вот так наведение порядка в ЦОДе помогает решить проблемы производительности ППО!
Но, что делать, когда ИТ-подразделение заказчика не зря ест свой хлеб и со стороны ИТ-инфраструктуры все работает как часы, проблем с нагрузкой на «железо» нет, но при достижении определенного уровня нагрузки на ИС в ней начинаются существенные замедления во время выполнения тех или иных операций? Для решения этого вопроса мы переходим на следующий шаг.
Шаг 3. Ищем коренной источник проблемы
Очень часто может казаться, что проблема низкой производительности заключается в одном модуле ИС, но детальный анализ обнаруживает корень проблемы совсем в другом месте, несмотря на ложные яркие проявления.
Давайте поясню на примере – у одного из наших заказчиков работает очень большая и высоконагруженная ИС с десятком бизнес-модулей и отдельным интеграционным слоем, обеспечивающим взаимодействие между ними. При этом интеграционные взаимодействия были построены с использованием синхронных веб-сервисов. Нагрузка на этот интеграционный слой была значительна, и в пиковые периоды активности пользователей в ней начинали происходить замедления, вплоть до полного зависания интеграции, были жалобы, что «эта интеграция опять умерла».
Анализ проблемы выявил, что при передаче документа на обработку в один из бизнес-модулей интеграция вызывает синхронный сервис и ожидает ответ об успешной или не успешной обработке для возвращения ответа модулю-отправителю документа. В момент пиковой нагрузки модуль-получатель начинал недопустимо медленно проводить обработку и, тем самым, держал открытыми большое количество подключений интеграции к нему. В результате у интеграционного слоя в какой-то момент оказывались заняты все подключения – он переставал отвечать другим модулям, что и приводило к коллапсу.
Таким образом, причина нестабильной работы интеграции оказалась в медленном выполнении операций в одном из бизнес-модулей, и, решив данную проблему, мы смогли вернуть систему к балансу и стабильной работе.
Здесь необходимо упомянуть, что очень большую помощь в таком анализе оказывает грамотно выстроенное логирование работы ИС, в частности, логирование длительности выполнения бизнес- и технологических операций, а также использование инструментов работы с логами. Например, в нашем случае, это был стек ELK (Elasticsearch, Logstash, Kibana).
Однако найти истинное узкое место – это только полдела, нужно еще и придумать, что с ним делать. Поиск решения порой бывает нетривиальным, особенно когда с точки зрения кода все выглядит очень даже неплохо, с точки зрения обращений к базе данных тоже замедлений нет – то есть операция на самом деле тяжелая и действительно выполняется медленно. Что же делать в таком случае?
Перейти к финальному шагу.
Шаг 4. Устраняем потери
Если же очевидных решений проблемы нет, чтобы оптимизировать тяжелый процесс, нужно перепроектировать саму операцию – устранить действия, не добавляющие ценности и расходующие ресурсы.
Уже по традиции рассмотрим пример – вернемся к первым шагам и нашему клиенту, финансовой организации и ее подразделениям. В одно из подразделений стекаются финансовые заявки от клиентов с несколькими подписями сотрудников клиента, далее в подразделении организации приходит многоступенчатый контроль этих заявок и подписание их уже сотрудниками подразделения. В итоге заявки пачками приходят на утверждение руководителю подразделения – пачками по несколько тысяч штук, и таких пачек в день может быть несколько десятков.
Мы столкнулись с проблемой, что, чем ближе документ к утверждению руководителем подразделения, тем больше времени тратится на его согласование – у руководителя могло уйти до 2 часов на пачку документов. Анализ показал, что самой длительной операцией при согласовании на каждом этапе оказалась проверка всех наложенных подписей на документ до этого – естественно, что с ростом количества согласований возрастало и время на проверку все большего количества электронных подписей. При этом целесообразности проверять все подписи не было – для гарантии неизменности документа достаточно на каждом шаге проверять валидность первой и последней подписи.
Устранение данных лишних действий из бизнес-операции позволило добиться приемлемого времени на выполнение операций согласования и утверждения.
Ну и еще один пример: в ИС, состоящей из двух бизнес-модулей:
- Бизнес-модуль 1. Отвечал за бизнес-обработку документов и формирование бухгалтерских записей;
- Бизнес-модуль 2. Отвечал за хранение бухгалтерских записей и формирование отчетности;
При передаче записей бухучета из первого модуля во второй возникла проблема.
Передача шла пакетами по 10 тыс. записей и скорость обработки пакета во втором модуле занимала до 30 минут, что оказалось слишком долго и приводило к образованию очереди из необработанных пакетов. Суть операции по обработке пакета была довольно проста: для каждой записи из таблицы балансов бухгалтерских проводок находился нужный баланс с нужной кодовой комбинацией счетов и аналитик, и с периодом, соответствующим периоду записи. Баланс пересчитывался в зависимости от данных записи из пакета, и сохранялся обратно в таблицу – для обработки пакета такая операция проводилась 10 тыс. раз.
Применив принцип Парето к данным, содержащимся в пакете, мы выяснили, что количество уникальных кодовых комбинаций, используемых в бухгалтерских проводках, не превышает 300, и при этом 90% приходится на 10 комбинаций. Мы изменили алгоритм работы: теперь при импорте пакета сначала происходит группировка записей по комбинациям и расчет временного баланса для каждой комбинации из пакета, а уже после извлекаются 300 балансов, в которых уже и учитывались временные балансы. Такой подход позволил сократить поиск и сохранение балансов в БД в десятки раз, тем самым мы привели время обработки пакета к нормативному значению – оно занимает менее 1 минуты!
Вот таким алгоритмом, основанным на принципах бережливого производства и 6 сигм, я пользуюсь для устранения проблем производительности и стабильности разрабатываемых нами ИС. Надеюсь, было полезно. Поделитесь, какими алгоритмами или методами вы пользуетесь для решения проблем производительности информационных систем. Что работает в ваших отраслях?
