käytännön polku DevOps-maturiteettiin

mikä tahansa ketterä menetelmä on turha ilman todellisia DevOps-käytäntöjä. Tunnussanaa käytettiin väärin monissa järjestöissä. Jos sanotaan, että on kypsynyt ketteriä joukkueita ja on DevOps-insinööri tai DevOps-tiimi, jotka eivät todennäköisesti ole menossa oikeaan suuntaan. DevOps on kulttuuri eikä joukkueen nimi tai nimitys. Ottaa mallia CMM (Capability Maturity Model) tämä yritys on auttaa organisaatiota tietää, missä he seisovat DevOps matka ja tie eteenpäin. Kehitys-ja Ops-ryhmien välisellä aivoriihellä tätä voidaan laajentaa ja räätälöidä organisaation tarpeisiin.

mikään luku ei ole huono, koska se auttaa yksilöä tai organisaatiota kasvamaan.

onnellinen asiakas

toisin kuin CMM, tämä ei ole malli, joka sinun täytyy todistaa mitään sertifiointiorganisaation. Ainoa sertifikaatti, jonka saat, on onnellisilta asiakkailtasi tai liikekumppaneiltasi. Se on malli, jolla itse heijastaa ja auttaa liiketoimintaa kasvamaan. Jokaisen IT-tiimin tarkoituksena on luoda arvoa tekemällä kestävää, ennakoitavaa ja laadukasta toimitusta.

tämä on yksinkertainen malli, jonka kehittäjästä CxO: Hon voi ymmärtää ja suhteuttaa.

ennen kuin keskustelen mallista. Meidän on ymmärrettävä tämän mallin tarve. Monta vuotta sitten Melvin Conway tutkielmassaan ” miten komiteat keksivät?”keksi opinnäytetyön, josta tuli kuuluisa Conwayn lakina.

mikä tahansa organisaatio, joka suunnittelee järjestelmän (määritellään laajasti), tuottaa mallin, jonka rakenne on kopio organisaation viestintärakenteesta.

laki perustuu siihen päättelyyn, että jotta ohjelmistomoduulit toimisivat, useiden ihmisten on kommunikoitava usein keskenään. Siksi järjestelmän ohjelmistorajapintarakenne heijastaa sen tuottaneiden organisaatioiden sosiaalisia rajoja, joiden yli kommunikointi on vaikeampaa.

katsotaan, miten tämä toimii ohjelmistokehityksessä todellisella skenaariolla. Radha rakentaa etupään näyttöä, joka näyttää tuotteen yksityiskohtaiset ominaisuudet. Sano, että tämä tuote on matkapuhelin. Harvat yhteiset tuotetiedot ovat väri, hinta,mitat, luokitukset jne. Uusi asetus tuli näyttää SAR arvo luurin. Hänen suunnittelemansa näyttö toimii mikropalvelupuhelulla. Hän puhui sunilille, joka työskentelee data Teamissa. Hän sanoi, että he voivat lähettää tietoja vain tasatiedostoina. Kahden moduulin välillä on selvä katkos. Tämä on skenaario jokainen IT joukkue törmää, jos ei kaikki 100% kertaa, mutta suurin osa kertaa. Tämä on vain suunnittelukysymys. Ongelma on laajempi. Entä jos toisen joukkueen prioriteetit ovat hyvin erilaiset kuin sinun joukkueesi? Vaatimuksesi saattavat olla heille alin prioriteetti, kun sidosryhmäsi ovat takanasi.

ensimmäinen askel onnistuneeseen DevOps-toteutukseen on avoin organisaatiomuutosten myötä.

organisaatiomuutokset

sallikaa minun käsitellä 5 kypsyystasoa:

  1. Initial: tässä vaiheessa, tiimit työskentelevät siiloissa ja on vain, tarvitaan yhteistyötä. Kun palaverissa kaikki joukkueet yhdessä, jos kysyt kuka omistaa ”tuote” sinulla ei ole mitään kädet ylös. Aika markkinoille on tyypillisesti pidempi, menee kuukausia ja joskus vuosia. Prioriteetit on asetettu joukkuetasolla, mutta ei tuotetasolla. Tämä johtaa siihen, että jokaisella joukkueella on omat prioriteettinsa. Koska määriteltyä prosessia ei ole, jokainen yritys on kuin keksisi pyörän uudelleen. Tämä johtaa laatukysymyksiin ja pidempiin aikajänteisiin. Ryhmä tekee enimmäkseen manuaalisia operaatioita ja manuaalisia interventioita. Sekä.. tämä ei ole huono tila. Näin suurin osa kehityksestä alkaisi.

2. Toistan: tiimit työskentelevät yhä siiloissa. Joukkueen sisällä on jonkinasteista automaatiota. Kun kriisi iskee, tiimi määrittelee oman prosessinsa ja seuraa, kunnes kriisi päättyy. Vain hyvä uutinen on, että jotkut näistä voivat tulla toistettavissa prosesseja, kun kriisi iskee uudelleen.

3. Määritelty: tämä on hyvä lähtökohta kylvää DevOps kulttuuri keskitetty joukkue. Tämä tiimi ymmärtää erilaisia teknologioita, joita Dev-tiimit käyttävät ja työkalut perustuvat nykyiseen tarpeeseen. Keskitettynä joukkueena ei ole helppoa seurata, mitä kukin joukkue tekee, joten osa päätöksistä jää joukkueiden kokeilemisen varaan. Keskusryhmä koostuu tyypillisesti asiantuntijoista ja dev-tiimeissä on joitain ihmisiä, joilla on perusymmärrys ja-tietämys.

4. Onnistunut: koska keskeinen DevOps-tiimi ymmärtää organisaation työkalumaisemaa, testataan useita ympäristöjä ja työkaluja. Johdonmukaisia ja toistettavia prosesseja seuraa useita tiimejä. Työkaluketju valitaan mieluummin käyttötapausten kuin henkilökohtaisten valintojen perusteella. Kaikkien prosessien valvontatyökalut otetaan käyttöön ja niitä käytetään paljon tiimeissä päätöksenteossa.

5. Optimoida:

hyvän johtajan menestyksen määrittelee se, ettei hänellä ole seuraajia, vaan kyky luoda suuria johtajia.

DevOpsin maturiteetin viimeinen vaihe on saada DevOpsin joukkue katoamaan. Tämä voi näyttää intuitiiviselta. Tässä vaiheessa DevOps on osa Tuotekehitystiimiä eikä erillinen kokonaisuus. Infrastruktuurin käyttäminen koodina, konteissa, orkestraatiossa jne. nollakosketus on saavutettu. Nyt jos soitat kaikille, jotka työskentelevät tuotteen ja kysyä kuka omistaa tuotteen, sinulla on joitakin luottavainen kädet nostaa epäröimättä. Seurantatyökaluista saatuja tietoja käytetään uusien työkalujen (kuten infrastruktuurin, ohjelmointikielten, tekniikoiden) valintaan. Päätökset perustuvat tietoihin henkilökohtaisten mieltymysten sijaan. Tuotetiimi on valmis ottamaan koodin käyttöön milloin tahansa ja milloin tahansa. He rakastavat ”liikearvoa” ja kohtelevat sitä lemmikkinä. Kaikkea muuta kohdellaan kuin karjaa.

DevOps-Kypsyysmalli.

Vastaa

Sähköpostiosoitettasi ei julkaista.