Затворите петљу провереним побољшањем

Дефинишите петљу коју желите да затворите

Софтвер током употребе производи доказе: грешке, кашњења, захтеве за подршку, инциденте, налазе одржавања и поновљени ручни рад. Потпун животни циклус враћа те доказе у инжењерске одлуке.

Софтвер који се сам побољшава може да значи да аутоматизација помаже у препознавању, предлагању, имплементацији и провери промена. Не мора да значи да модел обучава сам себе. Наведите који део се мења: код апликације, конфигурација, тестови, упутства, радни ток или параметри модела.

Самостални опоравак враћа познато радно стање. Самостално побољшавање мења систем да би будући исход био бољи. Друга тврдња захтева поређење и заштиту од регресија.

Пратите једно запажање кроз животни циклус

Следећи низ је предложена инжењерска метода. Није тврдња да било који производ сваки корак обавља самостално.

Сачувајте везе између ових резултата. Радњу после инцидента која гласи „побољшати надзор“ тешко је проверити. Дефинисан сигнал, одговорна особа, праг и тестиран одговор чине завршетак видљивим.

Процењујте независно од предлога

Агент може да направи закрпу и предложи тестове. Тим и даље мора да испита да ли ти тестови откривају првобитни проблем. Сачувајте верзионисан скуп за процену који промена не може неприметно да ослаби.

За измишљено цурење меморије упоредите еквивалентна оптерећења и верзије. Укључите велике извозе, отказивање, поновне покушаје и одбијање приступа. Користите синтетичке податке који представљају релевантне структуре без откривања записа о купцима.

Одбијте бржи извоз ако изоставља записе, заобилази ауторизацију или прелази дозвољени трошак. Дефинишите та ограничења пре оптимизације. У супротном, систем може да побољша изабрану метрику, а погорша сервис.

Ако промените упутства агента или модел, процените његово понашање на репрезентативним задацима и познатим отказима. Задржите претходну верзију доступном. Ажурирање упутстава није доказ да је основни модел научио нешто из инцидента.

Објавите и измерите резултат

Canary издање излаже ограничену групу кандидатској верзији. Упоредите сигнале кандидатске и контролне верзије и дефинишите када да проширите употребу или станете. Мало саобраћаја или различита оптерећења могу да оставе поређење без јасног закључка. Canary смернице.

Измишљен тим бележи полазно мерење на фиксном синтетичком оптерећењу. Тестира исправку, објављује је у одобреној граници и проверава упоредиве периоде у продукцији. Ако докази остану недовољни, бележи неизвесност уместо проглашавања добитка.

Мерите и поновљени ручни рад. Аутоматизација може да смањи рутински посао, али и њој требају одржавање и поступање при отказу. Укључите те трошкове када процењујете резултат. Смернице за рутински рад.

Учините запис повратних информација употребљивим

За вежбу користите ова поља: запажање и верзија; полазно мерење; предложени узрок; критеријуми прихватања; регресионе провере; промена и преглед; граница објављивања; измерен резултат; одговорна особа и следећи преглед.

Taiga Maintaining повезује налазе у репозиторијуму са радом на отклањању. Initiatives повезују намеравану промену са планирањем и испоруком. То обезбеђује делове ланца доказа. Особа одговорна за сервис и даље мора да провери постављање и оперативни резултат. Maintaining, Initiatives.

Зрела софтверска фабрика повезује овај посао кроз различите производе. Нека права одлучивања и критеријуми процене остану видљиви док аутоматизација расте. Коначан доказ је бољи проверени сервис, а не већи број генерисаних промена.