Однако при всей очевидности у большинства приложений пока отсутствует такая «ориентация на эксплуатацию» и не предусмотрена управляемость. Учитывая перспективу реализации сквозного управления в рамках инициативы Dynamic Systems Initiative (DSI), ситуация должна измениться. Новый член семейства System Center — Service Desk — поможет сделать очередной шаг на пути формирования единого процесса, увязывая потребности эксплуатации с разработкой при использовании преимуществ Visual Studio 2005 Team System (VSTS). За более подробной информацией о Service Desk и роли VSTS в программе DSI я обратилась к специалисту по планированию в группе VSTS Сэму Гукенхаймеру.

Острова в океане ИТ

Какую проблему ИТ призвана решить система Service Desk?

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

Островкам деятельности в сфере ИТ соответствуют обязанности архитекторов, разработчиков, тестеров приложений и менеджеров проектов, а также обязанности оперативного персонала. В рамках этой схемы инструменты VSTS и Visual Studio 2005 Team Foundation Server относятся к сфере разработки приложений, не так ли?

Мы выпустили VSTS в 2005 г., а в 2006 г. версия Visual Studio Team Edition for Database Professionals (VSDB Pro) стала первым крупным обновлением этого продукта. Так мы работаем в пространстве управления жизненным циклом приложений Application Lifecycle Management (ALM).

VSDB Pro относится к административному «острову», поскольку этот продукт предназначен для администраторов баз данных. Почему свою деятельность по соединению «островов» вы начали именно с VSDB Pro?

Выпустив Database Professional Edition для Team System, мы решили огромную проблему. Прежде процесс разработки приложений был областью, где каждый, кто работал на языках .NET или хотя бы более старых языках программирования третьего поколения 3GL, располагал первоклассными инструментами и средствами управления изменениями, что позволяло выполнять значительный объем тестирования. Специалист по базам данных был второстепенной фигурой и обычно не мог работать автономно, будучи уверенным, что имеет дело с образом, соответствующим производственной системе. Все администрирование баз данных осуществлялось на производственной системе. Специалист по базам данных не мог работать автономно и спокойно применять результаты своей работы к производственной системе, не убедившись, что изменения, внесенные на этапе разработки приложения, последовательно передаются и соответствуют изменениям, осуществляемым в базе данных. При этом специалист из числа оперативного персонала, со своей стороны, получая весь этот материал от обоих (разработчиков и DBA), мог сказать: «Кому я могу доверять? Давайте остановимся и займемся последовательным внесением изменений на протяжении следующих шести недель».

Как же VSDB Pro решает эту проблему?

Цель VSDB Pro — сделать специалистов по базам данных полноправными участниками цикла управления изменениями. Это позволяет устранить огромное число несоответствий из активных производственных процессов. Теперь можно применять к ресурсам базы данных, т. е. схемам, хранимым процедурам и т. д., тот же процесс управления изменениями, что и к коду, то же представление наборов изменений и тот же подход к измерению прогресса и функций. Можно использовать один и тот же принцип нумерации сборок, применимый к обеим сторонам. Работая с базой данных, при разработке можно получать непосредственное представление о производственных ресурсах для схемы и хранимых процедур, обо всем, что есть, и, следовательно, непосредственно создавать сценарии для изменений, с уверенностью, что производственная система обновляется в соответствии с конкретным набором, определяемым сборкой. Мы добиваемся повышения эффективности и намечаем траекторию доработки. Среди отслеживаемых нами показателей один из основных признаков дисфункции — многочисленные повторы, т. е. сколько раз заново обрабатывалось то, что было переведено из активной сферы в область принятия решений. И нам удалось устранить один из источников повторов. Это первый большой шаг и показатель действенности нашей стратегии.

Итак, VSDB Pro — первый мостик между разработкой и производством. Как вы налаживаете связь с другими ИТ-специалистам из сферы эксплуатации и как сюда вписывается DSI?

Мы начали с Team System — «центра гравитации» в пространстве управления жизненным циклом приложений ALM, что в большинстве организаций попадает в круг задач директора по разработке приложений. Но, с точки зрения CIO, вначале мы мало сделали в отношении проблемы сквозной управляемости, поскольку теперь разработка приложений может оказаться континентом, а не грядой островов. «Океаны» разделяют также целые «континенты» — производство и PMO (организация управления проектами). С помощью DSI мы перебросим через них мост. В Team System мы сделали лишь небольшие шаги в этом направлении. Первый из них — это интеграция Microsoft Project для соединения с PMO. Другой шаг касается нашего проекта Team Architect: мы ввели характеристику Designed for Operations (ориентация на эксплуатацию). Идея состоит в том, что при проектировании, т. е. до написания какого-либо кода, вы подтверждаете, что приложение будет соответствовать конфигурации информационного центра. В Team System мы реализовали свою идею при помощи логической модели информационного центра — Logical Datacenter Model, и это была первая попытка соединения континентов. Теперь DSI определяет общую позицию, принятую нами в Team System и System Center и нашими коллегами в Project в отношении CIO.

System Center Service Desk

Как дальше будет устанавливаться связь между разработкой и производством и как сюда вписывается System Center, в частности Service Desk?

Следующее, что нам нужно сделать, это приступить к увязке процессов в сфере разработки приложений с процессами производственной сферы. Реализация проекта Service Desk в System Center — значительный шаг в этом направлении. Обычно мы имеем полностью изолированные механизмы отслеживания, не связанные друг с другом и взаимодействующие в лучшем случае в режиме копирования и вставки. Team System позволяет получать представление о моделях процессов, несущих описания рабочих потоков и их элементов, описания ролей, отчеты и шаблоны, и все, что у нас есть. Эти механизмы позволяют применить к проекту определенный тип процесса; они включают в себя описания рабочих потоков.

Эквивалент в System Center — пакеты управления, позволяющие располагать такими описаниями содержимого. Мы внимательно рассмотрели, что должно происходить в контексте исходных рабочих потоков, и будем приступать к поддержке автоматизации. Например, в производственной сфере обнаружена серия ошибок, и вы считаете, что «здесь нужно что-то доработать». Вы собираете эти данные и передаете информацию о наличии дефекта разработчикам для анализа. Когда в отделе разработки кто-то не согласен с вами, такие передачи движутся туда и обратно. Затем, когда вопрос решен, вы узнаете от разработчиков, какая будет компоновка, с какими сценариями для изменения базы данных, и какие двоичные коды подлежат переносу в производственную среду.

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

Ранее вы говорили о системе измеримых показателей VSTS. Будет ли System Center также привязан к этим показателям?

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

Metrics Warehouse становится реальностью и для System Center. Мы совместно работаем над схемой, позволяющей все увязать в рамках общих бизнес-инициатив. Например, в сфере эксплуатации вы используете корпоративную систему управления взаимодействием с клиентами CRM, связанную с разрабатываемыми проектами по самообслуживанию клиентов, интеграции поставщиков, применению агентов по сбыту и т.д. в рамках одной бизнес-инициативы. Вы можете начать отслеживать все процессы как единую бизнес-инициативу и для CIO, и для заинтересованных сторон.

Идея такова, что с обеих сторон используются возможности соответствующих хранилищ Metrics Warehouses, которые сводятся воедино в рамках общей схемы. Это возможно благодаря всеобщему использованию SQL Server, что в большинстве случаев позволяет задействовать находящийся в распоряжении клиента портал или внутренний инструментарий. Сотрудник торгующей организации может рассматривать CRM-систему как единое целое и отслеживать качественные показатели из отдела разработки и основные показатели эксплуатационной готовности и производительности (KPI) из производственного отдела.

Как ИТ и разработчики будут использовать эти возможности для взаимодействия?

Все работают над одними и теми же проблемами и ищут одни и те же возможности. Сегодня в Team System мы используем отчет Quality Indicators, представляющий на одном графике данные о результатах прохождения теста (пройден, не пройден, результат не окончательный) на число активных дефектов, «перетряхивание» кода (новые и добавленные строки) и эффективность кода. При этом неожиданно выясняется, что тесты пройдены, дефектов мало, но эффективность кода низка. Что это означает? Это означает, что тесты устарели. Вы тестируете лишь старый код, который успешно проходит тесты, что неудивительно, а новый материал игнорируется. Поэтому вы не знаете истинного положения вещей, и необходимо пересмотреть порядок тестирования. Такой вид взаимосвязи вы не привыкли учитывать объективно.

То же самое можно сделать в отношении эксплуатации. Для той же CRM-системы можно наблюдать практически безукоризненные данные в качественных показателях по отделу разработки, но большие проблемы в информационном центре. Такая ситуация обнаруживает неполадки в управлении изменениями, и при совместном наблюдении одна сторона видит, что на другой стороне все происходит не так, как задумано. Тогда характер дискуссии меняется. Вместо взаимных претензий разработчиков приложений и специалистов эксплуатации и обвинений в некомпетентности обе стороны приходят к выводу: «Здесь проблема несоответствия версий, в которой нам следует разобраться».

Что важно для ИТ в части интеграции VSTS и Service Desk?

Большинство ИТ-специалистов четко осознают проблемы. Например, они знают, насколько важна степень исправности программ, но не располагают хорошим методом мониторинга их состояния. Они знают, что те показатели, которые они могут отслеживать, плохо отражают то, что происходит в программах. При попытке передать что-либо на доработку начинается неконструктивный диалог, когда разработчики говорят: «Вы никогда не даете нам нужные данные», на что ИТ-специалисты отвечают: «Мы даем вам все, что у нас есть!» Соединяя концы, вы совершенно неожиданно получаете возможность собирать данные об ошибках, свидетельствующих о наличии дефекта, и анализировать соответствующие данные для проведения диагностики без необходимости запрашивать дополнительный материал, поскольку это можно автоматизировать. Именно так мы предлагаем использовать преимущество нашей модели информационного центра, дающей представление о том, насколько приложение подходит для данного информационного центра. Именно так можно применить то, что мы называем Software Factory, т. е. стандартизированный шаблон, для оснащения приложения встроенными средствами управляемости, позволяющими путем анализа данных получить представление о его состоянии.

Начальный этап

Service Desk пока еще находится на самом раннем этапе развития, поэтому как могут ИТ-специалисты начать движение в обозначенном вами направлении?

Для тех, кто уже познакомился с VSTS, существует стартовый пакет, который можно загрузить по ссылке http://msdn2.microsoft.com/en-us/teamsystem/aa718768.aspx. Пакет Visual Studio 2005 Design for Operations Integration Kit предусматривает интеграцию и автоматизацию связи и управления ошибками в приложениях и выявленными ограничениями производительности. При использовании этой программы ошибки и ограничения приложений автоматически генерируют соответствующие уведомления в VSTS, давая разработчикам и специалистам эксплуатации четкое представление о работе и степени исправности .NET-приложений. Рабочие потоки эксплуатации увязываются с рабочими потоками производства.

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

Карен Форстер (karen@windowsitpro.com) — директор редакционной группы Windows IT Pro