Давайте подивимося правді в очі – зазвичай при виникненні проблеми насамперед звинувачують базу даних, і ця ситуація “винна, доки не доведено протилежне”. Точніше, коли щось працює “повільно” або продуктивність не відповідає очікуваній, база даних часто стає однією з перших підозрюваних.
Багато років тому те саме часто відбувалося з віртуалізацією та системами зберігання даних, хоча зміни згодом зменшили закиди на адресу цих областей. Що дійсно цікаво, так це те, що, хоча розміри даних згодом зростали експоненційно, очікування від продуктивності ставали все більш жорсткими та короткими щодо часу відгуку.
Якби ви запитали представників свого підприємства, з якою швидкістю повинен виконуватися той чи інший процес, якою була б відповідь? А як щодо того, яку частину апаратного забезпечення вони мають використати? Чи замислювалися ви про те, як змінювалися відповіді на ці питання з плином часу, чи що ще важливіше, як вони можуть змінитись у майбутньому?
Є сенс думати про свою роботу як захист систем від несподіваних проблем у майбутньому, але це не завжди можливо, оскільки завжди можуть виникнути обставини і ситуації, про які ніхто і не підозрював. Оцінка співвідношення витрат та вигоди в порівнянні з ризиком також іноді визначає, що ризик неймовірно малий у порівнянні з витратами на усунення ризику та потенційною вигодою, яку він може принести. Але як саме кількісно оцінити різні частини цього рівняння?
Армійський підхід щодо витрат у порівнянні з вигодою та ризиком
Простіше кажучи, щоб розрахувати витрати порівняно з вигодою та ризиком, ви повинні мати повне уявлення про те, що відбувається.
Оцінка ризику є частиною кожного прийнятого рішення, кожного проведеного заняття, практично кожного заходу, що проводиться військовими. Скрізь є оцінка ризику та аналіз наступних дій, а також застосування отриманих уроків для мінімізації ризику втрат, зниження ефективності або ризику провалу виконуваної місії/завдання.
Є старе прислів’я, яке говорить: “Ти сильний настільки, наскільки сильна твоя найслабша ланка”. У бою найважливішим активом є не піхотинець на передовий чи артилерія, що веде неприцільний вогонь, а лінії постачання, необхідні для поповнення запасів інших підрозділів, коли їх початкові запаси, доставлені на поле бою, виснажуються.
Це було підтверджено неодноразово. Можна стверджувати, що без доступу до даних, що зберігаються в базі даних, найкращий у світі додаток не зможе функціонувати. Уявіть собі, що весь код, обчислювальні потужності в хмарі або мікросервісні архітектури на середньому рівні не можуть виконати своє завдання, тому що їм не надаються дані, необхідні для виконання операцій.
У бою неможливо просто думати, що запаси будуть там, де вони потрібні; існує величезна інфраструктура, створена для того, щоб спрогнозувати потреби, визначити, як ефективно доставити їх туди, де вони мають бути, та контролювати ці дії, щоб переконатися, що очікуваного результату досягнуто.
Іноді достатньо лише незначного збою у потоці завдань, щоб виникли катастрофічні наслідки. Така проста річ, як колесо, що спустило на автомобілі, може призвести до багатогодинних затримок. Часто у таких ситуаціях розробляється план, що дозволяє мінімізувати наслідки будь-якої окремої події чи збою, але це не завжди так. Наприклад, якщо колона везе матеріали до лінії фронту, а машина зламалася, чи зупиняється вся колона, поки її відновлюють, чи машина відходить убік, а решта продовжують рух повз неї?
Проблеми при побудові операційного плану без комплексного моніторингу
Висока доступність та аварійне відновлення є невід’ємними частинами будь-якого операційного плану моніторингу бази даних. Надмірність виправдана лише настільки, наскільки велика здатність прогнозувати можливі точки відмови. Резервування не обмежується наявністю кількох важливих для місії активів – воно також включає стратегічне розміщення, щоб втрати всіх важливих для місії активів не відбулися в результаті однієї події. Часто це включає здатність виявити, що щось не працює належним чином, і переключитися на альтернативну/резервну стратегію, раніше передбачену планом.
У сфері ІТ це часто ґрунтується на доступності/недоступності послуг. Важко підрахувати, скільки разів сервер баз даних працював і міг відповідати на запити підключення та прості запити, але не міг обробляти робоче навантаження програми через умови, що сильно впливають на продуктивність, і при цьому ніхто не знав, що відбувається. Гірше того, коли хтось дивився на систему, не було поняття про те, що нормально, а що ні, виходячи з поточних умов.
Такі речі неймовірно безсистемні за своєю конструкцією, але, як говорить одна з приказок розробників, “Швидше – значить веселіше”. Чим швидше йдуть справи, тим кумеднішими можуть бути реалізовані рішення (Поспішиш – людей насмішиш).
Чому звітність, моніторинг та автоматизація мають вирішальне значення для спостереження бази даних
Можливість отримувати звіти про ситуацію (sitreps) в режимі реального часу під час операцій необхідна для гнучкого реагування на умови, що змінюються в міру їх розвитку. У сучасному хмарному операційному середовищі можливість моніторингу кожного аспекту рішення має вирішальне значення. У певних середовищах можливість передиктивного збільшення чи зменшення ресурсів з урахуванням тенденцій використання неймовірно важливіша для мінімізації витрат.
Хоча великі платформи нещодавно впровадили автоматизовані рішення для цього, існують обмеження на обсяг даних, що зберігаються для автоматизації таких прогнозів. Крім того, хоча і приємно, що така функція існує, все ж таки необхідно зберігати показники операційної ефективності окремо в базі даних для різних цілей. Прогнозувати зростання витрат за роками можна лише тоді, коли можна побачити тенденції змін у часі. Що якщо компанія придбає іншу компанію внаслідок злиття? Як це вплине на потреби у ресурсах?
Чи знаходили ви коли-небудь час, щоб розглянути ефективність можливостей ситуаційних звітів у вашому існуючому операційному середовищі? Під час надзвичайної ситуації або за умов дефіциту часу дуже важливо забезпечити ефективний зв’язок, передати точні дані та надати важливу інформацію.
Чи зможе ваше поточне рішення вирішити це завдання? Справа не тільки в наявності даних – не менш важливо, щоб ви могли швидко та ефективно їх аналізувати, щоб своєчасно вживати необхідних заходів. Хороший збір та аналіз оперативних даних зазвичай є проектом, повністю незалежним від існуючих бізнес-проектів.
Важливість AIOps для створення дієвих висновків із даних
Для того, щоб дані стали оперативними, ми повинні мати автоматизовані процеси для завантаження, агрегування та аналізу даних з урахуванням попередніх тенденцій. Саме тут штучний інтелект (ІІ) та машинне навчання стають важливими інструментами аналізу даних. Можливість складання звітів за потоковим контентом з’явилася вже через два місяці після початкового запуску нашого сайту, коли було впроваджено реєстрацію даних. Це стало окремим проектом у зв’язку з необхідністю усунення несправностей у міру нашого зростання. Сьогодні більшість проблем можна швидко вирішити на основі наявної інформації.
Як SolarWinds може допомогти у забезпеченні моніторингу баз даних
Платформа SolarWinds® Platform створена з підтримкою OpenTelemetry (OTEL) для збору даних із тисяч пристроїв, включаючи додатки, написані будь-якою з різних мов .NET, Java, PHP, Node.js або Ruby і працюють на Linux, Windows або Azure. Те саме стосується даних з екземплярів баз даних MongoDB, MySQL, PostgreSQL і SQL Server; вузлів інфраструктури у хмарі; локальних середовищ; і контейнерів Kubernetes. За допомогою OTEL ви можете легко інтегрувати та централізувати ці точки даних у своєму рішенні для спостереження.
За допомогою рішень SolarWinds Observability кожен актив вашої ІТ-інфраструктури стає об’єктом моніторингу. Створені за допомогою інформаційних панелей, що повністю настроюються, для звітності в режимі реального часу, ці рішення можуть надавати уніфіковані відомості про додатки та інфраструктуру для більш глибокої видимості всього технологічного стека.
Джерело: How Database Observability Increases Operational Reliability
