Agar interviewda "yangi qayta yozilgan APIni qanday qilib xavfsiz tarzda release qilish mumkin?" deb so‘rab qolsa nima deb javob berishni bilasizmi?

Dasturchi sifatida biror ishlab turgan narsani qaysidir sababga ko‘ra qayta yozishga majbur bo‘lamiz. Buni to‘g‘ri qilish esa oson ish emas.

- Balki boshqa tilda qayta yozayotgandirmiz

- Balki texnik qarzdan qutulish maqsadida qayta yozayotgandirmiz

- Balki yaxshiroq algoritm o‘ylab topganimiz uchun qayta yozayotgandirmiz

Sabablari ko‘p bo‘lishi mumkin. 

Lekin yangi kod bu har doim xavf. Ishlab turgan narsani yangi varianti bilan almashtiraman deb qandaydir yangi buglarni foydalanuvchilarga taqdim qilishimiz hech gap emas. Test qilamiz, ha. Lekin productionda, haqiqiy foydalanuvchilar bilan har balo bo‘lishi mumkin. 

Shuning uchun ham yangi yozilgan kod haqiqatda eskisini o‘rnini to‘g‘ri bosa olish-olmasligini bilishning eng zo‘r usuli bu productionda test qilish.

Lekin qanday qilib?

Traffic shadowing yoki traffic mirroring deb ataladigan usul mavjud. 

Unga ko‘ra bizga birorta request kelganda birinchi o‘rinda eski usul yordamida javobini foydalanuvchiga qaytaramiz. Lekin qaytarishimizdan oldin asinxron tarzda yangi usulga ham xuddi shu requestni yuborib qo‘yamiz. Nega asinxron? Foydalanuvchi kutilgandan ko‘proq kutib qolmasligi uchun.

Endi bizda 2 ta javob bor. Biri eski usulda olingan, narigisi esa yangi usulda olingan. Nima qilamiz? Solishtiramiz. Bir xil yoki boshqachaligi haqida xabar beramiz (metrics yuborish orqali).

Agar yetarlicha vaqt davomida yangi variantimiz eskisini bilan bir xil (va bir xil yoki yaxshiroq tezlikda) javob bera olsa, demak uni ommaga taqdim etishimiz mumkin. Havfsiz tarzda. Chunki u juda yaxshi test qilingan. Haqiqiy production trafficda.

Misol uchun, Amazon o‘zining IAM servisining asosida turadigan kutubxonani almashtirganda shu usuldan foydalangan. Ma’lumot uchun IAM sekundiga 1 milliarddan ortiq requestlarni qabul qila oladi. Bu raqam haqida yaxshilab o‘ylab ko‘ring!

@jakhonrakhmonov