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

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

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

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

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

 

Начало…

3. Организация процессов сопровождения Microsoft Axapta

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

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

Основой для сформулированного ниже подхода для Axapta являются рекомендации ITIL (Information Technology Infrastructure Library). Для читателей, не знакомых с ITIL, все понятия, которые используются в данной статье, будут определены, поэтому знание ITIL для понимания дальнейшего материала не требуется. Тем не менее, специалистам в области сопровождения программных систем знание основ ITIL или адаптации этого подхода в Microsoft - MOF (Microsoft Operations Framework) просто необходимо. Здесь можно рекомендовать прекрасный перевод на русский язык книги itSMF, который можно приобрести здесь: http://www.bolero ru/itsm. Материалы по MOF на английском языке доступны на сайте Microsoft по ссылке www.microsoft.com/mof.

 

3.1. Необходимость качественной организации процессов сопровождения

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

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

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

 

3.2. Процессы сопровождения с точки зрения обеспечения надежности

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

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

Управление инцидентами (Incident Management) и Service Desk. Service Desk – это служба, первоначально обрабатывающая все обращения в ИТ – подразделение и являющаяся единой точкой контактов для всех пользователей системы. В функции Service Desk входит оказание горячей поддержки, это первая линия оказания услуг. Инцидент – это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги. К инцидентам относятся зарегистрированные Service Desk сообщения о любых ошибках, а также запросы на обслуживание (предоставление какого либо сервиса).

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

Управление проблемами (Problem Management). Процесс, тесно взаимодействующий с управлением инцидентами. Основная цель – расследование, определение и последующее устранениепричин инцидентов. Очень важный процесс для обеспечения надежности системы Axapta. На практике, решая возникшие инциденты, очень часто не обращают внимания на наличие более важных проблем, стоящих за инцидентами. В этом случае, с течением времени неминуемо следует рост количества инцидентов, вызванных одними и теми же не решенными проблемами. Так как на обработку и решение инцидентов требуется ресурсы, то служба сопровождения на предприятии в некоторый момент может захлебнуться их количеством.

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

Управление изменениями и релизами (Change Management & Release Management). В оригинале (ITIL) это два раздельных процесса, но в данном случае, для системы Axapta, автор решил их объединить. Это процесс планирования и осуществления изменений для функционирующей системы, включающий также операции тестирования и контроля успешности изменений. Качество реализации данного процесса имеет прямое влияние на показатели всех категорий надежности системы Axapta. Достаточно часто при модификациях страдает доступность системы, появляются ошибки в уже реализованных функциях, и может значительно понизиться производительность.

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

Управление уровнем сервиса (Service Level Management). В нашем случае это процесс мониторинга текущего состояния надежности системы Axapta , сравнение надежности с заявленным уровнем посредством сравнения плановых и фактических показателей критериев надежности. Также процесс управления уровнем сервиса включает в себя анализ тенденций и пересмотрсоглашений о гарантированном уровне сервиса - SLA (Service Level Agreement) в случае необходимости. В нашем случае важно то, что показатели всех критериев надежности должны быть формально зафиксированы в SLA.

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

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

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

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

 

Функция Service Desk – единая точка контактов для всех запросов в подразделение IT. Все инциденты, относящиеся к обеспечению надежности системы в целом, получают самый высокий приоритет и немедленно решаются в рамках процесса управления инцидентами. При необходимости осуществляетсяэскалация, т.е. в терминах ITIL - привлечение дополнительных ресурсов для срочного восстановления необходимого уровня сервиса.

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

После возникновения ряда жалоб пользователей на производительность и устойчивость работы в Axapta, зафиксированные процессом управления инцидентами, управление проблемами определило источник проблемы – аппаратный сбой, связанный с контроллером RAID - массивов одного из серверов AOS. Временно, сбойный сервер был заменен резервным сервером. Быстро проведя модификацию и проверив доступность сервера для пользователей, процесс управления изменениями поставил об этом в известность Service Desk, который, в свою очередь, смог быстро помочь тем нескольким пользователям, которые, не зная о замене физического сервера приложения, пользуясь своими копиями конфигурационных файлов Axapta, неожиданно не смогли подключиться к AOS.

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

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

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

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

 

3.3. Роли команды сопровождения

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

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

Выделим основные значащие для нас роли в процессах сопровождения:

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

Кого-то забыли? В зависимости от сложности процессов сопровождения могут быть дополнительно введены роли руководителей процессов управления инцидентами, проблемами, изменениями и релизами, уровня сервиса и оптимизации. Логично роль управления уровнем сервиса выполнять функциональному руководителю подразделения IT. Главные цели для ролей руководителей процессов – обеспечение качества функционирования процесса и решение вопросов (проблем) взаимодействия с другими процессами.

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

Возможность совмещения зависит от квалификации и способностей специалистов. Например, не всегда оператор Service Desk может даже временно заместить аналитика - консультанта.

При совмещении двух или более ролей одним человеком необходимо следовать двум основным правилам:

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

 

3.4. Характеристики процессов сопровождения

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

В таблицах ниже:

Цель – кратко и ясно определенная миссия процесса, то к чему нужно постоянно стремиться

Виды деятельности – список основных функций (процедур) процесса.

Базовые роли – те роли, которые фактически определяют функционирование процесса

Документы – возможные документы для определения и поддержания внутреннего стандарта качества управления процессами сопровождения. Документы, названные "живыми" активно изменяются в процессе работы

Показатели эффективности – примеры возможных показателей эффективности KPI (Key Performance Indicator) для оценки качества функционирования процессов сопровождения и анализа тенденций

 

Управление уровнем сервиса

Цель	Определение необходимого уровня надежности системы Axapta и динамическая оценка его достижимости
Виды деятельности	Определение и утверждение обоснованного уровня надежности через критерии доступности, безошибочности, производительности. Формирование и сопровождение соглашений об уровне сервиса SLA Формирование и защита бюджета на сопровождение системы Axapta Мониторинг и анализ выполнения заявленного уровня надежности
Базовые роли	Руководитель подразделения IT Системный аналитик
Документы	Соглашение об уровне сервиса (SLA) Регламент мониторинга и аудита состояния надежности системы Axapta "Живой" лог мониторинга надежности
Показатели эффективности	Соответствие уровня надежности, определенного в SLA потребностям бизнеса Выполнение всех пунктов соглашений, оговоренных в SLA

 

Администрирование

Цель	Обеспечение доступности системы Axapta для пользователей
Виды деятельности	Управление серверами баз данных и приложений системы Axapta Резервное копирование / восстановление данных Экспорт / импорт данных Администрирование прав доступа Настройки конфигурации системы Axapta Мониторинг ключевых параметров функционирования системы
Базовые роли	Администратор БД и системы Axapta
Документы	Регламент периодических операций системы Axapta Регламент управления правами доступа Список ключевых параметров функционирования системы и их допустимые значения "Живая" техническая схема действующей архитектуры системы Axapta
Показатели эффективности	Выполнение определенного в SLA уровня доступности система Axapta Выполнение регламента периодических операций по администрированию системы Axapta согласно внутреннему стандарту

 

Управление инцидентами с функцией Service Desk

Цель	Скорейшее восстановление требуемого уровня надежности системы Axapta
Виды деятельности	Прием и регистрация входящих инцидентов Классификация инцидентов, определение приоритета, определение ответственных за решение Решение инцидентов (расследование, диагностика, восстановление уровня услуг, закрытие) Эскалация и мониторинг хода решения инцидентов Взаимодействие (оказание помощи и информирование) с конечными пользователями системы Axapta
Базовые роли	Оператор Service Desk Аналитик – консультант Другие роли в зависимости от категории и приоритета инцидента
Документы	Регламент управления инцидентами Правила определения и назначения приоритета "Живой" FAQ и полезные советы службы Service Desk
Показатели эффективности	Количество открытых инцидентов на момент времени Среднее время разрешения инцидентов (по приоритетам, по категориям)
Комментарии	Для качественной реализации этого процесса необходимо внедрить базу данных по управлению инцидентами. Есть уже готовые решения, но также несложно подобную систему реализовать на предприятии самостоятельно. База данных по инцидентам также активно используется другими связанными процессами сопровождения.

 

Управление проблемами

Цель	Расследование, определение и устранение причин инцидентов
Виды деятельности	Анализ инцидентов, определение проблем, исследование корневых причин проблем, стоящих за инцидентами Поиск решения известных ошибок Планирование и анализ результатов внедрения решений по устранению ошибок Проактивное исследование и предупреждение возможных будущих проблем и связанных с ними инцидентов
Базовые роли	Аналитик – консультант Системный аналитик Другие роли в зависимости от категории проблемы
Документы	"Живой" план работ по решению открытых проблем и проактивному анализу возможных проблем
Показатели эффективности	Выполнение определенного в SLA допустимого уровня количества открытых (в смысле не решенных) ошибок на момент времени

 

Управление изменениями и релизами

Цель	Минимизация возможного отрицательного воздействия модификаций системы Axapta на надежность эксплуатации
Виды деятельности	Регистрация запросов на изменения RFC (Request For Change) Классификация, оценка необходимости и срочности изменений Оценка воздействия и требуемых ресурсов Планирование и проведение изменений (модификаций) Тестирование результатов проведенных изменений и стабильности системы
Базовые роли	Администратор БД и системы Axapta Программист Аналитик по тестированию
Документы	Регламент выпуска релизов "Живой" список актуального эталонного программного обеспечения DSL (Definitive Software Library)
Показатели эффективности	Влияние проводимых изменений на снижение показателей критериев надежности Количество возвратов к исходному состоянию, вызванных неудачными изменениями

 

Оптимизация

Цель	Повышение уровня надежности системы Axapta
Виды деятельности	Анализ технической и программной инфраструктуры системы Axapta Анализ эффективности функционирования процессов сопровождения Поиск решений для повышения качества функционирования инфраструктуры и процессов сопровождения Оценка затрат, проектирование и планирование решений по оптимизации и развитию системы Axapta Анализ эффективности реализации решений по оптимизации
Базовые роли	Руководитель подразделения IT Системный аналитик Аналитик по тестированию
Документы	План по мощностям (Capacity Plan) План на случай чрезвычайных обстоятельств (Contingency Plan) "Живой" план работ по оптимизации Анализ результатов внедрения PIR (Post Implementation Review)
Показатели эффективности	Динамика изменения критериев надежности (успехом можно считать не только рост показателей, но зачастую и просто поддержку необходимых критериев назаданном уровне с течением времени). Выполнение определенного в SLA уровня производительности система Axapta

 

3.5. Внедрение процессов сопровождения

Разумеется, уровень внедрения рассматриваемых процессов сопровождения, а также последовательность внедрения, сроки и ресурсы зависят от конкретных условий, в том числе корпоративной культуры предприятия. Тем не менее, некоторые рекомендации можно привести.

Первоначально необходимо определиться с теми функциями процессов сопровождения, которые будут выполняться полностью или частично на условиях аутсорсинга (outsourcing).

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

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

• Недостаток знаний и опыта проектного и процессного управления
• Недостаток ресурсов, как для целей внедрения, так и для управления процессами
• Низкая корпоративная культура предприятия

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

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

Возможный вариант последовательности внедрения следующий:

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

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

Далее, логично реализовать службу Service Desk и управление инцидентами как фронт – офис подразделения IT.

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

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

Окончание следует…

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

Создано 23.01.05