Homelab genişlemesi, çoğu teknoloji meraklısı gibi benim için de başlangıçta heyecan verici bir serüvendi. Yeni teknolojileri denemek, farklı sistem mimarilerini kurcalamak ve üretim ortamlarında “elleyemediğim” şeyleri kendi evimde uygulamak paha biçilmez bir öğrenme alanı sağlıyordu. Ancak zamanla bu büyüyen lab, beklediğimden çok daha büyük bir bakım yükü ve kişisel zaman maliyeti getirdi; bu durum, hobinin işe dönüştüğü o ince çizgiyi bana defalarca hatırlattı.
İlk başta sadece birkaç Raspberry Pi ile başlayan bu süreç, zamanla rafları dolduran sunuculara, gigabit switch’lere ve karmaşık ağ topolojilerine dönüştü. Her eklenen yeni cihaz veya servis, beraberinde yeni bir sorumluluk ve potansiyel bir sorun kaynağı getirdi. Bu yazıda, homelab’in cazibesinden, zamanla nasıl bir bakım yüküne dönüştüğünden ve bu süreçte çıkardığım derslerden bahsedeceğim.
Homelab’in Büyüme Başlangıcı: Neden Başladık ve Nasıl Kaptırdık?
Benim homelab serüvenim, 2000’lerin başındaki mütevazı bir Linux sunucu denemesiyle başladı, ancak gerçek ivmeyi son 10 yılda kazandı. Üretim ortamlarında uyguladığım veya uygulamak istediğim ama zaman bulamadığım birçok konsepti burada deneme fırsatı buldum. Yeni bir veritabanı denemek, farklı bir container orkestrasyon aracı kurmak ya da sadece bir sistemin performansını uç noktalara kadar zorlamak gibi motivasyonlarım vardı. Bu, hem bir öğrenme aracı hem de bir stres atma yöntemiydi benim için.
Başlangıçta her şey basit ve düşük maliyetli görünüyordu. Tek bir mini PC üzerinde Docker Compose ile birkaç servis çalıştırmak, Raspberry Pi ile bir monitoring sistemi kurmak gibi projelerle başladım. “Biraz daha RAM”, “daha hızlı bir SSD”, “bir de 10Gbit switch olsa” derken, donanım listesi uzamaya, elektrik faturası da yavaş yavaş kabarmaya başladı. Bu süreçte, kendi yan ürünlerimden birinin (bir finansal hesaplayıcı backend’i) test ortamını da homelab’ime taşıdım. Bu, başlangıçta maliyet avantajı sağlasa da, zamanla bakım yükünü artırdı.
Beklenmedik Maliyetler: Para ve Zaman Dengesi Nasıl Değişiyor?
Homelab genişlemesinin en sinsi maliyeti, sadece donanım alırken ödediğimiz para değil, aynı zamanda harcadığımız zaman ve elektrik faturasıydı. İlk başta “bir heves” gibi görünen bu yatırımlar, zamanla ciddi bir bütçe kalemi haline gelebiliyor. Birkaç yıl içinde topladığım sunucular, switch’ler ve diskler için harcadığım para, iyi bir ikinci el otomobil fiyatına yaklaştı diyebilirim. Ama asıl sorun bu değildi.
Örneğin, 7/24 çalışan bir sunucu grubunun elektrik tüketimi, aylık faturada gözle görülür bir fark yaratıyor. Başlangıçta 50W çeken bir sistemden, şimdi 300-400W çeken bir yapıya geçtim. Bu, sadece elektrik faturasında değil, aynı zamanda soğutma ihtiyacında ve odanın sıcaklığında da kendini gösteriyor. Ancak paranın ötesinde, en büyük bedel zamandı. Bir pazar sabahı, kahvaltı yerine kritik bir servisin downtime’ını gidermek için 4 saat harcadığımı bilirim. Bu, hobinin işe dönüştüğü ve kişisel hayatın ihmal edildiği anlardan sadece biriydi.
Yazılım ve Konfigürasyon Karmaşası: Tech Debt Evde de mi Var?
Kurumsal ortamlarda “tech debt” diye dert yandığımız şey, homelab’de de peşimizi bırakmıyor. Farklı dağıtımlar (Ubuntu, Debian, Fedora), çeşitli servisler (PostgreSQL, Redis, Nginx), ve birbiriyle konuşan onlarca container… Her birinin kendine ait konfigürasyon dosyaları, güncelleme döngüleri ve bağımlılıkları var. Başlangıçta her şeyi manuel kurdum, “küçük bir lab zaten” diye düşündüm. Ancak bu yaklaşım, sistem büyüdükçe bir kabusa dönüştü.
Bir noktada, bir PostgreSQL major versiyon güncellemesi yaptığımda, eski bir uygulamanın veritabanı schema’sıyla uyumsuzluk yaşadım. Yeni versiyonun bazı sorgu planlama davranışları değişmişti ve uygulamanın ORM’i bu duruma adapte olamadı. Debug etmek 8 saatimi aldı ve bu süreçte pg_upgrade komutuyla uğraşırken kalıcı bir veri kaybı riskini de göze aldım. Bu gibi durumlar, manuel konfigürasyon yönetiminin ne kadar kırılgan olduğunu gösterdi. Şimdi en azından bazı kritik servisler için basit Ansible playbook’ları kullanmaya çalışıyorum, ancak bu bile tam otomatize bir çözüm değil.
-- PostgreSQL'de eski bir sorgu planının neden yavaşladığını anlamak için EXPLAIN ANALYZE çıktısı
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123 AND order_date > '2026-01-01';Ağ ve Güvenlik Zorlukları: Evdeki “Mini-Kurumsal” Ortam
Homelab genişledikçe, ağ yapısı da kaçınılmaz olarak karmaşıklaşıyor. Başlangıçta tek bir modemden çıkan Wi-Fi ile idare ederken, şimdi farklı VLAN’lar, firewall kuralları, VPN tünelleri ve birden fazla gigabit switch kullanıyorum. Bu yapı, hem daha güvenli hem de daha performanslı bir ortam sağlıyor, ancak beraberinde ciddi bir yönetim yükü getiriyor. IP çakışmaları, DNS çözümleme sorunları ve hatalı firewall kuralları, sıkça karşılaştığım problemlerden.
Bir keresinde, yeni bir IP kamera sistemi eklemek için ağa bir PoE switch bağladım. Ancak bu switch’i yanlış bir port’a bağladığımda, ağda bir loop oluştu ve tüm ev ağı çöktü. DHCP server’ım da bu durumdan etkilendiği için hiçbir cihaza IP ataması yapılamadı. Sorunu bulmak ve çözmek için fiziksel bağlantıları tek tek kontrol etmem gerekti. Bu tip durumlar, kurumsal network’lerde karşılaştığımız “switch loop” veya “broadcast storm” senaryolarını evimde yaşamama neden oldu. Network segmentasyonu (VLAN’lar aracılığıyla) iyi bir güvenlik pratiği olsa da, her yeni cihazı doğru VLAN’a atamak ve aralarındaki iletişimi doğru firewall kurallarıyla sağlamak sürekli bir dikkat gerektiriyor.
Monitöring ve Uyarılar: Prod Ortamı Disiplini Evde Ne Kadar Gerekli?
Profesyonel hayatta observability’nin (metrik, log, trace) önemini her zaman vurgularım. Ancak bu disiplini homelab’e taşımak, bazen hobinin keyfini kaçırabiliyor. Başlangıçta sadece htop ile CPU kullanımına bakarken, zamanla Prometheus, Grafana ve Alertmanager gibi araçları kurdum. Bu sistemler, sunucuların kaynak kullanımını, servislerin durumunu ve ağ trafiğini detaylı bir şekilde izlememi sağlıyor.
Fakat bu durum, beraberinde “alarm gürültüsü” sorununu da getirdi. Bir container’ın memory.high limitini aşması ve OOM-killed olması alarmının gece 3’te düşmesi, artık sadece bir hobi projesiyle uğraşmadığımı gösteriyordu. Journald loglarını Elasticsearch’e göndermek ve Kibana’da analiz etmek gibi karmaşık çözümlerle uğraşırken, aslında sadece evdeki bir Plex sunucusunun takılmamasını istediğimi hatırladım. Bu, “prod ortamı disiplinini” eve taşımanın getirdiği bir yük. Her bir uyarı kuralını ince ayar yapmak, false positive’leri elemek ve gerçekten önemli olanları ayırt etmek ciddi zamanımı alıyor.
# Bir container'ın memory limit'ini aştığını gösteren systemd log çıktısı örneği
# journalctl -u docker.service -f
...
Jun 18 03:14:22 homelab-server kernel: cgroup: "memory" controller: memory.high limit of 500M reached for container_name.service, currently 512M
Jun 18 03:14:22 homelab-server kernel: Memory cgroup out of memory: Killed process 1234 (container_name.service) total-vm:1024MB, anon-rss:512MB, file-rss:0MB, shmem-rss:0MBBu tarz bir çıktıyı gördüğümde, hemen cgroup memory.high ayarlarımı gözden geçirip, uygulamanın gerçekten bu kadar belleğe ihtiyaç duyup duymadığını analiz etmem gerekiyor. Bazen basit bir Redis OOM eviction policy ayarı bile saatler süren bir debug sürecini tetikleyebiliyor.
Kişisel Hayat ve Homelab Dengesi: Nerede Dur Demeli?
Sanırım homelab genişlemesinin getirdiği en büyük ders, hobinin ne zaman işe dönüştüğünü fark etmek ve dengeyi kurabilmek oldu. Başlangıçtaki öğrenme ve keşfetme motivasyonu, zamanla bir “yapılması gerekenler” listesine dönüştü. “Şu güncellemeyi yapmalıyım,” “o servisi optimize etmeliyim,” “disk alanı dolmadan yeni bir depolama çözümü kurmalıyım” gibi düşünceler, zihnimde sürekli bir yer kaplamaya başladı. Bu durum, eş ve ailemle geçirmem gereken zamanlardan çalmaya başladı.
Bir cumartesi öğleden sonra, çocuklarımla parkta olmak yerine, bir yan ürünümün backend’inde yaşanan bir performans regresyonunu debug ederken buldum kendimi. Postgres’in index stratejilerinden birindeki yanlış seçim (BRIN yerine B-tree’nin daha uygun olduğu bir tablo), sorguların aniden yavaşlamasına neden olmuştu. Bu, “sadece bir dakika daha” diyerek ekran başında geçen saatlerin, aslında benden çok daha değerli şeyleri alıp götürdüğünü gösterdi. Bilinçli sınırlar koymak ve “hayır, bu hafta sonu sadece dinleneceğim” diyebilmek, bu sürecin en zor ama en önemli kısmı oldu. Deneyimim gösterdi ki, bu tarz kararlar, genel yaşam kalitemi doğrudan etkiliyor.
Sonuç: Homelab Bir Yolculuktur, Bir Yarış Değil
Homelab genişlemesi, teknolojiye olan tutkumu besleyen, beni sürekli yeni şeyler öğrenmeye iten harika bir yolculuk. Ancak bu yolculukta, “daha fazla” her zaman “daha iyi” anlamına gelmiyor. Ulaşmaya çalıştığım performans ve özellikler, çoğu zaman getirdiği bakım yükünü ve kişisel zaman maliyetini haklı çıkarmıyor. Bu dengeyi bulmak, sürekli bir çaba ve farkındalık gerektiriyor.
Şu anki net pozisyonum, yeni donanım alımlarını ve yeni servis kurulumlarını ciddi şekilde kısıtlamak yönünde. Var olan sistemleri konsolide etmek, otomasyon seviyesini artırmak (daha fazla Ansible!) ve en önemlisi, homelab’i tekrar bir “hobi” olmaktan çıkarıp, bir “iş” haline getirmemeye çalışıyorum. Çünkü bazen en iyi optimizasyon, sistemi hiç kurmamaktır. Bir sonraki yazıda, bu konsolidasyon sürecinde kullandığım bazı stratejileri ve araçları anlatacağım.