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übeleri kitaplaştırdı: “Site Reliability Engineering”. 

Kitap, hem sektördeki sistem yönetimi ve yazılım geliştirme iş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 ancak, 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. Kitapta anlatılanları okuyunca, tecrübelerini aktaranlarla benzer yollardan geçtiğimi gördüm. Ancak bazılarında, oldukça sıradışı bakış açıları ve son derece yaratıcı çözümler gördüm. Bu bakımdan, kendi adıma oldukça 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

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 vurgulandı.

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.

Oysa 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”

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), çalışanlar, departmanlar ve tüm şirket olarak ölçülmesi ve kullanıcılara mutlaka sunulması gereken birşeydir.

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

1.Her problem bir yazılım problemidir – “Every problem is a Software problem”

Aslında bu sözün google 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.