Kapasite Yönetim i Neden Önem lidir?

Transkript

1 K A P A S İT E Y Ö N E T İM İ ISO 27001:2005 Bilgi G üvenliği Yönetim Sistem i nin Ek A Kısm ında M addesinde ve ISO 20000:2005 IT Servis Y önetim Sistem i 6.5 M addesinde söz edilen K apasite yönetim i hakkında geniş bilgiyi aşağıda bulabilirsiniz. Yönetim i Neden Önem lidir? yönetim i, şirketin IT operasyonlarının yönettiği, kaynakların uygun seviyede planlanm ası ve yönetilm esi için kullanılm ası gereken bir fonksiyondur. nin uygun biçim de planlanm am ası durum u, kaynakların gereksiz kullanım ına veya gerektiği anda kapasite eksikliğinin ortaya çıkarak IT servislerine erişilem em esine neden olabilir. yönetim i aynı zam anda, IT servislerinin etkin planlanm ası, sürdürülebilm esi ve işletilebilm esi için gerekli prosedürlere girdi oluştururur. Yeni sistem lerin, servislerin ve iş çözüm lerinin tasarlanm ası ve devreye alınabilm esi için öncelikle servis kapasite seviyelerinin ve IT bileşenlerinin perform ansının izlenm esi ve yorum lanm ası gerekir. yönetim i, erişilebilirlik yönetim i ile bireb ir ilişkilid ir ve yeni bir servisin veya bileşenin devreye alınm ası aşam asında optim um kapasitenin sağlanm ası için siz e bilgi verir ve böylece süreklilik planınızda da ihtiyaç duyacağınız geri bildirim i elde etm iş olursunuz. yönetim i, IT hizm etlerinin göz önünde bulundurm ası gereken en önem li bileşenlerdendir ve aşağıdaki faydaları sağlar: M üşteri m em nuniyetinde artış IT m aliyetlerinin ortaya çıkm ası ve daha etkin yönetilebilm esi H atalı kapasite planlam anın engellenm esi ve böylece: Kaynakların etkin kullanım ının sağlanm ası İş yükü ihtiyaçlarına uygun yeterli kapasitenin zam anında elde edilebilm esi. yönetim inin diğer faydaları: IT kapasite eksikliklerinden dolayı ortaya çıkan kesintilerin ve kesinti sürelerinin azaltılm ası. S ervis seviye yönetim i sürecinin desteklenebilm esi için kapasite gereksinim lerinin izlenm esi ve ö lçü lm e si. Yönetim i Süreç Akışı yönetim i kendisini sürekli tekrarlayan faaliyetlerden oluşan bir döngüdür. Bu döngünün bileşenlerini aşağıda ki şekilde bula b ilirsin iz. M onitoring - İz le m e yönetim i, kurum içindeki operasyon seviyesi gerekliliklerini ve tüm SLA gerekliliklerinin karşılanm ası için ölçülm esi gereken m etrikleri kapsar. H er kaynak ve servisin izlenm esi, donanım ve

2 yazılım kaynaklarının optim um kaynaklarla kullanılm akta olduğunu ve servis seviye hedeflerine ulaşılabilm esini sağlar. G enellikle m onitoring işlem i bazı toollar (izlem e araçları) kullanılarak yapılır. Toplanan bilgi belirli bir süre kaydedilm eli ve izlenm elidir. yönetim i veri tabanında toplanacak bilgiler, söz konusu param etrenin eğilim ini gösterebilm elidir. Veriler sadece toplam kaynak kullanım ı açısından değil aynı zam anda her bir kaynağın iş yükü açısından da izlenm elidir. Bu izlem e süreci tüm altyapıyı kapsam alıdır. Ö r: U ygulam alar, sunucular ve ağ. Benzer şekilde, her bir servisin de izlenm esi gerekir örneğin kullanıcı ekranının geliş süresi v.b. Bu araçlar (sistem m onitoring toolları) belirlenen sınır değerlerini aştığında alarm verir veya bu durum a yönelik raporlar üretilir. Bu sınır değerleri daha önceden analiz edilen veriler referans olarak alınarak belirlenir ve aşağıdakilere göre tanım lanabilir: Bireysel bileşenler örneğin C PU kullanım ının bir saat içinde % 80 in üzerine çıkm am ası B e lirli S e rvisle r örneğin, bir w eb sitesi sayfasının açılm asının 3 sn. nin üzerinde olm am ası veya transaction oranının dakikada 1000 i aşm am ası gibi. Tüm bu anlatılanlara rağm en kapasite izlem e araçlarının da sistem kapasitesinin bir kısm ını alabileceği ve sistem perform ansına etki edebileceği unutulm am alıdır. Bu nedenle öncelikle perform ans ölçüm lerine ve m üşteri ile yapılan SLA gerekliliklerine odaklanm ak faydalı olacaktır. A n a ly s is - A n a liz D aha öncesinde de anlatıldığı gibi, hangi bileşenlerin izlenm esi gerektiği IT katm anlarına göre b e lirle n e b ilir: S e rvis U ygulam a Arayüz İşletim S istem i D onanım Ağ Bu aşam ada, toplanan ve izlenm ekte olan veri analiz edilm ekte ve tuning için kullanılabilir hale getirilm ektedir. Bu verilerin toplanm ası ile profillerin oluşturulm ası sağlanır. Profiller çeşitli sınır ve alarm değerleri belirlenm esini sağlar. Belirlenm iş olan sınır değerlerin dışına çıkıldığında bu durum un analiz edilm esi ve raporlanm ası gerekir ve ardından uygun düzeltici aksiyonların alınm ası gerekir. G enellikle, tüm sınır değerler, kaynak kullanım ının fazla kullanılm ası durum u veya servis seviyesi gerekliliklerinin karşılanam adığı durum un altındaki değer ile eşleştirilm esi gerekir. Böylece, kapasite yönetim isüreci zam anında işletilerek O LA (operating service level agreem ent) hedefleri ihlal edilm eden, kesintiye uğram adan düzeltici faaliyetler alınabilsin. İzlem e toolundan elde edilen bilgi analiz edilm eli ve böylece norm al kullanım ve servis seviyesi değerlerinin belirlenm esi sağlanm alıdır. Belirlenen param etrelerin düzenli aralıklarla izlenm esi ve belirlenen sınır değerlerinin m evcut durum ile karşılaştırılm ası, istisna durum larının araştırılm asını, O LA seviyesine yaklaşılan durum ların araştırılm asını ve böylece geleceğe yönelik kullanım tahm ininin yapılm asını sağlayacaktır. Toplanan verilerin analizi aşağıdakileri içerebilir: U ygun kaynakların uygun olm ayan dağılım ı U ygulam aların tasarım ındaki eksiklikler Transaksiyon süresinin beklenm edik şekilde artm ası H afızanın yetersiz kullanım ı H er kaynak ve servisin kısa, orta ve uzun vadeli periyotlarla izlenm esi ve m inim um, m aksim um, ortalam a kullanım değerleri kaydedilm elidir. Örneğin, kısa süreli kullanım 24 saatten uzun kullanım ı, orta süreli kullanım 1 4 haftalık kullanım ı ve uzun süreli kullanım bir yıl veya daha fazla süreyi kapsar. Kaynağın zam an içindeki kullanım ı ortaya çıkm ış olur.

3 Bir çözüm ün kabul edilebilir seviyede olup olm adığının belirlenm esinin bir başka yolu da gecikm e süresinin (latency) ö lçü lm e sid ir. Bir sunucu üzerindeki ağır yük, sunucu kapasitesi yeterli olsa da kabul edilebilir seviyenin üzerinde beklem eye yol açabilir. Bu nedenle perform ansı büyük oranda etkileyebilecek ve istisnai durum lar oluşturabilecek konuları ayrıca ele alm ak ve raporlam ak gerekebilir. M odeling - M odellem e M odellem e kapasite yönetim sürecinin m erkezini oluşturur. M odellem e teknikleri ve sim ulasyon yazılım ının etkin kullanım ı, kapasite planınızdaki w hat - if eğer... olursa senaryolarınızın ortaya çıkm asını ve böylece de ihtiyaçların belirlenm esini sağlar. İş y ü k ü p ro fili oluşturun M odeli uygun h a le g e tirin M o d e li oluşturun y ö n e tim i v e rita b a n ı (C D B ) H M o d e li k e sin le ştirin E K u lla n ım a n a lizi W h a t if a n a lizi y a p ın Transaction a n a lizi S im ü la sy o n y a p ın W h a t if a n a lizin i iy ile şt irin Darboğaz a n a lizi M a liy e t a n a lizi M a liy e t A n a lizi Hedefe u la ş ılab ild i m i? H E Planı D ü ze ltic i fa a liy e tle re ka ra r ve rin D e ğ işik lik İste ğ i (R F C )

4 M odellem e en basit ve en ucuz yöntem dir, bu yöntem genellikle sadece deneyim e ve kaynak kullanım ının m evcut seviyesine bağlıdır. G ünlük verilecek pratik ve hızlı kararlar için bu m odel kolaylık sağlarken, daha köklü altyapı değişiklikleri için pilot uygulam alar, prototipler veya kıyaslam alar ya p ıla b ilir. Etkin pilot uygulam alar yürütm ek için m üm kün olduğu kadar çok değişken ile fonksiyonel testler yapm ak gerekir. Test süreci planlanm ış ve belirli bir süre ile sınırlı olm alıdır. Eğer yapılabiliyorsa stres testleri yapılarak, çözüm kırılm a noktasına kadar zorlanm alıdır. Böylece kaynak kullanım ının hangi noktalarda sizi zor durum da bırakacağını öncesinden daha kolay görebilirsiniz. O p tim iz in g O p tim ize E tm e Söz konusu param etreye ait veriyi analiz ettikten sonra iyileştirilebilecek noktalar belirlenm eli ve servisin perform ansı artırılm alıdır. Kabul edilebilir servis seviyesi elde edebilm ek için sistem inizi kaynak optim izasyonu yaparak iyile ştirm e lisin iz. Yeni bir uygulam a veya sistem im plem antasyonu sırasında, genellikle kullanılacak olan uygulam anın kendisine ait optim izasyon önerileri bulunur. Esnek m im ariye sahip uygulam alar genellikle C PU disk veya I/O hızı, ağ bant genişliği açısından kullanım ı genişletilebileceğinden veya düzenlenebileceğinden daha iyi yatırım lar oluştururlar. Change Initiation in B a ş la tılm a s ı D eğişim in başlatılm ası aşam asında analizde yapılm asına karar verilen faaliyetler başlatılır. D eğişim yürütülürken yavaş ve kontrollü bir yönetim tavsiye edilir. Yapılacak herhangi bir değişiklik resm i bir değişiklik yönetim i süreci ile yönetilm elidir. System tuning uygulam alarının m üşteri m em nuniyeti üzerinde büyük etkileri olabilir. D eğişikliğin gerçekleşm esinden sonra, yapılan değişikliğin etkilerini izlem ek önem lidir. Etkiler izlendiğinde, ek değişiklikler yapm ak veya bazı değişikliklerden geri dönm ek gerekebilir. Sonuç olarak, kapasite yönetim i sürecinin etkin kullanım ı ciddi bir analiz ve iş süreçlerinin yoğunluğunun anlaşılm asını gerektirir. M aliyetler, kaasite gerekliliklerinin türüne ve kapasite ihtiyacına göre belirlenir. İzlem e, analiz, tuning ve değişim in başlatılm ası faaliyetleri, kaynak ve perform ans yönetim ine girdi oluşturur. Yönetim inin Alt Süreçleri yönetim i bir kurum da üç seviyede incelenebilir: İş Yönetim i, servis kapasite yönetim i ve kaynak kapasitesi. planlam a, yöneticiler tarafında ne kadar m aliytle hangi kaynaklara ihtiyaç duyulduğunun ortaya çıkm asını sağlayacak bir araçtır. Aşağıdaki şekilde sözünü ettiğim iz üç kapasite yönetim i alt sürecini ve bu süreçlerin kapasite planı ile n a sıl e tkile şim de olduklarını göreceksiniz.

5 İş İş İş P la n la r ı İş İh t iy a ç la r ı IT S t ra t e jis i Ö n gö rü ler E ğ ilim le r Finansal Planlar B ü tçeler... Paydaşların Gözden T a le b i - R FC Servis Servis Gözden G e ç irm e S L A S e rv is K a t a lo ğ u A la rm la r D e ğ iş ik lik le r P ro b le m le r Servis İzlem e... P ro b le m M odel T a le b i - R FC Planı y ö n e t im i veritabanı (C D B ) Kaynak Deploym ent P la n la r ı Developm ent P la n la r ı O la y la r P ro b lem ler A la rm la r D e ğ iş ik lik le r Yönetim i P ro b le m M odel T a le b i - R FC İş K a p a site si Y ön e tim i İş yönetim i seviyesinde yöneticiler ve paydaşlar bir araya gelerek m evcut iş, finansal durum, ekonom ik ve teknolojik faktörleri değerlendirir, gelecekte gerçekleşm esi planlanan iş yükünü ve dolayısı ile IT üzerindeki iş yükünü tartışır. Bu tartışm adan çıkan sonuçlar altyapı gerekliliklerinin ortaya çıkm asını sağlar. Buradaki am aç uygun m aliyet ve riskle, geleceğe yönelik planlam a yapm ak ve gereken projeleri başlatm aktır. Paydaşların bir araya gelip gözden geçirm e yapm a aşam asında, tem silciler birb irle ri ile iş p la n la rın ı paylaşırlar. Bu planlar m evcut kapasite ile karşılaştırılır ve gereken noktalarda kapasite planı göüncellenir. Sürecin çıktısı revize edilm iş kapasite planıdır.

6 İş İş P la n la r ı İş İh t iy a ç la r ı IT S t ra t e jis i Ö n gö rü ler E ğ ilim le r F in a n s a l P la n la r Paydaşların Gözden T a le b i - R FC Planı Se rv is K a p a site si Y ön e tim i y ö n e t im i veritabanı (C D B ) Servis kapasitesi yönetim i aşam asında, kurum kısa dönem li stratejisini ve taktiklerini m asaya yatırır. Buradaki am aç, belirli servislerin uçtan uca değerlendirilerek servis seviyesi anlaşm aları dahilinde kalabilm esi için kaynak ihtiyaçlarının ortaya çıkartılm asıdır. Ö rneğin söz konusu serviste sürekli teknik sorunlar yaşanıyorsa, bu seviyedeki kararlar daha stratejik veya reaktif verilerek sorunun o an çözüm e kavuşm ası sağlanabilir. D iğer taraftan bazı dönem lerde erişilebilirliğin korunm ası için de çeşitli önleyici faaliyetler alınabilir, örneğin, Yılbaşı zam anında yoğunluktan dolayı kesintilerin ve kullanıcı tim e out larının engellenm esi için kapasitenin artırılm ası için yılbaşından iki hafta önce çalışm a yapılm ası. Servis Servis Gözden G e ç irm e S L A S e rv is K a t a lo ğ u A la rm la r D e ğ iş ik lik le r P ro b le m le r Servis İzlem e... P ro b le m M odel T a le b i - R FC Planı y ö n e t im i veritabanı (C D B ) S e rvis kapasite yönetim i sürecinin çalışm asını sağlayacak girdi değişiklik yönetim i sürecinden (m evcut serviste bir değişim olm ası sonucunda veya servis kataloğuna yeni bir servis eklenm esi durum unda) veya servis kapasitesini etkileyen ve bilinen bir problem den kaynaklanıyor olabilir. Bu alt sürecin çıktıları genellikle değişiklik talepleri (R FC ) veya kapasite planının revize edilm esidir. K aynak K apasite Yönetim i Kaynak kapasite yönetim i seviyesinde, karar verm e genellikle daha tactik veya reaktif seviyede gerçekleşir. Buradaki am aç altyapı dahilindeki kapasiteyi ve perform ansı yönetebilm ektir. Bu aşam ada başlatılacak olan görevler donanım optim izasyonu, servislerin yeniden planlanm ası veya dier kısa dönem li faaliyetler olabilir.

7 Planı y ö n e t im i veritabanı (C D B ) Kaynak Deploym ent P la n la r ı Developm ent P la n la r ı O la y la r P ro b lem ler A la rm la r D e ğ iş ik lik le r P ro b le m M odel T a le b i - R FC B u a lt sü re c in ç ık tıla rı, d e ğ işik lik ta le p le ri v e y a k a p a site p la n ın ın re v ize e d ilm e sid ir. Planlam a Süreci Kontrol Listesi Aşağıdaki kontrol listesi, sizlere bir kapasite planı hazırlanm ası aşam asında yardım cı olabilm ek için hazırlanm ıştır. K ap asiten iz için kilo m etre taşları b elirleyin H er projede olabileceği gibi, proje yöneticisinin bir program yapm ası gerekir. Bu program M S Project veya Excel de hazırlanabilir. H azırlanan program /proje planı yayınlanm alı ve projeniz ilerledikçe güncellenm elidir. Fazlara yönelik belirlenm iş olan kilom etre taşları için tarihler belirlenm elidir. M evcu t D o kü m an ların ızı B ir A raya G etirin Bu aşam ada, zaten kullanm akta olduğunuz doküm anlarınız, kaynaklarınız, stres testleri sonuçlarını, pazarlam a öngörüleriniz, sunucu ve ağ m im ari çizim leriniz, operasyonel rehberleriniz ve diğer kaynaklarınızı kapasite planınıza alm ak üzere bir araya getirin. K ick off toplantısı yapın planlam a yöneticisi bu toplantıyı paydaşları bir araya getirm ek, projenin am acı hakkında konsensusa varabilm ek, hedef tarihler konusunda anlaşm aya varm ak, sorum lulukları atam ak için yapm alıdır. Toplantı sonucunda tutulacak notlar saklanm alıdır. O L A /S L A /K P I G erekliliklerin i O rtaya Ç ıkartın D etaylı anlaşm alarınız ve bu anlaşm alarda tanım lanm ış ölçütler olm adıkça, gerçekçi bir kapasite planı oluşturm ak m üm kün değildir. O LA lar ( operating level agreem ents), S L A le r (service level agreem ents) ve KPI lar (Key Perform ance Indicators) anlam lı bir kapasite planı hazırlanm asını sağlar. D iğer taraftan bu ölçütlerin anlam lı olm ası da gerekir. Belirlenm iş bir servis seviyesi gerekliliği varsa, bu ihtiyacın nereden doğduğu belirtilm elidir, çünkü her SLA ölçütü takibi bir m aliyete neden olacaktır. G enellikle bu ölçütler sistem perform ansının başarısını ortaya çıkartır. Ö r: Kişinin bir w eb sayfası açılana kadar beklediği süre e rişile b ilirlik kullanıcının ihtiyaç duyduğunda ulaşm ak istediği bilgiye erişebilip erişem ediği. S u n u cu ların ızın p e rfo rm an s g e rekliliklerin i b elirleyin O LA/SLA/KPI gerekliliklerinin tüm sistem in perform ansını ortaya çıkartm akta olduğunu anlatm ıştık. D aha detaylı bakacak olursak bir bileşenin perform ans

8 g e re kliliğ in in, b ir se rvisin ta m am ını etkileyeceği gerçeğini unutm am alıyız. Ö rneğin, belirli bir servisteki gecikm e, front end sunucuları, SQ L sunucuları ve ağaltyapı bileşenlerinden kaynaklanan gecikm elerin toplam ından dolayı ortaya çıkabiliyor olabilir. Bu aşam ada, kapasite planı yapanların ve sistem altyapı m ühendislerinin tüm servis bileşenlerini incelem eleri ve perform ans göstergelerini bileşen seviyesinde belirlem eleri gerekir. İş yükü gerekliliklerinin ortaya çıkartılm ası İş yükü gereklilikleri tem el iş yükü param etreleridir (örneğin, transactions/se c, logons/sec, SQ L queries/sec, or user profiles stored) Belirli bir servisin birden fazla iş yükü gerekliliği olabilir ör: C PU, m em ory, depolam a kapasitesi, portlar vb. O L A /S L A /K P I S tres T esti G ereklilikleri Bu aşam ada iş yükü, perform ans ve kullanım hedeflerine ulaşabilm ek için çeşitli bileşenler arasında ilişki kurulm ası gerekir. Bu aşam anın çıktısı genellikle bir rapor veya bir grafiktir. Bu korelasyonlar tam am landığında belirli bir iş yükü durum unda, bir bileşenin nasıl davranacağını anlatacaktır. ( örneğin, n adet kullanıcı, saniyede n adet transfer gerçekleştirirse C PU kullanım ı ve işlem in gerçekleşm e gecikm esi ne olur). Yedeklem e ihtiyacının tanım lanm ası Bu aşam ada, kapasite planlam a takım ı, gelecekte gerçekleşebilecek bir kesintinin sonucunda ne tip yedek sistem ler tutulabileceğini ortaya çıkartm alıdır. Bu kesintiler yeni bir sistem e geçişten veya kaynak kesintilerinden kaynaklanıyor o la b ilir. G erçek büyüm e eğilim lerinin analiz edilm esi Ö ngörü (forecast) ile karşılaştırm a Bu aşam ada, geçm işte gerçekleşen değerler ile gelecekte öngörülen veriler karşılaştırılır. Bu analiz, m üşterilerin geçm işte ne kadar kapasite kullanm ış olduklarını görm elerini ve böylece geleceğe yönelik planlarını ortaya koym alarını sağlaya caktır. İş Y ü kü G ereklilikleri İçin S ınır D eğ erleri B elirleyin Servis perform ans gereklilikleri (OLA/SLA/PT). S unucu perform ans gereklilikleri İş yükü, perform ans ve kullanım ölçüt korelasyonu. K apasite m odellem e yapın İş yükü, stres testi, geçm iş veri analizi gibi yöntem ler kullanarak ihtiyaç duyduğunuz kapasiteye ulaşabilm ek için nelere ihtiyaç duyduğunuzu ortaya çıkartın. B u lg u ların ızı, varsayım ların ızı, sın ırların ızı ve g eleceğ e yö n elik beklentilerinizi doküm ante edin M odellem e sonucunda elde ettiğiniz bulguları doküm ante edin. B ir kap asite p lan ı taslağ ı o lu ştu ru n, so n h alin e g etirin ve p ay d aşla rın ız ile paylaşın Yazın, gözden geçirin ve planı yayınlayın G erektiğ in d e kap a site p lan ın ızı g ö zd en g eçirin ve g ü n celleyin Plan yaşayan bir doküm an olm alıdır. Bazı faktörler değiştiğinde güncellenm elidir. Kaynak: M OF Capacity M anagem ent