ITSM лікнеп: Навіщо потрібно управляти ІТ-послугами, а не просто ІТ-інфраструктурою

imageУявляю черговий переклад статті. Сьогодні це коротка рекламна стаття з блогу компанії Optanix. «Why You Need to Manage Services, Not Just Infrastructure» автор: Kishore Ramamurthy.

Навіщо Вам витрачати свій час на чергову рекламу? Не поспішайте робити висновки. На мій погляд, стаття цікава, оскільки дає дохідливий приклад опису цінності сервісного підходу до управління ІТ. Її можна брати як шаблон для обґрунтування корисності CMDB та сервісно-ресурсних моделей своєму керівництву, як від ІТ, так не від ІТ.

Цікаво? Прошу під кат. Не згодні? Прошу залишати коментарі. Не тільки не згодні, але і хочете знизити рейтинг публікації? Тим більше, прошу залишати коментарі :)

Тут і далі курсивом, коментарі перекладача.


Уявіть, що Ви збираєтеся в поїздку на поїзді. Приходьте на вокзал і бачите готовий до відправлення складу, але немає ніяких ніяких позначень, немає підказок на який він платформі, не кажучи вже про те, в якому напрямі слід. Є лише пів десятка платформ з поїздами, які очікують відправлення. Як дістанетеся до місця призначення? Вся інфраструктура перед Вами, але нічого не відомо про поїздах-послуги, які відходять зі станції.

Якщо Ви просто керуєте Вашої ІТ-інфраструктурою, то маєте аналогічну ситуацію. Ви знаєте, де сервера, бази даних, масиви сховищ і мережеві пристрої, але не маєте ні найменшого уявлення, як дані транслюються через ІТ середовище. Наприклад, підтримує згадана база даних портал електронної комерції, або вона використовується для відстеження виробничих залишків, а може вона задіяна в обох випадках?

Розуміння на рівні окремих компонентів Вашої ІТ інфраструктури недостатньо. Потрібно розуміти, як усі ці компоненти працюють разом, надаючи Бізнес Послуги, інакше це рівносильно подорожі в сліпу. Необхідно знати які компоненти задіяні в наданні конкретної Бізнес Послуги і їх взаємозв'язку. І поки цього немає, Ваша Послуга, споживана Бізнесом, перебуває в групі ризику.

У уникнення цього і потрібно управляти саме Послугами.

Розуміння впливу змін на Бізнес

Перша причина — це самі зміни. Кожен раз, коли Ви вносите зміни, Ви ж перший і потребу в усвідомленні їх потенційного впливу на Бізнес Послуги. Для прикладу, якщо Ви перенастраиваете окремий модуль, що підтримує Послугу, Ви сподіваєтеся, що вона продовжить успішно працювати з усіма іншими компонентами цього програмного комплексу? Якщо ні, то це шлях до серйозних проблем, які принесуть шкоди Бізнесу: погіршення продуктивності, втраті клієнтів або виручки.

По мірі того як Бізнес Послуги все більше стають комплексними, розуміння взаємозв'язків між Послугами та інфраструктурою стає все більш і більш важливим. Це знання не лише про додатку, запущеному на одному сервері і доступ до бази даних на іншому. Тепер безліч додатків взаємодіють один з одним, створюючи множинність базових технологічних елементів. Віртуалізація додає складності за рахунок здатності віртуальних машин і інших компонентів до динамічних змін, здатних відбуватися автономно. При відсутності розуміння цих багатогранних зв'язків, зміни стають надзвичайно витратним за часом і ризикованим за наслідками процесом. Розуміння, як зміни інфраструктури впливають на Бізнес Послуги, полегшує планування змін. Наприклад, ви можете знати, що для апгрейда сервера, його потрібно вимкнути. Наслідки цього відомі і вони неминучі. Однак, якщо вам не відомо які Бізнес Послуги він підтримує, у вас немає шансів узгодити технологічне вікно для цих зміну або сповістити власників Бізнес Послуг про заплановані зміни до того, як вони будуть виконані.

Уникнення випадків тривалих збоїв Послуг

Друге — це Доступність Послуг. Коли Бізнес Послуги стають недоступні аварії або їх якість погіршується, Ваше завдання відновити пов'язані з ними дані і запустити їх так швидко, як це тільки можливо. Наприклад, Delta Air Lines при останньому п'яти годинному просте з-за збою всього одного пристрою, втратила $500 млн і отримала розголос у заголовках в газетах по всьому світу. Причиною ж того, що сталося стало каскадне відключення обладнання із-за збою модуля контролю живлення, що призвело до руйнівних наслідків і на інших важливих об'єктах інфраструктури.

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

Щоб виділяти причини проблем, потрібно знати, як ІТ інфраструктура поставляє Бізнес-Послуги. Інакше зіткнетеся недоступністю Послуг і лавиною, начебто не пов'язаних одна з одною подій, кожне з яких може бути кореневої (істинної) причиною проблеми. Збій це сховища даних, або відсутність мережі, або падіння програми? Поки не відомо, за рахунок чого надаються Бізнес-Послуги та яку роль у цьому відіграє кожен компонент інфраструктури, складно визначити корінь проблеми.

В іншому випадку, якщо є розуміння цих взаємозв'язків, ви можете значно прискорити діагностику і усунення причин проблем з Послугами. Фактично розуміння цього на рівні Послуг одна з основних причин чому (пішла реклама продукту) Optanix platform здатна в звичайних умовах виявити справжню причину проблеми з Послугою не більш, ніж за 30 секунд. Коли кожна хвилина коштує тисячі доларів або більше видимість стану Послуг це не розкіш, а необхідність.

Баланс якості та вартості сервісу.

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

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

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

Давайте підведемо підсумки

Безліч ІТ організацій продовжують керувати інфраструктурою, а не Бізнес Послугами. Використання інфраструктурного підходу, який працював у минулому, більше не дозволяє збільшувати складність сьогоднішніх Бізнес Послуг. Відсутність розуміння, як Ваші Бізнес Послуги, пов'язані з Вашою ІТ-інфраструктурою, приводить до більш частого погіршення якості Послуг і робить більш тривалим їх відновлення. Ось чому так важливо шукати рішення для управління ІТ, яке руйнує розрізненість інфраструктури і надає наскрізну видимість Послуг. Якщо Ви цього не зробите, то піддаєте ризиків весь Бізнес. Зв'яжіться (і знову реклама) з нами сьогодні дізнайтеся більше про те, як Optanix може допомогти Вам керувати критичними Бізнес Послугами.

На сьогодні все. Дякую за увагу. Залишайте ваші відгуки.
Джерело: Хабрахабр

0 коментарів

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