DevOps Mühendisi Mülakat Soruları ve Örnek Cevaplar

Örnek Cevap

Ben pipeline'ı hızlı ama güven veren geri bildirim üretecek şekilde kurarım. Önce lint, unit test ve güvenlik taraması çalışır; ardından build alınır ve tek bir immutable artefact üretilir. Aynı artefact geliştirme, test ve prod ortamlarına terfi ettirilir; yeniden build yapılmaz. Deployment tarafında rolling veya canary yaklaşımı uygular, health check başarısız olursa otomatik rollback eklerim. Böylece main'e merge edilen değişiklik kontrollü şekilde prod'a gider.

Örnek Cevap

Bir projede sık düşen API'nin temel nedeni aşırı yüklenen veritabanıydı. Önce read replica ekledim, connection pooling yapılandırdım ve saturation için erken uyarı metrikleri kurdum. Takımla birlikte SLO tanımlayıp kabul edilebilir hata payını netleştirdik. Sonuçta outage sayısı azaldı ve incident'lar daha erken yakalanır oldu.

Örnek Cevap

Ben altyapıyı uygulama kodu gibi ele alırım: version control altında tutulur, peer review'den geçer ve elle değil pipeline ile uygulanır. Declarative araçları tercih ederim; yani hedef durumu tarif eder, araçların bu duruma reconcile etmesine izin veririm. Böylece configuration drift azalır, ortamlar tekrarlanabilir olur ve disaster recovery daha öngörülebilir hale gelir. Ayrıca modüler yapı kurarak tekrar kullanımı artırırım.

Örnek Cevap

Secret'ları asla source control içine koymam. Bunun yerine bir secrets manager kullanır, erişimi least privilege ile sınırlarım. Secret'ları image içine gömmek yerine runtime'da environment variable veya sidecar üzerinden veririm. Düzenli rotation uygular, erişim loglarını da denetlerim. Farklı ortamlar için config'i koddan ayırır, aynı artefact'ın doğru konfigürasyonla her yerde çalışmasını sağlarım.

Örnek Cevap

İlk önceliğim servisi geri getirmektir; önce rollback, failover veya trafiği sağlıklı node'lara yönlendirme gibi mitigasyon adımlarını atarım. Incident kanalında net iletişim kurar, paydaşları düzenli bilgilendirir ve gerekiyorsa bir incident commander belirlerim. Sistem stabil hale gelince blame-free postmortem yapar, kök neden yerine sistemsel sebebi çıkarır ve aksiyonları sahipleriyle birlikte takibe alırım. Amacım tekil hatayı yamamak değil, aynı sınıf sorunların tekrarını önlemektir.

Sanal makine donanımı sanallaştırır ve kendi guest işletim sistemiyle çalışır; bu yüzden daha ağırdır ve açılışı daha uzundur. Container ise işletim sistemi katmanını paylaşır, sadece uygulamayı ve bağımlılıklarını paketler. Bu nedenle container daha hafif, hızlı ve yoğunluk açısından avantajlıdır. VM daha güçlü izolasyon sağlarken container taşınabilirlik ve hız sunar.

Kubernetes, container'ları cluster üzerinde planlayan ve yöneten bir orchestrator'dır. Service discovery, scaling, self-healing ve rollout gibi işleri otomatikleştirir. Siz desired state tanımlarsınız, Kubernetes sürekli olarak gerçek durumu bu hedefe eşitler. Çok sayıda container'ı elle yönetmek yerine güvenilir biçimde işletmek için kullanılır.

Blue-green'de iki tam ortam bulunur; trafik eski sürümden yeni sürüme bir kerede geçirilir ve gerekirse aynı hızda geri dönülür. Canary'de ise yeni sürüm önce küçük bir trafik yüzdesine açılır, gözlemlenir ve sonra kademeli artırılır. Canary blast radius'u küçültür ve gerçek trafikle hatayı erken yakalar. Blue-green daha basittir ama tüm kullanıcıları aynı anda etkiler.

Load balancer gelen istekleri birden fazla backend instance arasında dağıtır, böylece tek bir node aşırı yüklenmez. Health check yaparak arızalı instance'ları rotasyondan çıkarır. Bu yaklaşım yatay ölçeklemeyi kolaylaştırır ve zero-downtime deploy'lara yardımcı olur. Ayrıca instance draining ile kesintisiz geçişi destekler.

Monitoring, bilinen metrikleri izleyip eşik aşımında uyarı veren sistemdir; yani sistem sağlıklı mı sorusunu cevaplar. Observability ise logs, metrics ve traces ile sistemin iç durumunu yeni sorular sorarak anlamanızı sağlar. Monitoring, önceden bildiğiniz riskleri yakalar; observability ise öngörmediğiniz sorunları debug etmenize yardım eder. İyi bir operasyon kültüründe ikisi birlikte kullanılır.

Yoğun saatlerde yapılan bir config değişikliği ana API'yi düşürmüştü. Incident ilan edip değişikliği dakikalar içinde rollback ettim ve paydaşları düzenli bilgilendirdim. Postmortem'de pipeline'da config doğrulaması olmadığını gördük; bunun üzerine otomatik kontrol ve staged rollout ekledim. Aynı tip outage bir daha yaşanmadı.

Önceden deployment manuel checklist ile yaklaşık bir saat sürüyor ve hata riski taşıyordu. Tüm akışı test, onay ve rollback içeren tek bir pipeline'a taşıdım. Ayrıca durum bilgisini görünür kıldım ki ekip kendi deploy'unu güvenle yapabilsin. Deployment sıklığı arttı, deploy kaynaklı incident'lar azaldı.

Bir ekip günlük release istiyordu ama change failure rate yüksekti. Ben progressive delivery, canary ve otomatik rollback ile ilerlemeyi önerdim. SLO'ları baz alarak error budget yanıyorsa hızı frenledik, yanmıyorsa akışı sürdürdük. Böylece veriyle desteklenen bir denge kurduk; hız da arttı, stabilite de korundu.

Bir projede cloud faturası kullanım artışından hızlı büyüyordu. Önce kaynakları analiz edip over-provision edilmiş instance'ları right-size ettim, ardından autoscaling ekledim. Uygun iş yüklerini spot instance'lara taşıdım ve cost dashboard ile bütçe uyarıları kurdum. Aylık maliyeti yaklaşık üçte bir oranında düşürdük; performans etkilenmedi.