Kuidas viia tehisintellektiga tehtud prototüüp tootmiskeskkonda

Prototüübi viimiseks tootmiskeskkonda suleta lõhe "töötab, kui ma seda proovin" ja "töötab edasi, kui teised seda kasutavad" vahel. Praktikas tähendab see viit asja: testi põhivoogusid iga muudatuse järel, lukusta ära, kes mida näha ja muuta saab, veendu, et kuuled vigadest enne kui kasutajad, varunda andmed ja tõesta, et oskad need taastada, ning hoia rakendus telefonis piisavalt kiire. Mitte miski sellest ei nõua ümberkirjutamist — see on kontrollnimekiri, mida läbid koos sama tehisintellektiga, mis prototüübi tegi.

Prototüüp vs tootmine: mis tegelikult muutub

Prototüübil on üks hoolikas kasutaja: sina. Sa tead, millistele nuppudele vajutada, sisestad mõistlikke andmeid ja kui midagi katkeb, ajad õlgu ja palud tehisintellektil parandada. Tootmises on palju hooletuid kasutajaid, mõned uudishimulikud ja aeg-ajalt ka vaenulik. Kood ei pea muutuma "ettevõttelikuks"; ta peab toime tulema olukordadega, mida prototüüp kunagi ei kohta.

Ülejäänud juhend käib läbi iga rea.

Samm 1: Lukusta ulatus ja kirjuta üles põhivood

Enne kui midagi kõvendad, otsusta, mis on esimene versioon. Loetle kolm kuni kuus voogu, mis on kõige olulisemad — näiteks "registreeru, loo projekt, kutsu kaasatöötaja, maksa". Need saavad su testskriptiks, jälgimise sihtmärkideks ja asjadeks, mida kontrollid pärast igat muudatust.

Kõik, mis nimekirjas ei ole, kas lõigatakse välja või märgitakse selgelt beetana. Neli töökindlat voogu on palju lihtsam teha kui neliteist.

Samm 2: Testi nagu võõras, seejärel tee korratavaks

Tehisintellekti loojad on head koodi tootma, mis töötab õnnelikul teel. Tootmisprobleemid elavad ebaõnnestunud teedel. Testi iga põhivoogu järgmisega:

• Halb sisend: tühjad kohustuslikud väljad, 5000-märgiline nimi, e-post ilma @-märgita, negatiivne kogus, minevikukuupäev.
• Värskendused ja tagasinupud: laadi kassa keskel uuesti; vajuta pärast vormi saatmist tagasi. Kas midagi luuakse kaks korda?
• Kaks vahelehte, kaks kasutajat: logi sisse kahe erineva kontoga ja proovi avada teise lehti, muutes URL-is ID-d.
• Aeglane ja väike: telefoniekraan ja piiratud ühendus (brauseri arendustööriistad saavad seda simuleerida).
• Tühjad olekud: täiesti uus konto ilma andmeteta. Prototüübid on sageli tehtud näidisandmetega ja näevad ilma nendeta katkised välja.

Seejärel tee kontroll korratavaks. Vähemalt hoia kirjalikku kontrollnimekirja ja käivita see enne iga väljalasset. Veelgi parem, palu tehisintellektil kirjutada automatiseeritud testid olulistele voogudele:

Lisa automatiseeritud otsast-lõpuni testid nendele voogudele: registreerimine e-postiga, projekti loomine, teise kasutaja kutsumine ja makse lõpetamine Stripe'i testrežiimis. Lisa ka testid, mis kinnitavad, et kasutaja ei saa vaadata ega muuta teise kasutaja projekti URL-i muutmise teel.

Testid, mis tõestavad, et kasutaja ei saa midagi teha, on need, mida prototüüpidel kõige sagedamini puudub.

Samm 3: Turvalisuse põhitõed, mida prototüübid vahele jätavad

Enamik turvaprobleeme tehisintellektiga tehtud rakendustes ei ole eksootilised. Need on puuduvad kontrollid. Käi see loend läbi ja vaata täielikumat turvakontrollnimekirja tehisintellektiga tehtud rakendustele:

• Volituskontroll serveris. Nupu peitmine ei ole turvalisus. Iga päring, mis andmeid loeb või muudab, peab serveris kontrollima, et sisse logitud kasutajal on selleks õigus. Kui su rakendus kasutab andmebaasi reeglitega ridade kaupa, kontrolli, et need on sisse lülitatud ja testitud.
• Saladused brauserist välja. Makse-, e-posti- või tehisintellektiteenuste pakkujate API-võtmed kuuluvad serveri keskkonnamuutujatesse, mitte esikülje koodi. Kui sa ei tea, mida see tähendab, loe mis on keskkonnamuutujad ja saladused.
• Valideerimine serveris. Brauseri saab mööda minna, seega korda igat olulist kontrolli serveris.
• Õige sisselogimine. Kasuta hästi testitud autentimisteeki või -teenust, mitte käsitsi tehtud parooliladustust. Meie juhend sisselogimise lisamisest oma rakendusse käsitleb valikuid.
• Päringupiirangud sisselogimisel, registreerimisel, parooli lähtestamisel ja kõigel, mis saadab e-kirju või kutsub tasulist API-d.
• Sõbralikud veateated. Kasutajad peaksid nägema "midagi läks valesti"; üksikasjad lähevad sinu logidesse, mitte ekraanile.
• Vaheta välja kõik, mis lekkis. Kui päris võti on kunagi kleebitud vestlusesse, commit'i või ekraanipildile, asenda see teenusepakkuja juures.

Prompt, mis katab korraga palju:

Vaata see rakendus üle tootmisturvalisuse seisukohast. Kontrolli, et iga API-marsruut kinnitab, et sisse logitud kasutaja omab kirjet, mida ta loeb või muudab, et ükski salavõti ei saadeta brauserisse, et sisendid valideeritakse serveris ning et sisselogimine ja parooli lähtestamine on päringupiiranguga. Loetle, mida leiad, enne kui midagi muudad.

Nimekirja esmalt küsimine annab sulle võimaluse näha probleeme ja otsustada järjekorra üle, selle asemel et saada üks suur muudatus.

Samm 4: Tea, millal see katkeb — logimine ja jälgimine

Eelvaates näed vigu nende tekkides. Tootmises peab rakendus sulle ise ütlema. Kolm kihti, odavamast kõige kasulikumani:

1. Serverilogid. Veendu, et vead logitakse piisava kontekstiga, et neid saaks taasesitada: milline marsruut, milline kasutaja ID (mitte parool ega kaardiandmed), millise kujuga sisend. Kui rakendus prindib ainult konsooli, palu tehisintellektil lisada struktureeritud logimine.
2. Veajälgimine. Teenus nagu Sentry või sarnane tööriist püüab esi- ja tagaosa erandid, grupeerib need ja saadab sulle e-kirja. Väikese rakenduse puhul piisavad nende teenuste tasuta paketid tihti; kehtivaid limiite vaata nende lehtedelt.
3. Töökindluse kontrollid. Väline teenus, mis laadib su avalehe ja ühe olulise API-marsruudi iga paari minuti järel ning hoiatab, kui need ebaõnnestuvad. See püüab kinni probleemid, mis takistavad rakendusel üldse logimist.

Lisa veel üks harjumus: pärast iga väljalasset ava elav rakendus ja käivita põhivoogude kontrollnimekiri päris URL-il, mitte ainult eelvaates.

Samm 5: Varundused ja tee tagasi

Kaks erinevat asja vajavad kaitset ja neid on lihtne segamini ajada.

• Kood. Hoia projekt versioonihalduses, et iga muudatus saaks tagasi võtta. Paljud tehisintellekti loojad hoiavad failidest kontrollpunkte; sünkroonimine Giti hoidlaga annab sulle koopia ka väljaspool loojat.
• Andmed. Koodi tagasikerimine ei too andmebaasi tagasi. Halb migratsioon või vigane kustutamisnupp võib hävitada read, mida ükski koodi kontrollpunkt ei too tagasi.

Andmete jaoks seadista korrapärased varundused, mis hoitakse mujal kui rakenduse enda hostingus. Postgresi andmebaasi puhul on levinud viis ajastatud pg_dump eraldi salvestusse, ja paljud hallatud andmebaasi hostid pakuvad automaatseid varundusi või ajapunktipõhist taastamist. Seejärel tee samm, mida enamik inimesi vahele jätab: taasta varundus eraldi testandmebaasi ja kontrolli, et andmed on olemas.

Palu tehisintellektil teha ka hävitavad toimingud ohutumaks: kustutamisel kinnitussamm ning "pehme kustutamine" (ridade märkimine kustutatuks selle asemel, et need eemaldada) kõige jaoks, mida kasutajad võivad tahta tagasi.

Samm 6: Jõudlus, mis peab vastu telefonis

Prototüübid tunduvad kiired, sest sina oled ainus kasutaja ja andmehulk on väike. Enne käivitamist:

• Laadi päris suurusega andmed. Palu tehisintellektil lisada paar tuhat rida ja vaata, millised lehed aeglustuvad. Loendid vajavad tavaliselt lehekülgedeks jagamist ning andmebaas vajab indekseid veergudele, mida filtreerid ja sorteerid.
• Vähenda pilte. Liiga suured pildid on kõige sagedasem põhjus, miks leht laeb aeglaselt. Palu muudetud suuruses ja tihendatud pilte ning lazy loading'ut nähtava ala alt.
• Mõõda. Käivita Chrome'i arendustööriistades Lighthouse elaval URL-il mobiilirežiimis. Google'i Core Web Vitals on mõistlik sihtmärk: Largest Contentful Paint alla 2,5 sekundi, Interaction to Next Paint 200 ms või vähem ja Cumulative Layout Shift 0,1 või vähem.
• Jälgi "äratamise" viivitusi. Hosting, mis magab tühikäigul, säästab raha, kuid muudab esimese külastuse pärast vaikset perioodi aeglasemaks. Uue rakenduse puhul on see sageli mõistlik kompromiss; tea, et see toimub.

Projektide leht on 5000 reaga aeglane. Lisa serveripoolne lehekülgedeks jagamine (25 lehe kohta), lisa andmebaasi indeksid veergudele, mida filtreerime ja sorteerime, ning näita laadimisolekut järgmise lehe laadimise ajal.

Samm 7: Operatiivsed põhitõed

Mõned väikesed asjad eristavad hobirakendust rakendusest, mida inimesed usaldavad:

• Kohandatud domeen HTTPS-iga. Vaata kuidas ühendada kohandatud domeen.
• Transaktsiooniline e-post kinnitatud domeenilt registreerimise kinnituste ja parooli lähtestamise jaoks — käsitletud juhendis kuidas saata e-kirju oma rakendusest.
• Privaatsuspoliitika ja tingimused, mis kirjeldavad, mida sa tegelikult kogud. Ära kopeeri vastavusväiteid, mida pole teeninud.
• Toetuskanal — isegi jälgitav e-posti aadress.
• Eraldi testvõtmed ja päris võtmed maksete ja e-posti jaoks ning selge märge, milline keskkond kasutab mida.

Samm 8: Puhas üleandmine

Varem või hiljem töötab rakenduse kallal keegi teine: vabakutseline, uus kaasasutaja või sina kuue kuu pärast. Tee see lihtsaks:

• README, mis ütleb, kuidas rakendust käivitada, milliseid keskkonnamuutujaid see vajab (ainult nimed, mitte kunagi väärtused) ja kuidas seda välja rakendada.
• Põhivoogude kontrollnimekiri ja automatiseeritud testid.
• Lühike arhitektuurimärkus: esikülg, tagaosa, andmebaas, kolmanda osapoole teenused ja kus iga üks hostitakse.
• Juurdepääsunimekiri: kellel on administraatoriõigused domeenile, hostingule, andmebaasile, makse- ja e-postikontodele. Pane need kontod pigem ettevõtte e-posti, mitte isikliku aadressi alla.
• Kood Gitis, eelistatavalt sünkroonituna sinu enda omatava hoidlaga. Kui võid hostingut hiljem vahetada, loe kuidas eksportida ja ise hostida tehisintellektiga ehitatud rakendust.

Tehisintellekt saab selle suure osa sinu eest koostada:

Kirjuta selle projekti README arendajale, kes pole seda kunagi näinud: mis rakendus teeb, tehnoloogiapinu, kuidas seda kohapeal käivitada, iga keskkonnamuutuja, mida see loeb (ainult nimed ja otstarve), kuidas andmebaasi skeem on korraldatud ja kuidas seda välja rakendada.

Tootmisvalmiduse kontrollnimekiri

• Põhivoogud kirja pandud ja testitud, sh "ei pääse ligi teise inimese andmetele"
• Volituskontroll ja valideerimine serveris igal andmemarsruudil
• Ükski salavõti esikoodis; lekkinud võtmed vahetatud
• Päringupiirangud autentimisel ja kõigel, mis maksab raha
• Veajälgimine ja töökindluse hoiatused suunatud postkasti, mida loed
• Andmebaasi varundused väljaspool rakenduse hostingut, üks edukas testtaastamine tehtud
• Lehekülgedeks jagamine ja indeksid kontrollitud realistlike andmetega
• Kohandatud domeen, kinnitatud saatmisdomeen, privaatsuspoliitika
• README ja juurdepääsunimekiri järgmisele inimesele

Tegemine Mythexiga

Kui prototüübi tegid Mythexis, on enamik neist sammudest prompte samas projektis. Kirjuta /test ja Mythex klõpsab läbi elava eelvaate nagu kasutaja ning teatab katkistest voogudest — vaata rakenduse testimine. Võtmed lähevad projekti saladustesse, mitte vestlusse; iga õnnestunud agendi käik salvestab failidest kontrollpunkti, millele saad tagasi pöörduda, ja avaldamine annab elava URL-i hostingu ja andmebaasiga, mis arvestatakse samast krediidisaldost (hostingu limiidid selgitab, kuidas rakendused ja andmebaasid magavad ja ärkavad). Kontrollpunktid katavad faile, mitte andmebaasi ridu, seega planeeri ikka andmete varundused. Pro-plaanil saad ühendada kohandatud domeeni ning eksportida koodi või sünkroonida selle oma GitHubi hoidlasse üleandmiseks.

Küsimused