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

Для того чтобы предоставлять корпоративное решение хорошего качества недостаточно просто сделать решение, реализующее бизнес-процесс. Заказчику нужно нечто большее, чем просто решение само по себе. Со своей стороны, заказчик понимает, что ему будет нужно эксплуатировать, поддерживать, мониторить это решение. Возможно, даже интегрировать его с уже существующими, разворачивать новые инсталляции, восстанавливать упавшие, производить анализ падений, плохой производительности и тому подобные задачи поддержки и эксплуатации. Еще одним свойством решений, состоящих из большого количества компонент является способность предоставлять информацию о самой себе, быть само-описываемой. Если решение состоит из большого количества связанных друг с другом компонент, которые исполняются на большом количестве серверов, будет очень хорошо если такое решение предоставляет интерфейс, который даст возможность автоматически узнавать где и какая компонента запущена. Даже если компонента была перенесена с сервера на сервер, информация о таких изменениях должна предоставляться автоматически. В случае наличия готовой системы на основе ITIL в компании, такая информация должна сама попадать в систему без вмешательства извне. Это уменьшит трудозатраты на интеграцию, мониторинг и поддержку решения, упростит процессы, позволит избавиться от хаоса и ручного обновления данных каталога приложений

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

Стратегия управляемости

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

По имени сервера вернуть все компоненты решения, которые исполняются на этом сервере и их состояние. Это даст возможность автоматически обновлять базу каталога приложений, что облегчит поддержку. По сути это может дать возможность автоматически получать граф взаимодействий между компонентами сложной системы
Производить базовые операции над компонентами, такие как stop/start/restart, получать состояние компонент, производить их конфигурирование

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

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

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

Таким образом рекомендации для разработчиков и архитекторов в части управляемости продукта таковы:

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

Стратегия мониторинга

Как известно программное решение можно рассматривать как сервис, предоставляемый компании. Таким образом для того, чтобы качество этого сервиса было высоким, необходимо, чтобы можно было легко мониторить решение и реагировать на возникающие инциденты. Более того, в лучшем случае, решение должно легко интегрироваться с существующей инфраструктурой мониторинга предприятия. Как этого достичь? Есть три основных пути от самого простого к сложному: журналы событий (event logs), счетчики производительности (performance counters), механизм event tracing for windows.

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

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

Случается, что и этого недостаточно. Иногда бывает необходимо копнуть глубже и увидеть, что происходит на боевой системе, коррелировать события, происходящие в системе с разных источников, под разными углами зрения. Для таких целей существуют механизмы Event tracing for Windows (ETW). В случае если решение предоставляет данные о своей производительности и состоянии через инфраструктуру ETW, становится возможным проведение глубокого анализа производительности.

Итак, как итог, при проектировании приложения, для обеспечения простоты его мониторинга и поддержки, необходимо:

Рассмотреть и выбрать способ регистрации событий о состоянии в системе.
Предоставлять метрики производительности по ключевым параметрам при помощи счетчиков.
Опционально предоставлять информацию через ETW провайдеры

Стратегия развертывания

Краеугольным камнем развертывания на платформе Windows являются пакеты. Они дают возможность не только легко развернуть решение, но и откатить неудачную инсталляцию, или исправить существующую при необходимости. Кроме этого MSI можно разворачивать с использованием централизованных средств таких как SCCM, или даже средствами самого Active Directory. Пакеты могут быть построены при помощи Wix Toolset, который предоставляет возможность собирать их, как часть процедуры сборки решения.

На данный момент есть несколько новейших технологий, которые предназначены для развертывания: Desired State Configuration (DSC) и OneGet.

Технология DSC это способ построения сложных сценариев развертывания декларативным языком. Идея в том, чтобы описать желаемую конфигурацию серверов простым декларативным языком, точнее подмножеством языка PowerShell и затем дать указание серверу применить эту конфигурацию на себя. Основной сценарий использования, это когда сервера обращаются к центральной точке и забирают свои конфигурации в случае если они поменялись – выросла версия. В процессе применения конфигурации сервера могут скачивать дополнительные файлы, дистрибутивы и т.д. Для того чтобы развертывать свое решение может понадобиться реализовать дополнительный компонент – ресурс DSC (DSC resource), который будет знать, как развертывать и конфигурировать именно ваш компонент, какие параметры и где ему нужно задать. Этот ресурс хранится на самой же центральной точке, хранилище конфигураций, и не нужно заботиться о его доставке на сервера. Все произойдет само по себе.

Еще одна технология, которая является экспериментальной на данный момент это OneGet. Ее можно рассматривать как пакетный менеджер для Windows сред. Идеологически это фреймворк, который может использовать любой внешний репозиторий пакетов, по-умолчанию используется публичный репозиторий Chocolatey основанный на NuGet. Однако вы можете реализовать провайдер для любого репозитория, используемого в компании. Такой подход является большим шагом вперед. Использование репозитория делает почти любой деплоймент, основанный на распространении файлов, довольно простым занятием. По сути система, собирающая решение, должна будет положить готовый пакет в репозитарий. В тот момент, когда возникнет необходимо в развертывании оно может быть инициировано любым централизованным средством типа SCCM.

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

Основываться на пакетах. Не нужно изобретать велосипед.
Выяснить, если ли у компании существующая инфраструктура control/repository/deployment и рассматривать ее в качестве среды для развертывания, дабы не изобретать велосипед. Скорее всего она учитывает все нюансы и политики безопасности компании, что с одной стороны усложнит, а с другой упростит вашу жизнь в будущем.
Если таковая система есть, использовать ее для развертываний

Ссылки
WMI
MSI
WIX
OneGet

Манифест инженеров поддержки