[Aior]

SRE bir disiplindir, iş ünvanı değil​

"Site Reliability Engineering" yıllar önce buzzword oldu. Gerçek pratik — taahhüt edilmiş güvenilirlik hedefleri, error budget'lar, post-incident incelemeler, on-call disiplini — gerçekten değerli.

SLO'lar, "uptime" değil​

"%99.9 uptime" bağlam olmadan anlamsız. Faydalı bir SLO belirler:

• Ölçtüğü kullanıcı yolculuğu.
• Başarı kriteri.
• Hedef — 28 günlük pencere üzerinde %99.5, %99.9, %99.95.
• Ölçüm metodolojisi.

Error budget'lar — müzakere aracı​

Error budget = (1 - SLO) × zaman. 28 günlük %99.9 SLO = ~40 dakika "izinli güvensizlik".

• Bütçe sağlıklıyken → özellikleri hızlı gönder, kontrollü riskler al.
• Bütçe tükendiğinde → özellikleri dondur, güvenilirlik işine odaklan.
• Karar mekanik, politik değil.

On-call: disiplin rotasyondan önemli​

• Primary + secondary.
• Bir haftalık rotasyon.
• Ödendi.
• Kötü bir on-call sonrası izin.
• On-call devirleri — açık incident'ler, devam eden araştırmalar.

Incident yaşam döngüsü​

1. Tespit — alert ateşler veya kullanıcı sorun bildirir.
2. Triyaj — primary on-call 5 dakika içinde değerlendirir.
3. Mobilizasyon — yüksek-severity için incident kanalı açılır, IC atanır.
4. Mitigation — tam anlaşılmasa bile servisi geri yükle.
5. İletişim — kullanıcılara, dahili paydaşlara.
6. Post-incident inceleme — 5 iş günü içinde, blameless.

Post-incident incelemeler — doğru yap​

• Blameless — hedef sistem iyileştirmesi.
• Sahipler ve son tarihlerle somut aksiyon öğeleri üretir.
• Aksiyon öğeleri tamamlanmaya kadar takip edilir.
• Incident'ler arası desenler tanımlanır ve ele alınır.

Toil — ekibi gizlice öldüren iş​

Toil = manuel, tekrarlayan, kalıcı değeri olmayan iş. SRE disiplini toil'i takip eder. Toil ekip zamanının ~%50'sini aştığında ekip operasyonlara dönüşmüştür.

Chaos engineering — ne zaman değerli​

• Ekibin sağlam observability'si var.
• Ekibin SLO'ları var.
• Sistem başarısızlıkları varsayacak kadar olgun.

Uyaracağımız bir desen​

Otorite vermeden SRE işe almak.

Her zaman karşılığını veren bir desen​

On-call inceleme toplantısı. Haftalık, on-call mühendis vardiyasında ne olduğunu anlatır.

Incident süreciniz nedir?

SRE is a discipline, not a job title​

"Site Reliability Engineering" became a buzzword years ago. The actual practice — committed reliability targets, error budgets, post-incident reviews, on-call discipline — is genuinely valuable.

SLOs, not "uptime"​

"99.9% uptime" is meaningless without context:

• The user journey it measures.
• The success criterion.
• The target over a defined window.
• The measurement methodology.

Error budgets — the negotiation tool​

Error budget = (1 - SLO) × time. 99.9% over 28 days = ~40 minutes.

• Budget healthy → ship features fast.
• Budget exhausted → freeze features.
• The decision is mechanical, not political.

On-call: discipline matters more than rotation​

• Primary + secondary.
• One-week rotations.
• Compensated.
• Time off after a bad on-call.
• On-call handoffs.

The incident lifecycle​

1. Detection.
2. Triage — within 5 minutes.
3. Mobilisation — Incident Commander assigned.
4. Mitigation — restore service first.
5. Communication.
6. Post-incident review — within 5 business days, blameless.

Post-incident reviews​

• Blameless.
• Concrete action items with owners.
• Action items tracked to completion.
• Patterns across incidents identified.

Toil​

Toil = manual, repetitive, no-lasting-value work. SRE tracks toil. When toil exceeds ~50% of team time, the team has become operations.

Chaos engineering — when worth it​

• Solid observability.
• SLOs exist.
• System mature enough to handle failures.

One pattern we'd warn about​

Hiring SREs without giving them authority.

One pattern that always pays off​

The on-call review meeting.

What's your incident process?