Slut loopen med verifierad förbättring

Definiera loopen du vill sluta

Programvara ger underlag under användning: fel, fördröjningar, supportärenden, incidenter, underhållsfynd och upprepat manuellt arbete. En fullständig livscykel för tillbaka underlaget till utvecklingsbeslut.

Självförbättrande programvara kan innebära att automatisering hjälper till att identifiera, föreslå, genomföra och verifiera ändringar. Det betyder inte nödvändigtvis att en modell tränar sig själv. Ange vilken del som ändras: applikationskod, konfiguration, tester, instruktioner, arbetsflöde eller modellparametrar.

Självläkning återställer ett känt drifttillstånd. Självförbättring ändrar systemet för att ge ett bättre utfall framöver. Det senare påståendet kräver en jämförelse och skydd mot regressioner.

Följ en observation genom livscykeln

Följden nedan är ett förslag till utvecklingsmetod. Den är inte ett påstående om att någon produkt utför alla steg autonomt.

Behåll länkar mellan resultaten. En postmortem-åtgärd som säger ”förbättra övervakningen” är svår att verifiera. En definierad signal, ansvarig, tröskel och testad insats gör det möjligt att se när arbetet är klart.

Håll utvärderingen oberoende av förslaget

En agent kan skapa en patch och föreslå tester. Teamet måste ändå granska om testerna upptäcker det ursprungliga problemet. Bevara en versionshanterad utvärderingsuppsättning som ändringen inte kan försvaga i det tysta.

Jämför likvärdiga arbetslaster och versioner för den fiktiva minnesläckan. Ta med stora exporter, avbrott, återförsök och nekad åtkomst. Använd syntetiska data som representerar relevanta strukturer utan att exponera kundposter.

Avvisa en snabbare export om den tappar poster, kringgår auktorisering eller överskrider tillåten kostnad. Definiera begränsningarna före optimering. Annars kan systemet förbättra det valda måttet samtidigt som tjänsten blir sämre.

Om du ändrar en agents instruktioner eller modell, utvärdera beteendet på representativa uppgifter och kända fel. Håll den tidigare versionen tillgänglig. Uppdaterade instruktioner är inget belägg för att den underliggande modellen har lärt sig av en incident.

Släpp och mät resultatet

En canary-release exponerar en begränsad grupp för en kandidatversion. Jämför signaler från kandidaten och kontrollgruppen. Definiera när utrullningen ska utökas eller stoppas. Lite trafik eller olika arbetslaster kan göra jämförelsen otillräcklig för en slutsats. Vägledning för canary-releaser.

Det fiktiva teamet registrerar en baslinje från en fast syntetisk arbetslast. Teamet testar korrigeringen, släpper den inom en godkänd gräns och kontrollerar jämförbara produktionsperioder. Om underlaget fortfarande är otillräckligt dokumenterar teamet osäkerheten i stället för att utropa en förbättring.

Mät också upprepat manuellt arbete. Automatisering kan minska sådant arbete, men behöver själv underhåll och felhantering. Ta med kostnaderna när du bedömer resultatet. Vägledning om repetitivt driftarbete.

Gör återkopplingsprotokollet användbart

Använd dessa fält i övningen: observation och version; baslinje; föreslagen orsak; acceptanskriterier; regressionskontroller; ändring och granskning; releasegräns; mätt resultat; ansvarig och nästa uppföljning.

Taiga Maintaining kopplar fynd i repositoryn till åtgärdsarbete. Initiatives kopplar en avsedd ändring till planering och leverans. De ger delar av en underlagskedja. Tjänsteansvarig måste fortfarande verifiera driftsättningen och resultatet i drift. Maintaining, Initiatives.

En mogen programvarufabrik kopplar samman arbetet mellan produkter. Håll beslutsrätt och utvärderingskriterier synliga när automatiseringen ökar. Det slutliga belägget är en bättre verifierad tjänst, inte fler genererade ändringar.