Vaikka PaaS-ratkaisut (Platform as a Service) eivät yksinään voi muuttaa yksilöiden ja tiimien yhteistyötapoja, ne toimivat usein katalysaattorina organisaatiomuutoksille vastauksena IT-teknologioiden lisääntyneeseen joustavuuteen.
Todellisuudessa PaaS-investoinnin tuoton maksimointi on usein mahdollista vain muuttamalla organisaatioiden rooleja, vastuita (tehtäviä) ja suhderakenteita. Onneksi PaaS-ratkaisut, kuten OpenShift Container Platform, tarjoavat riittävästi joustavuutta, jotta jokainen IT-organisaatio voi itsenäisesti määrittää muutoksen nopeuden ja laajuuden mukana olevien ihmisten ja prosessien suhteen.
Yrityskonttiratkaisun ensimmäisessä vaiheessa tärkein prioriteetti on konttialustan toteuttaminen uutena sovellusten käyttöönottojärjestelmänä. Tässä vaiheessa organisaatiot yhdistävät tutut tehtävät tuttuihin rooleihin vastatakseen kehitystiimin vakiopyyntöihin esimerkiksi tallennusjärjestelmistä, käyttöönottoympäristöistä ja niin edelleen. Seuraavissa konttiratkaisun vaiheissa painopiste siirtyy automatisointiin tai kehittäjien itsepalveluominaisuuksien tarjoamiseen järjestelmänvalvojien työmäärän vähentämiseksi ja kehittäjien autonomian ja reagointikyvyn parantamiseksi. Näin organisaatiot alkavat siirtyä kohti DevOpsia. Yrityskonttiratkaisun viimeisessä vaiheessa ne saavuttavat puhtaamman ja kanonisemman DevOps-mallin, jossa monet aiemmat tehtävät ja aktiviteetit siirretään monialaisille tiimeille, jotka on ryhmitelty sovellusten tai sovelluspalveluiden erityistarpeiden mukaan, ei alustan tai teknologian mukaan.
Tässä viestissä annamme ohjeita tarvittavien organisaatiomuutosten toteuttamiseen ja keskustelemme siitä, miten perinteiset IT-roolit muuttuvat konttiteknologioiden käyttöönoton myötä yrityksessä.
Uusien työpaikkojen yhdistäminen vanhoihin rooleihin
Perusmuodossaan PaaS-organisaatiomalli on suunniteltu siten, että se voi joustavammin ja nopeammin kohdentaa IT-resursseja sovelluksille ajonaikaisena ympäristönä. Vaikka tämä tarjoaa tiettyjä etuja järjestelmänvalvojille, kehittäjät eivät yleensä saa merkittäviä etuja tai uusia ominaisuuksia, sillä tässä vaiheessa yritys voi helposti olla ilman automaatiota, itsepalvelua tai käyttöönottoprosessin radikaalia parantamista. Vaikka PaaS vaikuttaa tässä vaiheessa vain vähän kehitysprosesseihin, se lisää IT-järjestelmän ketteryyttä, jolloin järjestelmänvalvojat voivat paremmin palvella kehittäjien pyyntöjä. Esimerkiksi aiemmin kehitysympäristöä luotaessa useista... virtuaalikoneet Tallennusvolyymien luominen ja käyttöönotto saattoi kestää päiviä tai jopa viikkoja ja vaatia useiden eri ylläpitäjien osallistumista, mutta PaaS:ssa kaikki hoituu paljon nopeammin ja yhden ylläpitäjän voimin. Toisin sanoen kehitystiimit lähettävät pyyntöjä kuten ennenkin, mutta niiden toteuttaminen tapahtuu nyt uuden mallin mukaisesti.
Kohti DevOps-organisaatiota
Käynnistämällä PaaS-palvelun ja siirtämällä IT-operaatioiden asiantuntijat ja sovelluskehittäjät siihen organisaatio voi jatkaa DevOps-menetelmän toteuttamista, joka sisältää muun muassa seuraavat ydinperiaatteet:
- Jaa työ pienempiin vaiheisiinsaada palautetta varhaisessa vaiheessa, vähentää riskejä ja välttää analyysihalvaantumista;
- Automatisoi toimintoja riittävässä määrin, jotta sovellusten käyttöönottoprosessiin ei synny esteitä tai pullonkauloja;
- Tiedon jakaminen – luottamuksen rakentamisen avain;
- Maksa tekniset velat säännöllisesti, varaamalla tietty määrä aikaa jokaisessa työsyklissä systemaattisille parannuksille.
Konttiteknologian käyttöönoton toisessa vaiheessa kehitystiimit alkavat luonnollisesti nähdä parannusmahdollisuuksia, ja yritys siirtyy kohti perinteisempää DevOps-mallia. Perinteistä palvelupyyntöjen lähettämis- ja täyttämismekanismia pidetään nyt pullonkaulana, joten organisaatio pyrkii automatisoimaan toistuvia tehtäviä ja tarjoamaan kehittäjille itsepalveluominaisuuksia. Nämä kehittäjäominaisuudet tietyn pyynnön sisällä määritetään alustan operatiivisten IT-asiantuntijoiden ja sovellusten toimituksesta vastaavien yhteistyöllä. Toisin sanoen järjestelmänvalvojat, jotka toimivat kehittäjien pyyntöjen perusteella, korvataan kahdella edellä mainitulla työntekijäryhmällä, jotka vastaavat kehittäjien itsenäisiä toimia koskevien käytäntöjen määrittelystä ja valvonnasta. Automatisoidut menettelyt auttavat varmistamaan näiden vaatimusten noudattamisen ja koordinoivat toimia, kun tilanteet ylittävät olemassa olevat käytännöt.
Siirtyminen iteratiiviseen aikatauluun, jossa IT-ympäristö ja toimintamalli käyvät läpi iteratiivisia muutoksia ajan myötä, on kriittinen virstanpylväs kypsän DevOps-järjestelmän luomisessa yritykseen. DevOps-menetelmän käyttöönottoaste riippuu kunkin organisaation muutossietokyvystä ja siitä, mitkä muutokset tuottavat eniten hyötyä. Jos esimerkiksi uusien ympäristöjen tai sovellusten luomisen tarve ilmenee harvoin, näiden toimintojen optimointi on vähemmän tärkeää kuin kehittäjän hallinnan vahvistaminen sovelluksen elinkaaren aikana.
IT-organisaatioiden uudet haasteet OpenShiftiin siirtyessä
Tässä osiossa tutkimme rooleja ja tehtäviä, joita OpenShiftiin siirtyneet organisaatiot tyypillisesti käyttävät automaation ja itsepalvelun nopeuttamiseen teknologioiden ja PaaS:n avulla.
Alla olevassa taulukossa luetellaan tärkeimmät korkean tason tehtävät, joita esiintyy kaikissa OpenShiftin käyttöön ottaneissa organisaatioissa, sekä esimerkkejä vastaavista tehtävistä ja taidoista. Tätä tehtäväluetteloa ei pidä sekoittaa työjakorakenteeseen tai tiimin organisaatiorakenteeseen; se on yksinkertaisesti joukko tehtäviä, jotka IT-ympäristön tukemisesta vastaavien on hoidettava konttialustan onnistuneen käyttöönoton varmistamiseksi. Itse asiassa osoitamme myöhemmin, että konttiteknologioiden käyttöönotto luo edellytykset kypsemmälle DevOps-strategialle yrityksessä, mikä puolestaan lisää tiimien sisäistä ristitoiminnallisuutta ja vähentää kapean erikoistumisen riskiä sekä yksilö- että tiimitasolla.
Taulukko 1. OpenShift-tehtävämääritelmät
tehtävät
Vaaditut taidot
IT-infrastruktuurien automatisointi ja käyttöönotto
Works:
- Laitteistoratkaisujen suunnittelu ja rakentaminen
- Alkuasennuksen automaation organisointi ja tuki
- Virtuaalikoneiden ja isäntäkoneiden provisioinnin suunnittelu ja automatisointi
- Datakeskusten suunnittelu ja toteutus
- Linux-järjestelmän hallinta
- Automaatioskenaariot
- Varastointijärjestelmien tuntemus
- Tietoa verkkojen suunnittelusta ja toteutuksesta
- Безопасность
OpenShift-alustan asentaminen ja hallinta
Works:
- Klusteriasennuksen suorittaminen
- Infrastruktuuripalveluiden hallinta
- Alustan skaalauksen hallinta
- Alustatason todennus ja valtuutus
- Linux-järjestelmän hallinta
- Verkkoteknologioiden tuntemus
- Automaatioskriptit (Ansible)
- Varastointijärjestelmien tuntemus
- Konttiteknologioiden ja -arkkitehtuurien tuntemus
- Kubernetes- ja OpenShift-arkkitehtuurien tuntemus
- Alustan turvallisuus
- Valvontaintegraatio
Vuokralaisten käyttöönoton ja IT-kapasiteetin eristämisen hallinta
Works:
- Käyttäjien ja tiimien luominen alustan sisällä
- Kiintiöiden suunnittelu ja hallinta
- RBAC-suunnittelu ja -toteutus
- Kubernetes- ja OpenShift-arkkitehtuurien tuntemus
- Konttiteknologioiden ja -arkkitehtuurien tuntemus
- Automaatioskenaariot
- Hyvä tietämys projekteista, kiintiöistä, roolien määrityksistä ja aikatauluttajien kanssa työskentelystä
Peruskuvien luominen ja hallinta
Works:
- Työnkulun kehittäminen kuvien muokkaamista varten
- Standardeihin perustuvien kuvien kehittäminen
- Linux-järjestelmän hallinta
- Automaatioskenaariot
- Ajonaikaisten sovelluskomponenttien ja väliohjelmistojen määrittäminen
- Konttiarkkitehtuurien tuntemus
- Sovellusten rakennuskehykset
- Hyvä kuvien, kuvavirtojen ja mallien tuntemus
Käyttöönottoputkien suunnittelu ja hallinta
Works:
- Kuljetinstandardien suunnittelu ja dokumentointi
- Pikaoppaiden ja mallipohjien kehittäminen
- Kehittäjäkoulutus
- Lähdekoodin hallinta
- Sovellusten suunnittelu ja toteutus
- Automaatioskenaariot
- Automatisoitu testaus
- Koodin laadun testaus
- Konttiarkkitehtuurien tuntemus
- Muuttumattomien infrastruktuurien tuntemus
- Tietoturva – prosessivaiheiden käyttöoikeuksien hallinta, työnkulkujen hyväksyminen jne.
- Hyvä tietämys OpenShift-malleista, komponenteista, rakennuskonfiguraatioista, käyttöönottokonfiguraatioista, palveluista, reiteistä ja konfiguraatiokartoista
Sovellus- ja testikehitys
Works:
- Sovelluskoodaus
- Automatisoitujen testien kehittäminen
- Testivirheisiin reagoiminen käyttöönottoprosessin aikana
- Sovellusvirheisiin reagoiminen
- Käyttäjän hyväksyntätestaus
- Sovellusten suunnittelu ja toteutus
- Automatisoitu testaus
- Lähdekoodin hallinta
- Sovellusten valvonta
- Pilvinatiivisten sovellusarkkitehtuurien tuntemus
Toiminnan valvonta ja sovellusten hallinta
Works:
- Sovellusten suunnittelu suorituskyvyn kontekstissa
- Sovellusten valvonta ajonaikana
- Sovelluksen skaalaus (tai automaattinen skaalaus)
- Sovellusten saatavuuden hallinta
- Pyyntöjen kiintiöt ja resurssienhallinnan rajoitukset
- Suorituskyvyn ja IT-kapasiteetin testaus
- Sovellusten suorituskyvyn suunnittelu ja toteutus
- Sovelluksen suorituskyvyn seuranta
- Suorituskyky- ja kuormitustestaus
Käyttäjän hyväksyntätestaus
Works:
- Käyttöliittymätestaus (suunnittelu ja käyttäjävuorovaikutus)
- Automatisoitujen testien kehittäminen
- Käyttöliittymien suunnittelu ja testaus
- Automatisoidut testausmallit
- Testauskehykset
- Sovellussuunnittelumallit
IT-organisaatiossa OpenShiftiin siirtymisen myötä syntyvät uudet roolit
Siirtyessämme DevOps-keskeiseen organisaatiomalliin roolierikoistumisten määrä tyypillisesti vähenee, kun taas toimintojen välisten tiimien ja roolien määrä kasvaa yhteistyön maksimoimiseksi. Uskomme, että OpenShiftiä käyttävän IT-organisaation ydinroolit näyttävät tältä:
- Sovellusoperaatioinsinööri TAI Sivuston luotettavuusinsinööri. Aiemmin tätä tehtävää on saatettu kutsua nimellä "Sovelluspalvelimen järjestelmänvalvoja".
- Sovelluskehittäjä/ohjelmistokehittäjä/ohjelmistoinsinööri.
- Klusteri-/sovellusalustan järjestelmänvalvoja. Aiemmin tätä roolia on saatettu kutsua nimellä "Järjestelmänvalvoja" tai "Linux-alustan järjestelmänvalvoja".
- Julkaisupäällikkö/Kokoonpanoinsinööri
RACI-rooli- ja tehtävämatriisi
Lopuksi vertailemme edellä käsiteltyjä tehtäviä ja positioita antaaksemme yleiskuvan siitä, miten DevOpsia OpenShift-alustalla toteuttavan organisaation tulisi rakentaa itsensä. Aluksi alla kuvattuja rooleja voivat hoitaa vanhan, perinteisen organisaatiorakenteen eri haarat. Ajan myötä kuitenkin tapahtuu konsolidaatiota ja uusia sovelluspohjaisia tiimejä syntyy, jotka kattavat suurimman osan tai jopa kaikki alla kuvatut tehtävät.
tehtävät
rooli
Sovellusoperaatioinsinööri / Sivuston luotettavuusinsinööri
Sovelluskehittäjä/Ohjelmistokehittäjä/Ohjelmistoinsinööri
Klusteri-/sovellusalustan ylläpitäjä
Ohjelmistojulkaisupäällikkö / Kokoonpanoinsinööri
IT-infrastruktuurien automatisointi ja käyttöönotto
I
I
R / A
C
OpenShift-alustan asentaminen ja hallinta
C
I
R / A
C
Käyttöönottoputkien suunnittelu ja hallinta
C
C
I
R / A
Vuokralaisten käyttöönoton, eristämisen ja IT-kapasiteetin hallinta
C
I
R / A
I
Peruskuvien luominen ja hallinta
R
C
R / A
C
Sovellus- ja testikehitys
C
R / A
I
I
Toiminnan valvonta ja sovellusten hallinta
R / A
C
C
I
Käyttäjän hyväksyntätestaus
C
R
I
I
RACI-matriisin symbolit
Lähde:
- Vastuullinen – Suorittaja on se, joka tekee tarvittavat toimet tehtävän suorittamiseksi.
- Vastuussa – Vastuullinen henkilö on työntekijä, joka on viime kädessä vastuussa tehtävän oikeasta ja perusteellisesta suorittamisesta tai tuloksen saavuttamisesta; ja hän on myös ainoa, joka voi delegoida työtä muille.
- kuultu – Konsultit ovat tyypillisesti aiheen asiantuntijoita, joilta pyydetään neuvoja; heidän kanssaan ylläpidetään kaksisuuntaista viestintää.
- Ilmoitti – Informoituneet – ihmiset, jotka pidetään ajan tasalla tapahtumista (joskus vasta tehtävän suorittamisen tai tuloksen saavuttamisen jälkeen); he vastaanottavat tietoa yksipuolisesti.
Kuinka tiimit tekevät yhteistyötä DevOps-organisaatiossa
Perinteinen resurssien hankintaprosessi sisältää tyypillisesti resurssipyyntöjen syklin, jotka useat tiimit sitten täyttävät. Lopulta pyytäjä allokoi ja vahvistaa kaikki tarvittavat resurssit. Nämä prosessit ovat usein osittain tai jopa kokonaan manuaalisia, ja ne vaativat tiimien välistä tiheää ja laajaa vuorovaikutusta jokaisen pyynnön onnistuneen käsittelyn varmistamiseksi.
Kuva 1. Perinteinen IT-organisaatio
Yllä oleva kaavio havainnollistaa tyypillistä tiimien välistä suhdetta perinteisessä IT-organisaatiossa. Tässä mallissa tiimit pyytävät töitä muilta tiimeiltä käyttämällä enemmän tai vähemmän muodollisia viestintätyökaluja, kuten tikettijärjestelmää tai sähköpostia. Nämä pyynnöt odottavat sitten jonossa vuoroaan, ja tämä pitkä odotus johtaa usein tiimien välisten suhteiden heikkenemiseen, ellei jopa heikkenemiseen. Tätä jännitettä pahentaa entisestään se, että tiimin jäsenet tapaavat harvoin henkilökohtaisesti ja jakavat tyypillisesti vain välttämättömän määrän tietoa.
Kuva 2. DevOps IT -organisaatio
Tämä kaavio havainnollistaa, miten yhteistyö toimii DevOps-organisaatiossa. Tässä samat tiimit edellisestä kaaviosta ovat luopuneet tehottomasta viestinnästä, joka edisti siiloja, ja korvanneet sen henkilökohtaisilla yhteydenotoilla, luoden jatkuvia vuorovaikutuskanavia tiimien välille. Nämä kanavat edistävät hybridiosaamista, joka auttaa työntekijöitä ymmärtämään ja edustamaan paremmin edustamiensa tiimien tarpeita, haasteita ja kyvykkyyksiä. Tiimit antavat toisilleen mahdollisuuden suorittaa tarvittavat työt automatisoitujen itsepalveluportaalien kautta sen sijaan, että he käsittelisivät toistensa muutospyyntöjä manuaalisesti, kuten aiemmin. Ja näiden viestintäkanavien ansiosta nämä itsepalvelujärjestelmät pystyvät nopeasti mukautumaan palvelemiensa tiimien tarpeisiin. Jotta keskinäistä ymmärrystä ja tiedon jakamista organisaation sisällä voidaan entisestään parantaa, tiimin jäsenet vaihtavat rooleja säännöllisesti saadakseen kokemusta eri tiimien kanssa toimimisesta ja ymmärtääkseen paremmin ylläpitämiään IT-järjestelmiä, mikä lisää niiden ristiintoiminnallisuutta ja arvoa.
Yhteenvetona
Tässä artikkelissa käsittelimme sitä, miten PaaS-ratkaisujen käyttöönotto voi kannustaa organisaatiota omaksumaan DevOps-menetelmän, jossa perinteiset roolit ja tehtävät muuttuvat osana tätä prosessia. Siksi listasimme keskeiset IT-tehtävät, joita organisaatiossa syntyy siirryttäessä OpenShiftiin, sekä niiden suorittamiseen tarvittavat taidot. Esittelimme myös ydinjoukon organisaatiorooleja, jotka syntyvät rakennettaessa monialaisia DevOps-tiimejä, sekä RACI-matriisin, joka yhdistää uudet roolit uusiin tehtäviin. Lopuksi käsittelimme sitä, miten OpenShift-alusta ja siihen liittyvä DevOps-menetelmä voivat muuttaa organisaation organisaatiorakennetta sen siirtyessä perinteisistä hierarkioista ja tiketöintijärjestelmistä monialaisiin tiimeihin, joissa henkilökohtainen viestintä on korkeampaa.
Lähde: will.com
