Rollback — muvaffaqiyatsiz yoki zararli o‘zgarishdan keyin tizimni avvalgi ma’lum ishlaydigan versiya yoki holatga qaytarish jarayonidir. U application artifact, konfiguratsiya, feature flag, infratuzilma va ma’lumotlar bazasi uchun turlicha bajariladi. “Oldingi kodni qo‘yish” barcha qatlamni avtomatik tiklamaydi.
Artifact rollback
Build once yondashuvida oldingi container digest yoki binary registryda saqlanadi va qayta deploy qilinadi. Source commitdan yangidan build qilish dependency yoki build environment o‘zgargani sabab ayni byte ni bermasligi mumkin. Imzolangan artifact va provenance qaysi nusxa ilgari tekshirilganini ko‘rsatadi.
Konfiguratsiya ham versiyalangan bo‘ladi. Eski kod yangi config schema bilan ishlamasligi mumkin. Release manifest image, config, chart va feature flag kombinatsiyasini bir birlik sifatida qayd etsa, qaytish aniqroq bajariladi.
Database muammosi
Schema migration rollbackning eng murakkab qismidir. Ustun o‘chirilgan yoki data yangi formatga qayta yozilgan bo‘lsa eski binary uchun zarur ma’lumot yo‘qolishi mumkin. Down migration har doim xavfsiz emas; katta jadvalda lock va yana data loss keltirishi ehtimol.
Expand–contract usuli avval backward-compatible qo‘shimcha kiritadi. Kod eski va yangi schema bilan ishlaydi, keyingi release da eski maydon olib tashlanadi. Destructive qadamdan oldin restore testi o‘tgan backup yoki snapshot saqlanadi. Restore vaqti RTOga mos baholanadi.
Feature flag orqali qaytish
Yangi funksiya flag ortida bo‘lsa, foydalanuvchi ta’sirini kodni qayta deploy qilmasdan to‘xtatish mumkin. Bu tez kill switch beradi. Biroq background migration, yangi message producer yoki startup side effect flagdan tashqarida ishlashi mumkin.
Flag defaulti, cache va client offline holati hisobga olinadi. Mobile client eski flag qiymatini saqlab qolishi mumkin. Flag o‘chirilganda yangi formatda yaratilgan data eski flow tomonidan to‘g‘ri qayta ishlanishi tekshiriladi.
Trigger va qaror
Rollback triggeri error rate, latency, data integrity, security signal yoki muhim business metric bo‘lishi mumkin. Threshold va observation window rolloutdan oldin belgilanadi. Faqat foydalanuvchi shikoyatini kutish detectionni kechiktiradi.
Ba’zan forward fix rollbackdan xavfsizroq: eski versiya ham zaif, yangi data bilan mos emas yoki qaytish uzoq davom etadi. Incident commander mavjud dalil, tiklash vaqti va blast radiusga qarab tanlaydi. Qaror auditda saqlanadi.
Operatsion jarayon
Runbook kerakli buyruq, authority, trafik drain, health check va kommunikatsiyani ko‘rsatadi. Rollback muntazam mashq qilinmasa, credential, eski artifact yoki script ayni paytda ishlamasligi mumkin. Game day qaytarish vaqtini o‘lchaydi.
Qaytishdan keyin incident yakunlanmaydi. Data reconciliation, queue backlog, cache va tashqi side effect tekshiriladi. Root cause tuzatiladi, oldingi yomon release qayta tasodifan promote qilinmasligi uchun bloklanadi.
Rollback chegarasi
Rollback qarori uchun aniq trigger va vakolat egasi belgilanadi. Error budgetning tez sarflanishi, muhim transactionning buzilishi yoki data corruption signali avtomatik to‘xtatish mezoni bo‘lishi mumkin. Faqat o‘rtacha CPU yoki umumiy health checkga qarash yashirin funksional nosozlikni o‘tkazib yuboradi. Orqaga qaytish mashqi staging bilan cheklanmay, productionga o‘xshash data hajmi va dependency sharoitida vaqt-vaqti bilan sinovdan o‘tkaziladi; natijada tiklanish vaqti taxmin emas, o‘lchangan qiymat bo‘ladi.
Mashq davomida credential, artifact va operator vakolati ham tekshiriladi.
Bog‘liq tushunchalar
Rollout, Deployment, Backup, Database migration, Feature flag, RTO, Incident response