Excerpt:<\/strong> Blog \u010dlanak:<\/strong><\/p>\n\n\n\n Production rollback system je sigurnosni mehanizam za situacije kada nova promena u produkciji napravi problem. To mo\u017ee biti update plugina, nova verzija teme, izmena koda, promena konfiguracije, migracija baze ili deploy koji nije pro\u0161ao kako je o\u010dekivano.<\/p>\n\n\n\n Rollback nije isto \u0161to i improvizovano vra\u0107anje fajlova. U ozbiljnom sistemu mora se znati \u0161ta se vra\u0107a, odakle se vra\u0107a, koliko je backup star i koje podatke mo\u017ee prepisati. Bez tog razumevanja rollback mo\u017ee re\u0161iti jedan problem, ali napraviti drugi.<\/p>\n\n\n\n Kod CMS sajtova rollback \u010desto uklju\u010duje vra\u0107anje prethodne verzije plugina, teme ili jezgra sistema. Ako je problem nastao posle update-a, najbr\u017ei put do stabilizacije mo\u017ee biti povratak na prethodnu proverenu verziju.<\/p>\n\n\n\n Kod custom aplikacija rollback se obi\u010dno vezuje za deploy proces. Pre objave nove verzije korisno je imati prethodnu verziju koda spremnu za brzo vra\u0107anje. To mo\u017ee biti kroz Git, release foldere, Docker image tagove ili hosting snapshot.<\/p>\n\n\n\n Baza podataka je najosetljiviji deo rollback-a. Fajlovi se \u010desto mogu vratiti relativno jednostavno, ali baza se tokom rada menja kroz porud\u017ebine, korisni\u010dke unose, forme, komentare i transakcije. Zato vra\u0107anje baze mora biti posebno pa\u017eljivo.<\/p>\n\n\n\n Kod e-commerce sajtova puni rollback baze mo\u017ee obrisati nove porud\u017ebine ako se ne uradi pravilno. U takvim slu\u010dajevima nekada je bolje vratiti samo kod ili konfiguraciju, a bazu ostaviti netaknutom, uz dodatnu korekciju problemati\u010dnih zapisa ako je potrebno.<\/p>\n\n\n\n Dobar rollback sistem po\u010dinje pre incidenta. Pre ve\u0107ih promena treba napraviti backup, zabele\u017eiti verzije, proveriti \u0161ta se menja i imati plan vra\u0107anja. Ako se plan pravi tek kada je sajt ve\u0107 oboren, rizik je mnogo ve\u0107i.<\/p>\n\n\n\n Va\u017eno je razlikovati rollback od trajnog re\u0161enja. Rollback vra\u0107a sistem u stabilno stanje, ali ne obja\u0161njava uvek za\u0161to je nova verzija napravila problem. Posle stabilizacije treba analizirati uzrok i pripremiti sigurniji na\u010din za ponovni poku\u0161aj.<\/p>\n\n\n\n Rollback proces treba testirati povremeno. Backup koji nikada nije vra\u0107en, snapshot koji nije proveren ili deploy strategija koja postoji samo u teoriji nisu dovoljno pouzdani za hitne situacije.<\/p>\n\n\n\n Production rollback systems daju produkcionom radu sigurnosnu mre\u017eu. Kada postoji jasan na\u010din da se sistem brzo vrati na stabilnu verziju, tehni\u010dke promene se mogu raditi sigurnije, a incidenti se re\u0161avaju sa manje stresa i manjim rizikom za poslovanje.<\/p>\n","protected":false},"excerpt":{"rendered":" Production rollback systems omogu\u0107avaju brzo vra\u0107anje sajta ili aplikacije na prethodno stabilno stanje nakon gre\u0161ke, neuspe\u0161nog update-a ili lo\u0161e deploy promene. Dobar rollback proces […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17,18],"tags":[],"class_list":["post-311","post","type-post","status-publish","format-standard","hentry","category-recovery-optimization","category-website-recovery"],"yoast_head":"\n
Production rollback systems omogu\u0107avaju brzo vra\u0107anje sajta ili aplikacije na prethodno stabilno stanje nakon gre\u0161ke, neuspe\u0161nog update-a ili lo\u0161e deploy promene. Dobar rollback proces smanjuje downtime, \u010duva podatke i omogu\u0107ava kontrolisanu reakciju bez panike.<\/p>\n\n\n\n