{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Mustafa Erbay",
  "home_page_url": "https://mustafaerbay.com.tr/",
  "feed_url": "https://mustafaerbay.com.tr/feed.json",
  "description": "Teknoloji, kariyer ve yaşam üzerine yazılar.",
  "language": "tr-TR",
  "authors": [
    {
      "name": "Mustafa Erbay",
      "url": "https://mustafaerbay.com.tr/about"
    }
  ],
  "items": [
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-olay-oncesi-tatbikat-anlatisi-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-olay-oncesi-tatbikat-anlatisi-tasarimi",
      "title": "Teknik Liderler İçin Olay Öncesi Tatbikat Anlatısı Tasarımı",
      "summary": "Incident tatbikatlarını sadece teknik test değil, ortak karar ve iletişim pratiği haline getiren liderlik yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin olay oncesi tatbikat anlatisi tasarimi diagram.svg'; Tatbikat yapan birçok ekip yine de gerçek incident geldiğinde dağınık davranıyor. Bunun sebebi çoğu zaman tatbikat eksikliği değil, tatbikatın yalnızca teknik adımlara indirgenmesidir. Alarm geldiğinde kim konuşacak, hangi bilgi \"yeterli görünürlük\" sayılacak, geri alma cümlesi nasıl kurulacak ve yönetim tarafına hangi dil taşınacak önceden çalışılmadığında, iyi araçlar bile baskı altında yetmez. Teknik lider için olay öncesi tatbikat anlatısı tasarımı tam bu boşluğu kapatır. <figure <Image src={diagram} alt=\"Tatbikat öncesi ortak olay anlatısını kuran teknik şema\" / <figcaption İyi tatbikat sadece ne yapacağınızı değil, olay sırasında neyi nasıl anlatacağınızı da önceden sadeleştirir.</figcaption </figure Neden anlatı tasarımı ayrı bir konu? Çünkü incident anında insanlar sadece sistemi değil birbirini de okumaya başlar. Aynı metric'e bakan iki ekip, farklı öncelik çıkarabilir. Biri veri tutarlılığını merkeze koyarken diğeri müşteri etkisini önceleyebilir. Eğer bu ayrım tatbikat öncesinde konuşulmamışsa, olay başladığında teknik doğruluk ile iletişim ritmi birbirini bozmaya başlar. Anlatı tasarımı burada ortak çerçeve sağlar. \"Bu tür olayda ilk cümlemiz ne olur, ikinci kontrol noktasında neyi kanıt sayarız, hangi eşikte rollback'i doğal kabul ederiz?\" gibi sorular önceden yanıtlandığında ekipler yalnızca prosedür takip etmez; aynı senaryoyu benzer şekilde yorumlamaya başlar. Tatbikat anlatısı hangi bileşenlerden oluşur? Ben pratikte beş parçalı bir iskeletin çok işe yaradığını görüyorum: 1. Olayın tek cümlelik etki tarifi 2. İlk hipotez ve ilk kanıt yüzeyi 3. Komuta, sürücü ve iletişim rolleri 4. Geri alma veya etki daraltma eşikleri 5. Sonraki kontrol noktasında beklenen karar Bu yapı, tatbikatı \"bir runbook okuyalım\" seviyesinden çıkarır. Ekipler hangi kararın hangi bilgiyle verileceğini önceden prova eder. Özellikle kurumsal ortamlarda teknik liderlik, bilinmezliği tamamen yok etmekten çok onu taşınabilir hale getirme becerisidir. <Callout type=\"tip\" title=\"Senaryoyu çok erken karmaşıklaştırmayın\" İlk tatbikatlarda üç katmanlı gizli sürprizler yerine net bir olay akışı daha faydalıdır. Önce ortak ritim kurulsun, sonra karmaşıklık artırılsın. </Callout Teknik lider hangi dili kurmalı? Tatbikat öncesi anlatı kurarken liderin dili belirleyicidir. \"Herkes ne yapacağını biliyor mu?\" sorusu genellikle yüzeysel onay alır. Daha iyi sorular şunlardır: İlk üç dakikada hangi bilgi olmadan karar veremeyiz? Hangi cümle kullanıcı etkisini doğru anlatır? Rollback kararı geldiğinde bunu kim savunur? Bu senaryoda yönetim hangi soruyu ilk sorar? Bu dil, tatbikatı teknik ekip içi simülasyon olmaktan çıkarıp kurumsal karar pratiğine dönüştürür. İnsanlar yalnızca komut değil bağlam çalışır. Hangi hatalar tatbikatı boşa çıkarır? En yaygın hata, tatbikatı araç doğrulamasına sıkıştırmaktır. Dashboard açıldı, alarm düştü, biri komut çalıştırdı diye tatbikat başarılı sayılmaz. Eğer ekip hangi anda iletişim kesileceğini, hangi anda yeni hipotez açılmayacağını ve hangi bilgiyle rollback savunulacağını konuşmadıysa gerçek olayda yine aynı belirsizlik yaşanır. İkinci hata, anlatıyı fazlasıyla senaryo özel kurmaktır. \"Şu servis bozulursa şu komutu çalıştır\" türü tatbikatlar kısa ömürlüdür. Daha kalıcı değer, hizmet etkisi, karar eşikleri ve iletişim ritmi gibi tekrar kullanılabilir katmanlarda oluşur. Mentorluk boyutu nerede başlar? Tatbikat anlatısı, kıdemli mühendisler için güçlü bir mentorluk aracıdır. Genç mühendisler gerçek incident gelmeden önce sadece teknik adımı değil düşünme sırasını da görür. Neden önce etki cümlesi kuruluyor, neden üç hipotez birden açılmıyor, neden geri alma zayıflık değil risk yönetimi sayılıyor gibi davranışlar burada öğrenilir. Bu yüzden tatbikat sonunda sadece \"neyi düzelteceğiz\" değil, \"hangi cümleler işe yaradı, hangi karar noktası bulanık kaldı\" sorularını da açmak gerekir. Teknik liderlik çoğu zaman bu görünmez aktarımda kalıcı hale gelir. Sonuç Teknik liderler için olay öncesi tatbikat anlatısı tasarımı, incident hazırlığını teknik checklist seviyesinden çıkarır. Ortak etki dili, net karar eşikleri ve tekrar edilebilir iletişim ritmi kurulduğunda tatbikat gerçekten üretim davranışını değiştirir. Kurumsal ekiplerde en güçlü hazırlık çoğu zaman daha çok araç değil, aynı olayı benzer berraklıkla anlatabilme kabiliyetidir.",
      "date_published": "2026-04-11T00:00:00.000Z",
      "date_modified": "2026-04-11T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "incident-management",
        "mentorluk",
        "ekip-surecleri"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-islem-golgeleme-ile-guvenli-surum-gecisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-islem-golgeleme-ile-guvenli-surum-gecisi",
      "title": "ERP Altyapılarında İşlem Gölgeleme ile Güvenli Sürüm Geçişi",
      "summary": "Kritik ERP akışlarında yeni sürümü canlı etki oluşturmadan sınamak için işlem gölgeleme yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda islem golgeleme ile guvenli surum gecisi diagram.svg'; ERP ortamlarında sürüm geçişi korkutucudur; çünkü hata sadece teknik sistemde kalmaz, iş sürecine de yansır. İşlem gölgeleme yaklaşımı, üretim isteğinin kopyasını yeni sürüme göndererek davranış farkını kontrollü biçimde gözlemlemeyi sağlar. <figure <Image src={diagram} alt=\"ERP işlem akışını yeni sürüme gölge trafiğiyle taşıyan teknik şema\" / <figcaption Gölgeleme, müşteriyi iki kez etkilemek için değil yeni sürümün karar davranışını görünür kılmak için kullanılır.</figcaption </figure İşlem gölgeleme neyi çözer? Klasik test ortamı üretim çeşitliliğini yansıtmaz. Yeni sürüm laboratuvarda doğru çalışsa bile gerçek dünyada farklı kararlar üretebilir. Gölgeleme, üretim isteğinin kopyasını yeni sürüme göndererek bu farkları müşteri etkisi oluşturmadan yakalamanızı sağlar. <Callout type=\"tip\" title=\"Gölgeleme eşittir aynı sonucu beklemek değildir\" Bazı alanlarda küçük zaman veya sıralama farkları normaldir. Önemli olan iş açısından anlamlı sapmaları ayırt edecek karşılaştırma kuralları tanımlamaktır. </Callout Sonuç ERP altyapılarında işlem gölgeleme ile güvenli sürüm geçişi, yeni sürümü üretim verisine yakın koşullarda ama kontrollü sınamak için güçlü bir yöntemdir. Doğru sapma sınıflandırması kurulduğunda sürüm geçişi daha sakin ve kanıta dayalı hale gelir.",
      "date_published": "2026-04-11T00:00:00.000Z",
      "date_modified": "2026-04-11T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "architecture",
        "release-management",
        "observability",
        "enterprise"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-patch-orkestrasyonu-icin-bakim-dalga-mimarisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-patch-orkestrasyonu-icin-bakim-dalga-mimarisi",
      "title": "Kurumsal Platformlarda Patch Orkestrasyonu İçin Bakım Dalga Mimarisi",
      "summary": "Geniş platform filolarında yamaları tek seferde değil kontrollü dalgalarla yaymak için mimari karar çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal platformlarda patch orkestrasyonu icin bakim dalga mimarisi diagram.svg'; Kurumsal platformlarda patch yönetimi çoğu zaman iki kötü uç arasında sıkışır: ya her şey aynı gece güncellenir ve toplu risk alınır ya da güncellemeler ötelenir ve güvenlik borcu sessizce büyür. Bakım dalga mimarisi, patch işini takvim operasyonundan çıkarıp hizmet riski yönetimine bağlar. <figure <Image src={diagram} alt=\"Patch yayılımını kontrollü bakım dalgalarıyla yöneten teknik şema\" / <figcaption Patch orkestrasyonu, bütün filoyu aynı komutla güncellemek değil etkisini ölçerek dalga dalga taşımaktır.</figcaption </figure Neden tek parça patch yaklaşımı kırılgandır? Çünkü kurumsal platformlarda bütün bileşenler aynı önem ve geri dönüş kolaylığına sahip değildir. Aynı patch penceresinde hepsini birlikte geçirmek, görünürde düzenli ama gerçekte toplu körlük üretir. Bakım dalgası mimarisi nasıl kurulur? Pratikte varlık sınıfı, risk seviyesi ve geri dönüş kabiliyeti birlikte ele alınmalıdır. Bu üçlü üzerinden ilk pilot dalga, genişletilmiş doğrulama dalgası ve genel yayılım dalgası tanımlanır. <Callout type=\"tip\" title=\"Dalgaları sadece yüzdeye göre kurmayın\" Yüzde 10, yüzde 30, yüzde 100 yaklaşımı faydalıdır ama tek başına yeterli değildir. Aynı yüzde içinde yanlış varlık sınıflarını bir araya toplarsanız risk yine kümelenir. </Callout Sonuç Kurumsal platformlarda patch orkestrasyonu için bakım dalga mimarisi, güvenlik güncellemesini toplu cesaret gösterisinden çıkarır. Dalgalar kontrollü açıldığında hem patch hızı hem operasyon güveni artar.",
      "date_published": "2026-04-11T00:00:00.000Z",
      "date_modified": "2026-04-11T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "platform-engineering",
        "security",
        "automation",
        "operations",
        "architecture"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/podman-quadlet-ile-sistemd-tabanli-servis-konteynerizasyonu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/podman-quadlet-ile-sistemd-tabanli-servis-konteynerizasyonu",
      "title": "Podman Quadlet ile systemd Tabanlı Servis Konteynerizasyonu",
      "summary": "Sunucu servislerini Docker daemon bağımlılığı olmadan systemd ve Podman Quadlet ile yönetmenin pratik yolu.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './podman quadlet ile sistemd tabanli servis konteynerizasyonu diagram.svg'; Konteyner çalıştırmak için her zaman büyük bir orkestrasyon katmanına ihtiyaç yok. Özellikle tekil sunucu servisleri ve yardımcı ajanlar için systemd zaten güçlü bir yaşam döngüsü yöneticisi sunuyor. Podman Quadlet, bu gücü daemon'sız konteyner çalıştırma modeliyle birleştiriyor. <figure <Image src={diagram} alt=\"Podman Quadlet ile systemd servislerini konteyner olarak yöneten teknik şema\" / <figcaption Quadlet, konteyneri systemd diline çevirir; böylece servis yönetimi ile konteyner yaşam döngüsü aynı yerde buluşur.</figcaption </figure Neden Quadlet? Klasik podman run komutları başlangıç için hızlıdır; ama uzun ömürlü servislerde tekrar üretilebilirlik ve yönetilebilirlik önem kazanır. Quadlet, .container dosyalarıyla bu yapılandırmayı kalıcı hale getirir. Basit bir servis tanımı <Callout type=\"tip\" title=\"Konteyner ayarını systemd mantığıyla okuyun\" [Container] bölümü Podman çalışma parametrelerini, [Service] bölümü ise systemd davranışını taşır. </Callout Sonuç Podman Quadlet ile systemd tabanlı servis konteynerizasyonu, küçük ama kritik servislerde ağır platform kurmadan temiz bir işletim modeli sağlar.",
      "date_published": "2026-04-11T00:00:00.000Z",
      "date_modified": "2026-04-11T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "linux",
        "podman",
        "systemd",
        "containers",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/vector-vrl-ile-loglarda-hassas-veri-maskeleme-pipelinei",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/vector-vrl-ile-loglarda-hassas-veri-maskeleme-pipelinei",
      "title": "Vector VRL ile Loglarda Hassas Veri Maskeleme Pipeline’ı",
      "summary": "Merkezi log akışında hassas alanları hedefe varmadan temizlemek için Vector ve VRL tabanlı pratik yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './vector vrl ile loglarda hassas veri maskeleme pipelinei diagram.svg'; Merkezi log toplama hattı görünürlük sağlarken aynı zamanda veri sızıntısı yüzeyi de oluşturabilir. Vector ve VRL ile kaynak ile hedef arasına yerleştirilen bir maskeleme katmanı, bu riski hızlı ve ölçülü biçimde azaltır. <figure <Image src={diagram} alt=\"Vector VRL ile log akışında hassas veriyi maskeleyen teknik şema\" / <figcaption Log hattında asıl kazanç, hassas veriyi indekslendikten sonra değil akış içindeyken temizlemektir.</figcaption </figure Neden pipeline seviyesinde maskeleme? Bir kere indexlenmiş ya da farklı ekiplere açılmış kayıtları geriye dönük temizlemek zordur. Uygulama tarafını düzeltmek uzun vadede doğrudur; ama kısa vadede merkezi boru hattında koruyucu bir katman kurmak ciddi risk azaltır. Örnek VRL dönüşümü <Callout type=\"warning\" title=\"Regex maskeleme sınırsız çözüm değildir\" Alan yapısını biliyorsanız anahtar bazlı maskeleme en güvenli yoldur. </Callout Sonuç Vector VRL ile loglarda hassas veri maskeleme pipeline'ı, merkezi log hattında hızlı ve etkili bir koruma katmanı sağlar. En iyi log hattı, en çok veriyi toplayan değil en doğru veriyi güvenli biçimde taşıyan hattır.",
      "date_published": "2026-04-11T00:00:00.000Z",
      "date_modified": "2026-04-11T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "vector",
        "logging",
        "security",
        "observability",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-sessiz-bilgi-envanteri-ritmi",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-sessiz-bilgi-envanteri-ritmi",
      "title": "Kıdemli Mühendisler İçin Sessiz Bilgi Envanteri Ritmi",
      "summary": "Sistemi ayakta tutan örtük operasyon bilgisini kişilere bağımlı olmadan görünür kılmak için uygulanabilir ritim.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Birçok ekibin en kritik problemi eksik dokümantasyon değil, sistemin gerçek davranışını açıklayan bilginin birkaç kişinin zihninde saklı kalmasıdır. Alarm eşikleri neden öyle seçildi, hangi entegrasyon neden hep cuma gecesi hassas davranıyor, hangi bakım adımı gerçekten riskli, hangi müşterinin trafiği hangi yan etkiyi tetikliyor; bunların önemli kısmı ticket sistemine değil hafızaya yazılır. Kıdemli mühendis için sessiz bilgi envanteri ritmi, tam bu görünmeyen alanı ekipçe okunabilir hale getirme disiplinidir. Sessiz bilgi neden kurumsal riske dönüşür? Sessiz bilgi ilk bakışta verimlilik gibi görünür. Çünkü deneyimli mühendis bir problemi hızlı çözer ve toplantı uzamaz. Fakat bu hız çoğu zaman kurumsal olarak ödünç alınmış bir hızdır. Bilgi kişide kaldıkça ekip bağımsızlığı düşer, nöbet kalitesi dalgalanır ve servis sahipliği görünürde dağıtılmış olsa da fiilen daralır. Bu risk özellikle şu koşullarda büyür: Uzun ömürlü sistemlerin davranışı tarihsel kararlarla şekillenmişse Incident çözümünde düzenli olarak aynı birkaç kişi çağrılıyorsa Runbook'lar adımı yazıyor ama karar mantığını açıklamıyorsa Takım değişimi veya platform dönüşümü hızlanmışsa Sorun yalnızca bilgi kaybı değildir. Sessiz bilgi, karar gecikmesi ve yanlış güven hissi de üretir. Doküman var sanılır ama kritik eşikler hâlâ sözlü kültürde taşınır. Envanter çıkarmak ne demektir? Buradaki amaç her şeyi yazmak değildir. Asıl iş, ekip için yüksek etkili ama düşük görünürlüklü bilgi kümelerini tespit etmektir. Ben bunu dört sınıfta düşünmeyi faydalı buluyorum: 1. Operasyonel kestirme bilgiler 2. Tarihsel karar bağlamları 3. Kırılgan bağımlılık gözlemleri 4. İnsan ve süreç tabanlı geçiş kuralları Bir örnekle bakarsak, \"bu job bazen timeout oluyor\" bilgi değildir; gözlemdir. Bilgi ise şudur: \"Timeout yalnızca ERP tarafındaki raporlama penceresi açıldığında oluşuyor, çünkü aynı storage pool üzerinde IOPS baskısı artıyor.\" Envanterin değeri bu farkta ortaya çıkar. Hangi kaynaklardan toplanmalı? Sessiz bilgi çoğu zaman tek belgede bulunmaz. Onu şu yüzeylerde yakalarsınız: Postmortem notları Slack veya Teams kriz başlıkları Değişiklik sonrası açılmış geçici checklist'ler Kıdemli mühendislerin kişisel notları Gölge nöbet veya onboarding oturumlarında söylenen cümleler Bu kaynaklar dağınık olabilir. O yüzden envanter çalışması tek seferlik arşivleme değil, tekrar eden bir ritim olmalıdır. Ayda bir yapılan kısa ama odaklı tarama, yılda bir yapılan büyük bilgi temizliğinden daha değerlidir. <Callout type=\"tip\" title=\"Adımı değil, muhakemeyi toplayın\" Runbook'a yalnızca komutları yazarsanız kişiye bağımlılığı azaltamazsınız. Envanter maddesi, hangi sinyal görüldüğünde hangi kararın neden verildiğini de taşımalıdır. </Callout Sağlam ritim nasıl kurulur? Ben pratikte kırk beş dakikalık aylık oturum modelini etkili buluyorum. Bu oturumun amacı retrospektif yapmak değil, son dönemde birkaç kişinin üzerinde toplanmış bilgiyi görünürleştirmektir. Basit bir akış yeterlidir: Son otuz günde yalnızca belirli kişilerin çözdüğü olayları çıkarın Bu olaylarda yazılmamış karar noktalarını belirleyin Hangi bilginin runbook, mimari kayıt veya onboarding notuna dönüşeceğine karar verin Sahip atayıp kapanış tarihini görünür yapın Burada önemli olan, \"güzel olur\" listesi üretmek değil; ekip davranışını değiştirecek maddeleri seçmektir. İyi ritim, bilgi toplama işi ile yayınlama işini ayırmaz. Hangi bilgiler önce ele alınmalı? Her sessiz bilgi aynı değerde değildir. Öncelik için şu sorular iyi çalışır: Bu bilgi yoksa incident süresi uzar mı? Bu bilgi tek kişide kaldığı için değişiklik riski artıyor mu? Bu bilgi ekipler arası iletişimde sürtünme yaratıyor mu? Bu bilgi yeni bir mühendisin bağımsızlaşmasını doğrudan etkiliyor mu? Bu çerçeveyle bakıldığında bazı parlak teknik ayrıntılar geri plana düşer, bazı sıradan görünen cümleler ise kritik hale gelir. Örneğin bir firewall kuralının hangi portu açtığı değil, hangi entegrasyonun gerçek test saatleri dışında yanlış negatif ürettiği daha değerli olabilir. Sessiz bilgi envanteri mentorlukla nasıl birleşir? Kıdemli mühendislik yalnızca problemi çözmek değil, çözme kapasitesini çoğaltmaktır. Sessiz bilgi envanteri bu yüzden mentorlukla doğrudan bağlıdır. Çünkü bilgi tek başına yazıya döküldüğünde değil, ekip içinde kullanıldığında değer üretir. Bu nedenle her envanter maddesi için küçük bir taşıma yöntemi tanımlamak gerekir: Runbook güncellemesi Kısa demo veya brown bag oturumu On call shadowing notu Mimari karar kaydı Yeni üyeler için onboarding adımı Bilginin depolandığı yer ile öğrenildiği yüzey aynı olmak zorunda değildir. Ama aralarında bilinçli bir köprü kurulmalıdır. En sık hata: Her şeyi wiki'ye yığmak Kurumsal ekiplerin sık yaptığı hata, sessiz bilgi problemini \"bir Confluence sayfası açalım\" düzeyinde çözmeye çalışmaktır. Bu yaklaşım kısa sürede belge çöplüğü üretir. Çünkü bilgi önceliklendirilmez, sahiplenilmez ve kullanım anına bağlanmaz. Daha doğru yaklaşım, envanteri küçük tutmak ve şu disiplinleri korumaktır: Her madde bir risk veya karar anına bağlanmalı Her madde güncel sahibi olan bir sisteme referans vermeli Her madde düzenli bakım gerektirmeli Her madde ya runbook'a ya onboarding'e ya da mimari kayda bağlanmalı Bu filtreler olmazsa bilgi artar ama belirsizlik azalmaz. Sonuç Kıdemli mühendisler için sessiz bilgi envanteri ritmi, dokümantasyon kampanyası değil ekip bağımsızlığı yatırımıdır. Sistem bilgisini kişisel reflekslerden çıkarıp ortak çalışma yüzeyine taşıdığınızda incident kalitesi yükselir, servis sahipliği daha gerçek hale gelir ve mentorluk soyut bir iyi niyet olmaktan çıkar. Kurumsal olgunluk da tam burada görünür: yalnızca bilen kişilere değil, bilgiyi taşıyan işletim modeline sahip olmakta.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "mentorluk",
        "operasyon-kulturu",
        "ownership",
        "incident-management"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-alert-yorgunlugundan-ogrenme-dongusune-gecis",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-alert-yorgunlugundan-ogrenme-dongusune-gecis",
      "title": "Teknik Liderler için Alert Yorgunluğundan Öğrenme Döngüsüne Geçiş",
      "summary": "Alert gürültüsünü yalnızca azaltmak yerine ekip öğrenmesine, nöbet sağlığına ve operasyon kalitesine bağlayan liderlik yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin alert yorgunlugundan ogrenme dongusune gecis diagram.svg'; Birçok teknik ekip alert yorgunluğunu izleme sisteminin doğal yan etkisi gibi kabul eder. Oysa konu çoğu zaman araç değil, liderlik tasarımı problemidir. Gürültülü alarm akışı; sahipliği belirsiz servisler, zayıf olay sınıflandırması, eksik geri besleme döngüsü ve ölçülmeyen nöbet yükünün birleşiminden çıkar. Teknik lider için asıl görev, alert sayısını düşürmekten önce bu sinyal akışını ekip öğrenmesine bağlayacak işletim modelini kurmaktır. <figure <Image src={diagram} alt=\"Alert gürültüsünden öğrenme döngüsüne geçen ekip ritmini gösteren teknik şema\" / <figcaption Operasyon olgunluğu, alarmı kapatmaktan çok alarmın kuruma ne öğrettiğini görünür kıldığında yükselir.</figcaption </figure Alert yorgunluğu neden kültürel bir semptomdur? Alert yorgunluğu genellikle şu cümleyle başlar: \"Bu alarmı da susturalım.\" Kısa vadede rahatlatıcı görünür; fakat uzun vadede sistem davranışını daha da opak hâle getirir. Çünkü aynı gürültüyü üreten asıl sorular masada kalır: Hangi alarm gerçekten kullanıcı etkisini temsil ediyor? Hangi alarm yalnızca teknik semptomu tekrar ediyor? Hangi alarmın net bir sahibi var? Hangi alarm kapanınca öğrenme döngüsü gerçekten tamamlanmış oluyor? Bu soruların cevabı yoksa sorun yalnızca eşik değeri değildir. Sorun, gözlem sinyallerinin işletim modeline bağlanmamış olmasıdır. Doğru soru: kaç alarm var değil, alarmdan sonra ne değişiyor? Benzer ekiplerde faydalı olan yaklaşım şudur: alarm hacmini ana metrik yapmamak. Çünkü bazı dönemlerde alarm artışı sağlıklı bile olabilir; yeni servis açılmıştır, yeni hata sınıfı görünmüştür, yeni SLO izlenmeye başlanmıştır. Önemli olan alarmın ardından ne olduğudur. İyi bir teknik lider, her alarm sınıfı için şu akışı zorunlu kılar: 1. Alarm görüldü mü? 2. Doğru ekip devreye girdi mi? 3. Etki seviyesi doğru sınıflandı mı? 4. Kalıcı iyileştirme kaydı açıldı mı? 5. Aynı alarm tekrarlandığında ekip daha az bilişsel yük taşıdı mı? Bu akış yoksa alarm kapansa bile organizasyon öğrenmemiş olur. <Callout type=\"tip\" title=\"Susturmak çözüm değildir\" Sık tekrarlanan düşük değerli alarmı sessize almak, ancak onun yerine hangi koruyucu sinyalin geçeceğini biliyorsanız doğrudur. </Callout Alert portföyünü üç sepete ayırın Tüm alarm kurallarına aynı yönetişim uygulanırsa sonuç ya aşırı bürokrasi ya da kontrolsüz çoğalmadır. Pratikte şu üç sepet yeterli olur: Aksiyon alarmı : Nöbetçi ekipten belirli sürede müdahale beklenir. Farkındalık alarmı : Aynı anda müdahale gerektirmez ama ekip ritmine veri sağlar. Mühendislik alarmı : Trend, kalite veya kapasite sorunu işaret eder; çalışma planına girmelidir. Bu ayrım kritik bir rahatlık sağlar. Çünkü her sinyali gece yarısı çağrısına dönüştürmek zorunda kalmazsınız. Aynı zamanda üretim davranışını görünmez hâle de getirmezsiniz. Nöbet yükünü servis başına değil hata sınıfı başına görün Çoğu ekip nöbet yükünü kişi başına gelen çağrı sayısıyla ölçer. Bu yetersizdir. Aynı sayıda çağrı alan iki ekipten biri daha fazla tükenebilir; çünkü çağrıların bağlamı zayıftır, çözüm yolları parçalıdır veya aynı kök neden farklı alarmlarla tekrar eder. Daha işe yarayan model, alarmı şu başlıklarda sınıflamaktır: Bilinen ve runbook'u olan Bilinen ama aksiyonu manuel olan Bilinmeyen ve araştırma gerektiren Yanlış pozitif veya düşük değerli Bu görünürlük oluştuğunda teknik lider hangi yatırımın nöbet yükünü gerçekten düşüreceğini daha net görür. Bazen yeni araç gerekmez; iki alarmı birleştirmek, bir alanı standardize etmek veya karar ağacını sadeleştirmek yeterlidir. Öğrenme döngüsü nasıl işletilir? Alert yorgunluğunu azaltan ekipler alarm review toplantısı yapmaz; alarm öğrenme ritmi kurar. Fark önemlidir. Review çoğu zaman geçmişi denetler. Öğrenme ritmi ise gelecekteki bilişsel yükü düşürür. Benim önerdiğim çerçeve şu şekilde: Haftalık olarak en çok tekrarlanan ilk 10 alarm incelenir. Her alarm için kullanıcı etkisi, müdahale süresi ve tekrar sebebi işaretlenir. Kalıcı aksiyonlar üç sınıfa ayrılır: kaldır, birleştir, güçlendir. Sonraki hafta gerçekten neyin değiştiği ölçülür. Burada amaç kusur aramak değildir. Amaç, gürültüyü kurumsal öğrenmeye çevirmektir. Teknik lider hangi metrikleri izlemeli? Alarm sayısı tek başına yanıltıcıdır. Daha iyi gösterge seti şöyledir: Aksiyon alarmı başına yanlış pozitif oranı Alarmdan ilk anlamlı aksiyona kadar geçen süre Aynı kök nedenden türeyen tekrar alarm oranı Runbook'u güncellenmiş alarm yüzdesi Nöbet devri sonrası kişi başı taşınan açık aksiyon sayısı Bu metrikler ekibin yalnızca operasyonu sürdürüp sürdürmediğini değil, operasyonu öğrenip öğrenmediğini gösterir. Ürün ve platform ekipleri arasında gerilim nerede çıkar? Alert yorgunluğu çoğu zaman platform takımının gürültüyü, ürün takımının ise etkisizliği hissetmesiyle büyür. Platform tarafı \"çok çağrı geliyor\" der; ürün tarafı \"ama sorunlar gerçek\" diye cevap verir. İki taraf da haklı olabilir. Liderin görevi bu gerilimi ortak bir risk diline çevirmektir. Örneğin yüksek gecikme alarmı için şu ayrım netleştirilebilir: Müşteri etkisi varsa aksiyon alarmı Sadece iç servis kuyruğu büyüyorsa mühendislik alarmı Deploy sırasında beklenen dalgalanmaysa farkındalık alarmı Aynı sinyal, bağlamına göre farklı işletim yoluna girebilir. Bunu kuran şey teknik liderliğin tasarım kalitesidir. Sonuç Alert yorgunluğu bir observability aracı problemi gibi görünse de gerçekte ekip öğrenme ekonomisinin problemidir. Teknik lider, alarm portföyünü risk, aksiyon ve öğrenme açısından yeniden düzenlediğinde hem nöbet sağlığı iyileşir hem incident kalitesi yükselir. Asıl başarı, daha sessiz sistem değil; daha anlamlı sinyal üreten ve her olaydan sonra biraz daha hafif çalışan ekip düzenidir.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "observability",
        "incident-management",
        "operasyon-kulturu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-degisiklik-sonrasi-guven-tazeleme-oturumu",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-degisiklik-sonrasi-guven-tazeleme-oturumu",
      "title": "Teknik Liderler İçin Değişiklik Sonrası Güven Tazeleme Oturumu",
      "summary": "Riskli yayınlardan sonra ekibin teslim güvenini geri toplamak için kısa, ölçülü ve teknik liderlik odaklı oturum modeli.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Zor bir yayın, rollback ya da kıl payı atlatılmış bir üretim problemi sonrasında teknik ekiplerin ilk refleksi genelde iki uçtan birine kayar. Ya hiçbir şey olmamış gibi normal akışa dönmeye çalışırlar ya da bir süre boyunca her değişikliğe gereğinden fazla kuşkuyla yaklaşırlar. Her iki uç da pahalıdır. Teknik lider için değişiklik sonrası güven tazeleme oturumu, ekibin teslim ritmini panik ya da inkâr üzerinden değil, görünür sinyaller üzerinden yeniden dengeleme pratiğidir. Güven neden ayrı bir operasyon konusu? Çünkü yayın güveni yalnızca test başarısıyla ölçülmez. Bir ekip arka arkaya sorunlu değişiklik yaşadığında şu etkiler ortaya çıkar: Review döngüleri gereksiz uzar Küçük değişiklikler bile yüksek risk gibi algılanır Operasyon ekibi daha fazla manuel kontrol ister Ürün tarafı teknik ekibin tahminlerine daha az güvenir Burada kaybolan şey yalnızca hız değildir. Karar netliği de zayıflar. Aynı değişiklik için bir hafta önce makul görülen risk, bugünkü duygusal bağlam yüzünden \"bekleyelim\" kararına dönebilir. Güven tazeleme oturumu neyi çözer? Bu oturum retrospektif değildir, postmortem de değildir. Amaç suçlu aramak ya da tüm kök nedenleri yeniden tartışmak değildir. Amaç, son değişiklikten sonra ekipte kalan belirsizliklerin hangilerinin gerçek risk, hangilerinin psikolojik yankı olduğunu ayırmaktır. Ben bu oturumda üç çıktı beklemeyi doğru buluyorum: 1. Hangi teslimatlar güvenle devam edebilir? 2. Hangi alanlarda geçici güven artırıcı kontrol gerekiyor? 3. Hangi kurallar artık yük üretmeye başladı? Bu çerçeve, ekipteki \"şimdilik hiçbir şeye dokunmayalım\" refleksini veriyle daraltır. Hangi anda yapılmalı? Çok erken yapılırsa herkes hâlâ savunmadadır. Çok geç yapılırsa olayın duygusal izi operasyon kararlarına sessizce yerleşir. Pratikte en iyi zaman, incident veya riskli yayın kapandıktan sonraki ilk bir ya da iki iş günüdür. Böylece teknik ayrıntılar hâlâ canlıdır, ama ekip refleks halinde konuşmaktan çıkmıştır. Oturumun süresi de önemlidir. Kırk beş dakikayı aşan toplantılar kolayca postmortem tekrarına dönüşür. Burada amaç kısa, karar üreten ve takvime etkisi olan bir konuşma yapmaktır. <Callout type=\"tip\" title=\"Sinyal ile korkuyu ayırın\" Sorunlu bir yayın sonrası her çekince risk değildir. Oturumun görevi, hangi çekincenin ölçülebilir sinyale dayandığını ayıklamaktır. </Callout Hangi girdiler masada olmalı? İyi oturum sezgiyle değil, küçük ama güçlü veriyle yürür. Ben şu girdilerin yeterli olduğunu görüyorum: Değişikliğin etkilediği servis veya alan listesi Yayın sonrası gözlenen gerçek hata penceresi Kullanılan geçici koruma adımları Bir sonraki benzer yayın için önerilen kontrol farkları Operasyon yükünün kimlerde toplandığı Bu girdiler sayesinde toplantı duygusal değerlendirme olmaktan çıkar. \"Ekip tedirgin\" yerine \"aynı alarmı iki kişi manuel doğrulamak zorunda kaldı\" gibi okunabilir cümlelere geçilir. Karar yüzeyi nasıl sade tutulur? Teknik liderin burada ana görevi tartışmayı küçük karar paketlerine çevirmektir. Ben şu başlıkları ayrı tutuyorum: Hemen kaldırılacak geçici frenler Bir sonraki yayın için eklenecek güven artırıcı adımlar Kalıcı süreç değişikliği gerektiren yapısal açıklar Bu ayrım yapılmadığında ekip ya gereksiz sertleşir ya da önemli dersi çok hızlı unutur. Özellikle değişiklik dondurma kararları için açık bir bitiş koşulu yazılmalıdır. Aksi halde geçici frenler kültüre dönüşür. Güven tazeleme ile kontrol artışı arasındaki fark Yayın güvenini geri kazanmanın kolay görünen yolu, daha fazla manuel onay ve daha uzun checklist eklemektir. Fakat bu yaklaşım çoğu zaman güven üretmez; yalnızca gecikmeyi resmileştirir. Güven tazeleme oturumunun farkı, kontrol eklemekten önce hangi kontrolün gerçekten sinyal ürettiğini sormasıdır. Örneğin: Yeni bir smoke test gerçekten yeni bir hata sınıfını yakalayacak mı? Ek onay adımı teknik belirsizliği mi azaltıyor, yoksa yalnızca sorumluluğu mı yayıyor? Canary süresi uzatılınca karar kalitesi artıyor mu, yoksa yalnızca bekleme süresi mi büyüyor? Bu sorular teknik liderliği görünür kılar. Çünkü liderin görevi daha fazla frene razı olmak değil, doğru frenin nerede işe yaradığını gösterebilmektir. Ekip psikolojisi neden ihmal edilmemeli? Bir yayın kazası sonrası bazı mühendisler daha çok kontrol ister, bazıları ise hemen normale dönmek ister. İkisi de anlaşılabilir. Fakat işletim modeli bu duygusal farkı yönetmezse ekip içinde gizli gerilim oluşur. Güven tazeleme oturumu burada ortak dil kurar: kişisel rahatlama yerine ekipçe kabul edilen risk eşiği. Bu yüzden oturum sonunda şu cümlelerin netleşmesi önemlidir: Şu tip değişiklikler normal akışta ilerleyebilir Şu tip değişiklikler için ek telemetry şarttır Şu tip değişiklikler için geçici çift onay uygulanacaktır Bu kurallar şu tarihte yeniden gözden geçirilecektir Kurala son kullanma tarihi yazmak, geçici reaksiyonların kalıcı bürokrasiye dönüşmesini engeller. Sonuç Teknik liderler için değişiklik sonrası güven tazeleme oturumu, ekip moralini düzeltme toplantısı değil teslim güvenini mühendislik verisiyle yeniden kurma aracıdır. Doğru uygulandığında ekip korkusuz değil, berrak hareket eder. En kıymetli çıktı da budur: riskli bir yayın sonrasında bile değişiklik yapma kapasitesini kaybetmemek, ama aynı hatayı da romantikleştirmemek.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "release-management",
        "operasyon-kulturu",
        "ekip-surecleri"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-sev2-olaylarda-karar-delegasyonu",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-sev2-olaylarda-karar-delegasyonu",
      "title": "Teknik Liderler İçin Sev2 Olaylarda Karar Delegasyonu",
      "summary": "Sev2 incident anlarında teknik liderin karar yükünü dağıtmak için net rol, eşik ve iletişim çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin sev2 olaylarda karar delegasyonu diagram.svg'; Sev2 olaylar çoğu kurumda yanıltıcı biçimde \"orta şiddette\" görülür. Gerçekte ise müşteri etkisi vardır, iş birimleri baskı üretir, ekipler hızla bir karar merkezi arar ve teknik liderin masasına aynı anda hem tanı, hem iletişim, hem de değişiklik onayı gelir. Bu noktada liderin her kararı kendisinin vermesi kısa süreli güven hissi yaratır; fakat birkaç saat içinde hem tempo düşer hem de ekip inisiyatifi donar. Doğru yaklaşım, kararları rastgele dağıtmak değil, incident daha büyümeden hangi kararın kimde olduğunu önceden tanımlamaktır. <figure <Image src={diagram} alt=\"Sev2 olaylarda teknik liderin karar delegasyonu akışını gösteren teknik şema\" / <figcaption Delegasyon, kontrol kaybı değil; karar trafiğini darboğaz oluşturmadan yönetme yöntemidir.</figcaption </figure Neden özellikle Sev2 olaylarda zorlanılır? Çünkü Sev1 kadar net komuta modeli kurulmaz, Sev3 kadar da rahat geçiştirilmez. Ekipler şu ikileme girer: Etki büyümeden hızlanmak gerekir. Fakat her değişiklik daha büyük bir müşteri etkisine de dönüşebilir. Bu yüzden teknik lider çoğu zaman her tartışmanın içine çekilir. Hangi rollback'in güvenli olduğu, hangi ekipten destek isteneceği, dış iletişime ne yazılacağı ve bir sonraki durum güncellemesinin ne zaman geçileceği tek kişide toplanır. Bu bir süre sonra liderliği güçlendirmez; sistemi kırılganlaştırır. Karar delegasyonu hangi kararlarla başlar? Ben Sev2 olaylarında kararları dört sınıfa ayırmayı faydalı buluyorum: 1. Tanı kararları : Hangi hipotez önce test edilecek? 2. Müdahale kararları : Rollback, feature kapatma, trafik yönlendirme gibi teknik hamleler. 3. İletişim kararları : İç paydaş, destek ve yönetim güncellemeleri. 4. Risk kararları : Ek değişiklik açma, bakım penceresi dışına çıkma, geçici istisna verme. Bu sınıflar ayrılmadığında herkes teknik kararı konuştuğunu sanır; oysa masada çoğu zaman iletişim ve risk kararı da vardır. Kim hangi kararı almalı? Pratik bir modelde roller şu şekilde netleşebilir: Incident komutanı : Tempo, zaman kutuları ve iletişim ritminden sorumludur. Teknik sürücü : Tanı ve geri alma seçeneklerini değerlendirir. Servis sahibi : Uygulama davranışı, veri etkisi ve bağımlılık risklerini teyit eder. Teknik lider : Yüksek etkili risk kararlarında son eşiği koyar ve darboğazları temizler. Buradaki kritik nokta, teknik liderin her kararı ilk elden vermemesi; hangi eşikte devreye gireceğini bilmesidir. Örneğin önceden tanımlanmış rollback, kapasite artırımı veya feature flag kapatma yetkisi teknik sürücüde olabilir. Fakat veri tutarlılığı riski taşıyan şema değişikliği geri alımı teknik lider onayına bağlı kalmalıdır. <Callout type=\"tip\" title=\"Delegasyon sadece rol dağılımı değildir\" Yetki devri ancak karar eşiği, geri çağırma koşulu ve kayıt disiplini ile birlikte çalışır. \"Gerekirse bana sorarsınız\" ifadesi delegasyon değildir. </Callout Hangi eşikler lider onayı gerektirir? Ben üç eşiğin açıkça yazılmasını öneriyorum: Geri dönüşü zor veri değişikliği Birden fazla kritik servisi etkileyen trafik kaydırma Regülasyon, güvenlik veya müşteri taahhüdü riski doğuran geçici istisna Bunun dışındaki kararlar mümkün olduğunca olay masasına yakın alınmalıdır. Çünkü liderin sürekli onay noktası olması, ekipte şu zararlı refleksi doğurur: sorumluluk yukarı taşınır, düşünme kası aşağıda zayıflar. İletişim delegasyonu neden ayrı düşünülmeli? Birçok teknik lider teknik delegasyonu tasarlar ama iletişim kendisinde kalır. Oysa Sev2 olaylarda iletişim gecikmesi, yanlış teknik karardan daha pahalı olabilir. İş birimi ya da destek ekipleri bilgi alamadığında kendi anlatısını üretir. Bu yüzden şu görev ayrı sahiplenilmelidir: Her 20 ya da 30 dakikada durum özeti geçmek Bilinen etkiyi tek cümlede güncellemek Tahmin ile kanıtı ayırmak Bir sonraki kontrol zamanını yazmak Bu akış incident komutanında veya operasyon iletişimi sorumlusunda olabilir. Teknik lider yalnızca mesajın riskli kısmını gözden geçirir. Delegasyon kültürü nasıl öğretilir? Kıdemli mühendislik pratiğinde delegasyon, iş bırakmak değil öğretilebilir karar modeli kurmaktır. Ben bunun için olay sonrası üç sorunun güçlü olduğunu düşünüyorum: 1. Hangi kararı merkezde tuttuğumuz için yavaşladık? 2. Hangi kararı sahaya bıraktığımız için hızlandık? 3. Hangi eşik belirsiz kaldığı için gereksiz escalation oluştu? Bu sorular düzenli kullanıldığında ekip, yalnızca teknik çözüm değil karar dağıtımı konusunda da olgunlaşır. En sık yapılan hata nedir? Delegasyonu yalnızca sakin zamanların lüksü sanmak. Oysa gerçek ihtiyaç tam baskı anında ortaya çıkar. Eğer ekipler normal günlerde rollback, feature kapatma, kapasite açma veya geçici yönlendirme kararlarını birlikte prova etmiyorsa Sev2 anında herkes otomatik olarak en kıdemli kişiye bakar. Sonuçta teknik lider yorulur, ekip pasifleşir ve olay süresi uzar. Sonuç Teknik liderler için Sev2 olaylarda karar delegasyonu, otoriteyi bölmek değil müdahale ritmini korumaktır. Doğru rol tanımı, net onay eşikleri ve ayrı iletişim sahipliği kurulduğunda teknik lider her ayrıntıya koşmak zorunda kalmaz. Bunun yerine gerçekten yüksek etkili kararların kalitesine odaklanır. Kurumsal ekiplerde sürdürülebilir incident yönetimi tam olarak bu ayrımdan güç alır.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "incident-management",
        "ekip-surecleri",
        "mentorluk"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-yonetime-teknik-risk-tercumesi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-yonetime-teknik-risk-tercumesi",
      "title": "Teknik Liderler İçin Yönetime Teknik Risk Tercümesi",
      "summary": "Teknik riski alarm diliyle değil, karar etkisi ve işletme sonucu üzerinden anlatan liderlik pratiği.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Teknik liderliğin zor tarafı çoğu zaman problemi görmek değil, gördüğü problemi kurumun karar diline çevirmektir. Mühendislik tarafında yüksek hata oranı, dar boğaz yaratan veritabanı kilitleri ya da yama gecikmeleri net birer risk sinyalidir. Fakat yönetim masasına geldiğinizde aynı başlıklar çoğunlukla bütçe, teslim tarihi, itibar, uyumluluk veya müşteri deneyimi ekseninde tartışılır. Aradaki köprü kurulmadığında teknik ekip haklı, yönetim de ikna olmamış olur. Neden salt teknik dil yetmez? Kurumsal yapılarda teknik liderin karşısındaki paydaşların hepsi aynı soyutlama seviyesinde çalışmaz. Operasyon müdürü hizmet kesintisinin yeniden yaşanıp yaşanmayacağını sorar. Finans tarafı riskin maliyetini duymak ister. Ürün tarafı takvim kaymasını bilmek ister. Siz ise \"queue saturation\", \"single AZ dependency\" veya \"sertifika rotasyonu eksik\" diyorsunuzdur. Bu ifadeler mühendislik için doğrudur ama karar üretmek için eksiktir. Çünkü yönetim teknik semptomu değil, semptomun iş etkisini değerlendirir. İyi tercüme neyi değiştirir? İyi risk tercümesi, teknik ayrıntıyı saklamaz; onu karar verilebilir hale getirir. Benim pratikte en faydalı bulduğum çerçeve dört sorudan oluşuyor: 1. Risk bugün hangi sistem davranışında görünür hale geldi? 2. Bu risk gerçekleşirse hangi iş sonucu bozulur? 3. Riski küçültmek için hangi yatırım veya kısıt gerekiyor? 4. Kararı geciktirmenin maliyeti nedir? Bu yapı sayesinde \"Redis failover testi yapılmadı\" cümlesi, \"ödeme akışında tek düğüm bağımlılığı var; kesinti tekrarlarsa yoğun saatte sipariş kaybı oluşur; iki sprintlik dayanıklılık yatırımı gerekir\" cümlesine dönüşür. Alarmı değil, karar yüzeyini anlatmak gerekir Teknik liderler bazen çok fazla veri taşıyarak daha ikna edici olacağını düşünür. Oysa yönetim toplantısında amaç ham veri dökmek değil, doğru karar yüzeyini açmaktır. Bunun için risk notunu şu katmanlarda kurmak daha güçlü olur: Belirti: Şu anda ne görüyoruz? Etki: Bu durum neyi bozabilir? Olasılık: Yakın dönemde tekrar etme ihtimali nedir? Seçenek: Hangi yatırım veya taviz masada? Son tarih: Karar hangi pencere kapanmadan alınmalı? Bu beşli, teknik borcu dramatize etmeden görünür kılar. <Callout type=\"tip\" title=\"Her risk notu bir karar istemelidir\" Teknik risk sunumu yalnızca durum raporu olarak kalıyorsa, toplantı bilgilendirici görünür ama yön değiştirmez. Notun sonunda açık bir karar talebi olmalıdır. </Callout Yönetim için en işe yarayan ölçü birimleri Her şeyi para ile konuşmak da her şeyi teknik skorlarla konuşmak kadar eksik olabilir. Kurum tipine göre aşağıdaki ölçüler daha işe yarar: Hizmet kesintisi tekrarlama olasılığı Kritik teslimat takvimine etkisi Uyumluluk veya denetim açığı oluşturma riski Operasyonel yükün birkaç kişide toplanması Müşteri güveni veya iç paydaş güveni kaybı Örneğin sertifika yaşam döngüsü dağınıklığı, yalnızca güvenlik açığı değildir. Aynı zamanda gece müdahalesi ihtimalini artıran bir operasyon riski ve değişiklik hızını yavaşlatan bir teslim riski olabilir. Kötü tercümenin iki yaygın biçimi İlk hata, riski korku diliyle anlatmaktır. \"Her an her şey olabilir\" ifadesi teknik olarak bazen doğru hissettirse de karar üretmez. Çünkü önceliklendirme için göreli etki gerekir. İkinci hata ise tam tersidir: riski fazlasıyla sterilize etmek. Burada da lider, teknik ayrıntıyı o kadar yumuşatır ki yatırım ihtiyacının gerçek ağırlığı kaybolur. Sonuçta yönetim hafif bir bakım işi duyduğunu sanır, ekip ise kırılgan bir altyapı ile çalışmaya devam eder. Risk kaydı ile toplantı dili aynı olmalı Tek seferlik sunumlar yerine yaşayan risk kaydı kullanmak büyük fark yaratır. Çünkü her yeni incident, audit bulgusu veya kapasite sorunu sıfırdan tartışılmaz; var olan risk envanterinde yerini bulur. Ben şu alanların özellikle faydalı olduğunu görüyorum: Risk başlığı ve açık teknik bağlam Etkilenen servis veya iş yeteneği Mevcut azaltıcı kontrol Açık kalan boşluk İstenen karar veya yatırım Sahip ekip ve gözden geçirme tarihi Bu kayıt, teknik liderin her toplantıda aynı gerçeği farklı kelimelerle yeniden savunma yükünü azaltır. Ne zaman yükseltmek gerekir? Her teknik eksiklik yönetim seviyesine çıkmamalı. Yükseltme eşiği genelde şu durumda oluşur: Risk birden fazla ekip sınırına taşıyorsa Çözüm yerel backlog ile kapanmayacak kadar büyükse İş önceliği ile mühendislik gereksinimi arasında açık gerilim varsa Regülasyon, güvenlik veya itibar etkisi doğrudan görünüyorsa Bu eşik oluştuğunda teknik liderin görevi daha çok alarm üretmek değil, kurumu seçime zorlamadan seçimsiz bırakmamaktır. Sonuç Teknik liderler için yönetime teknik risk tercümesi, sunum becerisi değil kurumsal mühendislik disiplinidir. Risk doğru çevrildiğinde yönetim teknik ekibin ne söylediğini daha net anlar, mühendislik de neden yatırım istediğini savunulabilir biçimde ortaya koyar. Kurumun olgunluğu da burada görünür: problemi en erken gören ekip ile kararı veren masa aynı cümlede buluşabildiğinde.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "risk-yonetimi",
        "kurumsal-iletisim",
        "operasyon-kulturu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-bolgesel-entegrasyon-hucreleri",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-bolgesel-entegrasyon-hucreleri",
      "title": "ERP Altyapılarında Bölgesel Entegrasyon Hücreleri",
      "summary": "Veri egemenliği, gecikme ve hata alanını yönetmek için ERP entegrasyonlarında bölgesel hücre yaklaşımını anlatır.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda bolgesel entegrasyon hucreleri diagram.svg'; ERP sistemleri kurumsal omurganın en hassas noktalarından biridir; ama modern kurumlardaki iş akışları artık tek bölgede yaşamaz. Finans Avrupa'da, tedarik zinciri Orta Doğu'da, analitik platformu başka bir cloud bölgesinde olabilir. Bu durumda tüm entegrasyon trafiğini tek bir merkezi katmanda toplamak kısa vadede kolay görünür; uzun vadede ise hem veri egemenliği baskısı hem de operasyon gecikmesi üretir. Bölgesel entegrasyon hücreleri yaklaşımı, tam da bu sıkışıklığı çözmek için değerlidir. <figure <Image src={diagram} alt=\"ERP bölgesel entegrasyon hücreleri mimarisini gösteren teknik şema\" / <figcaption Merkezî ERP çekirdeği ile bölgesel iş akışları arasına kontrollü hücreler koymak, yalnızca gecikmeyi değil hata alanını da sınırlar.</figcaption </figure Entegrasyon hücresi neyi çözer? Amaç ERP'yi kopyalamak değildir. Hücre yaklaşımı, ERP çekirdeğinin etrafında yerel ihtiyaçlara göre çalışan ama çekirdekle sözleşmeli konuşan bir entegrasyon zarfı oluşturmaktır. Bu zarf içinde tipik olarak şu bileşenler yer alır: Bölgesel API adapter'ları Yerel mesajlaşma veya event buffer katmanı Veri maskeleme ve politika kontrolleri Bölgeye özel gözlemlenebilirlik ve audit akışı Böylece her bölge, kendi gecikme ve regülasyon ihtiyaçlarını yönetebilirken çekirdek ERP üzerinde kontrolsüz genişleme yaşanmaz. Neden merkezi entegrasyon katmanı yetmeyebilir? Çünkü tek bir katman zamanla her şeyi bilmek zorunda kalır: Bölgesel veri saklama kuralı Yerel iş ortakları için protokol farkları Gecikmeye duyarlı iş akışları Çeviri, format ve idempotency ayrıntıları Bu yoğunluk arttığında en küçük değişiklik bile bütün dünyayı etkileyen release riskine dönüşür. Bölgesel hücreler ise entegrasyon sorumluluğunu daha küçük blast radius ile dağıtır. Hücre yaklaşımı hangi prensiplere dayanmalı? Ben burada dört ilkeyi kritik görüyorum: 1. Çekirdek tek doğruluk kaynağı olarak kalmalı 2. Bölgesel hücreler veri sahipliği değil entegrasyon sahipliği taşımalı 3. Sözleşmeler versiyonlu ve ölçülebilir olmalı 4. Her hücre bağımsız arıza alanı gibi ele alınmalı Bu ilkeler olmadan hücre yaklaşımı kısa sürede dağınık kopya mimarisine dönüşebilir. <Callout type=\"tip\" title=\"Hücre demek mini ERP kurmak değildir\" Bölgesel katman; yerel orkestrasyon, önbellek veya uyarlama yapabilir. Fakat iş kuralını sessizce yeniden üretmeye başlarsa kurumsal mimari ikiye bölünür. </Callout Veri egemenliği açısından neden güçlüdür? Birçok kurum için en zor alan, her veriyi her bölgeye taşıyamamaktır. Bölgesel hücreler sayesinde şu ayrımlar daha net yapılır: Hangi veri alanı yerelde işlenebilir? Hangi kayıt özetlenip merkeze döner? Hangi olay sadece metadata olarak aktarılır? Hangi audit izi bölge içinde saklanır? Bu model, veri göçünü kaba bir kopyalama problemi olmaktan çıkarıp açık sözleşmeli mimari karara dönüştürür. Operasyon tarafında getirisi nedir? En görünür fayda hata alanının küçülmesidir. Örneğin Orta Doğu bölgesindeki tedarik partneri akışı bozulduğunda Avrupa finans entegrasyonunun aynı anda etkilenmesi gerekmez. Hücreler ayrı ölçeklenir, ayrı alarm üretir ve ayrı rollback planına sahip olur. Bu da ERP çevresindeki değişiklikleri daha güvenli hâle getirir. Ayrıca gözlemlenebilirlik daha anlamlı olur. Tek merkezde akan genel entegrasyon logları yerine, her hücrenin kendi SLO'su, retry metriği ve teslimat kuyruğu okunabilir hale gelir. Hangi riskler unutulmamalı? Hücre yaklaşımı her problemi çözmez. Özellikle şu riskler açıkça yönetilmelidir: Bölgesel sözleşme sürümlerinin drift üretmesi Ortak kimlik ve sır yönetiminin zayıflaması Fazla yerel özelleştirme nedeniyle yönetişimin bozulması Cross region olay korelasyonunun zorlaşması Bu yüzden hücreler serbest bölge değil, merkezi ilkelerle sınırlandırılmış operasyon alanları olmalıdır. Sonuç ERP altyapılarında bölgesel entegrasyon hücreleri, küresel kurumların tek merkezli entegrasyon yükünü daha yönetilebilir parçalara ayırır. Veri egemenliği, gecikme ve operasyon dayanıklılığı aynı çerçevede ele alındığında bu yaklaşım özellikle çok bölgeli yapılarda ciddi değer üretir. Asıl başarı, her bölgeye aynı teknolojiyi vermekte değil; çekirdek ERP'yi bozmadan yerel gereksinimleri kontrollü hücreler içinde karşılayabilmektedir.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "integration",
        "architecture",
        "cloud",
        "enterprise"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-release-ring-ile-entegrasyon-yayilimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-release-ring-ile-entegrasyon-yayilimi",
      "title": "ERP Altyapılarında Release Ring ile Entegrasyon Yayılımı",
      "summary": "ERP çekirdeğini tek seferde açmak yerine entegrasyon akışlarını kontrollü halkalarla büyüten kurumsal mimari yaklaşım.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; ERP modernizasyonu ya da çekirdek sürüm geçişi konuşulurken en sık yapılan hata, entegrasyon tarafını tek bir açma kapama kararı gibi ele almaktır. Oysa ERP çevresinde çalışan raporlama, depo, üretim, finans, kimlik, B2B ve veri gölü akışları aynı risk profilini taşımaz. Çekirdeği güncelledikten sonra tüm entegrasyonları aynı anda yeni davranışa geçirmek, değişikliği teknik olarak mümkün kılsa da operasyonel olarak kırılgan bir yol açar. Release ring yaklaşımı neden işe yarar? Release ring mantığı, yeni sürüm veya yeni entegrasyon sözleşmesini herkese aynı anda açmak yerine kontrollü halkalarla büyütmektir. Bulut platformlarında ve istemci yazılımında sık gördüğümüz bu yöntem, ERP entegrasyonlarında daha da değerlidir. Çünkü burada yalnızca uygulama uyumluluğu değil, iş akışının sürekliliği söz konusudur. Genel olarak şu faydaları sağlar: İş kritikliği düşük akışlarla erken doğrulama yapılır Gözlem sinyalleri daha temiz okunur Geri alma kararı tüm kurumu etkilemeden verilebilir Partner veya iç ekip bağımlılıkları daha kontrollü çözülür ERP dünyasında halka nasıl tanımlanır? Halkaları coğrafya, iş birimi ya da teknik entegrasyon türüne göre tanımlayabilirsiniz. Ben çoğu kurumsal yapıda aşağıdaki ayrımın daha savunulabilir olduğunu görüyorum: 1. İç teknik ring : Raporlama, düşük riskli batch, gözlem ve test tüketicileri 2. Operasyonel ring : Depo, planlama, saha operasyonları gibi zaman hassas ama geri alınabilir akışlar 3. Finansal ring : Muhasebe, faturalama, tahsilat ve denetim etkili entegrasyonlar 4. Dış ekosistem ring'i : Bayi, tedarikçi, EDI ve partner bağlantıları Bu sıralama, hatayı en az maliyetli yüzeyde görüp büyümeden durdurmaya yardım eder. Halkalar arasında ne taşınmalı? Yalnızca kod veya entegrasyon paketini taşımanız yetmez. Her ring geçişinde şu unsurların da taşınması gerekir: Gözlem dashboard'ları ve hata eşiği Veri sözleşmesi versiyonu Geri alma koşulu Destek ve olay sahipliği Geçiş onayı için başarı kriteri Bu çerçeve kurulmadan yapılan halka geçişi, aslında etaplı yayın değil sadece yavaş toplu yayındır. <Callout type=\"tip\" title=\"Ring tasarımı teknikten çok sahiplik modelidir\" Bir entegrasyonun hangi halkada açılacağı çoğu zaman kod karmaşıklığından çok iş etkisi, veri hassasiyeti ve geri alma kolaylığıyla belirlenir. </Callout En sık görülen tasarım hatası En yaygın hata, ring'leri yalnızca takvim kutularına çevirmektir. Pazartesi birinci halka, salı ikinci halka, çarşamba herkes şeklindeki planlarda halka mantığı kağıt üzerinde vardır ama karar kapıları yoktur. Oysa her geçişte şu sorunun açık cevabı olmalıdır: \"Bir üst halkaya geçmeyi hangi sinyal haklı çıkarıyor?\" Bu sinyaller örneğin şunlar olabilir: Mesaj başarısızlık oranı belirli eşik altında kalmalı Veri uzlaşmazlığı sayısı sıfıra yakın olmalı Operasyon ekibinde manuel düzeltme ihtiyacı oluşmamalı Geri alma provası ilgili halkada kanıtlanmış olmalı Gözlemlenebilirlik neden merkezi rol oynar? ERP entegrasyonlarında hata çoğu zaman sert kırılma şeklinde gelmez. Kısmi veri kaybı, geciken mutabakat, yinelenen kayıt veya sıra birikmesi olarak görünür. Bu nedenle ring geçişleri için şu sinyaller özellikle kritiktir: Uçtan uca gecikme Kuyruk derinliği Başarısız mesaj oranı Tekrar işleme sayısı İşlem hacmine göre veri uyumsuzluğu Bu ölçüler olmadan halka yaklaşımı güven verici görünür ama karar yine sezgiyle alınır. Kurumsal iletişim modeli nasıl olmalı? Ring yaklaşımı yalnızca altyapı ekibinin iç tasarımı olarak kalmamalıdır. İş birimleri ve entegrasyon sahipleri hangi halkada olduklarını, bir üst halkaya geçiş için ne beklendiğini ve geri alma halinde ne olacağını bilmelidir. Bu görünürlük özellikle ERP tarafında güven sağlar; çünkü paydaşlar sürpriz yerine kontrollü ilerleme görür. Sonuç ERP altyapılarında release ring ile entegrasyon yayılımı, riskli çekirdek değişiklikleri tek seferde kuruma yaymak yerine kontrollü halkalarla olgunlaştırmanın etkili yoludur. İyi tasarlandığında daha yavaş değil, daha öngörülebilir bir dönüşüm sağlar. ERP başarısı da çoğu zaman burada ölçülür: entegrasyonu açabilmekte değil, açılış sırasını ve durdurma eşiğini disiplinli biçimde yönetebilmekte.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "architecture",
        "integration",
        "release-management",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-test-verisi-maskeleme-fabrikasi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-test-verisi-maskeleme-fabrikasi",
      "title": "ERP Altyapılarında Test Verisi Maskeleme Fabrikası",
      "summary": "ERP test ortamlarını beslerken gerçekçi veri davranışını koruyan, güvenliği bozmayan ve tekrar üretilebilir maskeleme hattı tasarımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda test verisi maskeleme fabrikasi diagram.svg'; ERP modernizasyonunda en ihmal edilen ama en pahalı problemlerden biri test verisidir. Üretime benzeyen veri olmadan entegrasyon, raporlama ve süreç senaryoları gerçekçi biçimde doğrulanamaz. Gerçek üretim verisini kopyalamak ise güvenlik, uyum ve erişim yönetimi açısından kabul edilemez risk üretir. Bu ikilemi çözmenin yolu tek seferlik veri gizleme betikleri değil, tekrar üretilebilir bir test verisi maskeleme fabrikası kurmaktır. <figure <Image src={diagram} alt=\"ERP test verisi maskeleme hattını gösteren teknik şema\" / <figcaption Doğru tasarım, test ortamını veri kaçak riski olmadan canlı davranışa yaklaştırır.</figcaption </figure Neden fabrika yaklaşımı gerekir? Birçok kurumda test verisi üretimi şu şekilde ilerler: üretimden kopya alınır, birkaç kritik kolon manuel maskelenir, dosya aktarılır ve ekipler \"şimdilik yeter\" diyerek devam eder. Bu model küçük bir prova için iş görebilir; fakat ERP dünyasında sürdürülebilir değildir. Çünkü veri sadece müşteri adı ya da telefon numarası değildir. Sipariş ilişkileri, finansal akışlar, tedarik zinciri referansları, insan kaynakları kayıtları ve çapraz modül anahtarları birlikte hareket eder. Eğer maskeleme yalnızca birkaç alanı değiştirirse iki sorun doğar: Hassas veri beklenmedik ilişkiler üzerinden geri çözülebilir. İş kuralları bozulduğu için test senaryoları anlamını kaybeder. Bu nedenle \"maskelenmiş dump\" değil, veri davranışını koruyan üretim hattı gerekir. Maskeleme fabrikasının dört istasyonu Pratikte sağlam bir model şu dört istasyondan oluşur: 1. Kaynak seçimi : Hangi tablo, alan ve ilişki kümeleri gerçekten gerekli? 2. Sınıflandırma : Kişisel veri, finansal veri, operasyonel referans ve teknik metadata ayrımı 3. Dönüştürme : Tokenizasyon, tutarlı sahte veri üretimi, aralık koruma, tarih kaydırma 4. Doğrulama : İş kuralları, referans bütünlüğü, raporlama tutarlılığı ve erişim sınırı Bu modelin değeri, her yeni ortam ihtiyacında sıfırdan karar vermeyi önlemesidir. <Callout type=\"tip\" title=\"Her alanı aynı yöntemle maskelemeyin\" ERP verisi için tek tip anonimleştirme yaklaşımı genellikle ya fazla sert olur ya da ilişki davranışını bozar. Alan türüne göre dönüşüm seçin. </Callout Tutarlı sahte veri neden kritik? ERP sistemlerinde aynı müşteri, çalışan veya tedarikçi onlarca tabloda farklı rollerde görünür. Bir alanda \"A Şirketi\"ni \"X Ltd.\" yapıp başka tabloda aynı kaydı başka değere çevirirseniz test ortamı teknik olarak dolu görünür ama iş akışı kırılır. Bu nedenle tutarlı sahte veri üretimi gerekir. Tutarlılık için şu ilkeler işe yarar: Aynı kaynak kimlik her yerde aynı takma değere dönüşmeli Segment, ülke veya para birimi gibi dağılımlar korunmalı Tarih alanları tek tek değil süreç akışı bozulmayacak biçimde kaydırılmalı Finansal büyüklükler mutlak değil bağıl ilişkiyi koruyacak şekilde dönüştürülmeli Böylece entegrasyon ve raporlama ekipleri gerçek hayata yakın davranış üzerinde çalışabilir. Güvenlik sınırı yalnızca veri alanında kurulmaz Maskeleme fabrikasının güvenli olması için boru hattının kendisi de sınırlandırılmalıdır. Kurumlarda sık görülen hata, veriyi iyi maskeleyip geçici çalışma alanlarını ve log'ları kontrolsüz bırakmaktır. Mimari olarak şu sınırlamalar önemlidir: Ham üretim kopyasına erişim yalnızca otomasyon hesabı ile sağlanmalı Geçici çalışma alanları kısa ömürlü ve şifreli olmalı Dönüştürme günlükleri hassas alan değeri içermemeli Çıktı veri seti yalnızca hedef test ağına aktarılmalı Her çalıştırma iz kaydı bırakmalı Bu sayede maskeleme hattısı yeni bir veri sızıntı yüzeyi olmaktan çıkar. Uyum ve mühendislik neden aynı masada oturmalı? ERP projelerinde güvenlik ve uyum ekipleri genellikle \"veri çıkmasın\" perspektifiyle, mühendislik ekipleri ise \"senaryo çalışsın\" perspektifiyle yaklaşır. İki taraf ayrı hareket ettiğinde ya test verisi anlamsızlaşır ya da risk iştahı yükselir. En iyi sonuç, veri sınıflandırma sözlüğünün ortak hazırlanmasıyla gelir. Bu sözlükte şunlar net olmalıdır: Tam maskeleme gereken alanlar Dağılımı korunacak ama kimliği değişecek alanlar Sadece ortam dışına çıkmaması gereken operasyonel referanslar Tamamen sentetik üretilecek veri kümeleri Bu kararlar bir kez netleştiğinde veri hazırlama süresi ciddi biçimde kısalır. Test verisi başarısı nasıl ölçülür? Başarı yalnızca \"kişisel veri görünmüyor\" diye ölçülmemeli. Şu sorular daha anlamlıdır: Kritik ERP iş akışları maske sonrası çalışıyor mu? Entegrasyon testleri referans bütünlüğü hatası üretiyor mu? Test verisi yenileme süresi ekipleri bekletiyor mu? Aynı veri seti gerektiğinde tekrar üretilebiliyor mu? Denetim için hangi veri nereden üretildiği izlenebiliyor mu? Bu soruların olumlu cevapları, mimarinin yalnızca güvenli değil aynı zamanda faydalı olduğunu gösterir. Sonuç ERP altyapılarında test verisi maskeleme fabrikası kurmak, güvenlik ile mühendislik arasında zorunlu bir uzlaşma alanıdır. Tek seferlik veri gizleme adımları, büyüyen kurumsal yapılarda hızla kırılır. Buna karşılık otomasyonlu, izlenebilir ve iş kurallarını koruyan maskeleme hattı; hem proje hızını artırır hem uyum riskini düşürür. Sağlam test ortamı, güvenli şekilde üretilmiş veriden başlar.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "data-security",
        "architecture",
        "automation",
        "governance"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-dnssec-dogrulayan-ayrik-resolver-katmani",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-dnssec-dogrulayan-ayrik-resolver-katmani",
      "title": "Kurumsal Ağlarda DNSSEC Doğrulayan Ayrık Resolver Katmanı",
      "summary": "İsim çözümleme güvenini artırmak için DNSSEC doğrulamasını ayrı resolver katmanında konumlandıran kurumsal mimari yaklaşım.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ağlarda DNS çoğu zaman ulaşılabilirlik konusu olarak ele alınır; güven konusu olarak değil. Oysa modern kurumlarda resolver zinciri sadece isim çözmez, hangi zone'un güvenilir sayılacağını da fiilen belirler. DNSSEC doğrulayan ayrık resolver katmanı, bu yüzden performans optimizasyonu değil güven sınırı tasarımıdır. Amaç tüm istemcilere doğrudan internet doğrulaması açmak değil; güvenilir doğrulamayı kontrollü, gözlemlenebilir ve işletilebilir bir resolver katmanında toplamak. Neden mevcut resolver zinciri yetmez? Birçok kurumda istemciler, domain controller, cache forwarder, bulut resolver ve güvenlik proxy'leri arasında dolanan bir zincir kullanır. Bu model çalışabilir; fakat hangi noktada hangi doğrulamanın yapıldığı çoğu zaman belirsizdir. DNSSEC bazı yerde kapalı, bazı yerde kırık, bazı yerde de transparan geçişli olabilir. Bunun sonucu şudur: İmzalı zone ile imzasız zone davranışı ekip tarafından okunamaz Bozuk imza durumunda hangi katmanın sorguyu düşürdüğü anlaşılamaz Güvenlik ekibi sahte cevap riskini teorik görür, operasyon ekibi ise performans bahanesiyle erteleyebilir Hibrit topolojide on prem ve cloud istemcileri farklı güven seviyesinde çözümleme yapar Dolayısıyla mesele yalnızca DNSSEC desteklemek değil, güven davranışını kurumsal ölçekte standardize etmektir. Ayrık resolver katmanı ne sağlar? Bu modelde DNSSEC doğrulaması her istemciye dağılmaz. Bunun yerine özel bir resolver katmanı yalnızca dış veya güven sınırından geçen çözümleme akışında doğrulama yapar. İç kurumsal zone'lar ise ayrı policy ile işlenir. Böylece imza zinciri anlamlı olduğu yerde sıkı, iç özel ad alanlarında ise kontrollü davranabilirsiniz. Ayrık katman şu faydaları üretir: Doğrulama davranışı merkezi ve izlenebilir olur Bozuk delegasyonlar istemciyi değil resolver katmanını etkiler Güvenlik olayı sırasında hangi sorguların neden reddedildiği okunabilir Kurumsal iç zone ile internet zone'u aynı kontrol mantığına zorlanmaz Bu sayede DNS güveni ağ kenarında dağılmış varsayımlardan çıkıp açık bir mimari karara dönüşür. Tasarımda hangi ayrım kritik? Burada en önemli ayrım, authoritative rol ile validating recursive resolver rolünü karıştırmamaktır. Kurumsal ekipler bazen mevcut forwarder zincirine birkaç ayar ekleyerek DNSSEC probleminden çıktığını düşünür. Fakat güvenli model için şu sınırlar net olmalıdır: 1. İç kurumsal zone yönetimi 2. İnternet recursive çözümleme 3. DNSSEC validation policy 4. Telemetry ve hata sınıflandırması Bu ayrım yapılmadığında resolver katmanı sorun çıktığında hem güvenlik ekibinin hem uygulama ekibinin suçladığı gri alana dönüşür. <Callout type=\"tip\" title=\"DNSSEC projesi değil, güven davranışı projesi\" DNSSEC ayarını açmak yeterli değildir. Hangi zone'lar için doğrulama yapılacağı, hata durumunda nasıl gözlemleneceği ve hangi uygulamaların etkilenebileceği baştan tasarlanmalıdır. </Callout Hangi trafik için özellikle değerlidir? Ben bu yaklaşımı özellikle şu alanlarda güçlü buluyorum: İnternetteki SaaS bağımlılıklarına yoğun çıkan istemci segmentleri Güvenlik ürünlerinin tehdit istihbaratı veya güncelleme alanları API entegrasyonları ile dış servislere bağımlı ERP veya middleware katmanları Yönetim ağından yapılan paket çekme, repository erişimi ve imza doğrulama akışları Bu akışlarda sahte cevap, yanlış cache ya da bozuk delegasyon etkisi sessiz olabilir. DNSSEC doğrulayan ayrı katman, bu sessizliği azaltır ve olay analizini kolaylaştırır. Operasyonel maliyet nasıl kontrol edilir? DNSSEC doğrulaması bazen performans veya karmaşıklık gerekçesiyle ertelenir. Gerçekte maliyetin büyük kısmı CPU değil işletim modelidir. Şunlar baştan düşünülürse maliyet savunulabilir olur: Resolver başına açık telemetry: SERVFAIL, bogus, validation failure oranları Cache politikalarının doğrulama davranışıyla birlikte gözlenmesi İç zone istisnalarının yazılı ve süreli tutulması Bozuk delegasyon senaryoları için test sorguları ve tatbikat Yani resolver katmanını \"kurduk oldu\" mantığıyla değil, güvenlik kontrolü olarak yönetmek gerekir. Aksi halde ilk bozuk DNSSEC olayı sonrası tüm yapı kapatılır ve güven kaybedilir. Sık yapılan hata: Her şeyi doğrulamaya zorlamak Kurumsal ağlarda iç özel zone'ların tamamını DNSSEC mantığıyla yönetmek çoğu zaman gerçekçi değildir. Bazı zone'lar Active Directory, bazıları geçici lab ortamı, bazıları da split horizon kurgularından gelir. Ayrık katman yaklaşımı tam da bu yüzden değerlidir: iç zone istisnalarını güvenli internet çözümlemesiyle karıştırmaz. Daha doğru yaklaşım şudur: İç zone'ları açık policy ile ayır İnternet çözümlemesinde DNSSEC'i tutarlı uygula İstisna alanlarını telemetry'de ayrı işaretle Fail open ya da fail closed kararını kullanım türüne göre açık yaz Bu netlik sağlanırsa DNS operasyonu da güvenlik denetimi de daha savunulabilir hâle gelir. Sonuç Kurumsal ağlarda DNSSEC doğrulayan ayrık resolver katmanı, isim çözümleme güvenini istemciye dağıtmadan yükseltmenin pragmatik yoludur. Değeri yalnızca imza zincirini doğrulamasında değil; güven davranışını merkezi, gözlemlenebilir ve açık istisnalı bir tasarıma dönüştürmesinde yatar. Güçlü resolver mimarisi de burada başlar: yalnızca hızlı cevap vermekte değil, cevabın güven sınırını kurumsal ölçekte savunabilmekte.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "security",
        "dns",
        "architecture",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-politika-drift-icin-dijital-ikiz-katmani",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-politika-drift-icin-dijital-ikiz-katmani",
      "title": "Kurumsal Ağlarda Politika Drift İçin Dijital İkiz Katmanı",
      "summary": "Firewall, yönlendirme ve segmentasyon kurallarındaki sapmayı üretime dokunmadan görebilmek için dijital ikiz yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ağ ekiplerinde en pahalı sorunlardan biri yanlış kural yazmak değil, hangi kuralın gerçekten çalıştığını geç fark etmektir. Firewall kural setleri, yönlendirme politikaları, NAT istisnaları ve segment geçişleri zamanla birbirinin üstüne biner. Doküman güncel görünür, değişiklik kaydı düzgün tutulur, hatta otomasyon da vardır; fakat üretim ağının davranışı yine de niyetten sapar. Bu sapmaya politika drift diyoruz. Neden klasik CMDB yaklaşımı yetmez? CMDB ya da kural envanteri, ağın ne olması gerektiğini kaydeder. Drift problemi ise ağın gerçekte nasıl davrandığıyla ilgilidir. Özellikle çok üreticili kurumsal topolojilerde şu boşluklar oluşur: Aynı niyet farklı cihazlarda farklı sözdizimiyle uygulanır Geçici incident kuralı kalıcı hale gelir Rota tercihleri beklenen güvenlik yolunu baypas eder Yeni segment açılır ama eski istisnalar temizlenmez Bu nedenle yalnızca konfigürasyon listesine bakmak, davranışsal sapmayı yakalamaya yetmez. Dijital ikiz katmanı ne yapar? Dijital ikiz katmanı, üretim ağının cihaz durumu, topoloji bilgisi ve politika niyetini modelleyip sorgulanabilir hale getirir. Amaç, üretimi emüle eden kusursuz bir laboratuvar kurmak değil; değişiklik ve mevcut durum arasında anlamlı farkı görünür kılan bir kontrol yüzeyi üretmektir. Bu katman tipik olarak üç kaynaktan beslenir: 1. Cihazlardan çekilen güncel konfigürasyon ve durum bilgisi 2. Kaynak koddaki niyet tanımı veya politika deposu 3. Akış testi, reachability ve yol doğrulama çıktıları Bu veriler aynı modelde toplandığında, \"hangi kural var?\" sorusundan \"hangi trafik hangi koşulda nereye gidebilir?\" sorusuna geçersiniz. Nerede değer üretir? Dijital ikiz yaklaşımı özellikle şu alanlarda güçlüdür: Segmentasyon politikasının fiili etkisini görmek Güvenlik zonları arasında örtük geçişleri bulmak Firewall değişikliği öncesi etki analizi yapmak Rota değişikliğinin güvenlik zincirini bozup bozmadığını doğrulamak Denetim sırasında niyet ile gerçek davranışı aynı tabloda göstermek Bu sayede ağ ekibi yalnızca konfigürasyon yöneten ekip olmaktan çıkıp davranış yöneten ekibe dönüşür. <Callout type=\"tip\" title=\"Drift çoğu zaman kötü niyet değil, birikmiş istisnadır\" Kurumsal ağlarda tehlikeli sapmaların büyük kısmı acele müdahale, geçici çözüm ve temizlenmeyen geçiş kuralı kombinasyonundan çıkar. </Callout Hangi modeli kurmak gerekir? Ben pratikte dört katmanlı modelin işe yaradığını görüyorum: Niyet katmanı: Segmentler arası izin matrisi, zorunlu inspeksiyon noktaları, zorunlu loglama kuralları Topoloji katmanı: Cihazlar, VRF'ler, VLAN'lar, transit ağlar, servis zincirleri Gerçekleşen politika katmanı: ACL, firewall policy, route map, NAT ve service insertion kuralları Doğrulama katmanı: Akış testi, yol çözümleme ve ihlal raporları Bu ayrım yapılmadığında dijital ikiz aracı yalnızca konfigürasyon arşivine dönüşür. Oysa kıymet, niyet ile gerçekleşme arasındaki farkı gösterebilmesindedir. Hangi sorular sorulmalı? Sağlam bir kontrol düzlemi şu sorulara cevap verebilmelidir: Bu segment gerçekten yalnızca izinli servislerle konuşabiliyor mu? İnternete çıkması yasaklanan ağlar yine de dolaylı egress alıyor mu? Yeni rota, zorunlu güvenlik kontrolünü baypas etti mi? Aynı servis için birbirini çürüten iki politika oluştu mu? Incident sırasında açılan geçici kural hâlâ aktif mi? Bu soruların cevabı görünür değilse, segmentasyon iddiası büyük ölçüde varsayıma dayanır. Operasyon modeli nasıl kurulmalı? Dijital ikiz katmanı tek başına ağ mimarisi projesi değildir; değişiklik sürecine bağlanmalıdır. En sağlıklı model genelde şöyledir: Politika değişikliği merge öncesi ikizde simüle edilir Gece canlıya alınan kritik değişiklik ertesi gün drift taramasından geçer Haftalık raporda açık ihlaller ve geçici istisnalar gözden geçirilir Denetim ekipleri cihaz ekran görüntüsü yerine model çıktısı kullanır Böylece dijital ikiz, operasyon dışında çalışan yan araç değil, değişiklik yönetiminin parçası olur. Sonuç Kurumsal ağlarda politika drift için dijital ikiz katmanı, görünürde düzgün çalışan ama davranışsal olarak sapmış ağları erken fark etmek için güçlü bir yaklaşımdır. Değeri cihaz sayısını merkezileştirmesinde değil, niyet ile gerçek akış arasındaki farkı sürekli görünür kılmasında yatar. Ağ olgunluğu da tam burada başlar: yalnızca kural yazabilmekte değil, yazılan kuralın sahada nasıl davrandığını savunulabilir biçimde gösterebilmekte.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "security",
        "architecture",
        "automation",
        "governance"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-rpki-ile-bgp-guven-zinciri",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-rpki-ile-bgp-guven-zinciri",
      "title": "Kurumsal Ağlarda RPKI ile BGP Güven Zinciri",
      "summary": "BGP route leak ve sahte origin riskini azaltmak için kurumsal ağlarda RPKI tabanlı güven zinciri tasarımını ele alır.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal aglarda rpki ile bgp guven zinciri diagram.svg'; Kurumsal ağ ekipleri BGP konuştuğunda çoğu zaman kapasite, failover ve segmentasyon üzerinde durur. Oysa internet kenarı, partner bağlantıları veya çoklu transit senaryolarında başka bir konu daha belirleyicidir: yönlendirme bilgisinin güvenilirliği. Route leak, hatalı origin ilanı veya yanlış prefix kabulü yalnızca operatör problemi değildir; kurumların dış dünya ile kurduğu rota sınırını doğrudan etkiler. Bu yüzden RPKI, sadece servis sağlayıcıların değil, kurumsal mimarilerin de gündemine girmelidir. <figure <Image src={diagram} alt=\"RPKI doğrulama katmanını ve BGP güven zincirini gösteren teknik şema\" / <figcaption BGP güveni sözlü mutabakat değil, doğrulanabilir imza ve politika ile güçlenir.</figcaption </figure RPKI neden kurumsal tarafta önem kazandı? Çünkü kurumlar artık yalnızca tek uplink kullanan kapalı yapılar değil. SD WAN çıkışları, bulut direct connect bağlantıları, DDoS temizleme sağlayıcıları, edge servisleri ve partner omurgaları aynı yönlendirme alanına temas ediyor. Bu topolojide bir prefix'in yanlış origin ile kabul edilmesi şu sonuçları doğurabilir: Trafiğin istemeden üçüncü tarafa gitmesi Dış erişimde kısmi kesinti DDoS yönlendirme politikasının bozulması Kök neden analizinde saatler süren belirsizlik RPKI bu problemi tamamen ortadan kaldırmaz; fakat \"hangi ASN bu prefix'i ilan etmeye yetkili\" sorusunu daha güçlü biçimde cevaplar. Güven zinciri nasıl işler? RPKI modelinde prefix sahibi, belirli ASN'lerin o prefix'i origin olarak duyurabileceğini ROA kaydıyla ilan eder. Route validator bu bilgiyi çeker ve yönlendiricilere üç temel sonuç üretir: Valid : Prefix ve ASN eşleşmesi doğru Invalid : Prefix ilanı ROA ile çelişiyor NotFound : Bu prefix için doğrulanabilir kayıt yok Kurumsal mimaride amaç, özellikle internet kenarında ve kritik partner eBGP oturumlarında bu sonucu politika motoruna bağlamaktır. Her invalid rota otomatik düşürülmeli mi? Hayır, özellikle geçiş döneminde dikkat gerekir. Kurumun kendi prefix'leri, bulut sağlayıcı anonsları ve DDoS scrubbing akışları birlikte düşünülmelidir. Ben üç aşamalı modeli daha sağlıklı buluyorum: 1. Önce sadece görünürlük: invalid prefix sayısını izle 2. Sonra düşük riskli kenarlarda tercih azalt 3. En sonunda kritik internet kenarında reddet Bu geçiş olmadan yapılan sert politika değişikliği, meşru ama eksik ROA tanımı olan yönleri gereksiz yere kesebilir. <Callout type=\"tip\" title=\"RPKI tek başına yeterli değildir\" RPKI origin doğrulaması yapar; yolun tamamını doğrulamaz. Prefix filtreleri, max prefix sınırları ve communities politikası yine gerekir. </Callout Kurumsal topolojide validator nereye konur? Validator'ı sadece tek bir ağ cihazına yakın düşünmek eksik kalır. Daha iyi model şudur: Çift örnekli validator servisi Ayrı yönetim segmentinde çalışma Router'lara RTR veya eşdeğer protokolle veri sağlama Metrik ve alarm entegrasyonu ile görünürlük üretme Böylece RPKI, tek seferlik güvenlik projesi değil yaşayan bir yönlendirme kontrol katmanına dönüşür. Özellikle farklı veri merkezleri veya hibrit edge yapıları varsa validator erişilebilirliği de tasarımın parçası olmalıdır. Hangi kurumlar daha hızlı değer görür? Şu ortamlarda RPKI yatırımının geri dönüşü daha hızlı olur: Kendi public ASN ve prefix alanı olan kurumlar Birden fazla transit veya upstream kullanan yapılar DDoS temizleme servisleriyle trafik yönlendiren ekipler Partner, MPLS ve internet kenarını birlikte yöneten ağ organizasyonları Bu yapılarda route leak kaynaklı belirsizlik operasyonel maliyeti ciddi biçimde artırır. RPKI en azından \"yanlış origin\" sınıfındaki sorunları daraltır. Operasyon modeli nasıl olmalı? Ben bu konuyu ağ, güvenlik ve platform operasyonunun ortak alanı olarak görüyorum. Sağlam bir modelde şunlar net olmalı: ROA kayıtlarını kim oluşturur ve kim onaylar? Yeni prefix tahsisinde güven zinciri checklist'e dahil mi? Invalid rota görüldüğünde olay kime düşer? Partner bağlantılarında istisna süreci nasıl yürür? Bu sorular cevaplanmadan RPKI yalnızca \"aktif\" görünen ama kimsenin sahiplenmediği bir katman olarak kalır. Sonuç Kurumsal ağlarda RPKI ile BGP güven zinciri kurmak, yönlendirmeyi tamamen güvenli hâle getirmez; fakat kritik bir doğrulama katmanı ekler. Route leak, yanlış origin ve hatalı prefix kabulü gibi sorunlar büyümeden görünür olur. Çoklu edge, hibrit bulut ve partner bağlantıları bulunan yapılarda bu görünürlük doğrudan operasyon kalitesi üretir. Modern ağ mimarisinde güven yalnızca ACL ve firewall ile değil, rotanın kendisini doğrulama disipliniyle de kurulur.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "security",
        "bgp",
        "architecture",
        "enterprise"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-break-glass-erisim-kasasi-mimarisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-break-glass-erisim-kasasi-mimarisi",
      "title": "Kurumsal Bulutta Break-Glass Erişim Kasası Mimarisi",
      "summary": "Ayrıcalıklı acil erişimi sürekli açık yetkilerle değil, denetlenebilir ve kısa ömürlü bir kontrol düzlemiyle yönetmenin mimari yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal bulutta break glass erisim kasasi mimarisi diagram.svg'; Kurumsal bulut ortamlarında en hassas denge, hız ile ayrıcalıklı erişim güvenliği arasında kurulur. Incident anında yönetim hesabına hızlı ulaşmak gerekir; ama aynı hesabın sürekli açık ve geniş yetkili tutulması, güvenlik modelini kalıcı biçimde zayıflatır. Break glass erişim kasası mimarisi, bu gerilimi \"ya hız ya güvenlik\" ikileminden çıkarır. Amaç, acil erişimi yasaklamak değil; denetlenebilir, kısa ömürlü ve açık sahiplikli bir hat üzerinden vermektir. <figure <Image src={diagram} alt=\"Kurumsal bulutta break glass erişim kasası mimarisini gösteren teknik şema\" / <figcaption Acil erişim ancak ayrı bir kontrol düzleminden, güçlü kayıt ve zaman sınırıyla verildiğinde kurumsal riski azaltır.</figcaption </figure Neden kalıcı admin hesabı kötü bir uzlaşmadır? Birçok kurumda acil durum gerekçesiyle birkaç hesap sürekli yüksek yetkili bırakılır. Böylece ekipler kriz anında uğraşmaz. Fakat bu rahatlığın maliyeti büyüktür: Kim hangi durumda bu hesabı kullanabilir sorusu bulanıklaşır Hesaplar zamanla normal operasyon işlerinde de kullanılmaya başlar MFA, onay ve kayıt disiplinleri gevşer Denetim sırasında gerçek sahiplik zinciri izlenemez Sonuçta break glass hesabı, istisna olmaktan çıkar ve gölge yönetim düzlemine dönüşür. Erişim kasası neyi çözer? Erişim kasası dediğim yapı, ayrıcalıklı kimlik bilgisini ya da yetki üretim mekanizmasını üretim kullanımından ayırır. Operasyon ekibi normalde daha dar rollerle çalışır. Yalnızca tanımlı koşullarda, sınırlı süreyle ve güçlü iz kaydıyla ek yetki alır. Bu mimarinin temel bileşenleri genellikle şunlardır: Ayrı yönetim hesabı veya güvenlik tenant'ı İki aşamalı onay akışı Kısa ömürlü oturum veya geçici rol üretimi Oturum kaydı ve komut izi Zaman aşımı sonrası otomatik yetki geri alma Bu yaklaşım, yetkiyi saklamak kadar etkinleştirme sürecini de güvence altına alır. <Callout type=\"tip\" title=\"Parola saklamak yeterli değildir\" Asıl güvenlik, kimlik bilgisinin kendisinden çok hangi koşulda, ne kadar süreyle ve hangi iz kaydıyla kullanılabildiğinde oluşur. </Callout Mimari kararlar hangi sırayla alınmalı? Pratikte şu sorular doğru sıra verir: 1. Break glass gerçekten hangi sistemler için gerekli? 2. Kalıcı root benzeri erişim yerine geçici rol yeterli mi? 3. Onayı kim verecek ve kim gözlemleyecek? 4. Oturum sırasında hangi kayıtlar zorunlu? 5. Erişim sonrası hangi gözden geçirme ritmi çalışacak? Bu sıralama önemlidir. Çünkü birçok kurum teknoloji seçimine erken gidip işletim modelini sonradan düşünür. O noktada araç vardır ama yönetişim eksik kalır. Çok hesaplı bulut yapılarında sınır nasıl kurulur? Kurumsal yapılarda break glass erişim tek bir hesabı hedeflemez. Üretim, güvenlik, ağ, gözlemlenebilirlik ve yedekleme alanları farklı hesap veya aboneliklerde olabilir. Bu nedenle acil erişim düzlemi de merkezi düşünülmelidir. Benzer ortamlarda işe yarayan desen şöyledir: Yönetim kasası üretim hesaplarından ayrı tutulur Her etki alanı için önceden tanımlı kurtarma rolleri bulunur Yetki verme süresi ve kapsamı role göre farklılaşır Kurtarma rolü normal CI/CD kimliklerinden tamamen ayrılır Böylece incident sırasında \"hangi hesabın parolası nerede\" kaosu yerine kontrollü rol aktivasyonu yapılır. Başarısız break glass tasarımlarının ortak hataları Şu hatalar sık görülür: Aynı hesap hem günlük operasyon hem acil erişim için kullanılır Erişim alındıktan sonra ne yapıldığı izlenmez Acil rol süresi dolsa bile açılan yan yetkiler kalır Yıllarca denenmemiş kurtarma prosedürü kâğıt üzerinde yaşar Bu tür tasarımlar güven veriyor gibi görünür ama gerçek incident anında ya çalışmaz ya da gereğinden fazla risk üretir. Tatbikat şart mı? Evet, çünkü break glass akışı teorik değil operasyonel bir yetenektir. Tatbikatsız bırakıldığında iki problem oluşur: ya süreç pratikte çok yavaş kalır ya da insanlar panik anında resmi akışı atlayıp eski kısa yolları kullanır. Bu nedenle belirli aralıklarla şu senaryolar denenmelidir: Kimlik sağlayıcı arızasında kurtarma erişimi Ağ ayrışmasında konsol düzeyi müdahale Yanlış policy dağıtımında geri alma yetkisi Güvenlik olayı sonrası yüksek riskli erişim gözden geçirmesi Tatbikat, yalnızca teknik çalışabilirliği değil kurumun disiplin refleksini de test eder. Sonuç Kurumsal bulutta break glass erişim kasası mimarisi, ayrıcalıklı erişimi hız kaybı olmadan daha güvenli hâle getirir. Kalıcı geniş yetkiler yerine geçici, kayıtlı ve açık sahiplikli erişim akışı kurulduğunda incident müdahalesi de denetim kalitesi de iyileşir. Güvenli kurumlar, acil erişimi yasaklayan değil; onu istisna olarak tasarlayıp gerçekten istisna gibi işleten kurumlardır.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "cloud",
        "security",
        "iam",
        "architecture",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-bagimlilik-grafi-ile-servis-etki-analizi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-bagimlilik-grafi-ile-servis-etki-analizi",
      "title": "Kurumsal Platformlarda Bağımlılık Grafı ile Servis Etki Analizi",
      "summary": "Mimari bağımlılıkları statik şema olmaktan çıkarıp değişiklik öncesi okunabilir etki analizine dönüştüren yaklaşım.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal platform ekipleri çoğu zaman servislere sahip olduklarını düşünür, ama o servislerin birbirini hangi yoğunlukta etkilediğini ancak bir arıza anında fark eder. Diyagramlar vardır, CMDB kayıtları vardır, katalog girişleri vardır; fakat değişiklikten hemen önce sorulan en kritik soru hâlâ karanlıkta kalır: \"Bunu değiştirirsek gerçekte kim etkilenir?\" Bağımlılık grafı ile servis etki analizi, tam bu soruyu operasyonel bir karar aracına dönüştürür. Neden servis kataloğu tek başına yetmiyor? Servis kataloğu sahiplik ve temel metadata için değerlidir; fakat bağımlılık yoğunluğunu çoğu zaman yansıtmaz. \"API gateway veri ambarına bağlı\" cümlesi, bu bağımlılığın canlı trafik, batch iş, gizli veri akışı ya da yalnızca raporlama yolu üzerinden olduğunu göstermez. Sonuçta değişiklik anında bütün oklar aynı ağırlıkta algılanır. Bu yüzden kurumsal ekiplerde şu problemler sık görülür: Düşük öncelikli bağımlılık ile kritik çağrı zinciri aynı görünür Ekipler yalnızca kendi doğrudan bağımlılıklarını bilir Incident sırasında ikinci ve üçüncü halka etki geç keşfedilir Değişiklik komiteleri sezgiyle karar verir Graf yaklaşımı bu sorunu, ilişkiyi yalnızca \"var/yok\" olarak değil yön, kritiklük ve gözlemlenebilirlik seviyesiyle ifade ederek çözer. Bağımlılık grafı neyi temsil etmeli? İyi model yalnızca servis isimleri arasındaki çizgilerden oluşmaz. Ben grafın en az şu bilgileri taşımasını gerekli görüyorum: 1. Çağrı veya veri akışının yönü 2. Bağımlılığın canlı mı batch mi olduğu 3. Etkinin müşteri yüzüne çıkma derecesi 4. Gözlemlenebilirlik kapsamı ve sahip ekip Bu metaveri olmadan çizilen ağlar güzel görünür ama karar kalitesi üretmez. Etki analizi için \"kim kime bağlı\" değil, \"hangi değişiklik hangi yolu hangi yoğunlukta keser\" sorusu cevaplanmalıdır. Hangi kaynaklardan beslenmeli? Bağımlılık grafı tek bir envanter sisteminden çıkarılamaz. Sağlam sonuç için birkaç kaynağın birleşmesi gerekir: Service catalog ve sahiplik kayıtları Tracing veya service mesh telemetry API gateway ve ingress logları Batch scheduler ve veri hattı bağımlılıkları Altyapı kodu ve mesajlaşma topolojisi Bu kaynaklar yüzde yüz doğru olmasa da sorun değildir. Asıl değer, farklı yüzeylerden gelen bağımlılık işaretlerini tek yorumlanabilir modele çevirmektir. Graf yaşayan bir ürün olmalı; yılda bir güncellenen diyagram değil. <Callout type=\"tip\" title=\"Etki analizi, topoloji çizimi değildir\" Platform grafı ancak değişiklik kararı anında kullanılabiliyorsa değerlidir. Sadece mimari sunumlarda görünen bir şema, blast radius yönetimine katkı vermez. </Callout Değişiklik öncesi nasıl kullanılır? Benim gördüğüm en faydalı model, grafı değişiklik şablonuna hafifçe bağlamaktır. Büyük bir süreç eklemek gerekmez. Sadece şu soruların otomatik ya da yarı otomatik cevaplanması ciddi fark yaratır: Bu servis hangi müşteri yolaklarında kritik düğüm? Bağımlı olduğu altyapı bileşenlerinden hangileri zaten kırılgan? Gözlemlenebilirlik kapsamı zayıf olan kenarlar hangileri? Benzer bir değişiklik geçmişte hangi düğümleri etkilemiş? Bu bilgilerle değişiklik bileti daha akıllı hale gelir. Onay süresi uzamaz; tersine anlamsız tartışmalar azalır. Incident yönetiminde neden değerli? Incident başladığında bağımlılık grafının en büyük katkısı, şüphe alanını hızla daraltmasıdır. Eğer kritik bir servis bozulduysa sadece onun loguna bakmak yeterli değildir. Yukarı akışta gecikme üreten bir kuyruk, aşağı akışta hata veren bir kimlik servisi ya da zayıf gözlemlenen bir batch köprüsü etkide belirleyici olabilir. Graf burada üç avantaj sağlar: İkinci halka etki alanını hızla çıkarır Hangi ekiplerin masada olması gerektiğini gösterir Geçici mitigation adımlarının hangi müşteri yolunu rahatlatacağını öngörür Böylece incident komutası yalnızca semptom değil, gerçek etki yüzeyi üzerinden hareket eder. En sık hata: Her bağlantıyı kritik saymak Bazı kurumlar graf üretirken her ilişkiyi aynı ağırlıkta modele sokar. Bu yaklaşım kısa sürede gürültü üretir. Graf büyür ama karar kalitesi artmaz. Asıl iş, bağımlılıkları önem derecesi ve davranış tipine göre sadeleştirmektir. Ben şu ayrımı önemli buluyorum: Zorunlu çalışma zamanı bağımlılığı Gecikmeye duyarlı ama toleranslı bağımlılık Sadece raporlama veya batch etkisi üreten bağımlılık Geçici ya da deneysel bağımlılık Bu sınıflandırma yapılırsa graf gerçek operasyon kararlarını besler. Aksi halde platform ekipleri yine sezgiye döner. Sonuç Kurumsal platformlarda bağımlılık grafı ile servis etki analizi, mimari görünürlüğü operasyonel karara çevirdiği için değerlidir. İyi kurulduğunda değişiklik güveni artar, incident yüzeyi daha hızlı okunur ve ekipler kendi servislerini çevresinden kopuk düşünmeyi bırakır. Kurumsal mimari olgunluk da burada belirir: yalnızca bileşenleri listelemekle değil, etki zincirini canlı biçimde okuyabilmekle.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "platform-engineering",
        "architecture",
        "observability",
        "governance",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/apparmor-ile-servis-bazli-linux-sertlestirme",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/apparmor-ile-servis-bazli-linux-sertlestirme",
      "title": "AppArmor ile Servis Bazlı Linux Sertleştirme",
      "summary": "Sunucu servislerini genel sertleştirme yerine süreç bazlı kısıtlarla güvenceye almak için AppArmor rehberi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './apparmor ile servis bazli linux sertlestirme diagram.svg'; Birçok kurum sunucu sertleştirmesini SSH ayarları, paket güncellemeleri ve firewall kurallarıyla sınırlar. Bunlar gereklidir; ancak uygulama sürecinin neye erişebileceğini kısıtlamadığınız sürece ihlal sonrası hareket alanı geniş kalır. AppArmor, özellikle Ubuntu ve Debian tabanlı altyapılarda bu boşluğu kapatmak için pratik bir araçtır. Gücü, çekirdeğe büyük bir güvenlik çerçevesi eklemesinden değil; servis bazında okunabilir kısıtlar tanımlayabilmesinden gelir. <figure <Image src={diagram} alt=\"AppArmor profil akışını gösteren teknik şema\" / <figcaption Servis bazlı profil yaklaşımı, genel sertleştirmeyi uygulama davranışıyla birleştirir.</figcaption </figure AppArmor hangi problem için uygundur? Şu senaryolarda ciddi fayda sağlar: Reverse proxy, job worker veya ajan gibi belirli süreçlerin dosya erişimini daraltmak Beklenmeyen komut çalıştırma yollarını kapatmak Servisin sadece ihtiyaç duyduğu ağ ve dosya alanıyla çalışmasını sağlamak Güvenlik ihlalinde yatay hareketi zorlaştırmak Amaç her şeyi yasaklamak değil, normal davranışı tanımlayıp bunun dışına çıkan hareketi görünür ve engellenebilir hâle getirmektir. Audit moduyla başlamak neden önemlidir? Doğrudan enforce moduna geçmek küçük servislerde bile kırılgan olabilir. Önce profilin deneme modunda çalışması, gerçek erişim desenini görmek için kritiktir. Tipik başlangıç akışı şudur: 1. Servis için temel profil üret 2. complain modunda çalıştır 3. Audit kayıtlarını incele 4. Meşru erişimleri profile ekle 5. Sonra enforce moduna geçir Bu sıra, \"güvenlik açtık ama servis niye durdu\" sürprizlerini azaltır. Basit bir profil örneği Aşağıdaki örnek, /usr/local/bin/report exporter adlı bir servisin yalnızca kendi konfigürasyonunu okuyup belirli dizine yazabilmesini hedefleyen sade bir başlangıç verir: Bu profil iki önemli fikir taşır: süreç yalnızca ihtiyaç duyduğu yolları açar ve özellikle shell ya da key dosyalarına erişim açıkça reddedilir. <Callout type=\"tip\" title=\"İlk hedefiniz tam kapsama değil\" Önce en fazla saldırı yüzeyi taşıyan servisleri profilleyin: internet kenarı proxy'leri, ajanlar, dosya işleyiciler ve entegrasyon worker'ları genelde iyi başlangıç noktasıdır. </Callout Loglar nasıl okunmalı? Profil devreye alındığında asıl öğretici alan audit kayıtlarıdır. Özellikle şu desenleri arayın: Beklenmeyen dosya açma denemeleri Shell veya yardımcı ikili çalıştırma girişimleri Geçici dizinlerde gereksiz yazma denemeleri Servisin normalde erişmemesi gereken gizli anahtar yolları Bu kayıtlar bazen saldırı denemesi, bazen de yıllardır fark edilmeyen gereksiz bağımlılık anlamına gelir. Her iki durumda da değer üretir. Operasyon ekipleri için pratik yaklaşım nedir? Ben AppArmor'u merkezi bir baseline yerine servis sınıfı bazında ele almayı öneriyorum: Proxy ve edge servisleri Arka plan işleyicileri Gözlemlenebilirlik ajanları Yönetim yardımcı araçları Her sınıf için tekrar kullanılabilir profil kalıpları oluşturmak, yeni sunucu açıldığında güvenliği hızlandırır. Böylece AppArmor bir kere açılıp unutulan araç değil, altyapı standardının parçası olur. Hangi hatalar sık görülür? En yaygın hata, kırılan meşru erişimleri çözmek için profili hızla genişletip yine anlamsız hâle getirmektir. İkinci hata ise tüm servisler için tek profil mantığı kurmaktır. Güvenli ve sürdürülebilir yaklaşım, dar kapsamlı ama anlaşılır profilleri çoğaltmaktır. Sonuç AppArmor ile servis bazlı Linux sertleştirme, klasik sunucu güvenliğini süreç seviyesine taşır. Dosya, komut ve çalışma davranışı sınırlandığında saldırganın hareket alanı belirgin biçimde azalır. Kurumsal altyapılarda gerçek değer, bu profilleri birkaç kritik servis üzerinde sessizce çalıştırmakta değil; onları gözlemlenebilir ve tekrar kullanılabilir operasyon standardına dönüştürmektedir.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "security",
        "linux",
        "apparmor",
        "servers",
        "hardening"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/blackbox-exporter-ile-cok-noktadan-servis-sagligi-izleme",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/blackbox-exporter-ile-cok-noktadan-servis-sagligi-izleme",
      "title": "Blackbox Exporter ile Çok Noktadan Servis Sağlığı İzleme",
      "summary": "Farklı ağ noktalarından HTTP, TCP ve TLS denetimleri yaparak gerçek erişilebilirlik sinyalini Prometheus'a taşıyan kurulum rehberi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './blackbox exporter ile cok noktadan servis sagligi izleme diagram.svg'; Servis erişilebilirliğini yalnızca içeriden ölçmek, özellikle kurumsal ağlarda sıkça yanıltıcıdır. Uygulama pod'u ayaktadır, node sağlıklıdır, load balancer yanıt veriyordur; ama belirli ofis segmentinden, partner ağından ya da internet çıkışından servis gerçekte ulaşılamaz durumdadır. Blackbox Exporter bu kör noktayı kapatmak için çok etkili bir araçtır. Doğru kullanıldığında sentetik probe sayfası değil, ağ deneyimini farklı noktalardan ölçen güvenilir bir sinyal katmanı hâline gelir. <figure <Image src={diagram} alt=\"Blackbox Exporter ile çok noktadan servis sağlığı izlemesini gösteren teknik şema\" / <figcaption Gerçek erişilebilirlik ancak tek merkezden değil, etki yaratan ağ konumlarından ölçüldüğünde görünür olur.</figcaption </figure Ne kuracağız? Bu rehberde şu modeli kuracağız: Farklı ağ bölgelerinde çalışan birden fazla probe istemcisi HTTP ve TCP denetimlerini yapan Blackbox Exporter Sonuçları toplayan Prometheus Hedef ve konuma göre alarm üreten etiketleme yapısı Amaç, \"servis açık mı?\" sorusunu tek noktalı ve yanıltıcı şekilde değil, hangi konumdan açık olduğunu gösterecek biçimde yanıtlamaktır. 1. Blackbox Exporter konfigürasyonunu hazırlayın İlk adım, denetim modüllerini tanımlamaktır. Aşağıdaki örnek; HTTP 2xx, TCP bağlantısı ve TLS sertifika geçerliliği için sade bir başlangıç sunar: Burada önemli nokta, her problemi tek modüle yıkmamaktır. HTTP erişilebilirlik, ham TCP ulaşılabilirlik ve TLS doğrulaması farklı alarm yüzeyleri üretir. <Callout type=\"tip\" title=\"Probe'u hedefin yerine koymayın\" Blackbox sinyali uygulama metriklerinin alternatifi değildir. İç gözlem ile dış gözlem birlikte çalışmalıdır. </Callout 2. Exporter'ı farklı noktalara yerleştirin Asıl değer bu adımda çıkar. Blackbox Exporter'ı yalnızca merkezi izleme ağında çalıştırırsanız yine tek bakış noktasına mahkûm kalırsınız. Bunun yerine örneğin şu konumları düşünün: Merkez veri merkezi çıkışı Bulut VPC içi izleme segmenti Şube veya uzak ofis çıkışı İnternete açık bağımsız probe noktası Her probe aynı hedefi izleyebilir; fakat probe location etiketi farklı olur. Böylece kesintinin gerçekten servis katmanında mı yoksa belirli erişim yolunda mı olduğunu daha hızlı anlarsınız. 3. Prometheus scrape tanımını ekleyin Aşağıdaki örnek, Blackbox Exporter'a hedefi parametre olarak verip sonuçta hedef URL ve probe konumunu etikete dönüştürür: Farklı noktalar için aynı blok ayrı Prometheus'larda ya da federasyonla çalışan bölgesel toplama katmanlarında tekrarlanabilir. 4. Alarm mantığını tek başarısız probe üzerine kurmayın Kurumsal ağlarda geçici DNS, rota veya çıkış sorunları kaçınılmazdır. Bu nedenle alarmı \"bir probe başarısız oldu\" mantığıyla kurmak gürültü üretir. Daha iyi yaklaşım, konum çoğunluğu ya da kritik konum eşikleri tanımlamaktır. Örnek: İnternet probe'u ve iki iç probe aynı anda düşerse kritik alarm Sadece tek şube probe'u düşerse orta seviye alarm TLS geçerlilik süresi 14 gün altına inerse bakım alarmı Bu model, sentetik izlemenin sahadaki gerçek önceliklerle hizalanmasını sağlar. 5. Sonuçları servis sahipliğine bağlayın Blackbox Exporter çok faydalı olabilir; ama hedef listesi sahipsiz bırakılırsa hızla eskiyen bir kontrol paneline dönüşür. Bunun için hedef tanımlarını şu metadatalarla birlikte tutmak iyi sonuç verir: Servis sahibi ekip İş etki seviyesi Beklenen erişim yüzeyi İlgili TLS alan adı Escalation politikası Bu sayede alarm çıktısı doğrudan doğru ekibe bağlanır. 6. Basit bir PromQL örneği Konuma göre başarısız probe oranını görmek için aşağıdaki sorgu yararlıdır: Sertifika kalan gününü izlemek için de: Bu iki sorgu birlikte kullanıldığında hem erişilebilirlik hem sertifika hijyeni tek panelde görünür olur. Sonuç Blackbox Exporter ile çok noktadan servis sağlığı izleme kurmak, erişilebilirliği uygulama içinden değil gerçek erişim yollarından görmek için güçlü bir adımdır. Tek merkezden çalışan probe'lar yerine konuma duyarlı sentetik ölçüm kurduğunuzda ağ, DNS, TLS ve kenar katmanındaki kırılmaları daha hızlı ayırırsınız. İyi tasarlanmış sentetik izleme, daha fazla alarm değil; daha doğru bağlam üretir.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "prometheus",
        "network",
        "monitoring",
        "sre"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/headscale-ile-kurumsal-yonetim-agi-overlay-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/headscale-ile-kurumsal-yonetim-agi-overlay-tasarimi",
      "title": "Headscale ile Kurumsal Yönetim Ağı Overlay Tasarımı",
      "summary": "Dağınık sunucu ve yönetim uçlarına kontrollü erişim sağlamak için Headscale tabanlı yönetim ağı overlay rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Dağınık veri merkezi, bulut ve uzak ofis ortamlarında yönetim erişimi büyüdükçe klasik VPN modeli zorlanmaya başlar. Herkesi aynı ağa sokan kalın tüneller, erişim sınırını sadeleştirmek yerine bulanıklaştırır. Headscale ile kurumsal yönetim ağı overlay tasarımı, tam burada daha kontrollü bir yol sunar: merkezi bir koordinasyon düzlemi, kısa listelenmiş istemciler ve yalnızca gerekli düğümlerin birbirini görmesi. Bu yaklaşım hangi problemi çözer? Birçok kurumda yönetim erişimi zamanla katman katman büyür: Bastion üstüne ikinci bastion eklenir Uzak ofisler için ayrı VPN profilleri açılır Sunucu ekipleri ile platform ekipleri aynı ağ koridorunu paylaşır Acil erişim için geçici istisnalar kalıcı hale gelir Sonuçta ağ erişimi vardır ama erişim modeli okunabilir değildir. Headscale tabanlı overlay, erişimi fiziksel konuma değil kimlik ve cihaz üyeliğine bağlayarak bu dağınıklığı azaltır. Temel mimari nasıl kurulmalı? Pratikte üç katman yeterlidir: 1. Headscale kontrol düzlemi 2. Yönetilen istemciler ve sunucular 3. Politika dosyası ile tanımlanan görünürlük sınırları Burada kritik karar, overlay ağı \"herkes her yere erişsin\" mantığıyla kurmamaktır. Amaç L3 rahatlığı değil, yönetim trafiğini açık sahiplikle daraltmaktır. Bu yüzden namespace, grup ve ACL modeli ilk günden düşünülmelidir. Başlangıç bileşenleri Küçük ama üretime yakın bir kurulum için şu bileşenler yeterlidir: Bir Linux sunucuda Headscale servisi İstemciler için Tailscale uyumlu agent Kurumsal kimlik sistemiyle entegre kayıt akışı Ayrı bir DNS çözümleme veya MagicDNS kararı Log ve audit izlemesi Headscale, kontrol düzlemini kendi elinizde tutmanızı sağlar; ancak bunun karşılığında yaşam döngüsü ve politika disiplinini sizin kurmanız gerekir. O yüzden ilk aşamada kullanıcı sayısından çok sahiplik modeline odaklanın. Örnek konfigürasyon iskeleti config.yaml için sade bir başlangıç örneği: Bu yapı tek başına yeterli değildir; ama hangi sorumluluğun sizde olduğunu berraklaştırır. DNS, metrics ve adres aralığı kararlarını baştan açık yazmak ileride overlay karmaşasını azaltır. ACL modelini baştan dar kurun Kurumsal kullanımda en sık yapılan hata, ilk kurulumun geniş ACL ile açılmasıdır. Sonra ekipler o geniş erişime alışır ve sıkılaştırma politik olarak zorlaşır. Bunun yerine başlangıçtan itibaren dar görünürlük tanımlamak daha sağlıklıdır. Örnek bir ACL yaklaşımı: Bu örnekte dikkat edilmesi gereken nokta, erişimin IP'ye değil role ve etikete bağlanmasıdır. Sunucu taşınsa bile yönetim kuralı aynı mantıkla çalışır. <Callout type=\"tip\" title=\"Overlay kolayligi, sınırsız görünürlük anlamına gelmez\" Headscale ile iyi tasarımın ölçüsü kullanıcıların ağa girebilmesi değil, gereksiz düğümlerin birbirini hiç görmemesidir. </Callout Operasyonel doğrulama nasıl yapılmalı? Kurulum sonrası şu kontrolleri mutlaka uygulayın: Yeni bir istemci yalnızca beklenen tag'lerle görünüyor mu? DNS sorguları kurumsal resolver üzerinden mi akıyor? Yanlış grupla kaydedilen cihazlar erişim kazanıyor mu? Overlay kapansa bile üretim servisleri etkilenmiyor mu? Audit log'ları kim, ne zaman, hangi cihazla bağlandı bilgisini taşıyor mu? Bu kontroller yapılmadığında overlay ağı çalışıyor görünür ama yönetim düzlemi sessizce fazla genişler. Headscale ne zaman doğru tercih olmaz? Eğer kurumun asıl ihtiyacı tam mesh değil, sabit site to site taşıma ise overlay kontrol düzlemi gereğinden fazla soyutlama olabilir. Benzer şekilde cihaz yaşam döngüsünü ve kimlik entegrasyonunu yönetecek operasyon disiplini yoksa Headscale kısa sürede \"bir araç daha\" problemine dönüşür. Bu nedenle şu sorular önce sorulmalı: Yönetim erişimini kullanıcıdan cihaza kadar etiketleyebiliyor muyuz? Overlay üyeliğini offboarding sürecine bağlıyor muyuz? İnternet çıkışı zayıf bölgeler için relay ya da DERP stratejimiz var mı? Bu ağın denetim kaydını gerçekten okuyacak mıyız? Bu sorulara net cevap yoksa önce işletim modelini toparlamak gerekir. Sonuç Headscale ile kurumsal yönetim ağı overlay tasarımı, klasik VPN karmaşasını kimlik ve cihaz temelli daha okunabilir bir erişim modeline çevirebilir. Değeri yalnızca self hosted kontrol düzlemi sunmasında değil, yönetim ağını açık policy ve dar görünürlük ilkesiyle kurabilmesinde yatar. İyi sonuç almak için de ilk günden şu disiplin korunmalıdır: overlay kurmak kolay, onu kurumsal sınırlarla yaşatmak asıl iştir.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "network",
        "security",
        "headscale",
        "automation",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/nuclei-ile-ic-varliklarda-surekli-zafiyet-dogrulama",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/nuclei-ile-ic-varliklarda-surekli-zafiyet-dogrulama",
      "title": "Nuclei ile İç Varlıklarda Sürekli Zafiyet Doğrulama",
      "summary": "İç ağdaki servisleri düşük gürültüyle tarayıp doğrulanmış bulguları operasyon akışına bağlamak için pratik Nuclei yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal iç ağlarda zafiyet yönetimi çoğu zaman iki uçtan birine savrulur. Ya kapsamlı taramalar nadiren yapılır ve sonuçlar haftalarca işlenmeden kalır, ya da çok sık tarama yapılıp gürültü seviyesi ekiplerin güvenini düşürür. Nuclei bu dengeyi kurmak için iyi bir araçtır; çünkü doğrulanabilir şablon yaklaşımıyla hedefi belli, düşük maliyetli ve otomasyona uygun kontroller üretir. Nuclei'yi neden iç ağ için düşünmeli? Nuclei genelde internet yüzeyi taramalarında anılır, fakat iç varlıklar için de güçlüdür. Özellikle şu senaryolarda değer üretir: Yönetim panellerinde unutulmuş varsayılan yollar Açık versiyon bilgisinden doğrulanabilen zafiyetler Kurumsal standart dışı başlık veya konfigürasyon eksikleri Bilinen middleware ve ajan yüzeyleri Burada ana fikir, her portu körlemesine denemek değil; envanteri bilinen servis sınıflarına göre anlamlı şablon setleriyle doğrulamaktır. Hedef listesi nasıl hazırlanmalı? En sağlıklı model, hedefleri CMDB veya servis envanterinden beslemektir. En azından şu alanlar olmalı: Varlık adı IP veya FQDN Servis tipi Ortam sınıfı Sahip ekip Bu veri sayesinde Nuclei şablonlarını tüm ağa aynı şekilde değil, servis profiline göre uygulayabilirsiniz. Örnek hedef dosyası: Temel tarama komutu: Gürültüyü nasıl azaltırsınız? Asıl farkı burada yaratırsınız. İç ağda sürekli doğrulama kurarken şu filtreler önemlidir: Şablonları servis sınıfına göre ayırmak Düşük değerli bilgi bulgularını varsayılan olarak dışarıda bırakmak Bakım penceresi dışındaki agresif kontrolleri kapatmak Aynı bulguyu tekrar tekrar ticket'a dönüştürmemek Pratikte çoğu ekip için günlük hafif tarama, haftalık derin taramadan daha sürdürülebilir sonuç verir. <Callout type=\"tip\" title=\"Doğrulama ile keşfi ayırın\" İç ağda Nuclei'yi keşif aracı gibi kullanmak yerine, zaten bilinen varlıkları doğrulayan bir kontrol katmanı olarak kullanmak daha düşük gürültü üretir. </Callout Operasyon akışına nasıl bağlanır? En kötü kullanım, JSON çıktısını üretip kimsenin bakmadığı bir klasöre bırakmaktır. Benim önerdiğim akış şöyledir: 1. Nuclei çıktısını jsonl olarak üretin 2. Aynı bulgunun açık kaydı varsa yeniden açmayın 3. Sahip ekibi varlık envanterinden eşleyin 4. Sadece doğrulanmış orta ve üzeri bulguları ticket'a dönüştürün 5. Kritik bulgular için kısa SLA ve yeniden doğrulama çalıştırın Bu model, zafiyet yönetimini rapor üretiminden çıkarıp kapanabilir operasyon işine dönüştürür. Örnek zamanlama Basit bir cron yaklaşımı yeterli olabilir: Bu komutun ardından küçük bir ayrıştırıcı ile bulguları normalize edip mevcut ticket sistemiyle eşleştirebilirsiniz. En sık yapılan hata Şablon deposunun tamamını hiçbir filtre olmadan iç ağa koşturmak sık görülen hatadır. Böyle yapıldığında hem gereksiz gürültü oluşur hem de bazı ekipler taramayı saldırı gibi algılar. Başlangıç için daha dar ama güvenilir bir şablon seti seçmek, sisteme güven oluştuğunda kapsamı büyütmek daha doğrudur. Sonuç Nuclei ile iç varlıklarda sürekli zafiyet doğrulama, iç ağ güvenliğini dönemsel tarama raporlarından çıkarıp yaşayan bir kontrol katmanına dönüştürür. Hedef envanteri, sınıflandırılmış şablon seti ve tekrarları azaltan ticket akışı birlikte kurulduğunda hem gürültü azalır hem de gerçekten kapanan bulgu oranı yükselir. Sağlam zafiyet yönetimi, en çok bulgu üreten değil; en tutarlı doğrulama döngüsünü kuran sistemdir.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "security",
        "network",
        "automation",
        "vulnerability-management",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/opentelemetry-collectorda-tail-sampling-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/opentelemetry-collectorda-tail-sampling-tasarimi",
      "title": "OpenTelemetry Collector'da Tail Sampling Tasarımı",
      "summary": "Yüksek hacimli trace verisinde maliyeti düşürürken kritik akışları korumak için tail sampling kurgusunu anlatan rehber.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './opentelemetry collectorda tail sampling tasarimi diagram.svg'; Trace verisi büyüdükçe ekipler iki uç arasında sıkışır: her span'i saklamak pahalıdır, ama fazla agresif örnekleme incident anında körlük yaratır. Head sampling bu sorunu erken ve ucuz biçimde azaltır; fakat karar daha isteğin sonucu bilinmeden verildiği için kritik hata zincirlerini kaçırabilir. Tail sampling ise isteğin tamamı görüldükten sonra karar verdiği için özellikle kurumsal sistemlerde çok daha anlamlıdır. Bedeli ise daha dikkatli kuyruk ve bellek tasarımıdır. <figure <Image src={diagram} alt=\"Tail sampling tabanlı trace hattını gösteren teknik şema\" / <figcaption Tail sampling, trace'in sonunu bekleyerek karar verdiği için hata ve gecikme örneklerini daha iyi korur.</figcaption </figure Tail sampling ne zaman gerekli olur? Şu sinyaller varsa genelde zamanı gelmiştir: İstek hacmi yüksek ama anlamlı hata oranı düşüktür Health check ve düşük değerli trafik trace depolamasını şişirir Incident sonrası \"tam o isteğin trace'i yok\" cümlesi sık duyulur Maliyet düşürme baskısı instrumentation kalitesini tehdit etmeye başlar Bu durumda amaç tüm veriyi kesmek değil, yüksek tanısal değeri koruyan seçici bir akış kurmaktır. Temel tasarım prensibi nedir? Ben tail sampling için üç katman öneriyorum: 1. Hata veya yüksek gecikme içeren trace'leri öncelikli tut 2. Kritik servisler için minimum örnekleme tabanı bırak 3. Başarılı ve düşük etkili trafiği düşük oranda örnekle Bu model, yalnızca teknik maliyet değil operasyon önceliği üzerinden de okunabilir. Önemli olan sampling kuralını backend fiyatına göre değil, hangi soruları cevaplamak istediğinize göre kurmaktır. Örnek Collector akışı Aşağıdaki örnek, tail sampling'i bellek güvenliği ve temel sınıflandırma ile birlikte başlatmak için sade bir çerçeve verir: Bu örnekte decision wait ve num traces değerleri kritik parametrelerdir. Çok düşük ayar, geç biten trace'leri eksik toplar; çok yüksek ayar ise collector belleğini gereksiz büyütür. <Callout type=\"tip\" title=\"Sampling kuralını önce gözlemleyin\" İlk gün tam ret politikasıyla başlamayın. Hangi policy'nin ne kadar trace tuttuğunu birkaç gün ölçmeden kalıcı oran belirlemek yanıltıcıdır. </Callout Politika sırası neden önemli? Tail sampling yalnızca \"yüzde kaç kalsın\" problemi değildir. Politika mantığını şu sırayla düşünmek daha sağlıklı olur: Önce kesin tutulacak sınıflar Sonra iş açısından kritik ama teknik olarak başarılı istekler En sonda arka plan ve düşük değerli trafik Böylece düşük oranlı genel örnekleme, kritik hata trace'lerini gölgede bırakmaz. Operasyon tarafında hangi metrikler izlenmeli? En az şu alanları dashboard'a bağlamak gerekir: Collector bellek tüketimi Sampling sonrası trace kabul oranı Politika bazında tutulan trace sayısı Karar bekleme süresi ve düşen trace miktarı Bu metrikler olmadan tail sampling çoğu ekipte \"maliyet düştü sanıyoruz\" şeklinde kör uygulanır. Oysa yanlış ayarlı akış, sessiz veri kaybı üretir. Yaygın hata nedir? Tek collector havuzunda tüm servisleri aynı policy setiyle yönetmek. ERP, kimlik ve batch iş akışları aynı tanısal değere sahip değildir. İdeal durumda en azından servis sınıfına göre ayrı policy kümeleri ya da ayrı collector havuzları düşünülmelidir. Sonuç OpenTelemetry Collector'da tail sampling tasarımı, trace hacmini azaltma hilesi değil gözlemlenebilirlik önceliklerini kodlama işidir. Hata, gecikme ve kritik servis trafiği korunurken düşük değerli akışlar kontrollü azaltıldığında hem maliyet hem de tanı kalitesi birlikte iyileşir. Güçlü sonuç almak için sampling oranından önce karar bekleme süresi, bellek sınırı ve politika görünürlüğü doğru kurulmalıdır.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "opentelemetry",
        "tracing",
        "sampling",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/step-ca-ile-ic-servisler-icin-kisa-omurlu-sertifika-otomasyonu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/step-ca-ile-ic-servisler-icin-kisa-omurlu-sertifika-otomasyonu",
      "title": "step-ca ile İç Servisler için Kısa Ömürlü Sertifika Otomasyonu",
      "summary": "İç servisler arasında uzun ömürlü sertifika yükünü azaltmak için step-ca tabanlı kısa ömürlü TLS sertifikası üretim akışını anlatan rehber.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './step ca ile ic servisler icin kisa omurlu sertifika otomasyonu diagram.svg'; İç servis trafiğinde TLS kullanımı artık istisna değil temel beklenti. Buna rağmen birçok kurumda sertifika yönetimi hâlâ manuel talepler, uzun ömürlü dosyalar ve nadiren dokunulan gizli anahtarlar üzerinden ilerliyor. Bu model küçük ölçekte taşınabilir; fakat servis sayısı arttıkça operasyon yükü ve güvenlik riski birlikte büyür. Kısa ömürlü sertifika yaklaşımı, bu yükü azaltmak için etkili bir yöntemdir. step ca, sade kurulum modeli sayesinde bu dönüşüm için pratik bir başlangıç sunar. <figure <Image src={diagram} alt=\"step ca ile kısa ömürlü sertifika otomasyonunu gösteren teknik şema\" / <figcaption Sertifika yaşam döngüsü otomasyona geçtiğinde güvenlik, iş yükü ve hata olasılığı aynı anda iyileşir.</figcaption </figure Neden kısa ömürlü sertifika? Uzun ömürlü sertifikalar ilk bakışta rahat görünür. Bir kez üretirsiniz, aylarca unutursunuz. Fakat bu rahatlık üç sorun taşır: Sızıntı durumunda etki süresi uzundur Yenileme zamanı geldiğinde operasyon baskısı oluşur Sertifika sahipliği zamanla belirsizleşir Kısa ömürlü sertifikada ise güvenlik modeli \"iyi koru ve uzun süre sakla\" yerine \"hızlı üret, kısa kullan, otomatik yenile\" eksenine kayar. Böylece risk yüzeyi küçülür. 1. step ca kurulumu Önce kontrol düzlemini ayağa kaldırın. Küçük bir lab ya da iç ağ ortamında aşağıdaki komutlar iyi bir başlangıç verir: Kurulum sırasında kök ve ara CA anahtarlarının korunacağı dizini dikkatle seçin. Bu host mümkünse genel amaçlı uygulama düğümlerinden ayrılmalıdır. 2. ACME provisioner ekleyin İç servislerin otomatik sertifika alabilmesi için ACME akışını açmak en pratik seçeneklerden biridir: Bu sayede servisler certbot benzeri akışlarla ya da doğrudan step istemcisiyle sertifika alabilir. İç DNS çözümlemesi ve erişim kontrolü bu noktada önemlidir; her host'a koşulsuz sertifika vermek istemezsiniz. <Callout type=\"tip\" title=\"Kimlik doğrulamayı servis ağıyla bağlayın\" Mümkünse sertifika talep hakkını yalnızca belirli ağlardan, servis hesaplarından veya cihaz kimliklerinden gelen istemcilere tanımlayın. </Callout 3. Servis üzerinde sertifika isteyin Örnek olarak bir iç API için kısa ömürlü bir sertifika alalım: Gerçek üretimde bunu elle çalıştırmak yerine systemd timer, sidecar ya da giriş script'i içinde otomatikleştirmek daha doğrudur. Ana fikir, sertifika dosyasının tek seferlik insan işlemiyle değil, denetimli otomasyonla üretilmesidir. 4. Yenilemeyi zamanlayın Kısa ömürlü sertifika modelinin kalbi yenilemedir. Sertifika süresini örneğin 24 saate çekiyorsanız yenilemeyi son dakikaya bırakmamak gerekir. Basit bir systemd timer örneği: Bu örnekte kritik nokta, yenileme sonrası servisin yeni sertifikayı gerçekten yüklemesidir. Dosya yenilenip proses eski sertifikayla çalışmaya devam ederse model kağıt üzerinde kalır. 5. Gözlem ve alarm ekleyin Sertifika otomasyonu kurulduktan sonra her şeyin kendi kendine çalışacağını varsaymak risklidir. Şu sinyalleri mutlaka izleyin: Kalan sertifika ömrü Son başarılı yenileme zamanı Yenileme hata oranı step ca erişilebilirliği İmzalama isteği hacmi ve başarısızlık dağılımı Bu görünürlük olmadan otomasyon sessizce bozulabilir ve ancak büyük çaplı sona erme olayında fark edilir. 6. Gizli anahtar yönetiminde dikkat edilmesi gerekenler Kısa ömürlü sertifika kullanmak, özel anahtar disiplinini gereksiz kılmaz. Hatta bazı durumlarda yenileme sıklaştığı için anahtar dosyasına dokunan süreç sayısı artabilir. Bu yüzden: Anahtar izinlerini minimumda tutun Yenileme sürecini servis kullanıcısıyla sınırlandırın Mümkünse anahtar rotasyonunu da periyodikleştirin step ca log'larında hassas içerik bırakmayın Sertifika ömrü kısaldıkça operasyon daha güvenli olur; ama yalnızca anahtar hijyeni de korunuyorsa. Sonuç step ca ile iç servisler için kısa ömürlü sertifika otomasyonu kurmak, mTLS ve iç TLS kullanımını operasyonel açıdan taşınabilir hâle getirir. Uzun ömürlü sertifikaların unutulmuş riskini azaltır, yenileme baskısını otomasyona taşır ve servis güvenliğini daha düzenli bir ritme bağlar. İç PKI'nin değeri, karmaşık olmasında değil; ekiplerin gerçekten sürdürebileceği kadar sade olmasında yatar.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "security",
        "tls",
        "automation",
        "pki",
        "platform-engineering"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/syft-ve-grype-ile-sbom-tabanli-imaj-kabul-kapisi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/syft-ve-grype-ile-sbom-tabanli-imaj-kabul-kapisi",
      "title": "Syft ve Grype ile SBOM Tabanlı İmaj Kabul Kapısı",
      "summary": "Container imajlarını yalnızca CVE listesiyle değil, bileşen envanteri ve politika eşiğiyle kabul etmek için pratik rehber.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Container güvenliğinde en yaygın refleks, imajı registry'ye göndermeden önce bir zafiyet tarayıcısından geçirip kritik bulgu varsa yayını durdurmaktır. Bu temel yaklaşım gereklidir ama tek başına yeterli değildir. Çünkü çoğu ekip aslında hangi bileşenleri taşıdığını bilmeden yalnızca anlık CVE çıktısına göre karar verir. SBOM tabanlı kabul kapısı ise kararı daha sağlam zemine taşır: önce imajın içeriğini görünür kılar, sonra politikayı bu envanter ve zafiyet birleşimi üzerinden uygular. Neden yalnızca tarama skoru yetmez? Bir imaj bugün temiz görünebilir, yarın yeni bir CVE ile riskli hale gelebilir. Ayrıca aynı imajda gereksiz shell araçları, unutulmuş dil runtime'ları ya da kurumsal olarak yasaklı paketler bulunabilir. Bunlar doğrudan CVE puanına yansımayabilir. SBOM burada iki şeyi mümkün kılar: İmajın içeriğini sürüm bazında kayıt altına almak Zafiyet dışındaki politika ihlallerini de konuşabilmek Syft bu envanteri üretmek için, Grype ise bu envanteri ve imajı zafiyet verisiyle eşlemek için oldukça pratik araçlar sunar. Basit akış nasıl kurulur? En yalın boru hattı şu adımlardan oluşur: 1. İmajı build edin 2. Syft ile SPDX veya CycloneDX formatında SBOM üretin 3. Grype ile imajı veya üretilen SBOM'u tarayın 4. Çıktıyı bir politika eşiğine göre yorumlayın 5. Kabul edilen imajı imzalayıp registry'ye gönderin Örnek Syft komutu: Ardından Grype ile aynı imajı ya da dosyayı tarayabilirsiniz: Bu komut yalnızca başlangıçtır. Gerçek değer, fail on seviyesini iş bağlamınıza göre ayarladığınızda oluşur. Politikayı CVE eşiğinden ibaret bırakmayın Kurumsal kapıda şu kurallar daha sağlıklı sonuç verir: Üretim imajlarında kritik zafiyet sıfır tolerans Yüksek zafiyetlerde yalnızca istisna kaydıyla geçiş Desteklenmeyen taban imajlara otomatik red Yasaklı paket veya shell araçlarında red SBOM dosyası olmayan build'lerde doğrudan red Bu sayede kabul kapısı, reaktif tarama adımı olmaktan çıkıp supply chain kontrolü haline gelir. <Callout type=\"tip\" title=\"Temiz imaj, küçük imaj demek değildir\" Küçük imajlar genelde daha az yüzey taşır ama asıl önemli olan hangi paketlerin neden orada olduğunun görünür olmasıdır. SBOM bu görünürlüğü sağlar. </Callout CI içinde nasıl bağlanır? GitHub Actions, GitLab CI ya da kendi Jenkins hattınızda temel mantık aynıdır. Build sonrası önce SBOM üretin, sonra tarayın, son olarak sonucu artefact olarak saklayın. Basit bir örnek: Sonraki adımda JSON çıktısını politika dosyanızla yorumlayabilirsiniz. Örneğin belirli paket ailelerini yasaklayabilir, CVE skorunu çalışma zamanı profiliyle ağırlıklandırabilir veya yalnızca internete açık servislerde daha sert eşik uygulayabilirsiniz. Hangi kayıtlar saklanmalı? Uygulamada şu artefact'ları saklamak önemli fark yaratır: İmaj digest'i SBOM dosyası Grype raporu Kabul veya red kararı İstisna varsa onay kaydı ve son kullanma tarihi Böylece üç ay sonra \"bu imaj neden geçmişti?\" sorusuna savunulabilir cevap verebilirsiniz. Sık yapılan hata En sık hata, tüm kırmızı bulguları anında bloklayıp ekiplerin sisteme güvenini kırmaktır. Eğer başlangıçta taban imajlar zaten kirliyse, politika bir gecede tam sertleştirilmemelidir. Daha iyi yaklaşım, önce görünürlük, sonra zorunlu eşik, en son istisna yönetimi katmanı kurmaktır. Sonuç Syft ve Grype ile SBOM tabanlı imaj kabul kapısı, container güvenliğini anlık tarama refleksinden çıkarıp tekrar edilebilir tedarik zinciri kontrolüne dönüştürür. SBOM üretmek, zafiyet taramak ve sonucu kayıtlı politika ile değerlendirmek birlikte çalıştığında hem güvenlik kalitesi artar hem de ekipler hangi imajın neden geçtiğini daha net görür. Güçlü kapı, en çok alarm veren değil; en tutarlı kabul kararını üreten kapıdır.",
      "date_published": "2026-04-10T00:00:00.000Z",
      "date_modified": "2026-04-10T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "security",
        "devops",
        "containers",
        "sbom",
        "supply-chain"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-teknik-borc-pazarligi-cercevesi",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-teknik-borc-pazarligi-cercevesi",
      "title": "Kıdemli Mühendisler İçin Teknik Borç Pazarlığı Çerçevesi",
      "summary": "Teknik borcu yalnızca şikâyet konusu olmaktan çıkarıp bütçe, risk ve teslim planı arasında pazarlık edilebilir hale getiren yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kidemli muhendisler icin teknik borc pazarligi cercevesi diagram.svg'; Teknik borç çoğu ekipte iki hatalı uç arasında yaşar. Birinci uçta borç sürekli şikâyet edilir ama iş planına giremez. İkinci uçta ise her kalite problemi \"önce bunu temizleyelim\" diyerek teslim takvimini felç eder. Kıdemli mühendislik pratiğinde değer üreten yaklaşım, teknik borcu duygusal bir yakınma alanı olmaktan çıkarıp pazarlık edilebilir bir mühendislik konusu hâline getirmektir. <figure <Image src={diagram} alt=\"Teknik borç, teslim baskısı ve risk azaltımı arasında kurulan pazarlık çerçevesini gösteren teknik şema\" / <figcaption İyi kıdemli mühendis, borcu sadece görmez; doğru anda doğru dile çevirir.</figcaption </figure Teknik borç neden pazarlık konusu olmak zorunda? Çünkü kurumsal ekiplerde kaynaklar sınırlıdır ve her iş aynı anda yapılamaz. Teknik borcun gerçek etkisi çoğu zaman şu başlıklardan birine dokunur: Teslim hızını yavaşlatır Incident ihtimalini artırır Değişiklik riskini yükseltir Onboarding süresini uzatır Platform maliyetini görünmez biçimde büyütür Fakat bu etkiler soyut cümlelerle anlatıldığında iş kararına dönüşmez. \"Bu kod kötü\" demek yerine \"bu servis her değişiklikte iki ekip bağımlılığı yaratıyor\" demek daha güçlüdür. Pazarlık çerçevesi tam burada başlar. Borcu konuşurken hangi dili kullanmak gerekir? Ben üç dilli bir modelin faydalı olduğunu düşünüyorum: 1. Risk dili 2. Akış dili 3. Maliyet dili Risk dili, olası kesinti veya güvenlik etkisini anlatır. Akış dili, teslim süresini ve ekip bekleme noktalarını görünür kılar. Maliyet dili ise fazla altyapı, operasyon yükü veya yeniden işleme bedelini masaya getirir. Kıdemli mühendis, aynı problemi bu üç dilden uygun olanla anlatabildiğinde karar vericilerle ortak zemin kurar. Örneğin \"monolitik deployment pipeline karmaşık\" cümlesi zayıftır. Bunun yerine \"rollback süremiz kırk dakikaya çıktığı için değişiklik pencereleri daralıyor\" cümlesi karar üretir. Her teknik borç aynı önemde değildir En sık hata, bütün borçları eşit öncelikli göstermek. Bu yaklaşım kısa sürede güven kaybettirir. Daha sağlam model, borcu şu kümelere ayırmaktır: Kesinti borcu : Incident olasılığını veya etki alanını büyüten borç Akış borcu : Ekiplerin iş teslim hızını düşüren borç Uyum borcu : Denetim, güvenlik veya regülasyon riski doğuran borç Platform borcu : Tekrarlı manuel iş ve işletim yükü yaratan borç Bu sınıflandırma sayesinde aynı backlog içinde hangi kalemin neden öne çıktığı daha şeffaf olur. <Callout type=\"tip\" title=\"Borcun sahibini değil etkisini görünür yapın\" \"Bu kodu şu ekip yazdı\" ekseninde başlayan konuşma savunma üretir. \"Bu yapı her release'te aynı darboğazı yaratıyor\" ekseni ise çözüm üretir. </Callout Pazarlık masasına neyle gidilir? Yalnızca sezgiyle değil, küçük ama ikna edici kanıtlarla. Benim faydalı bulduğum giriş seti şunlar: Son üç değişiklikte görülen aynı hata deseni Ortalama lead time veya rollback süresi Runbook bağımlılığı veya tek kişiye bağlı operasyon adımı Alert hacmi ile gerçek kök neden arasındaki kopukluk Yeni ekip üyelerinin öğrenme eğrisi Bu veriler mükemmel olmak zorunda değildir. Ama pazarlığı \"hissediyoruz\" seviyesinden \"desen görüyoruz\" seviyesine taşır. Teknik borç için ne zaman tam çözüm, ne zaman ara katman? Kıdemli mühendisliğin fark yarattığı yerlerden biri de budur. Her problem tam yeniden yazım gerektirmez. Bazen en doğru hareket geçici ama kontrollü bir ara katman kurmaktır: Kırılgan entegrasyon için idempotent retry katmanı Dağınık log yapısı için ortak şema zenginleştirme katmanı Zayıf erişim modeli için kısa ömürlü yetki koridoru Kaotik release süreci için daraltılmış değişiklik kontratı Bu ara çözümler, borcu inkâr etmek için değil, büyük dönüşüm için güvenli zaman kazanmak için kullanılmalıdır. Mentorluk boyutu neden önemli? Çünkü genç mühendisler çoğu zaman teknik borcu ya tamamen görmez ya da görünce her şeyi acil kabul eder. Kıdemli mühendis burada örnek olur. Borcu nasıl tarif ettiğiniz, neyi ölçtüğünüz ve neyi şimdilik kabul ettiğiniz ekipte standart oluşturur. Mentorluk şu davranışlarla görünür: Borç başlığını iş etkisiyle birlikte yazmak Tasarım görüşmelerinde \"gelecekteki operasyon maliyeti\" sorusunu sormak Refactor önerisini teslim planından koparmadan anlatmak \"Şimdi düzeltmiyoruz\" kararını da gerekçeli almak Bu disiplin, teknik olgunluğu bireysel sezgiden ekip pratiğine taşır. Sonuç Kıdemli mühendisler için teknik borç pazarlığı çerçevesi, daha yüksek sesle şikâyet etmek değil; daha isabetli karar zemini kurmaktır. Teknik borcu risk, akış ve maliyet diliyle görünür kıldığınızda; ürün, platform ve yönetim katmanlarıyla daha gerçekçi anlaşmalar yapabilirsiniz. İyi kıdemli mühendislik biraz da budur: her teknik gerçeği doğru teknik olmayan dile çevirebilmek.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "teknik-borc",
        "incident-management",
        "mentorluk"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-blameless-escalation-cercevesi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-blameless-escalation-cercevesi",
      "title": "Teknik Liderler İçin Blameless Escalation Çerçevesi",
      "summary": "Escalation kararlarını kişisel reflekslerden çıkarıp net eşiklerle yöneten blameless liderlik çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin blameless escalation cercevesi diagram.svg'; Birçok kurumda escalation kelimesi hâlâ başarısızlık çağrışımı taşıyor. Bir ekip başka bir ekibi sürece dahil ettiğinde, konuşma çoğu zaman teknik riski küçültmekten çok \"neden daha erken fark edilmedi\" tartışmasına kayıyor. Bu kültürün doğal sonucu, ekiplerin yardım istemeyi geciktirmesi oluyor. Teknik lider için asıl iş, escalation kararını kişilerden bağımsızlaştırmak ve bunu blameless bir çalışma kuralına dönüştürmektir. <figure <Image src={diagram} alt=\"Blameless escalation eşikleri, roller ve karar akışını gösteren teknik şema\" / <figcaption Sağlıklı escalation kültürü, zayıflık itirafı değil riskin doğru seviyede paylaşılmasıdır.</figcaption </figure Blameless escalation neden ayrı bir liderlik konusu? Çünkü incident yönetimindeki en pahalı gecikmeler genellikle teknik karmaşıklıktan değil, sosyal friksiyondan çıkar. Ekip sinyalin büyüdüğünü görür ama başka bir ekibi çağırmak için çok bekler. Bunun nedeni çoğu zaman yeterli telemetry değil, \"erken çağırırsam panik yaratmış olur muyum\" endişesidir. Blameless çerçeve bu belirsizliği azaltır. Escalation kararı kişisel cesarete veya kıdeme değil, önceden tanımlanmış eşiklere dayanır. Böylece süreç, yardım isteme psikolojisini değil, risk paylaşım disiplinini yönetir. Hangi eşikler önceden tanımlanmalı? Ben sahada dört eşiğin açık yazılmasını çok değerli buluyorum: Müşteri etkisi başladıysa ya da başlamak üzereyse Runbook dışı adım gerektiren teknik belirsizlik oluştuysa Tek ekip içinde çözülemeyecek bağımlılık açığa çıktıysa Müdahale süresi hizmet hedefini tehdit etmeye başladıysa Bu maddeler basit görünür; ama net yazılmadığında her ekip kendi toleransına göre davranır. Sonuçta aynı risk seviyesinde iki farklı tepki doğar. Suçlayıcı olmayan süreç pratikte nasıl kurulur? İlk kural şudur: escalation, \"hata yaptık\" cümlesinin kurumsal karşılığı değildir. Daha doğru cümle, \"risk artık daha geniş koordinasyon gerektiriyor\" olmalıdır. Bu dil farkı küçüktür ama müdahale hızını doğrudan etkiler. İkinci kural, sürecin toplantı anında icat edilmemesidir. Rollerin baştan belirlenmesi gerekir: 1. Olay komutası kimde kalır? 2. Hangi ekipler hangi sırayla çağrılır? 3. Kim teknik karar kaydını tutar? 4. Kim dış iletişim özetini üretir? Bu netlik yoksa escalation, çözüm hızlandıran mekanizma olmaktan çıkıp kaotik bir yayın listesine döner. <Callout type=\"tip\" title=\"Yardım istemek için kusur kanıtı beklemeyin\" Escalation eşiği ancak kesin kök neden bulunduğunda çalışıyorsa çok geç çalışıyor demektir. İyi liderlik, belirsizliğin büyüdüğü anda koordinasyonu genişletir. </Callout Teknik liderin dili neden belirleyici? Teknik liderler olay anında sadece karar vermez; olayın nasıl hissedildiğini de belirler. \"Neden daha önce haber vermediniz?\" sorusu birkaç saniyede tüm kültürü zehirleyebilir. Bunun yerine şu sorular daha sağlıklıdır: Hangi sinyal bu eşiği geçti? Şu anda hangi bağımlılık bizi yavaşlatıyor? Hangi uzmanlık eksik olduğu için kapsamı genişletiyoruz? Bu yaklaşım, kişileri değil sistemi görünür kılar. Özellikle kıdemli mühendisler için bu dil modeli mentorluk etkisi de üretir; genç mühendisler yardım istemenin kariyer riski olmadığını görür. Escalation sonrası hangi kayıtlar tutulmalı? Blameless kültürün kalıcı olması için süreç sonrasında üç kayıt mutlaka oluşmalıdır: Eşik gerçekten doğru yerde mi tetiklendi? Daha erken tetiklenebilseydi ne değişirdi? Hangi runbook, alarm veya sahiplik boşluğu bu ihtiyacı doğurdu? Burada amaç savunma hazırlamak değil, eşikleri zamanla iyileştirmektir. Aksi halde ekipler aynı tartışmayı sonraki olayda tekrar yaşar. Kurumsal yapılarda en sık görülen anti pattern Bazı kurumlar escalation matrisini çok ayrıntılı yazar ama gerçek hayatta kimsenin açıp okuyamayacağı kadar ağır hâle getirir. Bazıları ise tamamen sezgiye bırakır. İki uç da sorunludur. İyi model, birkaç net eşik ve birkaç net rol üzerinden çalışır. Bir başka hata da escalation'ı yalnızca kritik olaylara ayırmaktır. Oysa orta şiddette tekrar eden olaylar için erken koordinasyon kurulmazsa aynı desen ileride daha pahalı patlar. Teknik liderin görevi sadece yangın anında bağırmak değil, koordinasyonun geç kalma maliyetini düşürmektir. Sonuç Teknik liderler için blameless escalation çerçevesi, incident yönetiminin iletişim katmanını olgunlaştırır. Eşikler açık, roller net ve dil suçlayıcı değilse ekipler daha erken yardım ister, daha sakin karar alır ve bilgi daha düzenli akar. Kurumsal ölçekte gerçek hız, kahramanlıktan değil doğru anda doğru kişileri devreye sokan güvenli süreçlerden çıkar.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "incident-management",
        "mentorluk",
        "operasyon-kulturu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-aktif-aktif-entegrasyon-koridoru",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-aktif-aktif-entegrasyon-koridoru",
      "title": "ERP Altyapılarında Aktif-Aktif Entegrasyon Koridoru",
      "summary": "ERP çekirdeğini zorlamadan, entegrasyon katmanını aktif-aktif çalıştırmak için dayanıklılık ve tutarlılık odaklı mimari yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda aktif aktif entegrasyon koridoru diagram.svg'; Kurumsal ERP sistemlerinde aktif aktif mimari konuşulduğunda tartışma çoğu zaman doğrudan çekirdeğe gider: veritabanı nasıl çoğalacak, finansal işlemler nasıl sıralanacak, lisans modeli bunu kaldıracak mı? Oysa pratikte daha uygulanabilir alan çoğu zaman entegrasyon katmanıdır. ERP çekirdeğini tek yazım otoritesi olarak koruyup, çevresindeki entegrasyon koridorunu aktif aktif tasarlamak hem dayanıklılığı artırır hem de kurumsal dönüşümü daha yönetilebilir hâle getirir. <figure <Image src={diagram} alt=\"ERP çekirdeği ile iki bölgeli entegrasyon koridoru arasındaki aktif aktif akışı gösteren teknik şema\" / <figcaption Aktif aktif olmak her katmanı çift yazarlı yapmak değil; doğru katmanda paralel kapasite kurmaktır.</figcaption </figure Neden çekirdek yerine entegrasyon koridoru? Çünkü ERP çekirdeği çoğu kurumda sıkı tutarlılık, lisans kısıtı ve operasyon alışkanlığı nedeniyle zor hareket eder. Buna karşılık entegrasyon katmanı daha esnek davranabilir: API gateway Mesaj kuyruğu Dönüşüm servisleri Olay yönlendirme katmanı Partner bağlantı adaptörleri Bu koridor aktif aktif çalıştığında tek bölge kaybı, partner trafiği ve iç sistem çağrıları için daha düşük kesinti etkisi üretir. ERP çekirdeği ise kontrollü failover ya da tek yazar modelinde kalabilir. Aktif aktif koridorun ana ilkesi nedir? Ben bu tip yapılarda şu ilkeyi kritik görüyorum: işlemi değil teslimatı çoğaltın . Yani her iki bölge aynı anda mesaj kabul edebilir, doğrulama yapabilir ve sıraya alabilir; ancak ERP üzerinde etkili yazım davranışı belirli tutarlılık kurallarıyla sınırlandırılır. Bu ayrım sayesinde: Uç sistemler tek bölgeye bağımlı kalmaz Trafik yükü iki tarafa da dağılabilir Kuyruk ve dönüşüm katmanları yatay ölçeklenir Çekirdekteki tutarlılık baskısı kontrol altında tutulur Hangi riskler baştan çözülmeli? Aktif aktif koridor kurmak yalnızca yük dengeleyici eklemek değildir. Özellikle şu konular mimarinin merkezinde olmalıdır: 1. İdempotent işlem anahtarları 2. Bölge bağımsız sıra kimliği 3. Gecikmiş teslimat toleransı 4. Dead letter ve karantina akışı 5. Geri oynatma sınırları Eğer aynı sipariş, tahsilat ya da stok hareketi iki bölgeden farklı zamanlarda gelebiliyorsa; entegrasyon koridorunun görevi yalnızca taşıma değil, tekrarları güvenle absorbe etmektir. <Callout type=\"tip\" title=\"Aktif aktif eşittir çift çalıştırma değildir\" Aynı işlemi iki yerde paralel yürütmek çoğu zaman veri problemi üretir. Sağlam yaklaşım, kabul ve hazırlama katmanını aktif aktif; nihai yazımı kontrollü tasarlamaktır. </Callout Trafik yönlendirme modeli nasıl olmalı? İyi bir modelde kuzey güney trafik ile doğu batı senaryoları ayrılır. Partner ve iç servisler bölgesel ingress noktalarına en yakın yoldan gelir. Bu girişlerde: Kimlik doğrulama Şema kontrolü Temel rate limit Korelasyon kimliği üretimi Kuyruğa güvenli teslim işlemleri yapılır. Sonraki adımda mesajlar ya doğrudan aktif ERP bölgesine ya da tutarlılık kurallarını bilen entegrasyon orkestrasyon katmanına aktarılır. Bu yapı, network ve uygulama ekipleri arasında net bir sorumluluk sınırı da sağlar. Gözlemlenebilirlik neden bu kadar kritik? Çünkü aktif aktif koridorda \"sistem ayakta\" cümlesi yeterli değildir. Asıl sorular şunlardır: Hangi bölge ne kadar trafik aldı? Tekrarlı teslimatlar hangi oranda arttı? Karantina kuyruğuna hangi partner düştü? ERP yazımı hangi bölgede yavaşladı? Replay sonrasında veri tutarsızlığı oluştu mu? Dolayısıyla telemetri modeli iş anahtarı, bölge, adaptör tipi ve teslimat sonucu etiketlerini taşımalıdır. Aksi halde dayanıklılık tasarımı operasyon anında okunamaz. Bu mimari ne zaman mantıklı değildir? Bazı kurumlarda entegrasyon hacmi düşüktür, partner sayısı azdır ve tek bölge kesintisi tolere edilebiliyordur. Bu durumda aktif aktif koridor gereksiz karmaşa olabilir. Ayrıca ERP çekirdeği idempotent olmayan yan etkileri yoğun biçimde tetikliyorsa, önce işlem kontratlarını temizlemek gerekir. Yani aktif aktif koridor bir moda değil, belirli koşullara verilen cevaptır: Çok sayıda dış sistem varsa Bölgesel kesinti riski ciddiyse İş sürekliliği baskısı yüksekse Entegrasyon trafiği ERP'den daha hızlı büyüyorsa Sonuç ERP altyapılarında aktif aktif entegrasyon koridoru, çekirdeği zorlamadan yüksek erişilebilirlik kazanmanın pratik yollarından biridir. Doğru tasarlandığında kabul, kuyruklama ve dönüşüm katmanlarını iki bölgede ölçekler; çekirdek ERP tarafında ise kontrollü tutarlılık modelini korur. Kurumsal mimaride asıl ustalık, her katmana aynı yüksek erişilebilirlik desenini dayatmak değil; hangi katmanın ne kadar çoğalacağını doğru seçmektir.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "integration",
        "architecture",
        "resilience",
        "cloud"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-backbone-kapasite-planlama-modeli",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-backbone-kapasite-planlama-modeli",
      "title": "Kurumsal Ağlarda Backbone Kapasite Planlama Modeli",
      "summary": "Underlay ve servis trafiğini birlikte okuyarak omurga kapasitesini büyüme öncesinde yöneten mimari model.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal aglarda backbone kapasite planlama modeli diagram.svg'; Kurumsal ağlarda kapasite problemi çoğu zaman bağlantı doygunluğundan önce görünmez bir davranış değişimi olarak başlar. Yedek hat devreye girer, east west akışları farklı yollara kayar, backup penceresi uzar ve latency önce küçük sıçramalar üretir. Buna rağmen birçok ekip backbone kapasitesini hâlâ \"arayüz kullanım yüzdesi\" seviyesinde izler. Oysa omurga planlaması yalnızca bant genişliği değil, trafik sınıfı, büyüme paterni ve dayanıklılık senaryosu birlikte okunarak yapılmalıdır. <figure <Image src={diagram} alt=\"Backbone bağlantıları, kapasite eşikleri ve trafik katmanlarını gösteren teknik şema\" / <figcaption Backbone kapasitesi, tek bir port grafiğinden değil servis, replikasyon ve yedek hat davranışlarının birleşiminden okunur.</figcaption </figure Neden klasik yüzde bazlı izleme yetersiz? Çünkü omurga hatları çoğu zaman düzenli ve tek biçimli trafik taşımaz. Gündüz saatlerinde uygulama trafiği, gece backup ve replikasyon, kriz anında ise failover akışları dominant hâle gelir. Aynı ortalama kullanım değeri üç farklı risk anlamına gelebilir. Bu yüzden kapasite planlamasının ilk adımı, trafikteki ana sınıfları ayırmaktır: Kullanıcı ve uygulama trafiği Veri replikasyonu ve batch kopyalama Yönetim ve gözlemlenebilirlik akışı Felaket anında devreye girecek yedekleme yolları Sadece toplam Mbps bakıldığında bu katmanlar birbirini gizler. Sağlıklı model hangi girdilerle kurulur? Ben omurga kapasite planlamasında dört veri kaynağını birlikte okumayı faydalı buluyorum: 1. P95 ve P99 arayüz kullanımı 2. Trafik sınıfı bazında zaman dilimi deseni 3. Failover veya bakım anındaki alternatif yol yükü 4. İş büyümesiyle ilişkili hacim sürücüleri Özellikle üçüncü madde kritiktir. Çünkü birçok ağ tasarımı normal koşulda rahat görünür ama tek uplink kaybında bir anda darboğaz üretir. Omurga planlaması yalnızca mutlu gün grafiğiyle yapılamaz. Kapasite eşiği nasıl tanımlanmalı? Kurumlar genelde yüzde 70 veya yüzde 80 gibi tek eşiklerle hareket eder. Bu pratik ama eksiktir. Daha iyi yöntem, trafik sınıfına göre üç eşik tanımlamaktır: Normal çalışma eşiği Bakım ve yeniden yönlenme eşiği Acil durum taşıma eşiği Örneğin veri merkezi omurgasında gündelik kullanım yüzde 45 iken, tek spine kaybında yüzde 78'e çıkılıyorsa sistem bugün sağlıklı ama büyüme açısından kırılgandır. Bu ayrım yapılmadığında yatırım hep geç kalır. <Callout type=\"tip\" title=\"Büyüme hızını iş sinyaliyle bağlayın\" Backbone yatırımını sadece SNMP grafiklerine bakarak savunmak zayıf kalır. ERP batch hacmi, yeni şube açılışı veya log taşıma artışı gibi iş sürücülerini modele bağlayın. </Callout Observability katmanı neden doğrudan etkili? Çünkü kapasite planlaması geçmişin raporu değil, geleceğin uyarısıdır. NetFlow, sFlow, queue drop, interface error ve latency ölçümleri tek tabloda okunmuyorsa, problem ancak kullanıcı etkisi oluştuğunda görünür. Özellikle şu sinyaller birlikte ele alınmalıdır: Aynı yol üzerinde büyüyen mikroburst davranışı Queue discard ile artan uygulama timeout ilişkisi Failover testleri sırasında route değişimi ve throughput farkı Backup ve observability akışlarının çakıştığı saatler Bu görünürlük yoksa kapasite sorunu ağ ekibinin değil tüm platformun geç fark ettiği bir darboğaza dönüşür. Kurumsal mimaride karar anı nasıl gelir? Yatırım kararı vermek için portun tam dolması beklenmemelidir. Daha doğru yaklaşım, belirli senaryolarda taşıma emniyet payının nereye indiğini görmek ve bunun üzerine karar vermektir. Ben şu soruları etkili buluyorum: Tek uplink kaybında hangi iş yükü ilk önce bozulur? Önümüzdeki iki çeyrekte hangi proje trafiği kalıcı artırır? QoS tanımı gerçekten kritik akışları koruyor mu? Yeni kapasite mi, daha iyi trafik ayrıştırması mı daha doğru yatırım? Bu sorular omurga planlamasını cihaz sayısından çıkarıp mimari karar seviyesine taşır. Sonuç Kurumsal ağlarda backbone kapasite planlama modeli, yalnızca arayüz grafiği okumak değildir. Trafik sınıflarını, failover davranışını, iş büyümesini ve observability sinyallerini aynı çerçevede topladığınızda yatırım kararları daha erken ve daha savunulabilir hâle gelir. Omurga tasarımında gerçek dayanıklılık, link dolduktan sonra değil dolmadan önce doğru modeli kurduğunuz anda başlar.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "sistem-mimarisi",
        "kapasite-planlama",
        "observability",
        "kurumsal-teknoloji"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-finops-guardrail-katmani",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-finops-guardrail-katmani",
      "title": "Kurumsal Bulutta FinOps Guardrail Katmanı",
      "summary": "Bulut maliyetini sonradan raporlamak yerine politika, etiket ve yaşam döngüsü kurallarıyla baştan sınırlayan mimari yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal bulutta finops guardrail katmani diagram.svg'; Kurumsal bulutta maliyet disiplini çoğu ekipte ay sonu raporuyla başlar. Fatura büyür, dashboard açılır, birkaç büyük kaynak bulunur ve ardından tasarruf kampanyası başlar. Bu yaklaşım her zaman geç kalır. Çünkü maliyetin önemli kısmı kötü niyetli harcamadan değil, varsayılanların gevşekliğinden doğar. FinOps guardrail katmanı, bütçeyi raporlayan bir ekip fonksiyonu değil; provisioning anında davranış şekillendiren bir mimari kontrol yüzeyi olarak ele alınmalıdır. <figure <Image src={diagram} alt=\"Bulut hesapları, maliyet politikaları ve guardrail katmanını gösteren teknik şema\" / <figcaption Maliyet kontrolü en iyi raporda değil, kaynağın doğduğu anda çalışan guardrail katmanında etkili olur.</figcaption </figure Guardrail katmanı neden gerekli? Çünkü maliyetin büyük bölümü tek tek pahalı kaynaklardan değil, zamanla çoğalan küçük ihlallerden birikir. Etiketsiz kaynaklar, sınırsız retention, unutulan test ortamları, yanlış instance ailesi ve gereksiz veri çıkışı maliyeti sessizce büyütür. Bu yüzden FinOps yaklaşımı yalnızca görünürlükle sınırlı kalmamalıdır. Aşağıdaki kurallar provisioning seviyesine gömülmelidir: Zorunlu etiket ve sahiplik bilgisi Ortam bazlı yaşam süresi sınırı Bölge ve servis türü için izinli liste Varsayılan retention ve snapshot politikası Egress ve veri kopyalama için bütçe eşiği Bu kurallar yoksa ekipler aynı hataları iyi niyetle tekrar eder. Hangi katmanda uygulanmalı? Ben guardrail katmanını üç seviyede düşünmeyi faydalı buluyorum: 1. Self service şablonlar ve golden path 2. IaC policy kontrolleri 3. Çalışan ortam için sürekli maliyet anomali denetimi Sadece üçüncü katman varsa kurum olay sonrası yorum yapar. Sadece birinci katman varsa istisnalar büyür. Üçü birlikte çalıştığında maliyet kontrolü hem önleyici hem düzeltici olur. Teknik ekipler neden buna direnebiliyor? Çünkü maliyet kısıtı çoğu zaman dışsal bir iş baskısı gibi sunuluyor. Oysa doğru anlatım şudur: FinOps guardrail, hız düşüren onay süreci değil; tekrar eden yanlış seçimleri otomatik durduran bir emniyet katmanıdır. İyi örneklerde geliştirici şu deneyimi yaşar: Uygun instance ailesi zaten varsayılan gelir Geçici ortamlar otomatik sonlanır S3 benzeri depolamada retention sınıfı önceden atanır Yüksek egress veya pahalı disk tipi için bilinçli onay gerekir Bu model, maliyeti manuel uyarıdan çıkarıp sistem davranışına dönüştürür. <Callout type=\"tip\" title=\"Maliyet kuralı teknik borcu azaltabilir\" Doğru guardrail yalnızca fatura düşürmez. Sahipsiz kaynakları, gereksiz veri kopyalarını ve yaşam döngüsü belirsizliğini de azaltır. </Callout Observability ve güvenlikle nasıl birleşir? Kurumsal yapılarda maliyet kuralları tek başına yaşamaz. Bir retention sınırı güvenlik kayıt ihtiyacıyla çelişebilir; bir egress sınırı replikasyon stratejisini etkileyebilir. Bu yüzden FinOps guardrail seti şu ekiplerin ortak diliyle yazılmalıdır: Platform ve bulut mimarisi Güvenlik ve uyumluluk Operasyon ve gözlemlenebilirlik Ürün veya iş yükü sahipleri Bu ortaklık kurulmazsa maliyet disiplini ya çok sert olur ya da tamamen etkisiz kalır. Hangi metrikler gerçekten anlamlı? Ben guardrail başarısını sadece toplam fatura ile ölçmeyi zayıf buluyorum. Daha iyi sinyaller şunlardır: Sahipsiz kaynak oranı Otomatik sonlanan geçici ortam sayısı Politika nedeniyle engellenen yüksek maliyetli değişiklik oranı Birim iş yükü başına maliyet eğilimi Sonradan temizlenen kaynak yerine baştan önlenen ihlal oranı Bu tablo, kontrol mekanizmasının raporlama mı yoksa davranış şekillendirme mi yaptığını açık gösterir. Sonuç Kurumsal bulutta FinOps guardrail katmanı, bütçe savunusunu aylık sunumdan çıkarıp platform mimarisine yerleştirir. Etiket, yaşam döngüsü, servis seçimi ve veri hareketi kuralları provisioning anında çalıştığında maliyet disiplini daha az tartışma, daha çok varsayılan davranış üretir. Gerçek olgunluk, faturayı görünce paniklemek değil; pahalı davranışı oluşmadan önce engelleyebilmektir.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "cloud",
        "finops",
        "guardrail",
        "devops",
        "kurumsal-teknoloji"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-yonetim-duzlemi-karantina-hesabi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-yonetim-duzlemi-karantina-hesabi",
      "title": "Kurumsal Bulutta Yönetim Düzlemi Karantina Hesabı",
      "summary": "Yönetim servislerini üretim kaynaklarından ayırmak için cloud ortamında karantina hesabı yaklaşımını ve sınırlarını ele alan mimari rehber.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal bulutta yonetim duzlemi karantina hesabi diagram.svg'; Kurumsal cloud mimarilerinde kimlik, log, ağ ve otomasyon katmanları büyüdükçe kritik bir soru ortaya çıkar: yönetim düzlemini üretim kaynaklarından gerçekten ne kadar ayırdık? Birçok kurum \"management account\" açtığını düşünür; fakat bu hesap aynı CI anahtarlarını, aynı IAM rollerini ve aynı ağ çıkış kurallarını paylaşıyorsa ayrım büyük ölçüde teorik kalır. Daha güvenli yaklaşım, yönetim düzlemi için kontrollü ve sıkılaştırılmış bir karantina hesabı tasarlamaktır. <figure <Image src={diagram} alt=\"Yönetim hesabı, üretim hesapları ve güvenlik denetim katmanını ayıran bulut mimarisini gösteren teknik şema\" / <figcaption Yönetim hesabı ayrı bir klasör değil, ayrı güven varsayımları gerektiren bir kontrol zonudur.</figcaption </figure Karantina hesabı neyi amaçlar? Amaç yönetim servislerini merkezileştirmek değildir; onların patlama yarıçapını küçültmektir. Özellikle şu bileşenler bu hesaba adaydır: IAM otomasyonu Merkezi denetim logları Policy as code yürütücüleri Güvenlik tarama orkestrasyonu Break glass ve acil erişim kasaları Bu bileşenler doğrudan üretim hesaplarında çalıştığında tek bir anahtar sızıntısı veya yanlış rol zinciri, tüm platform üzerinde kontrol kaybına yol açabilir. Neden mevcut shared services hesabı yetmeyebilir? Çünkü shared services hesabı genelde kolaylık odaklı büyür. CI, artefact repo, gözlemlenebilirlik ajanları ve platform servisleri aynı yerde toplanır. Bu yaklaşım operasyonu hızlandırabilir; ancak güven sınırı açısından sorunludur. Karantina hesabı ise tersine şu prensiple kurulur: Daha az insan erişimi Daha kısa ömürlü oturum Daha dar ağ çıkışı Daha güçlü denetim kayıtları Daha yavaş ama kontrollü değişiklik akışı Yani amaç konfor değil, güvenli kontrol noktası oluşturmaktır. Temel tasarım kararları neler? Ben bu mimaride dört kararın kritik olduğunu görüyorum: 1. Tek yönlü yönetim akışı : Yönetim hesabı üretim hesaplarına komut gönderebilir; ters yön sınırlı olmalıdır. 2. Ayrı kimlik yolu : İnsan erişimi ile makine erişimi aynı role zincirlenmemelidir. 3. Bölgesel kayıt koruması : Audit log'lar yalnızca tek bölgeye bağlı kalmamalıdır. 4. Acil durum istisnası : Break glass erişim normal akıştan ayrı kasada tutulmalıdır. Bu kararlar alınmadan açılan her \"management account\", güvenli görünse de pratikte başka bir shared account'a dönüşür. <Callout type=\"tip\" title=\"En kritik rol: yönetim hesabına kim yönetici olabilir?\" Eğer üretim yöneticisi aynı kolaylıkla karantina hesabı yöneticisi de olabiliyorsa güven sınırı kağıt üzerinde kalır. Ayrım rol zincirinde başlamalıdır. </Callout Ağ ve erişim sınırı nasıl kurulmalı? Karantina hesabının internet çıkışı, artefact erişimi ve üretim hesaplarıyla konuşma kuralları olabildiğince dar olmalıdır. Özellikle şu kontroller faydalıdır: Sadece onaylı egress hedefleri Ayrı DNS çözümleme politikası Yönetim araçları için kısa ömürlü erişim oturumları İnteraktif erişim yerine kayıtlı otomasyon akışı Her role için zorunlu gerekçe veya ticket bağlamı Bu yaklaşım operasyonu biraz yavaşlatır, fakat yanlışlıkla tüm organizasyona yayılan etkiyi ciddi biçimde azaltır. Platform ekipleri için bedeli nedir? Her güvenli mimarinin operasyon maliyeti vardır. Karantina hesabı da istisna değildir. Daha fazla rol ayrımı, daha fazla onay akışı ve daha sıkı ağ kuralı gerektirir. Fakat bu maliyet özellikle çok hesaplı veya regülasyon baskısı altındaki yapılarda mantıklıdır. Çünkü yönetim düzleminin ele geçirilmesi, tek uygulama hesabı ihlalinden çok daha geniş etki üretir. Burada önemli olan, karantina hesabını her şeyi içine alan yeni bir merkez değil, sadece kritik kontrol fonksiyonlarının yaşadığı sınırlı bir alan olarak tutmaktır. Sonuç Kurumsal bulutta yönetim düzlemi karantina hesabı, güvenlik ekibi için ekstra bir katılık değil; platform riskini mühendislik seviyesinde sınırlandırma yöntemidir. Yönetim servisleri ayrı kimlik, ayrı ağ ve ayrı denetim varsayımlarıyla işletildiğinde; üretim hesaplarında oluşan hatalar veya sızıntılar doğrudan tüm organizasyon kontrolüne sıçramaz. Modern cloud mimarisinde gerçek olgunluk bazen daha fazla servis eklemekten değil, en kritik servisleri daha az güven varsayımıyla çalıştırmaktan geçer.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "cloud",
        "security",
        "architecture",
        "platform",
        "governance"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/cosign-ile-container-supply-chain-imzalama-rehberi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/cosign-ile-container-supply-chain-imzalama-rehberi",
      "title": "Cosign ile Container Supply Chain İmzalama Rehberi",
      "summary": "Container imajlarını Cosign ile imzalayıp dağıtım hattında doğrulamak için pratik ve kurumsal uyumlu kurulum rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Container tabanlı platformlarda güvenlik tartışması çoğu zaman runtime tarafında başlıyor. Ancak zincirin daha erken halkalarında neyin üretildiği, kimin ürettiği ve dağıtıma neyin girdiği yeterince net değilse runtime korumaları tek başına yeterli olmaz. Cosign, container imajına kimlik ve bütünlük katmanı ekleyerek supply chain güvenliğini daha uygulanabilir hâle getirir. Bu rehberde imajı imzalama, doğrulama ve dağıtım kapısına bağlama adımlarını sade bir akışta kuracağız. Hedef mimari Amaç şu zinciri kurmak: 1. CI pipeline imajı üretir 2. İmaj registry'ye push edilir 3. Cosign imzayı üretir ve registry yanında saklar 4. Dağıtım öncesi admission veya pipeline adımı imzayı doğrular Bu model sayesinde sadece \"image tag var mı\" değil, \"bu imaj güvenilir üretim hattından mı çıktı\" sorusu cevaplanır. Cosign kurulumu Yerel test için araç kurulumu yeterlidir: Kurumsal kullanımda iki yaklaşım yaygındır: keyless: OIDC tabanlı, CI kimliği ile imzalama key pair: Özel anahtar ve şifre ile imzalama Mümkünse keyless yaklaşımı daha sürdürülebilirdir. Anahtar döndürme ve saklama yükünü azaltır. Örnek imaj üretimi ve imzalama Basit bir imaj oluşturalım: Anahtar çiftiyle imzalamak için: Bu komut imzayı registry tarafında ilgili artifact ile ilişkilendirir. İmajı yeniden etiketlemek ile içeriği değiştirmek aynı şey değildir; bu yüzden üretim akışında digest bazlı çalışma tercih edilmelidir. Doğrulama adımı İmajı doğrulamak için: Çıktıda sertifika veya imza bilgisi döner. Buradaki kritik nokta, yalnızca imzanın varlığı değil, beklediğiniz kimlik veya anahtarla uyumlu olmasıdır. Aksi hâlde herhangi bir imza sahte güven üretebilir. Bir CI kapısı örneği: Bu yaklaşım deployment öncesi digest ve imza ilişkisinin net kalmasını sağlar. <Callout type=\"tip\" title=\"Tag yerine digest ile ilerleyin\" İmzalı bir etiketi sonradan başka digest'e taşımak operasyonel karışıklık yaratır. Dağıtım kapısında digest bazlı doğrulama daha güvenlidir. </Callout Kubernetes dağıtım hattına bağlama En basit model, deploy job içinde doğrulama yapmaktır. Daha güçlü model ise admission katmanında imzasız imajı reddetmektir. Örnek akış: CI imajı üretir ve imzalar GitOps veya deployment pipeline yalnızca doğrulanan digest'i geçirir Admission policy imzasız ya da yanlış kimlikli artifact'i engeller Bu sayede insan hatasıyla yanlış registry ya da test imajı üretime kaçma ihtimali ciddi biçimde azalır. Kurumsal kullanımda ek kontroller Cosign tek başına tüm supply chain güvenliğini çözmez. Ben şu tamamlayıcı adımları öneriyorum: SBOM üretimi ve artifact ile ilişkilendirme Build ajanı kimliğini OIDC ile sınırlandırma İmzalama yetkisini yalnızca üretim pipeline'ına verme Registry tarafında yetkisiz overwrite davranışını kapatma Bu çerçeve, imzayı dekorasyon olmaktan çıkarıp gerçek kontrol katmanına dönüştürür. Sonuç Cosign ile container supply chain imzalama, dağıtıma giden artifact'in kimliğini görünür kılar. İmajı üretmek, push etmek ve imzalamak aynı zincirin parçaları olarak çalıştığında güvenlik ekibi ile platform ekibi arasında ortak bir doğrulama dili oluşur. Sağlıklı başlangıç için küçük bir servis seçin, digest bazlı doğrulama kurun ve imzasız artifact'in üretime geçmesini sistematik olarak durdurun.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "cosign",
        "guvenlik",
        "devops",
        "container",
        "supply-chain"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/nftables-ile-cikis-trafigi-politika-katmani",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/nftables-ile-cikis-trafigi-politika-katmani",
      "title": "nftables ile Çıkış Trafiği Politika Katmanı",
      "summary": "Sunucuların dış dünyaya hangi hedeflere çıkabileceğini denetlemek için nftables tabanlı egress politika katmanının kurulumunu anlatan rehber.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './nftables ile cikis trafigi politika katmani diagram.svg'; Kurumsal Linux sunucularında güvenlik kuralları çoğu zaman inbound trafiğe odaklanır. Oysa veri sızıntısı, yanlış proxy kullanımı, kontrolsüz paket yükleme veya beklenmedik dış API çağrıları gibi pek çok risk çıkış trafiğinde görünür olur. Bu nedenle üretim sunucularında egress davranışını da açık politika ile yönetmek gerekir. nftables, bu iş için hem modern hem de okunabilir bir zemin sunar. <figure <Image src={diagram} alt=\"Sunucudan internete çıkan trafiği izinli hedeflere göre sınırlayan teknik şema\" / <figcaption Güvenlik yalnızca kimin içeri girdiğiyle değil, içeriden nereye çıkılabildiğiyle de ilgilidir.</figcaption </figure Egress kontrolü neden önemli? Şu senaryolar çok yaygındır: Paket yöneticisi yalnızca iç mirror'a gitmelidir Uygulama sadece belirli API sağlayıcılarına çıkmalıdır Log ve telemetry yalnızca kurumsal backend'lere gitmelidir Yönetim araçları internete açık olmamalıdır Bu kurallar ağ duvarında tanımlı olsa bile host seviyesinde ikinci kontrol katmanı kurmak özellikle hassas sistemlerde değerlidir. Örnek tasarım Bu rehberde şu yaklaşımı kuracağız: 1. Varsayılan olarak çıkış trafiğini reddet 2. DNS, NTP ve iç mirror gibi zorunlu hedefleri izinli listeye al 3. Uygulama kullanıcısına özel ek hedefler tanımla 4. Loglama ile reddedilen akışları görünür kıl Önce /etc/nftables.conf içinde sade bir inet tablosu oluşturalım: Bu örnekte DNS ve NTP yalnızca iç hedeflere gider. HTTPS çıkışı ise izinli set ile sınırlandırılır. <Callout type=\"tip\" title=\"Alan adı değil, çözülmüş hedef davranışını yönetin\" Host firewall katmanında FQDN tabanlı düşünmek yanıltıcıdır. Önce çözümleme ve proxy tasarımını netleştirin, sonra izinli IP veya prefix setleriyle ilerleyin. </Callout Kuralları güvenli şekilde nasıl devreye alırsınız? Varsayılan drop politikasına doğrudan geçmeyin. Güvenli rollout için: 1. Önce log only zincir kurun 2. Birkaç saat gerçek trafiği izleyin 3. Eksik hedefleri tamamlayın 4. Sonra policy drop ile etkinleştirin Birçok ekip ilk denemede paket mirror, zaman sunucusu veya telemetry hedefini unutuyor. Bunun bedeli gereksiz operasyon gürültüsü oluyor. Operasyon tarafında hangi metrikler izlenmeli? Egress politikası kurulduktan sonra sadece kural varlığına değil davranışına bakın: Reddedilen bağlantı sayısı En çok reddedilen hedefler Uygulama kullanıcılarına göre dağılım Politika değişikliği sonrası hata oranı Bu veriler yoksa birkaç hafta sonra kural seti bir \"neden var bilmiyoruz\" dosyasına dönüşür. Sonuç nftables ile çıkış trafiği politika katmanı kurmak, sunucu güvenliğini ağ sınırının bir uzantısı hâline getirir. Doğru uygulandığında üretim host'larının nereye konuşabileceği netleşir, yanlış yönlendirilmiş trafik daha erken görünür ve veri sızıntısı yüzeyi daralır. Özellikle kurumsal altyapıda gerçek güvenlik, inbound kapıları kapatmak kadar outbound davranışı da niyetli hâle getirmekten geçer.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "network",
        "security",
        "linux",
        "nftables",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/opentelemetry-collector-ile-telemetri-filtreleme-katmani",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/opentelemetry-collector-ile-telemetri-filtreleme-katmani",
      "title": "OpenTelemetry Collector ile Telemetri Filtreleme Katmanı",
      "summary": "Metric, log ve trace akışında gereksiz hacmi azaltmak için OpenTelemetry Collector üzerinde filtreleme ve yönlendirme kurulumunu anlatan rehber.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './opentelemetry collector ile telemetri filtreleme katmani diagram.svg'; OpenTelemetry Collector kurulduktan sonra birçok ekip bir rahatlama yaşar: uygulamalar doğrudan backend'e bağlanmaz, veri akışı merkezî bir katmandan geçer. Fakat kısa süre içinde başka bir sorun görünür olur. Her şeyi toplamaya başlamak kolaydır; hangi sinyalin gerçekten gerekli olduğunu seçmek daha zordur. Filtreleme katmanı tam bu noktada devreye girer. Amaç veri kaybetmek değil, veri davranışını yönetmektir. <figure <Image src={diagram} alt=\"OpenTelemetry Collector üzerinde filtreleme ve yönlendirme katmanlarını gösteren teknik şema\" / <figcaption Collector yalnızca transit noktası değil, telemetri davranışının kontrol yüzeyidir.</figcaption </figure Filtreleme katmanı neden gerekli? Collector'ı yalnızca iletim ajanı gibi kullanırsanız birkaç hafta içinde şu sonuçlar oluşur: Gürültülü log akışları maliyeti yükseltir Düşük değerli trace span'leri analizi zorlaştırır Debug metriği üretimde kalıcı hâle gelir Hassas alanlar yanlış backend'lere taşınabilir Bu nedenle collector üzerinde karar verme sırası genelde şöyledir: 1. Tutulacak sinyali tanımla 2. Zenginleştirilecek alanları seç 3. Düşürülecek hacmi belirle 4. Hedef backend'leri ayır Örnek mimari Basit ama etkili bir yapı için tek collector pipeline'ını üç aşamada düşünebilirsiniz: Alım katmanı : OTLP, syslog veya agent çıkışları collector'a gelir Filtreleme katmanı : düşük değerli telemetry düşürülür, PII maskelenir Yönlendirme katmanı : sinyaller farklı backend'lere dağıtılır Bu model özellikle merkezi observability kullanan kurumsal yapılarda çok işe yarar. Örnek konfigürasyon Aşağıdaki örnek, health check span'lerini düşüren, belirli log alanlarını maskeleyen ve metric ile trace'i farklı hedeflere yönlendiren sade bir başlangıç verir: Bu örnek her senaryoya uymaz; ama filtrenin backend tarafında değil collector katmanında uygulanmasının neden önemli olduğunu gösterir. <Callout type=\"tip\" title=\"İlk kural: düşürdüğünüz şeyi ölçün\" Filtreleme kuralları sessiz veri kaybı üretmemelidir. Düşürülen span, log veya metrik sayısını ayrı sayaçlarla görünür tutun. </Callout Hangi sinyaller filtrelenmeli? Kural basit görünse de uygulaması zordur. Ben şu sıralamayı faydalı buluyorum: Yüksek hacimli health check ve readiness çağrıları Analize değer katmayan debug log alanları Regülasyon riski taşıyan hassas kimlik alanları Aynı bilgiyi tekrar eden düşük değerli event'ler Buna karşılık şu sinyalleri kolay kolay düşürmemek gerekir: Hata sınıfındaki span ve log'lar Kritik iş akışına ait transaction sinyalleri SLO hesabına giren metrikler Incident sonrası adli inceleme değeri taşıyan kayıtlar Rollout nasıl yapılmalı? Collector filtresini bir anda sertleştirmek risklidir. Güvenli sıralama şöyle olabilir: 1. Önce sadece sayaç üretin, düşürmeyin 2. Aday kuralları canary collector üzerinde deneyin 3. Bir backend'e tam akış, diğerine filtreli akış gönderin 4. Alarm ve dashboard kırılmalarını gözleyin 5. Sonra genel rollout yapın Bu yaklaşım, \"maliyeti düşürdük ama incident anında veri yok\" senaryosunu önler. Sonuç OpenTelemetry Collector ile telemetri filtreleme katmanı kurmak, gözlemlenebilirlik maliyetini kısmak için aceleci bir kırpma işi değildir. Doğru yapıldığında veri kalitesini artırır, güvenlik riskini azaltır ve backend'lere giden trafiği niyetli hâle getirir. Collector'ı sadece boru hattı olarak değil karar yüzeyi olarak gördüğünüzde, observability platformu daha sürdürülebilir bir yapıya dönüşür.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "opentelemetry",
        "collector",
        "telemetry",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/opentofu-ile-tenant-bazli-state-ayristirma-rehberi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/opentofu-ile-tenant-bazli-state-ayristirma-rehberi",
      "title": "OpenTofu ile Tenant Bazlı State Ayrıştırma Rehberi",
      "summary": "Kurumsal altyapıda tenant, ortam ve sahiplik sınırlarını korumak için OpenTofu state yapısını ayrıştıran pratik rehber.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; IaC kullanan ekipler ilk günlerde tek bir state dosyasıyla hızlı ilerler. Ancak kurum büyüdükçe farklı tenant'lar, farklı ortamlar ve farklı sahiplik sınırları aynı state içinde sıkışmaya başlar. Sonuç olarak küçük bir değişiklik gereksiz kilitlenme, geniş erişim yetkisi ve kırılgan plan çıktıları üretir. OpenTofu ile tenant bazlı state ayrıştırma yaklaşımı, yalnızca teknik düzen değil; yönetişim, güvenlik ve operasyon ölçeği için kritik bir sınır tanımıdır. Ne zaman tek state modelinden çıkmalısınız? Aşağıdaki sinyaller genellikle ayrıştırma ihtiyacını gösterir: Farklı ekipler aynı plan kilidine takılıyorsa Üretim ve test ortamı aynı state kökünde yaşıyorsa Bir tenant değişikliği başka tenant kaynaklarını listeletiyorsa Erişim izinleri state düzeyinde ayrılamıyorsa Bu durumlarda sorun çoğu zaman araç değil sınır modelidir. State yapısı, organizasyon yapısının ve güvenlik sınırlarının gerisinde kalmıştır. Referans klasör yapısı Sade ve okunabilir bir model şöyle olabilir: Buradaki amaç her klasörü farklı state yapmak değil; değişiklik frekansı, sahiplik ve etki alanına göre ayrım yapmaktır. Aynı yaşam döngüsünü paylaşmayan kaynakları tek state içinde tutmamak gerekir. Backend tanımını nasıl ayırmalı? OpenTofu tarafında state anahtarı tenant ve bileşen bazlı ayrılmalıdır. Basit bir S3 uyumlu backend örneği: Burada kritik olan şey sadece key alanı değil; lock ve erişim politikasının da aynı sınırı izlemesidir. Aksi hâlde dizin ayrılmış görünür ama yetki yüzeyi ayrılmaz. Ortak modüllerle tenant ayrımı birlikte nasıl yaşar? Birçok ekip şu hataya düşer: modüller ortaksa state de ortak kalmalı sanılır. Bu doğru değildir. Ortak modül kullanmak ile ortak state kullanmak farklı kararlardır. Doğru model şudur: Modül kodu ortak olabilir Değişken seti tenant'a özgü olur Backend ve lock alanı tenant sınırını izler Pipeline yetkisi yalnızca ilgili tenant state'ine erişir Bu ayrım sayesinde platform standardı korunur ama operasyon etkisi dar tutulur. <Callout type=\"tip\" title=\"Önce sınırı, sonra klasörü tasarlayın\" State ayrıştırma klasör estetiği işi değildir. Kimin plan çalıştırdığı, kimin kilit beklediği ve hangi değişikliğin kimi etkilediği sorularına göre sınır kurun. </Callout Pipeline tasarımında nelere dikkat edilmeli? Tenant bazlı yapı kurulduğunda CI/CD hattı da bunu takip etmelidir. Ben şu kuralları öneriyorum: 1. Her tenant bileşen çifti için ayrı plan job 2. Değişiklik olmayan tenant'lar için koşullu çalışma 3. Plan çıktısının ilgili sahip ekibe yönlendirilmesi 4. Üretim tenant'ları için ayrı onay ve rollout adımı Bu model hem paralellik üretir hem gereksiz kilitlenmeyi azaltır. Geçiş nasıl yapılmalı? Mevcut büyük state'i bir günde parçalamaya çalışmak risklidir. Daha güvenli yöntem kademeli taşımadır: Önce sınır matrisi çıkarılır En az bağımlı bileşen seçilir state mv veya import stratejisiyle yeni köke alınır İlk birkaç değişiklik gözlemlenerek lock ve yetki modeli doğrulanır Özellikle üretim ERP veya ağ katmanlarında bağımlılık haritası çıkarılmadan yapılan ayrıştırma yeni kırılganlık doğurur. Sonuç OpenTofu ile tenant bazlı state ayrıştırma, yalnızca teknik temizlik değildir. Yetki alanını daraltır, plan kilitlenmesini azaltır ve değişiklik etkisini okunabilir hâle getirir. Kurumsal altyapı büyüdükçe asıl hız tek büyük state'ten değil, doğru sınırlar içinde çalışan küçük ve sahipliği net state alanlarından gelir.",
      "date_published": "2026-04-09T00:00:00.000Z",
      "date_modified": "2026-04-09T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "opentofu",
        "infrastructure-as-code",
        "cloud",
        "devops",
        "otomasyon"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-karar-gunlugu-disiplini",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-karar-gunlugu-disiplini",
      "title": "Kıdemli Mühendisler İçin Karar Günlüğü Disiplini",
      "summary": "Mimari ve operasyon kararlarını kişisel hafızadan çıkarıp ekipçe taşınabilir hâle getiren karar günlüğü yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kidemli muhendisler icin karar gunlugu disiplini cover.svg'; Birçok kurumda mimari kararlar teknik dokümanlarda değil, birkaç kıdemli mühendisin zihninde yaşar. Neden o veritabanı seçildi, neden o servis ayrı VPC'ye taşındı, neden belirli bir alarm eşiği kabul edildi gibi soruların cevabı çoğu zaman toplantılarda dağılır ve zamanla buharlaşır. Sonra ekip değişir, sistem büyür ve aynı kararlar tekrar tekrar tartışılır. Karar günlüğü disiplini, teknik hafızayı kişisel otoriteden çıkarıp ekip tarafından taşınabilir bir işletim pratiğine dönüştürür. <figure <Image src={diagram} alt=\"Karar günlüğü, teknik bağlam ve operasyonel sonuç ilişkisini gösteren teknik şema\" / <figcaption Karar günlüğü, yalnızca “ne yaptık” sorusunu değil, “hangi varsayımla yaptık” sorusunu da korur.</figcaption </figure Karar günlüğü tam olarak neyi çözer? Bir ADR veya wiki sayfası yazmak tek başına yeni bir disiplin kurmaz. Buradaki asıl mesele, kritik kararların yaşam döngüsünü görünür hâle getirmektir: Kararın bağlamı neydi? Hangi alternatifler elendi? Hangi risk kabul edildi? Kararın yeniden gözden geçirilme koşulu ne? Bu sorular cevapsız kaldığında ekipler geçmiş kararları ya kutsal metin gibi korur ya da nedenini bilmeden bozmaya çalışır. İki uç da pahalıdır. Neden özellikle kıdemli mühendislik konusudur? Çünkü kıdem arttıkça senden sadece iyi çözüm değil, tekrar üretilebilir muhakeme beklenir. Genç mühendis bir problemi çözer; kıdemli mühendis ise o çözümün hangi bağlamda doğru olduğunu ekip için okunabilir kılar. Bu yüzden karar günlüğü, belgeleme alışkanlığından daha derin bir liderlik pratiğidir. İyi işlediğinde şu etkileri üretir: Yeni katılan mühendislerin bağlam kazanma süresi kısalır Aynı tartışmalar daha az tekrar eder Devir ve nöbet sırasında karar sınırları netleşir Postmortem ve mimari review daha verimli ilerler Hangi kararlar günlüğe girmeli? Her küçük tercih günlüğe yazılmaz. Günlük şişerse kimse okumaz. Ben şu tip kararları özellikle değerli buluyorum: 1. Geri dönmesi pahalı mimari seçimler 2. Güvenlik, ağ ve erişim modelini etkileyen kabuller 3. Operasyon davranışını değiştiren alarm, rollback veya yayın kuralları 4. Veri saklama, replikasyon ve yedekleme stratejileri 5. İstisna olarak kabul edilen geçici ama kritik çözümler Yani karar günlüğü, her toplantı notunun mezarlığı değildir. Kurumsal hafıza açısından pahalı düğüm noktalarının kaydıdır. <Callout type=\"tip\" title=\"Karar kaydı sonuç belgesi değil muhakeme kaydı olmalı\" “X teknolojisini seçtik” cümlesi tek başına zayıftır. Güçlü kayıt, seçimin hangi baskı altında yapıldığını ve hangi koşulda tekrar açılacağını da yazar. </Callout İyi bir kayıt nasıl görünür? Ben çok uzun formatları sürdürülebilir bulmuyorum. Pratikte aşağıdaki alanlar çoğu durumda yeterlidir: Başlık: Kararın kısa adı Tarih ve sahiplik Bağlam Alternatifler Kabul edilen risk Beklenen operasyon etkisi Yeniden gözden geçirme tetikleyicisi Buradaki son madde özellikle önemlidir. Çünkü birçok karar, sanki sonsuza kadar geçerliymiş gibi dokümante edilir. Oysa kurumsal altyapıda kararların çoğu çevresel koşullara bağlıdır. Trafik hacmi, ekip yapısı veya regülasyon değiştiğinde, doğru karar artık farklı olabilir. Operasyon tarafında en büyük kazanç nerede? Karar günlüğünün değeri yalnızca mimari toplantılarda değil, kesinti ve değişim anlarında görünür. Örneğin bir incident sırasında ekip şu soruya hızlı yanıt verebilmelidir: “Bu serviste neden agresif autoscaling yerine kapasite rezervi tercih ettik?” Cevap kişisel hafızadaysa risk büyür. Kayıtta ise müdahale hızı artar. Aynı şey değişim yönetiminde de geçerlidir: Neden belirli ağ segmenti kapalı tutuluyor? Neden rollout penceresi farklı? Neden bazı loglar uzun süre saklanıyor? Bu soruların cevabı görünür olduğunda ekip kararları daha sakin tartışır. Çünkü tartışma kişiler üzerinden değil varsayımlar üzerinden yürür. Mentorluk etkisi neden güçlü? Kıdemli mühendislik çoğu zaman görünmez düşünme biçimini öğretmektir. Karar günlüğü, bu görünmezliği kısmen görünür yapar. Yeni bir mühendis sadece son mimariyi değil, o mimariye giden muhakemeyi de okuyabilir. Bu, teknik öğrenmeyi ciddi biçimde hızlandırır. Ben özellikle şu kullanım biçimini faydalı buluyorum: Büyük karar öncesi taslak kayıt açılır Review sırasında alternatifler birlikte netleşir Karar çıktıktan sonra operasyon etkisi eklenir Birkaç ay sonra kısa değerlendirme notu düşülür Bu yöntem, dokümanı statik rapor olmaktan çıkarıp yaşayan karar geçmişine dönüştürür. En sık yapılan hata İlk hata, günlüğü yalnızca mimari ekiplerin işi sanmak. Oysa operasyon ve platform kararları da aynı ölçüde kritiktir. İkinci hata ise günlüğü çok ağır süreçle boğmaktır. Her karar için uzun onay mekanizması koyulduğunda ekipler kaydı bırakır, karar yine sohbet kanallarına döner. Doğru denge şudur: kayıt açmak kolay, okumak hızlı, güncellemek net olmalı. Disiplinin amacı bürokrasi üretmek değil, hafıza maliyetini düşürmektir. Sonuç Kıdemli mühendisler için karar günlüğü disiplini, teknik yazı düzeni değil kurumsal düşünme altyapısıdır. İyi kurulduğunda mimari tercihleri kişisel otoriteye bağımlı olmaktan çıkarır; servis devrini, incident yönetimini ve mentorluk akışını güçlendirir. Sistemler karmaşıklaştıkça en değerli şey yalnızca doğru karar vermek değil, o kararın neden verildiğini ekipçe taşıyabilmektir.",
      "date_published": "2026-04-08T00:00:00.000Z",
      "date_modified": "2026-04-08T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "mentorluk",
        "architecture",
        "decision-making",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-incident-sonrasi-oncelik-sifirlama",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-incident-sonrasi-oncelik-sifirlama",
      "title": "Teknik Liderler İçin Incident Sonrası Öncelik Sıfırlama",
      "summary": "Kesinti sonrası backlog'u körlemesine büyütmeden toparlanma, borç ve teslim dengesini yeniden kurma pratiği.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin incident sonrasi oncelik sifirlama cover.svg'; Bir incident kapandığında takvim sakinleşir ama sistem gerçekten sakinleşmiş olmaz. Alarm sesi kesildiği anda çoğu ekip iki uçtan birine savrulur: ya ertelenmiş tüm işleri bir anda geri yüklemeye çalışır ya da kesinti sırasında açığa çıkan borçları belirsiz bir “sonra bakarız” alanına iter. Teknik lider için asıl sınav tam burada başlar. Çünkü incident sonrasındaki ilk birkaç gün, yalnızca toparlanma dönemi değil; ekibin gelecek iki haftasını, bazen bir çeyreğini şekillendiren öncelik sıfırlama anıdır. <figure <Image src={diagram} alt=\"Incident sonrası öncelik sıfırlama akışını, ekip kararlarını ve toparlanma fazlarını gösteren teknik şema\" / <figcaption İyi ekipler incident sonrasında hızlanmaya değil, önce önceliklerini yeniden doğrulamaya odaklanır.</figcaption </figure Neden sıfırlama gerekir? Kesinti döneminde işler doğal olarak bozulur: Planlı teslimatlar durur Operasyon yükü birkaç kişide toplanır Geçici çözümler kalıcı gibi görünmeye başlar Yeni riskler görünür hâle gelir Eğer ekip bu tabloyu bilinçli biçimde yeniden çerçevelemezse backlog şişer, karar kalitesi düşer ve “incident bitti ama hâlâ toparlayamadık” hissi kalıcılaşır. Öncelik sıfırlama disiplini tam olarak bunu engeller: duygusal reaksiyonu değil, sistematik yeniden dengelemeyi öne çıkarır. İlk yapılacak iş: aynı listede her şeyi tutmamak Birçok ekip incident sonrası tek bir görev listesi üretir. Oysa üretim güvenliği ile yol haritası maddelerini aynı torbada tutmak, karar bulanıklığı üretir. Ben ilk ayırımı şu üç başlıkla yapmayı daha doğru buluyorum: 1. Hemen kapatılması gereken operasyonel açıklıklar 2. Öğrenim ve kalıcı iyileştirme işleri 3. Yeniden başlayabilecek normal teslimatlar Bu sınıflandırma yapılmadan “önceliklendirme” konuşmak genelde kavga üretir. Çünkü herkes farklı risk seviyesindeki işi aynı listede savunur. Hangi işleri gerçekten acil saymalı? Incident sonrasında her bulgu kritik değildir. Teknik liderin burada panik değil eşik üretmesi gerekir. Şu tip maddeler genelde ilk dalgada ele alınmalıdır: Aynı semptomu tekrar ettirecek açık konfigürasyon hataları Yetersiz alarm veya görünürlük boşlukları Rollback ve değişiklik güvenini düşüren eksikler Tek kişiye bağımlı müdahale adımları Buna karşılık daha büyük mimari dönüşümler, olayın bahanesiyle “hemen yapalım” kategorisine sokulmamalıdır. Çünkü incident sonrası dönemde ekiplerin odak kapasitesi zaten azalmıştır. Büyük iş, doğru olabilir; ama ilk iş olmayabilir. <Callout type=\"tip\" title=\"Hızlı olmak ile acele etmek aynı şey değildir\" Incident sonrası ilk 48 saatte verilen kararlar, çoğu zaman teknik doğruluktan çok psikolojik rahatlama amacı taşır. Bu yüzden öncelik listesi yazılmadan önce açık risk sınıflandırması yapılmalıdır. </Callout Yol haritası nasıl yeniden dengelenir? Burada teknik liderin rolü “her şeyi durdurmak” değildir. Asıl iş, hangi teslimatların güvenle devam edebileceğini gösterebilmektir. Ben şu üç sorunun oldukça işe yaradığını görüyorum: Bu iş incident kök nedenini veya tekrar riskini artırıyor mu? Bu iş için gereken ekip odağı son günlerde operasyon tarafından tüketildi mi? Bu teslimat ertelenirse iş etkisi, operasyon iyileştirmesinden daha mı büyük? Bu sorularla bakıldığında bazı proje maddeleri olduğu gibi devam eder, bazıları küçültülür, bazıları ise bilinçli biçimde ötelenir. Kritik nokta, bu kararların “hissettiğimiz için” değil görünür çerçeveyle alınmasıdır. Toparlanma borcu diye ayrı bir dil kurmak gerekir Ben incident sonrası dönemde “toparlanma borcu” ifadesini faydalı buluyorum. Çünkü bu alan klasik teknik borçtan biraz farklıdır. Toparlanma borcu şunları içerir: Geçici bypass veya manuel iş adımları Olay sırasında açılmış ama kapatılmamış erişimler Kalıcılaştırılmamış gözlemler ve timeline notları Yorgunluk nedeniyle ertelenmiş bakım işleri Bu borç görünmez bırakıldığında ekip takvimi normal görünür ama sistem hâlâ yaralı çalışır. O yüzden teknik lider bu işleri “sonra bakarız” bölümüne değil, görünür bir toparlanma şeridine koymalıdır. Ekip psikolojisi neden bu konunun parçası? Çünkü incident sonrası ekipler aynı hızla geri dönmez. Bazı mühendisler hemen normal ritme geçer; bazıları ise birkaç gün boyunca temkinli ve dağınık çalışır. Kıdemli liderlik burada üretkenlik baskısını artırmak değil, karar yüzeyini sadeleştirmek anlamına gelir. Sağlıklı yaklaşım genelde şöyledir: İlk hafta çok sayıda yeni paralel iş açılmaz Kritik sahiplikler yeniden dağıtılır Müdahaleyi taşıyan birkaç kişiye nefes alanı bırakılır Postmortem aksiyonları sayıca değil etkiyle filtrelenir Bu düzen kurulursa incident, tüm sprinti bozan bir travma olmaktan çıkıp ölçülü bir toparlanma programına dönüşür. Hangi metrikler gerçekten işe yarar? Incident sonrasında sadece “kök neden kapandı mı?” diye bakmak eksik kalır. Ben şu sinyalleri daha anlamlı buluyorum: Aynı semptom için yeniden alarm oluşup oluşmadığı Olay sonrası açılan geçici işlerin kapanma süresi Ertelenen teslimatların yeniden planlanma netliği Operasyon yükünün kaç gün içinde normale döndüğü Müdahaleyi taşıyan kişilerin görev dağılımındaki düzelme Bu metrikler, ekibin gerçekten toparlanıp toparlanmadığını gösterir. Çünkü incident’ın bittiği an ile etkisinin bittiği an çoğu zaman aynı değildir. Teknik liderin en sık yaptığı hata En sık gördüğüm hata, postmortem aksiyonlarını yeni backlog gerçekliği sanmak. Oysa her incident onlarca fikir üretir; bunların tamamı aynı ağırlıkta değildir. Teknik liderin görevi çok fikir çıkarmak değil, hangisinin sistem davranışını gerçekten değiştireceğini ayıklamaktır. İkinci hata ise tam tersidir: olayı yalnızca bir ticket ile kapatmak. Bu durumda da ekip kısa vadede hızlandığını sanır ama birkaç hafta sonra aynı kırılganlık başka biçimde geri gelir. Sonuç Teknik liderler için incident sonrası öncelik sıfırlama, toplantı takvimini yeniden düzenleme işi değildir. Bu disiplin; operasyonel açıklıkları, toparlanma borcunu ve normal teslimat ritmini aynı resimde okuyabilme yeteneğidir. İyi kurulduğunda ekip kesintiden sonra daha yavaş değil, daha berrak hareket eder. Asıl olgunluk da burada görünür: sorunu çözmekte değil, çözüm sonrasındaki yön duygusunu kaybetmemekte.",
      "date_published": "2026-04-08T00:00:00.000Z",
      "date_modified": "2026-04-08T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "incident-management",
        "ekip-surecleri",
        "operasyon-kulturu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-raporlama-kopyasi-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-raporlama-kopyasi-tasarimi",
      "title": "ERP Altyapılarında Raporlama Kopyası Tasarımı",
      "summary": "Üretim işlem yükünü korurken raporlama ve analitik sorguları ayrı bir veri yüzeyine taşıyan mimari yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda raporlama kopyasi tasarimi cover.svg'; ERP sistemlerinde performans problemleri çoğu zaman uygulama kodundan değil, yanlış veri tüketim alışkanlıklarından büyür. Finans, lojistik, stok ve operasyon ekipleri daha fazla rapor ister; entegrasyon ekipleri yeni sorgular açar; BI tarafı canlıya yakın veri ister. Bütün bu ihtiyaçlar doğrudan üretim veritabanısına yüklendiğinde, işlem hattı ile analitik beklenti aynı kaynak için yarışmaya başlar. Raporlama kopyası tasarımı, bu çatışmayı mimari seviyede ayırmak için güçlü bir yaklaşımdır. <figure <Image src={diagram} alt=\"ERP üretim veritabanısı ile raporlama kopyası arasındaki ayrımı ve veri akışını gösteren teknik şema\" / <figcaption ERP çekirdeğini hızlı tutmanın yolu, her raporu optimize etmekten çok raporlama yüzeyini doğru ayırmaktan geçer.</figcaption </figure Problem gerçekten nerede? Kurumsal ERP ortamlarında raporlama sorguları genelde “okuma yapıyor, zararı olmaz” düşüncesiyle küçümsenir. Oysa pratikte şu etkiler oluşur: Uzun süren join ve aggregation sorguları disk baskısını artırır Yoğun saatlerde kilit ve bekleme süreleri uzar Bakım işleri ile raporlama pencereleri çakışır Uygulama ekipleri üretim veritabanısını görünmez analitik platforma çevirir Bu tablo sürdürülebilir değildir. Çünkü ERP çekirdeği işlem güveni ister; raporlama ise geniş okuma özgürlüğü ister. Aynı yüzeyde ikisini birlikte optimize etmek zordur. Raporlama kopyası ne demektir? Raporlama kopyası, üretimden veri alan ama üretimle aynı çalışma sözleşmesine sahip olmayan ayrı bir okuma yüzeyidir. Bu yüzey: Salt okunur olabilir Gecikmeli replikasyonla beslenebilir İndekslerini raporlama ihtiyacına göre taşıyabilir BI ve entegrasyon ekiplerine farklı sorgu özgürlüğü sunabilir Önemli olan, bu kopyayı “yedek” ile karıştırmamaktır. Yedek geri dönüş içindir; raporlama kopyası tüketim içindir. Hangi tasarım modelleri öne çıkar? Ben bu konuyu üç modelde düşünmeyi faydalı buluyorum: 1. Yakın gerçek zamanlı read replica 2. Saatlik veya periyodik veri kopyası 3. Olay tabanlı analitik yüzey İlk model, dashboard ve operasyon raporları için uygundur. İkinci model, kapanış veya günlük raporlama için yeterli olabilir. Üçüncü model ise ERP çekirdeğini daha fazla korur ama tasarımı daha karmaşıktır. <Callout type=\"tip\" title=\"İş birimine önce veri tazeliği sözleşmesini anlatın\" Birçok tartışma teknik değil beklenti problemidir. Her raporun saniyeler içinde güncel olması gerekmiyorsa, daha sade ve daha güvenli mimari seçebilirsiniz. </Callout En kritik mimari karar: veri tazeliği Raporlama kopyası tasarımında en önemli soru genelde teknoloji değil, kabul edilen gecikmedir. Şu ayrım netleşmeden altyapı kararı vermek erken olur: 5 saniye gecikme kabul mü? 5 dakika kabul mü? Yalnızca saatlik yenileme yeterli mi? Bu cevap değiştiğinde, replikasyon maliyeti, ağ tasarımı, indeks stratejisi ve operasyon yükü de değişir. Kurumsal yapılarda çoğu zaman “her şey canlı olsun” refleksi vardır; fakat iş birimleriyle konuşulduğunda çok daha makul pencereler ortaya çıkar. Operasyonel sınırlar nasıl çizilmeli? Raporlama kopyası açmak, kontrolsüz sorgu cenneti kurmak anlamına gelmemeli. Sağlıklı modelde şu sınırlar açık olmalıdır: Kimler doğrudan bağlanabilir? Hangi sorgu sınıfları desteklenir? Saklama ve maskeleme politikası ne olacak? Kopya bozulursa iş sürekliliği nasıl etkilenir? Özellikle ERP verilerinde kişisel veri, finansal kayıt ve tedarik zinciri bilgileri iç içe olabilir. Bu yüzden raporlama yüzeyi güvenlik ve veri yönetişiminden bağımsız düşünülemez. Hangi kazanımlar gerçekçidir? Doğru kurulan model şu faydaları üretir: Üretim işlem yükü daha öngörülebilir olur BI ve raporlama ekipleri daha geniş sorgu alanı kazanır Performans incelemeleri üretim ile raporlamayı ayrı okuyabilir ERP yükseltmeleri ve bakım işleri daha kontrollü planlanır Burada kritik nokta, raporlama kopyasının her problemi çözmeyeceğini bilmektir. Kötü veri modeli, zayıf sorgu disiplini veya sahipliği belirsiz raporlar yine maliyet üretir. Ama en azından bu maliyet artık çekirdek işlem hattını aynı ölçüde tehdit etmez. Sık yapılan hata En sık hata, raporlama kopyasını açıp işletim modelini tanımlamamaktır. Sonuçta herkes yeni yüzeye bağlanır, veri tazeliği şikâyeti başlar, indeksler kontrolsüz büyür ve sistem ikinci üretim veritabanısına dönüşür. İkinci hata ise kopyayı yalnızca teknik ekip kararı sanmak. Oysa bu mimari değişiklik aynı zamanda iş birimleriyle veri gecikmesi, rapor doğruluğu ve destek modeli üzerine açık sözleşme kurmayı gerektirir. Sonuç ERP altyapılarında raporlama kopyası tasarımı, veritabanı ölçekleme hilesi değil iş yükü ayrıştırma kararıdır. Çekirdek işlem trafiği ile analitik ve raporlama ihtiyacını aynı veri yüzeyinde zorlamak yerine, beklentileri açık sözleşmelerle ayırmak uzun vadede daha sağlıklı sonuç üretir. Kurumsal ERP sistemleri için hız çoğu zaman daha büyük donanımdan değil, doğru tüketim sınırlarından gelir.",
      "date_published": "2026-04-08T00:00:00.000Z",
      "date_modified": "2026-04-08T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "architecture",
        "database",
        "reporting",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/rsyslog-relp-ile-guvenilir-uzak-log-tasima",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/rsyslog-relp-ile-guvenilir-uzak-log-tasima",
      "title": "Rsyslog RELP ile Güvenilir Uzak Log Taşıma",
      "summary": "Kritik logları TCP kopmalarında kaybetmeden merkezî sisteme aktarmak için rsyslog ve RELP tabanlı kurulum.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './rsyslog relp ile guvenilir uzak log tasima cover.svg'; Kurumsal ortamlarda log toplama hattının en zayıf anı, ağın kısa süreli bozulduğu anlardır. Uygulama veya sunucu log üretmeye devam eder; fakat merkezi sisteme taşıma katmanı bu esnada satır kaybedebilir. Özellikle güvenlik, audit ve işletim kayıtları için bu kayıp kabul edilemez. Rsyslog ile RELP kullanımı tam bu noktada değer üretir: taşımanın yalnızca “gönderdim” demesine değil, karşı tarafın alımı teyit etmesine dayanır. <figure <Image src={diagram} alt=\"Rsyslog istemci, RELP kuyruğu ve merkezi log sunucusu arasındaki güvenilir taşıma akışını gösteren teknik şema\" / <figcaption Log hattında güvenilirlik, protokolden çok kuyruk ve teslim teyidi tasarımıyla elde edilir.</figcaption </figure RELP neden klasik syslog TCP'den farklı? TCP kullanmak çoğu ekip için yeterli güvence gibi görünür. Ancak bağlantı koptuğunda, yeniden bağlanma sırasında ve hedef tarafın yavaşladığı anlarda hangi mesajın gerçekten işlendiğini bilmek zordur. RELP bu açığı kapatır: Her mesaj işlem kimliğiyle taşınır Hedef alımı teyit eder Kesinti sonrası iletim daha güvenilir devam eder Bu özellikler özellikle güvenlik olayları, sudo kayıtları, sistem logları ve kritik uygulama günlükleri için önemlidir. Sunucu tarafı kurulumu Önce merkezi log sunucusunda gerekli modülleri açalım. Debian tabanlı bir örnek için: Ardından /etc/rsyslog.d/10 relp server.conf içine temel dinleme yapılandırmasını ekleyebiliriz: Bu yapı tek başına çalışır; ama üretimde dizin yetkileri, disk alanı ve log rotate stratejisi ayrıca düşünülmelidir. İstemci tarafı yapılandırma İstemci düğümde kuyruk ve yeniden deneme ayarları en kritik bölümdür. Sadece uzak hedefi tanımlamak yeterli değildir. /etc/rsyslog.d/60 relp forward.conf için örnek: Bu yapı, hedef ulaşılamadığında logları geçici olarak diske tutar ve hedef geri geldiğinde akışı sürdürür. <Callout type=\"tip\" title=\"Güvenilir taşıma kuyruksuz kurulmaz\" RELP protokolü tek başına mucize değildir. Disk tabanlı kuyruk, yeniden deneme ve kapasite planı yapılmadığında ilk baskı anında yine veri kaybı yaşanabilir. </Callout TLS ne zaman eklenmeli? Eğer log koridoru paylaşımlı ağdan geçiyor, farklı segmentler arasında taşınıyor veya regülasyon baskısı taşıyorsa RELP üzerine TLS eklemek gerekir. Rsyslog bu konuda esnek davranır; fakat sertifika yaşam döngüsünü yönetmeden TLS açmak operasyon borcu üretir. Genel yaklaşım şöyle olabilir: Önce iç, güvenilen koridorda şifrelemesiz akışı doğrula Sonra istemci ve sunucu sertifikalarını dağıt Bağlantıyı TLS ile zorunlu hâle getir Yenileme ve iptal sürecini otomasyona bağla Hangi logları bu hatta almalıyım? Ben RELP hattını özellikle şu tür kayıtlar için ayırmayı faydalı buluyorum: auth.log ve sudo kayıtları Güvenlik ajanı ve EDR olayları Sistem olay günlükleri Kritik middleware ve ERP entegrasyon logları Her debug logunu aynı hatta koymak gereksizdir. Çünkü amaç her şeyi pahalı güvenilirlikle taşımak değil; kaybı kabul edilemeyecek veriyi doğru koridorla iletmektir. Doğrulama nasıl yapılır? Kurulum sonrasında sadece servis ayağa kalktı diye yetinmeyin. Şu testleri özellikle uygulayın: 1. İstemciden test logu üretin 2. Sunucuda doğru dosyaya düştüğünü görün 3. Ağ bağlantısını kısa süre kesip kuyruk davranışını izleyin 4. Bağlantı geri geldiğinde satırların teslim edildiğini doğrulayın Basit test komutu: Ardından merkezi sunucuda ilgili host ve program dosyasında girdiyi arayın. Sık yapılan hatalar En yaygın hata, güvenilir taşıma hedefi kurup hedef sunucudaki disk baskısını hesaba katmamak. İkinci hata, tüm istemcileri tek dizin ve tek dosyada toplamaya çalışmak. Böyle olunca sorgulama, rotate ve olay inceleme zorlaşır. Bir başka hata da RELP hattını kurup bu hattın durumunu izlememektir. Kuyruk boyutu, başarısız teslim sayısı ve disk tüketimi de gözlemlenmelidir. Aksi halde sistem sessizce biriken risk yaratır. Sonuç Rsyslog RELP ile güvenilir uzak log taşıma, log toplama hattını “en iyi ihtimalle gider” modelinden çıkarıp operasyonel güvenceye taşır. Özellikle Linux sunucular, güvenlik kayıtları ve kurumsal entegrasyon servisleri için bu yaklaşım basit ama güçlü bir dayanıklılık katmanıdır. Kritik loglar için önemli olan yalnızca toplamak değil, bozuk ağ anlarında da kaybetmemektir.",
      "date_published": "2026-04-08T00:00:00.000Z",
      "date_modified": "2026-04-08T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "rsyslog",
        "relp",
        "logging",
        "observability",
        "linux"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/smokeping-ile-hat-gecikmesi-baz-cizgisi-kurulumu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/smokeping-ile-hat-gecikmesi-baz-cizgisi-kurulumu",
      "title": "SmokePing ile Hat Gecikmesi Baz Çizgisi Kurulumu",
      "summary": "Şube, veri merkezi ve bulut bağlantılarında gecikme ve jitter davranışını görünür kılmak için SmokePing rehberi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './smokeping ile hat gecikmesi baz cizgisi kurulumu cover.svg'; Ağ sorunlarının büyük bölümü “bağlantı var mı yok mu?” sorusuyla yakalanmaz. Asıl problem çoğu zaman aralıklı gecikme sıçramaları, jitter artışı ve belirli saatlerde bozulan hat davranışıdır. Özellikle şube bağlantıları, MPLS çıkışları, internet VPN koridorları ve bulut tünelleri söz konusu olduğunda, anlık ping testi çoğu zaman yeterli sinyal üretmez. SmokePing bu alan için hâlâ güçlüdür; çünkü zaman içinde gecikme davranışını baz çizgisi olarak görmenizi sağlar. <figure <Image src={diagram} alt=\"Şube, veri merkezi ve bulut hatları için gecikme baz çizgisi oluşturan SmokePing mimarisini gösteren teknik şema\" / <figcaption Asıl amaç tek bir anlık ölçüm değil, hattın normal davranışını görünür kılan tarihsel baz çizgiyi oluşturmaktır.</figcaption </figure Hangi senaryoda işe yarar? Şu durumlarda SmokePing oldukça değerlidir: Şubelerden merkeze giden hatlarda kullanıcı “ara ara yavaş” diyorsa Bulut VPN veya IPSec tünellerinde belirli saatlerde gecikme artıyorsa SaaS veya dış servis bağlantısında paket kaybı değil jitter sorunu yaşanıyorsa Ağ ekipleri ile uygulama ekipleri aynı performans sorununu farklı yorumluyorsa Bu tip problemlerde ihtiyaç duyulan şey yeni bir dashboard değil, ortak gerçekliktir. Baz çizgisi bunu sağlar. Kurulum yaklaşımı Bu rehberde tek bir SmokePing düğümünden üç farklı hedef kümesini izleyeceğiz: 1. Şube yönlendiricileri 2. Veri merkezi geçitleri 3. Bulut içi kritik uçlar Ubuntu veya Debian üzerinde temel kurulum oldukça sade: Kurulumdan sonra asıl iş paketleri göndermek değil, hedefleri operasyonel anlam taşıyacak şekilde gruplanmaktır. Hedef grupları nasıl tasarlanmalı? Benim önerim isimlendirmeyi lokasyon değil davranış üzerinden kurmak: branches datacenter gateways cloud egress critical partners Böylece grafiklere bakarken yalnızca IP değil, hangi iş koridorunu izlediğinizi de anlarsınız. Örnek Targets kurgusu şöyle olabilir: Bu yapı küçük görünür ama daha sonra problem korelasyonu için çok işe yarar. <Callout type=\"tip\" title=\"Hedefleri fazla büyütmeyin\" Yüzlerce hedefi ilk günden eklemek yerine, önce gerçekten tartışma yaratan 10 ila 20 kritik hattı izleyin. Değer, veri hacminde değil yorumlanabilirliktedir. </Callout Neden baz çizgisi kavramı önemli? Bir hattın 22 ms gecikme göstermesi tek başına iyi ya da kötü değildir. Aynı hat normalde 8 ms ise problem vardır; normalde 20 ms ise yoktur. SmokePing'in değeri tam burada çıkar. Zaman içinde normal davranışı görünür kıldığınızda şu sorulara daha net yanıt verirsiniz: Gecikme artışı sürekli mi, dönemsel mi? Jitter yalnızca belirli saatlerde mi yükseliyor? Sorun tek bir lokasyonda mı, tüm koridorda mı? Uygulama şikâyeti ağ sinyaliyle aynı ana denk geliyor mu? Bu veriler olmadan incident sırasında herkes farklı gerçeği savunur. Alarm üretimi nasıl yapılmalı? SmokePing tek başına tam alarm platformu değildir; ama baz çizgiden sapma sinyalini üretmek için kullanılabilir. Pratikte şu yaklaşım işe yarar: SmokePing grafiklerini düzenli review edin Belirli hedef grupları için ortalama ve jitter eşiği belirleyin Bu veriyi Prometheus veya başka izleme katmanına aktaran küçük kontrol betikleri kullanın İlk hedef anlık alarm bombardımanı olmamalı. Önce normal davranışı okuyun, sonra eşik koyun. Aksi halde sistem gereksiz gürültü üretir. Hangi hatalar sık yapılır? En yaygın hata, hedef olarak yalnızca internet adresleri seçmek. Bu durumda kurum içi davranışı anlamak zorlaşır. İkinci hata ise grafiklere bakıp aksiyon eşikleri tanımlamamaktır. O zaman SmokePing dekoratif bir araç olur. Bir diğer önemli hata da yorumlamayı sadece ağ ekibine bırakmak. Oysa şube ERP erişimi, bulut API gecikmesi veya uzak yedekleme koridoru gibi alanlarda uygulama ve platform ekipleri de bu baz çizgiden faydalanır. Sonuç SmokePing ile hat gecikmesi baz çizgisi kurmak, yalnızca ping grafiği üretmek değildir. Bu yaklaşım; ağ performansını anlık sezgiden çıkarıp tarihsel davranış üzerinden okunabilir hâle getirir. Özellikle şube, veri merkezi ve bulut arasında uzanan kurumsal bağlantılarda, doğru tartışmanın başlaması için önce bu baz çizginin kurulması gerekir.",
      "date_published": "2026-04-08T00:00:00.000Z",
      "date_modified": "2026-04-08T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "network",
        "smokeping",
        "observability",
        "latency",
        "monitoring"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-runbook-borcu-yonetimi",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-runbook-borcu-yonetimi",
      "title": "Kıdemli Mühendisler İçin Runbook Borcu Yönetimi",
      "summary": "Operasyonel hafızayı kişilere değil sisteme taşıyan runbook borcu yönetimi için teknik liderlik yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kıdemli mühendislik pratiğinde en pahalı borç türlerinden biri kod borcu değil, runbook borcudur. Sistem ayakta görünürken ekip yalnızca birkaç kişinin kafasında yaşayan operasyon bilgisine yaslanıyorsa, ilk büyük incident anında bunun bedeli ortaya çıkar. Runbook borcu yönetimi, operasyonel hafızayı kahramanlıktan çıkarıp tekrar edilebilir mühendislik pratiğine dönüştürür. Runbook borcu neden görünmez kalır? Birçok ekip runbook eksikliğini dokümantasyon problemi gibi görür. Oysa sorun yalnızca belge yazmamak değildir; karar akışlarının, geri dönüş adımlarının ve gözlem sinyallerinin sistematik biçimde dışsallaştırılmamasıdır. Bu nedenle görünürde süreç işler, fakat bilgi yükü sessizce belirli kıdemli kişilere yığılır. Runbook borcu genelde şu belirtilerle kendini gösterir: Aynı tip incident için her seferinde farklı müdahale sırası izlenir. Nöbetçi mühendis bir işi çözmek için belirli bir kişiye mesaj atmak zorunda kalır. Değişiklik sonrası geri dönüş kararı ölçüme değil tecrübeli kişinin hissine dayanır. Yeni katılan mühendisler üretim sistemine yaklaşırken gereğinden fazla çekingen davranır. Bu tablo, organizasyonun teknik olgunluğunu olduğundan yüksek gösterir. Çünkü bilgi vardır, ama taşınabilir değildir. Runbook yazmak değil, runbook portföyü yönetmek gerekir Kıdemli mühendisler çoğu zaman \"bir runbook yazarız\" yaklaşımına düşer. Problem burada ölçeklenmez. Doğru yaklaşım, runbook'ları yaşayan bir operasyon portföyü olarak ele almaktır. Her runbook bir belge değil; bir risk sınıfı, bir karar ağacı ve bir gözlem bağlamı taşır. Benim pratikte verimli bulduğum ayrım şu şekildedir: 1. Müdahale runbook'ları : Incident sırasında ilk 15 dakikayı standardize eder. 2. Değişiklik runbook'ları : Yayın, rollback ve doğrulama adımlarını açıklar. 3. Bakım runbook'ları : Düzenli operasyon işlerini kişiden bağımsızlaştırır. 4. Tanı runbook'ları : Belirtiye göre hangi sinyale bakılacağını tanımlar. Bu sınıflandırma olmadan bütün operasyon bilgisi tek tip belgeye dönüşür ve arama kolay görünse de kullanımı zorlaşır. İyi bir runbook hangi soruları cevaplamalı? Runbook metni uzun olmak zorunda değildir. Ama karar kalitesini artıracak kadar net olmalıdır. Özellikle şu sorular cevapsız kalmamalı: Bu runbook hangi alarm, belirti veya değişiklik türü için geçerli? İlk üç kontrol noktası nedir? Hangi metrik, log veya dashboard müdahale kararını etkiler? Ne zaman rollback yapılır, ne zaman escalation açılır? Etki alanı hangi servislerle sınırlıdır? Runbook yalnızca adım listesi olursa hız kazandırır ama muhakeme üretmez. Adımların yanında karar eşiği de tarif edilirse ekip kalitesi tutarlı hâle gelir. <Callout type=\"tip\" title=\"Belge değil karar kasası\" En iyi runbook, bir komutu kopyalatandan çok daha fazlasını yapar. Operasyon sırasındaki yanlış sıralamayı ve gereksiz panik kararlarını azaltır. </Callout Borcu nasıl ölçeriz? Runbook borcu görünmez kaldığında öncelik alamaz. Bu yüzden teknik liderin görevi, belge saymak değil operasyonel açıklığı ölçmektir. Aşağıdaki sinyaller pratikte işe yarar: Son üç incident'ta manuel bilgi aktarımı kaç kez gerekti? İlk müdahale süresi kişi bazında ciddi değişiyor mu? Aynı iş için farklı ekip üyeleri farklı dashboard'lara mı gidiyor? Rollback kararı açık eşiklere bağlı mı, yoksa yoruma mı kalıyor? Bu veriler sayesinde runbook çalışması \"dokümantasyon temizliği\" gibi değil, doğrudan incident performansı yatırımı gibi görülür. Runbook borcunu kapatırken sık yapılan hata En yaygın hata, kıdemli mühendislerin incident sonrasında tek başına belge yazmasıdır. Bu yöntem kısa vadede hızlı görünür; fakat runbook gerçek kullanıcıların diline ve akışına temas etmez. Sonuçta belge vardır ama nöbetçi ekip yine kişiye döner. Daha sağlam model şudur: 1. Incident veya değişiklik sonrası taslak akışı çıkarın. 2. İlk kullanımını belgeyi hiç yazmamış bir mühendis yapsın. 3. Eksik kalan karar eşiklerini kullanım sırasında düzeltin. 4. Runbook'u ilgili alarm, dashboard ve repo referanslarıyla bağlayın. Böylece runbook statik wiki sayfası değil, operasyon yüzeyinin gerçek parçası olur. Teknik liderin rolü nedir? Runbook borcu yönetimi yalnızca SRE veya operasyon ekibine bırakılmamalıdır. Teknik lider, hangi bilgilerin kurumsal hafızaya dönüşmesi gerektiğini seçen kişidir. Her şeyi belgelemek doğru olmadığı gibi, kritik karar yollarını kişide bırakmak da kabul edilemez. Kıdemli mühendislik burada üç sorumluluk taşır: En yüksek etkiye sahip runbook boşluklarını önceliklendirmek Runbook kalitesini gerçek kullanım üzerinden değerlendirmek Yeni mühendisleri belge tüketicisi değil belge geliştiricisi yapmak Bu yaklaşım, mentorlukla operasyon disiplinini aynı hatta taşır. Sonuç Kıdemli mühendisler için runbook borcu yönetimi, belge üretiminden çok sistematik hafıza tasarımı işidir. Operasyon bilgisi kişiden sisteme taşındığında nöbet yükü daha adil dağılır, incident müdahalesi daha öngörülebilir olur ve ekip kıdemi kurumsal çarpana dönüşür. Sağlam mühendislik kültürü, yalnızca iyi çalışan sistemlerle değil; gerektiğinde herkesin aynı netlikle müdahale edebildiği sistemlerle kurulur.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "runbook",
        "incident-management",
        "teknik-liderlik",
        "operasyon-kültürü"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-servis-sahipligi-devir-protokolu",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-servis-sahipligi-devir-protokolu",
      "title": "Kıdemli Mühendisler için Servis Sahipliği Devir Protokolü",
      "summary": "Servis bilgisini kişilere değil işletilebilir sözleşmelere taşıyan devir modeli, teknik liderlikte sürekliliği güçlendirir.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kidemli muhendisler icin servis sahipligi devir protokolu diagram.svg'; Bir servisin sahibi değiştiğinde yalnızca nöbet listesi güncellenmez; karar geçmişi, risk iştahı, gizli operasyon alışkanlıkları ve kurumsal güven de el değiştirir. Birçok ekipte devir, wiki bağlantısı paylaşmak veya birkaç toplantı yapmak sanılır. Oysa kıdemli mühendislik pratiğinde servis sahipliği devri, operasyonel boşluk bırakmadan süreklilik üreten bilinçli bir protokoldür. <figure <Image src={diagram} alt=\"Servis sahipliği devrinde bilgi akışını, risk alanlarını ve onay kapılarını gösteren teknik şema\" / <figcaption İyi devir, bilgi transferi kadar karar sınırlarını da görünür kılar.</figcaption </figure Neden servis sahipliği devri ayrı bir disiplin olmalı? Servisler büyüdükçe yazılı doküman ile gerçek işletme davranışı arasındaki fark açılır. Runbook güncel görünür; fakat kritik alarmlarda hangi metriklerin gerçekten önemli olduğu, hangi müşterinin daha hassas etkilendiği veya hangi deploy penceresinin riskli olduğu çoğu zaman birkaç kişinin zihninde saklı kalır. Bu görünmez bilgi aktarılmadan yapılan her devir, kısa vadede sakin görünür ama ilk incident anında çatlar. Yeni sahibi olan ekip teknik olarak yetkin olsa bile, bağlam eksikliği nedeniyle daha yavaş karar alır ve gereksiz escalation üretir. Devir protokolünün dört katmanı Ben servis sahipliği devrini dört katmanlı düşünmeyi faydalı buluyorum: 1. Operasyonel gerçeklik 2. Mimari sınırlar 3. Paydaş haritası 4. Karar yetkisi İlk katman, alarm yüzeyi, bakım işleri, kapasite davranışı ve bilinen kırılganlıkları kapsar. İkinci katman, servisin hangi bağımlılıklarla yaşadığını ve hangi değişikliklerin başka ekipleri etkilediğini görünür kılar. Üçüncü katman, ürün, destek, güvenlik ve iş birimleriyle olan ilişkiyi açığa çıkarır. Dördüncü katman ise en kritik sorudur: yeni sahip neyi kendisi değiştirebilir, ne zaman daha geniş onay gerekir? <Callout type=\"tip\" title=\"Devir toplantısı bilgi dökümü değildir\" Amaç tüm ayrıntıları anlatmak değil; yeni sahibin ilk 30 günde bağımsız ve güvenli karar alabileceği çerçeveyi kurmaktır. </Callout Operasyonel gerçekliği belgelemek ne demektir? Bir servis için yalnızca dashboard bağlantısı paylaşmak yeterli değildir. Aşağıdaki parçalar açıkça yazılmalıdır: Kritik alarmların gerçek öncelik sırası Gürültülü ama tolere edilen sinyaller Elle yürütülen bakım adımları En sık yapılan geri alma senaryoları Kapasite artışı öncesinde bakılan göstergeler Bu liste, servisin yaşayan davranış modelidir. Özellikle ERP veya entegrasyon ağırlıklı sistemlerde gece batch yükü, ay sonu kapanışları ve dış bağımlılık pencereleri belgede açık değilse yeni sahip ekip sürekli sürprizle karşılaşır. Mimari sınırları nasıl aktarmalı? Servisin topolojisini göstermek yararlıdır; ama daha değerlisi hangi değişikliklerin tehlikeli olduğunu söylemektir. Örneğin: Bu servis ana veri tabanı bağlantı havuzunda ortak limit kullanır. Retry süresi artırılırsa ERP kuyruğunda gecikme büyür. Sertifika yenileme akışı başka platform ekibinin pipeline'ına bağlıdır. Audit log formatı uyum gereği değiştirilemez. Bu cümleler yeni sahibin tasarım özgürlüğünü kısıtlamak için değil, yanlış güven üretmemek için gerekir. Kıdemli mühendislikte olgunluk, sadece sistemi anlamak değil, sistemin görünmeyen kontratlarını adlandırabilmektir. Paydaş haritası neden devrin parçası? Servis sahipliği teknik olduğu kadar kurumsal bir roldür. Yeni sahibin sadece repository'yi değil, ilişki ağını da devralması gerekir. Hangi ürün yöneticisi bu servise duyarlıdır, hangi güvenlik ekibi belirli değişikliklerde bilgilendirilmelidir, hangi destek lideri olay anında ilk durum özetini bekler? Bu ağ görünür olmazsa yeni sahip, teknik olarak doğru karar verse bile kurumsal sürtünme yaratır. Özellikle kesinti veya bakım anlarında kimin neyi ne hızda duyması gerektiği önceden aktarılmışsa geçiş çok daha sakin olur. Devir tamamlandı mı, nasıl anlaşılır? Bence aşağıdaki üç test geçilmeden devir tamamlanmış sayılmamalı: 1. Yeni sahip ekip tek başına kontrollü bir değişiklik yayınlayabiliyor mu? 2. Önceki sahip devreye girmeden orta ölçekli bir alarmı kapatabiliyor mu? 3. Paydaş güncellemesini doğru dilde ve doğru ritimde paylaşabiliyor mu? Bu testler geçilmiyorsa problem çoğu zaman yetkinlik değil, eksik çerçevedir. Pratik bir 30 günlük geçiş modeli Benzer ortamlarda şu ritim iyi çalışır: İlk hafta: gölge sahiplik ve ortak gözden geçirme İkinci hafta: yeni ekibin yönettiği düşük riskli değişiklik Üçüncü hafta: alarm ve incident simülasyonu Dördüncü hafta: eski sahibin danışman rolüne çekilmesi Bu model, bilgiyi toplantı notlarından operasyon pratiğine taşır. Özellikle platform dönüşümü yaşayan kurumlarda servis sahipliğinin kadro değişimlerinden etkilenmemesi için bu tür ritüeller kritik değer üretir. Sonuç Kıdemli mühendisler için servis sahipliği devir protokolü, yalnızca devir teslim kontrol listesi değildir. Bu protokol; bilgiyi kişiden sisteme, sezgiyi sözleşmeye ve bağımlılığı güvenli işletmeye dönüştürür. Sağlam kurulduğunda ekip değişse bile servis davranışı bozulmaz; asıl kurumsal olgunluk da burada görünür.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "ownership",
        "mentorluk",
        "operasyon-kültürü"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-kapasite-muzakeresi-disiplini",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-kapasite-muzakeresi-disiplini",
      "title": "Teknik Liderler İçin Kapasite Müzakeresi Disiplini",
      "summary": "Teslim baskısı ile operasyon yükü arasında ezilmeden kapasite konuşabilen teknik liderlik pratiği üzerine net bir çerçeve.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin kapasite muzakeresi disiplini diagram.svg'; Teknik liderlikte en yıpratıcı alanlardan biri kapasite konuşmalarıdır. Yol haritası büyür, incident yükü sürer, platform borcu kabarır ve herkes aynı ekibin daha hızlı koşmasını ister. Bu noktada kötü liderlik ya sessizce her şeyi kabul eder ya da sürekli \"kaynağımız yok\" diyerek soyut bir savunma üretir. İyi liderlik ise kapasiteyi sayı, risk ve operasyon gerçeği üzerinden müzakere eder. Çünkü kapasite bir his değil, sistem davranışıdır. <figure <Image src={diagram} alt=\"Teknik liderler için kapasite müzakeresi disiplinini gösteren teknik şema\" / <figcaption Kapasite müzakeresi yalnızca proje planı değil; incident yükü, bakım borcu ve ekip odağını aynı anda görünür kılma işidir.</figcaption </figure Neden bu konu teknik kariyer başlığıdır? Çünkü kıdem arttıkça sizden yalnızca iyi çözüm üretmeniz değil, ekibin gerçekte neyi kaldırabileceğini de savunmanız beklenir. Özellikle platform, altyapı veya kurumsal teknoloji ekiplerinde kapasite tartışmaları çoğu zaman şu üç eksende sıkışır: Yeni teslimatlar Operasyon ve nöbet yükü Görünmez bakım işleri Bu üçlüden birini yok saydığınız anda ekip bir süre idare eder; sonra ya kalite düşer ya tükenmişlik başlar ya da kritik borç bir incident olarak geri döner. En sık yapılan hata nedir? Kapasiteyi yalnızca sprint puanı veya görev sayısı sanmak. Oysa kıdemli mühendislik pratiğinde kapasite daha geniş bir çerçevedir: 1. Kesintisiz odak süresi 2. Incident sonrası toparlanma payı 3. Mimarî karar ve review zamanı 4. Bakım ve platform iyileştirmeleri 5. Mentorluk ve ekip içi destek Bunlar hesaba katılmadığında ekip kâğıt üzerinde dolu görünür ama gerçekte dağınık çalışır. Müzakere dili nasıl kurulmalı? Teknik liderin işi yalnızca \"hayır\" demek değildir. Asıl iş, hangi talebin hangi başka bedeli doğuracağını görünür kılmaktır. Ben şu dili daha sağlıklı buluyorum: \"Bu işi yapamayız\" yerine: \"Bunu bu çeyrekte alırsak şu iki altyapı riskini erteliyoruz.\" \"Ekip çok dolu\" yerine: \"Son altı haftada operasyon yükü odak kapasitesinin yüzde otuzunu tüketti.\" \"Önceliği değiştirin\" yerine: \"Bu seçimin incident yanıt süresi ve değişim güveni üzerindeki etkisi şu olacak.\" Bu yaklaşım hem daha dürüst hem daha etkili olur. Çünkü kapasite tartışmasını kişisel görüşten çıkarıp sistem etkisine bağlar. <Callout type=\"tip\" title=\"Kapasite savunusu şikâyet değil, tasarım işidir\" Liderlik olgunluğu çoğu zaman daha çok iş almakta değil, ekibin sürdürülebilir çalışma şeklini açık verilerle koruyabilmektedir. </Callout Incident yükü neden ayrı hesaplanmalı? Birçok ekip yol haritasını planlarken incident'i istisna kabul eder. Oysa kurumsal platformlarda incident istisna değil, kapasitenin düzenli tüketicisidir. Eğer nöbet, üretim desteği ve değişim sonrası izleme işini ayrı kapasite dilimine koymazsanız plan sürekli iyimser kalır. Benim önerim şu üç bant modelidir: Planlı teslimatlar Operasyon ve nöbet Stratejik iyileştirme alanı Bu bantlar görünür olduğunda ekip neden her hafta aynı hızda feature çıkaramadığını savunmak zorunda kalmaz; çünkü model zaten bunu açıklıyordur. Üst yönetimle konuşurken ne değişir? Burada saf teknik ayrıntı değil, risk kontratı önemlidir. Yönetim çoğu zaman bütün talepleri aynı tür iş gibi görür. Teknik lider ise ayrımı netleştirmelidir: Gelir veya müşteri etkili teslimatlar Regülasyon ya da güvenlik zorunlulukları Platform sürdürülebilirliği için kaçınılmaz işler Bu sınıflandırma yapılmadan kapasite konuşması kolayca duygu temelli pazarlığa dönüşür. Sayı, örnek ve yakın geçmiş incident verisiyle konuşmak daha güçlü sonuç verir. Ekip içinde bu disiplin nasıl öğretilir? Kıdemli mühendisler kapasite müzakeresini yalnızca yönetici işi gibi görmemelidir. Ekip kültürü şunu öğrenmelidir: Her iş parçasının görünmeyen operasyon bedeli vardır. \"Küçük değişiklik\" ifadesi çoğu zaman eksik bağlam taşır. Bakım borcu ertelendiğinde sessiz maliyet büyür. Hayır demek yerine takasları görünür kılmak daha olgundur. Bu dil yerleştiğinde kapasite savunusu bireysel direnç değil, ekip pratiği hâline gelir. Başarılı olduğunuzu nasıl anlarsınız? İyi sinyaller genelde şöyledir: Son dakika öncelik değişiklikleri daha bilinçli yapılır. Nöbet sonrası toparlanma zamanı planlarda görünür olur. Platform işleri sürekli ertelenen kategori olmaktan çıkar. Ekip teslim hızı ile kalite arasında daha tutarlı denge kurar. Bu sonuçlar, teknik liderin yalnızca iş dağıtmadığını; çalışma sistemini de yönettiğini gösterir. Sonuç Teknik liderler için kapasite müzakeresi disiplini, daha sert konuşma ya da daha iyi tahmin yapma konusu değildir. Bu alan; operasyon gerçeğini, teslim baskısını ve mühendislik sürdürülebilirliğini aynı çerçevede anlatabilme becerisidir. Kıdemli mühendislik pratiğinde gerçek etki çoğu zaman daha çok iş almakla değil, ekibin hangi işi hangi bedelle alacağını dürüstçe görünür kılmakla oluşur. Kapasiteyi sistem olarak yöneten lider, hem ekibini korur hem kurumu daha gerçekçi karar vermeye zorlar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "team-processes",
        "incident-management",
        "mentorluk"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-operasyon-sagligi-gozden-gecirme-ritmi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-operasyon-sagligi-gozden-gecirme-ritmi",
      "title": "Teknik Liderler için Operasyon Sağlığı Gözden Geçirme Ritmi",
      "summary": "Alarm gürültüsü, runbook borcu ve ekip yükünü aynı tabloda okuyarak operasyon kültürünü olgunlaştıran haftalık liderlik ritmi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin operasyon sagligi gozden gecirme ritmi diagram.svg'; Teknik liderlikte en görünmez ama en belirleyici alışkanlıklardan biri, operasyonel durumu yalnızca incident olduğunda konuşmamaktır. Birçok ekip üretim sağlığını alarm patladığında, kritik müşteri etkisi oluştuğunda veya yorgunluk artık hissedilir düzeye geldiğinde tartışıyor. O noktada konuşulan konu genellikle çözüm değil, birikmiş borcun hasarı oluyor. Daha iyi yaklaşım ise haftalık ya da iki haftalık net bir operasyon sağlığı gözden geçirme ritmi kurmaktır. <figure <Image src={diagram} alt=\"Teknik liderler için operasyon sağlığı gözden geçirme ritmini gösteren teknik şema\" / <figcaption Sağlıklı operasyon kültürü, yalnızca yangın söndürme hızından değil düzenli durum muhasebesinden de oluşur.</figcaption </figure Bu ritim tam olarak ne işe yarar? Operasyon sağlığı oturumu bir status meeting değildir. Amaç; ekipten genel güncelleme almak değil, üretim davranışını ve ekip yükünü aynı karede görmektir. Ben bu oturumların özellikle şu dört soruya cevap üretmesini değerli buluyorum: Hangi alarm veya incident türü tekrar ediyor? Hangi hizmette sessizce biriken runbook veya otomasyon borcu var? Hangi ekip ya da kişi orantısız operasyon yükü taşıyor? Hangi risk birkaç küçük yatırım ile düşürülebilir? Bu sorular düzenli sorulmadığında liderlik refleksi kaçınılmaz olarak sadece acil olana çalışır. Hangi veriler masaya gelmeli? İyi bir gözden geçirme toplantısı sezgiye değil, küçük ama anlamlı bir veri paketine dayanmalıdır. Ben şu seti yeterli buluyorum: Son hafta incident ve major alarm sayısı En çok sayfa alan servisler Gürültülü ama düşük değerli alarm kümeleri Güncellenmeyen runbook veya eksik otomasyon listesi Nöbet dağılımı ve kişi bazlı yük dengesi Buradaki amaç yönetim raporu üretmek değil, müdahale kararını besleyecek kadar ortak gerçeklik yaratmaktır. Toplantı nasıl bozulur? En sık görülen hata, bu oturumu genel teknik gündem toplantısına çevirmektir. Bir başka hata ise herkesten uzun durum özeti istemektir. Böyle olunca operasyon sağlığı yerine toplantı yorgunluğu üretilir. Sağlıklı format bence en fazla 30 ila 45 dakikadır ve şu sırayı izler: 1. Geçen dönemin kritik sinyalleri 2. Tekrarlayan sorunların kök desenleri 3. Küçük ama etkili iyileştirme kararları 4. Sahiplik ve kapanış tarihi Bu iskelet, konuşmayı teknik ayrıntıda boğmadan somut eyleme taşır. <Callout type=\"tip\" title=\"Her sorunu çözmeyin, en pahalı paterni seçin\" Operasyon sağlığı oturumunun başarısı çok iş çıkarması değil, en maliyetli tekrar desenini görünür kılıp ona sahip atamasıdır. </Callout Teknik lider burada hangi rolü oynar? Teknik liderin görevi yalnızca metriği sunmak değildir. Asıl iş, sayının arkasındaki davranışı tercüme etmektir. Örneğin aynı servis bir haftada üç kez alarm üretmiş olabilir. Mesele sadece o servisin bozulması değildir; belki alarm eşiği yanlıştır, belki runbook eksiktir, belki de ekipte konuyu bilen kişi çok azdır. Lider bu sinyali kişi performansı tartışmasına değil, sistem tasarımı ve ekip sağlığı bağlamına taşımalıdır. Bu yüzden iyi liderlik şu ayrımı yapar: Kimin hatası sorusu yerine hangi desen tekrar ediyor? Daha fazla dikkat yerine hangi mekanizma eksik? Daha çok kahramanlık yerine hangi otomasyon gerekli? Mentorluk ve kıdemli mühendislik pratiğiyle ilişkisi Bu ritim, kıdemli mühendisler için önemli bir mentorluk alanıdır. Çünkü üretim sağlığı yalnızca dashboard okumak değildir; sinyalden aksiyona giden yolu öğrenmektir. Kıdemli mühendis adayları bu toplantılarda şunları görür: Teknik borcun operasyon maliyetine nasıl dönüştüğünü Alarm kalitesinin ekip davranışını nasıl etkilediğini Küçük platform yatırımlarının nöbet yükünü nasıl azalttığını Bence gerçek kıdem, sadece zor problemi çözmek değil; tekrar eden problemi sistematik biçimde küçültmeyi öğrenmektir. Hangi çıktılar beklenmeli? Her oturumun sonunda en fazla birkaç net çıktı olmalı: Kapatılacak bir alarm gürültüsü Yazılacak veya güncellenecek bir runbook Otomasyona alınacak bir operasyon adımı Ekip yükünü dengelemek için sahiplik değişikliği Bu liste uzadığında ritim etkisini kaybeder. Ama düzenli şekilde çalıştığında birkaç hafta içinde ekipte belirgin sakinlik oluşur. Sonuç Teknik liderler için operasyon sağlığı gözden geçirme ritmi, incident çözümünden farklı bir kas geliştirir: tekrar eden acıyı görünür kılma ve onu sistematik olarak küçültme kası. Alarm gürültüsü, runbook borcu ve kişi bazlı yük tek bir çerçevede okunduğunda ekip daha az reaktif, daha çok bilinçli hareket eder. Operasyon kültürü de tam burada olgunlaşır.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "operasyon-kulturu",
        "incident-management",
        "mentorluk"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-geri-donusumlu-sema-gecis-hatti",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-geri-donusumlu-sema-gecis-hatti",
      "title": "ERP Altyapılarında Geri Dönüşümlü Şema Geçiş Hattı",
      "summary": "Veri tabanı şema değişikliklerini kesinti riski büyütmeden, geri alınabilir ve gözlemlenebilir bir geçiş hattıyla yöneten ERP yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda geri donusumlu sema gecis hatti diagram.svg'; ERP sistemlerinde şema değişikliği çoğu zaman yalnızca bir veri tabanı işi gibi ele alınır. Oysa gerçek hayatta değişen şey tablo değil, aynı anda çalışan entegrasyonlar, batch akışları, raporlama sorguları ve operasyon ekiplerinin hata ayıklama kabiliyetidir. Bu nedenle sağlıklı bir ERP modernizasyonunda hedef \"migration çalıştı\" demek değil, değişikliği gerektiğinde güvenle geri alabilecek bir şema geçiş hattı kurmaktır. <figure <Image src={diagram} alt=\"ERP altyapılarında şema geçiş hattı, uyumluluk katmanı ve geri dönüş adımlarını gösteren teknik şema\" / <figcaption Şema değişikliği bir SQL betiği değil, bütün bağımlılık zincirini etkileyen kontrollü bir yayın hareketidir.</figcaption </figure Neden ERP tarafında şema değişikliği daha hassastır? Çünkü ERP verisi genellikle tek bir uygulamanın değil, onlarca iş akışının ortak sözleşmesidir. Bir alan adının değişmesi ya da zorunlu bir kolon eklenmesi şu katmanları aynı anda etkileyebilir: Uygulama sunucuları ETL ve raporlama akışları Entegrasyon servisleri Batch işleyiciler Yetki ve denetim kayıtları Modern mikroservislerde bu etki bazen servis sınırında kalabilir; ancak ERP dünyasında değişiklik çoğu zaman yatayda daha fazla sisteme dokunur. Bu yüzden geri dönüşlü tasarım temel gereksinimdir. Geri dönüşümlü şema geçiş hattı nedir? Ben bu modeli dört aşamalı düşünmeyi faydalı buluyorum: 1. Uyumluluk genişletmesi : Yeni şema alanlarını ekle ama mevcut davranışı bozma. 2. Çift okuma veya çift yazma dönemi : Uygulama eski ve yeni yapıyı kontrollü biçimde birlikte kullanır. 3. Trafik ve veri gözlemi : Hangi bağımlılığın hâlâ eski alanı kullandığını telemetriyle teyit et. 4. Daraltma ve temizlik : Eski alanı yalnızca gerçekten terk edildiği doğrulandıktan sonra kaldır. Bu yaklaşımın temel avantajı, değişikliği tek adımda geri dönülmez bir harekete çevirmemesidir. Asıl hata nerede yapılıyor? Çoğu ekip migration dosyasını başarıyla çalıştırdığında işin bittiğini düşünüyor. Oysa kırılma genellikle iki gün sonra, gece batch'inde, bir raporlama sorgusunda veya dış entegrasyonda ortaya çıkıyor. Bunun sebebi, şema değişikliğinin teknik olarak uygulanmış ama davranışsal etkisinin ölçülmemiş olmasıdır. Bu yüzden geçiş hattının içine şu kontrol kapıları yazılmalıdır: Hangi sorgular eski alanı kullanıyor? Hangi entegrasyon sürümü yeni şemayı tüketemiyor? Hangi batch job veri tutarsızlığı üretiyor? Rollback yapılırsa veri kaybı mı yoksa yalnızca davranış değişimi mi olur? <Callout type=\"tip\" title=\"Rollback yalnızca kod için planlanmamalı\" Kod geri alınabiliyor ama veri şekli geri alınamıyorsa gerçekten güvenli bir yayın yapılmış sayılmaz. ERP projelerinde veri dönüş yönü en kritik karardır. </Callout Uyumluluk katmanını küçümsemeyin ERP altyapılarında uyumluluk katmanı bazen geçici diye hafife alınır; aslında en değerli koruma yüzeyidir. Örneğin yeni bir document status v2 alanı ekleniyorsa uygulama bir süre hem eski hem yeni alanı okuyabilir. Hatta gerekli durumlarda yazma sırasında dönüştürme adaptörü kullanılarak iki yapı paralel tutulabilir. Bu katman sayesinde: Uygulama ekipleri farklı sürümlerle kontrollü geçiş yapar. Raporlama ekibi sorgularını gecikmeli ama güvenli biçimde uyarlayabilir. Beklenmeyen hatada eski davranışa dönmek veri bütünlüğünü bozmaz. Buradaki kritik nokta, bu dönemi sonsuz bırakmamak ve çıkış kriterlerini baştan tanımlamaktır. Telemetri olmadan bu hat yönetilemez Şema geçiş hattı gözlemlenebilir değilse ekipler kararlarını sezgiyle verir. Ben bu tür dönüşümlerde en az şu sinyallerin izlenmesini gerekli görüyorum: Eski ve yeni alan kullanım oranı Migration sonrası hata sınıfları Rapor ve entegrasyon sorgularında başarısızlık oranı Veri eşleme veya dönüştürme gecikmesi Özellikle ERP tarafında \"kırıldı mı?\" sorusundan çok \"kim hâlâ eski davranışa bağımlı?\" sorusu daha değerlidir. Bu da ancak uygulama ve veri katmanı birlikte gözlemlendiğinde ortaya çıkar. Değişiklik penceresi yerine karar penceresi Kurumsal ekipler çoğu zaman gece yayın penceresi planlar; ama asıl ihtiyaç duyulan şey karar penceresidir. Yani yayın anında hangi sinyal gelirse devam edileceği, hangi sinyalde durulacağı ve hangi koşulda geri dönüleceği önceden net olmalıdır. Bu modelde değişiklik bir cesaret testi değil, kontrollü seçenek yönetimidir. Bence iyi tanımlanmış bir karar penceresi şunları içerir: Sorumlu teknik kişi İş etki temsilcisi Veri bütünlüğü kontrol listesi Rollback sınırı ve veri geri alma yöntemi Sonuç ERP altyapılarında geri dönüşümlü şema geçiş hattı, veri tabanı değişikliğini operasyonel bir güven modeliyle birlikte ele alır. Uyumluluk katmanı, telemetri ve net rollback kapıları olmadan yapılan migration'lar ilk anda başarılı görünse de kurumsal ölçekte pahalı sürprizler üretir. Sağlam yaklaşım, değişikliği küçük adımlarla genişletmek, davranışı ölçmek ve yalnızca bağımlılıklar gerçekten taşındığında daraltmaktır.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "database",
        "migration",
        "architecture",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-gozlemlenebilirlik-kontrol-odasi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-gozlemlenebilirlik-kontrol-odasi",
      "title": "ERP Altyapılarında Gözlemlenebilirlik Kontrol Odası",
      "summary": "ERP çevresindeki kritik akışları tek panelde değil, tek operasyon dilinde toplayan gözlemlenebilirlik kontrol odası yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda gozlemlenebilirlik kontrol odasi diagram.svg'; ERP altyapılarında izleme çoğu zaman çok veri üretir ama az bağlam sunar. CPU, disk, queue depth, batch süresi, entegrasyon hatası, kullanıcı oturumu, rapor kuyruğu ve veritabanı bekleme istatistikleri ayrı sistemlerde bulunur. Teknik olarak her şey izleniyor gibi görünür; fakat iş kritik bir akış bozulduğunda ekipler hangi sinyale öncelik vereceğini bilemez. Bu yüzden ERP ortamında güçlü gözlemlenebilirlik, sadece daha fazla dashboard kurmak değildir. Asıl ihtiyaç, operasyon kararlarını hızlandıran bir kontrol odası modelidir. <figure <Image src={diagram} alt=\"ERP altyapılarında gözlemlenebilirlik kontrol odası katmanlarını gösteren teknik şema\" / <figcaption Kontrol odası yaklaşımı veri kaynaklarını tek yerde toplamak kadar, iş etkisini teknik sinyalle aynı konuşmaya taşımak için gereklidir.</figcaption </figure Neden klasik izleme yetmiyor? Çünkü ERP dünyasında sorunlar nadiren tek katmanda yaşanır. Kullanıcı tarafında \"sipariş onaylanmıyor\" şikâyeti gelir; altta ise entegrasyon kuyruğu dolmuştur, message consumer gecikmiştir, veritabanında belirli bir tablo kilidi uzamıştır ve batch işi normal süresini aşmıştır. Bu tabloyu yalnızca ayrı ayrı dashboard'larla takip etmek yeterli olmaz. Kontrol odası yaklaşımı şu soruya cevap verir: \"Şu anda hangi iş akışı risk altında ve bunu hangi teknik sinyaller destekliyor?\" Kontrol odası deyince neyi kastediyorum? Benim kullandığım model dört katmandan oluşur: 1. İş akışı görünümü 2. Servis ve entegrasyon sağlığı 3. Altyapı ve kapasite sinyalleri 4. Müdahale ve iletişim akışı Buradaki kritik nokta, metrikleri tek ekrana yığmak değil; iş etkisini teknik bağımlılıklarla ilişkilendirmektir. Örneğin \"fatura oluşturma gecikiyor\" sinyali, ilgili queue lag, API hata oranı ve veritabanı bekleme metriğiyle aynı bağlamda görünmelidir. Hangi akışlar merkezde olmalı? ERP ortamında her şeyi birincil panel yapmak hatadır. Kontrol odasında önce en kritik iş akışları seçilmelidir: Siparişten sevkiyata giden zincir Finans kapanış ve mutabakat işleri Stok güncelleme ve depo senkronizasyonu İK veya bordro gibi takvim bağımlı batch süreçleri Bu akışların her biri için \"normal çalışma bandı\" tanımlanırsa anomali çok daha erken fark edilir. <Callout type=\"tip\" title=\"İş akışını bilmeyen dashboard karar hızını düşürür\" ERP gözlemlenebilirliğinde en yaygın hata, herkesin kendi katmanını mükemmel izlemesi ama ortak iş akışının sağlığını kimsenin sahiplenmemesidir. </Callout Teknik sinyalleri nasıl eşlemeli? İyi bir kontrol odasında her iş akışının altında şu tip sinyaller bulunur: Gecikme ve kuyruk derinliği Başarı oranı ve hata sınıfları Bağımlı servis erişilebilirliği Veri tazeliği Batch penceresi uyumu Örneğin stok senkronizasyonu için yalnızca API yanıt süresi yeterli değildir. Son başarılı transfer zamanı, bekleyen mesaj sayısı ve hedef sistemdeki kabul oranı birlikte değerlendirilmelidir. Alarm tasarımı ayrı konu değil Kontrol odası modelinin en zayıf halkası çoğu zaman alarm yönlendirmesidir. Her eşik ihlalinin aynı nöbet kanalına düşmesi ERP ekiplerini çok hızlı yorar. Daha iyi model şu ayrımı yapar: Bilgilendirici sapmalar Operasyon müdahalesi gerektiren olaylar İş etkisi yaratmış kritik bozulmalar Bu sınıflandırma olmadan dashboard düzgün olsa bile incident akışı kaotik kalır. Veri kaynakları tek tedarikçiden gelmek zorunda değil Kurumsal yapılarda ERP platformu tek ürün üstüne kurulu olmayabilir. Metrikler Prometheus'ta, loglar başka yerde, APM farklı araçta, batch raporları ise uygulama veritabanında durabilir. Bu durum tek başına problem değildir. Problem, bu verilerin ortak sözlüğe bağlanmamasıdır. Benim önerim şu ortak alanları zorunlu kılmak: İş akışı adı Servis sahibi Ortam ve bölge Kritik seviye İlgili runbook veya müdahale bağlantısı Bu alanlar, araç çeşitliliği olsa bile operasyonda tek dil kurulmasını sağlar. Başarılı olduğunuzu nasıl anlarsınız? Bir ERP kontrol odasının değeri dashboard sayısıyla değil, müdahale kalitesiyle ölçülür. İyi sinyaller şunlardır: Sorun fark edilme süresi kısalır. İlk tanı için harcanan toplantı trafiği azalır. İş birimleriyle teknik ekip aynı olayı aynı kelimelerle tarif eder. Postmortem'lerde \"veri vardı ama birleştiremedik\" cümlesi seyrekleşir. Bu durum, gözlemlenebilirliğin rapor üretmekten çıkıp operasyon yönetişimine dönüştüğünü gösterir. Sonuç ERP altyapılarında gözlemlenebilirlik kontrol odası kurmak, daha parlak dashboard üretmek değil; iş akışı, teknik sinyal ve müdahale biçimini aynı modele bağlamaktır. Kritik süreçler etrafında tasarlanmış bir kontrol odası, hem incident yönetimini hızlandırır hem de kurumsal teknoloji mimarisinde görünmez bağımlılıkları açığa çıkarır. ERP gibi yüksek etkili sistemlerde gerçek gözlemlenebilirlik tam olarak budur: veri bolluğu değil, karar netliği.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "observability",
        "architecture",
        "operations",
        "enterprise"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-mesaj-kuyrugu-izolasyon-koridoru",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-mesaj-kuyrugu-izolasyon-koridoru",
      "title": "ERP Altyapılarında Mesaj Kuyruğu İzolasyon Koridoru",
      "summary": "ERP çekirdeği ile çevre sistemler arasındaki entegrasyon yükünü ayırmak için mesaj kuyruğu izolasyon yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; ERP altyapılarında en zor problemlerden biri, çekirdek işlem akışının çevre sistemlerin hızına ve kalitesine bağımlı kalmasıdır. Finans, lojistik, raporlama ve üçüncü taraf servisler aynı iş olayına farklı tempolarda tepki verir. Mesaj kuyruğu izolasyon koridoru, ERP çekirdeğini entegrasyon gürültüsünden ayırarak hem dayanıklılığı hem de değişim kabiliyetini artırır. İzolasyon koridoru neyi çözer? Klasik ERP entegrasyonlarında sipariş, fatura veya stok hareketi oluştuğunda aynı işlem sırasında birçok dış hedefe senkron çağrı yapılır. Bu tasarım ilk başta sade görünür; fakat bir hedef sistem yavaşladığında veya hata verdiğinde çekirdek ERP akışı da etkilenir. Sonuçta business transaction ile entegrasyon teslimatı aynı hata alanına sıkışır. İzolasyon koridoru yaklaşımı bu bağı şu şekilde gevşetir: ERP çekirdeği işi tamamlar ve dayanıklı bir olay kaydı üretir. Mesaj kuyruğu katmanı teslimatı zamandan bağımsızlaştırır. Tüketici grupları iş önceliğine göre ayrılır. Arızalı entegrasyon tek başına geri basınç üretir; çekirdeği kilitlemez. Bu sayede hata alanı küçülür ve sistem davranışı daha okunabilir hâle gelir. Koridor tasarımında ana ilke: tek kuyruk değil, kontrollü ayrışma Birçok kurum asenkron mimariye geçişi tüm olayları tek mesaj omurgasına atmak olarak yorumlar. Oysa iyi tasarım, kuyruk eklemekten çok doğru sınır koymaktır. Çünkü ERP olayları aynı öneme, aynı teslimat süresine ve aynı veri hassasiyetine sahip değildir. Pratikte şu ayrım yüksek değer üretir: 1. İşlemsel koridor : Gecikmeye duyarlı ama sınırlı tüketici seti olan akışlar 2. Analitik koridor : Veri çoğaltma ve raporlama için yüksek hacimli akışlar 3. Dış entegrasyon koridoru : Partner veya legacy sistemlere giden dayanıklı teslimatlar 4. Operasyon koridoru : Audit, bildirim ve gözlemlenebilirlik olayları Bu katmanlama, her arızanın her şeyi etkilemesini engeller. ERP çekirdeği ile olay kaydı arasındaki sınır İzolasyon koridorunun güvenilir olması için çekirdek veritabanı işlemi ile üretilen olay kaydı arasında açık bir teslimat modeli gerekir. En sık kullanılan desenlerden biri outbox yaklaşımıdır. İşlem başarılı olduğunda olay da dayanıklı biçimde kaydolur; sonra ayrı bir taşıyıcı bu kaydı kuyruk sistemine aktarır. Burada önemli olan soru şudur: olay ne zaman \"işlenmiş\" sayılacak? Cevap, entegrasyon hedefi başarıyla aldıktan sonra değil; ERP çekirdeği olay kaydını tutarlı biçimde yazdıktan sonra verilmelidir. Aksi halde dış sistem sorunu çekirdeğin başarı tanımını bozar. <Callout type=\"info\" title=\"Asenkron yapmak, garanti modelini açık yazmayı zorunlu kılar\" Entegre sistemlerin ne zaman yeniden deneneceği, ne zaman dead letter kuyruğa alınacağı ve ne zaman insan müdahalesi gerektireceği baştan tanımlanmalıdır. </Callout Tüketici izolasyonu nasıl kurulmalı? İzolasyon koridorunun başarısı yalnızca broker seçimine bağlı değildir. Asıl farkı tüketicilerin hata alanını ne kadar iyi ayırdığınız belirler. Özellikle ERP tarafında şu sorular kritiktir: Stok senkronizasyonu ile BI yükü aynı tüketici grubunda mı? Dış partner entegrasyonu başarısız olunca retry fırtınası çekirdeği etkiliyor mu? Dead letter kuyruğa düşen olaylar iş kritikliğiyle etiketleniyor mu? Aynı iş olayı farklı veri redaksiyon seviyeleriyle mi paylaşılıyor? Bu ayrım yapılmadığında kuyruk teknolojisi modern olsa bile operasyon davranışı eski kalır. Observability olmadan kuyruk mimarisi körleşir Mesaj kuyrukları çoğu zaman sistemin sağlığını saklar. Çünkü işlem başarılı görünür, fakat kuyruk gecikmesi sessizce büyür. Bu yüzden koridor tasarımında yalnızca throughput değil, iş etkisine yakın sinyaller de izlenmelidir: Kuyruk gecikmesi Tüketici başarısızlık oranı Dead letter birikimi Yeniden deneme yoğunluğu Olay tipine göre teslimat süresi Bu metrikler servis seviyesine bağlanmadığında ekipler \"broker ayakta\" yanılgısına düşer. Geçiş stratejisi nasıl olmalı? Büyük ERP altyapılarında tüm entegrasyonları bir anda asenkron koridora taşımak risklidir. En doğru geçiş, bağımlılığı en yüksek ama iş etkisi kontrol edilebilir akışlardan başlamaktır. Benim tercih ettiğim sıralama şöyledir: 1. Audit ve bildirim akışlarını ayırın. 2. Raporlama ve veri çoğaltma yükünü çekirdekten çıkarın. 3. Dış partner entegrasyonlarını ayrı retry politikalarıyla taşıyın. 4. Gecikmeye duyarlı işlemleri en son ele alın. Bu yaklaşım mimari kazancı erken gösterir ve çekirdek sistemin güvenini sarsmadan ilerler. Sonuç ERP altyapılarında mesaj kuyruğu izolasyon koridoru, yalnızca entegrasyon modernizasyonu değil; iş sürekliliği yatırımıdır. Çekirdek ERP akışını teslimat sorunlarından ayırdığınızda hem hata alanı küçülür hem de çevre sistemlerle değişim yapmak kolaylaşır. Kurumsal mimaride asıl değer, daha fazla mesaj üretmekte değil; hangi yükün hangi sınırda tutulacağını bilinçli seçmekte ortaya çıkar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "entegrasyon",
        "messaging",
        "sistem-mimarisi",
        "dayanıklılık"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-entegrasyonlarinda-idempotent-retry-koridoru",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-entegrasyonlarinda-idempotent-retry-koridoru",
      "title": "ERP Entegrasyonlarında İdempotent Retry Koridoru",
      "summary": "Tekrarlanan çağrıların veri tutarsızlığı üretmesini önleyen retry koridoru, ERP entegrasyonlarında dayanıklılığı artırır.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp entegrasyonlarinda idempotent retry koridoru diagram.svg'; ERP entegrasyonları kırılgan olduğunda sorun çoğu zaman ilk hatada değil, ikinci denemede başlar. Ağ kesintisi, uzak sistem timeout'u veya sıra birikmesi nedeniyle tekrar edilen çağrılar; siparişin iki kez açılmasına, faturanın tekrarlı oluşmasına veya stok mutabakatının bozulmasına yol açabilir. Bu yüzden retry mekanizması yalnızca dayanıklılık değil, veri doğruluğu mimarisidir. <figure <Image src={diagram} alt=\"ERP entegrasyonlarında retry koridoru ve idempotent işleme akışını gösteren teknik şema\" / <figcaption Retry akışını koridor hâline getirmek, tekrar denemeyi kontrollü ve izlenebilir kılar.</figcaption </figure Neden klasik retry mantığı ERP dünyasında yetmez? Birçok uygulama retry'i basitçe “başarısız olduysa yeniden dene” olarak uygular. Fakat ERP sistemleri genellikle durum tutan, yan etki üreten ve işlem geçmişini sıkı denetleyen ortamlardır. Çağrı hedefe ulaşıp yanıt dönmediyse, istemci başarısızlık görürken arka tarafta kayıt çoktan oluşmuş olabilir. Bu nedenle retry kararı, sadece ağ hatasına verilen tepki değil; işlemin iş anahtarı, yan etki tipi ve uzlaştırma yeteneğiyle birlikte ele alınmalıdır. Retry koridoru neyi ifade eder? Ben retry koridorunu, tekrar denemelerin rastgele uygulama kodunda değil ortak bir güvenlik alanında yürütülmesi olarak düşünüyorum. Bu koridor tipik olarak şu sorumlulukları taşır: İdempotency key üretimi ve saklanması İlk denemenin durumunu izleme Gecikmeli yeniden deneme politikası Zehirli mesaj ayrıştırması Manuel uzlaştırma kuyruğu Bu yapı sayesinde aynı entegrasyon davranışı farklı ekiplerde farklı biçimde yeniden yazılmaz. Kurumsal mimaride standartlaşma tam burada değer üretir. <Callout type=\"tip\" title=\"Retry koridoru entegrasyon katmanının fren sistemidir\" Amaç her hatayı otomatik çözmek değil; hangi hatanın güvenle tekrar edileceğini ve hangisinin insan müdahalesi gerektirdiğini ayırmaktır. </Callout İdempotency key nasıl seçilmeli? En sık hata, idempotency key'i teknik istek kimliğiyle sınırlamaktır. Daha doğru yaklaşım iş anlamını taşıyan birleşik anahtarlar kullanmaktır. Örneğin: Sipariş numarası + işlem tipi Fatura numarası + versiyon Kaynak sistem olay kimliği + hedef kayıt türü Bu sayede ağ yeniden denemesi ile gerçekten yeni bir iş olayı birbirinden ayrılır. Aksi hâlde sistem teknik olarak dayanıklı görünür ama iş verisi sessizce bozulur. Gözlemlenebilirlik neden tasarımın merkezinde? Retry davranışı görünmüyorsa güven vermez. Koridorun şu sinyalleri üretmesi gerekir: Bekleyen retry sayısı Maksimum deneme eşiğine takılan kayıtlar İşlem türüne göre tekrar oranı Uzlaştırma kuyruğuna düşen iş yüzdesi Bu metrikler sadece operasyon ekibine değil, entegrasyon mimarisinin sağlığına da ayna tutar. Özellikle ay sonu ERP yoğunluklarında hangi bağlantıların sistematik olarak kırıldığını bu yüzeyden okuyabilirsiniz. Hangi durumlarda otomatik retry yapılmamalı? Her hata geçici değildir. Aşağıdaki durumlar genellikle otomatik tekrar için kötü adaydır: Şema veya zorunlu alan hatası Yetki ve sertifika problemi İş kuralı ihlali Sürüm uyumsuzluğu Bu tip durumlarda agresif retry yalnızca kuyruk doldurur ve gerçek problemi gizler. Koridorun asıl olgunluğu, tekrar etmek kadar durmayı da bilmesidir. Kurumsal uygulama modeli Pratikte şu katmanlı model işe yarar: 1. API veya mesaj girişinde idempotency key doğrulaması 2. Durum deposunda ilk denemenin kaydı 3. Retry scheduler ile gecikmeli deneme 4. Dead letter veya uzlaştırma kuyruğu 5. Dashboard ve incident alarm yüzeyi Bu akış, ERP entegrasyonlarını sadece “çalışıyor mu” seviyesinden “tekrar bozulduğunda da kontrollü mü” seviyesine çıkarır. Sonuç ERP entegrasyonlarında idempotent retry koridoru, dayanıklılık ile veri bütünlüğünü aynı tasarımda buluşturur. Tekrar denemeyi uygulama içindeki dağınık reflekslerden çıkarıp ortak mimari yüzeye taşıdığınızda; hatalar daha az gizlenir, operasyon daha hızlı toparlanır ve kurumsal veri güveni belirgin biçimde artar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "integration",
        "reliability",
        "architecture",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-dns-firewall-ile-segment-bazli-cozumleme",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-dns-firewall-ile-segment-bazli-cozumleme",
      "title": "Kurumsal Ağlarda DNS Firewall ile Segment Bazlı Çözümleme",
      "summary": "Çözümleme akışını segment bazında ayırarak kötüye kullanım riskini, veri sızıntısını ve operasyonel kör noktaları azaltan DNS mimarisi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal aglarda dns firewall ile segment bazli cozumleme diagram.svg'; Kurumsal ağlarda DNS çoğu zaman yalnızca bir yardımcı servis gibi görülür; oysa saldırgan için de operasyon ekibi için de en kritik kontrol noktalarından biridir. Aynı çözümleme katmanını kullanıcı ağı, veri tabanı segmenti, yönetim ağı ve entegrasyon koridoru için ortak kullanmak kısa vadede sade görünür; fakat zamanla hem görünürlük hem güvenlik hem de hata ayıklama kalitesi bozulur. Sağlıklı yaklaşım, çözümleme davranışını segment bazında tanımlamak ve bunu bir DNS firewall politikasıyla desteklemektir. <figure <Image src={diagram} alt=\"Kurumsal ağlarda segment bazlı çözümleme ve DNS firewall karar noktalarını gösteren teknik şema\" / <figcaption DNS katmanı yalnızca isim çözmez; hangi segmentin nereye güveneceğini de belirler.</figcaption </figure Neden ortak çözümleme katmanı zamanla risk üretir? Çünkü her segmentin çözümleme ihtiyacı aynı değildir. Kullanıcı ağı internet tabanlı SaaS hedeflerine sık giderken, ERP uygulama katmanı iç servis kayıtlarına ve entegrasyon uçlarına bağımlıdır. Yönetim ağı ise daha sınırlı ama daha hassas isimleri çözmek zorundadır. Bu farklılıklar tek cache, tek policy ve tek log akışında toplandığında şu problemler büyür: Gereksiz geniş izin alanları oluşur. Yanlış yapılandırılmış istemciler problemi bütün ağı etkiler. Şüpheli sorgular hangi segmentten geldi diye sonradan araştırmak zorlaşır. İç isimler ile dış isimlerin yaşam döngüsü birbirine karışır. Sonuçta DNS katmanı çalışıyor görünse bile aslında güven sınırlarını bulanıklaştırır. Segment bazlı çözümleme ne demektir? Bu yaklaşım her VLAN ya da subnet için fiziksel olarak ayrı resolver kurmak anlamına gelmez. Esas fikir, çözümleme davranışını segmentin güven profiline göre ayırmaktır. Bunu üç ana katmanda düşünmek daha doğrudur: 1. İstemci sınıfı : Kullanıcı, sunucu, yönetim, entegrasyon veya üretim dışı ortam. 2. Policy katmanı : Hangi segment hangi zone'a, hangi forwarder'a ve hangi kayıt tiplerine erişebilir. 3. Denetim katmanı : Şüpheli sorgu örüntüsü, veri sızıntısı riski ve politika ihlali için kayıt ve alarm üretimi. Bu modelde firewall yalnızca IP seviyesinde değil, isim çözümleme davranışı seviyesinde de çalışır. DNS firewall burada tam olarak ne yapar? DNS firewall kavramı çoğu zaman yalnızca tehdit istihbaratıyla engellenen domain listeleri olarak anlaşılır. Oysa kurumsal kullanımda daha geniş bir role sahiptir: Segmentin yetkili olmadığı zone sorgularını reddeder. Veri sızıntısı riski taşıyan anormal kayıt tiplerini sınırlar. Yüksek hacimli veya tünelleme benzeri sorgu davranışını işaretler. Çözümleme akışını iç resolver, özel forwarder veya internet çıkışı arasında yönlendirir. Bu yüzden DNS firewall, geleneksel ağ güvenliği ile servis keşfi arasında duran bir karar noktasıdır. <Callout type=\"tip\" title=\"Tüm DNS loglarını eşit değerli saymayın\" Yönetim ağı ve ERP entegrasyon katmanından gelen sorgular genellikle kullanıcı uçlarından daha düşük hacimli ama daha yüksek önemde olur. Alarm eşiğini buna göre ayarlamak gerekir. </Callout ERP ve kurumsal uygulamalar için neden kritik? ERP ekosistemlerinde çözümleme akışı yalnızca uygulamanın ayağa kalkmasıyla ilgili değildir. Dış entegrasyon uçları, lisans servisleri, dosya aktarım hedefleri, raporlama katmanları ve yedek bağımlılıklar aynı isim çözümleme düzleminden geçer. Eğer entegrasyon segmenti serbest internet çözümlemesine açıksa şu sorunlar ortaya çıkar: Onaylı olmayan hedeflere sessiz trafik akışı başlayabilir. Uygulama ekibi ağ problemi ile DNS policy problemini ayıramaz. Felaket kurtarma testlerinde beklenmeyen dış bağımlılıklar görünür. Değişiklik sonrası cache etkileri yanlış kök neden analizine yol açar. Bu nedenle çözümleme politikası, ERP mimarisinin görünmeyen ama etkili bir kontrol yüzeyidir. Sağlıklı tasarım ilkeleri Benim pratikte en işe yarar gördüğüm yaklaşım şu ilkelerden oluşuyor: Kullanıcı, sunucu ve yönetim segmentleri için ayrı çözümleme policy grupları oluşturun. İç zone çözümlemesini dış internet resolver'larıyla karıştırmayın. Resolver loglarını segment etiketiyle merkezi telemetry hattına taşıyın. Kritik segmentlerde yalnızca izin verilen kayıt tiplerini ve forwarder hedeflerini açın. DNS cache davranışını incident analizine yardımcı olacak şekilde gözlemleyin. Buradaki amaç aşırı parçalanmış altyapı kurmak değil, davranışı okunabilir kılmaktır. Operasyon tarafında hangi kazanımı sağlar? Segment bazlı çözümleme modeli güvenliği artırdığı kadar operasyonu da sadeleştirir. Örneğin bir uygulama ekibi \"servis bulunamıyor\" dediğinde artık şu sorular daha hızlı cevaplanır: İstemci yanlış segmentten mi geliyor? Yetkisiz zone sorgusu mu yapıyor? İç resolver doğru hedefe forward ediyor mu? Sorun cache etkisi mi yoksa yetkili DNS katmanı mı? Bu görünürlük, ağ ekibi ile platform ekibi arasındaki klasik \"bizde problem yok\" döngüsünü ciddi biçimde azaltır. Sonuç Kurumsal ağlarda DNS firewall ile segment bazlı çözümleme, yalnızca güvenlik ürünü eklemek değil; çözümleme davranışını kurumsal mimarinin aktif bir parçası hâline getirmektir. Segmentin ihtiyacı, güven profili ve denetim gereksinimi birlikte tasarlandığında DNS katmanı daha sessiz ama daha güçlü çalışan bir kontrol yüzeyine dönüşür. Özellikle ERP, yönetim ve entegrasyon ağlarında bu yaklaşım hem riski düşürür hem teşhis süresini kısaltır.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "security",
        "dns",
        "architecture",
        "enterprise"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-slo-tabanli-kapasite-rezervasyonu",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-slo-tabanli-kapasite-rezervasyonu",
      "title": "Kurumsal Bulutta SLO Tabanlı Kapasite Rezervasyonu",
      "summary": "Kapasite kararlarını sadece ortalama kullanım yerine hizmet hedeflerine bağlayan bulut mimarisi yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal bulutta slo tabanli kapasite rezervasyonu diagram.svg'; Kurumsal bulut mimarisinde kapasite planlama çoğu zaman iki kötü uç arasında sıkışır: ya gereğinden fazla rezerv alınır ve maliyet şişer ya da ortalama kullanım rakamlarına fazla güvenilip kritik anda performans daralması yaşanır. Oysa kapasiteyi anlamlı yöneten soru CPU ortalaması değil, hizmet hedefinin hangi yük davranışını garanti etmesi gerektiğidir. SLO tabanlı kapasite rezervasyonu tam bu ayrımı görünür kılar. <figure <Image src={diagram} alt=\"SLO, rezerv kapasite ve maliyet dengesini gösteren teknik şema\" / <figcaption Kapasiteyi yalnızca kaynak değil, söz verilen hizmet davranışı üzerinden okumak gerekir.</figcaption </figure Ortalama kullanım neden yanıltıcıdır? Çünkü kurumsal sistemlerde yük eşit dağılmaz. ERP entegrasyonları gün sonu yığılabilir, self service platform akşam pipeline patlaması yaşayabilir, güvenlik taramaları belirli pencerelerde ani dalga üretebilir. Ortalama kullanım grafiği sakin görünürken kuyruk gecikmesi veya hata oranı kritik eşikleri sessizce aşabilir. Bu yüzden kapasite kararını sadece yüzde kullanım üzerinden almak, maliyet optimizasyonu gibi görünse de gerçekte riskin görünmez şekilde taşınmasıdır. SLO kapasite rezervasyonuna nasıl bağlanır? SLO, sistemin ne kadar hızlı ve güvenilir davranması gerektiğini söyler. Kapasite rezervasyonu ise bu hedefi taşıyacak güvenlik payını belirler. İkisini birlikte düşündüğünüzde şu çerçeve oluşur: İzin verilen gecikme ve hata bütçesi tanımlanır. Bu hedefleri bozan yük paternleri çıkarılır. Yüksek etkili pikler için rezerv kapasite sınıfı ayrılır. Düşük öncelikli iş yükleri geri bastırma veya sıraya alma ile yönetilir. Yani rezerv kapasite, “boşta duran pahalı kaynak” olmaktan çıkar; hizmet vaadini koruyan operasyonel tampon hâline gelir. <Callout type=\"tip\" title=\"Her servise aynı güvenlik payını vermeyin\" Kullanıcıya doğrudan etki eden API ile gecikmeyi tolere eden batch işinin aynı rezerv politikasına sahip olması rasyonel değildir. </Callout Mimari olarak hangi katmanlarda uygulanır? Kurumsal bulutta SLO tabanlı rezervasyon tek bir servis ayarı değildir. Genellikle üç katmanda kurulur: 1. Hesaplama katmanı: node pool, autoscaling sınırı, reserved instance veya committed use planı 2. Veri katmanı: bağlantı havuzu, IOPS tavanı, replika stratejisi 3. Ağ ve kenar katmanı: egress kapasitesi, load balancer eşikleri, rate limit politikası Bu katmanlardan biri ihmal edildiğinde kapasite sorunu başka yüzeyde tekrar ortaya çıkar. Örneğin uygulama katmanında autoscaling çalışırken veri tabanı bağlantı tavanı sabit kalıyorsa, görünürde kapasite artar ama kullanıcı deneyimi bozulur. FinOps ile operasyon aynı masada nasıl buluşur? Burada kritik nokta, maliyet optimizasyonunu sadece “daha az kaynak tüket” söyleminden çıkarmaktır. Daha doğru yaklaşım şudur: Hangi kapasite rezervi SLO'yu koruyor? Hangi rezerv yalnızca varsayım rahatlığı sağlıyor? Hangi yük ertelenebilir veya farklı zaman penceresine kaydırılabilir? Bu sorular sayesinde FinOps ekibi maliyet azaltırken kör kesinti riski yaratmaz, platform ekibi de her ek güvenlik payını savunmak zorunda kalmaz. Dil ortaklaşır. Pratikte işe yarayan karar modeli Benzer yapılarda şu karar matrisi verimli çalışır: Kritik müşteri akışı: yüksek rezerv, agresif gözlem, düşük tolerans İç operasyon servisi: orta rezerv, kontrollü kuyruklama Batch veya raporlama: düşük rezerv, planlı geri basınç Geçici deney ortamı: minimum rezerv, sert kota Bu sınıflandırma, kapasiteyi iş etkisiyle hizalar. Böylece her sistem için aynı tartışmayı baştan yapmak gerekmez. Başarı nasıl ölçülür? Sadece maliyet düşüşü başarı sayılmamalı. Bence şu üç sinyal birlikte izlenmeli: Pik trafik anlarında SLO ihlali sıklığı Kapasite artış taleplerinin tahmin doğruluğu Atıl rezerv ile kesinti önleme etkisi arasındaki oran Eğer kapasite planı bu sinyalleri birlikte iyileştiriyorsa mimari işe yarıyor demektir. Sonuç Kurumsal bulutta SLO tabanlı kapasite rezervasyonu, klasik kapasite planlamayı hizmet odaklı hâle getirir. Kaynağın ne kadar kullanıldığı kadar, neyin garanti edildiği de görünür olur. Sonuçta daha pahalı değil, daha bilinçli bir kapasite modeli kurulur; bu da hem bulut maliyetini hem kurumsal güveni daha yönetilebilir kılar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "cloud",
        "slo",
        "capacity-planning",
        "architecture",
        "finops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-cloudda-paylasimli-servis-vpc-karar-matrisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-cloudda-paylasimli-servis-vpc-karar-matrisi",
      "title": "Kurumsal Cloud’da Paylaşımlı Servis VPC Karar Matrisi",
      "summary": "DNS, egress, güvenlik ve gözlem servislerini tek VPC'de toplamanın ne zaman doğru olduğunu açıklayan mimari çerçeve.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal cloud mimarilerinde paylaşımlı servis VPC fikri çok hızlı kabul görür. Merkezi DNS resolver, egress kontrolü, inspection katmanı, ortak observability ajanları ve kimlik köprüleri tek yerde toplandığında ilk bakışta düzen artar. Fakat yanlış kurulduğunda bu model, platform kolaylığı yerine yeni bir merkezi darboğaz üretir. Bu yüzden paylaşımlı servis VPC kararı, alışkanlıkla değil açık bir mimari matrisle verilmelidir. Paylaşımlı servis VPC ne zaman anlamlıdır? Her ortak bileşen merkezi olmak zorunda değildir. Benim kullandığım temel test şudur: ilgili servis, ürün ekiplerinin bağımsız sahipliğini zayıflatmadan ortak güvenlik veya ağ davranışı sağlayabiliyor mu? Eğer cevap evetse paylaşımlı VPC mantıklı olabilir. Eğer ekipler her küçük değişiklikte merkezi takıma bağımlı kalıyorsa, tasarım hedefini kaçırmışsınız demektir. Özellikle şu servis sınıfları bu modele daha uygundur: Kurumsal DNS forwarder veya resolver katmanları İnternet egress inspection ve politika geçitleri Ortak sertifika ve kimlik köprü servisleri Merkezi gözlemlenebilirlik toplayıcıları Buna karşılık uygulamaya özgü proxy, cache veya veri işleme bileşenleri genelde ürün VPC sınırında kalmalıdır. Karar matrisi hangi eksenlerden oluşmalı? Paylaşımlı servis VPC kararını \"merkeziyse tek yere alalım\" mantığıyla vermek zayıf sonuç üretir. Sağlam çerçeve için en az dört ekseni birlikte düşünmek gerekir: 1. Bağımlılık yoğunluğu : Kesilirse kaç ürün etkilenir? 2. Politika gerekliliği : Ortak zorunluluk var mı, yoksa rahatlık mı sağlıyor? 3. Değişim frekansı : Servis sık mı değişiyor? 4. Hata alanı : Arıza olursa blast radius ne kadar büyür? Bu matris, ağ topolojisini yönetişim ihtiyacıyla birlikte değerlendirmenizi sağlar. En sık yapılan hata: ortak olan her şeyi merkezi ağdan geçirmek Kurumsal ortamlarda güvenlik ve uyum baskısı arttıkça tüm egress, tüm DNS ve bazen iç servis trafiği bile merkezi VPC üzerinden geçmeye başlar. Sonuçta görünürde kontrol artar, fakat gizli maliyetler büyür: Latency ve ağ saçılımı artar. Uygulama takımlarının hata ayıklama yeteneği düşer. Merkezi ağ bileşeni her değişiklikte koordinasyon yükü üretir. Bir arıza çok sayıda ekibi aynı anda etkiler. Merkezileştirme ile standardizasyon aynı şey değildir. Standardı politika ve referans mimariyle sağlamak çoğu zaman daha sağlıklıdır. <Callout type=\"warning\" title=\"Ortak servis ile zorunlu transit katmanı aynı karar değildir\" Bir servisi ortak işletmek, bütün trafiği tek ağ boğazından geçirmek anlamına gelmez. İki kararı ayrı değerlendirmek gerekir. </Callout İyi tasarım için pratik ilkeler Paylaşımlı servis VPC kullanıyorsanız aşağıdaki ilkeler mimariyi daha sürdürülebilir yapar: Ürün VPC'leri ile ortak servisler arasındaki sözleşmeyi açık yazın. Zorunlu trafiği ve isteğe bağlı tüketimi ayrı tutun. Her ortak servis için fallback veya bypass stratejisi tasarlayın. Gözlem sinyallerini yalnızca merkezi ekip değil ürün ekibi de görebilsin. Bu yaklaşım, platform ekibini tek kapı bekçisine çevirmeden ortak kontrol sağlar. Operasyon ve güvenlik açısından ne izlenmeli? Paylaşımlı VPC tasarımının sağlıklı çalışması için yalnızca ağ bağlantısı değil davranış metrikleri izlenmelidir: Resolver gecikmesi ve hata oranı Egress politika reddi ve istisna oranı Transit bağımlılığı olan ürün servis sayısı Ortak servis değişikliği sonrası etkilenen domain sayısı Bu metrikler sayesinde merkezi bileşenin gerçekten çarpan mı yoksa kırılganlık kaynağı mı olduğu görünür olur. Sonuç Kurumsal cloud ortamında paylaşımlı servis VPC kararı, ağ diyagramı tercihi olmaktan çok sahiplik ve blast radius tasarımıdır. Ortak güvenlik ve ağ davranışını açık sözleşmelerle sunabildiğiniz noktada bu model ciddi değer üretir. Fakat her ortak servisi merkezi bağımlılığa çevirdiğiniz anda platform tasarımı hızlandırıcı olmaktan çıkar. Doğru karar matrisi, hangi servisin gerçekten merkezde kalması gerektiğini sakin biçimde ayırmanızı sağlar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "cloud",
        "network",
        "platform-engineering",
        "sistem-mimarisi",
        "security"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-sertifika-yasam-dongusu-mimarisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-sertifika-yasam-dongusu-mimarisi",
      "title": "Kurumsal Platformlarda Sertifika Yaşam Döngüsü Mimarisi",
      "summary": "TLS sertifikalarını dosya yenileme işi olmaktan çıkarıp kurumsal platform bileşeni hâline getiren mimari yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal platformlarda sertifika yasam dongusu mimarisi diagram.svg'; Kurumsal platformlarda sertifika yönetimi uzun süre görünmez bir yan iş gibi yaşar. Uygulama ayağa kalkınca bir wildcard alınır, ters proxy'ye yüklenir, süresi dolunca biri yeniler ve hayat devam ediyormuş gibi görünür. Ölçek büyüdüğünde bu model sessizce çöker. Çünkü sertifika artık sadece HTTPS açan dosya değildir; servis kimliği, makine güveni, ortam ayrımı, otomasyon disiplini ve olay etkisiyle doğrudan ilgilidir. Bu yüzden sertifika yaşam döngüsü başlı başına bir platform mimarisi konusu olarak ele alınmalıdır. <figure <Image src={diagram} alt=\"Kurumsal platformlarda sertifika yaşam döngüsü mimarisini gösteren teknik şema\" / <figcaption Sertifikayı bir dosya değil, üretimden iptale kadar yönetilen bir platform varlığı gibi ele almak kurumsal ölçekte kırılganlığı azaltır.</figcaption </figure Problem neden büyür? Çünkü sertifika sayısı artarken sahiplik modeli aynı olgunlukta büyümez. Bir süre sonra kurumda şu tablo oluşur: Hangi sertifikanın hangi servise ait olduğu tam bilinmez. Yenileme akışının manuel mi otomatik mi olduğu değişkendir. Özel anahtarların nerede tutulduğu tutarsızdır. mTLS kullanan servislerle public edge sertifikaları aynı yaklaşımla yönetilir. Bu koşullarda sertifika süresi dolması yalnızca operasyon hatası değil, mimari eksiklik belirtisidir. Yaşam döngüsü hangi aşamalardan oluşur? Benim pratikte kullandığım çerçeve altı aşamalıdır: 1. Talep ve politika kararı 2. Üretim ve imzalama 3. Dağıtım ve ilişkilendirme 4. Döndürme ve yenileme 5. İptal ve acil müdahale 6. Envanter ve denetim Kurumların çoğu ilk üç adımı bir şekilde yapar; fakat son üç adım eksik olduğu için sertifika yönetimi güvenilir olmaz. Aynı sertifika modeli her yerde çalışmaz Edge katmanı, iç servis kimliği, insan erişimi ve cihaz sertifikaları farklı ihtiyaçlar taşır. Bu yüzden tek PKI anlatısı yerine kullanım sınıfı bazlı ayrım gerekir: Dış yüzey TLS sertifikaları İç servisler için kısa ömürlü mTLS sertifikaları Yönetim erişimi için kullanıcı veya cihaz sertifikaları Batch ya da entegrasyon iş yükleri için makine kimliği Bu sınıflar ayrışmadığında yenileme takvimi, güven sınırı ve iptal etkisi birbirine karışır. <Callout type=\"tip\" title=\"Süre kısaldıkça otomasyon zorunlu hâle gelir\" Kısa ömürlü sertifikalar güvenliği artırır; fakat sadece üretim, dağıtım ve rotasyon zinciri gerçekten otomatikse. </Callout Mimari omurga nasıl kurulmalı? Sağlıklı modelde şu parçalar bulunur: Politika motoru veya onay kuralı Kurumsal CA ya da güvenilir imzalama otoritesi Sır kasası veya anahtar koruma katmanı Runtime dağıtım mekanizması Envanter ve olay kaydı Burada kritik karar, sertifika üretimini CI işi gibi mi, platform servisi gibi mi yönettiğinizdir. Ben ikinci yaklaşımı daha doğru buluyorum. Çünkü sertifika yaşam döngüsü uygulama deploy'undan bağımsız olaylar da içerir. En sık yapılan yanlışlar Kurumsal ekiplerde tekrar eden dört hata görüyorum: Ortamlar arasında aynı wildcard kullanımına güvenmek Sertifika yenilemeyi cron başarısına bırakmak Sertifika sahibini takım yerine kişiyle eşlemek İptal senaryosunu hiç test etmemek Bu hatalar normal günlerde görünmez; ilk güvenlik olayı, CA değişimi veya yanlış dağıtım anında çok pahalıya çıkar. Ölçülebilir başarı sinyalleri Sertifika mimarisinin olgunlaştığını şu sinyallerden anlarsınız: Envanter dışı sertifika oranı düşer. Manuel yenileme ihtiyacı azalır. mTLS veya servis kimliği dağıtımı uygulama ekipleri için daha sade hâle gelir. Yaklaşan süre sonları incident seviyesine dönüşmeden çözülür. Acil iptal sonrası yeniden dağıtım süresi ölçülebilir olur. Bu metrikler sertifikanın gerçekten platform kabiliyetine dönüştüğünü gösterir. Kurumsal iletişim boyutu Sertifika konusu teknik görünür; fakat etkisi kurumsaldır. Bir sertifika yenileme penceresi API tüketicilerini, mobil istemcileri, üçüncü taraf entegrasyonları ve iç operasyon ekiplerini aynı anda etkileyebilir. Bu yüzden yaşam döngüsü mimarisinin bir parçası da değişiklik iletişimidir. Hangi sertifika sınıfında ne kadar önceden duyuru gerektiği, hangi ekiplerin etkilenebileceği ve geri dönüş planının ne olduğu baştan tanımlanmalıdır. Sonuç Kurumsal platformlarda sertifika yaşam döngüsü mimarisi, güvenlik ekibinin arka ofis işi değildir. Bu alan; platform mühendisliği, otomasyon, servis kimliği ve kurumsal sürekliliğin ortak kesişimidir. Sertifikayı dosya değil, yaşam döngüsü olan bir varlık olarak yönettiğinizde hem kesinti riskini azaltır hem de platformun güven sınırlarını daha temiz kurarsınız. Ölçek büyüdükçe doğru soru \"sertifikayı kim yeniliyor\" değil, \"sertifika mimarisi hangi ilkeyle yaşıyor\" olur.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "security",
        "tls",
        "platform-engineering",
        "automation",
        "cloud"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/bird-2-ile-route-reflector-lab-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/bird-2-ile-route-reflector-lab-tasarimi",
      "title": "Bird 2 ile Route Reflector Lab Tasarımı",
      "summary": "Kurum içi BGP topolojilerini güvenli biçimde denemek için Bird 2 tabanlı route reflector laboratuvarı kurulumu.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; BGP topolojilerinde route reflector davranışını üretimde öğrenmek pahalıdır. Özellikle spine leaf, edge veya veri merkezi geçişlerinde küçük bir yansıma hatası geniş bir yönlendirme etkisi doğurabilir. Bird 2 ile route reflector lab tasarımı, bu davranışları düşük maliyetle test etmek ve karar mantığını net görmek için güçlü bir yöntemdir. Lab hedefi Bu rehberde üç istemci router ve iki route reflector düğümünden oluşan sade bir BGP laboratuvarı kuracağız. Amaç, production ölçeğini taklit etmek değil; şu davranışları doğrulamaktır: Route reflector cluster yapısı Client ve non client oturum farkı Route yayılımının doğrulanması Failover anında adjacency ve route davranışı Lab'ı container veya VM üzerinde kurabilirsiniz. Bird 2 hafif olduğu için küçük test ortamlarında rahat çalışır. Topoloji Örnek topoloji şu mantıkla ilerler: 1. rr1 ve rr2 route reflector olarak görev yapar. 2. leaf1, leaf2 ve edge1 istemci router rolündedir. 3. Tüm düğümler aynı private lab ağı üzerinde BGP komşuluğu kurar. Basit bir adresleme örneği: Bu örnekte iBGP kullanıyoruz. Route reflector mantığını görmek için bu yeterli. Bird 2 kurulumu Debian veya Ubuntu tabanlı bir sistemde: Servis dosyası kurulduktan sonra ana konfigürasyon tipik olarak /etc/bird/bird.conf altında bulunur. İlk aşamada her düğüm için farklı dosya üreterek ilerlemek daha okunabilir olur. Route reflector düğümü için örnek konfigürasyon rr1 üzerinde sade bir örnek: İkinci reflector için benzer yapı kurulabilir. İki reflector kullanmak, tek düğüm arızasında rotaların nasıl davrandığını görmek açısından önemlidir. <Callout type=\"tip\" title=\"Lab'da cluster id açık yazın\" Bird varsayılan davranışı anlamlıdır, fakat route reflector lab'ında cluster id değerini bilinçli vermek topoloji etkilerini okumayı kolaylaştırır. </Callout İstemci router örneği leaf1 için sade bir istemci konfigürasyonu: Bu tanım, istemcinin kendi static rotasını reflectorlara duyurmasını sağlar. Doğrulama adımları Konfigürasyon sonrası şu kontrolleri yapın: Beklenen davranışlar: Tüm BGP oturumları Established görünmeli leaf2 ve edge1, leaf1 kaynaklı prefix'i reflectorlardan öğrenmeli Reflector düğümünde route origin ve next hop bilgisi okunabilir olmalı Sonra rr1 servisini durdurup rr2 üzerinden route sürekliliğini test edebilirsiniz. Lab'ı değerli kılan genişletmeler Temel akış çalıştıktan sonra lab'a şu denemeleri eklemek faydalıdır: Local pref farkı Route map veya filter kullanımı next hop self davranışı Reflector dışı peer ile non client dağıtımı Bu deneyler, üretim geçişinde dokümantasyon okumaktan çok daha net içgörü sağlar. Sonuç Bird 2 ile route reflector lab tasarımı, BGP davranışını küçük ve denetlenebilir bir ortamda görünür kılar. Özellikle kurumsal ağ modernizasyonu, veri merkezi segmentasyonu veya edge yönlendirme kararları öncesinde bu tür bir lab, pahalı sürprizleri azaltır. Önemli olan mükemmel laboratuvar kurmak değil; hangi route kararının neden oluştuğunu güvenli biçimde gözleyebilmektir.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "network",
        "bgp",
        "bird",
        "lab",
        "altyapı"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/envoy-ext-authz-ile-ic-api-yetkilendirme-zinciri",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/envoy-ext-authz-ile-ic-api-yetkilendirme-zinciri",
      "title": "Envoy ext_authz ile İç API Yetkilendirme Zinciri",
      "summary": "İç servis trafiğinde kimlik, politika ve karar kaydını ayırmak için Envoy ext_authz filtresiyle kurulabilecek güvenli yetkilendirme hattı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './envoy ext authz ile ic api yetkilendirme zinciri diagram.svg'; İç API'lerde en sık görülen güvenlik hatası, kimlik doğrulama ile yetkilendirmeyi aynı uygulama koduna gömüp zamanla her serviste farklı davranış üretmektir. Bir servis JWT'yi sadece imzaya göre kabul eder, diğeri claim kontrolü yapar, bir başkası ise kullanıcı yerine servis kimliğini yorumlar. Envoy'un ext authz filtresi burada pratik bir ara katman sunar: istek önce proxy'de karşılanır, karar ayrı bir yetkilendirme servisine sorulur, uygulama ise sadece iş mantığına odaklanır. <figure <Image src={diagram} alt=\"Envoy ext authz ile iç API yetkilendirme zincirini gösteren teknik şema\" / <figcaption Proxy üzerinde ortak güvenlik kontrolü kurmak, uygulama kodundaki dağınık yetki kararlarını azaltır.</figcaption </figure Hangi problem çözülüyor? İç ağda çalışan servisler çoğu zaman \"zaten güvenli bölgedeyiz\" varsayımıyla büyür. Sonra entegrasyon sayısı arttığında şu sorunlar belirir: Aynı kimlik farklı servislerde farklı haklarla yorumlanır. Politika değişikliği için tüm servisleri ayrı ayrı yayınlamak gerekir. İstek reddedildiğinde kararın neden alındığı merkezi olarak görülemez. Operasyon ekibi 403 hatasının ağ mı, token mı, politika mı kaynaklı olduğunu ayırt edemez. ext authz modeli bu yüzden yalnızca güvenlik değil, operasyonel okunabilirlik de sağlar. Hedef mimari Temel akış şöyledir: 1. İstemci isteği Envoy'a gelir. 2. Envoy istek metadatasını ext authz servisine yollar. 3. Yetkilendirme servisi kimliği ve politikayı değerlendirir. 4. Envoy isteği geçirir ya da reddeder. 5. Karar kaydı merkezi log veya metric hattına düşer. Bu modelde uygulama servisi, isteğin yetki açısından önceden filtrelenmiş olduğunu varsayabilir. Minimal Envoy yapılandırması Aşağıdaki örnek, HTTP filtre zincirinde ext authz kullanımını gösterir: Buradaki kritik tercih failure mode allow: false ayarıdır. Yetkilendirme servisiniz cevap veremiyorsa isteği geçirmek değil, kontrollü biçimde reddetmek daha güvenlidir. Fakat bu kararın operasyon etkisini de baştan planlamak gerekir. Yetkilendirme servisi neye bakmalı? ext authz servisini mümkün olduğunca küçük ama net sorumluluklu tasarlamak gerekir. Ben şu alanları temel kabul ediyorum: İstek yapanın servis ya da kullanıcı kimliği Hedef yol, metod ve tenant bağlamı Gerekli rol veya politika adı Kararın neden alındığını gösteren kısa neden kodu Bu servisin doğrudan iş mantığına girmesi yanlış olur. Sipariş limiti, kampanya kuralı veya müşteri segmenti gibi alanlar uygulamanın sorumluluğunda kalmalı; ext authz katmanı erişim kararıyla sınırlı olmalıdır. <Callout type=\"tip\" title=\"403 yeterli değil, neden kodu şart\" Reddedilen isteğin yalnızca HTTP durumu görünüyorsa operasyon ekibi kör kalır. Karar kaydında token expired, policy denied veya tenant mismatch gibi kısa kodlar tutmak teşhisi hızlandırır. </Callout Test akışı nasıl kurulmalı? Bu hattı canlıya almadan önce üç senaryoyu otomatikleştirin: Geçerli kimlikle izin verilen istek Geçerli kimlikle reddedilmesi gereken istek Yetkilendirme servisi gecikmeli veya erişilemez durumdayken sistem davranışı Özellikle üçüncü senaryo kritiktir. Çünkü birçok ekip normal trafik testini yapar ama yetkilendirme servisi yavaşladığında Envoy kuyruklarının ve istemci zaman aşımlarının nasıl davranacağını gözlemlemez. Operasyonel gözlem katmanı Kurulum tamamlandıktan sonra aşağıdaki sinyalleri izleyin: Toplam istek sayısı ve reddedilen oran Neden koduna göre ret dağılımı ext authz yanıt süresi Proxy ile yetkilendirme servisi arasındaki hata oranı Bu metrikler olmadan güvenlik katmanı görünürde merkezî, gerçekte opak kalır. Sonuç Envoy ext authz ile iç API yetkilendirme zinciri kurmak, erişim kararını servis kodundan tamamen koparmak zorunda değildir; fakat bunu ortak, gözlemlenebilir ve yönetilebilir bir katmana taşır. Kimlik, politika ve karar kaydı ayrıldığında güvenlik ekibi daha tutarlı kontrol uygular, platform ekibi sorunları daha hızlı teşhis eder ve uygulama ekipleri iş mantığına odaklanabilir.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "envoy",
        "security",
        "api",
        "service-proxy",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/grafana-loki-ile-log-retention-katmanlama",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/grafana-loki-ile-log-retention-katmanlama",
      "title": "Grafana Loki ile Log Retention Katmanlama",
      "summary": "Sıcak, ılık ve arşiv log katmanlarını Loki üzerinde kurgulamak için maliyet odaklı retention rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Log platformlarında en yaygın kırılma, toplama tarafında değil retention kararında yaşanır. Her logu aynı sürede, aynı depolama katmanında ve aynı sorgu beklentisiyle tutmak kısa sürede maliyet üretir. Grafana Loki ile log retention katmanlama yaklaşımı, log değerini iş etkisine göre ayırıp sıcak sorgu deneyimini bozmadan toplam maliyeti kontrol etmeyi sağlar. Neden tek retention politikası zayıftır? Kurumsal ortamlarda uygulama logu, audit kaydı, güvenlik olayı ve altyapı debug çıktısı aynı yaşam döngüsüne sahip değildir. Buna rağmen sık görülen desen, tüm akışı aynı retention period ile yönetmektir. Sonuç olarak ya arama katmanı gereğinden pahalı olur ya da kritik kayıtlar çok erken silinir. Sağlam model, logları teknik kaynağa göre değil kullanım niyetine göre ayırır: Günlük operasyon sorguları Incident sonrası kısa dönem inceleme Uyumluluk ve audit saklama Düşük değerli debug veya geçici gürültü Bu ayrım, Loki mimarisinin depo ve index davranışını da daha kontrollü yönetmenizi sağlar. Katmanlı retention modeli Pratikte üç katman iyi sonuç verir: 1. Sıcak katman : En sık sorgulanan ve hızlı erişim gereken loglar 2. Ilık katman : Daha seyrek kullanılan ama hâlâ erişilebilir tutulacak loglar 3. Arşiv katmanı : Uyumluluk veya geriye dönük denetim için düşük maliyetli saklama Loki kullanırken bu ayrımı tenant, stream etiketi veya nesne depolama politikalarıyla birlikte tasarlayabilirsiniz. Amaç yalnızca silme süresi değil; hangi verinin hangi sorgu beklentisiyle tutulduğunu açık hale getirmektir. Etiket stratejisi retention başarısını belirler Loki tarafında retention kararı çoğu zaman etiket modelinden bağımsız düşünülür. Bu hata pahalıdır. Eğer akışlar doğru etiketlenmemişse, düşük değerli logları ayrı tutamazsınız ve sorgu maliyeti artar. Özellikle şu etiketler işe yarar: log class: hot, warm, archive team: sahip ekip service tier: kritik, standart, düşük öncelik compliance scope: audit veya regulasyon kapsamı Bu alanlar retention kararını teknik depolama ayarından çıkarıp yönetişim seviyesine taşır. Örnek yaklaşım Loki tarafında stream seçimi ve retention için örnek bir düşünce modeli: Bu yapı tek başına yeterli değildir, fakat katman mantığını netleştirir. Eğer depolama politikaları da buna göre eşlenirse sorgu sıcaklığı ile saklama maliyeti arasında daha sağlıklı denge kurulur. <Callout type=\"tip\" title=\"Retention kararı yalnızca silme süresi değildir\" Sıcak katman sorgu performansı, ılık katman maliyet dengesi ve arşiv katmanı erişim prosedürü birlikte tasarlanmalıdır. </Callout Operasyonel doğrulama Retention stratejisi canlıya alındığında şu kontroller yapılmalıdır: Log akışları gerçekten doğru sınıfa düşüyor mu? Incident sırasında ihtiyaç duyulan stream'ler sıcak katmanda kalıyor mu? Audit sorguları arşivde erişilebilir ama pahalı olmayan biçimde tutuluyor mu? Gürültülü servisler sıcak katmanı gereksiz dolduruyor mu? Bu kontroller yapılmadığında iyi görünen retention politikası pratikte yanlış sınıflandırma yüzünden değer kaybeder. Sık yapılan hata: tüm logları uyumluluk bahanesiyle tutmak Kurumsal ekipler bazen ileride lazım olur düşüncesiyle her logu uzun süre tutmak ister. Bu yaklaşım iki sorun doğurur. Birincisi maliyet şişer. İkincisi gerçekten önemli sinyaller düşük değerli veri içinde görünmez olur. Uyumluluk ihtiyacı olan logları teknik ve hukuki bağlamıyla ayırmak, platformun geri kalanını gereksiz yükten kurtarır. Daha doğru yaklaşım, saklama gereksinimini veri sınıfına göre yazmak ve bunun sahipliğini açık biçimde atamaktır. Sonuç Grafana Loki ile log retention katmanlama, yalnızca depolama optimizasyonu değildir; log platformunun ne için var olduğunu netleştiren bir mimari karardır. Sıcak, ılık ve arşiv katmanlarını iş etkisine göre ayırdığınızda hem sorgu deneyimi iyileşir hem de observability maliyeti daha savunulabilir hâle gelir. Güçlü log platformu, en çok veri tutan değil; en doğru veriyi doğru ömürle tutan platformdur.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "loki",
        "logging",
        "devops",
        "maliyet"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/metallb-ile-bare-metal-kubernetes-servis-yayinlama",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/metallb-ile-bare-metal-kubernetes-servis-yayinlama",
      "title": "MetalLB ile Bare Metal Kubernetes Servis Yayınlama",
      "summary": "Bulut load balancer olmadan bare metal Kubernetes kümelerinde servis yayınlamak için MetalLB tabanlı net bir tasarım çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './metallb ile bare metal kubernetes servis yayinlama diagram.svg'; Bare metal Kubernetes çalıştıran ekiplerin çok sık yaşadığı bir gerçek var: cluster tarafı olgunlaşır, ingress yerleşir, observability oturur; ama dış dünyaya servis yayınlama adımı hâlâ elde tutulur. Bulut ortamında bu iş genelde LoadBalancer servisiyle birkaç dakikada çözülür. Kendi veri merkezinizde veya hibrit altyapınızda ise aynı ihtiyaç ağ ekibi, firewall kuralları, VIP yönetimi ve elle tutulan IP tabloları arasında dağılır. MetalLB bu boşluğu doldurur; fakat gerçek değeri yalnızca IP dağıtmak değil, Kubernetes ile ağ operasyonunu birbirine daha öngörülebilir biçimde bağlamaktır. <figure <Image src={diagram} alt=\"Bare metal Kubernetes kümesinde MetalLB ile servis yayınlama akışını gösteren teknik şema\" / <figcaption MetalLB, bare metal ortamda servis yayınlamayı bulut benzeri bir deneyime yaklaştırır; ancak IP havuzu, L2 ya da BGP modu ve operasyon sınırları baştan netleşmelidir.</figcaption </figure Problem aslında IP vermek değil Birçok ekip MetalLB'yi sadece \"Kubernetes'e dış IP verdiren araç\" gibi konumlandırır. Bu eksik bir tanımdır. Asıl problem şudur: Hangi servislerin dış erişim alacağı net değildir. IP havuzları ile ağ segmentasyonu arasında sahiplik kopuktur. Failover davranışı L2 topolojiye veya routing tasarımına göre değişir. Uygulama ekipleri servis açmayı kolaylaştırırken platform ekibi risk kontrolünü kaybetmek istemez. MetalLB kurulumu kolaydır; ama başarılı kullanım için ağ niyetinin de açık olması gerekir. L2 mi, BGP mi? Başlangıçta en kritik karar budur. L2 modu daha hızlı başlatılır. Özellikle tek veri merkezi, sınırlı node sayısı ve aynı broadcast domain içinde çalışan kümelerde iyi sonuç verir. Fakat L2 modunda VIP sahipliği bir node'dan diğerine taşınırken ağ davranışı topolojiye duyarlı olur. BGP modu ise daha kurumsal ve ölçeklenebilir bir model sunar: 1. Ağ cihazlarıyla açık rota alışverişi yapılır. 2. Çoklu rack ya da çoklu segment senaryolarında daha tutarlı davranır. 3. Node arızasında erişim yolu daha öngörülebilir hâle gelir. Benim önerim şudur: iki switch, tek oda ve sınırlı servis sayısı olan lab ya da küçük üretim ortamlarında L2 kabul edilebilir; kurumsal cluster'larda ise BGP düşünülmeden kalıcı tasarım yapılmamalıdır. IP havuzu tasarımı neden önemlidir? MetalLB kurulduktan sonra en sık yapılan hata, tek ve geniş bir IP havuzu tanımlayıp her yük dengeleyici servisini buna bırakmaktır. Bu model kısa vadede pratiktir ama denetim ve operasyon kalitesini düşürür. Daha iyi yaklaşım, havuzları niyete göre ayırmaktır: Kuzey güney üretim trafiği İç ağdan erişilen servisler Geçici test veya migration servisleri Yönetim düzlemi bağımlılıkları Bu ayrım sayesinde hangi IP aralığının hangi risk sınıfına ait olduğu görünür olur. Özellikle firewall ekibi, güvenlik ekibi ve platform ekibi aynı tabloya bakabilir. <Callout type=\"tip\" title=\"IP havuzunu teknik değil operasyonel bir varlık gibi yönetin\" Havuz adları uygulama ekibinin anlayacağı kadar sade, ağ ekibinin denetleyebileceği kadar net olmalıdır. \"prod external\" veya \"internal shared\" gibi niyet bazlı isimler bu yüzden değerlidir. </Callout Basit bir başlangıç tanımı Aşağıdaki örnek, bare metal cluster için küçük ama yönetilebilir bir MetalLB kurulumu gösterir: Bu örnek küçük görünür; fakat servis açıklaması, havuz sahipliği ve segment niyeti tutarlıysa ileride BGP moduna geçmek de daha kolay olur. Operasyon tarafında hangi kontroller şart? MetalLB'yi yalnızca kube manifest seviyesiyle yönetmek yeterli değildir. Şu kontrolleri baştan kurmanızı öneririm: Kullanılan ve boşta kalan IP sayısını izleme Aynı havuzu paylaşan servislerin envanteri VIP değişim olayları için audit izi Dış IP alan servislerin onay modeli Ingress, gateway ve doğrudan LoadBalancer kullanımlarının ayrımı Özellikle farklı ekiplerin aynı kümeyi kullandığı kurumsal yapılarda, \"kim dış IP aldı\" sorusu teknikten önce yönetişim sorusudur. Ağ ekibi ile platform ekibi arasındaki sınır Başarılı MetalLB kullanımında bu sınır çok nettir: Ağ ekibi: hangi VLAN, subnet, BGP peer ve kuzey güney akışın kabul edildiğini belirler. Platform ekibi: bu sınırlar içinde Kubernetes nesneleri ve havuz politikalarını işletir. Uygulama ekipleri: servis talebini self service deneyimle yapar ama kurumsal guardrail'ler dışına çıkmaz. Bu ayrım yapılmadığında ya platform ekibi ağ tasarımı yapmaya başlar ya da ağ ekibi her servis değişikliğinde darboğaz olur. Hangi senaryolarda dikkatli olunmalı? MetalLB her problemi çözmez. Aşağıdaki durumlarda mimari karar daha dikkatli verilmelidir: Geniş L2 domain'lerde ARP davranışının belirsiz olduğu eski ağlar Sık değişen test cluster'larında IP kirlenmesi Aynı IP alanını tüketen eski fiziksel yük dengeleyiciler Gelişigüzel açılmış LoadBalancer servisleri nedeniyle yönetilemeyen dış yüzey Bu ortamlarda önce servis yayınlama ilkelerini sadeleştirmek, sonra MetalLB kurmak daha doğru olur. Sonuç MetalLB ile bare metal Kubernetes servis yayınlama, \"bulutta olan özelliği veri merkezine getirme\" işi gibi görünse de aslında platform ve ağ ekipleri arasında daha sağlıklı bir sözleşme kurma fırsatıdır. IP havuzlarını niyete göre ayırır, L2 ve BGP kararını topolojiye göre verir ve dış IP kullanımını görünür kılarsanız bare metal Kubernetes ortamı çok daha yönetilebilir hâle gelir. MetalLB'nin gücü kurulum kolaylığında değil, servis yayınlamayı standartlaştırabilmesindedir.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "kubernetes",
        "network",
        "metallb",
        "bare-metal",
        "platform"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/netplan-ile-policy-based-routing-ve-yedek-hat-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/netplan-ile-policy-based-routing-ve-yedek-hat-tasarimi",
      "title": "Netplan ile Policy-Based Routing ve Yedek Hat Tasarımı",
      "summary": "Linux sunucularda birincil ve ikincil uplink'leri kaynak ağa göre ayıran policy-based routing kurgusunu Netplan ile kurun.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './netplan ile policy based routing ve yedek hat tasarimi diagram.svg'; Birden fazla uplink kullanan Linux sunucularda varsayılan rota tek başına yeterli değildir. Yönetim trafiğinin ayrı çıkması, replikasyon akışının ikinci hat üzerinden gitmesi veya belirli kaynak ağların farklı gateway kullanması gerektiğinde policy based routing devreye girer. Ubuntu tabanlı sunucularda bunu elle ip rule yazarak değil, Netplan üzerinden kalıcı ve okunabilir biçimde kurmak daha sağlıklıdır. <figure <Image src={diagram} alt=\"İki uplink ve policy based routing akışını gösteren teknik şema\" / <figcaption Çoklu uplink tasarımında asıl mesele ikinci arayüzü eklemek değil, geri dönüş yolunu doğru kurgulamaktır.</figcaption </figure Hangi problem çözülüyor? Tek NIC mantığında gelen ve giden trafik aynı yol üzerinden akar. Fakat çift uplink senaryosunda şunlar ortaya çıkar: Yanlış arayüzden çıkan cevap paketleri Asimetrik yönlendirme nedeniyle bozulmuş oturumlar Failover anında yönetim erişiminin kaybı Replikasyon trafiğinin üretim hattını sıkıştırması Policy based routing, paketlerin sadece hedefe göre değil; kaynak IP, tablo ve kural önceliğine göre yönlendirilmesini sağlar. Örnek senaryo Bu rehberde şu kurguyu ele alıyorum: ens18: üretim ağı, varsayılan trafik ens19: replikasyon ve yedek erişim ağı 10.20.0.10/24: uygulama IP'si 172.16.30.10/24: yönetim veya replikasyon IP'si Amaç; 172.16.30.10 kaynağından çıkan trafiği ikinci gateway üzerinden zorlamak, birincil rota dururken bile kaynak simetrisini korumaktır. Netplan yapılandırması Önce özel routing table tanımı kullanacağız. Ubuntu'da tablo numarasını dosyada doğrudan verebiliriz: Bu tanımın kritik noktası routing policy bölümüdür. Böylece 172.16.30.10 kaynağından çıkan trafik ana tabloyu değil, tablo 200 içindeki rotaları kullanır. <Callout type=\"warning\" title=\"Yalnızca subnet rotası çoğu zaman yetmez\" İkinci uplink gerçekten internete veya başka uzak ağlara çıkacaksa tablo 200 içine ayrıca uygun default via satırı eklenmelidir. Aksi hâlde yalnızca yerel subnet erişimi sağlanır. </Callout Yedek hat için varsayılan rota ekleme İkinci uplink uzak erişim veya site to site yedek hat olarak kullanılacaksa yapı şöyle genişler: Buradaki metric, aynı tablo içindeki rota tercih sırası içindir; tablo seçimini ise routing policy belirler. Bu ayrımı karıştırmak, policy based routing kurulumlarında en sık yapılan hatalardan biridir. Uygulama ve doğrulama adımları Dosyayı örneğin /etc/netplan/99 multi uplink.yaml gibi gerçek hedefe yerleştirdikten sonra şu sırayı izleyin: Özellikle son komut, paketin beklenen gateway üzerinden gidip gitmediğini açıkça gösterir. Failover mantığı nasıl düşünülmeli? Policy based routing tek başına sağlık kontrolü yapmaz. Gerçek failover istiyorsanız: keepalived veya benzeri araçla gateway erişimini izleyin route değişimini script veya networkd dispatcher ile tetikleyin uygulama timeout'larını yeni topolojiye göre gözden geçirin Sunucu tarafında rota değişse bile upstream firewall veya NAT kurgusu ikinci hattı tanımıyorsa failover yalnızca kâğıt üzerinde kalır. Bu yüzden ağ tasarımını uçtan uca doğrulamak gerekir. Sık karşılaşılan hata senaryoları rp filter nedeniyle ters yol denetiminin paketleri düşürmesi Policy kuralının yanlış kaynak IP'ye bağlanması Tablo içinde dönüş rotasının eksik kalması DNS veya yönetim servisi gibi kritik trafiğin yanlış hatta taşınması Bu tip hatalarda ilk bakılacak komutlar ip rule, ip route get, journalctl u systemd networkd ve gerekirse tcpdump i ens19 olmalıdır. Sonuç Netplan ile policy based routing ve yedek hat tasarımı, çoklu uplink kullanan Linux sunucularda kontrolü varsayılan rotadan geri almanızı sağlar. Doğru tablo, kural önceliği ve doğrulama alışkanlığıyla hem yönetim trafiğini hem kritik veri akışlarını daha öngörülebilir biçimde ayırabilirsiniz. Özellikle kurumsal altyapılarda bu disiplin, ağ esnekliğini ciddi ölçüde artırır.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "netplan",
        "network",
        "linux",
        "routing",
        "infrastructure"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/suricata-ile-dogu-bati-trafik-profilleme-rehberi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/suricata-ile-dogu-bati-trafik-profilleme-rehberi",
      "title": "Suricata ile Doğu-Batı Trafik Profilleme Rehberi",
      "summary": "Veri merkezi içinde servisler arası trafiği görünür kılmak için Suricata ile düşük sürtünmeli profil çıkarma yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './suricata ile dogu bati trafik profilleme rehberi diagram.svg'; Doğu batı trafik çoğu kurumda en az görülen ama en çok risk taşıyan ağ yüzeyidir. Aynı veri merkezindeki servisler birbirleriyle konuştuğu için “iç trafik güvenlidir” varsayımı sessizce yerleşir. Oysa lateral movement, yanlış açılmış yönetim portları veya beklenmeyen bağımlılıklar çoğu zaman tam bu koridorda saklanır. Suricata, tüm ağı yeniden tasarlamadan bu akışı görünür kılmak için pratik bir başlangıç sağlar. <figure <Image src={diagram} alt=\"Suricata sensörü ve doğu batı trafik akışlarını gösteren teknik şema\" / <figcaption İlk amaç engellemek değil; kim, kiminle, ne sıklıkta konuşuyor sorusunu kanıtlı veriye çevirmektir.</figcaption </figure Hangi kullanım modeli hedefleniyor? Bu rehberde inline engelleme değil, pasif profil çıkarma yaklaşımını ele alıyorum. Amaç: SPAN veya mirror port üzerinden kopyalanmış iç trafiği dinlemek EVE JSON çıktısıyla akış özeti toplamak En sık konuşan servis çiftlerini ve port dağılımını görmek Gerekirse daha sonra politika sıkılaştırmasına zemin hazırlamak Bu model, özellikle zero trust veya mikro segmentasyon öncesi mevcut davranışı anlamak için değerlidir. Suricata kurulumu Ubuntu tabanlı bir sensör düğümünde temel kurulum şöyle yapılabilir: Sonrasında dinleme arayüzünü ve JSON çıktısını netleştirmek gerekir. Dağıtım paketine göre ana dosya genellikle /etc/suricata/suricata.yaml olur. Kritik yapılandırma alanları Profil çıkarma için aşağıdaki ayarlar yeterli bir temel sağlar: flow çıktısı konuşan uçları ve hacmi, dns/http/tls çıktıları ise temel protokol bağlamını görmenizi sağlar. İlk aşamada agresif kural seti yüklemek yerine görünürlük odaklı kalmak daha doğrudur. <Callout type=\"tip\" title=\"Önce hacmi ve deseni öğrenin\" Trafik modelini anlamadan yazılan imza kuralları ya gürültü üretir ya da yanlış güven hissi verir. Profil çıkarma ayrı bir fazdır. </Callout Servisi başlatma ve canlı kontrol Yapılandırmadan sonra: T testi özellikle önemlidir; yanlış interface adı veya bozuk YAML nedeniyle servis sessizce başlamıyor olabilir. Hızlı profil çıkarma sorguları EVE JSON dosyasından en çok konuşan akışları çıkarmak için jq yeterlidir: Benzer biçimde beklenmeyen yönetim portlarını bulmak için: Bu sorgular tam güvenlik analizi yerine ilk davranış haritasını çıkarır. Özellikle belge dışı bağımlılıkları yakalamada çok işe yarar. Operasyonel dikkat noktaları Mirror trafiği sensöre gerçekten geliyor mu, önce tcpdump ile doğrulayın. Yüksek hacimli omurga hatlarında disk büyümesi için log rotasyonu kurun. Zaman senkronizasyonu düzgün değilse akış korelasyonu bozulur. Aynı trafik birden fazla sensöre düşüyorsa sayım çarpılabilir. Suricata sensörünü üretim sisteminin üzerine değil, ayrı bir gözlem noktasına koymak genellikle daha güvenlidir. Sonraki adım ne olabilir? Profil görünür olduktan sonra kurumun olgunluğuna göre şu adımlar değerlidir: 1. Beklenmeyen akışlar için inceleme kuyruğu açmak 2. Cilium, firewall veya ACL politikalarını bu gözleme göre daraltmak 3. Kritik servis çiftleri için baseline çıkarmak 4. Incident anında trafik sapmasını normal profille karşılaştırmak Böylece Suricata sadece IDS aracı değil, kurumsal ağ observability bileşeni hâline gelir. Sonuç Suricata ile doğu batı trafik profilleme, iç ağın karanlıkta kalan davranışını görünür kılmak için düşük sürtünmeli bir adımdır. Pasif izleme, net JSON çıktıları ve basit analiz komutlarıyla hangi servislerin ne yaptığına dair somut veri üretirsiniz. Bu da güvenlik sertleştirmesi, segmentasyon ve incident triage için çok daha sağlam bir temel sağlar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "suricata",
        "security",
        "network",
        "observability",
        "linux"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/unbound-ile-bolgesel-dns-cache-ve-forwarder-ayristirma",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/unbound-ile-bolgesel-dns-cache-ve-forwarder-ayristirma",
      "title": "Unbound ile Bölgesel DNS Cache ve Forwarder Ayrıştırma",
      "summary": "Kurumsal segmentlerde çözümleme trafiğini ayırmak için Unbound ile cache, forwarder ve erişim kontrolünü sade biçimde kurma rehberi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './unbound ile bolgesel dns cache ve forwarder ayristirma diagram.svg'; Kurumsal ağlarda DNS sorunlarının önemli bölümü aslında isim çözme başarısızlığından değil, yanlış forwarder seçimi ve kontrolsüz cache davranışından kaynaklanır. Kullanıcı ağı, uygulama segmenti ve yönetim koridoru aynı resolver'a bağlandığında bir noktadan sonra hangi sorgunun nereye gittiğini okumak zorlaşır. Unbound bu işi karmaşıklaştırmadan çözmek için güçlü bir araçtır: farklı erişim ağları için ayrı policy, ayrı forward zone ve kontrollü cache davranışı tanımlayabilirsiniz. <figure <Image src={diagram} alt=\"Unbound ile bölgesel DNS cache ve forwarder ayrıştırma mimarisini gösteren teknik şema\" / <figcaption Resolver aynı yazılım olabilir; önemli olan çözümleme davranışının bağlama göre ayrılmasıdır.</figcaption </figure Kurulum hedefi Bu rehberde şu örnek senaryoyu kuruyoruz: 10.10.0.0/16 kullanıcı ağı internet çözümlemesi için genel forwarder kullanacak. 10.20.0.0/16 uygulama ağı iç zone'lar için kurumsal DNS'e, diğer kayıtlar için kontrollü dış forwarder'a gidecek. 10.30.0.0/16 yönetim ağı yalnızca iç zone çözebilecek. Bu yapı tek Unbound örneğiyle başlanabilecek kadar basit, ama segment bazlı davranışı gösterecek kadar da gerçekçidir. Örnek yapılandırma Minimal unbound.conf örneği şöyle olabilir: Burada dikkat edilmesi gereken nokta view first davranışıdır. İstemci önce eşleşen görünümle işlenir; böylece aynı resolver üzerinde bağlama göre farklı forwarder politikaları uygulanır. Neden TTL değerlerini sıkı tutuyoruz? Kurumsal ortamlarda çok uzun TTL ilk bakışta performans kazanımı gibi görünür; fakat değişiklik ve incident anlarında cache etkisini büyütür. Özellikle entegrasyon uçları, failover kayıtları veya bakım sırasında değişen servis isimleri için kısa ama anlamlı TTL daha güvenlidir. Yukarıdaki örnekte cache max ttl: 900 ile cache'i sonsuza bırakmıyoruz; yine de resolver seviyesinde gereksiz yükü azaltıyoruz. Günlük operasyon için testler Kurulumdan sonra şu testleri ayrı istemci ağlarından çalıştırın: Beklenen davranış şu olmalı: Kullanıcı ağı iç zone'u çözmemeli. Uygulama ağı hem iç zone'u hem kontrollü dış kayıtları çözebilmeli. Yönetim ağı dış internet çözümlemesi yapamamalı. Bu testleri sadece başarılı cevap üzerinden değil, doğru reddedilme davranışı üzerinden de değerlendirin. <Callout type=\"tip\" title=\"Refuse ile timeout aynı şey değil\" İzin verilmeyen sorguya açık biçimde REFUSED dönmek, istemcinin ve operasyon ekibinin problemi daha hızlı anlamasını sağlar. Sessiz zaman aşımı çoğu zaman gereksiz teşhis yükü üretir. </Callout Log ve gözlem önerisi Unbound tek başına geniş observability sunmaz; ama doğru yerlere bağlandığında yeterli sinyali verir. Ben şu alanların merkezi log hattına taşınmasını öneriyorum: İstemci IP veya segment etiketi Sorgu adı ve türü Cevap kodu Gecikme ve upstream hedefi Bu sayede DNS cache isabet oranı ile politika ihlali davranışını aynı tabloda görebilirsiniz. Özellikle yönetim segmentinde dış isim çözme denemeleri değerli bir sinyal üretir. Yaygın hata: Her segment için yeni resolver açmak Büyük kurumlarda bu bazen gerekli olabilir; ancak çoğu ekip çok erken parçalanmaya gidiyor. Önce politika ayrıştırmasını aynı araç üzerinde kurup davranışı görünür kılmak daha sağlıklı. Ölçek veya regülasyon gereği ayrım gerekiyorsa sonrasında fiziksel ayrıştırmaya geçebilirsiniz. Sonuç Unbound ile bölgesel DNS cache ve forwarder ayrıştırma, çözümleme katmanını okunabilir bir ağ kontrolüne dönüştürür. Tek bir resolver yazılımı üzerinde segment bazlı erişim, farklı forwarder yolları ve kontrollü cache davranışı kurarak hem güvenliği hem teşhis kabiliyetini artırabilirsiniz. Özellikle kurumsal uygulama ve yönetim ağlarında bu yaklaşım sessiz ama etkili bir altyapı kazanımı sağlar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "dns",
        "unbound",
        "network",
        "infrastructure",
        "security"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/wireguard-ile-yonetim-agina-just-in-time-erisim",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/wireguard-ile-yonetim-agina-just-in-time-erisim",
      "title": "WireGuard ile Yönetim Ağına Just-in-Time Erişim",
      "summary": "Kalıcı VPN hesapları yerine kısa ömürlü ve denetlenebilir yönetim erişimi kurmak için WireGuard tabanlı pratik yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './wireguard ile yonetim agina just in time erisim diagram.svg'; Kurumsal altyapılarda en zor problemlerden biri yönetim erişimini hem pratik hem denetlenebilir tutmaktır. Bir yanda operasyon ekiplerinin hızlı bağlanma ihtiyacı vardır, diğer yanda güvenlik tarafı kalıcı VPN kullanıcıları, paylaşılan bastion hesapları ve geniş ağ görünürlüğünden haklı olarak rahatsızdır. Just in time erişim modeli bu gerilimi azaltır. WireGuard ise bu model için güçlü bir temel sunar; çünkü hafif, açık ve otomasyona elverişli bir tünel katmanı sağlar. <figure <Image src={diagram} alt=\"WireGuard ile yönetim ağına kısa süreli erişim akışını gösteren teknik şema\" / <figcaption Kalıcı geniş erişim yerine, onaylı ve süreli tünel açmak yönetim ağını sadeleştirir ve denetim kalitesini yükseltir.</figcaption </figure Kalıcı VPN hesabı neden zayıf modeldir? Sorun yalnızca hesabın varlığı değildir; hesabın zamanla görünmezleşmesidir. Bir kullanıcıya aylar önce verilmiş yönetim erişimi, ilk gün gerekçeli olabilir. Fakat şu riskler zaman içinde büyür: Erişimin hangi iş ihtiyacı için açık kaldığı unutulur. Aynı tünel birçok segmente fazla geniş görünürlük sağlar. Incident dışında da üretim yönetim ağına sürekli kapı açık kalır. Denetim kayıtları \"erişebiliyordu\" der ama \"neden şimdi bağlandı\"yı açıklayamaz. Just in time yaklaşımı erişimi varsayılan hak olmaktan çıkarıp açık bir operasyon olayına dönüştürür. WireGuard burada neden iyi oturur? WireGuard'ın en büyük avantajı karmaşık olmamasıdır. IPsec kadar ağır değildir, geleneksel uzak erişim çözümleri kadar fazla bileşen istemez. Doğru tasarlandığında şu faydaları verir: 1. Kısa ömürlü anahtar ve konfigürasyon üretimi kolaydır. 2. Erişim kapsamı eşlenmiş IP ve route seti ile daraltılabilir. 3. Otomasyonla onay, açılış ve kapanış aynı akışa bağlanabilir. 4. Kullanıcı deneyimi kötüleşmeden güvenlik sınırı sıkılaşır. Önemli nokta, WireGuard'ı sadece VPN yerine koymak değildir. Onu erişim orkestrasyonunun bir parçası yapmak gerekir. Mimariyi nasıl kurarım? Benim önerdiğim model dört parçalıdır: Kimlik ve onay katmanı Kısa ömürlü WireGuard peer üretimi Yönetim ağına daraltılmış rota seti Oturum sonrası otomatik iptal Bu modelde kullanıcı kalıcı bir peer taşımaz. İhtiyaç oluştuğunda örneğin 90 dakikalık erişim tanımlanır, peer dosyası üretilir, denetim izi yazılır ve süre bitince erişim kapanır. <Callout type=\"tip\" title=\"Erişim süresi varsayılan olarak kısa olmalı\" İstisna olarak uzatılan erişim daha sağlıklıdır. Tersi modelde kısa süreli çalışma bahanesiyle kalıcı ayrıcalık birikir. </Callout Basit bir konfigürasyon iskeleti Aşağıdaki örnek, yönetim geçidi üzerinde çalışan sade bir WireGuard arayüzünü gösterir: Gerçek ortamda bu peer tanımı elde yazılmamalıdır. Onay akışı sonunda otomasyon tarafından üretilmesi ve süre sonunda kaldırılması gerekir. Yalnızca tünel açmak yetmez Burada kritik hata, erişimi kısa ömürlü yapıp rotaları geniş bırakmaktır. Just in time erişimin iyi çalışması için şu sınırlar birlikte düşünülmelidir: Hangi subnet'e gidilebilir? Hangi port'lar açıktır? Hangi jump host ya da yönetim API'lerine erişilir? Erişim sırasında komut geçmişi veya session log nasıl ilişkilendirilir? Bu yüzden WireGuard katmanı çoğu zaman firewall, PAM, SSH CA veya erişim kayıt sistemiyle birlikte ele alınmalıdır. Incident anında model bozulur mu? Hayır, eğer önceden tasarlanmışsa tam tersine daha iyi çalışır. Çünkü incident anında herkesin zaten kalıcı erişimi olması gerekmez. Bunun yerine: 1. Nöbetçi veya incident komutanı erişim talebini açar. 2. Gerekli kişiler için süreli peer'ler üretilir. 3. Erişim yalnızca ilgili segmentlere açılır. 4. Olay kapandıktan sonra tüm peer'ler otomatik iptal edilir. Bu yaklaşım hem hız hem güvenlik açısından daha temizdir. Ölçmeniz gereken sinyaller Modelin çalıştığını anlamak için yalnızca bağlantı sayısına bakmayın. Şu ölçümler daha değerlidir: Ortalama erişim süresi Süre bitiminde otomatik kapanan oturum oranı Geniş segment yerine hedefe yönelik erişim oranı Manuel müdahale gerektiren istisna sayısı Incident sırasında erişim açma süresi Bu metrikler erişimin gerçekten just in time mı, yoksa sadece yeni isimli bir VPN mi olduğunu gösterir. Sonuç WireGuard ile yönetim ağına just in time erişim kurmak, VPN teknolojisi değiştirmekten daha büyük bir adımdır. Kalıcı ayrıcalığı azaltır, erişim niyetini görünür kılar ve denetim izini operasyonel akışın parçası yapar. Kurumsal altyapıda güvenli yönetim erişimi istiyorsanız mesele yalnızca tüneli şifrelemek değil, erişimin ne zaman ve neden var olduğunu açıkça tanımlamaktır. WireGuard bu hedef için sade ve güçlü bir temel sağlar.",
      "date_published": "2026-04-07T00:00:00.000Z",
      "date_modified": "2026-04-07T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "wireguard",
        "security",
        "network",
        "access-control",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-degisiklik-penceresiz-yayin-disiplini",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-degisiklik-penceresiz-yayin-disiplini",
      "title": "Kıdemli Mühendisler İçin Değişiklik Penceresiz Yayın Disiplini",
      "summary": "Kurumsal ekiplerde değişiklik penceresine bağımlı kalmadan güvenli yayın yapmanın teknik liderlik çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kidemli muhendisler icin degisiklik penceresiz yayin disiplini diagram.svg'; Kurumsal yapılarda yayın güvenliği uzun süre boyunca \"değişiklik penceresi\" ile yönetildi. Cuma akşamı ya da gece yarısı belirlenen dar zaman aralıkları, riski azaltmanın tek yolu gibi görüldü. Fakat modern platformlarda asıl risk çoğu zaman değişikliğin ne zaman yapıldığından değil; yayın disiplininin gözlemlenebilir, geri alınabilir ve küçük parçalara ayrılmış olmamasından kaynaklanır. <figure <Image src={diagram} alt=\"Değişiklik penceresi olmadan güvenli yayın disiplini katmanlarını gösteren teknik şema\" / <figcaption Takvim koruması yerine sistematik yayın disiplini kurulduğunda hız ile güvenlik aynı anda korunabilir.</figcaption </figure Değişiklik penceresi neden tek başına çözüm değil? Çünkü pencere, yalnızca takvimi yönetir; riskin yapısını yönetmez. Eğer ekip: büyük paketler hâlinde deploy yapıyorsa, canary veya aşamalı dağıtım kullanmıyorsa, rollback süresi uzunsa, etkiyi gerçek zamanlı ölçemiyorsa, değişikliği gece 02:00'de yapmak yalnızca problemi daha az görünür bir saate taşır. Kıdemli mühendislik pratiği burada takvim yönetimini değil, yayın sisteminin davranışını dönüştürmeyi hedeflemelidir. Güvenli yayın disiplini hangi temellere oturur? Ben bu disiplini beş katmanda düşünmeyi faydalı buluyorum: 1. Değişikliği küçük ve geri alınabilir paketlere bölmek 2. Dağıtımı aşamalı ve ölçümlü yapmak 3. Etkiyi iş metriğiyle birlikte izlemek 4. Geri alma kararını politik değil operasyonel kılmak 5. Ekipler arası iletişim ritmini önceden tanımlamak Bu yapı kurulmadan \"change window kaldırıyoruz\" demek yalnızca denetimsiz hız üretir. Kıdemli mühendis burada neyin sahibi olmalı? Teknik lider veya kıdemli mühendis doğrudan her deploy'u yapmasa bile yayın sisteminin güvenlik çerçevesinin sahibidir. Bu sahiplik üç soruda görünür olur: Yeni bir servis hangi koşulda üretime çıkabilir? Etkiyi fark etmek için hangi sinyaller zorunludur? Ne zaman ilerlemeyi durdurup geri almak gerekir? Bu soruların cevabı wiki sayfasında değil, günlük operasyonda yaşamalıdır. Eğer rollout politikası yalnızca SRE ekibinin bildiği bir ayrıntıysa, kültür kurulmamış demektir. <Callout type=\"tip\" title=\"Küçük değişiklik, küçük risk anlamına yalnızca ölçülüyorsa gelir\" Parçalı yayın yapmak tek başına güvenli değildir. Her aşamanın bir durdurma şartı ve net başarı sinyali olmalıdır. </Callout Değişiklik penceresiz modelde iletişim nasıl sadeleşir? Kurumsal ekiplerin büyük kısmında gerginlik, deploy anından çok deploy etrafındaki belirsizlikten doğar. \"Kim onay verdi?\", \"hangi servis etkilenecek?\", \"geri alma kararı kimden çıkacak?\" gibi sorular olay anında soruluyorsa süreç zaten yavaştır. Daha sağlıklı model şudur: Yayın tipi önceden sınıflandırılır. Düşük riskli değişiklikler otomatik guardrail ile akar. Yüksek riskli değişiklikler için daraltılmış karar zinciri kullanılır. Incident kanalı ile yayın kanalı birbirine bağlanır ama karıştırılmaz. Bu sayede iletişim, istisna yönetimine odaklanır; her deploy için yeniden bürokrasi kurulmaz. Geri alma kültürü neden teknik kariyer konusu? Çünkü birçok kurumda rollback hâlâ başarısızlık gibi yorumlanır. Oysa olgun ekiplerde geri alma, başarısızlığın değil kontrol kabiliyetinin göstergesidir. Kıdemli mühendisler bu kültürü dil üzerinden kurar: \"Sorunu inceleyelim, önce etkiyi daraltalım.\" \"Rollback kararını kişisel performansla ilişkilendirmiyoruz.\" \"İlerlemek için daha fazla kanıta ihtiyacımız var.\" Bu yaklaşım, genç mühendislerin üretime daha güvenli çıkmasını sağlar. Aynı zamanda teknik liderin güven verdiği anlardan biri de budur; hatayı dramatize etmeden, sistemi sakin biçimde güvenli duruma almak. Kurumsal tarafta en büyük dönüşüm nerede yaşanır? Asıl dönüşüm CAB toplantılarını kaldırmakta değil, CAB ihtiyacını azaltan teknik kontrol düzlemini kurmaktadır. Feature flag, canary, otomatik sağlık kontrolü, SLO tabanlı durdurma, pre deploy doğrulama ve gözlemlenebilir rollback akışı kurulduğunda değişiklik penceresi zorunluluğu doğal olarak daralır. Burada kritik nokta, süreci \"tamamen serbest\" bırakmak değil; insan onayını takvim tabanlı olmaktan çıkarıp kanıt tabanlı hâle getirmektir. Sonuç Kıdemli mühendisler için değişiklik penceresiz yayın disiplini, yalnızca bir CI/CD iyileştirmesi değildir. Bu yaklaşım; risk algısını, ekip güvenini ve kurum içi operasyon dilini yeniden düzenler. Değişiklik penceresi yerine ölçülen rollout, hızlı geri alma ve açık karar sınırları kurulduğunda, yayın güvenliği takvimden mimariye taşınmış olur.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "deployment",
        "incident-management",
        "platform"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-incident-komuta-rotasyonu-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-incident-komuta-rotasyonu-tasarimi",
      "title": "Kıdemli Mühendisler İçin Incident Komuta Rotasyonu Tasarımı",
      "summary": "Incident yükünü birkaç kişinin refleksine bırakmadan ölçeklemek için komuta rotasyonu tasarımının teknik çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kidemli muhendisler icin incident komuta rotasyonu tasarimi diagram.svg'; Kurumsal ortamlarda incident yönetiminin en kırılgan noktalarından biri, komuta pratiğinin birkaç güçlü kişide toplanmasıdır. Sistemler büyüdükçe alarm sayısı, etkilenen ekip sayısı ve iş baskısı artar; fakat müdahale ritmi çoğu zaman hâlâ aynı iki ya da üç kıdemli mühendisin omzunda kalır. Bu yapı ilk bakışta verimli görünür, ama zamanla hem tükenmişlik üretir hem de kurumun kriz kapasitesini daraltır. <figure <Image src={diagram} alt=\"Incident komuta rotasyonu, roller ve karar akışını gösteren teknik şema\" / <figcaption Komuta rotasyonu, kişiye bağımlı kahramanlığı azaltıp kurumsal tepki kalitesini standartlaştırır.</figcaption </figure Neden komuta rotasyonu gerekir? Bir incident sırasında herkes aynı anda teknik çözüm üretmeye çalışırsa, görünürlük hızla bozulur. Kimin karar verdiği, kimin etki analizi yürüttüğü ve kimin iletişimi yönettiği net değilse ekipler paralel ama kopuk çalışmaya başlar. Komuta rotasyonu üç problemi aynı anda çözer: Müdahale liderliğini tek kişiden çıkarır Kıdemli mühendisler arasında ortak davranış standardı üretir Incident deneyimini mentorluk alanına dönüştürür Buradaki hedef daha fazla toplantı yapmak değildir. Hedef, olay anında belirsizliği azaltacak rol netliğini önceden tasarlamaktır. Hangi roller gerçekten gerekli? Birçok ekip gereğinden fazla rol tanımlar. Oysa orta ölçekli kurumsal yapılarda çoğu incident için şu çekirdek yapı yeterlidir: 1. Incident commander 2. Teknik yürütücü veya çözüm sahibi 3. İletişim sahibi 4. Gerekirse not tutucu Bu rollerin aynı kişide birleşmesi küçük olaylarda mümkündür; fakat yüksek etkili olaylarda komutan ile uygulayıcının ayrılması ciddi fark yaratır. Komutanın görevi terminal başında en hızlı komutu yazmak değil, karar ritmini ve öncelik sırasını korumaktır. Rotasyon tasarımı neye göre yapılmalı? Rotasyon çizelgesi sadece takvim meselesi değildir. İyi tasarım şu girdileri dikkate alır: Kişinin o sistem alanındaki bağlamsal bilgisi Son haftalardaki nöbet ve incident yükü İş saatleri dışındaki erişilebilirlik sınırları Bir sonraki seviye yedek komutanın hazır olup olmaması Özellikle platform ve altyapı ekiplerinde \"kim uygunsa o baksın\" yaklaşımı sürdürülebilir değildir. Çünkü komuta rolü teknik uzmanlıktan farklı olarak koordinasyon, karar berraklığı ve iletişim disiplinini de gerektirir. <Callout type=\"tip\" title=\"Rotasyon yalnızca takvim değildir\" Komuta rotasyonu hazırlanmadan önce hangi incident tiplerinde hangi kişinin liderlik edeceği tanımlanmalı. Aksi halde rotasyon kağıt üstünde vardır, gerçek olayda herkes yine aynı isme döner. </Callout Komutanın karar alanı nasıl sınırlandırılmalı? Kurumsal yapılarda en sık hata, komutana sınırsız otorite atamaktır. Bu durum bir süre sonra hem aşırı yük bindirir hem de yanlış teşvik üretir. Daha sağlıklı yaklaşım, komuta rolünün yetki sınırlarını açık tarif etmektir: Etki daraltma için rollback veya trafik kesme kararı Ek uzman çağırma kararı Yönetici ve paydaş eskalasyonu İletişim frekansı ve güncelleme formatı Buna karşılık kalıcı mimari değişiklik, müşteri taahhüdü veya yüksek riskli veri işlemleri gibi konular ayrı onay kanalına bağlanmalıdır. Böylece komuta rolü hem güçlü hem de kontrollü kalır. Rotasyon kalitesi nasıl ölçülür? Sadece \"olayı çözdük\" demek yeterli değil. Rotasyonun işe yarayıp yaramadığını anlamak için şu sinyallere bakmak gerekir: İlk durum özetinin kaç dakika içinde paylaşıldığı Komutan değişimlerinde bilgi kaybı yaşanıp yaşanmadığı Aynı isimlerin toplam incident saatindeki payı Postmortem çıktılarında iletişim ve rol karışıklığı oranı Yeni komutan adaylarının kaç olayda gölgeli katılım yaptığı Bu göstergeler komuta kapasitesinin gerçekten kurumsallaşıp kurumsallaşmadığını açığa çıkarır. Mentorluk boyutu nasıl kurgulanmalı? Komuta rotasyonu, kıdemli mühendislik pratiğinin aktarımı için güçlü bir araçtır. Bunun için gölgeli katılım modeli faydalıdır: Yeni aday önce gözlemci olarak katılır Sonraki olayda iletişim veya not tutma rolünü üstlenir Daha sonra düşük riskli olaylarda komutayı devralır Deneyimli komutan ise yalnızca destek ve geri bildirim verir Bu yaklaşım, bilgi transferini sunum dosyası yerine gerçek operasyon bağlamında yapar. Ayrıca ekibin \"bu rolü yalnızca belli kişiler yapabilir\" inancını da kırar. En sık yapılan tasarım hatası Birçok kurum rotasyonu tanımlayıp eğitimini atlar. Oysa komuta pratiği, sadece isim yazılarak oluşmaz. İnsanların ortak dilde konuşması gerekir: Etki nasıl özetlenecek? Hipotez nasıl ifade edilecek? Ne zaman rollback denecek? Hangi durumda yönetici devreye alınacak? Bu çerçeve yoksa rotasyon listesindeki her yeni isim farklı standart getirir ve güven azalır. Sonuç Kıdemli mühendisler için incident komuta rotasyonu tasarımı, nöbet takviminin küçük bir eki değil; operasyonel dayanıklılığın temel yapıtaşıdır. Kurum birkaç uzmanın refleksiyle değil, çoğaltılabilir karar disipliniyle ayakta kalır. Teknik liderlik bunu sistematik biçimde kurabildiğinde incident yönetimi daha hızlı, daha sakin ve daha öğretici bir hale gelir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "incident-management",
        "teknik-liderlik",
        "operations",
        "mentorluk"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-operasyonel-delegasyon-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/career/kidemli-muhendisler-icin-operasyonel-delegasyon-tasarimi",
      "title": "Kıdemli Mühendisler İçin Operasyonel Delegasyon Tasarımı",
      "summary": "Kritik operasyon bilgisini tek elde tutmadan, güvenli sorumluluk devri yapabilmek için delegasyon modeli.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kidemli muhendisler icin operasyonel delegasyon tasarimi diagram.svg'; Birçok kurumda en güvenilir mühendis aynı zamanda en çok darboğaz üreten kişiye dönüşür. Bunun nedeni yetersiz niyet değil, operasyonel delegasyonun bilinçli tasarlanmamasıdır. Kıdemli mühendis kritik alanları bırakmak istemez; ekip ise aynı alanlara güvenle giremez. Sonuçta hem hız düşer hem de sürdürülebilirlik zayıflar. <figure <Image src={diagram} alt=\"Operasyonel delegasyon tasarımının katmanlarını gösteren teknik şema\" / <figcaption Delegasyon, işi başkasına bırakmak değil; güvenli sorumluluk yüzeyi tasarlamaktır.</figcaption </figure Delegasyon neden operasyonel bir tasarım problemidir? Çünkü çoğu ekipte devir şu iki yanlış uç arasında kalır: \"Ben hallederim\" yaklaşımı \"Artık bu senden sorumlu\" diyerek ani bırakış Her iki model de risklidir. İlki tek kişiye bağımlılık üretir, ikincisi ise bağlamsız sorumluluk yükler. Sağlıklı model, karar alanını katmanlara ayırarak ilerler. İyi delegasyonun üç katmanı Ben operasyonel delegasyonu şu sırayla kurmayı faydalı buluyorum: 1. Görünürlük delegasyonu 2. Karar öncesi analiz delegasyonu 3. Kontrollü müdahale delegasyonu İlk aşamada kişi sistem sinyallerini okumayı öğrenir. Sonra yorum yapar. En son aksiyon alır. Bu sıralama atlandığında ekipler yetki almış görünür ama müdahalede yine kıdemliye geri döner. Kıdemli mühendis burada neyi netleştirmeli? Delegasyonun başarısı çoğu zaman şu dört sorunun açıklığına bağlıdır: Hangi kararlar bağımsız alınabilir? Hangi eşikte escalation zorunludur? Hangi değişiklikler gözlem altında yapılmalıdır? Geri alma sınırı kimdedir? Bu soruların cevabı kişiden kişiye değişiyorsa ekip operasyonu kurumsallaşmamıştır. <Callout type=\"tip\" title=\"Yetki devri ile risk devri aynı şey değildir\" Bir mühendise aksiyon alanı açmak, bütün riski ona yüklemek anlamına gelmez. Güvenli delegasyon gözetim ve açık sınır ister. </Callout Incident ortamında nasıl uygulanır? Incident sırasında delegasyon en hızlı bozulur. Çünkü stres altında insanlar doğal olarak \"en deneyimli kimse o yapsın\" eğilimine döner. Bu yüzden operasyonel delegasyonun kriz öncesinde normalleştirilmiş olması gerekir. Pratikte şu model iyi çalışır: Bir kişi iletişim ritmini tutar. Bir kişi hipotez akışını yönetir. Bir kişi değişiklikleri uygular. Kıdemli mühendis yalnızca kritik karar noktalarında devreye girer. Bu ayrım ekip içi öğrenmeyi de hızlandırır, çünkü sorumluluk görünür parçalara bölünür. Mentorluk boyutu neden vazgeçilmez? Delegasyon sadece görev atama olursa ekipte kaygı üretir. Mentorlukla birleştiğinde ise kapasite üretir. Kıdemli mühendislerin özellikle şu davranışları öğretici olur: Karar verirken yüksek sesle düşünmek Hangi sinyali neden daha önemli gördüğünü açıklamak Geri alma kararını geciktirmeme nedeni paylaşmak Bu sayede ekip, sadece işi yapmayı değil işi nasıl düşündüğünü de öğrenir. Sonuç Kıdemli mühendisler için operasyonel delegasyon tasarımı, rahatlamak için iş dağıtma tekniği değildir. Bu yaklaşım; ekip kapasitesi, incident dayanıklılığı ve kurumsal öğrenme hızı için temel bir mühendislik yatırımıdır. İyi delegasyon, sorumluluğu belirsizce yaymaz; onu güvenli biçimde çoğaltır.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "mentorluk",
        "operasyon-kültürü",
        "incident-management",
        "delegasyon"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-incident-iletisim-mimarisi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-incident-iletisim-mimarisi",
      "title": "Teknik Liderler için Incident İletişim Mimarisi",
      "summary": "Kesinti anında ekipler arası bilgi akışını hızlandıran iletişim modeli, rol sınırları ve karar ritmi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin incident iletisim mimarisi diagram.svg'; Kesinti anlarında teknik çözüm kadar iletişim modeli de sistemi toparlama süresini belirler. Birçok ekip teknik olarak güçlüdür; fakat durum güncellemeleri, karar sahipliği ve paydaş dili net olmadığı için incident uzar, güven azalır ve aynı anda hem operasyon hem iletişim tarafında darboğaz oluşur. Teknik liderin görevi yalnızca doğru insanı doğru işe atamak değil, bilgi akışını da mimari bir disiplin gibi tasarlamaktır. <figure <Image src={diagram} alt=\"Komuta masası, paydaş akışları ve durum güncelleme ritmini gösteren teknik şema\" / <figcaption İyi incident iletişimi, teknik müdahale akışını kesmeden yönetim ve iş tarafına güvenilir durum bilgisi taşır.</figcaption </figure Neden iletişim mimarisi gerekir? Kurumsal ortamlarda tek bir incident aynı anda dört farklı beklenti üretir: Operasyon ekibi semptomu azaltmak ister. Uygulama ekibi kök nedeni anlamaya çalışır. Yönetim tarafı etki ve toparlanma süresini duymak ister. Destek veya müşteri ekipleri dış iletişim için net cümlelere ihtiyaç duyar. Bu beklentiler tek kanalda yönetildiğinde herkes birbirini keser. Teknik ayrıntı ihtiyacı ile yönetici özeti aynı başlık altında yürümeye başlayınca ne saha ekibi rahat çalışabilir ne de iş tarafı güven hisseder. İletişim mimarisi bu çakışmayı çözmek için vardır. Üç kanallı model en pratik yaklaşım Benim en verimli gördüğüm model üç ayrı akıştan oluşur: 1. Müdahale kanalı : Komutlar, hipotezler ve teknik teyitler burada konuşulur. 2. Durum kanalı : Beş veya on beş dakikalık ritimle kısa, teyitli güncellemeler paylaşılır. 3. Paydaş kanalı : Yönetim, ürün ve müşteri tarafına etkisi sade dille aktarılır. Bu modelin avantajı şudur: birinci kanal hız için, ikinci kanal doğruluk için, üçüncü kanal güven için optimize edilir. Herkesi aynı metinle beslemeye çalışmak yerine, aynı gerçeğin üç görünümünü üretirsiniz. <Callout type=\"tip\" title=\"Ritim sabit, içerik değişken olsun\" Durum güncellemesinin zamanı tartışmaya açık olmamalıdır. Güncellenecek içerik değişebilir; fakat ritim sabit olduğunda paydaş baskısı azalır. </Callout Rolleri isim değil görev olarak tanımlayın Incident sırasında “bu kanalda kim var?” sorusu yerine “hangi rol kimin üzerinde?” sorusunu netleştirmek gerekir. Benzer deneyimlerde şu roller işleri ciddi ölçüde sadeleştirir: Incident commander : Öncelik sırasını ve karar ritmini yönetir. Teknik sürücü : Tanı ve müdahale adımlarını koordine eder. İletişim sorumlusu : Dış paydaş güncellemelerini hazırlar ve yayınlar. Kayıt tutucu : Zaman çizelgesini, kararları ve aksiyonları not eder. Küçük ekiplerde aynı kişi iki rol üstlenebilir; ama incident commander ile iletişim sorumlusunu mümkünse ayırmak gerekir. Çünkü teknik karar ritmi yükseldiğinde sade ve kontrollü iletişim üretmek ayrı dikkat ister. Durum güncellemesinin iskeleti İyi bir durum güncellemesi karmaşık değil, tekrar edilebilir olmalıdır. Benim önerdiğim şablon şu dört maddeden oluşur: Etki: Kim veya hangi sistem etkileniyor? Mevcut durum: Kesinti sürüyor mu, kısmi iyileşme var mı? Yapılan işlem: Ekip şu anda hangi düzeltme hattında çalışıyor? Sonraki güncelleme zamanı: Bir sonraki teyitli bilgi ne zaman paylaşılacak? Bu yapı yönetim tarafının en çok sorduğu soruları proaktif olarak cevaplar. Belirsizlik varsa onu da dürüst biçimde yazmak gerekir. Uydurulmuş güven, gerçek belirsizlikten daha pahalıdır. Hangi cümleler güven kaybettirir? Teknik liderlikte iletişim kalitesi çoğu zaman kullanılan dilde görünür. Şu kalıplar risklidir: “Sorun çözüldü gibi görünüyor.” “Muhtemelen ağ kaynaklı.” “Ekibe döneceğiz.” “Bir sorun var ama kapsam net değil.” Bu tür cümleler hem kararsız hem de sahipliksiz görünür. Bunun yerine daha kontrollü ifade kullanmak gerekir: “Etki daraldı, izleme sürüyor.” “Kök neden doğrulanmadı; iki hipotez üzerinde çalışıyoruz.” “Bir sonraki teyitli güncelleme 14:30'da paylaşılacak.” Buradaki amaç abartılı kesinlik değil, kontrollü dürüstlüktür. Teknik liderin asıl katkısı tercümedir Kıdemli mühendisler çoğu zaman teknik çözümün doğru kurulmasına odaklanır; ama kurumsal ortamda yüksek etkiyi yaratan şey teknik doğruluğu farklı paydaş dillerine çevirebilmektir. Veri tabanı gecikmesini anlatırken ürün ekibine “sipariş akışı sıraya girdi”, yönetim tarafına “işlem hacmi etkileniyor ama veri kaybı teyit edilmedi” diyebilmek gerekir. Aynı olayın farklı cümlelerle ama aynı gerçeklikle anlatılması liderlik pratiğidir. Sonuç Incident iletişim mimarisi, operasyon kültürünün görünmez taşıyıcı kolonlarından biridir. Net rol dağılımı, sabit güncelleme ritmi ve kontrollü dil sayesinde teknik ekip daha sakin çalışır; paydaşlar ise daha az spekülasyonla daha çok güven duyar. Teknik lider için olgunluk göstergesi yalnızca incident'ı çözmek değil, incident boyunca kurumun bilgi düzenini ayakta tutabilmektir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "incident-management",
        "teknik-liderlik",
        "iletişim",
        "operasyon-kültürü"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-platform-goclerinde-direnc-haritalama",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-platform-goclerinde-direnc-haritalama",
      "title": "Teknik Liderler İçin Platform Göçlerinde Direnç Haritalama",
      "summary": "Platform dönüşümlerinde görünmeyen ekip itirazlarını erken okumak için direnç haritalama yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin platform goclerinde direnc haritalama diagram.svg'; Platform göçleri çoğu zaman teknoloji seçimi problemi gibi anlatılır. Yeni Kubernetes standardı, yeni CI/CD hattı, yeni secret yönetimi veya yeni gözlemlenebilirlik katmanı masaya gelir; ardından ekiplerin bu yeni düzene \"neden geçmek istemediği\" sorgulanır. Oysa kurumsal dönüşümlerde esas zorluk teknik eksiklikten çok, ekiplerin farklı risk algılarıyla yaşamasıdır. <figure <Image src={diagram} alt=\"Platform göçünde ekip direnci, risk ve geçiş dalgalarını gösteren teknik şema\" / <figcaption Direnç çoğu zaman inat değil, görünmeyen operasyon maliyetinin sinyalidir.</figcaption </figure Direnç neden normaldir? Bir ürün ekibi mevcut hattını sevdiği için değil, onu öngörebildiği için korur. Yeni platform vaadi daha iyi görünse bile ekip şu soruları kendine sorar: Production sorunu çıkarsa kimi arayacağım? Geri dönüş yolu net mi? Yeni akış ek iş mi çıkaracak? Eski görünürlüğümü kaybedecek miyim? Teknik lider bu soruları \"direnç\" diye etiketleyip geçerse platform göçü politik sürtünmeye döner. Daha iyi yaklaşım, bu sinyalleri sistematik biçimde haritalamaktır. Direnç haritalama ne demektir? Ben bunu ekiplerin göçe verdiği tepkiyi üç eksende okumak olarak görüyorum: 1. Operasyonel risk algısı 2. Yetkinlik ve öğrenme maliyeti 3. Sahiplik ve kontrol kaybı hissi Bu üç alan her ekipte farklı kombinasyonlarla ortaya çıkar. Aynı göç programında bir ekip rollback belirsizliğinden rahatsız olurken, başka bir ekip self service modelinin kendisini destek ekiplerine bağımlı kılmasından korkabilir. Teknik lider bunu nasıl görünür kılar? İlk adım anket değil, yapılandırılmış görüşmedir. Teknik lider, platform ekibiyle ürün ekipleri arasında şu başlıklarda kısa oturumlar planlayabilir: Bugünkü darboğaz ne? En çok hangi manuel iş yoruyor? Geçişte en çok neyi kaybetmekten korkuyorsunuz? Başarılı göç sizin için neyi değiştirmeli? Bu görüşmelerden çıkan sinyaller genellikle dört kümeye ayrılır: Güven eksikliği Belirsiz sorumluluk sınırı Araç öğrenme maliyeti Zamanlama uyumsuzluğu <Callout type=\"tip\" title=\"Her itiraz aynı türde değildir\" Bir ekibin \"şimdi geçmeyelim\" demesi bazen siyasi direnç değil, kritik müşteri dönemine giriyor olmasıdır. Direnç tipini ayırmadan çözüm üretmek yanlış kaldıraç seçimine yol açar. </Callout Geçiş dalgaları neye göre planlanmalı? Birçok platform programı bütün ekipleri aynı hızda taşımaya çalışır. Bu yaklaşım genelde başarısız olur. Daha etkili yöntem, ekipleri direnç profiline göre dalgalara ayırmaktır: Düşük risk ve yüksek istek: erken benimseyen dalga Yüksek istek ama düşük kapasite: yakın destekli dalga Yüksek operasyon riski: kontrollü pilot dalga Politik veya organizasyonel sürtünmesi yüksek ekipler: gecikmeli dalga Buradaki amaç herkesi ikna etmek değil, doğru sırayla geçirmek ve her dalgadan öğrenilen dersi sonraki dalgaya taşımaktır. Hangi sinyaller göçün yanlış yönetildiğini gösterir? Teknik liderler çoğu zaman yalnızca adoption yüzdesine bakar. Oysa şu sinyaller daha uyarıcıdır: Ekipler yeni platformu kullanıyor ama kritik servisleri taşımıyor İstisna sayısı hızla artıyor Rollback planları belgelenmemiş Platform ekibi ticket kuyruğuna dönüşüyor Yeni standartlar yüzünden görünürlük kaybı yaşanıyor Bu işaretler, göçün teknik olarak başlamış olsa da güven üretmediğini gösterir. Kurumsal iletişim boyutu neden kritik? Platform dönüşümlerinde teknik doğruluk kadar anlatım dili de belirleyicidir. \"Artık herkes bunu kullanacak\" dili savunma üretir. Daha etkili dil şudur: Hangi problemi birlikte çözüyoruz? Hangi manuel işi ortadan kaldırıyoruz? Geçişte hangi riskleri biz üstleniyoruz? Ekibin kontrol alanı nerede korunuyor? Bu yaklaşım, platform ekibini zorlayan taraf değil; belirsizliği azaltan taraf haline getirir. Sonuç Teknik liderler için platform göçlerinde direnç haritalama, yumuşak bir iletişim egzersizi değil; doğrudan teslimat kalitesini etkileyen operasyonel bir pratiktir. Ekiplerin neden tereddüt ettiğini görünür kılmadan yapılan her göç programı, teknik olarak doğru olsa bile kurumsal olarak kırılgan kalır. Dönüşümün kalıcı olması için önce direncin şeklini anlamak gerekir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "platform-engineering",
        "teknik-liderlik",
        "degisim-yonetimi",
        "operasyon"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-risk-kontrati-ile-degisim-onayi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-risk-kontrati-ile-degisim-onayi",
      "title": "Teknik Liderler İçin Risk Kontratı ile Değişim Onayı",
      "summary": "Change approval sürecini bürokratik imzadan çıkarıp net risk kontratına dönüştüren teknik liderlik yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin risk kontrati ile degisim onayi diagram.svg'; Kurumsal yapılarda değişim onayı çoğu zaman \"kim imzaladı?\" sorusuna sıkışır. Oysa üretim sistemleri açısından asıl belirleyici soru, değişikliğin hangi risk varsayımıyla kabul edildiğidir. Teknik lider için onay sürecinin değeri, daha fazla kutucuk işaretlemekten değil; riskin sınırını, geri alma koşulunu ve görünürlük beklentisini önceden tanımlamaktan gelir. Ben buna risk kontratı demeyi daha doğru buluyorum. <figure <Image src={diagram} alt=\"Risk kontratı ile değişim onayı yaklaşımının bileşenlerini gösteren teknik şema\" / <figcaption İyi değişim onayı, kimin cesur olduğundan çok neyin ölçüldüğüyle ilgilidir.</figcaption </figure Risk kontratı neyi değiştirir? Klasik change approval toplantılarında konuşma çoğu zaman bu düzeyde kalır: Değişiklik ne zaman çıkacak? Kim nöbette olacak? Problem olursa kimi arayacağız? Bunlar gerekli ama yetersiz sorulardır. Risk kontratı ise aynı değişikliği şu eksende ele alır: 1. Beklenen etki nedir? 2. Kabul edilen başarısızlık yüzeyi nedir? 3. Durdurma veya geri alma eşiği nedir? 4. Hangi sinyal karar için zorunludur? Bu çerçeve sayesinde onay, kişisel sezgi değil ortak mühendislik dili hâline gelir. Teknik lider neden bu modelin sahibi olmalı? Çünkü riskin dili ekipler arasında kendiliğinden eşit dağılmaz. Ürün ekibi iş değerine, operasyon ekibi sistem etkisine, güvenlik ekibi kontrol zayıflığına bakar. Teknik liderin görevi bu perspektifleri tek cümlede toplayabilen net bir karar alanı kurmaktır. Ben pratikte şu başlıkları kontratın merkezine koyuyorum: Rollout tipi Etki alanı Gözlem sinyalleri Geri alma süresi Karar sahibi Bu beşli yazılmadığında kurumlar görünürde onaylı ama gerçekte belirsiz değişiklikler üretir. <Callout type=\"tip\" title=\"Onayı hızlandırmanın yolu soruları azaltmak değil netleştirmektir\" Risk kontratı iyi yazıldığında daha az toplantı gerekir. Çünkü tartışma kimlik çevresinde değil kanıt çevresinde döner. </Callout CAB yerine ne gelir? Bu noktada sık yapılan hata, \"kurul istemiyoruz\" diyerek kontrolsüz serbestlik ilan etmektir. Oysa olgun model kurulun yerini boşlukla değil, yapılandırılmış risk diliyle değiştirir. Örneğin düşük riskli değişikliklerde: standart rollout politikası önceden tanımlanır, sağlık sinyalleri otomatik ölçülür, rollback eşiği nettir, ek onay gerekmez. Yüksek riskli değişikliklerde ise insan değerlendirmesi sürer; fakat tartışmanın konusu hâlâ kontratın kendisidir, kişinin ünvanı değil. Operasyon kültürüne etkisi nedir? Risk kontratı ekipleri daha yavaş değil, daha dürüst yapar. Çünkü şöyle bir ortam yaratır: Bilinmeyen alanlar açıkça yazılabilir. \"Henüz yeterli sinyalimiz yok\" demek zayıflık sayılmaz. Geri alma kararı kişisel başarısızlık yerine sözleşme gereği kabul edilir. Bu kültür özellikle kıdemli mühendislerin davranışıyla yayılır. Bir lider kontratı ciddiye aldığında ekipler de \"onay almak\" ile \"riski anlamak\" arasındaki farkı öğrenir. Hangi değişikliklerde özellikle faydalıdır? Ben bu modeli en çok şu durumlarda yüksek değerli buluyorum: altyapı bileşeni sürüm geçişleri, ağ politikası veya egress değişiklikleri, ERP entegrasyon akışı güncellemeleri, kimlik ve erişim sınırı etkileyen rollout'lar, gözlemlenebilirlik pipeline değişiklikleri. Çünkü bu tip değişikliklerde sorun çoğu zaman yalnızca hata üretmek değil, hatanın geç fark edilmesidir. Sonuç Teknik liderler için risk kontratı ile değişim onayı, gereksiz bürokrasiyi romantize eden bir karşı çıkış değil; daha olgun bir mühendislik işletimi modelidir. Onayın değeri imza sayısından değil, riskin ne kadar açık tarif edildiğinden gelir. Bu ayrım kurulduğunda kurumlar sadece daha güvenli değişiklik yapmaz; değişiklik hakkında daha dürüst konuşmaya başlar.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "change-management",
        "risk",
        "operasyon-kültürü"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderlikte-golge-nobet-ve-yetkinlik-transferi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderlikte-golge-nobet-ve-yetkinlik-transferi",
      "title": "Teknik Liderlikte Gölge Nöbet ve Yetkinlik Transferi",
      "summary": "On-call bilgisini tek kişide tutmadan ekip içine yaymak için gölge nöbet ve mentorluk temelli işletim modeli.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderlikte golge nobet ve yetkinlik transferi diagram.svg'; Birçok kurumda operasyon bilgisi görünürde takımın, gerçekte ise birkaç kıdemli kişinin omuzundadır. Runbook'lar yazılmış olabilir, alarmlar tanımlanmış olabilir, hatta nöbet çizelgesi de vardır; ancak gerçek incident geldiğinde hangi sinyalin önemli olduğu, hangi servisin önce daraltılacağı ve hangi ekipten nasıl destek isteneceği hâlâ aynı kişilere sorulur. Bu durumun sürdürülebilir çözümü yalnızca dokümantasyon değil, gölge nöbetle desteklenen yetkinlik transferidir. <figure <Image src={diagram} alt=\"Gölge nöbet modeli üzerinden operasyon bilgisinin ekibe nasıl aktarıldığını gösteren teknik şema\" / <figcaption Bilgiyi yalnızca belgelemek yetmez; gerçek operasyon ritmi içinde paylaştırmak gerekir.</figcaption </figure Gölge nöbet neden gerekli? Çünkü üretim bilgisi çoğu zaman bağlama bağlıdır. Log satırının ne söylediğini anlamak, hangi alarmın gürültü olduğunu ayırt etmek veya rollback kararının ne zaman verileceğini sezmek; yalnızca bir belge okuyarak öğrenilmez. Operasyon kültürü, gerçek olay akışına maruz kalındığında oluşur. Gölge nöbet modeli şu boşluğu kapatır: Kıdemli mühendis üretim müdahalesini yürütür. Daha az deneyimli mühendis aynı akışı canlı olarak izler. Kararların gerekçesi olay anında sesli hâle getirilir. Müdahale sonrasında kısa bir öğrenme döngüsü tamamlanır. Bu model, \"yanında oturup bakmak\"tan daha fazlasıdır; bilinçli bir öğretim tasarımıdır. Teknik lider için doğru çerçeve nedir? Ben gölge nöbeti üç fazda düşünmeyi öneriyorum: 1. Hazırlık: sistem topolojisi, alarm kaynakları ve escalation rotası anlatılır. 2. Eşlik: gerçek olaylarda gölge mühendis karar akışını canlı takip eder. 3. Devir: düşük riskli olaylarda ilk yönlendirmeyi gölge mühendis yapar. Bu fazların her biri açık beklenti ister. Aksi halde süreç kolayca pasif gözleme döner ve yetkinlik aktarımı sınırlı kalır. Yalnızca runbook yazmak neden yetmez? Çünkü iyi runbook, görünür adımları yazar; görünmez muhakemeyi değil. Örneğin bir incident sırasında teknik lider şunları aynı anda değerlendirir: Alarmın iş etkisi var mı? Bu, daha büyük bir semptom zincirinin ilk işareti olabilir mi? Üçüncü taraf ekipleri şimdi mi yoksa birazdan mı dahil etmek gerekir? Geri alma mı, trafik daraltma mı daha güvenli? Bu muhakeme zinciri yazılabilir ama ancak birlikte yaşandığında içselleşir. Gölge nöbet bu yüzden mentorluk ile operasyonun kesişim noktasında durur. <Callout type=\"tip\" title=\"Her olay öğretim anına çevrilmez\" Kritik bir incident sırasında ana hedef etkiyi daraltmaktır. Öğretim, müdahaleyi yavaşlatmadan ve asıl komut zincirini bozmadan yapılmalıdır. </Callout Ekip süreçlerine etkisi nedir? Gölge nöbet iyi kurulduğunda üç önemli sonuç üretir: Nöbet yükü tek kişiden çıkar ve daha adil dağılır. Incident iletişimi standartlaşır. Kıdemli mühendislerin zihin içi karar modeli görünür olur. Kurumsal ölçekte bu, yalnızca bir eğitim programı değil; operasyonel kapasite çarpanıdır. Çünkü ekip büyüdükçe en pahalı kaynak, uzman kişinin zamanı değil uzmanlığın çoğaltılabilirliği hâline gelir. Hangi metrikler gerçekten anlamlı? Bu modelin başarısını sadece \"kaç kişi nöbete yazıldı\" diye ölçmek yanıltıcıdır. Daha yararlı göstergeler şunlardır: Düşük ve orta riskli incident'lerde ilk doğru müdahale oranı Escalation için geçen ortalama süre Runbook'a yeni eklenen karar notlarının kalitesi Nöbet sonrası retrospektifte bağımsız çıkarım yapabilen mühendis sayısı Bu metrikler, bilginin gerçekten transfer olup olmadığını daha iyi gösterir. Teknik liderin dili neden kritik? Yetkinlik transferi yalnızca iş devri değildir; güven devridir. Kıdemli mühendis her müdahaleyi kendisi tamamlarsa ekip ona bağımlı kalır. Buna karşılık kontrollü risk alanı açarsa ekip büyür. Bu yüzden teknik lider şu tür cümleler kurmalıdır: \"İlk hipotezi sen kur, ben doğrulayacağım.\" \"Bu alarmı neden düşük öncelik gördüğünü anlat.\" \"Burada müdahaleyi sen yaz, ben son kontrolü yapayım.\" Bu yaklaşım, mentorluk ile operasyonel güvenliği aynı anda korur. Sonuç Teknik liderlikte gölge nöbet ve yetkinlik transferi, yalnızca genç mühendisi yetiştirme yöntemi değildir. Bu model; incident kalitesini, nöbet sürdürülebilirliğini ve operasyon kültürünü doğrudan etkiler. Bilginin birkaç kıdemli kişide sıkışmadığı ekipler, sadece daha dayanıklı değil aynı zamanda daha öğretilebilir sistemler kurar.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "mentorluk",
        "on-call",
        "incident-management",
        "ekip-surecleri"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-batch-penceresiz-is-akisi-mimarisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-batch-penceresiz-is-akisi-mimarisi",
      "title": "ERP Altyapılarında Batch Penceresiz İş Akışı Mimarisi",
      "summary": "Gece batch pencerelerine bağımlı ERP süreçlerini olay odaklı ve gözlemlenebilir akışlara dönüştüren mimari yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda batch penceresiz is akisi mimarisi diagram.svg'; ERP sistemleri uzun yıllar boyunca gecelik batch pencereleri etrafında tasarlandı. Gün sonu mutabakatı, stok senkronizasyonu, finansal kapanış öncesi taşıma işleri ve dış sistem entegrasyonları belirli zaman bloklarında işlendi. Bu model hâlâ birçok kurumda çalışıyor; ancak gerçek zamanlı operasyon beklentisi yükseldikçe batch penceresi hem teknik borç hem de operasyonel darboğaz üretmeye başlıyor. Çözüm, ERP'yi bir anda yeniden yazmak değil; batch bağımlılığını mimari olarak daraltmaktır. <figure <Image src={diagram} alt=\"ERP altyapısında batch penceresiz iş akışı mimarisi bileşenlerini gösteren teknik şema\" / <figcaption Gece işleyen ağır hareketleri küçülterek gün içine dağıtmak, ERP modernizasyonunun en görünür kazanımlarından biridir.</figcaption </figure Batch penceresi neden sorun çıkarıyor? Çünkü birikimli iş yükü, riskleri de aynı zamana yığar. Gecelik akış uzadığında operasyon ekipleri şu etkilerle karşılaşır: Hata fark edildiğinde geri dönmek için zaman kalmaz. Tek bir darboğaz bütün iş zincirini geciktirir. İş etkisi sabaha kadar görünmez kalır. Kapasite planı pik yüke göre gereksiz büyük kurulur. Özellikle depo, lojistik ve finans entegrasyonu yüksek şirketlerde bu durum yalnızca teknik değil doğrudan ticari risk üretir. Batch penceresiz mimari ne demek? Bu ifade, bütün işleri anlık çalıştırmak anlamına gelmez. Daha doğru tanım şudur: yalnızca gerçekten toplu işlenmesi gereken yükleri batch olarak bırakmak, geri kalan akışları küçük ve gözlemlenebilir olay zincirlerine çevirmek. Pratikte bu dönüşüm şu katmanlarla ilerler: 1. Değişiklik üreten işlemler olay olarak dışa açılır. 2. Senkron olmayan tüketiciler idempotent çalışır. 3. Ağır mutabakat işleri daraltılmış zaman bloklarına sıkıştırılır. 4. İş akışları teknik alarm yerine iş metriğiyle de izlenir. Bu model, ERP çekirdeğini parçalamadan çevresini daha esnek kılar. En sık yapılan hata: batch'i kuyrukla yeniden adlandırmak Birçok ekip message broker ekleyince problemi çözdüğünü düşünür. Oysa eğer tüketiciler hâlâ saatlik toplu iş mantığıyla davranıyorsa sadece eski batch'i yeni bir teknolojiyle taşımış olursunuz. Mimari dönüşümün gerçek işareti şu sorularda ortaya çıkar: Olay başına işlenebilir en küçük birim nedir? Aynı kayıt tekrar gelirse akış güvenli kalıyor mu? Hata alan parça tüm zinciri durdurmadan izole edilebiliyor mu? İş etkisi panelde gerçek zamanlı görülebiliyor mu? Bu sorular cevaplanmadan yapılan modernizasyonlar, yalnızca entegrasyon görünümünü günceller. <Callout type=\"tip\" title=\"Her süreci gerçek zamanlı yapmak zorunda değilsiniz\" Finansal kapanış veya denetim odaklı bazı akışlar hâlâ toplu çalışabilir. Ama bu karar teknik alışkanlıktan değil iş gereksiniminden çıkmalıdır. </Callout Observability tarafı neden kritik? ERP akışlarında başarısızlık çoğu zaman altyapı metriğinde değil iş sonucunda görünür. Bir kuyruğun dolması, retry sayısının artması veya API gecikmesinin yükselmesi ancak iş bağlamıyla birleştiğinde anlam kazanır. Bu yüzden batch penceresiz mimaride telemetry şunları birlikte taşımalıdır: Teknik gecikme İşlem hacmi Mutabakat farkı Başarısız kayıt oranı Geri işleme kuyruğu büyüklüğü Bu görünürlük olmadan yeni mimari, eski batch modelinden daha karmaşık ama daha az anlaşılır olabilir. Kurumsal geçiş nasıl yapılmalı? En sağlıklı yaklaşım bir \"strangler\" modeli kurmaktır. Önce yüksek iş etkili ama teknik olarak çevrelenebilir bir akış seçilir. Örneğin siparişten envantere yansıyan güncelleme, stok rezervasyonları veya dağıtım merkezi olayları. Bu akış olay temelli hâle getirilir, iş metriğiyle izlenir ve bir süre eski batch ile paralel çalıştırılır. Böylece kurum: yeni davranışı güvenli ölçer, veri tutarlılığını doğrular, operasyon ekibini yeni ritme alıştırır, ERP çekirdeğini bir anda destabilize etmez. Sonuç ERP altyapılarında batch penceresiz iş akışı mimarisi, \"her şeyi stream yapalım\" çağrısı değildir. Amaç; gecelik yığılmaları azaltmak, hata etkisini küçültmek ve iş akışlarını gün içine yayılmış gözlemlenebilir parçalara bölmektir. Bu yaklaşım doğru uygulandığında ERP modernizasyonu sadece entegrasyon hızını değil, operasyonel güvenilirliği de ciddi biçimde yükseltir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "architecture",
        "integration",
        "observability",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-gizli-anahtar-dagitim-duzlemi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-gizli-anahtar-dagitim-duzlemi",
      "title": "ERP Altyapılarında Gizli Anahtar Dağıtım Düzlemi",
      "summary": "ERP entegrasyonları ve batch akışlarında sır saklama yükünü azaltmak için merkezi gizli anahtar dağıtım mimarisi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda gizli anahtar dagitim duzlemi diagram.svg'; ERP altyapıları modernizasyon konuşmalarında çoğu zaman entegrasyon, mesajlaşma ve veri akışı üzerinden ele alınır. Fakat gerçek operasyon yükü çoğu zaman daha altta, kimlik bilgileri ve gizli anahtarların nasıl dağıtıldığına gömülüdür. Batch işleri, middleware katmanları, raporlama servisleri ve üçüncü taraf entegrasyonları aynı sır setine farklı zamanlarda erişiyorsa, kurum çok hızlı biçimde görünmeyen güvenlik borcu üretir. <figure <Image src={diagram} alt=\"ERP sistemleri, entegrasyon katmanları ve merkezi secret dağıtım düzlemini gösteren teknik şema\" / <figcaption Secret yönetimi ERP dünyasında yalnızca güvenlik konusu değil, operasyonel süreklilik konusudur.</figcaption </figure Problem neden bu kadar büyür? Çünkü ERP ekosistemleri nadiren tek bir uygulamadan oluşur. Ana ERP çekirdeğine ek olarak şu katmanlar devrededir: ETL veya batch işleyiciler Entegrasyon sunucuları Dosya aktarım servisleri Raporlama araçları Scheduler veya ajan tabanlı süreçler Bu yapı içinde sırların bir kısmı konfigürasyon dosyasında, bir kısmı script içinde, bir kısmı da operasyon ekibinin paylaştığı kasalarda tutuluyorsa, gerçek sahiplik ve rotasyon takibi hızla kaybolur. Gizli anahtar dağıtım düzlemi neyi çözer? Merkezi dağıtım düzlemi, sırları tek kasada saklamakla sınırlı değildir. Asıl değer, tüketim modelini standardize etmesidir: 1. Secret hangi uygulama kimliğiyle istenir? 2. Ne kadar süreyle geçerlidir? 3. Kim ve hangi log kaydıyla erişmiştir? 4. Rotasyon olduğunda hangi iş akışları otomatik yenilenir? ERP tarafında bu yaklaşım özellikle servis hesaplarının yaşam döngüsünü yönetilebilir hale getirir. Mimari olarak hangi katmanlar olmalı? Kurumsal ölçekte faydalı olan model genelde dört katmandan oluşur: Merkezi secret kasası Kimlik doğrulama ve makine kimliği katmanı Dağıtım aracısı veya sidecar modeli Denetim ve kullanım telemetrisi Bu katmanlar sayesinde sırın hem nerede durduğu hem de nasıl tüketildiği görünür hale gelir. Özellikle batch çalışan işler için \"görev başlamadan kısa ömürlü credential al, iş bitince bırak\" modeli ciddi risk azaltır. <Callout type=\"tip\" title=\"ERP dünyasında statik parola yıllarca yaşar\" Bir entegrasyon çalışıyorsa kimse dokunmak istemez. Bu yüzden secret rotasyonu kültürü ERP tarafında daha da zordur. Merkezi dağıtım düzlemi, rotasyonu istisna değil varsayılan davranış yapmalıdır. </Callout Hangi tasarım kararları kritik? Bu alanda en çok değer üreten kararlar şunlardır: İnsan kullanıcıları ile servis kimliklerini kesin ayırmak Batch işleri için kısa ömürlü token tercih etmek Secret erişimini uygulama rolü ve ortam bazında daraltmak Acil durum erişimini normal akıştan ayırmak Denetim loglarını SIEM veya observability katmanına taşımak Bu prensipler uygulanmadan kurulan secret çözümü sadece yeni bir kasa arayüzü olur. Operasyonel gerçekler nasıl yönetilir? ERP platformlarında bakım pencereleri, dış sistem bağımlılıkları ve eski istemciler nedeniyle tam modern tasarım her zaman mümkün olmaz. Bu durumda geçiş yaklaşımı katmanlı olmalıdır: Önce en yüksek ayrıcalıklı statik sırları merkezileştir Sonra entegrasyon gruplarını role göre ayır Ardından rotasyon otomasyonunu batch ve middleware süreçlerine genişlet En son eski uygulamaları kısa ömürlü kimlik modeline taşı Bu sıralama, kurumun en riskli noktayı önce kapatmasına yardım eder. Sonuç ERP altyapılarında gizli anahtar dağıtım düzlemi tasarlamak, güvenlik ekibinin ayrı bir kontrol talebi değil; iş sürekliliğinin temel parçasıdır. Secret yönetimi dağınık kaldığında entegrasyon güvenilirliği, denetim izi ve operasyon disiplini aynı anda zayıflar. Kurumsal mimari bunu merkezi bir dağıtım problemi olarak ele aldığında, hem güvenlik hem de işletilebilirlik ciddi biçimde iyileşir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "security",
        "architecture",
        "secrets-management",
        "infrastructure"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-jump-hostsuz-yonetim-koridoru",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-jump-hostsuz-yonetim-koridoru",
      "title": "ERP Altyapılarında Jump Host'suz Yönetim Koridoru",
      "summary": "Ayrıcalıklı erişimi tek sıçrama sunucusuna bağımlı bırakmadan yöneten kurumsal erişim mimarisi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda jump hostsuz yonetim koridoru diagram.svg'; Kurumsal ERP altyapılarında ayrıcalıklı erişim çoğu zaman tek bir jump host üzerine inşa edilir. Bu yaklaşım yıllarca iş gördü; fakat günümüzde denetlenebilirlik, kayıt kalitesi, kısa ömürlü yetki ve çok ekipli işletim ihtiyaçları arttıkça tek sıçrama noktası dar boğaz haline geliyor. Daha sürdürülebilir model, erişimi bir sunucu üzerinden değil bir yönetim koridoru üzerinden tasarlamaktır. <figure <Image src={diagram} alt=\"Kimlik doğrulama katmanı, erişim broker'ı ve ERP yönetim ağı akışını gösteren teknik şema\" / <figcaption Jump host'suz modelde erişim, tek bir kalıcı ara sunucudan çok politika tabanlı broker katmanlarıyla yönetilir.</figcaption </figure Jump host neden artık yeterli değil? Tek bir jump host modeli aşağıdaki riskleri taşır: Ayrıcalıklı oturumlar tek düğüm üzerinde yoğunlaşır. Kim erişti, ne kadar süre kaldı ve hangi komutları çalıştırdı soruları tutarsız cevaplanır. Bakım veya arıza anında yönetim yolu da etkilenir. Farklı ekipler için farklı güven seviyeleri üretmek zorlaşır. ERP tarafında bu risk daha büyüktür; çünkü veritabanı yöneticileri, basis ekipleri, altyapı ekipleri ve dış entegrasyon sağlayıcıları aynı çekirdeğe farklı ihtiyaçlarla bağlanır. Yönetim koridoru yaklaşımı nedir? Buradaki fikir basittir: erişimi belirli bir makinenin üzerinden geçirmek yerine, kimlik, oturum politikası ve hedefleme mantığını ayrı katmanlara bölmektir. 1. Merkezi kimlik ve güçlü doğrulama : Kullanıcı kimliği ve ikinci faktör burada çözülür. 2. Erişim broker'ı : Kullanıcıyı uygun hedefe, uygun süre ve kayıt politikasıyla yönlendirir. 3. Hedef ajan veya proxy katmanı : ERP bileşenleri üzerinde kısa ömürlü erişim oturumu açar. 4. Kayıt ve gözlem katmanı : Oturum, komut ve olay izi merkezi sisteme akar. Bu mimaride “jump host'a kim girdi?” sorusundan “hangi kullanıcı hangi ERP bileşenine hangi bağlamla erişti?” sorusuna geçersiniz. <Callout type=\"tip\" title=\"Sunucu değil politika merkezde olsun\" Erişim akışını tek makineye bağlamak kolay görünür; ama kurumsal ölçekte asıl ölçeklenen şey erişim politikasıdır. Mimariyi de bunun etrafında kurmak gerekir. </Callout ERP özelinde neden faydalı? ERP ekosistemi saf uygulama sunucularından ibaret değildir. Genellikle şu bileşenler birlikte yaşar: Uygulama düğümleri Veritabanı katmanı Batch veya job sunucuları Entegrasyon proxy'leri Dosya aktarım uçları Bu bileşenlerin hepsi aynı yönetim modeline ihtiyaç duymaz. Veritabanına erişim daha sıkı kayıt isterken, entegrasyon job sunucusu için süre sınırlı otomasyon oturumları yeterli olabilir. Yönetim koridoru bu farkı doğal biçimde taşır. Ağ ve güvenlik tasarımında hangi sınırlar önemli? Bu modelin başarılı olması için üç sınır net çizilmelidir: Kimlik sınırı : Kullanıcı veya servis hesabı hangi rol adına işlem yapıyor? Ağ sınırı : Yönetim trafiği üretim istemci trafiğinden nerede ayrılıyor? Zaman sınırı : Verilen erişim ne kadar süre geçerli? Özellikle kısa ömürlü yetkilendirme burada kritik avantaj sağlar. Kalıcı anahtarlar veya paylaşılan bastion hesapları yerine talep bazlı erişim, incident sırasında dahi daha temiz denetim izi üretir. Operasyonel kazanım ne olur? Doğru kurulduğunda ekipler şu faydaları görür: Ayrıcalıklı erişim kayıtları daha okunabilir hale gelir. Bakım pencerelerinde erişim akışı merkezi olarak açılıp kapanabilir. Dış tedarikçi erişimi dar kapsamlı ve süreli tanımlanabilir. Incident anında hangi yönetim oturumlarının açık olduğu net izlenir. Bu, güvenlik ekibinin rahatlaması kadar operasyon ekiplerinin de hızlanması anlamına gelir. Çünkü erişim talebi artık manuel bilet akışından çok politika motoru üzerinden akar. Sonuç ERP altyapılarında jump host'suz yönetim koridoru, güvenliği karmaşıklaştırmak için değil sadeleştirmek için tasarlanmalıdır. Merkezi kimlik, kısa ömürlü erişim ve hedefe özel politika katmanları sayesinde hem denetim hem operasyon tarafı güçlenir. Kurumsal altyapılarda olgunluk, daha fazla sunucu eklemekten çok ayrıcalıklı erişimi daha az varsayımla yönetebilmektir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "güvenlik",
        "network",
        "erişim-yönetimi",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-bgp-evpn-segmentasyon-stratejisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-bgp-evpn-segmentasyon-stratejisi",
      "title": "Kurumsal Ağlarda BGP EVPN Segmentasyon Stratejisi",
      "summary": "Veri merkezi ve kampüs ağlarında segmentasyonu daha ölçeklenebilir kılan BGP EVPN yaklaşımının mimari çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal aglarda bgp evpn segmentasyon stratejisi diagram.svg'; Kurumsal ağlarda segmentasyon çoğu zaman VLAN tablosu büyüdükçe kırılgan hale gelir. Yeni uygulama zonları, yönetim ağları, ERP çevre sistemleri ve güvenlik gereksinimleri arttıkça klasik L2 genişlemesi operasyon maliyeti üretir. BGP EVPN yaklaşımı burada yalnızca veri merkezi modası değil; ağ segmentlerini daha açık sahiplikle, daha iyi görünürlükle ve daha kontrollü yayılım politikalarıyla yönetmenin yolu olarak öne çıkar. <figure <Image src={diagram} alt=\"Spine leaf topoloji, VRF sınırları ve EVPN kontrol düzlemini gösteren teknik şema\" / <figcaption EVPN, segmentlerin veri düzleminden bağımsız biçimde kontrol edilmesini sağlayarak ağ değişikliklerini daha güvenli hale getirir.</figcaption </figure Klasik segmentasyon nerede zorlanıyor? Birçok kurumda ağ segmentasyonu yıllar içinde birikmiş kural katmanlarıyla yürür: VLAN'lar lokal ihtiyaç için açılır. ACL kuralları zamanla büyür. L2 uzatmaları geçici çözüm olarak kalıcılaşır. Uygulama ekiplerinin bağımlılıkları ağ katmanında görünmez hale gelir. Bu model küçük ölçekte yönetilebilir; fakat çok veri merkezi, hibrit bulut bağlantısı veya ERP çevresinde yüksek hassasiyetli servis ayrımı gerektiğinde sorun çıkarır. Kontrol düzlemi net değilse değişiklik etkisi de net olmaz. EVPN burada neyi değiştirir? BGP EVPN'nin asıl katkısı paket taşımadan önce niyeti tanımlayabilmesidir. Hangi segmentin hangi VNI ile temsil edildiği, hangi leaf üzerinde bulunduğu ve hangi VRF altında duyurulduğu kontrol düzleminde görünür hale gelir. Böylece: Segment yayılımı seçici yapılır. Ağ genişlemesi değişiklik yönetimine daha uygun hale gelir. Taşınan broadcast alanı azalır. Güvenlik ve operasyon ekipleri ortak referans modeline kavuşur. Özellikle kurumsal mimarilerde ağ ile platform ekibi arasında ortak dil kurmak için bu görünürlük değerlidir. <Callout type=\"tip\" title=\"L2 ihtiyacını sorgulamadan EVPN'e geçmeyin\" EVPN tasarımı güçlüdür; ama her segmenti uzatmak için değil, gerçekten taşınması gereken sınırları daha kontrollü yönetmek için kullanılmalıdır. </Callout Mimariyi nasıl kurmak gerekir? Pratikte en sürdürülebilir model şu ilkelere dayanır: 1. Spine yalnızca taşıma ve yönlendirme omurgası olsun. 2. Leaf katmanında segment sahipliği net tanımlansın. 3. VRF sınırları uygulama alanı veya güven seviyesiyle eşleşsin. 4. Harici güvenlik katmanlarına çıkış rotaları merkezi olarak yönetilsin. Bu yaklaşım segmentasyonu sadece ağ operasyonunun değil, kurumsal mimarinin bir parçası haline getirir. ERP üretim zonu, entegrasyon koridoru ve yönetim düzlemi aynı fiziksel fabric üzerinde dursa bile mantıksal olarak ayrışabilir. Hangi kullanım alanlarında fark yaratır? Kurumsal ortamda en belirgin fayda şu senaryolarda görülür: Veri merkezi içindeki sunucu kümelerinin güvenli ayrımı ERP çekirdeği ile entegrasyon servislerinin farklı güven bölgelerinde çalışması Yedek veri merkezi veya felaket kurtarma ortamına kontrollü segment taşınması Kubernetes worker ağlarının geleneksel veri merkezi servisleriyle net sınırda konuşması Bu durumlarda EVPN yalnızca performans için değil, değişiklik etkisini sınırlamak için de önemlidir. Operasyon tarafında nelere dikkat edilmeli? Teknoloji seçimi kadar operasyon modeli de önemlidir. EVPN kullanan ağlar için şu disiplinler gereklidir: Segment envanteri ve VNI katalogu merkezi tutulmalı Route target politikaları sürüm kontrollü yönetilmeli Yeni VRF açılışları mimari gözden geçirme sürecinden geçmeli Telemetry tarafında BGP komşulukları ve MAC/IP ilan davranışı izlenmeli Kontrol düzlemi güçlü olsa da insan hatası tamamen kaybolmaz. Bu yüzden görünürlük ve değişiklik disiplini şarttır. Sonuç BGP EVPN segmentasyon stratejisi, kurumsal ağları yalnızca daha modern değil daha anlaşılır hale getirir. Segmentlerin hangi amaçla açıldığını, nerede yayıldığını ve hangi güven sınırında çalıştığını netleştirir. Ağın kurumsal teknoloji mimarisi içindeki rolünü güçlendirmek isteyen kurumlar için asıl değer burada oluşur: daha fazla esneklik değil, daha az belirsizlik.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "bgp",
        "evpn",
        "sistem-mimarisi",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-l3-clos-kumasina-gecis-stratejisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-l3-clos-kumasina-gecis-stratejisi",
      "title": "Kurumsal Ağlarda L3 Clos Kumaşına Geçiş Stratejisi",
      "summary": "Büyüyen veri merkezi ağlarında katmanlı bottleneck yapısından L3 Clos kumaşa geçiş için mimari yol haritası.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal aglarda l3 clos kumasina gecis stratejisi diagram.svg'; Kurumsal veri merkezi ağları uzun süre boyunca çekirdek dağıtım erişim katmanlarıyla taşındı. Bu model belli ölçeğe kadar yönetilebilir görünür; fakat east west trafik, sanallaştırma yoğunluğu ve mikro segmentasyon gereksinimi arttığında, hiyerarşik yapı çoğu zaman darboğaza dönüşür. Trafik desenleri değişirken ağ omurgası aynı kalırsa gecikme, hata alanı ve operasyon karmaşıklığı birlikte büyür. <figure <Image src={diagram} alt=\"L3 Clos kumaş topolojisi, spine leaf katmanları ve trafik akışını gösteren teknik şema\" / <figcaption L3 Clos yaklaşımı, tahmin edilebilir yatay ölçek ve daha sade hata alanları sunar.</figcaption </figure Neden L3 Clos gündeme geliyor? Geleneksel tasarımlarda ağ büyümesi çoğu zaman daha büyük çekirdek cihaz, daha karmaşık STP davranışı veya artan politik istisnalarla karşılanır. Bu yaklaşımın sınırları şuralarda görünür: Aynı rack dışı trafik için gereksiz katman geçişi Büyük L2 alanlarından kaynaklanan hata yayılımı Ölçek arttıkça zorlaşan kapasite planlaması Bakım anlarında geniş etki alanı L3 Clos kumaş ise çok sayıda küçük ve öngörülebilir bağlantıyla kapasiteyi yatay büyütmeyi hedefler. Spine leaf modeli bu yüzden sadece büyük bulut sağlayıcılarına değil, kurumsal veri merkezlerine de mantıklı hale gelmiştir. Geçiş öncesi hangi gerçekler netleştirilmeli? Birçok ekip önce cihaz listesi çıkarır, sonra mimari karara gelir. Sağlıklı sıra bunun tersidir. Önce şu sorulara cevap gerekir: 1. En baskın trafik deseni ne? 2. Hangi iş yükleri düşük gecikmeye duyarlı? 3. L2 bağımlılıkları gerçekten nerede bitiyor? 4. IP planı ve yönlendirme sınırları yeniden kurgulanabilir mi? Bu analiz yapılmadan kurulan Clos, yalnızca yeni cihazlarla eski alışkanlıkları taşır. L3 Clos'un kurumsal ortamda en büyük avantajı ne? Benim gördüğüm en önemli avantaj, arızayı ve ölçeklemeyi sadeleştirmesidir. Leaf veya spine kaybı dramatik olay olmaktan çıkar; çünkü kapasite çok sayıda benzer bağlantı arasında paylaştırılmıştır. Ayrıca politika sınırları daha net çizilir: Rack veya pod bazlı yönlendirme EVPN veya benzeri kontrol düzlemleri için daha temiz entegrasyon Segmentasyonun L2 bağımlılığından ayrılması <Callout type=\"tip\" title=\"Basitlik yeni cihazla değil, yeni sınırla gelir\" Clos tasarımının değeri sadece spine ve leaf sayısında değildir. Asıl fark, geniş L2 yayılımını sonlandırıp hata alanını bilinçli biçimde küçültmesidir. </Callout En sık yapılan geçiş hatası Kurumsal ekipler çoğu zaman eski VLAN alışkanlıklarını aynen yeni kumaşa taşır. Sonuçta topoloji değişmiş görünür ama işletim modeli değişmez. Oysa geçişin değer üretmesi için şu alanlar yeniden ele alınmalıdır: Prefix planı Route summarization sınırları Sunucu ve hypervisor uplink modeli Out of band yönetim ayrımı Telemetri ve kapasite gözlemi Bu alanlar dönüşmeden Clos yalnızca daha pahalı bir kablolama projesi olur. Operasyon ekibi nasıl hazırlanmalı? Yeni topoloji, yeni troubleshooting kası gerektirir. Ekiplerin şu başlıklarda ortak pratiğe ihtiyacı vardır: ECMP davranışı nasıl doğrulanır? Bir leaf kaybında beklenen etki nedir? BGP komşuluk sorunu hangi sırayla incelenir? Kablo ve optik hataları nasıl hızlı ayrıştırılır? Kurumsal dönüşümlerde teknik mimarinin kadar operasyonel eğitim programı da planın parçası olmalıdır. Sonuç Kurumsal ağlarda L3 Clos kumaşına geçiş, yalnızca veri merkezi ölçeğini büyütme kararı değildir. Aynı zamanda ağın hata alanını, bakım ritmini ve kapasite mantığını yeniden tanımlama işidir. Kurum bu geçişi cihaz yenileme projesi gibi değil, yönlendirme ve işletim modeli dönüşümü gibi ele aldığında gerçek fayda ortaya çıkar.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "datacenter",
        "architecture",
        "bgp",
        "infrastructure"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-observability-icin-telemetri-kontrol-duzlemi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-observability-icin-telemetri-kontrol-duzlemi",
      "title": "Kurumsal Observability için Telemetri Kontrol Düzlemi",
      "summary": "Dağınık agent ve pipeline yapıları yerine merkezî karar katmanı kurarak telemetry maliyetini ve güvenliğini yöneten mimari.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal observability icin telemetri kontrol duzlemi diagram.svg'; Kurumsal yapılarda observability yatırımı büyüdükçe iki problem aynı anda belirginleşir: veri miktarı hızla artar ve gözlemlenebilirlik mimarisi görünmez biçimde karmaşıklaşır. Her ekip kendi agent'ını, kendi sampling kuralını ve kendi telemetry yolunu seçtiğinde kısa vadede ilerleme olur; fakat orta vadede maliyet, güvenlik ve veri kalitesi birlikte bozulur. Bu noktada ihtiyaç duyulan şey daha fazla araç değil, telemetriyi yöneten bir kontrol düzlemidir. <figure <Image src={diagram} alt=\"Kurumsal observability için telemetri kontrol düzlemi ve veri akışlarını gösteren teknik şema\" / <figcaption Veri boru hattını büyütmek başka şeydir, veri davranışını yönetmek başka.</figcaption </figure Telemetri kontrol düzlemi neyi çözer? Kontrol düzlemi, telemetry üreten her bileşeni merkezileştirmez; bunun yerine dağıtık üretim üzerinde ortak politika uygular. Şu sorulara tutarlı cevap üretir: Hangi sinyal nerede örneklenmeli? Hangi veri sınıfı hangi bölgeye çıkabilir? Hangi servis için zorunlu minimum telemetry seti nedir? Maliyet baskısı geldiğinde önce ne kısılmalı, ne korunmalı? Bu cevaplar kod, konfigürasyon ve platform politikası olarak işletilmediğinde observability kısa sürede \"her şeyi topluyoruz ama ihtiyaç anında yine eksik kalıyoruz\" durumuna düşer. Veri düzlemi ile kontrol düzlemi ayrımı neden önemli? Çünkü her ajanı aynı araçta toplamak, kontrol problemini çözmez. Veri düzlemi; log, metric, trace ve event akışlarının taşındığı katmandır. Kontrol düzlemi ise bu akışların ne zaman, hangi sınırla ve hangi garantiyle işleyeceğine karar verir. Sağlıklı ayrım şu bileşenlerle kurulabilir: 1. Ortak telemetry politikaları 2. Şema ve etiket standartları 3. Sampling ve yönlendirme karar motoru 4. Veri sınıflandırma ve güvenlik kuralları 5. Maliyet görünürlüğü ve geri besleme döngüsü Bu ayrım olmadan observability platformu teknik olarak çalışsa bile yönetişim açısından okunamaz hâle gelir. Güvenlik ve uyum tarafı neden mimarinin içine yazılmalı? Kurumsal telemetri akışları çoğu zaman üretim verisine en yakın katmandır. Uygulama header'ları, kullanıcı kimlikleri, sorgu örnekleri veya ERP işlem referansları yanlış yerde toplanırsa güvenlik problemi gözlemlenebilirlik sisteminin içinde üretilir. Bu yüzden kontrol düzleminde şu sınırlar açık olmalıdır: Hassas alanlar toplanmadan önce maskelenir. Bölge dışına çıkamayacak veri sınıfları önceden etiketlenir. Üçüncü taraf observability servislerine giden akışlar ayrı kuralla yönetilir. Denetim kayıtları telemetry'den ayrı ama ilişkili tutulur. Bu disiplin güvenlik ekibiyle observability ekibini aynı masaya getirir; çatışmayı azaltır. <Callout type=\"tip\" title=\"Maliyeti sadece saklama katmanında aramayın\" Kurumsal telemetry maliyetinin büyük kısmı çoğu zaman yanlış yerde değil, gereksiz hacimde üretilen sinyalden kaynaklanır. Toplama anındaki politika daha etkilidir. </Callout Ekip özerkliği bu modelde kaybolur mu? Hayır, eğer platform doğru sınırı kurarsa tam tersine artar. Ürün ekipleri kendi dashboard, alarm ve servis bağımlılık yorumlarını korur; fakat ortak isimlendirme, minimum telemetry kontratı ve veri çıkış sınırları platform tarafından yönetilir. Bu modelde merkezileşen şey analiz değil, temel kurallardır. Örneğin: Her servis temel SLI metriğini üretmek zorundadır. Her ekip kendi özel metriğini ekleyebilir. Log şeması belirli anahtar alanları zorunlu kılar. Yüksek hacimli trace'ler yalnızca hedefli sampling ile tam toplanır. Bu yaklaşım kurumsal ölçekte birlikte çalışabilirliği ciddi biçimde artırır. Kontrol düzleminin başarısı nasıl anlaşılır? Bence üç gösterge belirleyicidir: Incident anında doğru sinyalin bulunma süresi kısalıyor mu? Telemetry maliyeti hacim artmasına rağmen öngörülebilir kalıyor mu? Yeni ekipler platforma katıldığında haftalar içinde uyum sağlayabiliyor mu? Eğer bu sorulara evet deniyorsa kontrol düzlemi yalnızca belge değil, çalışan mimari demektir. Sonuç Kurumsal observability için telemetri kontrol düzlemi, agent seçimi ya da vendor tercihi tartışmasının üst katmanında durur. Asıl mesele; veri üretimini, güvenlik sınırlarını ve maliyet davranışını birlikte yöneten bir mimari kurmaktır. Veri düzlemi kadar karar düzlemi de tasarlandığında observability sonunda ölçeklenebilir ve denetlenebilir bir kurumsal kabiliyete dönüşür.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "observability",
        "architecture",
        "telemetry",
        "security",
        "cloud"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-kontrol-duzlemi-ayristirma-stratejisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-kontrol-duzlemi-ayristirma-stratejisi",
      "title": "Kurumsal Platformlarda Kontrol Düzlemi Ayrıştırma Stratejisi",
      "summary": "Platform ekiplerinde ortak servisleri büyütürken kontrol düzlemini ürün yaşam döngüsünden ayıran mimari yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal platformlarda kontrol duzlemi ayristirma stratejisi diagram.svg'; Platform ekipleri büyüdükçe aynı problem tekrar ortaya çıkar: ortak servisler arttıkça hem hız kazanılır hem de merkezi bağımlılık riski yükselir. Bu kırılma noktasında sorulması gereken soru, \"daha fazla platform mu kuruyoruz?\" değil; hangi parçaların gerçekten kontrol düzlemi olduğudur. Kontrol düzlemini ürün yaşam döngüsünden doğru ayrıştırmak, kurumsal platformların en kritik mimari becerilerinden biridir. <figure <Image src={diagram} alt=\"Kurumsal platformlarda kontrol düzlemi ayrıştırma stratejisini gösteren teknik şema\" / <figcaption Merkezileşmesi gereken şey her servis değil, karar ve politika yüzeyidir.</figcaption </figure Kontrol düzlemi neden ayrı düşünülmeli? Çünkü platform adı altında iki farklı şey aynı sepete atılır: ekiplerin kullandığı ortak runtime ve servisler, bu servislerin nasıl yönetileceğini belirleyen kontrol mantığı. İkisini karıştırdığınızda her değişiklik platform ekibinden geçmek zorunda kalır. Bu da zamanla self service yerine gizli ticket sistemi üretir. Neler kontrol düzlemine aittir? Ben kurumsal ölçekte şu parçaları kontrol düzlemi olarak görmeyi faydalı buluyorum: 1. Politika ve guardrail'ler 2. Kimlik ve yetki sınırları 3. Gözlemlenebilirlik minimum kontratı 4. Ortam terfi ve rollback kuralları 5. Maliyet ve kapasite kotaları Bunların ortak özelliği, doğrudan ürün davranışı değil ürün davranışının sınırını belirlemeleridir. <Callout type=\"tip\" title=\"Kontrol düzlemi ile platform ürünü aynı takımda olabilir, aynı katmanda olmak zorunda değildir\" Önemli olan org şeması değil, hangi kararın kim tarafından ve hangi gecikmeyle alınabildiğidir. </Callout Ürün ekipleri neyi sahiplenmeli? Sağlıklı ayrımda ürün ekipleri şunların sahibi olur: servis yaşam döngüsü, iş mantığına yakın telemetri, rollout zamanlaması, servis içi konfigürasyon tercihleri. Platform ekibi ise bunları yöneten ortak oyun alanını ve koruma mekanizmasını kurar. Böylece merkezileşen şey operasyon kültürü olur, günlük iş akışı değil. En sık yapılan hata nedir? Platform olgunlaşırken en sık görülen hata, her yararlı bileşeni merkezi zorunluluk hâline getirmektir. Sonuçta ürün ekipleri kendi kararını veremez ama platform ekibi de bütün detaylara yetişemez. Bu model kısa vadede standart gibi görünür, orta vadede ise yavaş ilerleyen bir kuyruk üretir. Doğru ayrım şu soruyla test edilebilir: Bu bileşen olmadan ürün ekibi güvenli biçimde ilerleyemiyor mu, yoksa sadece ortak kullanım rahat mı? İlkine yakınsa kontrol düzlemi adayıdır; ikincisine yakınsa platform ürünü olabilir ama zorunlu merkez olmamalıdır. Sonuç Kurumsal platformlarda kontrol düzlemi ayrıştırma stratejisi, mimarinin soyut bir tartışması değildir. Bu ayrım; platform ekibinin darboğaz mı çarpan mı olacağını belirler. Karar, politika ve güvenlik katmanı merkezileşirken servis davranışının ürün ekibinde kalabildiği yapılar, hem daha ölçeklenebilir hem de daha öğretilebilir platformlar üretir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "platform-engineering",
        "architecture",
        "cloud",
        "governance",
        "observability"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/chrony-ile-sunucularda-zaman-drift-izleme",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/chrony-ile-sunucularda-zaman-drift-izleme",
      "title": "Chrony ile Sunucularda Zaman Drift İzleme",
      "summary": "Dağıtık Linux sunucularda saat sapmasını görünür kılmak ve operasyonel riskleri azaltmak için Chrony tabanlı rehber.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './chrony ile sunucularda zaman drift izleme diagram.svg'; Dağıtık sistemlerde zaman sapması çoğu zaman görünmez ama pahalı bir problemdir. Log korelasyonu bozulur, sertifika doğrulamaları beklenmedik şekilde hata verir, replikasyon gecikmesi yanlış yorumlanır ve incident analizi uzar. Linux sunucularda saat senkronizasyonu için Chrony kullanılıyor olsa bile, asıl değer bu davranışı sürekli izleyebildiğinizde ortaya çıkar. <figure <Image src={diagram} alt=\"Chrony ile sunucularda zaman drift izleme akışını gösteren teknik şema\" / <figcaption Zamanı yalnızca senkronize etmek yetmez; sapmayı ölçmek ve yorumlamak gerekir.</figcaption </figure Neyi izlemeliyiz? Chrony tarafında en yararlı sinyaller şunlardır: referans kaynak durumu, son offset değeri, root delay ve root dispersion, sync durumu, source değişim frekansı. Bu veriler bir araya geldiğinde sorun gerçekten ağda mı, upstream NTP kaynağında mı, yoksa tek bir sunucuda mı anlayabilirsiniz. Hızlı kontrol komutları İlk aşamada Chrony durumunu elle görünür kılmak için şu komutlar yeterlidir: Özellikle tracking çıktısındaki Last offset ve RMS offset alanları günlük işletimde çok faydalıdır. Otomasyonla izleme mantığı Basit ve etkili bir yaklaşım, bu çıktıları periyodik olarak parse edip merkezi metrik sistemine aktarmaktır. Örneğin: Bu tip bir çıktı node exporter textfile collector veya özel bir ajan üzerinden toplanabilir. <Callout type=\"tip\" title=\"Tek başına offset eşik alarmı yeterli olmayabilir\" Kısa süreli offset sıçramaları her zaman incident değildir. Kaynak kararlılığı ve sync durumu ile birlikte değerlendirmek daha doğru sonuç verir. </Callout Hangi ortamlarda özellikle kritik? Zaman drift izlemesi şu yapılarda yüksek değer üretir: birden fazla veri merkezi olan kurumsal ağlar, ERP ve finansal işlem sistemleri, sertifika ve kimlik doğrulaması yoğun platformlar, log korelasyonuna dayanan SIEM mimarileri. Bu ortamlarda küçük saat sapmaları bile görünürlük kalitesini doğrudan bozar. Sonuç Chrony ile sunucularda zaman drift izleme, \"NTP çalışıyor\" demekten daha olgun bir işletim yaklaşımı sunar. Saatin ne kadar doğru olduğu, çoğu zaman sistemin ne kadar anlaşılır olduğunu belirler. Bu nedenle zaman sapması, görünmez altyapı konusu değil aktif gözlemlenebilirlik sinyali olarak ele alınmalıdır.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "linux",
        "sunucu",
        "observability",
        "chrony",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/ebpf-ile-ag-akis-gozlemi-ve-slo-korelasyonu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/ebpf-ile-ag-akis-gozlemi-ve-slo-korelasyonu",
      "title": "eBPF ile Ağ Akış Gözlemi ve SLO Korelasyonu",
      "summary": "Kernel seviyesinde ağ akışlarını izleyip servis gecikmesi ve hata bütçesi sinyalleriyle ilişkilendirme yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './ebpf ile ag akis gozlemi ve slo korelasyonu diagram.svg'; Servis gecikmesi arttığında çoğu ekip önce uygulama loglarına bakar. Oysa bazı problemlerde cevap uygulama katmanında değil, çekirdek seviyesindeki ağ davranışında saklıdır. eBPF tabanlı akış gözlemi burada güçlü bir pencere açar: paket yakalama maliyetine girmeden, kernel içindeki ağ olaylarını servis seviyesindeki SLO sinyalleriyle ilişkilendirebilirsiniz. <figure <Image src={diagram} alt=\"eBPF sensörleri, ağ akışları ve SLO panelini gösteren teknik şema\" / <figcaption Kernel seviyesinde toplanan akış sinyalleri, servis hedefleriyle ilişkilendirildiğinde ağ davranışı daha anlamlı hale gelir.</figcaption </figure Problem neden sadece metrikle çözülemiyor? CPU, bellek ve istek sayısı metrikleri birçok durumda yeterlidir; ancak ağ kuyruğu, yeniden iletim, bağlantı kapanışı veya gecikme dağılımı bozulduğunda daha ince sinyallere ihtiyaç olur. Özellikle: Node sağlıklı görünürken belirli servis çağrıları yavaşlıyorsa Aynı uygulama bazı bölgelerde iyi, bazılarında kötü davranıyorsa Paket kaybı yerine bağlantı davranışı sorun yaratıyorsa eBPF bu noktada sistem çağrıları ve ağ olayları üzerinden düşük seviyeli görünürlük sağlar. Minimum mimari nasıl olmalı? Başlangıç için üç bileşen yeterlidir: 1. eBPF sensörü : Socket, TCP veya ağ gecikmesiyle ilgili olayları toplar. 2. Toplama katmanı : Ölçümleri merkezi telemetry hattına taşır. 3. Korelasyon katmanı : Ağ sinyallerini servis adı, ortam ve SLO göstergeleriyle eşler. Amaç mümkün olduğunca az veriyle anlamlı görünürlük üretmektir. Tüm paketleri kaydetmek yerine, karar verecek kadar akış özeti toplamak daha sürdürülebilir olur. Hangi sinyallerle başlamak mantıklı? İlk aşamada şu sinyaller yüksek değer üretir: TCP yeniden iletim sayısı SYN bekleme süresi Bağlantı kurulma gecikmesi Soket kapanış nedenleri Hedef servis veya port bazında akış hacmi Bu veriler tek başına yorumlanmazsa çok gürültü üretir. Asıl değer, bunları SLO görünümüyle birleştirdiğinizde ortaya çıkar. <Callout type=\"tip\" title=\"Önce etiket modelini tasarlayın\" eBPF verisi çok hızlı büyür. service, environment, node, region ve mümkünse owner etiketleri olmadan topladığınız veri, kısa sürede aranamaz hale gelir. </Callout Basit bir korelasyon örneği Örneğin sipariş servisi için hata bütçesi tüketimi artıyor ve aynı anda aşağıdaki sinyalleri görüyorsunuz: Belirli node grubunda TCP retransmit oranı yükseliyor Aynı gruptaki upstream çağrılarda bağlantı kurulum süresi uzuyor Uygulama loglarında açık hata yok Bu durumda problem uygulama kodundan çok ağ veya altyapı yolu üzerinde olabilir. eBPF verisi, “servis yavaş” gözlemini “hangi ağ davranışı bozuk?” sorusuna çevirmeye yardım eder. Toplama tarafında nelere dikkat edilmeli? eBPF araçları güçlüdür ama ölçüsüz kullanılırsa maliyet çıkarır. Şunlara dikkat edin: Tüm node'larda aynı anda en yüksek örneklemeyi açmayın Çekirdek sürümü uyumluluğunu kontrol edin Ham olay yerine önceden özetlenmiş metrik veya akış kaydı taşıyın Yalnızca operasyonel karar üreten probe'ları açık tutun Küçük başlayıp değer doğrulandıktan sonra genişletmek en sağlıklı yoldur. SLO ile ilişkilendirme neden önemli? Observability tarafında en sık yapılan hata, yeni bir veri kaynağını sadece “daha fazla veri” olarak görmek. Oysa eBPF verisinin değeri, servis hedefleriyle ilişkilendirildiğinde ortaya çıkar: Hangi ağ anomalisi kullanıcıya yansıdı? Hangi bozulma sadece altyapı seviyesinde kaldı? Hangi node veya segment hata bütçesini gerçekten tüketiyor? Bu sayede ekipler her kernel sinyaline tepki vermek yerine, kullanıcı etkisi yaratan davranışlara odaklanır. Sonuç eBPF ile ağ akış gözlemi, ağ ve uygulama ekipleri arasındaki görünmez duvarı zayıflatır. Kernel seviyesindeki davranışı servis hedefleriyle birleştirdiğinizde, özellikle performans bozulmaları ve bölgesel anormallikler çok daha hızlı teşhis edilir. Güçlü gözlemlenebilirlik, daha fazla dashboard değil; doğru seviyedeki sinyali doğru iş etkisiyle eşleştirebilmektir.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "ebpf",
        "network",
        "slo",
        "linux"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/frrouting-ile-bgp-failover-lab-rehberi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/frrouting-ile-bgp-failover-lab-rehberi",
      "title": "FRRouting ile BGP Failover Lab Rehberi",
      "summary": "Çift uplink kullanan sunucu veya edge ortamlarında BGP failover davranışını laboratuvarda doğrulama adımları.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './frrouting ile bgp failover lab rehberi diagram.svg'; BGP failover senaryolarını üretimde öğrenmek pahalıdır. Çift uplink kullanan edge sunucular, transit router'lar veya servis gateway'leri için daha güvenli yol, davranışı küçük bir laboratuvarda önceden gözlemlemektir. FRRouting bu iş için hafif ve yeterince esnek bir araç sağlar. <figure <Image src={diagram} alt=\"Çift router, FRRouting düğümü ve BGP yol değişimini gösteren teknik şema\" / <figcaption Laboratuvar topolojisi küçük olsa da amaç nettir: komşu kaybı ve rota değişiminin sistem davranışını önceden görmek.</figcaption </figure Hangi senaryoyu test ediyoruz? Bu rehberde tek bir FRRouting düğümünün iki ayrı upstream router ile BGP komşuluğu kurduğunu varsayıyoruz. Amaç: Normal durumda birincil yolu tercih etmek Bir upstream düştüğünde trafiğin ikincil yola akmasını görmek Failback anında davranışı ölçmek Bu düzen, veri merkezi edge katmanı veya kurumsal servis çıkış noktası için iyi bir başlangıç simülasyonudur. Basit lab topolojisi Örnek IP planı şöyle olabilir: edge01: 10.10.10.10/24 rtr a: 10.10.10.1/24 rtr b: 10.10.10.2/24 Yerel ASN: 65010 Upstream ASN'ler: 65100 ve 65200 Laboratuvarı container, sanal makine veya ağ namespace'leri ile kurabilirsiniz. Önemli olan komşulukların gerçekten kurulması ve rota tercihinin gözlenebilmesidir. FRRouting kurulumu ve temel ayar Ubuntu tabanlı bir düğümde kurulum mantığı şu şekildedir: Ardından temel frr.conf iskeleti: Buradaki mantık basit: rtr a üzerinden gelen yollar daha yüksek local preference ile seçiliyor. <Callout type=\"tip\" title=\"Önce gözlenebilirlik ekleyin\" Failover testi yapmadan önce show bgp summary, show ip route ve arayüz sayaçlarını birlikte izleyin. Rota değişimi ile gerçek trafik davranışı her zaman aynı hızda görünmeyebilir. </Callout Test adımları İlk doğrulama için şu komutlar yeterlidir: Sonra birincil komşuyu düşürün. Bunun için lab ortamınıza göre arayüz kapatma, BGP oturum kesme veya iptables ile TCP/179 bloklama gibi yöntemler kullanılabilir. Beklenen sonuç: 1. rtr a komşuluğu düşer. 2. En iyi yol rtr b üzerinden seçilir. 3. FIB güncellenir. 4. Uygulama akışı kısa bir geçiş süresinden sonra devam eder. Failback sırasında ise en sık gözlenen sorun, rotanın çok hızlı geri dönmesi nedeniyle bağlantı flap'leridir. Bu durumda route dampening değil, daha kontrollü tercih politikaları ve üst katman zamanlaması düşünülmelidir. Ölçülmesi gereken metrikler Sadece “rota değişti” demek yeterli değildir. Şunları ölçün: BGP komşuluk düşüş süresi Yeni en iyi yolun seçilme süresi Uygulama seviyesinde başarısız istek sayısı Failback sırasında tekrar seçimin ne kadar sürdüğü Bu ölçümler, ağ tasarımının uygulama davranışına gerçekten nasıl yansıdığını gösterir. Üretime geçmeden önce hangi tuzakları kontrol etmeli? İki upstream aynı prefix'i farklı topluluklarla mı duyuruyor? Varsayılan rota mı, belirli prefix'ler mi taşınıyor? ECMP isteniyor mu, yoksa kesin birincil/ikincil akış mı gerekli? Uygulama bağlantıları kısa kesintilere toleranslı mı? Laboratuvarın amacı teoriyi kanıtlamak değil, üretim varsayımlarını erkenden kırmaktır. Sonuç FRRouting ile kurulan küçük bir BGP laboratuvarı, failover davranışını anlamak için yeterince güçlüdür. Özellikle edge servisleri, yönetim ağları ve kurumsal çıkış noktaları için rota seçiminin pratik etkisini önceden görmek ciddi operasyon kazancı sağlar. Ağ dayanıklılığı, yalnızca yedek bağlantı eklemekle değil, o yedeğin gerçekten ne zaman ve nasıl devreye girdiğini ölçmekle oluşur.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "network",
        "bgp",
        "frrouting",
        "yüksek-erişilebilirlik",
        "lab"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/grafana-mimir-ile-uzun-sureli-metrik-saklama",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/grafana-mimir-ile-uzun-sureli-metrik-saklama",
      "title": "Grafana Mimir ile Uzun Süreli Metrik Saklama",
      "summary": "Prometheus darboğazına düşmeden çok tenant'lı ortamlarda uzun süreli metric retention tasarlamak için pratik rehber.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './grafana mimir ile uzun sureli metrik saklama diagram.svg'; Prometheus tek başına güçlü bir başlangıç noktasıdır; ancak metrik hacmi büyüdükçe ve saklama süresi uzadıkça merkezi bir darboğaza dönüşebilir. Özellikle birden fazla cluster, ekip veya müşteri segmenti için ortak observability platformu kuruyorsanız, retention süresi ile sorgu performansı arasındaki dengeyi yalnızca lokal TSDB ile taşımak zorlaşır. Grafana Mimir bu noktada, Prometheus uyumlu ama daha kurumsal ölçekte saklama ve sorgu kabiliyeti sunar. <figure <Image src={diagram} alt=\"Grafana Mimir ile uzun süreli metrik saklama akışını gösteren teknik şema\" / <figcaption Prometheus'u söküp atmak yerine, onu daha büyük bir metric platformunun kenar toplayıcısı gibi konumlandırmak daha sağlıklıdır.</figcaption </figure Ne zaman Mimir düşünmelisiniz? Şu belirtiler görünmeye başladıysa Mimir anlamlıdır: Prometheus instance'ları sık sık bellek baskısına giriyorsa Retention süresi uzadıkça sorgular belirgin biçimde yavaşlıyorsa Çok tenant'lı ayrım ihtiyacı doğduysa Uzak depolama için tutarlı bir mimari istiyorsanız Amaç yalnızca daha fazla veri tutmak değil; veri hacmi artarken operasyon yükünü kontrol altında tutmaktır. Temel mimari parçalar Kurulumdan önce rol ayrımını netleştirmek gerekir. Basit bir Mimir kurulumunda bile şu bileşenler önemlidir: 1. Prometheus veya Alloy gibi edge scraper'lar 2. Distributor ve ingester katmanı 3. Object storage tabanlı kalıcı metric deposu 4. Querier ve query frontend 5. Tenant ve limit politikaları Küçük ortamda monolithic moda geçebilirsiniz; ancak kurumsal kullanımda bileşenleri ayrı düşünmek daha doğru kapasite planı yapmanızı sağlar. Başlangıç için pratik dağıtım akışı İlk geçişte bütün scraping işini taşımaya çalışmayın. Önce bir veya iki Prometheus kaynağını remote write ile Mimir'e bağlamak daha güvenlidir. Genel akış şöyle olabilir: Ardından veri akışını şu açıdan doğrulayın: ingestion gecikmesi rejected sample sayısı label cardinality baskısı sorgu yanıt süresi Bu doğrulama yapılmadan retention süresini hızla büyütmek pahalı sürprizlere yol açar. <Callout type=\"tip\" title=\"Retention artırmadan önce cardinality temizliği yapın\" Uzun süreli saklamanın maliyeti çoğu zaman yalnızca gün sayısından değil, kontrolsüz label alanlarından büyür. Önce veri disiplinini kurun. </Callout Object storage seçimi neden kritik? Mimir'in ekonomik avantajı büyük ölçüde object storage kullanımından gelir. Bu yüzden bucket politikası, lifecycle ayarları ve ağ erişim modeli mimarinin parçasıdır. Dikkat edilmesi gereken başlıklar şunlardır: Bölge içi erişim gecikmesi Sunucu tarafı şifreleme Lifecycle ile eski blok yönetimi Yedekleme ve silme korumaları Kurumsal ortamlarda güvenlik ekibiyle birlikte tenant sınırlarını ve bucket erişim modelini erken netleştirmek gerekir. Çok tenant'lı yapı nasıl yönetilir? En yaygın hata bütün ekipleri tek tenant altında toplamaktır. Başlangıçta pratik görünür ama limit, kota ve sorgu izolasyonu kaybolur. Daha sağlıklı yaklaşım: tenant sınırını ekip veya ortam bazında çizmek, ortak dashboard'lar için federasyon mantığı kurmak, global limitleri tenant bazlı görünür kılmak. Bu sayede bir ekibin kontrolsüz metriği bütün platformu baskılamaz. Operasyonel olarak neyi izlemelisiniz? Mimir'i kurduktan sonra asıl iş başlar. Platformun kendi sağlığını da gözlemlemeniz gerekir: ingester memory ve WAL baskısı compaction süreleri query frontend cache etkinliği distributor reject nedenleri object storage hata oranı Mimir'i sadece saklama katmanı gibi görmek hatadır; bu da kendi içinde aktif işletim isteyen bir platformdur. Sonuç Grafana Mimir ile uzun süreli metrik saklama, Prometheus'tan vazgeçmek değil onu kurumsal ölçekte desteklemek anlamına gelir. Doğru tenant sınırları, remote write disiplini, object storage tasarımı ve cardinality kontrolü kurulduğunda Mimir; metric retention süresini uzatırken sorgu güvenilirliğini ve operasyonel öngörülebilirliği birlikte artırır.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "grafana",
        "mimir",
        "observability",
        "prometheus",
        "cloud"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/haproxy-ile-ic-servisler-icin-pasif-saglik-kontrolu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/haproxy-ile-ic-servisler-icin-pasif-saglik-kontrolu",
      "title": "HAProxy ile İç Servisler İçin Pasif Sağlık Kontrolü",
      "summary": "Aktif probe trafiğini artırmadan, iç servis hatalarını gerçek istek akışından yakalamak için HAProxy yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './haproxy ile ic servisler icin pasif saglik kontrolu diagram.svg'; İç servislerde sağlık kontrolü çoğu zaman aktif probe üzerinden düşünülür. Bu model işe yarar; ancak her zaman yeterli değildir. Özellikle stateful uygulamalar, pahalı handshake yapan servisler veya sadece gerçek trafik altında hata veren akışlarda aktif probe yanlış bir güven hissi üretebilir. HAProxy'nin pasif sağlık kontrolü yaklaşımı, gerçek istek akışını gözlemleyerek daha doğal bir sinyal sağlar. <figure <Image src={diagram} alt=\"HAProxy ile pasif sağlık kontrolü akışını gösteren teknik şema\" / <figcaption Bazen en doğru sağlık sinyali sentetik probe değil, gerçek kullanıcı trafiğinin davranışıdır.</figcaption </figure Pasif sağlık kontrolü ne demek? Sunucuya ayrı bir test isteği göndermek yerine, gerçek isteklerdeki hata oranına ve başarısız bağlantılara bakarak backend'i geçici olarak kötü kabul etmektir. Bu modelde HAProxy şu tip sinyalleri kullanır: bağlantı hataları, timeout'lar, belirli hata kodları, üst üste başarısız cevaplar. Bu yaklaşım aktif kontrolü tamamen ortadan kaldırmak zorunda değildir; ama özellikle iç trafik için güçlü bir ek sinyal sunar. Basit bir yapılandırma örneği Burada on error mark down, gerçek hata davranışının backend durumuna etkisini hızlandırır. Bunu log ve metrik gözlemiyle birlikte kullanmak gerekir. Ne zaman özellikle faydalı? Pasif sağlık kontrolü şu senaryolarda çok yararlıdır: aktif probe ile pahalı işlem tetiklenen servisler, sadece belirli header veya auth akışında hata veren uygulamalar, iç ağda yoğun east west trafik taşıyan API'ler, kısmi hata yaşayan ama tamamen down olmayan backend'ler. Bu tip servislerde sentetik probe çoğu zaman sorunun yalnızca küçük bir kısmını görür. <Callout type=\"tip\" title=\"Pasif kontrolü tek başına kör kullanmayın\" Trafik yoksa pasif sağlık kontrolü de sinyal üretmez. Bu yüzden düşük hacimli servislerde aktif kontrol ile birlikte düşünmek daha güvenlidir. </Callout İzleme tarafında neye bakmalı? HAProxy istatistikleri ve logları şu alanlarda çok iş görür: backend başına hata oranı, retry ve redispatch sayısı, srv abrt ve econ artışları, kısa süreli mark down dalgaları. Bu veriler yalnızca load balancer sağlığını değil, arka taraftaki uygulamanın davranış kalitesini de ortaya çıkarır. Sonuç HAProxy ile iç servisler için pasif sağlık kontrolü, özellikle gerçek trafik altında ortaya çıkan hataları görünür kılmak için güçlü bir tekniktir. Aktif probe hâlâ değerlidir; ancak onu tek hakikat kaynağı yapmak çoğu zaman eksik kalır. Gerçek isteğin sonucunu sağlık sinyaline çevirebildiğinizde, load balancing katmanı daha dürüst karar vermeye başlar.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "haproxy",
        "network",
        "observability",
        "devops",
        "sunucu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/keepalived-ile-yonetim-duzlemi-icin-vrrp-failover",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/keepalived-ile-yonetim-duzlemi-icin-vrrp-failover",
      "title": "Keepalived ile Yönetim Düzlemi İçin VRRP Failover",
      "summary": "İç yönetim servislerinde tekil VIP bağımlılığını azaltmak için Keepalived tabanlı VRRP failover yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './keepalived ile yonetim duzlemi icin vrrp failover diagram.svg'; Yönetim düzlemi servisleri çoğu kurumda ikinci planda kalır; ama bozulduklarında etkisi büyüktür. İç DNS paneli, bastion portalı, konfigürasyon aracı veya operasyon API'si gibi servisler tekil bir IP veya tek bir sanal makineye bağlı kaldığında bakım anları gereksiz risk üretir. Tam ölçekli load balancer gerekmeyen, ama temel süreklilik isteyen durumlarda Keepalived ile VRRP failover sade ve etkili bir seçenektir. <figure <Image src={diagram} alt=\"İki yönetim düğümü arasında VRRP tabanlı sanal IP failover akışını gösteren teknik şema\" / <figcaption VRRP ile amaç yük dağıtmak değil, yönetim giriş noktasını öngörülebilir biçimde taşımaktır.</figcaption </figure Hangi senaryoda anlamlı? Bu model özellikle şu tür servislerde işe yarar: İç erişime açık bastion veya jump servisleri Yönetim API'leri Hafif dashboard veya portal bileşenleri Dağıtık olmayan ama kısa kesintiye tahammülü düşük araçlar Eğer uygulamanız aktif aktif davranacak kadar stateless ve yatay ölçekliyse farklı çözümler gerekir. Keepalived tarafı daha çok giriş noktasını yüksek erişilebilir yapmak için uygundur. Mimari nasıl kurulur? En sade model iki Linux düğümünden oluşur: 1. node a başlangıçta MASTER 2. node b BACKUP 3. İki düğüm aynı L2 segmentte VRRP anonsu yapar 4. Servis için ortak bir VIP atanır Normal durumda trafik VIP üzerinden node aya gelir. Sağlık kontrolü bozulduğunda Keepalived önceliği düşürür ve VIP node bye geçer. Basit bir yapılandırma örneği Temel mantık şöyledir: BACKUP düğümünde aynı blok daha düşük priority ile tanımlanır. Asıl kritik nokta sağlık kontrolü script'inin gerçekten servis doğrulaması yapmasıdır. Sadece proses çalışıyor kontrolü çoğu zaman yeterli değildir. <Callout type=\"tip\" title=\"Health check gerçekten işe yaramalı\" Port dinliyor diye servis sağlıklı sayılmamalı. Özellikle yönetim API'lerinde bir endpoint doğrulaması veya iç bağımlılık kontrolü yapmak daha güvenlidir. </Callout Hangi ağ ayrıntıları gözden kaçıyor? VRRP kurulumlarında sık karşılaşılan sorunlar genellikle uygulamadan değil ağ davranışından gelir: Gratuitous ARP'nin switch veya güvenlik katmanı tarafından bastırılması Yanlış MTU veya VLAN eşleşmesi Aynı virtual router idnin başka segmentte çakışması nopreempt davranışının gereksinime uymaması Bakım penceresiz operasyon istiyorsanız, failover davranışını üretim öncesi kontrollü biçimde test etmek şarttır. Operasyon için hangi kontroller eklenmeli? Kurulum tamamlandıktan sonra aşağıdaki sinyaller mutlaka izlenmelidir: VRRP durum değişimleri Health check başarısızlık sayısı VIP geçiş süresi Failover sonrası uygulama yanıtı ARP tablosu yakınsama gecikmesi Bu metrikler olmadan \"yüksek erişilebilir\" yapı kurulduğunu düşünmek erken olur. Sonuç Keepalived ile yönetim düzlemi için VRRP failover, pahalı ve ağır bir yüksek erişilebilirlik mimarisi kurmadan giriş noktasını dayanıklı hale getirmek için pragmatik bir yöntemdir. Doğru sağlık kontrolü, ağ davranışı bilgisi ve ölçümleme ile birlikte kullanıldığında, özellikle iç operasyon servislerinde ciddi risk azaltımı sağlar.",
      "date_published": "2026-04-06T00:00:00.000Z",
      "date_modified": "2026-04-06T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "network",
        "linux",
        "high-availability",
        "keepalived",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-operasyonel-sakinlik-pratigi",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-operasyonel-sakinlik-pratigi",
      "title": "Teknik Liderler İçin Operasyonel Sakinlik Pratiği",
      "summary": "Incident, değişim baskısı ve ekip gerilimi altında sakin kalabilen teknik liderlik davranışlarının pratik çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin operasyonel sakinlik pratigi diagram.svg'; Teknik liderlik çoğu zaman vizyon, mimari doğruluk ve ekip gelişimi üzerinden anlatılır. Fakat kurumsal yapılarda liderliğin gerçek sınavı çoğunlukla daha az romantik anlarda ortaya çıkar: incident sırasında, zor bir değişiklik öncesinde, beklenmedik bir müşteri etkisinde ya da ekipler arası tansiyon yükseldiğinde. Bu anlarda teknik liderin ilk görevi en parlak çözümü üretmek değil, operasyonel sakinliği korumaktır. <figure <Image src={diagram} alt=\"Yüksek baskı altında karar veren teknik liderin operasyonel sakinlik çerçevesini gösteren teknik şema\" / <figcaption Sakinlik pasiflik değildir; yüksek baskı altında berrak karar üretme disiplinidir.</figcaption </figure Operasyonel sakinlik neden ayrı bir beceri? Çünkü teknik doğruluk ile davranışsal etki aynı şey değildir. Bir lider doğru çözümü biliyor olabilir; ama bunu panikle, dağınık önceliklerle veya suçlayıcı dille yönetirse ekip kapasitesini düşürür. Incident ortamında insanlar çoğu zaman liderin söylediği cümleyi değil, taşıdığı ritmi kopyalar. Ben operasyonel sakinliği üç davranışta görüyorum: 1. Belirsizliği sadeleştirmek 2. Önceliği daraltmak 3. Ritmi kontrol etmek Bu üçlü olmadan bilgi çokluğu, ekip için güven üretmez. Sakin görünen ama etkisiz liderlik başka bir problem Burada sık yapılan hata, sakinliği yavaşlık veya duygusuzluk sanmaktır. Oysa iyi teknik lider yüksek baskıda sessiz kalmaz; aksine iletişimi daha sıkılaştırır. Fark şuradadır: Gürültü üretmez Suçlu aramaya erken başlamaz Aynı anda beş farklı öncelik açmaz Ekiplerin durumunu tek cümlede özetleyebilir Bu tavır, özellikle platform ve operasyon ekiplerinde bulaşıcı etki yaratır. Incident anında ilk 10 dakika neden belirleyici? Çünkü ekip o sırada yalnızca sistemi değil, birbirini de okumaya çalışır. Teknik lider ilk dakikalarda dağınık davranırsa, insanlar kendi önceliğini kendi belirlemeye başlar. Sonuçta paralel ama kopuk müdahaleler ortaya çıkar. İlk dakikalarda benim faydalı bulduğum çerçeve şudur: Etkiyi tek cümlede tarif et O anki ana hipotezi söyle Bir sonraki kontrol noktasını zamanla belirt İletişim kanalını sabitle Bu kadar basit bir disiplin bile ekip tansiyonunu ciddi biçimde düşürür. <Callout type=\"tip\" title=\"Hızlı olmak ile aceleci olmak aynı şey değildir\" Incident sırasında ekipler çoğu zaman hız baskısı altındadır. Fakat aceleci liderlik, aynı hatayı daha hızlı tekrarlatır. Sakin liderlik ise karar kalitesini düşürmeden hız üretir. </Callout Operasyonel sakinlik ekip kültürünü nasıl etkiler? Kıdemli mühendisler ve teknik liderler yalnızca kendi kararlarıyla değil, ekipte normal kabul edilen davranış standardıyla da etki üretir. Eğer lider: status update'leri net istiyorsa, bilinmeyeni rahatça söyleyebiliyorsa, geri alma kararını zayıflık gibi çerçevelemiyorsa, postmortem sırasında savunmaya değil öğrenmeye yöneliyorsa, ekip zamanla aynı kültürü içselleştirir. Bu yüzden operasyonel sakinlik bireysel karakter değil, kurumsal alışkanlık üretme aracıdır. Baskı altında dil neden bu kadar önemli? Kurumsal yapılarda teknik liderin dili sadece bilgi taşımaz; politik risk de taşır. \"Kim yaptı?\", \"neden hâlâ düzelmedi?\" veya \"bunu konuşmak için zamanımız yok\" gibi cümleler kısa vadede sert görünür, uzun vadede ise ekipleri savunmaya iter. Savunmaya geçen ekip daha az görünürlük üretir. Daha iyi dil genellikle daha yalındır: \"Şu an bildiğimiz bu.\" \"Bilmediğimiz kısım şu.\" \"Şimdi tek öncelik etkiyi daraltmak.\" \"Kök neden sonrası için ayrıca zaman ayıracağız.\" Bu çerçeve, teknik otoriteyi zayıflatmaz; tam tersine artırır. Mentorluk boyutu nerede başlar? Operasyonel sakinlik ancak transfer edilebildiğinde kıymetlidir. Teknik lider, daha az deneyimli mühendisleri yalnızca ticket veya tasarım incelemesinde değil, kriz anındaki davranış biçiminde de yetiştirir. Bunun için sonrası kadar olay anı da öğretim alanıdır: Neden rollback seçildiğini açıklamak Neden tek komuta kanalı kurulduğunu göstermek Neden spekülasyon yerine kanıt istendiğini anlatmak Böylece sakinlik, \"o kişiye özel bir özellik\" olmaktan çıkar; ekip pratiğine dönüşür. Sonuç Teknik liderler için operasyonel sakinlik pratiği, yumuşak bir karakter özelliği değil; yüksek etkili mühendislik davranışıdır. Incident yönetimi, platform dönüşümü ve kurumsal iletişim baskısı altında ekiplerin en çok ihtiyaç duyduğu şeylerden biri berrak ritimdir. Lider bunu sağlayabildiğinde, sadece problemi çözmez; ekibin gelecekte problemi çözme şeklini de kalıcı biçimde değiştirir.",
      "date_published": "2026-04-05T00:00:00.000Z",
      "date_modified": "2026-04-05T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "incident-management",
        "operations",
        "mentorluk"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-modernizasyonunda-entegrasyon-sozlesmesi-yonetisimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-modernizasyonunda-entegrasyon-sozlesmesi-yonetisimi",
      "title": "ERP Modernizasyonunda Entegrasyon Sözleşmesi Yönetişimi",
      "summary": "ERP çevresindeki servislerin sürüm, sahiplik ve değişim sınırlarını koruyan entegrasyon sözleşmesi yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp modernizasyonunda entegrasyon sozlesmesi yonetisimi diagram.svg'; ERP modernizasyonu denildiğinde kurumlar çoğu zaman uygulama yenileme, buluta taşıma veya entegrasyon platformu seçimi üzerinde durur. Oysa asıl kırılganlık genellikle ERP'nin çevresinde biriken entegrasyon katmanında saklıdır. Satış, finans, depo, insan kaynakları ve raporlama sistemleri yıllar içinde aynı çekirdeğe farklı dillerde bağlanır. Modernizasyon başladığında sorun kod değil, sözleşmesiz bağımlılıkların görünür hâle gelmesidir. <figure <Image src={diagram} alt=\"ERP çekirdeği ile çevre servisler arasındaki entegrasyon sözleşmesi katmanlarını gösteren teknik şema\" / <figcaption ERP modernizasyonunun başarısı, entegrasyonların kaç tane olduğundan çok hangi kurallarla yaşadığına bağlıdır.</figcaption </figure Entegrasyon sözleşmesi neden merkezi bir konu? Kurumsal yapılarda ERP sistemi yalnızca bir uygulama değildir; muhasebe hareketinden tedarik zinciri verisine kadar işin referans kaydıdır. Bu yüzden ERP'ye bağlanan her sistem, teknik olarak bir API tüketicisi olsa da iş açısından kritik bir bağımlılıktır. Sorun şu ki birçok kurumda bu bağımlılıklar belgelenmiş arayüzler üzerinden değil, örtük beklentiler üzerinden yaşar: Bir alanın adı değişmez varsayılır. Gecikme toleransı hiç yazılmaz. Batch penceresi yıllardır aynı kaldığı için doğal kural kabul edilir. Hata durumunda kimin devreye gireceği belirsizdir. Entegrasyon sözleşmesi yönetişimi, bu örtük davranışları açık operasyon kurallarına dönüştürür. Sözleşme yalnızca şema değildir Birçok ekip sözleşme denince JSON schema, WSDL veya tablo kolon listesini düşünür. Oysa ERP çevresinde gerçek sözleşme daha geniştir. Benim pratikte kullandığım çerçeve beş parçadan oluşur: 1. Veri şekli ve zorunlu alanlar 2. Zamanlama beklentisi 3. Hata ve tekrar deneme davranışı 4. Sahiplik ve değişiklik onayı 5. Geriye dönük uyumluluk sınırı Bu parçalar yazılmadığında entegrasyon, teknik olarak çalışsa bile kurumsal ölçekte yönetilemez. Modernizasyon döneminde hangi risk büyür? ERP modernizasyonu sırasında en sık görülen hata, eski entegrasyonların \"nasıl olsa sonra toparlarız\" düşüncesiyle geçici adaptörlere bağlanmasıdır. Bu geçici katman çoğu zaman kalıcı olur. Sonuçta kurum, modern ERP'nin etrafında eski kurallarla çalışan yeni bir karmaşa üretir. Bunu önlemek için şu ilke işe yarar: ERP çekirdeğine bağlanan her yeni ya da taşınan entegrasyon, önce sözleşme kaydına girmeli; sonra kod seviyesine inmelidir. Sözleşme envanteri olmayan modernizasyon, yalnızca teknolojik borcu başka formda yeniden üretir. <Callout type=\"tip\" title=\"Sözleşme kaydı olmayan entegrasyon görünmez maliyettir\" Kurumlar genelde kırılan entegrasyonu fark eder; ama sessizce yavaşlayan, veri kaydıran veya yanlış zamanda çalışan entegrasyonun maliyetini aylar sonra görür. </Callout Yönetişim modeli nasıl kurulmalı? Burada aşırı merkeziyet de, tam serbestlik de işe yaramaz. Benim önerdiğim model şu ayrımı yapar: Domain ekipleri sözleşmenin iş anlamından sorumludur. Platform veya entegrasyon ekibi taşıma standartlarını ve gözlemlenebilirliği sağlar. ERP ekibi çekirdek sistem üzerindeki kırılma noktalarını ve uyumluluk takvimini yönetir. Bu rol ayrımı sayesinde herkes aynı noktaya bakar ama aynı işi yapmaz. Özellikle batch entegrasyonlar, dosya tabanlı aktarımlar ve olay akışları aynı yönetişim şemsiyesi altında farklı kurallarla yönetilebilir. Hangi metrikler gerçekten işe yarar? Entegrasyon sözleşmesi yönetişimi \"doküman sayısı\" ile ölçülmez. Daha anlamlı sinyaller şunlardır: Sözleşme kaydı olan entegrasyon oranı Sahibi tanımlı entegrasyon oranı Geriye dönük uyumsuz değişiklik sayısı ERP kaynaklı incident'larda sözleşme ihlali payı Değişiklik duyurusundan canlıya geçişe kadar geçen süre Bu metrikler kurumun entegrasyon katmanını yönettiğini mi, yoksa yalnızca yaşattığını mı net gösterir. Teknik karar ile kurumsal iletişim burada birleşir ERP çevresindeki entegrasyonlar teknik görünür; fakat kırıldığında etki alanı teknik sınırı aşar. Bu yüzden entegrasyon sözleşmesi yönetişimi aynı zamanda kurumsal iletişim modelidir. Kim, hangi değişikliği, ne kadar önce, hangi kanaldan duyuracak sorusu mimari kararın parçası olmalıdır. Özellikle büyük kurumlarda, duyurulmamış küçük bir alan değişikliği bazen veri ambarı, finans raporu ve saha operasyonunu aynı anda bozar. Sorun çoğu zaman sistemden çok koordinasyondur. Sonuç ERP modernizasyonunda entegrasyon sözleşmesi yönetişimi, eski sistemlerle yeni platformların arasına bürokrasi koymak değildir. Asıl amaç, kurumsal bağımlılıkları görünür kılmak ve değişimi kontrollü şekilde hızlandırmaktır. Çekirdek uygulamayı yenilemek önemlidir; fakat çevresindeki entegrasyonların hangi kuralla yaşayacağını tanımlamadan yapılan modernizasyon, sadece daha modern görünen yeni bir kırılganlık üretir.",
      "date_published": "2026-04-05T00:00:00.000Z",
      "date_modified": "2026-04-05T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "integration",
        "architecture",
        "governance",
        "enterprise"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-ortak-kimlik-siniri-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-bulutta-ortak-kimlik-siniri-tasarimi",
      "title": "Kurumsal Bulutta Ortak Kimlik Sınırı Tasarımı",
      "summary": "Çok hesaplı cloud yapılarda kimlik, yetki ve operasyon sınırlarını sadeleştiren ortak tasarım yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal bulutta ortak kimlik siniri tasarimi diagram.svg'; Kurumsal bulut mimarilerinde en pahalı problemler çoğu zaman compute, network veya storage seçiminden değil; kimliğin nerede başladığı ve hangi sınırda bittiği konusundaki belirsizlikten çıkar. Birden fazla hesap, ortam ve ekip aynı cloud omurgasını paylaşıyorsa, kimlik modeli net değilse her yeni servis yalnızca teknik değil yönetsel risk de üretir. Ortak kimlik sınırı tasarımı, bu karmaşayı tek bir IAM dokümanıyla değil, açık sorumluluk katmanlarıyla çözmeyi hedefler. <figure <Image src={diagram} alt=\"Çok hesaplı bulutta ortak kimlik sınırı ve güven ilişkilerini gösteren teknik şema\" / <figcaption Kimlik sınırı iyi tanımlandığında, ekip özgürlüğü artarken yetki dağınıklığı azalır.</figcaption </figure Ortak kimlik sınırı neyi çözer? Kurumsal yapılarda sık görülen kötü desen şudur: merkezi platform hesabı her yere erişir, ürün ekipleri de gerektiğinde bu gücü dolaylı olarak kullanır. İlk bakışta pratik görünür; fakat zamanla şu sorunlar oluşur: Kim hangi rolü neden kullanıyor belirsizleşir. Incident sırasında erişim izleri anlamını kaybeder. Ortamlar arası ayrım kağıt üzerinde kalır. Üçüncü taraf araçlar fazladan kalıcı yetki biriktirir. Ortak kimlik sınırı tasarımı, platform ve ürün ekipleri arasındaki güven ilişkisini yeniden yazar. Amaç her yetkiyi merkezileştirmek değil, kimliğin yaşam döngüsünü ve etkisini yönetilebilir hâle getirmektir. İyi tasarımın ilkesi: kimlik, topoloji kadar önemlidir Çok hesaplı cloud yapılarda herkes VPC ayrımı, subnet tasarımı veya transit gateway konuşur. Oysa bunların üzerinde çalışan asıl kontrol katmanı kimliktir. Hangi servis hangi hesaba deploy olacak, hangi pipeline hangi rolü üstlenecek, kırılma anında kim geçici erişim alacak sorularının cevabı mimarinin parçasıdır. Benim önerdiğim yaklaşım üç sınır üstüne kurulur: 1. İnsan kimliği ile iş yükü kimliği ayrılır. 2. Günlük operasyon rolü ile acil durum rolü ayrılır. 3. Ortamlar arası güven ilişkileri minimum gerekli yetkiyle yazılır. Bu çerçeve olmadan \"merkezi IAM standardı\" yalnızca büyüyen bir izin listesine dönüşür. Platform hesabı ne yapmalı, ne yapmamalı? Platform ekipleri doğal olarak bootstrap, gözlemlenebilirlik, ortak ağ servisleri ve güvenlik guardrail'leri için geniş erişim ister. Bu ihtiyaç gerçektir. Fakat platform hesabının her ürüne sürekli yönetici yetkisi taşıması doğru model değildir. Daha sağlıklı yaklaşım şudur: Platform hesabı ortak servisleri yönetir. Ürün hesapları kendi iş yükü yaşam döngüsünden sorumludur. Merkezi pipeline yalnızca tanımlı deployment rollerini üstlenir. Kırılma anında kullanılan yükseltilmiş erişim ayrı kayıt ve onay akışıyla açılır. Bu ayrım, güveni azaltmaz; aksine platform ekibinin neden kritik olduğunun sınırlarını görünür kılar. <Callout type=\"tip\" title=\"Kalıcı yönetici rolü yerine kısa ömürlü yükseltme\" Kurumsal yapılarda operasyon hızını korumak için kalıcı geniş yetki vermek cazip görünür. Fakat uzun vadede maliyeti, birkaç dakika kazanımdan çok daha yüksektir. </Callout İş yükü kimliği neden ayrı ele alınmalı? Güncel cloud mimarisinde asıl hareketi insanlar değil otomasyon yapar. CI/CD pipeline'ları, scheduled task'ler, entegrasyon servisleri ve agent'lar sürekli kimlik kullanır. Bu yüzden iş yükü kimliği tasarımı ikinci planda bırakılamaz. Şu kurallar pratikte güçlü sonuç verir: Her pipeline kendi ortam rolünü üstlenir. Gözlemlenebilirlik veya backup agent'ları ortak ama dar kapsamlı roller kullanır. Cross account erişim sadece açık güven ilişkisiyle verilir. Secret erişimi uygulama kimliğiyle sınırlanır; insan erişimi ayrı akıştan geçer. Bu model, \"aynı anahtar her yerde çalışıyor\" türü görünmez riskleri azaltır. Ortak kimlik sınırı ile denetim nasıl kolaylaşır? Denetim ekiplerinin ihtiyacı binlerce izin satırını okumak değildir. Asıl ihtiyaç, kararın niyetini anlayabilmektir. Eğer rol isimleri, güven ilişkileri ve erişim akışları mimari sınırlarla uyumluysa denetim tartışması teknik ayrıntıdan çıkar ve yönetişim seviyesine yükselir. Örneğin şu soruların cevabı kolaylaşır: Bu rol hangi ekip adına hareket ediyor? İnsan mı kullanıyor, otomasyon mu? Normal operasyon mu, acil durum mu? Bu erişim hangi hesaplar arasında neden kurulmuş? Kimlik modeli mimariye konuştuğunda güvenlik ekibi ile platform ekibi arasındaki sürtünme belirgin biçimde azalır. En sık yapılan hata: organizasyon şemasını IAM'e kopyalamak Birçok kurum kimlik sınırını teknik akışa göre değil, org chart'a göre çizer. Sonuçta rol adları yönetim yapısına benzer, fakat gerçek servis ilişkilerini anlatmaz. Oysa hesap, ortam ve servis yaşam döngüsü değiştikçe org chart da değişir. Mimari sınırları organizasyonel isimlerle kurmak kısa sürede çürür. Daha iyi yaklaşım, rol ve güven ilişkilerini şu eksenle yazmaktır: ortam, iş yükü tipi, etki alanı ve operasyon seviyesi. Böylece isimlendirme şirket içi değişimlerden daha az etkilenir. Sonuç Kurumsal bulutta ortak kimlik sınırı tasarımı, yalnızca IAM temizlik işi değildir. Bu tasarım, platform ekiplerinin hangi alanlarda merkezi kaldığını, ürün ekiplerinin hangi alanlarda gerçek sahiplik aldığını ve güvenlik politikasının operasyonu nerede yavaşlatmadan koruduğunu belirler. Ağ ve hesap topolojisi kadar kimlik topolojisi de bilinçli tasarlandığında, cloud mimarisi sonunda okunabilir hâle gelir.",
      "date_published": "2026-04-05T00:00:00.000Z",
      "date_modified": "2026-04-05T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "cloud",
        "identity",
        "security",
        "architecture",
        "platform-engineering"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/nginx-ile-mtls-tabanli-yonetim-api-korumasi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/nginx-ile-mtls-tabanli-yonetim-api-korumasi",
      "title": "Nginx ile mTLS Tabanlı Yönetim API Koruması",
      "summary": "Yönetim API'lerini istemci sertifikasıyla korumak için Nginx üzerinde sade ve denetlenebilir mTLS kurgusu.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './nginx ile mtls tabanli yonetim api korumasi diagram.svg'; Yönetim API'leri çoğu kurumda ürün trafiği kadar görünür değildir; ama etkileri çok daha büyüktür. Bir config reload uç noktası, operasyon paneli veya iç yönetim servisi yanlış korunursa, küçük bir açıklık tüm platformu etkileyebilir. Bu yüzden yalnızca IP allowlist veya basic auth ile yetinmek zayıf kalır. İstemci sertifikasıyla çalışan mTLS modeli, özellikle operasyonel arayüzlerde güçlü ve net bir güvenlik sınırı oluşturur. <figure <Image src={diagram} alt=\"Nginx önünde istemci sertifikası doğrulamasıyla korunan yönetim API akışını gösteren teknik şema\" / <figcaption mTLS, \"kim geldi?\" sorusunu ağ seviyesinden uygulama sınırına taşır.</figcaption </figure Bu rehberde Nginx'i ters proxy olarak kullanıp yalnızca geçerli istemci sertifikası taşıyan istekleri yönetim API'sine geçireceğiz. Ne kuruyoruz? Senaryo basit: İç ağda çalışan bir yönetim API var. API doğrudan internete açık olmayacak. Önünde Nginx olacak. İstek yapan istemciler kurum içi CA'den üretilmiş sertifika taşıyacak. Bu model özellikle bastion arkasındaki iç araçlar, yönetim dashboard'ları ve platform servislerinin admin uç noktaları için uygundur. Nginx konfigürasyonu Temel örnek şöyle olabilir: Buradaki kritik satır ssl verify client on; ifadesidir. Nginx, istemci sertifikasını CA zincirine göre doğrulamadan trafiği iç servise geçirmez. Sertifika yaşam döngüsünü düşünmeden mTLS kurmayın mTLS teknik olarak kolay görünür; ama sürdürülebilir olması için sertifika yaşam döngüsü tasarlanmalıdır. Şu soruların cevabı net olmalı: İstemci sertifikası kim için üretiliyor? Kaç gün geçerli olacak? Kaybolur veya sızarsa nasıl iptal edilecek? Ekipten ayrılan kullanıcıların sertifikaları nasıl kapanacak? Özellikle uzun ömürlü istemci sertifikaları, sistem ilk kurulduğunda güvenli görünse de zamanla görünmez bir erişim mirası bırakır. <Callout type=\"tip\" title=\"mTLS kimliktir, ağ kuralı değil\" İstemci sertifikasını yalnızca ulaşım güvenliği gibi düşünmek eksik olur. mTLS aynı zamanda erişim kimliğidir; üretim ve iptal akışı buna göre yönetilmelidir. </Callout Uygulama katmanında ne kontrol edilmeli? Nginx sertifikayı doğrulasa bile uygulama katmanının gelen bilgiyi körlemesine kabul etmemesi gerekir. En azından şu kontroller değer üretir: X Client Verify gerçekten SUCCESS mi? Sertifika konusu beklenen ekip veya servis adını içeriyor mu? Uç nokta bazlı ek yetki kontrolü gerekiyor mu? Yani mTLS, kimliği kapıda doğrular; fakat içeride yapılacak işlemin yetkisini yine uygulama karar vermelidir. Operasyonel sertleştirme önerileri Bu kurulumun sağlam kalması için şu ek adımlar anlamlıdır: Yönetim API'sini yalnızca loopback veya iç arayüzde dinletmek Nginx erişim loglarında istemci DN bilgisini kaydetmek İptal edilen sertifikalar için CRL veya kısa ömürlü sertifika modeli kullanmak Başarısız doğrulama denemelerini alarm sinyaline çevirmek Böylece mTLS yalnızca erişim kapısı değil, aynı zamanda denetlenebilir bir operasyon kontrolüne dönüşür. Sonuç Nginx ile mTLS tabanlı yönetim API koruması, iç servisleri yalnızca \"güvenilir ağ\" varsayımına bırakmaktan çok daha sağlam bir model sunar. Özellikle platform ve operasyon araçlarında, istemci sertifikasıyla çalışan sade bir doğrulama katmanı hem güvenliği güçlendirir hem de erişim niyetini daha okunabilir kılar. Kritik olan kısım, konfigürasyonu yazmak değil; sertifika yaşam döngüsünü ve uygulama içi yetki kararlarını aynı disiplinle yönetmektir.",
      "date_published": "2026-04-05T00:00:00.000Z",
      "date_modified": "2026-04-05T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "security",
        "nginx",
        "mtls",
        "network",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/vector-ile-merkezi-log-toplama-pipelinei",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/vector-ile-merkezi-log-toplama-pipelinei",
      "title": "Vector ile Merkezî Log Toplama Pipeline'ı",
      "summary": "Uygulama, syslog ve altyapı loglarını tek akışta toplayıp yönlendirmek için Vector tabanlı pratik kurulum yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './vector ile merkezi log toplama pipelinei diagram.svg'; Kurumsal ortamlarda log toplama problemi çoğu zaman \"hangi platformu kullanacağız?\" sorusuyla başlar. Oysa daha kritik soru şudur: farklı formatta, farklı frekansta ve farklı risk seviyesinde üretilen logları aynı teslimat omurgasında nasıl taşıyacağız? Vector bu iş için güçlü bir araç çünkü sadece bir ajan değil; dönüştürme, zenginleştirme ve yönlendirme katmanını da sade biçimde kurmaya izin veriyor. <figure <Image src={diagram} alt=\"Vector ile uygulama, syslog ve altyapı loglarının tek pipeline içinde birleşmesini gösteren teknik şema\" / <figcaption İyi bir log pipeline'ı yalnızca veri taşımakla kalmaz; kaynakları ortak etiket ve akış kuralları altında hizalar.</figcaption </figure Bu rehberde, birden fazla log kaynağını Vector ile toplayan ve iki farklı hedefe yönlendiren temel bir kurulum iskeleti kuracağız. Hangi senaryo için uygun? Şu durumlarda bu model oldukça kullanışlıdır: Linux sunuculardan syslog akıyor. Uygulamalar JSON veya satır tabanlı log üretiyor. Bazı loglar uzun süreli depoya, bazıları hızlı arama sistemine gitmeli. Ortak etiket standardı ve filtre mantığı merkezi yönetilmek isteniyor. Bu örnekte üç kaynak alacağız: 1. /var/log/messages 2. Bir uygulama log dosyası 3. Journald Temel Vector yapılandırması Önce kaynakları tanımlayalım: Burada özellikle uygulama loglarını wildcard ile toplamak, çok servisli yapılarda konfigürasyon tekrarını azaltır. Ortak zenginleştirme katmanı Kaynakları toplamak yetmez. Logun hangi ortamdan, hangi servisten ve hangi düğümden geldiğini hızlıca anlamak gerekir. Bunu remap ile yapabiliriz: Kurumsal yapılarda en büyük sorunlardan biri, aynı olayın farklı ekiplerce farklı etiketlerle aranmasıdır. Bu katman, daha ilk toplama noktasında ortak dil kurar. Gürültüyü erkenden azaltmak Tüm logu aynı hedefe aynen göndermek pahalıdır. Özellikle health check, rutin cron çıktısı veya tekrar eden düşük değerli kayıtlar index maliyetini artırır. Basit bir filtre ekleyelim: Bu filtreyi agresif tutmamak gerekir. İlk aşamada silmek yerine ayrı hedefe yönlendirmek daha güvenli olabilir. <Callout type=\"tip\" title=\"Ham akışı tamamen kaybetmeyin\" Kurumsal incident'larda daha önce değersiz görülen kayıtların kritik olduğu çok görülür. Mümkünse gürültüyü ucuz depoya, değerli kaydı hızlı arama katmanına ayırın. </Callout İki hedefe birden yönlendirme Şimdi aynı akışı hem Elasticsearch benzeri arama katmanına hem de uzun süreli objeye dayalı depoya gönderelim: Burada dikkat edilmesi gereken nokta şu: arama katmanına filtrelenmiş akış giderken, arşiv katmanına normalize edilmiş ama filtrelenmemiş veri gidebilir. Bu ayrım operasyon ve maliyet dengesini güçlendirir. Operasyonel olarak nelere dikkat edilmeli? Vector kurulduktan sonra asıl değer, çalışma davranışını izlemekten gelir. Ben şu kontrolleri öneririm: Buffer doluluk oranı Hedefe yazma hataları Kaynak bazlı gecikme Düşürülen event sayısı Konfigürasyon değişim sıklığı Özellikle merkezi log omurgasında sessiz veri kaybı, açık hatadan daha tehlikelidir. Bu yüzden pipeline'ın kendisini de gözlemlemek gerekir. Sonuç Vector ile merkezî log toplama pipeline'ı kurmak, sadece ajan kurmak değildir. Asıl iş, log kaynaklarını ortak bir veri ve operasyon sözleşmesi altında toplamak, gürültüyü erkenden azaltmak ve doğru veriyi doğru hedefe yollamaktır. Gözlemlenebilirlik olgunluğu çoğu zaman kullandığınız arama aracından değil, veriyi oraya hangi disiplinle taşıdığınızdan anlaşılır.",
      "date_published": "2026-04-05T00:00:00.000Z",
      "date_modified": "2026-04-05T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "logging",
        "vector",
        "devops",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/platform-donusumunde-teknik-liderin-ceviri-rolu",
      "url": "https://mustafaerbay.com.tr/blog/career/platform-donusumunde-teknik-liderin-ceviri-rolu",
      "title": "Platform Dönüşümünde Teknik Liderin Çeviri Rolü",
      "summary": "Platform dönüşüm projelerinde teknik liderin mühendislik, operasyon ve iş birimleri arasında ortak dil üretme sorumluluğu.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './platform donusumunde teknik liderin ceviri rolu diagram.svg'; Platform dönüşümü konuşulurken çoğu kurum araç listesini, internal developer platform'u veya self service katalogları öne çıkarıyor. Fakat dönüşümün asıl kırıldığı yer teknoloji seçimi değil, aynı değişimi farklı ekiplerin farklı anlamasıdır. Operasyon ekibi risk kontrolü görür, ürün ekibi hız baskısı hisseder, yönetim ise maliyet ve görünürlük ister. Teknik liderin değeri tam burada ortaya çıkar: aynı dönüşümü bu grupların anlayacağı ortak bir dile çevirmek. <figure <Image src={diagram} alt=\"Platform dönüşümünde ekipler arası çeviri rolünü gösteren teknik şema\" / <figcaption Teknik liderlik bazen en doğru çözümü söylemekten çok, aynı hedefi farklı ekiplerin kabul edeceği biçimde tarif etmektir.</figcaption </figure Neden çeviri rolü diyorum? Çünkü platform dönüşümünde en sık görülen problem teknik yanlışlık değil, semantik kopukluktur. \"Golden path\", \"guardrail\", \"self service\" veya \"platform ownership\" gibi ifadeler farklı ekiplerde farklı çağrışımlar üretir. Teknik lider bu kavramları soyut bırakırsa dönüşüm dirençle karşılaşır. İyi teknik lider şunu yapar: Mühendislik kararını iş etkisine bağlar. Operasyon kaygısını hız düşmanlığı gibi göstermeden açıklar. Ürün ekibine yeni sınırların nedenini anlatır. Yönetim tarafına ölçülebilir kazanımı sade dille sunar. Dönüşüm neden genelde toplantılarda yavaşlar? Çünkü aynı masa etrafındaki herkes aynı kelimeleri kullanıyor gibi görünse de aynı problemi konuşmaz. Örneğin bir platform ekibi \"standart pipeline\" dediğinde ürün ekibi bunu ek özgürlük kaybı olarak okuyabilir. Operasyon ekibi ise kontrol mekanizması olarak görebilir. Teknik lider burada yalnızca moderatör değildir; kavram çakışmalarını açığa çıkarmak zorundadır. Hangi konular en çok çeviri gerektirir? Benim sık gördüğüm başlıklar şunlar: 1. Ortak CI/CD akışları 2. Erişim ve kimlik politikaları 3. Observability zorunlulukları 4. Platform ekiplerinin hizmet seviyesi beklentileri 5. İstisna yönetimi ve mimari yönetişim Bu başlıklarda dil netleşmediğinde teknik olarak doğru karar bile gereksiz direnç üretir. <Callout type=\"tip\" title=\"Liderlik çoğu zaman bağlam kurmaktır\" Teknik doğruluk, bağlam kurulmadığında ikna edici olmaz. Özellikle kurumsal yapılarda insanlar çözüme değil, çözümün kendi işine etkisine reaksiyon verir. </Callout Peki bu çeviri pratikte nasıl yapılır? Benim etkili bulduğum yöntem üç katmanlıdır: Önce kavramı sadeleştiririm: örneğin \"guardrail\", hata yapmayı zorlaştıran güvenli varsayılanlar demektir. Sonra ekip bazlı etkisini ayırırım: ürün ekibi için hız, operasyon için kontrol, yönetim için ölçülebilirlik. Son olarak sınırları netlerim: bu model hangi iş yükleri için geçerli, hangi durumda istisna var? Bu yöntem, teknik belirsizliği yönetişim tartışmasına dönüşmeden yönetmeyi sağlar. Mentorluk boyutu neden önemli? Platform dönüşümü yalnızca kıdemli mühendislerin değil, daha genç ekip üyelerinin de günlük çalışma modelini değiştirir. Bu noktada teknik liderin mentorluk rolü devreye girer: Neden yeni akışa geçildiğini anlatmak İstisna istemenin meşru sınırlarını öğretmek Runbook ve ownership kültürünü görünür kılmak Sürekli şikâyet edilen değil, sürekli açıklanan liderlik pratiği göstermek Bu davranışlar olmadan dönüşüm \"yukarıdan gelen süreç\" gibi algılanır. Başarılı olduğunuzu nasıl anlarsınız? İyi sinyaller genelde şunlardır: Ekipler yeni platform akışını başkalarına savunmaya başlar. İstisna talepleri daha net ve gerekçeli gelir. Incident sırasında ortak kelime dağarcığı oluşur. Yönetim toplantılarında platform yatırımı araç listesi yerine çıktı metrikleriyle anlatılır. Sonuç Platform dönüşümünde teknik liderin çeviri rolü, çoğu zaman görünmez ama belirleyici bir yetkinliktir. Çünkü kurumsal mimarilerde dönüşüm yalnızca sistemleri değil, insanların birlikte çalışma şeklini de değiştirir. Ortak dil kurulmadan ortak platform kurulmuş sayılmaz. Kıdemli mühendislik pratiğinde kalıcı etki yaratmak isteyenler için en güçlü kaldıraçlardan biri tam olarak budur.",
      "date_published": "2026-04-04T00:00:00.000Z",
      "date_modified": "2026-04-04T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "platform-engineering",
        "mentorluk",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-aktif-pasif-felaket-kurtarma",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-aktif-pasif-felaket-kurtarma",
      "title": "ERP Altyapılarında Aktif-Pasif Felaket Kurtarma",
      "summary": "ERP sistemlerinde veri tutarlılığı, ağ yönlendirmesi ve operasyon rolleriyle gerçekçi bir aktif-pasif toparlanma modeli kurmanın esasları.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda aktif pasif felaket kurtarma diagram.svg'; ERP ortamlarında felaket kurtarma konusu çoğu zaman yalnızca veritabanı replikasyonu olarak ele alınıyor. Oysa gerçek hayatta toparlanma başarısı; veri tutarlılığı, entegrasyon akışları, batch takvimi, kimlik servisleri ve ağ yönlendirmesinin birlikte düşünülmesine bağlıdır. Uygulama ayağa kalksa bile entegrasyon kuyruğu bozulmuş, kullanıcı oturumu kopmuş veya dış sistem yönlendirmesi güncellenmemişse kurumsal tarafta kesinti bitmiş sayılmaz. <figure <Image src={diagram} alt=\"ERP üretim ve felaket kurtarma bölgeleri arasındaki veri akışını gösteren teknik şema\" / <figcaption ERP felaket kurtarma planı, yalnızca ikinci veri merkezi değil; veri, entegrasyon ve operasyon akışlarının birlikte toparlanmasıdır.</figcaption </figure Neden aktif pasif model hâlâ yaygın? Kurumsal ERP yüklerinde aktif aktif model her zaman ekonomik veya operasyonel olarak mantıklı değildir. Lisans maliyetleri, veri tutarlılığı gereksinimi ve kritik süreçlerin sıralı işlenmesi nedeniyle aktif pasif yaklaşım çoğu durumda daha kontrollü bir tercih olur. Ancak bu tercih, pasif bölgenin gerçekten hazır tutulduğu anlamına gelmelidir. Pasif taraf yalnızca \"sunucular var\" seviyesinde bırakılıyorsa felaket kurtarma değil, iyimserlik yönetiliyordur. Planın merkezine hangi bileşenler alınmalı? ERP sistemlerinde en kritik katmanlar genellikle şunlardır: Uygulama sunucuları ve oturum yönetimi Veritabanı ve transaction tutarlılığı Mesaj kuyruğu veya entegrasyon aracısı Dış sistem bağlantıları Batch ve zamanlanmış iş akışları Bu bileşenlerden yalnızca biri atlanırsa failover teoride mümkün görünür, pratikte ise iş birimleri üretime dönemeyebilir. Veri tutarlılığı için neye dikkat edilmeli? Aktif pasif yapıda ilk soru \"kaç dakikada ayağa kalkarız?\" değil, \"hangi veri noktasına döneriz?\" olmalıdır. Çünkü bazı ERP süreçlerinde birkaç dakikalık veri kaybı bile finansal veya operasyonel uzlaşma gerektirir. Bu yüzden aşağıdaki başlıklar net tanımlanmalıdır: Hedeflenen RPO ve RTO değerleri Hangi tablolar veya modüller eşzamanlıya yakın korunmalı Entegrasyon mesajlarının yeniden oynatılma stratejisi Failback sırasında veri çatışmasının nasıl engelleneceği <Callout type=\"tip\" title=\"Batch etkisini küçümsemeyin\" Geceleri çalışan mutabakat, fiyat güncelleme veya stok konsolidasyon işleri çoğu zaman felaket kurtarma planlarında unutulur. Oysa failover sonrası ilk iş yükü genellikle bu jobs zinciridir. </Callout Ağ ve yayın katmanı neden ayrı başlık olmalı? Birçok kurum veri replikasyonunu tasarlar ama kullanıcıyı ve entegrasyon partnerini yeni bölgeye nasıl yönlendireceğini geç düşünür. Sağlam tasarımda şu katmanlar hazır olmalıdır: DNS failover veya kontrollü yönlendirme politikası İç ağ ACL ve firewall kurallarının iki bölge için eşlenik olması VPN, MPLS veya özel hat terminasyonlarının pasif bölgede doğrulanması Gerekirse üçüncü tarafların erişim allowlist bilgilerinin önceden tanımlanması Felaket anında ağ ekibi ayrı, uygulama ekibi ayrı keşif yapıyorsa kaybedilen süre hızla büyür. Operasyon rolleri nasıl tanımlanmalı? Aktif pasif senaryolarda teknik doğruluk kadar komuta netliği de önemlidir. Benim önerdiğim yapı şu şekilde: 1. Incident komutanı : Karar akışını ve iletişimi yönetir. 2. Altyapı sahibi : Bölge aktivasyonu, ağ ve compute adımlarını yürütür. 3. Uygulama sahibi : ERP servis sağlığını ve batch etkisini doğrular. 4. Entegrasyon sahibi : Dış sistem akışlarını test eder. Bu roller önceden net değilse teknik ekipler aynı işi iki kez kontrol ederken bazı kritik adımlar sahipsiz kalır. Tatbikat yapmadan plan geçerli sayılır mı? Hayır. Özellikle ERP gibi kesinti maliyeti yüksek ortamlarda gerçekçi tatbikat olmadan belgeye güvenmek doğru değildir. İyi tatbikatlarda: Belirli modüller için sentetik iş senaryosu koşturulur. Kullanıcı girişi, kritik işlem akışı ve raporlama birlikte test edilir. Dış sistem entegrasyonlarından en az bir uçtan uca örnek akış doğrulanır. Tatbikat sonrası iyileştirme listesi tarih ve sahiplik ile kapatılır. Sonuç ERP altyapılarında aktif pasif felaket kurtarma, ikinci lokasyon kiralamaktan ibaret değildir. Asıl değer; veri, yayın ve operasyon katmanlarının aynı toparlanma hikâyesine bağlanmasında oluşur. Kurumsal teknoloji mimarisinde güvenilirlik arayan ekipler için doğru soru \"DR ortamımız var mı?\" değil, \"gerçek bir kesintide iş süreçlerini düzenli biçimde geri getirebiliyor muyuz?\" olmalıdır.",
      "date_published": "2026-04-04T00:00:00.000Z",
      "date_modified": "2026-04-04T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "disaster-recovery",
        "infrastructure",
        "network",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-dns-tabanli-servis-yonlendirme",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-dns-tabanli-servis-yonlendirme",
      "title": "Kurumsal Ağlarda DNS Tabanlı Servis Yönlendirme",
      "summary": "DNS katmanını yalnızca isim çözümleme değil, servis yönlendirme ve dayanıklılık kontrol noktası olarak tasarlamanın çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal aglarda dns tabanli servis yonlendirme diagram.svg'; Birçok kurum DNS'i hâlâ yalnızca isim çözümleme servisi olarak konumlandırıyor. Oysa gerçek üretim ortamlarında DNS katmanı, trafik akışının nerede sonlanacağını, felaket senaryosunda hangi bölgenin devreye gireceğini ve istemcilerin ne kadar hızlı toparlanacağını doğrudan etkiler. Load balancer, reverse proxy ve service mesh konuşulurken DNS tasarımı geri planda kalıyorsa, mimarinin ilk karar katmanı çoğu zaman ihmal ediliyor demektir. <figure <Image src={diagram} alt=\"DNS tabanlı servis yönlendirme ve sağlık kontrol katmanlarını gösteren teknik şema\" / <figcaption DNS; sağlık sinyali, bölgesel öncelik ve yayın politikası birleştiğinde yalnızca kayıt sistemi olmaktan çıkar.</figcaption </figure DNS neden mimari bir karar katmanıdır? Kurumsal ağlarda kullanıcı veya uygulama çoğu zaman sisteme ilk olarak bir alan adı üzerinden ulaşır. Bu nedenle aşağıdaki soruların ilk cevabı DNS katmanında verilir: Trafik hangi veri merkezine veya bölgeye gitmeli? Hangi servis uçları öncelikli olmalı? Hangi kayıt ne kadar süre önbellekte kalmalı? Bir kesinti olduğunda istemciler ne hızda yeni hedefe dönebilmeli? Bu soruların her biri doğrudan erişilebilirlik, performans ve operasyonel kontrol başlığına bağlanır. Sık görülen yanlış tasarım Kayıtların yalnızca elle tanımlandığı ve TTL değerlerinin rastgele verildiği yapılarda DNS katmanı zamanla görünmez teknik borca dönüşür. Özellikle ERP, entegrasyon servisi ve kurumsal API yayınlarında şu hatalar pahalıya mal olur: Aynı servisin farklı ortamlarda farklı isim şemasıyla açılması Failover mantığının yalnızca load balancer seviyesinde düşünülmesi Sağlık kontrolü ile DNS kaydı yaşam döngüsünün birbirinden kopuk kalması Çok uzun TTL yüzünden felaket anında eski uçlara dönülmesi Bu yapı çalışırken sessizdir; ama incident anında toparlanma süresini gereksiz yere uzatır. Sağlam bir yönlendirme modeli nasıl kurulur? Kurumsal ölçekte pratik bir model genellikle dört bileşenden oluşur: 1. Tutarlı adlandırma : Servis, ortam, bölge ve erişim tipi aynı kalıpta tanımlanır. 2. Sağlık sinyali : Uçların gerçekten yanıt verdiği merkezi olarak izlenir. 3. Politika katmanı : Öncelik, ağırlık, geo veya failover kuralı açık tanımlanır. 4. Düşük sürtünmeli değişiklik akışı : DNS değişiklikleri ticket bekleyen manuel operasyon olmaktan çıkar. Bu model olmadan DNS her ekibin kendi yöntemini kullandığı bir kayıt defterine döner. <Callout type=\"tip\" title=\"TTL kararı teknik bir ayrıntı değildir\" TTL değeri; cache verimliliği, failover hızı ve istemci davranışı arasında net bir denge kurar. Üretim servislerinde bu değeri tesadüfen değil, toparlanma hedeflerine göre belirleyin. </Callout Hangi senaryolarda DNS daha kritik hâle gelir? Özellikle aşağıdaki ortamlarda DNS tasarımı ilk sınıf mimari bileşen olarak ele alınmalıdır: Birden fazla veri merkezi veya cloud bölgesi bulunan yapılar ERP ve kurumsal entegrasyon servislerinin farklı erişim katmanlarından geçtiği topolojiler İç ve dış istemcinin farklı rota politikaları kullandığı ağ segmentleri Planlı bakım sırasında trafiğin kontrollü taşınması gereken servisler Bu durumlarda DNS, yalnızca servis bulunurluğu değil, değişiklik yönetimi aracı da olur. Health check ile DNS ilişkisi nasıl kurulmalı? Burada temel hata, health check bilgisini ayrı bir sistemde izleyip DNS katmanına bağlamamaktır. Eğer kayıtlar sağlık durumundan habersizse yönlendirme kararları statik kalır. İyi tasarımda: Sağlık sinyali uygulama seviyesinde anlamlı olmalıdır. Yalnızca TCP açık olması yeterli kabul edilmemelidir. Bölgesel öncelik değişimi operasyon ekibi tarafından gözlenebilir olmalıdır. Yapılan kayıt değişikliği audit izi bırakmalıdır. Böylece DNS kararı veriyle beslenir ve operasyonel olarak izlenebilir olur. İç servisler için split horizon gerekli mi? Kurumsal ağlarda çoğu zaman aynı servisin iç ve dış istemciler için farklı hedeflere çözülmesi gerekir. Split horizon DNS burada faydalıdır; ancak gelişi güzel uygulanırsa debug sürecini zorlaştırır. Bu nedenle: İç ve dış kayıtların sahipliği net tanımlanmalı Aynı servis adı için farklı çözümlerin dokümantasyonu tutulmalı Gözlemlenebilirlik tarafında hangi istemcinin hangi çözümü aldığı görülebilmeli Aksi halde \"bende açılıyor, sende açılmıyor\" tipi problemler yapısal hâle gelir. Sonuç Kurumsal ağlarda DNS tabanlı servis yönlendirme, görünmez ama kritik bir kontrol düzlemidir. Doğru tasarlandığında yalnızca isim çözmez; bakım pencerelerini sadeleştirir, felaket senaryolarında toparlanmayı hızlandırır ve servis yayın politikasını merkezîleştirir. Ağ mimarisinin ilk kararını daha bilinçli vermek isteyen ekipler için başlangıç noktası tam olarak burasıdır.",
      "date_published": "2026-04-04T00:00:00.000Z",
      "date_modified": "2026-04-04T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "dns",
        "architecture",
        "high-availability",
        "infrastructure"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/grafana-alloy-ile-ajan-konsolidasyonu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/grafana-alloy-ile-ajan-konsolidasyonu",
      "title": "Grafana Alloy ile Ajan Konsolidasyonu",
      "summary": "Node exporter, log agent ve telemetry toplayıcı karmaşasını tek bir akışta toparlamak için Grafana Alloy tabanlı yaklaşım.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './grafana alloy ile ajan konsolidasyonu diagram.svg'; Sunucu ve Kubernetes ortamlarında zamanla şu tablo oluşur: metric için ayrı ajan, log için ayrı ajan, trace için başka bir collector ve bunların her biri için farklı konfigürasyon modeli. Bu parçalı yapı küçük ölçekte tolere edilir; fakat kurumsal sistemlerde sürüm yönetimi, etiket standardı ve kaynak tüketimi tarafında ciddi operasyon maliyeti üretir. Grafana Alloy bu dağınık ajan manzarasını tek bir veri toplama katmanında toparlamak için güçlü bir adaydır. <figure <Image src={diagram} alt=\"Tek ajanlı telemetry toplama akışını gösteren teknik şema\" / <figcaption Tek ajan yaklaşımı; konfigürasyon, etiketleme ve veri yönlendirmesini merkezi hâle getirerek operasyon yükünü azaltır.</figcaption </figure Alloy hangi problemi çözer? Asıl problem ajan sayısı değil, ajanların yönetim biçimidir. Ayrı ayrı çalışan araçlarda şu sorunlar büyür: Her ajan için farklı rollout prosedürü gerekir. Etiket standardı drift üretir. Aynı host üzerinde gereksiz kaynak tüketimi artar. Sorun çıktığında hangi katmanın veri kaybettiğini bulmak zorlaşır. Alloy; Prometheus scrape, log toplama ve OpenTelemetry veri akışlarını tek yapı altında birleştirerek bu sorunu azaltır. Nereden başlanmalı? İlk aşamada mevcut ajan envanterini çıkarın. Genelde şu üç akış görünür: 1. Sistem ve uygulama metrikleri 2. Uygulama ve platform logları 3. Trace veya OTLP tabanlı telemetry Amaç ilk günde tüm ajanları sökmek değildir. Önce Alloy'u yan yana çalıştırıp veri modelini ve kaynak etkisini görmek daha güvenlidir. Örnek mimari Pratik bir başlangıç mimarisinde Alloy şu görevleri üstlenebilir: Node exporter benzeri sistem metriklerini scrape eder. Dosya veya journald tabanlı logları toplar. Uygulama telemetry verisini OTLP ile kabul eder. Ortak etiketleri bütün akışlarda uygular. Veriyi Prometheus uyumlu metric deposu, log deposu ve trace backend'ine yönlendirir. <Callout type=\"tip\" title=\"Tek konfigürasyon, tek sahiplik\" Telemetry toplama katmanında parçalı sorumluluk yerine ortak bir konfigürasyon havuzu ve net onay akışı kurun. Aksi halde ajan konsolidasyonu kısa sürede yeniden parçalanır. </Callout Basit bir Alloy akışı Aşağıdaki örnek; bir host üzerindeki sistem metriklerini ve logları toplayıp merkezi hedeflere yönlendiren sade bir başlangıç mantığı verir: Bu yapı büyüdükçe discovery, relabel ve OTLP pipeline'larıyla genişletilebilir. En kritik konu: etiket ve sahiplik Tek ajan modeli ancak veri düzeni iyiyse değer üretir. Bu yüzden aşağıdaki alanları standartlaştırın: environment team service region criticality Bu etiketler alarm yönlendirmesi, dashboard gruplama ve olay analizi için temel omurgayı oluşturur. Migration nasıl yapılmalı? Benim önerdiğim geçiş sırası şu şekilde: 1. Alloy'u mevcut ajanlarla paralel devreye alın. 2. Veri hacmi ve etiket eşleşmesini doğrulayın. 3. Önce en düşük riskli ajanı devreden çıkarın. 4. Kaynak kullanımı ve veri kaybı sinyallerini izleyin. 5. Host sınıflarına göre rollout dalgaları yapın. Bu yaklaşım, bir anda tüm gözlemlenebilirlik katmanını riske atmadan ilerlemenizi sağlar. Sonuç Grafana Alloy ile ajan konsolidasyonu, araç sayısını azaltma egzersizi değil; telemetry üretimini yönetilebilir ve tutarlı hâle getirme çalışmasıdır. Özellikle çok sayıda sunucu, hibrit ağ ve kurumsal servis bulunan ortamlarda tek ajan yaklaşımı; operasyon karmaşasını azaltır, standartlaşmayı hızlandırır ve incident anında veri akışına güveni artırır.",
      "date_published": "2026-04-04T00:00:00.000Z",
      "date_modified": "2026-04-04T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "grafana",
        "alloy",
        "monitoring",
        "automation"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/netbox-ile-ipam-ve-envanter-otomasyonu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/netbox-ile-ipam-ve-envanter-otomasyonu",
      "title": "NetBox ile IPAM ve Envanter Otomasyonu",
      "summary": "Ağ adres planı ve veri merkezi envanterini ticket tablosundan çıkarıp otomasyon dostu modele taşımak için NetBox yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './netbox ile ipam ve envanter otomasyonu diagram.svg'; Ağ ve sunucu tarafında en hızlı bozulan alanlardan biri envanter gerçeğidir. IP blokları ayrı Excel dosyasında, rack yerleşimi başka bir wiki sayfasında, VLAN bilgisi ticket geçmişinde, cihaz rolleri ise yalnızca birkaç kişinin hafızasında tutuluyorsa otomasyon için güvenilir veri zemini oluşmaz. NetBox bu problemi çözmek için yalnızca bir IPAM aracı değil, altyapı gerçekliğinin merkezi veri modeli olarak düşünülmelidir. <figure <Image src={diagram} alt=\"IPAM ve envanter otomasyon akışını gösteren teknik şema\" / <figcaption Envanter veri modeli düzeldikçe provisioning, denetim ve değişiklik yönetimi otomasyonla uyumlu hâle gelir.</figcaption </figure Neden önce veri modeli? Birçok ekip otomasyona Ansible veya Terraform ile başlamak ister. Oysa kaynak gerçeği dağınıkysa otomasyon yalnızca hatalı bilgiyi daha hızlı çoğaltır. NetBox tarafında ilk kazanım; cihaz, prefix, VLAN, site ve tenant gibi nesnelerin ortak dilde tanımlanmasıdır. Bu tanım sayesinde şu sorular otomatik cevaplanabilir: Bu subnet hangi lokasyona ait? Hangi cihaz hangi role sahip? Boş IP aralığı nerede? Belirli bir rack içinde hangi kritik sistemler bulunuyor? Minimum uygulanabilir kurulum nasıl görünür? İlk aşamada her detayı doldurmaya çalışmak yerine veri modelini sade tutmak daha doğrudur. Benim önerdiğim başlangıç seti şu nesneleri içerir: Site Device role Device type Prefix VLAN IP address Rack Bu nesneler bile düzgün işletildiğinde hem ağ operasyonu hem de sunucu kurulum akışı ciddi ölçüde netleşir. Otomasyon için hangi alanlar kritik? NetBox'ta veri girilmiş olması tek başına yeterli değildir. Otomasyonun güvenmesi için bazı alanlar zorunlu hale getirilmelidir: Sahip ekip bilgisi Ortam sınıfı (production, test, lab) Lokasyon veya veri merkezi Cihaz rolü Servis kritikliği <Callout type=\"tip\" title=\"Opsiyonel alanlar hızla çürür\" Eğer kritik metadata alanları opsiyonel kalırsa ilk yoğunlukta boş bırakılır. Sonra da tüm raporlar ve otomasyon kuralları kırılgan hâle gelir. </Callout NetBox'tan hangi süreçleri besleyebilirsiniz? Doğru veri modeliyle NetBox aşağıdaki akışlara kaynak olabilir: 1. Yeni sunucu için IP atama 2. Firewall obje üretimi 3. DNS kayıt oluşturma 4. Rack kapasite görünürlüğü 5. CMDB benzeri temel envanter raporları Özellikle IPAM ile DNS ve firewall akışı birleştiğinde ağ tarafındaki manuel ticket yükü ciddi biçimde azalır. API kullanımı nasıl planlanmalı? NetBox'ın gerçek değeri API katmanında ortaya çıkar. Otomasyon tarafında yaygın bir desen şudur: İstenen site, rol ve ortam bilgisi alınır. Uygun prefix havuzu API ile sorgulanır. İlk boş IP ayrılır. Cihaz nesnesi ve arayüz ilişkileri oluşturulur. Çıktı Ansible veya Terraform akışına aktarılır. Bu sayede insan hatasıyla çakışan IP, unutulan VLAN ya da eksik envanter kaydı gibi sorunlar azalır. Süreç disiplini kurulmazsa ne olur? En büyük risk, NetBox'ın zamanla referans sistem değil, geriden gelen rapor sistemi haline dönüşmesidir. Bunu engellemek için: Değişiklik akışlarında NetBox güncellemesi kapanış kriteri olmalı Mümkün olan yerde kayıt üretimi API üzerinden yapılmalı Düzenli uyumsuzluk raporları alınmalı Elle açılan istisna kayıtları sınırlanmalı Sonuç NetBox ile IPAM ve envanter otomasyonu, görünüşte veri girişi disiplini gibi durur; fakat aslında bütün altyapı otomasyonunun güvenilir zeminini kurar. Ağ, sunucu ve veri merkezi operasyonlarını daha sistematik hale getirmek isteyen ekipler için doğru başlangıç noktası çoğu zaman yeni bir araç değil, tek bir doğru envanter modelidir.",
      "date_published": "2026-04-04T00:00:00.000Z",
      "date_modified": "2026-04-04T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "network",
        "ipam",
        "netbox",
        "automation",
        "infrastructure"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-postmortem-kulturu",
      "url": "https://mustafaerbay.com.tr/blog/career/teknik-liderler-icin-postmortem-kulturu",
      "title": "Teknik Liderler için Postmortem Kültürü",
      "summary": "Postmortem sürecini suç arama toplantısından çıkarıp öğrenen ekip pratiğine dönüştürmek için liderlik rehberi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './teknik liderler icin postmortem kulturu diagram.svg'; Bir kesinti yaşandıktan sonra yapılan toplantıların adı çoğu yerde postmortem'dir; ama pratiğin kendisi çoğu zaman öğrenme değil savunma üretir. İnsanlar kronolojiyi toparlamak yerine kendi kararlarını açıklamaya, ekipler çözüm üretmek yerine sınır çizmeye başlar. Teknik lider için asıl mesele rapor yazdırmak değil, olay sonrasını kurumsal öğrenmeye çevirebilmektir. <figure <Image src={diagram} alt=\"Postmortem toplantısı, zaman çizelgesi ve öğrenim döngüsünü gösteren teknik şema\" / <figcaption Sağlıklı postmortem kültürü, suçlu aramaktan çok karar zincirini ve sistem boşluklarını görünür kılar.</figcaption </figure Postmortem neden kariyer pratiğidir? Kıdemli mühendislik ve teknik liderlik, yalnızca doğru teknoloji seçmekle ölçülmez. Aynı derecede önemli bir yetkinlik, zor bir olaydan sonra ekibin güvenini ve öğrenme hızını koruyabilmektir. Çünkü teknik borç kadar ilişki borcu da birikir. İyi postmortem kültürü teknik lider açısından şu etkileri üretir: Belirsizliği suç diline dönüştürmeden açıklığa kavuşturur. Ekipler arası güven kaybını azaltır. Tekrarlayan zayıf sinyalleri görünür kılar. İyileştirme işlerini önceliklendirmeyi kolaylaştırır. En sık yapılan yanlış yaklaşım Toplantının görünmez gündemi \"hata kimde?\" olduğunda, herkes savunma moduna geçer. O noktadan sonra kronoloji bozulur, asıl karar anları kaybolur ve ekipler bir daha açık konuşmak istemez. Teknik liderin ilk görevi, kişisel savunmayı değil sistem davranışını merkezde tutmaktır. Bu şu anlama gelir: Hangi alarm önce geldi? Ekip neyi ne zaman doğru sandı? Hangi bilgi eksikliği kararı yavaşlattı? Hangi koruma katmanı çalışmadı? Sorular bu çerçevede kurulduğunda tartışma daha dürüst ve daha üretken olur. <Callout type=\"tip\" title=\"Ton liderlikten başlar\" Toplantının dili, liderin ilk beş dakikadaki çerçevesiyle belirlenir. Savunmacı tonla açılan postmortem, teknik olarak ne kadar iyi hazırlanırsa hazırlansın güven üretmez. </Callout Sağlıklı bir postmortem akışı nasıl kurulmalı? Benim en verimli gördüğüm akış dört parçadan oluşur: 1. Etkinin net tanımı : Kim etkilendi, ne kadar süre etkilendi? 2. Zaman çizelgesi : Alarm, tespit, müdahale ve toparlanma adımları 3. Karar noktaları : O anda hangi bilgiyle hangi karar verildi? 4. İyileştirme işleri : Sahipli, tarihlendirilmiş ve ölçülebilir aksiyonlar Bu yapı, olay anlatımını duygusal yorumlardan ayırıp ortak gerçeklik üretir. Teknik lider burada neyi yönetir? Teknik lider her ayrıntıyı kendisi çıkarmak zorunda değildir. Ama şu disiplinleri korumalıdır: Toplantının savunma değil öğrenme amacı taşıdığını açık söylemek Belirsiz iddiaları veri veya zaman çizelgesine bağlatmak Takımlar arası suç transferini durdurmak Aksiyonların gerçekten sahiplenildiğini doğrulamak Özellikle çok ekipli ortamlarda bu rol kritikleşir; çünkü postmortem kalitesi doğrudan kurumun operasyon kültürünü şekillendirir. Aksiyon maddeleri neden çoğu yerde işlemiyor? Çünkü birçok postmortem'de sonuç bölümü ya fazla genel kalır ya da yalnızca teknik düzeltmeye indirgenir. Oysa bazı aksiyonlar teknolojiye değil sürece dokunmalıdır: Alarm eşiği yeniden tasarlanmalı mı? Nöbetçi iletişim akışı değişmeli mi? Rollback kararı için açık kural gerekiyor mu? Ekipler arası eskalasyon seviyesi net mi? Bu tip maddeler teknik olmayan iş gibi görünür; ama bir sonraki incident'ın süresini çoğu zaman onlar belirler. Kültürün yerleştiği nasıl anlaşılır? İyi işaretler şunlardır: İnsanlar olay anlatırken kendini korumaya değil açıklamaya odaklanır. Postmortem notları sonraki projelerde gerçekten referans alınır. Aynı tür kesintilerde daha hızlı karar verilir. Takımlar \"sorun kimde\" yerine \"hangi katman eksikti\" diye düşünmeye başlar. Bu noktaya gelmek zaman alır; ama teknik liderlikte kalıcı etki tam burada oluşur. Sonuç Teknik liderler için postmortem kültürü, operasyonel olgunluğun en net göstergelerinden biridir. İyi yönetildiğinde yalnızca geçmiş olayı açıklamaz; ekiplerin birbirine nasıl güvendiğini, nasıl öğrendiğini ve bir sonraki baskı anında nasıl davranacağını da şekillendirir. Güçlü kurumlar, hatayı hiç yaşamayanlar değil, hatadan sistematik biçimde öğrenebilenlerdir.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "teknik-liderlik",
        "incident-management",
        "mentorluk",
        "operations"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-entegrasyon-dmz-deseni",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-entegrasyon-dmz-deseni",
      "title": "ERP Altyapılarında Entegrasyon DMZ Deseni",
      "summary": "ERP çekirdek sistemlerini doğrudan açmadan partner ve dış servis entegrasyonlarını güvenli ara katmanda toplama yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ERP sistemleri çoğu zaman iş sürekliliğinin kalbidir; ama aynı zamanda en zor modernize edilen yüzeylerden biridir. E ticaret, bayi ağı, lojistik sağlayıcıları, bankalar ve kamu servisleriyle konuşmak zorunda olan bu sistemler, doğrudan internete veya geniş partner ağlarına açıldığında risk hızlıca büyür. Entegrasyon DMZ deseni, ERP çekirdeği ile dış dünya arasına kontrollü bir ara katman koyarak bu riski azaltır. Neden klasik DMZ yaklaşımı yetmez? Geleneksel DMZ genelde web sunucusu yayımlama senaryosundan türemiştir. ERP entegrasyonlarında ise tablo daha karmaşıktır: Senkron API çağrıları vardır Zamanlanmış batch dosya akışları vardır Mesaj kuyruğu veya olay akışları bulunur Bazı partnerler sabit IP, bazıları mTLS, bazıları VPN ister Bu nedenle entegrasyon DMZ yalnızca ağ sınırı değil; protokol dönüştürme, kimlik doğrulama, kayıt üretme ve trafik sınırlama yüzeyi olarak düşünülmelidir. Desenin ana prensipleri 1. ERP çekirdeğini izole tutmak ERP veritabanısı, uygulama sunucusu ve iç servisleri doğrudan partner erişimine açılmamalıdır. Dış bağlantılar önce ara katmana gelmeli; gerekli doğrulama ve filtreler burada uygulanmalıdır. 2. Arabulucu servis kullanmak Adapter, API gateway, message broker bridge veya dosya aktarım ajanı gibi bileşenler ERP'nin iç protokolünü dış tüketiciden ayırır. Böylece çekirdek sistem değişmeden çevresel entegrasyon daha kontrollü evrilir. 3. Tekrarlanabilir güvenlik politikası Partner bazlı IP kısıtı, kimlik türü, oran limiti, veri maskesi ve denetim kaydı politikaları standart modelle yönetilmelidir. Her entegrasyon için ayrı istisna betiği yazmak uzun vadede sürdürülemez. <Callout type=\"tip\" title=\"Sınırları net çizin\" DMZ katmanının görevi iş mantığını büyütmek değildir. Burada doğrulama, yönlendirme, sınırlama ve görünürlük olmalı; ERP iç kuralları mümkün olduğunca çekirdekte kalmalıdır. </Callout Hangi bileşenler tipik olarak yer alır? Pratik bir entegrasyon DMZ mimarisinde şu parçalar sık görülür: Ters proxy veya API gateway WAF veya temel istek filtreleme katmanı Mesaj veya dosya aktarım köprüsü mTLS sertifika sonlandırma noktası Audit log ve telemetry toplayıcıları Gerekirse veri maskeleme veya şema doğrulama katmanı Burada önemli nokta, bu bileşenlerin tek ürün altında toplanması değil; aynı güven ve işletim modeline bağlı olmasıdır. Ağ ve güvenlik tarafında kritik kararlar Entegrasyon DMZ kurulurken şu sorular baştan yanıtlanmalıdır: Partner erişimi hangi segmentten başlayacak? ERP'ye doğru tek yönlü mü, kontrollü çift yönlü mü akış olacak? Dosya aktarımı ile API çağrıları aynı güven düzeyinde mi ele alınacak? Hangi veriler DMZ içinde geçici tutulabilir? Olay anında hangi loglar delil niteliğinde korunacak? Özellikle finans, üretim ve dağıtım odaklı ERP sistemlerinde audit izi çoğu zaman teknik detay değil, regülasyon gereğidir. Operasyon modelinde neden fayda sağlar? DMZ deseni doğru kurulduğunda şu sonuçları üretir: Yeni partner bağlantıları daha hızlı devreye alınır Kimlik ve sertifika yaşam döngüsü standardize olur İç ERP topolojisi daha az ifşa edilir Olay incelemesi daha kısa sürer Segmentasyon ihlallerinin etkisi daralır Ayrıca ERP yükseltmeleri sırasında dış entegrasyon yüzeyini sabit tutmak daha kolay hale gelir. Böylece çekirdek sistem değişirken partner sözleşmeleri daha az etkilenir. Sonuç ERP altyapılarında entegrasyon DMZ deseni, dış dünya ile çekirdek iş sistemleri arasında kontrollü bir tampon görevi görür. Ağ sınırı, kimlik, protokol ve telemetry kararlarını ortak yüzeyde topladığınızda; hem güvenlik riski azalır hem de entegrasyon operasyonu daha ölçeklenebilir hale gelir. Özellikle partner trafiği yoğun, regülasyon baskısı yüksek ve değişim maliyeti büyük ERP ortamlarında bu desen ciddi fark yaratır.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "security",
        "network",
        "integration",
        "sistem-mimarisi"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-entegrasyon-dmz-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-altyapilarinda-entegrasyon-dmz-tasarimi",
      "title": "ERP Altyapılarında Entegrasyon DMZ Tasarımı",
      "summary": "ERP sistemlerini dış servislerle güvenli ve yönetilebilir biçimde bağlamak için entegrasyon DMZ yaklaşımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './erp altyapilarinda entegrasyon dmz tasarimi diagram.svg'; ERP platformları çoğu kurumda çekirdek sistemdir; ama çevresindeki entegrasyon yüzeyi kontrol edilmediğinde en kırılgan nokta hâline gelir. Banka, e fatura, lojistik, insan kaynakları, bayi portalı veya veri ambarı gibi sistemlerle kurulan bağlantılar arttıkça, ERP çekirdeğini doğrudan dış dünyaya açmak hem güvenlik hem de işletilebilirlik açısından pahalı bir hataya dönüşür. Entegrasyon DMZ tasarımı bu nedenle yalnızca ağ güvenliği konusu değil, kurumsal mimari disiplini olarak ele alınmalıdır. <figure <Image src={diagram} alt=\"ERP çekirdeği, entegrasyon DMZ katmanı ve dış servis akışlarını gösteren teknik şema\" / <figcaption ERP çekirdeğinin doğrudan değil, kontrol edilen entegrasyon katmanı üzerinden dış sistemlere açılması.</figcaption </figure Entegrasyon DMZ neyi çözer? En sık görülen hata, ERP uygulama sunucularının aynı ağ düzleminden hem kullanıcı trafiğini hem de entegrasyon çağrılarını kabul etmesidir. Bu model kısa vadede hızlı görünür; ancak birkaç ay sonra hangi servisin hangi porttan konuştuğu, hangi kimlikle eriştiği ve hangi akışın gerçekten iş için kritik olduğu belirsizleşir. Entegrasyon DMZ yaklaşımı bu karmaşayı şu ayrımlarla düzenler: ERP çekirdeği ile dış dünya arasında ayrı bir güvenlik ve protokol katmanı kurar. Dosya, API, message queue ve batch akışlarını sınıflandırır. Kimlik, sertifika, kayıt ve oran sınırlama gibi kontrolleri merkezîleştirir. Sorun olduğunda etkilenme alanını daraltır. Bu katman sayesinde \"ERP’ye kim erişiyor?\" sorusu teknik olarak izlenebilir hâle gelir. Hangi bileşenler bu bölgede yaşamalı? Her şeyin DMZ'ye taşınması doğru değildir. Ama aşağıdaki servisler çoğunlukla bu bölge için uygundur: 1. API gateway veya reverse proxy katmanı 2. Mesajlaşma köprüleri ve entegrasyon ajanları 3. Güvenli dosya transfer servisleri 4. Partner bağlantıları için bağlantı sonlandırma bileşenleri 5. Entegrasyon loglama ve denetim servisleri Buradaki ana prensip şudur: iş kurallarının merkezi yine ERP veya onu çevreleyen kontrollü uygulama servislerinde kalır; dış erişim temas yüzeyi ise ayrı bir koruma bandı içinde yönetilir. <Callout type=\"info\" title=\"Pratik mimari kararı\" ERP veritabanısını veya uygulama çekirdeğini entegrasyon DMZ içinde konumlandırmak yerine, yalnızca kontrollü geçiş servislerini burada tutmak daha güvenli ve daha sürdürülebilir bir model üretir. </Callout Neden yalnızca firewall kuralı yetmez? Kurumsal ortamlarda \"gerekli portları açtık\" ifadesi çoğu zaman mimari tasarım sanılır. Oysa entegrasyon riski yalnızca port seviyesinde oluşmaz. Asıl risk şu alanlarda birikir: Aynı servis hesabının birçok partner tarafından paylaşılması Sertifika yenileme sürecinin manuel ilerlemesi Başarısız isteklerin merkezi olarak izlenmemesi Üretim ile test entegrasyonlarının karışması Dosya bazlı akışların kimin tarafından tetiklendiğinin bilinmemesi Entegrasyon DMZ tasarımında ağ kuralı sadece ilk filtredir. Kimlik, gözlemlenebilirlik ve yaşam döngüsü disiplini aynı ölçüde önemlidir. Trafik sınıflandırmasını baştan yapmak neden kritik? ERP çevresinde genellikle dört temel entegrasyon tipi vardır: Senkron API çağrıları Asenkron kuyruk veya event akışları Zamanlanmış batch veri transferleri Dosya tabanlı dış kurum iletişimi Bu dört akışı aynı operasyon modeline zorlamak verimsizlik üretir. Örneğin bayi portalı için düşük gecikmeli API gerekirken, finans mutabakatı için dosya bütünlüğü ve denetlenebilirlik daha kritik olabilir. Entegrasyon DMZ tasarımı, farklı akış tiplerine farklı güvenlik ve izleme politikaları tanımlayabildiğinde değer üretir. Operasyon tarafında hangi sinyaller toplanmalı? Bu bölge kör bırakılırsa, sorun yalnızca ERP ekibine \"entegrasyon çalışmıyor\" diye yansır. Bunun yerine aşağıdaki sinyaller standart olmalıdır: Kaynak ve hedef sistem bazında başarı oranı Kuyruk birikimi veya yeniden deneme sayıları Sertifika sona erme tarihleri Partner veya kanal bazında hata dağılımı Gecikme eşikleri ve kapasite limitleri Bu yaklaşım, incident anında ERP çekirdeği mi sorunlu, yoksa dış bağlantı katmanı mı zayıf sorusunu dakikalar içinde ayırmanıza yardım eder. Başlangıç için uygulanabilir tasarım prensipleri 1. ERP çekirdeğini doğrudan internete veya partner ağlarına açmayın. 2. Dış entegrasyonları protokol tipine göre ayrı giriş noktalarına bölün. 3. Her partner için ayrı kimlik veya sertifika yaşam döngüsü tanımlayın. 4. Tüm entegrasyon çağrılarını merkezi loglama ve alarm sistemine bağlayın. 5. Test ve üretim akışlarını ağ, kimlik ve gözlemlenebilirlik düzeyinde ayırın. Sonuç ERP altyapılarında entegrasyon DMZ tasarımı, yalnızca güvenlik duvarı önüne birkaç sunucu koymak değildir. Doğru uygulandığında, çekirdek iş sistemini dış bağımlılıklardan ayırır; denetlenebilirliği artırır ve partner ekosistemi büyüdükçe mimarinin dağılmasını önler. Kurumsal teknoloji mimarisinde sürdürülebilirlik çoğu zaman tam burada başlar: kritik sistemi korurken entegrasyonu durdurmadan yönetebilmek.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "network",
        "security",
        "integration",
        "architecture"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-modernizasyonunda-veri-replikasyon-katmani",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-modernizasyonunda-veri-replikasyon-katmani",
      "title": "ERP Modernizasyonunda Veri Replikasyon Katmanı",
      "summary": "ERP çekirdeğini bozmadan entegrasyon yükünü dağıtmak için veri replikasyon katmanı tasarım yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ERP modernizasyon projelerinde en pahalı hatalardan biri, her yeni analitik, entegrasyon veya mikroservis ihtiyacını doğrudan ERP veritabanına bağlamaktır. Bu model ilk etapta hızlı görünür; zamanla raporlama sorguları üretim yükünü bozar, entegrasyon ekipleri birbirinin veri modeline bağımlı hale gelir ve ERP yükseltmeleri büyük kırılım alanlarına dönüşür. Veri replikasyon katmanı, ERP çekirdeği ile tüketici sistemler arasına kontrollü bir tampon koyarak bu baskıyı azaltır. Replikasyon katmanı neyi çözer? Temel amaç, operasyonel çekirdeği korurken veri tüketimini ölçeklenebilir hale getirmektir. İyi tasarlanmış bir katman şunları sağlar: ERP veritabanı üzerindeki doğrudan okuma baskısını azaltır Entegrasyonları ortak veri sözleşmeleri üzerinden yönetir Analitik, arama ve raporlama iş yüklerini ayrıştırır Hata alanını küçültür; her tüketici çekirdek sisteme dokunmaz Bu yaklaşım özellikle birden fazla ülke, iş birimi veya entegrasyon partneri olan yapılarda kritik değer üretir. Replikasyon türünü seçerken nelere bakılmalı? Her senaryo için aynı çözüm uygun değildir. Genel olarak üç model görülür: 1. Toplu kopyalama Saatlik veya günlük snapshot yaklaşımıdır. Finansal kapanış, tarihsel raporlama veya düşük frekanslı entegrasyonlar için uygundur. Basittir ama gerçek zamanlılık beklentisini karşılamaz. 2. CDC tabanlı akış Change Data Capture ile tablo değişiklikleri event akışına taşınır. Yakın gerçek zamanlı entegrasyon, veri gölü besleme ve olay tabanlı mimari için güçlüdür. Buna karşılık şema evrimi ve sıralama yönetimi daha dikkatli ele alınmalıdır. 3. Domain odaklı yayın Ham tablo değişikliği değil, iş anlamı olan olay yayımlanır. En temiz model budur; fakat ERP tarafında bunu üretmek her zaman kolay değildir. Kurumsal sahada çoğu zaman hibrit model gerekir: kritik domain olayları iş katmanından, geniş veri değişimleri ise CDC ile taşınır. <Callout type=\"tip\" title=\"Tablo kopyalamak entegrasyon tasarlamak değildir\" Replikasyon katmanı, veriyi sadece çoğaltmamalı; sahiplik, gecikme hedefi ve veri kalitesi sözleşmesini de tanımlamalıdır. </Callout Referans mimari Pratikte sağlam çalışan model şu bloklardan oluşur: 1. ERP kaynak sistemi 2. Replikasyon veya CDC yakalama katmanı 3. Şema normalizasyon ve maskeleme adımı 4. Tüketiciye göre ayrışan veri servisleri veya topic'ler 5. İzleme, gecikme ve veri tutarlılığı dashboard'ları Buradaki kritik karar, replikasyon katmanının \"pasif kopya\" mı yoksa \"yönetilen veri ürünü katmanı\" mı olacağıdır. İkinci yaklaşım başta daha çok disiplin ister ama uzun vadede entegrasyon kaosunu ciddi ölçüde azaltır. Güvenlik ve yetki modeli ERP verisi çoğu zaman personel, finans ve tedarik verilerini içerir. Bu nedenle replikasyon katmanı güvenlik açısından daha hafif değil, bazen çekirdek sistem kadar sıkı olmalıdır. Hassas kolonlar maskeleme veya tokenizasyon ile ayrılmalı Tüketici bazlı erişim profili tanımlanmalı Kim hangi veri ürününü okuyor, izlenebilir olmalı Test ortamına taşınan kopyalarda veri anonimizasyonu zorunlu tutulmalı Özellikle analitik ekiplerin \"ham tablo erişimi\" talebi kısa vadede kolay görünür; uzun vadede yönetişimi dağıtır. Operasyonel riskler Replikasyon projeleri çoğu zaman teknik olarak değil, sahiplik belirsizliği yüzünden başarısız olur. Şu sorular önceden yanıtlanmalıdır: Gecikme bütçesi nedir? Hatalı kayıt tekrar işlendiğinde iş etkisi nasıl yönetilecek? Şema değişikliği kim tarafından duyurulacak? Kaynak sistem bakım pencereleri tüketicilere nasıl yansıyacak? Bu cevaplar yoksa sistem teknik olarak ayakta olsa bile kurumsal kullanımda güven kaybeder. Hangi durumlarda özellikle değerlidir? Veri replikasyon katmanı aşağıdaki senaryolarda yüksek fayda üretir: ERP'den çok sayıda yan sistem besleniyorsa Raporlama sorguları üretim performansını etkiliyorsa Modern uygulamalar ile legacy çekirdek aynı anda yaşayacaksa Çoklu bulut veya hibrit veri tüketim deseni oluştuysa Burada amaç ERP'yi hemen değiştirmek değil, çevresindeki entegrasyon baskısını mimari olarak soğutmaktır. Sonuç ERP modernizasyonu her zaman çekirdek sistemi yeniden yazmak anlamına gelmez. Çoğu kurum için asıl kaldıraç, ERP'nin etrafında güvenli, izlenebilir ve kontrollü bir veri replikasyon katmanı kurmaktır. Böylece modern servisler ve analitik ihtiyaçlar büyürken çekirdek sistem daha az zorlanır; yükseltme, güvenlik ve performans kararları daha yönetilebilir hale gelir.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "veri-mimarisi",
        "entegrasyon",
        "kurumsal-mimari",
        "replikasyon"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-sistemlerinde-ayricalikli-erisim-segmentation",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-sistemlerinde-ayricalikli-erisim-segmentation",
      "title": "ERP Sistemlerinde Ayrıcalıklı Erişim Segmentasyonu",
      "summary": "ERP çekirdek sistemlerini yönetirken kalıcı geniş yetkileri azaltan ağ ve erişim segmentasyonu yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ERP altyapılarında en hassas risklerden biri, operasyon kolaylığı uğruna fazla genişletilmiş yönetim erişimleridir. Uygulama sunucusuna bağlanan bir hesap çoğu zaman veritabanına, entegrasyon katmanına ve işletim sistemi düzeyine de dolaylı erişim kazanır. Bu durum yalnızca güvenlik sorunu değildir; değişiklik yönetimi, denetim izi ve görev ayrılığı açısından da ciddi zafiyet üretir. Ayrıcalıklı erişim segmentasyonu, bu dağınık modeli kontrollü bir mimariye çevirmeyi amaçlar. Sorun gerçekten nerede başlıyor? ERP ortamları tek katmanlı değildir. Tipik bir kurumsal topolojide şu bileşenler birlikte yaşar: Uygulama sunucuları Veritabanı katmanı Batch ve entegrasyon servisleri Dosya aktarım alanları Yönetim ve bakım araçları Bu katmanların hepsi aynı yönetim ağı veya aynı yetki modeliyle erişilebilir olduğunda, bir hesabın ele geçirilmesi beklenenden çok daha geniş etki alanı yaratır. Özellikle dış danışman, destek ekibi ve iç operasyon rollerinin aynı erişim yolunu paylaşması yüksek risk üretir. Segmentasyonun amacı yetkiyi değil yüzeyi küçültmektir Birçok ekip segmentasyonu sadece “kim nereye bağlanır” sorusu gibi görür. Oysa asıl hedef, her rolün ihtiyaç duyduğu minimum yüzeyi tanımlamaktır. Örneğin: ERP uygulama yöneticisi doğrudan veritabanı işletim sistemine çıkmamalıdır. Veritabanı yöneticisi uygulama middleware katmanına kalıcı erişim taşımamalıdır. Entegrasyon servis hesabı interaktif shell oturumu açmamalıdır. Dış destek erişimi zaman sınırlı ve kayıtlı olmalıdır. Bu ayrım hem saldırı yüzeyini hem de hatalı değişiklik riskini azaltır. Ağ, kimlik ve oturum katmanlarını birlikte düşünmek gerekir Ayrıcalıklı erişim segmentasyonu sadece firewall kuralı yazmak değildir. Üç katman birlikte ele alınmalıdır: 1. Ağ segmentasyonu ERP veritabanı, uygulama ve yönetim ağları ayrı segmentlerde yaşamalıdır. Özellikle yönetim erişimi, kullanıcı uygulama trafiği ile aynı hat üzerinden akmamalıdır. 2. Kimlik segmentasyonu İnsan kullanıcılar, servis hesapları ve acil durum hesapları aynı dizin grubunda toplanmamalıdır. Federasyon, MFA ve geçici rol yükseltme akışları ayrılmalıdır. 3. Oturum kontrolü Jump host, session recording ve emir geçmişi tutulmadan verilen kalıcı SSH/RDP erişimleri kurumsal ERP ortamında kabul edilebilir tasarım değildir. <Callout type=\"tip\" title=\"Görev ayrılığı kâğıtta kalmamalı\" Denetim raporlarında görev ayrılığı maddesi görmek yeterli değildir. Gerçek ayrım, ağ yolu, kimlik kaynağı ve komut geçmişi katmanında teknik olarak ispatlanmalıdır. </Callout Hangi desenler pratikte işe yarar? Kurumsal yapılarda aşağıdaki desenler en çok değer üretir: ERP yönetimi için ayrı bastion veya privileged access gateway Kalıcı admin hesabı yerine onaylı ve süreli yükseltme akışı Veritabanı bakım erişimleri için ayrı kayıt ve onay hattı Entegrasyon servisleri için insan oturumundan bağımsız makine kimliği Tüm ayrıcalıklı erişim olaylarının SIEM ve observability sistemine akması Bu desenler güvenliği artırırken operasyonu da daha okunabilir hâle getirir. En sık görülen zayıflıklar Sahada tekrar eden bazı hatalar şunlardır: Aynı servis hesabının hem batch işlerinde hem manuel bakımda kullanılması ERP uygulama ekibine kalıcı root veya local admin verilmesi Jump host üzerinde oturum kaydı tutulmaması Destek tedarikçileri için VPN sonrası doğrudan sunucu erişimi açılması Bu yaklaşımlar kısa vadede kolay görünür; ama olay analizi ve denetim anında ciddi kör nokta bırakır. Yol haritası nasıl kurulmalı? 1. ERP ortamındaki tüm insan ve servis erişimlerini ayrı ayrı envanterleyin. 2. Kalıcı geniş yetki taşıyan hesapları belirleyin. 3. Uygulama, veritabanı ve yönetim yollarını segment bazında ayırın. 4. Ayrıcalıklı erişimleri kayıtlı jump host üzerinden geçirin. 5. Acil durum hesaplarını süreli ve denetlenebilir modele taşıyın. Bu dönüşüm bir gecede tamamlanmaz; fakat doğru sırayla ilerlediğinde operasyonu bozmadan risk yüzeyini küçültür. Sonuç ERP sistemlerinde ayrıcalıklı erişim segmentasyonu, yalnızca güvenlik ekibinin beklentisi değildir; kritik iş süreçlerinin sürdürülebilir işletimi için temel mimari gereksinimdir. Kalıcı geniş yetkileri azaltıp erişim yollarını ayrıştırdığınızda hem olay etkisini daraltır hem de kurumsal denetim kalitesini yükseltirsiniz. Özellikle ERP gibi merkezi ve yüksek etkili sistemlerde bu disiplin, teknik borcu azaltan stratejik bir yatırımdır.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "güvenlik",
        "zero-trust",
        "erişim",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-merkezi-egress-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-merkezi-egress-tasarimi",
      "title": "Kurumsal Ağlarda Merkezi Egress Tasarımı",
      "summary": "İnternete çıkan kurumsal trafiği görünür, denetlenebilir ve ölçeklenebilir bir egress katmanında toplama prensipleri.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal yapılarda internet çıkışı çoğu zaman ağ tasarımının en geç konuşulan ama en pahalı kararlarından biridir. İlk servisler açılırken birkaç güvenlik duvarı kuralı ve birkaç NAT kaydı yeterli görünür. Zaman içinde SaaS bağlantıları, güncelleme depoları, API entegrasyonları, yedekleme hedefleri ve gözlemlenebilirlik ajanları çoğaldıkça egress davranışı kontrolsüz bir yüzeye dönüşür. Merkezi egress tasarımı, bu dağınık çıkışı ortak politika ve görünürlük katmanında toplar. Neden ayrı bir mimari katman olarak düşünülmeli? İnternete çıkan trafik sadece web erişimi değildir. Kurumsal ortamda tipik olarak şu akışlar aynı dış yüzeyi paylaşır: Sunucu ve container imaj güncellemeleri SaaS servis çağrıları ERP entegrasyonlarının dış sistem bağlantıları Tehdit istihbaratı ve güvenlik imza güncellemeleri Yedekleme veya arşivleme trafiği Bu akışların risk profili, bant genişliği ihtiyacı ve kayıt gereksinimi aynı değildir. Her segmentin kendi çıkışını yönetmesi ise kısa sürede kural dağınıklığı üretir. Merkezi egress modeli ne kazandırır? Sağlam bir tasarımın ana hedefleri şunlardır: 1. Trafiğin kaynağını açık biçimde tanımlamak 2. İzin verilen hedefleri politika ile sınırlandırmak 3. TLS görünürlüğü veya metadata görünürlüğünü kontrollü üretmek 4. Olay incelemesi için ortak log ve akış verisi toplamak 5. Gerektiğinde bölgesel veya servis bazlı çıkış ayrımı yapabilmek Buradaki amaç her şeyi tek cihazdan geçirmek değildir; denetimi tek mimari model altında toplamaktır. Tasarımın temel bileşenleri 1. Çıkış segmentasyonu Üretim uygulamaları, yönetim ağı, CI ajanları ve kullanıcı trafiği aynı NAT havuzunu kullanmamalıdır. Çıkış IP ayrımı, hem güvenlik politikası hem dış servislerde allowlist yönetimi açısından ciddi kolaylık sağlar. 2. Politika motoru Hedef FQDN, servis etiketi, ortam tipi ve risk seviyesi üzerinden politika uygulanmalıdır. Salt IP tabanlı kural seti, SaaS ve dinamik servis tüketen modern yapılarda hızlıca yetersiz kalır. 3. Görünürlük katmanı Flow log, DNS log ve proxy log birlikte ele alınmalıdır. Yalnızca firewall kabul/ret kayıtlarıyla anlamlı operasyon resmi çıkmaz. 4. Yedeklilik modeli Merkezi egress katmanı tek hata noktasına dönüşmemelidir. Çift bölge, çift cihaz veya farklı çıkış yolu stratejileri baştan düşünülmelidir. <Callout type=\"warning\" title=\"Yaygın hata\" Merkezi egress kurarken tüm trafiği zorla tek güvenlik cihazına toplamak, performans ve arıza etkisini büyütebilir. Merkezileşmesi gereken şey, topoloji kadar politika ve telemetry modelidir. </Callout Hibrit bulut senaryolarında kritik kararlar On prem veri merkezi ile public cloud birlikte kullanılıyorsa şu sorular netleşmelidir: Buluttan çıkan trafik doğrudan mı internete gidecek, yoksa merkez veri merkezine mi dönecek? SaaS erişimi için bölgesel çıkış mı, merkezi güvenlik kırılımı mı tercih edilecek? İnternet egress ile partner bağlantıları aynı katmanda mı yönetilecek? DNS çözümlemesi ve hedef doğrulaması hangi güven sınırında yapılacak? Özellikle ERP çevresindeki batch entegrasyonlarında, dış sistemin yalnızca belirli çıkış IP aralıklarını kabul etmesi sık görülen bir gerçektir. Bu yüzden egress IP planı, ağ operasyonu kadar entegrasyon mimarisinin de parçasıdır. Neyi ölçmek gerekir? Merkezi egress katmanı kurulduktan sonra yalnızca cihaz sağlığı izlenmemelidir. Operasyonel açıdan şu sinyaller yüksek değer üretir: Servis veya segment bazlı çıkış hacmi Engellenen hedef dağılımı DNS isteği ile gerçek çıkış trafiği arasındaki korelasyon Bölgesel doygunluk ve gecikme TLS el sıkışma hataları ve sertifika problemleri Bu ölçümler, güvenlik ekibi için tehdit görünürlüğü; platform ekibi için ise kapasite ve hata ayıklama sinyali üretir. Sonuç Kurumsal ağlarda merkezi egress tasarımı, internet erişimini yalnızca “çıkış var mı” seviyesinden çıkarıp yönetilebilir mimari bileşene dönüştürür. Kaynak ayrımı, politika disiplini, görünürlük ve dayanıklılık birlikte düşünülürse; hem güvenlik yüzeyi daralır hem de dış bağımlılıklar daha kontrol edilebilir hale gelir. Özellikle hibrit bulut, ERP entegrasyonları ve denetim gereksinimi yüksek ortamlarda egress artık kenar detay değil, çekirdek tasarım kararıdır.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "security",
        "cloud",
        "egress",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-out-of-band-yonetim-duzlemi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-out-of-band-yonetim-duzlemi",
      "title": "Kurumsal Ağlarda Out-of-Band Yönetim Düzlemi",
      "summary": "Kritik ağ ve sunucu altyapılarında yönetim erişimini üretim trafiğinden ayıran out-of-band tasarım yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurum içi altyapılarda en büyük operasyonel yanılgılardan biri, üretim trafiğini taşıyan ağ ile yönetim erişimini aynı kaderi paylaşacak şekilde kurgulamaktır. Her şey normalken bu yaklaşım fark edilmez; ama switch konfigürasyonu bozulduğunda, routing tablosu kilitlendiğinde veya veri merkezi kenarındaki güvenlik duvarı hatalı kural aldığında ekipler tam da ihtiyaç duydukları anda cihazlara ulaşamaz hâle gelir. Out of band yönetim düzlemi, bu kırılganlığı azaltmak için tasarlanır. Out of band yaklaşımı neyi değiştirir? Bu modelin temel fikri basittir: cihazların yönetim arayüzleri, konsol portları ve kurtarma erişimleri; uygulama veya kullanıcı trafiğini taşıyan veri düzleminden fiziksel ya da mantıksal olarak ayrılır. Böylece üretim ağı bozulsa bile, işletim ekipleri altyapıyı ayağa kaldıracak kanalı kaybetmez. Pratikte şu bileşenler ayrı düşünülür: Switch, router ve firewall yönetim portları Hypervisor ve sunucu iLO, iDRAC, IPMI gibi kartları Konsol sunucuları ve seri erişim hatları Jump host veya bastion erişim katmanı Ayrı izleme, loglama ve kimlik denetim akışları Bu ayrım sadece erişim kolaylığı değil, olay anında düzenli karar alabilme kabiliyeti sağlar. Neden kurumsal yapılarda kritik? Küçük ortamlarda üretim ve yönetim trafiğinin aynı ağ üzerinde yaşaması çoğu zaman tolere edilir. Kurumsal yapılarda ise tablo değişir. Çünkü: Aynı anda yüzlerce ağ cihazı yönetilir. Bakım pencereleri çok katmanlıdır. ERP, güvenlik, sanallaştırma ve yedekleme ekipleri farklı erişim ihtiyaçları taşır. Regülasyon ve denetim ekipleri kim, ne zaman, hangi cihazda işlem yaptı sorusuna net yanıt ister. Bu nedenle out of band tasarım, sadece ağ erişim kolaylığı değil; iş sürekliliği ve denetlenebilirlik gereksinimidir. Sağlam bir yönetim düzleminin katmanları 1. Ayrı adresleme ve segmentasyon Yönetim ağı, üretim VLAN'larının uzantısı gibi ele alınmamalıdır. Kendi IP planı, yönlendirme politikası ve erişim kontrol listeleri olmalıdır. Özellikle omurga cihazlarının yönetim arayüzleri, doğrudan kullanıcı veya uygulama ağlarından erişilebilir olmamalıdır. 2. Güvenli giriş noktası Her yönetim bağlantısı doğrudan cihazlara açılmamalıdır. Kimlik federasyonu, MFA, oturum kaydı ve emir geçmişi tutan merkezi jump host yapısı operasyon kalitesini ciddi biçimde artırır. 3. Konsol kurtarma hattı SSH veya HTTPS erişimi kaybolduğunda seri konsol bağlantısı hayat kurtarır. Konsol sunucuları pahalı görünür; fakat hatalı bir core switch değişikliğinde saatlerce veri merkezi yolculuğunu önleyebilir. 4. Telemetry ve audit Yönetim ağında olup bitenler, üretim kadar görünür olmalıdır. Başarısız oturum açma, beklenmeyen cihaz erişimi, yapılandırma değişikliği ve firmware güncellemesi ayrı alarm sinyalleri üretmelidir. <Callout type=\"tip\" title=\"Yönetim ağı ayrıcalıklı ağdır\" Out of band segmenti daha güvenli varsaymak yaygın bir hatadır. Aslında bu katman en yüksek ayrıcalığı taşır; bu yüzden en sıkı kimlik ve kayıt politikası burada uygulanmalıdır. </Callout Sık yapılan tasarım hataları Birçok kurum out of band ağı kurduğunu düşünür; fakat aslında yalnızca farklı bir VLAN açmıştır. Şu yanlışlar sık görülür: Aynı firewall kural seti hem üretim hem yönetim erişimini taşıyordur. Jump host yoktur; cihazlara kullanıcı bilgisayarlarından doğrudan erişim verilir. Yönetim arayüzleri DNS veya sertifika bağımlılığı nedeniyle üretim servislerine muhtaç kalır. Loglar sadece cihaz üzerinde tutulur, merkezi denetim yapılmaz. Bu durumda ağ ayrımı görünürde vardır ama kriz anında bağımsızlık yoktur. Uygulanabilir mimari prensipler Sağlıklı başlangıç için şu sıra işe yarar: 1. Tüm kritik ağ ve sunucu ekipmanının yönetim arayüzlerini envanterleyin. 2. Yönetim IP planını üretim ağlarından ayrı tasarlayın. 3. Tüm erişimi MFA zorunlu merkezi jump host üzerinden geçirin. 4. Seri konsol erişimini en az çekirdek cihazlar için devreye alın. 5. Yönetim ağı erişim kayıtlarını SIEM ve observability hattına bağlayın. Bu yaklaşım, “ayrı kablo çekelim” seviyesinden çıkıp işletilebilir bir yönetim düzlemi üretir. Sunucu ve ERP altyapıları için özel dikkat noktaları Kurumsal ERP ortamlarında sorun sadece ağ cihazları değildir. Veritabanı cluster node'ları, sanallaştırma kümeleri, storage kontrolcüleri ve lisans bağımlı uygulama sunucuları da aynı kapsamda değerlendirilmelidir. Özellikle bakım penceresinde bir storage yönetim arabiriminin kaybedilmesi, uygulama kesintisini katlayarak büyütebilir. Bu yüzden out of band yaklaşımı sadece network ekibinin işi olarak değil, veri merkezi işletiminin ortak mimari standardı olarak ele almak gerekir. Sonuç Out of band yönetim düzlemi, normal zamanda görünmeyen ama kriz anında gerçek değerini ispatlayan bir mimari karardır. Ağ, sanallaştırma, sunucu ve güvenlik katmanlarını tek bir ayrıcalıklı erişim modeli altında birleştirdiğinizde hem müdahale süresi kısalır hem de denetim kalitesi yükselir. Kurumsal ölçekte güvenli ve dayanıklı altyapı tasarımının önemli bileşenlerinden biri budur.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "güvenlik",
        "sunucu",
        "altyapı",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-altyapida-ephemeral-yonetim-erisimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-altyapida-ephemeral-yonetim-erisimi",
      "title": "Kurumsal Altyapıda Ephemeral Yönetim Erişimi",
      "summary": "Kalıcı bastion ve paylaşılan hesap yükünü azaltmak için ephemeral yönetim erişimi tasarımını ele alır.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal altyapılarda yönetim erişimi yıllarca bastion sunucular, paylaşılan admin hesapları ve uzun ömürlü SSH anahtarları etrafında kuruldu. Bu model hâlâ yaygın olsa da tehdit yüzeyi gereksiz derecede büyüktür: kim hangi sunucuya ne zaman girdi, hangi ayrıcalıkla işlem yaptı, erişim süresi neydi gibi sorular çoğu zaman tam yanıtlanamaz. Ephemeral yönetim erişimi yaklaşımı, oturumu kalıcı ağ açıklığı yerine kısa ömürlü kimlik ve politika kararları üzerinden kurar. Ephemeral erişim ne demektir? Kullanıcıya veya otomasyona sadece belirli iş için, belirli süreyle ve belirli hedefler üzerinde geçerli olacak bir erişim bileti verilmesidir. Bu modelde: Kalıcı ortak parola veya anahtar paylaşılmaz Erişim kimlik sağlayıcı ve politika motoru üzerinden açılır Oturum bittiğinde yetki de kapanır Kayıt ve denetim izi oturumla birlikte oluşur Buradaki fark, erişimin ağ üzerinde sürekli açık olmaması ve kullanıcı tarafında uzun süre saklanan sırlarla taşınmamasıdır. Bastion neden artık yeterli değil? Bastion sunucular hâlâ bazı senaryolarda işe yarar, fakat kurumsal ölçekte şu sorunları üretir: 1. Tekil sıçrama noktası oluşturur 2. Oturum kayıtları parçalı kalabilir 3. Paylaşılan hesaplar nedeniyle bireysel iz sürme zayıflar 4. Anahtar döndürme ve erişim kaldırma süreçleri manuel hale gelir Özellikle hibrit bulut, Kubernetes düğümleri ve ERP çevresi Linux sunucular aynı erişim modeline bağlandığında bastion yönetimi başlı başına ayrı bir platform yüküne dönüşür. <Callout type=\"tip\" title=\"Ağ erişimi ile kimlik erişimini ayırın\" Hedef sistem görünürlüğünü kısıtlamak değerlidir, ancak asıl karar kullanıcıya hangi süreyle ve hangi bağlamda yetki verildiğinde yatmalıdır. </Callout Referans mimari Ephemeral yönetim erişimi genellikle şu bileşenlerle kurulur: Merkezi kimlik sağlayıcı Erişim brokerı veya access proxy Politika motoru Kısa ömürlü sertifika veya token üretimi Oturum kayıt ve denetim katmanı Kullanıcı güçlü kimlik doğrulama ile sisteme girer, rol ve bağlam bilgisine göre erişim talep eder, broker hedef sistem için kısa ömürlü kimlik üretir ve oturumu aracılık eder. Ağ seviyesinde hedefler genelde genel internete açılmaz; erişim brokerı kontrollü geçit görevi görür. Hangi alanlarda en hızlı faydayı sağlar? Bu model özellikle aşağıdaki ortamlarda etkili olur: Ayrıcalıklı Linux sunucu yönetimi Geçici incident müdahale erişimleri Üretim veritabanı bakım oturumları Tedarikçi veya dış ekip için süreli erişim ERP operasyon ekiplerinin sınırlı yönetim ihtiyaçları Kalıcı VPN hesabı açmak yerine iş emriyle ilişkilendirilen kısa ömürlü erişim verilmesi, denetlenebilirlik açısından çok daha nettir. Tasarımda atlanan kritik noktalar Ephemeral erişim sadece yeni bir araç kurmakla çözülmez. Şu sorular baştan net olmalıdır: Acil durum erişim yolu normal akıştan farklı mı olacak? Erişim kararı CMDB veya varlık kritiklik verisiyle besleniyor mu? Oturum kaydı veri koruma politikalarıyla uyumlu mu? Otomasyon hesapları için insan erişiminden farklı bir akış var mı? Bu ayrımlar yapılmazsa eski bastion pratiği yeni araçların içine taşınır. Uygulama sırası Sağlam geçiş için aşağıdaki sıra uygulanabilir: 1. Mevcut bastion ve admin erişim envanterini çıkarın 2. En riskli üretim erişimlerini kısa ömürlü modele taşıyın 3. Kalıcı SSH anahtarlarını kademeli kapatın 4. Oturum kayıtlarını SOC ve audit akışına bağlayın 5. Son olarak ağ erişim modelini sadeleştirin Bu sırayla gidildiğinde değişim sadece güvenlik politikası değil, operasyonel kolaylık da üretir. Sonuç Kurumsal altyapıda ephemeral yönetim erişimi, bastion'ı kaldırma projesinden daha geniş bir disiplindir. Amaç, yönetim erişimini ağ yakınlığına değil kimlik, bağlam ve süre sınırına dayandırmaktır. Kısa ömürlü erişim biletleri, merkezi denetim ve politika temelli karar mekanizması birlikte çalıştığında hem saldırı yüzeyi küçülür hem de operasyon ekipleri daha izlenebilir biçimde çalışır.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "guvenlik",
        "erisim-yonetimi",
        "zero-trust",
        "altyapi",
        "sunucu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-golden-path-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-platformlarda-golden-path-tasarimi",
      "title": "Kurumsal Platformlarda Golden Path Tasarımı",
      "summary": "Platform ekiplerinin hız ve standartlaşmayı birlikte üretmesi için golden path yaklaşımının mimari çerçevesi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kurumsal platformlarda golden path tasarimi diagram.svg'; Kurumsal yapılarda geliştirici deneyimi çoğu zaman tek bir araç seçimiyle değil, ekiplerin aynı işi tekrar tekrar nasıl çözdüğüyle belirlenir. Yeni servis açarken ağ tanımı, kimlik, CI/CD, loglama, secret yönetimi ve temel güvenlik politikaları her ekip tarafından yeniden tasarlanıyorsa, kurum aslında platform değil sabır tüketir. Golden path yaklaşımı, ekipleri zorlayan rastgele özgürlük yerine güvenli varsayılanlar sunar. <figure <Image src={diagram} alt=\"Golden path akışı, platform servisleri ve ekip teslimat yolunu gösteren teknik şema\" / <figcaption Platform ekibinin ortak servisleri ürün ekiplerine yönlendiren, kontrollü ama hız odaklı teslimat yolu.</figcaption </figure Golden path tam olarak nedir? Golden path, ürün ekiplerine \"tek doğru yol\" dayatmak değildir. Asıl amaç, en sık ihtiyaç duyulan servis yaşam döngüsünü önceden tasarlanmış, belgelenmiş ve otomatikleştirilmiş bir teslimat hattı hâline getirmektir. Bu hattın tipik özellikleri şunlardır: Hazır repo veya servis şablonu Standart CI/CD boru hattı Varsayılan güvenlik ve secret politikaları Gözlemlenebilirlik entegrasyonları Self service altyapı talebi Eğer ekiplerin çoğu bu yoldan geçebiliyorsa, platform doğru yerde değer üretiyor demektir. Neden kurumsal ortamlarda kritik? Kurumsal teknoloji mimarilerinde asıl sorun araç eksikliği değil, karar tutarsızlığıdır. Aynı kurum içinde beş ekip beş farklı deployment akışı, üç farklı log standardı ve dört farklı erişim modeli kurduğunda toplam sahip olma maliyeti görünmez biçimde yükselir. Golden path yaklaşımı şunu hedefler: ekiplerin farklı ürünler geliştirmesi normaldir, ama her ürünün temel operasyon omurgasını sıfırdan kurması gerekmez. Böylece platform ekibi özgürlüğü değil, tekrar eden mühendislik yükünü merkezîleştirir. İyi bir golden path hangi sınırlarla tanımlanmalı? Başarılı örneklerde yolun başlangıcı kadar çıkış noktası da nettir. Her servis golden path’e girmek zorunda olmayabilir. Ancak şu üç konu açık olmalıdır: 1. Bu yol hangi iş yükleri için uygundur? 2. Varsayılan olarak hangi güvenlik ve operasyon standartlarını getirir? 3. Bu yoldan çıkmak isteyen ekip hangi ek sorumlulukları üstlenir? Bu ayrım yapılmadığında platform ekibi \"hayır diyen ekip\" gibi görünür. Oysa iyi tasarımda golden path, istisnaları azaltır ama gerektiğinde bilinçli çıkışa da izin verir. <Callout type=\"tip\" title=\"Platform disiplini\" Golden path yalnızca belgede tanımlanırsa kısa sürede unutulur. Değer üretmesi için servis şablonları, pipeline’lar ve politika kontrolleri gerçekten çalışır durumda olmalıdır. </Callout Hangi katmanlar öncelikle standardize edilmeli? İlk yatırımın en yüksek geri dönüş sağladığı alanlar genellikle şunlardır: Kimlik ve secret yönetimi CI/CD ve release onay akışları Log, metric ve trace etiket standardı Ağ erişim kalıpları Ortam bazlı yapılandırma ve policy guardrail’leri Bu alanlar çözülmeden yalnızca \"template repo\" vermek, platform deneyimi üretmez. Ölçümlemeden başarı anlaşılır mı? Golden path’i \"ekipler sevdi\" düzeyinde değerlendirmek zayıf kalır. Daha anlamlı sinyaller şunlardır: Yeni servis açılış süresi İlk production deploy’a kadar geçen süre İstisna isteklerinin oranı Ortak güvenlik politikalarına uyum oranı Incident’larda standart dışı yapıdan kaynaklanan hata sayısı Bu metrikler, platformun gerçekten sürtünmeyi azaltıp azaltmadığını net gösterir. Platform ekibinin sık düştüğü tuzak Bazı ekipler golden path’i çok esnek tasarlayıp değersizleştirir; bazıları ise o kadar katı kurar ki ürün ekipleri etrafından dolaşır. Doğru denge, sık kullanılan yolun güçlü varsayılanlar sunması ve nadir ihtiyaçlar için kontrollü istisna mekanizması bırakmasıdır. Sonuç Kurumsal platformlarda golden path tasarımı, geliştirici deneyimi başlığı altında pazarlanan bir kolaylık katmanı değildir. Asıl etkisi, güvenlik, gözlemlenebilirlik ve teslimat kalitesini tekrar eden karar yükünden çıkarıp varsayılan davranışa dönüştürmesidir. Platform ekibi hız ile standardı aynı anda üretmek istiyorsa, işe tam burada başlamalıdır.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "platform-engineering",
        "devops",
        "automation",
        "cloud",
        "architecture"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-siem-icin-telemetry-sampling-stratejisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-siem-icin-telemetry-sampling-stratejisi",
      "title": "Kurumsal SIEM için Telemetry Sampling Stratejisi",
      "summary": "Güvenlik görünürlüğünü kaybetmeden log hacmini kontrol altında tutmak için telemetry sampling tasarım prensipleri.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ortamlarda SIEM maliyeti çoğu zaman lisans kaleminden değil, kontrolsüz büyüyen telemetry akışından patlar. Uygulamalar, altyapı servisleri, güvenlik duvarları, uç cihazlar ve bulut servisleri aynı havuza ölçüsüz veri akıttığında iki sorun aynı anda doğar: kritik olayların bulunması zorlaşır ve operasyon ekibi gereksiz veriyi taşımak için sürekli bütçe savunur. Sampling stratejisi bu yüzden yalnızca maliyet düşürme tekniği değildir; güvenlik görünürlüğünü koruyan mimari karardır. Sampling neden yanlış anlaşılıyor? Sampling çoğu ekipte \"daha az log gönder\" şeklinde ele alınır. Bu yaklaşım tehlikelidir, çünkü hangi olayların güvenlik, hangi olayların operasyon, hangi olayların adli analiz için gerekli olduğu sınıflandırılmaz. Sonuçta ya kritik veri kaybolur ya da gerçekten işe yaramayan veri tutulmaya devam eder. Doğru yaklaşım, telemetry akışını önce sınıflandırmaktır: Güvenlik açısından zorunlu olaylar Operasyonel hata ve kapasite olayları Yüksek hacimli ama düşük değerli debug veya access olayları Yasal saklama gerektiren kayıtlar Bu ayrım yapılmadan sampling kararı almak, veri mimarisini körleştirmek anlamına gelir. Hangi veriler asla örneklenmemeli? Her veri seti aynı değerde değildir. Aşağıdaki sinyaller genellikle tam saklama gerektirir: 1. Kimlik doğrulama ve yetkilendirme olayları 2. Ayrıcalıklı erişim yükseltmeleri 3. Politika ihlali ve reddedilen erişim kayıtları 4. Kritik altyapı değişiklikleri 5. Üretim ERP veya finans sistemlerindeki yönetimsel işlemler Özellikle başarısız girişler, rol değişiklikleri ve güvenlik politikası kararları daha sonra olay korelasyonunda temel veri olur. Bunları örneklemek, olay inceleme zincirini kırar. Nerede agresif sampling yapılabilir? En büyük hacim genelde access log, health check ve tekrar eden başarı kayıtlarından gelir. Burada bağlamsal sampling uygulanabilir: Sağlıklı servislerden gelen 200 erişim loglarının yüzde 1 ila 5'i tutulur Aynı kullanıcı aracısından gelen tekrarlı probe istekleri gruplanır Kubernetes readiness veya liveness çağrıları ayrı hatta yönlendirilir CDN veya WAF üzerinde zaten tutulan veriler uygulama katmanında tekrar saklanmaz Bu yöntemde amaç veri kaybetmek değil, aynı bilginin çok sayıda kopyasını azaltmaktır. <Callout type=\"tip\" title=\"Sampling kararı katman bazlı olmalı\" Kenar katmanda örneklenebilen veri, güvenlik katmanında tam saklanmak zorunda olabilir. Aynı kuralı tüm kaynaklara uygulamayın. </Callout Mimari karar noktaları Kurumsal SIEM sampling stratejisi oluştururken dört tasarım sorusu kritik hale gelir. 1. Karar ingestion öncesinde mi, sonrasında mı verilecek? Ingestion öncesi sampling maliyet avantajı sağlar ama yanlış karar geri alınamaz. Ingestion sonrası karar daha esnektir fakat ham veri katmanı için ek depolama ister. Yüksek regülasyonlu yapılarda kısa süreli ham veri tamponu çoğu zaman daha güvenlidir. 2. Kural kaynağı kim olacak? Sampling kuralları sadece SOC ekibinin kararıyla yönetilmemelidir. Ağ, platform, uygulama ve uyumluluk tarafı ortak karar vermezse kritik kullanım durumları atlanır. 3. Olay önceliği nasıl kodlanacak? Kaynaklar critical, important, routine gibi bir telemetri öncelik alanı üretirse yönlendirme ve saklama politikaları sadeleşir. 4. Geri besleme nasıl toplanacak? SOC analistlerinin en sık aradığı ama bulamadığı olay tipleri düzenli raporlanmazsa sampling politikası giderek körleşir. Uygulanabilir bir referans model Sahada iyi çalışan model genellikle üç katmanlıdır: hot: Kimlik, güvenlik kontrolü ve olay müdahalesi için gereken veri. Tam saklama. warm: Operasyon ve kapasite analizleri için gereken veri. Seçici sampling. cold: Ham veya regülasyon amaçlı arşiv. Ucuz depolama, yavaş erişim. Bu modelde telemetry üreticisi değil, merkezi pipeline hangi verinin nereye gideceğini belirler. Böylece uygulama ekipleri her servis için farklı log politikası yazmak zorunda kalmaz. ERP ve kurumsal çekirdek sistemler için özel durum ERP tarafında düşük hacimli ama yüksek etkili olaylar bulunur. Yetki atamaları, batch job tetiklemeleri, kritik tablo export işlemleri veya entegrasyon kullanıcılarının beklenmeyen erişimleri mutlaka tam saklanmalıdır. Burada sampling yapılacak alanlar genelde teknik başarı loglarıdır; iş etkisi yüksek kayıtlar değil. Bu ayrımı yapabilmek için iş akışını bilen mimarlar ile güvenlik ekiplerinin aynı tablo üzerinde çalışması gerekir. Aksi halde ERP telemetry'si ya gereğinden fazla tutulur ya da en önemli olaylar sadeleştirme sırasında kaybolur. Sonuç Kurumsal SIEM için sampling stratejisi, log azaltma projesi değil görünürlük tasarımıdır. Hangi sinyalin olay müdahalesi, hangi sinyalin kapasite yönetimi, hangi sinyalin yalnızca arşiv değeri taşıdığı netleştirildiğinde hem maliyet hem analist verimliliği iyileşir. En doğru başlangıç noktası, \"hangi logları keselim\" sorusu değil, \"hangi kararları bu veriye dayanarak veriyoruz\" sorusudur.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "siem",
        "observability",
        "guvenlik",
        "telemetry",
        "mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/yedekleme-altyapisinda-izole-kurtarma-bolgesi",
      "url": "https://mustafaerbay.com.tr/blog/technology/yedekleme-altyapisinda-izole-kurtarma-bolgesi",
      "title": "Yedekleme Altyapısında İzole Kurtarma Bölgesi",
      "summary": "Yedekleri yalnızca saklamakla kalmayıp fidye yazılımı ve yönetim hatalarına karşı izole geri dönüş alanı kurma yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Yedekleme stratejilerinde sık görülen yanılgı, kopya sayısı arttıkça kurtarma güveninin de otomatik arttığını varsaymaktır. Oysa fidye yazılımı, yanlış yetkilendirme veya hatalı otomasyon senaryolarında asıl kritik soru şudur: geri döneceğiniz alan gerçekten üretimden ve yönetim zincirinden yeterince izole mi? İzole kurtarma bölgesi, yedekleme mimarisini yalnızca depolama problemi olmaktan çıkarıp güvenilir geri dönüş senaryosuna dönüştürür. Neden sadece immutable yedek yetmez? Immutable snapshot veya WORM depolama çok değerlidir; ancak tek başına yeterli değildir. Çünkü geri dönüş sırasında şu riskler devam eder: Aynı kimlik alanı saldırıya uğramış olabilir Yönetim ağı güvenilir olmayabilir Geri dönüş otomasyonu hatalı veya manipüle edilmiş olabilir Kurtarma ortamı hiç test edilmemiş olabilir İzole kurtarma bölgesi, bu riskleri azaltmak için yönetim ve erişim sınırlarını ayrıştırır. Temel mimari yaklaşım Sağlıklı modelde üç ayrı alan tanımlanır: 1. Üretim alanı : çalışan iş yükleri 2. Yedekleme alanı : korumalı kopyaların tutulduğu katman 3. Kurtarma alanı : gerektiğinde kontrollü biçimde ayağa kaldırılan izole bölge Bu alanlar aynı fiziksel kurum içinde olabilir; ancak ağ, kimlik, yönetim hesabı ve erişim süreçleri mümkün olduğunca ayrıştırılmalıdır. Hangi ayrımlar kritik? Ayrı yönetim hesabı veya tenant Üretimden farklı erişim anahtarları ve MFA politikası Sınırlı yönlü ağ akışı Kurtarma sırasında geçici ve kaydedilen erişim modeli Test için temiz veri örnekleri veya maskeleme yaklaşımı <Callout type=\"warning\" title=\"Sık yapılan hata\" Yedekleme yazılımının yönetim konsolunu üretim ile aynı ayrıcalıklı hesaplara bağlamak, saldırı anında tüm savunma hattını anlamsız hale getirebilir. </Callout ERP ve kurumsal verilerde neden daha da önemli? ERP, finans ve operasyon verileri yalnızca teknik değil iş sürekliliği açısından da kritik olduğu için, geri dönüşte şu beklentiler oluşur: Doğru zaman noktasına dönülebilmeli Veri bütünlüğü doğrulanabilmeli Bağımlı servisler birlikte ayağa kalkabilmeli Test ve gerçek kurtarma yolları benzer olmalı İzole kurtarma bölgesi bu beklentilere cevap vermek için sadece yedeği okumaz; kontrollü bir yeniden başlatma alanı sunar. Neyi düzenli test etmek gerekir? Bir kurtarma bölgesinin değeri kağıt üzerindeki mimarisinden değil, tekrar eden denemelerden gelir. Özellikle şu senaryolar periyodik olarak çalıştırılmalıdır: Ayrı kimlikle sisteme erişim Son sağlam kurtarma noktasından açılış Ağ segmenti ve DNS davranışı Uygulama ile veri katmanı tutarlılığı İş birimlerinin kabul ettiği minimum operasyon seviyesi Bu testler yoksa “yedek var” ifadesi gerçek geri dönüş garantisi vermez. Sonuç Yedekleme altyapısında izole kurtarma bölgesi, kurumsal dayanıklılığın çoğu zaman eksik bırakılan parçasıdır. Yedeklerin değiştirilemez olması kadar; onları güvenli, ayrı ve test edilmiş bir alanda geri yükleyebilmek de kritik önemdedir. Özellikle fidye yazılımı riski, ERP bağımlılığı ve sıkı denetim gereksinimi olan yapılarda kurtarma bölgesini ayrı mimari katman olarak tasarlamak gerekir.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "backup",
        "security",
        "sunucu-altyapısı",
        "felaket-kurtarma",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/ansible-ile-sunucu-konfigurasyon-drift-tespiti",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/ansible-ile-sunucu-konfigurasyon-drift-tespiti",
      "title": "Ansible ile Sunucu Konfigürasyon Drift Tespiti",
      "summary": "Linux sunucularda beklenen durumdan sapmaları ölçmek ve raporlamak için Ansible tabanlı drift denetimi rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Sunucu standartlarını kodla tanımlamak tek başına yeterli değildir; canlı sistemlerin gerçekten o tanıma uyup uymadığını da düzenli kontrol etmek gerekir. Drift tespiti, özellikle manuel müdahale, acil düzeltme veya unutulmuş paket değişiklikleri nedeniyle oluşan farkları görünür kılar. Ansible bu iş için yalnızca dağıtım aracı değil, aynı zamanda denetim aracı olarak da oldukça etkilidir. Drift tam olarak nedir? Bir sunucunun beklenen durumdan sapmasıdır. Bu sapma şu alanlarda görülebilir: Kurulu paket listesi Konfigürasyon dosyası içeriği Çalışan servis durumu Açık port ve dinleyen süreçler Yetkili kullanıcı veya grup üyelikleri Bu farklar küçük görünse de güvenlik, operasyon ve denetlenebilirlik tarafında ciddi sorun üretir. Yaklaşım: uygulamak yerine önce gözlemlemek İlk aşamada hedef, drift'i otomatik düzeltmek değil görünür kılmaktır. Bunun için check modu, changed when, failed when ve özel doğrulama görevleri birlikte kullanılabilir. Basit bir örnek: Bu model, canlı sunucuyu değiştirmeden farkı görmenizi sağlar. En yararlı denetim alanları Başlangıç için şu kontrol setleri yüksek değer üretir: 1. Paket ve repo standardı 2. SSH ve temel sertleştirme ayarları 3. Güvenlik ajanlarının çalışıyor olması 4. Zaman senkronizasyonu ve log iletimi 5. Yetkili kullanıcı listesi Özellikle yönetim erişimi olan sunucularda bu alanlar hızlı güvenlik geri bildirimi verir. <Callout type=\"tip\" title=\"Düzeltmeden önce sınıflandırın\" Her drift aynı önemde değildir. Güvenlik, operasyon ve kabul edilebilir istisna olarak sınıflandırırsanız otomasyon daha az gürültü üretir. </Callout Örnek raporlama yaklaşımı Ansible çalışmasının çıktısını sadece terminalde bırakmak yerine JSON veya Markdown rapora dönüştürmek daha kullanışlıdır. Basit yaklaşım şöyledir: Envanteri takım veya ortam bazında gruplayın Her denetim için register çıktısı toplayın Sonuçları tek rapor dosyasında derleyin Kritik sapmaları CI veya cron üzerinden bildirin Bu sayede drift tespiti tek seferlik deneme değil, sürekli kontrol haline gelir. Ne zaman otomatik düzeltme eklenmeli? Önce gözlemleyin, sonra desenleri anlayın. Eğer aynı sapmalar tekrar ediyorsa iki soru sorun: Bu sapma gerçekten istenmeyen bir manuel müdahale mi? Yoksa standart tanım güncel değil mi? Cevap netleşmeden otomatik düzeltme eklemek yanlış pozitifi büyütebilir. Sağlıklı sıra; görünürlük, sınıflandırma, onaylı düzeltme ve en son tam otomasyondur. Sonuç Ansible ile sunucu konfigürasyon drift tespiti, altyapı standardını yaşayan bir kontrole dönüştürür. Özellikle Linux sunucular, bastion sistemleri ve kurumsal servis düğümleri için düzenli drift denetimi; güvenlik açıklarını, belge dışı değişiklikleri ve operasyon riskini erken aşamada görünür hale getirir. Değişikliği yalnızca uygulamak değil, sapmayı sürekli ölçmek de altyapı disiplininin parçasıdır.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "ansible",
        "linux",
        "devops",
        "otomasyon",
        "sunucu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/ansible-ile-sunucu-sertlestirme-baselinei",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/ansible-ile-sunucu-sertlestirme-baselinei",
      "title": "Ansible ile Sunucu Sertleştirme Baseline'ı",
      "summary": "Linux sunucularda güvenlik baseline'ını Ansible ile tekrarlanabilir ve denetlenebilir hâle getirme rehberi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './ansible ile sunucu sertlestirme baselinei diagram.svg'; Sunucu güvenliğinde en yorucu noktalardan biri, iyi bildiğiniz kontrolleri her yeni sunucuda yeniden uygulamak zorunda kalmaktır. SSH ayarı, gereksiz servislerin kapatılması, auditd, zaman senkronizasyonu, journald sınırları ve temel firewall politikaları çoğu kurumda bilinir; ancak bilgi ile uygulanabilir standart aynı şey değildir. Ansible ile sertleştirme baseline'ı kurmak, güvenliği tek seferlik kontrol listesinden çıkarıp sürdürülebilir operasyon pratiğine dönüştürür. <figure <Image src={diagram} alt=\"Ansible playbook akışı ve Linux sunucu güvenlik kontrollerini gösteren teknik şema\" / <figcaption Kontrolleri yaşayan sunucuda elle yapmak yerine, aynı baseline'ı playbook ile tekrar üretmek.</figcaption </figure Baseline neden önemlidir? Birçok ekipte güvenlik sertleştirmesi \"kurulumdan sonra bakarız\" başlığı altında kalır. Bu durumda iki problem ortaya çıkar: Yeni sunucular arasında fark oluşur. Hangi kontrolün gerçekten uygulandığı net takip edilemez. Baseline yaklaşımı, minimum kabul edilen güvenlik standardını kodla tanımlar. Böylece sunucu değişse bile standart değişmez. Başlangıçta hangi kontrolleri seçmeli? Aşırı uzun bir ilk listeyle başlamak yerine, hem etkili hem de güvenli değişiklikler seçmek daha doğrudur. Benim çoğu Linux altyapısında ilk eklediğim kontroller şunlardır: 1. SSH için parola ile girişin kapatılması 2. Root login'in sınırlandırılması 3. Gereksiz ağ servislerinin kaldırılması 4. UFW veya nftables üzerinden temel inbound politika 5. auditd, chrony ve log rotasyonunun doğrulanması Bu kontroller kurumun gereksinimine göre genişletilebilir; ama ilk adımda hızlı kazanım üretir. Rol yapısını nasıl kurmalı? Tek bir dev playbook kısa vadede kolay görünür; uzun vadede bakımı zorlaştırır. Bunun yerine baseline'ı küçük ve anlaşılır rollere bölmek daha sağlıklıdır: common packages ssh hardening audit and logging firewall compliance facts Bu yapı sayesinde hangi katmanın sorun çıkardığını anlamak ve kontrollü genişlemek kolaylaşır. <Callout type=\"tip\" title=\"Önce görünürlük, sonra zorlama\" İlk geçişte tüm kontrolleri anında zorunlu kılmak yerine, bazı adımları yalnızca raporlayarak başlatmak üretim riski açısından daha güvenlidir. </Callout Idempotent tasarım neden kritik? Ansible ile güvenlik yönetirken en önemli prensiplerden biri, playbook'un her çalıştığında aynı sonucu güvenle üretmesidir. Eğer aynı görev ikinci çalıştırmada gereksiz değişiklik yapıyorsa, iki sorun doğar: güven azalır ve operasyon ekibi otomasyonu düzenli çalıştırmaktan kaçınır. Bu nedenle görevler mümkün olduğunca şu özellikleri taşımalıdır: Dosya içerikleri açık şekilde tanımlanmalı Servis restart koşulları kontrollü olmalı Dağıtım ortamı bazında istisnalar değişkenlerle yönetilmeli Her kontrol için doğrulama çıktısı üretilmeli Compliance görünürlüğü nasıl sağlanır? Sunucu sertleştirmesinin en zayıf noktası, uygulandıktan sonra unutulmasıdır. Bunu engellemek için her çalıştırmadan sonra asgari bir uyum çıktısı üretmek gerekir. Örneğin: Hangi hostlar başarılı geçti? Hangi hostlarda drift tespit edildi? Hangi kontrol istisna nedeniyle atlandı? Son çalıştırma ne zaman yapıldı? Bu veriler CI/CD, AWX veya merkezi log sistemiyle ilişkilendirildiğinde baseline yaşayan bir kontrol mekanizmasına dönüşür. Üretim ortamında dikkat edilmesi gerekenler SSH sertleştirme gibi kritik ayarlar için kademeli yayılım önemlidir. Tüm host grubuna aynı anda uygulama yapmak yerine: 1. Pilot host grubunda çalıştırın. 2. Doğrulama komutlarını otomatik ekleyin. 3. Değişiklik sonrası erişim testini zorunlu kılın. 4. Başarılı ise kalan gruplara yayın. Bu akış, güvenliği artırırken erişim kaybı riskini düşürür. Sonuç Ansible ile sunucu sertleştirme baseline'ı oluşturmak, güvenlik ekibinin beklentilerini operasyon gerçekliğiyle buluşturur. Standart bir minimum seviye tanımladığınızda, güvenlik yalnızca denetim gününde hatırlanan bir kontrol listesi olmaktan çıkar. Sunucular çoğaldıkça değeri artan şey tek tek müdahaleler değil, güvenilir ve tekrar edilebilir baseline olur.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "ansible",
        "linux",
        "security",
        "automation",
        "servers"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/argo-cd-image-updater-ile-guvenli-surum-terfisi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/argo-cd-image-updater-ile-guvenli-surum-terfisi",
      "title": "Argo CD Image Updater ile Güvenli Sürüm Terfisi",
      "summary": "Container sürümlerini kontrolsüz otomasyona bırakmadan GitOps hattında güvenli terfi modelini kurma rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; GitOps kullanan ekiplerde en tartışmalı konulardan biri image sürümlerinin nasıl terfi ettirileceğidir. Tam manuel model yavaş kalır; tamamen serbest otomasyon ise istenmeyen image etiketlerini üretime taşıyabilir. Argo CD Image Updater, bu dengeyi daha kontrollü kurmak için iyi bir araçtır. Ancak gerçek değer, aracı kurmakta değil; hangi image'ın, hangi koşulda, hangi ortama otomatik terfi edeceğini açık biçimde tanımlamaktadır. Neden doğrudan latest etiketi tehlikelidir? Birçok ekip başlangıçta işleri kolaylaştırmak için latest veya düzensiz semver etiketleriyle ilerler. Bu yaklaşım kısa sürede şu sorunları doğurur: Hangi image'ın ne zaman terfi ettiği izlenemez. Geri dönüş için güvenilir sürüm noktası kalmaz. Testten geçmeyen bir image üretime taşınabilir. Farklı ortamlar arasında sürüm farkı açıklanamaz hâle gelir. GitOps modelinde image terfisi, deployment manifest güncellemesi kadar denetlenebilir olmalıdır. Güvenli modelin temel prensipleri Sağlıklı bir kurulum için şu kurallar net olmalıdır: Image seçimi belirli etiket kalıbına göre yapılmalı Üretim dışı ve üretim ortamı farklı terfi politikasına sahip olmalı Registry, imza veya provenance kontrolleri opsiyon değil standart olmalı Güncellenen manifest Git geçmişinde açıkça izlenmeli Image Updater bu süreci otomatikleştirebilir; ama politika sizden gelir. Başlangıç için örnek akış 1. Registry tarafında düzenli semver veya onaylı etiket standardı belirleyin. 2. Argo CD uygulamasını image annotation'ları ile eşleyin. 3. Üretim dışı ortamda otomatik patch stratejisini etkinleştirin. 4. Üretim ortamında terfiyi onaylı PR veya belirli kanal üzerinden ilerletin. 5. Geri dönüş için önceki image bilgisini açık tutun. Bu akış, hem hız hem de denetim sağlar. <Callout type=\"tip\" title=\"Ortam politikalarını ayırın\" Geliştirme ortamında çalışan otomasyonun aynısını üretime kopyalamak kolaydır ama yanlıştır. Üretim için onay, imza ve geri dönüş kuralları daha sıkı olmalıdır. </Callout Hangi kontroller eklenmeli? Olgun ekiplerde image terfisi sadece sürüm kontrolü değildir. Şu kontroller ciddi fark yaratır: Image imza doğrulaması Kritik CVE eşiği üstündeki image'ların engellenmesi Belirli branch veya release hattından üretilmeyen image'ların reddi Deployment öncesi smoke test veya policy gate Bu kapılar kurulmadan yapılan tam otomasyon, sadece hızlı risk üretir. Operasyonel dikkat noktaları Registry rate limit sorunlarını görünür izleyin. Çoklu cluster yapısında aynı updater davranışını standardize edin. Git deposunda otomatik commit mesajlarını anlamlı tutun. Image seçim kuralını uygulama bazında belgeleyin. Amaç yalnızca “yeni sürüm gelsin” değil; değişiklik akışı güvenle açıklanabilsin olmalıdır. Sonuç Argo CD Image Updater ile güvenli sürüm terfisi, GitOps ortamlarında hız ile kontrol arasında sağlıklı denge kurmanın etkili yollarından biridir. Etiket disiplini, ortam bazlı politika ayrımı ve güvenlik kapılarıyla desteklendiğinde, image otomasyonu üretim riskini artırmadan teslim hızını yükseltebilir.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "gitops",
        "argocd",
        "kubernetes",
        "otomasyon",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/cilium-ile-kubernetes-ag-politikalarini-asamali-sikilastirma",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/cilium-ile-kubernetes-ag-politikalarini-asamali-sikilastirma",
      "title": "Cilium ile Kubernetes Ağ Politikalarını Aşamalı Sıkılaştırma",
      "summary": "Üretimi bozmadan Kubernetes ortamlarında ağ politikasını görünürlükten zorunlu kontrole taşıma rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kubernetes ortamlarında ağ politikası uygulamak herkesin kabul ettiği doğru yaklaşımdır; ama birçok ekip üretimde kırılma yaratmaktan çekindiği için bu işi sürekli erteler. Sonuçta cluster büyür, servisler çoğalır ve doğu batı trafik görünmez bir serbest alana dönüşür. Cilium, gözlemlenebilirlik ve politika uygulamayı aynı zeminde birleştirdiği için bu geçişi daha kontrollü hâle getirir. Doğru sıra izlendiğinde, “her şeyi bir gecede kapatmak” yerine adım adım sıkılaştırma mümkündür. Neden aşamalı yaklaşım şart? Cluster üzerinde hangi pod'un hangi servise konuştuğu net bilinmeden doğrudan deny mantığına geçmek, özellikle eski servislerde üretim hatası doğurur. Bu yüzden ilk amaç “engellemek” değil, mevcut davranışı görünür kılmaktır. Sağlıklı geçiş üç evrede düşünülür: 1. Trafiği ve bağımlılıkları gözlemleme 2. Namespace veya uygulama bazında izin modelini tanımlama 3. Kademeli olarak zorunlu politika moduna geçme Bu sıra, güvenlik ile operasyon arasında gereksiz çatışmayı azaltır. Başlangıç envanteri nasıl çıkarılır? Önce hangi servislerin gerçekten birbirine ihtiyaç duyduğunu anlamalısınız. Bu aşamada: ingress ve egress yönlerini ayırın DNS, metrics, tracing, secret yönetimi gibi ortak servisleri not alın batch işleri ve cron workload'larını ayrı değerlendirin geçici debug pod'larının politikasız davranmasını engelleyin Cilium Hubble veya eşdeğer görünürlük araçları, tam bu noktada değer üretir. Amaç sadece bağlantı sayısı görmek değil, uygulama sahipliğini de anlamaktır. Politika yazımında hangi prensipler işe yarar? İlk kural setini en dar etki alanında başlatmak doğrudur. Örneğin tek bir namespace veya tek bir uygulama etrafında başlayın. Politika yazarken şu yaklaşım işleri kolaylaştırır: Ortak platform servisleri için ayrı politika grubu oluşturun. Uygulama içi trafik ile namespace dışı trafiği ayrı tanımlayın. DNS ve observability bağımlılıklarını açıkça izin listesine koyun. matchLabels kullanımında ekip standardını koruyun. <Callout type=\"tip\" title=\"Ortak servisleri unutmayın\" İlk kırılmalar çoğu zaman uygulama trafiğinde değil; DNS, telemetry agent veya secret çözümleme bağımlılıklarında ortaya çıkar. Politika geçişini bunları modellemeden tamamlamaya çalışmayın. </Callout Kademeli zorlama nasıl yapılır? Pratikte şu akış güvenli sonuç verir: 1. Seçili namespace'lerde sadece görünürlük toplayın. 2. Tavsiye edilen politika setini oluşturun. 3. Düşük riskli servislerde kuralı etkinleştirin. 4. Olay ve drop kayıtlarını gözleyin. 5. Üretim kritik namespace'lere kontrollü geçiş yapın. Bu modelde geri dönüş yolu nettir ve değişiklik pencereleri daha yönetilebilir olur. Dikkat edilmesi gereken operasyonel noktalar Uygulama etiketleri dağınıksa politika sürdürülemez. Namespace sınırları yanlış tasarlandıysa politika sayısı patlar. Politika ihlallerini sadece güvenlik ekibi değil platform ekibi de izlemelidir. GitOps hattına bağlanmayan ağ politikaları kısa sürede manuel istisna deposuna döner. Kısacası konu yalnızca YAML yazmak değildir; cluster sözleşmesini disipline etmektir. Sonuç Cilium ile ağ politikası sıkılaştırması, Kubernetes güvenliğini teoriden pratiğe taşıyan güçlü bir adımdır. Başarının anahtarı agresif başlangıç değil, görünürlükten zorunlu kontrole giden aşamalı bir yol izlemektir. Servis bağımlılıklarını doğru modellediğinizde hem güvenlik seviyesini yükseltir hem de üretim riskini yönetilebilir tutarsınız.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "kubernetes",
        "cilium",
        "network",
        "güvenlik",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/falco-ile-calisma-zamani-guvenlik-gozlemi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/falco-ile-calisma-zamani-guvenlik-gozlemi",
      "title": "Falco ile Çalışma Zamanı Güvenlik Gözlemi",
      "summary": "Linux ve Kubernetes ortamlarında şüpheli çalışma zamanı davranışlarını görünür kılmak için Falco tabanlı kurulum rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Sunucu veya Kubernetes güvenliğinde birçok ekip yalnızca erişim kontrolüne ve imaj taramasına odaklanır. Bunlar gereklidir; fakat saldırı veya kötüye kullanım çalışma zamanında gerçekleşir. Beklenmeyen kabuk açılması, ayrıcalıklı süreç, hassas dosya erişimi veya konteyner içinden şüpheli ağ davranışı ancak o anda görünür hale gelirse operasyon anlamlı tepki verebilir. Falco, tam bu noktada çalışma zamanı güvenlik sinyali üretmek için güçlü bir araçtır. Falco neyi izler? Falco, sistem çağrıları ve çalışma zamanı olayları üzerinden şu tip davranışları tespit etmeye yardımcı olur: Beklenmeyen shell çalıştırma Yetkisiz dosya okuma veya yazma Ayrıcalıklı container kullanımı Host namespace erişimi Şüpheli ağ bağlantıları Amaç, antivirüs benzeri imza avcılığı değil; normalden sapan operasyonel güvenlik davranışını görünür kılmaktır. Nerede konumlandırılır? Falco iki yaygın senaryoda değer üretir: 1. Linux sunucularda doğrudan host seviyesinde 2. Kubernetes kümelerinde DaemonSet olarak Kubernetes tarafında her node üzerinde sensör çalıştırarak konteyner davranışını merkezi kural setiyle izleyebilirsiniz. Örnek Helm kurulumu: Kurulum kadar önemli olan nokta, kuralların ortamınıza göre ayarlanmasıdır. İlk günden hangi kurallar değerlidir? Başlangıç için yüksek sinyal üreten birkaç sınıf şunlardır: Üretim konteynerinde shell açılması Hassas dizinlere yazma denemesi Ayrıcalıklı container veya hostPath kullanımı Paket yöneticisi çalıştırılması Yönetim ağlarına beklenmeyen çıkış Bu kurallar doğrudan olay müdahalesi başlatmasa bile güvenlik görünürlüğünü ciddi biçimde artırır. <Callout type=\"tip\" title=\"Önce sinyal kalitesi\" Falco'yu başarılı kullanan ekipler önce az sayıda yüksek değerli kural ile başlar. Gürültülü kurulum, çalışma zamanı güvenliğini hızla göz ardı edilen bir panele dönüştürür. </Callout Uyarılar nereye akmalı? Falco çıktısını yalnızca pod loglarında bırakmak yetersizdir. Daha iyi model şöyledir: Falco olayları merkezi log hattına gönderilir Kritik olaylar Alertmanager veya olay yönetim sistemine yönlendirilir Kural isabetleri dashboard üzerinde ekip ve ortam bazında izlenir Gerekirse olay kaydı, SIEM veya ticket sistemine aktarılır Böylece Falco tek başına çalışan bir sensör değil, observability ve incident sürecinin parçası olur. Yanlış pozitifleri nasıl azaltırsınız? Çalışma zamanı güvenlik araçlarında en kritik konu bağlamdır. Gürültüyü azaltmak için: Ortam bazlı istisnaları açık tanımlayın Geliştirme ve üretim kurallarını ayırın Beklenen bakım pencereleri için sessizleştirme ekleyin Container imajı, namespace ve servis sahipliği etiketlerini kullanın Bu yaklaşım, güvenlik sinyalini operasyonel olarak tüketilebilir kılar. Sonuç Falco ile çalışma zamanı güvenlik gözlemi, sistemlerin yalnızca nasıl kurulduğunu değil çalışma anında nasıl davrandığını da izlenebilir hale getirir. Özellikle Linux sunucular, Kubernetes platformları ve yüksek yetkili servisler için Falco; güvenlik ile observability arasındaki boşluğu kapatan pratik bir katmandır. Doğru kural seti ve doğru uyarı akışı ile, fark edilmesi zor anomali davranışlarını erken aşamada yakalayabilirsiniz.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "falco",
        "security",
        "observability",
        "kubernetes",
        "linux"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/kisa-omurlu-sertifikalarla-ayricalikli-erisim",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/kisa-omurlu-sertifikalarla-ayricalikli-erisim",
      "title": "Kısa Ömürlü Sertifikalarla Ayrıcalıklı Erişim",
      "summary": "Kalıcı SSH anahtarları yerine kısa ömürlü sertifikalar kullanarak ayrıcalıklı erişimi güvenli yönetme rehberi.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import diagram from './kisa omurlu sertifikalarla ayricalikli erisim diagram.svg'; Sunucu erişiminde en zayıf halka çoğu zaman saldırgan değil, yıllarca yaşayan anahtarlardır. Ayrıcalıklı hesaplar için paylaşılan SSH key'ler, kimin ne zaman eriştiğini belirsizleştirir; anahtar sızıntısı olduğunda kapsamı daraltmak zorlaşır. Kısa ömürlü sertifikalarla erişim tasarlamak, bastion host mantığını tamamen ortadan kaldırmasa bile erişimi süre, kimlik ve amaç bazında çok daha kontrollü hâle getirir. <figure <Image src={diagram} alt=\"Kısa ömürlü sertifika akışı, erişim onayı ve hedef sunucu ilişkisini gösteren teknik şema\" / <figcaption Kullanıcı anahtarı yerine, doğrulanmış talep sonrası süreli sertifika ile erişim verilmesi.</figcaption </figure Neden kalıcı anahtar modeli sorunlu? Kalıcı anahtar kullanımı küçük ekiplerde pratik görünür. Ancak kurumsal ölçekte şu sorunları üretir: Ayrıcalıklı erişim geri alma süresi uzar. Anahtar paylaşımı veya kopyalanması kolaydır. Erişim gerekçesi ile teknik erişim birbirinden kopar. Incident sonrası hangi oturumun kime ait olduğu netleşmeyebilir. Özellikle çok sayıda tedarikçi, operasyon ekibi veya geçici erişim ihtiyacı olan yapılarda bu model sürdürülebilir değildir. Kısa ömürlü sertifika modeli nasıl çalışır? Temel akış basittir: 1. Kullanıcı merkezi kimlik sistemiyle doğrulanır. 2. Ayrıcalıklı erişim talebi policy üzerinden değerlendirilir. 3. Onay sonrası birkaç dakikalık veya saatlik SSH sertifikası üretilir. 4. Sunucu, yalnızca güvenilir CA tarafından imzalanmış sertifikaları kabul eder. Böylece erişim hakkı, cihaza dağıtılmış statik anahtarlarla değil, anlık yetkilendirme kararıyla verilir. Bu model hangi bileşenleri gerektirir? Tam kurumsal çözüm ürün seçimine göre değişir; ama bileşen mantığı benzerdir: Merkezî kimlik sağlayıcı Politika veya erişim onay katmanı SSH CA veya sertifika imzalama servisi Hedef sunucularda CA güven zinciri Oturum ve komut kayıt görünürlüğü Bu yapı sayesinde kullanıcı hesabı devre dışı kaldığında, yeni sertifika üretilmediği için erişim fiilen kapanır. <Callout type=\"info\" title=\"Güvenlik kazancı\" Süreli sertifikalar tek başına yeterli değildir. En iyi sonuç, just in time onay, oturum kaydı ve merkezi loglama ile birlikte elde edilir. </Callout Sunucu tarafında ne değişir? Hedef host'larda her kullanıcı için tek tek public key tutmak yerine, güvenilen CA tanımlanır. Böylece kullanıcı değişimi host bazında değil merkezi imzalama zincirinde yönetilir. Operasyonel olarak bu, özellikle yüzlerce Linux sunucuda ciddi sadelik sağlar. Bu modelin önemli avantajları: Host üstündeki authorized keys karmaşasını azaltır. Geçici erişim taleplerini otomasyona bağlar. Kimlikten erişim kararına kadar zinciri denetlenebilir yapar. Ayrıcalıklı erişimi süre ve rol bazında sınırlar. Geçiş sırasında en sık hata nedir? Bazı ekipler kısa ömürlü sertifika modeline geçerken eski kalıcı anahtarları da \"yedek olsun\" diye bırakır. Bu durumda sistem güvenli görünür ama fiilen iki ayrı erişim modeli yaşamaya devam eder. Geçiş planında hangi host grubunda hangi tarihten itibaren yalnızca sertifika kabul edileceği açık şekilde tanımlanmalıdır. Nereden başlanmalı? En uygun başlangıç alanı, yüksek riskli ama kullanıcı sayısı sınırlı erişimlerdir: Production Linux yönetim hesapları Ağ cihazı yönetim erişimi ERP veya batch altyapısındaki zıplama hesapları Bu gruplarda başarı sağlandığında model diğer yönetim düzlemlerine genişletilebilir. Sonuç Kısa ömürlü sertifikalarla ayrıcalıklı erişim tasarımı, \"SSH key dağıtıp unutma\" alışkanlığını kırar. Ayrıcalıklı erişimin kimlik, süre ve onay bağlamıyla birlikte verilmesi; güvenlik ekipleri için denetlenebilirlik, operasyon ekipleri içinse daha kontrollü bir yaşam döngüsü üretir. Büyük altyapılarda güvenliğin kalıcı parçası olmak istiyorsanız, erişim hakkını kalıcı anahtar değil geçici güven kararı üzerinden vermek daha doğru yoldur.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "ssh",
        "security",
        "access-control",
        "automation",
        "infrastructure"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/nginx-ile-mtls-tabanli-servis-kimligi-dogrulama",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/nginx-ile-mtls-tabanli-servis-kimligi-dogrulama",
      "title": "Nginx ile mTLS Tabanlı Servis Kimliği Doğrulama",
      "summary": "İç servis trafiğinde karşılıklı TLS kullanarak servis kimliğini doğrulamak için Nginx tabanlı pratik yaklaşım.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; İç ağda çalışan servislerin birbiriyle sadece ağ segmentine güvenerek konuşması artık yeterli değil. Kubernetes içinde, sanal makinelerde veya hibrit yapılarda aynı segmentte bulunmak; çağrının gerçekten yetkili servisten geldiği anlamına gelmiyor. mTLS, hem trafiği şifreleyip hem de istemci tarafının sertifika ile kimliğini kanıtlamasını sağlayarak bu boşluğu kapatır. Nginx bu modeli küçük ve kontrollü bir başlangıç için oldukça kullanışlıdır. Ne kuruyoruz? Amaç, belirli bir iç servisin sadece kurumsal CA tarafından imzalanmış istemci sertifikasına sahip çağrıları kabul etmesi. Basit modelde üç bileşen bulunur: Sunucu sertifikası kullanan Nginx İstemci sertifikaları üreten bir CA Arkada çalışan hedef servis Nginx istemci sertifikasını doğrular, CN veya SAN alanına göre ek politika uygular ve trafiği arkadaki servise iletir. Temel Nginx yapılandırması Örnek blok: Bu kurulum istemci sertifikasını zorunlu kılar. Fakat üretim kullanımı için sadece ssl verify client on demek yetmez; sertifika yaşam döngüsü ve yetki eşlemesi ayrıca ele alınmalıdır. Sertifika yaşam döngüsü neden kritik? mTLS projelerinin büyük kısmı sertifika yenileme sürecinde dağılır. Sağlıklı model için: 1. Kısa ömürlü istemci sertifikaları kullanın 2. Dağıtımı otomatikleştirin 3. İptal veya erişim kaldırma akışını test edin 4. Hangi servis hesabının hangi sertifikayı kullandığını envanterde tutun Uzun ömürlü istemci sertifikaları, paylaşılan SSH anahtarı probleminin TLS versiyonuna dönüşür. <Callout type=\"tip\" title=\"Kimlik ile yetkiyi ayırın\" Sertifika, çağrının kimden geldiğini ispatlar. O servisin hangi uçlara erişebileceği ise ayrıca politika olarak tanımlanmalıdır. </Callout Uygulamada hangi başlıklar kontrol edilmeli? Nginx üzerinden mTLS kurarken şu alanlar hızlı değer üretir: Sadece belirli CA zincirine güvenmek subjectAltName veya distinguished name üzerinden servis eşleme yapmak İstemci kimliğini arka servise güvenli başlıklarla iletmek Hatalı doğrulamaları ayrı log akışına göndermek Bu sayede sadece erişim sağlanmaz; aynı zamanda güvenlik görünürlüğü de oluşur. Loglama ve gözlemlenebilirlik mTLS hata ayıklaması çoğu zaman zor görünür, çünkü bağlantı TLS katmanında kesilir. Bu yüzden erişim ve hata loglarında en az şu alanlar tutulmalıdır: Sertifika doğrulama sonucu İstemci DN veya SAN bilgisi Hedef upstream TLS sürümü ve cipher Bu kayıtlar güvenlik ekibi için kimlik doğrulama izi, platform ekibi için ise bağlantı sorunlarını çözme aracı olur. Nerede iyi başlangıç sağlar? Nginx tabanlı mTLS özellikle şu durumlarda kullanışlıdır: Monolith ile mikroservis arasında kontrollü geçiş ERP çevresi entegrasyon servisleri Sanal makinelerde çalışan iç API'ler Servis mesh kurmadan önce dar güvenlik ihtiyacı Daha büyük ölçekte servis mesh veya merkezi kimlik altyapısı tercih edilebilir; fakat Nginx yaklaşımı kontrollü ve anlaşılır başlangıç sunar. Sonuç Nginx ile mTLS tabanlı servis kimliği doğrulama, iç ağ güvenliğini segment sınırından servis kimliği seviyesine taşır. Başarılı uygulama için asıl mesele konfigürasyon satırları değil; CA yönetimi, sertifika ömrü, kimlik eşleme ve log görünürlüğünün birlikte düşünülmesidir. Bu model doğru kurulduğunda, iç servis trafiği çok daha net ve savunulabilir hale gelir.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "nginx",
        "mtls",
        "guvenlik",
        "network",
        "servis-mimarisi"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/terraform-plan-politikalari-icin-opa-pipeline",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/terraform-plan-politikalari-icin-opa-pipeline",
      "title": "Terraform Plan Politikaları için OPA Pipeline",
      "summary": "Terraform plan çıktısını OPA ile denetleyerek altyapı değişikliklerini politika kapısından geçirmek için pratik rehber.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Infrastructure as Code kullanan ekiplerin sık düştüğü tuzak, terraform plan çıktısını sadece insan gözüne bırakmaktır. Kod incelemesi değerlidir; fakat etiket standardı, internetten erişilebilir kaynaklar, bölge seçimi, maliyet sınırı veya şifreleme zorunluluğu gibi kuralları her PR'da elle kontrol etmek sürdürülebilir değildir. OPA tabanlı bir pipeline, plan çıktısını politika kararına çevirerek değişiklikleri insan yorumuna ek bir güvenlik katmanından geçirir. Temel akış Amaç, Terraform kodunu apply aşamasından önce iki kapıdan geçirmek: 1. terraform plan ile oluşacak değişikliği üretmek 2. Plan JSON çıktısını OPA policy seti ile değerlendirmek Bu yaklaşım sayesinde \"bulut hesabında ne olacak?\" sorusu ile \"bu değişikliğe izin var mı?\" sorusu birbirinden ayrılır ama aynı pipeline içinde birleşir. Plan çıktısını JSON olarak üretmek İlk adım standarttır: OPA veya Conftest tarafı genelde tfplan.json üzerinden çalışır. Önemli nokta, policy motorunun HCL dosyasına değil gerçek plan sonucuna bakmasıdır. Çünkü modül genişlemesi, değişken çözümü ve provider davranışları ancak plan aşamasında netleşir. Örnek politika senaryoları Başlangıç için yüksek değer üreten kurallar şunlardır: Public IP alan üretim kaynağı reddedilsin Zorunlu etiketler yoksa plan başarısız olsun Şifreleme kapalı storage kaynakları engellensin Belirli bölgeler dışına kaynak açılması reddedilsin Yüksek maliyetli instance tipleri için uyarı üretilebilsin Basit bir Rego örneği: Bu kural tek başına yeterli değildir ama yaklaşımı net gösterir: kaynak değişikliği, hedef durum ve iş bağlamı birlikte değerlendirilir. <Callout type=\"tip\" title=\"Plan seviyesinde denetim daha güvenilir\" Sadece kaynak kodunu incelemek yerine plan sonucunu denetlemek, modül ve değişken etkilerini gerçek haliyle görmenizi sağlar. </Callout Pipeline tasarımı CI akışı genelde şu sırayla kurulabilir: 1. Format ve validate 2. Plan üretimi 3. Plan JSON çıkarımı 4. OPA veya Conftest policy değerlendirmesi 5. Sonuçların PR yorumuna yazılması Bu akışta policy sonucu sadece \"geçti/kaldı\" olmamalıdır. Hangi kaynağın hangi kurala takıldığı PR üzerinde açık görünmelidir. Aksi halde geliştirici için düzeltme döngüsü uzar. Politika setini yönetmek Başarısız policy projelerinin çoğunda teknik değil yönetişim sorunu vardır. Şunlar netleşmelidir: Policy deposu uygulama kodundan ayrı mı? Versiyonlama nasıl yapılacak? Acil istisna mekanizması var mı? Uyarı ile engelleme kuralları nasıl ayrılıyor? Tüm kuralları ilk günden bloklayıcı yapmak ekiplerde tepki üretir. Sağlıklı model, önce görünürlük sağlamak sonra kritik kuralları kapı haline getirmektir. Kurumsal kullanım için ek kontroller Kurumsal yapılarda sadece güvenlik değil platform ve finans ekipleri de policy üretir. Bu yüzden kuralları üç gruba ayırmak işe yarar: Güvenlik guardrail'leri Operasyon ve gözlemlenebilirlik zorunlulukları Maliyet ve yönetişim kuralları Örneğin her üretim kaynağında log toplama ajanı veya izleme etiketi zorunlu tutulabilir. Böylece IaC doğrulaması ile observability standardı da birlikte taşınır. Sonuç Terraform plan çıktısını OPA pipeline üzerinden geçirmek, IaC pratiğini \"kod yaz ve um\" seviyesinden çıkarır. En büyük kazanım, platform bilgisini insan hafızasından alıp tekrar edilebilir politika setine dönüştürmektir. Küçük bir kural kümesiyle başlayıp plan tabanlı görünürlük oluşturursanız, zamanla güvenlik ve yönetişim kararlarını çok daha az sürtünmeyle standardize edebilirsiniz.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "terraform",
        "opa",
        "devops",
        "guvenlik",
        "otomasyon"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/vector-ile-merkezi-log-yonlendirme-boru-hatti",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/vector-ile-merkezi-log-yonlendirme-boru-hatti",
      "title": "Vector ile Merkezi Log Yönlendirme Boru Hattı",
      "summary": "Dağınık log akışlarını filtreleme, zenginleştirme ve çoklu hedefe yönlendirme için Vector tabanlı pratik kurulum.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ortamlarda log toplamak genellikle çözülmüş sorun gibi görünür. Asıl karmaşa, logların farklı formatlarda gelmesi, bazı kayıtların gereksiz yere pahalı hedeflere akması ve ekiplerin aynı veriyi farklı amaçlarla kullanmak istemesiyle başlar. Tam bu noktada merkezi yönlendirme boru hattı ihtiyacı doğar. Vector, hafif çalışma modeli ve esnek dönüşüm katmanlarıyla bu ihtiyaca güçlü bir yanıt verir. Neden araya bir yönlendirme katmanı koymalı? Uygulamalardan doğrudan SIEM, arşiv ve analiz sistemine log göndermek ilk bakışta sade görünür. Fakat şu sorunlar hızla ortaya çıkar: Her ekip farklı format üretir. Hassas alanların maskelemesi tutarsız kalır. Aynı log birden fazla hedefe farklı filtrelerle gitmelidir. Hedef sistemde yaşanan sorun, uygulama katmanını etkileyebilir. Vector burada tampon, dönüştürme ve yönlendirme katmanı olarak devreye girer. Boru hattı tasarımında önce akış sınıflandırılır Merkezi log hattında ilk iş tüm logları tek sepete atmak değildir. Önce şu sınıfları netleştirin: Operasyonel uygulama logları Güvenlik olayları Audit kayıtları Düşük değerli debug veya geçici loglar Bu ayrım olmadan her şeyi SIEM'e dökmek maliyeti artırır, analitik değeri düşürür. Vector ile temel akış nasıl kurulur? Tipik bir kurulum şu adımları izler: 1. Kaynakları belirleyin: dosya, syslog, container stdout veya agent girişi 2. Ortak alanları normalize edin 3. Hassas veriyi maskeleyin veya düşürün 4. Hedeflere göre filtreleyin 5. Yeniden deneme ve buffer ayarlarını yapılandırın Vector'ın güçlü yanı, dönüşüm zincirini okunabilir bir yapı içinde tutabilmesidir. <Callout type=\"tip\" title=\"Tek hedef yerine amaç bazlı hedef düşünün\" Güvenlik ekibinin ihtiyaç duyduğu log ile operasyon ekibinin hızlı arama logu aynı yerde ve aynı saklama süresiyle yaşamak zorunda değildir. Yönlendirme katmanı bu ayrımı mümkün kılar. </Callout Hangi zenginleştirmeler değer üretir? Merkezi hatta logu zenginleştirirken aşağıdaki alanlar pratikte çok işe yarar: environment service team region compliance scope Bu alanlar olmadan log sadece metindir. Bu alanlarla birlikte yönlendirme, arama ve alarm kuralları çok daha anlamlı hâle gelir. Çoklu hedef stratejisi Olgun yapılarda tek bir nihai hedef yerine katmanlı strateji daha sağlıklıdır: Gerçek zamanlı olaylar için SIEM Operasyonel inceleme için hızlı arama platformu Uzun süreli saklama için nesne depolama Bu yaklaşım hem maliyeti hem performansı dengeler. Vector üzerinden filtre ve route tanımlayarak her hedefe aynı yükü göndermek zorunda kalmazsınız. Operasyonel dikkat noktaları Backpressure durumunda buffer dolumunu mutlaka izleyin. Dönüşüm kurallarını Git tabanlı yönetin. Hassas veri maskelerini test etmeden üretime almayın. Agent sürümlerini heterojen bırakmayın. Merkezi log hattı görünürde altyapı işi olsa da, veri kalitesi doğrudan olay yönetimini etkiler. Sonuç Vector ile merkezi log yönlendirme boru hattı kurmak, sadece log taşımak değil; logu kurumsal ölçekte yönetilebilir bir veri ürününe dönüştürmektir. Doğru sınıflandırma, zenginleştirme ve çoklu hedef stratejisiyle hem maliyet hem güvenlik hem de operasyonel görünürlük aynı anda iyileşir.",
      "date_published": "2026-04-03T00:00:00.000Z",
      "date_modified": "2026-04-03T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "vector",
        "log",
        "devops",
        "otomasyon"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-api-gecidinde-politika-tabanli-guvenlik",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-api-gecidinde-politika-tabanli-guvenlik",
      "title": "Kurumsal API Geçidinde Politika Tabanlı Güvenlik",
      "summary": "API gateway katmanında kimlik, hız limiti ve veri koruma politikalarını merkezileştiren kurumsal yaklaşım.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal sistemlerde API geçidi çoğu zaman yalnızca yönlendirme yapan bir ters proxy gibi konumlandırılır. Oysa gerçek değeri, teknik entegrasyon noktalarını merkezi güvenlik ve yönetişim yüzeyine dönüştürmesidir. Özellikle ERP, mobil uygulama, partner entegrasyonu ve iç servis trafiği aynı ekosistemde buluşuyorsa; kimlik, hız limiti ve veri koruma kararlarını her ekipte yeniden uygulamak sürdürülebilir değildir. Neden uygulama koduna bırakmak yetmez? API güvenliği yalnızca JWT doğrulamak veya rol kontrolü yapmak değildir. Kurumsal tarafta şu kararlar birlikte ele alınmalıdır: Hangi istemci hangi API ailesine erişebilir? Aynı tüketici için oran limiti ne olmalı? Hassas alanlar loglarda veya cevaplarda nasıl maskelenmeli? Şüpheli trafik davranışı ne zaman kesilmeli? Hangi isteğin hangi sözleşme sürümünü kullandığı nasıl izlenmeli? Bu kontrolleri uygulama ekiplerinin tek tek yönetmesi, zamanla kural sapmasına yol açar. Sonuçta aynı kurum içinde benzer API'ler farklı güvenlik davranışları sergiler. Politika tabanlı model ne önerir? Politika tabanlı yaklaşım, API geçidini bir yönlendirme katmanından daha fazlası olarak görür. Bu modelde geçit, istek işleme sürecinde şu kararları merkezi olarak uygular: 1. Kimlik doğrulama ve istemci profili 2. Yetki ve kaynak erişim kısıtları 3. Rate limiting ve quota 4. Şema doğrulama ve payload filtreleme 5. Audit ve telemetry üretimi Böylece uygulamalar iş mantığına odaklanırken, güvenlik politikaları yaşam döngüsü yönetilebilir bir katmanda toplanır. Hangi politikalar ilk günden tanımlanmalı? Pratikte en yüksek değeri şu politika setleri üretir: İç ve dış istemci sınıflandırması Token süresi ve kapsam kontrolü IP veya ağ kaynağına göre ek doğrulama Kritik uç noktalar için daha agresif rate limit Hassas başlık ve alanların loglardan çıkarılması Standart hata kodu ve izleme başlığı üretimi <Callout type=\"info\" title=\"Merkezi ama kör olmayan yapı\" Tüm politikaları tek yerde toplamak, ekiplerin esnekliğini öldürmek anlamına gelmez. Ama istisnaların açık tanımlı ve izlenebilir olması gerekir; gizli konfigürasyon olmamalıdır. </Callout ERP ve kurumsal entegrasyonlarda neden kritik? Kurumsal çekirdek sistemler genelde tek biçimli değildir. Aynı anda SOAP, REST, dosya aktarımı ve iç servis çağrıları yan yana bulunabilir. API geçidi bu dağınık alan için üç önemli fayda sağlar: Yeni tüketiciler için kontrollü bir giriş yüzeyi oluşturur. Eski servisleri doğrudan internete veya geniş iç ağa açma ihtiyacını azaltır. İstek hacmi ve hata davranışını tek noktadan ölçülebilir kılar. Bu özellikle bayi entegrasyonları, e ticaret bağlantıları ve mobil istemciler için büyük fark yaratır. Telemetry tarafı ihmal edilmemeli İyi bir API güvenlik modeli, yalnızca engelleyen bir katman değildir; aynı zamanda öğrenen bir katmandır. Bu yüzden şu sinyaller mutlaka üretilmelidir: İstemci bazlı istek hacmi Yetkisiz erişim denemeleri Sürüm bazlı kullanım dağılımı Oran limiti ihlalleri Hedef servis gecikmesi Bu veriler olmadan politika ayarlamaları genellikle sezgiyle yapılır. Oysa gerçek trafik davranışı görüldüğünde hem güvenlik hem performans kararları daha savunulabilir olur. Sık yapılan tasarım hataları Kurumsal ortamlarda tekrarlayan bazı yanlışlar vardır: API geçidini yalnızca SSL sonlandırma noktası gibi kullanmak İç ve dış istemcileri aynı güven modeliyle ele almak Rate limit kurallarını iş kritikliği yerine kaba global sayılarla tanımlamak Geçit konfigürasyonlarını sürüm kontrolüne almamak Gateway olaylarını merkezi observability akışına bağlamamak Bu hatalar, geçidi yönetim katmanı olmaktan çıkarıp yeni bir tekil hata noktasına dönüştürür. Sonuç Kurumsal API geçidi, doğru tasarlandığında yalnızca trafik yönlendirme bileşeni değildir; kimlik, hız limiti, veri koruma ve denetim kurallarının buluştuğu politika yüzeyidir. Özellikle heterojen entegrasyon alanları olan kurumlarda, güvenliği uygulama koduna dağınık biçimde bırakmak yerine merkezi ve izlenebilir bir katmanda toplamak; hem operasyonel tutarlılık hem de denetlenebilirlik açısından daha güçlü bir mimari üretir.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "api",
        "guvenlik",
        "cloud",
        "kurumsal-mimari",
        "zero-trust"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-dns-ve-servis-kesfinde-dayaniklilik",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-dns-ve-servis-kesfinde-dayaniklilik",
      "title": "Kurumsal DNS ve Servis Keşfinde Dayanıklılık",
      "summary": "Hibrit altyapılarda DNS ve servis keşfi katmanını tek hata noktasına dönüştürmeden tasarlama prensipleri.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal sistemlerde ağ kesintilerinin önemli bir kısmı doğrudan hatalı routing'den değil, görünüşte küçük görünen isim çözümleme sorunlarından başlar. Yanlış TTL, tutarsız resolver davranışı, bölgesel gecikme veya servis keşif kayıtlarının zamanında güncellenmemesi; tüm uygulama katmanını etkileyebilir. Özellikle hibrit bulut, veri merkezi ve eski ERP servislerinin aynı ekosistemde yaşadığı yapılarda, DNS yalnızca altyapı detayı değil kritik mimari bileşendir. Sorun neden sık hafife alınır? Çünkü DNS çoğu zaman \"zaten çalışan\" bir temel servis gibi görülür. Ancak uygulama tarafında yaşanan pek çok semptomun kökü burada olabilir: Yeni node'ların geç görünmesi Eski IP'lere trafik akması Bölgesel kesintide iç servislerin birbirini bulamaması Farklı resolver zincirlerinde tutarsız cevaplar Bu sorunlar özellikle mikroservis yayılımı, çoklu ortam ve hibrit bağlantılar arttıkça büyür. Dayanıklı bir model hangi prensiplere dayanır? Kurumsal DNS ve servis keşfi tasarımında şu ilkeler kritik olur: Yetkili zone yönetimi ile resolver katmanını ayırmak İç ve dış isim alanlarını net bölmek TTL değerlerini operasyonel ihtiyaçla uyumlu seçmek Sağlık durumu ile kayıt yaşam döngüsünü ilişkilendirmek Gözlemlenebilirlik verisini DNS katmanından üretmek Buradaki amaç yalnızca cevap dönen resolver sayısını artırmak değil; isim çözümlemenin güvenilir davranışını tasarlamaktır. <Callout type=\"info\" title=\"Sessiz bağımlılık\" Birçok platformda servis keşfi görünmez bağımlılıktır. Herkes kullanır, az ekip sahiplenir. Bu yüzden arıza anında sorun uygulama, ağ ve platform ekipleri arasında dolaşır. </Callout Hibrit altyapıda nereler zorlaşır? Hibrit yapılarda DNS davranışı tek ortamdan farklıdır çünkü: On prem ve cloud resolver zincirleri farklı olabilir. Split horizon kayıtlar tutarsız sonuç üretebilir. VPN veya özel bağlantı gecikmesi çözümleme süresini etkileyebilir. Eski sistemler kısa TTL değişimlerine uyumlu olmayabilir. Bu yüzden servis keşif modeli tasarlanırken yalnızca Kubernetes veya cloud native tarafına bakmak yetersiz kalır. Neyi ölçmek gerekir? Sağlıklı bir DNS katmanı için sadece \"servis ayakta mı\" metriği yetmez. Şunlar da takip edilmelidir: Çözümleme gecikmesi NXDOMAIN ve SERVFAIL oranı Resolver bazlı hata dağılımı Kayıt değişim sonrası yayılım süresi En çok sorgulanan kritik servis kayıtları Bu sinyaller olmadan arıza kök nedeni çoğu zaman geç bulunur. Sonuç Kurumsal DNS ve servis keşfi, altyapının en az görünür ama en kritik dayanıklılık katmanlarından biridir. Doğru tasarım; resolver sürekliliği, sağlıklı kayıt yaşam döngüsü ve güçlü telemetry üzerine kurulur. İyi çalışan sistemlerde DNS fark edilmez; kötü tasarlanmış sistemlerde ise en çok onu fark edersiniz.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "dns",
        "network",
        "sistem-mimarisi",
        "hibrit-bulut",
        "dayaniklilik"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/platform-engineering-ile-self-service-altyapi-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/platform-engineering-ile-self-service-altyapi-tasarimi",
      "title": "Platform Engineering ile Self-Service Altyapı Tasarımı",
      "summary": "Altyapı ekiplerini darboğaz olmaktan çıkaran self-service platform yaklaşımını kurumsal ölçekte tasarlama rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal yapılarda altyapı ekiplerinin en sık yaşadığı baskı, her proje için tekrar eden kaynak taleplerinin elle yönetilmesidir. Yeni bir servis ortamı, veritabanı erişimi, log hattı veya ağ kuralı gerektiğinde her iş altyapı kuyruğuna düşer. Bu model bir süre çalışır; fakat ölçek büyüdükçe ekipler hem yavaşlar hem de birbirinin işini beklemeye başlar. Platform engineering yaklaşımı, bu darboğazı self service prensibiyle çözmeyi hedefler. Self service gerçekten ne demek? Self service altyapı, geliştiricilerin sınırsız yetkiyle kaynak açması değildir. Asıl hedef, kurumun onayladığı güvenlik, ağ ve gözlemlenebilirlik kurallarını platform ürünleri hâline getirmektir. Böylece ekipler ihtiyaçlarını standart bir arayüz üzerinden alır; altyapı ekibi ise her talebi elle işlemez. Bu yaklaşım tipik olarak şu kazanımları üretir: Yeni ortam açma süresi kısalır. Standart dışı konfigürasyon azalır. Güvenlik ve denetim kontrolleri akışa gömülür. Altyapı ekibi bilet kapatmak yerine platform geliştirmeye odaklanır. Hangi katmanlar ürünleştirilir? Başarılı self service platformlarda genelde benzer servis alanları ürünleştirilir: Uygulama deploy şablonları Veritabanı ve cache yaşam döngüsü Ağ politikası ve erişim modelleri CI/CD entegrasyonları Log, metric ve trace bağlantıları Buradaki kritik nokta, geliştiricinin yalnızca \"kaynak\" değil, \"güvenli varsayılanlarla gelen bir platform davranışı\" almasıdır. <Callout type=\"tip\" title=\"Ürün gözüyle bakın\" Platform engineering, iç IT hizmeti değil iç ürün geliştirmedir. Eğer geliştirici deneyimi ölçülmüyorsa platform çalışıyor sanılabilir ama kullanılmıyor olabilir. </Callout Kurumsal mimaride neden daha zor? Self service modeli startup ölçeğinde nispeten kolaydır. Kurumsal yapılarda ise iş zorlaşır çünkü: Ortamlar farklı regülasyon sınırlarına sahiptir. ERP ve çekirdek sistemler özel ağ segmentlerinde yaşar. Yetkilendirme modeli takım bazlı değil rol ve süreç bazlı olabilir. Değişiklik onayları bazı ortamlar için zorunludur. Bu yüzden tek tip bir portal veya tek Terraform modülü yetmez. Platformun, farklı risk seviyelerine göre farklı ürün yüzeyleri sunması gerekir. Minimum uygulanabilir platform nasıl kurulur? Pratik başlangıç için şu sırayı izlemek verimlidir: 1. En sık açılan üç altyapı talebini belirleyin. 2. Bu talepler için güvenli varsayılanlar tanımlayın. 3. Talep yüzeyini Git tabanlı veya portal tabanlı standart akışa taşıyın. 4. Telemetry ve audit kaydını platformun parçası hâline getirin. Bu yaklaşımla ilk günden dev platform kurmak yerine, gerçekten kullanılan küçük ama kaliteli servisler üretmek mümkün olur. Hata yapılan nokta Birçok ekip self service hedefini yalnızca otomasyonla karıştırır. Oysa otomasyon tek başına yeterli değildir. Eğer kullanıcı deneyimi net değilse, dokümantasyon zayıfsa ve hata mesajları geliştiriciye yol göstermiyorsa; otomatik sistem de yeni bir darboğaz oluşturur. Sonuç Platform engineering ile self service altyapı tasarımı, yalnızca araç standardizasyonu değil; altyapıyı kurum içinde tüketilebilir bir ürün hâline getirme işidir. Doğru kurulduğunda hem hız hem güvenlik hem de işletilebilirlik aynı anda gelişir. Özellikle çok takımlı, kurumsal ve regülasyonlu yapılarda, sürdürülebilir büyümenin yolu talepleri artırmaktan değil tekrar eden altyapı kararlarını ürünleştirmekten geçer.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "platform-engineering",
        "devops",
        "cloud",
        "otomasyon",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/servis-mesh-olmadan-dogu-bati-trafik-gozlemlenebilirligi",
      "url": "https://mustafaerbay.com.tr/blog/technology/servis-mesh-olmadan-dogu-bati-trafik-gozlemlenebilirligi",
      "title": "Servis Mesh Olmadan Doğu-Batı Trafik Görünürlüğü",
      "summary": "Mikroservis ve VM tabanlı ortamlarda servis mesh kurmadan doğu-batı trafiğini görünür kılma yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Dağıtık sistemler büyüdükçe ekiplerin ilk kaybettiği şeylerden biri, servisler arasındaki yatay trafiğin netliğidir. Kuzey güney trafiği genelde load balancer, WAF veya reverse proxy katmanlarında görünür hâle gelir; fakat doğu batı trafik çoğu zaman uygulama logları, node metrikleri ve dağınık trace kayıtları arasında kaybolur. Her kurumun servis mesh yatırımı yapmak için doğru zamanı veya operasyon kapasitesi olmayabilir. Bu durumda hedef, mesh kurmadan önce görünürlüğü disiplinli biçimde artırmaktır. Problem gerçekten nerede başlıyor? Mikroservisler arttıkça ekipler tipik olarak şu sorulara hızlı yanıt veremez: Hangi servis hangi porta ve hangi protokolle konuşuyor? Bir isteğin gecikmesi ağ katmanından mı, uygulama katmanından mı geliyor? Retry fırtınası hangi servis zincirinden doğuyor? Aynı segment içinde beklenmeyen çağrılar var mı? Bu sorular yanıtsız kaldığında sorun yalnızca operasyonel olmaz. Güvenlik ekipleri de beklenmeyen yatay iletişimi fark etmekte zorlanır. Özellikle ERP entegrasyonları, iç servis ağları ve hibrit bağlantılar aynı ortamdaysa risk katlanır. Mesh olmadan görünürlük için dört veri kaynağı Servis mesh çoğu zaman politika uygulama ve telemetry üretimi için cazip bir çerçeve sunar. Fakat benzer bir görünürlüğün önemli kısmı aşağıdaki katmanlarla da kurulabilir: 1. L7 ters proxy logları : Envoy, NGINX veya HAProxy benzeri proxy'ler merkezi erişim kayıtları üretir. 2. eBPF veya flow telemetry : Kernel seviyesinde bağlantı hareketleri ve latency sinyalleri toplanır. 3. OpenTelemetry instrumentation : Uygulama çağrıları trace ve metric olarak işlenir. 4. Ağ akış verileri : VPC flow log, firewall log veya switch telemetry kaynakları genel resmi verir. Buradaki amaç tek bir sihirli araç seçmek değil, sinyalleri aynı olay modeline bağlamaktır. Nereden başlanmalı? Pratik başlangıç noktası, servis çağrılarının sahiplik bilgisini zorunlu alan hâline getirmektir. Her çağrıyı göremeseniz bile, gördüğünüz her akışı şu ortak etiketlerle zenginleştirin: source.service destination.service environment region team criticality Bu alanlar olmadan toplanan ağ verisi teknik olarak zengin olsa bile operasyonel olarak zayıf kalır. <Callout type=\"tip\" title=\"Öncelik sırası\" Önce görünürlük kurun, sonra politika sıkılaştırın. Hangi servislerin gerçekten konuştuğunu ölçmeden ağ segmentasyonu veya mTLS zorlaması başlatmak gereksiz kesintilere yol açar. </Callout Gözlem mimarisi nasıl kurulabilir? Kurumsal ölçekte sürdürülebilir bir yaklaşım genelde şu akışı izler: Giriş ve çıkış yapan kritik servislerin önüne standart proxy katmanı yerleştirilir. Node seviyesinde bağlantı ve paket davranışları eBPF tabanlı ajanlarla toplanır. Uygulama ekipleri kritik istek zincirleri için trace üretir. Tüm sinyaller ortak bir observability platformunda korele edilir. Bu modelin önemli avantajı, tüm platformu tek seferde dönüştürme zorunluluğu olmamasıdır. Önce en kritik servis kümeleriyle başlanır; sonra görünmeyen alanlar kademeli olarak azaltılır. Hangi metrikler anlamlıdır? Doğu batı trafik gözlemlenebilirliğinde herkes bağlantı sayısına bakar; ama asıl değerli sinyaller şunlardır: Servis bazlı P95 ve P99 gecikme Hata oranı ve reset edilen bağlantı yüzdesi Yeni ve beklenmeyen servis bağımlılıkları Aynı istemciden gelen retry yoğunluğu Bölge veya segment bazlı trafik sapmaları Bu sinyaller, yalnızca performans sorunu değil, hatalı yayın, yanlış DNS çözümü veya yanlış güvenlik politikası gibi konuları da erken yakalar. Güvenlik tarafında kazanım nedir? Doğu batı trafik görünürlüğü güvenlik ekiplerine üç net avantaj sağlar: Beklenmeyen lateral movement davranışları daha hızlı fark edilir. Sadece teorik değil, gerçek servis bağımlılıklarına göre mikrosegmentasyon yapılır. İç ağda kimlik doğrulaması olmayan eski protokoller daha görünür hâle gelir. Özellikle eski ERP servisleri, dosya paylaşımı kullanan batch işleri ve servis hesabı ile konuşan yardımcı sistemler bu analizde hızlıca ayrışır. Mesh ne zaman gerçekten gerekli olur? Servis sayısı arttığında, ekipler arası yetki ayrımı derinleştiğinde ve mTLS gibi politikalar zorunlu hâle geldiğinde servis mesh ciddi değer üretir. Ancak görünürlük katmanını daha erken kurmak, mesh geçişini de daha güvenli yapar. Çünkü hangi akışların kritik, hangilerinin gereksiz ve hangilerinin istisna olduğunu zaten biliyor olursunuz. Sonuç Servis mesh, dağıtık sistemlerde güçlü bir araçtır; ama görünürlük ihtiyacı için ilk ve tek seçenek değildir. Doğu batı trafiği proxy logları, eBPF sinyalleri, trace verisi ve ağ akış kayıtlarıyla birleştirdiğinizde; performans, güvenlik ve mimari borç aynı resimde görünür hâle gelir. Kurumsal platformlarda doğru yaklaşım, önce trafiği anlamak, sonra zorunlu kontrol katmanlarını devreye almaktır.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "network",
        "observability",
        "mikroservis",
        "sistem-mimarisi",
        "guvenlik"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/ebpf-ile-linux-ag-akislarini-gozlemleme",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/ebpf-ile-linux-ag-akislarini-gozlemleme",
      "title": "eBPF ile Linux Ağ Akışlarını Gözlemleme",
      "summary": "Linux sunucularda paket yakalamaya boğulmadan akış, gecikme ve bağlantı davranışını eBPF ile izleme rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Linux sunucularda ağ problemi araştırılırken ekipler çoğu zaman iki uç arasında sıkışır: ya çok az veri vardır ya da tcpdump ile toplanan ham paket miktarı operasyonel olarak yönetilemez boyuttadır. eBPF, bu denklemi değiştiren güçlü bir araçtır. Doğru kullanıldığında kernel seviyesinden bağlamlı sinyaller almanızı sağlar; üstelik tüm trafiği diske dökmeden. eBPF neden fark yaratıyor? Geleneksel araçlar bağlantı tabloları, paket yakalama veya sınırlı arayüz sayaçları üretir. eBPF ise çekirdek içinde belirli olaylara program bağlayarak daha anlamlı veri çıkarır. Bunun pratik sonucu şudur: Yeni açılan bağlantıları izleyebilirsiniz. Hangi prosesin hangi hedefe konuştuğunu görebilirsiniz. Bağlantı gecikmesi ve reset davranışını ölçebilirsiniz. Ağ görünürlüğünü observability platformuna uygun etiketlerle aktarabilirsiniz. Bu özellikle mikroservis, yüksek bağlantı yoğunluğu veya hibrit ağ geçişleri olan sistemlerde değerlidir. Başlangıç için hedef sinyaller İlk kurulumda her şeyi toplamaya çalışmak yanlıştır. Önce hangi sorulara yanıt istediğinizi netleştirin: Hangi prosesler beklenmeyen dış bağlantı açıyor? En çok timeout yaşayan hedefler hangileri? Aynı node üzerinde tekrar eden retry fırtınası var mı? Belirli saatlerde bağlantı kapanma oranı artıyor mu? Bu sorulara göre eBPF programlarının üreteceği olay tiplerini seçmek daha doğrudur. Güvenli başlangıç akışı Pratik bir devreye alma sırası şöyledir: 1. Önce gözlem yapılacak node gruplarını belirleyin. 2. Kernel sürümü ve güvenlik ayarlarının eBPF kullanımına uygunluğunu doğrulayın. 3. Düşük hacimli bağlantı olaylarıyla başlayın. 4. Toplanan alanları sınırlayın; her paketi kopyalamayın. 5. Sonuçları merkezi log veya metric sistemine akıtın. <Callout type=\"tip\" title=\"Yanlış metrikten kaçının\" Paket sayısını toplamak kolaydır ama çoğu zaman iş değeri düşük kalır. Proses, hedef servis, gecikme ve hata tipi gibi alanlar daha yüksek operasyonel değer üretir. </Callout Hangi alanlar mutlaka etiketlenmeli? Toplanan olaylar merkezi platforma giderken aşağıdaki alanlar kritik olur: host.name process.name destination.ip destination.port connection.state latency ms environment Bu etiketler sayesinde sadece ağ davranışı değil, iş yükü sahipliği de görünür olur. Özellikle aynı node üzerinde çok sayıda servis varsa bu zorunludur. Operasyonel kullanım örnekleri eBPF tabanlı akış verisi şu senaryolarda ciddi hız kazandırır: Uygulama yavaş ama altyapı metriği normal görünen durumlar Anlık bağlantı reset patlamaları Beklenmeyen DNS veya dış servis bağımlılıkları Güvenlik ekibinin lateral movement araştırmaları Paket içeriğine dokunmadan bağlantı davranışını izlemek, hem maliyet hem gizlilik açısından daha sürdürülebilir bir yoldur. Dikkat edilmesi gereken sınırlar eBPF çok güçlüdür; bu yüzden kontrolsüz kullanılırsa yeni sorun üretir: Fazla olay üretmek CPU ve bellek baskısı yaratabilir. Ham IP verisini bağlam olmadan toplamak anlamlı sonuç vermez. Her kernel sürümünde aynı davranışı beklemek yanlıştır. Toplanan veriyi etiket standardına bağlamamak analiz değerini düşürür. Bu yüzden üretim ortamına geçmeden önce sınırlı node grubunda profil çıkarmak gerekir. Sonuç eBPF, Linux ağ gözlemlenebilirliği için yalnızca yeni bir araç değil; daha doğru soyutlama seviyesidir. Ham paket dünyası ile yetersiz sayaçlar arasında kalmak yerine, proses ve akış odaklı anlamlı telemetry elde etmenizi sağlar. Kurumsal ortamlarda en iyi sonuç, küçük ama net sorularla başlayıp eBPF verisini merkezi observability modeline disiplinli biçimde bağladığınızda ortaya çıkar.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "linux",
        "ebpf",
        "network",
        "observability",
        "sunucu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/gitops-ile-coklu-ortam-terfi-hatti",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/gitops-ile-coklu-ortam-terfi-hatti",
      "title": "GitOps ile Çoklu Ortam Terfi Hattı",
      "summary": "Geliştirme, test ve üretim ortamları arasında kontrollü terfi akışı kurmak için GitOps tabanlı pratik rehber.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ekiplerde dağıtım hatlarının en kırılgan noktalarından biri, geliştirme ortamında çalışan bir değişikliğin test ve üretime hangi kurallarla taşınacağının net olmamasıdır. CI sistemleri artefact üretir; ama asıl kontrol sorusu çoğu zaman şu olur: hangi sürüm ne zaman, kim tarafından ve hangi onay mekanizmasıyla üst ortama terfi etti? GitOps yaklaşımı bu soruya daha denetlenebilir bir cevap verir. GitOps burada neyi çözüyor? GitOps yalnızca \"deploy manifestleri Git'te dursun\" yaklaşımı değildir. Çoklu ortam yönetiminde üç somut problem çözer: Ortam durumu istenen durum olarak sürüm kontrolüne alınır. Terfi kararları görünür ve denetlenebilir olur. Operasyon ekibi ile uygulama ekibi arasında ortak bir değişiklik yüzeyi oluşur. Bu özellikle birden fazla Kubernetes kümesi, ayrı ağ segmentleri veya ERP çevresinde çalışan yardımcı servis kümeleri olduğunda önemlidir. Sağlam bir ortam modeli nasıl görünür? Başlangıç için en okunabilir yapı genelde şu ayrımı yapar: dev: hızlı geri bildirim ve esnek deneme alanı test veya staging: entegrasyon, regresyon ve güvenlik kontrolleri prod: kural seti sıkı, değişiklik penceresi net ortam Bu ortamların tamamı aynı repo içinde tutulabilir; ancak onay kuralları, branch korumaları ve dağıtım tetikleyicileri farklı olmalıdır. Terfi hattını tasarlarken temel kararlar GitOps hattında şu kararlar baştan verilmelidir: 1. Artefact sürümü immutable mı? 2. Terfi için PR mı, etiket mi, otomatik policy mi kullanılacak? 3. Ortamlar arası fark yalnızca değer dosyalarında mı tutulacak? 4. Geri dönüş hangi commit veya manifest sürümüne göre yapılacak? Bu sorular net değilse GitOps yalnızca yeni bir commit ritüeline dönüşür. <Callout type=\"tip\" title=\"Doğru sınır\" CI artefact üretir, GitOps ise ortamın hedef sürümünü ilan eder. Bu iki sorumluluğu karıştırmak, hem rollback hem audit izini zayıflatır. </Callout Örnek terfi akışı Pratik ve kontrollü bir akış şu şekilde işler: Uygulama değişikliği CI ile derlenir ve sürümlü imaj üretilir. dev ortam manifesti yeni imaja referans verecek şekilde güncellenir. Doğrulamalar geçerse test ortamı için ayrı bir PR açılır. Gerekli kontroller sonrası prod manifesti onayla yükseltilir. Bu modelde her ortam geçişi Git geçmişinde izlenebilir olur. Aynı zamanda \"hangi sürüm üretimde?\" sorusu cluster içine bakmadan da yanıtlanabilir. Kurumsal tarafta neden zorlaşır? Gerçek hayatta ortamlar sadece teknik olarak ayrılmaz; ağ, erişim, veri sınıfı ve değişiklik penceresi açısından da ayrılır. Bu yüzden GitOps hattı şu alanlara da temas etmelidir: Ayrı sır ve kimlik yönetimi Ortam bazlı politika kontrolleri Dağıtım sonrası sağlık doğrulaması Onaylı bakım pencereleri Özellikle ERP bağımlı sistemlerde, uygulama sağlıklı olsa bile aşağı akış entegrasyonları hazır değilse terfi tamamlanmış sayılmaz. Sık yapılan hatalar Ortam farklarını kopyala yapıştır manifestlerle büyütmek Üretim terfisini aynı branch akışıyla kontrolsüz yapmak GitOps aracını manuel müdahaleyle sürekli bypass etmek Rollback stratejisini yalnızca yeniden deploy varsaymak Ortamlara özel gözlem ve alarm şartlarını unutmak Bu hatalar yüzünden GitOps görünürde vardır; ama gerçek kontrol yine kişilerin terminal geçmişinde kalır. Sonuç GitOps ile çoklu ortam terfi hattı kurmak, dağıtımı yalnızca otomatikleştirmek değil; değişikliği denetlenebilir bir ürün hâline getirmektir. İyi tasarlanmış bir akış, geliştirme hızını boğmadan test ve üretim ortamlarında daha yüksek güven üretir. Kurumsal yapılarda asıl değer, her ortam terfisinin izlenebilir, geri alınabilir ve sahipliği açık bir karar noktası olmasında ortaya çıkar.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "gitops",
        "devops",
        "cloud",
        "otomasyon",
        "kubernetes"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/kubernetes-secret-rotasyonu-icin-external-secrets-akisi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/kubernetes-secret-rotasyonu-icin-external-secrets-akisi",
      "title": "Kubernetes Secret Rotasyonu için External Secrets Akışı",
      "summary": "Kubernetes ortamlarında secret verisini merkezi kasadan çekip rotasyonu uygulamak için External Secrets tabanlı rehber.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kubernetes içinde sır yönetimi yapılırken en sık görülen hata, uygulama secret'larının doğrudan manifest veya CI değişkenlerinde yaşatılmasıdır. Bu model küçük ortamlarda tolere edilir; ancak ortam sayısı, takım sayısı ve güvenlik gereksinimi arttıkça sürdürülemez hâle gelir. External Secrets yaklaşımı, bu problemi merkezi sır kasası ile cluster içindeki çalışma zamanı arasında kontrollü bir senkronizasyon katmanı kurarak çözer. External Secrets neden gerekli? Çünkü Kubernetes Secret nesnesi depolama formatıdır; sır yaşam döngüsü çözümü değildir. Aşağıdaki ihtiyaçlar büyüdükçe harici kaynak şart olur: Düzenli rotasyon Ortam bazlı farklı değerler Erişim denetimi Audit kaydı Secret kaynağını uygulama manifestinden ayırma Bu noktada External Secrets Operator veya benzeri desenler anlamlılaşır. Temel akış nasıl işler? Model basittir: 1. Uygulama ekibi cluster içinde ExternalSecret tanımı oluşturur. 2. Operatör merkezi sır kasasına yetkili kimlikle bağlanır. 3. İlgili değer Kubernetes Secret nesnesine senkronize edilir. 4. Secret değiştiğinde uygulama yeniden yüklenir veya rollout tetiklenir. Bu modelin önemli avantajı, uygulama manifestinin sırrın kendisini değil referansını taşımasıdır. <Callout type=\"tip\" title=\"Rotasyon uygulama davranışıdır\" Secret'ı güncellemek tek başına yeterli değildir. Uygulamanın bu değişimi nasıl tüketeceği net değilse rotasyon kağıt üstünde kalır. </Callout Hangi tasarım kararları kritik? Başarılı bir kurulum için şu konular net olmalıdır: Hangi takım hangi secret yoluna erişebilir? Ortamlar arası ayrım nasıl yapılır? Refresh aralığı neye göre seçilir? Uygulama yeniden yükleme mekanizması nedir? Audit verisi nerede toplanır? Bu kararlar verilmeden operatör kurmak, yalnızca secret kopyalama işini otomatikleştirir. Sonuç Kubernetes secret rotasyonu için External Secrets akışı, sır yönetimini manifest seviyesinden yaşam döngüsü seviyesine taşır. Merkezi kasa, kontrollü erişim ve düzenli senkronizasyon ile daha güvenli bir platform modeli kurulur. Özellikle çoklu ortam, çoklu takım ve yüksek denetim gerektiren kurumsal yapılarda bu yaklaşım ciddi operasyonel sadelik sağlar.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "kubernetes",
        "security",
        "external-secrets",
        "devops",
        "vault"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/prometheus-alert-routing-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/prometheus-alert-routing-tasarimi",
      "title": "Prometheus Alert Routing Tasarımı",
      "summary": "Alertmanager ile yanlış kişiye giden uyarıları azaltan ve olay yönetimini hızlandıran yönlendirme modelini kurma rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Monitoring sistemi kurmak görece kolaydır; doğru kişiyi doğru zamanda uyarmak ise daha zordur. Birçok ekipte problem uyarı eksikliği değil, uyarıların yanlış ekipte, yanlış öncelikte ve yanlış kanal üzerinden dolaşmasıdır. Prometheus ve Alertmanager birlikte kullanıldığında, bu gürültüyü daha yönetilebilir bir rotaya çevirmek mümkündür. Neden routing tasarımı ayrı ele alınmalı? Çünkü alarm üretmek ile alarmı işletmek aynı şey değildir. Sağlıklı bir yönlendirme modeli: Aynı olaydan doğan tekrarlı bildirimleri birleştirir. Takım sahipliğine göre doğru alıcıyı seçer. İş kritikliğine göre farklı kanal ve escalation kullanır. Sessizleştirme ve bakım penceresini destekler. Bu kararlar tanımsızsa, her yeni kural sonunda alarm yorgunluğunu artırır. Etiket disiplini olmadan routing zayıf kalır Alertmanager yönlendirmesi esasen etiketlerle çalışır. Bu yüzden alert kuralı üretirken şu alanları disiplinli tanımlamak gerekir: severity team service environment runbook Bu alanlar eksikse veya takım bazında farklı kullanılıyorsa; routing ağacı hızla karmaşıklaşır. <Callout type=\"tip\" title=\"Alarmı çalıştıran bağlamdır\" Bir alarmın teknik olarak doğru olması yetmez. Runbook linki, sahiplik bilgisi ve etki alanı yoksa uyarı operasyonel olarak eksik kalır. </Callout Hangi yönlendirme katmanları işe yarar? Pratikte şu ayrım netlik sağlar: Bilgilendirme seviyesi alarmlar: sohbet kanalı Müdahale gerektiren yüksek öncelik: pager veya telefon zinciri Güvenlik ve erişim olayları: ayrı güvenlik kanalı Üretim dışı ortamlar: bastırılmış veya düşük öncelikli kanal Bu modelle test ortamındaki gürültü ile üretim krizi aynı davranışı üretmez. Sonuç Prometheus alert routing tasarımı, alarm sisteminin gerçek operasyon değerini belirler. Doğru etiket modeli, grup mantığı ve sahiplik temelli yönlendirme ile daha az ama daha anlamlı uyarı üretmek mümkündür. Gözlemlenebilirlikte kalite, sadece neyi ölçtüğünüzle değil, kime nasıl haber verdiğinizle de belirlenir.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "prometheus",
        "alertmanager",
        "observability",
        "devops",
        "monitoring"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/traefik-ile-ic-servis-yayinlama-ve-tls-otomasyonu",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/traefik-ile-ic-servis-yayinlama-ve-tls-otomasyonu",
      "title": "Traefik ile İç Servis Yayınlama ve TLS Otomasyonu",
      "summary": "İç servisleri güvenli biçimde yayınlamak ve sertifika yaşam döngüsünü otomatikleştirmek için Traefik tabanlı rehber.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; İç servisleri kurumsal ağ içinde güvenli ve yönetilebilir biçimde yayınlamak, düşündüğünden daha fazla operasyonel karar içerir. Sadece reverse proxy kurmak yetmez; alan adı, TLS sertifikası, yönlendirme kuralı ve erişim kontrolü aynı akışın parçası olmalıdır. Traefik bu alan için özellikle faydalıdır çünkü dinamik keşif, TLS otomasyonu ve modern proxy davranışlarını tek yerde birleştirir. Hangi problem çözülüyor? Birçok kurumda iç servis yayınlama şu şekilde büyür: Önce tek bir NGINX konfigürasyonu yazılır. Sonra yeni servisler eklendikçe dosya kalabalıklaşır. Sertifika yenilemeleri ayrı süreç olur. Hangi host'un hangi servise gittiği zor okunur. Traefik ile bu davranış daha deklaratif ve otomatik hâle gelir. Başlangıç mimarisi Minimum uygulanabilir kurulumda şu bileşenler yeterlidir: Bir veya daha fazla entrypoint Dinamik servis keşfi kaynağı TLS resolver Router, middleware ve service tanımları Bu modelin değeri, yeni bir iç servisi yayınlarken tam proxy dosyasını yeniden yazmamakta ortaya çıkar. <Callout type=\"tip\" title=\"İç DNS'i unutmayın\" TLS otomasyonunun düzgün çalışması için iç DNS kayıt yaşam döngüsü ile proxy yayın akışı uyumlu olmalıdır. Sertifikayı otomatikleştirip isim çözümlemeyi manuel bırakmak yeni darboğaz üretir. </Callout Hangi middleware'ler ilk günden eklenmeli? Pratikte en yüksek faydayı şu middleware seti sağlar: HTTP'den HTTPS'e yönlendirme Güvenli başlıklar Basit IP veya ağ erişim kısıtı İstek boyutu sınırı Hata sayfası veya bakım modu yönlendirmesi Bunlar iç servisler için bile önemlidir; çünkü kurum içi ağ güvenli kabul edilse de kontrolsüz değildir. Operasyon tarafında ne kazanılır? Traefik tabanlı model şu açılardan iş kolaylaştırır: Yeni servis yayın süresi kısalır. Sertifika yenilemeleri standartlaşır. Yönlendirme hataları daha görünür olur. Docker, Kubernetes veya dosya tabanlı keşif kaynakları tek modelde buluşur. Sonuç Traefik ile iç servis yayınlama ve TLS otomasyonu, reverse proxy yönetimini daha okunabilir ve sürdürülebilir hâle getirir. Kurumsal ortamlarda asıl değer, yalnızca sertifika yenilemekte değil; iç servislerin güvenli, izlenebilir ve düşük sürtünmeli biçimde yayınlanmasında ortaya çıkar.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "traefik",
        "tls",
        "reverse-proxy",
        "cloud",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/vault-ile-makine-kimligi-yonetimi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/vault-ile-makine-kimligi-yonetimi",
      "title": "Vault ile Makine Kimliği Yönetimi",
      "summary": "Sunucu, servis ve otomasyon kullanıcıları için statik sırlar yerine kısa ömürlü makine kimliği tasarlama rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal altyapılarda en sessiz ama en pahalı risklerden biri, makine kimliklerinin yıllarca değişmeden kullanılan statik sırlarla yönetilmesidir. CI ajanları, backup betikleri, entegrasyon servisleri ve konfigürasyon otomasyonları çoğu zaman bir yerlerde unutulmuş erişim anahtarlarına bağlı yaşar. Bu yapı yalnızca güvenlik sorunu üretmez; aynı zamanda sır rotasyonu, denetim ve servis sahipliği alanlarında da ciddi belirsizlik yaratır. Makine kimliği neden ayrı ele alınmalı? İnsan kullanıcıları için MFA, SSO ve oturum politikaları konuşulur; ancak makineler için aynı disiplin çoğu kurumda eksiktir. Oysa makineler: Çok daha sık erişim ister. Çoğu zaman yüksek yetkiyle çalışır. Parola yerine token, sertifika veya kısa ömürlü sır tüketebilir. Denetim kayıtlarında açık sahiplik bilgisine ihtiyaç duyar. Bu yüzden makine kimliği yönetimini \"secret storage\" problemine indirgemek eksik kalır. Asıl mesele, kimliğin nasıl doğduğu, nasıl doğrulandığı ve nasıl iptal edildiğidir. Vault burada ne rol oynar? Vault, sır saklama ürünü olmanın ötesinde, makine kimlikleri için güvenilen bir aracı katman görevi görebilir. Sağlam bir modelde süreç şu şekilde işler: 1. Makine veya iş yükü güvenilir bir yöntemle kendini doğrular. 2. Vault ilgili rol ve politikalara göre kısa ömürlü token üretir. 3. İstek sahibine gerekli sır veya sertifika geçici olarak verilir. 4. Erişim süresi dolduğunda kimlik doğal olarak geçersizleşir. Bu yaklaşım, depolanan statik anahtar miktarını ciddi biçimde azaltır. Hangi doğrulama yöntemleri uygun? Altyapıya göre farklı yollar seçilebilir: Kubernetes servis hesabı tabanlı auth Bulut instance metadata tabanlı auth AppRole benzeri kontrollü bootstrap modelleri mTLS ile sertifika tabanlı makine doğrulaması Seçim yapılırken ana kriter, otomasyon kolaylığı değil; kimliğin gerçekten çalışma zamanında kanıtlanabilir olmasıdır. <Callout type=\"tip\" title=\"Bootstrap sorununu küçümsemeyin\" Makine ilk token'ını nasıl alacak sorusu net değilse, tasarımın en kritik kısmı eksik kalmıştır. En güvenli model, başlangıç güvenini platformdan alan modeldir; betik içine gömülü statik token değildir. </Callout Politika modeli nasıl tasarlanmalı? Makine kimlikleri için erişim modeli genelde fazla geniş tanımlanır. Bunun yerine şu prensipleri uygulayın: Her servis veya otomasyon için ayrı rol tanımlayın. Politikaları ortam bazında ayırın. Sırları yalnızca gerçekten ihtiyaç duyan yollara açın. Kısa TTL ve yenileme sınırı kullanın. Audit log'ları merkezi gözlem sistemine aktarın. Bu model sayesinde hangi servisin neye eriştiği daha net anlaşılır ve olay incelemeleri hızlanır. Operasyonda en çok fayda nerede görülür? Vault tabanlı makine kimliği yönetimi özellikle şu alanlarda fark yaratır: Sunucu bootstrap sırasında geçici erişim üretimi CI/CD hatlarında kısa ömürlü deployment kimlikleri Veritabanı veya mesaj kuyruğu için dinamik kimlik bilgileri Ayrıcalıklı otomasyon kullanıcılarının denetlenebilir yönetimi Bu kullanım alanlarında statik sırların kaldırılması, hem sızıntı etkisini hem de operasyonel bakım yükünü azaltır. Sık yapılan hatalar Vault'u sadece parola kasası gibi kullanmak Uzun ömürlü root benzeri token'ları otomasyona vermek Audit kaydını kapalı veya dağınık bırakmak Üretim ve test politikalarını aynı rolde toplamak Token yenilemeyi sınırsız bırakmak Bu hatalar, aracı platform kurduğunuzu düşündürür; gerçekte ise sadece sırların yerini değiştirmiş olursunuz. Sonuç Makine kimliği yönetimi, modern altyapının temel güvenlik konularından biridir. Vault ile doğru kurulan bir model; statik sırları azaltır, erişim süresini kısaltır ve denetim izini güçlendirir. Özellikle otomasyon, ERP entegrasyonu ve çoklu ortam yönetimi olan kurumsal yapılarda; makinelere de insanlar kadar ciddi bir kimlik yaşam döngüsü uygulamak artık opsiyon değil, temel mimari gereksinimdir.",
      "date_published": "2026-04-02T00:00:00.000Z",
      "date_modified": "2026-04-02T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "guvenlik",
        "vault",
        "devops",
        "otomasyon",
        "sunucu"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/erp-entegrasyonlarinda-olay-tabanli-mimari",
      "url": "https://mustafaerbay.com.tr/blog/technology/erp-entegrasyonlarinda-olay-tabanli-mimari",
      "title": "ERP Entegrasyonlarında Olay Tabanlı Mimari",
      "summary": "Kurumsal ERP sistemleri çevresinde dayanıklı, izlenebilir ve gevşek bağlı entegrasyon mimarisi kurma rehberi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ERP projelerinde en sık görülen problem, çekirdek sistemin etrafına yıllar içinde doğrudan bağlantılar örülmesidir. Muhasebe, e ticaret, depo, CRM, raporlama ve insan kaynakları aynı veri alanına farklı yöntemlerle dokunur. Sistem çalışıyor gibi görünür; fakat her yeni entegrasyon, karmaşıklığı görünmez biçimde büyütür. Neden doğrudan entegrasyon modeli kırılgan? Nokta nokta entegrasyon modeli kısa vadede hızlıdır; uzun vadede ise pahalıdır. Çünkü: Hata yayılımı kontrolsüz olur. Kaynak sistem üzerinde gereksiz yük oluşur. Sıra, tekrar deneme ve idempotency mantığı her uygulamada yeniden yazılır. Gözlemlenebilirlik parçalanır. Özellikle ERP sistemleri yüksek iş kritikliği taşıdığı için, entegrasyon mimarisi performanstan çok dayanıklılık perspektifiyle ele alınmalıdır. Olay tabanlı mimari ne kazandırır? Olay tabanlı modelde ERP çekirdeği, “bir şey oldu” bilgisini güvenilir biçimde dışarı aktarır. Tüketici sistemler bu olayı bağımsız şekilde işler. Böylece: Üretici ile tüketici zaman açısından gevşek bağlanır. Geçici hatalarda mesaj tekrar işlenebilir. Her entegrasyon için ayrı ölçekleme yapılabilir. İş akışları izlenebilir ve yeniden oynatılabilir. <Callout type=\"info\" title=\"Doğru hedef\" Amaç ERP’yi tamamen olay tabanlı yapmak değil; çekirdek sistem etrafındaki entegrasyon baskısını kontrollü bir arayüz katmanına taşımaktır. </Callout Sağlam bir desen: Outbox + Message Broker Kurumsal sistemlerde en güvenli başlangıç deseni çoğu zaman transactional outbox yaklaşımıdır. Bunun mantığı basittir: 1. ERP işlemi kendi veritabanısında tamamlanır. 2. Aynı işlem içinde bir outbox kaydı oluşturulur. 3. Ayrı bir yayınlayıcı süreç bu kayıtları mesaj broker’a taşır. 4. Tüketiciler olayları bağımsız şekilde işler. Bu desen, “veri yazıldı ama olay yayınlanamadı” ya da tersi gibi tutarsızlık risklerini azaltır. Hangi olaylar yayınlanmalı? Her alan değişikliği bir olay olmak zorunda değildir. Kurumsal teknoloji mimarisinde iyi olay tasarımı şu nitelikleri taşır: İş anlamı vardır. Tüketiciler için yeniden kullanılabilir. Versiyonlanabilir. Kişisel veya hassas veri minimum tutulur. Örnekler: SiparisOnaylandi FaturaKesildi StokRezervasyonuTamamlandi CariHesapLimitiGuncellendi İzlenebilirlik ve hata yönetimi Olay tabanlı sistemlerde başarı yalnızca mesajın yayınlanması değildir. Her adım izlenmelidir: Olay üretildi mi? Broker’a başarıyla yazıldı mı? Tüketici kaç kez denedi? Dead letter kuyruğuna düştü mü? İş etkisi hangi kayıtları etkiledi? Bu nedenle correlation ID, olay kimliği ve iş emri numarası gibi alanlar standardize edilmelidir. ERP dünyasında dikkat edilmesi gereken sınırlar Gerçek hayatta bazı ERP sistemleri eski sürücüler, dosya tabanlı aktarım mekanizmaları veya kısıtlı API yetenekleri taşır. Böyle durumlarda olay tabanlı mimariyi idealleştirmek yerine pragmatik bir ara katman kurmak daha doğrudur: Kaynak sistemden değişiklikleri toplayan entegrasyon servisi Normalizasyon ve zenginleştirme katmanı Mesaj broker Tüketici servisler Bu yaklaşım, çekirdek ERP’ye minimum müdahale ile modern entegrasyon davranışı kazandırır. Sonuç ERP entegrasyonlarında ölçek sorunu çoğu zaman işlem hacminden değil, bağımlılık biçiminden kaynaklanır. Olay tabanlı mimari; doğru olay modeli, outbox deseni ve güçlü gözlemlenebilirlik ile birlikte uygulandığında çekirdek sistem üzerindeki baskıyı azaltır ve kurumsal mimariyi daha dayanıklı hâle getirir. En iyi sonuç, teknoloji modasına değil iş akışlarının kırılgan noktalarına odaklanıldığında elde edilir.",
      "date_published": "2026-04-01T00:00:00.000Z",
      "date_modified": "2026-04-01T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "erp",
        "entegrasyon",
        "event-driven",
        "sistem-mimarisi",
        "dayanıklılık"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/hibrit-bulutta-landing-zone-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/hibrit-bulutta-landing-zone-tasarimi",
      "title": "Hibrit Bulutta Landing Zone Tasarımı",
      "summary": "Kurumsal bulut geçişlerinde ağ, güvenlik ve yönetişimi baştan doğru kurmak için landing zone yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Buluta geçişte en maliyetli yanlışlardan biri, ilk iş yüklerini hızlıca ayağa kaldırıp temel yönetişim kararlarını sonraya bırakmaktır. Bu yaklaşım kısa vadede hız kazandırır; birkaç ay içinde ise ağ karmaşası, hesap dağınıklığı, rol çakışmaları ve görünmeyen güvenlik açıkları üretir. Landing zone tasarımı, bulutu yalnızca kaynak açılan bir platform değil, kurumsal mimarinin kontrollü genişleme alanı olarak ele alır. Landing zone aslında neyi çözer? Landing zone, tek bir şablon veya tek bir Terraform modülü değildir. Esas amacı, yeni iş yüklerinin güvenli ve standart bir tabanda doğmasını sağlamaktır. Bunun için şu alanlarda başlangıç kuralları tanımlar: Hesap ve abonelik hiyerarşisi Ağ topolojisi Kimlik ve yetki modeli Loglama ve güvenlik zorunlulukları Politika denetimleri Yedekleme ve felaket kurtarma varsayımları Kurumsal ölçekte bu kurallar yoksa her proje kendi mini platformunu kurar ve toplam teknoloji borcu hızla artar. Hibrit bulut için neden daha kritik? Sadece public cloud kullanan yapılarda bile yönetişim zordur; hibrit bulutta zorluk ikiye katlanır. Çünkü veri merkezi, MPLS/VPN bağlantıları, mevcut güvenlik duvarları, eski kimlik sistemleri ve ERP bağımlılıkları da tasarımın bir parçasıdır. Burada landing zone şunları netleştirmelidir: On prem ile bulut arasındaki trafik hangi merkezî güvenlik noktasından geçecek? DNS, kimlik ve sertifika yaşam döngüsü nerede yönetilecek? Hangi veri sınıfları bulutta tutulabilir, hangileri yalnızca kurum içinde kalır? Gözlemlenebilirlik verisi tek yerde mi toplanacak, bölgesel olarak mı ayrılacak? İyi bir landing zone’un temel bileşenleri 1. Kimlik ve erişim modeli İnsan erişimi, servis erişimi ve acil durum erişimi birbirinden ayrılmalıdır. Özellikle ayrıcalıklı roller için geçici yükseltme ve kayıtlı erişim akışı kritik öneme sahiptir. 2. Ağ omurgası Paylaşımlı servisler, uygulama ağları ve yönetim erişimi aynı segmentte olmamalıdır. Transit gateway, hub spoke veya eşdeğer topolojiler seçilirken yalnızca teknik sadelik değil, denetlenebilir akış hedeflenmelidir. 3. Politika motoru Etiketsiz kaynak açılmaması, genel internete açık disk snapshot’larının engellenmesi, log üretmeyen hesapların uyarılması gibi kurallar baştan otomatikleştirilmelidir. 4. Ortak gözlemlenebilirlik Landing zone yalnızca kaynak yaratma standardı değildir; tüm hesapların log, metric ve güvenlik olaylarını ortak bir izleme modeline bağlamalıdır. <Callout type=\"tip\" title=\"Doğru sıra\" Landing zone çalışmasını yalnızca altyapı takımı projesi olarak değil, güvenlik, ağ ve uygulama sahiplerini kapsayan kurumsal mimari programı olarak yönetin. </Callout ERP ve kurumsal çekirdek sistemler için özel not Birçok bulut geçişi, web uygulamalarına odaklanırken ERP çevresindeki bağlantı kalıplarını hafife alır. Oysa gerçek karmaşıklık genellikle burada ortaya çıkar: Lisans veya ağ bağımlılığı olan uygulama sunucuları Kurum içi veritabanısına bağımlı entegrasyon servisleri Dosya aktarımı veya zamanlanmış batch akışları Regülasyon gereği kurum dışına çıkamayan veri kümeleri Landing zone tasarımı bu gerçekleri baştan modellemezse, sonradan istisna katmanlarıyla bozulur. Başlangıç için uygulanabilir prensipler 1. Üretim, üretim dışı ve paylaşımlı servis hesaplarını ayırın. 2. Tüm kaynaklar için zorunlu etiket standardı tanımlayın. 3. Merkezî loglama, SIEM ve alarm yönlendirmesini ilk günden aktif edin. 4. Ağ geçişlerini belgeleyin; “sonradan firewall açarız” yaklaşımını reddedin. 5. Bulut politikalarını denetim sonrası değil, dağıtım anında uygulayın. Sonuç Landing zone tasarımı, bulut geçişinin görünmeyen temelidir. Doğru kurulduğunda ekiplerin hızını kesmez; aksine her yeni iş yükünün tekrar tartışılmasını önleyerek hız kazandırır. Özellikle hibrit mimariler, ERP bağımlılıkları ve kurumsal güvenlik gereksinimleri olan yapılarda, sağlam bir landing zone olmadan sürdürülebilir bulut mimarisi kurmak zordur.",
      "date_published": "2026-04-01T00:00:00.000Z",
      "date_modified": "2026-04-01T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "cloud",
        "landing-zone",
        "hibrit-bulut",
        "güvenlik",
        "yönetişim"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kubernetes-platformunda-maliyet-yonetimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kubernetes-platformunda-maliyet-yonetimi",
      "title": "Kubernetes Platformunda Maliyet Kontrollü Tasarım",
      "summary": "Bulut üzerinde ölçeklenebilir ama bütçe disiplini koruyan Kubernetes platform mimarisi için pratik ilkeler.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Bulutta Kubernetes kullanmak çoğu ekip için teknik bir başarı gibi görünür; fakat birkaç ay sonra fatura kalemleri incelendiğinde asıl sınav başlar. Ölçeklenebilirlik sağlanmıştır ama maliyet davranışı öngörülemez hâle gelmiştir. Sağlıklı platform mimarisi, performans ile bütçe disiplini arasında bilinçli bir denge kurar. Maliyet neden sadece bulut ekibinin problemi değildir? Kubernetes maliyetleri tek bir satırdan oluşmaz: Node maliyetleri Kalıcı disk ve snapshot giderleri Load balancer ve ağ geçidi ücretleri Gözlemlenebilirlik veri hacmi Boşta duran test ve geçici ortamlar Platform ekibi bu kalemleri yönetir; ancak asıl tüketimi uygulama davranışı belirler. Bu yüzden FinOps yaklaşımı platform tasarımına gömülmelidir. Dört katmanlı maliyet kontrol modeli 1. Hesaplama katmanı Node havuzlarını iş yükü tipine göre ayırın. Her iş yükünü aynı instance ailesine koymak pratik görünür ama pahalıdır. Tipik ayrım şu şekilde olabilir: Genel amaçlı uygulamalar Yoğun CPU kullanan batch işleri Bellek ağırlıklı entegrasyon servisleri Spot veya preemptible node üzerinde çalışabilecek toleranslı işler 2. Planlama katmanı Kaynak istekleri (requests) ve limitler (limits) maliyet üzerinde doğrudan etkilidir. Gerçek kullanım ölçülmeden yazılan konservatif değerler, kümede görünmez kapasite israfı yaratır. 3. Otomasyon katmanı Cluster autoscaler, node auto provisioning veya Karpenter gibi çözümler maliyet azaltır; ancak yalnızca doğru etiketleme ve iş yükü sınıflaması varsa çalışır. 4. Yaşam döngüsü katmanı Preview environment, kısa ömürlü test kümeleri ve haftalarca açık kalan PoC ortamları çoğu zaman ana maliyet kaçağıdır. Otomatik kapanış politikaları olmazsa bütçe disiplini kurulamaz. <Callout type=\"warning\" title=\"Sık hata\" Kubernetes maliyet optimizasyonu yalnızca daha küçük node seçmek değildir. Yanlış küçültme, performans sorunları ve yeni operasyon maliyetleri üretir. </Callout Gözlemlenebilirlik olmadan optimizasyon yapılamaz Bir kümede hangi namespace’in, hangi takımın, hangi servisin ne kadar maliyet ürettiği görünmüyorsa yönetim tahmine dayanır. Bu nedenle: Namespace bazlı sahiplik etiketleri zorunlu olmalı CPU ve bellek kullanım trendleri tutulmalı Boşta çalışan workload’lar raporlanmalı Egress ve load balancer maliyetleri ayrı izlenmeli Kubernetes’te maliyet görünürlüğü yalnızca finansal rapor için değil, mimari kararların geri bildirimi için de gereklidir. Kurumsal iş yükleri için önerilen yaklaşım ERP entegrasyonları, arka plan kuyrukları ve API ağ geçitleri aynı kümede çalışabilir; fakat aynı kaynak politikasına sahip olmamalıdır. Örneğin: ERP senkronizasyon işleri zaman pencereli ve önceliklidir. Web API’ler sürekli yanıt süresi hedefi taşır. Raporlama işleri yoğun kaynak tüketebilir ama ertelenebilir. Bu ayrımı priorityClass, taint/toleration ve ayrı node havuzları ile ifade etmek, hem güvenilirlik hem maliyet açısından daha doğru sonuç verir. Uygulanabilir optimizasyon listesi 1. Her namespace için sahiplik, ortam ve maliyet merkezi etiketlerini zorunlu kılın. 2. Son 30 günlük gerçek kullanıma göre request/limit değerlerini gözden geçirin. 3. Spot kapasiteye taşınabilecek işler için ayrı havuz açın. 4. Çalışma saatleri dışında kapanabilecek ortamları planlı olarak durdurun. 5. Gözlemlenebilirlik veri hacmini saklama politikasına göre sınırlayın. Sonuç Kubernetes platformu pahalı olduğu için değil, kontrolsüz büyüdüğü için bütçeyi zorlar. Başlangıçta doğru node stratejisi, iş yükü sınıflaması ve yaşam döngüsü otomasyonu kurulduğunda hem geliştirici hızını hem de maliyet öngörülebilirliğini korumak mümkündür. Sağlam platform mühendisliği, kapasiteyi yalnızca artırmak değil; ne zaman, neden ve kimin için artırdığını görünür kılmaktır.",
      "date_published": "2026-04-01T00:00:00.000Z",
      "date_modified": "2026-04-01T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "kubernetes",
        "cloud",
        "finops",
        "platform-mühendisliği",
        "sunucu-altyapısı"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-zero-trust-mimarisi",
      "url": "https://mustafaerbay.com.tr/blog/technology/kurumsal-aglarda-zero-trust-mimarisi",
      "title": "Kurumsal Ağlarda Zero Trust Mimarisi",
      "summary": "Kurumsal ağlarda Zero Trust yaklaşımını kimlik, segmentasyon ve gözlem katmanlarıyla nasıl kurabilirsiniz?",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import zeroTrustVisual from './kurumsal aglarda zero trust mimarisi.svg'; Zero Trust, sadece güvenlik ürünü seçimi değil, ağın varsayılan davranışını değiştiren bir mimari karardır. Kurumsal yapılarda asıl fark, iç ağın artık otomatik olarak güvenilir kabul edilmemesidir. <figure <Image src={zeroTrustVisual} alt=\"Kurumsal ağlarda Zero Trust mimarisini anlatan teknik şema\" / <figcaption Kimlik, politika, segmentasyon ve gözlem katmanlarının birlikte çalıştığı temel Zero Trust akışı.</figcaption </figure Zero Trust neden kurumsal yapıda kritiktir? Klasik modelde kullanıcı VPN ile içeri girdikten sonra fazla geniş erişim alır. Bu yaklaşım özellikle ERP, dosya sunucuları, yedekleme altyapısı ve yönetim ağları aynı omurgada yaşıyorsa ciddi risk üretir. Zero Trust modelinde ise şu sorular her istekte yeniden sorulur: 1. Bu isteği yapan kim? 2. Bu cihaz şu anda güvenilir durumda mı? 3. Kullanıcının rolü gerçekten bu kaynağa erişmeli mi? 4. Bu trafik hangi segmentten geliyor? 5. O anki davranış normal mi, yoksa anomali mi? Temel katmanlar 1. Kimlik ve MFA Zero Trust'ın kalbi kimliktir. Active Directory, Entra ID, Okta veya benzeri bir kimlik sağlayıcısı, kullanıcının sadece giriş yaptığını değil, hangi rolde olduğunu ve hangi kaynaklara hangi şartlarda erişebileceğini belirler. 2. Cihaz durumu Erişim kararı sadece kullanıcı adına göre verilmemeli. Cihazda disk şifreleme kapalıysa, EDR ajanı çalışmıyorsa veya patch seviyesi düşükse erişim seviyesi düşürülmelidir. 3. Mikro segmentasyon ERP, yönetim ağları, izleme platformları, yedekleme sistemleri ve internet facing servisler aynı güven seviyesinde tutulmamalı. Her biri ayrı güven bölgesi gibi davranmalıdır. 4. Sürekli gözlem SIEM, NDR ve merkezi log akışı olmadan Zero Trust yarım kalır. Politika koymak kadar o politikanın nasıl davrandığını görmek de gerekir. <Callout type=\"warning\" title=\"En sık yapılan hata\" Kurumsal yapılarda en sık hata, MFA ekleyip tüm yapıya Zero Trust denmesidir. Eğer segmentasyon ve görünürlük yoksa bu sadece giriş katmanını güçlendirmiş olur. </Callout Uygulama sırası nasıl olmalı? Benim önerdiğim kurulum sırası genellikle şöyledir: 1. Kimlik kaynaklarını sadeleştir. 2. Ayrı erişim profilleri oluştur. 3. Kritik sunucuları mikro segmentlere ayır. 4. Yönetim erişimini ayrı katmana taşı. 5. Log ve olay korelasyonunu merkezi hale getir. 6. Düşük riskli servislerde pilot başlat. Bu sıra, özellikle canlı ERP ve üretim ortamlarında kesinti riskini azaltır. Gerçek dünyada dikkat ettiğim mimari prensipler Yönetim erişimi kullanıcı erişiminden ayrı tasarlanmalı. Yedekleme ağı hiçbir zaman genel kullanıcı ağıyla aynı güven alanında olmamalı. Güvenlik politikası sadece ofis için değil, uzak çalışma senaryosu için de tasarlanmalı. Her politika, olay incelemesini kolaylaştıracak log üretmeli. \"Allow any internal\" yaklaşımı tamamen kaldırılmalı. Sonuç Zero Trust, büyük yapılarda güvenlik ekibinin değil tüm altyapı mimarisinin konusu haline gelmelidir. Kimlik, ağ ve sistem katmanları tek karar düzleminde buluştuğunda hem güvenlik artar hem de operasyon daha öngörülebilir hale gelir.",
      "date_published": "2026-04-01T00:00:00.000Z",
      "date_modified": "2026-04-01T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "zero-trust",
        "network",
        "security",
        "mimari",
        "cloud",
        "kurumsal"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/zero-trust-ag-segmentasyonu",
      "url": "https://mustafaerbay.com.tr/blog/technology/zero-trust-ag-segmentasyonu",
      "title": "Zero Trust Ağ Segmentasyonu ile Kurumsal Savunma",
      "summary": "Kurumsal ağlarda yatay hareketi azaltan, gözlemlenebilir ve uygulanabilir Zero Trust segmentasyon yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Kurumsal ağların en büyük problemi, bir kez içeri sızan bir aktörün yanal hareket için çok fazla alana sahip olmasıdır. Zero Trust yaklaşımı tam olarak burada devreye girer: ağın içinde olmak güvenilir olmak anlamına gelmez. Her akış, her servis ve her kimlik yeniden doğrulanır; erişim olabilecek en dar sınırda tutulur. Neden klasik VLAN yaklaşımı artık yetmiyor? Uzun yıllar boyunca ağ güvenliği, çevre güvenliği etrafında tasarlandı. DMZ, iç ağ, sunucu ağı ve kullanıcı ağı gibi büyük güven bölgeleri oluşturuldu. Bu model bugün üç sebeple kırılıyor: İş yükleri artık yalnızca veri merkezinde yaşamıyor; bulut, hibrit bağlantılar ve SaaS servisleri sürekli yeni akışlar üretiyor. Kullanıcılar ofiste değil; VPN, ZTNA ve uzaktan erişim katmanları ağ sınırını bulanıklaştırıyor. Uygulama bağımlılıkları çok daha karmaşık; ERP, kimlik servisleri, log toplama, mesajlaşma ve API katmanları birbirine yoğun şekilde bağlı. Sonuç olarak tek bir “iç ağ” varsayımı, saldırgana gereğinden fazla hareket alanı bırakıyor. Zero Trust segmentasyonun temel prensipleri Sağlam bir segmentasyon tasarımı ürün bazlı değil, ilke bazlı kurulmalıdır: 1. Kimlik merkezli erişim : Kaynak IP yerine servis hesabı, cihaz durumu ve kullanıcı kimliği değerlendirilir. 2. En az ayrıcalık : Her akış için sadece gereken port, protokol ve yön açılır. 3. Varsayılan reddetme : Yeni bir servis eklendiğinde erişim otomatik açılmaz. 4. Sürekli gözlemlenebilirlik : Politika ihlalleri, reddedilen akışlar ve olağan dışı trafik merkezi olarak izlenir. 5. İş kritikliği farkındalığı : ERP veritabanısı ile test ortamı aynı risk seviyesinde ele alınmaz. <Callout type=\"info\" title=\"Pratik yaklaşım\" Zero Trust geçişi tek seferlik büyük bir dönüşüm değil, akış haritalama ve kademeli sıkılaştırma programıdır. </Callout Kurumsal ortamda segmentasyon katmanları Başarılı bir tasarımda tek bir segmentasyon katmanı yoktur. Birkaç katman birlikte çalışır: 1. Ortam segmentasyonu Üretim, test, geliştirme ve yönetim ağları fiziksel ya da mantıksal olarak ayrılır. Bu ayrım, yanlış yapılandırma veya kimlik kötüye kullanımında zincirleme etkiyi azaltır. 2. Uygulama segmentasyonu Aynı ortam içindeki servisler de birbirinden ayrılır. Örneğin: Web katmanı yalnızca uygulama katmanına erişir. Uygulama katmanı yalnızca gerekli veritabanısı portlarına erişir. Gözlemleme ajanları yalnızca telemetri uç noktalarına veri gönderir. 3. Yönetim düzlemi segmentasyonu SSH, RDP, Kubernetes API, hypervisor yönetimi ve yedekleme arayüzleri ayrı bir güven düzleminde tutulmalıdır. En sık ihmal edilen ama en kritik katman budur. Uygulamaya geçmeden önce çıkarılması gereken envanter Segmentasyon projeleri genellikle teknoloji seçiminde değil, eksik envanter nedeniyle başarısız olur. Başlamadan önce şu soruların net cevabı olmalıdır: Hangi servis hangi servise hangi porttan bağlanıyor? Bu akışın iş sahibi kim? Akış sürekli mi, zamanlanmış mı, yalnızca bakım penceresinde mi gerekli? Bu bağlantı kesilirse hangi iş süreci etkilenir? Erişim uygulama seviyesinde çözülebilir mi, yoksa ağ seviyesi kontrol gerçekten gerekli mi? Bu çalışma için NetFlow, VPC Flow Logs, güvenlik duvarı logları ve servis keşif verileri birlikte okunmalıdır. ERP ve kurumsal çekirdek sistemler için özel durum ERP altyapıları segmentasyon açısından daha hassastır çünkü hem eski protokoller barındırır hem de çok sayıda entegrasyona sahiptir. Burada iyi bir pratik, sistemi üç bölüme ayırmaktır: Kullanıcı erişim katmanı Uygulama işlem katmanı Veri ve entegrasyon katmanı SAP, Logo, Mikro, özel geliştirilmiş finans uygulamaları veya insan kaynakları servisleri aynı mantıkla ele alınabilir. Entegrasyon sunucularını doğrudan çekirdek veritabanı segmentine almak yerine kontrollü bir servis ara katmanı kullanmak, risk yüzeyini ciddi biçimde küçültür. Başlangıç için uygulanabilir yol haritası Kurumsal bir ekip için gerçekçi geçiş planı şu sırayla ilerler: 1. Akışları görünür kılın ve 30 günlük baz çizgi çıkarın. 2. Üretim dışı ortamlarda varsayılan reddetme modelini deneyin. 3. Yönetim düzlemini ayrı bir erişim politikası altına alın. 4. Kritik uygulamaları mikro segmentasyon kuralları ile daraltın. 5. Politika ihlallerini SIEM ve alarm sistemine bağlayın. Zero Trust ağ segmentasyonu, güvenlik ekibinin tek başına yürüteceği bir güvenlik projesi değildir. Ağ, sistem, uygulama ve iş ekiplerinin birlikte yönettiği bir mimari disiplin olarak ele alındığında sürdürülebilir olur. Asıl hedef bütün kapıları kapatmak değil, yalnızca gerekli kapıları görünür ve savunulabilir hâle getirmektir.",
      "date_published": "2026-04-01T00:00:00.000Z",
      "date_modified": "2026-04-01T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "zero-trust",
        "network",
        "güvenlik",
        "mikro-segmentasyon",
        "kurumsal-mimari"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/linux-sunucularda-immutable-altyapi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/linux-sunucularda-immutable-altyapi",
      "title": "Linux Sunucularda Immutable Altyapı Disiplini",
      "summary": "Sunucu yapılandırmalarını el emeğinden çıkarıp güvenli ve tekrarlanabilir otomasyon akışına dönüştürme yaklaşımı.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Sunucu yönetiminde en pahalı alışkanlıklardan biri, canlı sistemler üzerinde el ile değişiklik yapmaktır. Sorun yalnızca operasyonel hata riski değildir; aynı zamanda hangi sunucunun ne zaman, neden farklılaştığını izleyememektir. Immutable altyapı yaklaşımı, bu belirsizliği azaltmak için sistemleri “yerinde düzeltmek” yerine “yeniden üretmek” prensibiyle ele alır. Immutable yaklaşım neyi değiştirir? Geleneksel modelde bir sunucu kurulur, zamanla yamalanır, paket eklenir, konfigürasyonlar canlıda düzeltilir ve birkaç ay sonra tam olarak nasıl bu hâle geldiği belirsizleşir. Immutable modelde ise: Temel imaj tanımlıdır. Konfigürasyon kodla üretilir. Değişiklik yeni artefact üretir. Dağıtım, mevcut sunucuyu dönüştürmek yerine yeni örnek başlatır. Bu yaklaşım özellikle güvenlik, denetlenebilirlik ve felaket kurtarma açısından ciddi avantaj sağlar. Hangi katmanlar kodla yönetilmeli? Pratikte immutable disiplin şu alanları kapsamalıdır: 1. İmaj üretimi : Packer veya benzeri araçlarla standart taban imajları. 2. Altyapı tanımı : Terraform, Pulumi veya eşdeğeri ile ağ, disk, güvenlik grupları. 3. Bootstrap akışı : Cloud init, systemd unit’leri veya güvenli başlangıç betikleri. 4. Dağıtım mekanizması : Rolling, blue/green veya canary stratejileri. <Callout type=\"tip\" title=\"Önemli ayrım\" Immutable olmak, hiçbir zaman değişiklik yapmamak değil; değişikliği tanımlı boru hattı dışında yapmamaktır. </Callout Güvenlik açısından neden değerlidir? Canlı sistemlere manuel müdahale azaldıkça saldırı yüzeyi de azalır. Özellikle şu faydalar belirgindir: Yetkili kullanıcıların kalıcı değişiklik yapma ihtiyacı azalır. Drift tespiti kolaylaşır. Güvenlik yamaları yeni imaj üretimi ile kontrollü yayılır. İnceleme ve rollback süreçleri standartlaşır. Kurumsal altyapılarda bu model, audit süreçlerini de basitleştirir çünkü “mevcut durum” yerine “tanımlı durum” esas alınır. Nereden başlanmalı? Tam dönüşüm çoğu ekip için bir anda mümkün değildir. Başlangıç için şu sıra etkilidir: Önce kritik olmayan yardımcı servisleri immutable boru hattına taşıyın. Temel işletim sistemi sertleştirmesini imaj seviyesinde standardize edin. Kullanıcı açma, paket yükleme ve ajan kurulumunu canlı erişimden çıkarın. Dağıtım sırasında sağlık kontrolü ve otomatik geri dönüş ekleyin. Sunucu altyapılarında sık yapılan hata Birçok ekip immutable hedefini yalnızca container dünyasıyla ilişkilendirir. Oysa sanal makine tabanlı yapılarda, hatta bare metal yaşam döngülerinde bile aynı prensipler uygulanabilir. Asıl mesele teknoloji seçimi değil, değişikliğin kaynağını kontrol etmektir. Sonuç Linux sunucularda immutable altyapı disiplini; güvenlik, operasyon ve standartlaşma arasında güçlü bir ortak zemin kurar. Manuel düzeltmeleri azaltıp üretilebilir sistemler tasarladığınızda, yalnızca hata oranını düşürmezsiniz; aynı zamanda ölçeklenebilir bir operasyon modeli kurarsınız. Kurumsal yapılarda sürdürülebilirlik çoğu zaman yeni araçlardan değil, değişikliğin nereden ve nasıl yapıldığını netleştirmekten gelir.",
      "date_published": "2026-04-01T00:00:00.000Z",
      "date_modified": "2026-04-01T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "linux",
        "otomasyon",
        "infrastructure-as-code",
        "güvenlik",
        "devops"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/opentelemetry-ile-observability-pipeline",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/opentelemetry-ile-observability-pipeline",
      "title": "OpenTelemetry ile Uçtan Uca Observability Pipeline",
      "summary": "Metric, log ve trace verisini tek standarda taşıyan OpenTelemetry tabanlı gözlemlenebilirlik mimarisi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Modern sistemlerde “log var, metric var” demek yeterli değil. Bir incident sırasında cevap aranan soru şudur: aynı isteğin servisler arasındaki hareketini, gecikmesini ve hata nedenini tek bir akış olarak görebiliyor muyuz? OpenTelemetry bu problemi çözmek için ortaya çıkan ortak standarttır. Neden tek araç değil, ortak bir telemetry standardı? Kurumsal ortamlarda telemetry verisi çoğu zaman parçalıdır: Uygulama ekipleri APM kullanır. Sistem ekipleri node exporter ve sistem metriklerini toplar. Güvenlik ekipleri ayrı log hatlarına sahiptir. Platform ekipleri Kubernetes olaylarını başka yerde izler. Bu parçalı yapı, özellikle hibrit mimarilerde kök neden analizini yavaşlatır. OpenTelemetry’nin değeri, veriyi tek ürün altında toplamasında değil; üretim biçimini standartlaştırmasındadır. Temel mimari Pratik ve sürdürülebilir bir observability pipeline şu bileşenlerden oluşur: 1. Instrumentation katmanı : Uygulama içine trace ve metric üretimi eklenir. 2. Collector katmanı : Veriler uygulamalardan merkezi toplayıcıya akar. 3. Processor katmanı : Örnekleme, etiket temizleme, zenginleştirme ve routing yapılır. 4. Exporter katmanı : Veriler Prometheus, Tempo, Loki, Elastic veya başka hedeflere aktarılır. Bu modelin avantajı, backend değişse bile uygulama kodunun büyük ölçüde sabit kalmasıdır. Collector neden kritik? Collector kullanmadan doğrudan backend’e veri göndermek küçük sistemlerde işe yarayabilir. Fakat kurumsal ölçekte collector şarttır çünkü: Servis keşfi ve çoklu backend yönlendirmesi yapabilir. Hassas alanları maskeleyebilir. Maliyet yönetimi için örnekleme uygulayabilir. Log, metric ve trace verisini farklı hedeflere ayırabilir. <Callout type=\"tip\" title=\"Öneri\" Collector katmanını uygulama ekiplerinden bağımsız yönetin. Böylece veri yönlendirme ve politika değişiklikleri kod dağıtımı gerektirmez. </Callout Başlangıç için örnek pipeline Aşağıdaki yaklaşım, orta ölçekli bir platform için iyi bir başlangıçtır: Uygulamalar OTLP üzerinden collector’a veri yollar. Collector trace verisini Tempo’ya, metric verisini Prometheus uyumlu hedefe, log verisini Loki’ye iletir. Tüm sinyallerde ortak etiket standardı kullanılır: service.name, deployment.environment, team, region. Etiket standardı olmadan observability eksik kalır Birçok ekip telemetry toplamaya odaklanır ama veri modelini ihmal eder. Oysa etiket standardı yoksa sorgulanabilirlik zayıf kalır. Özellikle şu alanlar kurumsal mimaride kritik önem taşır: Servis adı Ortam bilgisi Bölge veya veri merkezi Takım sahipliği Uygulama kritikliği Bu alanlar hem dashboard tasarımını hem de alarm yönlendirmesini doğrudan etkiler. Log, metric ve trace birlikte nasıl okunur? Sağlam bir incident akışında ekip şu sırayla hareket eder: 1. Alarm metric tabanlı tetiklenir. 2. İlgili servis trace görünümünde hangi downstream çağrılarda bozulma olduğunu gösterir. 3. Aynı trace veya request kimliği ile uygulama logları açılır. 4. Gerekirse node ve container seviyesi metric’lerle kapasite baskısı doğrulanır. Bu zincir kurulmadığında ekipler aynı sorunu üç farklı ekrandan ayrı ayrı çözmeye çalışır. Güvenlik ve maliyet dengesi Observability sistemi de bir veri platformudur; dolayısıyla maliyet ve veri koruma sınırları net olmalıdır: PII alanları collector üzerinde maskeleyin. Her ortam için farklı örnekleme politikası uygulayın. Yüksek hacimli debug loglarını varsayılan olarak merkezi sisteme taşımayın. Veri saklama sürelerini iş ve regülasyon gereksinimlerine göre ayırın. Sonuç OpenTelemetry, tek başına sihirli bir araç değil; telemetry disiplinini standartlaştıran bir kontrol noktasıdır. Doğru kurulduğunda platform ekiplerine bağımsızlık, uygulama ekiplerine tutarlılık ve operasyon ekiplerine daha hızlı teşhis imkânı verir. Özellikle dağıtık servisler, ERP entegrasyonları ve hibrit altyapılar için uçtan uca görünürlük artık lüks değil, işletme gereksinimidir.",
      "date_published": "2026-04-01T00:00:00.000Z",
      "date_modified": "2026-04-01T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "observability",
        "opentelemetry",
        "devops",
        "monitoring",
        "logging"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/cloudflare-tunnel-ve-reverse-proxy-rehberi",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/cloudflare-tunnel-ve-reverse-proxy-rehberi",
      "title": "Cloudflare Tunnel ve Reverse Proxy Rehberi",
      "summary": "Cloudflare Tunnel ile origin IP saklayarak güvenli reverse proxy yapısını nasıl kurabilirsiniz?",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import tunnelVisual from './cloudflare tunnel ve reverse proxy rehberi.svg'; Cloudflare Tunnel, özellikle dış dünyaya doğrudan port açmak istemediğim yapılarda en çok tercih ettiğim yayın katmanlarından biri. Özellikle ERP, yönetim paneli, iç servisler ve özel dashboard'larda hem güvenlik hem de operasyonel sadelik sağlar. <figure <Image src={tunnelVisual} alt=\"Cloudflare Tunnel ve reverse proxy mimarisini anlatan akış diyagramı\" / <figcaption Cloudflare Edge, cloudflared ve origin servislerin birlikte çalıştığı güvenli yayın modeli.</figcaption </figure Neden klasik port yönlendirme yerine Tunnel? Klasik modelde servis, firewall veya router üzerinden internete açılır. Bu hem origin IP'yi görünür hale getirir hem de doğrudan saldırı yüzeyi oluşturur. Tunnel yaklaşımında ise: dış dünyadan içeri inbound port açılmaz origin IP görünmez TLS, WAF ve Access politikaları edge katmanında uygulanır servis yayınlama ve geri alma operasyonu çok daha kontrollü hale gelir Kurulum mantığı Temel akış şu şekildedir: 1. Sunucuya cloudflared kurulur. 2. Tünel Cloudflare hesabına bağlanır. 3. DNS kaydı tunnel'a yönlendirilir. 4. Reverse proxy katmanı Nginx veya doğrudan servis olabilir. 5. Gerekirse Cloudflare Access ile kimlik kontrollü erişim eklenir. Örnek yaklaşım Ardından örnek bir config.yml: Reverse proxy ile birlikte kullanım Ben çoğu zaman içeride yine bir Nginx katmanı tutuyorum. Bunun iki büyük avantajı var: 1. Uygulama loglarını servis bazlı ayrıştırmak kolaylaşıyor. 2. İç ağda da tutarlı bir yönlendirme katmanı oluşuyor. Nginx örneği: <Callout type=\"tip\" title=\"Pratik yaklaşım\" Uygulama doğrudan internete açılmıyorsa, bakım pencerelerinde erişim katmanını yönetmek çok daha kolay olur. Özellikle staging ve test servislerinde bu ciddi rahatlık sağlar. </Callout Hangi senaryolarda çok faydalı? ERP veya yönetim paneli yayınlamak Uzak ekipler için güvenli dashboard erişimi vermek Geçici PoC ortamlarını hızla yayınlamak İç API'leri Access politikaları ile korumak Origin IP'yi dış dünyadan tamamen saklamak Dikkat edilmesi gereken noktalar Sadece Tunnel kurmak yetmez, Access politikası da düşünülmeli. Origin sunucuda yerel firewall yine aktif olmalı. Log akışı hem Cloudflare hem origin tarafında tutulmalı. Tekil servislerde health check ve timeout davranışları test edilmeli. Sonuç Cloudflare Tunnel, doğru kullanıldığında sadece kolay bir yayın aracı değil, ciddi bir güvenlik ve operasyon standardı haline gelir. Özellikle port açmadan servis yayınlama fikri, modern altyapılarda çok değerli bir katman sunar.",
      "date_published": "2026-03-31T00:00:00.000Z",
      "date_modified": "2026-03-31T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "cloudflare",
        "tunnel",
        "reverse-proxy",
        "nginx",
        "security",
        "tutorial"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/tutorials/astro-ile-blog-olusturma",
      "url": "https://mustafaerbay.com.tr/blog/tutorials/astro-ile-blog-olusturma",
      "title": "Astro ile Modern Blog Oluşturma",
      "summary": "Astro framework ile hızlı, SEO-uyumlu ve performanslı bir blog nasıl oluşturulur.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Astro, içerik odaklı web siteleri için ideal bir framework. Zero JavaScript varsayılan yaklaşımı ile kusursuz performans sunar. Neden Astro? Astro'yu diğer frameworklerden ayıran özellikler: 1. Zero JS by default : Sayfalarınız saf HTML olarak sunulur 2. Island Architecture : Sadece interaktif bölümler JS yükler 3. Content Collections : Tip güvenli içerik yönetimi 4. Çoklu framework desteği : React, Vue, Svelte birlikte kullanılabilir <Callout type=\"info\" title=\"Performans\" Astro ile oluşturulan siteler, varsayılan olarak 100/100 Lighthouse puanına yaklaşır. </Callout Proje Kurulumu Yeni bir Astro projesi oluşturmak çok basit: Content Collections Astro'nun en güçlü özelliklerinden biri Content Collections: Bu yapıyla tüm içerikleriniz build time'da validate edilir. Cloudflare Pages ile Deploy Astro projenizi Cloudflare Pages'e deploy etmek için: 1. GitHub'a push edin 2. Cloudflare Dashboard'da yeni bir Pages projesi oluşturun 3. Build komutunu npm run build olarak ayarlayın 4. Build çıktı dizinini dist olarak belirleyin <Callout type=\"tip\" title=\"Ucretsiz Hosting\" Cloudflare Pages, unlimited bandwidth ve otomatik SSL ile tamamen ücretsizdir. </Callout SEO Optimizasyonu Astro'da SEO için temel adımlar: Meta tagleri : Her sayfada title ve description Open Graph : Sosyal medya paylaşımları için Sitemap : @astrojs/sitemap entegrasyonu RSS Feed : @astrojs/rss ile otomatik JSON LD : Structured data ile arama motorlarını bilgilendirin Astro, modern web geliştirmenin en iyi uygulamalarını kolayca uygulamanızı sağlar. Hızlı, güvenli ve SEO uyumlu bir blog için mükemmel bir seçimdir.",
      "date_published": "2026-03-30T00:00:00.000Z",
      "date_modified": "2026-03-30T00:00:00.000Z",
      "tags": [
        "Rehberler",
        "astro",
        "web",
        "blog",
        "tutorial",
        "javascript"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/observability-stack-tasarimi",
      "url": "https://mustafaerbay.com.tr/blog/technology/observability-stack-tasarimi",
      "title": "Observability Stack Tasarımı",
      "summary": "Log, metric ve trace katmanlarını tek bir operasyon modelinde toplamak için pratik bir observability tasarımı.",
      "content_text": "import { Image } from 'astro:assets'; import Callout from '../../../components/mdx/Callout.astro'; import observabilityVisual from './observability stack tasarimi.svg'; Bir sistem büyüdükçe \"monitoring\" tek başına yeterli olmaz. CPU ve RAM grafikleri, bir problemin varlığını gösterir; ama problemi neden yaşadığınızı söylemez. Observability yaklaşımı tam burada devreye girer. <figure <Image src={observabilityVisual} alt=\"Observability stack mimarisini gösteren log metric trace diyagramı\" / <figcaption Kaynaklardan toplanan log, metric ve trace verisinin tek görünürlük katmanında birleşmesi.</figcaption </figure Monitoring ile observability farkı Monitoring genellikle \"ne oldu?\" sorusuna cevap verir. Observability ise \"neden oldu, hangi serviste başladı ve kullanıcıyı nasıl etkiledi?\" sorularını da yanıtlar. Kurumsal yapılarda özellikle şu üç veri tipi birlikte düşünülmelidir: Metrics : Sunucu ve uygulama sayısalları Logs : Olay ve hata kayıtları Traces : İstek zincirinin servisler arası yolu İdeal akış Benim en çok tercih ettiğim tasarımda veri akışı şu şekilde ilerler: 1. Sunucu, uygulama ve ağ cihazları telemetri üretir. 2. OpenTelemetry Collector veriyi normalize eder. 3. Log, metric ve trace doğru depolama katmanlarına yönlenir. 4. Grafana üzerinden hepsi tek deneyimde sorgulanır. 5. Alarm sistemi incident sürecini tetikler. Neden tek panel yaklaşımı önemli? Bir uyarı geldiğinde ekip şunu yapmamalı: başka ekranda CPU grafiğine bak sonra başka araçta log ara sonra trace için üçüncü aracı aç Bunun yerine tek alarmdan aynı olayın log, metric ve trace zincirine gidilebilmelidir. Bu, özellikle kritik servislerde MTTR süresini gözle görünür şekilde düşürür. Pratik stack örneği Metrics için Prometheus veya Mimir Logs için Loki Traces için Tempo Dashboard için Grafana Collection için OpenTelemetry Collector Bu yaklaşım hem açık kaynak dünyasında güçlüdür hem de maliyet kontrolü açısından esnektir. <Callout type=\"info\" title=\"Operasyon gerçeği\" Güzel dashboard yapmak observability değildir. Asıl değer, incident anında hangi verinin hangi ekranda görüneceğinin önceden tasarlanmış olmasıdır. </Callout Alarm tasarımında yaptığım temel ayrım Semptom alarmı : kullanıcıyı etkileyen belirti Neden alarmı : kök sebebi işaret eden veri Kapasite alarmı : yaklaşan risk Bu ayrım yapılmazsa ekip aynı olay için onlarca alarm alır ama hangisinin gerçekten önemli olduğunu ayıramaz. Sonuç Doğru observability tasarımı, sadece sistemleri izlemek değil, sistemleri anlamak için kurulur. Büyük yapılarda log, metric ve trace katmanını tek operasyon modeline bağlamak artık lüks değil, temel ihtiyaçtır.",
      "date_published": "2026-03-29T00:00:00.000Z",
      "date_modified": "2026-03-29T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "observability",
        "grafana",
        "monitoring",
        "logs",
        "metrics",
        "tracing"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/technology/yapay-zeka-ile-yazilim-gelistirme",
      "url": "https://mustafaerbay.com.tr/blog/technology/yapay-zeka-ile-yazilim-gelistirme",
      "title": "Yapay Zeka ile Yazılım Geliştirme",
      "summary": "AI destekli yazılım geliştirme araçları ve bunların modern yazılım mühendisliğine etkisi.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Yapay zeka, yazılım geliştirme süreçlerini köklüden değiştiriyor. Kod tamamlama, hata ayıklama, test yazımı ve hatta mimari tasarım gibi alanlarda AI araçları artık vazgeçilmez bir yardımcı haline geldi. AI Kod Asistanları Modern AI kod asistanları, geliştiricilerin verimliliğini önemli ölçüde artırıyor. Bu araçlar sadece kod tamamlama değil, aynı zamanda: Kod inceleme : Potansiyel hataları ve güvenlik açıklarını tespit etme Refactoring : Kod kalitesini artırmak için öneriler sunma Dokümantasyon : Otomatik açıklama ve doküman üretimi Test yazımı : Birim ve entegrasyon testleri oluşturma <Callout type=\"tip\" title=\"Ipucu\" AI araçlarını kullanırken, ürettikleri kodu mutlaka gözden geçirin. AI bir yardımcıdır, karar verici değil. </Callout Prompt Muhendisligi AI ile etkili çalışmanın anahtarı, doğru prompt yazmaktır. İyi bir prompt: 1. Açık ve net olmalıdır 2. Bağlam içermelidir 3. Beklenen çıktı formatını belirtmelidir 4. Kısıtlamaları tanımlamalıdır Gelecek Perspektifi Yapay zekanın yazılım geliştirmedeki rolü hızla büyüyor. Önümüzdeki yıllarda: Otonom kodlama yetenekleri artacak Daha akıllı debug araçları ortaya çıkacak Doğal dil ile programlama yaygınlaşacak <Callout type=\"info\" title=\"Not\" Bu yazı AI tarafından oluşturulmuş ve insan editörü tarafından gözden geçirilmiştir. </Callout Yapay zeka, yazılım mühendislerinin yerini almak için değil, onları güçlendirmek için burada. Doğru kullanıldığında, AI araçları geliştirme sürecini hızlandırır ve kaliteyi artırır.",
      "date_published": "2026-03-28T00:00:00.000Z",
      "date_modified": "2026-03-28T00:00:00.000Z",
      "tags": [
        "Teknoloji",
        "yapay-zeka",
        "yazilim",
        "ai",
        "gelistirme"
      ]
    },
    {
      "id": "https://mustafaerbay.com.tr/blog/career/uzaktan-calisma-rehberi",
      "url": "https://mustafaerbay.com.tr/blog/career/uzaktan-calisma-rehberi",
      "title": "Uzaktan Çalışma Rehberi",
      "summary": "Verimli uzaktan çalışma için pratik ipuçları, araçlar ve stratejiler.",
      "content_text": "import Callout from '../../../components/mdx/Callout.astro'; Uzaktan çalışma, modern iş hayatının ayrılmaz bir parçası haline geldi. Ancak verimli uzaktan çalışma, sadece evden bilgisayar başında oturmaktan ibaret değil. Çalışma Ortamı Verimli bir ev ofisi için temel gereksinimler: Ergonomik masa ve sandalye : Sağlığınız için yatırım yapın İyi aydınlatma : Doğal ışık tercih edin Sessiz ortam : Gürültü önleyici kulaklık kullanın Stabil internet : En az 50 Mbps bağlantı hızı <Callout type=\"warning\" title=\"Dikkat\" Yatak odasında çalışmaktan kaçının. İş ve özel yaşam alanlarınızı ayırın. </Callout Zaman Yönetimi Uzaktan çalışmada en büyük zorluk, zamanı etkili yönetmektir: 1. Pomodoro Tekniği : 25 dakika çalış, 5 dakika mola 2. Time blocking : Gününüzü bloklara bölün 3. Deep work : Odaklanma gerektiren işler için kesintisiz zamanlar ayırın 4. Asenkron iletişim : Her mesaja anında cevap vermek zorunda değilsiniz İletişim Araçları Doğru araçları kullanmak büyük fark yaratır: | Araç | Kullanım | | | | | Slack | Hızlı mesajlaşma | | Zoom | Toplantı | | Notion | Dokümantasyon | | Linear | Proje yönetimi | | GitHub | Kod işbirliği | Is Yasam Dengesi Uzaktan çalışmada sınırlar koymak çok önemlidir: Belli saatlerde çalışmaya başlayın ve bitirin Öğle molasında bilgisayardan uzaklaşın Hafta sonları iş bildirimlerini kapatın Düzenli egzersiz yapın <Callout type=\"tip\" title=\"Tavsiye\" Her gün en az 30 dakika dışarı çıkın. Güneş ışığı ve temiz hava, verimlilik için mucizeler yaratır. </Callout Uzaktan çalışma, doğru alışkanlıklar ve araçlarla son derece verimli olabilir. Önemli olan, kendi rutininizi oluşturmak ve buna sadık kalmaktır.",
      "date_published": "2026-03-25T00:00:00.000Z",
      "date_modified": "2026-03-25T00:00:00.000Z",
      "tags": [
        "Kariyer",
        "kariyer",
        "uzaktan-calisma",
        "verimlilik",
        "iletisim"
      ]
    }
  ]
}