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