Ağustos 1 2025

Kitle Turizminden Uzak Adriyatik: Karadağ ve Arnavutluk Yol Rotası

Her yaz aynı hikaye: İtalya sahilleri el yakıyor, Yunan adalarında adım atacak yer kalmıyor. İşte tam bu noktada, hem cebinizi hem de ruhunuzu koruyacak harika bir alternatif devreye giriyor. Sırtınızı Adriyatik’in hırçın dağlarına yaslayıp, rotayı güneye kırmak. Keşfedilmemiş koyları, bütçe dostu lokantaları ve orta çağ kasabalarıyla harmanlanmış bir adriyatik yol rotası, son yıllarda yaptığım en iyi yolculuklardan biriydi. Eğer siz de turist akınından kaçıp gerçek bir balkanlar seyahat deneyimi yaşamak istiyorsanız, Karadağ ve Arnavutluk’un el değmemiş sahilleri tam aradığınız yer olabilir. Bu yazıda, cebinizi yormadan rüya gibi bir tatil yapabilmeniz için hazırladığım kapsamlı bir karadağ arnavutluk rehberi bulacaksınız. Hazırsanız, ucuz yaz tatili hayallerinizi gerçeğe dönüştürmek için yola çıkalım.

Kotor Körfezi’nin Büyüsünden Adriyatik’e Doğru

Yolculuğa genellikle uçak biletlerinin daha uygun olduğu Karadağ’ın başkenti Podgorica’dan başlamak en mantıklısı. Havalimanından günlük ortalama 30-40 Euro’ya kiralayacağınız küçük bir araç, bu rotanın can damarı olacak. Ancak burada kritik bir detay var: Sınır geçişi yapacağınız için kiralama şirketine mutlaka “Green Card” (Yeşil Kart) sigortası yaptırmak istediğinizi söylemelisiniz. Bu sigorta için tek seferlik yaklaşık 40 Euro ekstra bir ücret ödemeniz gerekiyor ancak sınırda saatlerce beklemekten veya geri çevrilmekten kurtuluyorsunuz.

Karadağ’da araç kiralarken uluslararası dev firmalar yerine yerel işletmeleri tercih etmek genellikle daha esnek koşullar sunar. Depozitoyu nakit alan ve kredi kartı bloke etmeyen lokal acenteler sayesinde bütçenizi sıkıştırmamış olursunuz.

Budva’nın Ötesine Geçmek: Petrovac ve Bar

Budva artık bence Adriyatik’in eski cazibesini yitirmiş, fazlasıyla ticarileşmiş ve pahalı bir noktası. Eğer “klişelerden uzaklaşalım” diyorsak, Budva’yı sadece içinden arabayla geçerek selamlayıp güneye, Petrovac ve Bar kasabalarına doğru devam etmeliyiz. Petrovac’ta deniz kenarındaki taş binaların arasında yürürken kokusunu alacağınız taze deniz mahsulleri, akşam yemeği için harika birer seçenek. Burada iki kişilik zengin bir akşam yemeği, ev yapımı lokal şarap dahil yaklaşık 35 Euro civarında tutuyor.

Bar şehri ise eski kalesi (Stari Bar) ile size tarihin kapılarını aralıyor. Dağın yamacına kurulmuş bu eski şehirde, zeytin ağaçlarının gölgesinde Türk kahvesi içmek bu rotanın en keyifli anlarından biri. Üstelik burada konaklama fiyatları Budva’nın neredeyse yarı fiyatına, gecelik 25-30 Euro bandında temiz stüdyo daireler bulmak mümkün.

Sınırı Aşmak: Arnavutluk’un Kaotik ve Samimi Dünyası

Karadağ’dan Arnavutluk’a geçiş, sadece bir coğrafya değişimi değil, aynı zamanda tamamen farklı bir kültüre adım atmak anlamına geliyor. Sukobin sınır kapısından geçerken memurların rahat tavırları ve arkada çalan Balkan müzikleri size doğru yerde olduğunuzu hissettiriyor. Sınırı geçtikten sonra yollar biraz daha daralıyor, trafik kuralları ise biraz daha “tavsiye niteliğinde” bir hal alıyor. Ancak endişelenmeyin, bu tatlı kaos kısa sürede size de sirayet edecek ve sürüş tarzınızı buna uyduracaksınız.

Arnavutluk’ta para birimi Lek. 1 Euro yaklaşık 100 Lek civarında değer buluyor. Sınırı geçer geçmez ilk benzinlikte veya küçük bir kasabada bir miktar Euro bozdurmak hayatınızı kolaylaştırır çünkü yerel restoranlarda ve küçük pansiyonlarda kredi kartı geçme ihtimali oldukça düşük. Nakit burada hala kral.

Ksamil’in Ötesi: Himare ve Dhermi Sahilleri

Sosyal medyada sürekli karşımıza çıkan Ksamil, Maldivler benzeri deniziyle ünlü, evet. Ancak dürüst olmak gerekirse, yüksek sezonda burası o kadar kalabalık ki, kumsalda havlu atacak yer bulamazsınız. Üstelik şezlong fiyatları da Avrupa standartlarıyla yarışıyor. Gerçek bir gezgin ruhuyla hareket ediyorsak, rotamızı Himare ve Dhermi gibi daha kuzeydeki sahil kasabalarına çevirmeliyiz.

Himare, balıkçı teknelerinin kıyıya yanaştığı, yerel halkın akşamları sahilde turladığı samimi bir Ege kasabasını andırıyor. Burada denize sıfır bir aile pansiyonunda geceliği 30-40 Euro’ya kalabilirsiniz. Akşam yemeğinde ise tabağınızı dolduran taze ahtapot ve kalamar için ödeyeceğiniz rakam kişi başı en fazla 12 Euro olacaktır. Denize girmek için ise gizli kalmış Gjipe Plajı’nı mutlaka listenize ekleyin. Kanyonun içinden yaklaşık 20 dakika yürüyerek ulaşılan bu plajda elektrik ve lüks yok, sadece siz ve Adriyatik’in vahşi doğası var.

Yolculuk Boyunca Zaman ve Bütçe Yönetimi

Bu yol rotasında toplamda yaklaşık 400-500 kilometre yol yapacaksınız. Ancak yolların tek şeritli ve virajlı olması, ayrıca sınır geçişlerindeki olası yoğunluklar nedeniyle seyahat sürelerini tahmin ederken haritadaki sürelere her zaman birer saat eklemenizi öneririm. Örneğin, Kotor’dan Arnavutluk’un güneyindeki Sarande’ye gitmek sınır geçişi dahil yaklaşık 6-7 saat sürüyor. Acele etmeyin, yolun kendisinin de tatilin bir parçası olduğunu unutmayın.

Rezervasyon tüyosu olarak; Booking gibi platformlar üzerinden yer ayırtmak yerine, özellikle Arnavutluk’ta doğrudan pansiyonların kapısını çalmak hala işe yarayan en iyi yöntem. Nakit ödeme yapacağınızı söylediğinizde genellikle internet fiyatının %20 altına kolayca anlaşabiliyorsunuz.

Arnavutluk’ta yerel bir SIM kart almak oldukça ucuz ve hayat kurtarıcıdır. Vodafone veya One iletişim noktalarından yaklaşık 15 Euro karşılığında 30 GB internet içeren turist paketleri alarak haritadan asla kopmamanızı garantileyebilirsiniz.

Neden Şimdi Gitmelisiniz?

Adriyatik hala el değmemiş köşelerini koruyor ancak bu durum çok uzun sürmeyecek. Karadağ’ın lüks liman projeleri ve Arnavutluk’un hızla gelişen turizm altyapısı, bu rotayı birkaç yıl içinde çok daha pahalı ve kalabalık hale getirecektir. Henüz doğallığını ve bütçe dostu yapısını kaybetmemişken, yerel fırınlardan sıcak böreklerinizi alıp yola çıkmanın şimdi tam zamanı. Adriyatik’in bu iki güzel ülkesi, size sadece ucuz bir tatil değil, aynı zamanda unutulmaz dostluklar ve gerçek keşif hikayeleri sunmaya hazır.

Category: Genel | LEAVE A COMMENT
Temmuz 25 2025

Kubernetes Aşırı mı Geliyor? 2026’da Backend Uygulamalarını Canlıya Almanın En İyi PaaS Alternatifleri

SRE dünyasında bir süredir sessiz ama kararlı bir isyan dalgası büyüyor. Her yeni projeye, sorgusuz sualsiz bir Kubernetes (K8s) cluster’ı fırlatma çılgınlığı yerini “Ben sadece basit bir REST API ayağa kaldıracaktım, neden şu an ingress-nginx helm chart’ı debug ediyorum?” aydınlanmasına bıraktı. K8s şüphesiz harika bir orkestratör; ancak devasa bir platform ekibiniz yoksa, getirdiği operasyonel yük faydasından çok zarar getirebiliyor. Geliştirici üretkenliğini ve hızı her şeyin önüne koyan ekipler için modern paas alternatives 2026 ekosistemi hiç olmadığı kadar olgun. Bu yazıda, karmaşık orkestrasyon labirentlerinde kaybolmadan, ölçeklenebilir ve güvenli bir backend deployment süreci yürütebilmeniz için en iyi serverless hosting ve yeni nesil cloud platforms alternatiflerini teknik derinliğiyle ele alıyoruz.

Kubernetes Neden Her Zaman Doğru Cevap Değil? (Neden Böyle?)

K8s kullanırken ödediğiniz gizli vergilere yakından bakalım. Sadece uygulamanızı çalıştırmak için bile CoreDNS sorunları, CSI driver uyumsuzlukları, cert-manager yenileme hataları ve Ingress Controller konfigürasyonları ile uğraşmak zorundasınız. Buna ek olarak, uygulamanızın boşta kaldığı zamanlarda bile harcanan “idle CPU/Memory” maliyetleri, Kubernetes’in control plane ücretleriyle birleşince cüzdanı ciddi şekilde hırpalıyor.

SRE’lerin asıl görevi altyapıyı fetişleştirmek değil, kodun güvenli ve hızlı bir şekilde production ortamına ulaşmasını sağlamaktır. 2026 yılında modern bulut platformları, bize K8s’in sunduğu izolasyon, autoscaling ve zero-downtime deployment (mavi-yeşil / canary) gibi yetenekleri, hiçbir altyapı yönetim yükü olmadan sunabiliyor. Şimdi bu alternatifleri masaya yatıralım.

1. Fly.io: Firecracker MicroVM’leri ile Edge-Native SRE Deneyimi

Fly.io, geleneksel container mimarisini doğrudan çıplak metal üzerinde koşan hafif sanal makinelere (microVM) dönüştürerek ezber bozuyor. AWS Firecracker teknolojisini kullanan Fly.io, uygulamanızı kullanıcılara en yakın edge lokasyonlarında milisaniyeler içinde ayağa kaldırabiliyor.

SRE Gözünden Neden Fly.io?

Fly.io, karmaşık VPC ve peering konfigürasyonlarıyla uğraşmadan multi-region veritabanı replikasyonlarını (LiteFS veya PostgreSQL read-replicas) yönetmeyi inanılmaz kolaylaştırıyor. Anycast IP routing mimarisi sayesinde, istekler otomatik olarak en yakın çalışan makineye yönlendiriliyor.

Aşağıdaki fly.toml konfigürasyonu, otomatik ölçeklenme ve scale-to-zero (kullanılmadığında kapanma) yeteneğine sahip production-ready bir Go/Node.js backend servisinin tanımıdır:

# fly.toml
app = "kertenkerem-api-prod"
primary_region = "ams"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = "suspend"
  auto_start_machines = true
  min_machines_running = 1
  processes = ["app"]

[[vm]]
  size = "shared-cpu-1x"
  memory = "1024mb"
  cpus = 1

[checks]
  [checks.alive]
    type = "http"
    port = 8080
    path = "/healthz"
    interval = "15s"
    timeout = "2s"
    grace_period = "5s"

Buradaki auto_stop_machines = "suspend" parametresine dikkat edin. Fly.io, makinenizi kapatmak yerine RAM durumunu diske dondurarak suspend moduna alır. Yeni bir HTTP isteği geldiğinde cold start süresi saniyenin altına iner. Kubernetes’te HPA (Horizontal Pod Autoscaler) ile bu kadar agresif ve hızlı bir scale-to-zero mekanizmasını stabil çalıştırmak tam bir kabustur.

2. Render: Altyapıyı Kodla Yönetmek İsteyenlere IaC Odaklı PaaS

Render, Heroku’nun kolaylığını alıp modern DevOps pratikleriyle (IaC, GitOps, Private Networking) harmanlayan, bizim en sevdiğimiz platformlardan biri. Render üzerinde sadece Dockerfile’ınızı göstererek ya da doğrudan kod reposunu bağlayarak saniyeler içinde canlıya çıkabilirsiniz.

SRE Gözünden Neden Render?

K8s’teki en büyük dertlerden biri, servislerin birbirleriyle güvenli bir şekilde konuşmasını sağlamaktır. NetworkPolicies yazmak, istio/linkerd kurmak ciddi efor gerektirir. Render, tüm servislerinizi otomatik olarak dış dünyaya kapalı bir private network içerisine alır. API servisiniz, Redis instance’ınıza dış dünyaya hiçbir port açmadan, doğrudan internal host name üzerinden bağlanır.

Tüm altyapıyı GitOps felsefesiyle sürümlemek için projenizin kök dizinine ekleyeceğiniz render.yaml dosyası şu şekilde görünür:

# render.yaml
services:
  - type: web
    name: main-backend-api
    env: docker
    dockerfilePath: ./Dockerfile
    plan: standard
    numInstances: 3
    healthCheckPath: /healthz
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: prod-postgres
          property: connectionString
      - key: REDIS_URL
        fromService:
          name: cache-redis
          type: redis
          property: connectionString

  - type: redis
    name: cache-redis
    plan: starter
    ipAllowList: [] # Sadece private network'e açık

databases:
  - name: prod-postgres
    plan: standard
    postgresMajorVersion: 16
    ipAllowList: [] # Dış dünyaya kapalı

Bu tek bir dosya ile multi-tier mimariyi, private network izolasyonunu ve zero-downtime rolling update stratejisini tanımlamış oldunuz. Kubernetes dünyasında bunu yapmak için en az 10 farklı YAML manifesti (Deployment, Service, PVC, Secret, Ingress vb.) yazmanız gerekirdi.

3. Railway: Nixpacks Gücü ve Üstün DX (Developer Experience)

Özellikle hızlı iterasyon yapan startup ekipleri ve mikroservis mimarisine yeni geçenler için Railway mükemmel bir liman. Alt yapısında Heroku buildpack’lerinin modern alternatifi olan Nixpacks teknolojisini kullanıyor.

SRE Gözünden Neden Railway?

Railway, Dockerfile yazma zorunluluğunu ortadan kaldırır. Projenizdeki kod dilini analiz eder, en optimize build imajını oluşturur ve caching mekanizmalarıyla build sürelerini minimize eder. Tabii ki isterseniz kendi custom Dockerfile’ınızı da doğrudan ezebilirsiniz.

CLI arayüzünün gücü sayesinde SRE mühendisleri pipeline entegrasyonlarını saniyeler içinde yazabilir. CI/CD süreçlerinizde kullanabileceğiniz örnek bir Railway deployment otomasyon scripti:

#!/usr/bin/env bash
set -eo pipefail

# Railway authentication ve deployment adımları
export RAILWAY_TOKEN="your_prod_ci_token_here"

echo "[*] Production ortamı için konfigürasyonlar doğrulanıyor..."
railway status

echo "[*] Yeni imaj build ediliyor ve deploy tetikleniyor..."
railway up --detach --service "auth-service"

echo "[✓] Deployment başarıyla başlatıldı!"

4. Google Cloud Run: Kurumsal ve Ölçeklenebilir Serverless

Eğer regülasyonlar (KVKK, GDPR, SOC2) veya mevcut şirket politikaları nedeniyle bağımsız PaaS sağlayıcılarını kullanamıyorsanız, hyperscaler dünyasındaki en mantıklı tercih Google Cloud Run’dır. Cloud Run, arka planda Knative (Kubernetes tabanlı serverless framework) kullanır ancak K8s’in tüm karmaşıklığını sizden gizler.

SRE Gözünden Neden Cloud Run?

Sadece kullandığınız saniye kadar ödersiniz. Eğer backend uygulamanıza istek gelmiyorsa, CPU kullanımı sıfıra iner ve hiçbir ücret ödemezsiniz (scale-to-zero). Ayrıca GCP ekosistemindeki IAM rollerini kullanarak, database şifrelerini kodun içine gömmeden doğrudan Cloud KMS/Secret Manager entegrasyonu sağlayabilirsiniz.

Aşağıdaki gcloud CLI komutu, bir backend container’ını production standartlarında, private VPC connector kullanarak Cloud SQL veritabanına bağlayarak deploy eder:

# GCP VPC Connector ile güvenli Cloud Run Deployment'ı
gcloud run deploy customer-api-prod \
  --image europe-west3-docker.pkg.dev/my-gcp-project/api:v1.2.0 \
  --platform managed \
  --region europe-west3 \
  --no-allow-unauthenticated \
  --vpc-connector projects/my-gcp-project/locations/europe-west3/connectors/prod-vpc-conn \
  --cpu 2 \
  --memory 4Gi \
  --min-instances 2 \
  --max-instances 100 \
  --set-env-vars="NODE_ENV=production,DB_HOST=10.0.1.5" \
  --set-secrets="DB_PASS=prod-db-password:latest" \
  --concurrency 80

Buradaki --concurrency 80 parametresi çok kritik. AWS Lambda gibi geleneksel FaaS çözümlerinin aksine, Cloud Run tek bir container instance’ında eşzamanlı olarak 80 (veya isterseniz daha fazla) isteği işleyebilir. Bu da node bazlı cold start problemlerini ve gereksiz kaynak tüketimini neredeyse tamamen ortadan kaldırır.

PaaS vs Kubernetes Karar Matrisi: Hangi Yoldan Gitmelisiniz?

Özellik Kubernetes (EKS/GKE) Fly.io / Render / Railway Google Cloud Run / AWS App Runner
Kurulum & Güncelleme Maliyeti Çok Yüksek (Sürekli bakım gerekir) Sıfır Sıfır
Cold Start Riski Yok (Her an hazır podlar) Çok Düşük (Suspend / warm pool) Düşük (Min-instances ile sıfırlanabilir)
IaC ve GitOps Desteği Karmaşık (Helm, ArgoCD, Kustomize) Yüksek (render.yaml, fly.toml) Mükemmel (Terraform native)
Bütçe Kontrolü Zor (Boşta duran nodelara ödeme var) Kolay (Kullandığın kadar öde / Sabit plan) Çok Kolay (Scale-to-zero)

Özet: Ne Zaman Hangisini Seçmeli?

Kariyerinde 5+ yılı devirmiş bir SRE/DevOps mühendisi olarak şu gerçeği kabul etmek gerekir: En iyi altyapı, en az yönettiğiniz altyapıdır. Eğer ekibinizde sadece altyapı otomasyonu ve cluster sağlığı ile ilgilenen dedike bir Platform Engineering ekibiniz yoksa, Kubernetes’e yatırım yapmak teknolojik bir borç sarmalına girmek demektir.

2026 yılındaki projeleriniz için basit bir yol haritası çizelim:

  • Eğer global bir kitleye hitap eden, düşük gecikme süreli edge-native mikroservisler yazıyorsanız Fly.io ilk tercihiniz olmalı.
  • Eğer klasik bir web/API backend, cron job’lar ve ilişkisel veritabanı üçlüsüyle çalışıyorsanız ve altyapıyı kodla sürümlemek istiyorsanız Render biçilmiş kaftan.
  • Çok hızlı prototip üretip, Dockerfile yazmakla bile uğraşmadan multi-service pipeline’lar kurmak istiyorsanız adresiniz Railway.
  • Büyük ölçekli kurumsal regülasyonlara tabi iseniz ve tüm verileriniz zaten Google Cloud/AWS üzerindeyse, doğrudan Cloud Run veya App Runner ile serverless gücünü kullanın.

Unutmayın, müşterileriniz uygulamanızın hangi k8s cluster’ında çalıştığıyla ilgilenmiyor; uygulamanızın ne kadar kesintisiz ve hızlı çalıştığıyla ilgileniyor.

Category: Genel | LEAVE A COMMENT
Temmuz 18 2025

Mühendis Yakılmasına Son: Sağlıklı ve Sürdürülebilir Bir On-Call Kültürü Nasıl Kurulur?

Gece saat 03:00. Slack veya PagerDuty’den gelen o tanıdık siren sesiyle uyanıyorsunuz. Eğer modern bir devops kültürü yerine “kim ayaktaysa baksın” kaosunu yaşıyorsanız, ekibinizde tükenmişlik sendromu (burnout) çanları çoktan çalmaya başlamış demektir. Doğru yapılandırılmamış bir on-call yönetimi, sadece sistemlerin değil, en yetenekli mühendislerinizin de sessizce istifa etmesine (veya daha kötüsü, sistemin ortasına çökmesine) neden olur. Bu yazıda, incident response süreçlerini nasıl insani, sürdürülebilir ve otomatize hale getireceğimizi inceliyoruz. Sıkıcı teorileri bir kenara bırakıp doğrudan production ortamında can kurtaracak pratiklere odaklanıyoruz.

Alert Fatigue ile Savaş: Sadece “Aksiyon Alınabilir” Alarmlar

Alert fatigue (alarm yorgunluğu), on-call mühendislerinin en büyük düşmanıdır. CPU kullanımının %85’e çıkması tek başına bir alarm sebebi olmamalıdır. Eğer alarm çaldığında mühendisin yapabileceği net, manuel bir aksiyon yoksa (örneğin sistem kendi kendine auto-scale oluyorsa), o alarm çöp gürültüdür. Sadece kullanıcı deneyimini doğrudan etkileyen (SLO/SLI ihlalleri) veya sistemin tamamen durma noktasına geldiğini gösteren durumlar pager seviyesinde olmalıdır.

Gürültüyü azaltmak için Prometheus Alertmanager üzerinde akıllı gruplama (grouping) ve engelleme (inhibition) kuralları uygulamalısınız. Örneğin, tüm veri merkezi down olmuşken her bir pod için ayrı ayrı 500 tane “PodDown” alarmı almak yerine, tek bir “DatacenterDown” alarmı tetiklenmeli ve alt alarmlar susturulmalıdır.

Aşağıdaki Alertmanager konfigürasyon bloğu, benzer alarmları nasıl gruplayıp birbirini ezmesini (inhibit) sağlayabileceğinizi gösterir:

# alertmanager.yml
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'pagerduty-high-priority'
  routes:
    - match:
        severity: warning
      receiver: 'slack-low-priority'

inhibit_rules:
  - source_match:
      alertname: 'NodeNetworkDown'
    target_match_re:
      alertname: 'InstanceDown|TargetDown'
    equal: ['node', 'instance']

Neden böyle yapıyoruz? Çünkü NodeNetworkDown olduğunda, o node üzerindeki tüm container’ların erişilemez olması kaçınılmazdır. Bu engelleme kuralı sayesinde, gece yarısı telefonunuza 50 farklı push bildirimi gelmez; sorunun kök nedenine odaklanan tek bir kritik alarm alırsınız.

Rotasyon ve Eskalasyon Politikalarında Matematiksel Adalet

Adil bir on-call rotasyonu oluşturmak, excel tablolarından fazlasını gerektirir. Tek bir birincil (Primary) nöbetçi koyup tüm yükü ona yıkmak, tek hata noktası (SPOF) yaratmaktır. Sürdürülebilir bir sistemde her zaman Primary ve Secondary (Shadow/Backup) rollerinin tanımlanması gerekir.

Eğer global bir ekipseniz, “Follow-the-Sun” modelini uygulamak hayat kurtarır. Bu modelde nöbetler, coğrafi olarak gündüz vaktinde olan bölgeye devredilir. Eğer lokal bir ekipseniz, haftalık rotasyonların cuma günü saat 17:00’de devredilmesi yerine salı günü öğleden sonra devredilmesi daha sağlıklıdır. Böylece yeni nöbetçi, haftalık iş yoğunluğunun ortasında sisteme ısınır ve olası devir-teslim sorunlarını mesai saatleri içinde çözer.

Bu yapıyı kod olarak yönetmek (Infrastructure as Code) esnekliği artırır. Aşağıdaki Terraform konfigürasyonu, PagerDuty üzerinde adil bir eskalasyon politikasını tanımlar:

# pagerduty.tf
resource "pagerduty_escalation_policy" "production_policy" {
  name      = "Production Escalation Policy"
  num_loops = 2

  rule {
    escalation_delay_in_minutes = 10
    target {
      id   = pagerduty_schedule.primary_schedule.id
      type = "schedule_reference"
    }
  }

  rule {
    escalation_delay_in_minutes = 15
    target {
      id   = pagerduty_schedule.secondary_schedule.id
      type = "schedule_reference"
    }
  }

  rule {
    escalation_delay_in_minutes = 20
    target {
      id   = pagerduty_user.engineering_lead.id
      type = "user_reference"
    }
  }
}

Buradaki felsefe şudur: Primary nöbetçi 10 dakika içinde alarmı ack’lemezse (onaylamazsa), alarm otomatik olarak Secondary nöbetçiye geçer. O da 15 dakika içinde yanıt vermezse, engineering lead seviyesine eskalasyon gerçekleşir. Bu hiyerarşi, nöbetteki mühendisin üzerindeki psikolojik baskıyı azaltır; arkasında her zaman bir güvence olduğunu bilir.

Incident Response Otomasyonu: Self-Healing ve ChatOps

Bir alarm çaldığında mühendisin yaptığı ilk iş genellikle terminali açıp df -h yazmak veya ilgili servisi restart etmekse, burada ciddi bir otomasyon eksiği var demektir. Tekrarlanan runbook adımları, insan müdahalesine gerek kalmadan otomatik olarak çalıştırılmalıdır.

Örneğin, disk doluluk alarmı tetiklendiğinde otomatik olarak geçici cache dosyalarını temizleyen veya log rotasyonunu tetikleyen bir Kubernetes DaemonSet veya serverless fonksiyon yazabilirsiniz. İnsan faktörünü sadece “otomasyonun çözemediği” durumlarda devreye sokmalıyız.

Eğer manuel müdahale şartsa, bunu Slack/MS Teams üzerinden ChatOps ile yapmak hızı katlar. Aşağıdaki basit bash script’i, Alertmanager webhook’undan gelen disk alarmını yakalayıp, AWS API’si üzerinden EBS hacmini otomatik olarak genişleten bir self-healing mekanizmasının mantığını göstermektedir:

#!/usr/bin/env bash
# auto_expand_disk.sh
set -euo pipefail

ALERT_PAYLOAD=$(cat)
VOLUME_ID=$(echo "$ALERT_PAYLOAD" | jq -r '.alerts[0].labels.volume_id')
REGION=$(echo "$ALERT_PAYLOAD" | jq -r '.alerts[0].labels.region')

echo "Kritik disk alarmı alındı: $VOLUME_ID. Disk boyutu %10 artırılıyor..."

# Mevcut boyutu al
CURRENT_SIZE=$(aws ec2 describe-volumes \
  --volume-ids "$VOLUME_ID" \
  --region "$REGION" \
  --query "Volumes[0].Size" --output text)

NEW_SIZE=$(( CURRENT_SIZE + (CURRENT_SIZE * 10 / 100) ))

# AWS üzerinde diski genişlet
aws ec2 modify-volume \
  --volume-id "$VOLUME_ID" \
  --region "$REGION" \
  --size "$NEW_SIZE"

echo "Disk başarıyla $NEW_SIZE GB değerine genişletildi."

Neden böyle bir otomasyon kuruyoruz? Çünkü gece 04:00’te bir mühendisi sadece disk genişletmek için uyandırmak, operasyonel verimliliği baltalamaktan başka bir işe yaramaz. Bırakın otomasyon diski genişletsin, mühendis sabah kahvesini içerken slack kanalındaki log’lardan olayı takip etsin.

Suçsuz (Blameless) Post-Mortem Kültürü

Sürdürülebilir on-call kültürünün teknik olmayan en kritik ayağı, olay sonrası analizlerdir. Bir incident bittiğinde her şey bitmiş sayılmaz. Amaç “Hatayı kim yaptı?” sorusunu sormak değil, “Sistemimiz bu hatanın yapılmasına nasıl izin verdi?” sorusuna yanıt aramaktır.

Blameless post-mortem süreçlerinde şu üç kuralı asla esnetmeyin:

  • İnsanlar hata yapabilir: Süreçleriniz ve tool’larınız bu hataları tolere edebilecek şekilde tasarlanmalıdır.
  • Zaman çizelgesi çıkarın: Alarmın çalma anından, ilk müdahaleye ve nihai çözüme (mitigation) kadar geçen süreci kronolojik olarak dökün.
  • Aksiyon maddeleri (Action Items) üretin: Her post-mortem belgesinden, gelecekte benzer hatanın tekrarlanmasını önleyecek en az 2 adet Jira task’i çıkmalı ve bunlar sonraki sprint’e dahil edilmelidir.

Sonuç: Mühendisleri Yakmadan Sistemleri Ayakta Tutmak

Sağlıklı bir on-call sistemi kurmak, teknik bir zorunluluk olduğu kadar etik bir sorumluluktur. Ekibinizi sürekli yangın söndüren itfaiyecilere dönüştürmek yerine, yangının hiç çıkmamasını sağlayan sistem mimarları haline getirmelisiniz. Alarmlarınızı sadeleştirin, rotasyonlarınızı adilleştirin, otomasyona yatırım yapın ve her hatayı sisteminizi güçlendirmek için bir fırsat olarak görün. Unutmayın; iyi bir SRE, uykusunu en iyi almış SRE’dir.

Category: Genel | LEAVE A COMMENT
Temmuz 11 2025

Stressiz Performansın Anahtarı: HRV (Kalp Atış Hızı Değişkenliği) Nedir?

Akıllı saatinizi kolunuza taktınız, sabah uyandınız ve ekranda daha önce pek dikkat etmediğiniz bir değer gördünüz: HRV. Peki, son dönemde adını sıkça duyduğumuz hrv nedir ve neden spor dünyasından stres yönetimine kadar herkes bu metriğin peşinden koşuyor? Türkçe adıyla kalp atış hızı değişkenliği, aslında vücudumuzun stresle nasıl başa çıktığını, ne kadar dinlendiğini ve güne ne kadar hazır olduğunu gösteren en sadık biyolojik pusuladır.

Birçoğumuz kalbimizin bir metronom gibi, her saniye tam olarak aynı ritimde attığını düşünürüz. Dakikada 60 kere atıyorsa, her atış arası tam 1 saniyedir, değil mi? Aslında hayır. Kalbimiz bir İsviçre saati gibi çalışmaz ve işin doğrusu, çalışmasını da istemeyiz. Atışlar arasındaki o milisaniyelik milimetrik düzensizlikler, sağlıklı bir yaşamın ve yüksek performansın en büyük sırrıdır.

Kalp Ritminin Gizli Yönetmeni: Otonom Sinir Sistemi

HRV’nin mantığını kavramak için vücudumuzun arka planında çalışan işletim sistemine, yani otonom sinir sistemi mekanizmasına bakmamız gerekir. Bu sistem iki ana şubeden oluşur:

  • Sempatik Sinir Sistemi (Savaş veya Kaç): Vücudun gaz pedalıdır. Stres altındayken, spor yaparken veya heyecanlandığımızda devreye girer. Kalp atışını hızlandırır ve ritmi daha “sabit” hale getirir.
  • Parasempatik Sinir Sistemi (Dinlen ve Sindir): Vücudun fren pedalıdır. Sakinken, uyurken ve toparlanırken aktiftir. Kalp atışını yavaşlatır ve atışlar arasındaki süreyi esnetir.

İşte bu iki sistem sürekli bir çekişme içindedir. Sağlıklı ve dinlenmiş bir vücutta parasempatik sistem güçlüdür ve kalbe “rahat ol, ritmini esnetebilirsin” mesajı gönderir. Bu da yüksek bir HRV değeri yaratır. Eğer çok stresliyseniz, uykusuzsanız veya vücudunuz bir hastalıkla savaşıyorsa, sempatik sistem kontrolü ele alır, kalp atışları arasındaki süre sabitlenir ve HRV değeriniz düşer.

HRV Neden Bu Kadar Önemli? (Sporcu Recovery ve Ötesi)

Gelişen teknoloji sayesinde artık sadece elit atletler değil, kolunda akıllı saat taşıyan herkes bu veriye erişebiliyor. Peki, bu veri günlük hayatta ve antrenman rutinimizde ne işimize yarar? Cevap basit: Akıllıca dinlenmek.

Özellikle yoğun antrenman yapanlar için sporcu recovery (toparlanma) süreci, kas gelişiminin asıl gerçekleştiği yerdir. Araştırmalar gösteriyor ki, antrenman yoğunluğunu HRV değerlerine göre ayarlayan sporcular, sadece sabit bir program takip edenlere kıyasla daha az sakatlanıyor ve çok daha hızlı performans artışı kaydediyor.

Sabah uyandığınızda HRV değerinizin normal ortalamanızın (baseline) altında olduğunu görüyorsanız, bu vücudunuzun hala bir önceki antrenmanın, yoğun iş gününün veya dün gece yediğiniz ağır yemeğin yükünü taşıdığı anlamına gelir. Böyle günlerde ağır bir kardiyo yerine hafif bir yürüyüş veya yoga tercih etmek, performansınızı uzun vadede yukarı taşıyacaktır.

Akıllı Saatlerdeki HRV Değerleri Ne Anlama Geliyor?

Akıllı saatinizde gördüğünüz HRV değeri genellikle RMSSD denilen karmaşık bir matematiksel formülle hesaplanır ve milisaniye (ms) cinsinden sunulur. Burada bilmeniz gereken en önemli kural şudur: “Mükemmel bir HRV sayısı yoktur.”

20 yaşındaki birinin HRV ortalaması 80 ms iken, çok fit bir 50 yaşındaki kişinin ortalaması 40 ms olabilir. Önemli olan kendi kişisel “baseline” yani taban değerinizi bulmaktır. Saatinizi birkaç hafta boyunca düzenli olarak (özellikle uyurken) takarak kendi normalinizi öğrenin ve sapmaları bu normale göre takip edin.

HRV Değerinizi İyileştirmek İçin Eyleme Geçilebilir Adımlar

HRV’nizi bir günde uçuramazsınız ama yaşam tarzınızda yapacağınız küçük değişikliklerle otonom sinir sisteminizi sakinleştirebilir ve bu değeri yukarı taşıyabilirsiniz:

  1. Alkolü Sınırlandırın: Alkol, HRV’nin bir numaralı düşmanıdır. Gece içilen tek bir kadeh bira bile parasempatik sistemi baskılayarak gece boyu HRV’nizin taban yapmasına neden olabilir.
  2. Uykuyu Standartlaştırın: Sadece kaç saat uyuduğunuz değil, ne zaman uyuduğunuz da önemlidir. Her gün aynı saatte yatıp kalkmak otonom sinir sistemini dengeler.
  3. Nefes Egzersizleri Yapın: Dakikada 6 nefes alacak şekilde yapılan yavaş ve derin nefes egzersizleri (kutu nefesi veya 4-7-8 tekniği), parasempatik sistemi saniyeler içinde tetikler.
  4. Antrenman Sonrası Soğumayı İhmal Etmeyin: Antrenmanı birdenbire bitirip duşa koşmayın. 5-10 dakikalık hafif esneme hareketleri, vücudun “savaş veya kaç” modundan çıkıp “recovery” moduna geçişini hızlandırır.

Önemli Uyarı: HRV değerlerinizde ani, açıklanamayan ve haftalarca süren ciddi düşüşler görüyorsanız; bu duruma nefes darlığı, göğüs ağrısı veya aşırı halsizlik eşlik ediyorsa, akıllı saatinizle teşhis koymaya çalışmayın. HRV bir wellness takip aracıdır, tıbbi bir cihaz değildir. Bu gibi durumlarda mutlaka bir uzman doktora danışın.

Özetle: Dinlenmeyi De Bir Performans Parametresi Yapın

Modern dünya bize sürekli “daha çok çalış, daha sert antrenman yap” diye fısıldıyor. Ancak bilim bize gösteriyor ki, gelişim sadece çalışırken değil, doğru dinlenirken gerçekleşir. HRV, vücudunuzun size fısıldadığı o sessiz çığlığı duymanızı sağlar. Saatinizdeki o küçük milisaniye değerine kulak verin; çünkü bazen en büyük başarı, koltuğa uzanıp hiçbir şey yapmamaktır.

Category: Genel | LEAVE A COMMENT
Temmuz 4 2025

Esneklik Yetmez: Eklemleri Koruyan ve Ağrıları Önleyen Mobilite Antrenmanı

Pek çoğumuz spordan sonra ya da sabah uyandığımızda “şöyle bir esneyeyim” deriz. Kendimizi yere bırakıp bacaklarımızı açmaya çalışmak veya parmak uçlarımıza dokunarak beklemek harika hissettirebilir. Ancak eklemlerimizi gerçekten korumak ve o kronik masa başı ağrılarından kurtulmak istiyorsak, sadece esnemek maalesef yetmiyor. İşte tam bu noktada hayatımıza mobilite egzersizleri giriyor. Peki, her gün yaptığınız o klasik esneme hareketleri neden bazen yetersiz kalıyor ve eklemlerimizi gerçekten “özgürleştirmek” için ne yapmamız gerekiyor?

Esneklik ve Mobilite: Aynı Şey Değil mi?

Sporda en çok karıştırılan iki kavram kesinlikle esneklik ve mobilite ikilisidir. Birbirlerinin yerine kullanılsalar da aralarında hayati bir fark vardır. Bu farkı anlamak, antrenmanlarınızdan aldığınız verimi tamamen değiştirecektir.

Esneklik (Flexibility) Nedir?

Esneklik, bir kasın veya kas grubunun pasif olarak ne kadar uzayabildiğidir. Örneğin, yere oturup bacağınıza doğru uzandığınızda yerçekiminin ve vücut ağırlığınızın yardımıyla kasınızı esnetirsiniz. Burada aktif bir kas gücü veya eklem kontrolü gerekmez; sadece dokunun uzama kapasitesi ölçülür.

Mobilite (Mobility) Nedir?

Mobilite ise bir eklemin kendi kas gücüyle, aktif olarak kontrol edilebilen hareket açıklığıdır (Range of Motion). Yani sadece “bacağınızın ne kadar açıldığı” değil, “bacağınızı havada kendi kas gücünüzle ne kadar yüksekte ve stabil tutabildiğiniz” mobilitenin konusudur. Mobilite, esnekliğin üzerine güç ve kontrol eklenmiş halidir.

Neden Sadece Esnemek Yetmiyor?

Eğer çok esnek biriyseniz ama o hareket açıklığında yeterli güce sahip değilseniz, sakatlanmalara son derece açıksınız demektir. Kontrol edemediğiniz bir esneklik, eklemleriniz için dengesiz bir zemin yaratır. Spor bilimlerinde yapılan araştırmalar gösteriyor ki, sadece pasif esneme yapmak antrenman öncesinde performansı artırmadığı gibi, sakatlık riskini de doğrudan azaltmıyor. Güçlü bir eklem sağlığı için eklemi çevreleyen kasların, o hareket açısında aktif olarak çalışabilmesi gerekir.

Örneğin, squat yaparken dibe çökmekte zorlanıyorsanız sorun muhtemelen kaslarınızın kısa olması değil, kalça ve ayak bileği eklemlerinizin aktif hareket kapasitesinin (mobilitesinin) kısıtlı olmasıdır.

Postür Düzeltme ve Günlük Konfor

Günümüzün büyük kısmını bilgisayar başında, omuzlarımız öne doğru çökmüş şekilde geçiriyoruz. Bu durum zamanla göğüs kaslarının kısalmasına, sırt kaslarının ise zayıflayıp uzamasına neden olur. Kronikleşen bu duruş bozukluğu için sadece esneme hareketleri yapmak geçici bir rahatlama sağlar. Kalıcı bir postür düzeltme süreci için göğüs kafesini açan ve sırtı aktif olarak devreye sokan mobilite egzersizlerine ihtiyacımız vardır. Eklemler olması gerektiği gibi hareket ettiğinde, vücut doğal dengesini bulur ve o sinir bozucu sırt-boyun ağrıları kendiliğinden azalır.

Önemli Uyarı: Herhangi bir kronik eklem rahatsızlığınız, bel/boyun fıtığı geçmişiniz veya aktif bir sakatlığınız varsa, bu hareketlere başlamadan önce kesinlikle bir fizyoterapist veya doktora danışın. Egzersiz sırasında keskin, batıcı bir ağrı hissederseniz hareketi derhal durdurun.

Haftalık Mobilite Antrenman Programı

Mobiliteyi hayatınıza dahil etmek için saatlerinizi harcamanıza gerek yok. Günde sadece 10-15 dakikalık aktif bir rutin, birkaç hafta içinde kendinizi çok daha hafif ve güçlü hissetmenizi sağlayacaktır. Aşağıdaki basit ama etkili haftalık programı günlük rutininize ekleyebilirsiniz:


# HAFTALIK MOBİLİTE PROGRAMI (Günde 10-15 Dakika)

Pazartesi: Kalça Mobilitesi Focus
- 90/90 Kalça Rotasyonu (Her yön için 10 tekrar)
- World's Greatest Stretch (Her bacak için 5 yavaş tekrar)

Salı: Omurga & Göğüs Kafesi (Thoracic) Focus
- Cat-Cow (Yavaş tempo, 12 tekrar)
- Thread the Needle (Her yön için 8 tekrar)

Çarşamba: Aktif Dinlenme
- Hafif tempolu yürüyüş ve tüm vücut hafif sallantı/silkelenme hareketleri

Perşembe: Omuz & Boyun Mobilitesi Focus
- Duvar Y-T-W Egzersizi (Her harf için 8 tekrar)
- Omuz dislokasyonu (Sopa veya direnç bandı ile 10 tekrar)

Cuma: Ayak Bileği ve Diz Sağlığı Focus
- Duvara karşı ayak bileği mobilizasyonu (Her bilek için 12 tekrar)
- Cossack Squat (Yavaş ve kontrollü, her bacak için 6 tekrar)

Cumartesi & Pazar: Tüm Vücut Akışı (Full-body flow)
- Yukarıda en çok zorlandığınız 3 hareketi seçip uygulayın.

Eyleme Geçirilebilir İpuçları:

  • Nefesi Unutmayın: Hareketleri yaparken nefesinizi tutmayın. Zorlandığınız noktalarda derin nefes vererek kasların gevşemesine ve sinir sisteminin sakinleşmesine izin verin.
  • Zorlamayın: Mobilite egzersizleri bir yarış değildir. Önemli olan hareketi ne kadar büyük yaptığınız değil, ne kadar kontrollü yaptığınızdır.
  • Isınma Olarak Kullanın: Bu hareketleri ağırlık antrenmanlarınızdan önce dinamik bir ısınma rutini olarak da kullanabilirsiniz.

Unutmayın, esneklik kaslarınızın ne kadar uzayabildiğini gösterir; mobilite ise hayatı ne kadar rahat ve ağrısız hareket ettirebildiğinizi. Kendinize bir şans verin ve eklemlerinizin hak ettiği özgürlüğü onlara geri verin!

Category: Genel | LEAVE A COMMENT
Haziran 20 2025

Ev Fırınında Kusursuz Napoli Pizzası Yapmanın Sırları: Döküm Tava Tekniği

İtalyanların o dışı çıtır, içi bulut gibi hafif, üzeri hafifçe yanık Napoli pizzalarına hepimiz bayılıyoruz. Ancak iş evde napoli pizzası yapmaya geldiğinde fırınımızın gücü yetmiyor. Çünkü o taş fırınlar 450-500 derecede çalışırken, bizim emektar ev fırınları maksimum 250 dereceyi görüyor. Peki ne yapıyoruz? Havlu mu atıyoruz? Tabii ki hayır. Bugün, döküm tava ve fırın ızgarasını (broiler) birleştirerek evde o pofuduk kenarları yakalamanın hilesini açıklıyorum. Hazırsanız, mutfağı küçük bir Napoli pizzacısına çevirelim!

Porsiyon: 2 adet (25-30 cm)
Hazırlık Süresi: 20 dakika (Aktif) + 24 saat (Soğuk mayalanma)
Pişirme Süresi: 5 dakika

Kusursuz Pizza İçin Malzemeler

Gerçek bir Napoli pizzası için çok az malzemeye ihtiyacımız var. Kalite burada en önemli anahtar. İşte sepetimiz:

  • Hamur için (Pratik pizza hamuru tarifi):
    • 300 gr Tip 00 un (Yoksa yüksek proteinli ekmeklik un da iş görür)
    • 195 ml soğuk su (Yüzde 65 hidrasyon oranı için)
    • 9 gr tuz (İnce deniz tuzu tercih sebebi)
    • 1 gr kuru maya (Instant maya da kullanabilirsiniz)
  • Üzeri için:
    • 1 su bardağı konserve San Marzano domatesi (Ezip biraz tuz ekleyin)
    • 150 gr taze mozzarella (Suyu iyice süzülmüş olmalı)
    • Taze fesleğen yaprakları
    • Sızma zeytinyağı
    • Alternatif öneri: Mozzarella yerine kaliteli bir kaşar peyniri veya tulum peyniri kullanabilirsiniz. Şarküteri seviyorsanız, fırından çıkınca üzerine prosciutto veya kaliteli füme et eklemek harika bir dokunuş olur.

Adım Adım Döküm Tava Pizza Yapılışı

Bu teknik, döküm tavanın ocakta topladığı yüksek ısıyı, fırının üst ızgarasıyla birleştirir. Adımları dikkatlice takip edin, gerisi çok kolay.

  1. Hamuru Hazırlayın: Un, su, maya ve tuzu karıştırıp pürüzsüz olana kadar yoğurun. Hamuru iki bezeye ayırıp hava almayan bir kaba koyun ve buzdolabında 24 saat bekletin. Soğuk mayalanma, hamura o muazzam aromayı verir. Pişirmeden 2 saat önce dolaptan çıkarıp oda sıcaklığına getirin.
  2. Fırını ve Tavayı Isıtın: Fırınınızın sadece üst ızgara (grill/broiler) modunu en yüksek dereceye ayarlayın. Döküm tavanızı da ocağın en büyük gözünde, orta-yüksek ateşte yaklaşık 10-12 dakika iyice ısıtın. Tava adeta ısı saçmalı.
  3. Hamuru Açın: Tezgaha biraz irmik (semolina) veya un serpin. Hamur bezesini parmak uçlarınızla ortadan dışarıya doğru bastırarak açın. Kenarlardaki havayı ezmeyin ki pişerken pofur pofur kabarsın. Asla merdane kullanmayın!
  4. Tavaya Aktarın ve Soslayın: İyice ısınan döküm tavanın altını kapatmadan hemen önce açtığınız hamuru dikkatlice tavanın içine serin (Tava çok sıcak, dikkat edin!). Hemen domates sosunu yayın, mozzarella ve fesleğenleri dizip üzerine biraz zeytinyağı gezdirin. Hamurun altı tavada 1-2 dakika içinde çıtırdamaya başlayacaktır.
  5. Fırınlama Aşaması: Tavayı hemen fırının en üst rafına, ızgaranın tam altına yerleştirin. Yaklaşık 3-4 dakika içinde kenarların benek benek yandığını ve peynirin eridiğini göreceksiniz. Fırından çıkarıp sıcak servis yapın. İşte ilk nefis ev yapımı pizza karşınızda!

Neden Döküm Tava? İşin Kimyası

Ev fırınları havayı ısıtır ama ısıyı pizzaya hızlıca aktaramaz. Pizza taşı bu yüzden kullanılır. Ancak döküm tava pizza tekniği, döküm malzemenin ısıyı pizza taşından çok daha hızlı ve yoğun bir şekilde hamurun tabanına iletme yeteneğinden faydalanır. Ocağın üzerinde aldığınız o ekstrem sıcaklık, pizzanın altını saniyeler içinde pişirir. Fırının üst ızgarası ise Napoli usulü “leopard spots” dediğimiz o karakteristik yanık benekleri üstten vererek fırın açığını kapatır.

Püf Noktası: Islaklığa Dikkat Edin!

Taze mozzarella çok fazla su barındırır. Eğer peyniri doğrudan pizzaya koyarsanız, fırında suyunu salar ve pizzanızın ortası çorba gibi olur. Peyniri pizzaya eklemeden en az 1 saat önce dilimleyip süzgeçte bekletin, hatta kağıt havluyla fazla nemini alın. Çıtır bir taban için kuru malzeme hayati önem taşır.

Artık dışarıda dünyanın parasını verdiğiniz o gurme pizzaları evinizde, sadece tek bir döküm tava ve fırınla yapabilirsiniz. İlk denemede kenarlar istediğiniz gibi kabarmadıysa pes etmeyin, hamurun mayalanma süresiyle oynayın. Afiyet olsun!

Category: Genel | LEAVE A COMMENT
Haziran 13 2025

Cursor IDE ve Claude ile Kod Yazma Sürecini 10 Kat Hızlandırma Rehberi

Yazılım dünyasında kartlar yeniden dağıtılıyor ve bu sefer masada oldukça dişli bir oyuncu var. Eskiden saatlerce Stack Overflow’da “bu hata neden kaynaklanıyor?” diye debelenirken, bugün yapay zeka asistanımıza sadece hata çıktısını verip saniyeler içinde çözümü alabiliyoruz. İşte tam bu noktada, geleneksel editörlerin pabucunu dama atma iddiasıyla ortaya çıkan cursor ide ve onun en büyük yardımcısı claude sonnet sahneye giriyor. Eğer siz de yapay zeka kodlama dünyasında kaybolmadan, üretkenliğinizi gerçekten artırmak ve modern bir ai developer olmak istiyorsanız, doğru yerdesiniz. Bu rehberde, lafı hiç dolandırmadan, kendi deneyimlerimize dayanarak bu ikilinin neler yapabildiğini inceleyeceğiz.

Cursor IDE Nedir? Neden VS Code’u Bırakalım?

Cursor, aslında popüler kod editörü VS Code’un “fork” edilmiş, yani çatalı alınarak üzerine yapay zeka entegrasyonu yapılmış bir versiyonu. Bu ne anlama geliyor? VS Code’da kullandığınız tüm eklentiler, temalar ve kısayollar Cursor’da da aynen çalışıyor. Geçiş yapmak tam olarak 30 saniyenizi alıyor.

Peki neden geçelim? Çünkü Cursor, yapay zekayı bir eklenti (Copilot gibi) olarak değil, editörün tam kalbine konumlandırıyor. Kod yazarken editörün projenizin tamamını (context) okuyabilmesi, sizinle birlikte dosyaları tarayıp hata ayıklayabilmesi muazzam bir konfor sunuyor.

[Görsel: Cursor IDE genel arayüzü ve entegre chat panelinin görünümü]

Claude 3.5 Sonnet: Neden GPT-4o Değil de Claude?

Yapay zeka modelleri arasında kıyasıya bir rekabet var ancak dürüst olalım: Kod yazma, mantık yürütme ve talimatları takip etme konusunda claude sonnet şu an pazarın tartışmasız lideri. GPT-4o hızlı ve pratik olabilir ancak karmaşık kod bloklarını analiz ederken veya “bunu şu mimariye göre baştan yaz” dediğinizde Claude Sonnet çok daha az hata (hallucination) yapıyor ve çok daha temiz, okunabilir kodlar üretiyor.

İki Dev Güç Birleşince Ne Oluyor?

Cursor IDE içinde Claude Sonnet’i aktif ettiğinizde, artık sadece bir otomatik tamamlayıcıya sahip olmuyorsunuz. Karşınızda projenizin tüm klasör yapısını bilen, yazdığınız kütüphaneleri anlayan ve sizinle bir Senior Developer gibi tartışabilen bir iş ortağı buluyorsunuz.

Gerçek Bir Senaryo: Sıfırdan Bir Express.js API ve Caching Mekanizması

Hemen teoriden pratiğe geçelim. Amacımız, harici bir hava durumu API’sinden veri çeken ve bu verileri Redis ile cache’leyen basit bir Express.js API’si yazmak. Cursor ve Claude ikilisini kullanarak bunu nasıl dakikalar içinde yapabileceğimizi görelim.

Öncelikle boş bir klasör açıp Cursor içindeki “Composer” modunu (Ctrl + I veya Cmd + I) açıyoruz ve Claude’a şu komutu veriyoruz:

# Projeyi başlatmak ve gerekli paketleri kurmak için terminali kullanacağız
npm init -y
npm install express axios redis redis-om dotenv

Ardından Composer ekranına şu talimatı yazıyoruz: “Bana harici bir hava durumu API’sinden veri alan, gelen verileri 1 dakika boyunca Redis’te tutan ve hata yönetimini düzgün yapan bir Node.js Express yapısı kur. Proje yapısı modüler olsun.”

[Görsel: Cursor Composer arayüzünde Claude Sonnet ile çoklu dosya oluşturma süreci]

Claude saniyeler içinde bizim için server.js, config/redis.js ve controllers/weatherController.js dosyalarını oluşturuyor ve içlerini dolduruyor. Üstelik sadece kodu yazmakla kalmıyor, .env dosyasında hangi değişkenleri tanımlamamız gerektiğini de söylüyor.

// controllers/weatherController.js dosyasından bir kesit
const axios = require('axios');
const redisClient = require('../config/redis');

exports.getWeather = async (req, res) => {
    const { city } = req.params;
    const cacheKey = `weather:${city.toLowerCase()}`;

    try {
        // Önce cache kontrolü
        const cachedData = await redisClient.get(cacheKey);
        if (cachedData) {
            return res.status(200).json({ source: 'cache', data: JSON.parse(cachedData) });
        }

        // Cache'te yoksa API'ye istek at
        const response = await axios.get(`https://api.weatherapi.com/v1/current.json?key=${process.env.API_KEY}&q=${city}`);
        const weatherData = response.data;

        // Redis'e 60 saniye süreyle kaydet
        await redisClient.setEx(cacheKey, 60, JSON.stringify(weatherData));

        return res.status(200).json({ source: 'api', data: weatherData });
    } catch (error) {
        return res.status(500).json({ error: error.message });
    }
};

Biz tek satır kod yazmadık. Sadece mimariyi belirledik ve süreci yönettik. İşte gerçek bir ai developer çalışma pratiği tam olarak budur.

Yapay Zeka ile Kodlamanın Altın Kuralları

Cursor kullanırken hüsrana uğramamak için şu kurallara dikkat etmelisiniz:

  • @ Sembolünü Etkin Kullanın: Cursor’da chat kısmına @Files yazarak sadece ilgili dosyayı, @Web yazarak güncel internet dökümanlarını yapay zekaya bağlam olarak sunabilirsiniz.
  • Küçük Adımlarla İlerleyin: Yapay zekadan tek seferde devasa bir e-ticaret sitesi yazmasını isterseniz başarısız olur. Önce veritabanı şemasını yazdırın, sonra auth sistemini, ardından sepet işlemlerini adım adım kodlatın.
  • Körlemesine Güvenmeyin: Claude harika kod yazar ama mantık hataları yapabilir. Kodu her zaman test edin ve ne yazdığını anlamaya çalışın.

Karşılaştırma Tablosu: Artılar ve Eksiler

Cursor ve Claude kombinasyonunun gerçekçi bir değerlendirmesini yapalım:

Özellik Artıları (+) Eksileri (-)
Kod Kalitesi Claude Sonnet sayesinde mükemmel refactoring ve temiz kod. Bazen çok eski kütüphane versiyonlarını önerebiliyor.
Hız ve Entegrasyon VS Code eklentileriyle tam uyumlu, öğrenme eğrisi sıfır. Büyük projelerde indeksleme yaparken sistem kaynağı tüketimi artabiliyor.
Çoklu Dosya Yönetimi Composer ile tek seferde 5-6 dosyayı birden güncelleyebilme. Çok karmaşık değişikliklerde bazen kodları birbirine karıştırabiliyor.

Fiyatlandırma ve Ücretsiz Alternatifler

Gelelim işin duygusal kısmına. Cursor IDE, aylık 20 premium Claude/GPT isteğiyle birlikte ücretsiz bir plan (Hobby) sunuyor. Ancak aktif olarak kullanacaksanız, aylık 20$ olan Pro üyeliği almanız gerekiyor. Bu üyelik size aylık 500 hızlı yapay zeka isteği hakkı veriyor.

Bütçem yok diyenler için ücretsiz alternatifler:

  1. VS Code + Continue.dev: Tamamen açık kaynaklı bir eklentidir. Ollama ile bilgisayarınızda yerel çalışan modelleri veya Gemini’nin ücretsiz API anahtarını bağlayarak ücretsiz kullanabilirsiniz.
  2. Roo Code (Eski adıyla Roo Cline): VS Code üzerinde çalışan, Cursor benzeri dosya oluşturma yeteneklerine sahip harika bir açık kaynaklı yapay zeka asistanı.

Son Söz: Geliştirici Olarak Rolümüz mü Değişiyor?

Evet, değişiyor. Artık sadece “kod yazan” kişi olmak yetmiyor. Cursor ve Claude gibi araçlar sayesinde artık “sistem tasarlayan”, “yön veren” ve “kod kalitesini denetleyen” birer orkestra şefi haline geliyoruz. Bu dönüşüme ne kadar hızlı adapte olursanız, sektörde o kadar kalıcı ve değerli olursunuz. Denemekten korkmayın!

Category: Genel | LEAVE A COMMENT
Haziran 6 2025

Ollama ve Open-WebUI ile Kendi Sunucunuzda Gizli ve Ücretsiz LLM Çalıştırın

Yapay zeka araçları hayatımızın merkezine yerleşti ancak akıllarda hep aynı soru var: Verilerimiz nereye gidiyor? OpenAI, Anthropic ya da Google gibi devlere gönderdiğimiz her prompt, onların sunucularında işleniyor ve gelecekteki modelleri eğitmek için kullanılabiliyor. İşte tam bu noktada yapay zeka gizlilik endişeleri devreye giriyor. Eğer siz de şirketinizin hassas verilerini, kişisel günlüklerinizi veya geliştirdiğiniz gizli kodları bulutla paylaşmak istemiyorsanız, çözüm kendi yerel llm sisteminizi kurmak. Bu rehberde, Docker üzerinde adım adım ollama kurulumu yapacak ve şık bir arayüz sunan open webui ile kendi ChatGPT alternatifimizi tamamen ücretsiz ve internete bile ihtiyaç duymadan nasıl çalıştıracağımızı göreceğiz.

Neden Yerel LLM? Bulut Şirketlerine Karşı Dijital Egemenlik

Açık kaynaklı yapay zeka modelleri (Llama 3, Mistral, Gemma 2 gibi) son bir yılda inanılmaz bir gelişim gösterdi. Artık milyarlarca parametrelik bu modelleri çalıştırmak için süper bilgisayarlara ihtiyacımız yok. Evinizdeki ortalama bir oyuncu bilgisayarı veya küçük bir ev sunucusu (home lab) bu iş için biçilmiş kaftan.

Peki neden bu zahmete girelim? Yanıt basit: Bağlam ve kontrol. Yerel bir model kullandığınızda, internet bağlantınız olmasa bile yapay zekanız çalışmaya devam eder. Daha da önemlisi, modelle paylaştığınız hiçbir şey bilgisayarınızın dışına çıkmaz. “Prompt” dediğimiz girdiler tamamen yerel disklerde kalır ve üçüncü şahısların eline geçmez.

Gereksinimler: Donanım ve Yazılım Altyapısı

Yerel bir dil modeli çalıştırmak için en kritik bileşen ekran kartınızın belleğidir (VRAM). İşlemci (CPU) ile de çalıştırabilirsiniz ancak bu durumda kelimelerin ekrana gelme hızı kaplumbağa hızında olacaktır.

  • Asgari Donanım: En az 8 GB RAM ve modern bir CPU (CPU modu için) veya minimum 6 GB VRAM’e sahip bir Nvidia GPU (Örn: RTX 3060).
  • Önerilen Donanım: 12 GB+ VRAM’e sahip Nvidia GPU veya Apple Silicon M1/M2/M3 çipli Mac (Mac bilgisayarlar birleşik bellek kullandığı için bu işte çok başarılıdır).
  • Yazılım: Sisteminizde Docker ve Docker Compose kurulu olmalıdır.

Docker ile Ollama Kurulumu ve Open-WebUI Entegrasyonu

Sistemi tek tek kurmak yerine Docker kullanarak her şeyi tek bir komutla ayağa kaldıracağız. Bu yöntem hem sistemimizi kirletmez hem de ileride güncellemeleri tek tuşla yapmamızı sağlar.

İlk olarak projemiz için boş bir klasör oluşturalım ve içine docker-compose.yml adında bir dosya yaratalım. Ardından aşağıdaki yapılandırmayı bu dosyanın içine yapıştıralım:

version: '3.8'

services:
  ollama:
    volumes:
      - ./ollama:/root/.ollama
    container_name: ollama
    pull_policy: always
    tty: true
    restart: unless-stopped
    image: ollama/ollama:latest
    # Eğer Nvidia ekran kartınız varsa aşağıdaki deploy bloğunun önündeki # işaretlerini kaldırın:
    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: all
    #           capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - ./open-webui:/app/backend/data
    ports:
      - 3000:8080
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    extra_hosts:
      - "host.docker.internal:host-gateway"
    restart: unless-stopped
    depends_on:
      - ollama

Dosyayı kaydettikten sonra terminalinizden bu klasöre gidin ve şu komutu çalıştırın:

docker compose up -d

Docker, gerekli imajları indirecek ve arka planda servisleri başlatacaktır. Tarayıcınızı açıp http://localhost:3000 adresine gittiğinizde sizi şık bir giriş ekranı karşılayacak.

[Görsel: Open-WebUI ilk giriş ve kayıt olma ekranı arayüzü]

İlk Modelin İndirilmesi ve Test Aşaması

Open-WebUI ilk açıldığında sizden bir hesap oluşturmanızı isteyecektir. Bu hesap tamamen yerel olarak bilgisayarınızda tutulur ve internete gönderilmez. İlk kaydolan kullanıcı otomatik olarak “Admin” (Yönetici) yetkisine sahip olur.

Giriş yaptıktan sonra sol alttaki profil resminize tıklayıp Settings > Models sekmesine gidin. Buraya indirmek istediğimiz modelin adını yazmamız gerekiyor. Başlangıç için hem hızlı hem de Türkçe performansı fena olmayan Llama 3 (8B) modelini öneririm. Kutuya sadece llama3 yazıp indir butonuna basın.

[Görsel: Open-WebUI ayarlar menüsünde Llama 3 modelinin indirilme süreci]

Gerçekçi Bir Test: Llama 3 Ne Kadar Başarılı?

Model indikten sonra üst menüden indirdiğimiz modeli seçip sohbete başlayabiliriz. Ben kendi yaptığım testlerde yerel LLM’e şu soruyu yönelttim:

“Bana Python ile yazılmış, verilen bir metindeki kelimeleri sayan basit bir fonksiyon yazar mısın?”

Llama 3, bu isteği yaklaşık 2 saniye içinde yanıtladı ve kod bloklarını eksiksiz şekilde önüme koydu. Yanıt hızı (token per second), kullandığınız ekran kartına göre değişecektir. RTX 3060 ekran kartımla saniyede yaklaşık 40 kelime (token) üretebildim ki bu değer ChatGPT Plus hızına oldukça yakın.

Artılar ve Eksiler: Yerel LLM vs Bulut Servisleri

Kendi yapay zekanızı çalıştırmak harika bir his olsa da, her güzel şeyin bir bedeli var. Aşağıdaki tabloda yerel sistemlerin ticari bulut servislerine karşı durumunu tarafsızca özetledim:

Özellik Yerel LLM (Ollama + Open-WebUI) Bulut Servisleri (ChatGPT / Claude)
Veri Gizliliği ✅ %100 Güvenli (Tamamen Çevrimdışı) ❌ Riskli (Verilerinizle model eğitilebilir)
Abonelik Ücreti ✅ Ücretsiz (Sonsuza kadar) ❌ Aylık ortalama 20$
İnternet Bağımlılığı ✅ İnternetsiz çalışabilir ❌ İnternet şarttır
Maksimum Akıl Yürütme 🟡 Donanımınıza bağlı (Llama 3 8B veya 70B) ✅ Çok Güçlü (GPT-4o, Claude 3.5 Sonnet)
Kurulum Kolaylığı ❌ Teknik bilgi ve Docker gerektirir ✅ Tek tıkla üye olup kullanılır

Maliyetler ve Ücretsiz Alternatifler

Ollama ve Open-WebUI tamamen ücretsiz ve açık kaynak kodludur. Tek maliyetiniz, bilgisayarınızın harcayacağı elektrik ve varsa başlangıçta satın alacağınız donanım yatırımıdır.

Eğer Docker kullanmak istemiyorsanız veya bu kurulum size karmaşık geldiyse, şu ücretsiz alternatifleri de değerlendirebilirsiniz:

  • LM Studio: Tek tıkla kurulabilen, Docker gerektirmeyen ve modelleri kendi içinden indirmenize izin veren harika bir masaüstü uygulamasıdır.
  • AnythingLLM: Dokümanlarınızı (PDF, Word vb.) yapay zekaya kolayca öğretip soru-cevap yapabileceğiniz, yine tamamen yerel çalışan kullanıcı dostu bir araçtır.

Son Sözler ve Değerlendirme

Kendi yerel LLM sisteminizi kurmak, yapay zeka gizlilik hassasiyeti olan her geliştirici ve teknoloji meraklısı için bir dönüm noktasıdır. Ollama’nın sunduğu sade arka plan motoru ve Open-WebUI’ın modern arayüzü birleştiğinde, evimizde kendi küçük ChatGPT’mizi çalıştırmak artık hayal değil. Eğer elinizde güçlü bir GPU varsa, bu kuruluma şans vermenizi kesinlikle öneririm. Gelecek, verilerini kendi kontrolünde tutabilenlerin olacak.

Category: Genel | LEAVE A COMMENT
Mayıs 23 2025

Kitle Turizminden Kaçış: Japonya’nın Gizli Köyleri ve Nakasendo Yolu

Japonya denince aklımıza hemen neon ışıklarıyla parıldayan Tokyo caddeleri ya da Kyoto’nun insan seli altındaki tapınakları geliyor. Peki ya size ülkenin kalbinde, zamanın adeta 17. yüzyılda durduğu, samurayların ve postacıların ayak izlerini taşıyan bambaşka bir dünya olduğunu söylesem? Bugün, popüler rotaların dışına çıkıp modern hayatın hızını biraz yavaşlatıyoruz. Alışılmış bir japonya gezi rehberi okumaktan sıkılanlar ve seyahatlerinde daha derin bir bağ arayanlar için, ülkenin en büyüleyici alternatif rotalar listesinin başında gelen nakasendo yolu ve onun sunduğu benzersiz yavaş seyahat felsefesine derin bir dalış yapıyoruz.

Kalabalıkları Arkada Bırakmak: Neden Nakasendo?

Edo Dönemi’nde Tokyo (o zamanki adıyla Edo) ve Kyoto’yu birbirine bağlayan beş ana ticaret yolu vardı. Bunlardan en dağlık, en zorlu ama bir o kadar da güvenli olanı Nakasendo Yolu’ydu. Deniz yolu yerine dağları aşmayı tercih eden samuraylar, tüccarlar ve saray mensupları bu yolu arşınlardı. Günümüzde bu tarihi yolun büyük kısmı asfaltın altında kalmış olsa da, Kiso Vadisi içinde yer alan Magome ve Tsumago köyleri arasındaki bölüm, aslına tamamen sadık kalınarak korunmuş durumda.

Burayı özel kılan şey sadece korunmuş ahşap evler değil, yerel halkın bu mirası yaşatma biçimi. Köylerde elektrik kabloları yerin altından geçiyor, motorlu taşıtların girmesi günün büyük bölümünde yasak ve hiçbir modern tabela tarihi dokuyu bozmuyor. Buraya adım attığınızda, turizm endüstrisinin sizin için hazırladığı bir dekora değil, yaşayan bir tarihe tanıklık ediyorsunuz.

Nakasendo’da yürürken yolda sık sık metal çanlar göreceksiniz. Bu çanlar sadece nostaljik birer süs değil; bölgedeki siyah ayıları uzak tutmak için yerleştirilmiş gerçek güvenlik araçları. Yanlarından geçerken çanı güçlüce çalmak hem yerel bir gelenek hem de güvenli bir yürüyüşün anahtarı.

Yolculuk Başlasın: Ulaşım ve Zamanlama

Bu rotaya başlamak için en mantıklı lojistik merkez Nagoya. Nagoya İstasyonu’ndan kalkan JR Shinano sınırlı ekspres treni ile yaklaşık 50 dakikada Nakatsugawa İstasyonu’na ulaşabilirsiniz. Bu tren yolculuğu için bilet ücreti yaklaşık 3,000 JPY civarında tutuyor. Nakatsugawa’dan ise Magome köyüne giden yerel otobüsler kalkıyor; bu kısa yolculuk da bütçenize sadece 570 JPY olarak yansıyor.

Yürüyüşü Magome’den Tsumago’ya doğru yapmak, yokuş aşağı eğimin daha fazla olması nedeniyle fiziksel olarak çok daha konforlu. Yaklaşık 8 kilometrelik bu parkur, ortalama bir tempo ve bolca fotoğraf molasıyla 2,5 ila 3 saat sürüyor. Eğer büyük sırt çantalarıyla seyahat ediyorsanız, Magome’deki turizm ofisine çantanızı teslim edip cüzi bir ücret karşılığında (valiz başına yaklaşık 1,000 JPY) Tsumago’daki ofise gönderilmesini sağlayabilirsiniz. Böylece sadece küçük bir sırt çantası ve suyunuzla özgürce yürüyebilirsiniz.

# Nakasendo bütçe ve lojistik hızlı kontrol aracı
$ nakasendo-plan --from Nagoya --to Nakatsugawa
[Tren] JR Shinano Express | Süre: 50 dk | Ücret: 3,100 JPY
[Otobüs] Nakatsugawa -> Magome | Süre: 25 dk | Ücret: 570 JPY
[Bagaj Taşıma] Magome Danışma -> Tsumago | Ücret: 1,000 JPY (Valiz başına)
[Önerilen Sezon] İlkbahar (Nisan-Mayıs) & Sonbahar (Ekim-Kasım)

Adım Adım Tarihin İçinden Geçmek

Yürüyüş Magome’nin taş döşeli, dik yokuşlu sokaklarından başlıyor. Sağlı sollu uzanan ahşap su çarkları ve geleneksel evlerin arasından geçerken, yerel fırınlardan yükselen “Oyaki” (kestane veya tatlı fasulye dolgulu buharda pişmiş çörekler) kokusu sizi kendine çekecektir. Tanesi yaklaşık 300 JPY olan bu çörekler, yürüyüş öncesi harika bir enerji kaynağı oluyor.

Köy sınırlarından çıkıp ormanlık patikaya girdiğinizde ise doğanın sesi baş başa kalıyorsunuz. Dev sedir ağaçlarının gölgesinde, şırıl şırıl akan derelerin üzerindeki taş köprülerden geçerek ilerliyorsunuz. Yolun tam ortasında yer alan tarihi bir çay evinde (Tateba Teahouse) ücretsiz yeşil çay ikram eden ve odun ateşinde ısınan yerel gönüllülerle karşılaşacaksınız. Burada acele etmeyin; ikram edilen çayı yudumlayıp, bağış kutusuna birkaç yüz yen bırakarak bu güzel geleneğin sürmesine katkıda bulunun. İşte yavaş seyahat tam olarak budur: tüketmek değil, anın ve paylaşılan emeğin parçası olmak.

Samurayların İzinde Bir Gece: Minshuku Deneyimi

Günübirlikçiler öğleden sonra son otobüslerle büyük şehirlere dönerken, Nakasendo’nun gerçek büyüsü akşam karanlığı çöktüğünde başlar. Sokakları aydınlatan fenerlerin altında, ahşap evlerin pencerelerinden sızan sıcak ışıklar eşliğinde yürümek için Tsumago’da bir gece konaklamalısınız.

Büyük ve lüks ryokan otelleri yerine, yerel ailelerin işlettiği ve “Minshuku” denilen geleneksel pansiyonları tercih etmek hem bütçe dostu hem de son derece samimi bir deneyim sunuyor. Kişi başı akşam yemeği ve kahvaltı dahil ortalama 9,000 – 13,000 JPY arasında değişen bu konaklamalarda, ev sahibinin kendi bahçesinden topladığı nehir balıkları, yerel mantarlar ve taze sebzelerle hazırladığı akşam yemeğini tatma şansı buluyorsunuz. Tatami minderleri üzerinde, pamuklu futon yataklarda uyumak ve sabahın erken saatlerinde sis çökmüş boş sokaklarda yürümek, Japonya seyahatinizin en unutulmaz anısı olmaya aday.

Minshuku konaklamaları için rezervasyonlar genellikle popüler booking sitelerinde yer almaz. En iyi ve bütçe dostu seçenekleri bulmak için Magome veya Tsumago turizm ofislerinin resmi web siteleri üzerinden doğrudan e-posta ile veya yerel turizm birlikleri aracılığıyla rezervasyon yapmanız gerekir. Sezon dışı dönemlerde bile bu odalar çok hızlı tükendiği için en az 3 ay önceden harekete geçmekte fayda var.

Alternatif Rotalar ve Son Söz

Tsumago’ya ulaştıktan sonra yolculuğunuzu burada bitirmek zorunda değilsiniz. Kondisyonuna güvenen gezginler, trenle birkaç durak ilerideki Narai-juku köyüne de geçebilirler. “Bin evlik Narai” olarak bilinen bu köy, Nakasendo üzerindeki en uzun posta istasyonuydu ve mimari açıdan diğerlerine kıyasla çok daha geniş bir alana yayılıyor.

Japonya sadece hızlı trenlerden ve kalabalık kavşaklardan ibaret değil. Nakasendo Yolu bize, durup nefes almanın, doğayla uyum içinde yaşamanın ve geçmişe saygı duymanın güzelliğini hatırlatıyor. Eğer siz de bir sonraki seyahatinizde turist olmaktan çıkıp birer gezgin gibi hissetmek istiyorsanız, sırt çantanızı hazırlayın ve samurayların yürüdüğü o sessiz patikalara doğru yola çıkın.

Category: Genel | LEAVE A COMMENT
Mayıs 16 2025

Kubernetes Küme Yönetiminde GPU İsrafını Önleme ve Maliyet Optimizasyonu

Biz SRE’lerin kabusu genelde bellek sızıntıları veya çöken DNS servisleridir sanıyorduk. Yanılmışız. Asıl kabus, şirketin yapay zeka trenine binmesiyle başlayan ve ay sonunda CFO’nun masasında patlayan o meşhur bulut faturasıymış. Evet, kubernetes gpu yönetimi ve beraberinde gelen astronomik maliyetler, modern cloud devops dünyasının yeni canavarı. Veri bilimcilerin “Deney yapıyorum” diyerek rezerve ettiği ama günün %95’inde boş yatan A100’leri görünce saç baş yoluyorsanız, doğru yerdesiniz. Bu yazıda, gpu monitoring ve k8s cost optimization tekniklerini kullanarak GPU israfını nasıl önleyeceğimizi, teoriyi geçip doğrudan üretim ortamında uygulayabileceğiniz konfigürasyonlarla inceleyeceğiz.

Göremediğin Şeyi Optimize Edemezsin: GPU İzleme altyapısı

Kubernetes’in native metrik sunucusu (metrics-server), CPU ve bellek konusunda harikalar yaratsa da GPU dünyasından tamamen habersizdir. Bir podun GPU talep etmesi ve Kubernetes scheduler tarafından o poda bir GPU atanması, o GPU’nun gerçekten aktif kullanıldığı anlamına gelmez. Bizim için kritik olan iki metrik var: GPU Duty Cycle (hesaplama gücü kullanımı) ve Framebuffer (VRAM) kullanımı.

Bu metrikleri toplamak için NVIDIA’nın DCGM Exporter aracını kümemize kurmak zorundayız. Prometheus ile entegre çalışan bu ajan, bize pod seviyesinde GPU kullanım detaylarını verir.

DCGM Exporter Kurulumu ve Prometheus Entegrasyonu

Aşağıdaki Helm komutuyla DCGM Exporter’ı kümenize hızlıca dahil edebilirsiniz. Burada kritik nokta, servis izleme (ServiceMonitor) özelliğini aktif etmektir:

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update

helm install --namespace gpu-operator \
  --create-namespace \
  --set dcgmExporter.serviceMonitor.enabled=true \
  gpu-operator nvidia/gpu-operator

Kurulum tamamlandıktan sonra Prometheus üzerinde şu sorguyu (PromQL) çalıştırarak, rezerve edilmiş ama kullanılmayan (idle) GPU’ları anında tespit edebilirsiniz:

# Son 1 saat içinde ortalama GPU kullanımı %5'in altında olan ve pod tarafından rezerve edilmiş GPU'lar
avg_over_time(DCGM_FI_DEV_GPU_UTIL[1h]) < 5 and on(pod) kube_pod_container_resource_requests{resource="nvidia.com/gpu"} > 0

Neden bu sorgu? Çünkü sadece DCGM_FI_DEV_GPU_UTIL metriğine bakmak yanıltıcı olabilir; sistemde başıboş duran, hiçbir podun istemediği GPU’ları da listeler. Bizim amacımız, bir geliştirici tarafından rezerve edilip kilitlenmiş ama kullanılmayan “israf” kaynakları yakalamak.

GPU Bölümleme Teknolojileri: MIG ve Time-Slicing

Her podun koca bir A100 veya L4 GPU’ya ihtiyacı yoktur. Basit bir model çıkarımı (inference) veya hafif bir Jupyter Notebook hücresi için koca bir donanımı kapatmak tam bir kaynak israfıdır. Kubernetes dünyasında GPU’ları bölmenin iki popüler yolu vardır: donanımsal MIG (Multi-Instance GPU) ve yazılımsal Time-Slicing.

1. Donanımsal Bölümleme: NVIDIA MIG

MIG, fiziksel bir GPU’yu tamamen izole edilmiş mini GPU’lara (instance) böler. Bellek ve hata toleransı donanım seviyesinde izole edilir; yani bir podun çökmesi diğer “slice”ı etkilemez. A100 ve H100 gibi enterprise kartlarda desteklenir.

GPU Operator yüklü bir kümede MIG profilini aktif etmek için node üzerindeki etiketi değiştirmemiz yeterlidir:

kubectl label nodes <node-adi> nvidia.com/mig.config=all-1g.10gb --overwrite

Bu komut, uyumlu bir GPU’yu her biri 10GB VRAM’e sahip bağımsız parçalara böler. Podlarınız artık nvidia.com/gpu yerine doğrudan bu profilleri isteyebilir:

resources:
  limits:
    nvidia.com/mig-1g.10gb: 1

2. Yazılımsal Bölümleme: GPU Time-Slicing

Eğer elinizde MIG desteklemeyen (örneğin T4, L4 veya RTX serisi) kartlar varsa, kurtarıcınız Time-Slicing’dir. Bu yöntem, GPU üzerinde zaman paylaşımlı (interleaved) çalışmayı sağlar. Bellek izolasyonu yoktur (biri hata yaparsa OOM olur), ancak dev/staging ortamları için can kurtarır.

Time-slicing yapılandırması için aşağıdaki ConfigMap’i oluşturup GPU Operator’e bildirmemiz gerekir:

apiVersion: v1
kind: ConfigMap
metadata:
  name: device-plugin-config
  namespace: gpu-operator-resources
data:
  any-name: |-
    version: v1
    sharing:
      timeSlicing:
        resources:
        - name: nvidia.com/gpu
          replicas: 4

Bu konfigürasyon, Kubernetes scheduler’a fiziksel olarak 1 adet olan GPU’yu sanal olarak 4 adetmiş gibi gösterir. Böylece 4 farklı pod aynı GPU’yu paylaşarak çalışabilir.

Karpenter ve Dynamic Autoscaling ile Scale-to-Zero

GPU makineleri pahalıdır. Gecenin bir yarısı çalışmayan bir eğitim (training) podu için AWS veya GCP üzerinde bir GPU makinesinin açık kalması, sabaha kadar dolar yakmak demektir. Kubernetes Cluster Autoscaler yerine Karpenter kullanmak, GPU maliyet optimizasyonunda çağ atlatır.

Neden Karpenter? Çünkü Karpenter, podun taints/tolerations ve kaynak isteklerine doğrudan bakarak milisaniyeler içinde doğru boyuttaki GPU makinesini (Spot veya On-Demand) ayağa kaldırabilir ve iş bittiğinde node’u anında yok edebilir (scale-to-zero).

Karpenter NodePool GPU Konfigürasyonu

GPU iş yüklerinizi Spot instance’lar üzerinde koşturmak, faturanızı %70’e varan oranda düşürür. İşte Karpenter için optimize edilmiş bir GPU NodePool tanımı:

apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu-spot-pool
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: karpenter.k8s.aws/instance-gpu-manufacturer
          operator: In
          values: ["nvidia"]
        - key: node.kubernetes.io/instance-type
          operator: In
          values: ["g4dn.xlarge", "g5.xlarge"]
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule
      disruption:
        consolidationPolicy: WhenEmpty
        consolidateAfter: 30s

Buradaki ince ayar disruption.consolidationPolicy: WhenEmpty ve consolidateAfter: 30s parametreleridir. GPU üzerindeki iş bittiği ve pod silindiği anda, Karpenter 30 saniye içinde o pahalı makineyi kapatır. Geleneksel autoscaler’lardaki 10 dakikalık varsayılan bekleme süresini bypass etmiş oluruz.

Uygulama Seviyesinde Optimizasyon: MPS (Multi-Process Service)

Eğer yoğun bir model çıkarım (inference) API’si çalıştırıyorsanız ve kuyrukta bekleyen binlerce istek varsa, Time-Slicing’in yarattığı bağlam geçişi (context switching) yükü CPU’yu ve GPU’yu yorar. NVIDIA MPS, tek bir GPU üzerinde birden fazla CUDA işleminin eşzamanlı ve sıfıra yakın overhead ile çalışmasını sağlar.

Kubernetes üzerinde MPS kullanmak için pod konfigürasyonunuza NVIDIA amblemli şu ortam değişkenlerini eklemeniz yeterlidir:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mps-inference-deployment
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: model-server
        image: my-inference-model:v1
        env:
        - name: CUDA_MPS_ACTIVE_THREAD_PERCENTAGE
          value: "33" # Donanım gücünün %33'ünü sınırla
        resources:
          limits:
            nvidia.com/gpu: 1

Bu sayede, aynı GPU’yu kullanan 3 pod, donanım kaynaklarını birbirini bloklamadan, sanki paralel donanımları varmış gibi yüksek performansla kullanır.

Özet ve “Ne Yapmalı?” Listesi

Kubernetes üzerinde GPU optimizasyonu yapmak tek bir hamleyle çözülecek bir iş değildir. Katmanlı bir yaklaşım gerektirir:

  • İzleme: DCGM Exporter kurun ve boşta yatan (idle) GPU’ları alarm sisteminize (Alertmanager) bağlayın.
  • Paylaşım: Geliştirme ortamlarında Time-Slicing, üretim ortamlarında ise izolasyon için MIG tercih edin.
  • Autoscaling: Karpenter ile scale-to-zero uygulayın. İş bittiğinde sunucunun anında kapandığından emin olun.
  • Satın Alma: Model eğitimi gibi kesintiye dayanıklı işlerde kesinlikle Spot/Preemptible instance kullanın.

Günün sonunda, doğru konfigüre edilmiş bir Kubernetes kümesi, AI projelerinizin hızından ödün vermeden bulut faturalarınızı yönetilebilir seviyelerde tutmanın tek yoludur.

Category: Genel | LEAVE A COMMENT