https://www.buraksenyurt.com/Burak Selim Şenyurt - Dokuman2018-10-06T18:40:04+00:00Matematik Mühendisi Bir Bilgisayar Programcısının NotlarıBurak Selim SenyurtBlogEngine.Net Syndication Generatorhttps://www.buraksenyurt.com/opml.axdBurak Selim SenyurtMatematik Mühendisi Bir Bilgisayar Programcısının Notlarıtr-TRBurak Selim Şenyurt0.0000000.000000https://www.buraksenyurt.com/post/itil-in-farkina-vardimITIL'ın Farkına Vardım2018-10-06T18:05:00+00:00bsenyurt<p><img style="float: right;" src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/itil_intro.jpg" alt="" />Merhaba Arkadaşlar,</p>
<p>Seksenli yıllarda İngilizlerin Central Computer and Telecommunications Agency isimli departmanı, IT hizmetlerindeki sıkıntıların tespiti ve doğru yolun bulunması amacıyla ITIL olarak kısaltılan bir konseptin temellerini ortaya koymuş. Tam olarak açılımı <strong class="markup--strong markup--p-strong">Information Technology Infrastructure Library </strong>şeklinde. Ona kütüphane denmesinin makul bir sebebi de süreçlere ait pratikleri içeren beş kitaptan oluşması. O yıllarda temelleri atılan ITIL zaman içerisinde yeni versiyonları ile birlikte gelişmeye devam etmiş. Bugün pek çok IT firmasının<em class="markup--em markup--p-em">(ki sadece IT ile sınırlamak doğru değil nitekim içerisinde hizmet geçen her alanda ele alınabilir)</em> uygulamaya çalıştığı bir, bir…Şey…Immm…Bir ne? </p>
<p>İşte geçtiğimiz günlerde Doğuş Teknoloji tarafından düzenlenen “ITIL Farkındalık” eğitiminde bu sorunun cevabını bulmaya çalıştık. Ben, her zaman olduğu gibi heyecanla not tutmaya çalıştım. Bir günlük eğitimde yaklaşık onaltı sayfalık not çıkmıştı. Üstelik kaçırdığım bir çok kısım vardı.</p>
<p>Konuya belkide uzun zamandır hayatımda<em class="markup--em markup--p-em">(hayatımızda)</em> olan Service Now ürününden bahsederek başlasam iyi olur. Bazen çalışmayan masa telefonu için, bazen Test ortamından PreProd’a aktarılacak bir SQL Script taşıması için, bazen canlı ortam geçişindeki değişikliğe ait geri dönüşüm dokümanının eklemenmesi için, bazen ekibin üzerine düşen ve belli bir sürede çözülmesi beklenen hizmet kesintisine ait kayıda bakmak için kullanmakta olduğumuz ServiceNow ürününden bahsediyorum. Gerek önceden çalıştığım ING Bank gerek şu an çalışmakta olduğum Doğuş Teknoloji bünyesinde hali hazırda kullanmakta olduğumuz bir ürün.</p>
<p>Neredeyse altı yıldır karşımda olan bu ürünün, ITIL pratiklerinin şirket bünyesinde uygulanması ve hizmet kalitesinin arttırılması için kullanıldığını fark etmem ne acıdır ki bu eğitime nasip oldu. Eğitmenimiz <a class="markup--anchor markup--p-anchor" href="https://www.linkedin.com/in/fokay/" target="_blank" rel="noopener" data-href="https://www.linkedin.com/in/fokay/">Fırat Okay</a> bir gün boyunca bizleri bilgilendirdi. Aslında proje yönetimi gibi bir konuyla alakalı olacağını düşündüğüm bir eğitimdi ve bu önyargı ile güne başlamıştım<em class="markup--em markup--p-em">(Kimse duymasın sıkılacağımı düşünüyordum)</em> Ancak Fırat hocamız cidden doyurucu bilgiler vererek tabiri caizse ITIL’ı bana sevdirdi.</p>
<blockquote>
<p>ITIL’ı anlamak için şu soruyu sormamız gerekiyor; “IT hizmetlerini nasıl daha kaliteli hale getirir ve yönetiriz?”</p>
</blockquote>
<p>Bir elektronik posta servisini göz önüne alalım. Bu servis temel olarak müşterilerin haberleşme ihtiycını karşılar. Bu ihtiyacın karşılanması için tasarlanan sistemin içerisinde yazılım<em class="markup--em markup--p-em">(software)</em> ve donanım<em class="markup--em markup--p-em">(hardware)</em> bir arada yer alır. Ancak detaylara inildiğinde işin içerisine güvenlik<em class="markup--em markup--p-em">(security)</em>, ağ yönetimi<em class="markup--em markup--p-em">(network management)</em>, firewall, anit-virus koruması, router, switch, veritabanı, mail uygulaması gibi konu başlıkları da dahil olur. Üstelik bu konular hem istemci hem de sunucu tarafını ilgilendirir niteliktedir. Görüldüğü üzere basit bir email servisi gibi görünse de, içerdiği bileşenler nedeniyle karmaşık bir sistemle karşı karşıya olduğumuzu söyleyebiliriz.</p>
<blockquote>
<p>ITILcada “servis” veya “hizmet” terimi, müşteriye fayda sağlayan ve onun ihtiyacını karşılayan anlamına gelmektedir. </p>
</blockquote>
<p>Bu örnekte aslolan hizmettir<em class="markup--em markup--p-em">(Service)</em> Müşterinin belli bir ihtiyacını karşılamak üzere tasarlanır. Hizmet bileşenleri yukarıdaki örnekte bahsettiğimiz gibi karmaşık bir sistemin parçaları olabilir. Ayrıca her bir bileşen farklı sayıda ve beceride takımların sorumluluğunda işletilebilir. İşin içerisine sorumluluk girince tahmin edeceğiniz üzere dikkat edilmesi gereken hususların sayısı da artar. ITIL , işte bu takımların hizmet faydası ekseninde birleştirilmesini amaç edinir.</p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_1.gif" alt="" /></p>
<p>Elbette hizmeti sadece IT kapsamında bir olguymuş gibi düşünmemek gerekir. Hatta ITIL’ın faydasının farkına varmak için neden otele ya da restorana gittiğimizi düşünmek gerekir. Bir restorana gittiğimizde bizi kapıda karşılayan kişiden, siparişimizle ilgilenen garsona, mutfaktaki aşçıdan kasiyere kadar herkes verilen hizmetin farkındadır. Müşteriyi<em class="markup--em markup--p-em">(bizi)</em> memnun etmek için herkes kendi sorumluluğunun bilincinde hareket eder ve en iyi hizmeti sunma misyonunun bir parçası olur<em class="markup--em markup--p-em">(İyi restoranlardan bahsediyoruz tabii)</em> Bu farkındalığın bir sonucu olarak ortaya çıkan kaliteli hizmet, sadık müşterilerin ortaya çıkmasına ve restoranın itibarının artmasına sebep olur. Ancak bu farkındalık düzeyi potansiyel Service-Provider rolünde olan her IT organizasyonu için geçerli değildir. Çünkü IT organizasyonuna dahil olanlar bazen bu hizmet olgusunun farkında olmazlar. Dolayısıyla ITIL’ın bu soruna çözüm aradığını da söyleyebiliriz.</p>
<p>ITIL içerisindeki terimler düşünüldüğünde bazı kavramların dikkatli kullanılması gerekir. Hizmet kalitesinden bahsederken bu hizmetin müşterilerin ihtiyacını karşılamak için var olduğunu belirttik. Ancak ITIL kütüphanesine göre müşteri<em class="markup--em markup--p-em">(Customer)</em> ve kullanıcı<em class="markup--em markup--p-em">(User)</em> şeklinde iki ayrı rol söz konusudur. Temelde hizmeti talep eden ve hatta bunun parasını veren tarafı müşteri olarak tanımlayabiliriz. Hizmet ortaya çıktıktan sonra bunu kullanan kişi ise kullanıcı rolünde değerlendirilir.</p>
<p>Fırat hocanın bu ayrımla ilgili verdiği güzel bir örnek de var; Henüz küçük bir çocuğun ebeveyninden bisiklet istediğini düşünelim. Bisikleti araştıran, parasını veren, satıcı ile anlaşan ebeveyn müşteri<em class="markup--em markup--p-em">(Customer)</em> olarak düşünülebilir. Destek tekerlekli sevimli bisikletine kavuşan o minnak çocuk ise kullanıcı<em class="markup--em markup--p-em">(User)</em> olarak tanımlanır.</p>
<p>Eğitimin bu kısımlarında ITIL içerisindeki temel kavramları incelemeye devam ettik. Az çok servisin ne anlama geldiğini, servis müşterisi ve kullanıcısının nasıl ayrıştırıldığını öğrendik. Materyaller yavaş yavaş toplanmaya devam ediyordu. İşin içerisinde servis varsa bunların kurumsal anlamda yönetimi de ITIL açısından değer kazanmakta ki bu durum Service Management olarak ifade edilmekte. Kısacası servisleri nasıl yönetiriz sorusuna cevap aradığımız bir konu olduğunu belirtebiliriz.</p>
<p>Servisler kuvvetle muhtemel süreçlerle<em class="markup--em markup--p-em">(Process) </em>ilişkili olacaktır. Sonuçta bir hizmetin devreye alınması, yönetimi, takibi ve diğer bir çok organizasyonel konu süreçlerle ilişkili. Normal şartlarda süreçleri, belli bir amaç için bir araya getirilmiş aktiviteler dizisi olarak düşünebiliriz. Kurum içindeki iş yapış biçimlerini tanımlamak gibi önemli bir rolleri vardır. Bir çağrı merkezinin talep karşılama adımlarından birisini süreç olarak değerlendirelim. Burada çağrıların nasıl geldiği, neye göre önceliklendirileceği ve çıktının ne olacağı gibi soruların cevapları sürecin aktiviteleri tarafından karşılanacaktır. Aktivite söz konusu olduğunda yine ITILcalaştırılmış bir başka kavram daha karşımıza çıkıyor; fonksiyonlar<em class="markup--em markup--p-em">(Functions) </em></p>
<blockquote>
<p>ITIL’ın güncel sürümünde 26 ayrı sürecin olduğundan bahsediliyor<em class="markup--em markup--pullquote-em">(Bunu bi araştıralım Burak)</em></p>
</blockquote>
<p>Fonksiyonlar süreç kapsamında ilgili aktiviteyi gerçekleştirecek ekip veya araçlar olarak tanımlanmakta. Dolayısıyla kimin ya da hangi aracın, süreç kapsamındaki hangi fonksiyonu işleteceğinin bilinmesi ve yönetimi de ITIL’ın uğraştığı konular arasında yer almakta. Buradan da fonksiyonların rolleri<em class="markup--em markup--p-em">(Roles) </em>ve sorumluluklarının<em class="markup--em markup--p-em">(Responsibilities) </em>önem kazandığını söyleyebiliriz.</p>
<p>Service, Service Management, Customer vs User, Process, Function, Roles ve Responsibilities…Şu ana kadar ITIL dünyasında ilerleyebilmek için bilinmesi gereken temel terimlerdi. Artık asıl mevzuya girilebilir. Şaşırtıcı olmasa gerek ITIL’ın da bir servis yaşam döngüsü bulunuyor. </p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_2.gif" alt="" /></p>
<p>Döngüler bizim hayatımızın olmassa olmazı değil mi? ITIL’da olsa, Agile’da olsa sürekli iyileştirmeye dayanan bir iterasyon zinciri söz konusu. Yukarıdaki güzel şeklin de ifade edeceği üzere ITIL, beş temel başvuru kitabıyla tanımlanmış bir yaşam döngüsü olarak düşünülmeli. Kısaca bunların temel özellikleri üzerinde konuşarak ilerleyelim.</p>
<h4 class="graf graf--h4">Service Strategy</h4>
<p>İhtiyacın belirlendiği aşamadır ve şu sorulara cevap bulan pratikler içermektedir.</p>
<ul class="postList">
<li class="graf graf--li">Biz kimiz? </li>
<li class="graf graf--li">Vizyonumuz nedir? </li>
<li class="graf graf--li">Kime hitap ediyoruz? </li>
<li class="graf graf--li">Müşterimiz kim?</li>
<li class="graf graf--li">Hedeflerimize ulaşmak için izleyeceğimiz yol/yordam nedir?</li>
<li class="graf graf--li">İhtiyaçları karşılamak için ne tür hizmetler sunmalıyız?</li>
</ul>
<h4 class="graf graf--h4">Service Design</h4>
<p>Tasarımın yapıldığı safha olarak düşünülebilir. Strateji aşamasında alınan kararlara göre servis tasarımı oluşturulur. İhtiyaca yönelik bir tasarımın oluşturulması için gerekli doneleri sağlar.</p>
<h4 class="graf graf--h4">Service Transition</h4>
<p>Testlerin yapıldığı, test sonuçlarına göre hizmetlerin taşındığı<em class="markup--em markup--p-em">(Deployment)</em> aşamanın tariflendiği bölüm olarak düşünülebilir.</p>
<h4 class="graf graf--h4">Service Operation</h4>
<p>Devreye alınan hizmetin işletildiği kısmı tanımlar. Hizmetin müşteriye/kullanıcıya sunulduğu ve aslında ITIL’ın en önemli aşamasıdır<em class="markup--em markup--p-em">(Yani en azından eğitimde en çok üzerinde durduğumuz aşamaydı)</em></p>
<h4 class="graf graf--h4">Continual Service Improvement</h4>
<p>Aşağıdaki soruların cevaplandığı iyileştirme safhasıdır.</p>
<ul class="postList">
<li class="graf graf--li">Neler iyi gidiyor?</li>
<li class="graf graf--li">Neler kötü gidiyor?</li>
<li class="graf graf--li">Eksikler neler?</li>
<li class="graf graf--li">Neleri iyileştirmek lazım?</li>
</ul>
<p>Retrospective toplantıları geldi aklınıza değil mi? :) </p>
<p>Yaşam döngüsünde yer alan Design, Transition ve Operation kısımları sürekli bir iterasyon halinde işlemektedir. Aslında tipik bir yazılım geliştirme sürecini ele aldığımızda ITIL’ın bu süreç üzerinde denk düştüğü belli başlı yerler olduğunu da söyleyebiliriz. Aşağıdaki şekle bir bakalım.</p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_3.gif" alt="" /></p>
<p>İhtiyaçları belirledikten sonra analizini yapıp bir tasarımın ortaya konması ve buna göre kodlama yapılması söz konusudur. Bunu kullanıcı kabul testleri<em class="markup--em markup--p-em">(User Acceptance Test)</em> ve sonuçlarına göre dağıtım<em class="markup--em markup--p-em">(Deployment)</em> işlemleri takip ediyor. Dağıtılan ürüne daha sonradan destek verilir. </p>
<p>Evet, biraz Waterfall’a benzer bir yapı gibi görünüyor. Benim kafamda da benzer soru eğitim sırasında oluşmadı değil. Lakin ITIL’ın yaşam döngüsünün de iterasyonlar üzerine dayalı olduğunu görmekteyiz. Bu açıdan bakıdığında Agile yürüdüğümüz yapılar için de iz düşümlerin olduğunu söylemek sanıyorum ki mümkün. Nitekim bir Product Backlog Item’ı sprint’e dahil ettiğimizde onun kısa bir analizi, task’lar halinde parçalanması, task’lara ait kodlamanın yapılması, DevOps söz konusu ise test iterasyonlarının çalıştırılması ve belki de Sprint için bir UAT gerçekleştirilmesi, sprint sonuna gelindiğinde müşteri için değer yaratan increment’lerin dağıtımı ve operasyonun takibi… Pek tabii tüm bu operasyon sürecinin gözden geçirilmesi, gerekli iyileştirmelerin yapılması ve yeniden ihtiyaçların belirlenip aynı akışın devam ettirilmesi…İşte kalıba uydu:) </p>
<p>Tabii bana göre ITIL‘ın uygulanabilir nitelikte olduğu projeler olmalı. Bir başka deyişle IT açısından ne tür hizmetlerin ITIL çerçevesinde değerlendirilmesi gerektiğinin bir takım kriterleri olmalı. Bakalım notlarımızın sonunda bu soruya cevap bulabilecek miyiz?</p>
<p>Eğitimin bundan sonraki kısımlarında yaşam döngüsünde yer alan bazı maddelerin biraz daha detayına girmeye çalıştık. İlk olarak Service Operation sürecini ele aldık.</p>
<h4 class="graf graf--h4">Service Operation Process(Biraz daha detay)</h4>
<p>Bu safhada Event Management, Incident Management, Request Fullfilment, Problem Management ve Access Management gibi çeşitli alt yönetim süreçleri tanımlanıyor<em class="markup--em markup--p-em">(ITIL versiyonlarına göre farklılıklar olabilir)</em></p>
<p>Olay yönetimi sürecinde durum değişikliklerinin izlenmesi ile ilgili işlemlere yer verilmektedir. Örneğin bir kullanıcının sisteme Login olması, servisin yeniden başlatılması veya durması gibi haller bu bağlamda düşünülebilir.</p>
<p>Request Fullfilment sürecinde, kullanıcıdan gelen basit ve çabuk gerçeklenebilir isteklere yer verilir. Paralo sıfırlama, biten yazıcı kartuşunun değiştirilmesi, yer değişikliği nedeniyle PC IP adresi taşınması, ortak alandaki bir klasöre erişim yetkisi gibi istekleri örnek gösterebiliriz.</p>
<p>Erişim yönetimi<em class="markup--em markup--p-em">(Access Management) </em>adındanda anlaşılacağı üzere yetkilendirme ile alakalı bir süreçtir. Bir kullanıcının ilgili domain’e eklenmesi, uzak sunucuya erişim yetkisi alınması örnek olarak verilebilir.</p>
<p>Eğitim sırasında üzerinde daha çok durduğumuz ve kısımlar Incident Management ve Problem Management süreçleriydi. Incident ve Problem birbirleriyle çok sık karıştırılabilen kavramlar olduğu için eğitimin bu safhasını biraz daha derinleştirdik.</p>
<p>Devreye alınmış bir hizmette yaşanan plan dışı bir kesinti genel olarak Incident şeklinde adlandırılmakta. Tahmin edileceği üzere bu tip kesintilerin belirlenen veya müşteri ile anlaşılan süreler içerisinde çözümlenmesi bekleniyor/gerekiyor. Aksi durumda hizmet kesintisinin ürünün veya hizmetin itibari üzerinde olumsuz etkileri olması kuvvetle muhtemel.</p>
<blockquote>
<p class="graf graf--pullquote">Geliştirici olarak bizleri en çok ürküten postaların başında Incident kayıtlarına ait bildirimler gelir dersek yeridir. Bir Incident’ın büyüklüğü ve aciliyetine göre SLA(Service Level Aggrement) içinde tanımlanmış sürelerde çözülmesine uğraşırız. Hatta tanımlanan zamanın %25ini, %50sini ya da %75ini tükettiğimizde daha ciddi şekilde uyarılırız. Hele ki Incident çözüme kavuşmazsa…</p>
<p class="graf graf--pullquote">Bu durum sorunun süreçteki bir üst pozisyona eskale edilmesi ile sonuçlanabilir. Burada bahsi geçen SLA esasında müşteri ile el sıkışılan bir konudur. SLA’in bir amacı, üzerinde anlaşılan seviyelerde hizmet sunulmasını garanti etmektir. Service Design aşamasında tanımlanan SLA’lerin kardeşleri de var. İlerleyen kısımlarda onlar da karşımıza çıkacak.</p>
</blockquote>
<p>Belki garip gelecek ama Incident hallerinde günü kurtaracak çözüm neyse uygulanması gerekir<em class="markup--em markup--p-em">(Söz gelimi printer’dan evrak çıktısı alınamıyorsa bir şekilde geçici çözüm uygulanıp sorun giderilmelidir)</em> İşte bu sebepten problem yönetimi isimli ayrı bir süreç daha vardır. Çok sık tekrar eden, etkisi büyük olan veya üst yönetime kadar eskale olduğu için önem arz eden bazı sorunlar problem olarak tanımlanır ve kök nedenleri araştırılır. Bu kök nedenlere bakılaraktan Incident’ların tekrardan oluşmasını önlemek amacıyla kalıcı çözümler uygulanır. Problem yönetimi sürecinde esas amaç kök nedenlerin bulunup kalıcı çözümlerin uygulanmasıdır. Problemler genellikle Workaround, Known Error şeklinde değerlendirilirler. Hatta bilinen hatalar KEDB<em class="markup--em markup--p-em">(Known Error Database) </em>adı verilen veritabanında saklanırlar.</p>
<blockquote>
<p class="graf graf--pullquote">Incedent olarak gelen bir bulgu mutlaka çözülmek durumundadır. Çünkü sistemde kesinti söz konusudur. Ancak Request Fullfilment aşamasında bir zorunluluk yoktur. Nitekim istekler onaya tabidir.</p>
</blockquote>
<p>Incident ve Problem yönetimi, Olay izleme ile birleştirildiğinde hizmet kesintilerinin ve sorunlarının çeşitli seviyelerde karşılanması da mümkün hale gelir. Olay izlemedeki bilgilerden yararlanılarak henüz meydana gelmeyen bir kesintinin önceden tespit edilmesi, buna istinaden bir problem kaydının oluşturulup, kök neden tespiti ile kalıcı çözüm uygulanabilmesi sağlanabilir <em class="markup--em markup--p-em">(Bu durum çoğunlukla Proactive Problem Management olarak adlandırılmaktadır)</em> Ancak bu her zaman mümkün değildir. Çünkü işin içerisinde değişim yönetimi<em class="markup--em markup--p-em">(Change Management)</em> denilen ve uygulanacak çözümün çeşidi, büyüklüğü, kritikliğine göre devreye girecek bir onay mekanizması da olabilir.</p>
<p>Servis operasyon sürecinde dört temel fonksiyon<em class="markup--em markup--p-em">(veya ekip diyelim) </em>bulunur. Aşağıdaki şekilde aralarındaki ilişki özetlenmektedir.</p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_4.gif" alt="" /></p>
<p>Çoğumuz farkındayızdır. Firmada 7x24 etkin görev alan bir operasyon ekibi vardır. Bazı sorunlara otomatik olarak müdahale ederler<em class="markup--em markup--p-em">(Aslında bazı kesintiler önceden tespit edilip robotlaştırılmış süreçler işletilerek sorunlar hissettirilmeden bertaraf da edilebilir)</em> Diğer yandan müşteriden gelen bir kesinti ihbarında bunu ön cephede karşılayan hizmet destek ekibi vardır. Çoğunlukla birinci seviye olarak düşünebileceğimiz bu ekip ilgili sorunu çözmeye çalışır. Bunu yaparken daha önceden kayıt altına alınmış bilinen problemlere ait ipuçlarından da yararlanabilir. Tabii defalarca karşılaşılmış ve birinci seviye tarafından birçok kez çözülmüş bir bulgunun kalıcı olması da iyi değildir. Bunu problem olarak değerlendirip kök sebebini araştırmak ve kalıcı çözüm uygulamak gerekir. Yine de hizmet masası sorunu çözemezse tipine göre bu sorunu teknik veya uygulama yönetim ekiplerine aktarabilir <em class="markup--em markup--p-em">(Çözemessen aktar modeli) </em></p>
<p>Teknik ve uygulama yönetimi ekiplerinin aslında IT Operasyon ekibiyle sıkı ilişkisi vardır. Genellikle hizmetin dağıtımı ile ilgili prosedürleri operasyon ekibine de aktarırlar ki bir sorun oluşması halinde 7x24 müdahale edilebilsin. Teknik yönetim kendisine gelen bir bulguyu çözemezse ve bu bulgu üçüncü parti bir servis sağlayıcıya aitse<em class="markup--em markup--p-em">(Vendor)</em> ona aktarır<em class="markup--em markup--p-em">(Ticket açıldı deriz ya bazen) </em>Benzer durum uygulama yönetimi içinde geçerlidir. Lakin burada iki farklı durum olabilir. Bazı uygulamalar iç ekiplerce geliştirilmiştir. Dolayısıyla ilgili bulgu uygulama sahibi ekibe yönlendirilir. Ancak uygulama yine dış firma kökenli ise sorun için ilgili servis sağlayıcıya bir Ticket açılır. </p>
<blockquote>
<p class="graf graf--pullquote">Bulguları özellikle üçüncü parti fimaya indirgemeye gerek duymayacak şekilde hizmet geliştirmek bence önemlidir. Bu ancak işin en başından itibaren sistem dinamiklerini sürekli olarak test etmekten, test etmekten, test etmekten ve yine test etmekten geçmektedir. TDD gibi yaklaşımlar her ne kadar geliştirme sürelerini uzatsa da, uzun vadede sağlayacağı garantörlük dikkate alınmalıdır. </p>
</blockquote>
<h4 class="graf graf--h4">Service Transiciton Process(Biraz daha detaylı)</h4>
<p>Hizmeti devreye alma süreci olarak tanımlanmıştır. Devreye alınacak, emekli edilecek veya değişikliğe uğrayacak hizmetler ile ilgili her türlü dağıtım işleminin tariflendiği süreçtir. Change Management, Configuration Management, Release and Deployment Management, Transision Planning and Support, Change Evoluation, Knowledge Management gibi alt süreçleri barındırır.</p>
<p>Dikkat edileceği üzere değişim ve konfigurasyon yönetimi de bu süreçler içerisinde yer almaktadır. En önemli süreçlerden birisi değişim yönetimidir. IT süreçlerine etkisi olabilecek her türlü durum değişikliği Change Management’ın konusudur. Çalışan bir sistem üzerinde değişiklik yapmak<em class="markup--em markup--p-em">(yeni özellik eklenmesi, özellik çıkartılması vb) </em>her zaman için kritik ve riskli bir işlemdir. Bu nedenle değişikliğin sistem üzerinde minimum kesintiye uğrayacak şekilde yapılmasının garanti edilmesi gerekir. </p>
<blockquote>
<p class="graf graf--pullquote">Yine de sevgili Murphy’yi unutmamak lazım. Bu sebeptendir ki, değişim süreçlerinde mutlaka geri alma planları <em class="markup--em markup--pullquote-em">(Remediation Plan) </em>yapılır, yapılmalıdır.</p>
<p class="graf graf--pullquote">ING Bank bünyesinde çalıştığım dönemlerde taşıma yapılırken mutlaka girmemiz gereken bilgilerden birisi de geri alma planıyla ilgili olandı. Üretim ortamına bir SPmi taşınacak? Taşındıktan sonra sorun olursa sistemin durumunu tekrar eski konumuna nasıl döndüreceğiz, tariflenirdi. Bu tarifleme veritabanı operasyon ekibi tarafında önem arz eden bir konuydu. </p>
<p class="graf graf--pullquote">Pek tabii günümüz modern DevOps destekli süreçlerinde olası sorunların taşıma sonrası otomatik olarak hissedilip geri alma ile ilgili programlanmış betiklerin anında yürütülmesi gibi senaryolarda mümkün. Lakin bunların yine de dokümante edilmesi şart. Çünkü sizi/bizi çeşitli regülasyonlar nedeniyle denetlemek zorunda olanlar var(Auditçilerin kulağı çınlasın)</p>
</blockquote>
<p>Değişim yönetiminin önemini vurgulamak için Amerikada yapılan bir araştırmayı göz önüne alabiliriz. Araştırmaya göre firmalara gelen çağrıların belirli dönemlerde tavan yaptığı fark edilmiş. Tahmin edeceğiniz üzere çağrı sayılarının anormal seviyede yükseldiği zamanlar değişiklik sonrasına denk gelen anlar. Hatta bir senelik zaman periyodundaki istatistiki verilere bakıldığında, yükselen çağrı zamanlarındaki bulguların neredeyse %90a yakınının yeni değişikliklerle alakalı olduğu saptanmış.</p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_5.gif" alt="" /></p>
<p>Dolayısıyla yapılacak değişikliklerin riskinin ve etki analizinin de iyi yapılmış olması beklenmekte. Change Management süreci bunu da esas alır. Yeri gelmişken değişiklik adımlarına bakmakta yarar var aslında.</p>
<p>Bütün değişiklikler kayıt altına alınmalıdır. Bir değişim süreci çoğunlukla RFC<em class="markup--em markup--p-em">(Request for Change) </em>adı verilen istekle başlatılır. Söz konusu talep, sonrasında bir değişim kaydı<em class="markup--em markup--p-em">(Change Record) </em>haline gelir. Değişiklikler genelde üç türlüdür. Standart olanlar, acil yapılması gerekenler ve normal şartlara uyanlar. Önceden onaylanmış ve düşük riskli rutin değişiklikler, standart olarak adlandırılırlar. Ancak üretim ortamına alınan hizmette yaşanan ciddi problemler, yasal regülasyonlar nedeniyle uygulanması gereken kurallar veya güvenlik açıklarının oluştuğu durumlar acil değişim<em class="markup--em markup--p-em">(Emergency Change)</em> statüsüne girer. Standart ve acil değişime uymayan haller normal değişim olarak adlandırılır ve minor ya da major tipli olarak iki şekilde kategorilendirilir.</p>
<blockquote>
<p class="graf graf--pullquote graf--startsWithDoubleQuote">“As soon as possible” tipinden değişimlerin “Mission Impossible” durumuna düşmesini engellemek için planlamanın iyi yapılması önemlidir. </p>
</blockquote>
<p>Değişim kaydının oluşturulmasından sonraki aşama etki ve risk analizinin yapılmasıdır. Buna görede bir onay mekanizması çalıştırılır. Pek çoğumuzun yakınen bildiği şu meşhur CAB<em class="markup--em markup--p-em">(Change Advisory Board)</em> toplantıları yapılır. Hatta acil durumlar için ECAB<em class="markup--em markup--p-em">(Emergency Change Advisory Board) </em>toplantısı gerçekleştirilir. ECAB’in yapılma olasılığı düşük ve onay çıkması da çok kolay değildir. Yönetim çok aksi bir durum olmadığı sürece ritüel değişim sürecinin dışına çıkılmasını istemez. Hoş bunu geliştirme takımı da istemez. Nitekim acil değişim kaydı gerektiren durumların oluşmasına neden olan geliştirici hataları üst tarafta pek de iyi algılanmaz.</p>
<p>Değişim, konfigurasyon yönetimi<em class="markup--em markup--p-em">(Configuration Management)</em> ile de yakın ilişki içerisindedir. Herhangibir özelliğin hizmetleştirildiği süreçleri düşünün. Ortamlar için gerekli bir çok konfigurasyon ayarı bulunuyor. Sunucu adları, veritabanı bağlantıları, sertifikalar vb…Ama olaya sadece yazılım açısından bakmamak lazım. Fiziki sunucular, dokümanlar, IT kadrosu, lisanslamalar ve benzerleri de aslında birer konfigurasyon öğesi<em class="markup--em markup--p-em">(Configuration Item) </em>Keza bunlar arasındaki bağlantılar da değişim sürecinde önemli rol oynamakta. İlişkiler, etki analizi ve kök nedenlerin bulunmasına da yardımcı olan Configuration Management System<em class="markup--em markup--p-em">(CMS) </em>isimli sistem üzerinde tutulurlar.</p>
<p>Çoğunlukla bir sürüm<em class="markup--em markup--p-em">(Release)</em> çıkılacağı zaman birden fazla değişim kaydı sürece dahil olur. Bu durumda onay alanların bir paket haline getirilerek taşınması söz konusudur. Burada paketlerin build, test ve deploy aşamalarının da koordinasyonu gerekir ve bu işlemler sırasında konfigurasyon öğelerinin de sorunsuz işliyor olması önemlidir. </p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_6.gif" alt="" /></p>
<blockquote>
<p class="graf graf--pullquote">Release demişken; Hocamızın verdiği bilgiye göre İngiliz Barclay bankası senede bir sürüm(Release) çıkarmış. Eh onların bankacılık süreçleri veya devlet regülasyonları bizimki gibi olmadığı için bu son derece normal diyebiliriz. </p>
<p class="graf graf--pullquote">Lakin ING Bank bünyesindeki dönüşüm projesi kapsamında haftada bir sürüm çıkılan dönemlere indiğimizi hatırlıyorum. Preprod ortamına kadar normal olarak ilerleyen hizmetlerin onaya istinaden bir RFC numarası ile canlı ortama alınması söz konusuydu. </p>
<p class="graf graf--pullquote">Hatta kanlı bıçaklı CAB toplantıları yapıldığını hatırlıyorum. Ufak bir belgesi eksik olan değişim kaydı onaylanmaz ve o canlı ortam geçişini kaçırabilirdi.</p>
</blockquote>
<h4 class="graf graf--h4">Service Design Process (Biraz daha detay)</h4>
<p>Tasarımın tariflendiği bu aşamada iş birimi ve operasyonun gereksinimleri işin içerisine katılarak ilerlenilir. Edindiğim bilgiye göre sekiz süreç içeriyor ancak en önemli ikisi Service Catalogue Management ve Service Level Management.</p>
<p>Service Catalogue daha çok ne sunduğumuzun ya da ne sattığımızın tarifini içeriyor. Eski olsa da şu grafiği göz önüne alabiliriz.</p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_7.gif" alt="" /></p>
<p>Bu örnekte çeşitli seviyelerdeki müşteriler için verilen depolama ve kurtarma hizmetlerine ait bilgiler yer alıyor. Bunu bir servis kataloğu olarak değerlendirmek mümkün. Hizmetlere ait kısa tanımlamalar dışında dikkat çekecek detaylara da yer verilmekte.</p>
<p>Service Level Management’ta ise bizim daha çok aşina olduğumuz bazı kavramlar var. Bunların başında Service Level Aggrement geliyor. Ancak OLA<em class="markup--em markup--p-em">(Operational Level Aggrement)</em> ve UC<em class="markup--em markup--p-em">(Underpinning Contract)</em> şeklinde iki sözleşme daha yer almakta. SLM’in temel amacı müşteri ile dahili<em class="markup--em markup--p-em">(Internal)</em> ve harici<em class="markup--em markup--p-em">(External)</em> ekipler arasında bir orta yol bulmak. Buna göre antlaşmalar yapılıyor. Antlaşmalarda belirlenen kurallar çerçevesinde de bir servis tasarımına gidiliyor. </p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_8.gif" alt="" /></p>
<p>Müşteri çok doğal olarak almak istediği hizmetlerle ilgili olarak bazı gereksinimlerini sunar<em class="markup--em markup--p-em">(Service Level Requirements)</em> Bu zaman zaman fonksiyonel olmayan dilekler olarak da anılır. Bu bildirgede bir hizmetin ne zaman, hangi periyotlarda çalışması istendiği, hizmette kesinti olduğunda da müdahala sürelerinin ne olacağı ve güvenlik kriterleri gibi konulara açıklık getirilir. </p>
<p>Buna göre müşteri ile iç ekipler arasında operasyonel antlaşma yapılır<em class="markup--em markup--p-em">(OLA)</em> Microsoft, HP, Amazon, Oracle ya da bizim çalışmakta olduğumuz SahaBT gibi firmalarla da SLAler imzalanır. Aslında tarafların durduğu konuma göre antlaşma bir taraf için SLA iken diğer taraf için OLA anlamına gelebilir ya da tam tersi<em class="markup--em markup--p-em">(Bu kısma biraz daha çalışmam lazım)</em></p>
<blockquote>
<p>ITIL, müşteriler ile ilgili SLA, UC ve OLA sözleşmelerinin işin başında yapılması gerektiğini önerir.</p>
</blockquote>
<p>Tedarikçi firmalar ile yapılan Underpinning Contract ile Service Level Aggrement sözleşmesi birbirlerine oldukça benzer formattadır. Genellikle UCler çok daha ağır şartlar içerir.</p>
<p>SLA sözleşmesi firmanın kendi iş birimi ile geliştirme ekibi arasında da yapılmış olabilir. Bu durumda iş biriminin talep ettiği hizmetler ile ilgili aksamalarda devreye bu sözleşemelerde belirtilen reaksiyon süreleri girer. Taahüt edilen süreler içerisinde sorunun çözülmesi kaydın atandığı kişi açısından değerlidir<em class="markup--em markup--p-em">(KPI diyeyim siz gerisini anlayın)</em></p>
<h4 class="graf graf--h4">Service Strategy ve Continual Service Improvment Hakkında Kısa Kısa</h4>
<p>Eğitimin sonları yaklaştıkça bendeki yorgunlukta artmaya başladı. Hocamızın güzel anlatımını pür dikkat dinlemeye çalışırken bir yandan da notlar alıyordum. Ancak her güne sabah 05:50de başlayınca ikindi vakitlerinden sonra enerji az da olsa düşüyor. Yinede servis stratejisi ve iyileştirme noktasında bir kaç kısa not almayı başardım. </p>
<p>Müşteriye ne sağlayacağımızı bilmek için onu anlamamız gerekir. Bu, strateji sürecinde ele alınan bir olgudur. Business Relationship Management, Service Portfolio Management, Financal Management for IT Services, Strategy Management for IT Services ve Demand Management gibi süreçleri içerir. İsimlerinden anlayacağınız üzere müşteriye sunulacak bir hizmet için organizasyonun finansal bacağından portföyündeki bileşenlerine, arz talep dengesindeki taleplerden IT stratejilerine kadar bir çok önemli kalem hesaba katılır. </p>
<blockquote>
<p>Cep telefonu operatörlerinin maç günlerinde, maç sahasındaki baz istasyonlarının yetersizliği üzerine bir strateji belirleyip ilgili günlerde ilgili alanlara mobil baz istasyonları çıkartması Demand Management için güzel bir örnektir. Arzın arttığı bu vakada talepleri sorunsuz karşılayabilmek için örneğin bir aylık zaman dilimindeki maçların belirlenip mobil istasyonların çıkışını planlamak bir strateji hamlesidir.</p>
</blockquote>
<p>Continual Service Improvment diğer ITIL süreçlerini çevreleyen ve dolayısıyla onları gözlemleyip çıktılarını değerlendirerek sürekli iyileştirmenin ele alındığı bir safhadır. Burada adım adım, sakince ilerlenilmesi öğütlenir. Önemli olan bir husus ise ölçümlemektir. İyileştirme yapabilmek için elde metrik değerlerin olması gerekir. Bunları beslemek için de ölçme mekanizmalarının oluşturulması. CSI esasında planlama<em class="markup--em markup--p-em">(plan)</em>, yürütme<em class="markup--em markup--p-em">(do)</em>, kontrol etme<em class="markup--em markup--p-em">(check)</em> ve aksiyon alma<em class="markup--em markup--p-em">(act)</em> adımlarından oluşan bir döngüyü temel alır<em class="markup--em markup--p-em">(Deming kalite çemberi)</em></p>
<p><img src="https://www.buraksenyurt.com/image.axd?picture=/2018/10/ITILE_9.gif" alt="" /></p>
<h4 class="graf graf--h4">Sonuç</h4>
<p>Yönetemediğimiz sistemi kontrol edemeyiz. ITIL, kaliteli hizmet verebilmek, bu hizmetleri yönetebilmek, ölçümleme yapıp iyileştirebilmek için beş farklı disiplini sunmaktadır. Uygulanması bazen çok kolay görünmese de, büyük çaplı kurumsal projelerde ve özellikle müşteriye sunulan hizmetlerin yüksek itibara sahip olduğu durumlarda ITIL gibi endüstüriyel olarak standartlaşmış desenleri tatbik etmeye çalışmak uzun vadede mutlaka yararlıdır. </p>
<p>Aldığım bu eğitim sonrası Service Now ürününe ve iş yapış şeklimize olan bakışım daha da değişmiş oldu. Hizmeti sahiplenmenin önemli bir unsur olduğunu bir kere daha fark ettim. Elbette ITIL’ı bir şirkete kurgulayacak derecede bilgiye sahip olmamız gerek ve şart değil. Ancak içinde ServiceNow ve benzeri ürünlerin koştuğu, SLA zaman aşımı maillerinin geldiği ve CAB toplantılarının yapıldığı firmalarda bunların neden var olduğunun farkına varılması açısından yazıldığı kadarını bilmek önemli.</p>
<p>Tekrardan görüşünceye dek hepinize mutlu günler dilerim.</p>2018-10-06T18:05:00+00:00itilproject managementdevopsscrumagilebsenyurtSeksenli yıllarda İngilizlerin Central Computer and Telecommunications Agency isimli departmanı, IT hizmetlerindeki sıkıntıların tespiti ve doğru yolun bulunması amacıyla ITIL olarak kısaltılan bir konseptin temellerini ortaya koymuş. Tam olarak açılımı Information Technology Infrastructure Library şeklinde. Ona kütüphane denmesinin makul bir sebebi de süreçlere ait pratikleri içeren beş kitaptan oluşması. O yıllarda temelleri atılan ITIL zaman içerisinde yeni versiyonları ile birlikte gelişmeye devam etmiş. Bugün pek çok IT firmasının(ki sadece IT ile sınırlamak doğru değil nitekim içerisinde hizmet geçen her alanda ele alınabilir) uygulamaya çalıştığı bir, bir…Şey…Immm…Bir ne?https://www.buraksenyurt.com/pingback.axdhttps://www.buraksenyurt.com/post.aspx?id=730722ec-fbdd-462f-a282-b1b33421dff90https://www.buraksenyurt.com/trackback.axd?id=730722ec-fbdd-462f-a282-b1b33421dff9https://www.buraksenyurt.com/post/itil-in-farkina-vardim#commenthttps://www.buraksenyurt.com/syndication.axd?post=730722ec-fbdd-462f-a282-b1b33421dff9https://www.buraksenyurt.com/post/Burak-Senyurt-Almanac-2012-Hazc4b1rBurak Şenyurt Almanac 2013 Hazır2012-12-28T05:05:00+00:00bsenyurt<p><a href="http://www.buraksenyurt.com/pics/almanac.jpg"><img style="margin: 4px 0px; display: inline; float: right;" title="almanac" src="http://www.buraksenyurt.com/pics/almanac_thumb.jpg" alt="almanac" width="193" height="240" align="right" /></a>Merhaba Arkadaşlar,</p>
<p style="background-color: gold;"><strong>[Alamanac 2013 Version 2</strong> <a href="http://www.buraksenyurt.com/pics/2014%2f2%2fAlmanac2013_V2(Indexed).pdf" target="_blank">sürümünü buradan indirebilirsiniz</a>. <strong>Kasım 2013 </strong>tarihi itibariyle güncellenmiş dokümandır. <br />Dosyayı tarayıcı uygulama üstünde açmaya çalıştığınızda boyutu nedeniyle uzun süre bekleyebilirsiniz. Bu yüzden download ederek kullanmanızı öneririm. Güncel içerik <strong>3935</strong> sayfadan oluşmaktadır.]<br /><br />[Bu arada Almanac 2013 öncesi zamana ait eski blog yazılarıma <a href="http://www.buraksenyurt.com/pics/2014%2f2%2fOldiesGoldies(Indexed).pdf" target="_blank">OldiesButGoldies isimli PDF dosyası üzerinden erişebilirsiniz</a>]</p>
<p>Uzun süredir bloğumda sizlere elimden geldiğince teknik paylaşımda bulunmaya çalışıyorum. Bundan bir kaç sene önce, o zaman dilime kadar ki yazılarımı bir <strong>Almanac </strong>haline getirmiş ve public olarak internet ortamına hediye etmiştim.</p>
<p>Aradan geçen zaman içerisinde bloğun kapasitesi de arttı haliyle. Hatta o almanağa baktığımda neredeyse iki katı ölçüde genişlediğini ifade edebilirim. Ben de bunun üzerine hafta sonu oturdum ve <strong>BlogML.xml</strong> içeriğini <strong>Parse</strong> ederek, <a href="http://www.buraksenyurt.com">www.buraksenyurt.com</a> üzerinden yayınladığım ne kadar basılı içerik varsa, tek bir dökümanında topladım. Tabi bazı kısımlarında hatalar olabilir. Özellikle eski blogdan gelen bazı yazılardaki Flash nesnelerini dökümana gömemedim.</p>
<p>Dokümanları arzu ettiğiniz ortamlara dağıtabilir, paylaşabilir, çıktısını alabilir ve bu sayede başkalarının da yararlanmasını sağlayabilirsiniz. Umarım hepiniz için yararlı bir döküman olmuştur. Tekrardan görüşünceye dek hepinize mutlu günler dilerim.</p>2012-12-28T05:05:00+00:00almanacbsenyurtUzun süredir bloğumda sizlere elimden geldiğince teknik paylaşımda bulunmaya çalışıyorum. Bundan bir kaç sene önce, o zaman dilime kadar ki yazılarımı bir Almanac haline getirmiş ve public olarak internet ortamına hediye etmiştim. Aradan geçen zaman içerisinde bloğun kapasitesi de arttı haliyle. Hatta o almanağa baktığımda neredeyse iki katı ölçüde genişlediğini ifade edebilirim. Ben de bunun üzerine hafta sonu oturdum ve BlogML.xml içeriğini Parse ederek, www.buraksenyurt.com üzerinden yayınladığım ne kadar basılı içerik varsa, tek bir dökümanında topladım. Tabi bazı kısımlarında hatalar olabilir. Özellikle eski blogdan gelen bazı yazılardaki Flash nesnelerini dökümana gömemedim.https://www.buraksenyurt.com/pingback.axdhttps://www.buraksenyurt.com/post.aspx?id=7b4ebcbd-51f3-404f-8796-865439ae062e37https://www.buraksenyurt.com/trackback.axd?id=7b4ebcbd-51f3-404f-8796-865439ae062ehttps://www.buraksenyurt.com/post/Burak-Senyurt-Almanac-2012-Hazc4b1r#commenthttps://www.buraksenyurt.com/syndication.axd?post=7b4ebcbd-51f3-404f-8796-865439ae062ehttps://www.buraksenyurt.com/post/Oldies-but-Goldies-(Bsenyurtcom)Oldies but Goldies (Bsenyurt.com)2012-02-02T04:30:00+00:00bsenyurt<p><a href="http://www.buraksenyurt.com/pics/341399_8_bit_computer_game_casette.jpg"><img style="margin: 4px 0px; display: inline; float: right" title="341399_8_bit_computer_game_casette" src="http://www.buraksenyurt.com/pics/341399_8_bit_computer_game_casette_thumb.jpg" alt="341399_8_bit_computer_game_casette" width="300" height="225" align="right" /></a>Merhaba Arkadaşlar,</p>
<p><strong>2003 </strong>yılından bu yana teknik makale yazma uğraşısı içerisindeyim. Mümkün olduğunca fazla sayıda <strong>Türkçe </strong>içerik üretmeye ve belirli bir kalite seviyesinin üzerine çıkmaya çalıştım. Tabi bu işe ilk başladığım yıllardaki yazılarıma baktığım zaman biraz kendimden utanmıyor da değilim <img class="wlEmoticon wlEmoticon-smile" style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" src="http://www.buraksenyurt.com/pics/wlEmoticon-smile_32.png" alt="Smile" /></p>
<p>Hakkatten zamanında fecaat derecesinde kötü yazılarım da olmuş. Ama tabiki yazdıkça, yazdıkça, yazdıkça daha da iyileşmeye başlamışım.</p>
<p>Zaman içerisinde yazılarımı öncelikli olarak <a href="http://www.bsenyurt.com">www.bsenyurt.com</a> adresi üzerinden yayınlamıştım. <strong>Asp.Net 1.1 </strong>ile yazdığım bu site tabi sonradan gelen hazır blog araçları göz önüne alınınca bir süre sonra atıl hale gelmişti. Bundan sonra BlogEngine.Net ile yola devam ettim ve makalelerimi <a href="http://www.buraksenyurt.com">www.buraksenyurt.com</a> adresi üzerinden yayınlamaya başladım.</p>
<p>ve bildiğiniz üzere Ocak ayı içerisinde Almanac 2012 adında bir döküman yayınlayarak, <a href="http://www.buraksenyurt.com">www.buraksenyurt.com</a> sitesindeki makaleleri tek bir döküman haline getirip sizlerin kullanımına sundum. Geçtiğimiz günlerde aynı çalışmayı niye <a href="http://www.bsenyurt.com">www.bsenyurt.com</a> için yapmıyorum diye düşündüm. <a href="https://skydrive.live.com/redir.aspx?cid=508fd670ead5682d&resid=508FD670EAD5682D!260&parid=508FD670EAD5682D!172&authkey=!AI3J2JNdRo6nVzc" target="_blank"><span style="font-size: large;">Ve işte karşınızda Oldies but Goldies</span></a> dökümanı <img class="wlEmoticon wlEmoticon-smile" style="border-bottom-style: none; border-left-style: none; border-top-style: none; border-right-style: none" src="http://www.buraksenyurt.com/pics/wlEmoticon-smile_32.png" alt="Smile" /> 2933 sayfalık içeriğe SkyDrive üzerindeki linkten erişebilirsiniz. Yanlız dökümanı browser üzerinde açmayı denemek yerine Download edip açarsanız daha performanslı olacaktır.</p>2012-02-02T04:30:00+00:00oldies but goldiesbsenyurthttps://www.buraksenyurt.com/pingback.axdhttps://www.buraksenyurt.com/post.aspx?id=87ef404a-c0e7-49a7-b75c-c849f02c9d256https://www.buraksenyurt.com/trackback.axd?id=87ef404a-c0e7-49a7-b75c-c849f02c9d25https://www.buraksenyurt.com/post/Oldies-but-Goldies-(Bsenyurtcom)#commenthttps://www.buraksenyurt.com/syndication.axd?post=87ef404a-c0e7-49a7-b75c-c849f02c9d25https://www.buraksenyurt.com/post/Java-ile-24-Kahve-Molasc4b1-Dokumanc4b1Java ile 24 Kahve Molası Dökümanı2012-01-28T15:33:00+00:00bsenyurt<p><a href="http://www.buraksenyurt.com/pics/java_emulatorler.jpg"><img style="margin: 4px 0px; display: inline; float: right;" title="java_emulatorler" src="http://www.buraksenyurt.com/pics/java_emulatorler_thumb.jpg" alt="java_emulatorler" width="240" height="147" align="right" /></a>Merhaba Arkadaşlar,</p>
<p>Henüz makale yazmaya yeni başladığım dönemlerdi. Sadece .Net ile ilişkili yazılar yayınlamak istemiyordum aslında. Farklı bir şeyler de yapabilmeliydim. Gözüme Java programlama dilini kestirdim <img class="wlEmoticon wlEmoticon-smile" style="border-style: none;" src="http://www.buraksenyurt.com/pics/wlEmoticon-smile_33.png" alt="Smile" /> C# ile aramın iyi olması, nesne yönelimli dil kavramlarına aşina olmam bir avataj olabilirdi diye düşünmüştüm. Ve sonunda enteresan bir proje doğdu. “Java ile 24 Kahve Molası”. Seri de hiç bilmediğim Java dilini öğrenmeye çalışıyor ve bu sırada yaşadığım tecrübeleri değerli okurlarıma aktarıyordum. 24 bölüm sonuna geldiğimde en azından bir alt yapı ve temel oluşturabilecek seviyede bir içerik oluştuğunu gördüm. Geçtiğimiz günlerde daha önceden Almanac ve Oldies But Goldies serisinde yaptığım gibi, bu yazıları da tek bir döküman altında toplayayım dedim <img class="wlEmoticon wlEmoticon-smile" style="border-style: none;" src="http://www.buraksenyurt.com/pics/wlEmoticon-smile_33.png" alt="Smile" /> <a href="http://www.buraksenyurt.com/pics/2014%2f2%2fJavaile24KahveMolasi.docx" target="_blank">Söz konusu dosyayı bu adresten indirebilirsiniz</a>. Eskidir, nostaljiktir, amatördür ama yine de temel bazı bilgileri sunmaktadır. Yararlı olması dileğiyle hepinize mutlu günler dilerim.</p>2012-01-28T15:33:00+00:00javajava ile 24 kahve molasibsenyurtGeçtiğimiz günlerde daha önceden Almanac ve Oldies But Goldies serisinde yaptığım gibi, bu yazıları da tek bir döküman altında toplayayım dedim Smile Söz konusu dosyayı bu adresten indirebilirsiniz. Eskidir, nostaljiktir, amatördür ama yine de temel bazı bilgileri sunmaktadır. Yararlı olması dileğiyle hepinize mutlu günler dilerim.https://www.buraksenyurt.com/pingback.axdhttps://www.buraksenyurt.com/post.aspx?id=7559e3a1-b5ef-4aee-b75a-2045058def9614https://www.buraksenyurt.com/trackback.axd?id=7559e3a1-b5ef-4aee-b75a-2045058def96https://www.buraksenyurt.com/post/Java-ile-24-Kahve-Molasc4b1-Dokumanc4b1#commenthttps://www.buraksenyurt.com/syndication.axd?post=7559e3a1-b5ef-4aee-b75a-2045058def96