IT Altyapısı Bir Ürünler Listesi Değildir

Gerçek altyapı tasarımı, araçlardan değil sistemlerden başlar

Bu yazı, serinin mimari temelini oluşturur.
Switch, firewall, wireless, Zero Trust veya 802.1X konuşmadan önce, tek bir konuda net olmamız gerekiyor:

IT altyapısı, satın aldığınız ürünlerin toplamı değildir.
IT altyapısı, bu sistemlerin baskı altında nasıl davrandığının sonucudur.

Altyapı projeleri gerçekte nerede başarısız olur?

Birçok altyapı projesi iyi niyetle başlar. Yenileme planlanır, bütçe ayrılır ve tartışma hızla ürün karşılaştırmalarına döner. Vendor’lar, özellik listeleri ve veri sayfaları masaya gelir.

Ancak sahada başarısız olan projelerin büyük bölümü, seçilen ürünler kötü olduğu için değil; altyapı hiçbir zaman gerçek anlamda bir sistem haline gelmediği için başarısız olur.

Yıllar içinde tekrar tekrar gördüğüm tablo şudur:
Her bileşen kendi başına düzgün çalışır, ancak ortamın genel davranışı öngörülemezdir. Kimlik bir yerde üretilir, segmentasyon başka bir yerde uygulanır, politika kararları farklı katmanlarda verilir ve operasyon her şeyi manuel olarak bir arada tutmaya çalışır. Bir sorun çıktığında, hiçbir katman tüm bağlama hâkim değildir.

Altyapı vardır.
Ama altyapı davranışı yoktur.

Ürünler problemi çözer, sistemler operasyonu taşır

Bir ürün belirli bir problemi çözmek için tasarlanır.
Bir altyapı ise bir organizasyonu ayakta tutmak için tasarlanır.

Bu fark küçük gibi görünür ama kritiktir. Ürünler değiştirilebilir. Sistemler evrilmek zorundadır.

Altyapı ürünler listesi olarak tasarlandığında, kararlar lokal olarak optimize edilir. Her ekip kendi alanında “en iyiyi” seçer. Zamanla bu lokal optimizasyonlar küresel bir karmaşaya dönüşür. Entegrasyon kırılganlaşır, troubleshooting uzar ve yapılan her değişiklik risk haline gelir.

Sistem odaklı tasarım ise farklı sorularla başlar:

• Kimlik nerede üretiliyor ve nereye kadar taşınıyor?
• Güven sınırları nerede tanımlanıyor?
• Hangi bileşenler politika kararı veriyor, hangileri sadece uyguluyor?
• Bağlam katmanlar arasında nasıl korunuyor?
• Bir şey bozulduğunda operasyonel olarak ne oluyor?

Bu sorular net değilse, en iyi ürünler bile zamanla birbirine karşı çalışmaya başlar.

Mimari, stres altında kendini belli eder

Her şey yolundayken altyapı tasarlamak kolaydır.
Mimari, ancak bir şeyler ters gittiğinde kendini gösterir.

Incident’lar, ölçek problemleri, güvenlik ihlalleri ve operasyonel değişiklikler; yazıya dökülmemiş varsayımları ortaya çıkarır. Ürünlerden oluşan gevşek yapılarda bu anlar yangın söndürmeye dönüşür. Geçici çözümler kalıcı istisnalar haline gelir. Zamanla altyapı tutarlılığını kaybeder.

İyi tasarlanmış sistemler ise farklı davranır. Kontrollü şekilde bozulur, sorumluluklar nettir, hatalar sınırlandırılır ve toparlanma yolları önceden bellidir. Bu bir tesadüf değildir; bilinçli mimari kararların sonucudur.

Entegrasyon bir özellik değildir

Altyapı tasarımındaki en yaygın yanılgılardan biri, entegrasyonu bir checkbox olarak görmektir. Aynı vendor’dan alınan ya da aynı standartları destekleyen ürünlerin “entegre” olduğu varsayılır.

Gerçek entegrasyon uyumlulukla ilgili değildir.
Ortak bağlamla ilgilidir.

Kimlik farkındalığı, tutarlı segmentasyon, birleşik loglama ve öngörülebilir politika davranışı; “entegre ürün” satın alarak otomatik oluşmaz. Bunlar tasarlanır, test edilir ve operasyonun parçası haline getirilir.

Aksi halde entegrasyon yalnızca sunum slaytlarında vardır.

Gerçek mimari operasyonlarda ortaya çıkar

Bir ortamın gerçek mimarisi diyagramlarda değil, günlük operasyonlarda yaşar.

• Değişiklikler nasıl uygulanıyor?
• Sorunlar nasıl analiz ediliyor?
• İstisnalar nasıl yönetiliyor?
• Otomasyon nereye kadar giriyor?
• Sorumluluklar ekipler arasında nasıl bölünüyor?

Bu akışlar manuel, kopuk veya dokümansızsa; altyapı da bu gerçeği yansıtır. Ne kadar modern teknoloji kullanılırsa kullanılsın, tutarlı şekilde işletilemeyen altyapı güvenli ve ölçeklenebilir olamaz.

Bu yüzden otomasyon, gözlemlenebilirlik ve lifecycle yönetimi “ekstra” değil; mimarinin kendisidir.

Network konuşmadan önce neden bunu anlatıyorum?

Bu problemler en hızlı network katmanında görünür hale gelir. Trafik akışları bozuk güven modellerini, segmentasyon eksik kimlik tasarımlarını, performans problemleri ise mimari kestirmeleri ortaya çıkarır.

Ama network sebep değildir.
Aynadır.

Bu seri tam da bu yüzden burada başlıyor. Core network, vendor stratejileri, Zero Trust veya 802.1X konuşmadan önce ortak bir zemine ihtiyacımız var: altyapı bir alışveriş listesi değil, niyetle tasarlanmış bir sistemdir.

Bu serinin yönünü belirleyen ilke

Bu serideki tüm yazılar tek bir ilkeye dayanır:

Önce sistemi tasarla. Sonra ürünleri seç.

Bu sıra tersine döndüğünde altyapı pahalı ve kırılgan olur.
Bu sıraya sadık kalındığında ise altyapı öngörülebilir ve evrilebilir hale gelir.

Sırada ne var?

Bir sonraki yazı bu yaklaşımı doğrudan core network üzerine uyguluyor:

• Core network neden switch, firewall ve access point listesinden ibaret değildir?
• Entegrasyon, kapasite planlaması ve operasyonel bağlam gerçek network mimarisini nasıl tanımlar?

Bu ilk yazı, serinin temelini atmak için var.
Diğer her şey bunun üzerine inşa ediliyor.

Not

Bu makale ilk olarak Substack’te daha kısa, anlatısal bir biçimde yayınlanmıştı.

Bu versiyon, serinin mimari temelini genişletiyor.

👉 Makaleyi Substack’te okuyun: Burayı Tıklayın