Operasyonel Etki Analizi / 12 dk
Enerji Arızası Hangi Dijital Servisleri Etkiler? Octatus, Enlogy ve Argamos
Enerji/OT alarmından fiziksel varlığa, BT bağımlılığına ve servis etkisine uzanan teknik senaryo.

Alarm neden servis etkisi değildir?
UPS, PDU ve soğutma arızaları BT servislerini etkileyebilir; ancak her enerji alarmı otomatik servis kesintisi sayılmamalıdır.
Olay, bağımlılık ve gerçek servis sağlığı ayrı kanıtlarla ilişkilendirilmelidir.
Üç ürünün katkısı
Enlogy enerji ölçümü ve alarmı sağlar. Octatus fiziksel varlık konumunu ve birleşik görünümü sunar. Argamos CI, rack, sunucu, ağ ve servis bağımlılıklarını yönetir.
Octatus ana kullanıcı deneyimidir; uzmanlık ürünleri kendi yetkili kayıtlarını korur.
UPS senaryosu
Enlogy UPS anomalisini kaydeder. Octatus UPS'in konumunu ve bağlı panoları gösterir. Argamos eşlenmiş rack ve sunucular üzerinden risk altındaki servisleri belirlemeye yardımcı olur.
İş emri, atama, eskalasyon ve SLA süreçleri yetki ve insan onayıyla yürütülmelidir.
Kalite ve kabul
Eksik güç bağlantısı, eski rack kaydı, yanlış CI eşlemesi veya saat kayması yanlış etki haritası üretir. Kaynak ve güven düzeyi kullanıcıya gösterilmelidir.
UPS alarmı, yanlış eşleme, bağlantı kaybı, bakım penceresi, mükerrer olay ve tenant izolasyonu için test yapılmalıdır.
Sahadan örnek: karar anında hangi bilgi gerekir?
Bir enerji beslemesi arızalandığında hangi rack ve servislerin risk altında olduğunu bulmak için elektrik dağıtım topolojisi ile BT CI bağımlılıkları eşlenmelidir. Yedek güç yolu ve güncel ölçüm durumu değerlendirilmeden kesin kesinti ilan edilmemelidir.
Bir trafo fiderinin kesilmesi, fiziksel olarak bağlı panoları etkileyebilir; ancak hangi dijital servisin duracağı UPS ve ağ bağımlılıklarına göre değişir. Enlogy enerji olayını, Argamos BT servis grafını, Octatus fiziksel varlık bağlantısını sağlayabilir. Bilinmeyen ilişkiler kesin etki gibi sunulmaz.
Uygulama ve kabul kontrolü
Pilot testinde seçilmiş bir besleme noktasından etkilenen fiziksel varlıklar, olası BT servisleri, alarm kaynağı ve güven düzeyi izlenmelidir.
Pilot arıza testinde bir fider devre dışı senaryosu oluşturulur. Doğrulanmış pano ve rack bağlantıları izlenir; UPS yedekliliği varsa kesinti varsayımı ayrıca incelenir. Servis etkisi yalnızca güncel CMDB bağımlılıklarıyla hesaplanır.
Yatırım ve kapsam kararı nasıl verilir?
Enerji ve BT etki analizinin yatırım kararı için önce yedeklilik bilgisinin doğruluğu incelenmelidir. Bir fider kesintisi UPS üzerinden beslenen rack grubunda hemen servis kaybı yaratmayabilir. Model, doğrulanmış besleme yolları ile BT servis grafını ayırmalı; bilinmeyen ilişkileri kesin etki olarak sunmamalıdır. Pilot yanlış pozitif servis uyarısı ve olay inceleme süresi üzerinden değerlendirilmelidir.
Yatırım değerini ölçmek için yanlış etki bildirimi sayısı, olayın kök nedenine ulaşma süresi ve ekipler arası bilgi aktarımı izlenebilir. Topoloji verisinin bakımı ve BT bağımlılık keşfi ayrı maliyet kalemleridir. Otomatik müdahale için ek güvenlik değerlendirmesi gerekir.
Enerji alarmından iş hizmetine uzanan zincir
Bir UPS alarmı doğrudan uygulama kesintisi anlamına gelmez. Alarmın hangi elektriksel besleme yoluna ait olduğu, bu yolun hangi PDU ve raflara ulaştığı, raflardaki sunucuların hangi uygulamaları barındırdığı ve servislerin yedekli olup olmadığı bilinmelidir. Birleşik etki analizi bu bağlantıları doğrulanmış ilişki grafı üzerinde inceler. Fiziksel yakınlık tek başına elektriksel veya dijital bağımlılık kanıtı değildir.
Örneğin aynı odada bulunan iki raf farklı UPS hatlarından beslenebilir. Bir UPS kesildiğinde yalnızca o hatta bağımlı cihazlar risk altında olabilir. Ancak ortak soğutma veya ağ bağımlılığı ikinci rafı dolaylı etkileyebilir. Bu nedenle analiz yalnızca bir harita katmanına değil yönlü ve tipli ilişkilere dayanmalıdır.
Octatus, Enlogy ve Argamos arasındaki sınır
Octatus fiziksel varlıkların BIM/GIS konumunu ve teknik bağlamını, Enlogy enerji/OT ölçümlerini ve alarmlarını, Argamos BT yapılandırma öğeleri ile servis bağımlılıklarını temsil eden hedef mimari katmanları olarak konumlandırılabilir. Bu ayrım yetkili kaynakların korunmasını sağlar. Belirli entegrasyon ve otomasyonların üretimde hazır olduğu proje bazında doğrulanmalıdır. Birleşik ekran tek kontrol otoritesi olduğu anlamına gelmez.
Örneğin Enlogy tarafında ölçülen gerilim düşümü Octatus üzerindeki fiziksel pano ile eşlenebilir. Argamos ilişkileri üzerinden olası etkilenen servisler bulunabilir. Ancak enerji kesicisine komut gönderme yetkisi yetkili OT sisteminde kalmalıdır. Veri akışları ve güvenlik sınırları mimari sözleşmeyle tanımlanmalıdır.
Fiziksel varlık ve CI kimliklerini eşlemek
BIM nesnesinin IFC GlobalId değeri, asset ID, enerji analizörü tag adı, PDU seri numarası ve CMDB CI kimliği farklı kimliklerdir. Bunlar otomatik olarak eşit kabul edilmemelidir. Eşleme kaydı kaynak sistem, tenant, tesis, varlık türü, doğrulama zamanı ve sorumlu kişi içermelidir. Yanlış eşleme kritik servislerin yanlış risk altında gösterilmesine neden olabilir.
Örneğin PDU-A değiştirildiğinde fonksiyonel pozisyon korunabilir fakat seri numarası ve bakım geçmişi değişir. Eski cihazın olayları yeni cihaza yanlışlıkla aktarılmamalıdır. İlişki geçerlilik zamanları tutulmalıdır. Belirsiz eşlemeler kesin etki hesabından ayrılmalıdır.
İlişki türleri ve graf yönü
Birleşik graf 'located in', 'powered by', 'connected to', 'hosts', 'depends on' ve 'cooled by' gibi farklı ilişki türlerini desteklemelidir. Bunların hepsini genel bağlı ilişkisine indirgemek etki analizini bozabilir. Her ilişkinin yönü, kaynağı ve geçerlilik tarihi bilinmelidir. Aynı ekipman birden fazla güç veya ağ yoluna sahip olabilir.
Örneğin UPS-A bir PDU'yu beslerken PDU bir rafa bağlı olabilir. Sunucu o rafta bulunur ama aynı zamanda ikinci PDU üzerinden de beslenebilir. Uygulama sunucuda çalışırken yedek kopyası başka kümede bulunabilir. Etki hesabı bu alternatif yolları dikkate almalıdır.
Yedeklilik ve tek hata noktası
Bir ekipmanın arızası, yedek besleme veya hizmet kopyası varsa otomatik kesinti yaratmayabilir. Analiz tek hata noktalarını ve alternatif yolları ayrı göstermelidir. Ancak yedek yolun varlığı yeterli değildir; kapasite, gerçek çalışma durumu ve geçiş mekanizması da önemlidir. Bu bilgiler bilinmiyorsa kesin hizmet sürekliliği iddiası kurulamaz.
Örneğin çift güç kaynaklı bir sunucu iki PDU'ya bağlı olabilir. PDU-A kaybında PDU-B çalışıyorsa sunucu hizmet vermeye devam edebilir. Fakat PDU-B aşırı yüklenmişse risk sürer. Sistem doğrulanmış kesinti ile olası risk seviyesini ayırmalıdır.
Gerçek zamanlı durum ve statik topoloji
BIM ve CMDB ilişkileri fiziksel veya mantıksal yapıyı tanımlar; telemetri ise belirli bir andaki durumu bildirir. Statik topoloji güncel değilse canlı ölçüm doğru olsa bile etki analizi yanlış çıkabilir. Bu nedenle ilişki grafının doğrulama tarihi ile ölçüm zaman damgası ayrı gösterilmelidir. İki veri türü farklı güncelleme sıklıklarına sahiptir.
Örneğin geçen hafta başka rafa taşınan sunucunun CMDB kaydı güncellenmemişse UPS alarmı yanlış servis listesi üretebilir. Sistem bu belirsizliği raporlamalıdır. Geçmiş olay analizi yapılırken olay anında geçerli ilişki sürümü kullanılmalıdır. Güncel topolojiyi geçmişe uygulamak hatalı kök neden analizi doğurabilir.
Enerji telemetrisinde kalite ve gecikme
Gerilim, akım, aktif güç ve kesici durumları farklı cihazlardan farklı aralıklarla gelebilir. Ölçümün olay zamanı, alınma zamanı, birimi, kaynağı ve kalite kodu korunmalıdır. İletişim kesintisinde son değer canlıymış gibi gösterilmemelidir. Gerçek sıfır ölçümü ile eksik veri farklı durumdur.
Örneğin PDU akım verisi on dakika önce geldiyse o değerle kesin anlık kapasite hesabı yapılmamalıdır. Geç gelen mesajlar yeni alarm gibi yorumlanmamalıdır. Kalite seviyesi düşükken otomatik yüksek öncelikli olay açılması kısıtlanabilir. Kullanıcı hangi verinin tahmin olduğunu görebilmelidir.
UPS ve PDU alarm korelasyonu
Bir UPS arızası birden fazla PDU, sunucu ve ağ cihazından alarm üretebilir. Aynı kök nedene ait olaylar korelasyonla gruplanabilir. Ancak yalnızca zaman yakınlığına göre bütün alarmları birleştirmek yanlış olur. Varlık ilişkileri, enerji yolu ve ölçüm kalitesi korelasyon gerekçesini oluşturmalıdır.
Örneğin UPS-A kaybından sonra PDU-A1 ve PDU-A2 uyarıları geliyorsa ortak neden düşünülebilir. Farklı UPS üzerindeki PDU-B alarmı yalnızca eşzamanlı olduğu için aynı olaya bağlanmamalıdır. Operatör korelasyon kararını inceleyebilmeli ve gerektiğinde ayırabilmelidir. Mükerrer mesajlar ayrı ITSM bileti oluşturmamalıdır.
Servis etki puanı ve önceliklendirme
Bir fiziksel alarmın şiddeti ile iş hizmetinin etkisi farklıdır. Önceliklendirme etkilenen servisin kritiklik seviyesi, yedeklilik, kullanıcı etkisi, sözleşmesel SLA ve doğrulanmış kesinti durumunu dikkate almalıdır. Aynı PDU alarmı test laboratuvarında düşük, canlı işlem merkezinde yüksek öncelik taşıyabilir. Bu ayrım kurumsal politika ile tanımlanmalıdır.
Örneğin tek PDU kaybı çift beslemeli sunucuda risk artışı yaratırken tek beslemeli cihazda doğrudan kesinti oluşturabilir. İş hizmeti birden fazla sunucuya dağıtılmışsa uygulama ayakta kalabilir. Etki puanı varsayımlarını ve veri kaynaklarını açıklamalıdır. Belirsiz ilişkiler kesin etki gibi sunulmamalıdır.
ITSM olay ve iş emri yaşam döngüsü
Enerji alarmının temizlenmesi ITSM olayının otomatik kapandığı anlamına gelmez. Fiziksel arıza giderilmiş olsa da servis doğrulaması, kök neden analizi veya bakım raporu tamamlanmamış olabilir. Alarm durumu, olay çözümü ve iş emri kapanışı ayrı yönetilmelidir. Otomatik iş akışları yetki ve onay kurallarıyla sınırlandırılmalıdır.
Örneğin UPS normal duruma döndükten sonra akü sağlığı kontrolü beklenebilir. ITSM olayı doğrulama aşamasında kalabilir. Aynı alarm yeniden gönderildiğinde ikinci iş emri oluşmamalıdır. Biletin hangi varlık ve servis ilişkilerinden türetildiği denetlenebilir olmalıdır.
SLA, bildirim ve servis sahibi eşlemesi
Enerji arızasının etkilediği iş hizmetleri belirlendiğinde servis sahipleri ve nöbetçi ekipler bilgilendirilebilir. Ancak yanlış ilişki yüzünden hassas topoloji bilgisi ilgisiz kişilere gönderilmemelidir. Bildirimler rol bazlı ve içerik sınıflandırmasına uygun olmalıdır. SLA saati olayın algılanması, bilet açılması ve hizmetin geri gelmesi gibi farklı zamanları ayırmalıdır.
Örneğin planlı UPS bakımı öncesi ilgili servis sahiplerine bilgilendirme yapılabilir. Bakım penceresi dışında devam eden arıza normal eskalasyon sürecine alınmalıdır. Yanıt alınmadığında kademeli bildirim kuralları çalışabilir. Mükerrer bildirim ve yanlış hedef sorunları pilotta test edilmelidir.
Soğutma arızasıyla çapraz etki analizi
Enerji ve BT etki analizi yalnızca elektrik beslemesini kapsamaz. Soğutma sistemlerinin kaybı belirli rafların sıcaklık riskini artırabilir. Ancak aynı odada bulunmak bütün sunucuların eşit etkileneceği anlamına gelmez. Soğutma zonları, hava akışı, sensör konumu ve yedek kapasite değerlendirilmelidir.
Örneğin CRAC-03 arızasında ilgili sıcaklık sensörleri ve raflar üzerinden risk hesaplanabilir. Ölçüm kalitesi veya zon ilişkisi belirsizse kesin kesinti sonucu verilmemelidir. Enerji ve soğutma bağımlılıkları ayrı ilişki türleri olarak tutulmalıdır. Böylece operatör hangi senaryonun hangi altyapı yolundan kaynaklandığını anlayabilir.
Graf sorguları ve performans sınırları
Büyük tesislerde fiziksel ve dijital varlık ilişkileri çok sayıda düğüm ve kenar oluşturabilir. Etki sorgusu belirli bir arızadan başlayıp ilgili besleme, barındırma ve servis bağımlılıklarını izlemelidir. Sorgu derinliği, döngü algılama, indeksleme ve önbellek stratejisi tanımlanmalıdır. Ön belleğin güncellik süresi de operatöre açıklanmalıdır.
Örneğin bir UPS arızası için üç aşamalı sorgu ile bütün portföyde sınırsız gezinme farklı performans maliyetine sahiptir. Sorgu yanıt süresi gerçek veri büyüklüğünde ölçülmelidir. Kısmi sonuç oluşursa kullanıcıya bildirilmelidir. Döngüsel ilişkiler sonsuz sorgu üretmemelidir.
Tenant izolasyonu ve kritik altyapı güvenliği
Birleşik ilişki grafı enerji topolojisiyle iş hizmetleri arasındaki hassas bağlantıları açığa çıkarabilir. Bu nedenle yalnızca düğüm erişimi değil ilişki erişimi de yetkilendirilmelidir. API, arama, rapor ve dışa aktarım yollarında tenant sınırları korunmalıdır. Görüntüleme yetkisi OT kontrol komutu verme yetkisine dönüşmemelidir.
Kabul testinde bir tenant kullanıcısı başka tenantın PDU kimliğiyle sorgu yapar ve erişimin reddedildiği doğrulanır. Ayrı testte görüntüleme rolü enerji kesicisine komut gönderemez. Denetim kayıtları kritik sorgu ve yetki değişikliklerini izlemelidir. Arayüzde düğme gizlemek tek başına güvenlik kontrolü değildir.
İlk pilot: tek UPS, iki PDU, üç servis
Pilot kapsamı sınırlı ama uçtan uca seçilmelidir. Bir UPS, iki PDU, birkaç raf, fiziksel sunucular ve üç iş hizmeti yeterli olabilir. Önce saha besleme ilişkileri ve CMDB servis bağımlılıkları doğrulanır. Ardından kontrollü alarm üretilir ve olası etki yolu görüntülenir. Gerçek kontrol komutu verilmeden simüle edilmiş olayla da ilk kabul yapılabilir.
İkinci testte yedek enerji hattı devreye alınmış varsayılır ve sonuç değişimi incelenir. Üçüncü testte yanlış raf eşlemesi eklenerek sistemin belirsizliği işaretlemesi beklenir. Dördüncü testte gecikmiş telemetri gönderilir. Her testin beklenen sonucu ve kanıtı önceden yazılmalıdır.
Negatif testler ve koşullu kabul
Başarılı normal senaryo tek başına yeterli değildir. Mükerrer alarm, eski ölçüm, yanlış CI eşlemesi, silinmiş varlık, yetkisiz sorgu ve bağlantı kesintisi gibi negatif senaryolar çalıştırılmalıdır. Bir sistemin yanlış sonuç vermek yerine belirsizliği göstermesi bazı durumlarda daha güvenlidir. Kritik yanlış servis etkisi veya veri sızıntısı bulgusu açıkken koşulsuz kabul verilmemelidir.
Örneğin geçici ağ kesintisinde edge tamponundan gelen eski alarm yeni kesinti gibi yorumlanmamalıdır. Silinen CI kaydı tarihsel olaylardan tamamen kaybolmamalıdır. Mükerrer olay aynı korelasyon kimliğiyle işlenmelidir. Düzeltme sonrası aynı testler tekrar çalıştırılmalıdır.
İşletme sorumlulukları ve değişiklik kontrolü
Tesis ekibi elektriksel besleme yollarını, OT ekibi ölçüm ve kontrol sınırlarını, BT ekibi CI ve servis ilişkilerini doğrulayabilir. Bilgi güvenliği erişim ve ağ politikalarını denetler. Entegrasyon ekibi kimlik eşleme ve olay sözleşmelerini yönetir. Bu roller kurumun yapısına göre uyarlanmalıdır. Tek bir ekip bütün alanların veri doğruluğunu üstlenmemelidir.
Örneğin sunucu başka rafa taşındığında yeni PDU ve ağ bağlantıları doğrulanmalıdır. UPS değişiminde seri numarası ve fonksiyonel pozisyon ayrılmalıdır. Değişiklik kaydı ilgili ilişki grafı güncellemelerini tetiklemelidir. Uyuşmazlıklar sorumlu ekibin inceleme kuyruğuna düşmelidir.
Fayda ölçümü ve yaygınlaştırma kararı
Birleşik etki analizinin maliyeti yazılım geliştirmesi dışında saha doğrulaması, CMDB temizliği, telemetri entegrasyonu, güvenlik, eğitim ve bakım giderlerini içerir. İlk aşamada kritik servisleri kapsayan küçük pilot tercih edilebilir. Böylece gerçek veriyle yanlış pozitif ve eksik ilişki sorunları görülür. Yaygınlaştırma kararı yalnızca güzel bir görselleştirmeye dayanmaz.
Başarı göstergeleri doğru servis eşleme oranı, yanlış alarm korelasyonu, olay inceleme süresi, veri güncelliği ve operatör görev tamamlama süresi olabilir. Başlangıç ölçümleriyle karşılaştırma yapılmalıdır. Olası kesintilerin önlenmesi gerçekleşmiş tasarruf gibi sunulmamalıdır. İşletme sorumluluğu ve veri taşınabilirliği sözleşmede açıklanmalıdır.
Karar destek ekranında gösterilecek kanıtlar
Operatör bir enerji alarmına tıkladığında fiziksel varlık konumunu, son ölçüm zamanını, kalite kodunu, etkilenen PDU ve rafları, olası servis listesini ve ilişki yollarını görebilmelidir. Her bağlantının hangi kaynaktan geldiği ve ne zaman doğrulandığı açılabilmelidir. Kesin kesinti ile olası risk farklı biçimde sunulmalıdır. Bu yaklaşım kararın gerekçesini görünür kılar.
Yanlış eşleme fark edildiğinde kullanıcı ilgili veri sahibine düzeltme talebi gönderebilmelidir. İlişki düzeltildikten sonra etki sorgusu yeniden çalıştırılmalıdır. Olay geçmişindeki eski sonuçlar denetim için korunabilir. Böylece sistem yalnızca bir alarm panosu değil sürdürülebilir karar destek aracı olur.
Teknik şartname ve veri sözleşmesi
Birleşik etki analizi için teknik şartname düğüm ve ilişki türlerini, yetkili kaynakları, kimlik eşleme yöntemini, olay zamanını, kalite kodunu ve sorgu yanıt süresi hedeflerini tanımlamalıdır. Her ilişki için kanıt ve geçerlilik aralığı saklanmalıdır. API ve arayüz aynı tenant yetkilerini uygulamalıdır. Eksik veri olduğunda kesin sonuç yerine açık belirsizlik durumu dönülmelidir.
Kabul testinde bir UPS alarmının doğru PDU, raf, sunucu ve servis yolunu izlediği doğrulanabilir. Yanlış eşleme, ikinci güç hattı, gecikmiş ölçüm ve tenant dışı sorgu ayrı senaryolar olmalıdır. Başarılı API yanıtı tek başına doğru iş etkisi kanıtı sayılmamalıdır. Sonuçlar saha ve servis sahipleri tarafından birlikte onaylanmalıdır.
Bu ortak onay işletme güvenilirliği için kritik bir karar kapısıdır.
Kanıtlar saklanmalı ve izlenebilir olmalıdır.
UPS bulunan bir veri merkezinde şebeke fiderinin kesilmesi anında servis kaybı anlamına gelmeyebilir. Etki grafı yedeklilik, akü özerkliği ve geçiş durumunu ancak doğrulanmış verilerle hesaba katabilir. Bu alanlar bilinmiyorsa sistem olası risk bildirir; kesin kesinti süresi üretmez. Operatörün kararını desteklemek için fiziksel bağlantı kanıtı ve servis bağımlılığı ayrı gösterilir.
Not: Teknik standartlara ilişkin açıklamalar bilgilendirme amaçlıdır. Ürün yetenekleri ve entegrasyon kapsamı proje bazında doğrulanmalıdır.