Sammenlign ansvar før produkter
Sammenlign en assistent, en intern leveranseplattform og en programvarefabrikk. Identifiser arbeidet hvert alternativ utfører, og ansvaret som blir igjen.
Publisert av TaigaSlik skriver vi
Dette lærer du
- Sammenlign alternativer mot samme påkrevde resultat.
- Skill det å utføre arbeid fra det å ta ansvar for konsekvensene.
- Identifiser mangler og overlapp i en foreslått driftsmodell.
Sammenlign samme resultat
Valget av prototypeverktøy trenger ikke bestemme driftsmodellen i produksjon. Folk kan utforske med verktøy som passer arbeidet. Organisasjonen trenger fortsatt en støttet måte å sikre, rulle ut, vedlikeholde og drifte nyttige resultater på.
En kodeassistent, en intern plattform og en programvarefabrikk kan løse ulike deler av problemet. Å sammenligne abonnementspriser uten å definere omfanget kan gi en misvisende beslutning.
Start med et påkrevd resultat: lever og drift en intern tjeneste under selskapets krav til data, sikkerhet og pålitelighet. Identifiser deretter nødvendig arbeid gjennom livssyklusen. Ta med arbeidet etter den første vellykkede demonstrasjonen.
For en fiktiv kontraktstjeneste trenger organisasjonen godkjente krav, ansattilgang, private poster, verifiserte utgivelser, hendelseshåndtering og løpende oppdateringer. Et verktøy som genererer et endpoint, håndterer en del av listen.
Beskriv tre mulige driftsmodeller
Med en kodeassistent bruker utviklere AI i et eksisterende utviklingssystem. Organisasjonen leverer de omkringliggende prosessene, integrasjonene, plattformfunksjonene og innsamlingen av dokumentasjon. Det kan passe en organisasjon med modne fellestjenester.
Med et internt sammensatt leveransesystem integrerer organisasjonen agenter, kontekst, kontroller, utrulling og driftstilbakemeldinger. Den får kontroll over designet og eier også integrasjonsproduktet, støtten og oppgraderingene.
Med en kjøpt programvarefabrikk leverer en leverandør en bredere sammenhengende arbeidsflyt. Verifiser faktisk omfang og støttede integrasjoner. Organisasjonen trenger fortsatt produktbeslutninger og en tydelig ansvarsdeling.
Dette er sammenligningsmodeller, ikke universelle produktkategorier. En konkret leverandør eller intern plattform kan kombinere funksjoner annerledes.
Verifiser veien fra prototype til en tjeneste i drift
Bruk samme konkrete scenario for hvert alternativ. For bankprototypen starter dere med syntetiske transaksjoner og ingen reelle tillatelser. Be teamet eller leverandøren demonstrere disse evnene før tilgangen utvides:
- Vurder prototypen, og identifiser kode som må endres eller erstattes.
- Rull ut i nødvendig infrastruktur, inkludert egne skykontoer der policyen krever det.
- Verifiser applikasjonstillatelser, håndtering av hemmeligheter og datastrømmer under utvikling og kjøring.
- Produser dokumentasjon mot gjeldende krav, og registrer utgivelsesbeslutningen.
- Overvåk tjenesten, rett sårbarheter, test gjenoppretting og håndter hendelser.
Å flytte kode til egen konto er én del av arbeidet. Verifiser hvem som kan administrere miljøet, og hvor eksterne tjenester mottar data. Tilpass kontrollene til forpliktelsene; plasseringen av en utrulling dokumenterer ikke alene etterlevelse.
Sammenlign Taigas beskrivelse av delt ansvar med kartet for å se én leverandørs oppgitte grenser. Dette er utgiverens eget materiale. Verifiser gjeldende avtale og konfigurasjon før dere tar Taiga i bruk.
Skill utførelse, kontroll og beslutning
Registrer hvem som utfører hver aktivitet, hvem som verifiserer resultatet, og hvem som aksepterer konsekvensen. Én part kan ha flere roller, men en tom rolle er en mangel.
| Aktivitet | Spørsmål til ansvarskartet |
|---|---|
| Krav | Hvem avklarer en tvetydig forretningsregel? |
| Databehandling | Hvem godkjenner mottakere og behandlingsvilkår? |
| Implementering | Hvem vedlikeholder generert kode etter aksept? |
| Verifisering | Hvem kontrollerer at dokumentasjonen dekker den faktiske utgivelsen? |
| Utrulling | Hvilken identitet endrer hvilket miljø? |
| Drift | Hvem reagerer når tjenesten svikter? |
| Plattformoppdateringer | Hvem tilpasser integrasjoner når avhengigheter endres? |
Skytjenester deler også ansvar mellom leverandør og kunde. Den nøyaktige fordelingen avhenger av tjenesten. Bruk det som grunn til å be om et presist kart, ikke til å anta at alle administrerte produkter har samme grense. AWS om delt ansvar.
Se etter mangler og dobbeltarbeid
Anta at leverandøren genererer en pipeline mens plattformteamet allerede vedlikeholder den godkjente utrullingsveien. Beslut om leverandøren bør bruke den. To uavhengig vedlikeholdte pipelines kan skape motstridende kontroller og unødvendige kostnader.
Motsatt kan leverandøren anta at kunden har et hendelsesteam, mens kunden antar at drift er inkludert. Avklar mangelen før brukere blir avhengige av tjenesten.
CNCFs plattformveiledning åpner for å kombinere interne og administrerte tjenester. Det relevante spørsmålet er om den samlede opplevelsen dekker brukerbehov med tydelig eierskap. CNCF-veiledning.
Bruk kartet i den kommersielle beslutningen
Legg ansvarskartet ved evalueringsnotatene, og avklar det i gjeldende avtale. Pris arbeidet som blir hos organisasjonen. Ta med kostnaden ved å vedlikeholde forbindelser mellom komponenter.
En leverandør med bredere omfang kan være verdifull når den fjerner integrasjonsarbeid og bevarer dokumentasjon gjennom livssyklusen. En intern løsning kan være verdifull der særegne krav begrunner fortsatt eierskap. Beslutt ut fra påkrevd resultat og verifisert omfang.
Gjør øvelsen
Lag tre kolonner: kodeassistent, internt sammensatt leveransesystem og kjøpt programvarefabrikk. Legg til rader for krav, policyer, implementering, verifisering, utgivelse, drift og oppdateringer. Registrer hvem som utfører, verifiserer og aksepterer hver aktivitet. Marker alt som er ukjent.
Last ned arbeidsark (Markdown)Kontroller forståelsen din
Kilder og videre lesning
Relatert lesning fra Taiga
Hvis du fjerner dette valget, slettes all fremdrift som er lagret i denne nettleseren.
Fremdriften blir i denne nettleseren. Ingen konto eller sporing.