# Sukūriau produktą su AI — kaip jį tobulinti nesugadinant to, kas veikia > Saugi produkto priežiūra po paleidimo: git, grąžinimas į ankstesnę versiją, staging, slaptų duomenų apsauga, priegloba, atsarginės kopijos ir priežiūra. Išsaugoti visi šeši raginimai. Source: https://ailoot.ai/blog/lt/ai-product-maintenance-after-launch/ Canonical: https://ailoot.ai/blog/lt/ai-product-maintenance-after-launch/ Language: lt Publisher: Ailoot (https://ailoot.ai/) Translation: guide-033 Revision: sha256-e1fddaf2f21ca35c31752acb27b0f4e89153e639628d0cc6c4a8b98f4acab2ac Daugiau apie darbą su modeliais sužinosite [Ailoot dokumentacijoje](https://ailoot.ai/docs/). ## Kodėl brangiausi darbai prasideda po paleidimo?
Svarbiausia Produkto kūrimas su AI yra mažesnioji darbo dalis. Iš kiekvieno dolerio, investuoto į AI plėtrą, tik 18 centų virsta užbaigtu produktu, o 44 centai skiriami pačios AI sukurtoms klaidoms taisyti. Visa tai vyksta po paleidimo. Daugiausia pinigų ir nervų kainuoja priežiūra, o ne kūrimas.
Per vieną vakarą sukūrėte programėlę, paskelbėte nuorodą ir nusiuntėte ją draugams. Ji veikia. Po savaitės pasirodo pirmasis tikras žmogus, netinkamai ką nors paspaudžia, ir pusė funkcijų nustoja veikti. Paprašote Claude tai pataisyti — jis pataiso vieną dalyką ir sugadina kitą. Pažįstama? Ir čia kyla pagrindinis klausimas: ką daryti paleidus produktą, kai jau praėjo pirmojo veikiančio prototipo euforija, o jį vis tiek reikia kažkaip prižiūrėti? Tai galima pavadinti vibe coding suaugusiesiems. Kūrimas teikia jaudulį ir vyksta greitai. Priežiūrai reikia šalto proto: suprantate, ką keičiate, ir išlaikote tai kontroliuojama. Dauguma žmonių šioje antroje dalyje patiria nesėkmę, nes niekas jų tam neparuošia. Vienas pramonės tyrimas išanalizavo daugiau nei milijoną kodo pakeitimų iš 2 444 komandų ir apskaičiavo, kur iš tikrųjų keliauja AI plėtrai išleidžiami pinigai. Štai vaizdas: | Kur keliauja doleris | Suma | Ką tai reiškia praktiškai | |----|----|----| | Pateko į produktą | **18 centų** | Funkcijos, kurios iš tikrųjų veikė naudotojams | | AI klaidų taisymas | 44 centai | AI jau parašyto kodo taisymas, kad jis nesugriūtų | | Perdarymas | 27 centai | AI sukurto kodo, neatitikusio užduoties, perrašymas | | Peržiūra | 11 centų | Kodo aiškinimasis ir klaidų paieška | Vadove [„Paslėpta vibe coding kaina“](https://ailoot.ai/blog/lt/vibe-coding-cost-time/) šie skaičiai paaiškinti išsamiau. Ten klausėme, už ką mokate. Čia klausimas kitas: 44 centai iš kiekvieno dolerio skiriami klaidoms taisyti — ir visas šis straipsnis apie tai, kaip neleisti šiai daliai didėti. Darbas, kuriuo ją kontroliuojate, vadinamas priežiūra. Skirtumas tarp žmogaus, kuris taiko vibe coding suaugusiesiems, ir žmogaus, kuris tik prižiūri neuroninį tinklą, išryškėja po paleidimo. Pirmojo kodo bazė auga, jis ją tobulina, o niekas nesugenda. Po mėnesio antrojo produktas tampa kiauru aparatu, kurį baisu liesti. Toliau paaiškinsiu, kaip patekti į pirmąją grupę. ## Kas iš tikrųjų sugenda: 5 nelaimės po paleidimo
Svarbiausia AI sukurti produktai sugenda dėl to paties trumpo sąrašo priežasčių: nuteka raktai ir duomenų bazės, AI ištrina produkcinę aplinką, o klientams pinigus nuskaito nepažįstami žmonės. Kiekvienos nelaimės galima išvengti vienu veiksmu.
Tai viešos tikrų AI sukurtų produktų incidentų analizės, kuriose pateikiami skaičiai ir datos. Įsivaizduokite jas kaip minų lauko žemėlapį — kiekviena mina jau sprogo kažkam kitam, o būdas jos išvengti žinomas. | Kas nutiko | Kaip tiksliai | Kas būtų tam užkirtę kelią | |----|----|----| | **Nutekėjo 1,5 milijono raktų** | Viešas duomenų bazės raktas buvo tiesiai puslapio kode, o prieiga prie duomenų bazės buvo atvira be slaptažodžio | Įjungti eilučių lygmens saugą (RLS) kiekvienoje lentelėje | | **Atskleista 170 programėlių** | Programėlės jungėsi prie duomenų bazės tiesiai iš naršyklės naudodamos viešą raktą, be nustatytų prieigos taisyklių | Prieš parduodant patikrinti duomenų bazės prieigos teises ir nepasitikėti numatytaisiais nustatymais | | **AI ištrynė produkcinę duomenų bazę** | Agentui buvo suteikta prieiga prie produkcinės duomenų bazės, ir jis ją ištrynė nepaisydamas draudimo | Fiziškai izoliuoti produkcinę duomenų bazę nuo agento aplinkos | | **Mokėjimų raktai naršyklėje: \$87,500** | Mokėjimo sistemos raktai atsidūrė puslapio kode; jie buvo rasti ir iš 175 klientų nuskaičiuoti pinigai | Laikyti paslaptis tik serveryje, niekada naršyklėje | | **Atskleista 72 000 nuotraukų ir dokumentų** | Failų saugykla neturėjo slaptažodžio, todėl kiekvienas, turintis nuorodą, galėjo atsisiųsti asmenukes ir tapatybės dokumentus | Pagal numatytuosius nustatymus reikalauti autentifikacijos norint pasiekti failų saugyklą | Visų penkių atvejų pagrindinė priežastis ta pati. Pagal numatytuosius nustatymus AI pasirūpina, kad viskas veiktų dabar, o ne saugiai po mėnesio esant apkrovai. Kurdami savo kompiuteryje skirtumo nepastebėsite. Jis išryškėja pasirodžius pirmajam nepažįstamam žmogui, turinčiam blogų ketinimų. Problema ne ta, kad kodas nerašomas rankomis — taip dirba daug žmonių. Problema ta, kad niekas nepaklausia: „Ar duomenų bazė apsaugota?“ Toliau parodysiu raginimą, kuris užduos šį klausimą už jus. ## Pirmasis apsauginis tinklas yra git ir grįžimas prie to, „kaip buvo vakar“
Svarbiausia Pagrindinis apsauginis tinklas po paleidimo — galimybė atšaukti bet kokį pakeitimą. Kartu veikia du sluoksniai: git kaip nuolatinė projekto istorija ir vietinės Claude Code momentinės kopijos, skirtos greitai „atšaukti paskutinį veiksmą“. Prieš leisdami produktą naudoti kitiems, būtinai turėkite privatų saugyklos projektą ir paslapčių failą ignoruojamų failų sąraše.
Kai Claude ką nors sugadina, reikia mygtuko „grąžinti taip, kaip buvo vakar“. Techniškai tas mygtukas vadinamas git ir yra paprastesnis, nei skamba. Trys terminai, kuriuos turi suprasti ne programuotojas: 1. **Saugykla** — projekto aplankas, išsaugotas debesyje (paprastai „GitHub“). Viso jūsų kodo kopija, kuri yra ne vien jūsų kompiuteryje. 2. **Commit** — grįžimo taškas. Iš esmės kodui sakote: „išsaugok tokią būseną“. Kiekvienas commit yra žymeklis, prie kurio galite grįžti. 3. **Deploy** — perkėlimas. Kodas buvo vietinis, jūsų kompiuteryje, ir veikė tik jums. Deploy nusiunčia jį į išorinį serverį, kad jis veiktų visiems. Jei turite naujausių commit taškų, bet kokį gedimą galite atšaukti vienu sakiniu. Tiesiogine prasme.
Raginimas: Grįžk prie veikiančios versijos ``` Kažką sugadinau — vakar viskas veikė, o šiandien nebeveikia. Rask naujausią commit, kuriame viskas buvo gerai, parodyk, kas pasikeitė nuo tada, ir grąžink projektą į tą būseną. ```
Dvi taisyklės, kurias reikia įdiegti iškart, dar prieš kitiems pamatant produktą: - **Saugykla turi būti privati.** Ne vieša. Kitaip bet kas galės perskaityti jūsų kodą ir visa, kas jame yra. - **Paslapčių failą įtraukite į ignoruojamų failų sąrašą.** Raktai, slaptažodžiai ir duomenų bazės prieigos duomenys laikomi atskirame faile (paprastai `.env`), ir tas failas niekada nepatenka į saugyklą. Į `.gitignore` įtraukite eilutę su `.env`, ir paslaptys liks pas jus. Atskiras vadovas paaiškina, kaip saugiai atšaukti pakeitimus Claude Code: [Kaip atšaukti Claude Code pakeitimus](https://ailoot.ai/blog/lt/claude-code-undo-changes/). Neturėdami grįžimo taškų, einate įtemptu lynu be apsauginio tinklo ir anksčiau ar vėliau nukrisite. ## Ką `/rewind` atšaukia, o ko neatšaukia?
Svarbiausia Claude Code turi komandą `/rewind` — prieš kiekvieną redagavimą ji sukuria momentinę kopiją ir grąžina kodą bei pokalbį į pasirinktą tašką. Tačiau ji atšaukia tik failus, kuriuos pakeitė pats Claude. Ji neliečia įdiegtų paketų, į debesį įkeltų failų, duomenų bazės pakeitimų ar išorinių paslaugų iškvietimų. Git yra nuolatinė istorija, o `/rewind` — greitas vietinis „anuliavimas“.
Claude Code sukuria būsenos momentinę kopiją prieš kiekvieną savo atliekamą pakeitimą. Komanda `/rewind` (arba dukart paspaustas Esc) grąžina failus ir pokalbį į pasirinktą tašką. Tai patogu: jei prieš penkias minutes sugadinote funkciją, galite grįžti penkiomis minutėmis atgal. Tačiau yra spąstai, dėl kurių pradedantieji praranda duomenis. `/rewind` neatšaukia visko: | Ką `/rewind` atšaukia | Ko jis NEATŠAUKIA | |--------------------------------------|-------------------------------------| | Claude atliktus failų pakeitimus | Paketų įdiegimo (`npm install`) | | Šios sesijos pokalbį | Kodo įkėlimo į debesį (`git push`) | | Vietinę projekto būseną | Duomenų bazės pakeitimų | | \- | Išorinių paslaugų iškvietimų ir mokėjimų | Pati „Anthropic“ tai nusako aiškiai: momentinės kopijos yra vietinis mygtukas „anuliuoti“, o git — nuolatinė istorija. Momentinės kopijos papildo versijų valdymą, bet jo nepakeičia.

Momentinės kopijos yra vietinis „anuliavimas“, o Git — nuolatinė istorija. Momentinės kopijos papildo išsamų versijų valdymą, bet jo nepakeičia.

— Claude Code dokumentacija, https://code.claude.com/docs/en/checkpointing
Praktinė išvada ne programuotojui: `/rewind` išgelbės jus nuo situacijos „Claude ką tik sugadino funkciją“. Tačiau jei jis spėjo ištrinti duomenų bazės eilutę ar įkelti kodą į debesį, ją atkurti gali tik git ir duomenų bazės atsarginė kopija. Todėl turėkite abu sluoksnius: momentines kopijas greitam atšaukimui, o commit — nuolatinei projekto istorijai. ## Kaip tobulinti produktą nesugadinant to, kas jau veikia?
Svarbiausia Pagrindinis pavojus tobulinant produktą — loginis nukrypimas: paprašote AI ką nors pataisyti, o ji tyliai pakeičia gretimą logiką, nes vibe coding nėra deterministinis. Apsaugos taisyklė — auksinė taisyklė: neįdiekite kodo, kurio negalite paaiškinti kitam žmogui. Darykite mažus pakeitimus, kiekvieną įrašykite commit ir visada tiksliai peržiūrėkite, kas pasikeitė.
Kas antras žmogus įstringa šiame cikle. Paprašote AI pataisyti nedidelę klaidą. Ji pasiūlo pagrįstą pakeitimą. Tas pakeitimas sugadina ką nors kita. Paprašote pataisyti naują problemą, ir atsiranda dar dvi. Ir taip toliau. Šis ciklas atsiranda todėl, kad vibe coding nėra deterministinis. Tas pats raginimas dukart pateikia skirtingą kodą. Todėl kiekvienas redagavimas gali tyliai pakeisti aplinkinę logiką: nuolaidos riba pasikeičia nuo 10 iki 12 procentų arba kitaip ima veikti tikrinimo taisyklė — jums nieko netikrinant ir negavus nė vieno įspėjimo. Tai vadinama loginiu nukrypimu, ir jis tyliai kenkia būtent tam, kas atneša pinigus: kainoms, prieigai ir mokėjimams. Yra viena taisyklė, padedanti apsisaugoti nuo nukrypimų, ir ji tokia paprasta, kad galite pasikabinti ant sienos: neįrašykite commit kodo, kurio negalėtumėte žodis į žodį paaiškinti kitam žmogui. Praktiškai tai tampa paruoštu šablonu, kurį galite naudoti prieš bet kokį veikiančio kodo pakeitimą. Jis skatina AI žengti mažais žingsniais ir tiksliai parodyti, kas pasikeitė.
Raginimas: Suplanuok saugų pakeitimą ``` Prieš keisdamas kodą, atlik šiuos veiksmus: Išsaugok dabartinę veikiančią būseną kaip atskirą grįžimo tašką (commit). Žodžiais tiksliai aprašyk, ką ketini keisti ir kuriuose failuose. Atlik kuo mažesnį pakeitimą — tik tai, kas išsprendžia mano užduotį, nieko daugiau. Parodyk, kas pasikeitė, ir paaiškink kiekvieną pakeitimą taip, kad galėčiau jį paaiškinti kitam žmogui. Neliesk kainodaros, prieigos ar mokėjimų logikos, nebent to paprašyčiau. ```
Dar vienas principas, sutaupantis savaites, — drausmingai laikytis užduoties ribų. Viena problema, vienas pakeitimas, greitas įgyvendinimas. Neprašykite AI vienu raginimu perrašyti pusės projekto. Profesionalūs kūrėjai kartais pradeda kurti visą „Uber“, nors jiems reikėjo tik vieno mygtuko, ir tempia tai mėnesiais. Jums to nereikia. Viskas, ką aprašiau, remiasi vienu dalyku: konteksto valdymu. Kad AI nesugadintų gretimos logikos, ji turi prisiminti jūsų projekto taisykles. ## Kaip patikrinti pakeitimą prieš jį paskelbiant?
Svarbiausia Prieš pateikdami pakeitimą tikriems naudotojams, išbandykite pagrindinius scenarijus: mokėjimą, registraciją, prieigą ir kainas. Geriausias būdas galutinai patikrinti — naudoti bandomąją produkcinės aplinkos kopiją (kūrėjų įrankiuose vadinamą staging). Eiga tokia: kurkite kūrimo aplinkoje, tikrinkite bandomojoje kopijoje, diekite į produkciją. Kiekvienas leidimas kelia riziką; bandomoji kopija ją pašalina.
Tarp „veikia mano kompiuteryje“ ir „veikia visiems“ yra tarpinis žingsnis, kurį pradedantieji praleidžia: bandomoji kopija. Tai atskira jūsų produkcinės aplinkos kopija, kurioje patikrinate pakeitimą prieš jį pamatant tikriems žmonėms. Darbo ciklas atrodo taip: 1. Sukurkite pakeitimą ir patys jį patikrinkite (kūrimo aplinka). 2. Įdiekite jį į staging — produkcijos kopiją be tikrų naudotojų. 3. Atlikite pagrindinius scenarijus ir įsitikinkite, kad niekas nepasikeitė. 4. Tik tada įdiekite į produkciją. Kodėl tai svarbu po paleidimo: kiekvienas leidimas kelia riziką. Nedidelis kodo pakeitimas gali sutrikdyti prisijungimą prie paskyros. Vienas trūkstamas nustatymas gali sustabdyti visą produktą. Staging aptinka šias problemas be pasekmių; produkcijoje prarandate klientus. Kad nereikėtų kaskart visko tikrinti rankiniu būdu, pateikite AI raginimą palyginti naujos versijos veikimą su ankstesnės versijos veikimu kritinėse srityse.
Raginimas: Regresijos patikra prieš leidimą ``` Ketinu įdiegti pakeitimą. Iš eilės pereik pagrindinius produkto scenarijus ir patikrink, ar kiekvienas jų vis dar veikia kaip anksčiau: Naujo naudotojo registracija ir prisijungimas. Mokėjimas ir prieigos suteikimas po mokėjimo. Prieigos teisės — įprastas naudotojas negali matyti kito asmens duomenų ar administravimo srities. Pagrindinės verslo logikos reikšmės (kainos, nuolaidos, limitai) nepasikeitė. Jei kas nors veikia kitaip nei ankstesnėje versijoje, sustok ir tiksliai parodyk, kas pasikeitė. ```
## Kur yra jūsų paslaptys? Didžiausia pradedančiųjų spraga
Svarbiausia Dažniausia ir brangiausia klaida po paleidimo — paslaptys puslapio kode. Duomenų bazės, mokėjimo sistemos ir išorinių paslaugų raktai turi būti tik serveryje, aplinkos kintamuosiuose, ir niekada ne naršyklėje. Dėl šios spragos jau nutekėjo 1,5 milijono vieno produkto raktų, o vieno įkūrėjo klientams buvo nuskaičiuota \$87,500.
Didžiausią miną paaiškinsiu išsamiai, nes ji sužlugdo daugiau produktų nei bet kuri kita. Kai AI rašo kodą, paprasčiausia įdėti raktą ten, kur jis iškart veiks — tiesiai į puslapio, atidaromo naršyklėje, kodą. Kurdami skirtumo nepastebėsite. Tačiau kiekvienas gali perskaityti viską, kas pasiekia naršyklę, atidaręs kūrėjo įrankius. Įkūrėjas, kurio klientams buvo nuskaičiuota \$87,500, vėliau pasakė, kad to būtų užtekę išvengti vieno raginimo. Mokesčiai galiausiai buvo panaikinti, tačiau negrąžinami mokesčiai ir prarasta ramybė liko. Štai tas raginimas.
Raginimas: Patikrink, kur saugomos mano paslaptys ``` Patikrink visą projektą ir įsitikink, kad joks slaptasis raktas nepatenka į naršyklę: Rask visus duomenų bazės, mokėjimo sistemos ir išorinių paslaugų raktus. Įsitikink, kad kiekvienas jų saugomas tik serveryje, aplinkos kintamuosiuose, o ne puslapio kode. Patikrink projekto istoriją — ar anksčiau koks nors raktas netyčia nepateko į ją? Parodyk visas vietas, kuriose radai paslapčių, ir nurodyk, ką reikia padaryti kiekvienu atveju. ```
Kita netoliese esanti mina — prieigos teisių tikrinimas tik naršyklės pusėje. Jei produktas puslapio kode nusprendžia, ar „rodyti administravimo sritį“, bet kas gali šį sprendimą apeiti. Prieigos teisės visada turi būti tikrinamos serveryje. Duomenų bazė turi grąžinti duomenis tik tiems, kurie turi teisę juos gauti — tam skirta eilučių lygmens sauga (RLS), kurią reikia įjungti kiekvienoje lentelėje. Prieš parduodami prieigą ar įsileisdami kitus žmones, atlikite bendrą produkto saugumo auditą.
Raginimas: Patikrink projekto saugumą po paleidimo ``` Peržiūrėk projektą kaip užpuolikas ir rask saugumo spragas: Ar kokie nors slapti raktai saugomi kode, kuris siunčiamas į naršyklę, arba projekto istorijoje? Ar eilučių lygmens sauga (RLS) įjungta kiekvienoje duomenų bazės lentelėje, ir ar prieigos teisės tikrinamos serveryje, o ne vien naršyklėje? Ar sukonfigūruota automatinė duomenų bazės atsarginė kopija ir ar kada nors tikrinau, ar galiu ją atkurti? Ar produkcinė duomenų bazė izoliuota nuo aplinkos, kurioje veikia AI agentas? Kiekvieno punkto atveju pasakyk, ar viskas gerai, arba ką konkrečiai reikia pataisyti. ```
Atskiras išsamus vadovas skirtas vibe coding saugumui: [Kaip apsaugoti vibe coding būdu sukurtą programėlę](https://ailoot.ai/blog/lt/vibe-coding-security/). Taisyklė paprasta: laikykite viską, ką AI padarė pagal numatytuosius nustatymus, nesaugiu, kol nepatikrinote kitaip. ## Kur talpinti produktą: prieglobos pakopos
Svarbiausia Kur laikomas produktas, priklauso nuo to, kas juo naudojasi. Nemokama priegloba tinka bandymams ir mažiems projektams be asmens duomenų. Produktui su duomenų baze ir tikrais naudotojais rinkitės platformą, kurioje galima įdiegti viena komanda. Nuosavas serveris yra kitas žingsnis, kai apkrova didelė. Nepradėkite nuo sudėtingo sprendimo.
Nereikia iškart nuomotis nuosavo serverio ir konfigūruoti jo rankiniu būdu — pradžioje tai sudėtinga užduotis, kuri atims daug laiko. Produktui augant, galite kilti šiomis pakopomis: 1. **Nemokama priegloba** (pavyzdžiui, „Vercel“) — sau, bandymams ir mažiems projektams. Ji tinka, jei platforma prieinama jūsų auditorijai ir nesaugote žmonių asmens duomenų. 2. **Platforma, kurioje galima įdiegti viena komanda** („Railway“) — kai turite backend ir duomenų bazę. Diegiate viena komanda ir nereikia konfigūruoti serverio. Pradėti labai paprasta. 3. **Nuosavas dedikuotas serveris** — kai apkrova didelė ir reikia visiškos kontrolės. Pereikite prie jo vėliau, kai pasieksite platformos ribą. Ne programuotojui, kuris ką tik paleido produktą, paprasčiausia rinktis platformą, kurioje galima įdiegti viena komanda, be rankinio serverio konfigūravimo. Prie nuosavo serverio pereikite vėliau. Jei norite šį kelią išbandyti su konkrečiu pavyzdžiu, skaitykite vadovą, kaip [vibe coding būdu sukurtą projektą įdiegti nuosavame serveryje naudojant Coolify](https://ailoot.ai/blog/lt/coolify-claude-code-deploy/). ## Kada atskirti programėlę, duomenų bazę ir atsargines kopijas?
Svarbiausia Kol produktas mažas, programėlė ir duomenų bazė veikia tame pačiame kompiuteryje. Jas laikas atskirti, kai didžiausios apkrovos metu naudojimas nuolat viršija 70–80 procentų arba duomenų bazė ir programėlė pradeda viena kitą lėtinti. Atsarginėms kopijoms taikoma taisyklė 3-2-1: trys kopijos, dviejų tipų laikmenose, viena laikoma kitoje vietoje. Kopijos turi būti kuriamos automatiškai, o ne „kai prisimenu“.
Trijų dalykų nereikėtų laikyti viename krepšyje: programėlės, duomenų bazės ir atsarginių kopijų. Kol naudotojų nedaug, viskas yra kartu, ir tai gerai. Tačiau yra aiškus ženklas, rodantis, kada jas metas atskirti. - **Laikykite programėlę ir duomenų bazę skirtinguose kompiuteriuose.** Ženklas: didžiausios apkrovos metu CPU ir atminties naudojimas nuolat viršija 70–80 procentų, užklausos lėtėja, o programėlė ir duomenų bazė konkuruoja dėl tų pačių išteklių. Atskyrę jas galėsite stiprinti duomenų bazę neliesdami programėlės ir atvirkščiai. - **Laikykitės atsarginių kopijų taisyklės 3-2-1.** Trys duomenų kopijos dviejų skirtingų tipų laikmenose, viena laikoma kitoje vietoje. Tai apsaugo nuo aparatinės įrangos gedimo ir išpirkos reikalaujančių virusų. Svarbiausia, kad kopijos būtų daromos automatiškai. Atsarginių kopijų dažnumas priklauso nuo to, kiek kainuotų prarasti kelių valandų duomenis. Internetinei prenumeratos paslaugai, kurioje nepriimtina prarasti valandos mokėjimų įrašus, atsarginių kopijų intervalas turi būti trumpesnis nei valanda arba reikia patikrintų operacijų žurnalų ir atkūrimo į konkretų laiko tašką (PITR). Intervalą rinkitės pagal didžiausią toleruojamą duomenų praradimą, o paslaugos atkūrimo trukmę išbandykite atskirai. Tinklaraščiui pakanka vienos per dieną. Logika paprasta: nuspręskite, kiek duomenų galite sau leisti prarasti, ir atitinkamai sukonfigūruokite kopijų kūrimą.
Raginimas: Ar metas pereiti prie atskirų serverių? ``` Padėk man nuspręsti, ar mano produktui metas pereiti prie rimtesnės infrastruktūros. Patikrink kiekvieną punktą ir apie jį manęs paklausk: Kokia CPU ir atminties apkrova didžiausio piko metu — ar naudojimas nuolat viršija 70–80 procentų, ar ne? Ar duomenų bazė ir programėlė veikia tame pačiame kompiuteryje, ar skirtinguose? Ar sukonfigūruota automatinė duomenų bazės atsarginė kopija ir ar išbandžiau jos atkūrimą? Ar yra atskira aplinkos kopija (staging), skirta patikrai prieš diegimą? Remdamasis rezultatais, pateik aiškią rekomendaciją: ką palikti kaip yra, ką pirmiausia atskirti ir kodėl. ```
Yra ir atskiras klausimas: valdoma duomenų bazė ar nuosava. Mažai komandai valdoma duomenų bazė beveik visada geresnis pasirinkimas: nuosava pigesnė aparatinės įrangos požiūriu, bet priežiūrai sunaudoja daug valandų. Jei dirbate vieni, o jūsų produktas nėra infrastruktūra, tos valandos kainuoja daugiau nei serverio kainų skirtumas. ## Kaip automatizuoti priežiūrą?
Svarbiausia Priežiūra nebūtinai turi būti rankinė. Du stebėjimo įrankiai atlieka pagrindinį darbą: vienas tikrina, ar svetainė pasiekiama, kitas aptinka produkto klaidas. Taip pat galite nustatyti AI agentą, kuris ryte atliktų apėjimą — perskaitytų naudotojų pranešimus, rastų, kas sugedo, ir pateiktų paruoštą pritaikyti pataisymą. Tačiau laiškus ir masines operacijas reikia vykdyti porcijomis, o ne vienu kartu visoje duomenų bazėje.
Rankinė priežiūra vargina. Galite ją perleisti dviem būdais: stebėjimo įrankiais ir patruliuojančiu agentu. Stebėjimui naudojami du skirtingi įrankiai dviem skirtingoms užduotims: 1. **„Ar svetainė veikia?“** — pasiekiamumo stebėjimo įrankis (pavyzdžiui, UptimeRobot). Jis kas kelias minutes tikrina produktą ir siunčia įspėjimą, jei svetainė neveikia. Yra nemokamas planas. 2. **„Kas tiksliai sugedo?“** — klaidų stebėjimo įrankis (pavyzdžiui, Sentry). Jis renka programėlės klaidas ir parodo, kur ir kodėl kas nors nepavyko. Pirmasis aptinka, kad produktas nustojo veikti. Antrasis parodo, kuri funkcija neveikia ir kodėl. Kartu jie atsako į klausimą: „Ar apie gedimą sužinosiu anksčiau, nei klientas parašys palaikymo tarnybai?“ Antrasis automatizavimo lygis — patruliuojantis agentas. Įsivaizduokite nekilnojamojo turto agentūrą: septintą ryto AI agentas perskaito svetainės užklausas, pastebi, kad rezervacijos forma neveikia, randa priežastį kode ir pateikia paruoštą pataisymą su paaiškinimu. Jūs jį peržiūrite ir sakote „taip“ — jis įdiegiamas. Eiliškumas svarbus: pirmiausia išspręskite naudotojo problemą (suteikite prieigą, atsiprašykite), tada aiškinkitės priežastį ir pinigų klausimus.
Dėmesio Nevykdykite masinių operacijų iškart visoje duomenų bazėje. Vienu metu išsiųskite el. laišką visiems, ir serveris bus perkrautas, o pusė laiškų pateks į šlamštą. Tinkamas būdas — siųsti porcijomis: 100–1 000 per dieną, išdėstant per dienos valandas. Tai taikoma bet kokiai klientų duomenų bazei: parduotuvės, klinikos ar paslaugos.
Dar viena taisyklė dėl AI prieigos prie produkcinės duomenų bazės: suteikite jai tik skaitymo teises turinčią paskyrą, o asmens duomenis paslėpkite tarpininkavimo sluoksniu, kad agentas matytų „vardas“, o ne tikrą žmogaus vardą. Tada, net jei suklys, jis fiziškai negalės ištrinti ar sugadinti produkcinių duomenų. Incidentas iš lentelės aukščiau, kuriame agentas išvalė produkcinę duomenų bazę, yra būtent apie tokio apribojimo nebuvimą. Vadove [Ką daryti, jei AI ištrynė jūsų duomenų bazę](https://ailoot.ai/blog/lt/ai-deleted-database-recovery/) paaiškinama, ką daryti, jei nelaimė jau įvyko. ## Kada metas uždaryti produktą?
Svarbiausia Ne kiekvieną produktą verta prižiūrėti; kai kuriuos reikia uždaryti. Duokite idėjai dvi savaites gyvybingumui įrodyti, o griežta riba — trys mėnesiai. Jei ji neįsibėgėjo, uždarykite produktą, kad ir kaip gailėtumėte į jį investuotų pastangų. Produktą pražudo ne blogas kodas, o tai, kad žmonės nustoja juo naudotis. Kiekvienas turi nebaigtų projektų kapines — tai normalu.
Labiausiai neįvertinta priežiūros dalis — žinojimas, kada ją nutraukti. Kiekvienas, daug kuriantis, turi projektų kapines: vieną sukūrė, šiek tiek padirbėjo, paskui paliko. Tai normalu ir nėra nesėkmė. Nesėkmė — mėnesiais vilkti tai, ko niekas nenaudoja, vien dėl to, kad gaila sugaišto laiko. Sprendimui priimti galite naudoti šias ribas: 1. **Dvi savaitės** — pakanka pamatyti, ar idėja veikia. Jei pirmieji tikri naudotojai sugrįžta, tęskite. Tyla irgi yra atsakymas. 2. **Trys mėnesiai** — griežta riba. Jei produktas per tris mėnesius neįsibėgėjo, uždarykite jį. Vibe coding greičiu šešis mėnesius bandyti vieną idėją yra per ilgai. Uždaryti projektą psichologiškai sunku, todėl laikykite tai sprendimu, o ne jausmu. Atsisakyti projekto, į kurį investavote, panašu į darbuotojo, negalinčio atlikti darbo, atleidimą: nemalonu, bet jo išlaikymas kainuoja daugiau nei atsisveikinimas. Priežiūra — tai darbas, atliekamas tam, kad produktas išliktų gyvas ir naudingas žmonėms. Visa kita — git, atsarginės kopijos, stebėjimas — tėra įrankiai, padedantys pasiekti tašką, kai produktas ima jums tarnauti kiekvieną dieną.
### Šaltiniai - [Anthropic - Kontroliniai taškai Claude Code](https://code.claude.com/docs/en/checkpointing) - [Anthropic - Claude Code saugumo modelis](https://code.claude.com/docs/en/security)
Sukurti produktą su AI per vieną vakarą — pusė darbo. Išlaikyti jį veikiantį ir saugų, kai jis auga — štai ką reiškia vibe coding suaugusiesiems. Kitas žingsnis — [Ailoot](https://ailoot.ai/). ## Klausimai ir atsakymai ### Kaip dažnai kurti paslaugos su mokėjimais atsargines kopijas? Intervalą rinkitės pagal didžiausią toleruojamą duomenų praradimą. Jei nepriimtina prarasti valandą, naudokite dažnesnes nei kasvalandines kopijas arba patikrintą operacijų žurnalo ir PITR sąranką; taip pat išbandykite tikrą atkūrimo trukmę. ### Ar veikimo laiko stebėsenos pakanka produkto būklei patikrinti? Ne. Ji rodo, ar svetainė atsako, o klaidų sekimo įrankis nustato gedimus programos viduje. Svarbias naudotojų eigas prieš išleidimą patikrinkite parengiamojoje aplinkoje ir įsitikinkite, kad atsarginę kopiją galima atkurti. ## Ailoot · Įmonė ir jos projektų portfelis Ailoot remiasi sukaupta veiklos patirtimi, plačia klientų baze, stabiliomis paslaugomis ir nuolatine KPI kontrole. Įmonė ir jos projektų portfelis: milijonai klientų; mėnesio pardavimai siekia milijardus. Ailoot šią veiklos patirtį pritaiko teikdama API prieigą prie DI funkcijų klientų produktuose, agentuose, programose ir automatizavimo sprendimuose.