Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Game Day ve Chaos Engineering: Incident'ı Beklemeden Prova Etmek
Game day, steady state, hipotez, küçük blast radius ve önceden yazılmış abort koşuluyla yapılan kontrollü bir arıza provasıdır; chaos engineering bunu ölçülebilir bir deneye çevirir. Bookstore'un ödeme client'ına Polly'nin chaos strategy'leriyle hata enjekte ediyor, iki hipotezin çürüdüğünü (page 46 dakika gecikiyor, runbook sebebi göstermiyor) ölçüyor ve sonuçları runbook'a ve bir retry'a geri besleyerek checkout hatasını yüzde 9,3'ten yüzde 0,9'a indiriyoruz.
Gerçek Incident'lar 2: Otomasyon, Gizli Bağımlılıklar ve Kurtarma Yolları — AWS 2025, Facebook 2021, GitLab 2017, Knight Capital 2012
AWS, Facebook, GitLab ve Knight Capital vakalarında arızayı büyüten şey otomasyonun kendi hataları, gizli bağımlılıklar ve kurtarma yolunun da bozulan şeye bağlı olmasıydı; ders, kurtarma yolunu da düzenli denemektir. Dört vakayı resmî kaynaklardan anlatıyor, Bookstore'un SQL Server'ında ilk koşusu kırmızı çıkan bir restore drill çalıştırıyor, bağımlılık haritası ve break-glass erişim hazırlıyor ve sürüm karışıklığını yakalayan bir alert yazıyoruz.
Gerçek Incident'lar 1: Global Yayılan Config — Cloudflare 2025, Google Cloud 2025 ve CrowdStrike 2024
Cloudflare, Google Cloud ve CrowdStrike'ın büyük kesintilerinde tetikleyici kod değil, saniyeler içinde bütün dünyaya yayılan bir config ya da veri değişikliğiydi; ortak ders, kendi config'ini de input gibi doğrulamak ve aşamalı dağıtmaktır. Üç vakayı resmî postmortem'lerinden özetliyor, aynı hatayı Bookstore'un switches.json dosyasında üretiyor (geçersiz değerde her checkout 500, bozuk dosyada crash loop) ve bir doğrulama aracı ile last-known-good okuyucuyla düzeltiyoruz.
Postmortem Süreci: Review Toplantısı, Action Item Takibi ve Incident Metriklerinin Sınırları
Postmortem süreci, hangi incident'ın postmortem alacağını önceden yazmak, taslağı yazarı olmayan birinin yönettiği bir review'dan geçirmek ve action item'ları sahip, tarih ve ticket ile takip etmektir; MTTR gibi ortalamalar az örnekte çoğunlukla gürültüdür. Bookstore'un tabletop postmortem'ini yazıyor, action item'ları denetleyen bir .NET aracı kuruyor ve yüzde 38'lik bir MTTM iyileşmesinin hiçbir şey değişmeden de yüzde 40 olasılıkla görüldüğünü ölçüyoruz.
Incident Management: Severity, Incident Commander, İletişim ve Önce Mitigation
Incident yönetimi, arızayı tek bir karar noktasından (incident commander) yönetmek ve sebebi aramadan önce müşterinin yaşadığı etkiyi durdurmaktır; severity tanımları, roller ve kollar önceden hazırlanır. Bookstore'a restart gerektirmeyen bir ödeme timeout'u ve kill switch ekliyor, ödeme sağlayıcısının önce yavaşlayıp sonra çöktüğü bir tabletop exercise'ı laboratuvarda oynuyor ve her kararın etkisini ölçüyoruz.
On-call ve Runbook: Nöbet Düzeni, Escalation ve Uygulanabilir Runbook Yazmak
Sürdürülebilir on-call primary ve secondary nöbetçiyle, page bütçesiyle ve her alert için kopyalanabilir komutlardan oluşan bir runbook'la kurulur. Üç kişilik Bookstore ekibine uyarlanmış bir rotation, amtool ile doğrulanan Alertmanager routing'i, repoda tutulan bir runbook ve bu runbook'un gerçek bir arızada denenmesiyle bulduğumuz hataları; ilk iki adımı alert metnine taşıyan otomasyonu anlatıyoruz.
SLO Tabanlı Alerting: Burn Rate, Multiwindow Alert'ler ve Alert Yorgunluğunu Bitirmek
SLO tabanlı alert, error budget'ın harcanma hızını (burn rate) bir uzun ve bir kısa pencerede birlikte ölçer: uzun pencere kısa sıçramalarda susar, kısa pencere arıza bitince alert'i hızla kapatır. Bookstore checkout'u için Workbook'un 14,4/6/1 eşiklerini Prometheus rule'larına çeviriyor, promtool ile test ediyor, canlı bir arızada ne zaman çalıp sustuklarını ölçüyor ve Sloth'un ürettikleriyle karşılaştırıyoruz.
SLO ve Error Budget: Hedef Belirlemek, Nine'ların Matematiği ve Error Budget Policy
SLO, bugünkü ölçümden ve kullanıcı beklentisinden türetilen ve SLA'dan sıkı olan bir hedeftir; aradaki pay error budget'tır ve bittiğinde ne olacağını önceden yazılmış bir policy söyler. Bookstore checkout'u için yüzde 99,5 availability ve 800 ms latency SLO'sunu dokümana, Prometheus rule'larına ve OpenSLO'ya döküyor, nine'ları dakikaya çeviriyor ve yeni bucket ile kısa pencerenin bütçeyi nasıl yanlış gösterdiğini ölçüyoruz.
SLI Seçmek: Kullanıcı Yolculuğundan Ölçülebilir Sinyale
İyi bir SLI kullanıcının yolculuğundan çıkar ve iyi olayların geçerli olaylara oranıdır; 4xx ile health check paydaya girmez. Bookstore'un checkout'u için ASP.NET Core'un http.server.request.duration histogram'ından availability ve latency SLI'ları yazıyor, bütün endpoint'leri karıştırmanın ve ortalamanın hatayı nasıl gizlediğini, API kapalıyken uygulama metric'inin neden hiçbir şey görmediğini ölçüyoruz.
SRE Nedir? DevOps ile İlişkisi, Toil, Error Budget Fikri ve Küçük Ekipte SRE
SRE, operasyon işini yazılım mühendisliğiyle yürütmek ve güvenilirliği ölçülebilir bir hedefe bağlamaktır; yüzde 100 yanlış hedeftir, aradaki pay error budget olarak hız ile güvenilirlik arasındaki kararı verir. Toil'in tanımını, DevOps ile ilişkiyi ve ayrı SRE ekibi olmayan Bookstore ekibinin hangi pratikleri alacağını bir envanter tablosuyla ele alıyoruz.