Kazanimlar:
- Yapay zeka ile dağınık notlardan runbook, post-mortem ve mimari doküman iskeleti üretebilme
- 'Uydurma yasağı' koyma ve her runbook'u gerçek ortamda baştan sona test edip damgalama disiplinini uygulayabilme
- Yanlış bir runbook'un hiç olmamasından daha tehlikeli olduğunu kavrayıp dokümantasyonu değişiklik süreciyle canlı tutabilme
Dokümantasyon ve Bilgi Yönetimi: YZ ile Runbook, Mimari ve Kurumsal Hafıza
Sistem yönetiminin en çok ihmal edilen ama en çok hayat kurtaran işi dokümantasyondur. Bir sistem çöktüğünde, onu kuran kişi tatildeyse ve nasıl toparlanacağı hiçbir yerde yazılı değilse, o gece herkes için uzun olur. Dokümantasyon, bir sistemin nasıl kurulduğunu, nasıl çalıştığını ve bir sorun çıkınca ne yapılacağını yazılı ve bulunabilir kılan kurumsal hafızadır. Bu hafızanın en kritik türü runbook'tur: belirli bir durumda (servis çöktü, disk doldu, yedek başarısız) adım adım ne yapılacağını anlatan operasyonel kılavuz. İşte YZ, dokümantasyon yazmanın en büyük düşmanı olan "boş sayfa" ve "üşenme" sorununu çözer: dağınık notlarınızdan düzenli bir runbook, bir komut geçmişinden bir prosedür, bir mimariden bir açıklama üretir. Ama kritik ilke: YZ taslak ve iskelet üretir; her adımı gerçekte doğru mu diye test eden ve onaylayan sizsiniz — yanlış bir runbook, hiç runbook olmamasından daha tehlikelidir.
Bu ünitede runbook, post-mortem (olay sonrası inceleme raporu), mimari dokümantasyon ve bilgi tabanı yazımını; YZ ile taslak üretmeyi; ve en önemlisi doğrulanmamış dokümantasyonun risklerini öğreneceksiniz.
Neden yanlış runbook, runbook'suzluktan kötüdür?
Bu ünitenin en önemli kavramı budur. Runbook'suz bir ekip, panik anında dikkatli ve şüpheci davranır; her komutu iki kez düşünür. Ama elinde "resmi" bir runbook olan biri, ona körü körüne güvenir — gece yarısı, stres altında, adımları sorgulamadan uygular. Eğer o runbook YZ tarafından üretilip test edilmeden yayınlandıysa ve bir adımı yanlışsa (yanlış bir komut, eksik bir önkoşul, atlanmış bir yedek adımı), sonuç felakettir. Bu yüzden YZ ile üretilen her runbook, yayınlanmadan önce gerçek bir ortamda baştan sona koşulmalı ve her adım doğrulanmalıdır. Test edilmemiş runbook, güven veren ama içi boş bir söz gibidir.
Dikkat: Bir runbook'a "test edildi: [tarih], [kişi]" damgası koyun. Test edilmemiş taslakları "TASLAK — DOĞRULANMADI" etiketiyle açıkça işaretleyin. Böylece kimse doğrulanmamış adımları gerçek bir krizde güvenle uygulamaz.
İyi bir runbook'un anatomisi
İyi bir runbook belirli parçalardan oluşur ve YZ bu iskeleti kurmakta ustadır: başlık ve amaç (hangi durum için), önkoşullar (hangi erişim, hangi araç gerekli), belirtiler (bu runbook'u ne zaman kullanırım), adımlar (numaralı, kopyalanabilir komutlarla), doğrulama (her adımdan sonra başarı nasıl anlaşılır), geri dönüş (bir adım kötü giderse nasıl geri alınır) ve eskalasyon (çözemezsem kimi ararım). YZ'ye dağınık notlarınızı verip bu yapıya oturtmasını isteyebilirsiniz; siz sadece içeriğin doğruluğunu sağlarsınız.
Adım adım: YZ ile dokümantasyon üretimi
- Ham malzemeyi topla. Komut geçmişiniz, notlarınız, eski bir e-posta, bir sohbet kaydı — dağınık da olsa gerçek malzeme, YZ'nin uydurmasından iyidir.
- Yapıyı iste. "Bunu şu başlıklarla bir runbook haline getir: amaç, önkoşul, belirti, adımlar, doğrulama, geri dönüş, eskalasyon."
- Uydurmayı yasakla. "Sana vermediğim hiçbir komut, IP, sürüm veya adım ekleme; eksik gördüğün yeri [DOLDURULACAK] olarak işaretle." Bu, en tehlikeli hatayı — makul görünen uydurma adımları — engeller.
- Maskele. Gerçek host, IP, kullanıcı yerine yer tutucu kullanın; belge paylaşılırsa sır sızmasın.
- Test et. Runbook'u gerçek (tercihen test) bir ortamda baştan sona koşun. Çalışmayan, eksik veya belirsiz her adımı düzeltin.
- Damgala ve yayınla. Test tarihini, test edeni ve son güncellemeyi ekleyin. Dokümantasyon canlıdır; sistem değişince güncellenmelidir.
Üç mini vaka
Vaka 1 — 2 saatlik iş, 15 dakika. Bir yönetici, bir yedekleme geri yükleme prosedürünü belgelemeyi aylardır erteliyordu. Terminal komut geçmişini (maskeleyerek) ve birkaç dağınık notunu YZ'ye verip runbook iskeletine oturttu. YZ 15 dakikada düzenli bir taslak üretti. Yönetici sonraki 45 dakikayı taslağı bir test sunucusunda baştan sona koşup iki eksik adımı düzeltmeye ayırdı. Sonuç: test edilmiş, güvenilir bir runbook.
Vaka 2 — Uydurma adım yakalandı. Bir ekip, YZ'ye bir servis yeniden başlatma runbook'u yazdırdı ama "uydurma" yasağını koymayı unuttu. YZ, mantıklı görünen ama o serviste var olmayan bir "önce cache temizle" komutu ekledi. Neyse ki mühendis runbook'u test ortamında koştu; o komut hata verdi. Test adımı, gerçek bir krizde kafa karışıklığı yaratacak uydurma bir adımı yakaladı.
Vaka 3 — Post-mortem hızlandı. Büyük bir kesinti sonrası ekibin bir post-mortem yazması gerekiyordu ama kimse başlayamıyordu. Olay zaman çizelgesini ve maskelenmiş logları YZ'ye verip suçlamasız (blameless) bir post-mortem iskeleti — özet, etki, zaman çizelgesi, kök neden, düzeltici aksiyonlar — istediler. YZ taslağı bir saatlik işi on dakikaya indirdi; ekip enerjisini olguları doğrulamaya ve aksiyon maddelerini netleştirmeye ayırdı.
Dört kopyalanabilir şablon
1) Runbook iskeleti üretme:
Rolün: kıdemli SRE. Aşağıdaki maskeli notlardan/komutgeçmişinden bir runbook oluştur. Başlıklar: Amaç, Önkoşullar,Belirtiler (ne zaman kullanılır), Adımlar (numaralı,kopyalanabilir), Her adımda Doğrulama, Geri Dönüş, Eskalasyon.KURAL: Sana vermediğim hiçbir komut/IP/sürüm/adım UYDURMA;eksik yerleri [DOLDURULACAK] yaz. Malzeme: [maskeli not]
2) Suçlamasız post-mortem:
Rolün: olay inceleme kolaylaştırıcısı. Aşağıdaki maskelizaman çizelgesi ve loglardan SUÇLAMASIZ bir post-mortemtaslağı yaz: Özet, Etki (süre/kapsam), Zaman Çizelgesi,Kök Neden (doğrulanmışsa), Katkıda Bulunan Faktörler,Düzeltici Aksiyonlar (sahip + öncelik). Kişi suçlama,sisteme odaklan. Kanıtsız kök neden yazma. Veri: [...]
3) Mimari/servis açıklaması:
Aşağıdaki maskeli yapılandırma/diyagram bilgisinden birservis dokümanı yaz: servis ne işe yarar, hangi bileşenlerdenoluşur, bağımlılıkları neler, veri nasıl akar, hangi portlar/protokoller. Teknik ama okunabilir olsun. Emin olmadığınilişkiyi "doğrulanmalı" diye işaretle. Bilgi: [maskeli]
4) Dokümantasyon tazeleme denetimi:
Aşağıdaki mevcut dokümanı incele ve güncelliğini denetle:(1) hangi bölümler eksik/muğlak, (2) hangi adımlar testedilmemiş görünüyor, (3) hangi bilgiler eskimiş olabilir?Her bulgu için ne sormam/doğrulamam gerektiğini yaz.Doküman: [maskeli doküman]
Zayıf prompt / Güçlü prompt
Zayıf prompt:
Bana bir sunucu bakım runbook'u yaz.
Hiçbir gerçek malzeme yok. YZ tamamen kendi genel bilgisinden, sizin ortamınıza uymayan, hatta uydurma adımlar içeren bir metin üretir. Bu, tehlikeli bir yanlış güven kaynağıdır.
Güçlü prompt:
Rolün: kıdemli SRE. Aşağıda "ödeme servisi disk doldu"olayında uyguladığım maskeli komut geçmişi ve notlarım var.Bunlardan bir runbook oluştur: Amaç, Önkoşul (erişim/araç),Belirti, Numaralı Adımlar (benim komutlarımla), her adımdaDoğrulama, Geri Dönüş, Eskalasyon. Bana vermediğim komutuydurma; boşluğu [DOLDURULACAK] yap. Sonuna "test edilmedi"uyarısı koy. Malzeme: [maskeli komut geçmişi]
Doküman türü
YZ'nin katkısı
İnsanın zorunlu katkısı
Runbook
İskelet + düzen
Gerçek ortamda test, doğruluk
Post-mortem
Taslak + yapı
Olguları ve kök nedeni doğrulama
Mimari doküman
Açıklama + akış
İlişkileri ve bağımlılıkları teyit
Bilgi tabanı maddesi
Hızlı taslak
Güncellik ve doğruluk kontrolü
Sık yapılan hatalar
- Test edilmemiş runbook yayınlamak. Doğrulanmamış adımlar krizde körü körüne uygulanır; yanlış runbook felakettir.
- Uydurma yasağını koymamak. YZ'ye "vermediğimi ekleme" demezseniz, makul ama gerçek dışı adımlar üretir.
- Maskelemeyi atlamak. Gerçek host, IP ve kullanıcı içeren doküman paylaşılınca sır sızar.
- Dokümanı güncellememek. Sistem değişince güncellenmeyen doküman, zamanla yanıltıcı hale gelir.
- Damgasız yayınlamak. Test tarihi ve durumu olmayan doküman, güvenilir mi taslak mı belli değildir.
İpucu: Dokümantasyonu "canlı" tutmanın en iyi yolu, onu değişiklik sürecine bağlamaktır: bir sistem değiştiğinde ilgili runbook'u güncellemek, değişikliğin tamamlanma kriterlerinden biri olsun. YZ güncellemeyi hızlandırır ama tetikleyen süreç sizsiniz.
Özetle
Dokümantasyon kurumsal hafızadır; runbook ise kriz anında hayat kurtaran operasyonel kılavuzdur. YZ, boş sayfa ve üşenme sorununu çözerek dağınık notlarınızdan düzenli taslaklar üretir. Ama en kritik gerçek şudur: yanlış bir runbook, hiç olmamasından tehlikelidir çünkü krizde körü körüne uygulanır. Bu yüzden YZ'ye "uydurma" yasağı koyun, maskeleyin, ve her runbook'u gerçek bir ortamda baştan sona test edip damgalayın. Dokümanı sistem değiştikçe canlı tutun. YZ iskeleti kurar; doğruluğu ve testi garanti eden sizsiniz.
Uygulama görevi
Ekibinizde belgelenmemiş bir prosedür seçin (örneğin bir servisin yeniden başlatılması veya bir yedeğin geri yüklenmesi). İlgili komut geçmişinizi ve notlarınızı maskeleyip yukarıdaki "Runbook iskeleti üretme" şablonuyla YZ'ye bir taslak yaptırın; uydurma yasağını mutlaka koyun. Taslağı bir test ortamında baştan sona koşun ve çalışmayan/eksik her adımı işaretleyip düzeltin. Runbook'a test tarihi ve test eden bilgisini ekleyin. Süreçte YZ'nin ürettiği ve sizin düzelttiğiniz farkları 5 maddede yazın.
Kontrol listesi
- [ ] Runbook'u gerçek malzemeden (not, komut geçmişi) ürettim, sıfırdan uydurtmadım mı?
- [ ] YZ'ye "vermediğim komut/IP/adım ekleme" yasağını koydum mu?
- [ ] Host, IP ve kullanıcı gibi hassas bilgileri maskeledim mi?
- [ ] Runbook'u gerçek/test bir ortamda baştan sona koşup doğruladım mı?
- [ ] Test tarihi, test eden ve son güncelleme bilgisini ekledim mi?
- [ ] Dokümanı sistem değişikliği sürecine bağlayıp güncel tutmayı planladım mı?