2026’da DevOps’a Yeniden Başlasaydım: Yapacağım ve Kaçınacağım 5 Şey

Sektörde uzun yılları devirdikten sonra geriye bakıp “Şimdiki aklım olsa bu altyapıyı kesinlikle böyle kurmazdım” dediğimiz anlar çok oluyor. Hele ki 2026 yılına geldiğimiz şu günlerde, eski usul pratiklerin birer birer tarihe gömüldüğünü görüyoruz. Modern bir devops kariyer planlaması yaparken, eski ezberlerin bugünün dünyasında nasıl birer teknik borç (technical debt) haline geldiğini anlamak hayati önem taşıyor. Bu yazıda, bulut bilisim dünyasının değişen dinamikleriyle güncel bir devops yol haritasi çizecek ve modern altyapi yonetimi süreçlerinde mutlaka yapmanız ve kesinlikle kaçınmanız gereken 5 kritik yaklaşımı ele alacağız.

Eğer 5+ yıllık deneyimli bir SRE veya DevOps mühendisiyseniz, “Kubernetes nedir, Dockerfile nasıl yazılır” gibi giriş seviyesi konuları çoktan geçtiğinizi biliyorum. Bu yüzden doğrudan can acıtan, production ortamlarında prodüktiviteyi ve kararlılığı artıran mimari kararlara odaklanacağız.

1. Yapacağım: Platform Engineering ve Crossplane / Kaçınacağım: Ham YAML ve Terraform Spagettisi

Yıllarca Terraform ile state yönetmeye, binlerce satırlık HCL kodları arasında kaybolmaya ve terraform apply komutunun bitmesini beklerken kahve içmeye alıştık. Ancak 2026’da, altyapıyı doğrudan geliştiricinin önüne ham YAML veya Terraform dosyalarıyla atmak kabul edilemez bir kognitif yük (cognitive load) yaratıyor. Artık yapmamız gereken şey, geliştiricilere Internal Developer Platform (IDP) sunmak.

Bu dönüşümün kalbinde ise Crossplane yer alıyor. Altyapıyı Kubernetes API’si üzerinden, kontrol düzlemi (control plane) mantığıyla yönetmek, Terraform state kilitlenmelerini ve manuel tetiklenen CI/CD süreçlerini tarihe gömüyor. “Neden böyle?” derseniz; çünkü sürekli mutabakat (continuous reconciliation) döngüsü, altyapının anlık durumunu (actual state) hedef durumla (desired state) her saniye eşitliyor. Dışarıdan yapılan manuel müdahaleler (drift) anında eziliyor.

Aşağıdaki örnekte, bir geliştiricinin cloud ekibine hiç dokunmadan, sadece Kubernetes CRD (Custom Resource Definition) kullanarak nasıl güvenli bir PostgreSQL veritabanı isteyebileceğini görüyoruz:

apiVersion: database.kertenkerem.net/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: billing-prod-db
  namespace: billing-team
spec:
  parameters:
    storageGB: 100
    version: "16"
  compositionSelector:
    matchLabels:
      provider: aws
      environment: production

Arka planda bu istek, Crossplane’in Composite Resource Definition (XRD) yapısı sayesinde AWS RDS instance’ına, güvenlik gruplarına ve gerekli IAM rollerine otomatik olarak çözümleniyor. Kaçınacağınız şey ise: Her mikro servis için ayrı bir Terraform modülü yazıp, bunu Jenkins/GitLab pipeline’larından tetiklemeye çalışmak.

2. Yapacağım: Programatik IaC (Pulumi/CDKTF) / Kaçınacağım: HCL Sınırlarında Loop Debelleşmeleri

Terraform’un HCL dili (HashiCorp Configuration Language) basit altyapılar için harikaydı. Ancak karmaşık mantıklar, dinamik döngüler, çoklu bölge (multi-region) replikasyonları ve test yazma süreçleri işin içine girdiğinde HCL tam bir işkenceye dönüşüyor. 2026’da artık altyapımızı gerçek programlama dilleriyle (TypeScript, Go, Python) tanımlıyoruz.

Neden programatik IaC? Çünkü yazılım mühendisliğinin son 30 yılda kazandığı tüm kazanımları (unit testing, mocking, inheritance, static analysis) altyapı koduna uygulayabiliyoruz. Bir S3 bucket konfigürasyonunu test etmek için artık plan çıktısını regex ile parse etmek zorunda değiliz; doğrudan Go veya TypeScript ile unit test yazabiliyoruz.

TypeScript ile yazılmış bir Pulumi örneğine göz atalım:

import * as aws from "@pulumi/aws";
import { PolicyDocument } from "@pulumi/aws/iam";

const environments = ["dev", "staging", "prod"];

environments.forEach(env => {
    const bucket = new aws.s3.BucketV2(`app-assets-${env}`, {
        tags: {
            Environment: env,
            ManagedBy: "pulumi",
        },
    });

    // Sadece prod için ek güvenlik politikaları
    if (env === "prod") {
        new aws.s3.BucketPublicAccessBlock(`block-prod-${env}`, {
            bucket: bucket.id,
            blockPublicAcls: true,
            blockPublicPolicy: true,
            ignorePublicAcls: true,
            restrictPublicBuckets: true,
        });
    }
});

Bunu HCL ile yapmaya kalktığınızda karşılaşacağınız dynamic blokları, for_each hileleri ve okunaksız ternary operatörleri yerine, temiz bir forEach döngüsü ve basit bir if bloğuyla işi çözüyoruz. Kodun bakımı ve test edilebilirliği katbekat artıyor.

3. Yapacağım: eBPF Tabanlı Gözlemlenebilirlik (Cilium) / Kaçınacağım: Her Pod’a APM Sidecar’ı Kakalamak

Gözlemlenebilirlik (observability) dünyasında 2026 yılı, kernel seviyesinde devrimin olgunlaştığı dönemdir. Eskiden her pod’un yanına (sidecar) bir log/metric forwarder koyardık ya da uygulama kodunun içine ağır APM kütüphaneleri entegre ederdik. Bu durum hem ciddi kaynak tüketimine (CPU/Memory overhead) yol açardı hem de network topolojisini izlemeyi karmaşıklaştırırdı.

Bugün ise eBPF (Extended Berkeley Packet Filter) ve onun kalesi olan Cilium var. Uygulama koduna tek bir satır dokunmadan, pod’ların yanına sidecar falan koymadan, doğrudan Linux kernel seviyesinde ağ trafiğini, sistem çağrılarını ve güvenlik ihlallerini izleyebiliyoruz.

Cilium kullanarak L7 seviyesinde (HTTP, gRPC) trafik izleme ve güvenlik politikası uygulamak için yazacağımız basit bir `CiliumNetworkPolicy` örneği:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: secure-api-limit
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: public-ingress
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/v1/public/.*"

Bu politika, kernel seviyesinde çalışır. Ne iptables kurallarının hantallığına takılır ne de uygulama katmanında proxy maliyeti yaratır. Saniyede yüz binlerce istek alan sistemlerde eBPF tabanlı gözlemlenebilirlik ve ağ yönetimi, bulut maliyetlerinizi (cloud spend) ciddi oranda düşürür.

4. Yapacağım: GitOps ve Progressive Delivery (Argo Rollouts) / Kaçınacağım: CI Pipeline’ından ‘kubectl apply’ Tetiklemek

CI/CD araçlarından (GitHub Actions, GitLab CI) production Kubernetes kümesine doğrudan erişim vermek, 2026 standartlarında büyük bir güvenlik açığıdır ve mimari bir hatadır. CI aracınızın ele geçirilmesi durumunda tüm production cluster’ınız saldırganın eline geçer. Ayrıca, pipeline yarıda kaldığında cluster’da neyin canlıda olduğunu bilemezsiniz (drift tespiti imkansızlaşır).

Çözüm: Çekme tabanlı (pull-based) GitOps yaklaşımı ve Canary/Blue-Green deployment’lar için Argo Rollouts kullanımı. Git, sistemin tek doğruluk kaynağıdır (Single Source of Truth) ve cluster içindeki bir agent (ArgoCD) sürekli olarak git reposunu dinleyerek değişiklikleri cluster’a çeker.

İşte aşamalı canlıya alma (Canary) sürecini yöneten bir Argo Rollout tanımı:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
spec:
  replicas: 10
  strategy:
    canary:
      analysis:
        templates:
          - templateName: prometheus-error-rate
        args:
          - name: service-name
            value: payment-service
      steps:
        - setWeight: 10
          pause: { duration: 5m }
        - setWeight: 50
          pause: { duration: 10m }

Bu konfigürasyon sayesinde yeni sürüm önce %10 trafiğe açılır. 5 dakika boyunca Prometheus üzerindeki hata oranları (error rate) analiz edilir. Eğer hata oranı eşik değerin üzerindeyse, sistem otomatik olarak rollback yapar. Kimsenin gece yarısı alarm alıp uyanmasına veya manuel geri alma işlemi yapmasına gerek kalmaz.

5. Yapacağım: Sanal Cluster’lar (vcluster) ile Local-First Geliştirme / Kaçınacağım: Ortak Staging Cehennemi

“Staging ortamında benim servisimin deployment’ı patladı, kim güncelledi?”, “Database şemasını kim değiştirdi?” gibi soruları duymaktan yorulmadınız mı? Geliştiricileri tek bir büyük staging cluster’ına sıkıştırmak, geliştirme hızını (developer velocity) sıfırlayan en büyük darboğazlardan biridir.

Bunun yerine yapılması gereken, her geliştiriciye veya her özelliğe (feature branch) özel, saniyeler içinde ayağa kalkan sanal Kubernetes cluster’ları (vcluster) sağlamaktır. vcluster, fiziksel bir Kubernetes kümesi içinde tamamen izole, kendi API server’ı ve veri depolama alanı olan hafif bir sanal cluster oluşturur.

Geliştiricinin kendi makinesinde veya bir CI pipeline’ında vcluster oluşturması tek bir komuta bakar:

# vcluster CLI ile yeni bir sanal küme oluşturma
vcluster create feature-payment-sandbox --namespace dev-environments

# Kümenin kubeconfig dosyasını otomatik olarak alma ve bağlanma
vcluster connect feature-payment-sandbox

# Artık tamamen izole bir kümedesiniz, dilediğiniz gibi CRD kurun, test edin
kubectl get namespaces

Bu yöntemle, staging ortamlarını yönetme yükünüz neredeyse sıfıra iner. Geliştirici işini bitirdiğinde vcluster’ı siler ve kaynaklar ana cluster’a iade edilir. Altyapı maliyetleriniz düşerken, ekiplerin birbirine bağımlılığı ortadan kalkar.

Özet: 2026’da Değer Yaratan DevOps Mühendisi Olmak

Modern bir devops kariyer planı, artık sadece araçları (tools) bilmekle ilgili değil; bu araçların organizasyona getirdiği yükü minimize etmekle ilgilidir. Bulut bilisim çözümleri karmaşıklaştıkça, bizim görevimiz bu karmaşıklığı soyutlayarak (abstraction) geliştiricilere pürüzsüz bir deneyim sunmaktır. Altyapi yonetimi süreçlerinde yukarıda bahsettiğimiz modern pratikleri benimseyerek, hem sistemlerinizin güvenilirliğini artırabilir hem de ekiplerinizin teslimat hızını katlayabilirsiniz.