yoklateknik mülakat
GelişimGeçmiş

DevOps / Cloud Observability Monitoring Mülakat Soruları

75 doğrulanmış DevOps / Cloud Observability Monitoring mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Observability MonitoringZorluk 1
Monitoring ile observability arasındaki temel fark nedir?
  • aMonitoring her zaman yalnızca log toplar, observability ise her zaman yalnızca metrik toplar.
  • bMonitoring bilinen metrikleri bilinen eşiklere göre izler; observability üretilen veriden sistem durumunu çıkarır.✓
  • cObservability yalnızca bir şirket büyüdükten sonra önem kazanır; küçük sistemler yalnızca monitoring'e güvenebilir.
  • dMonitoring ve observability, yalnızca iki farklı şekilde pazarlanan tamamen aynı pratiği tanımlar.
Açıklama:Monitoring, önceden tanımlı sinyalleri (CPU, hata oranı) bilinen eşiklere göre izler. Observability daha geniştir: önceden bir dashboard kurulmamış olsa bile, mevcut metrics/logs/traces verisiyle yeni ve öngörülemeyen sorular sorabilme yeteneğidir. (a) yanlıştır çünkü her iki pratik de hem metrik hem log kullanır, tek biriyle sınırlı değildir.
Observability MonitoringZorluk 1
Observability'nin genellikle "üç temel sinyali" (three pillars) olarak kabul edilen bileşenleri hangileridir?
  • aMetrics, logs ve traces✓
  • bCPU, memory ve disk kullanımı
  • cAlertler, dashboard'lar ve raporlar
  • dUptime, throughput ve error budget
Açıklama:Metrics (sayısal zaman serisi), logs (ayrık olay kayıtları) ve traces (servisler arası istek düzeyinde yürütme yolu), sistemlerin davranışını yeniden kurmak için birleştirdiği üç temel veri türüdür. (b) yalnızca kaynak metriklerini listeler, bu metriklerin bir alt kümesidir; (c) ve (d) bu üç sinyal üzerine kurulan araçlar/türetilmiş kavramlardır, sinyallerin kendisi değildir.
Observability MonitoringZorluk 2
Bir counter metrik ile bir gauge metrik arasındaki pratik fark nedir?
  • aCounter yalnızca artan (ya da sıfırlanan) kümülatif bir değer tutar; gauge ise serbestçe artıp azalabilen bir değer tutar.✓
  • bCounter zamanla dalgalanan anlık bir değeri tutar, gauge ise zaman içinde yalnızca yukarı doğru birikir.
  • cCounter her zaman yalnızca string değerler için, gauge her zaman yalnızca sayısal ölçümler için kullanılır.
  • dCounter ve gauge herhangi bir sistemde birbirinin yerine geçebilir, aralarında hiçbir pratik fark yoktur.
Açıklama:Counter'lar toplam işlenen istek sayısı gibi yalnızca artan (ya da restart'ta sıfırlanan) kümülatif toplamları modeller. Gauge'lar ise anlık kuyruk uzunluğu veya memory kullanımı gibi dalgalanan değerleri modeller. Yanlış tip seçimi, sonraki rate/trend hesaplamalarını bozar. (b) tanımları ters çevirir; (c) ve (d) yanlıştır — ikisi de sayısal değer tutar ve aggregation'da çok farklı davranır.
Observability MonitoringZorluk 2
Bir servis şu log satırını üretiyor:
{"timestamp":"2020-01-01T10:00:00Z","level":"error","service":"payment-api","message":"db connection timeout","request_id":"abc123"}

Bu structured (JSON) log formatının düz metin log'a göre temel avantajı nedir?
  • aStructured log dosyaları her zaman herhangi bir düz metin log'dan belirgin şekilde daha az disk kaplar.
  • bStructured formata geçen uygulamalar bu sayede otomatik olarak daha hızlı çalışmaya başlar.
  • clevel veya request_id gibi alanlar doğrudan filtrelenebilir, çünkü format makine tarafından ayrıştırılabilir.✓
  • dStructured logging, error/info gibi log seviyelerinin kullanılmasına olan ihtiyacı tamamen ortadan kaldırır.
Açıklama:Her alan serbest metin yerine ayrı ve tipli bir anahtar olduğundan, log araçları kırılgan metin ayrıştırma (regex gibi) yapmadan service, level veya request_id üzerinden filtreleme/aggregation/korelasyon yapabilir. (a) ve (b), structured logging'in garanti etmediği boyut/performans iddialarıdır; (d) yanlıştır — örnekte level alanı hâlâ mevcuttur.
Observability MonitoringZorluk 1
Uygulamalar neden genellikle DEBUG, INFO, WARN, ERROR gibi log seviyeleri kullanır?
  • aYalnızca geliştiricilerin log yazarken kullandığı kodlama stilini standartlaştırmak için.
  • bLog seviyeleri kullanmak, uygulamanın her log satırını diske daha hızlı yazmasını sağladığı için.
  • cLog seviyeleri yalnızca geliştirme ortamlarında gereklidir, production'da anlamsızdır.
  • dLog'ların ciddiyete göre filtrelenip gürültünün azaltılmasını, operatörlerin önemli olana odaklanmasını sağlamak için.✓
Açıklama:Seviyeler, ortama göre ayrıntı düzeyinin ayarlanmasını sağlar: derin sorun giderme için DEBUG, production'da gerçekten dikkat gerektiren şeyler için ERROR/WARN. Bu, sinyal/gürültü oranını yönetilebilir tutar. (b) yanlış bir performans iddiasıdır; (c) yanlıştır, production genelde INFO/WARN seviyesinde çalışır ve seviyeler anlamlı kalır; (a) operasyonel amacı küçümser.
Observability MonitoringZorluk 2
Bir ekip, %70 üzerindeki her küçük CPU dalgalanmasında alert tetiklenecek şekilde ayar yapıyor. Birkaç hafta içinde günde onlarca alert almaya başlıyorlar ve okumadan kapatma alışkanlığı geliştiriyorlar. Bu duruma ne ad verilir ve kök neden nedir?
  • aCardinality patlaması; çok fazla benzersiz etiket kombinasyonu metrik altyapısını yavaşlatıyor.
  • bAlert fatigue; yüksek hacimli düşük-sinyal alertler, önemli olanların da gözden kaçmasına ya da yok sayılmasına yol açar.✓
  • cLog rotation hatası; disk sürekli dolduğu için aynı alert tekrar tekrar tetikleniyor.
  • dSLA ihlali; müşteriye resmi olarak taahhüt edilen çalışma süresi zaten aşılmış durumda.
Açıklama:Alertler gerçekten aksiyon gerektiren durumlar yerine gürültü üzerine çok sık tetiklendiğinde, operatörler duyarsızlaşıp gerçek incident'lar dahil bildirimleri yok saymaya başlar — buna alert fatigue denir. Çözüm genelde eşiği yükseltmek, bir süre penceresi eklemek veya ham dalgalanma yerine semptoma göre alert kurmaktır. (a), (c), (d) senaryoda ima edilmeyen alakasız hata türlerini anlatır.

Uzmanlığa göre

AWS 450Azure 450GCP 450Kubernetes 450Linux 450Terraform 450

Kıdeme göre

DevOps / Cloud JuniorDevOps / Cloud MidDevOps / Cloud Senior

Diğer alanlar

BackendFrontendFullstackAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

3375 soruluk DevOps / Cloud bankasında kendini sına.

Mülakata başla