Artūras Milašauskas, BAIP pardavimų direktorius
Auganti konkurencija ir tempai 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.
Tuo tarpu gelbėjimo paketas, vardu „Agile“, produktų išleidimo ciklą paspartinęs dešimtimis kartų, daug kur tampa savotišku pleistru ant voties.
Laikais, kai ekonomika skaitmenizuojasi ir IT iš aptarnaujančios veiklos – kaštų centro tampa pelno centru, tai tampa jau nebe niežuliu, o nuolatine migrena ir karščiavimu. Problema yra sena, ji tik gilėja ir tai nėra žmonės.
Bendri reikalai, skirtingi interesai
Vadovų akyse įmonės IT dažniausiai buvo (ir vis dar daug kur yra) tiesiog IT – skyrius, departamentas, 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, diegimo.
Tačiau toje trumpoje abreviatūroje telpa du skirtingi poliai: programinės įrangos kūrėjai ir IT 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ų ir kliudo IT 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 specifikas. Programuotojai vis labiau nesidomi, kaip veikia infrastruktūra, infrastruktūros operatoriai nesidomi programuotojų reikalais.
Programuotojai sprendžia savo užduotis laikydami, 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 nuolatinius vėlavimus, biudžetų viršijimus bei konfliktus. Kraštiniu asmeniu visada tampu IT departamento vadovas, dirbantis dvipusiu magnetu ir bandantis suartinti tuos du priešingus polius.
Skyrybos ir slapta mutavusios problemos
Atotrūkis vis didėja iki kol pradeda trūkinėti paskutiniai saitai – tada, kai programuotojai patys pradeda kurti savo įrankius – konteinerius – nedideles modulines aplinkas, skirtas vienai aplikacijai, veikiančias esamoje infrastruktūroje, taip pat naudodami viešąsias IT infrastruktūros (debesijos) paslaugas. Ir iš tokių lego kaladėlių greitai statydami veiklos prašomus sprendimus.
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ą.
O pagrindinis problemos faktorius – IT infrastruktūros operatoriai, kurie atsakingi už patikimą infrastuktūros veikimą ir tinklo saugumą, sužino tik tada, kai paslauga „nulūžta“, o viešumoje pradeda rodytis įmonės klientų asmeniniai duomenys.
Kaip tai spręsti?
Būdami dalis didelės „INVL Technology“ grupės, kurioje veikia ir kibernetinio saugumo, IT infrastruktūros ir programinių sistemų bei produktų kūrimo įmonės, šį 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 iš veiklos, 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ą, žmogiškuosius.
- 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į. Kai kur tai yra atliekama ne žmonių, bet procesų ir praktikų lygyje.
- 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žesnio kritiškumo aplikacijas bei jas jungiant per API sąsajas su įmonės vidaus IT debesyje veikiančiomis.
- Atvirojo kodo sistemos – pažangūs, dinamiški 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.
