Bugün İçin İnşa Edin. Yarın İçin Planlayın. Başarısızlık İçin Planlayın.

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun ilk bölümü olan Bir Veri Mimarı Gibi Düşünmek bölümündeki 7 modülden 5.‘si. Her modül kendi başına okunabilir. Önceki: Mimari, Ödünleşim Sanatıdır · Sonraki: Araçlarınızı Tanıyın: Dokuz Soru

Bu modülün yanıtladığı soru: Büyüme ve başarısızlık için plan yaparken bugünün gereksinimlerine göre nasıl tasarlarsınız?

Mimaride yapılan en kolay hatalardan biri yalnızca önünüzdeki gereksinimlere göre tasarlamaktır. Bir projemiz, bir iş listemiz ve gereksinimlerimiz var. Onları karşılayan bir şey inşa ediyoruz. Çalışıyor ve zafer ilan ediyoruz. Altı ay sonra iş değişiyor ya da veri büyüyor ya da başka bir iş birimi onu kullanmak istiyor ya da bir şirket satın alıyoruz ya da yeni bir sistemin entegre olması gerekiyor ya da kimsenin hesaba katmadığı bir şey bozuluyor.

Bunların hiçbiri bir mimarı şaşırtmamalı. Olacak her şeyi tahmin edemeyiz, ama bir şeylerin olacağını bilerek tasarlayabiliriz. Bu yüzden mimariye üç mercekten bakarım:

Bugün için inşa edin. Yarın için planlayın. Başarısızlık için planlayın.

Üçüne de ihtiyacınız var.

Click to enlarge

Bugün İçin İnşa Edin

Mimari gerçekte sahip olduğumuz sorunla başlar. Bu apaçık gibi görünür, ama mimarlar kısa vadeli düşünmenin tersi olan hataya düşebilir: aşırı mimari yapabiliriz. Ya on iki şirket satın alırsak, bir milyar müşterimiz olursa, 40 ülkeye açılırsak ve her sistem gerçek zamanlı entegrasyon gerektirirse? Belki. Ama bunlar gerçek olasılıklar mı, yoksa sorun mu uyduruyoruz? Mimari hayal edebileceğimiz en gelişmiş sistemi inşa etmek değildir. Uygun olanı inşa etmektir.

O yüzden bugünle başlayın: işin neye ihtiyacı var, gerçek hacimler, kullanıcılar ve işlemler, veri ne sıklıkla değişiyor ve ne kadar hızlı hareket etmesi gerekiyor, kimin erişime ihtiyacı var ve veri nereden gelip nereye gidiyor. Ve en önemlisi: neden? Bu cevaplar bize tasarlayacak somut bir şey verir.

Örtük Gereksinimleri Arayın

Size verilen gereksinimler, sahip olduğunuz tüm gereksinimler olmayabilir. Neredeyse her zaman örtük gereksinimler vardır.

İş birimi “Müşteri verisinin Salesforce’ta olması gerekiyor” der. Peki. O zaman birinin bu verinin sahibi olması ve ne kadar güncel olması gerektiğine karar vermesi gerekir. Kaynak sistem çöktüğünde ne olacağını, senkronizasyon başarısız olduğunda bunu nasıl fark edeceğimizi ve Salesforce ile kaynak uyuşmadığında hangi tarafın kazanacağını bilmemiz gerekir. Bir saklama süresine, bir erişim modeline, hassas alanlarla ilgili bir karara ve kötü veriyi düzeltmenin bir yoluna ihtiyacımız var.

Bunların hiçbiri kullanıcı hikâyesinde yoktu. Hepsi yine de mimaridir. Mimar olmanın büyük bir kısmı henüz sorulmamış soruları tanımayı öğrenmektir.

Sayılarınızı Bilin

Mimarları sürekli sayısallaştırmaya zorlarım. Bana çok veri olduğunu söylemeyin; ne kadar olduğunu söyleyin. On bin mi, on milyon mu, yüz milyon mu, bir milyar mı? Bunlar çok farklı mimarilerdir. Bana entegrasyonun sık çalıştığını söylemeyin: saatte bir mi, dakikada bir mi, saniyede bin kez mi? Bana hızla büyüdüğümüzü söylemeyin. Ne kadar hızla?

Daha iyi bir sayım olmadığında temel değerim yıllık yüzde 30 büyümedir. Bu bir tahmin değil, bir zorlama aracıdır. Biri bana bugün 10 milyon kaydımız olduğunu söylerse tartışmanın 10 milyonda durmasını istemem. Yılda yüzde 30 ile gelecek yıl kabaca 13 milyona, ondan sonraki yıl 17 milyona ve bir sonraki yıl yaklaşık 22 milyona ulaşırız. Şimdi tasarımı konuşalım. İş birimi bana yüzde 30’un saçma olduğunu söylerse harika: bana gerçek sayıyı verin. Amaç büyümeyi mimari tartışmanın bir parçası yapmaktır.

Ben buna Steve’in Sıfır Sayısı (Steve’s Number of Zeros) diyorum. Fazladan bir sıfır mimarinizi tamamen değiştirebilir. On bin, yüz bin, bir milyon, on milyon, yüz milyon: özellik değişmedi, gereksinim de değişmemiş olabilir, ama mimari değişebilir.

1. modüldeki randevuları hatırlıyor musunuz? Onlara gerçek sayıları koyalım. 1.200’ün üzerinde nokta, nokta başına günde 100 randevu, haftada altı gün, yılda yaklaşık 305 gün. Bu ilk yılda 36 milyonun üzerinde randevu eder. Her ziyaret iki kayıt oluşturur, yani 73 milyonun üzerinde kayıt. Şimdi yılda yüzde 30 büyüyerek beş yıllık geçmişi saklayın; 650 milyon kaydı aşar. Aynı özellik, aynı gereksinim. Birkaç sıfır daha ve çok farklı bir mimari.

Yarın İçin Planlayın

Bugünü anladıktan sonra ileriye bakarım: neyin değişmesi makul ölçüde olası? Hacim bunun bir parçasıdır ama yarın yalnızca daha fazla demek değildir. Farklı da demek olabilir: daha fazla ürün, iş birimi ve ülke; farklı gizlilik gereksinimleri; yeni kanallar ve entegrasyonlar; bir birleşme ya da satın alma; yeni bir ana veri stratejisi ya da analiz platformu; yalnızca insanlar için tasarlanmış bilgiyi tüketen bir yapay zekâ ajanı.

Mimarinin sürekli değişiklik yerine ekleme yoluyla büyüyüp büyüyemeyeceğini bu kadar önemsememin nedeni budur. İş bir ürün eklerse model onu alabilir mi? Başka bir sistemin veriye ihtiyacı olursa onu temiz biçimde sunabilir miyiz? Hacim sıçrarsa gidecek bir yerimiz var mı? İş yapısı değişirse veri modelini parçalamak zorunda kalacak mıyız? Geleceği kusursuz tahmin etmeye çalışmıyoruz. Kendimizi köşeye sıkıştırmamaya çalışıyoruz.

Yarını Bugün İnşa Etmeyin

Burada bir denge var. Yarın için planlamak, yarının sistemini bugün inşa etmek demek değildir. 100.000 kaydımız varsa ve beş yıl içinde 100 milyon olabilecekse, bu 100 milyon kayıtlık mimariyi şimdi inşa ettiğimiz anlamına gelmez. Henüz ihtiyacımız olmayan maliyet ve karmaşıklık getirebilir.

Cevaplanmasını istediğim soru şudur: bugünün mimarisi yarınınkine evrilebilir mi? İleriye giden net bir yolla basit başlayabiliyorsak, bu çoğu zaman karmaşıklığın bedelini yıllar önceden ödemekten daha iyidir. Tehlike küçük başlamak değildir. Tehlike gidecek hiçbir yeri olmayan bir yerden başlamaktır.

Başarısızlık İçin Planlayın

Şimdi kimsenin konuşmayı sevmediği kısım: işler bozulur. Her bileşenin sonsuza kadar erişilebilir kaldığı, her entegrasyonun başarılı olduğu, her kullanıcının kusursuz veri girdiği ve her harici sistemin tam belgelendiği gibi davrandığı bir sistem hiç tasarlamadım. O yüzden o sistemi tasarlamayın.

Neyin bozulabileceğini sorun, sonra bozulduğunda ne olacağını sorun. Bir entegrasyon zaman aşımına uğrar. Bir API bir isteği reddeder. Bir gece yüklemesi 800.000 kaydı işler ve 200.000’inde başarısız olur. Bir kaynak sistem çöker. Bir kullanıcı geçersiz veri girer. Bir harici tanımlayıcı iki kez karşımıza çıkar. Bir üst akış sistemi bir değerin biçimini alan adını değiştirmeden değiştirir. Bir süreç bir sistemde başarılı olur, diğerinde başarısız olur. Bunlar alışılmadık uç durumlar değildir. Üretim ortamı böyle görünür.

Kısmi Başarı da Anlamanız Gereken Bir Başarısızlıktır

Kısmi başarısızlıklar veri mimarisinde özellikle tehlikelidir. Bir milyon kayıt taşıdığınızı ve sürecin tamamlandığını bildirdiğini düşünün. Harika. Ama bir milyon mu geldi, yoksa 999.997 mi ve eksik üçü hangileri? Belki 200.000’i başarısız oldu, bazıları iki kez oluşturuldu ya da hepsi geldi ama bazı alanların dönüşümü başarısız oldu.

“İş tamamlandı”, verinin doğru olduğu ile aynı şey değildir. Bir veri mimarı mutabakatı düşünür: ne olması gerektiğini, gerçekte ne olduğunu ve aradaki farkı nasıl biliriz? Ve bu konuda ne yaparız?

Sistemler karmaşıklaştığında şunu yaparım. Kayıtlar A’dan B’ye, soldan sağa gider. Sonra B bir şey geri gönderir: aldığı ve kaydettiği her kayıt için bir onay. Artık A gönderdiklerini onaylananlarla karşılaştırabilir. Her kaydın onayı varsa çalıştırma başarılı olmuştur. Herhangi bir onay eksikse, iş durumu ne derse desin başarılı olmamıştır ve hangi kayıtların peşine düşeceğimizi tam olarak biliriz: yeniden deneriz, bir kişiye yönlendiririz ya da bir uyarı oluştururuz.

Click to enlarge

Zarif Biçimde Başarısız Olun

Başarısızlık olduğunda sistemin sonra ne yaptığını bilmek isterim: yeniden deniyor mu, otomatik mi; aynı işlem iki kez işlenirse ne oluyor; başarısız kayıtlar nereye gidiyor ve iyi kayıtlar kötü bir kaydın yanından akmaya devam ediyor mu; kime, hangi bilgiyle uyarı gidiyor ve başarısızlığı nasıl yeniden oynatıyorlar; bir kullanıcı bir şeylerin ters gittiğini nasıl öğreniyor.

Ve en önemlisi: sorunu daha da kötüleştirmeden kurtarabilir miyiz? Yinelenen veri yaratan bir yeniden deneme stratejisi pek bir kurtarma stratejisi sayılmaz. İyi mimari başarısızlığı varsayar ve bize geri dönüş yolu verir.

Önemli Olanı İzleyin

İzleme olmadan başarısızlık için plan yapmak gerçek bir plan değildir. Bir entegrasyon gece 2:00’de başarısız olursa ve üç gün sonra bir müşteri arayana kadar kimse fark etmezse, bir operasyonel mimarimiz yoktu. Bir umudumuz vardı.

Neyin gözlemlenebilir olması gerektiğine karar verin: süreç çalıştı mı, ne kadar sürdü, kaç kayıt işlendi, kaçı başarılı ve kaçı başarısız oldu? Hacimler normalden birden farklı mı? Birikim büyüyor mu, hatalar artıyor mu? Mimari dağıtım başarılı olduğunda bitmez. Birinin yarın bu sistemi işletmesi gerekiyor ve bu da tasarımın bir parçasıdır.

Üç Yönde Düşünün

Kursun geri kalanında üç merceği uygulamaya devam edin. Bir veri modeli tasarlarken: bugün çalışıyor mu, yarın büyüyebilir mi ve veri yanlış ya da eksik olduğunda ne olur? Bir entegrasyon: bugünün verisini taşıyor mu, yarının hacmini ve sistemlerini kaldırabilir mi ve bir taraf çöktüğünde ne olur? Büyük veri hacimleri: bugün elimizde ne var, sayılar nereye gidiyor ve büyük bir işlem yalnızca kısmen başarılı olduğunda nasıl kurtarırız?

Teknoloji bölümden bölüme değişir. Sorular değişmez.

Mimari Zaman İçinde Var Olur

Bir geliştirici bazen bir gereksinime bakıp “Bu çalışıyor mu?” diye sorabilir. Mimar daha fazlasını sormak zorundadır: bugün çalışıyor mu, yarın da çalışacak mı ve hiç çalışmadığında ne olur? Bu üç soru bizi uygulamanın ötesine, sistemin yaşamına taşır.

Gelecekteki her gereksinimi tahmin etmeyecek ya da her başarısızlığı önlemeyeceksiniz. Amaç bu değil. Amaç bugün bildiklerimize uygun bir şey inşa etmek, yarın için kendimize gidecek bir yer bırakmak ve gerçeklik işbirliği yapmadığında bir planımızın olmasıdır.

Bugün için inşa edin. Yarın için planlayın. Başarısızlık için planlayın. Bu üç merceği tekrar tekrar kullanacağız.

Mimarın Burada Karar Verdikleri

• Gerçek hacimlerin ve büyümenin ne olduğu ve hangi sayıların tasarımı değiştireceği.
• İşin henüz dile getirmediği örtük gereksinimlerin neler olduğu.
• Yarının sistemini bugün inşa etmeden bugünün tasarımının yarınınkine nasıl evrilebileceği.
• Bir şey bozulduğunda ne olacağı: kurtarma, mutabakat ve izleme.