Bir veri alanı, bir yazılım sistemindeki en küçük anlam birimlerinden biridir ve buna rağmen, bir işletme genelinde izini sürmek, bir geliştirici, analist veya uyumluluk görevlisinden istenebilecek en zor işlerden biridir. customer_id Bir yerde tanım olarak mevcuttur. Bir veya daha fazla tabloda saklanır. Programlar tarafından okunur, servisler arasında aktarılır, ETL işleri tarafından dönüştürülür, iş kuralları tarafından doğrulanır ve sonunda raporlarda, gösterge panolarında veya tamamen diğer sistemler tarafından tüketilen API yanıtlarında görüntülenir. Bu alanın nereden geldiği, nereye gittiği ve arada başına ne geldiği sorusu bir dokümantasyon sorusu veya mimari sorusu değildir. Bu, çalışan bir kurumsal sistemin gerçek kodu, gerçek verileri ve gerçek yürütme yolları hakkında canlı bir sorudur. Bunu doğru bir şekilde yanıtlamak, alanın göründüğü her katmanda, yaşadığı her dilde, platformda ve depoda izlenmesini gerektirir.
Sistem genelinde veri alanlarını izleme
SMART TS XL Ortamınızdaki herhangi bir dil ve platformda alan düzeyinde eksiksiz bir çapraz referans oluşturur.
Buraya TıklaModern veri odaklı kuruluşlarda bu yetenek, veri soy ağacı olarak adlandırılır ve bulut veri ambarları, ETL işlem hatları ve BI platformları da dahil olmak üzere modern analitik yığınları için kullanılan araçlar önemli ölçüde olgunlaşmıştır. Sütun düzeyinde soy ağacı, birçok analitik ortamda standarttır. Ancak kurumsal yazılım sistemleri analitik yığınları değildir. Bunlar, her biri farklı araçlar, farklı ekipler ve farklı on yıllara dayanan tasarım kararlarıyla yönetilen ana bilgisayar programları, toplu işler, ilişkisel veritabanları, dağıtılmış hizmetler ve modern API'lerin heterojen kombinasyonlarıdır. ACCT-BALANCE COBOL copybook'unda tanımlanan alan Databricks veya dbt'de görünmez. Bu alan için toplu güncellemeyi besleyen JCL işi, hiçbir bulut veri soy ağacı aracında yakalanmaz. Ortaya çıkan veritabanı satırını okuyan ve bir yanıt nesnesi oluşturan Java servisi, aynı temel değer için kendi adlandırma kuralına sahip üçüncü bir sistemdir. Bu durum, aşağıdaki bağlamda ayrıntılı olarak incelendiğinde ortaya çıkar: JCL'den COBOL'a eşlemeBu üç katman, tek bir aracın çözmek için tasarlanmadığı şekillerde derinlemesine iç içe geçmiş durumdadır ve birleşik bir izlemenin yokluğu küçük bir boşluk değil, paylaşılan verilere dokunan her görevi etkileyen yapısal bir kör noktadır.
Bu makale, kurumsal bir sistemde alan izlemenin aslında ne anlama geldiğine dair pratik bir kılavuzdur: bir alanın geçtiği katmanlar, onu izlemek için mevcut yöntemler, bu yöntemlerin katman sınırlarında neden başarısız olduğu, gerçek bir alan düzeyinde izlemenin ne gerektirdiği ve bu yeteneğe yatırım yapan kuruluşların riski azaltmak, soruşturmayı hızlandırmak ve verilerinin kontrolünü büyük ölçekte sağlamak için bunu nasıl kullandıkları.
Bir Veri Alanının Kurumsal Sistem Üzerinden İzlenmesi Ne Anlama Geliyor?
Bir veri alanının izlenmesi, adlandırılmış bir veri öğesini tanımlandığı noktadan sistemdeki her dönüşüm, hareket, depolama ve tüketim olayına kadar her iki yönde de takip etmek anlamına gelir: alanın değerinin orijinal kaynağına doğru yukarı yönde ve bu değeri okuyan, kopyalayan, hesaplayan veya yayınlayan her yere doğru aşağı yönde. Tam bir alan izleme, alanın tüm yaşam döngüsünün bir haritasıdır: nerede oluşturulduğu, nasıl değiştiği, kimin okuduğu ve onunla ne yaptıkları. Bu, yararlı bir başlangıç noktası ancak son derece yetersiz bir bitiş noktası olan yalnızca bir alan adını aramaktan farklıdır. Bir arama sonuç listesi, yorumlar, günlük mesajları, test fikstürleri ve dokümantasyon dizeleri de dahil olmak üzere bir dizenin göründüğü her yeri içerirken, alanın yeniden adlandırıldığı, takma adlandırıldığı veya hesaplanmış bir anahtar aracılığıyla erişildiği referansları atlar. Bir alanın izlenmesi, aramanın yapamayacağı ayrımlar gerektirir: bir tanım ile bir kullanım, bir okuma ile bir yazma, alanın değerini değiştiren bir dönüşüm ile basit bir geçiş.
Her bir izleme işlemine sorulan soru, gerekli yönünü ve ayrıntı düzeyini belirler. Etki analizi, alanın tanımından başlayarak her bir tüketiciye doğru aşağı yönlü izleme yapar. Kök neden analizi, gözlemlenen yanlış bir değerden geriye doğru, her dönüşümden geçerek hatanın kaynağına kadar yukarı yönlü izleme yapar. Uyumluluk haritalaması ise, yönü ne olursa olsun, hangi sistemlerin alanı depoladığını veya işlediğini izler. Her izleme yönü aynı temel yeteneği gerektirir: yalnızca tek bir katman içinde değil, tüm katmanlarda alan düzeyindeki ilişkileri temsil eden bir sistem modeli. Veri analizi ve kontrol akışı analizinde incelendiği gibi , bir alanın sistemde ne yaptığını anlamak, hem taşıdığı veriler hem de hareket ettiği yürütme yolları hakkında akıl yürütmeyi gerektirir ve bu iki tür akıl yürütme, doğru ve eksiksiz bir sonuç üretmek için birlikte çalışmalıdır.
Tablo Düzeyi ve Alan Düzeyi İzleme Arasındaki Fark
Veri soy ağacı literatürü iki ayrıntı düzeyini birbirinden ayırır: veri kümelerinin birbirleriyle nasıl ilişkili olduğunu gösteren tablo düzeyinde soy ağacı ve tek tek alanların nasıl oluşturulduğunu, dönüştürüldüğünü ve kullanıldığını gösteren sütun düzeyinde soy ağacı. Bu ayrım yalnızca hassasiyetle ilgili değildir. Bu, A sisteminin B sistemini beslediğini bilmek ile B sisteminin değerinin ne olduğunu bilmek arasındaki farktır. customer_segment B sistemindeki değer, uygulanan bir hesaplamadan türetilmiştir. account_type hem de tenure_months A sisteminde. Tablo düzeyindeki soy ağacı, bir ekibe A sistemindeki bir değişikliğin B sistemini etkileyebileceğini söyler. Alan düzeyindeki soy ağacı ise, B sistemindeki hangi spesifik alanın, hangi spesifik dönüşümden, hangi spesifik koşullar altında etkilendiğini gösterir. Bu ayrıntı düzeyi, soy ağacını yönlendirme haritasından eyleme geçirilebilir bir haritaya dönüştüren şeydir.
Ana bilgisayar ve eski bileşenlere sahip kurumsal sistemlerde, veri gösterimi kurallarının katmanlar arasında önemli ölçüde farklılık göstermesi, ayrıntı düzeyi sorununu daha da karmaşık hale getirir. COBOL çalışma alanı alanı şu şekilde tanımlanır: WS-ACCT-BAL PIC S9(13)V99 Java değişkeniyle aynı iş konseptini içerir. accountBalance türü BigDecimalBu, veritabanı sütunuyla aynı kavramı içerir. ACCT_BALANCE DECIMAL(15,2)Tablo düzeyinde bir izleme, verilerin COBOL programından veritabanı tablosuna ve oradan da Java servisine aktığını gözlemler. Alan düzeyinde bir izleme ise bunu çözümler. WS-ACCT-BAL, ACCT_BALANCE, ve accountBalance Bunların hepsi aynı iş konseptinin farklı temsilleridir ve aralarındaki dönüşümler belgelenmiştir. Bu çözünürlük, izlemeyi eyleme geçirilebilir kılan şeydir.
Kurumsal Saha İzlemenin Analitik Soy Ağacını Takip Etmekten Neden Daha Zor Olduğu
Veri ambarları ve dbt gibi dönüşüm çerçeveleri etrafında oluşturulmuş modern platformlar da dahil olmak üzere analitik soy ağacı araçları, veri hareketinin tanımlanmış işlem adımları aracılığıyla açıkça düzenlendiği ve her adımın girdilerinin ve çıktılarının soy ağacı aracının okuyabileceği meta verilerde kaydedildiği ortamlarda çalışır. Soy ağacı, bu tür analizleri desteklemek için özel olarak tasarlanmış makine tarafından okunabilir yapılar olan işlem hattı tanımlarından oluşturulur. Kurumsal yazılım sistemleri bu şekilde çalışmaz. Bir COBOL programı, veri girdilerini ve çıktılarını makine tarafından okunabilir bir bildirimde bildirmez. Bir JCL işi, okuduğu ve yazdığı alanların şemasını bir meta veri kayıt defterine yayınlamaz. Bir Java servisi, her alan referansını bir veritabanı sütunuyla kavramsal ilişkisiyle açıklamaz. Katmanlar arası alan referansları arasındaki bağlantılar, kodun kendisinde ifade edilir: MOVE ifadelerinde, programlara gömülü SQL sorgularında, dosya düzeni tanımlarında, servis yöntemi imzalarında. Bu bağlantıları izlemek, bir işlem hattı meta veri kayıt defterini tüketmek değil, gerçek kodu okumayı ve anlamayı gerektirir. Dağıtılmış sistemlerde statik analiz bağlamında incelendiğinde , karmaşık bir dağıtılmış sistemin bileşenleri arasında veri akışı hakkında akıl yürütmek, yalnızca sistemin dış davranışını gözlemlemekle kalmaz, kodun kendisinin yapısal analizini de gerektirir.
Bir Kurumsal Sistemde Veri Alanının Geçtiği Katmanlar
Bir alanın izlenebilmesi için, geçtiği katmanların anlaşılması gerekir. Kurumsal sistemler mimarileri bakımından önemli ölçüde farklılık gösterse de, alan hareketleri çoğu büyük kuruluşun işlettiği teknik katmanlara karşılık gelen tanınabilir kalıpları izler. Alanın yaşam döngüsünde her katmanın rolünü anlamak, araştırmanın başladığı katmanla sınırlı kalmak yerine gerçekten eksiksiz bir izleme oluşturmanın ön koşuludur.
Tanım Katmanı: Alanın Kaynağı
Her alanın bir başlangıç noktası vardır: bir türü, uzunluğu ve anlamı olan adlandırılmış bir veri öğesi olarak ilk tanımlandığı yer. COBOL ortamlarında bu, tipik olarak bir çalışma alanı tanımı veya bir copybook üyesidir. İlişkisel veritabanlarında, bir tablo şemasındaki sütun tanımıdır. Java veya .NET servislerinde, bir sınıf veya yapıdaki alan bildirimidir. Mesaj tabanlı sistemlerde, JSON Şema, Avro, Protobuf veya XSD olsun, bir şema tanımındaki bir alandır. Tanım katmanı önemlidir çünkü alanın kanonik kimliğini belirler. CUST-ID COBOL copybook'unda yer alan tanım, ana bilgisayar ortamında bu kavramın yetkili tanımıdır ve okuyan, yazan veya dönüştüren her şey bu tanıma uyar. CUST-ID Bu ortamda, bu tanımın bir tüketicisi bulunur. Alanın izlenmesi buradan başlar ve onu kullanan kod boyunca dışarıya doğru referansları takip eder.
Tek bir iş kavramının genellikle, dönüşümlerle birbirine bağlanan, katman başına bir tane olmak üzere birden fazla tanımı vardır. Aynı kavramın tüm temsillerini belirlemek, eksiksiz bir izleme için ön koşuldur ve her zaman kolay değildir: adlandırma kuralları ekipler ve on yıllar arasında farklılık gösterir, tür temsilleri diller arasında farklılık gösterir ve bir alanın kavramsal sınırları, otomatik araçların tek başına her zaman sağlayamayacağı alan yargısı gerektirir. Bu, heterojen ortamlarda alan izlemenin indekslemeden daha fazlasını gerektirmesinin nedenlerinden biridir. Sadece sözdizimini değil, niyeti de yakalayan bir model gerektirir.
Depolama Katmanı: Veritabanları, Dosyalar ve Veri Kümeleri
İlk işlemeden sonra, bir alanın değeri neredeyse her zaman kalıcı olarak saklanır. İlişkisel veritabanlarında, bir sütunda bulunur. Ana bilgisayar ortamlarında, bir VSAM dosyasında, tanımlanmış bir düzene sahip düz bir dosyada veya CICS veya IMS aracılığıyla yönetilen bir veritabanında bulunabilir. Dağıtılmış sistemlerde, bir NoSQL deposunda, bir mesaj kuyruğunda, dağıtılmış bir önbellekte veya bir blob depolama sisteminde bulunabilir. Depolama katmanı, alan referanslarının temsilinin en sık değiştiği yerdir: bir alanın adı... CUST-ID COBOL programında, adlı bir sütuna yazma işlemi gerçekleştirilir. CUSTOMER_ID DB2 tablosunda ve bir Java servisi bu verileri okuyor. CUSTOMER_ID Aynı tablodan alır ve onu adlı bir nesne alanına kaydeder. customerIdBunların her biri aynı değere sahiptir, ancak COBOL alan referansını veritabanı sütununa ve Java nesne alanına bağlayan bir model olmadan hiçbir otomatik araç bu eşdeğerliği kuramaz.
Depolama katmanı ayrıca sessiz dönüşüm riskini de beraberinde getirir. Veritabanında sayısal türde saklanan ve uygulama kodunda bir dize değişkenine alınan bir alan, tüm bilgileri koruyup korumayacağı belirsiz olan bir tür dönüşümüne uğramıştır. COBOL dosyasında paketlenmiş ondalık biçimde saklanan ve bir Java servisine okunan bir alan, yanlış uygulandığında yuvarlama hatalarına yol açabilecek açık bir dönüştürme gerektirir. Tam bir alan izleme kaydı, bu depolama katmanı dönüşümlerini yalnızca her iki taraftaki sistemlerin adları olarak değil, açık adımlar olarak içerir.
İşleme Katmanı: Programlar, Hizmetler ve Toplu İşlemler
Tanımlama ve depolama arasında, depolama ve tüketim arasında alan değerleri işlenir. Programlar bunlardan türetilmiş değerler hesaplar. Servisler bunları iş kurallarına göre doğrular. Toplu işler bunları bir araya getirir, biçimlerini dönüştürür, kayıtları içeriklerine göre filtreler veya değerlerine göre işlemeyi yönlendirir. Bu işlem adımlarının her biri alanın izinde bir düğümdür ve değer doğruluğu, dönüşüm mantığı ve işlem sırası hakkındaki soruları yanıtlamak için her birinin anlaşılması gerekir. Ana bilgisayar ortamlarında, karmaşıklığın çoğu işlem katmanında bulunur ve COBOL statik analiz çözümlerinin incelenmesinde ayrıntılı olarak açıklandığı gibi , bir COBOL programının bir alanla gerçekte ne yaptığını anlamak, belirli bir girdi için hangi işlem yolunun yürütüleceğini belirleyen koşullu mantık da dahil olmak üzere, programın tüm yapısını ayrıştırmayı ve anlamayı gerektirir.
İşleme katmanı, diller arası sınırların en sık ortaya çıktığı yerdir. Bir COBOL toplu işi bir veritabanına yazarken ve bir Java servisi ondan okurken veya bir Python ETL işi bir ana bilgisayar işlemi tarafından üretilen bir dosyayı dönüştürürken, alan bir dilin işleminden diğerine geçer. İşleme katmanını kapsayan bir alan izleme, bu geçişler boyunca alanı takip etmeli, her dilde taşıdığı farklı adları ve gösterimleri çözümlemeli ve bunu dize eşleştirmesi yerine yapısal analiz yoluyla yapmalıdır.
Tüketim Katmanı: Raporlar, API'ler ve Aşağı Akış Sistemleri
Alanın yolculuğunun sonunda, değeri tüketilir: bir raporda görüntülenir, bir API yanıtında döndürülür, bir makine öğrenimi modeline beslenir, başka bir sistem için bir mesaj kuyruğuna yayınlanır veya bir düzenleyici başvuruda ortaya çıkarılır. Bu tüketim noktaları iki nedenden dolayı önemlidir. Birincisi, alanın değeri yanlış veya kullanılamaz olduğunda kimin etkileneceğini tanımlarlar. İkincisi, alanın tanımı veya işlenmesi değiştirildiğinde değişiklik etkisinin kapsamını belirleyen, alana bağlı olan harici sistemleri, kullanıcıları ve düzenleyici yükümlülükleri tanımlarlar. Tüketim katmanı izleme, genellikle uyumluluk ve düzenleyici ekiplerin en çok ihtiyaç duyduğu şeydir ve bağımlılık grafikleri ve uygulama riski bağlamında açıklandığı gibi , bir sistemin her bileşeninin neye bağlı olduğunu haritalamak, değişimi güvenli bir şekilde yönetmek ve kanıtlanmış izlenebilirlik gerektiren yükümlülükleri yerine getirmek için temeldir.
Kurumsal Ortamlarda Standart İzleme Yöntemleri Neden Başarısız Olur?
Özel olarak tasarlanmış araçlar olmadan saha izleme girişiminde bulunan kuruluşlar genellikle metin araması, dokümantasyon ve manuel incelemenin bir kombinasyonunu kullanırlar. Bu yaklaşımların her birinin, büyük, çok dilli kurumsal ortamlarda ciddi hale gelen bilinen sınırlamaları vardır. Her yöntemin nerede ve neden başarısız olduğunu anlamak önemlidir, çünkü bu yöntemler o kadar yaygın olarak varsayılan yöntemlerdir ki, başarısızlık biçimleri genellikle aracın yetersizliğinden ziyade görevin karmaşıklığına bağlanır.
Metin araması gereksiz sonuçlar üretir ve referansları gözden kaçırır.
Alan izleme için en yaygın başlangıç noktası metin aramasıdır: kaynak kodda, SQL komut dosyalarında ve yapılandırma dosyalarında alan adını bulmak. Metin araması hızlıdır, her yerde mevcuttur ve özel bir araç gerektirmez. Ancak, eksiksiz ve doğru bir alan izleme amacıyla güvenilir değildir. Güvenilirlik sorunu her iki yönde de işler. Metin araması çok fazla sonuç üretir: kısa alan adları gibi ID, STATUSya da DATE Binlerce farklı bağlamda ve hatta daha uzun isimlerde ortaya çıkabilir, örneğin account_balance İzlenen alanla yapısal bir ilişkisi olmayan günlük mesajlarında, yorumlarda ve test verilerinde görünebilirler. Aynı zamanda, metin araması çok az sonuç üretir, alan adının katmanlar arasında farklılık gösterdiği referansları, hesaplanmış anahtarlar veya takma adlar aracılığıyla ifade edilen referansları, oluşturulan koddaki referansları ve doğrudan kod referansı yerine veri aracılığıyla iletilen referansları gözden kaçırır.
Bir izini göz önünde bulundurun WS-CUSTOMER-IDCOBOL çalışma alanı bölümündeki bir alan:
COBOL
WORKING-STORAGE SECTION.
05 WS-CUSTOMER-ID PIC X(10).
PROCEDURE DIVISION.
MOVE CUSTOMER-RECORD-ID TO WS-CUSTOMER-ID.
EXEC SQL
INSERT INTO CUSTOMER_AUDIT
(CUST_ID, AUDIT_TS)
VALUES (:WS-CUSTOMER-ID, CURRENT TIMESTAMP)
END-EXEC.Metin araması WS-CUSTOMER-ID Bu programda çalışma belleği tanımını ve referanslarını bulur. Bulamadığı şeyler:
- Veritabanı sütunu
CUST_IDBu, gömülü SQL INSERT sorgusu aracılığıyla alanın değerini alır. - Java servisini okuyan fonksiyon
CUST_IDitibarenCUSTOMER_AUDITve onu şu şekilde saklar:customerId - Seri hale getirilen API yanıtı
customerIdascustomer_idAşağı yönlü tüketiciler için JSON formatında. - Bu değeri son kullanıcılara gösteren rapor veya gösterge paneli.
Bu bağlantıların her biri farklı bir analiz türü gerektirir: SQL ayrıştırma, şema eşleme, Java AST analizi ve API sözleşmesi incelemesi. Metin araması bunların hiçbirini sağlamaz ve sonuç kümesi bu bağlantıların var olduğuna ve gözden kaçtığına dair hiçbir gösterge vermez.
Belgeler tamamlanmadan önce güncelliğini yitirir.
Otomatik araçların yokluğunda, kuruluşlar genellikle elle tutulan dokümantasyona güvenirler: veri sözlükleri, alan eşleme elektronik tabloları, veri akış diyagramları ve mimari kayıtlar. Bu belgeler, doğru ve güncel olduklarında değerlidir. Ancak nadiren ikisi aynı anda doğrudur. Sorun, dokümantasyon ekiplerinin dikkatsiz olması değil, kod değişim hızı ve manuel dokümantasyonun iş gücü yoğunluğunun kurumsal ölçekte temelde uyumsuz olmasıdır. Bir sprintte üç yeni hizmete eklenen bir alan, bu hizmetlerin etkileşimde bulunduğu sistemleri açıklayan her veri sözlüğünün, her akış diyagramının ve her eşleme elektronik tablosunun güncellenmesini gerektirir. Uygulamada, bu güncellemelerin bazıları gözden kaçırılır. Dokümantasyon gerçeklikten sapar, referans olarak güvenilmez hale gelir ve yavaş yavaş terk edilir. Eski sistemlerin modernizasyon projeleri, yanlış veya eksik dokümantasyonu birincil risk faktörlerinden biri olarak sürekli olarak tanımlar; çünkü güvenli modernizasyon, her bileşenin ne yaptığını ve ona neyin bağlı olduğunu bilmeyi gerektirir ve dokümantasyonun bu bilgiyi güvenilir bir şekilde sağlayacağına güvenilemez.
Manuel Denetim Ölçeklenebilir Değildir
Manuel kod incelemesi, alan izleme için en yüksek doğruluk oranına sahip yaklaşımdır: bir geliştirici kaynak kodu okur, referansları takip eder ve alanın yaşam döngüsünün zihinsel bir modelini oluşturur. Tek bir programdaki tek bir alan için bu iyi çalışır. Üç dilde ve iki platformda elli programda görünen bir alan için, manuel inceleme, hiçbir bireyin aynı anda bu kadar çok bağlamı aklında tutamayacağı için hala tamamlanmamış, günlerce süren bir egzersiz haline gelir. Yirmi yıldır üretimde olan ve yüzlerce geliştirici tarafından incelenen bir alan için, manuel inceleme, son teslim tarihine bağlı herhangi bir görev için gerçekçi bir seçenek değildir. Organizasyonel maliyet, tükettiği zamandan daha fazlasını kapsar: manuel inceleme yoluyla oluşturulan bilgi, paylaşılabilir bir eserde değil, bunu yapan kişide yaşar. Aranabilir, aktarılabilir ve doğrulanabilir değildir. Aynı alanı izlemesi gereken bir sonraki kişi, aynı boş temelden başlar ve aynı işi tekrarlar. Alan izleme araçlarının kırmak için var olduğu yapısal kalıp budur.
Birleşik Alan İzleme İşlemi Pratikte Nasıl Çalışmalıdır?
Kurumsal bir sistemde eksiksiz bir alan izleme işlemi, tüm sistemi yapısal düzeyde indekslemiş bir araç gerektirir: her dildeki her kaynak yapıtını ayrıştırmış, bu yapıtların içerdiği sembollerin ve ilişkilerin bir modelini oluşturmuş ve sistem sınırları boyunca alan referanslarını birbirine bağlayan diller arası ve katmanlar arası bağlantıları çözmüş olmalıdır. Bu model oluşturulduktan sonra, bir alan izleme işlemi, sorunun gerektirdiği yönde, başlangıç düğümünden dışa doğru bağımlılık kenarlarını izleyen bir grafik sorgusudur. Sorgu, manuel olarak incelenecek dosyaların bir listesini değil, belirli yapıtları, belirli satır referanslarını ve belirli ilişki türlerini döndürür.
İzleme İşlemine Başlama: Doğru Bağlantı Noktasını Seçme
Bir alan izlemesi, bir çapa noktasından başlar: belirli bir yapıttaki belirli bir alan referansı. Çapa noktası, alanın kanonik tanımı (örneğin, copybook üyesi, veritabanı sütun şeması veya Java sınıfı alan bildirimi) veya mevcut araştırma konusu olan belirli bir programda gözlemlenen bir kullanım olabilir. Doğru çapa noktasını seçmek önemlidir çünkü izlemenin başlangıç yönünü belirler. Etki analizi için çapa noktası genellikle tanımdır ve buradan ileriye doğru izleme, bir değişiklikten etkilenecek her tüketiciyi listeler. Kök neden analizi için çapa noktası genellikle bir tüketim noktasında gözlemlenen yanlış bir değerdir ve buradan geriye doğru izleme, hatanın kaynağına doğru yukarı yöndeki işlem zincirini takip eder. Uyumluluk haritalaması için izleme çift yönlüdür: yönünden bağımsız olarak alanı depolayan, işleyen veya gösteren her sistemi bulur.
Her Katmandaki İzi Takip Etmek
Çapa noktasından başlayarak, iz, sistemin her katmanında uygun yönde saha referanslarını takip eder. Bu geçişin doğru ve eksiksiz olması için birkaç farklı çözünürlük adımının birlikte çalışması gerekir:
Tek bir program içerisinde: Tanımlar, okuma, yazma, dönüşümler ve koşullu kullanımlar dahil olmak üzere, tek bir kaynak dosya içindeki alan referanslarını çözümlemek. COBOL için bu, MOVE ifadelerini, COMPUTE ifadelerini, REDEFINES maddelerini ve paragraf düzeyindeki veri akışını anlamayı gerektirir. Java için ise alan erişimlerini, alanı geçiren veya döndüren yöntem çağrılarını ve dönüşüm ifadelerini çözümlemeyi gerektirir.
Aynı dil içindeki program sınırları boyunca: Bir programın başka bir programı çağırdığında, paylaşılan bir dosya veya veri kümesi üzerinden veri aktardığında veya paylaşılan bir depolama katmanına yazdığında bir alanın değerinin nasıl değiştiğini çözümlemek. COBOL ortamlarında bu, bir alan tanımını paylaşan tüm programları bulmak için copybook referanslarını çözümlemeyi ve aynı dosya düzenini okuyan veya yazan tüm programları bulmak için VSAM dosya erişimini izlemeyi içerir.
Dil sınırları ötesinde: Bir alanın değerinin bir COBOL programından veritabanı sütununa, veritabanı sütunundan Java nesne alanına, Java nesnesinden JSON API yanıtına veya herhangi bir kaynak dil gösteriminden hedef dil gösterimine geçtiği diller arası bağlantıların çözümlenmesi. Bu, tüm dillerden alan referanslarını ortak bir yapıda temsil eden ve aynı iş kavramının farklı gösterimleri arasındaki kavramsal eşdeğerlikleri çözen birleşik bir model gerektirir.
Sistem ve platform sınırları boyunca: mesaj kuyrukları, dosya transferleri, toplu aktarımlar ve API çağrıları dahil olmak üzere sistemler arası arayüzler aracılığıyla alanı takip etmek. Bu sistemler arası bağlantılar, kod yerine yapılandırmada veya herhangi bir statik yapıda temsil edilmeyen çalışma zamanı adlandırma kuralları aracılığıyla ifade edilebildikleri için otomatik olarak izlenmesi genellikle en zor olanlardır.
Diller Arası Alan Eşdeğerliklerinin Çözümlenmesi
Pratikte en sık başarısız olan adım, diller arası alan eşdeğerliğinin çözümlenmesidir: yani şunun belirlenmesidir: WS-CUSTOMER-ID COBOL dilinde, CUST_ID DB2 sütununda ve customerId Bir Java nesnesindeki tüm temsiller aynı iş kavramının farklı biçimleridir. Bu eşdeğerlik olmadan, COBOL-veritabanı sınırına ulaşan bir izleme, Java katmanına devam edemez. Bu eşdeğerlikleri kurmanın en güvenilir yolu, hedef alanı dolduran kodun yapısal analizidir. Bir COBOL programı çalıştırıldığında... INSERT INTO CUSTOMER_AUDIT (CUST_ID) VALUES (:WS-CUSTOMER-ID)SQL sorgusunun yapısal analizi doğrudan şunu ortaya koymaktadır: CUST_ID değerini şuradan alır WS-CUSTOMER-IDBu bağlantı, alanın izleme grafiğinde bir kenar haline gelir ve izleme veritabanı tarafında devam eder.
Aşağıdaki tablo, temsili bir alan için eksiksiz bir alan izleme işleminin, yapılandırılmış bir çözümleme adımları dizisi olarak nasıl göründüğünü göstermektedir:
| İzleme adımı | Kaynak yapıtı | Hedef yapıt | Bağlantı türü |
|---|---|---|---|
| 1. Programa yönelik defter | CUSTCOPY defter üyesi CUST-ID | COBOL programı CUSTINQ | KOPYA ifadesi referansı |
| 2. Veritabanına program | COBOL ana değişkeni :WS-CUSTOMER-ID | DB2 sütunu CUST_ID in CUSTOMER_AUDIT | Gömülü SQL INSERT |
| 3. Veritabanından hizmete | DB2 CUST_ID | Java alanı customerId in CustomerAuditService | JDBC ResultSet eşlemesi |
| 4. API'ye Hizmet | Java customerId | JSON alanı customer_id REST yanıtında | Jackson serileştirmesi |
| 5. Raporlama için API | JSON customer_id | Gösterge paneli boyutları Customer Identifier | BI katmanı tarafından API tüketimi |
Kurumsal Saha İzlemenin En Önemli Kullanım Alanları
Saha izleme, akademik bir çalışma değildir. Büyük, çok katmanlı kurumsal sistemlerin işletiminde rutin olarak ortaya çıkan belirli yüksek riskli durumlara bir kuruluşun ne kadar hızlı ve doğru bir şekilde yanıt verebileceğini belirleyen pratik bir yetenektir. Aşağıdaki örnekler, saha izlemenin yokluğunun en doğrudan ve ölçülebilir maliyete sahip olduğu senaryoları temsil etmektedir.
Şema Değişikliği Etki Analizi
Şema değişiklikleri, kurumsal sistemlerdeki üretim olaylarının en yaygın kaynaklarından biridir. Bir sütunun yeniden adlandırılması, bir sütunun silinmesi, bir veri türünün değiştirilmesi veya bir uzunluğun uzatılması: Veritabanı şemasında yapılan bu değişikliklerin herhangi biri, etkilenen sütuna referans veren her programı, hizmeti veya raporu sessizce bozabilir ve önceden uyarı verecek bir derleme zamanı hatası vermez. Bir sütunun birden fazla dilde düzinelerce program tarafından referans verildiği büyük bir sistemde, şema değişikliğini güvenli bir şekilde gerçekleştirmenin tek yolu, değişiklik yapılmadan önce her referansı listelemek ve dağıtımdan önce her tüketicinin güncellendiğini doğrulamaktır. Alan düzeyinde izleme bu listelemeyi sağlar: Veritabanı sütunundan tüm tüketici kodlara doğru bir izleme, incelenmesi gereken her programı, hizmeti, toplu işi ve raporu tanımlar ve sistemlerin bir listesi yerine belirli dosya konumlarını ve satır numaralarını döndürür. Kurumsal modernizasyon için etki analizi bağlamında incelendiğinde , bir değişiklikten önce tam olarak neye dokunacağını bilmek, mevcut sorunları çözerken yeni üretim riski yaratmayan modernizasyon çalışmaları için temel yetenektir.
Mevzuat Uyumluluğu ve Veri Sahibi Hakları
GDPR, HIPAA ve CCPA dahil olmak üzere veri koruma düzenlemeleri, alan düzeyinde izlenebilirlik gerektiren yükümlülükler getirmektedir. Bir GDPR silme hakkı talebi, talepte bulunan kişinin kişisel veri alanlarının tüm sistemlerdeki her bir deposunun tanımlanmasını ve silinmesini gerektirir. Bir HIPAA denetimi, korunan sağlık bilgisi alanlarına yalnızca yetkili sistemler ve personel tarafından erişildiğini göstermeyi gerektirir. Bir BCBS 239 değerlendirmesi, belirli risk ölçütlerinin belgelenmiş kaynak alanlarından belgelenmiş dönüşümler yoluyla tutarlı bir şekilde hesaplandığını kanıtlamayı gerektirir. Bu yükümlülüklerin hiçbiri tablo düzeyinde soy ağacıyla karşılanamaz, çünkü yükümlülük tüm tablolara değil, belirli alanlara yöneliktir. Alan düzeyinde izleme, uyumluluk ekiplerine hangi sistemlerdeki hangi programlardaki hangi sütunların, talebe konu olan belirli alanları depoladığını ve işlediğini söyler ve bu özgüllük, bir uyumluluk yanıtının eksiksiz ve denetlenebilir mi yoksa eksik ve yalnızca tasdik yoluyla savunulabilir mi olduğunu belirler.
Veri Kalitesi Olayları için Kök Neden Analizi
Bir veri kalitesi olayı meydana geldiğinde, ister yanlış toplamlar gösteren bir gösterge paneli, ister geçersiz değerler içeren kayıtlar içeren bir rapor veya beklenmedik boş değerler döndüren bir API olsun, soruşturma geriye doğru izleme ile başlar: hatanın kaynağı belirlenene kadar, hata noktasından başlayarak onu üreten her dönüşümden geçerek alanın değerini yukarı doğru takip edin. Alan düzeyinde izleme araçları olmadan, bu soruşturma büyük bir sistemde günler sürebilen manuel bir işlemdir. Bir Java API yanıtındaki yanlış bir değeri araştıran bir geliştirici, hatayı oluşturan hesaplamayı bulmadan önce Java kodundan, veritabanı sorgusundan, veritabanı sütununu dolduran ETL veya toplu işten ve potansiyel olarak yukarı akış toplu işlemeye kadar manuel olarak geriye doğru izleme yapmalıdır. Her katman geçişi, farklı bir kod tabanına ve potansiyel olarak farklı bir ekibe manuel bir bağlam geçişidir. Bağımlılık indeksleme yoluyla ortalama kurtarma süresini azaltma bağlamında açıklandığı gibi , otomatik bağımlılık izleme yoluyla elde edilebilen olay soruşturma süresindeki azalma, soruşturma süresinin olay süresine düzeltme süresinden çok daha fazla hakim olduğu veri kalitesi soruşturmalarında en doğrudan hissedilir.
Güvenli Alan Yeniden Adlandırma ve Kullanımdan Kaldırma
Bir alanı yeniden adlandırmak veya bir alan tanımını kullanımdan kaldırmak, değişiklik yapılmadan önce mevcut adı kullanan her konumu bilmeyi gerektirir. Tek dilli, tek depolu bir kod tabanında, IDE yeniden düzenleme araçları bunu güvenilir bir şekilde halleder. Çok dilli bir kurumsal sistemde, yeniden adlandırma, hiçbir aracın tam görünürlüğe sahip olmadığı dil sınırlarını aşar: bir COBOL copybook'unda yeniden adlandırılan bir alan, copybook'a referans veren her COBOL programında, ilgili sütun adını kullanan her SQL sorgusunda, sütunu bir nesne alanına eşleyen her Java servisinde ve bu servislerin her alt tüketicisinde güncellenmelidir. Alan düzeyinde bir izleme, yeniden adlandırma başlamadan önce referansların tam listesini sağlar ve geliştirme ekiplerinin referans listesini önceden incelemesine ve yeniden adlandırmanın tamamlandığından emin olarak dağıtım yapmasına olanak tanır. Aynı durum alan kullanımdan kaldırma için de geçerlidir: kullanımdan kaldırılan alanın bir izlemesi, hangi tüketicilerin hala ona bağımlı olduğunu ve bu nedenle kullanımdan kaldırma işlemi güvenli bir şekilde tamamlanmadan önce hangi tüketicilerin taşınması gerektiğini belirler.
Ne kadar SMART TS XL Saha düzeyinde eksiksiz bir izleme kaydı oluşturur.
SMART TS XL Ortamdaki her dil ve platformdan kaynak kodunu alarak ve her birini dile özgü analiz kullanarak ayrıştırarak, tüm kurumsal sistemin birleşik bir çapraz referans modelini oluşturur. COBOL programları, JCL iş akışları, DB2 ve SQL şemaları, Java servisleri, .NET uygulamaları, Python komut dosyaları ve XML ve JSON yapılandırma öğeleri, ortak bir sembol ve ilişki grafiğine ayrıştırılır. Her dildeki alan referansları bu grafikte düğümler olarak temsil edilir ve aralarındaki ilişkiler (tanımlar, okumalar, yazmalar, dönüşümler ve diller arası eşdeğerlikler dahil) tipli kenarlar olarak temsil edilir. Bu grafik, platformun gerçekleştirdiği her alan izlemesinin temelini oluşturur.
Alan düzeyinde izleme SMART TS XL Grafikteki herhangi bir alan referans düğümünden başlayarak, sorulan soruya uygun yönde kenarları takip eden bir grafik geçişidir. Bir COBOL copybook üyesinden ileriye doğru bir izleme, copybook'u içeren her programı, bu programlardaki ilgili sütuna referans veren her SQL ifadesini, sütunun değerini alan her tabloyu, bu tablodan okuyan her hizmeti ve alanı harici tüketicilere sunan her API yanıtını veya raporunu döndürür. Geçiş, dil sınırlarını otomatik olarak aşar çünkü diller arası eşdeğerlikler sorgu zamanında değil, indeksleme sırasında çözülür. Platformun kurumsal arama özelliği, alan izleme için giriş noktası sağlar: indekslenmiş sistemde bir alan adı arayan bir geliştirici veya analist, sonuç kümesinde tanımlar, okumalar, yazmalar, SQL referansları, copybook dahil etmeleri ve API sunumları ayırt edilerek, yapıt türüne, dile ve ilişki türüne göre düzenlenmiş sonuçlar alır. Açıklandığı gibi, kurumsal arama çözümleri Bu platform, bir alanın tüm uygulama portföyünde nerede kullanıldığını bulmak üzere özel olarak tasarlanmıştır; bu özellik, kurumsal alan izleme sorununu doğrudan ve büyük ölçekte ele almaktadır.
SMART TS XLEtki analizi, ileriye dönük soruyu otomatik olarak yanıtlayarak alan izleme iş akışını tamamlar. Bir copybook'taki, veritabanı şemasındaki veya hizmet arayüzündeki bir alan değişiklik için işaretlendiğinde, platform tüm aşağı yönlü etki grafiğini hesaplar ve bunu katmana ve belirli referans konumuna göre düzenlenmiş, gezilebilir bir çapraz referans raporu olarak sunar. Bu, alan izlemenin en zaman alıcı kısmı olan, bir değişiklik yapmadan önce her aşağı yönlü tüketiciyi listeleme işlemini, manuel bir araştırmadan, herhangi bir ekip üyesinin çalıştırabileceği, yorumlayabileceği ve üzerinde işlem yapabileceği yapılandırılmış bir sorgu sonucuna dönüştürür. Bu bağlamda incelendiğinde, bağımlılık topolojisi ve modernizasyon sıralamasıBir değişikliğin yapılmadan önce tam olarak neleri etkileyeceğini bilme yeteneği, risk yaratmaktan ziyade riski yöneten modernizasyon çalışmaları için temel bir gerekliliktir.
Saha İzleme, Proje Faaliyeti Değil, Sürekli Bir Yetenek Olarak Görülmelidir.
Kurumsal saha izleme ile ilgili en önemli nokta, bunun olaylar veya uyumluluk son tarihleri tarafından tetiklenen proje tabanlı bir araştırma değil, geliştirme ve operasyon iş akışına entegre edilmiş sürekli bir yetenek olması gerektiğidir. Saha izleme reaktif olduğunda, araştırmanın maliyeti en fazla zaman baskısı altında olan ekiplerin omuzlarına düşer: üretim olayını çözen geliştiriciler, denetim için hazırlanan uyumluluk ekibi, teslimat son tarihine kadar bir geçiş planlayan mimarlar. Araştırma, düzeltme için ihtiyaç duydukları zamanı tüketir ve bunu gerektiren her olayın etkisini artırır.
Sistemde sürekli güncellenen bir modelde alan izleme sürekli bir yetenek olarak sürdürüldüğünde, araştırma zaten yapılmış olur. Alanın tüm katmanlardaki ilişkileri, ön analiz aşamasına gerek kalmadan anında kullanılabilir hale gelir. Şema değişiklikleri dağıtımdan önce değerlendirilir, sonradan keşfedilmez. Uyumluluk soruları, manuel yeniden yapılandırma yoluyla değil, modelden yanıtlanır. Kök neden araştırmaları, metin araması ve ekip iletişimiyle değil, alan izlemesinden başlar. Bu sürekli güncel modeli sürdürmek, kod değişiklikleri sırasında sistemi sürekli olarak indeksleyen, çapraz referans modelini artımlı olarak güncelleyen ve her katmanda alan düzeyindeki ilişkileri doğru tutan bir araç gerektirir. Bu yeteneği oluşturmak anlamlı bir yatırımdır. Alternatif olarak, kurumsal ölçekte faaliyet gösteren bir kuruluşta her ihtiyaç duyulduğunda manuel alan izlemenin maliyetini ödemek, sürekli olarak daha fazla maliyete yol açar ve sistem büyüdükçe maliyet artmaya devam eder.
