Configuration drift — ishlayotgan tizim konfiguratsiyasi tasdiqlangan desired state yoki bir xil guruhdagi boshqa instansiyalardan vaqt o‘tishi bilan farqlanib ketishidir. Manual hotfix, package update, console’dagi edit, environment variable yoki provision script xatosi drift yaratishi mumkin. Natijada “bir xil” serverlar turlicha ishlaydi va incidentni qayta tiklash qiyinlashadi.
Drift manbalari
Operator favqulodda muammoni production hostda tuzatib, o‘zgarishni repositoryga qaytarmasligi mumkin. Vendor agent avtomatik file qo‘shadi. Cloud service default qiymatni platform update’da o‘zgartiradi. Secret rotation eski instancega yetmaydi. Autoscaling eski image’dan node yaratishi mumkin.
Drift faqat file diff emas. IAM policy, firewall, database parameter, feature flag, certificate, scheduled job va runtime package holati ham configurationdir. Mutable serverda vaqt bilan farq ko‘payadi; immutable image modelida drift kamayadi, ammo external control plane va mounted configuration baribir o‘zgarishi mumkin.
Oqibatlar
Bitta instansiya debug mode’da qolib ma’lumot ochishi, boshqa biri eski TLS policy ishlatishi mumkin. Load balancer trafikni turli behaviorli node’ga yuborib intermittent xato yaratadi. Failover replica uzoq vaqt ishlamagan configuration bilan primary bo‘lsa incident kuchayadi.
Compliance audit snapshotda to‘g‘ri ko‘ringan setting keyin o‘zgarishi mumkin. Drift detection uzluksiz bo‘lmasa evidence faqat tekshiruv paytiga tegishli. Security baseline va application behavior birga nazorat qilinadi.
Aniqlash
Infrastructure as code desired state’ni versiyalangan manbada saqlaydi. Agent yoki API runtime state’ni yig‘ib, semantic diff qiladi. File tartibi yoki generated timestamp kabi ahamiyatsiz farq normalizatsiya qilinadi. Muhim permission va policy alohida severity oladi.
Golden image hash asosiy paketni, software inventory esa runtime qo‘shimchani ko‘rsatadi. Kubernetes admission desired policyga zid resource’ni yaratishdan oldin rad etishi mumkin. External scan enforcement’dan tashqaridan real port va TLS holatini tekshiradi.
Tuzatish
Auto-remediation driftni repository holatiga qaytaradi, ammo har o‘zgarishni darhol overwrite qilish production incidentda zararli bo‘lishi mumkin. Critical security setting uchun tez enforcement, stateful database parameter uchun approval va maintenance window tanlanadi. Blast radius canary bilan cheklanadi.
Favqulodda manual change taqiqlanmaydi, lekin ticket, owner va expiry bilan break-glass jarayoniga kiradi. O‘zgarish foydali bo‘lsa desired state’ga commit qilinadi; aks holda rollback qilinadi. Host muntazam patch bilan juda o‘zgargan bo‘lsa qayta provision qilish qo‘lda tuzatishdan ishonchliroq.
Oldini olish
Immutable deployment, minimal console access va GitOps drift ehtimolini kamaytiradi. Configuration schema type va range’ni tekshiradi. Secret, feature flag va infrastructure o‘zgarishi bir xil audit timeline’da bog‘lanadi. Owner va environment metadata noma’lum resursni kamaytiradi.
Metrikalar drift soni bilan birga ochiq qolgan vaqt, takroriy sabab va auto-remediation muvaffaqiyatini ko‘rsatadi. Ko‘p drift bitta pipeline bypassidan chiqsa har resursni alohida yopish o‘rniga process root cause tuzatiladi.
Tiklash va oldini olish
Drift topilganda joriy holatni ko‘r-ko‘rona kerakli holatga qaytarishdan oldin farqning sababi tekshiriladi. Favqulodda hodisada muhandis ataylab o‘zgartirish kiritgan bo‘lishi mumkin; uni darhol avtomatik bekor qilish xizmatni yana buzadi. Tasdiqlangan o‘zgarish deklarativ manbaga qayta yoziladi, ruxsatsiz o‘zgarish esa xavfsiz holatga qaytariladi. Immutable infrastructure yondashuvida ishlayotgan serverni tahrirlash o‘rniga tuzatilgan obrazdan yangi nusxa yaratiladi. Shu usul tarixni aniq saqlaydi, biroq ma’lumot va maxfiy sirlar tashqi boshqarilishi zarur. Drift signallari ko‘pligi uchun muhim xavfsizlik sozlamalari oddiy kosmetik farqlardan yuqori ustuvorlik oladi.
Bog‘liq tushunchalar
Desired state, Infrastructure as Code, GitOps, Immutable infrastructure, Secure configuration, Compliance, Configuration management