5.1.3 Хід виконання

Обрати задачу, що потребує використання ЦОД як системи зберігання даних, як інфраструктури або системи обробки даних.

Розглянути можливості використання публічних хмарних сервісів для реалізації запропонованої задачі.

5.1.4 Контрольні запитання та завдання

1. Як здійснюється оцінка аутсорсингу послуг дата центрів?

2. Провайдери хмарних послуг.

3. Що таке хмарний брокер?

4. Які існують умови створення приватних хмар?

5. Які існують умови використання публічних хмар?

6. Опишіть приватну хмару як елемент рівня інфраструктури.

7. Розрахунки вартості ЦОД в залежності від рівня надійності

8. Оцінка аутсорсингу послуг ДЦ та вартості експлуатації ДЦ.

9. Яким чином оцінюється надійність послуги «верхнього рівня»?

10. Розкрийте показники ефективності аутсорсингу

11. Оцініть вартість володіння дата центрів за основними показниками.

12. Оцінка вартості перерв в роботі ДЦ.

6 Індивідуальні розрахункові завдання, контрольні завдання

6.1 Контрольна робота

Для студентів денної форми навчання наведене завдання вважається завданням домашньої контрольної роботи. Для студетнів заочної форми навчання виконання цієї контрольної роботи є обов’язковим компонентом для допуску до складання іспиту.

6.1.1 Завдання на контрольну роботу

Для студентів заочної форми навчання контрольна робота складається з двох частин. Перша частина – відповіді на 3 питання з п.4.2. Питання обираються згідно останнім двом цифрам номеру залікової книжки за такою формулою:

N_i = N_k + N_i-1 *27,

де – номер питання (і  [1, 3]); N₀=0;

N_k – останні дві цифри номеру залікової книжки.

Завдання другої частини.

Обрати довільну задачу, що потребує використання послуг центрів обробки даних. Коротко описати задачу. Розробити SLA (Service Level Agreement) для обраної задачі.

6.1.2 Методичні вказівки до виконання контрольної роботи

Контрольна робота може бути виконана як із застосуванням ЕОМ, так і без її застосування. Перевага надається виконанню роботи з використанням ЕОМ із застосуванням CASE-засобів інфологічного проектування (наприклад ERWin, PowerDesigner тощо).

Типова модель SLA має включати такі розділи:

• Визначення сервісу, сторони, залучені в угоду, і терміни дії угоди.

• Дні та години, коли сервіс буде пропонуватися, включаючи тестування, підтримку і модернізації.

• Число і розміщення користувачів і / або обладнання, що використовують даний сервіс.

• Опис процедури звітів про проблеми, включаючи умови ескалації на наступний рівень. Повинно бути включено час підготовки звіту.

• Опис процедури запитів на зміну. Може включатися очікуваний час виконання цієї процедури.

• Специфікації цільових рівнів якості сервісу, включаючи:

• Середня доступність, виражена як середнє число збоїв на період надання сервісу

• Мінімальна доступність для кожного користувача

• Середній час відгуку сервісу

• Максимальний час відгуку для кожного користувача

• Середня пропускна здатність

• Описи розрахунку наведених вище метрик і частоти звітів

• Опис платежів, пов'язаних з сервісом. Можливо як встановлення єдиної ціни за весь сервіс, так і з розбивкою за рівнями сервісу.

• Відповідальності клієнтів при використанні сервісу (підготовка, підтримка відповідних конфігурацій обладнання, програмного забезпечення або зміни тільки відповідно до процедури зміни).

• Процедура дозволу неузгодженостей, пов'язаних з наданням сервісу.

• Процес поліпшення SLA.

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

Також SLA - це управління очікуваннями користувачів. Якісним може бути тільки таке обслуговування, коли кожен, хто подає заявку, завжди знає - коли ця заявка буде виконана, тобто грамотне управління очікуваннями користувачів.

Впровадження Service Desk, безумовно, тісно пов'язане як з визначенням каталогу сервісів, так і з розробкою SLA. оскільки:

• без каталогу сервісів неможливо окреслити зону відповідальності ІТ-служби - а значить, грамотно підібрати ресурси і організувати процеси роботи

• без SLA неможливо задати орієнтири роботи ІТ-служби (причому такі орієнтири, які б корелювали з цілями бізнесу).

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

Визначте терміни для виділених SLA. Щоб вказати в SLA реально здійснимі терміни, ми повинні: а) знати, які терміни ми в змозі дотримуватися зараз; б) розуміти, який процес стоїть за дотриманням цих термінів.

При розробці SLA необхідно враховувати кілька ключових моментів:

• параметри якості, що визначають, як повинні функціонувати сервіси - тобто як виміряти, чи досягнута ІТ-службою поставлена мета - повинні бути вимірні.

• Встановлені параметри повинні бути досяжні в поточному житті ІТ-служби. Така організація роботи саме по собі мотивує персонал. А ось якщо завдання зрозуміле, але недосяжна - від неї немає ніякого толку.

• Не всім користувачам повинні бути доступні всі сервіси та послуги (наприклад, запросити послугу зі створення нової поштової скриньки можуть тільки керівники бізнес-одиниць; а повідомити про інцидент можуть всі користувачі). Відповідно, необхідно планувати розробку кількох SLA з різними групами користувачів

• Різні співробітники компанії вимагають різних умов надання одних і тих же послуг.

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

• Передбачити способи вимірювання фактичних параметрів якості.