ITIL для розробників



"… british scientists proved..."


Привіт, Хабр. Мене звуть Сергій Сапегін, я працюю PHP-розробником в DataArt. Але сьогодні я хочу поговорити не про PHP.

Працівники ІТ, незалежно від галузі спеціалізації, останнім часом все частіше стикаються з цікавим феноменом світу ITIL. Оскільки загальносвітова тенденція не оминула і DataArt, ми провели невелике дослідження, щоб зрозуміти, що і як слід знати нашим розробникам, щоб деякі процеси замовників не ставили в глухий кут всю команду. Представляємо вам, що з цього вийшло…

Куди дівається софт?
Виробляючи різноманітні фічі і виправляючи численні баги, доводячи розробляються компоненти до рівня релізу ми, як правило, не замислюємося, куди це все потім дівається. Фактично, софт для нас — щось, що лежить на операційному робочому столі, то, що треба препарувати, доробити, переробити, вилікувати і змусити працювати.

Більшість методик і прийомів, спрямованих на досягнення якості випливають з цього погляду на світ. Безумовно, струнка архітектура, об'єктний підхід, MVC, угоди про оформлення коду і коментарі… Ми так багато уваги приділяємо цьому, що абсолютно незрозуміло, звідки вилазять чергові потворні чудовиська, які так дороги користувачам, що обов'язково треба привести їх у порядок. Краса повинна була давно вже правити світом.

І, кажучи відверто, вона править. У світі існують мільйони різновидів прекрасного, чарівного, надихаючого ЗА! Інша справа, що ми, розробники, оцінюємо красу програмних виробів здебільшого зі своєї професійної точки зору, приблизно також, як паталогоанатом хірург може оцінювати красу людей, виходячи зі стану їх внутрішніх органів. В той час, як весь інший світ аплодує фигуристым блондинкам з подіумів.

Як же нам доторкнутися до цього непростого погляду всього світу? Світ вже знайшов спосіб привести красу IT до стандарту — він пропонує нам ITIL!

Ідея британської корони
Як змусити програмістів писати не просто якісний, але корисний для користувачів софт? Багато хто намагався відповісти на це питання, але найбільш успішний результат поки вийшов у британського уряду. Ідея, покладена в його основу, була досить простою: зібрати інформацію за досить великою кількістю проектів, виділити серед них успішні і неуспішні, розбити за критеріями, витягти з цього набір правил. А проектів автоматизації різних організації у оного уряду вже накопичилося хоч відбавляй.

Зібралася група експертів (попередньо пообіцявши всім роздачу рожевих слонів), ретельно опрацювала статистику — і виникла бібліотека ITIL. Зараз вона стає все популярнішою, пережила вже третю інкарнацію (найсвіжіша та популярна версія — ITIL V3), а найголовніше — вона, по суті, пояснює, що користувачу потрібно, як йому організувати експлуатацію всієї його IT-інфраструктури, як оцінити, що приносить користь, що шкідливо, а що марно. Найпікантніше, що оцінка працює незалежно від того, чи дійсно користувач знає свої реальні бажання, може чи ні їх сформулювати. Якщо він, звичайно, взагалі зацікавлений у використанні IT в своєму бізнесі.

Основа ITIL
Перше, з чого починається знайомство з ITIL, — загальні поняття і терміни, які можуть дуже відрізнятися від очікувань. Сама ITIL — бібліотека (збірка) рецептів, придатних для організації процесу експлуатації IT. Спосіб управління організацією IT-послуг на основі рецептів цієї бібліотеки називається ITSM (IT Service Management). Бібліотека 3-й версії (ITIL v3) складається з декількох основних книг, послідовно висвітлюють питання організації різних сфер роботи з IT-інфраструктурою підприємства.

Ключове поняття ITIL, на базі якого розгортається вся інша ідеологія, — поняття сервісу. В ITIL v3 сервісом називається «спосіб надання замовнику цінностей (values), очищених від ризиків і витрат, властивих дій, за отримання цих результатів» (A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks). Зверніть увагу, що під цінностями в контексті роботи організації, як правило, мається на увазі досягнення працівником будь-яких проміжних цілей у процесі виконання своїх професійних обов'язків. Це визначення досить сильно відрізняється від того інтуїтивного поняття «сервісу», яке притаманне розробникам. (Мається на увазі «розгорнутий в мережі набір функціональності, який можна використовувати»).

Сервіс ITIL — це:
  1. Не тільки і не обов'язково набір програмної функціональності. Грубо кажучи, ми постійно вважаємо нову модель рушниці способом полювання. Хоча на ділі, щоб воно було способом, його треба розпакувати, пристріляти, зарядити, доставити на місце, направити на ціль і дати в руки мисливцеві. Все це, з точки зору ITIL, — складові частини сервісу.
  2. Спосіб надання замовнику цінностей. Розроблений софт використовується користувачем не тому, що його легко і зручно використовувати, він має ретельно продуману архітектуру і т. д., а тому, що він приносить користувачеві цінності, причому набір цих цінностей обмежений рамками виробничого процесу, і мислить категоріями якого користувач. Перевірте себе, відповідайте, який алгоритм сортування краще — традиційний «бульбашка» або Quicksort? А якщо мова йде не більш ніж про десять елементах? А якщо він потрібен взагалі щоб пояснити людині принцип сортування?
  3. «… очищених від ризиків і витрат» — теж важливе доповнення. Всю продуктивність розробників, яку важко визначити і нормувати з точки зору процесу розробки, користувач оцінює зі своєї точки зору по одній простій і безвідмовної шкалою — очищення свого робочого процесу від ризиків і трудовитрат. Чи Давно ви самі писали гнівні повідомлення на форумах про відсутність кнопки «Пуск» в новій версії Windows? Чи замислювалися тоді безсумнівних поліпшень в функціональності і надійності цієї ОС? Чи Часто ви входите в положення сервісних служб, коли у вас падає інтернет або відключають електрику?

Виходить, як у поета: ми говоримо «ITIL» — маємо на увазі «сервіси», говоримо «сервіси» — маємо на увазі «доставлені цінності, очищені від ризиків і витрат».

Структура і місце ITIL
В якості ілюстрації тієї області, яку охоплюють методики ITIL (а конкретніше — ITIL 3), можна подивитися на наступну картинку:



Основне завдання ITIL, таким чином — отримання вигоди для робочого процесу з існуючої інфраструктури. Однак, оскільки існує в реальності ніколи не буває достатньо, процеси ITIL охоплюють область формування вимог до нового та включають процеси його приймання, тестування і введення в експлуатацію.

Структура ITIL у 3-й редакції складається з п'яти основних книг і виглядає таким чином:



Розглянемо їх зміст докладніше…

Service Design
Книга, присвячена проектуванню сервісів, деталізує принципи, які повинні використовуватися при грамотному розвитку ІТ-інфраструктури. В процесі проектування сервісів, крім усього іншого, визначається потреба в новому, визначається набір початкових вимог до нього, вибирається виконавець — і тут в справу вступають розробники. Вибір виконавця і характер проекту зазвичай визначається шляхом знаходження балансу між:

  1. функціональністю сервісу (бізнес — та системної);
  2. його вартістю (включаючи фінансові, виробничі і кадрові ресурси);
  3. часом, за яке треба запустити сервіс в експлуатацію.


Крім вимог до ПЗ, при проектуванні сервісу зазвичай опрацьовуються питання запуску його в експлуатацію, подальшого управління і т. д. Сам процес проектування зазвичай організовується на основі матриці RACI (Responsible, Accountable, Consulted, Informed), згідно з методом якої, участь кожного учасника в задачі може бути наступних типів:

  • Responsible — учасник може брати участь у роботі над завданням.
  • Accountable — відповідальний за завдання (тільки один на кожну).
  • Consulted — бере участь у роботі в якості консультанта.
  • Informed — повинен стежити за ходом робіт і отримувати інформацію про прогрес.


У більш специфічних випадках використовують розширену матрицю RACI-VS, до якої додаються наступні ролі:

  • Verifies — людина або група людей, що перевіряють відповідність результатів роботи заданим критеріям.
  • Signs off — людина, що фіксує досягнення мети і приймає рішення про випуск продукту (роль сумісна з роллю A).


Існує ще одна варіація цієї матриці, т. зв. RASCI, в якій передбачено наявність ролі Supportive — для людей, що забезпечують підтримку основного потоку робіт.

Service Transition
Власне кажучи, зазвичай ми досить мало знаємо про ITIL ще й тому, що бібліотека ніяк не формалізує сам процес розробки. Для нас він постає у вигляді Agile, водоспаду або ще чого хитріше, а з точки зору користувачів, це чорний ящик, куди кладуться вимоги, що там усередині шарудить і працює на виході виїжджає цукерочка готове. Однак, того, що далі робити з виїхали з чорного ящика, присвячена чергова книга — «Передача сервісів».

Основна мета процесу передачі сервісів — розгортання і введення в експлуатацію нових версій сервісів в загальній інформаційній середовищі підприємства. Основа процесу — зазвичай формальна угода, складена у документальному вигляді і використовується у всіх випадках введення сервісу в експлуатацію. Важливість цього пов'язана, насамперед, з тим, що процес некорретного введення сервісу в експлуатацію може принести серйозні збитки эксплуатирующему його підприємству. Чому я підкреслюю цей факт? Для нас зазвичай цінна саме функціональність, то, що ми робимо: алгоритми, структури таблиць БД. А для користувача найбільшу цінність представляють ДАНІ. В руках у користувача структури даних заповнюються не абстрактними «123», «test», «privet», «helloworld», «test again», а цілком конкретними фактами з реального життя, що мають значення (виражається у грошах!) для діяльності компанії. А оскільки, як я вже говорив вище, софт завжди приходить на зміну чого-небудь, проблем адаптації старих даних під нові моделі слід приділяти найпильнішу увагу. По можливості — з самого початку розробки, а не коли вже зробили готовий виріб.

Коли розроблене ЗА запускається в експлуатацію, інтереси користувача уразливі найбільше: він довіряє вашого продукту найцінніше, що у нього є — ІНФОРМАЦІЮ.

Передача в експлуатацію зазвичай пов'язана з кількома етапами тестування, часто пов'язана з використанням будь-яких технічних засобів, що регламентують процес (CI — continuous Integration), а результат її… тут де-факто є невелика розбіжність результатів.

Для розробника кінцеві результати — підписаний акт про передачу та фінальний платіж.

Для замовника кінцевий результат — факт використання програмного кошти за призначенням. Спільне досягнення цих результатів і є бажаний підсумок проекту. Багато зараз подумали про варіанти, коли «розробник склав програму і зник, а користувач з нею мучиться і не може толком працювати» — справедливості заради, є й інші варіанти, коли «користувач поставив стару версію і працює, а всякі ліві баги не помічає, від нових фіч відмовляється». Оптимум — десь посередині.

Головне завдання організації процесу передачі сервісів — уникнути затяжних антагоністичних конфліктів між командами, причини яких — нерозуміння і, швидше за все, різні корпоративні інтереси. Для попередження і вирішення конфліктів використовуються і формальні документи (SLA, ТЗ тощо), та неформальні ініціативи, спрямовані на усунення нерозуміння і розширення загального понятійного контексту між групами розробки та експлуатації сервісів.

Service Operation
«Використання сервісів» — внутрішнє чтиво наших клієнтів, з якого, однак, можна почерпнути чимало корисного. З нашої точки зору особливий інтерес представляє не сам комплекс методів організації роботи користувачів з ІТ-забезпеченням, а його вихідні регламенти та документи.
Наприклад, посмішку можуть викликати регламентовані рецепти обходу багів, які розробники так і не спромоглися виправити. Однак головна мета аналізу інформації про реально відбувається в компанії під час її роботи — зрозуміти, наскільки запроваджене було вдалим, наскільки воно корисно, де у нього є вузькі місця… де є вузькі місця в роботі співробітників компанії взагалі (і що ми можемо зробити за гроші, щоб це виправити).
Книга в цілому цікава і корисна, особливо в частині розуміння, де і що з ІТ-забезпечення використовується в реальній роботі.

Continual Service Improvement
Остання книжка ITIL 3-ї версії присвячена організації саморефлексії — відстеження, які процеси відбуваються в організації, спроб поліпшення якості використовуваних сервісів. Найголовніший постулат книги — процес вдосконалення корпоративної ІС повинен відбуватися постійно і безперервно. Ну, а методики, що використовуються для цього, можуть бути надзвичайно різноманітні.
Наприклад, широко використовуються різні способи вимірювання технічної продуктивності ІТ-сервісів, ефективності їх роботи у взаємодії з користувачем, способи загальної оцінки роботи сервісів, фази їх життєвого циклу і т. д. (цикл Демінга і матриця SWOT).
Знання принципів CSI дозволяє аналізувати, що відбувається в ІТ-інфраструктурі наших клієнтів, пропонувати їм рішення, завойовувати довіру і робити пропозиції, від яких важко відмовитися. Природно, якщо організація-замовник регулярно ділиться даними постійного моніторингу своєї ІТ-інфраструктури.

У підсумку?
Все це, звичайно, цікаво (хоча й дещо умоглядно), але навіщо розробнику-практику знати про цих низинних, юзерских концепціях? Наша справа — дбати про якість коду!

Може бути, воно так і повинно бути, але практика показує інше. Більшість холиваров про «прямих руках» та «кривих архітектурах» користувачеві байдужі. Більш того, між користувачами та розробниками, виявляється, існує великий простір, успішно перетнути яке під силу не кожному програмному продукту. І, як мені здається, настав час задуматися, як дати своєму програмному дітищу більше шансів стати корисним для кінцевого користувача. А допомогти в цьому може погляд на розробку з позиції ITIL.

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

0 коментарів

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