Turknet Altyapısını Otomasyonlar Yönetiyor: Self Service Portal’ın Doğuşu

Cloud ekibi olarak, TurkNet altyapısının on-prem ortamda 2000’in üzerinde sanal makine üzerinde çalışan uygulamalar, veri tabanları ve web servislerinden oluşan geniş ve kritik bir ekosistemi uçtan uca yönetiyoruz. Bu operasyonlarda sistemlerin sürekliliğini, performansını ve ölçeklenebilirliğini garanti altına almak amacıyla modern otomasyon teknolojileri ve gelişmiş yönetim araçlarından aktif biçimde yararlanıyoruz. Bu yazıda, söz konusu altyapıyı hangi problemlerden yola çıkarak, hangi araçlar ve yaklaşımlarla bütünsel bir yapıya dönüştürdüğümüzü ele alacağım.

Problemin Ortaya Çıkışı: Büyüyen Altyapı, Artan Operasyonel Yük

TurkNet’in hızla büyüyen on-prem altyapısında 2000’in üzerindeki sanal makinenin yönetimi, zamanla geleneksel operasyon yöntemleriyle sürdürülemez hâle gelmeye başladı. Artan VM sayısıyla birlikte; snapshot talepleri, DNS işlemleri, yeni VM oluşturma istekleri, kaynak artırımları ve servis kurulumları gibi operasyonlar her geçen gün daha fazla zaman ve efor gerektiriyordu. Bu talepleri karşılamaya çalışırken, altyapının sürekliliğini sağlamak ve mevcut sistemleri iyileştirmek giderek zorlaşmaya başladı.

Bu noktada asıl problem, iş yükünün artmasından çok; bu yükün büyük ölçüde manuel ve kişiye bağımlı süreçlerle yönetiliyor olmasıydı. Aynı zamanda sanallaştırma platformu üzerinde geniş yetkiler gerektiren bu işlemleri her ekibe açmak güvenlik ve yetkilendirme açısından da mümkün değildi.

Tüm bu etkenler, on-prem ortamlarımızı tıpkı bir cloud provider mantığıyla yönetebileceğimiz; envanteri merkezi hâle getiren, operasyonları standartlaştıran ve kullanıcı taleplerini güvenli biçimde self-service hâline getiren bir otomasyon katmanına olan ihtiyacı net şekilde ortaya koydu.

Otomasyon Katmanının Konumlanması

Bu ihtiyacı karşılamak üzere farklı otomasyon teknolojilerini değerlendirdik. Amacımız yalnızca belirli işlemleri otomatikleştirmek değil; on-prem altyapıyı, cloud providerların sunduğu yönetim deneyimine mümkün olduğunca yaklaştıracak esnek ve sürdürülebilir bir yapı kurmaktı. Bu değerlendirme sonucunda Ansible ve AWX, açık kaynak yapıları, geniş modül ekosistemleri ve tamamen ihtiyaçlarımıza göre şekillendirilebilir mimarileri sayesinde en uygun çözüm olarak öne çıktı.

Neden Ansible?

Ansible tarafında bizi öne çıkaran başlıca noktalar; agentless mimarisi sayesinde sanal makineler üzerinde ek bir bileşen gerektirmemesi, SSH üzerinden merkezi ve güvenli kontrol sağlaması ve idempotent çalışma prensibiyle aynı otomasyonun her çalıştırıldığında tutarlı sonuçlar üretmesiydi. Bu özellikler, özellikle 2000’in üzerinde VM’in bulunduğu dinamik bir ortamda konfigürasyon drift’ini önlemek ve operasyonel hataları minimize etmek açısından kritik avantajlar sağladı. Ayrıca tüm operasyonel süreçlerin kodlanabilir ve versiyonlanabilir hâle gelmesi, altyapı yönetimini kişilere bağımlı olmaktan çıkararak kurumsal bir standarda taşıdı.

Neden AWX?

AWX ise bu otomasyonları güvenli, denetlenebilir ve self-service bir yapıya dönüştüren katman oldu. Role-based access control (RBAC) sayesinde ekiplerin yalnızca yetkili oldukları envanterlere ve job’lara erişebilmesi sağlanırken, inventory sync mekanizması ile sanallaştırma katmanındaki değişiklikler otomatik olarak envantere yansıtıldı. Job template kavramı ile sık kullanılan operasyonlar standartlaştırıldı ve kullanıcıların karmaşık playbook detaylarına hakim olmadan kontrollü işlemler yapabilmesi mümkün hâle geldi. Tüm bu süreçlerin loglar ile kayıt altına alınması ise izlenebilirlik ve denetim açısından önemli bir kazanım sundu.

Bu bütüncül yapı sayesinde AWX, bizim için yalnızca Ansible playbook’larının çalıştırıldığı bir job runner olmaktan çıktı; yetkilendirme, envanter, otomasyon ve denetimi tek noktada toplayan bir on-prem cloud kontrol paneli hâline geldi.

Self-Service Portal ve Standartlaşma

AWX ve Ansible birleşimi, cloud provider’lardan ilham aldığımız yönetim modeline yaklaşmamız için önemli bir adımdı. Bu sayede ekipler, ihtiyaç duydukları altyapı taleplerini doğrudan sanallaştırma platformuna erişmeden, aracı ekiplerle minimum iletişim kurarak bağımsız ve kontrollü bir arayüz üzerinden iletebilir hâle geldi. Bizim açımızdan ise bu talepler, belirlenmiş kurallar ve onay mekanizmaları çerçevesinde otomasyonlar tarafından karşılanan, izlenebilir ve denetlenebilir süreçlere dönüştü. Böylece gerçek anlamda bir Self-Service Portal yapısı ortaya çıktı.

Bu modelde self-service kavramını yalnızca “butona bas ve işlem yapılsın” seviyesinde ele almadık. Asıl hedefimiz; standart, öngörülebilir ve güvenli çıktılar üreten bir otomasyon sistemi kurmaktı. Örneğin bir ekip yeni bir sanal makine veya servis talep ettiğinde; bu işlemler her seferinde aynı naming convention’lara, aynı etiketleme şemasına, aynı disk ve ağ konfigürasyonlarına sahip olacak şekilde otomatik olarak gerçekleştiriliyor. Böylece kişiye veya ekibe göre değişen, ileride yönetilmesi zorlaşan özel konfigürasyonların önüne geçildi.

Standartlaşma yalnızca VM seviyesinde de kalmadı. Ortam türlerine (prod/dev), servis rollerine ve sahiplik bilgilerine göre zorunlu etiketler tanımlanarak; envanterin her zaman güncel, anlamlı ve otomasyonlar tarafından kolayca işlenebilir olması sağlandı. Bu sayede hangi kaynağın hangi ekibe ait olduğu, hangi ortamda çalıştığı ve ne çalıştırdığı net biçimde ayrıştırılabilir hâle geldi.

Operasyonel Kazanımlar ve Ölçülebilir Etkiler

Bu dönüşümün en net çıktıları, günlük operasyonlara doğrudan yansıyan kazanımlarla ortaya çıktı.

Self-service portal öncesinde snapshot alma veya silme gibi basit operasyonlar dahi ekiplerin ticket açmasını gerektiriyordu. Bugün ise yetkili kullanıcılar bu işlemleri doğrudan ve kontrollü şekilde kendileri gerçekleştirebiliyor. Bu durum ticket trafiğini ciddi ölçüde azaltırken, altyapı ekibinin tekrar eden işlerden arınmasını sağladı.

Benzer bir dönüşüm DNS yönetimi tarafında da yaşandı. Daha önce tamamen manuel yürütülen DNS açma ve silme işlemleri, artık otomasyonlar üzerinden self-service olarak yönetilebiliyor.

Yeni VM talepleri geçmişte ISO veya template üzerinden manuel klonlama, IP tanımlama ve teslim süreçleriyle ilerlerken; bugün Netbox gibi IPAM araçlarıyla entegre çalışan otomasyonlar sayesinde kullanıcılar ortam, kaynak, envanter ve işletim sistemi seçimini talep aşamasında yapabiliyor. Altyapı ekibine yalnızca uygunluk ve onay düşüyor; onay sonrasında VM otomatik olarak oluşturulup sahibine iletiliyor. VM talep süresi günlerden dakikalara indi.

Redis, RabbitMQ ve Kafka gibi servisler de geçmişte ekip bazlı, farklı versiyon ve kurulum yaklaşımlarıyla devreye alınırken; bugün host isimlendirmesinden kullanılan versiyonlara, konfigürasyondan monitoring entegrasyonlarına kadar tüm süreçler uçtan uca otomasyonlarla standart hâle getirildi. Bu sayede hem versiyon karmaşası ortadan kalktı hem de troubleshooting süresi ciddi ölçüde kısaldı.

Belki de en kritik kazanım; bu altyapının otomatik ve sürdürülebilir hâle gelmiş olmasıydı. İnsan bağımlılığının azalması, operasyonel devamlılığı ve ekip üzerindeki sürdürülebilirliği doğrudan artırdı.

Karşılaşılan Zorluklar ve Öğrenilen Dersler

Bu ölçekte bir dönüşüm, tek seferde kusursuz bir sistem kurmaktan çok; deneme, hata ve sürekli iyileştirme gerektiren bir süreçti. En önemli farkındalıklardan biri, her şeyi aynı anda otomasyona dökmenin pratikte mümkün olmadığıydı. Özellikle kritik operasyonlarda küçük bir varsayım hatasının dahi geniş etkilere yol açabildiğini deneyimledik.

Zamanla küçük başlayıp kontrollü şekilde büyümenin en sağlıklı yaklaşım olduğu ortaya çıktı. Önce düşük riskli operasyonlar otomasyon kapsamına alındı, ardından daha kritik süreçler aynı disiplinle sisteme dahil edildi. Bu yolculukta dokümantasyon, otomasyonların sürdürülebilirliği açısından en hayati unsurlardan biri oldu.

Bu süreç bize otomasyonun yalnızca teknik bir çözüm değil; doğru standartlar, kademeli ilerleme ve güçlü dokümantasyonla desteklenmesi gereken organizasyonel bir dönüşüm olduğunu net biçimde gösterdi.

Sonuç: Regülasyon Altında Cloud Mentalitesi

Türkiye’deki regülasyonlar ve veri yerleşimi gereksinimleri, kritik sistemlerin on-prem altyapılarda çalışmasını zorunlu kılıyor. Ancak bu zorunluluk, on-prem ortamların esnekliği sınırlı ve operasyonel olarak ağır yapılar olması gerektiği anlamına gelmiyor. Doğru mentalite ve doğru araçlarla, on-prem altyapıların cloud kadar çevik, güvenli ve ölçeklenebilir olabildiğini bu projeyle deneyimledik.

On-prem artık “mecburen yönetilen” bir yapı değil; bilinçli olarak optimize edilmiş, kontrollü ve sürdürülebilir bir platform hâline geldi. Asıl farkı yaratan unsurun kullanılan teknolojilerden çok, benimsenen işletim modeli olduğu netleşti.

Gelecekte Olmak İstediğimiz Nokta

Bugün ulaştığımız seviye bu yolculuğun sonu değil. Süreci statik bir proje olarak değil, yaşayan ve sürekli evrilen bir sistem olarak ele alıyoruz. Hedefimiz daha fazla otomasyon değil; doğru yerde, doğru ölçekte otomasyon.

Bu doğrultuda hangi işlere ne kadar zaman harcandığını, taleplerin ne sıklıkla geldiğini ve manuel müdahale gerektiren noktaları düzenli olarak analiz ediyoruz. Bu veriler, bir sonraki otomasyon adımını sezgisel değil, ölçülebilir ve veriye dayalı kararlarla belirlememizi sağlıyor.

Uzun vadede hedefimiz; altyapı ekibinin günlük operasyonlarla değil, altyapının nasıl daha güvenli, daha ölçeklenebilir ve daha verimli çalışabileceğiyle ilgilendiği bir çalışma modeli oluşturmak. On-prem ama cloud mentalitesiyle işletilen bir altyapıyı sürekli bir adım ileri taşımak.

Bu yazıda, genel mimarinin hangi ihtiyaçlardan doğduğunu ve bugün hangi yetkinliklere sahip olduğumuzu özetlemeye odaklandık; mimarinin nasıl hayata geçirildiğine dair teknik detaylara ise sonraki yazılarda değineceğiz.