Kurumsal Sistemler

Tek seferde "her şeyi değiştir" projesi yerine, eski sistemin etrafını modern servislerle saran, kademeli bir göç stratejisi yürütüyoruz. 18 ay içinde lock-in'den çıkış mümkün.

Bu neden önemli

Çoğu büyük şirketin sırtında 10–20 yıllık bir ERP veya ana iş yazılımı var. İşi yapıyor; ama her küçük değişiklik için vendor faturası çıkıyor, yeni özellik 6 ay sürüyor, yeni nesil entegrasyon (modern API, gerçek zamanlı veri, mobil) imkânsız hale geliyor. Klasik “big bang replacement” projeleri %70 oranında ya başarısız oluyor ya da iki katına çıkan bütçe ile sonuçlanıyor. Strangler-fig deseni ise eski sistemi yerinde bırakıp, etrafına modern servisler ekleyerek işlevi parça parça devralır. Risk düşük, geri-dönüş erken.

Eylemsizliğin bir bedeli var ve bu bedel her çeyrek büyür. Eski bir çekirdek sistemin gerçek maliyeti lisans faturasıyla bitmez; gizli kalemler çoğu zaman daha pahalıdır. Tek bir geliştiricinin bildiği, başkasının dokunmaya korktuğu modüller “bus factor” riskini yükseltir — o kişi ayrılırsa kurumsal hafıza da gider. Modern bir API sunmayan sistem, her yeni entegrasyonu manuel veri aktarımına ya da gece çalışan kırılgan toplu işlere mahkûm eder. Tedarikçiye bağımlılık fiyat müzakeresindeki gücünüzü sıfırlar. Ve en önemlisi: rakipleriniz haftalar içinde yeni özellik çıkarırken siz aynı işi aylarla ölçüyorsanız, fark teknik değil ticari bir dezavantaja dönüşür. Modernizasyonu erteledikçe göç edilecek yüzey büyür; bugün 18 ayda yapılabilecek iş, üç yıl sonra 30 ay sürer.

Ne teslim ediyoruz

Teslimat listemiz bir yazılım paketi değil, bir geçiş güvencesidir. Her kalemin amacı operasyonu hiç durdurmadan eski sistemden bağımsızlaşmaktır.

• Kapsam haritası ve göç sırası. Eski sistemin her modülünü iki eksende puanlarız: iş açısından kritiklik ve teknik karmaşıklık. Bu matris, hangi modülün önce, hangisinin sonra taşınacağını öznel tartışmalardan çıkarıp veriye bağlar. Düşük risk + yüksek frekanslı işlerle başlanır; böylece ekip deseni öğrenirken iş sürekliliği güvende kalır.
• Anti-corruption layer (yozlaşma önleyici katman). Eski sistemle modern servisler arasında bir çeviri ve eşitleme katmanı kurarız. Eski sistemin tuhaf veri modeli yeni servislere sızmaz; iki taraf aynı veriyi aynı anda doğru görür. Bu katman, kademeli göçün teknik kalbidir.
• Modern servis implementasyonu. Node.js, Python veya .NET üzerinde mikroservis ya da modüler monolith — kararı ekibin büyüklüğüne ve operasyon olgunluğuna göre veririz, modaya göre değil. PostgreSQL veri ambarı, olay (event) veriyolu ve sözleşmeye dayalı API’ler standartımızdır.
• Kullanıcı geçiş yönetimi. Yazılım değişimi aynı zamanda bir alışkanlık değişimidir. Yeni arayüze geçen ekipler için eğitim, paralel kullanım dönemi, geri-bildirim döngüsü ve her modül için net bir “eski sistem kapanır” kriteri tanımlarız.

Yaklaşımımız

Modernizasyonu bir olgunluk yolculuğu olarak ele alıyoruz; “her şeyi sil, sıfırdan yaz” bir karar değil, çoğu zaman bir kaçıştır. Hangi modülün taşınacağına karar verirken 6R çerçevesini kullanıyoruz: her modül için altı seçenekten biri bilinçli olarak seçilir.

1. Retain (koru). İşini yapan, nadiren değişen, düşük riskli modüller olduğu gibi kalır. Her şeyi modernize etmek bir hedef değildir.
2. Rehost (taşı). Kod aynı kalır, altyapı modern bir ortama (konteyner, bulut) taşınır. Hızlı kazanç, düşük risk.
3. Replatform (yeniden zeminle). Çekirdek mantık korunur, çevresi modernize edilir — örneğin veritabanı PostgreSQL’e geçer, arayüz yenilenir.
4. Refactor (yeniden düzenle). Kod içeriden temizlenir, modüler hale getirilir; davranış aynı kalır ama bakımı kolaylaşır.
5. Rebuild (yeniden inşa et). Modül modern bir servis olarak sıfırdan yazılır — yalnızca iş değeri yüksek ve eski kodu kurtarmanın anlamsız olduğu yerlerde.
6. Replace (değiştir). Standart bir hazır çözümle (örneğin faturalama için yerleşik bir SaaS) değiştirilir; rekabet avantajı yaratmayan işlevler için en akılcı yol.

Bu çerçeve, her modülü “yenilenecek” ya da “kalacak” diye ikiye bölmek yerine doğru aracı doğru işe atar. Üzerine olgunluk modeli koyarız: Seviye 0 (belgesiz, tek kişiye bağlı, manuel dağıtım) → Seviye 1 (kaynak kontrolü, temel CI) → Seviye 2 (otomatik test, gözlemlenebilirlik) → Seviye 3 (bağımsız dağıtılabilir servisler, sözleşmeye dayalı API). Hedef her modülü Seviye 3’e çıkarmak değil; her modülü iş değerinin gerektirdiği seviyeye taşımaktır.

Süreç

• Hafta 1–4 — Envanter ve karar matrisi. Mevcut sistemin modül haritası, entegrasyon yüzeyi, kullanıcı yolculukları ve iş kritikliği analizi. Çıktı: 6R kararları işlenmiş göç sırası belgesi ve risk kaydı.
• Hafta 5–8 — Temel ve ilk modül. Anti-corruption layer kurulur ve ilk modül (genellikle düşük riskli, yüksek frekanslı bir iş akışı) canlıya alınır. Live A/B modunda eski ve yeni paralel çalışır. Çıktı: çalışan göç deseni ve geri-dönüş prosedürü.
• Ay 3–9 — Kademeli göç. Sıradaki 3–5 modül tek tek taşınır. Her modül kendi başına yayına alınır; geri-dönüş kapısı her aşamada açık kalır. Çıktı: her modül için dağıtım, test ve eğitim paketi.
• Ay 10–18 — Kapanış. Kalan modüller taşınır ve eski sistem kapanış planı yürütülür. Vendor sözleşmesi yalnızca son modül de güvenle taşındıktan sonra feshedilir. Çıktı: bağımsız modern yığın ve bakım devri.

Örnek bir senaryo

Bir omnichannel perakende markası, 16 yıllık özel ERP’sinin etrafında sıkışmıştı: e-ticaret sitesi ile mağaza stoğu arasında gerçek zamanlı veri yoktu, her promosyon kuralı vendor’a sipariş edilen bir geliştirmeye dönüşüyordu. Strangler-fig yaklaşımıyla önce stok senkronizasyonunu, ardından fiyatlandırma motorunu modern servislere taşıdık. 14 ayda altı modül modernize edildi. Yeni kampanya kuralı yayınlama süresi haftalardan bir güne indi, yıllık vendor geliştirme bütçesi belirgin ölçüde geriledi ve operasyon bu süre boyunca kesintisiz çalıştı. Sonuçlar her kurumda değişir; bu rakamlar tek bir senaryonun ölçeğini gösterir, garanti değildir.

Sık sorulan sorular

Operasyonumuz gerçekten hiç durmadan bu geçiş olur mu? Strangler-fig deseninin tüm amacı budur. Eski sistem her modül taşınana kadar çalışmaya devam eder; yeni servisler onun yanında devreye girer. Tek seferlik “büyük geçiş gecesi” yoktur, dolayısıyla o gecede her şeyin ters gitme riski de yoktur.

Big bang yeniden yazımdan neden kaçınıyorsunuz? Çünkü sektör verisi açık: büyük tek seferlik yeniden yazımların önemli bir kısmı bütçeyi aşar ya da yarıda kalır. Kademeli göç, her adımda çalışan bir sistem ve geri-dönülebilir bir karar bırakır. Risk küçük parçalara bölündüğünde yönetilebilir hale gelir.

Mevcut tedarikçimizle sözleşmemiz sürerken başlayabilir miyiz? Evet. Çoğu projeye tedarikçi sözleşmesi devam ederken başlarız. Anti-corruption layer iki sistemi eşgüdümlü tutar; sözleşmeyi yalnızca ilgili modüller güvenle taşındıktan sonra, kademeli olarak sonlandırırsınız.

Önce hangi modülü taşımalıyız? Genellikle iş açısından kritik olmayan ama sık kullanılan bir akışla başlarız. Bu, ekibin deseni düşük riskle öğrenmesini sağlar ve ilk somut kazanç erken gelir; böylece kurum içi destek de güçlenir.

Kurumsal sistemler pillar’ı altında legacy sisteminizi nasıl parça parça yenileyeceğimizi konuşmak için bize ulaşın.

B2B SaaS ürününüzü sıfırdan veya mevcut tekil-müşteri implementasyonundan multi-tenant mimariye taşıyoruz. Tenant izolasyonu, fiyatlandırma planları ve operasyonel araçlar — hepsi bir arada.

Bu neden önemli

Bir müşteri için yazılan yazılım hızlı yapılır; ama 50 müşteriye aynı kodu kopyalamak operasyonel çöküştür. Multi-tenant SaaS platformu, aynı kod tabanının çok sayıda müşteriye —her biri kendi verisini, kendi fiyat planını, kendi entegrasyonlarını izole ederek— hizmet ettiği mimaridir. Doğru tasarlandığında platformunuz exponansiyel ölçeklenir; yanlış tasarlandığında bir yıl içinde “bu hangi müşterinin verisi” sorusu cevapsız kalır. beynart bu işin “doğru” tarafına oturuyor — production’da çalışmış mimari kararlar.

Yanlış başlangıcın bedeli çoğu kurucunun sandığından yüksektir. En tehlikeli kalıp, “müşteri başına bir kopya” modelidir: her yeni anlaşmada kod çatallanır, üç ay sonra elinizde 50 ayrı sürüm ve hiçbir ortak güncelleme imkânı kalmaz. Tek bir güvenlik yaması 50 yerde test edilmek zorunda olunca, ekip yeni özellik yazamaz hale gelir. İzolasyon en baştan doğru kurulmadığında ise her sorgu “bu satır hangi tenant’a ait” kontrolünü uygulama katmanına bırakır — ve bir gün biri o kontrolü unutur. Veri sızması bir SaaS şirketinde teknik bir hata değil, varoluşsal bir kriz olur. Bu kararlar geri alınması en pahalı kararlardır; izolasyon modelini canlıdaki binlerce tenant’la değiştirmek, baştan doğru kurmaktan kat kat zordur. Bu yüzden mimariyi ilk haftada konuşuyoruz.

Ne teslim ediyoruz

Teslimatımız bir özellik listesi değil, ölçeklenebilir bir işletme platformudur. Her bileşen, ürünü büyütürken sizi yavaşlatmayacak şekilde tasarlanır.

• Tenant izolasyon mimarisi. Tek-veritabanı çok-şema, ayrı-veritabanı ya da silo modeli arasındaki kararı gerekçesiyle veririz. Şifreleme, yedekleme ve uyumluluk gerekleri (KVKK, GDPR, SOC 2) bu kararın bir parçasıdır, sonradan eklenen bir yama değil.
• Kimlik doğrulama ve yetkilendirme. Tenant-bazlı SSO, rol-tabanlı erişim kontrolü, denetim kaydı (audit log); OAuth ve SAML desteği. Gereken yerde çok bölgeli veri ikametgâhı seçenekleri.
• Fiyatlandırma ve abonelik motoru. Stripe veya Iyzico üzerinde plan yönetimi, kullanım-bazlı faturalama, deneme ve ödemesiz geçiş (grace period) mantığı. Fiyat değişikliği bir kod sürümü değil, bir yapılandırma olur.
• Operasyonel araçlar. Tenant kurulum (onboarding) paneli, faturalama panosu, denetim kaydına bağlı destek vekâleti (impersonation) ve kullanım analitiği. Bunlar müşteri başarı ekibinizin her gün kullanacağı araçlardır; sonradan değil baştan kapsamdadır.

Yaklaşımımız

Multi-tenant kararlarının çoğu, üç eksende verilen bilinçli takaslardır. Bir mimariyi “iyi” ya da “kötü” diye değil, iş bağlamınıza uygun mu diye değerlendiririz.

İzolasyon spektrumu. İki uç vardır ve doğru yer ikisinin arasındadır:

• Paylaşımlı (tek veritabanı, tek şema, tenant kimliğiyle satır filtreleme). En düşük maliyet, en kolay güncelleme, en yüksek yoğunluk. Çoğu B2B SaaS için doğru başlangıç. Riski: izolasyon disipline bağlıdır.
• Köprü (tek veritabanı, tenant başına şema). Daha güçlü mantıksal ayrım, hâlâ tek operasyon. Orta ölçek için dengeli seçim.
• Silo (tenant başına ayrı veritabanı/altyapı). En güçlü izolasyon, en yüksek maliyet. Yüksek uyumluluk gereği olan kurumsal müşteriler ya da veri ikametgâhı zorunluluğu için saklanır.

Doğru tasarım çoğu zaman karma olur: tenant’ların büyük çoğunluğu paylaşımlı katmanda, yalnızca özel gereksinimi olan birkaç büyük müşteri silo katmanında. Bu kararı verirken üç soruyu netleştiririz: uyumluluk yükümlülükleri (hangi sertifikalar, hangi ülkeler), beklenen tenant dağılımı (çok sayıda küçük mü, az sayıda dev mi) ve gürültülü komşu (noisy neighbor) toleransı. Üzerine kademeli ölçek hedefi koyarız — 10, 1.000 ve 10.000 tenant senaryoları için ayrı sınırları baştan belirleriz; çünkü 10 tenant’a doğru gelen mimari, 10.000’de yanlış olabilir.

Süreç

• Hafta 1–3 — Mimari atölyesi. İzolasyon modeli, veri modeli ve ölçeklenme hedefi (10? 1.000? 10.000 tenant?) netleştirilir. Çıktı: gerekçeli mimari kararlar belgesi ve uyumluluk haritası.
• Hafta 4–10 — Çekirdek platform. Kimlik doğrulama, tenant yaşam döngüsü, faturalama ve ilk iş özellikleri inşa edilir. Çıktı: ilk tenant’ı taşıyabilen çalışan platform.
• Hafta 11–14 — Operasyonel katman. Operasyonel araçlar, izleme, runbook’lar ve ilk pilot tenant kurulumu. Çıktı: müşteri başarı ekibinin tek başına tenant açabildiği panel.
• Hafta 15+ — Yayın ve öğrenme. Production yayını ve ilk 5 tenant ile öğrenme döngüsü. Çıktı: gerçek kullanıma göre rafine edilmiş onboarding ve faturalama akışları.

Örnek bir senaryo

Bir HR-tech ekibi, tek müşteri için yazdığı ürünü ikinci müşteriye satarken kodu çatallamış ve hızla “her müşteri ayrı sürüm” tuzağına düşmüştü. Karma izolasyon modeliyle yeniden kurduk: tenant’ların çoğunluğu paylaşımlı katmanda, veri ikametgâhı şart koşan büyük müşteriler ayrı bölgede. 14 haftada production’a çıktık; ilk altı ayda platform üç ülkede onlarca tenant’a hizmet verir hale geldi. Müşteri başarı ekibi yeni bir tenant’ı saatler süren manuel bir işten birkaç dakikalık panel akışına indirdi. Sayılar her üründe değişir; bu, tek bir senaryonun ölçeğidir, taahhüt değil.

Sık sorulan sorular

Tek veritabanı paylaşmak tenant’larımı riske atar mı? Hayır — doğru kurulduğunda. Paylaşımlı modelde izolasyon satır düzeyinde güvenlik politikalarıyla veritabanına gömülür; “tenant kontrolünü unutma” sorumluluğu tek tek geliştiricilere bırakılmaz. Yüksek uyumluluk gereği olan müşteriler için ise karma modelde ayrı silo katmanı sunarız.

Mevcut tek-müşteri ürünümüzü multi-tenant’a çevirebilir misiniz? Evet, en sık yaptığımız işlerden biri budur. Önce mevcut veri modelini ve gizli tenant varsayımlarını çıkarırız, sonra izolasyon katmanını kademeli olarak ekleriz. Geçişi tek seferde değil, mevcut müşteriyi kesintiye uğratmadan adım adım yürütürüz.

Faturalamayı neden baştan kapsama alıyorsunuz? Çünkü sonradan eklenen faturalama, en pahalı yeniden-yazımlardan biridir. Plan yapısı, kullanım sayacı ve abonelik durumları izolasyon modeliyle iç içedir; bunları baştan birlikte tasarlamak, altı ay sonra her şeyi söküp yeniden kurmaktan çok daha ucuzdur.

10 tenant’la başlayacağız; 10.000 için tasarlamak aşırı mühendislik değil mi? Hedef 10.000 tenant’ı bugün inşa etmek değil; o yolu kapatmamaktır. Mimariyi öyle kurarız ki ilk gün maliyeti düşük kalsın ama büyüme geldiğinde yeniden yazım gerektirmesin. Erken alınan birkaç karar, sonradan en pahalı borca dönüşür.

Kurumsal sistemler pillar’ı altında multi-tenant SaaS’ınızı kurmak için bize ulaşın.

Üretim sistemlerinizin neden yavaşladığını veya hata verdiğini açıklayan gözlemlenebilirlik katmanını kuruyoruz. OpenTelemetry, structured logging, SLO tanımları ve incident runbook'ları ile birlikte.

Bu neden önemli

Üretim sisteminiz çöktüğünde verilen ilk cevap “nereye bakacağımızı bilmiyoruz” ise, problem teknolojide değil — gözlemlenebilirlik katmanındadır. Log dosyaları farklı yerlerde, metrik adları her servisle değişir, distributed trace yoktur, bir hata kullanıcıya ulaşmadan 40 dakika sonra fark edilir. SRE ve gözlemlenebilirlik kurulumu bu boşluğu kapatır: sistem ne durumda, hangi sınırı aştık, kim hangi runbook ile müdahale eder. beynart’ta bu katman bir araç seçimi değil, organizasyonel bir kontrat.

Görünmezliğin bedeli her kesinti uzadıkça artar. Bir B2B SaaS’ta uzun bir kesinti yalnızca o saatin gelirini değil, sözleşmedeki SLA cezalarını, yenileme görüşmelerindeki güveni ve ekibin gece yarısı tükenmesini de kapsar. Kullanıcı sizi hatadan önce arıyorsa, bu artık bir mühendislik sorunu değil ticari bir itibar sorunudur. Daha sinsi bir bedel de var: gözlemlenebilirlik olmadan ekip “her ihtimale karşı” aşırı kapasite satın alır, çünkü gerçekte neyin yavaşladığını ölçemez. Performans sorunları kör tahminlerle “çözülmeye” çalışılır; her dağıtım bir kumar olur. Gözlemlenebilirlik bu körlüğü kaldırır — ve gözlemlenebilirlik olmadan kurulmuş bir SRE pratiği, ölçemediğiniz bir şeyi yönetmeye çalışmak demektir.

Ne teslim ediyoruz

Teslimatımız bir izleme aracı kurulumu değil, bir güvenilirlik pratiğidir. Amaç sadece grafik üretmek değil; doğru kişinin doğru anda doğru yere bakmasını sağlamaktır.

• Üç pilonlu gözlemlenebilirlik. Yapılandırılmış kayıt (JSON, correlation ID), metrikler (Prometheus / OpenTelemetry toplayıcı) ve dağıtık izleme (OTel + Tempo/Jaeger). Tek bir panodan istek, hata ve gecikme birlikte okunur; bir sorunun kökü “log mu, metrik mi, trace mi” diye dağılmaz.
• SLO ve SLA tanımları. İş açısından kritik 5–10 servis için erişilebilirlik ve gecikme SLO’ları, hata bütçesi (error budget) hesabı ve gereken yerde SLA’ya bağlı müşteri raporlaması. Hedefler mühendisin sezgisinden değil, kullanıcı deneyiminden türetilir.
• Incident runbook’ları. En sık görülen 8–12 hata senaryosu için adım adım müdahale belgesi; nöbetçi (on-call) mühendisin eli hiçbir zaman boş kalmaz. Postmortem (olay sonrası inceleme) şablonu ve aksiyon-madde takibiyle her olay bir öğrenmeye dönüşür.
• On-call rotasyonu. PagerDuty veya Opsgenie üzerinde haftalık rotasyon, eskalasyon kuralları ve yorgunluğu önleyen bir ritim. Sürdürülebilir bir nöbet deneyimi, doğru kurulmuş alarmlar kadar önemlidir.

Yaklaşımımız

Gözlemlenebilirliği bir araç kurulumu değil, bir olgunluk modeli olarak ele alıyoruz. Çoğu ekip Seviye 0’da takılır ve doğrudan en üst seviyeye atlamaya çalışır — bu, gürültü üreten ama güven vermeyen bir kuruluma yol açar. Dört seviyede ilerleriz:

• Seviye 0 — Reaktif. Kullanıcı şikâyet eder, ekip log dosyalarını manuel tarar. Görünürlük yok, MTTR tahmin edilemez.
• Seviye 1 — Merkezî. Loglar ve metrikler tek yerde toplanır, temel panolar var. Artık “nereye bakacağız” sorusunun bir cevabı var.
• Seviye 2 — Proaktif. Dağıtık izleme devrede; alarmlar eşiğe değil kullanıcı etkisine bağlı. Sistem siz bakmadan size haber verir.
• Seviye 3 — Öngörücü. SLO ve hata bütçesi karar verir; bütçe tükendiğinde özellik geliştirme durur, güvenilirlik önceliklenir. Gözlemlenebilirlik artık mühendislik değil, yönetim kararı.

Kararların merkezinde dört altın sinyal durur — gecikme, trafik, hata oranı ve doygunluk. Yüzlerce metrik arasında boğulmak yerine bu dördünü her kritik servis için doğru ölçmek, paranızın ve dikkatinizin çoğunu doğru yere yönlendirir. Alarm felsefemiz de buna bağlıdır: bir alarm yalnızca bir insan gece yarısı kalkıp müdahale edecekse çalmalıdır. “İlginç ama eyleme dönüşmeyen” her uyarı, gerçek alarmı boğan gürültüdür.

Süreç

• Hafta 1–2 — Envanter. Servis envanteri, mevcut log/metrik durumu ve kritik kullanıcı yolculuklarının haritası. Çıktı: olgunluk seviyesi tespiti ve öncelikli servis listesi.
• Hafta 3–4 — Enstrümantasyon. OpenTelemetry kurulumu, yapılandırılmış log formatı, correlation ID ve ilk panolar. Çıktı: üç pilonun tek panoda birleştiği temel görünürlük.
• Hafta 5–6 — SLO ve alarmlar. SLO tanımları, hata bütçesi bordrosu ve alarm eşiklerinin kullanıcı etkisine bağlanması. Çıktı: gürültüsüz, eyleme dönüşen alarm seti.
• Hafta 7–8 — Pratik. Runbook yazımı, on-call rotasyonu başlatma ve ilk gameday (kontrollü arıza) tatbikatı. Çıktı: ekibin denenmiş bir olay müdahale refleksi.

Örnek bir senaryo

Bir B2B SaaS ekibi, kesintileri neredeyse her zaman müşteri çağrısıyla öğreniyordu; loglar üç farklı yerde, alarmlar ise herkesin sustuğu bir gürültü duvarına dönüşmüştü (Seviye 0’a yakın). Sekiz haftada üç pilonu tek panoda topladık, dört altın sinyali kritik servislere bağladık ve alarmları kullanıcı etkisine göre yeniden yazdık. Ortalama kurtarma süresi (MTTR) saatlerden dakikalara indi; üretim hatalarının önemli bir kısmı artık kullanıcıdan önce alarmla yakalanıyor. Belki en kalıcı kazanç, nöbet yorgunluğunun belirgin biçimde azalması oldu — ekip bir alarm çaldığında artık nereye bakacağını biliyor. Bu rakamlar tek bir senaryonundur; her yığında sonuç değişir.

Sık sorulan sorular

Gözlemlenebilirlik ile izleme (monitoring) arasındaki fark nedir? İzleme, önceden bildiğiniz soruları sorar: “CPU %90’ı geçti mi?” Gözlemlenebilirlik, önceden bilmediğiniz soruları sormanızı sağlar: “Bu yeni hata yalnızca tek bir tenant’ta, tek bir endpoint’te ve son dağıtımdan sonra mı oluyor?” Üç pilon birlikte kurulduğunda, daha önce hiç görmediğiniz bir arızayı bile takip edebilirsiniz.

SLO ile SLA aynı şey mi? Hayır. SLA müşteriye verdiğiniz dış sözdür ve genelde ceza maddesi içerir. SLO ise ekibinizin kendine koyduğu, SLA’dan daha sıkı iç hedeftir. Aradaki tampon hata bütçenizdir: SLO’yu ihlal etmeden ne kadar risk alabileceğinizi ölçer ve özellik hızıyla güvenilirlik arasındaki dengeyi sayıya bağlar.

Çok fazla alarm geliyor; ekip artık bakmıyor. Ne yapmalı? Bu, alarm yorgunluğunun klasik belirtisidir ve çözümü daha fazla alarm değil, daha az ama daha iyi alarmdır. Kuralımız nettir: bir alarm yalnızca bir insanın hemen müdahalesini gerektiriyorsa çalar. Eyleme dönüşmeyen uyarıları panoya taşır, yalnızca gerçek olayları sayfa-çağrısına bırakırız.

Küçük bir ekibiz; tam SRE pratiği bize fazla mı? Küçük ekip için bütün kademeyi kurmayız; olgunluk modelinin sizi yormayacak bir seviyesini hedefleriz. Çoğu küçük ekip için Seviye 1–2 doğru noktadır: merkezî görünürlük ve birkaç gerçekten önemli alarm. SRE bir kadro değil, bir disiplindir; tek kişilik bir ekip bile uygulayabilir.

Kurumsal sistemler pillar’ı altında gözlemlenebilirlik ve SRE pratiklerini sizin yığınınıza nasıl uyarlayacağımızı konuşmak için bize ulaşın.