Prieš produktus palyginkite atsakomybes

Lyginkite tą patį rezultatą

Prototipų kūrimo įrankio pasirinkimas neturi nulemti produkcinės veiklos modelio. Žmonės gali tyrinėti idėjas jų darbui tinkamais įrankiais. Organizacijai vis tiek reikia palaikomo būdo naudingus rezultatus apsaugoti, įdiegti, prižiūrėti ir eksploatuoti.

Programavimo asistentas, vidinė platforma ir programinės įrangos gamykla gali spręsti skirtingas problemos dalis. Jų prenumeratos kainų palyginimas neapibrėžus apimties gali lemti klaidinantį sprendimą.

Pradėkite nuo reikiamo rezultato: pristatyti ir eksploatuoti vidinę paslaugą pagal įmonės duomenų, saugumo ir patikimumo reikalavimus. Tada nustatykite darbą, reikalingą per visą gyvavimo ciklą. Įtraukite darbą po pirmos sėkmingos demonstracijos.

Išgalvotai sutarčių paslaugai organizacijai reikia patvirtintų reikalavimų, darbuotojų prieigos, privačių įrašų, patikrintų versijų, reagavimo į incidentus ir nuolatinių atnaujinimų. Įrankis, generuojantis API adresą, apima dalį šio sąrašo.

Aprašykite tris galimus veiklos modelius

Naudodami programavimo asistentą, programuotojai dirba su DI esamoje inžinerijos sistemoje. Organizacija suteikia susijusius procesus, integracijas, platformos galimybes ir įrodymų rinkimą. Tai gali tikti organizacijai su brandžiomis bendromis paslaugomis.

Viduje sukomplektuotoje pristatymo sistemoje organizacija integruoja agentus, kontekstą, patikrinimus, diegimą ir eksploatavimo grįžtamąjį ryšį. Ji įgyja projekto kontrolę ir kartu atsako už integracijos produktą, jo palaikymą bei atnaujinimus.

Įsigijus programinės įrangos gamyklą, tiekėjas suteikia platesnę susietą darbo eigą. Patikrinkite tikrąją apimtį ir palaikomas integracijas. Organizacijai vis tiek reikia produkto sprendimų ir aiškaus atsakomybių pasidalijimo.

Tai palyginimo modeliai, o ne universalios produktų kategorijos. Konkretus tiekėjas ar vidinė platforma gali derinti galimybes kitaip.

Patikrinkite kelią nuo prototipo iki eksploatuojamos paslaugos

Kiekvienam variantui naudokite tą patį konkretų scenarijų. Banko prototipą pradėkite nuo sintetinių operacijų be tikros sistemos teisių. Prieš plėsdami prieigą, paprašykite komandos ar tiekėjo pademonstruoti šias galimybes:

1. Įvertinti prototipą ir nustatyti kodą, kurį reikia pakeisti ar perrašyti.
2. Įdiegti į reikiamą infrastruktūrą, įskaitant jūsų debesijos paskyras, kai to reikalauja taisyklės.
3. Patikrinti programos teises, paslapčių tvarkymą ir kūrimo bei vykdymo duomenų srautus.
4. Pateikti taikomų reikalavimų įrodymus ir užfiksuoti išleidimo sprendimą.
5. Stebėti paslaugą, taisyti pažeidžiamumus, išbandyti atkūrimą ir reaguoti į incidentus.

Kodo perkėlimas į jūsų paskyrą yra tik viena šio darbo dalis. Patikrinkite, kas gali administruoti aplinką ir kur išorinės paslaugos gauna duomenis. Suderinkite kontrolės priemones su prievolėmis; vien diegimo vieta neįrodo atitikties.

Vieno tiekėjo deklaruojamas ribas galite palyginti su savo žemėlapiu pagal Taiga bendros atsakomybės aprašymą. Tai svetainės leidėjui priklausanti medžiaga. Prieš įgalindami Taiga naudojimą, patikrinkite taikomą susitarimą ir konfigūraciją.

Atskirkite atlikimą, tikrinimą ir sprendimą

Kiekvienai veiklai užrašykite, kas ją atlieka, kas patikrina rezultatą ir kas prisiima pasekmes. Viena šalis gali turėti kelis vaidmenis, tačiau neužpildytas vaidmuo yra spraga.

Debesijos paslaugos taip pat paskirsto atsakomybę tarp teikėjo ir kliento. Tikslus pasidalijimas priklauso nuo paslaugos. Tai priežastis prašyti tikslaus žemėlapio, o ne manyti, kad visi valdomi produktai turi vienodas ribas. AWS bendra atsakomybė.

Ieškokite spragų ir besidubliuojančio darbo

Tarkime, tiekėjas generuoja konvejerį, nors platformos komanda jau prižiūri patvirtintą diegimo kelią. Nuspręskite, ar tiekėjas turėtų naudoti tą kelią. Du nepriklausomai prižiūrimi konvejeriai gali sukurti prieštaringas kontrolės priemones ir nereikalingų sąnaudų.

Kitu atveju tiekėjas gali manyti, kad klientas turi incidentų komandą, o klientas – kad eksploatavimas įtrauktas. Išspręskite šią spragą prieš naudotojams pradedant priklausyti nuo paslaugos.

CNCF platformų gairės leidžia organizacijoms derinti vidines ir valdomas galimybes. Svarbu, ar gauta patirtis tenkina naudotojų poreikius su aiškia atsakomybe. CNCF gairės.

Naudokite žemėlapį priimdami komercinį sprendimą

Pridėkite atsakomybių žemėlapį prie vertinimo pastabų ir patikslinkite jį taikomame susitarime. Įkainokite darbą, kuris lieka jūsų organizacijai. Įtraukite komponentų tarpusavio ryšių priežiūros kainą.

Platesnes paslaugas teikiantis tiekėjas gali būti vertingas, kai pašalina integravimo darbą ir išlaiko įrodymus per visą gyvavimo ciklą. Vidinis sprendimas gali būti vertingas, kai išskirtiniai reikalavimai pateisina nuolatinę atsakomybę. Spręskite pagal reikiamą rezultatą ir patikrintą apimtį.