Luk feedbacksløjfen med verificerede forbedringer

Definér den sløjfe, du vil lukke

Software skaber dokumentation under brug: fejl, forsinkelser, supporthenvendelser, hændelser, vedligeholdelsesfund og gentaget manuelt arbejde. En komplet livscyklus fører disse observationer tilbage til udviklingsbeslutninger.

Selvforbedrende software kan betyde, at automatisering hjælper med at identificere, foreslå, implementere og verificere ændringer. Det betyder ikke nødvendigvis, at en model træner sig selv. Angiv, hvilken del der ændres: applikationskode, konfiguration, tests, instruktioner, arbejdsgang eller modelparametre.

Self-healing gendanner en kendt driftstilstand. Self-improvement ændrer systemet, så det giver et bedre resultat fremover. Den anden påstand kræver sammenligning og beskyttelse mod regressioner.

Følg én observation gennem livscyklussen

Forløbet nedenfor er en foreslået udviklingsmetode. Det er ikke en påstand om, at et produkt udfører hvert trin autonomt.

Bevar links mellem resultaterne. En postmortem-opgave med teksten »forbedr overvågning« er svær at verificere. Et defineret signal, en ansvarlig, en grænseværdi og en testet reaktion gør færdiggørelsen observerbar.

Hold evalueringen uafhængig af forslaget

En agent kan skabe en patch og foreslå tests. Teamet skal stadig undersøge, om testene opdager det oprindelige problem. Bevar et versioneret evalueringssæt, som ændringen ikke ubemærket kan svække.

Sammenlign tilsvarende workloads og versioner for det fiktive hukommelseslæk. Medtag store eksporter, annullering, nye forsøg og afvist adgang. Brug syntetiske data, der repræsenterer relevante strukturer uden at eksponere kundeposter.

Afvis en hurtigere eksport, hvis den udelader poster, omgår autorisation eller overstiger de tilladte omkostninger. Definér begrænsningerne før optimering. Ellers kan systemet forbedre den valgte måling og samtidig forringe tjenesten.

Hvis du ændrer en agents instruktioner eller model, skal dens adfærd evalueres på repræsentative opgaver og kendte fejl. Hold den tidligere version tilgængelig. Opdaterede instruktioner beviser ikke, at den underliggende model lærte af en hændelse.

Udgiv og mål resultatet

En canary-release eksponerer en begrænset gruppe for en kandidatversion. Sammenlign signaler fra kandidat og kontrol, og definér, hvornår udrulningen skal udvides eller stoppes. Begrænset trafik eller forskellige workloads kan gøre sammenligningen uafklaret. Canary-vejledning.

Det fiktive team registrerer en baseline fra en fast syntetisk workload. Teamet tester rettelsen, udgiver inden for en godkendt grænse og kontrollerer sammenlignelige produktionsperioder. Hvis dokumentationen stadig er utilstrækkelig, registrerer teamet usikkerheden frem for at erklære en gevinst.

Mål også gentaget manuelt arbejde. Automatisering kan reducere rutinearbejde, men kræver også vedligeholdelse og fejlhåndtering. Medtag disse omkostninger i vurderingen af resultatet. Vejledning om rutinearbejde.

Gør feedbackregistreringen brugbar

Brug disse felter til øvelsen: observation og version; baseline; foreslået årsag; acceptkriterier; regressionskontroller; ændring og review; releasegrænse; målt resultat; ansvarlig og næste review.

Taiga Maintaining forbinder fund i repositories med afhjælpning. Initiativer forbinder en tilsigtet ændring med planlægning og levering. De leverer dele af en dokumentationskæde. Tjenesteejeren skal stadig verificere udrulning og driftsresultat. Maintaining, Initiatives.

En moden softwarefabrik forbinder dette arbejde på tværs af produkter. Hold beslutningsrettigheder og evalueringskriterier synlige, når automatiseringen øges. Det endelige bevis er en verificeret bedre tjeneste, ikke et større antal genererede ændringer.