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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.