До запуску прикладної системи дефекти та приховані небезпеки можна значно зменшити за допомогою інтенсивного тестування, але оскільки середовище симуляції тесту не може бути точно таким самим, як реальне середовище після запуску системи, тестова робота не може охопити всі сценарії виробництва та роботи ІТ-системи додатків, і важко уникнути збоїв у конкретному сценарії.
Оскільки прихована небезпека невдачі неминуча, дуже важливо вміти спокійно справлятися з нею помилки! Найкраще знати заздалегідь, передбачити можливі проблеми ІТ-системи та вживати заходів, коли проблема не виникає, щоб усунути її на початковому етапі. Незалежно від того, наскільки все серйозно, ми повинні якнайшвидше знати, які проблеми виникли в системі і де вони виникли, і вчасно вирішувати їх до поширення, щоб уникнути ескалації ситуації. Насправді, оскільки ці два моменти досі складно реалізувати, тиск експлуатації та обслуговування є безпрецедентним!
Дивлячись на сучасні підприємства з високим рівнем інформаційної структури, представленою банками, розвиток бізнесу дедалі більше залежить від ІТ, складність їхніх ІТ-застосувань зростає, а керованість дедалі гірша. Але головний біль у тому, що в такій інтенсивній ситуації переслідування та перехоплення системи все одно трапляються, ризики повторюються знову і знову, і часто дрібні проблеми зрештою переростають у серйозні збої, у чому причина? Чому завжди є затримка у відкритті? Чому різні методи моніторингу не можуть виявити аномалії з першого разу? Це необхідно розібрати.
Щодо основних аспектів, комп'ютерна кімната поділяється на дві категорії: базові ресурси та ІТ-прикладні системи. Довгий час ми надавали великого значення базовим ресурсам, таким як мережа, хост, зберігання, температура та вологість комп'ютерної кімнати, а методи моніторингу можна описати як «озброєні до зубів».
Для моніторингу ІТ-прикладних систем наразі вітчизняні та іноземні виробники та постачальники послуг пропонують багато продуктів або рішень, зміст моніторингу має власний фокус, комплексний аналіз, їхня практика полягає переважно у спостереженні за продуктивністю ІТ-прикладної системи на базовому рівні ресурсів через мережевий трафік, продуктивність системи, завантаженість процесора, зайнятість пам'яті, доступ до бази даних, статус проміжного програмного забезпечення та інші індикатори, у поєднанні з аналізом журналів, дослідженням зондів, доступом до симуляції та вилученням проксі та іншими методами отримання певної інформації про роботу системи. Приблизно оцінюючи загальний стан роботи системи, ці продукти або рішення не мають безперервного відстеження та моніторингу деталей роботи системи, тому не можуть зрозуміти деталі стану роботи кожного модуля в ІТ-застосунку і навіть функціональних точок модуля; ці деталі включають: Які транзакції обробляє система? Що вдалося? Що є проблемним? Хто ініціює цю угоду? Коли його запускають? Яким бізнесом ви займаєтесь? Який модуль системи беруть участь? Яка функціональна точка відповідає за обробку? О котрій годині відповідає відповідь? Чи є якісь аномалії продуктивності? Якщо це не вдалося, у чому ж вина? Вони дуже важливі для оцінки робочого стану системи ІТ-заявок.
На практиці, на початку відмови ІТ-прикладної системи, коли точка несправності має незначний вплив на базові ресурси або ще не передана на базовий ресурсний шар, або несправність виникає в проміжку між використанням журналів, зондів, проксі та інших засобів, хоча ризик системи був «підпліковим», але часто існуючі методи моніторингу не можуть відіграти роль, а зовнішня презентація також свідчить про «відсутність аномалій». Це також фундаментальна причина, чому виявлення несправностей відстає і з ним важко впоратися! Можна побачити, що своєчасне виявлення збоїв системи «вперше» є недоліком сучасних ІТ-операцій і технічного обслуговування, і це має велике значення для компенсації експлуатації та обслуговування ІТ.
Що таке «перший раз»? Тобто, у процесі відповіді ІТ-системи на запити доступу, у момент невдачі або аномального відбування транзакції вона має бути точно зафіксована! Усі знають, що раннє виявлення можна вирішити вчасно, і щоб змінити поточну пасивну ситуацію в ІТ-роботі та компенсувати недоліки роботи та обслуговування ІТ, необхідно технічно вирішити проблему виявлення збоїв системи «з першого разу». Завдяки порівняльним дослідженням і практиці роботи великої кількості ІТ-прикладних систем ця ідея технічно здійсненна, але люди в бюро можуть зазнавати впливу інерційного мислення, не вийти з початкового мислення і навіть вважати, що це неможливо в суб'єктивній свідомості, що не призведе до суттєвого прориву в цьому аспекті роботи, а операційні ризики ІТ-застосувань завжди перебувають у пасивній ситуації фрагментарної реакції.
Ключ до «першого» виявлення збоїв системи — бути «уважним» до ІТ-застосункової системи, опанувати кожен її крок, зокрема проводити глибоке спостереження за деталями роботи ІТ-застосунки та суворо контролювати роботу кожного модуля та функціональної точки, водночас цей моніторинг має бути безперервним і безперервним, лише таким чином не пропускаючи жодної аномалії системних транзакцій, щоб робота ІТ-прикладної системи була в контрольованому стані.
Оскільки цей процес може отримувати та накопичувати детальну інформацію про стан роботи системи, створювати дуже цінний файл операцій системи через свій аналіз і використання, він не лише надає орієнтир для оцінки якості кожного модуля та кожної функціональної точки, а й є базою для аналізу розвитку та зміни робочого стану системи, що дозволяє прогнозувати тенденції стану здоров'я ІТ-застосунків.
|
Опубліковано 13.10.2014 10:36:01
|
|
|
