Derinimas ir gedimų analizė naudojant dirbtinį intelektą

Pelnas:

• Galimybė greitai susiaurinti galimas pagrindines priežastis, suteikiant dirbtiniam intelektui strigčių įrašus (stack pėdsakus) su atitinkamu kodu ir scenarijaus kontekstu
• Galimybė visam laikui išspręsti pagrindinę priežastį, o ne patvirtinti AI diagnozę kaip hipotezę kode ir testuoti bei nutildyti simptomą
• Privatumo apsauga derinant, užmaskuojant asmeninius duomenis gedimų įrašuose ir žurnaluose

Kiekviena programa pateikia klaidų; Geras kūrėjas išsiskiria tuo, kaip greitai jie randa ir ištaiso klaidas. Mobilusis derinimas – problemos šaltinio radimas ir pašalinimas – ypač sunkus, nes klaida įvyksta vartotojo įrenginyje aplinkoje, kurios nematote. Dažniausiai viskas, ką turite, yra strigčių žurnalas (gedimų žurnalas / dėklo pėdsakas – techninis suskirstymas, kur programa nuėjo, kai ji sudužo). Dirbtinis intelektas yra nepaprastai galingas skaitydamas šiuos paslaptingus įrašus, išvardydamas galimas priežastis ir siūlydamas sprendimus. Šiame skyriuje išmoksime naudoti AI kaip „klaidų detektyvą“, tačiau paliksime jums atsakomybę už galutinės diagnozės patikrinimą ir pataisymą.

Avarijų žurnalo skaitymas: kur AI šviečia ryškiausiai

Avarijų žurnalas yra ilgas ir bauginantis tekstas; nepatyręs kūrėjas nežinos, kur ieškoti. AI analizuoja šį tekstą per kelias sekundes: kurioje eilutėje jis sudužo, kuri išimtis buvo padaryta, kokia yra galima priežastis. Įprastos mobiliųjų telefonų klaidos yra akivaizdžios ir dirbtinis intelektas jas greitai atpažįsta: NullPointerException (bandoma pasiekti nulinę reikšmę), IndexOutOfBoundsException (prieiga prie neegzistuojančio sąrašo elemento) sistemoje „Android“, EXC_BAD_ACCESS (prieiga prie atlaisvintos atminties) „iOS“, netikėtai rasta nulis (priverčianti ni).

Dažniausiai pasitaikantys mobiliųjų telefonų gedimų tipai ir jų tipinės priežastys yra šios:

Klaida (išimtis)

Platforma

tipinė priežastis

NullPointerException

Android

Prieiga prie nulinės reikšmės

IndexOutOfBoundsException

Android

Prieiga prie neegzistuojančio sąrašo elemento

netikėtai rastas nulis

iOS

Neprivaloma (!) priverstinai išvynioti nulį.

EXC_BAD_ACCESS

iOS

Prieiga prie atlaisvintos atminties

ANR / užšaldymas

Android

Ilgas/sunkus pagrindinio sriegio apdorojimas

Žingsnis po žingsnio derinimo eiga:

1. Surinkite įrašą. Sudėkite strigčių žurnalą, klaidos pranešimą ir, jei įmanoma, veiksmus, kad jį atkurtumėte.
2. Pateikite AI kontekstą. Pasakykite man ne tik klaidą, bet ir atitinkamą kodo dalį ir tai, ką darydama ji sugedo.
3. Klauskite galimų priežasčių. „Pasakykite man 3 labiausiai tikėtinas priežastis ir kaip jas patikrinti.
4. Patvirtinti. Patvirtinkite siūlomą priežastį kode ir testuodami; Nesitaisykite spėliodami.
5. Pataisykite ir išbandykite dar kartą. Patikrinkite, ar klaida iš tikrųjų dingo ir ar nesukurta jokių naujų klaidų.

Patarimas: pateikdami strigčių žurnalą AI, įtraukite ir atitinkamą kodo fragmentą. Tik naudojant kamino pėdsaką AI daro bendrą prognozę; Kai pamatysite kodą, tikimybė rasti tikslią eilutę ir tikrąją priežastį labai padidėja. Kontekstas lemia diagnozės kokybę.

Asmens duomenų spąstai

Strigčių žurnaluose ir žurnaluose dažnai yra vartotojo duomenų: el. pašto adreso, vartotojo ID, vietos ir net formos turinio. Šio įrašo įklijavimas į AI tokį, koks yra, yra asmens duomenų nutekėjimas trečiajai šaliai ir yra KVKK / GDPR pažeidimas. Prieš pateikdami įrašą, nuvalykite (užmaskuokite) asmenines vietas. Be to, būkite atsargūs ir nerašykite asmens duomenų į savo programos žurnalus nuo pat pradžių; Geras žurnalas aprašo problemą, bet neatskleidžia tapatybės.

Atsargiai: AI pasiūlytas pataisymas gali „nutildyti klaidą“, bet negali išspręsti pagrindinės priežasties. Pvz., NullPointerException įvedimas į nulinį patikrinimą sustabdys strigtį, bet jei nesuprasite, kodėl reikšmė yra nulinė, tikroji logikos klaida tęsis. Gydykite ligą, o ne simptomą.

Pagrindinės priežasties analizė

Profesionalaus derinimo tikslas yra ne nutildyti klaidą, o rasti pagrindinę priežastį. Aš paklausiau AI „kodėl tai gali būti niekinė, kur jis galėjo pasiklysti duomenų sraute? klausia: „Kaip man tai nutildyti? Tai daug vertingiau nei prašyti. Nustačius pagrindinę priežastį, vienu metu išsprendžiamos dešimtys tos pačios klaidos variantų. AI gerai išmano šį grandininį argumentą: sekite duomenis nuo įvesties iki išvesties ir paprašykite pagalvoti, kur jie sugenda.

trys mini dėklai

1 atvejis – 2 valandos darbo per 10 minučių. Kūrėjas praleido 2 valandas ieškodamas klaidos, kuri sudužo tik konkrečiame „Samsung“ modelyje. Perdavė avarijų žurnalą (asmeninių zonų išvalymas) AI; YZ teigė, kad klaida rodo atminties perpildymą, atsirandantį naudojant kitokią to įrenginio kameros skiriamąją gebą. Turint užuominą, priežastis buvo rasta per 10 minučių. AI paspartino paiešką, žmogus patikrino sprendimą.

2 atvejis – nutildyta klaida grįžta. Viena komanda nutildė pasikartojančią avariją naudodama AI pasiūlymą pabandyti ją sugauti. Gedimas sustojo, bet vartotojai pradėjo skųstis, kad „duomenys neišsaugomi“; nes tikroji problema (duomenų bazės ryšys) vis dar išliko, ji tiesiog tapo nematoma. Nustačius pagrindinę priežastį, gedimas ir duomenų praradimas buvo pašalinti. Pamoka: nutildymas neišsprendžia.

3 atvejis – žurnale nutekėjo duomenys. Atlikus auditą buvo nustatyta, kad vartotojų vardai ir telefonų numeriai buvo įrašyti į programėlės strigčių žurnalus. Kūrėjai reguliariai įklijavo šiuos žurnalus į AI ir ištaisė klaidas; Taigi asmens duomenys dingsta jau kelis mėnesius. Žurnalai buvo užmaskuoti ir procesas buvo pataisytas. Pamoka: konfidencialumas taikomas net derinant.

Silpnas raginimas / Stiprus raginimas

Prastas raginimas: „Kodėl įvyksta ši klaida? [stack trace]“

Stiprus raginimas: „Ši strigtis vyksta mano „Android“ programoje. Kontekstas: – Atliekant: naudotojas įdeda į krepšelį iš išsamios produkto informacijos – Tik kai kuriuose įrenginiuose, mažai RAM modeliuose – Susijęs kodas: [ViewModel and Repository part] – Strigčių žurnalas (asmeniniai duomenys išvalyti): [stack trace]Išvardykite 3 labiausiai tikėtinas pagrindines priežastis. Kiekvienam:1) Kaip taisyti (nepataisyti) (nepataisyti). prielaida, kai nesate tikras“.

Kopijuojami šablonai

Strigčių analizės šablonas: "Analizuokite toliau nurodytą strigtį. Kontekstas: [ką darote, kuris įrenginys / versija]. Atitinkamas kodas: [kodas]. Strigčių žurnalas (asmeniniai duomenys išvalyti): [atsekti]. Nurodykite 3 labiausiai tikėtinas priežastis ir kiekvienos iš jų patvirtinimą + nuolatinį pataisymą. Taip pat pažymėkite problemos sprendimo būdus, kurie nutildo simptomą."

Pagrindinės priežasties šablonas: "Ši reikšmė netikėtai gaunama [null/false]. Sekite duomenų srautą nuo įvesties iki šio taško: kur jie gali būti prarasti arba sugadinti? Nurodykite, kur turėčiau patikrinti kiekviename etape. [kodas]."

Žurnalo skaitymo šablonas: "Interpretuokite šį žurnalo išvestį: kokie įvykiai įvyko eilės tvarka, kur yra anomalija, koks buvo paskutinis sveikas veiksmas prieš klaidą? [žurnalas – išvalyti asmens duomenys]"

Atkūrimo šablonas: „Kokius veiksmus, įrenginio būsenas ir duomenis turėčiau bandyti patikimai atkurti šią klaidą? Išvardykite sąlygas, kurios gali sukelti klaidą, eilės tvarka pagal tikimybę. [aprašas]“

Dažnos klaidos

• Suteikiamas dėklo sekimas be konteksto. Be atitinkamo kodo ir scenarijaus AI daro bendrą prognozę.
• Asmens duomenų įklijavimas į AI kartu su žurnalais. Konfidencialumo pažeidimas; pirmiausia kaukė.
• Nutildykite simptomą. Avarijos slėpimas naudojant try-catch palieka pagrindinę problemą ir sukuria naujų problemų.
• Pirmojo pasiūlymo taikymas jo nepatvirtinus. AI diagnozė yra hipotezė; Patvirtinkite kode.
• Bandoma jį atkurti emuliatoriuje. Kai kurios klaidos atsiranda tik faktiniame įrenginyje / būsenoje.
• Po korekcijos pakartotinai nebandoma. Pataisymas galėjo sugadinti dar ką nors; Patikrinkite regresiją.

Apibendrinant

Viena iš sričių, kur AI puikiai tinka, yra gedimų žurnalų skaitymas ir galimų priežasčių nustatymas; Pateikus kontekstą, diagnozės kokybė labai pagerėja. Tačiau galutinė diagnozė ir korekcija priklauso žmogui: AI pasiūlymas yra hipotezė, patikrinta kodu ir testavimu. Tikslas yra ne nutildyti simptomą, o pašalinti pagrindinę priežastį; Nutildyta klaida dažniausiai grįžta kitu pavidalu. Strigčių žurnaluose gali būti asmens duomenų; Užmaskuokite tai prieš atiduodami dirbtiniam intelektui ir nerašykite asmens duomenų į savo žurnalus nuo pat pradžių.

Taikymo užduotis

Paimkite turimą strigčių žurnalą (arba pavyzdį, kurį generuojate iš AI), užmaskuokite jame visus asmeninius / skiriamuosius duomenis ir pateikite jį dirbtiniam intelektui su „Strigčių analizės šablonu“. Atskirkite, kurios iš pagrindinių priežasčių AI sąrašai yra tikri pataisymai, o kurie tik nutildo. Taikykite pasirinktą nuolatinį pataisymą ir patikrinkite, ar klaida dingo ir nekyla jokių naujų problemų.

kontrolinis sąrašas

• [ ] Pateikiau strigčių žurnalą su atitinkamu kodu ir scenarijaus kontekstu
• [ ] Žurnaluose užmaskavau asmeninius / skiriamuosius duomenis
• [ ] Paprašiau dirbtinio intelekto dėl pagrindinės priežasties ir nuolatinio pataisymo, o ne nutildymo
• [ ] Diagnozę patikrinau kodu ir testavimu, aklai netaikau
• [ ] Po pataisymo patikrinau, ar klaida dingo ir nėra regresijos
• [ ] Patikrinau, kad mano paraiška savo žurnaluose nerašo asmens duomenų