“Google, çalışanlarının başından geçen tüm mesleki tecrübeleri ve bu tecrübelerden öğrendiklerini kitaplaştırdı: “Site Reliability Engineering”.
Bir işi öğrenebilmek için, yıllarca okuluna gidip, binlerce sayfa teorik bilgiyi hafızamıza yerleştiriyoruz, yetmiyor. Stajyer olup öğrendiğimiz teorik bilgileri pekiştirmeye çalışıyoruz, gene yetmiyor. En azından iki üç sene çalışıp tecrübe edinmemiz gerekiyor ki, özgüven kazanıp, “öğrendim” diyebilelim. Ancak, tüm bu sürecin sonunda öğrendiğimiz tek şey, teori ile pratiğin çoğu zaman birbirine uymadığı.
Zaman içinde anlıyoruz ki: okulda öğrendiğimiz teorik bilgi, bizleri sadece çalışma hayatımızın başlama çizgisine getirmeye yetiyor. Aslolan tecrübeyle edindiklerimiz.
Google da, tecrübenin insana kattıklarının altını çizercesine, şirket çalışanlarının başlarından geçen tüm mesleki tecrübeyi kitaplaştırdı: “Site Reliability Engineering”. Kitap, hem sektördeki sistem yönetimi ve yazılım geliştirmeişlerinin önümüzdeki yıllarda nereye gideceğine ışık tutuyor , hem de tecrübelerini nasıl paraya çevirdiklerine dair, dikkate değer bir çok bilgiyi içeriyor. Bu yazıda, ilgimi çeken ve önemli bulduğum bölümlerden söz edeceğim. Elbette kitabın tamamını okumanızı öneririm. Online olarak erişebilirsiniz, link: https://landing.google.com/sre/books/
“Reliability Engineering” terimini, ilk defa 2001 yılında, bir workshop’da duymuştum. Açıkçası, özellikle uçaklarda ve uzay araçlarında kullanım alanı bulan bir disiplinin, bu denli hayatımızın içine gireceğini kestirememiştim. Site Reliability Engineering’de, bu konunun IT sektöründeki uygulamasını okumak, büyük bir hazine sandığını açmak gibiydi.
Kitaptaki tecrübeleri okuyunca, onları yaşayanlarla benzer yollardan geçtiğimi/geçiyor olduğumu gördüm. Ancak, bazılarındaki oldukça sıra dışı bakış açısı ve yaratıcı çözümlerden etkilendiğimi itiraf etmeliyim . Bu bakımdan, kendi adıma ufuk açıcı bir okuma olduğunu söyleyebilirim.
Okurken en çok etkilendiğim üç başlık :
- Riski Kucaklamak (embracing Risk)
- Hedeflenen servis seviyeleri (Service Level Objectives)
- Tuzakları elimine etmek (eliminating toil)
Bence bu başlıklar son derece isabetli. Çünkü, IT, altyapı yada Cloud hizmeti veren şirketlerin yaşamlarını sürdürebilmeleri için bu üç olguyu, kurumları ve yaptıkları iş içerisinde mutlaka doğru pozisyonlaması gerekiyor.
En büyük çıkarım: Prensipler
Kitapta, günümüz teknolojisinde yaşanan devrimsel değişim DevOps ve SRE kavramları ile özetlenmiş. Ve bu alanlarda yaşanmış tecrübelerden elde edilmiş, bir çok prensip ele alınıyor.
Bunu çok önemsiyorum, zira teknolojilere ve teknik konulara yaklaşımımız zamana ve mekana göre değişebilir, fakat prensiplerimiz çok uzun zamanda olgunlaşıyor. Okurken en çok etkilendiğim ve dikkate değer bulduğum prensipleri sizlerle de paylaşmak istiyorum.
DevOps prensipleri
1.Silolara ayrılmaya son – “No More Silos (versatilists)”
2010’ların başlarına kadar, iş hayatında tek bir alanda uzmanlaşmanın çok önemli olduğu vurgulandı ve bir koltukta iki karpuz taşınmaz misali, aynı anda başka uzmanlık alanlarına da yönelmenin ne kadar yanlış olabileceği anlatıldı. Ancak bu bakış açısı, son on yılda değişti. Şu an günümüzde, tam tersinin doğru olduğu kabul ediliyor. Gartner, 2021 yılına kadar IT çalışanlarının %40’ının “Versatilist” olacağını öngörüyor. Versatilist terimini, “birden çok disiplinde uzmanlık sahibi olan kişi” olarak anlayabiliriz.
Site Reliability Engineering ‘de, şu anda varolan yazılım geliştirici, operasyoncu, altyapıcı, network’çu gibi mesleki ayrımların, önümüzdeki yıllarda “SRE mühendisi” kavramına evrimleşeceği söyleniyor. Bunu, sektörün içinde bir süredir, bizzat deneyimlemeye başladığımı söyleyebilirim. Artık sistem yöneticisi olan birisinin, aynı zamanda hem yazılım geliştirebilmesi, hem de Storage Network konusunda değişiklik yapabilmesi gerekiyor. ITIL ile tanımlanmış “Silolara ayırma” çok ciddi anlamda zarar görmüş durumda ve “Çevik(Agile)” hareket edebilmek, ancak ekipler içersinde farklı disiplinlerin olması ile mümkün olabiliyor. Örneğin, herhangi bir sorunu Unix ekibi, Network ekibine atayamıyor. Çünkü müşterinin IT ekibinde “Network” ve “Unix” ünvanları artık mevcut değil. SRE’nin her türlü soruna çözüm üretmesi bekleniyor.
2.Kazaların oluşması normaldir – “Accidents are normal”
Doğamız gereği mi, bilmiyorum, ama çalışırken olumsuz bir durumla karşılaştığımızda, genelde hemen suçlayacak birilerini arıyoruz. Bulduktan sonra da, yapılan hatanın telafisine hiç bir olumlu katkısı olmadığı halde, o kişiyi “hatadan sorumlu” olarak ifşa ederek, bir çeşit psikolojik rahatlama sağlıyoruz. Kitapta, kazaların olmasının normal olduğu ve bunların, insanların “kişisel hataları” sonucu oluşmadığının altı çiziliyor. Buna tamamen katılıyorum. Kazanın oluşmasına sebeb olmuş(!) kişinin açığa vurulması ve suçlanması yapılabilecek en büyük hata. Çünkü bu durum, hem şirket içi “mobbing’in” varlığına işaret ediyor, hem de ekiplerde bilginin gizlenmesine ve hataların gerçek sebeplerinin bulunamamasına sebep oluyor.
Bu sıkıntılı durumlara düşmemek için, daha en başta sistemleri kurgularken, kazaların oluşacağını hesaba katmak gerekiyor. Çok basit, gündelik hayattan bir örnek vermek istiyorum. Diyelim ki bir sanal sunucu kuruyorsunuz ve diskleri konfigüre ediyorsunuz. Eğer LVM kullanırsanız, disklerinizi online olarak resize edebilirsiniz. Ya da performans sorunu yaşadığınızda, işletim sistemi üzerinde disklerinizi taşıyabilirsiniz. Böylece, baştan performans sorunu ve kapasite arttırımı gibi durumları öngörmüş olursunuz. Ayrıca sunucunuzda işlem yapmak için sistemleri kapatmak zorunda olmazssınız.
3.Değişim aşamalı olmalıdır – “Change should be gradual”
Aylık proje toplantılarını ve güncellenen dökümanları herkes bilir. Birşeyin iyi dökümantize edilmiş olması, alınan büyük kararların uygulanmasını veya katılımcıların bir sonraki toplantıya hazır olmasını sağlamaz. İşte bu sebeple, Site Reliability Engineering’de değişimin ufak adımlarla gerçekleştirilmesi ve sürekliliğinin olmasının çok önemli olduğuna değiniliyor. Mesela, şirketinizde kullandığınız izleme(Monitoring) aracını değiştirmek istiyorsunuz. Bunu bir anda yapmaya çalışmak ve bu konuda büyük toplantılar yapmak, sizin için ciddi bir handikap oluşturacaktır. Oysa, değişimi zamana yayarak, ikinci bir izleme aracını zaman içinde, yavaş yavaş devreye almak daha kolaydır. Aylık büyük toplantılar yerine, süreç içinde küçük toplantılar yapmak ve kullanıcılardan geri bildirim almak, tam ihtiyacınıza göre istediğiniz sonucu almanızı sağlar.
4.Kullandığınız araçlar ve kurum kültürü doğrudan ilişkilidir – “Tooling and Culture are Interrelated”
Kullandığınız araçlar ve kurum kültürünüz birbiriye ilişkilidir. Ancak, kurum kültürünüz, araçlar değişse bile değişmemelidir. Kullandığınız araçlar, şirketinizin çalışma kültürünü belirlememelidir. Zaman içinde başka araçlar, yaptığınız işin içeriğini değiştirebilir.
Bir şirket kurdunuz ve prensibiniz otomasyon kullanmak. Bunun için de Puppet Otomasyon Yazılımını seçtiniz. SRE yaklaşımına göre dizaynlarınız ve süreçleriniz Puppet yazılımına göre inşa edilmemeliler. Çünkü Puppet yazılımında bugün varolan özellikler yarın olmayabilir, ayrıca ürettiğiniz hizmet için Puppet yazılımında olmayan özellikleri geliştirmeniz gerekecektir. Oysa, çalışılan araçtan bağımsız olarak değişim yönetimi prensiplerinizi belirlerseniz, bunlar zaman içersinde çok az değişime uğrarlar. Şunu unutmayalım:
Prensiplerimizi araçlarımıza göre değiştirirsek, araçları değiştirdiğimizde prensiplerimiz kalmaz, yeni araçlar prensiplerimiz olurlar.
5.Ölçülebilirlik çok önemlidir – “Measurement is crucial”
Kitaptaki bölümlerden birinin başlığı: “Service Level Objectives (SLO)”. Yani, “Hedeflenen Servis Seviyesi .“ Bu cümleyi okuduğumda, henüz çalışma hayatının başında, çok genç ve tutkulu bir mühendisken, tecrübe ettiğim bir olayın öğrettiği şu ders aklıma geldi:
Eğer yaptığın işi ölçemiyorsan, o işi sen yapmıyorsun demektir.
Gerçekten de başarınızı ve başarısızlığınızı ölçmeniz, rapor verdiğiniz insanlar açısından olduğu kadar, sizin için de çok önemlidir. IT sektöründe hep, sistemlerin çalışıyor olması değil, çalışmıyor olması konuşulur. Ve eğer siz, yaptığınız işin farkında olup, başarı kriterinizi kendiniz belirlemezseniz, birileri ulaşmanız gereken çıtayı hep daha yukarıya koyar. Bu da, yaptığınız işin kalitesini ve anlaşılabilirliğini sürekli azaltır. Bu nedenle, Hedeflenen Servis seviyesi(SLO)bin, çalışanlar, departmanlar ve tüm şirket olarak ölçülmesi ve kullanıcılara mutlaka sunulması gereklidir. Yoksa hesap verdiğiniz kim varsa (müdürünüz, patronunuz veya müşteriler) her çıkan sorunda sizi daha fazla hırpalamaya devam eder.
SRE prensipleri
1.Operasyon bir yazılım problemidir – “Operations is a Software problem”
Aslında bu sözün Google’ın kitabı içindeki orjinali:
“Her problem bir yazılım problemidir” şeklinde.
Müthiş ve herşeyi etkileyecek çok köklü bir prensip. Çünkü, IT ile ilgili herşey, aslında altta çalışan bir yazılımı barındırıyor. Dolaysıyla, SRE (Site Reliabity Engineer) ‘ler sorunlarına çözüm üretirken, yazılım mühendisliği prensiplerini kullanmalılar.
Burada, Google dışından bir örnek vermek daha anlamlı. AWS, tüm servislerini donanımdan bağımsız geliştirerek, sadece Software Stack kullanmaktadır. Bu sayede Public Cloud sektöründe ilk kuruldukları günden beridir liderler. Çünkü her geliştirdikleri servis, bir yazılım servisidir ve sundukları operasyonel çözümler de yazılım çözümleridir.
2.”Hedef Servis Seviyesi” ile yönetim – “Manage by Service Level Objectives(SLOs)”
Geliştirdiğiniz her servise, bir “Hedef Servis Seviyesi” belirleyin. Bu öngörüye göre, kurumunuz içersinde yaratacağınız hizmetlerin ayakta kalma sürelerini ve bunun başarılı olup olmadığını kolaylıkla ölçebilirsiniz. Hiçbir SRE %100 ayakta kalma süresini söz vermemelidir. Yapılması gereken, her üretilen servis için bir SLO (Service Level Objectives) belirlemek ve bunun ölçülebileceği bir raporu, dashboard üzerinden izlemektir.
3.Tuzakları azaltmak için çalışmak – “Work to minimize toil”
SRE (Site Reliabity Engineer) için yapılan tüm manuel işler, nefret edilen işlerdir ve maalesef, her zaman elle müdahale edilmesi gereken birşeyler vardır. Operasyon ekipleri her zaman bu ikilemi yaşarlar. Yeni bir proje gelir ve sizden yaptığınız iyileştirmeleri bırakıp, onunla ilgilenmeniz istenir. Böylece, mesela sayısı 500 olan potansiyel sorunlu sunucunuza, 100 sunucu daha ekler ve 600 potansiyel problemle karşı karşıya kalırsınız.
Bu tür iş yükleri elimine edilmelidirler!
Çünkü, operasyonel sebeplerle yapacağınız manüel bir sistem müdahalesi, çok daha fazla sistemi etkileyebilecek büyük tuzakları çözmek için yapacağınız projelere ayıracağınız zamandan çalar.
4.Bu yılki işinizi otomatize edin – Automate this years job away
Google, bünyesindeki SRE(Site Reliability Engineer)’leri, tuzakları elemine etmeleri için toplam çalışma sürelerinin maksimum %50’sini kullanmaları konusunda teşvik etmiştir.
Yani, SRE ler olarak sürekli karşılaştığınız tuzakları çözecek otomatize yazılımlar geliştirmeniz gerekiyor. Şirketler çalışanlarının yaklaşık olarak hangi işlerle ne kadar zaman uğraştığını izlerler, bu konuda en büyük soru, Outsource hizmet veren şirketlerde bu tip bir beklentinin olmamasıdır. Onlar, “sorun çıksın ve bizim mühendisimiz oraya saatlerini harcasın, böylece biz para kazanalım” gibi bir iş modelini düşünürler. Maalesef günümüz dünyasında bu artık geçerliliğini yitirmiştir. Yapılması gereken müşeri ile hizmet içeriği paylaşılırken, Otomasyonun da hizmet içeriğine dahil edilmesidir, yani müşterinize verdiğiniz know-how firmanız için bir çalışan kaynağı gibidir.
Sonuç olarak, “Site Reliability Engineering (SRE)” elbette bu yazıda anlattıklarımdan çok daha fazlasını içeriyor. Ben sadece, altını çizdiğim bazı bölümleri, kitap hakkında fikir vermeye yardımcı olması için burada paylaştım. Özellikle IT şirketlerinin CEO/CIO/CTO’ları ve sektörde önünü görmeye çalışan IT çalışanları, bu kitaptan ciddi anlamda faydalanabilirler.
Keyifli okumalar dilerim.