SRE ekip modeli kurmak: katılım biçimleri ve geliştirici ekiplerle iş bölümü

Önce şu karar: SRE ekibi neyin sahibi olacak

SRE ekibi kurmak, bir grup mühendisi operasyon işine atamak demek değildir. Önce ekibin neyin sahibi olacağı ve neyin sahibi olmayacağı netleştirilmelidir. Google'ın yaklaşımında SRE, destek verdiği hizmetlerin üretim yönetimini bir üretime hazırlık incelemesinden sonra devralır; ama her hizmet SRE desteği almaz. Yüksek güvenilirlik gerektirmeyen ya da SRE kapasitesini aşan hizmetler daha hafif destekle karşılanır: ortak üretim iyi uygulama rehberleri ve kısa danışmanlık incelemeleri.

Bu karar ekip modelinin omurgasıdır. Kurumda kaç hizmetin SRE kapsamına gireceği, bunların kritiklik ölçütü ve hangi hizmetlerin geliştirici ekipte kalacağı yazılı kriterlerle belirlenir. Kriter yoksa SRE ekibi ya her şeyin yükünü taşır ya da kimsenin işine yaramaz. Başlangıç noktası genellikle, kesintisi iş için en pahalı olan birkaç hizmettir.

Katılım modelleri ve nasıl evrildikleri

Google SRE kitabı, katılım biçimlerinin zaman içinde nasıl evrildiğini anlatır.

Basit PRR modeli: yayına girmiş bir hizmet SRE ekibine devredilirken uygulanır. Küçük bir SRE grubu seçilir, geliştirme ekibiyle hedefler (bir SLO, planlı tasarım değişiklikleri, eğitim takvimi) üzerinde anlaşılır. Sonra mimari, izleme, hata yönetimi, uyarılar ve olay geçmişi hizmete özgü bir kontrol listesiyle incelenir, boşluklar öncelendirilip birlikte kapatılır, kalan SRE ekibi eğitilir ve sorumluluk kademeli devredilir. Geliştirme ekibi geçiş sürecinde danışmanlık için hazır kalır.

Erken katılım modeli: basit PRR'ın çok geç başladığı, bu aşamada bulunan sorunların düzeltilmesinin pahalı olduğu fark edildiğinde doğdu. SRE tasarım aşamasında devreye girer: riskleri ve ödünleşimleri erken görür, inşa aşamasında kütüphane ve operasyonel kontroller önerir, yayında kontrollü açılış desenlerine destek verir, yayın sonrası güvenilirlik ve özellik işi arasındaki çatışmayı azaltır.

Çerçeve ve platform modeli: hizmet sayısı arttıkça her devralma pahalı ve yavaş hâle geldi, her hizmet üretim özelliklerini farklı biçimde yeniden yazdı. Çözüm, desteklenen diller için ortak servis çerçeveleri ve platform kurmaktı.

Ekip içi yapı ve ekipler arası sorumluluk bölüşümü

Çerçeve yaklaşımı, sorumluluk bölüşümünü de değiştirir. Platformu SRE sürdürür: yük atma, trafik yönetimi, günlük kaydı ve izleme gibi ortak parçalar. Uygulama düzeyindeki hatalar ve işlevsel nöbet geliştirme ekibinde kalır. Bu bölüşüm personel planlamasını da etkiler: ekip büyüklüğü hizmet sayısıyla değil, platform ihtiyaçlarıyla belirlenir.

Kurumunuzda çerçeve geliştirmek mümkün değilse bile bu ilkeyi küçük ölçekte uygulayabilirsiniz: ortak bir dağıtım hattı, ortak izleme şablonları, ortak olay süreçleri. Geliştirme ekibine gömülü SRE (embedded SRE) düzeni de bir başka seçenektir: SRE mühendisi bir süre geliştirme ekibinin içinde çalışır, güvenilirlik pratiklerini oradan yayar, sonra başka ekibe geçer. Bu düzen küçük kurumlarda pratik olabilir, ama merkez bir SRE kimliği ve ortak standartlar olmadan dağınık kalma riski taşır.

Üretime hazırlık incelemesi nasıl yapılır

Üretime hazırlık incelemesi (PRR), bir hizmetin SRE desteğine alınmadan önce nasıl bir durumda olduğunu görmek için yapılır. Pratik bir kontrol listesi şu başlıkları kapsar:

• Hizmetin mimarisi ve bağımlılıkları belgelenmiş mi?
• SLI ve SLO tanımlı mı, panolar bu göstergeleri gösteriyor mu?
• Uyarılar semptom temelli ve harekete geçirilebilir mi?
• Hata yönetimi, geri alma ve yük atma mekanizmaları var mı?
• Olay geçmişi ve postmortem'ler incelendi mi?
• Kapasite ve büyüme planı mevcut mu?
• Nöbet kılavuzları güncel mi?

İnceleme bir geçme-kalma sınavı değil, geliştirme ekibiyle yapılan bir pazarlıktır. Boşluklar önceliklendirilir, birlikte kapatılır, devir bu kapanışa bağlanır. Google'ın örneğinde, SLO ölçümlerini göstermeyen panolar düzeltilmiş, ardından SRE nöbeti devralmış, geliştiriciler nöbet rotasyonunda kalmıştır.

Geliştirici ekiplerle ilişkiyi kurmak

SRE ve geliştirme arasındaki ilişki hata bütçesi ve ortak SLO üzerine kurulur. SLO, ekiplerin ortak ölçü dilidir; bütçe, sürüm hızı ve güvenilirlik arasındaki dengeyi tartışma konusu olmaktan çıkarır. Bütçe sağlıklıyken özellik yayını sürer, tükenirken güvenilirlik işleri öne alınır.

Geliştirici ekibin operasyonel işini SRE'ye aktarma eğilimi sık görülür. Bunu sınırlamak için net kriterler, nöbet yükü ölçümü ve gerekirse nöbetin geliştirici ekibe geri verilmesi gibi mekanizmalar bulunmalıdır. İyi bir ilişki ortak postmortem'ler, ortak nöbet tatbikatları ve SRE'nin geliştirici ekibe sunduğu platform araçlarıyla beslenir. SRE yalnızca bekçi değil, hizmet edici bir mühendislik ekibidir: geliştirici ekibin işini kolaylaştıran araçları ve kalıpları sağlar.

Kurumda küçükten başlama yolu

Kurulum için gerçekçi bir yol haritası şöyle olabilir. Önce kurumdaki en kritik hizmetleri ve bunların güvenilirlik sorunlarını belirleyin. Sonra küçük bir pilot seçin: tek hizmet, bir geliştirme ekibi, belirli SLO'lar. Pilot boyunca ekip toil'i ölçer, nöbet düzenini kurar, postmortem pratiğini başlatır. Başarılı örnek, diğer ekiplere kanıt olarak sunulur.

Sonraki aşamada katılım ölçütleri yazılı hâle getirilir, ortak izleme ve dağıtım araçları kurulur, ekip büyüdükçe çerçeve ve platform yatırımı yapılır. SRE kültürü kurumsallaşırken yöneticilerin sürece katılması, iyi olay yönetimi ve postmortem uygulamalarının takdir edilmesi önem taşır. Ekibe yalnızca operasyon işi verilirse, mühendisler ayrılır ve SRE adı altında klasik bir operasyon ekibi kalır.

Bu beceri Mindset programlarında nerede çalışılır

Site Reliability Engineering (SRE) Pratikleri programında SRE Ekip Modeli ve Örgütsel Entegrasyon modülü, SRE Kültürü programında ise SRE Kültürünü Kurumsallaştırma modülü bu konuya ayrılmıştır. İçerik, SRE ekibi kurmayı planlayan mühendislik ve operasyon yöneticileri, platform ekip liderleri ve geliştirme ile operasyon arasındaki sorumluluk bölüşümünü yeniden düşünen kurumsal ekipler içindir.