Naša in vaša nova rešitev je torej ugledala luč sveta. Žal to nikoli ni nek avtonomen sistem, ki bi v nedogled sam skrbel za sebe in deloval ne glede na spremembe, ki so v informatiki stalnica. Vsak zagon produkcije je zato hkrati tudi zagon vzdrževalnega procesa. Odločitev o tem, ali boste za izboljšave, nadgradnje, prilagoditve in samo infrastrukturo skrbeli sami ali z našo pomočjo je seveda povsem vaša – vsekakor pa je zelo pomembno, da pričnete z vzdrževanjem rezultatov razvojnega projekta že na prvi dan produkcije.

Če se odločite za lastno vzdrževanje, potem vam priporočamo, da sklenete neke vrste interni pisni dogovor, ki bo čim bolj natančno opredelil, kaj vse je predmet vzdrževanja, kakšni so pogoji, ki morajo biti za to izpolnjeni in kako hiter bo odziv v primeru če pride do težav. Če boste nalogo vzdrževanja zaupali nam, potem bomo te pogoje, odgovornosti in druge parametre vzdrževanja seveda dogovorili s pogodbo.

Tudi pri vzdrževanju rezultatov razvojnega projekta ni potrebno izumljati tople vode, ampak lahko dobro prakso razberemo kar iz standardov, ki to področje urejajo. Tak standard je ISO/IEC 14764:2006, ki daje smernice za načrtovanje, izvajanje, nadzor, evalvacijo in zaključek vzdrževalnega procesa. Standard se ukvarja z različnimi vidiki vzdrževalnega procesa:

1. Korekcijski vidik. Če v programski opremi, ki je že v produkciji, zaznate programskega hrošča – in morda to celo ni posledica napake izvajalca, ki vam je na izdelek po vsej verjetnosti dal garancijo – potem bo potreben poseg, s katerim bo takšna napaka popravljena. Tu gre torej za zagotavljanje storitve v situacijah, ko v naši rešitvi zaznamo napako in potrebujemo človeka oziroma ekipo s tehničnim in vsebinskim znanjem, ki bo to napako odpravila. Če izvajalec ne nudi vzdrževanja in je bila celotna projekta ekipa že razpuščena, potem je takšna situacija lahko precej nerodna.
2. Preventivni vidik. Ta je podoben vzdrževanju kvalitetnega vozila. Tudi če ni z avtom nič narobe, ga enkrat letno peljete na servis. Tam z menjavo olja, filtrov in pregledom točk obrabe poskrbijo za to, da boste varni na cesti tudi naslednje leto. Z rezultati vašega razvojnega projekta ni kaj dosti drugače – vsaj občasno je treba preveriti, ali je rešitev še vedno usklajena s sistemskimi in razvojnimi okolji, v katere je umeščena, ali je potrebna kakšna posodobitev, nadgradnja, odprava novih varnostnih tveganj in podobno.
3. Vidik nenehnih izboljšav. Kot vidimo pri vsakdanji uporabi programske opreme, se ta nenehno izboljšuje, posodablja, optimizira in prilagaja novim napravam ali tehnologiji. Tudi vaša rešitev, čeprav morda namenjena le interni javnosti, bi se morala nenehno posodabljati in izboljševati. Le tiste rešitve, ki so podvržene nenehnim izboljšavam, lahko preživijo dolgo obdobje uporabe. Pomislite na Microsoftove pisarniške izdelke, ki so ravno zaradi nenehnega prilagajanja in izboljšav z nami vse od časov, ko nam je zadoščal operacijski sistem DOS. Tudi sami smo razvili rešitve, ki ostajajo v uporabi že par desetletij in so ta čas preživele samo zaradi nenehnih izboljšav in prilagoditev.
4. Vidik prilagajanja. Podobno kot pri nenehnih izboljšavah, moramo poleg samega rezultata razvojnega projekta opazovati tudi okolico. Če je rešitev nastala pred desetimi leti in vidimo, da se naše poslovanje vse bolj seli v računalniški oblak, potem moramo nekaj ukreniti za to, da bo tudi naša, sicer morda redno vzdrževana, a na videz konceptualno zastarela rešitev lahko delovala v oblaku. Če vidimo, da komponente, ki so bile tedaj uporabljene za razvoj niso več konkurenčne, moramo poiskati sodobne nadomestke.

Pri planiranju vzdrževanja mora lastnik nove rešitve vedno razmišljati vsaj o naslednjih stvareh:

• Kakšen obseg vzdrževalnih storitev je treba zagotavljati za rezultat projekta? Odgovoriti si moramo na vprašanje o tem, katere vzdrževalne storitve in pod kakšnimi pogoji morajo biti na voljo, da bomo čim dlje in čim bolj učinkovito pokrivali cilje, ki smo si jih s projektom zastavili.
• Kdo bo odgovorna oseba oziroma katera vloga v organizaciji bo skrbela za to, da se bo vzdrževanje izvajalo optimalno?
• Kako bo potekalo vzdrževanje dokumentacije – spremembe, ki se bodo v okviru vzdrževanja izvajale, terjajo tudi spremembe v dokumentaciji. Brez tega bi hitro zašli v območje tipanja v temi ali celo zavajajočih informacij v ne-vzdrževani dokumentaciji.
• Kako bo tekel proces sprememb? Kdo bo tisti, ki lahko zahteva spremembo, kdo bo o tem razmislil, kdo odobril, kdo realiziral? Brez jasnih pravil o tem, kako naj bi prihajalo do vsebinskih, programskih ali drugih sprememb programske opreme zaidete v situacijo, kjer se odločitve sprejemajo konfuzno, morda celo z vidika enega samega uporabnika in posledično kot plaz rušijo vse, kar ste skozi razvojni projekt koristnega naredili.
• Kako hiter naj bo odziv, ko rabite vzdrževalno ekipo, kakšni stroški bodo s tem nastopili? Ni namreč vseeno, ali zahtevate rešitev nekega postranskega problema praktično v hipu ob 23h zvečer ali v treh delovnih dneh in med običajnim delovnim časom.
• Kdo skrbi za strežniške platforme, ki poganjajo vašo rešitev? Je to vaša lastna ekipa, nek tretji ponudnik? Kakšna zagotovila vam daje, kakšen nivo varnosti, koliko sploh imate vpliva na to, kaj bo ta ponudnik delal za vas?
• Kakšen nivo zagotavljanja kvalitete v fazi vzdrževanja pričakujete? Če smo se v fazi razvoja zavezali nekim visokim normam zagotavljanja kvalitete – bo to izničeno v fazi vzdrževanja?
• Kakšen način komunikacije in kakšen način poročanja pričakujemo od ekipe, ki bo vzdrževanje izvajala?

Iz navedenega je dokaj jasno razvidno, da si na vsa vprašanja v zvezi z vzdrževanjem ne boste odgovorili tistega dne, ko boste rešitev zagnali v produkcijskem okolju. O vzdrževanju je smiselno razmišljati že v fazi razvoja, preigrati različne možnosti in si ustvariti varno mrežo še preden prvi uporabnik sploh naredi prvi klik ali »tap« v produkcijski različici rešitve. Brez te mreže je padec lahko izjemno boleč. Pravočasno razmišljajte o tem, kakšne so vaše lastne kadrovske kapacitete za vzdrževanje rezultatov razvojnega projekta, kakšne možnosti imate na voljo za vzdrževanje infrastrukturnega okolja in seveda kolikšne finančne rezervacije potrebujete za to, da bo v bodoče vaša nova rešitev delovala stabilno in bo še dolgo v koraku s časom.

…in ne pozabite na informacijsko varnost!

Čudovito je imeti na voljo novo rešitev, ki modernizira in optimizira naše poslovanje ali morda celo služi splošni javnosti. Vendar v navdušenju niti za hip ne smemo pozabiti na to, da je praktično vsak izdelek v okviru informacijske tehnologije izpostavljen nenehnim grožnjam. Poskusi vdorov, vohunska programska oprema, kripto napadi, prevare z lažnim predstavljanjem, trojanski konji in številne druge pretnje so kot plevel na polju naših pridelkov. Običajno rastejo hitreje od našega sadja in zelenjave. Zato je ključnega pomena, da naredimo vse za to, da smo čim bolje zaščiteni pred zlikovci in njihovim orožjem.

SRC posveča informacijski varnosti veliko časa in sredstev. Nenehno se usposabljamo na tem področju, da smo v koraku z idejami, metodami in tehničnimi rešitvami tistih, ki samo čakajo na to, da bi pogledali vstran. Skrb za varnost je integrirana že v naš razvojni proces in storitve izvajamo po ključnem standardu na tem področju, to je ISO 27001. Ne glede na to, ali vaša organizacija ima potrebe po upoštevanju tega standarda ali ne, vam za varno uporabo rezultatov razvojnih projektov priporočamo vzpostavitev nekaterih osnovnih norm, ki predstavljajo vsaj tisti temeljni nivo zaščite, ki je nujno potreben za obrambo pred grožnjami, ki so v tesno prepletenem svetu sodobne informatike prisotne praktično ves čas. Zato je dobro na organizacijskem nivoju sprejeti naslednja izhodišča:

• Popišite oziroma jasno formulirajte tveganja. Ocenite verjetnost posamičnega potencialnega tveganja. Ni potrebe po tem, da ustvarite 100 km dolg dokument, ki bi bil sam sebi v namen, vsekakor pa je koristno skleniti nek zavezujoč interni dogovor, ki bo definiral odgovore na vprašanja o tem, kako obvladujete oziroma upravljate tveganja na področju informatike, kje beležite varnostne incidente, kako usposabljate zaposlene za prepoznavanje nevarnosti in prevar ter podobno.
• Definirajte vsaj osnovna pravila vaše varnostne politike. Kako preprečujete prost dostop do vaše strežniške infrastrukture, kakšne minimalne varnostne mehanizme morate uporabljati za preprečitev vdora v vaš informacijski sistem, kako se mora izvajati varovanje podatkov, kaj je minimalna varnostna zahteva za oddaljen dostop do vašega sistema, kdo mora zagotavljati redna izvajanja varnostnih pregledov informacijskega sistema, kdo in kako upravlja s pooblastili za dostop in podobno.
• Opredelite metode zagotavljanja varnostnih kopij, preverite ali potrebujete rezervno lokacijo s strežniško infrastrukturo, opredelite postopke, ki se morajo izvesti za restavriranje podatkov v primeru okvare, vdora, zlonamernega kriptiranja podatkov ali podobno.
• Odgovorite si na vprašanja v zvezi z zagotavljanjem neprekinjenega poslovanja. Kako verjetno je, da bo vaš informacijski sistem še vedno deloval v primeru naravne nesreče, kaj lahko izboljšate s ciljem rešitve takšnega problema? Kako uporaben je bil vaš sistem v obdobju epidemije in kako lahko izboljšate učinkovitost v bodoče? Imate vsaj zagotovljene alternativne vire v primeru daljšega izpada električne energije? Je dostopnost vašega informacijskega sistema v celoti odvisna od enega samega telekomunikacijskega ponudnika? Teh vprašanj je še veliko, nanizanih je le nekaj, za lažjo predstavo.

V kolikor z zagotavljanjem informacijske varnosti nimate izkušenj in tudi nimate virov, ki bi se s tem poglobljeno ukvarjali, se lahko vedno obrnete na nas. Poleg tega, da smo že v osnovi ponudnik poslovnega računalniškega oblaka s posebnim poudarkom na informacijski varnosti,  nudimo tudi specialne storitve s področja varovanja sistemov SRC Secure, varnostno operativni center SRC SOC, rezervni podatkovni center in druge storitve s tega področja.