CHIP Online - Arşiv: Kasım 2003 DOWNLOAD Microsoft Operations Framework

CHIP | KASIM 2003 Deneyim paylaşımı MOF (Microsoft Operations Framework) Kısaltmalara alışık Microsoft kullanıcıları MOF’un bir an için yeni bir Microsoft ürünü olduğunu düşünebilirler. Ancak bu sefer konumuz yeni bir ürün değil, bir süreç. MOF sayesinde, Microsoft’un kendi deneyimlerini ve iş ortaklarından kazandığı deneyimlerini süzerek, bu tür süreçler kullanma ihtiyacında olan kurum ve kuruluşlar ile paylaşma yoluna gittiğini söyleyebiliriz. Bu daha çok temel servis çözümleri ve Bilgi Teknolojileri hizmetlerinin yönetimi gibi iki kavram arasında gelişiyor. MOF’u, bu terime yabancı bilgi teknolojileri profesyonelleri için tek bir cümle ile tanımlamak istersek, söylenecek en doğru şey “MOF’un bir pratikler birikimi olduğu” olacaktır. Bu sayede tekerleği kimsenin tekrar tekrar icat etmesi gerekmiyor, yeni bir Şrmada olsanız bile işe sizden önce başlamış ve başarılı olmuş Şrmaların süreçlerinin nasıl olduğunu bilerek başlıyorsunuz. Gerçekten de konunun derinine indikçe göreceksiniz ki, MOF neyi nasıl yapmamız gerektiğini dayatan bir kurallar dizisi değil, daha çok pratikte ne tip yöntem ve süreçlerin iyi sonuçlar verdiğini ve size katkı sağlayabileceğini gösteren bir örnekler ve tecrübeler topluluğu. Esnek yapısı sayesinde de kurallar dizisi vermek yerine, size yolunu gösterip kendi iş süreçlerinizi oluşturmanızı sağlayan bir bilgi. MOF tabii ki önce çalışma süreçlerinizi bağımsız bir göz ile değerlendirip nerelerde iyileştirme yapmanız gerektiğini açık bir şekilde görmenizi sağlamak ile başlıyor. MOF’u birinci dereceden ilgilendiren grup ise, Microsoft teknolojilerine uygulanacak operasyon süreçlerinden, planlama ve uygulama aşamasında sorumlu IT (Bilgi Teknolojileri) profesyonelleri. Aslında kısaltmalar ve yeni yeni kavramlar kafa karıştırıcı olsa da, MOF hakkında konuşup ITIL’den hiç bahsetmemek haksızlık olur. Özellikle de bu işin kökeninin ITIL olduğu ve Microsoft’un MOF süreçlerinde temel olarak ITIL tecrübesini kullandığını düşünürsek. Bu yüzden önce ITIL hakkında çok kısa bilgi verip sonra MOF’u incelemeye devam edeceğiz. ITIL: Bir deneyim kütüphanesi Information Technology Infrastructure Library: Bilgi teknolojileri altyapı sistemi kütüphanesi. Adından da anlaşılacağı üzere ITIL, aslında 1980’lerin son yıllarına doğru yazılan 60 kadar kitaptan oluşmakta. Bu kitaplar CCTA, (Central Communications and Telecom Agency) yani İngiltere Merkezi İletişim ve Telekom kurumu tarafından yazılmış. ITIL, kurumun kraliçenin emriyle kendi süreçlerini daha verimli hale getirmeye çalışırken ortaya çıkan bir birikimin ürünü. Bu birikimin kaybolup gitmesini istemeyen CCTA, bu bilgiyi, devletin de bu süreçleri kullanarak daha hızlı iş yapar hale getirilmesini sağlamak için paylaşmış. Daha sonra özel Şrmaların da ilgi gösterdiği bu bilgi, özellikle Avrupa ülkelerindeki IT Şrmalarınca çok kabul gören bir başlangıç noktası olmuş. En iyi sonuç üreten iş yapış şekillerini örnekleyerek açıkladığını söyleyebileceğimiz bu 60 kadar kitap, geniş bir kabul görme oranına sahip. Şu anda artık 60 kitaptan çok bir k 222 CHIP | KASIM 2003 İİİİİİİİİİ ARAŞŞTIRMA DOSYASI MOF tecrübe birikimi olarak düşünebileceğimiz bu bilgi, herkes ile paylaşılıyor. Bu kitaplar 1980 yıllarında yazılmış olmalarına rağmen, o tarihten bugüne ilk hali ile kalmamıştır. Elbette edinilen tecrübe arttıkça kitaplar da yenileniyor. En son güncelleştirilme 2000-2001 döneminde yapılmış. Şu anda bu görev uluslararası düzeyde ITSMF (Service Management Forum) grubu tarafından üstlenilmiş görünüyor. Bu konuda daha detaylı bilgiye www.itsmf.com sitesinden ulaşabilirsiniz. Artık bir de facto standardı olan ITIL, uluslararası bir kullanıcı grubunun yanında, bu konuda geliştirilmiş araçları, dünyada ve Türkiye’de sertiŞkalı uzman danışmanları, eğitim ve kitapları kapsıyor. ITIL servis ve yönetim proseslerinden oluşuyor. Bahsettiğimiz prosesleri günlük servis sağlanması sırasında kullandıklarımız ve uzun süreli planlama ve gelişme için kullandıklarımız diye iki bölümde sıralayabiliriz. Bu prosesleri ITIL için açıklamayacağız, ancak bahsettiğimiz prosesler sadece ITIL değil, ITIL’i kullanılarak Microsoft tecrübesini ekleyip geliştirilen MOF’u da çok yakından ilgilendiriyor. Bu proseslerin aslında ne anlam ifade ettiğini MOF’u anlattığımız bölümlerde kısa kısa anlatıyor olacağız. Her ne kadar MOF, ITIL ın zaten geniş kabul gören tabanını kullansa ya da ITIL evrimini zaten Microsoft’unda içinde bulunduğu endüstri liderlerinden faydalanarak geçirse de sonuçta iki tecrübenin farklılık gösterdiği bir yer var. Aslında tahmin etmesi hiç kimse için zor olmasa gerek. Adından da anlaşılacağı üzere MOF,Microsoft teknolojilerini kullanarak çözüm süreçleri yaratılmasına yardımcı oluyor. Bu Microsoft’a kendine ait sistemler ile bir iş akış süreci oluşturma fırsatı verdiği için çok daha detaya girebiliyor, yedekleme gibi bir işte hangi gruplara hangi hakları vererek bu işi en güvenli yapabileceğinizi bu anlamda MOF söyleyebilirken; ITIL ise prosesleri ve tanımlamaları yaptıktan sonra neyi nasıl yapacağınızı, hangi ürünü kullanacağınızı size bırakıyor. Dolayısı ile MOF un girdiği türde detaylara giremiyor. MOF’un ve bu tip bir oluşumun nasıl ortaya çıktığına değindikten sonra, biraz da bizim Şrmamızın MOF gibi bir sürece neden ihtiyacı olduğuna değinebiliriz. IT sektörünü düşünürsek, aslında IT’nin üretime katkı için burada olduğu herkes tarafından sorgusuz sualsiz kabul edilebilecek bir gerçek. Etrafımızda her gün büyümekte ve gittikçe şartları daha ağırlaşmakta olan bir yarış var. Üretim ve hizmet sektöründeki tüm Şrmalar bu hızlı değişim süreci içinde, her gün birçok farklı kararı, çok daha hızlı bir şekilde uygulamaya geçirmek zorunda kalıyorlar. Böyle bir sektörde ister bir Şrmanın bilgi işlemi olarak, ister ayrı bir Şrma olarak varolsun, bir IT grubunu en çok zorlayan şey değişime bu kadar hızlı ayak uydurmak olsa gerek. Her gün kontrolünde olan ve üretim için kritik uygulamaların üzerinde çalıştığı makinelerin sorumluluğunu taşıyorlar. Üzerinde her yapılan değişiklik ile aklımıza gelen ya da gelmeyen bir sürü riskler alan IT grubu, bu tip bir süreç yardımı ile riskleri biraz daha öngörebilir, yapmak istedikleri değişiklikleri nasıl, hangi süreçlerden geçerek yaparsa hızlı ve doğru sonuçlar alabileceğini daha iyi tahmin edebilir hale geliyor. Burada ise esas olan, yazının başında da belirttiğimiz gibi Microsoft’ un tecrübeleri. MOF’un IT dünyasında neden bu kadar kritik olduğunu anlamak için, iş dünyasının karşılaştığı sorunları bir düşünmek ve iş dünyasının IT’den ne beklediğini anlamak gerekiyor. İş dünyasını bir rota dahilinde giden bir uçağa benzetebiliriz. İçindeki yolcular uçakla yolculuk ederlerken hava boşluğu gibi sorunlar ile karşılaşacaklardır. Dünya çapında ya da sadece Türkiye’de iş yapmak, aynı uçak örneğinde olduğu gibi tahmin edilemeyecek hava boşluklarını, yani riskleri de beraberinde getiriyor. Müdür ve daha üst seviyedeki kişiler, her gün bilemeyecekleri ama tahmin etmeye çalıştıkları krizler ile geçen bir süreçte karar almayı, Şrmalarının da aynı hızla bu kararları uygulaması ve hayata geçirmesini beklemekteler. IT uzmanları aldığı yedeklerin ihtiyaç olduğunda kullanabilir olduğundan emin olmaya çalışır, bir işe başlamadan önce çıkabilecek sorunları da hesaplayarak bir planlama yapması beklenir. Mesela “Bizim yeni işletim sistemini, tüm makinelere yüklememiz için üç iş gününe ihtiyacımız var,” diye işe başlayıp beş günde işi bitirmenin kabul edilemez olduğunu ya da çok soruna yol açacağını her IT uzmanı bilir. IT uzmanından atılan adımlarda riskleri düşünmüş ve kendi önlemlerini buna göre almış olmasının beklenmesi, aslında zor olsa da gerçektir. Bu noktada IT’- den beklenen yeni sorunlarla gelmesi değil, çözümün bir parçası olmasıdır. İyi bir IT servisi dendiğinde beklenen nedir? 1Zorunlu sağlanması gereken servislerin sağlanması. Müşterinizin ya da sizden hizmet alan grubun kullanmak istediği servisler. Bunlar internet bankacılığı olabilir, cep telefonu hizmeti olabilir, hatta bir MSN hizmeti bile olabilir. 2Güvenilir servis. Müşteri istediğinde, istediği sürece mevcut olan servis. Burada amaç servisi sadece vermek değil, devamlılığını da sağlamaktır. 3Verimli servis. Yani sizin hizmet sağladığınız Şrmanın, o servisi kullanarak vereceği hizmet sonrasında bir de belirli bir oranda kar etmesi gerekiyor. Sizin bu işteki masrafınız, müşteriye bu hizmeti kullandığında kar bırakabilmeli. Burada müşteri derken her zaman dış müşterilerden bahsetmiyoruz. Örneğin bir bilgi işlem departmanı için satış grubu da bir müşteridir. İşte, bu bahsettiğimiz niteliklere sahip bir servis ver- MOF Testi: Siz de MOF değerlendirmesini hiç bir ücret ödemeden yapabilirsiniz. k 224 CHIP | KASIM 2003 İİİİİİİİİİ ARAŞŞTIRMA DOSYASI MOF mek, riskleri görebilmek bir gecede kazanılan bir yetenek değildir. Kendimizi günün şartlarına uydurarak en iyi servisi verir hale gelmemizde MOF süreçleri, Microsoft tecrübelerini kullanarak bizi destekliyor. Peki biz MOF’un neresindeyiz ? Henüz MOF hakkında çalışmaya başlamamış olabilirsiniz, ancak kendi prosedürleriniz ve prosesleriniz vardır. Bunların bir kısmı veya hepsi, aslında MOF süreçleri ile benzerlikler gösterebilir, dolayısı ile aslında bazı konularda baştan başlamaya değil, nerede olduğunuzu fark etmeye ihtiyaç vardır. Eğer Şrmanızda MOF süreçlerini oturtmak istiyorsanız, bu konuda çalışmaya başlamadan önce yapılacak en uygun şey gelişmesi gereken alanların belirlenmesi olacaktır. Bu hizmet danışmanlarca verilmektedir ancak Microsoft’un web sitesinde bir de online versiyonu var. Ücretsiz olarak ulaşabileceğiniz bu siteyi, Şrmanızı tarafsız olarak değerlendirme şansınız olacağı için tavsiye ediyoruz. Bu web sitesine www.microsoft.com/mof adresinden MOF Self-A ssessment Tool başlığına tıkla yarak ulaşabilirsiniz. Bu siteden MOF’un kapsadığı herhangi bir fonksiyonu seçerek, kendinizi istediğiniz alanda değerlendirme şansınız var. Yani isterseniz sadece güvenlik ile ilgili ya da değişim yönetimi ile ilgili nerede olduğunuzu öğrenmeniz mümkün. Organizasyonel anlamda kendisinin çok iyi durumda olduğunu düşünen birçok Şrmanın, bu testlerde bilip de ihmal ettikleri ya da bilmedikleri şeyler ile karşılaşacaklarından eminiz. Kritik döngü MOF her bir servis çözümüne bir çalışma birimi olarak bakar ve MOF süreci döngüsü diye belirttiğimiz adımları takip ederek sonuca ulaşır. Bu, özellikle uygulama, geliştirme ve altyapı kurma konusunda önemlidir. Doğru bir sonucu ortaya çıkartabilmek için Değişim, İş, Destek, Düzeltme şeklinde özetleyebileceğimiz bir döngü süregelmektedir; buna MOF süreci döngüsü denir. Şimdi, MOF sürecinde bir değişikliği hayata geçirmek için gerekli 4 adımlık döngüyü birlikte inceleyelim. 1. Değiştirme: Değişim alanı, seri değişiklikler yönetim tarafından onaylandığında başlar. Bu alan, değişim yönetimi, konŞgürasyon yönetimi ve üretim yönetimi konularını içerir. Aslında bu adımda bir proses ya da prosedürün değişiminden bahsedebileceğimiz gibi, bir program ya da dokümantasyon, roller, sorumluluklar ve tabii ki bilgisayar gibi donanım malzemelerindeki değişimi de kapsar. Bu alan, yapılan hazırlığın hayata geçirilip geçirilmeyeceğini de ortaya çıkarır. 2. Operasyon: MOF’un çoğunluğu ITIL’e bağlı olsa da, operasyon alanı tamamen Microsoft’un Şkridir. ITIL, yazının başında da belirttiğimiz gibi ürün bağımsız geliştirilmiş bir yapı olduğu için belirli bir ürünün nasıl yönetileceği hakkında bilgi vermez. MOF, bu alanı, ayrıntılı olarak Microsoft ürünlerinin projelendirilmesi aşamasından başlayarak, yönetim, kurulum, güvenlik hakkında bilgi vererek kullanır. Şu anda www.microsoft.com/mof web sitesinden ulaşabileceğiniz iki ürün bilgisi var: Windows 2000 Operasyon serisi ve SQL Server 2000 Operasyon rehberi. Operasyon alanı, aslında gözden geçirmeleri, prosedürlerin doğru çalışıp çalışmadığını, istenilen sonuçların alınıp alınamadığını gözlemler ve hatta personelin yeterli olup olmadığını kontrol eder. 3. Destekleme: Hem destek hizmetlerinin yönetimi, hem de problem yönetimi olarak Yardım Masası (Helpdesk), Destek alanının bir fonksiyonudur. Burada ITIL’ in bizim günlük yaşantımızdan farklı olan iki tanımı vardır, bunları belirtmekte fayda var. Biz normalde bilgisayar ile ilgili karşılaştığımız her soruna problem derken, ITIL burada farklılık gösterir. Bunu biraz sonra açıklayacağımız SLA’de ölçülebilir, karşılaştırılabilir değerler elde etmek için yapmak zorundadır. Kullanıcının günlük işlerini yaparken verdiği bir komuta karşılık, bilgisayardan beklediği ya da alması gereken tepkiyi alamadığında oluşan sorusu bir “incident”tır. Incident’lar sistemlerin devamlılığı ile ilgili değillerdir. Sadece kullanıcının kendisini ilgilendirirler, belki de kullanıcı yanlış bir şey yapıyordur. Bu tip çağrılar Helpdesk (Yardım masası) tarafından çözülür. Problem ise genel olarak tüm sistemi ve bir grup ya da daha fazla kullanıcıyı etkileyen sorunlar için yapılan tanımlamadır. Uzun süre çözülemeyen incident’lar birden fazla kişide de görülmeye başlamışsa o zaman bir problem olurlar ve başka ve bu konuda daha uzman bir grup tarafından ele alınırlar. Destek alanındaki başarı tanımı ise, sistemin SLA anlaşması çerçevesinde söz verilen sürede çalışır hale getirilmesidir. Destek alanı temel işlevinin yanında, yazılım geliştiriciler gibi farklı gruplar ile birebir iletişimde olup geri besleme de yapmaktadırlar. Servis anlaşması, (The Service Level Agreement) soruna verilmesi gereken müdahale zamanını, uygunluk ve işlevselliği kontrol eder. Aslında SLA başlı başına başka yazı konusu olabilecek bir başlık. Ancak bağlantılı olduğu için kısaca açıklamaya çalışalım. SLA: Servis anlaşması SLA; bir önceki paragrafta da söylediğimiz gibi, sizin hizmet sağlayan Şrma olarak, hizmet verdiğiniz yer ile müşteri memnuniyeti, ortalama çözüm süresi gibi konu başÜcretsiz Test: İnternet üzerinden MOF’ta nerede olduğunuzu değerlendirmeniz mümkün. k 226 CHIP | KASIM 2003 İİİİİİİİİİ ARAŞŞTIRMA DOSYASI MOF lıklarında nasıl bir servis vereceğinizi belirlediğiz bir anlaşmadır. Burada önemli olan nokta, ölçebileceğiniz alanlar üzerinden anlaşmayı yapıyor olmaktır. Eğer müşteri memnuniyeti gibi bir alanda değerlendirilebilir sonuçlar ortaya koyacak araçlarınız yoksa, SLA’de daha baştan kaybettiğinizi söyleyebiliriz. Tabii ki bir de sizin hizmet sağlamak için hizmet aldığınız bazı yerler olabilir. Mesela telefon ile yardım masası hizmeti veren bir yer iseniz, telefonlarınızın 7*24 çalışabilir olması önemlidir. Bunun için Şrmanızın da kendisine hizmet sağlayan Şrmalarla anlaşmalar yapması gerekir. Bu anlaşmalara OLA (Operating Level Agrement) Operasyon seviyesinde anlaşmalar denir. SLA’in sağlanabilmesi için OLA çok kritiktir. Bu konuda daha önce verdiğimiz örneğin üzerinden gidersek, 7*24 telefonda destek hizmeti veren Şrmanın telefonlarının da 7*24 çalışması çok önemlidir. OLA sizin SLA maddelerini karşılayabilmeniz için vazgeçilmez bir alt anlaşmadır. Bu örnekte olduğu gibi, kendinizi korumak ve sizinde aldığınız hizmetin kalitesinden emin olmak için telefon Şrması ile yaptığınız anlaşma bir OLA’dır. Yeri olduğu için destekleme alanı içinde SLA konusuna girmiş olsak da, iki anlaşma daha çok optimizasyon alanına girer. Şimdi bu alanı inceleyelim. 4. Optimizasyon: Bu alan servis kalitesini ve maliyetini ilgilendirir. Bir değişiklik hayata geçirildikten sonra, bu konuda çalışan takım diğer takım üyelerinden ve hatta müşterilerden de gelebilecek değişiklik önerilerini toparlayarak, gelecekte uygulamak için bir kaç değişiklik önerir. Release grubu, önerilen değişiklilerin kazançlarını ve kayıplarını inceler. Kabul görmesi halinde döngü tekrar başlar. Optimizasyon aşamasında çokça bahsettiğimiz diğer aşamalarda olduğu gibi, faklı fonksiyon ve gruplarla beraber çalışılır; Şnans, bu işte çalışabilecek iş gücünü belirlemek için yönetim grubu, vs. MOF proses modeline ait yönetim gruplarının neler olduğu, MOF proses modeli alt açıklamalı şemada gösterilmiştir. MOF’un proses modelini açıkladıktan sonra, takım modelinin ne olduğunun çok kısaca üzerinden geçip, risk modeli ile devam edeceğiz. MOF’un takım modeli coğraŞ veya hiyerarşik olarak (ait oldukları departmanları) ayırt etmeksizin bir servis veya iş için takımlar oluşturulmasına izin vermektedir. Sanal da diyebileceğimiz bu takımların en büyük faydası, farklı proje deneyimleri olan ve farklı nitelikteki insanları (tabii ki iş yüklerini de göz önüne almak gerek) birlikte kullanabilmenize olanak sağlamakta, bu da en optimize iş gücü kullanımı olarak karşımıza çıkmaktadır. MOF, hangi grupların oluşturulması ve bu gruplarda bulunan insanların ne gibi becerilere sahip olması gerektiğini ayrıntılı biçimde tanımlamıştır. Bu konu ile derinlemesine ilgilenenler www.microsoft.com/mof sitesinden daha fazla bilgiye ulaşabilirler. MOF risk modeli Bu konuda önce bazı tanımlamaları yapmak ileride ortaya çıkacak soruları daha baştan giderecektir. Risk dediğimizde, kayba yol açabilecek bir olay ihtimalinden bahsediyoruz. Bunun olup olmayacağı garanti değildir, eğer olacağını kesinlikle biliyorsak bu olay artık risk tanımına girmez; çünkü bir gerçektir. Risk yönetimi ise bu hasar yaratabilecek olay ortaya çıkmadan önce, sizin belirlediğiniz stratejidir. ?____IT operasyonlarında çoğunlukla dört temel grupta toplayabileceğimiz risk faktörleri vardır. ?____İnsan: her zaman hata yapabilir, tecrübe eksikliği olabilir, baskılı bir ortamdan kaynaklanabilir ama her zaman hesaplanması gereken bir risktir. ?____Proses: Sadece kötü dokümante edilmiş bir proses bile bazen tüm operasyonu etkileyecek sonuçlar ortaya çıkartabilir. ?____Teknoloji:IT elemanları tüm prosesleri çok iyi takip etseler bile bir donanım ya da işletim sistemi hatası kendi başına risk yaratır. ?____Dış etkenler: Buradaki riskler diğerlerine göre biraz daha tahmin edilebilir, ancak asla kontrol edilemez risklerdir. Mesela Türkiye’de yaşıyorsanız sizin IT departmanınız için deprem daima bir risktir. Ya da virüs saldırısı gibi olabilme ihtimali olan ancak kontrol edemeyeceğiz riskler de dış riskler kapsamına girer. MOF, riskleri 4 ana modelde toplar Performans: Altyapınız kullanıcıların beklentilerini karşılamıyor olabilir, belki sadece beklentileri yanlış ve gerçekçi olmadığından ya da gerçekten altyapınız beklenen hızı sağlayamadığı için. Güvenlik: Güvenlik her zaman bir risk unsurudur. Bazen altyapı gereği kaynaklara zor ulaşılır ve kimse yeterli kaynaklara işini yapmak için ulaşamadığından sorunlar baş gösterebilir. Güvenliğin çok gevşek olduğu durumlarda ise herkes her yere ulaşabildiği için bilgi silinmesi gibi sorunlar ile karşılaşılması riski vardır, ya da bilginin gizli kalması sorun olur. Çeviklik: Altyapı çok düzgün çalışıyor olabilir, ancak iş dünyasının gerektirdiği hızda değişim yapmanız mümkün olmuyordur. Örneğin kapasite sorunu her IT çalışa- MOF Döngüsü: Doğru bir sonucu ortaya çıkartabilmek için Değişim, İş, Destek, Düzeltme şeklinde özetleyebileceğimiz bir döngü süregelmektedir, buna MOF süreci döngüsü denir. k 228 CHIP | KASIM 2003 İİİİİİİİİİ ARAŞŞTIRMA DOSYASI MOF nının karşılaştığı sorunlardan biridir. Ya da sistemde yapılacak değişiklikler sistemin yapısı gereği çok karmaşık oluyordur ve hem çalışanların hem de bu makinelerin hizmet verdiği grubun, bu değişikliğe alışması uzun sürüyordur. Bütçe: Aslında MOF’ta takımların sanal olabileceğinden ve her takımda farklı departman ve bilgi seviyesindeki insanların bulunmasının öneminden bahsetmiştik. İşte bu tip takımların faydasını bir risk hesaplaması yaparken bile görebiliriz. Sisteminizin bazen ne kadar iyi çalıştığının önemi yoktur, herkesin içtenlikle kabul edeceği bir gerçeği burada unutmamak gerekir: Bir sistem işe kazanç getireceği miktardan daha fazla masrafa yol açıyorsa (sadece kurulumundan bahsetmiyoruz, bakım ve gerektiğinde geliştirme olarak da maliyeti kazancından yüksekse) o zaman yatırımınızın geri dönmesi anlamında size bir faydası olmayacağı açıktır. Amerika’da ikiz kulelerden birinde çalışan bir banka, kulelerden birinin Şziksel olarak hasar görmesi sonucu çalışamayacağı riskini öngörmüş ve bunu çözmek için diğer kuleye de bir bilgi işlem bölümü kurarak çalışmaya devam etmeye karar vermiştir. Dolayısı ile kulelerden birinde hasar oluşursa diğer kule üzerinden çalışmaya devam edilebilir. Ancak iki kulenin birden hasar görme olasılığı çok düşük görülmüş ve “bu risk gerçekleşirse ne yaparız?” sorusu yanıtsız bırakılmıştır. Burada anlatmak istediğimiz, bazı risklerin çözüm maliyeti çok yüksek ya da bazı risklerin oluşma ihtimali çok düşük görülebilir. Peki hangi risklere öncelik vermemiz gerektiği, özellikle maliyet önemli ise -ki her zaman önemli bir konudur- nereden başlamamız gerektiğini nasıl bileceğiz? Burada MOF bize risk hesabı da diyebileceğimiz bir yöntem sağlıyor. Günün şartlarına göre bazı risklerin değeri artıp bazıları azalacağından, bu hesaplama yöntemi önünüzü görmeniz için bir başlangıç, bir referans olacaktır. Takımınızın önündeki en önemli riski görmesini sağlayacaktır. MOF, riski olabilirlilik ve etkinin çarpımı olarak tanımlar. Bunu bir örnek ile açıklarsak; Diyelim ki bir kişinin otobüs ile yolculuk yaparken kazaya uğrama olasılığı % 60, bu kaza sonucu ölme olasılığıysa (1 ile 5 arasında bir değer verirsek) 2 olsun. Buradaki risk 60*2=120 birimdir. Şimdi, bir uçağın düşme olasılığını % 10 farz eder ve uçak düştüğü takdirde bu kişinin ölme olasılığına 1 ile 5 arası bir değer vermemiz gerekirse 5 diyebiliriz. Buradaki risk 10*5=50 birimdir. Görüldüğü üzere, bazen olasılık oluştuğunda ortaya çıkacak hasar çok daha yüksek olmasına rağmen, risk tablosunda üst sıradaki risklerden biri olmayabiliyor. Tabii ki buradaki rakamları bizim şu an örnek vermek için yaptığımız gibi rasgele değil, gerçek verilere dayanarak almak gerekiyor; ancak örneğimizin bir Şkir verdiğini umuyoruz. Sonuç olarak diyebiliriz ki, olma olasılığı çok düşük, ancak verebileceği hasar çok yüksek olacak riskler listenin en alt sırasına inebilir. Bunun yanında olma olasılığı daha fazla, ancak olduğunda hasar olma ihtimalinin ya da hasarın daha düşük olduğu riskler listenin başında kalabilir. Bir riski görüp ona çözüm üretildiğinde bu riskin vereceği hasar azaltılmış olacaktır, ya da alternatif çözümler ile etkileri azalacaktır. Dolayısı ile listenin başında bulunan bir risk listenin en sonuna inecektir. MOF’un ana hatları ile ilgili verebileceğimiz bilgi şu an için bu kadar, ancak bu konu ile daha detaylı bilgi almak isteyenler için birinci kaynak olarak Microsoft’un web sitesini tavsiye ediyoruz (http:// www.microsoft.com/mof/). Maalesef internette arama yapanlar bu konuda pek fazla Türkçe kaynak bulunmadığını göreceklerdir, İngilizce kaynak bulmak ise mümkün. Yine bizim çok derine inmeden tanıtmaya çalıştığımız ITIL konusunda http://www. itil.co.uk/ adresinden bilgi bulabilirsiniz. ITIL konusunda çok değilse bile MOF hakkında olduğundan daha fazla Türkçe kaynağa erişmeniz mümkün. Önümüzdeki ay ilgilenenler için ITIL konusunda daha derinlemesine bilgi vermeye çalışacağız. Bu ayki yazımızı bu konuda kursa katılıp uzmanlaşmak isteyenler için ek bilgi vererek bitirmek istiyoruz. Şu anda MOF ile alakalı iki adet kurs var. Birincisi 1737 numaralı Microsoft Operations Framework Essentials isimli, iki gün süren bir kurs. Bu kursun sonunda doğrudan sertiŞka alıyorsunuz, şu an için bu kursun bir sınavı yok. Katılmak için de herhangi bir ön şart bulunmuyorsa da, ITIL kavramına yabancı olmamanız öneriliyor. Bizce de bu kurstan gerekli faydayı sağlayabilmek için ITIL’in bu yazıda çok azına değinilen bazı konseptleri hakkında bilgi sahibi olmakta fayda var. MOF ile alakalı ikinci kurs 1787 numaralı Microsoft Operations Framework Changing Quadrant isimli ve üç gün sürüyor. MOF’un temellerinin anlatıldığı bir önceki kurs, bu kurs için bir ön şart. Yine bu kurs için de bir sınav yok. Ancak bizim tavsiyemiz MOF’ta uzmanlaşmak isteyenlerin mutlaka ITIL sertiŞkasına sahip olmaları. _ Cihan Baykal, cihan@chip.com.tr MOF Proses Modeli: MOF döngüsünü oluşturan unsurlar. 257

Arşiv Listesi