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

Сергей Котов, serge_kotov@mail.ru

AxaptaReliablity.doc (482Kb, Для загрузки требуется регистрация на форуме у Mazzy)

Обеспечение надежности работы Microsoft Axapta

Цель статьи – представить системный и практичный подход к организации высоконадежного режима работы Microsoft Axapta для этапа промышленной эксплуатации системы.

 

Введение

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

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

Ниже рассматриваются вопросы обеспечения надежности работы Microsoft Axapta как комплексной системы, состоящей из многих взаимозависимых компонентов: серверов баз данных и приложений, операционных систем и СУБД, архитектуры соединений и ЛВС. Поэтому, в дальнейшем будет активно использоваться термин система Axapta, под которым надо понимать весь комплекс технической и программной инфраструктуры для Axapta, обеспечивающей в качестве решения класса ERP сопровождение бизнес - функций предприятия.

Чтобы снизить необъятность темы до приемлемого уровня рассмотрения, в рамках этой статьи по умолчанию примем следующие допущения:

Несмотря на принятые допущения, представленный ниже подход, в целом, подходит и для других комплексных ERP решений с различными СУБД.

Качество работы любой технической системы напрямую зависит от уровня ее надежности. Но что такое надежность для ERP – системы? Давайте первоначально определимся с терминами и точно сформулируем цели, над достижением которых будем работать.

 

1. Надежность. Стратегическая цель этапа сопровождения

Надежность – способность системы с ожидаемым качеством выполнять свои функции. Надежность системы Axapta можно определить, как способность выполнять требуемые и реализованные в системе функции с ожидаемым уровнем производительности и ожидаемым результатом.

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

Надежность

Ниже приведены два конкретных примера, поясняющих смысл данных критериев.

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

Общий пример. Для успешной работы всех пользователей Axapta должен быть, во-первых, доступен (запущен) сервис приложения (AOS) и сервис баз данных. Во-вторых, все реализованные и необходимые пользователям Axapta функции должны успешно выполняться. В-третьих, время отклика системы в целом должно быть удовлетворительным с точки зрения эффективного выполнения бизнес – процессов предприятия.

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

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

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

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

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

Проект внедрения

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

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

Доступность (в нашем контексте) – возможность пользователям или внутренним процессам системы Axapta выполнять требуемые функции. Доступность очень легко определить. Говоря проще, она или есть, или ее нет. Поэтому доступность обычно измеряют в часах простоя или процентах. Например, выражение доступность 99% означает, что измеряемый сервис доступен в течение 99% времени промежутка измерения, который чаще приравнивается к одному году.

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

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

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

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

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

 

2. Стратегия построения высоконадежной системы

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

Один из первых шагов определения стратегии построения высоконадежной системы Axapta – определить для предприятия уровень необходимой надежности посредством определения конкретных показателей критериев доступности, безошибочности, производительности.

На первый взгляд может показаться, а что может быть проще? Давайте примем, например, уровень доступности системы Axapta 24 на 7 (доступность 99.99%) и снимем тем самым все вопросы. ОК, давайте примем, но когда мы перейдем к технологическим и организационным решениям, которые должны обеспечить заявленный уровень доступности, и определим архитектуру, эквивалентную поставленной задаче, сколько это будет стоить, не 10 % от оборота предприятия за год?

Здесь мы сталкиваемся с обычной дилеммой качество – ресурсы и выбор оптимального сочетания может быть непростой задачей.

Возможная область оптимальных значений для соотношения Цена/Качество

Ниже представлены конкретные рекомендации по оценке предлагаемых критериев.

 

2.1. Доступность

Первый шаг для оценки приемлемой доступности – определить время, когда в соответствии со спецификой деятельности предприятия система Axapta должна быть доступна для работы пользователей. Скорее всего, это будут не круглые сутки, а, например, период с 8:00 по 21:00 в рабочие дни и с 9:00 по 18:00 в выходные дни. Это не значит, что во время, выходящее за пределы указанных рамок, система Axapta будет недоступна, это значит только то, что работа системы гарантируется только в указанный период, а за пределами этого периода возможны отключения для проведения каких-либо служебных операций или модификаций системы. Таким образом, все мероприятия по обеспечению уровня доступности проектируются только для обеспечения работы системы в заявленное время .

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

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

Таким образом, следует разумно подойти к определению гарантированного периода доступности.

Доступность: мечта руководства

Доступность: удачная реализация

Доступность: пример неудачной реализации

В случае если одновременно с эксплуатацией системы на предприятии проводятся также и ее значительные модификации, то, возможно, потребуется реализовать более гибкий подход. Заключается он в том, что необходимо выделить критически важные периоды времени, когда система Axapta должна быть доступна и периоды времени, когда возможны отключения для проведения служебных работ. В этом случае, гарантированный период доступности на время реализации проектов модификаций снижается, например с 9:00 по 16:00.

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

Для большинства случаев, доступность системы Axapta на уровне 99.5% во время гарантированного периода будет вполне достаточна. Это соответствует допустимым отключением системы примерно на два часа в месяц в случае гарантированного периода доступности системы с 8:00 по 21:00 в рабочие дни и с 9:00 по 18:00 в выходные дни.

 

2.2. Безошибочность

Сам термин, конечно, звучит немного странно, но лучшего слова для определения этого показателя надежности для системы Axapta автор не нашел.

Совершенно очевидно, что в любой реальной крупной программной системе всегда будут присутствовать какие-либо ошибки. Но далеко не все ошибки имеют существенное значение для работы системы Axapta в целом. Здесь важно определиться с областью действия (scope) критерия безошибочности. Область действия лучше всего определить исходя из обеспечения текущих бизнес – процессов предприятия, поддерживаемых системой Axapta . Речь идет только об обеспечении работы именно текущих бизнес – процессов. Бизнес – процессы, поддержка которых системой Axapta находится на стадии реализации или тестирования, не могут быть качественно оценены до тех пор, пока полностью не реализованы, протестированы и не включены в общие процессы технической поддержки для Axapta.

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

Ошибки в уже работающей системе могут проявляться различным образом. Некоторые примеры:

Похоже, этот список можно дополнять бесконечно.

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

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

Жизненный цикл ERP-системы при отсутствии отлаженных процессов сопровождения

Стратегия построения надежной системы выбрана правильно, процессы сопровождения хорошо реализованы

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

Подводя итог, критерий безошибочности в зависимости от конкретных условий решения системы Axapta можно оценить следующим образом:

или

при этом все зарегистрированные открытые ошибки должны входить в область действия рассматриваемого критерия.

Точные рекомендации здесь привести нет возможности, так как для их определения важно учесть следующие основные факторы:

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

 

2.3. Производительность

Более подробно вопросам производительности (определение, измерение, достижение) посвящена отдельная статья автора, планируемая к публикации в журнале Байт № 2 (февраль) 2005 года. Здесь приведены только основные тезисы, касающиеся оценки критерия производительности системы Axapta в целом.

Как у любой комплексной программной системы, производительность решения Axapta не является однородной. Например, многих пользователей вполне может удовлетворять скорость подготовки базовых отчетов, но совершенно не удовлетворять скорость резервирования товаров для клиентов.

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

Для каждой категории нужно подобрать один или несколько индексов производительности. Например, для операций оперативной обработки данных это может быть скорость резервирования товаров и скорость разноски проводок по счетам Главной книги. Скорость в данном случае можно измерять в количестве строк заказа в минуту. Для категории навигации по визуальному интерфейсу можно измерять время открытия основных форм (например, Заказы) и время отклика – реакции на выбор элементов форм в секундах или долях секунд.

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

Рекомендации по производительности для различных категорий требований

Ужесточение требований производительности неминуемо ведет к росту затрат на оптимизацию системы Axapta по программным и аппаратным направлениям.

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

Состояние общего критерия производительности системы Axapta определяется соблюдением ограничений на значения показателей для всех определенных выше индексов производительности.

 

2.4. Разработка стратегии построения высоконадежной системы Axapta

Итак, теперь мы готовы приступить к разработке стратегии. Здесь можно выделить следующие последовательные шаги:

  1. Осознать и принять главную стратегическую цель этапа эксплуатации – обеспечить уровень надежности работы системы Axapta, достаточный для успешной поддержки бизнеса компании в рамках реализованной функциональности. Поверьте, во многих случаях на практике цели не определяются, а без их приятия все дальнейшие шаги бессмысленны.
  2. Определить измеримые критерии надежности системы: доступность, безошибочность, производительность. Определить их показатели и оценить ресурсы, необходимые для достижения заявленных показателей критериев надежности.
  3. Утвердить в первом приближении необходимый бюджет для достижения заявленного уровня надежности. В противном случае придется вернуться к шагу 2 и снизить требования к надежности системы.
  4. Спроектировать процессы сопровождения системы Axapta, направленные на достижение и поддержку заявленного уровня надежности. Оценить требуемые ресурсы не только для функционирования процессов и их технического сопровождения, но и для схемы управления самими процессами.
  5. Утвердить уточненный бюджет для достижения заявленного уровня надежности. Опять возможен возврат к шагу 4.
  6. Внедрить и обеспечить управление разработанными процессами сопровождения системы Axapta.
  7. Далее необходимо проводить периодический аудит и анализ текущего состояния системы Axapta, анализировать существующие тенденции, принимать упреждающие решения до наступления крупных проблем надежности. Например, необходимо заблаговременно оценить темпы роста размера рабочей базы данных, утвердить и реализовать технические решения, не дожидаясь момента нехватки физического пространства на RAID массивах. Со временем и с учетом накопленного опыта можно постараться поднять планку требований к надежности работы системы Axapta, оптимизировав процессы сопровождения. Если это получится, то это значит, что организация высоконадежного режима работы Microsoft Axapta для этапа промышленной эксплуатации реализована профессионально.

Шаги с 1-го по 3 уже должны быть понятны. Рассмотрению шагов с 4-го по 7 посвящены следующие разделы.

Продолжение следует…

Сергей Котов, serge_kotov@mail.ru