Održavanje aplikacije uz System Center Operations Manager i Team Foundation Server

Developeri i administratori rame uz rame

mainDa bi softverski sustav dobro funkcionirao u produkcijskom radu jednako je bitna kvaliteta samog softvera kao i sigurnost te stabilnost infrastrukture na kojem se softver izvršava. Developeri razvijaju softver, a administratori se brinu oko infrastrukture. U slučaju problema u radu, a iskustvo nam kaže da su oni neizbježni, važna je komunikacija između onih koji se brinu o softveru kao i onih koji održavaju infrastrukturu. No, komunikacija, a pogotovo između različitih rola u timu, jedan je od najčešćih uzroka problema u IT branši. Kako izbjeći lošu komunikaciju kao usko grlo između administratora i razvojnog tima? Može li nam u tome pomoći alat?

Microsoft je već dugi niz godina prisutan među alatima za podršku razvoju softvera. Visual Studio zajedno sa Team Foundation Serverom čini skup ALM (Application Lifecycle Management) alata, odnosno alata za upravljanje životom aplikacije. Međutim, dosad su Visual Studio i TFS uglavnom bili orijentirani samo na ciklus razvoja softvera. Život aplikacije širi je pojam od procesa razvoja. Aplikacija nije gotova kada je završen razvoj. Život aplikacije traje i u fazi održavanja u produkciji. Održavanje nije mirovanje. To je proces koji uključuje monitoriranje, praćenje problema, iznimaka i nepredvidivih događaja sustava koji živi svoj život, ali i postavljanje dijagnostike i pronalaženje rješenje kada se uoči problem. Microsoft je sa skupinom System Center obitelji, a posebno s alatom System Center Operations Manager (SCOM) omogućio upravo to. SCOM je moćno, enterprise rješenje za monitoring kompletnog sustava i svih njenih dijelova. SCOM i TFS dva su sasvim različita alata. SCOM je u potpunosti prilagođen administratorima, a TFS je do sada bio uglavnom namijenjen razvojnom timu.

Karika koja nedostaje.

devops Konektor koji povezuje TFS i SCOM punim nazivom naziva se System Center Management Pack for Microsoft Visual Studio Team Foundation Server 2010 Work Item Synchronization. U svijetu Microsoftovih servera, SCOM polako postaje standard. Administratori koji koriste SCOM znaju da je to alat na kojega se mogu nadograđivati različiti dodaci, takozvani Management Packovi. Može se reći da je SCOM, osim što predstavlja alat za nadzor sustava i mreža, ujedno i platforma za nadogradnju različitim alatima koji se na njega nadovezuju. TFS Connector, kako ga se skraćeno naziva, povezuje Operations Manager Application Performance Monitoring (skraćeno APM) i TFS, odnosno radne stavke (work items) od TFS-a. APM omogućuje praćenje i dijagnostiku .NET aplikacija na izuzetno dubokom nivou. Moguće je do detalje definirati koje događaje, .NET iznimke i ostale eventualne pogreške u radu same aplikacije želimo pratiti. Možemo definirati i kritične granice performansi i odaziva naše aplikacije, što je posebno zanimljivo za web aplikacije i servise. Ovisno o našim željama upozorenje (alert) doći će nakon određenog broja ili postotka slabijeg odaziva određenog servisa ili asp.net stranica. Detalja ima jako puno i tko se želi tome posvetiti može uz pomoć APM-a postaviti sustav koji prati rad jedne ili više aplikacija na našim serverima upravo onako kako zahtjeva sustav koji se nadzire. APM kao dio SCOM 2012 sustava izgrađen je na temeljima AviCode aplikacije. U verziji SCOM-a 2007 mogli smo ugraditi AviCode Management Pack i dobiti sličnu funkcionalnost. U novoj verziji, sada se to naziva APM. AviCode je do nedavno bio neovisna aplikacija, te nije dolazio zajedno sa SCOM sustavom. Riječ je aplikaciji istoimene kompanije koju je Microsoft akvizicijom iz 2010. godine uzeo u svoje vlasništvo, te nakon toga integrirao kao sastavni dio nove verzije SCOM alata, gdje mu je i logično mjesto. Preuzimanjem AviCodea, Microsoft je dobio već gotovi proizvod koji omogućuje upravo ono što je do tada u lepezi alata za upravljanjem životom aplikacija nedostajalo. AviCode kao i njegov nasljednik APM često se naziva profiler alatom, međutim, APM to nije. Profiler alati služe mjerenju performansi aplikacija i servisa tijekom razvoja i testiranja. APM namijenjen je monitoriranju performansi i zdravlja sustava u produkcijskom radu. APM ne mijenja aplikaciju koju monitorira niti značajno utječe na brzinu sustava. Ne samo APM, već SCOM u cjelini namijenjen je za dugotrajno praćenje sustava i predviđen je za 24/7 način rada. APM je definitivno alat koji se odlično uklapa u Microsoftovu ALM viziju. Ono o čemu Microsoft, kada je riječ o upravljanju životom aplikacija, već dulje vremena govori, sada je ostvareno. Središnjica Microsoft ALM sustava je Team Foundation Server. Logično je onda očekivati da se i SCOM preko APM-a poveže na TFS. Tu ulogu dobio je TFS Connector.

SCOM i TFS – alati koji pričaju

connector_arhitektura SCOM TFS Connector je skup servisa koji se izvršavaju na SCOM Root Management Serveru (RMS) i potiho sinkroniziraju SCOM sa TFS radnim stavkama. Nakon što SCOM preko APM-a dohvati alert o neželjenom događaju ili problemu sa performansama u radu monitoriranog sustava, administrator ima mogućnost staviti alert u stanje „Assign to engineering“, odnosno poslati alert na daljnju analizu i rješavanje razvojnom timu. Kako razvojni tim saznaje za taj alert? TFS Connector automatski takve alarte dohvaća i na osnovi njih kreira radnu stavko na TFS-u tipa „Operetional Issue“. Još prilikom instalacije i konfiguracije, TFS Connector sa SCOM strane ugrađuje servis koji prati događaje aplikacije, a na strani TFS-a kreira novi tip radne stavke i dodaje upite koji omogućavaju razvojnom timu da imaju uvid u otvorene probleme uočene na produkcijskom okruženju. Radna stavka Operetional Issueosim što će obavijestiti razvojni tim o problemima na produkciji, također će sadržavati podatke o događaju koji je problem uzrokovao, uključujući i razne .NET dijagnostike koje je SCOM uspio prikupiti preko APM servisa za nadzor .NET aplikacija.

Sinkronizacija TFS-SCOM funkcionira i u drugom smjeru. Kada razvojni tim napravi svoj dio posla te problem riješi ili ga zatvori iz bilo kojeg razloga te tu promjenu označi u TFS radnoj stavci, ona postaje vidljiva i u SCOM-u. Administrator produkcijskog okruženja koji prati stanje sustava preko SCOM-a, može u svakom trenutku vidjeti koji je status uočenog problema. Da li je u fazi obrade, rješavanja ili je riješen i čeka se isporuka rješenja na produkciju. Kod velikih sustava gdje je nemoguća ili neefikasna manualna razmjena informacija između administratora i razvojnog tima, ovakav sustav nije samo koristan nego i nužan. No, osim što se ovakvim alatom uvodi siguran prijenos informacija između administratora i developera, uvodi se i transparentnost. Točno se zna i bilježe svaki problem u produkciji, vrijeme njegovog uočavanja, rješavanja te isporuke rješenja. U svakom trenutku vidljivo je na kojim zadacima vezanim uz rješavanje problema na produkciji radi koji član razvojnog tima. Zahvaljujući takvoj transparentnosti, puno je lakše objektivno procijeniti kvalitetu našeg sustava, ali i troškove njegovog održavanja.

Moj kod ili tvoj server?

Imamo odličan sustav za monitoriranje, uočavanje problema te prenošenje informacija između developera i administratora. No, ništa od toga ne garantira nam da ćemo efikasnije rješavati probleme. Prije opisani alat, garancija je transparentnijeg upravljanja sustavom na produkciji. Međutim, što kada na produkciji uočimo problem kojeg ne možemo niti ponoviti, a samim time ni riješiti na razvojnom okruženju. Svi koji se bave razvojem softvera znaju da je ovo vrlo česta pojava. Izlika „Kod mene radi“ toliko je česta da je Microsoft sa posljednjom verzijom Visual Studio uveo posve novi skup alata sa idejom da izbjegne takve situacije, izbije iz rukava standardnu ispriku programera. Jedna od krilatica Visual Studia 2010 bila je „no more not repro“, nikad više neponovljivog buga. Ako ga uoči i tester, vidjet će ga i developer. Intellitrace je dio debuggera koji omogućava da se razne debug informacije promatraju kroz prošlo vrijeme. Sustav na kojem se debugira kroz Intellitrace omogućava da naknadno pogledamo stanje svih bitnih značajki aplikacije, uključujući i stanje varijabli, stack trace, popis threadova u trenutku koji je već prošao, a ne samo onako kako smo to standardno navikli koristeći debugger, odnosno samo u sadašnje vrijeme. Intellitrace to radi tako dobro da ga i danas mnogi nazivaju „historical debugger“. Gdje je onda problem? Problem je u tome što, da bismo koristili Intellitrace moramo imati i Visual Studio na stroju na kojem želimo izvršiti dijagnostiku. Nažalost, kada je u pitanju produkcijska okolina, time sve ovo pada u vodu. Koji administrator će dopustiti da se Visual Studio instalira na neki od produkcijskih servera te još tamo radi nekakva debug analiza? Microsoft je toga bio svjestan i problem je riješio nadolazećom verzijom Visual Studia. Cijelu Intellitrace funkcionalnost izdvojio je iz Visual Studia i za potrebe analize u produkciji, upakirao ga u jednu PowerShell datoteku. Da bi se takav Intellitrace koristio na nekom serveru potrebo je samo dodati jedan PowerShell modul, bez ikakve instalacije ili promjene na bilo kojem sistemskom djelu sustava. Dijagnostika koja se zatim radi na produkcijskom okruženju pokretanjem jedne PowerShell komande, ne sprječava nesmetani rad sustava. Nakon završetka dijagnostičke sesije, sve debuger informacije spremaju se u log datoteku. Log datoteku preuzima razvojni tim i na osnovi njega u razvojnom okruženju radi retroaktivnu analizu događaja. Učitavanjem te datoteke unutar Visual Studija otvara se intellitrace izvještaj i daje se mogućnost programerima da u svom okruženju analiziraju događaje koji su se prije dogodili na produkcijskom serveru. Bez ikakve smetnje jedni drugima, developeri se dalje bave debugiranjemi daljnjim razvojem, a administratori u miru administriraju produkcijski sustav.

Svatko radi svoj posao, okreće svoj kotačić u procesu, a opet rede zajedno na životu iste aplikacije. Suživot dvoje potpuno različitih ljudskih podvrsta, developera i sistemaša nikad nije bio lakši, ali samo ako se koriste pravi alati za odgovarajuću namjenu. Team Foundation Server za razvojni tim i skup System Center alata za IT sistemski odjel polako postaju nezaobilazan standard ozbiljnih organizacija, a pogotovo onih koji svoj IT odjel temelje na Microsoftovim platformama. Povezivanjem ta dva alata dobit ćemo još uređeniji sustav i omogućit ćemo upravljanje životom aplikacije – ALM od početka razvoja do održavanja sustava u produkciji.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>