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

Згідно з дослідженням Boston Consulting Group, у якому взяли участь 825 керівників вищої ланки з 70 компаній, що провели 895 цифрових трансформацій, лише 30% трансформацій досягли своїх цілей.

Це не ті цифри, які вселяють довіру. На щастя, такі компанії, як Stark & Wayne, попрацювали над тим, щоб забезпечити багаторазову міграцію підприємств, аби інші могли її уникнути. Stark & Wayne — експерт у галузі міграції корпоративних інфраструктур. Серед попередніх проєктів — розгортання Cloud Foundry Foundation, які керують 45 000 екземплярами застосунків.

Задокументуйте базовий рівень продуктивності

Це обов’язкова умова! Кожна компанія прагне підвищити продуктивність, але багатьом бракує базових показників продуктивності або способів виміряти, що означає вища продуктивність. Чи пов’язана продуктивність із досвідом кінцевого користувача? Чи ґрунтується вона на масштабуванні робочих навантажень вгору й униз, щоб зменшити споживання ресурсів? Чи вимірюється продуктивність скороченням часу розгортання або оновлення? Щойно ви визначите, як вимірюватимете продуктивність, ви зможете пов’язати її зі своїми застосунками, клієнтами й бізнесом.

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

Те, що ви вимірюєте, залежить від бізнес-вимог, але є й кілька загальних показників.

Список стандартних контрольних показників

  • Час роботи компонентів
  • Час відгуку застосунку
  • Загальний час виконання застосунку
  • Тестові застосунки для перевірки підключення компонентів і доступності служб
  • Показники API (завантаження сторінки, використання пам’яті, ЦП, продуктивність сервера)
  • Вихідне навантаження журналу
  • Завантаження звітів про захворюваність із плином часу
  • Автоматизація (і ставтеся до автоматизації як до громадянина першого класу, адже вона підвищить загальну продуктивність)
  • Зміни операційних витрат у зв’язку з міграцією та автоматизацією завдань
  • Тестуйте типи застосунків, які моделюють ваше середовище.
  • Хороші інформаційні панелі: не можна перенести те, чого не можеш знайти

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

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

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

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

З чого почати? Для початку дайте відповіді на загальні запитання:

  • У яких регіонах ви працюєте і чому?
  • Які застосунки працюють у кожному регіоні?
  • Які служби використовує кожен застосунок у кожному регіоні?
  • Яка версія Linux використовується?
  • Які застосунки взаємодіють з іншими застосунками в регіоні?
  • Які застосунки призначені для клієнтів, а які — внутрішні?

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

Перевіряйте те, що можете, і приймайте те, чого не можете знати

Хай як добре ви перевірятимете чи документуватимете кожну деталь, залишаться невідомі змінні, що впливатимуть на час простою, клієнтів і співпрацю.