Envanter kalemi tek başına etkiyi açıklamaz
Bir switch, sunucu veya sanal makine kaydı ancak ilişkileri bilindiğinde operasyon kararına katkı sağlar. Kullanıcının yaşadığı sorun uygulama seviyesinde görünür; neden ise depolama, fiziksel ağ veya ortak bir altyapı hizmetinde olabilir. Bu yazıda önerilen model, iş hizmetinden başlayıp uygulama ve çalışma ortamı üzerinden fiziksel kaynaklara iner. Aynı model bakım planlamasında ters yönde kullanılır: değişecek cihazdan başlayarak değerlendirilmesi gereken hizmetler bulunur. Her iki yönde de ilişkinin kaynağı ve güncelliği önemlidir.
Tek bir ağaç yerine farklı ilişki türleri kullanın
Bir varlık aynı anda birden fazla sisteme bağlı olabilir. Uygulama veritabanını kullanır, VM üzerinde çalışır ve bir ekibin sorumluluğundadır. Bu üç ilişki aynı anlama gelmez. İçerir, üzerinde çalışır, veri kullanır, ağ erişimine ihtiyaç duyar ve sahibi farklı ilişki türleridir. Modeli tek bir klasör ağacına sıkıştırmak ortak bağımlılıkları kaybettirir. İlişkilerin yönünü de açık tanımlayın: uygulamanın veritabanına bağımlı olması, veritabanının yalnızca o uygulamaya hizmet verdiği anlamına gelmez.
Uygulamanın içindeki sistemleri ayrı görünür kılın
Bir iş hizmeti web ön yüzü, API, veritabanı, mesaj kuyruğu ve zamanlanmış görevlerden oluşabilir. Ayrıca DNS, kimlik sağlayıcısı, sertifika veya haricî API gibi bağımlılıkları bulunabilir. Bunların hepsi bir VM envanterinde doğrudan görülmez. Uygulama sahibinin onayladığı yapılandırma ve uygun teknik gözlemler birlikte kullanılmalıdır. Her çalışan süreç için kurumsal varlık açmak yerine işletim açısından anlamlı bileşenleri seçin. Sahiplik, kritiklik ve bağımlılık türü belli olmayan binlerce kayıt karar vermeyi kolaylaştırmaz.
Sanal katmandan gerçek donanıma inin
Kubernetes node’u bir VM ise önce bu eşleşme, sonra VM’nin hypervisor host’u doğrulanır. Host’un fiziksel sunucu kimliği, seri numarası, lokasyonu ve kabin konumu ayrı tutulur. Bare-metal node için VM katmanı bulunmaz. Birbirine benzeyen adlar veya aynı IP adresi, tek başına güvenilir eşleştirme değildir. Kaynak kimliği ve doğrulanmış teknik tanımlayıcılar önceliklidir. Birden fazla kaynak çeliştiğinde belirsizliği saklamak yerine inceleme kaydı oluşturmak, yanlış bir bağımlılık haritasından daha değerlidir.
Ağ ve storage yolları neden ayrı incelenmeli?
Sunucunun ağ kartı, bond veya uplink, fiziksel switch portu, VLAN ve ağ geçidi bir erişim yolunun parçaları olabilir. Depolama erişimi ise farklı bir ağ veya fabric kullanabilir. Bir uygulamanın kullanıcı trafiği sağlıklıyken storage yolu sorun yaşayabilir. Bu nedenle yalnızca kablo var bağlantısını hizmet çalışıyor sonucuna çevirmeyin. Fiziksel topoloji, mantıksal ağ, erişim politikası ve gözlenen erişilebilirlik farklı katmanlardır. Her katmanda kullanılan veri kaynağı, kapsam ve gözlem zamanı belli olmalıdır.
Her ilişkinin bir kanıtı ve geçerlilik zamanı olsun
Önerilen ilişki kaydı; başlangıç varlığı, hedef varlık, ilişki türü, kaynak, gözlem zamanı ve doğrulama durumunu içerir. API’den doğrudan okunan konum bilgisi ile ekip tarafından onaylanan uygulama bağımlılığı farklı kaynak türleridir. Trafik gözleminden türetilmiş bir ilişki ise gözlem aralığına bağlıdır ve tüm iş bağımlılıklarını açıklamayabilir. Veri toplama kesildiğinde son bilinen bilgiyi güncelmiş gibi göstermeyin. Bilinmiyor, doğrulanmış ve güncelliği şüpheli durumlarının ayrılması etki analizinin güvenilirliğini artırır.
Örnek: switch bakımı için etki incelemesi
Örnek bir erişim switch’inde bakım planlandığında önce bağlı fiziksel portları ve host’ları belirleyin. Sonra bu host’lardaki VM veya node’ları, üzerlerindeki iş yüklerini ve ilişkili hizmetleri inceleyin. Alternatif uplink veya başka replika varsa gerçekten bağımsız bir yol sağlayıp sağlamadığını doğrulayın. İki kablonun aynı switch’e veya aynı güç alanına gitmesi beklenen ayrışmayı sağlamayabilir. Elde edilen liste kesin kesilecek hizmetler değil, teknik ve operasyonel olarak değerlendirilmesi gereken potansiyel etki kapsamıdır.
CMDB, metrik ve olay verisi birlikte nasıl okunur?
CMDB varlıkların ve ilişkilerin bağlamını sağlar; metrikler belirli zamanlardaki davranışı, olaylar ise durum değişikliklerini gösterir. Aynı dakikada oluşan iki alarm tek başına neden-sonuç ilişkisi kanıtlamaz. Ortak altyapı bağımlılığı bu alarmları birlikte incelemek için güçlü bir gerekçe olabilir. Kapasite, gecikme, hata oranı ve hizmet kontrolleri uygun zaman aralığında karşılaştırılmalıdır. Argamos’u değerlendirirken haritanın yalnızca görsel olarak zenginliğini değil, incident kaydına doğru varlık ve hizmet bağlamı sağlayıp sağlamadığını inceleyin.
Argamos ile ilk kapsamı bir kritik hizmette kurun
Argamos kaynak gözlemlerini, yönetilen varlıkları, sahipliği ve hizmet ilişkilerini ortak operasyon bağlamında buluşturur. İlk çalışmada bir kritik hizmet seçin; uygulama bileşenlerini, çalışma ortamını ve bilinen fiziksel bağımlılıklarını doğrulayın. Kaynak erişimi atanmış Edge Runtime üzerinden yürür; merkez kapsam ve periyotları yönetir. Kullanılan kaynakların API ve yetki sınırlarını açıkça kaydedin. Hedef her ilişkiyi otomatik keşfetme vaadi değil, bakım ve incident değerlendirmesinde güvenle kullanılabilecek, eksikleri görünür bir envanter oluşturmaktır.
Envanter modeli: hızlı başvuru
| Katman / kayıt | Tutulacak bilgi | Operasyonel anlam |
|---|---|---|
| İş ve uygulama | Hizmet → uygulama → API / veritabanı / kuyruk | Hizmet sahibince doğrulanmış bağımlılıklar |
| Çalışma ortamı | Workload → node veya uygulama → VM | Platform API’sindeki gözlem ve kimlik eşlemesi |
| Fiziksel katman | VM → host → fiziksel sunucu → kabin | Sanallaştırma ve donanım envanteri |
| Erişim ve veri | NIC/uplink → switch; volume → storage | Ağ/storage kaynağı ve onaylı bağlantı kayıtları |
Teknik kaynaklar
Platform kavramları için resmî dokümantasyon. Kurulumunuzun sürümü ve erişim kapsamıyla birlikte değerlendirin.