2020-05-16 12:14

Ką daryti, kad IT būtų ne inkaras, o verslo variklis?

Auganti konkurencija ir verslo tempas reikalauja greitų sprendimų ir sparčių žingsnių, bet, atrodo, kad jūsų informacinių technologijų (IT) departamentas tapo inkaru veiklai? Terminai praleidžiami, biudžetai viršijami, o gaunami produktai nebetenkina aktualių poreikių? Ir situacija negerėja, nepaisant to, kokias švelnias ar griežtas vadybines taktikas naudojate, kad ir kiek IT komandų samdote ar pakeičiate? Jūs – ne vienintelis.

Tokiais atvejais dažnai griebiamasi gelbėjimo rato, vardu „Agile“. Ši programinės įrangos vystymo ir projektų valdymo metodika produktų išleidimo ciklą gali paspartinti dešimtimis kartų. Bet daug kur tampa savotišku pleistru ant voties.

Laikais, kai ekonomika skaitmenizuojasi ir IT iš aptarnaujančios veiklos, t.y., kaštų centro, tampa pelno centru, ši sena problema tik gilėja. Ir ta problema nėra žmonės.

Skirtingi interesai

Vadovų akyse IT dažnu atveju buvo – ir vis dar daug kur yra – tiesiog skyrius, departamentas ar padalinys, į kurį kreipiamasi, kai reikia spręsti bet kokius IT klausimus: nuo sugedusio kompiuterio ar nulūžusio serverio, iki naujos sistemos naujam produktui kūrimo ar diegimo.

Tačiau toje trumpoje abreviatūroje telpa du priešingi poliai: programinės įrangos kūrėjai ir infrastruktūros inžinieriai.

Skiriasi jų atsakomybės, skiriasi interesai, skiriasi vertinimo rodikliai. Vieni užsiima kūrimu, kiti – rizikų valdymu. Tačiau nuo to, kaip gerai jie kartu dirba priklauso, kaip greitai ir efektyviai juda visa organizacija. Šie skirtumai formuoja atotrūkį tarp programų kūrėjų ir jų kūrinių veikimą turinčios palaikyti IT infrastruktūros inžinierių. O tai kliudo įmonei judėti verslo greičiu.

Augant tempui ir specializacijai, mažėja tiek programuotojų, kurie suprastų infrastruktūros klausimus, tiek infrastruktūros operatorių, kurie suvoktų programavimo specifiką. Programuotojai vis labiau nesidomi, kaip veikia infrastruktūra, infrastruktūros operatoriai nesidomi programuotojų reikalais.

Programuotojai sprendžia savo užduotis darydami prielaidą, kad infrastruktūra yra paruošta ir jų sistemas beliks tik paleisti. Infrastruktūros inžinieriai įsijungia programuotojams jau baigus savo darbus ir tik tada suvokia, kokios apimties pokyčius IT infrastruktūroje reikės padaryti ir ar apskritai tie pakeitimai įmanomi dėl tinklo reikalavimų.

Tai lemia nuolatinį vėlavimą, biudžetų viršijimą bei konfliktus. O kraštiniu asmeniu paprastai tampu IT departamento vadovas, dirbantis dvipusiu magnetu ir bandantis suartinti tuos du priešingus polius.

Kai žmonės nebesikalba

Atotrūkis tarp minėtų polių didėja, kol pradeda trūkinėti paskutiniai saitai. Tą dažnai signalizuoja tai, kad kad programuotojai patys ima kurti savo įrankius – konteinerius – nedideles modulines aplinkas, skirtas vienai aplikacijai, veikiančias esamoje infrastruktūroje. Ir iš tokių „lego kaladėlių“ greitai statomi reikiami sprendimai. IT infrastruktūros inžinieriams tuomet pakanka tik pasirūpinti reikalingų IT resursų išplėtimu – pridėti naujų serverių ir duomenų saugyklų.

Įžanga į problemą yra tai, kad tos programuotojų „lego kaladėlės“ gyvena savo gyvenimą, pagal savo taisykles, nepaisydamos bendrų IT infrastruktūros taisyklių, reguliuojančių prieigos kontrolę, duomenų apsaugą, veikimo patikimumą, užtikrinančių IT sistemų atkūrimą.

Blogiausia, kad tokiais atvejais IT infrastruktūros operatoriai, kurie atsakingi už patikimą infrastuktūros veikimą ir tinklo saugumą, apie problemas dažnai sužino tik tada, kai paslauga „nulūžta“, o viešumoje pradeda rodytis įmonės klientų duomenys.

Kaip tai spręsti?

Šį IT infrastruktūros ir programinės įrangos kūrėjų atotrūkį patyrėme ir pergyvenome patys. Supratome vieni kitų klaidas ir iš jų išmokome savo pamokas:

  • Požiūrio pokytis. Programinės įrangos kūrėjai yra IT infrastruktūros operatorių klientai. Nesvarbu, ar tai to paties departamento kolegos, ar kita įmonė.

  • Įsitraukimas. IT infrastruktūros architektai turi dalyvauti programuotojų susirinkimuose, taip pat susitikimuose su užsakovais, kad nuo pat programinio produkto kūrimo pradžios būtų galvojama ir apie IT infrastuktūrą, o architektai geriau suvoktų poreikius ir galėtų planuoti resursus: biudžetą, infrastruktūrą, žmones.

  • Tarpininkai. Ugdyti, samdyti arba naudotis paslaugomis specialistų, kurie suvokia IT infrastruktūros reikalavimus ir programinės įrangos kūrėjų lūkesčius. IT pasaulyje tai vadinama DevOps: developers-operations – jie atlieka tarpininkų tarp programinės įrangos kūrėjų ir IT infrastruktūros operatorių, vaidmenį.

  • Automatizuoti savitarnos sprendimai. Kartu su programinės įrangos kūrėjais sukurti automatizuotas savitarnos aplinkas, kurias galėtų valdyti patys programuotojai, kuriose būtų apibrėžtos IT infrastruktūros taisyklės, realizuojančios IT saugos reikalavimus.

  • IT debesija – pinigų krosnis. Viešosios IT infrastruktūros (debesijos) paslaugos yra geras sprendimas, kai norisi greitai paleisti nedidelį produktą, kai įmonės IT infrastruktūra tam neparuošta. Tačiau šiam pradėjus augti, didėjant apkrovai, ilguoju laikotarpiu sąnaudos keleriopai viršys galimas investicijas į nuosavą infrastruktūrą, o perkėlimas atgal į savo IT ūkį taps itin brangus.

  • Hibridinė IT infrastruktūra. Derinti vidinį IT infrastruktūros debesį su viešosiomis paslaugomis, viešajame plėtojant mažiau resursų reikalaujančias, mažesnės svarbos aplikacijas bei jas jungiant per API sąsajas su įmonės vidaus IT debesyje veikiančiomis.

  • Atvirojo kodo sistemos – jos pažangios, dinamiškos ir taupo pinigus. Mes patys naudojame ir klientams siūlome „RedHat“ atvirojo kodo sprendimus. Mums tai – pasiteisinusi kryptis, nes atvirojo kodo sistemos jau įrodė savo patikimumą didelėse organizacijose. Be to, jos evoliucionuoja kur kas greičiau, nes jas kuria šimtai tūkstančių programuotojų. Galų gale jų licencijos nekainuoja, mokama tik už produktų aptarnavimą. Esame paskaičiavę, kad per trejus metus bendrosios išlaidos (TCO; Total Cost of Ownership) atvirojo kodo sistemai yra perpus mažesnės, palyginus su uždarosiomis sistemomis dėl šių licencijų kainos.

Nuomonės autorius yra Artūras Milašauskas, BAIP pardavimų direktorius
52795
130817
52791