halilibrahimd27 · halilibrahimd27 · Jun 28, 2026 · Jun 27, 2026 · Jun 27, 2026 · Jun 27, 2026
@@ -1,3 +1,12 @@
+---
+description: "Suçlamayan (blameless) postmortem felsefesi ve şablonu: neden blameless, blameful/blameless ton karşılaştırması, dolu örnek ve kontrol listesi."
+tags:
+  - Culture
+  - Incident Response
+  - SRE
+  - Template
+---
+
 # Blameless Postmortem — Felsefe ve Şablon
 
 > *"Blameless" = "Suçsuz" değil; **suçlamayan**. Sistem hatasını

@@ -1,3 +1,12 @@
+---
+description: "Mühendislik performansı için iki çerçeve: DORA 4 delivery metriği (deploy sıklığı, lead time, MTTR, change failure) ve bütünsel SPACE modeli."
+tags:
+  - Culture
+  - DORA
+  - SRE
+  - Performance
+---
+
 # DORA & SPACE — Mühendislik Performansı Metrikleri
 
 > *"Ölçmediğin şeyi iyileştiremezsin; ama yanlış ölçtüğün şey ekibini boğar."*
@@ -242,6 +251,39 @@ Gün 7:   Dashboard'u team channel'da haftalık otomatik post yap
 
 ---
 
+## 📋 Checklist — production-ready ölçüm sistemi
+
+Dashboard'u "kuruldu" sayma; aşağıdakiler bitmeden veri güvenilmez.
+
+**Veri toplama**
+- [ ] 4 DORA metriği de otomatik toplanıyor (manuel Excel YOK — manuel veri bayatlar ve güvenilmez)
+- [ ] Deploy event'i tek doğruluk kaynağından geliyor (CI pipeline), elle işaretleme yok
+- [ ] "Failed deploy" tanımı yazılı ve ekipçe onaylı (rollback + hotfix + incident-correlation)
+- [ ] Incident kaynağı (PagerDuty/Opsgenie/issue) deploy'larla otomatik ilişkilendiriliyor
+- [ ] Lead time ölçümü ilk commit timestamp'ından başlıyor (PR açılış'tan değil)
+
+**İstatistik kalitesi**
+- [ ] Lead time ve MTTR için ortalama değil p50 + p95 raporlanıyor (averaj outlier'ı saklar)
+- [ ] Metrikler rolling pencere ile (7d / 30d) gösteriliyor, tek snapshot değil
+- [ ] Düşük hacimli ekipler için sample size belirtiliyor (n<10 deploy → trend yorumlanmaz)
+
+**SPACE dengesi**
+- [ ] DORA yanında en az bir SPACE boyutu (satisfaction/focus) düzenli ölçülüyor
+- [ ] Hız metriklerinin yanında burnout/satisfaction trend'i izleniyor (hız ↑ + memnuniyet ↓ = kırmızı bayrak)
+- [ ] Hiçbir karar tek metriğe dayanmıyor; en az iki sinyal çapraz kontrol ediliyor
+
+**Erişim ve ritim**
+- [ ] Dashboard tüm ekibe açık (sadece yönetici görmüyor — gözetim hissi yaratır)
+- [ ] Haftalık otomatik özet team channel'a post ediliyor (quarterly değil)
+- [ ] Metrikler ekipler arası kıyas için DEĞİL, her ekibin kendi trend'i için kullanılıyor
+- [ ] Gizli veri/credential dashboard URL'lerinde yok (`<GRAFANA_URL>`, `<WEBHOOK_SECRET>` env'de tutuluyor)
+
+**Eylem döngüsü**
+- [ ] Negatif trend için sahip + aksiyon tanımlanıyor (sadece kırmızı ok göstermek yetmez)
+- [ ] Metrik review'ı retrospektifin parçası — veri konuşmaya dönüşüyor
+
+---
+
 ## 📚 Devamı
 
 - [DORA — State of DevOps Report](https://dora.dev) (yıllık)

@@ -1,3 +1,11 @@
+---
+description: "Right-sized, role-targeted dokümantasyon kültürü: 4 katmanlı hiyerarşi (README, RFC, ADR, runbook) ve doc rotting'e karşı pratik stratejiler."
+tags:
+  - Culture
+  - Soft Skills
+  - Platform Engineering
+---
+
 # Documentation Culture
 
 > *"Dokümante etmediğin sistem, sadece sen anlıyor; bus factor 1; sen
@@ -254,6 +262,27 @@ Yılda bir audit. Her doc:
 
 ---
 
+## 📋 Checklist
+
+Bir doc'u "production-ready" saymadan önce:
+
+- [ ] Her repo'da Tier-1 README var — özet + quick start + architecture link 5 dakikada anlaşılıyor
+- [ ] Önemli mimari kararlar numaralı ADR'da (`docs/adr/`), 1 sayfayı geçmiyor, immutable
+- [ ] Doc başında `last-reviewed` + `owner` + `review-frequency` frontmatter'ı dolu
+- [ ] `CODEOWNERS`'ta doc dizinlerinin sahibi tanımlı (orphan doc yok)
+- [ ] CI'da link checker (lychee vb.) çalışıyor — kırık link PR'ı bloke ediyor
+- [ ] CI'da "6 aydır review olmamış" / stale doc uyarısı aktif
+- [ ] Code change ile doc aynı PR'da güncelleniyor (drift'e karşı PR kuralı)
+- [ ] Tüm code block'lar test edildi — komutlar gerçekten çalışıyor
+- [ ] Placeholder'lar `<UPPER_CASE>` formatında, gerçek IP/domain/credential yok
+- [ ] Linkler relative — repo taşınınca kırılmıyor
+- [ ] Diátaxis ayrımı korunmuş — tutorial / how-to / reference / explanation karışmamış
+- [ ] On-call için runbook + incident sonrası postmortem template'i mevcut
+- [ ] Doc Git'te (markdown), meeting notes Notion/Confluence'da — kaynak doc Slack thread değil
+- [ ] Audit'te "decommission ya da düzelt" geçti — stale doc silindi
+
+---
+
 ## 📚 Devamı
 
 - [Diátaxis framework](https://diataxis.fr) — 4 doc türü

@@ -1,3 +1,12 @@
+---
+description: "Sağlıklı on-call rotation kurma rehberi: primary/secondary roller, alert hijyeni, devir-teslim, eskalasyon ve sürdürülebilir nöbet pratikleri."
+tags:
+  - Culture
+  - Incident Response
+  - SRE
+  - Monitoring
+---
+
 # On-Call Playbook
 
 > *"Sağlıklı on-call: 7 gün boyunca rotation'da olduğunda **2 kez bile
@@ -228,6 +237,28 @@ Bir mühendisin "production-ready on-call" olması için:
 
 ---
 
+## 📋 Checklist
+
+On-call rotation'ı **production-ready** saymadan önce hepsini işaretle:
+
+- [ ] Rotation 4-8 kişi — < 4 ise burnout riski, hemen büyüt.
+- [ ] PagerDuty/Opsgenie ile auto-rotation kurulu, tatil/izin override çalışıyor.
+- [ ] Her aktif alert'in runbook'u var — runbook'suz alert canlıya alınmaz.
+- [ ] Alert'ler actionable + customer-impacting + urgent; gerisi ticket'a düşürüldü.
+- [ ] Severity tier (SEV-1..SEV-4) tanımlı, her tier'ın bildirim kanalı net.
+- [ ] Acknowledge SLA'i (15 dk) ölçülüyor, kaçırılınca secondary'ye eskale oluyor.
+- [ ] Incident Commander + Comms Lead rolleri SEV-1/SEV-2 için belirli.
+- [ ] Status page (<STATUS_PAGE_URL>) bağlı, Comms Lead güncelliyor.
+- [ ] Handoff ritüeli var — outgoing özet yazıyor, 30 dk overlap uygulanıyor.
+- [ ] Postmortem 24 saat içinde draft'a giriyor, blameless yürütülüyor.
+- [ ] Postmortem aksiyon item'larının > %70'i kapatılıyor (takip ediliyor).
+- [ ] Haftalık alert audit yapılıyor; false positive eşik ayarı veya silme ile kapatılıyor.
+- [ ] Compensation politikası net: standby/page-time pay veya comp-day veriliyor.
+- [ ] Yeni mühendis 4 haftalık onboarding (shadow → reverse shadow → solo) tamamladı.
+- [ ] Rotation ortalaması < 5 page; üzeri reliability yatırımı tetikliyor.
+
+---
+
 ## 📚 Devamı
 
 - [Google SRE Book — Chapter 11: Being On-Call](https://sre.google/sre-book/being-on-call/)

@@ -1,3 +1,11 @@
+---
+description: "DevOps kültürü referans klasörünün indeksi: blameless postmortem, on-call playbook, DORA/SPACE metrikleri, Team Topologies ve dokümantasyon kültürü."
+tags:
+  - Culture
+  - SRE
+  - Roadmap
+---
+
 # 00 · DevOps Kültürü
 
 > *"En zor problem, kodun değil; insanların problemidir."*

@@ -1,3 +1,11 @@
+---
+description: "Skelton & Pais'in Team Topologies kitabından damıtılmış 4 takım türü (stream-aligned, enabling, complicated-subsystem, platform) ve etkileşim modları rehberi."
+tags:
+  - Culture
+  - Platform Engineering
+  - Soft Skills
+---
+
 # Team Topologies — Ekip Yapısı Olarak Mühendislik
 
 > *Conway's Law: "Sistemler, tasarlayan organizasyonların iletişim
@@ -241,6 +249,25 @@ DevOps & Platform Engineering ekiplerinin **yapı** referansı.
 
 ---
 
+## 📋 Checklist
+
+Bir org yapısını "Team Topologies uyumlu" saymadan önce şunları doğrula:
+
+- [ ] Her takım net bir tipe oturuyor (stream-aligned / enabling / complicated subsystem / platform) — "karma" takım yok
+- [ ] Stream-aligned takımlar end-to-end bir akışın sahibi: build + deploy + on-call aynı ekipte ("you build it, you run it")
+- [ ] Hiçbir stream-aligned takım 9 kişiyi aşmıyor (aşıyorsa böl)
+- [ ] Platform team ürün gibi yönetiliyor: roadmap var, NPS ölçülüyor, ticket-driven değil
+- [ ] Platform self-service: yeni servis açmak / prod'a deploy etmek tek ekiple, az adımda yapılıyor
+- [ ] "DevOps team" / "QA team" / "Database team" gibi silo bottleneck'ler yok
+- [ ] Enabling takımlar için çıkış kriteri tanımlı — kalıcı hale gelmiyor, iş bitince dağılıyor
+- [ ] Her takım çifti için etkileşim modu açık (collaboration / X-as-a-Service / facilitating) ve süreli olanların bitiş tarihi var
+- [ ] Cognitive load ölçülüyor: "yeni servis / deploy / incident için kaç ekiple konuşmalıyım?" sayısı takip ediliyor
+- [ ] Extraneous cognitive load (tooling/process karmaşası) platform team backlog'unda azaltma hedefi olarak duruyor
+- [ ] Mimari diyagramı org chart'ı yansıtıyor (Conway's Law) — uyumsuzluk reorg sinyali olarak izleniyor
+- [ ] Reorg tetikleyicileri tanımlı: feature lead time'ı, koordinasyon toplantısı yükü, çapraz-ekip ticket sayısı
+
+---
+
 ## 📚 Devamı
 
 - *Team Topologies* — Skelton & Pais (kitap, **must read**)

@@ -1,3 +1,11 @@
+---
+description: "Code review'i bilgi paylaşımı ve kalite aracına çeviren pratikler: review'ın 3 amacı, nit/blocker/question kategori sistemi, reviewer ve author rehberi."
+tags:
+  - Git
+  - Culture
+  - Soft Skills
+  - Cheatsheet
+---
 # Code Review Checklist — İyi Review, İyi Reviewer
 
 > *"PR'a 'LGTM' yazıp geçmek review değildir; **kontroldür**.

@@ -1,3 +1,11 @@
+---
+description: "Conventional Commits 1.0 spec: feat/fix/chore commit formatı, niye işe yaradığı ve CI'da nasıl enforce edileceği; otomatik changelog ve semver bump'ın temeli."
+tags:
+  - Git
+  - CI/CD
+  - Policy as Code
+  - Cheatsheet
+---
 # Conventional Commits — Disiplinli Commit Mesajları
 
 > *"`fix typo lol` mesajı olan bir commit, 6 ay sonra hangi bug'ın

@@ -1,3 +1,11 @@
+---
+description: "GitHub'da PR hijyeni: PR template, otomatik label, semantic-pr-action, commit doğrulama, CODEOWNERS ve Renovate/Dependabot ile PR trafiğini otomasyona bağlama."
+tags:
+  - Git
+  - CI/CD
+  - Template
+  - Policy as Code
+---
 # PR Templates & Automation — PR'ları Standart, Hızlı, İzlenebilir Yap
 
 > *"Her PR description boş, label yok, link yok, checklist yok →

@@ -1,3 +1,11 @@
+---
+description: "Modern Git iş akışı rehberi indeksi: trunk-based development, conventional commits, code review, stacked diffs ve PR otomasyonu; 2026 branching stack'i."
+tags:
+  - Git
+  - CI/CD
+  - Roadmap
+  - Platform Engineering
+---
 # 01 · Git Workflow
 
 > *"Branch'lerin yaşam süresi, bug'ların yaşam süresine eşittir."*

@@ -1,3 +1,11 @@
+---
+description: "Stacked diffs pattern: büyük feature'ı küçük ve gerçekten review edilebilir PR'lara bölme; Graphite, Sapling veya manuel branch chain ile araç ve workflow."
+tags:
+  - Git
+  - CI/CD
+  - Culture
+  - Field Notes
+---
 # Stacked Diffs — Büyük Feature'ı Küçük PR'lara Bölme
 
 > *"3000 satırlık PR'ı 'review et' demek, mühendisin **gözünü

@@ -1,3 +1,11 @@
+---
+description: "Git Flow yerine trunk-based development: kısa ömürlü feature branch, feature flag ve güvenli prod deploy ile main üzerinde hızlı ve güvenli geliştirme rehberi."
+tags:
+  - Git
+  - CI/CD
+  - DORA
+  - Platform Engineering
+---
 # Trunk-Based Development — Hızın ve Güvenliğin Buluştuğu Yer
 
 > *"Branch'iniz 3 gün yaşıyorsa kötü; 3 hafta yaşıyorsa felaket;

@@ -1,3 +1,11 @@
+---
+description: "CI/CD cache katmanlari rehberi: dependency, build, Docker layer ve test result cache stratejileri somut config ornekleriyle; pipeline'i dakikalara indirir."
+tags:
+  - CI/CD
+  - Performance
+  - Docker
+  - Containers
+---
 # Caching Strategies — Build, Test, Deploy Cache
 
 > *"Cache hit %0 = 'biz yeni başlıyoruz' demek. Production CI'da

@@ -1,3 +1,12 @@
+---
+description: "GitHub Actions production tarifleri: OIDC cloud auth, matrix build, reusable workflow, caching ve secret yonetimi somut YAML ornekleriyle anlatilir."
+tags:
+  - CI/CD
+  - Git
+  - Security
+  - Secrets
+  - AWS
+---
 # GitHub Actions Recipes — Production Tarifleri
 
 > *"GitHub Actions YAML 'magic' değil — **disiplin**. Reusable

@@ -1,3 +1,11 @@
+---
+description: "GitLab CI/CD pratik tarifleri: DAG pipeline, dynamic child, multi-project trigger ve OIDC AWS auth; monorepo dostu DAG-native kullanim anlatilir."
+tags:
+  - CI/CD
+  - Git
+  - AWS
+  - Security
+---
 # GitLab CI Recipes — DAG, Dynamic Child, Multi-Project
 
 > *"GitLab CI 'GitHub Actions klonu' değil — **DAG-native** + **monorepo

@@ -1,3 +1,11 @@
+---
+description: "Flutter CI/CD icin komple checklist: hesaplar, Android/iOS gereksinimleri, Firebase, GitHub kurulumu, kod tarafi duzenlemeler ve toplam maliyet hesabi."
+tags:
+  - CI/CD
+  - Git
+  - Template
+  - Roadmap
+---
 # Flutter CI/CD için Gerekli Tüm Şeyler - Komple Checklist
 
 ## 📑 İçindekiler
@@ -871,6 +879,25 @@ README.md'ye:
 
 ---
 
+## 🚫 Anti-Pattern
+
+Flutter CI/CD kurarken sık yapılan ve mutlaka kaçınılması gereken hatalar:
+
+| Anti-pattern | Niye kötü | Doğru |
+|--------------|-----------|-------|
+| Keystore/.p12/.mobileprovision dosyalarını repo'ya commit etmek | Sertifika sızar, herkes uygulamanı imzalayabilir; geri alınamaz. | Hassas dosyaları `.gitignore`'a al, base64 olarak GitHub Secrets'ta sakla. |
+| Şifreleri workflow YAML'ına veya koda gömmek | Repo'yu gören herkes credential'a erişir; rotasyon imkânsızlaşır. | Tüm credential'ları `${{ secrets.* }}` referansıyla Secrets'tan oku. |
+| Keystore'u tek yerde tutmak / yedek almamak | Kaybedersen uygulamayı bir daha güncelleyemezsin (Play Store imza zorunlu). | En az 3 ayrı yerde yedekle: password manager + şifreli cloud + offline. |
+| Build number'ı elle artırmak | İnsan unutur, çakışan build number upload'ı reddedilir. | `--build-number=${{ github.run_number }}` ile otomatik artır. |
+| İlk testleri doğrudan production track'e atmak | Hatalı build gerçek kullanıcılara ulaşır, geri çekme zor. | Önce Firebase Distribution / internal track / TestFlight'ta dene. |
+| API key / service account JSON'unu loglara yazdırmak | Actions logları sızdırırsa credential ifşa olur. | Secret'ları echo etme; `add-mask` kullan veya hiç yazdırma. |
+| Sertifika expiry tarihini takip etmemek | Sertifika dolduğunda pipeline aniden kırılır, release durur. | Expiry tarihlerini takvime/uyarıya bağla, dolmadan yenile. |
+| Release build'i imzasız veya `minifyEnabled false` ile çıkmak | Store reddeder ya da APK şişer, kod açıkta kalır. | `signingConfig` + `minifyEnabled`/`shrinkResources` + ProGuard aktif olsun. |
+| `flutter test` / lint adımını CI'dan atlamak | Kırık kod store'a kadar gider, geç fark edilir. | Test job'ı build'lerden önce zorunlu (required check) yap. |
+| Service account'a Owner/aşırı geniş izin vermek | Sızarsa tüm projeye erişim açılır. | En az ayrıcalık: yalnız Release Manager / App Manager rolü ver. |
+
+---
+
 ## 📞 Yardım Kaynakları
 
 ### Dokümantasyon:

@@ -1,3 +1,11 @@
+---
+description: "CI/CD pipeline patternleri: lint, test, security scan, build, image scan, imzalama, SBOM ve GitOps promote adimlarinin sirali katmanlama referansi."
+tags:
+  - CI/CD
+  - Security
+  - SBOM
+  - GitOps
+---
 # CI/CD Pipeline Patterns
 
 > *"Pipeline'ın 10 dakika sürüyorsa ekip 'bekleyim de bir kahve içeyim'

@@ -1,3 +1,10 @@
+---
+description: "CI pipeline optimizasyonu: caching, parallelization, selective testing ve runner secimi teknikleriyle 30 dakikalik CI'yi 90 saniyeye indirme protokolu."
+tags:
+  - CI/CD
+  - Performance
+  - Cost Optimization
+---
 # Pipeline Performance — "10 Dakikalık CI"yi 90 Saniyeye İndir
 
 > *"CI 30 dakika sürüyorsa, mühendislerin yarısı PR açtıktan

@@ -1,3 +1,10 @@
+---
+description: "CI/CD bolumu indeksi: pipeline patternleri, GitHub Actions ve GitLab CI tarifleri, caching, reusable workflow ve yavas CI tedavi protokolleri."
+tags:
+  - CI/CD
+  - Git
+  - Roadmap
+---
 # 02 · CI/CD
 
 > *"Her commit deploy edilebilir olmalı; her deploy reversible olmalı."*

@@ -1,3 +1,11 @@
+---
+description: "GitHub Actions reusable workflow ve composite action ile org-wide CI/CD standardizasyonu: step, job ve workflow seviyesinde soyutlama pratikleri."
+tags:
+  - CI/CD
+  - Git
+  - Template
+  - Platform Engineering
+---
 # Reusable Workflows — Org-Wide Template
 
 > *"50 repo, 50 farklı CI workflow YAML. Bug 1 yerde fix → 50 repo