Lukk sløyfen med verifisert forbedring

Definer sløyfen dere vil lukke

Programvare produserer bevis under bruk: feil, forsinkelser, støtteforespørsler, hendelser, vedlikeholdsfunn og gjentatt manuelt arbeid. En komplett livssyklus fører disse bevisene tilbake til utviklingsbeslutninger.

Selvforbedrende programvare kan bety at automatisering hjelper med å identifisere, foreslå, implementere og verifisere endringer. Det betyr ikke nødvendigvis at en modell trener seg selv. Oppgi hvilken del som endres: applikasjonskode, konfigurasjon, tester, instruksjoner, arbeidsflyt eller modellparametere.

Self-healing gjenoppretter en kjent driftstilstand. Self-improvement endrer systemet for å gi et bedre resultat i fremtiden. Den andre påstanden krever en sammenligning og beskyttelse mot regresjoner.

Følg én observasjon gjennom livssyklusen

Sekvensen nedenfor er en foreslått utviklingsmetode. Den hevder ikke at noe produkt utfører alle trinnene autonomt.

Bevar lenker mellom disse resultatene. Et tiltak fra en etteranalyse som sier «forbedre overvåking», er vanskelig å verifisere. Et definert signal, en eier, en terskel og en testet respons gjør fullføring observerbar.

Hold evalueringen uavhengig av forslaget

En agent kan lage en retting og foreslå tester. Teamet må fortsatt undersøke om testene oppdager det opprinnelige problemet. Bevar et versjonert evalueringssett som endringen ikke kan svekke i det stille.

For den fiktive minnelekkasjen sammenligner dere tilsvarende arbeidslaster og versjoner. Ta med store eksporter, avbrytelse, nye forsøk og tilfeller med nektet tilgang. Bruk syntetiske data som representerer de relevante strukturene uten å eksponere kundeopplysninger.

Avvis en raskere eksport hvis den mister opplysninger, omgår autorisasjon eller overskrider tillatt kostnad. Definer disse begrensningene før optimalisering. Ellers kan systemet forbedre det valgte måltallet mens tjenesten blir dårligere.

Hvis dere endrer en agents instruksjoner eller modell, må dere evaluere oppførselen på representative oppgaver og kjente feil. Hold den forrige versjonen tilgjengelig. Oppdaterte instruksjoner er ikke bevis på at den underliggende modellen lærte av en hendelse.

Gi ut og mål resultatet

En canary-utgivelse eksponerer en begrenset gruppe for en kandidatversjon. Sammenlign signalene fra kandidaten og kontrollgruppen, og definer når dere skal utvide eller stoppe. Lite trafikk eller ulike arbeidslaster kan gjøre sammenligningen uklar. Canary-veiledning.

Det fiktive teamet registrerer et utgangspunkt fra en fast syntetisk arbeidslast. Det tester rettingen, gir den ut innenfor en godkjent grense og kontrollerer sammenlignbare produksjonsperioder. Hvis bevisene fortsatt er utilstrekkelige, registrerer teamet usikkerheten i stedet for å erklære en gevinst.

Mål også gjentatt manuelt arbeid. Automatisering kan redusere rutinearbeid, men trenger også vedlikehold og feilhåndtering. Ta med disse kostnadene når dere vurderer resultatet. Veiledning om rutinearbeid.

Gjør tilbakemeldingsregistreringen nyttig

Bruk disse feltene i øvelsen: observasjon og versjon; utgangspunkt; foreslått årsak; akseptansekriterier; regresjonskontroller; endring og review; utgivelsesgrense; målt resultat; eier og neste gjennomgang.

Taiga Maintaining knytter repository-funn til utbedringsarbeid. Initiatives knytter en ønsket endring til planlegging og leveranse. Dette gir deler av en beviskjede. Tjenesteeieren må fortsatt verifisere utrulling og driftsresultat. Maintaining, Initiatives.

En moden programvarefabrikk kobler dette arbeidet sammen på tvers av produkter. Hold beslutningsrettigheter og evalueringskriterier synlige når automatiseringen øker. Det endelige beviset er en bedre, verifisert tjeneste, ikke flere genererte endringer.