Главная » Архитектура ПО » Уделяйте пристальное внимание поддержке и сопровождению

0

Мнчедизи Каспер

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

В ходе проектирования приложения перед внутренним взором архитекторов находятся главным образом разработчики, вооруженные интегрированными средами и отладчиками. Если что-то идет не так, искусные программисты переключаются в режим отладки и находят ошибку. Такая картина вполне естественна, поскольку большинство архитекторов основную часть своей жизни проводят в роли разработчиков, а не администраторов системы. К сожалению, разработчик и специалист службы поддержки обладают разными навыками – аналогично тому, как среда разработки/тестирования и рабочая среда (production environment) служат разным целям.

Вот примеры проблем, с которыми сталкивается администратор системы:

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

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

•      В рабочей среде нет отладчика.

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

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

Некоторые из симптомов недостаточного планирования поддержки выглядят так:

•      Большинство проблем требует привлечения разработчика.

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

•      Служба поддержки ненавидит новое приложение.

•      Команды архитекторов и разработчиков проводят много времени в рабочей среде.

•      Приложение часто перезапускается для решения возникших проблем.

•      Администраторам вечно не хватает времени для нормальной настройки системы, потому что они постоянно занимаются «тушением пожаров».

Чтобы ваше приложение успешно работало после того, как выйдет из рук разработчиков, вы должны:

•      Понять, что разработка и поддержка требуют разных навыков.

•      Как можно раньше вовлечь в проект руководителя службы технической поддержки.

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

•      Привлечь руководителя службы технической поддержки к планированию поддержки приложения.

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

Мнчедизи Каспер (Mncedisi Kasper) – директор по технологии и стратегии в Open Xcellence ICT Solutions, южноафриканской компании, специализирующейся на интеграции корпоративных приложений и консультациях в области SAP (АВАР/XI).

Источник: Форд Н., Найгард М., де Ора Б., 97 этюдов для архитекторов программных систем. – Пер. с англ. – СПб.: Сим- вол-Плюс, 2010. – 224 с., ил.

По теме:

  • Комментарии