3 kūrėjo dienoraštis: slapta problema, kuri tyliai sugriovė mūsų duomenų bazę

Viena valanda nakties. Mano telefonas pradeda išprotėti.

Aš dejuoju ir pasižiūriu. Žinoma, tai dar vienas „PagerDuty“ skambutis. Šią savaitę budiu ir jau trečią kartą per tiek dienų buvau pažadintas dėl tos pačios priežasties.

Šimtai mūsų klientų tris dienas iš eilės vieningai skundėsi, kad iš mūsų įsigijo bilietus į renginį ir atvyko į renginio vietą tik pamatę, kad jų bilietai jau išpirkti. Jiems neleidžiama įvažiuoti, ir tai suprantama labai piktas.

Pradinis tyrimas parodė labai keistą elgesį.

Klientai buvo nusipirkę bilietus, o po kelių minučių jų bilietai buvo išpirkti. Tai buvo gerokai anksčiau už patį įvykį, todėl buvo aiškiai netikėta. Ir tai nebuvo tolygiai paskirstyta mūsų klientų bazėje; šis klausimas buvo labai sutelktas į kai kurias atrinktas universitetų studentų grupes.

Jau žinojome, kad turime esminę problemą su mūsų išpirkimo sistema; buvo galima patiems nuskenuoti QR kodą bilietų užsakymo patvirtinimo el. laiške, kaip tai darytų durų darbuotojai renginio vietoje, kuri išpirktų bilietą. Deja, iki didesnio pataisymo dar liko kelios savaitės.

Nepaisant to, kodėl daug klientų iš konkrečių universitetų išpirktų arba netyčia išpirktų savo bilietus prieš renginį?!

Nė viena iš mūsų ankstyvųjų teorijų neturėjo prasmės, o problema tęsėsi.

Mes ėjome kasti. Galiausiai radome problemą.

The automatizuotas virusų skaitytuvas konkrečiame universitete .edu pašto sistemos paspaudė visas nuorodas mūsų patvirtinimo el. laiškuose, kad patikrintų, ar juose nėra virusų, įskaitant programiškai nuskaito visus QR kodus.

Todėl šis vienas procesas, visiškai nematomas mano komandai, buvo automatiškai mūsų klientų bilietų į renginį išpirkimas klientas net negavo el.

Niekada, niekada neatnaujinkite nuolatinių duomenų įkeliant puslapį.

Tai reiškė, kad bilieto QR kodas pateko į tinklalapį, kuriame iškart išperkamas bilietas įkeliant puslapį bet ką apsilankę šioje nuorodoje, nesvarbu, ar žmogus, ar mašina, netyčia atnaujintume mūsų duomenų bazę, kad bilietas būtų pažymėtas kaip išpirktas.

Mūsų svetainėse yra tūkstančiai nematytų automatizuotų lankytojų, apie kuriuos dažniausiai negalvojame. Štai keletas pavyzdžių:

• Naršyklės iš anksto gauna išteklius. Tai didelis. Tarkime, lankotės https://myblog.comir tame puslapyje yra žinomos nuorodos į/blog-post-1 ir /blog-post-2 . Labai tikėtina, kad jūsų naršyklė jau iš anksto pateiks tuos puslapius fone. Jei tų puslapių duomenys keičiasi įkeliant puslapį, pavyzdžiui, norint stebėti apsilankymus, tiesiog būdamas pagrindiniame puslapyje pakanka, kad jį suaktyvintumėte, net jei niekada nespustelėsite nuorodų.

• Google tikrintuvai. Dar vienas didelis. Neseniai pastebėjome daugybę klaidų, kurias sukėlė „Google“ tikrinimo programos, kurios lankėsi puslapiuose ir suaktyvino neautentifikuotus API iškvietimus.

• El. pašto skaitytuvai. Labai paplitusi mokyklose, vyriausybėse, didelėse korporacijose ir kt.

• Interneto archyvavimo mašinos

Paprasta pamoka – kiek įmanoma vengti dalykų, kurie vyksta automatiškai įkeliant puslapį. Be problemų, su kuriomis susidūrėme, tokie netikėti šalutiniai poveikiai yra blogas UX. Jei veiksmas yra „Išpirkti“, padarykite tai spustelėję mygtuką „Išpirkti“.

Tikiuosi, kad tai buvo naudinga – užsiprenumeruokite dabar, kad mano kūrėjo dienoraštis būtų gautųjų dėžutėje!