DevOps Mühendisleri için Ekran Kaydı: Olaylar, Pipeline’lar ve Runbook’lar

DevOps işleri hızlı, dağıtık ve sürekli çağrılarla kesintiye uğrayan bir yapıya sahiptir. Sabahın 3’ünde bir kesintiyi teşhis eden kişi ile ertesi sabah bunu inceleyen ekip arasında bağlam kaybolur. Ekran kaydı bu boşluğu kapatır. Geçici terminal oturumlarını, dashboard incelemelerini ve pipeline hata ayıklamalarını, kimsenin olayı hafızasından yeniden kurmak zorunda kalmadan tüm ekibin öğrenebileceği kayıtlara dönüştürür.

DevOps Ekipleri Neden Sadece Loglara Değil, Videoya da İhtiyaç Duyar

Loglar ve metrikler size ne olduğunu söyler. Bir mühendisin sorunu nasıl araştırdığını -önce hangi dashboard’a baktığını, hangi komutun asıl sebebi ortaya çıkardığını ya da neden yanıltıcı bir ipucunu elediğini- nadiren yakalarlar. Bir sonraki nöbetçi mühendisin tam olarak ihtiyaç duyduğu şey bu akıl yürütme sürecidir.

Yaygın DevOps kullanım senaryoları:

• Olay araştırmaları: Canlı hata ayıklama sürecini, olay bittikten sonra yeniden kurgulamak yerine gerçekleştiği anda kaydedin
• CI/CD pipeline anlatımları: Bir build’in neden başarısız olduğunu ve düzeltmenin nasıl çalıştığını gösterin
• Altyapı-kod incelemeleri: Bir Terraform veya Pulumi planını merge edilmeden önce adım adım gösterin
• Nöbet devirleri: Bir sonraki mühendisi açık sorunlar hakkında uzun bir yazılı devir dokümanı yerine dakikalar içinde bilgilendirin
• Deployment demoları: Yeni bir rollout sürecini başka bir ekibe devretmeden önce kaydedin
• Postmortem kanıtı: Bir olay sırasındaki tam dashboard durumunu retro için saklayın

Olay Araştırmalarını Kaydetme

Kayıt yapmak için en iyi zaman, sorunu çözdükten sonra değil, hâlâ teşhis ederken kayda başlamaktır. Canlı bir araştırma kaydı, çıkmaz sokakları da dahil olmak üzere gerçek düşünce sürecinizi yakalar ve bu genellikle cilalanmış bir özetten çok daha öğreticidir.

Bir olay araştırmasını kaydetme yöntemi:

1. Kök nedeni bilmeseniz bile araştırmaya başlar başlamaz kaydı başlatın
2. Hipotezlerinizi sesli olarak dile getirin: “14:02’de gecikme sıçradı, 14:00’teki deploy ile ilişkili mi diye kontrol ediyorum”
3. Çalıştırdığınız her dashboard’u, log sorgusunu ve komutu yakalayın
4. Kök nedeni bulduğunuzda, ileride zaman damgasıyla kolayca bulunabilmesi için kamerada net bir şekilde belirtin
5. Düzeltme ve doğrulama sırasında kayda devam edin

Ardından kaydı postmortem için önemli anlara indirin, ancak tam, düzenlenmemiş sürümü de arşivleyin - benzer bir olay tekrarlandığında genellikle öne çıkan bölümlerden daha değerlidir.

CI/CD Pipeline Anlatımları

Bozuk pipeline’lar, bir DevOps mühendisi için en yaygın kesinti kaynaklarından biridir ve çözüldükten sonra belgelenmesi en kolay olanlardan biridir.

Bir pipeline hata ayıklama oturumunu kaydetme:

• Başarısız build loglarını eksiksiz yakalayın - gürültüyü kırpmayın, genellikle ipucu orada bulunur
• Son başarılı build ile başarısız olan arasındaki farkı gösterin
• Hangi aşamanın neden başarısız olduğunu anlatın (bağımlılık çözümlemesi, kararsız testler, zaman aşımı, izinler)
• Düzeltmeyi gösterin ve yeşil olduğunu doğrulamak için pipeline’ı kamerada yeniden çalıştırın

Bu kayıtları pipeline yapılandırmanızla birlikte saklayın, böylece benzer bir hatayla karşılaşan bir sonraki mühendis çözümü sıfırdan hata ayıklamak yerine saniyeler içinde bulabilir.

Altyapı-Kod Değişikliklerini İnceleme

Bir pull request yorumunda Terraform planını, Kubernetes manifestosunu veya CloudFormation şablonunu incelemek zordur - incelemeciler tüm kaynak grafiğini kafalarında tutmak zorundadır. Kısa bir video anlatımı, bir değişikliğin etki alanını anında ortaya koyar.

Etkili IaC inceleme kayıtları:

1. Herhangi bir şey anlatmadan önce plan veya diff çıktısını eksiksiz gösterin
2. Oluşturulan, değiştirilen veya yok edilen her kaynağı tek tek anlatın
3. Bir kaynak değişimini (replacement) tetikleyen her şeyi belirtin (genellikle en riskli değişiklik türüdür)
4. Bir modül sürümünün neden sabitlendiği gibi açık olmayan kararların arkasındaki mantığı açıklayın
5. Apply sonrasında gereken manuel adımları belirtin (secret rotasyonu, DNS yayılımı, cache ısıtma)

Bu, yanlış okunan bir diff’in orantısız sonuçlara yol açabileceği, production ağ yapılandırması veya IAM politikalarını etkileyen değişiklikler için özellikle değerlidir.

Toplantısız Nöbet Devirleri

Yazılı nöbet devir dokümanları hızla eskir ve canlı bir devir görüşmesi farklı zaman dilimlerinde ölçeklenmez. 5 dakikalık bir kayıt genellikle en ideal noktadır.

Bir devir kaydına dahil edilmesi gerekenler:

• Açık olaylar ve mevcut durumları
• Tetiklenen ancak yanlış pozitif çıkan uyarılar, böylece bir sonraki mühendis onları yeniden araştırmaz
• Göz önünde tutulması gereken dashboard’lar ve bunlarda “normal” görünümün nasıl olduğu
• Bir sonraki vardiya sırasında planlanan deploy veya değişiklikler
• Güvenle göz ardı edilebilecek bilinen kararsız kontroller veya gürültülü uyarılar

Bunu vardiyanızın sonunda kaydedin ve linki ekibinizin devir kanalına bırakın. Bir sonraki mühendis, kahve yapacak kadar kısa bir sürede izleyebilir.

Dashboard’ları ve Terminal Çıktısını Net Bir Şekilde Yakalama

Gözlemlenebilirlik araçları ve terminal çıktısının videoda kendine özgü okunabilirlik zorlukları vardır.

• Dashboard’lar: İzleyicilerin kalabalık bir düzende kendi kendilerine bulmasına güvenmek yerine, üzerinde konuştuğunuz belirli grafiği veya paneli vurgulamak için yakınlaştırma efektleri kullanın
• Terminaller: Yazı tipi boyutunu en az 16pt’ye çıkarın ve normal oynatma hızında komut çıktısının okunabilir kalması için yüksek kontrastlı bir tema kullanın
• Birden fazla ekran: Araştırmanız bir monitörde metrik dashboard’u, diğerinde terminal içeriyorsa, tüm masaüstünüzü yakalamak yerine pencere yakalama kullanın ve aralarında temiz bir şekilde geçiş yapın
• Uzun süren komutlar: Kayıt odaklı kalsın diye düzenleme sırasında ölü zamanları (bir kubectl rollout status, uzun bir terraform apply beklerken) hızlandırın veya kırpın

Paylaşmadan Önce Hassas Verileri Gizleme

Altyapı kayıtları genellikle hassas bilgiler içerir. Yakın ekibinizin dışında paylaşmadan önce:

• Kayıt dışarıyla paylaşılacaksa dahili ana bilgisayar adlarını, IP aralıklarını ve hesap kimliklerini bulanıklaştırın veya kırpın
• Kimlik bilgilerini, tokenleri veya bağlantı dizelerini asla görünür bırakmayın - gizli bilgileri yazmadan önce kaydı duraklatın
• Loglarda veya trace’lerde görünebilecek müşteri verileri için dashboard kayıtlarını gözden geçirin
• Kuruluşunuzun veri sınıflandırma politikasını, yazılı olay raporlarına uyguladığınız gibi kayıtlara da uygulayın

Postmortem ve Runbook Kütüphanesi Oluşturma

Tek bir olay kaydı bir kez işe yarar. Bunların aranabilir bir kütüphanesi ise tüm SRE veya platform ekibiniz için bir güç çarpanıdır.

Kayıtları şuna göre düzenleyin:

• Servis veya sistem (payments-api, ana veritabanı, ingress controller)
• Olay ciddiyeti, böylece yüksek ciddiyetteki araştırmalar kolayca öne çıkar
• Kök neden kategorisi (deploy kaynaklı, kapasite, bağımlılık hatası, yapılandırma sapması)

Her kaydı postmortem dokümanınızdan ve runbook indeksinizden bağlayın, böylece yeni bir olayı araştıran mühendisler benzer bir şeyin daha önce yaşanıp yaşanmadığını hızlıca kontrol edebilir.

Sonuç

DevOps bilgisi kolayca kaybolur ve yeniden inşa etmesi pahalıdır. Ekran kaydı, bir olay müdahalesinin, bir pipeline düzeltmesinin veya bir altyapı değişikliğinin arkasındaki akıl yürütmeyi -yakalamanın en ucuz ve bir sonraki ihtiyaç duyan kişi için en değerli olduğu anda- yakalar. Bir sonraki olayınızla başlayın: cevabı bilmeden önce kaydı başlatın, sonra değil.

İyi kayıtlar!