Artefaktimanifestin palautus erottaa suosittelujärjestelmän palauttamisen tilanteesta, jossa kaikki pitää julkaista uudelleen yhden väärän mallin, feature-taulun tai sääntöpaketin vuoksi. Serving-järjestelmässä, jossa ranking ja data muuttuvat usein, aktiivisen artefaktiversion pitää olla eksplisiittinen.
Palvelubinaari on vain yksi osa suosittelupolkua. Vastaus voi riippua myös mallitiedostoista, feature-snapshotista, kandidaatti-indekseistä, config-säännöistä ja fallback-määrityksistä. Jos artefaktit liikkuvat ilman selkeää manifestia, operoijat menettävät kyvyn selittää tai palauttaa tuotannon käyttäytymistä.
Mitä artefaktimanifestin pitää tunnistaa
Artefaktimanifesti on osoitin versioituihin syötteisiin, joita serving-kerros saa käyttää. Sen pitää olla riittävän pieni katselmoitavaksi ja riittävän tarkka tarjoillun vastauksen toistamiseen.
Vähintään manifestin pitäisi tunnistaa:
- malli- tai pisteytysartefaktien versiot
- kandidaatti- tai indeksiversiot
- feature-snapshotin tai feature-poiminnan versiot
- sääntö- ja config-versiot
- buildin tai pipeline-ajon metadata
- tuoreusaikaleimat
- validointitila
Manifestin ei tarvitse sisältää jokaista artefaktin sisältöä. Sen pitää osoittaa täsmällisiin versioihin, joista serving-julkaisu koostuu.
Miksi palvelun rollback ei riitä
API-julkaisun palautus voi olla väärä vipu, jos virhe tuli datasta tai artefakteista. Edellinen binaari voi yhä ladata saman huonon manifestin. Uusi binaari voi olla terve, vaikka aktiivinen indeksi olisi vanhentunut.
Artefaktimanifestin palautus antaa operoijalle kapeamman korjauspolun. Sen sijaan, että palvelu julkaistaan uudelleen, tiimi voi palauttaa viimeksi tunnetusti hyvän manifestiosoitteen, varmistaa että palvelu lukee sen ja seurata, että guardrailit palaavat odotetulle tasolle.
Tämä parantaa myös häiriökatselmusta. Tiimi voi erottaa koodivirheet pipeline-virheistä, vanhentuneesta datasta ja huonosta ranking-konfiguraatiosta.
Artefaktimanifestin palautuspolku
Käytännöllinen palautuspolku on lyhyt ja eksplisiittinen:
- Tunnista epäonnistunut julkaisu, vaikutettu tenant tai pinta ja aktiivinen manifestiversio.
- Varmista guardrail tai arviointitulos, joka laukaisi palautuksen.
- Valitse päätösjäljestä edellinen tunnetusti hyvä manifesti.
- Siirrä aktiivinen manifestiosoitin takaisin siihen versioon.
- Varmista valmius, tuoreus, vastauksen muoto ja exposure-lokitus.
- Kirjaa palautettu versio ja rollbackin syy.
Tekniset dokumentit kuvaavat tämän työnkulun artefaktien ja pipelinejen oppaassa ja vanhentuneen artefaktimanifestin runbookissa.
Backfillit tarvitsevat saman kurinalaisuuden
Backfillit ovat hyödyllisiä, mutta ne voivat tehdä tuotantotilasta vaikeamman ymmärtää. Jos backfill päivittää featureita, indeksejä tai artefakteja, sen pitäisi tuottaa uusi manifestiehdokas eikä muuttaa aktiivisia serving-syötteitä hiljaisesti.
Silloin arvioijilla ja operoijilla on selkeä päätöspiste: validoi uusi manifesti, julkaise se, pidä se odottamassa tai palauta se.
Yhdistä palautus arviointiin
Rollbackin pitää olla osa arviointisuunnitelmaa, ei hätätilanteessa keksitty käytäntö. Tiimin pitää tietää, mitkä guardrailit merkitsevät, mikä manifestiversio on aktiivinen ja mikä edellinen versio on turvallinen ennen liikenteen siirtoa.
Tuotetason työnkulku löytyy arviointisivulta. Operatiiviseen korjaukseen käytä configin ja sääntöjen palautusrunbookia.