Вирішення непередбачуваних проблем розвитку інфраструктури ІС

Під непередбаченими проблемами розвитку інфраструктури ІТ ми тут і далі розумітимемо проблеми, не передбачені в регулярному плануванні ІС.

Слід зазначити, що для сучасного стану ІС і ІТ-інфраструктури російських підприємств непередбачені проблеми дуже типові. До них можуть відноситися:

- неприпустимі простої критично важливих сервісів (наприклад, програм операційного дня в комерційному банку);

- припинення супроводу критично важливих додатків внаслідок розпаду внутрішньої команди розробників або невеликої фірми-постачальника;

- масштабну поразку корпоративної мережі комп'ютерним вірусом;

- необхідність термінової легалізації вживаного ПО внаслідок правових проблем і т.д.

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

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

- технічні проблеми, не передбачені в рамках регулярних процедур планування і управління ІТ, наприклад «проблема 2000 року»;

- зміну технічної політики виробників устаткування і ПО, наприклад коливання компанії Hewlett-Packard відносно своєї лінії UNIX-серверів;

- зміну ліцензійної політики виробників ПО, наприклад введення фірмою Microsoft практики обмеженого терміну дії ліцензії на операційну систему Windows XP,а також інші можливі проблеми.

Ці зовнішні ризики знаходяться на зовні контролю підприємства і його ІС, внаслідок чого вдосконалення управління ІС не дозволяє їх усунути.

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

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

Розглянемо загальні принципи таких «надзвичайних проектів», як ми і будемо їх називати надалі:

- метою проекту є відновлення сервісу, а не забезпечення працездатності устаткування і ПЗ;

- проект повинен передбачати декілька варіантів рішення, включаючи основний (відновлення сервісу) і один або декілька резервних варіантів задоволення бізнес-вимог у випадку, якщо сервіс забезпечити не вдастся (дана умова не обов'язкова, якщо причина проекту - подорожання сервісу);

- необхідно оцінити повні витрати по моделі ФСА для основного і резервного варіантів рішення;

- проект повинен передбачати систему моніторингу, що дозволяє при необхідності завчасно перемкнути зусилля і витрати з основного варіанту на запасний.

Таким чином, розробка схеми проекту рішення проблеми має на увазі декілька обов'язкових етапів:

1. Діагностика проблеми - визначення переліку устаткування і ПО, зачеплених проблемою, потім внутрішніх сервісів, заснованих на даному устаткуванні і ПЗ, і, нарешті, зовнішніх сервісів.

2. Сортування порушених проблемою зовнішніх сервісів по їх пріоритетах. В результаті визначається коло сервісів, відновлюваних в рамках надзвичайного проекту. Інші сервіси відновлюються при виконанні звичайних інфраструктурних проектів.

3. Розробка і оцінка варіантів рішення проблеми. У кожному варіанті аналізуються, по-перше, здатність розв'язати проблему, і, по-друге, витрати по моделі життєвого циклу ІТ-рішення. Виходячи з останнього критерію серед допустимих варіантів вибирається оптимальний.

4. Виконання проекту і його моніторинг. Вибраний варіант рішення проблеми виконується. Паралельно керівництво проекту контролює хід робіт з метою визначення відхилень від плану і їх істотності.

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

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

7. Введення в дію резервного плану у випадку, якщо основний проект не укладається в необхідні терміни.

8. Запуск в експлуатацію основного варіанту рішення проблеми, що включає заходи щодо забезпечення безперебійного функціонування рішення в перехідний період.

Вищенаведена схема заснована на досвіді рішення «проблеми 2000 року», що є на сьогоднішній день найбільшим проектом такого роду. В більш простих проектах, таких як заміна бухгалтерської системи, ряд кроків може бути опущений. Проте базова схема залишається незмінною: оцінка масштабу проблеми - вибір основного варіанту рішення - виконання робіт - планування резервних варіантів - оцінка готовності до експлуатації.

Економічна оцінка проекту рішення проблеми проводиться в наступному порядку. Початковий пункт - оцінка втрат, пов'язаних з непередбаченими обставинами. Ці втрати складаються з трьох складових:

1. Втрати від можливої відмови сервісів, зачеплених проектом. Дані для такої оцінки збираються в рамках моделі ФСА в ІС підприємства (див. розділ 1.3). При необхідності дані про втрати уточнюються бізнес-підрозділами.

2. Втрати від скорочення життєвого циклу ІТ-рішення. Дані для цієї оцінки збираються в рамках моделі життєвого циклу ІТ-рішення (див. розділ 2.2.1).

3. Далі оцінюється подорожання сервісів у зв'язку з непередбаченими обставинами. Ці дані оцінюються також на підставі моделі життєвого циклу ІТ-рішення (див. розділ 2.2.1).

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

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

Рис. 2.12. Прийняття рішень по проекту вирішення проблем

Якщо проект був початий, витрати списуються на проект як тимчасовий об'єкт витрат. При успішному завершенні проекту витрати списуються на сервіси ІТ, зачеплені непередбаченими обставинами.

Схему ухвалення рішення за проектом рішення проблем наведено на рис. 2.12. Оцінка можливих втрат від непередбачених обставин проводиться спільно бізнес-підрозділами (уточнення втрат від відмови сервісу) і ІС (оцінка інших видів втрат). На підставі сукупної оцінки втрат оцінюються варіанти рішення з урахуванням впливу на інші проекти. На підставі основного і резервного варіантів рішення формуються основна і альтернативна оцінка витрат. Рішення про доцільність проекту ухвалюється Комітетом із змін. При значному об'ємі проекту рішення приймає Правління підприємства. Це мало місце, наприклад, у разі «проблеми 2000 року». Її рішення вимагало від найбільших російських підприємств витрат в десятки мільйонів доларів. Ці суми знаходилися у винятковій компетенції Правління відповідних підприємств.