DevOps ve Bulut Mühendisi CV'si: Metrikler, Araçlar, Sertifikalar ve Örnek

Güçlü bir DevOps veya bulut mühendisi CV'si her aracı bir sonuca bağlar: neyi otomatikleştirdiğinizi veya kurduğunuzu, hangi ölçekte çalıştığınızı ve teslimat, güvenilirlik, güvenlik ya da maliyetin nasıl değiştiğini gösterir. Gerçekten kullandığınız servisleri ve sorumluluğunuzu yazın; AWS, Docker ve Kubernetes listesiyle yetinmeyin. Dağıtım sıklığı ve kurtarma süresi gibi savunabileceğiniz metrikleri kullanın. Bu rehber DevOps, bulut, SRE ve platform mühendisleri içindir. Önce ve sonra örnekleri, tam bir CV ve yazılım geliştirme ya da sistem yönetiminden geçenler için öneriler içerir.

İlk neye bakılır?

İşe alımcılar bulut platformunu, ortamın büyüklüğünü, sorumluluğunuzu ve bir iyileştirme kanıtını arar. İlanı dikkatle okuyun: platform, SRE ve bulut geçişi rolleri farklı vurgular ister. CV'yi işe uyarlama rehberi bunu hiçbir şey uydurmadan nasıl yapacağınızı gösterir.

• Başlık: ad, unvan, şehir, e-posta, LinkedIn ve ilgili işleri gösteriyorsa GitHub.
• Özet: deneyim yılı, bulut platformu, sistem türü ve en güçlü alanınız.
• Beceriler: alana göre gruplu, yalnızca derinlemesine anlatabileceğiniz araçlar.
• Deneyim: ölçek, yaptıklarınız, araçlar ve ölçülen sonuçlar.
• Sertifikalar, seçili projeler ve eğitim.

Araç listesi değil, sonuç yazın

Şu kalıbı kullanın: eylem, teknoloji, ölçek ve sonuç. Tasarladığınızı, yönettiğinizi, sürdürdüğünüzü veya yalnızca katkı verdiğinizi belirtin. Rakamlar örnektir; kendi verilerinizi yazın. Daha fazlası için CV'de başarılar rehberine bakın.

Önce: Jenkins ile CI/CD'den sorumluydum.

Sonra: 40 servisin CI/CD sürecini GitHub Actions ve Argo CD ile yeniden kurdum; sürümler haftalıktan günde birkaç kereye çıktı, başarısız değişiklikler %18'den %7'ye indi.

Önce: Kubernetes kümelerini yönettim.

Sonra: Günde 2 milyon isteğe hizmet veren 6 Amazon EKS kümesini işlettim; müşteri kesintisi olmadan yükseltmeleri yönettim ve otomatik ölçeklendirmeyle işlem maliyetini %24 azalttım.

Önce: İzleme ve nöbet işlerinde çalıştım.

Sonra: Ödeme servisleri için SLO ile Prometheus ve Grafana uyarıları kurdum, gereksiz uyarıları kaldırdım; ortalama kurtarma süresini 55 dakikadan 20 dakikaya indirdim.

Önce: Terraform kullandım.

Sonra: 3 AWS hesabını politika denetimli, yeniden kullanılabilir Terraform modüllerine taşıdım; ortam kurulumu 3 günden 2 saate indi.

Hangi metrikler yazılmalı?

DORA metrikleri yaygın olarak bilinir: dağıtım sıklığı, değişiklik teslim süresi, değişiklik hata oranı ve hizmeti geri getirme süresi. Erişilebilirlik, olay sayısı, bulut maliyeti, derleme ve hazırlık süresi de yardımcı olabilir. Dönemi ve bağlamı verin, yalnızca açıklayabileceğiniz rakamları yazın. Neyin ölçüldüğünü bilmiyorsanız “%99,99 çalışma süresi” pek bir şey anlatmaz. Kesin rakamınız yoksa ölçeği ve doğrulanmış bir değişikliği anlatın.

Becerileri net biçimde gruplayın

Gruplu liste kolay taranır ve ATS yazılımları için de yararlıdır. Bir kez kullandığınız araçları çıkarın. Beceriler rehberi seçim yapmanıza yardımcı olur.

• Bulut: AWS (EKS, Lambda, IAM, VPC), Azure veya Google Cloud.
• Kod olarak altyapı: Terraform, Ansible, CloudFormation, Pulumi.
• Konteynerler: Docker, Kubernetes, Helm.
• CI/CD: GitHub Actions, GitLab CI, Jenkins, Argo CD.
• Gözlemlenebilirlik: Prometheus, Grafana, ELK, Datadog.
• Betik ve sistemler: Linux, Bash, Python, Go, ağlar.
• Güvenlik: gizli bilgi yönetimi, imaj taraması, en az yetki. Siber güvenlik CV'si rehberine bakın.

Sertifikalar ve projeler

Sertifikalar deneyimi destekler, ama onun yerini almaz. Uygun örnekler AWS Certified DevOps Engineer – Professional, Microsoft Certified: DevOps Engineer Expert, Google Professional Cloud DevOps Engineer, Certified Kubernetes Administrator ve HashiCorp Terraform Associate'tır. Yılı yazın ve geçerliliğini kontrol edin. Sertifikalar rehberi biçimi anlatır. Kişisel projeler gerçekten çalışıyorsa işe yarar: depo bağlantısını verin, mimariyi açıklayın ve sonucu yazın. Projeler bölümü rehberine de bakın.

Geçmişinize göre uyarlayın

• Yeni başlayan: ev laboratuvarı, yayına alınmış proje, Linux ve betikler; dürüstçe belirtin. Deneyimsiz CV rehberine bakın.
• Yazılımdan gelen: sürüm otomasyonu, testler ve üretim sorumluluğu. Yazılım mühendisi CV'si yardımcı olur.
• Sistem yönetiminden gelen: Linux, ağlar, yedekleme, olaylar ve yeni otomasyon. Kariyer değiştirme rehberine bakın.
• Kıdemli: mimari kararlar, geçiş liderliği, maliyet ve mentorluk.
• SRE: SLO, hata bütçeleri, olay değerlendirmeleri ve güvenilirlik çalışmaları.

Teknik görüşmeye hazırlanın

CV'nizdeki her araç ve rakam görüşmede sorulabilir. Yaşadığınız bir olayı nasıl tespit ettiğinizi, nasıl çözdüğünüzü ve tekrarını nasıl önlediğinizi anlatmaya hazır olun. Kubernetes yazdıysanız ağ, kaynak sınırları ve hata ayıklama sorularına; Terraform yazdıysanız state yönetimine hazırlıklı olun. Şirket bilgilerini paylaşmadan mimariyi basit bir çizimle açıklayabilmelisiniz.

Kısa ve tam bir örnek

Kişi ve rakamlar kurgusaldır, ancak format kullanılabilir.

Deniz Kaya | Kıdemli DevOps Mühendisi | İstanbul | [email protected] | LinkedIn | GitHub

Özet: E-ticaret ve SaaS alanında 7 yıllık deneyime sahip, AWS, Kubernetes ve teslimat otomasyonunda uzman DevOps mühendisi.

Deneyim: Kıdemli DevOps Mühendisi, ShopGrid, 2021 – devam. 40 servisin teslimatını yeniden kurdum, sürümler haftalıktan günlüğe çıktı. 6 EKS kümesini işlettim, işlem maliyetini %24 azalttım.

Bulut Mühendisi, DataLoop, 2018 – 2021. 25 uygulamayı Terraform ile AWS'ye taşıdım. Yeni uyarılar ve runbook'larla kurtarma süresini 55 dakikadan 20 dakikaya indirdim.

Beceriler: AWS, Terraform, Kubernetes, Helm, GitHub Actions, Prometheus, Python. Sertifikalar: CKA, AWS DevOps Engineer – Professional. Eğitim: Bilgisayar Mühendisliği, 2017.

Sık yapılan hatalar

• Ölçek ve sonuç içermeyen uzun araç listeleri.
• Tüm ekibin geçiş çalışmasını kendinize mal etmek.
• Yalnızca bir eğitim tamamlayıp Kubernetes yazmak.
• Süresi dolmuş sertifikaları geçerli gibi göstermek.
• Depoda gizli bilgi, iç sunucu adı veya müşteri verisi bırakmak.
• Görüşmede açıklayamayacağınız metrikler.

Sonuç

En güçlü iyileştirmelerinizi seçin, gerçek sistemlere bağlayın ve işe uyarlayın. Ardından dosyayı ATS denetleyicimizle kontrol edin.