Odgovornosti primerjajte pred izdelki

Primerjajte isti rezultat

Izbira orodja za prototipe ne določa nujno vašega produkcijskega modela delovanja. Ljudje lahko raziskujejo z orodji, ki ustrezajo njihovemu delu. Organizacija še vedno potrebuje podprt način za zaščito, namestitev, vzdrževanje in upravljanje uporabnih rezultatov.

Pomočnik za programiranje, notranja platforma in tovarna programske opreme lahko rešujejo različne dele težave. Primerjava njihovih naročnin brez določitve obsega lahko vodi v zavajajočo odločitev.

Začnite z zahtevanim rezultatom: dobaviti in upravljati notranjo storitev v skladu z zahtevami podjetja glede podatkov, varnosti in zanesljivosti. Nato določite potrebno delo skozi življenjski cikel. Vključite delo po prvi uspešni predstavitvi.

Pri izmišljeni storitvi za pogodbe organizacija potrebuje odobrene zahteve, dostop zaposlenih, zasebne zapise, preverjene izdaje, odziv na incidente in stalne posodobitve. Orodje, ki ustvari končno točko, obravnava del tega seznama.

Opišite tri možne modele delovanja

Pri pomočniku za programiranje razvijalci uporabljajo AI znotraj obstoječega inženirskega sistema. Organizacija zagotavlja okoliške postopke, integracije, zmožnosti platforme in zbiranje dokazil. To je lahko primerno za organizacijo z zrelimi skupnimi storitvami.

Pri notranje sestavljenem sistemu dobave organizacija poveže agente, kontekst, preverjanja, namestitev in povratne informacije iz delovanja. Pridobi nadzor nad zasnovo, hkrati pa prevzame odgovornost za integracijski izdelek, njegovo podporo in nadgradnje.

Pri kupljeni tovarni programske opreme dobavitelj zagotovi širši povezan delovni tok. Preverite dejanski obseg in podprte integracije. Organizacija še vedno potrebuje odločitve o izdelku in izrecno delitev odgovornosti.

To so modeli za primerjavo in ne splošne kategorije izdelkov. Posamezni dobavitelj ali notranja platforma lahko zmožnosti združuje drugače.

Preverite pot od prototipa do delujoče storitve

Za vsako možnost uporabite isti konkreten scenarij. Pri bančnem prototipu začnite s sintetičnimi transakcijami in brez dovoljenj za prave sisteme. Pred razširitvijo dostopa naj ekipa ali dobavitelj pokaže naslednje zmožnosti:

1. Oceniti prototip in prepoznati kodo, ki potrebuje spremembo ali zamenjavo.
2. Namestiti ga v zahtevano infrastrukturo, vključno z vašimi računi v oblaku, kadar jih zahtevajo pravila.
3. Preveriti dovoljenja aplikacije, ravnanje s skrivnostmi ter tokove podatkov med razvojem in delovanjem.
4. Pripraviti dokazila glede na veljavne zahteve in zabeležiti odločitev o izdaji.
5. Spremljati storitev, odpravljati ranljivosti, preizkušati obnovo in se odzivati na incidente.

Prenos kode v vaš račun je en del tega dela. Preverite, kdo lahko upravlja okolje in kje zunanje storitve prejemajo podatke. Nadzorne ukrepe prilagodite svojim obveznostim; sama lokacija namestitve ne dokazuje skladnosti.

Za navedene meje enega dobavitelja primerjajte opis deljene odgovornosti Taiga s svojim zemljevidom. To je gradivo izdajatelja tega spletišča. Pred omogočanjem uporabe Taiga preverite veljavni dogovor in konfiguracijo.

Ločite izvajanje, preverjanje in odločanje

Za vsako dejavnost zabeležite, kdo jo izvaja, kdo preverja rezultat in kdo sprejme posledico. Ena stran ima lahko več vlog, prazna vloga pa je vrzel.

Tudi storitve v oblaku delijo odgovornost med ponudnika in stranko. Natančna delitev je odvisna od storitve. To naj bo razlog za zahtevo po natančnem zemljevidu, ne za predpostavko, da ima vsak upravljani izdelek enako mejo. Deljena odgovornost AWS.

Poiščite vrzeli in podvojeno delo

Recimo, da dobavitelj ustvari cevovod, platformna ekipa pa že vzdržuje odobreno pot namestitve. Odločite se, ali naj dobavitelj uporabi to pot. Dva neodvisno vzdrževana cevovoda lahko ustvarita nasprotujoče si nadzorne ukrepe in nepotrebne stroške.

Nasprotno lahko dobavitelj predpostavlja, da ima stranka ekipo za incidente, stranka pa predpostavlja, da je upravljanje vključeno. To vrzel razrešite, preden postanejo uporabniki odvisni od storitve.

Smernice CNCF za platforme organizacijam omogočajo kombiniranje notranjih in upravljanih zmožnosti. Relevantno vprašanje je, ali nastala izkušnja izpolnjuje potrebe uporabnikov z jasno odgovornostjo. Smernice CNCF.

Zemljevid uporabite pri komercialni odločitvi

Zemljevid odgovornosti priložite ocenjevalnim zapisom in ga pojasnite v veljavnem dogovoru. Ocenite strošek dela, ki ostane v vaši organizaciji. Vključite stroške vzdrževanja povezav med komponentami.

Dobavitelj s širšim obsegom je lahko koristen, ko odstrani integracijsko delo in ohrani dokazila skozi življenjski cikel. Notranji pristop je lahko koristen, kadar posebne zahteve upravičujejo stalno lastno odgovornost. Odločite se na podlagi zahtevanega rezultata in preverjenega obsega.