Зміщення конфігурації є важливою проблемою для всіх розробників IAAC. У цьому дописі ми дізнаємося про керування дрейфом конфігурації, його важливість, причини та можливі рішення.
Що таке дрейф конфігурації?
Власники додатків повинні з часом змінювати свої додатки та базову інфраструктуру, щоб постійно покращувати взаємодію з клієнтами. Ці клієнти можуть бути внутрішніми або зовнішніми щодо компанії.
Конфігурація програм та інфраструктура змінюється в результаті цих оновлень і змін. Ці модифікації можуть бути корисними або погіршити міцність системи. Зміщення конфігурації – це термін для цього.
Як працює дрейф конфігурації
Потенціал дрейфу конфігурації зростає зі складністю систем виробництва та доставки програмного забезпечення. Код, як правило, передається з робочої станції розробника в спільне середовище розробки, у середовища тестування та контролю якості, а згодом – у проміжне та робоче середовища.
Потенційний вплив зростає залежно від того, наскільки далеко вздовж трубопроводу відбувається дрейф. Навіть незначні відмінності між версією пакета, встановленою на ноутбуці розробника, і версією, встановленою на тестовому сервері, можуть затримати усунення проблеми. Як правило, очікується, що лише постановка та постановка будуть копіями одне одного. Напруга є великою, оскільки багато компаній розгортають новий код багато разів на день.
Поширені причини відхилення конфігурації
Відсутність спілкування
Іноді командам, які займаються видобутком, не вдається повідомити партнерам про внесені ними зміни, що, як наслідок, ламає всю систему виведення з ладу.
Виправлення
Виправлення — це зміни коду, внесені для вирішення критичної проблеми, яка не може чекати до наступного запланованого оновлення програми. Іноді інженери, які працюють над вирішенням проблеми, не можуть внести зміни або задокументувати те саме виправлення в інших середовищах у конвеєрі, що, як наслідок, призводить до дрейфу. Часто повторне введення початкової проблеми вирішить цей дрейф.
Критичні оновлення пакетів
Критичні оновлення пакетів чимось схожі на виправлення. Обидва виконуються у швидкому темпі. Основна відмінність полягає в тому, що критичні оновлення пакетів застосовуються в надії уникнути майбутніх інцидентів. Таким чином, такі оновлення можуть викликати дрейф так само, як і виправлення.
Відсутність автоматизації
Автоматизація повністю не усуне ймовірність дрейфу конфігурації. Це лише зменшить його шанси.
Зміни зручності
Іноді зміни, внесені розробниками, є тимчасовими. Наприклад, дрейф виникає, якщо розробник встановлює новий пакет на тестовому сервері, щоб перевірити деякі функції, і забуває повернути його до початкового стану.
Чому керування конфігурацією важливе?
Однією з причин, чому дрейф конфігурації може бути настільки шкідливим, є те, що якщо його ніхто постійно не шукає, дрейф може залишитися невиявленим, оскільки він поступово підриває основу вашої інфраструктури, подібно до невеликого витоку в будинку за стіною.
Коли виявлено дрейф конфігурації, пошук основної причини дрейфу конфігурації, яка спричинила все це, потребує часу, який є цінним ресурсом у надзвичайних ситуаціях.
У розробці програмного забезпечення дрейф є важливою причиною повільних циклів випуску. Це може спричинити непотрібну роботу та знизити продуктивність розробника.
Менші витрати
Ви можете зменшити загальну необхідну суму, визначивши дублювання або надмірне надання, коли у вас є детальне зображення вашої ІТ-інфраструктури.
Вища продуктивність
Кластери зі стабільними та добре відомими конфігураціями дозволяють пакетне керування та побудову інфраструктури. Крім того, вимога до керування окремими параметрами вручну зменшується завдяки обмеженню унікальних (або сніжинок) серверів.
Швидше налагодження
Послідовні конфігурації дозволяють командам з налагодження виключати помилки конфігурації. Команди можуть зосередитися на інших потенційних причинах, швидше вирішуючи запити, оскільки їм не доведеться шукати розбіжності конфігурації між серверами, кластерами серверів або середовищами.
Проблеми, спричинені дрейфом конфігурації
Питання безпеки
Незахищені конфігурації є однією з найпоширеніших причин порушень безпеки. Зміщення конфігурації може збільшити ймовірність інших атак і зламу мережі, навіть якщо ви починаєте із захищеної конфігурації.
Час простою
Значні простої можуть бути наслідком помилки конфігурації, яка дозволяє зловмиснику використати недолік DoS або скомпрометувати важливий сервер. Але це ще не все. Припустімо, ви змінюєте конфігурацію мережевого пристрою, що впливає на продуктивність. Ви завжди можете повернутися до своєї «золотої конфігурації», правда? Відновлення служби займе набагато більше часу, якщо ця конфігурація має недоліки.
Випадання з комплаєнсу
Для дотримання таких нормативних актів, як ISO 27001, PCI-DSS і HIPAA, необхідний жорсткий контроль безпеки. Зміщення конфігурації може призвести до порушення відповідності, якщо його не зупинити.
Знижена продуктивність
Конфігурація зазвичай перебуває в найоптимальнішому стані, коли вона перебуває в призначеному стані. Спеціальні модифікації можуть перешкоджати спробам оптимізації мережі, спричиняючи вузькі місця та конфлікти.
Витрачений час
Усунення несправностей мережі, яку ви погано розумієте або не відповідає документації вашої мережі, може зайняти багато часу. Це означає, що дрейф конфігурації може призвести до проблем з усуненням неполадок ІТ, яких могло б не існувати або які було б легше вирішити, якби мережа була в належному стані, на додаток до простою для користувачів.
Поширені помилки, на які слід звернути увагу під час моніторингу дрейфу конфігурації
В ідеальному світі всі сервери середовища для розробників (Dev/QA/Staging/Prod) мали б однакові конфігурації. На жаль, у «реальному» світі все відбувається не так. У комерційних умовах власники програм часто змінюють інфраструктуру, коли в програмне забезпечення вводяться нові можливості.
Відстеження дрейфу конфігурації має вирішальне значення для того, щоб програмне середовище було максимально однорідним. Налаштування керування зменшує витрати, підвищує продуктивність і час налагодження, а також покращує взаємодію з користувачем.
Щоб досягти максимального успіху в моніторингу, організації повинні уникати помилок, навіть якщо вони використовують керування конфігурацією та відстежують дрейф своєї конфігурації.
Нижче наведено типові помилки.
Не підтримується CMDB
Підтримка бази даних керування конфігурацією (CMDB) в актуальному стані є важливим елементом керування конфігурацією. Інформацію про встановлення обладнання та програмного забезпечення мережі можна переглянути в одному місці, наданому базою даних керування конфігурацією. Дані збираються для кожного активу або елемента конфігурації, забезпечуючи видимість і прозорість на робочому місці.
Відмова підтримувати CMDB наражає підприємства на небезпеку не повністю зрозуміти, як конфігурація одного елемента впливає на інший елемент. Організації ризикують завдати шкоди своїй інфраструктурі та безпеці, не розуміючи наслідків.
Адмініструвати CMDB може бути складно, особливо коли кількість активів зростає, але ефективна організація бази даних і керування є вирішальними для успішного відстеження зміни конфігурації та розуміння інфраструктури.
Відсутність плану моніторингу дрейфу конфігурації
Організації часто мають масивну, складну інфраструктуру, за якою потрібно стежити. Важливо визначити, які компоненти потребують найбільшого моніторингу. Інакше керування конфігурацією може швидко стати некерованим і хаотичним.
Організації повинні вказати, які активи є важливими для моніторингу компанії та конкретних бізнес-підрозділів. Переглядатимуться найважливіші системи, які відрізнятимуться від підрозділу до підрозділу та галузі до галузі.
Автоматичний моніторинг не здійснюється
Організації можуть відстежувати зміну конфігурації кількома способами. Однак деякі підходи є більш витонченими та успішними, ніж інші.
Ручний моніторинг дрейфу конфігурації є дорогим і тривалим. Ручний моніторинг також виявляє ймовірність людської помилки. Це не найкращий метод моніторингу дрейфу конфігурації, якщо ваша компанія не займає дуже мало інфраструктури.
Автоматичний моніторинг є найбільш розвиненим і ефективним способом підтримки конфігурацій у потрібному стані. Спеціалізовані системи моніторингу конфігурації можуть миттєво виявляти дрейф і часто пропонують рішення, включаючи швидке виправлення. Це гарантує повернення інфраструктури бізнесу до бажаного стану якомога швидше та з мінімальними наслідками.
Як контролювати дрейф конфігурації:
Стає очевидним, чому виявлення дрейфу конфігурації має бути головною проблемою, коли ви усвідомлюєте шкоду, яку це може завдати. Першим кроком у цьому процесі є знання того, що потрібно зберегти і чому це було представлено як зміну, яка спричинила дрейф.
Знайте, що ви шукаєте
Ви можете сортувати свою організацію, визначивши компоненти, важливі для організації в цілому, і ключові для кожного підрозділу.
Це залежить від підрозділу та може бути розширеним у суворо регульованих галузях або зосереджуватись виключно на вузьких критично важливих для системи файлах/додатках. Важливість системи визначатиме частоту та серйозність систем моніторингу.
Встановіть базову лінію
Завжди будуть відмінності між виробничим середовищем і етапами тестування через різні налаштування. Базова лінія для перевірки дрейфу створюється шляхом визначення того, яким повинен бути кожен крок і типів допустимих відхилень.
Ранні етапи тестування можуть бути більш придатними для вищого дозволу на дрейф, ніж налаштування приймального тестування користувача або етап виробництва з нульовим дрейфом.
Контролюйте свою систему
Рівень необхідного моніторингу змінюватиметься залежно від зрілості організації, її поточних систем, інструментів, загальної кількості конфігурацій, які необхідно перевірити, і необхідного рівня перевірки. Залежно від вимог і відповідності моніторинг може відрізнятися для кожного підрозділу в організації.
Як запобігти дрейфу конфігурації
Моніторинг повинен гарантувати, що інфраструктура підтримується у відповідній конфігурації після визначення базової конфігурації та допустимих прогалин. Без стратегії моніторингу побудова планів конфігурації та документації витрачає час.
Для моніторингу дрейфу конфігурації можна використовувати різні підходи, і багато компаній поєднуватимуть методології та інструменти на основі своєї зрілості та вимог до відповідності.
Постійний ручний моніторинг
Окремі конфігурації машини можна переглянути вручну та порівняти з відомим файлом конфігурації. Через людський аспект цей процес все ще схильний до помилок і дорогий щодо робочого часу співробітників. Мене слід використовувати лише в невеликих масштабах для кількох конкретних кластерів серверів або компанії зі скромною інфраструктурою.
аудити
Команда вручну перевіряє конфігурації сервера в рамках аудиту конфігурації, порівнюючи їх із зазначеною моделлю. Ці аудити можуть бути дорогими, оскільки вони вимагають спеціальних знань, щоб визначити, як слід будувати систему, а потім ретельного дослідження будь-яких незадокументованих шансів, щоб вирішити, чи варто її зберігати.
Група аудиту також вносить необхідні корективи в документи конфігурації, які будуть застосовані під час наступного аудиту. Аудити, як правило, проводяться для кластерів із високою вартістю або відповідністю вимогам і регулярно виконуються, як правило, кілька разів на рік, з огляду на час і витрати.
Аудит гарантує послідовну та повторювану конфігурацію сервера за заздалегідь визначеним розкладом.
Однак до наступного аудиту налаштування будуть дрейфувати і залишатися все більше і більше.
Автоматизований моніторинг у реальному часі
Автоматизований моніторинг у режимі реального часу є найдосконалішим способом підтримувати конфігурації в бажаному стані. Для цього потрібно створити сервери або групи серверів разом із описом того, як їх слід налаштувати за допомогою спеціальних інструментів налаштування сервера.
Ці програми використовуватимуть легкий агент для моніторингу конфігурації сервера в цій групі та порівняння її з його визначенням.
Цей автоматизований процес миттєво попереджає про дрейф і зазвичай надає кілька варіантів виправлення дрейфу сервера.
Заключні слова:
Неузгоджені елементи конфігурації (CI) між комп’ютерами або пристроями є основною причиною дрейфу конфігурації. Зміни конфігурації відбуваються природно в середовищах центрів обробки даних, коли модифікації програмного та апаратного забезпечення здійснюються на ходу без ретельного документування чи відстеження.
Багато збоїв системи високої доступності та аварійного відновлення пояснюються дрейфом конфігурації. Адміністратори повинні вести ретельний облік мережевих адрес апаратних пристроїв, а також версії програмного забезпечення, встановленого на них, і зроблені оновлення, щоб мінімізувати дрейф конфігурації.