Checklist’in Ötesinde, Deneyimle Şekillenen Uzmanlık
Bu yazı; klimalı sistem odalarında dirsek çürütmüş, gece yarısı gelen bir “Update terminated” mesajıyla uykusu bölünmüş ve “Sistem yavaş” şikayetinin aslında ne kadar derin bir kuyu olduğunu bizzat tecrübe etmiş bir mutfaktan çıktı.
SAP Basis dünyasında mesleğe yeni adım atan meslektaşlarımıza genellikle standart bir “daily checklist” (günlük kontrol listesi) verilir. SM21’e bak, ST22’yi kontrol et, yedekleri gör, iş bitti. Evet, bu rutinleri uyguladığınızda sisteminiz muhtemelen “çalışıyor” demektir. Ancak ‘çalışan bir sistem’ ile en başından doğru kurgulanmış, çevik ve dayanıklı (resilient) bir mimari arasında; genellikle büyük bir sistem kesintisi esnasında fark edilen o görünmez uçurum vardır.
Dayanıklı bir sistem, sadece hata vermeyen değil; hatayı gelmeden önce kokusundan tanıyan bir uzman tarafından yönetilen sistemdir. Gelin, klişelerden uzak, sahanın tozuyla şekillenmiş bu uzmanlık katmanlarına birlikte bakalım.
1. “Sistem Logu Temiz” Yanılgısı: Sessiz Çığlıkları Duymak
Her sabah SM21’e girip kırmızı satır görmediği için huzurla kahvesini içen meslektaşlarımız olabilir. Ancak gerçek bir kıdemli, logun “ne yazdığına” değil, “ne yazmadığına” odaklanır.
Gerçek Bir Vaka:
Bir keresinde sistem logları pırıl pırıldı ama kullanıcılar rastgele “connection lost” hataları alıyordu. Klasik kontrollerin hiçbiri bir şey söylemiyordu. Derine indiğimizde, bir ağ anahtarının (switch) paket kaybı yaşadığını, SAP’nin bunu bir sistem hatası olarak değil, sadece bir ağ gecikmesi olarak algıladığını gördük.
Hayat Kurtaran İpucu:
Sadece hataları değil, istatistiksel sapmaları izleyin. Eğer her gün belli sayıda dump (ST22) alan bir sistemde o sabah hiçbir hareket yoksa, bu sistemin iyileştiği anlamına gelmez; bazen bir veritabanı bağlantı hatası, sistemin dump bile üretemeden “kör” kalmasına neden olabilir. Örneğin, TSV_TNEW_PAGE_ALLOC (bellek tahsis hatası) gibi kritik bir dump gördüğünüzde, bu sadece bir kod hatası değil, sistemin o an “nefes alamadığının” işaretidir.
Uzman Refleksi:
Log’lar “sessiz” olduğunda şunu sorarım:
– Bu sistem normalde günde kaç event üretirdi?
– Network latency, enqueue wait, dialog response time gibi metrikler birlikte mi değişiyor?
– SAP bunu hata olarak mı görüyor, yoksa “tolere edilebilir gecikme” olarak mı yutuyor?Bir sistemin hiç hata üretmiyor olması, sistemin kusursuz olduğunun değil; bazen izleme (monitoring) katmanının sistemin gerçek durumundan koptuğunun kanıtıdır. Loglardaki sessizliği, huzur değil bir “tetikte olma” işareti olarak okuyun.
2. Performansın Kara Kutusu: ST04 ve DB02
“Veritabanı alanı %90 olmuş, biraz daha disk ekleyelim.” Bu, sistemi çalıştıran mantıktır. Dayanıklı mantık ise şudur: “Bu alan neden doldu?”
Vaka: Şişen Tablolar ve Arşivleme Eksikliği:
HANA sistemlerinde bellek (memory) kıymetlidir, ancak asıl sorun genellikle disk alanı ve istatistiklerin bozulmasıyla başlar. Bir müşterimizde IDOC tablolarının (EDIDC, EDID4 gibi) veya RFC log tablolarının (ARFCSSTATE, ARFCRSTATE) yüz milyonlarca satıra ulaştığını gördük. Bu durum HANA’da doğrudan bir “bellek çöpü” yaratmasa da, veri hacmi (data volume) büyüdükçe veritabanı istatistikleri hantallaşır ve basit bir SELECT sorgusu, indekslerin hantallaşması veya ‘expensive SQL’ haline gelmesiyle sistemi yormaya başlar.
Risk ve Çözüm:
- Risk: Arşivleme stratejisi olmayan bir sistem, ne kadar güçlü donanımınız olursa olsun bir gün “Expensive SQL” sorguları içinde boğulur.
- Çözüm: Ayda bir kez en büyük ilk 20 tabloyu analiz edin. Eğer bir log tablosu kontrolsüz büyüyorsa, orada bir “teknik borç” birikiyor demektir. Çözüm disk eklemek değil, verinin yaşam döngüsünü yönetmektir.
Uzman Notu:
ST04 ve DB02’nin yanı sıra, EWA (Early Watch Alert) raporlarını da düzenli okumak gerekir. EWA, SAP’nin sizin yerinize sistemin iç organlarını taradığı bir “sağlık raporu”dur. Orada gördüğünüz bir sarı veya kırmızı uyarı, birkaç hafta sonra sizin başınıza bela olarak gelebilir.
Hayat Kurtaran Detay:
Aynı tablo, ay ortasında sorun çıkarmazken ay sonu kapanışında sistemi kilitleyebilir.
Bu yüzden tablo büyüklüğüne değil, büyüme hızına ve yoğunluk zamanına bakarım. “Bu tablo ne zaman büyüyor?” sorusu, “ne kadar büyümüş?” sorusundan daha kritiktir.
3.Asılı Kalan İşler (SM37): “Saatli Bomba” Joblar
Çalışan bir sistemde job’lar “Finished” veya “Cancelled”dır. Dayanıklı bir sistemde ise işler “Anlamlı”dır. SAP dünyasında bazen bir iş ne biter ne hata verir; sadece “Active” kalarak sistem kaynaklarını rehin alır.
İroni Notu:
Bazı geliştiriciler “Job’ı her 5 dakikada bire kurdum, bitmezse öbürü başlar” demeyi çok sever. Bu, Basis dünyasında “Saatli bomba kurdum, ne zaman patlayacağını ben de bilmiyorum” demektir.
Öneri:
Bu “asılı kalan” (hanging) işler, özellikle BTC (Background) work process’leri doldurduğunda sistemde hayat durur. Kritik işlerin çalışma sürelerini takip edin. Her gün 10 dakikada biten bir iş, bir gün 2 saat sürüyorsa, o iş “Finished” olsa bile sisteminizde bir şeyler ters gidiyor demektir.
Uzman Refleksi:
Bir job’un süresi tek seferlik uzadığında panik yapmam. Ama her hafta %10 daha uzun sürüyorsa, henüz kimse şikayet etmeden o job’u radar altına alırım. Çünkü job’lar genelde “iptal oldukları gün” değil, yavaşladıkları haftalarda sistem öldürür.
Ek Bilgi Kaynağı
SAP mimarisi sadece bir diyagram değildir. Operasyonel disiplin, hata yönetimi ve canlı sistem gerçekleriyle dayanıklı bir SAP ekosistemi kurmanın yollarını keşfedin.
4. Tamponlar (Buffers) ve Mimari Farklar (ST02)
ST02 ekranındaki “Swap” değerleri, klasik veritabanlarında (Oracle, MSSQL vb.) sistemin diskle ne kadar boş yere meşgul olduğunun karnesidir. Ancak HANA dünyasında bakış açımızı biraz güncellemeliyiz.
HANA sistemlerinde de ST02 önemlidir; ancak burada artık ‘swap’ değil, Buffer Hit Ratio ve DBA Cockpit’teki memory metrics birlikte takip edilir. Eğer ST02’de sürekli düşük hit ratio görüyorsanız, sisteminiz veriyi hafızadan okumak yerine sürekli veritabanına sorma zahmetine giriyordur. Gerçek uzmanlık, ST02’deki bu değerleri DBA Cockpit verileriyle harmanlayıp “darboğaz nerede?” sorusuna net yanıt verebilmektir.
5. En Tehlikeli Hata: “Ben Yedek Aldım”
Basis dünyasının en eski ama en geçerli şakası şudur: “Yedek alan değil, restore edebilen Basisci huzurlu uyur.”
Gerçek Bir Risk:
Sadece “Backup Successful” yeşil ışığına güvenmeyin. Haftalık veya aylık olarak, mümkünse üretim dışı (test) bir ortamda Restore testi yapın. Yedekleme yazılımları bazen yetki hataları nedeniyle bazı veri dosyalarını (datafiles) atlayabilir ama genel rapora “başarılı” diyebilir. 10 TB’lık sistemin yedeği 100 GB geliyorsa, orada bir mucize değil, bir facia vardır.
Niş Bir Örnek:
Çok büyük bir perakende firmasında, yedekleme yazılımı her gün “Backup Successful” raporu veriyordu. Ancak bir felaket kurtarma (DR) testi sırasında fark ettik ki; veritabanı logları yedekleniyor ama datafile’ların olduğu bir bölüm yetki hatası yüzünden yedekleme dışı kalmış. Yazılım bunu “uyarı” olarak geçmiş ama “hata” vermemiş.
Checklist Tuzağı:
Backup kontrolü çoğu checklist’te tek satırdır.
Ama gerçek hayatta yedekleme, “alındı mı?” sorusunun cevabı değildir,
“Hangi senaryoda, ne kadar sürede, kim restore edecek?” sorularının cevabıdır.
6. S/4HANA ve 2026 Gerçekliği: Hibrit Uzmanlık
2026 yılındayız ve “sadece kurulum yapan” Basis uzmanı devri aslında bir dönüşüm geçirdi. Geleneksel beceriler hala temel direğimiz; ancak artık bu temelin üzerine BTP, Cloud Connector ve Güvenlik (SNOTE) katmanlarını koymak zorundayız.
Bir Basis profesyoneli artık bir iletişim mimarı gibi çalışmalı. Bulut servislerine bağlanan bir sistemde, sertifika sürelerini (certificate expiry) takip etmemek veya kritik Security Notes (Hot News) yamalarını geçmemek, sistemin kapısını dış dünyaya açık bırakmaktır.
Çalışan ve Dayanıklı Sistem Karşılaştırması
Özellik | Çalışan Sistem (Rutin Yönetim) | Dayanıklı Sistem (Uzmanlık) |
İzleme | Hata olduğunda müdahale eder. | Trend sapmalarını izler, hata oluşmadan önler. |
Taşıma (STMS) | Sadece “Import” tuşuna basar. | Versiyon çakışmalarını ve bağımlılıkları yönetir. |
Yedekleme | Loga bakar geçer. | Düzenli restore testi ile yedeği doğrular. |
Güvenlik | Talep gelince yetki verir. | SNOTE (Hot News) ve RFC güvenliğini proaktif yönetir. |
Zamanlama | Peak anlarını dikkate almaz. | Yoğunluk çakışmalarını önceden simüle eder. |
O Görünmez Dokunuş
Gerçek bir SAP Basis uzmanı, sistemin en yoğun olduğu ay sonu kapanışlarında veya bayram öncesi satış trafiklerinde, ekibinin arkasına yaslanıp “Sistem sakin, her şeyi simüle etmiştik” diyebilen kişidir.
Eğer sürekli “yangın söndürüyorsanız”, bir yerde uzmanlığı değil, rutini yönetiyorsunuz demektir. Checklist’leri birer “minimal gereklilik” olarak görün ve sistemin size fısıldadığı o teknik detaylara odaklanın. Çünkü şeytan, her zaman o incelenmemiş kilitlerde veya temizlenmemiş log kuyruklarında gizlidir.