Sulje palautekierros varmennetulla parannuksella

Määritä suljettava palautekierros

Ohjelmiston käyttö tuottaa havaintoja virheistä, viiveistä, tukipyynnöistä, incidenteistä, ylläpitolöydöksistä ja toistuvasta käsityöstä. Täysi elinkaari palauttaa nämä havainnot kehityksen päätöksiin.

Self-improving voi tarkoittaa, että automaatio auttaa tunnistamaan, ehdottamaan, toteuttamaan ja varmentamaan muutoksia. Se ei välttämättä tarkoita mallin kouluttavan itseään. Kerro, mikä muuttuu: sovelluskoodi, konfiguraatio, testit, ohjeet, työnkulku vai mallin parametrit.

Self-healing palauttaa tunnetun toimintatilan. Self-improvement muuttaa järjestelmää niin, että tuleva tulos paranee. Jälkimmäinen väite tarvitsee vertailun ja suojan regressioita vastaan.

Seuraa havaintoa elinkaaren läpi

Alla on ehdotettu kehitysmenetelmä. Se ei väitä minkään tuotteen suorittavan kaikkia vaiheita autonomisesti.

Säilytä yhteydet vaiheiden tulosten välillä. Postmortemin tehtävää ”paranna monitoringia” on vaikea varmentaa. Määritelty signaali, omistaja, kynnys ja testattu toimintatapa tekevät valmistumisen havaittavaksi.

Pidä arviointi erillään ehdotuksesta

Agentti voi tehdä patchin ja ehdottaa testejä. Tiimin pitää silti tarkistaa, tunnistavatko testit alkuperäisen ongelman. Säilytä versioitu arviointiaineisto, jota muutos ei voi huomaamatta heikentää.

Vertaa muistivuotoesimerkissä vastaavia kuormia ja versioita. Sisällytä suuret viennit, keskeytys, retry ja pääsyn estot. Käytä synteettistä dataa, joka kuvaa olennaisia rakenteita paljastamatta asiakastietoja.

Hylkää nopeampi vienti, jos se hukkaa tietueita, ohittaa authorizationin tai ylittää sallitun kustannuksen. Määritä ehdot ennen optimointia. Muuten valittu mittari voi parantua palvelun heiketessä.

Jos muutat agentin ohjeita tai mallia, arvioi toimintaa edustavilla tehtävillä ja tunnetuilla virheillä. Pidä aiempi versio saatavilla. Ohjeen päivitys ei osoita kielimallin oppineen incidentistä.

Julkaise ja mittaa tulos

Canary release rajaa ehdokasversion pienelle käyttäjä- tai liikennejoukolle. Vertaa ehdokasta kontrolliin ja määritä laajentamisen sekä pysäytyksen ehdot. Vähäinen liikenne tai erilaiset kuormat voivat jättää tuloksen epäselväksi. Canary-ohje.

Kuvitteellinen tiimi mittaa lähtötason samalla synteettisellä kuormalla. Se testaa korjauksen, julkaisee hyväksytyn rajauksen sisällä ja vertaa sopivia tuotantojaksoja. Jos näyttö ei riitä, tiimi kirjaa epävarmuuden parannusväitteen sijaan.

Mittaa myös toistuvaa käsityötä. Automaatio voi vähentää toilia, mutta se tarvitsee ylläpitoa ja virheenkäsittelyä. Huomioi nämä kustannukset tuloksen arvioinnissa. Toil-ohje.

Tee palautetietueesta käyttökelpoinen

Käytä harjoituksessa näitä kenttiä: havainto ja versio; lähtötaso; oletettu syy; hyväksymiskriteerit; regressiotarkistukset; muutos ja review; julkaisurajaus; mitattu tulos; omistaja ja seuraava tarkistus.

Taigan Maintaining yhdistää repositorylöydöksiä korjaustyöhön. Initiatives yhdistää tavoitellun muutoksen suunnitteluun ja toimitukseen. Ne tuottavat osia näyttöketjusta. Palvelun omistajan pitää edelleen varmentaa deployment ja operatiivinen tulos. Maintaining, Initiatives.

Kypsä ohjelmistotehdas yhdistää työn useiden tuotteiden läpi. Pidä päätösoikeudet ja arviointikriteerit näkyvissä automaation lisääntyessä. Lopullinen näyttö on varmennetusti parempi palvelu, ei generoituja muutoksia kuvaava suurempi luku.