Læringsløp 06Leksjon 1 / 6

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.

Grunnleggende10 minGjennomgått

Publisert av Slik 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:

  1. Vurder prototypen, og identifiser kode som må endres eller erstattes.
  2. Rull ut i nødvendig infrastruktur, inkludert egne skykontoer der policyen krever det.
  3. Verifiser applikasjonstillatelser, håndtering av hemmeligheter og datastrømmer under utvikling og kjøring.
  4. Produser dokumentasjon mot gjeldende krav, og registrer utgivelsesbeslutningen.
  5. 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.

AktivitetSpørsmål til ansvarskartet
KravHvem avklarer en tvetydig forretningsregel?
DatabehandlingHvem godkjenner mottakere og behandlingsvilkår?
ImplementeringHvem vedlikeholder generert kode etter aksept?
VerifiseringHvem kontrollerer at dokumentasjonen dekker den faktiske utgivelsen?
UtrullingHvilken identitet endrer hvilket miljø?
DriftHvem reagerer når tjenesten svikter?
PlattformoppdateringerHvem 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

En leverandør automatiserer implementering og testkjøring. Hvem eier forretningskravet?

Kilder og videre lesning

Relatert lesning fra Taiga