DevOps Rolünü Anlamak: Yazılımcı mı Sysadmin mi?

Bir gün bir yazılımcı arkadaşım bana şunu sordu: “Sen tam olarak ne yapıyorsun? Kod da yazıyorsun, sunucu da yönetiyorsun, ama ne yazılımcısın ne de klasik sysadmin. Sen kimsin?” O soruyu duyduğumda güldüm. Çünkü bu sorunun cevabı, son on yılda teknoloji dünyasının en çok tartıştığı kimlik krizinin tam ortasındaydı. DevOps rolü, hem yazılımcıların hem de sistem yöneticilerinin birbirini küçümseyerek “o bizim işimiz değil” dediği her şeyi kapsıyor. Ve bu durum, bu rolü hem çok güçlü hem de bazen akıl almaz derecede yorucu yapıyor.

DevOps Nedir, Ne Değildir

Önce şunu netleştirelim: DevOps bir araç değil, bir kültür. Ama bu cümleyi söylediğinizde insanlar genellikle gözlerini devirip “ne demek istediğini anlamadım” bakışı atıyor. O yüzden somutlaştıralım.

DevOps, yazılım geliştirme (Dev) ve operasyon (Ops) ekiplerinin birbirinden bağımsız siloları yıkarak ortak sorumluluk üstlendiği bir çalışma modelidir. Ama pratikte bu ne anlama geliyor?

Klasik dünyada yazılımcı kodu yazar, test eder, paketi ops ekibine teslim eder ve “tamam ben bittim” der. Ops ekibi de bu paketi alır, “bu neden çalışmıyor” diye baş ağrısı yaşar ve aralarında bir duvar örülür. Bu duvarın adı ise “bu benim işim değil” sendromu.

DevOps’ta ise şöyle bir anlayış var: Kodu yazan kişi, o kodun üretimde nasıl davrandığından da sorumludur. Deployment pipeline’ını kuran kişi, yazılımcının geliştirme deneyimini de düşünmek zorundadır.

Peki bir DevOps mühendisi günlük hayatta ne yapar? Bunu şöyle özetleyebilirim:

Continuous Integration / Continuous Deployment pipeline’larını kurar ve yönetir
Altyapıyı kod olarak yazar (Infrastructure as Code)
Container orchestration sistemlerini yönetir
Monitoring ve alerting sistemleri kurar
Güvenlik pratiklerini geliştirme süreçlerine entegre eder
Yazılımcılar ile ops arasında köprü görevi görür

Yazılımcı ile Sistem Yöneticisi Arasındaki Fark Neredeydi

Eski dünyada iki ayrı dünya vardı. Ben her ikisinde de çalıştım, ikisini de çok iyi tanıyorum.

Sistem yöneticisi bakış açısından dünya şöyle görünürdü: Sunucu kararlı olmalı, uptime maksimum olmalı, değişiklik minimum olmalı. “Çalışıyorsa dokunma” felsefesi. Bu anlayış yanlış değildi, çünkü bir bankada üretim sunucusuna Cuma öğleden sonra deployment yapmak gerçekten tehlikeliydi.

Yazılımcı bakış açısından dünya ise tam tersi görünürdü: Hızlı iterasyon, sık deployment, yeni özellik. “Neden bu kadar yavaş gidiyoruz” sorusu. Bu anlayış da yanlış değildi, çünkü rekabet beklemiyordu.

İşte bu iki dünyayı birleştirme çabası DevOps’u doğurdu.

Şimdi bir senaryo üzerinden gidelim. Diyelim ki bir e-ticaret platformunda çalışıyorsunuz ve kara cuma yaklaşıyor.

Eski dünyada:

Yazılımcılar özelliği geliştirdi
QA ekibi test etti
Ops ekibine “production’a al” dedi
Ops ekibi “şimdi değil, kara cuma yakın” dedi
Gerilim tırmandı

DevOps dünyasında:

Feature flag’ler ile kod production’a alındı ama aktif değil
Load testing pipeline’da otomatik çalıştı
Kara cuma geldiğinde sadece flag açıldı
Herhangi bir sorun olursa otomatik rollback devreye girdi

Temel Araçlar ve Bunları Kim Kullanır

Şimdi gelelim işin pratik kısmına. DevOps mühendisleri hangi araçlarla çalışır ve bu araçları nasıl kullanır?

CI/CD Pipeline Örneği

Basit bir Jenkins pipeline’ı düşünelim. Bu pipeline hem yazılımcının kodu push etmesiyle tetiklenir hem de ops tarafından tanımlanmış ortamlara deploy eder.

# Jenkinsfile örneği - Groovy syntax
pipeline {
    agent any
    
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean package -DskipTests'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test'
                junit 'target/surefire-reports/*.xml'
            }
        }
        stage('Docker Build') {
            steps {
                sh 'docker build -t myapp:${BUILD_NUMBER} .'
                sh 'docker push registry.example.com/myapp:${BUILD_NUMBER}'
            }
        }
        stage('Deploy to Staging') {
            steps {
                sh '''
                    kubectl set image deployment/myapp 
                    myapp=registry.example.com/myapp:${BUILD_NUMBER} 
                    -n staging
                '''
            }
        }
    }
    post {
        failure {
            slackSend channel: '#alerts', 
                      message: "Build ${BUILD_NUMBER} başarısız oldu!"
        }
    }
}

Bu pipeline’ı kim yazar? Bir DevOps mühendisi. Ama bu pipeline’ın içindeki mvn test satırı yazılımcının yazdığı testleri çalıştırır. Yani ikisi birlikte çalışmak zorunda.

Infrastructure as Code

Terraform ile altyapı kurmanın güzelliği şu: Bir yazılımcı “staging ortamı lazım” dediğinde, ops ekibinin ticket açmasına gerek yok. Kod var, ortam var.

# Basit bir AWS EC2 instance Terraform kodu
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server-prod"
    Environment = "production"
    ManagedBy   = "terraform"
  }
  
  user_data = file("scripts/setup.sh")
}

resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Web sunucu guvenlik grubu"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Bu kodu yazmak için hem cloud provider’ı bilmek lazım (ops tarafı) hem de versiyon kontrol, modülerlik gibi yazılım geliştirme pratiklerini bilmek lazım (dev tarafı). İşte DevOps tam olarak burada.

Monitoring ve Observability

Bir sistem yöneticisi için monitoring, sunucunun ayakta olup olmadığını kontrol etmekti. DevOps dünyasında bu çok daha karmaşık bir hal aldı.

# Prometheus ile basit bir uygulama health check script
#!/bin/bash

APP_URL="http://localhost:8080"
HEALTH_ENDPOINT="/actuator/health"
METRICS_ENDPOINT="/actuator/prometheus"

# Health check yap
HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" 
    "${APP_URL}${HEALTH_ENDPOINT}")

if [ "$HTTP_STATUS" -ne 200 ]; then
    echo "CRITICAL: Uygulama sagliksiz! HTTP Status: $HTTP_STATUS"
    # Alertmanager'a bildirim gonder
    curl -X POST http://alertmanager:9093/api/v1/alerts 
        -H "Content-Type: application/json" 
        -d '[{
            "labels": {
                "alertname": "AppHealthCheckFailed",
                "severity": "critical",
                "instance": "web-server-01"
            },
            "annotations": {
                "summary": "Uygulama health check basarisiz"
            }
        }]'
    exit 2
fi

echo "OK: Uygulama saglikli, HTTP Status: $HTTP_STATUS"
exit 0

Container Yönetimi

Docker ve Kubernetes, DevOps’un sembolü haline geldi. Bir yazılımcı “bende çalışıyor” diyordu, ops ise “sunucuda çalışmıyor” diyordu. Container’lar bu tartışmayı büyük ölçüde bitirdi.

# Kubernetes deployment yaml - Basit bir uygulama
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-application
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-application
  template:
    metadata:
      labels:
        app: web-application
    spec:
      containers:
      - name: web-app
        image: registry.example.com/web-app:v1.2.3
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: db-password

DevOps Mühendisinin Gerçek Günü

Sabah 9’da işe başladığınızda ne yapıyorsunuz? Bir DevOps mühendisi olarak gerçek bir gün genellikle şöyle geçer:

İlk iş Grafana dashboard’una bakmak. Geceden kalma bir alarm var mı? Deployment pipeline’larından hangisi başarısız olmuş? Bunları kontrol etmeden güne başlamak olmaz.

Sonra Slack veya Teams’i açıyorsunuz. Bir yazılımcı “production’da bir şeyler yavaş, log’lara bakabilir misin?” diye yazmış. Log analizi başlıyor.

# ELK Stack'te log sorgulama veya dogrudan sunucuda hizli analiz
# Son 1 saatin error loglarini filtrele ve en cok tekrar edeni bul
kubectl logs -n production deployment/web-application 
    --since=1h | 
    grep "ERROR" | 
    awk '{print $NF}' | 
    sort | 
    uniq -c | 
    sort -rn | 
    head -20

# Ayni anda memory kullanimi kontrol et
kubectl top pods -n production --sort-by=memory | head -10

Öğleden sonra bir yazılımcı yeni bir servis için ortam istiyor. Terraform modülünüzü kullanarak 20 dakikada staging ortamını ayağa kaldırıyorsunuz.

Akşama doğru bir güvenlik açığı bildirimi geliyor. Kullandığınız bir base image’da kritik CVE var. Hızlıca tüm servislerin bu image’ı kullanıp kullanmadığını kontrol etmek gerekiyor.

# Tum deployment'larda belirli bir image kullanilanları bul
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{"t"}{.metadata.name}{"t"}{range .spec.containers[*]}{.image}{"n"}{end}{end}' | 
    grep "ubuntu:20.04"

# Etkilenen image'lari hizlica guncelle
for deployment in $(kubectl get deployments -n production -o name); do
    kubectl rollout restart $deployment -n production
done

Bu gün boyunca hem yazılımcıya danıştınız hem de sistem güvenliğiyle ilgilendiniz, hem kod yazdınız hem de infrastructure yönettiniz. İşte bu DevOps.

Kim Olmalısınız

Şimdi gelelim asıl soruya. DevOps mühendisi olmak için hangi taraftan gelmeniz gerekiyor?

Cevap şu: Her iki taraf da olabilir, ama belirli temel bilgilere sahip olmanız şart.

Sistem yöneticisi geçmişinden geliyorsanız şunları öğrenmeniz gerekecek:

En az bir scripting dili (Python kesinlikle şart, bash zaten biliyorsunuzdur)
Git ve versiyon kontrol kültürü
REST API’lar nasıl çalışır
Yazılım geliştirme metodolojileri (Agile, Scrum)

Yazılımcı geçmişinden geliyorsanız şunları öğrenmeniz gerekecek:

Linux sistem yönetimi temelleri
Ağ protokolleri (TCP/IP, DNS, HTTP/HTTPS)
Güvenlik temelleri
Storage ve database operasyonları

Ama şunu da söyleyeyim: Her şeyi bilmek zorunda değilsiniz. Önemli olan, bilmediğiniz bir konuyla karşılaştığınızda “bu benim alanım değil” demek yerine öğrenmeye hazır olmaktır.

Pratik Bir Başlangıç Rehberi

Eğer DevOps’a geçiş yapmak istiyorsanız ve nereden başlayacağınızı bilmiyorsanız, şu sırayla ilerleyin:

# 1. Adim: Git'i gunluk hayatinizin bir parcasi haline getirin
git init
git add .
git commit -m "feat: ilk deployment pipeline eklendi"
git push origin main

# 2. Adim: Basit bir CI pipeline kurun - GitHub Actions ornegi
# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Testleri calistir
      run: |
        echo "Testler calistirilıyor..."
        # Uygulamanizin test komutunu buraya ekleyin
    - name: Lint kontrolu
      run: |
        pip install flake8
        flake8 . --count --select=E9,F63,F7,F82 --show-source

Önce küçük adımlar atın. Tek bir servisi dockerize edin.
Sonra pipeline kurun. O servis için basit bir CI pipeline yazın.
Monitoring ekleyin. Uygulama çalışıyor mu, nasıl çalışıyor?
Infrastructure as Code’a geçin. Sunucuları elle kurmayı bırakın.

Türkiye’deki Gerçeklik

Türkiye’de iş ilanlarına bakınca ilginç bir tablo görüyorsunuz. “DevOps Mühendisi” ilanlarının yarısında aslında “hem yazılım yaz hem de sunucu yönet” isteniyor, üstelik maaş da bunların ikisinin ortalamasında kalıyor.

Bu bir gerçeklik ve bu gerçeklikle yüzleşmek lazım. Küçük ve orta ölçekli şirketlerde DevOps rolü çoğunlukla “her şeyi yapan adam/kadın” anlamına geliyor. Büyük şirketlerde ise daha net bir iş tanımı oluyor.

Hangi ortamda çalışırsanız çalışın, değer üretmenin yolu şu: Otomasyon. Her tekrarlayan görevi otomatize edin.

Bir şirkete gittiğimde ilk gün şunu yapıyorum: Kim hangi görevi manuel yapıyor? Onu not ediyorum. Sonra bu görevleri tek tek otomatize ediyorum. Hem operasyonel yükü azaltıyorum hem de değerimi ispatlıyorum.

#!/bin/bash
# Ornek: Gunluk database backup script - Manuel yapilan bir islemi otomatize etmek

DB_HOST="localhost"
DB_USER="backup_user"
DB_NAME="production_db"
BACKUP_DIR="/backup/postgresql"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=30

# Backup dizini yoksa olustur
mkdir -p "$BACKUP_DIR"

# Backup al
echo "[$DATE] Backup basliyor: $DB_NAME"
PGPASSWORD="$DB_PASSWORD" pg_dump 
    -h "$DB_HOST" 
    -U "$DB_USER" 
    -Fc 
    "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump"

# Backup basarili mi kontrol et
if [ $? -eq 0 ]; then
    echo "[$DATE] Backup basarili: ${DB_NAME}_${DATE}.dump"
    # S3'e yukle
    aws s3 cp "$BACKUP_DIR/${DB_NAME}_${DATE}.dump" 
        "s3://company-backups/postgresql/${DATE}/"
    echo "[$DATE] S3'e yukleme tamamlandi"
else
    echo "[$DATE] HATA: Backup basarisiz!"
    exit 1
fi

# Eski backupları temizle
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete
echo "[$DATE] $RETENTION_DAYS gunden eski backuplar temizlendi"

Kariyer Perspektifi

DevOps mühendisliği, doğru yapılırsa kariyer açısından çok güçlü bir konum. Neden?

Çünkü hem yazılımcının hem de operasyon ekibinin dilini konuşuyorsunuz. Her toplantıda anlıyorsunuz ne konuşulduğunu. CTO ile de konuşabiliyorsunuz, backend yazılımcısıyla da.

Ama şunu da söylemeliyim: Eğer sadece araçları bilen ama sorunları çözemeyen biri olursanız, değeriniz hızla düşer. Kubernetes bilmek tek başına yetmiyor. Bir production outage’ında soğukkanlılıkla root cause analizi yapabilmek, ekibe net iletişim kurabilmek, ve sorunu kalıcı olarak çözmek asıl değer.

Platform mühendisliği, SRE (Site Reliability Engineering) gibi roller de DevOps’un alt dalları olarak ortaya çıktı. SRE daha çok güvenilirlik ve ölçeklenebilirliğe odaklanırken, Platform Engineering iç geliştirici araçları ve self-service altyapı üzerine kurulu.

Türkiye’de bu rollerin net ayrımı henüz oturmuş değil. Çoğu şirkette hepsi “DevOps” başlığı altında toplanıyor. Ama dünya genelinde bu ayrışma giderek netleşiyor. Kariyerinizde nereye gitmek istediğinizi düşünürken bu yönleri göz önünde bulundurun.

Sonuç

“Sen kimsin?” sorusuna geri dönelim. DevOps mühendisi, ne salt bir yazılımcıdır ne de klasik anlamda bir sistem yöneticisidir. İkisinin kesişim noktasında duran, bu kesişimi bilinçli olarak seçmiş ve bu seçimin sorumluluğunu alan biridir.

Bu rol yorucudur. Çünkü her iki tarafın da beklentisini karşılamak zorundasınızdır. Yazılımcı hızlı isteyecek, güvenilirlik kararlılık isteyecek. Bu gerilimi yönetmek, teknik bilgiden çok daha önemli bir beceridir.

Ama aynı zamanda bu rol son derece tatmin edicidir. Bir pipeline kurduğunuzda ve iki haftada bir yapılan manual deployment’ın yerini günde onlarca otomatik deployment aldığında, o sistemi kullanan yazılımcıların “artık çok rahat” demesini duyduğunuzda, gerçekten değer ürettiğinizi hissediyorsunuz.

Sonuçta DevOps bir unvan değil, bir bakış açısıdır. Ve bu bakış açısını kazandığınızda, ne taraftan geldiğinizin artık pek önemi kalmıyor.

Yazılımcı mı Sistem Yöneticisi mi: DevOps Rolünü Anlamak