В статьях серии "Служба поддержки" (Support Authority) обсуждаются ресурсы, инструментальные средства и другие элементы технической поддержки IBM®, доступные для продуктов WebSphere®, а также методики и новые идеи, которые расширяют возможности в области технической поддержки.

Для начала…

Как всегда, начнем с новостей, представляющих интерес для широкого сообщества WebSphere:

• Готовы ли вы к конференции Impact-2011? Присоединяйтесь к нам на конференции Impact-2011, которая будет проходить с 10 по 15 апреля 2011 года в Лас-Вегасе, штат Невада, в отелях The Venetian и The Palazzo. Зарегистрируйтесь до 18 февраля, и вы получите скидку для "ранней пташки". Вот пять главных доводов в пользу участия в Impact (PDF, 115 КБ), единой конференции для руководителей производственных и ИТ-подразделений, где они могут вместе решить, как добиться повышенной гибкости бизнеса.
• В начале года Ассоциация специалистов по технической поддержке назвала IBM Support Portal в числе десяти лучших сайтов технической поддержки 2010 года. Вы еще не работали с порталом IBM Support? В него уже включены все программные продукты IBM, и страницы поддержки всех программных продуктов заменены порталом IBM Support. Подробности см. в статье Знакомство с порталом IBM Support в разделе "Служба поддержки".
• Ознакомьтесь со списком предстоящих конференций на странице IBM Conferences & Events.
• Учитесь, обменивайтесь опытом и общайтесь в блоге сообщества IBM Electronic Support портала developerWorks.
• Международное сообщество пользователей WebSphere находится по адресу: websphereusergroup.org. Настройте содержание своей персональной страницы GWC и установите связь с другими "Web-сферянами", разделяющими ваши интересы.
• В феврале планируется несколько интересных Web-трансляций в разделе WebSphere Technical Exchange. Узнайте детали на Facebook и станьте нашим фанатом!
• Вышла версия IBM Support Assistant 4.1.2. В IBM Support Assistant 4.1.2 исправлены несколько ошибок и содержится новая версия инструмента быстрого сбора данных ISA Lite. В ISA Lite появились следующие новые функции:
  • собранные в ISA Lite инвентаризационные данные можно легко просматривать в браузере;
  • ISA Lite использует новейшую технологию Ant 1.8;
  • просматривать меню стало легче, так как каждому пункту меню, который работает в режиме консоли, присвоен свой номер;
  • обработку файла ответа можно приостанавливать в различных сценариях:
    • приостановка обработки ответа на определенный период времени (например, для сбора трассировок);
    • приостановка обработки ответа в ожидании реакции консоли (например, при воссоздании проблемы, которая появляется на определенном шаге при большом количестве подключенных сценариев);
  • у ISA Lite теперь более масштабируемый формат благодаря использованию пар имя-значение для файла ответа, что позволяет:
    • добавлять комментарии в файл ответа;
    • включать в файл ответа пары имя-значение, охватывающие все подходящие вопросы;
    • легко редактировать файлы ответа вручную для настройки под различные системы;
  • при запуске информация о версии ISA Lite автоматически записывается в консоль и журнал; ту же информацию можно найти в меню Справка, а также передав параметр –version сценариям запуска;
  • ISA Lite можно запускать с параметром –help для просмотра информации о том, как пользоваться этим инструментом;
  • можно выбрать альтернативный способ передачи файлов, если выбранный способ не работает;
  • визуальный индикатор показывает, удалась ли операция сбора (когда операция завершена без ошибок, индикатор зеленый, в противном случае - красный);
  • если ISA Lite запускается с параметром -useHome, никакие файлы в каталог установки ISA Lite не записываются;
  • добавлена поддержка Windows 7 и Linux RedHat 64-бит;
  • добавлена поддержка сбора инвентаризационных данных для Solaris.

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

А теперь ― наша главная тема…

В начало

Новый год, новый подход

С момента появления колонки Служба поддержки в ней было представлено несколько важных инициатив и инструментов, разработанных сообществом IBM WebSphere Support. В новом году мы принимаем несколько иной подход. В дополнение к статьям об утилитах и ресурсах, которые способствуют улучшению поддержки и самоподдержки, мы будем публиковать статьи, основанные на нашем опыте работы с клиентами. Здесь мы начинаем с одного из самых распространенных недостатков, с которыми сталкиваемся: неподходящей среды тестирования.

В начало

Неподходящая инфраструктура

В IT-индустрии большое внимание уделяется созданию моделей и приемов проектирования, которые помогают преодолеть сложность проектов масштаба предприятия. Клиенты IBM получают выгоду, следуя таким практическим рекомендациям. Однако акцент делается на положительный опыт, что означает, что пользователи часто не вдаются в детали того, что делает ИТ-инфраструктуру неустойчивой, пока сами не попадут в неприятную ситуацию.

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

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

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

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

Большинство пользователей IBM WebSphere Application Server применяет ту или иную среду тестирования. Однако из-за фактора стоимости она часто бывает технически не идентичной их рабочей системе. Мы сталкивались со случаями, когда отсутствие отдельной опытной среды приводило к выходу продукта из строя. На протяжении последних нескольких лет при посещении клиентов мы регистрировали оплошности, подобные перечисленным выше, которые непосредственно вызвали или усугубили перебои в работе предприятия. Наш анализ показал, что наиболее частым фактором, вызывающим критические ситуации, в которых оказывались пользователи WebSphere Application Server, были системы тестирования, технически не идентичные рабочим системам, либо вовсе отсутствие систем тестирования. Это причина более чем 35% всех ситуаций, которые мы наблюдали ― и эта тенденция растет.

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

В начало

Опытная среда отличается от рабочей

Эта ситуация может охватывает следующие варианты:

• опытная среда слишком мала или перегружена и недоступна, когда это необходимо;
• опытное оборудование, сеть или программное обеспечение по своему уровню отличаются от рабочей среды;
• логический раздел z/OS® на том же компьютере или в той же сети не изолирован от производственной системы;
• параметры конфигурации опытной системы отличаются от параметров рабочей.

Чтобы лучше понять, почему это происходит, рассмотрим пример.

Крупный банк обнаружил, что во время налогового сезона в работе его среды WebSphere Application Server для Z/OS часто случаются перебои, которые подрывают бизнес онлайновых налоговых платежей его клиентов, что, в свою очередь, портит отношения этого банка с клиентами. Группа IBM WebSphere SWAT провела обследование и обнаружила много факторов, которые способствовали этой ситуации, прежде всего, ошибок конфигурации.

В частности, одна ошибка заключалась в том, что банк создал два сервера приложений на базе одной установки WebSphere Application Server: один для тестирования, а другой в качестве рабочего сервера. Так как серверы приложений работали на одной и той же базовой установке WebSphere Application Server, у них были общие журналы, их порты были настроены на избежание конфликтов, и, самое главное, так как они работали на одной и той же базе двоичного кода, любые обновления Software Development Kit (SDK) могли нарушить работу обоих серверов приложений. Если частое обновление системы тестирования необходимо, то регулярное нарушение работы производственной системы недопустимо.

Обнаружив эту проблему, команда SWAT порекомендовала банку разделить опытный сервер приложений и рабочую систему, разместив их в разных логических разделах (LPAR), чтобы они не могли влиять друг на друга. Любой последующий анализ проблем, необходимый после завершения разделения, будет значительно облегчен.

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

В начало

Возможное решение и профилактические меры

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

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

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

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

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

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

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

В начало

Заключение

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

Ресурсы

Научиться

• Оригинал статьи
  
  
• Типичные ошибки ― одиннадцать рисков для стабильности и надежности системы
  
  
• Служба поддержки. Если вам нужна помощь по продуктам WebSphere, существует множество способов получить ее.
  
  
• Информационные центры программных продуктов IBM
  
  
• Web-сайт IBM Software Support
  
  
• IBM Education Assistant
  
  
• IBM Redbooks
  
  
• WebSphere Software Accelerated Value Program
  
  

Получить продукты и технологии

• IBM Software Support Toolbar
  
  
• IBM Support Assistant
  
  

Обсудить

• Форумы и группы новостей
  
  
• Форумы по технологии Java
  
  
• Техническая поддержка сообщества WebSphere на портале Facebook
  
  
• Международное сообщество WebSphere на портале WebSphere.org
  
  
• Следите за поддержкой IBM в Твиттере!
  • WebSphere Electronic Support
  • WebSphere MQ
  • WebSphere Business Process Management
  • WebSphere Business Modeler
  • WebSphere Adapters
  • WebSphere DataPower Appliances
  • WebSphere Commerce
  • IBM Support Assistant Tools
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Для начала…
• Новый год, новый подход
• Неподходящая инфраструктура
• Опытная среда отличается от рабочей
• Возможное решение и профилактические меры
• Заключение
• Ресурсы
• Об авторе
• Комментарии