В даний час існує велика кількість хороших програмних рішень. Чому ж тільки деякі з них успішні? На мій погляд здебільшого причина в тому, що вони недостатньо добре вписуються у великі корпоративні інфраструктури, керовані 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