Bir üretim ERP’sinde uzun yıllar çalışırken, yeni bir veritabanı teknolojisine geçiş fikri sıkça gündeme gelirdi. Her seferinde “daha hızlı,” “daha modern” gibi argümanlarla karşılaşırdık; ancak ben her zaman mevcut PostgreSQL sisteminin stabilite ve olgunluğunu savunurdum. Bu durum, teknoloji dünyasında sürekli karşımıza çıkan bir ikilemi net bir şekilde ortaya koyuyor: Her yeni çıkan teknolojiye koşulsuz şartsız atlamak gerçekten gerekli mi, yoksa bazen yavaş ve istikrarlı olmak daha mı akıllıca? Benim tecrübelerime göre, bu sorunun cevabı çoğu zaman ikincisinde gizli.
Bu yazıda, yeni teknolojilerin getirdiği heyecan ve potansiyelin yanı sıra, gözden kaçan maliyetleri, riskleri ve uzun vadeli etkilerini kendi deneyimlerimden yola çıkarak ele alacağım. Bir teknolojiyi benimsemeden önce hangi kritik soruları sormamız gerektiğini ve pragmatik bir yaklaşımın neden daha sürdürülebilir olduğunu anlatacağım. Amacım, her zaman en yeniyi kovalamak yerine, projelerimize ve işimize gerçek değer katacak doğru çözümleri seçme konusunda bir perspektif sunmak.
Yeni Teknolojilerin Hype Cycle’ı ve Saha Gerçekleri Arasındaki Farklar Nelerdir?
Teknoloji dünyası, sürekli bir yenilik ve değişim döngüsü içinde. Her birkaç yılda bir, “game changer” olarak lanse edilen yeni bir framework, veritabanı, mimari desen ya da araç ortaya çıkıyor. Bunlar genellikle ilk çıktıklarında büyük bir heyecan yaratır, konferanslarda ve bloglarda bolca konuşulur, adeta bir “hype cycle” yaşar. Ancak benim yirmi yıllık tecrübemde gördüğüm şey, bu hype’ın saha gerçekleriyle her zaman örtüşmediğidir. Pazarlama materyalleri ve ilk kullanıcı deneyimleri, genellikle teknolojinin potansiyel faydalarını abartırken, beraberinde getirdiği karmaşıklıkları ve olgunlaşmamışlıkları göz ardı eder.
Örneğin, bir zamanlar microservices mimarisi, her monolith uygulamanın mutlak sonu olarak lanse edilmişti. Birçok kuruluş, mevcut sistemlerini aceleyle parçalamaya girişti; ancak dağıtık sistemlerin getirdiği operasyonel yük, veri tutarlılığı sorunları, ağ gecikmeleri ve CI/CD karmaşası gibi zorluklarla yüzleşmek zorunda kaldılar. Küçük ekipler veya daha az karmaşık iş yükleri için monolith’in sunduğu basitlik ve hız, çoğu zaman göz ardı edildi. Kendi yan ürünlerimin backend’ini geliştirirken, ben de bu tarz bir mimari seçimiyle karşı karşıya kaldım. Başlangıçta microservices’in sunduğu modülerlik cazip gelse de, projenin ölçeği ve ekibimin büyüklüğü düşünüldüğünde, daha kontrollü bir monolith yapısının operasyonel yükü çok daha az olacaktı. Bu bana, her mimarinin kendi bağlamında değerlendirilmesi gerektiğini bir kez daha öğretti.
Saha gerçekleri, bir teknolojinin sadece kağıt üzerindeki vaatlerinden ibaret olmadığını gösterir. Bir sistem mimarı olarak, benim önceliğim her zaman stabilite, güvenlik ve sürdürülebilirlik oldu. Yeni bir teknoloji bu temelleri sarsıyorsa, ne kadar “havalı” olursa olsun, benim için bir risk faktörü haline gelir. Örneğin, kernel modüllerini blacklist’e almak veya fail2ban paternlerini ince ayar yapmak gibi sistem güvenliği konularında, denenmiş ve güvenilir çözümlerin sağladığı gönül rahatlığı, deneysel bir yaklaşımdan çok daha değerlidir. Bu nedenle, her zaman bir teknolojinin olgunluğunu, topluluk desteğini ve uzun vadeli yol haritasını dikkatle değerlendiririm.
Bir Yeni Teknolojiye Atlamanın Gizli Maliyetleri Sadece Lisans Ücretleri mi?
Birçok kişi, yeni bir teknolojiye geçişin maliyetini sadece lisans ücretleri veya ilk geliştirme süresiyle sınırlı sanır. Ancak yirmi yıla yakın tecrübemde defalarca gördüm ki, gerçek maliyetler buzdağının görünmeyen kısmındadır ve genellikle çok daha büyüktür. Bu gizli maliyetler, öğrenme eğrisinden entegrasyon zorluklarına, bakım yükünden güvenlik açıklarına kadar geniş bir yelpazeyi kapsar.
Yeni bir teknolojiye geçiş, ekibiniz için ciddi bir öğrenme eğrisi anlamına gelir. Geliştiricilerin, sistem yöneticilerinin ve hatta operasyon ekibinin yeni araçları, dilleri ve paradigmaları öğrenmesi zaman ve kaynak tüketir. Bu süreç, sadece eğitimlerle sınırlı kalmaz; deneme-yanılma, hata ayıklama ve en iyi uygulamaları keşfetme süreçlerini de içerir. Örneğin, bir projemizde monolitik bir yapıdan daha dağıtık bir yapıya geçiş kararı alındığında, ekibin Redis, Kafka gibi bileşenlerin yanı sıra, bunların üretim ortamındaki yönetimi, izlenmesi ve güvenliği konularında kapsamlı bir bilgi birikimine ihtiyacı oldu. Bu geçiş, sadece kod yazmaktan ibaret değildi; aynı zamanda sistemlerin nasıl davranacağını öngörmek, olası WAL bloat sorunlarını önlemek veya Redis’in OOM eviction policy’sini doğru seçmek gibi derinlemesine bilgi gerektiren operasyonel zorlukları da beraberinde getirdi.
Entegrasyon maliyetleri de göz ardı edilmemelidir. Yeni bir teknoloji, mevcut altyapınızla, diğer uygulamalarınızla ve veri kaynaklarınızla sorunsuz bir şekilde konuşabilmelidir. Bu entegrasyonlar genellikle karmaşıktır ve beklenenden daha fazla zaman alır. Veri geçişleri, API uyumsuzlukları ve güvenlik protokollerinin senkronizasyonu gibi konular, projenin zaman çizelgesini ve bütçesini ciddi şekilde etkileyebilir. Özellikle bir üretim ERP’sinde, tedarik zinciri entegrasyonları veya IFRS uyumlu finansal raporlama gibi kritik iş akışlarının yeni bir teknolojiye taşınması, en ufak bir hatanın bile büyük finansal sonuçlar doğurabileceği anlamına gelir. Bu yüzden, yeni bir şey eklerken mevcut sistemin bütünlüğünü korumak ve olası yan etkileri minimuma indirmek esastır.
Bakım yükü de önemli bir gizli maliyettir. Yeni bir teknoloji, genellikle daha sık güncelleme, daha fazla yama ve daha yoğun bir izleme gerektirir. Erken aşamadaki teknolojilerde bug’lar daha yaygın olabilir ve topluluk desteği henüz tam oturmamış olabilir. Bu durum, operasyon ekibinin iş yükünü artırır ve beklenmedik kesintilere yol açabilir. Ayrıca, vendor lock-in riski de vardır; belirli bir teknolojiye ne kadar bağımlı hale gelirseniz, gelecekte farklı bir çözüme geçiş yapma esnekliğiniz o kadar azalır. Son olarak, her yeni teknolojinin kendine özgü güvenlik açıkları olabilir. CVE takibi, kernel module blacklist uygulamaları ve fail2ban paternlerinin sürekli güncellenmesi gibi güvenlik pratikleri, yeni bileşenlerle birlikte daha da karmaşık hale gelir. Bu yüzden, bir kararı vermeden önce sadece “ne kadar hızlı” olduğunu değil, “ne kadar güvenli ve sürdürülebilir” olduğunu da sormak gerekir.
Mevcut ve Kanıtlanmış Çözümlerimizden Ne Zaman Vazgeçmeliyiz?
Yeni teknolojilerin cazibesi altında her şeyi değiştirmek yerine, mevcut ve kanıtlanmış çözümlerimizden ne zaman vazgeçmemiz gerektiği sorusu daha kritik hale geliyor. Ben, bu kararı verirken her zaman somut verilere ve iş ihtiyaçlarına odaklanırım, sadece “modası geçti” argümanına itibar etmem. Bir teknolojinin ömrünü tamamladığını gösteren belirgin işaretler vardır ve bu işaretleri doğru okumak, stratejik bir geçiş yapmanın anahtarıdır.
Öncelikle, performans darboğazları ve ölçeklenebilirlik limitleri, mevcut bir çözümün yetersiz kaldığının en açık göstergeleridir. Eğer PostgreSQL veritabanında index stratejilerini (B-tree, GIN, BRIN) optimize etmeme, connection pool’u ayarlamama ve replikasyon çözümleri (logical vs physical) kullanmama rağmen hala sorgu sürelerinde ciddi artışlar yaşıyorsak veya Redis’in hafıza kullanımı sürekli limitlere dayanıyorsa, bu, mevcut mimarinin sınırlarına ulaştığımız anlamına gelebilir. Bu gibi durumlarda, L4 vs L7 load balancing tercihleri gibi network katmanındaki optimizasyonlar bile sorunu kökten çözmeyebilir ve daha radikal bir değişimi düşünmemiz gerekebilir. Ancak bu, “yeni bir veritabanına geçelim” demekten önce, mevcut sistemdeki her optimizasyon fırsatının değerlendirildiğinden emin olmak demektir.
İkinci olarak, ciddi güvenlik açıkları veya end-of-life (EOL) desteği, bir teknolojiyi terk etme kararı için güçlü gerekçeler sunar. Bir yazılımın artık güvenlik güncellemeleri almıyor olması veya bilinen kritik CVE’ler için yama yayınlanmaması, projenizi ve verilerinizi büyük risk altına sokar. Örneğin, bir Linux dağıtımının eski bir kernel sürümünü kullanması ve algif_aead gibi modüllerde bilinen güvenlik açıklarının bulunması, sistem yöneticisi olarak benim için kırmızı alarmdır. Bu durumda, kernel module blacklist uygulamak veya AppArmor/SELinux profillerini sıkılaştırmak gibi önlemler geçici çözümler sunsa da, uzun vadede daha güncel ve desteklenen bir platforma geçiş kaçınılmaz hale gelir.
Üçüncü olarak, iş ihtiyaçlarının ve özellik setinin değişmesi, mevcut çözümün artık amaca uygun olmadığını gösterebilir. Eğer mevcut yazılım, yeni iş modellerini, yasal düzenlemeleri veya müşteri taleplerini karşılayamıyorsa ve bu eksiklikler kolayca giderilemiyorsa, yeni bir çözüm arayışına girmek makul olabilir. Örneğin, bir üretim ERP’sinde AI ile üretim planlama veya gerçek zamanlı operatör ekranları gibi özellikler eklemek istediğimde, mevcut yapının bu tarz dinamik ve yüksek performans gerektiren modülleri desteklemediğini fark ettim. Bu durum, ya mevcut sistem üzerinde büyük bir refactoring yapmayı ya da bu yeni modüller için farklı, daha modern bir altyapı kullanmayı gerektirdi. Ancak yine de, bu yeni teknolojiyi “big bang” bir yaklaşımla tüm ERP’ye entegre etmek yerine, event-sourcing veya transaction outbox gibi desenlerle kademeli bir geçişi tercih ettim. Özetle, bir teknolojiden vazgeçme kararı, duygusal değil, tamamen mantıksal, veri odaklı ve risk-fayda analizi yapılmış bir süreç olmalıdır.
20 Yıllık Tecrübemden Çıkardığım Dersler: “Yavaş ve İstikrarlı” Neden Önemli?
Yirmi yıllık sistem mimarisi, network yönetimi ve kurumsal yazılım geliştirme tecrübem bana bir gerçeği net bir şekilde öğretti: Hız her zaman en önemli faktör değildir; bazen “yavaş ve istikrarlı” olmak, uzun vadede çok daha değerli sonuçlar doğurur. Özellikle operasyonel mükemmellik ve sistem güvenliği söz konusu olduğunda, denenmiş ve güvenilir çözümlere sadık kalmak, bana göre altın bir kuraldır.
Birçok projede, bleeding-edge teknolojilerin ilk başta sunduğu “hız” ve “modernlik” vaatlerinin, kısa sürede operasyonel karmaşıklık, beklenmedik hatalar ve bakım yükü olarak geri döndüğünü gördüm. Örneğin, Linux servislerini yönetirken, systemd unit’lerini ve journald’ı derinlemesine anlamak ve optimize etmek, bana her zaman yeni bir process manager denemekten daha fazla güven verdi. cgroup limit’lerini hassas bir şekilde ayarlayarak bellek kullanımı ve CPU tahsisini kontrol etmek, uygulamalarımın stabil çalışmasını sağlarken, bilinmeyen bir araçla vakit kaybetmemi engelledi. Geçen ay bir test sunucusunda, bir polling işlemi için sleep 360 yazıp OOM-killed olduğumda, bu hatadan ders çıkararak polling-wait mekanizmalarına geçtim. Bu tarz “saha” tecrübeleri, bana her zaman teorik bilgiden daha fazla yol gösterdi.
Network tarafında da benzer dersler çıkardım. VLAN tagging karmasası, switch loop’ları veya MTU/MSS mismatches gibi sorunlar, en yeni network ekipmanını kullanıyor olsanız bile karşınıza çıkabilir. Bu sorunları çözmek için temel routing prensiplerini, DSCP/QoS ayarlarını ve segmentasyon stratejilerini iyi bilmek gerekir. Bir projemizde, şirket çıkışında 3 farklı ISP kullanıyorduk ve DSCP marking doğru yapılmadığı için ses paketleri sürekli patlıyordu. Bu sorunu çözmek, yeni bir router almak yerine, mevcut cihazların konfigürasyonlarını detaylıca inceleyip QoS politikalarını baştan yazmakla mümkün oldu. Bu, bana teknolojinin kendisinden çok, teknolojinin nasıl kullanıldığı ve yönetildiği konusunda derinlemesine bilgi sahibi olmanın önemini gösterdi.
Güvenlikte de durum farklı değil. Kernel module blacklist (örneğin algif_aead, CVE-2026-31431 gibi kritik zafiyetleri engellemek için), fail2ban paternleri veya auditd ile dosya bütünlük monitoring gibi uygulamalar, yeni ve karmaşık güvenlik ürünlerine kıyasla çok daha temel ve güvenilir bir koruma katmanı sunar. Bu temel katmanlar olmadan, en gelişmiş “next-gen” güvenlik çözümleri bile işe yaramaz kalır. Benim felsefem, sağlam bir temel üzerine inşa etmek ve her adımı dikkatle atmaktır. Bu yaklaşım, sadece sistemlerin daha stabil çalışmasını sağlamakla kalmaz, aynı zamanda beklenmedik sorunlar karşısında hızlı ve etkili bir şekilde müdahale etme yeteneğimi de artırır. Bu yüzden, “yavaş ve istikrarlı” yaklaşımı, benim için sadece bir tercih değil, aynı zamanda operasyonel bir zorunluluktur.
”Zero-Trust Mimarisi” Gerçekten Yeni Bir Teknoloji mi, Yoksa Zihniyet Değişikliği mi?
“Zero-Trust Mimarisi” terimi son zamanlarda sıkça duyduğumuz, güvenlik dünyasında popülaritesi artan bir kavram. İlk bakışta, bu da “yeni bir teknoloji” gibi algılanabilir; ancak yirmi yıllık siber güvenlik tecrübemle söyleyebilirim ki, Zero-Trust aslında bir ürün veya tek bir teknoloji yığını değil, köklü bir zihniyet değişikliği ve stratejik bir güvenlik yaklaşımıdır. Bu ayrımı anlamak, yeni teknolojilere atlama dürtüsünü kontrol etmek açısından kritik öneme sahiptir.
Zero-Trust’ın temel felsefesi “asla güvenme, her zaman doğrula” ilkesine dayanır. Bu, ağ içindeki veya dışındaki hiçbir kullanıcıya, cihaza ya da uygulamaya varsayılan olarak güvenilmemesi gerektiği anlamına gelir. Geleneksel güvenlik modelleri genellikle çevresel güvenliğe (perimeter security) odaklanırken, Zero-Trust, her erişim isteğini sanki düşmanca bir ortamdan geliyormuş gibi değerlendirir. Bu yaklaşım, network segmentasyonu, güçlü kimlik doğrulama (MFA), mikrosegmentasyon, en az ayrıcalık (least privilege) prensibi ve sürekli izleme gibi bir dizi teknik ve operasyonel uygulamayı gerektirir. Benim ağ güvenliği alanındaki deneyimimde, ZTNA egress kontrol ve şirket segmentasyonu gibi konuları uygularken, bu felsefenin ne kadar dönüştürücü olabileceğini gördüm.
Birçok firma, Zero-Trust’ı “yeni bir firewall”, “yeni bir VPN çözümü” veya “yeni bir kimlik yönetimi platformu” satın alarak uygulayabileceğini düşünür. Oysa Zero-Trust, mevcut altyapıyı baştan sona gözden geçirmeyi, güvenlik politikalarını yeniden tanımlamayı ve operasyonel süreçleri değiştirmeyi gerektiren kapsamlı bir dönüşümdür. Örneğin, switch hardening (DHCP snooping, DAI, IP source guard) uygulamak, routing authentication (OSPF/IS-IS) kullanmak veya DSCP/QoS’i uçtan uca yapılandırmak, Zero-Trust felsefesinin temel taşlarındandır ve bunlar tek bir yeni ürünle elde edilemez. Bu, mevcut sistemlerin doğru yapılandırılması ve sürekli olarak denetlenmesiyle gerçekleşir.
Zero-Trust’ın en büyük değeri, saldırı yüzeyini küçültmesi ve ihlallerin etkisini sınırlamasıdır. Bir saldırgan ağa sızsa bile, yatay hareket (lateral movement) kabiliyeti önemli ölçüde kısıtlanır çünkü her erişim noktası ayrı ayrı doğrulanmak zorundadır. Benim tecrübelerime göre, bu tarz bir yaklaşım, sadece yeni teknolojileri peşinden koşmak yerine, mevcut güvenlik araçlarını ve süreçlerini daha akıllıca kullanmanın ne kadar önemli olduğunu gösterir. Tahminsel ve anomali tabanlı izleme sistemleriyle entegre edildiğinde, Zero-Trust, bir kuruluşun güvenlik duruşunu temelden güçlendiren, kalıcı bir stratejik avantaj sağlar. Bu, bana göre “yeni teknoloji”den ziyade, “doğru zihniyet”in zaferidir.
Yeni Bir Teknolojiyi Projelerimize Nasıl Entegre Etmeliyiz?
Yeni teknolojilere tamamen sırt çevirmek de gerçekçi değil; gelişim ve ilerleme için yeniliklere açık olmak şart. Ancak mesele, her yeni teknolojiye atlamak değil, doğru teknolojiyi doğru zamanda ve doğru yöntemle entegre etmektir. Kendi projelerimde ve danışmanlık süreçlerimde, yeni bir teknolojiyi benimserken izlediğim pragmatik bir yol haritası var. Bu harita, riskleri minimize ederken faydaları maksimize etmeyi hedefler.
İlk adım, teknolojinin “neden” gerekli olduğunu net bir şekilde anlamaktır. Mevcut bir sorunu çözüyor mu, verimliliği artırıyor mu, yeni bir iş fırsatı yaratıyor mu? Bu soruların cevabı net değilse, o teknoloji sadece bir “parlak oyuncak” olabilir. Örneğin, AI uygulama mimarisi üzerinde çalışırken, RAG (retrieval-augmented generation) paternlerini veya agent pattern’lerini kullanma kararı, sadece “AI kullanıyoruz” demek için değil, belirli bir bilgi eksikliğini gidermek veya karmaşık bir iş akışını otomatikleştirmek için alındı. Bu, sadece bir trendi takip etmek yerine, işin gerçek ihtiyacına odaklanmaktır.
İkinci adım, küçük ölçekli bir Proof-of-Concept (PoC) veya pilot proje yapmaktır. Tamamen yeni bir teknolojiyi doğrudan üretim ortamına entegre etmek yerine, kontrollü bir ortamda test etmek, potansiyel sorunları ve uyumsuzlukları erkenden tespit etmenizi sağlar. Kendi yan ürünümün finansal hesaplayıcılarında yeni bir veri işleme motoru denerken, önce izole bir ortamda performans testleri yaptım ve mevcut sistemle entegrasyonunu simüle ettim. Bu, bana hem teknolojinin vaatlerini doğrulama hem de gizli maliyetleri ve entegrasyon zorluklarını öngörme fırsatı verdi. Bu pilot projelerde, sadece teknik uygunluğu değil, aynı zamanda ekibin öğrenme eğrisini ve operasyonel karmaşıklığı da gözlemlemek önemlidir.
Üçüncü adım, kademeli bir entegrasyon stratejisi izlemektir. “Big bang” yaklaşımlar genellikle felaketle sonuçlanır. Bunun yerine, blue-green deployment, canary release veya feature flag gibi tekniklerle yeni teknolojiyi küçük bir kullanıcı grubuna veya belirli bir işlevselliğe açmak, riskleri dağıtmanızı sağlar. Bir üretim ERP’sinde yeni bir AI destekli üretim planlama modülünü devreye alırken, ilk önce verileri replikasyon ile izole bir ortama taşıdık, ardından AI modelini belirli bir ürün grubu için test ettik ve ancak sonuçlar pozitif olduğunda kapsamı genişlettik. Bu sayede, olası hataların üretim sürecini etkilemesini engelledik ve geri dönüş (rollback) süreçlerini kolaylaştırdık.
Son olarak, her yeni teknolojinin yaşam döngüsü boyunca sürekli izlenmesi ve değerlendirilmesi gerekir. Observability (metrik, log, trace) araçlarıyla performansı, hataları ve kullanıcı deneyimini yakından takip etmek, teknolojinin beklentileri karşılayıp karşılamadığını anlamak için hayati öneme sahiptir. SLO ve error budget yönetimi, yeni teknolojilerin üretim ortamındaki davranışlarını objektif bir şekilde değerlendirmemizi sağlar. Kendi VPS’imde çalıştırdığım self-hosted CI/CD runner’larında bile, container memory limit’lerini ve docker disk yangınlarını izleyerek olası sorunları proaktif olarak tespit ediyorum. Bu sürekli geri bildirim döngüsü, bize bir teknolojiyi benimseme kararımızın ne kadar doğru olduğunu gösterir ve gerektiğinde ayarlamalar yapmamıza olanak tanır. Çoklu provider fallback (Gemini Flash, Groq, Cerebras, OpenRouter) stratejisi de AI modelleri için bu tür bir esneklik ve izleme imkanı sunar.
Sonuç
Teknoloji dünyasının baş döndürücü hızı altında, her yeni parlak araca atlama dürtüsü oldukça cazip gelebilir. Ancak yirmi yıllık saha tecrübem bana gösterdi ki, bu dürtüye direnmek ve stratejik, pragmatik bir yaklaşım benimsemek çoğu zaman daha sağlıklı ve sürdürülebilir sonuçlar doğurur. Her yeni teknoloji, sadece bir araçtır ve gerçek değeri, bir iş sorununu çözme veya somut bir fayda sağlama yeteneğinde yatar.
Önemli olan, bir teknolojinin hype cycle’ına kapılmak yerine, onun gerçek maliyetlerini, öğrenme eğrisini, entegrasyon zorluklarını ve uzun vadeli bakım yükünü göz önünde bulundurmaktır. Mevcut ve kanıtlanmış çözümlerimizi, performans darboğazları, güvenlik açıkları veya değişen iş ihtiyaçları gibi somut gerekçelerle aşmadıkça, onlara sadık kalmak genellikle daha akıllıca bir seçimdir. “Zero-Trust Mimarisi” örneğinde olduğu gibi, bazen “yeni teknoloji” olarak algıladığımız şey aslında köklü bir zihniyet değişikliği ve mevcut araçları daha akıllıca kullanma biçimidir.
Yeni bir teknolojiyi projelerimize entegre ederken, “neden” sorusunu sormak, küçük ölçekli PoC’ler yapmak, kademeli geçiş stratejileri izlemek ve sürekli izleme ile geri bildirim döngüleri oluşturmak esastır. Bu yaklaşım, sadece riskleri minimize etmekle kalmaz, aynı zamanda teknolojinin işimize gerçek değer katmasını sağlar. Unutmayalım ki, teknoloji bir amaç değil, bir araçtır. Amacımız her zaman istikrarlı, güvenli ve verimli sistemler inşa etmek olmalıdır.