Обслуживание приложений клиент-сервер непрерывного действия может стать постоянным кошмаром для работников в области информационных технологий
Старший эксперт-программист одной из крупных страховых компаний Восточного побережья недавно потратил несколько недель на подготовку к своему первому отпуску в Европе. Вместо того чтобы выбирать среди добрых старых гостиниц типа "постель-и-завтрак" в сельской местности английского графства Оксфордшир, этот эксперт отчаянно старался обеспечить себе круглосуточную связь на случай, если что-то произойдет в его компании с одним из приложений клиент-сервер непрерывного действия.
Обслуживание приложений клиент-сервер непрерывного действия
может стать постоянным кошмаром для работников
в области информационных технологий
Используемая в этой страховой компании система, на которую ушли четыре года работы и многие миллионы долларов, стала произведением искусства. Трехуровневая система включает в себя ориентированное на сообщение межплатформное ПО (midlleware) для обмена между базами данных DB2, установленными на большую машину, DB2/2 на ПК, работающими под OS/2, и собственное межплатформное ПО для обмена между ними.
Такая впечатляющая разработка требует довольно обременительных условий поддержки. Сотрудники не имеют достаточной полготовки, чтобы заменять друг друга в случае необходимости, так что все десять членов группы поддержки находятся на связи 24 часа в сутки, 7 дней в неделю, 365 дней в году.
"Поскольку сотрудники не могут заменять друг друга, а мы пока не достигли определенного уровня компетенции, совершенно необходимо, чтобы каждый из них оставался в пределах досягаемости в любое время. Никому не нужны люди, которые не понимают сами, что они делают, возясь с вашей базой данных", - сказал этот эксперт, пожелавший остаться анонимным.
К счастью для него, первый разработчик системы во время его отпуска по-прежнему работал в этой компании.
ПРАВДА, О КОТОРОЙ МОЛЧАТ
Дилемма, вставшая перед ним, позволяет нам увидеть горькую истину, открывающуюся при работе с системами клиент-сервер: разработка приложений - это самая легкая часть. Необходимость подобрать, обучить, направить на соответствующие участки группу поддержки для большой сложной системы, так же как и обеспечить ей соответствующее обслуживание - вот оно, спящее лихо работы с системой клиент-сервер.
Большинство нынешних систем клиент-сервер еще не доросло даже до того уровня, когда проблемы поддержки после запуска становятся очевидными.
Недавний отчет фирмы Gartner Group (Стэмфорд, шт.Коннектикут), занимающейся исследованиями рынка, показал, что стоимость обеспечения поддержки приложения клиент-сервер в крупной компании за пять лет достигает 15% общей стоимости системы на клиента, или суммы $7260 на компьютер. Другие значительные расходы на клиента включают затраты на разработку приложений и аппаратно-программное обеспечение.
По словам Веса Тейлора, менеджера по информационным и системным проектам отделения Motor Vehicles (Салем, шт.Орегон), спящее лихо собирается проснуться. С апреля фирма приступила к производству системы клиент-сервер (стоимость - 50 млн. долл., обслуживает 1000 пользователей) для отслеживания лицензий и регистраций. Тейлор работал над проблемами поддержки, включая необходимость общей подготовки для сотрудников, и пытался заинтересовать работников информационных технологий заняться обслуживанием. Его труды скоро выйдут в свет. Первый шаг Тейлора в решении этой дилеммы - организация обязательных для всех сотрудников, включая разработчиков и сборщиков, курсов, которые будут представлять собой шестимесячную стажировку в команде обслуживания, состоящей из двух человек. Такая пара уже после трех месяцев подготовки может брать на себя большую часть ответственности. "Мы не собираемся заставлять каждого знать о системе все", - говорил Тейлор, подчеркивая, что компания планировала заняться такой подготовкой еще в 1991 году, когда было утверждено это приложение.
| Чтобы облегчить поддержку
Создание оперативной инструкции, описывающей процедуры, позволит решить 80% обычно возникающих проблем. Вам следует совершить следующие шаги. - Опросите каждого члена команда поддержки, с тем чтобы определить три или четыре главные проблемы, беспокоящие их сектор. Не пытайтесь задокументировать каждую крупицу их знаний. Чем проще, тем лучше. - Если вы действительно тонете, наймите технического писателя, чтобы он разрабатывал для вас отчеты о проблемах и опрашивал сотрудников для создания черновика этой инструкции. После этого вы можете отдать его сотрудникам для комментариев. - Наметьте основные процедуры в зависимости от обнаруженных признаков неполадок в системе. Убедитесь, что вы включили в инструкцию порядок действий: например, куда обратиться, если не удается все быстро исправить. - Обучите сотрудников пользоваться этой инструкцией. Не рассчитывайте на то, что они сами сразу начнут обращаться к ней, если до этого они привыкли звонить эксперту домой |
Подобный подход заслужил восторженную оценку одного из вербовщиков, занятых распределением специалистов по поддержке. Он рассматривает его как решение проблемы для сотрудников, которые не хотят оставаться узкими специалистами.
"Наши кандидаты хотят иметь разностороннюю подготовку и уметь работать на разных платформах. Им необходим тренинг в смежных областях", - подтвердил Рон Мэй, президент фирмы Specific Recruiting (Чикаго).
Одной из проблем, которые беспокоят группу Тейлора после принятия решения по тренингу в смежных областях, является то, что при разработке проекта им приходится сотрудничать с тремя различными консалтинговыми фирмами. "Теперь нам приходится разрабатывать стратегию по превращению знания в работу", - добавил он.
ПРАВИЛО 80-20
Марк Тебб, президент корпорации Lante (Чикаго), занимающейся интеграцией систем, считает, что тренинг в смежных областях становится более жизнеспособным, если компания учитывает, что 80% проблем поддержки относятся к одним и тем же областям.
После того как процедуры определены и политика эскалации занимает свое место, профессионалы по поддержке первого уровня могут пройти тренинг в смежных областях, чтобы научиться разбираться во всем блоке повседневных проблем, говорит Тебб (см. схему).
Уравнять знания с помощью тренинга в смежных областях в самом начале процесса тоже принципиально важно.
"Специалисты, работающие в области информационных технологий, не смогут овладеть системой, если не проведен тренинг в смежных областях, - говорит Крэйг Лэшмет, глава консультации Grant Thornton LLP (Чикаго). - Это то, чему любой, кто осуществляет этот проект, должен придавать первостепенное значение".
Для тех, кто не планирует поддержку в начале осуществления проекта, легких ответов не существует. Все это гложет того эксперта-программиста страховой компании, о котором говорилось вначале, хотя он еще и надеется найти панацею.
До тех пор пока существует эта проблема, перед ним будет по-прежнему стоять малоприятная задача: как в обозримом будущем ухитриться круглосуточно держать всех работников поддержки на связи. Любому на его месте потребовался бы длительный отдых в Европе.
ЛОРЕН ГИББОНС ПОЛ
