Çoklu hesap yönetim sistemi geliştirirken önce arayüzü değil, cihaz katmanındaki alanları ve yaşam döngüsünü tanımlamak gerekir. Yanlış bir soyutlama, hesap sayısı arttığında veya cihaz türleri değiştiğinde zincirleme yeniden geliştirmelere yol açar.
Bir çoklu hesap yönetim sistemi geliştirirken ilk sürüm çoğu zaman arayüzden düşünülür: bir hesap listesi oluşturulur, her hesaba bir tarayıcı profili bağlanır ve ardından işlemler için arayüzler çağrılır. Sistem gerçekten çalışmaya başlayana kadar bu yeterli görünür.
İlk uygulama genellikle son derece doğrudandır. Hesap A profil 001'i, hesap B profil 002'yi gösterir; hesap C ise bir bulut telefona bağlanır. Sorunlar üç yerde ortaya çıkar: operasyon ekibi bir makinenin bozulduğunu söyler ve hesap A'nın bulut telefona taşınıp taşınamayacağını sorar; bunun cevabı veritabanını değiştirmek, manuel işlem yapmak ve risk almaktır. Yeni bir cihaz kaynağı eklenir ve nasıl bağlanacağı sorulduğunda hesap modülünün yeniden düzenlenmesi gerektiği anlaşılır. Ya da aynı hesabın sabah tarayıcı ortamını, öğleden sonra bulut telefonu kullanması istenir; bunu zaman dilimlerine göre düzgün şekilde yürütmek neredeyse imkânsızdır.
Bu üç senaryo ilgisiz görünür, ancak tek bir temel nedenleri vardır: hesap varlığının içine ona ait olmayan şeyler konmuştur. Şu anda oturum açılan cihaz, geçmişte kullanılan cihazlar, parmak izi parametreleri ve çıkış adresi doğrudan hesabın üzerinde tutulur. Böylece cihaz değiştirmek hesap değiştirmekle aynı anlama gelir ve tek bir değişiklik tüm sistemi etkiler.
Cihaz ayrı bir nesne türü olmalı
Ayrıştırmadan sonra hesaplar ile cihazlar arasında çoktan çoğa ilişki olmalıdır. Hesap parmak izi saklamaz; yalnızca o anda hangi cihaza bağlı olduğunu kaydeder. Cihaz değiştirme atomik bir işlem olarak yapılmalı, geçmiş bağlamalar ayrı bir tabloda tutulmalı ve her cihazın dışarıya sunulan tek referans olan benzersiz bir kimliği olmalı; durum bilgisi gerçek zamanlı sorgulanabilmelidir.
Bunun amacı modeli daha güzel göstermek değildir. Operasyonun yapmak istediği bir ayarlama ile geliştiricinin değiştirmesi gereken kod arasındaki mesafeyi kısaltmaktır; bu mesafe cihaz sayısıyla birlikte büyür.
Soyutlama katmanının netleştirmesi gereken dört alan grubu
Ölçeklenebilir bir cihaz soyutlamasının dışarıya yalnızca dört şeyi açıklaması gerekir.
- Ortam kimliği: benzersiz ve kararlı olmalıdır. Üst katmanlar ortama yalnızca bu kimlikle başvurur; alt düzey numaralar, kapsayıcı adları ve süreç kimlikleri dışarı açılmamalıdır
- Çıkış bağlaması: ortamın hangi ağ çıkışını kullandığı ve buna bağlı saat dilimi, dil ve DNS ayarlarının bir bütün olarak eşleşip eşleşmediği. Çıkışı ayrı soyutlamak, ortamın kendisini değiştirmeden çıkışı değiştirmeyi sağlar
- Durum: oluşturuluyor, başlatılmaya hazır, çalışıyor, bir görev tarafından kullanılıyor, anormal, geri kazanılmayı bekliyor. Durum modeli olmadan havuzlama ve geri kazanım yönetilemez
- Yaşam döngüsü: oluşturma, başlatma, kullanım, bırakma ve geri kazanımı kimin tetiklediği; görev zaman aşımında ne olacağı; ortamda hata oluştuğunda kapanışı kimin yöneteceği
Durum ve yaşam döngüsü sık sık tek bir alanda birleştirilir. Bu en kolay ama aynı zamanda en pahalı yaklaşımdır. Durum, ortamın şu anda nasıl olduğunu; yaşam döngüsü ise sıradaki adımı kimin yapabileceğini açıklar. Üretimde gerçek sorunlar neredeyse her zaman ikinci noktada çıkar: görev çöker ve kimse ortamı bırakmaz ya da ortam hâlâ çalışırken geri kazanılır ve çıkışın değiştiği ancak bir sonraki başlatmada fark edilir.
Yanlış soyutlamanın bedeli ölçeklenirken çıkar
On ortam varken hiçbir şey fark edilmeyebilir. Sayı onlarca veya yüzlerce olduğunda sorunlar aynı anda patlar:
- Yeni bir cihaz türü eklemek hesap modülünde değişiklik gerektirir ve regresyon kapsamı cihaz katmanından hesap katmanına genişler
- Cihaz değiştirmek veritabanı değişikliği gerektirir; operasyon ekibi dokunmaktan çekinir ve sistem giderek yalnızca geliştiricilerin bakım yapabildiği bir yapıya dönüşür
- Durum ve kullanım kayıtları olmadan, anormal çıkışlardan sonra kalan ortamlar geri kazanılmaz ve zombi ortamlar birikir
- Üst katmandaki görevler, içerik ve otomasyon hesap ile cihaz arasında bire bir ilişki olduğu varsayımı üzerine kuruludur; bu varsayımı değiştirmek tüm zinciri yeniden kurmayı gerektirir
Farklı kaynaklardan gelen cihazların uygulaması birbirinden çok farklıdır; yerel tarayıcı ortamları ile bulut telefonlar farklı arayüzler kullanır. Soyutlama katmanının görevi bunları aynı arayüz kümesinin arkasına yerleştirmektir. Yeni bir cihaz türü eklemek için başlatma, durdurma ve durum sorgulamayı uygulayan bir adaptör eklemek yeterli olmalıdır; üst katman mantığı değişmemelidir. Soyutlamanın doğru olup olmadığını anlamanın basit bir yolu da şudur: yeni bir cihaz türü eklerken değiştirilmesi gereken kod tek bir dosyada mı kalıyor?
İlk aşamada mümkün olduğunca az şey yapın
Teknik model belirlendikten sonra arayüz çok daha doğal hâle gelir. Menüler yapılandırma, parametre ve loglara göre değil; hesaplar, görevler ve cihazlar gibi iş nesnelerine göre ayrı bölümlerde düzenlenmelidir. En görünür öğeler durum ve hatalar olmalıdır, çünkü kullanıcı kayıt sayısını değil, bir sorun olup olmadığını arar.
İşlev açısından ilk aşamada cihaz listesi, cihaz ekleme ve en küçük uçtan uca görev akışı yeterlidir. Menüyü mümkün olduğunca küçük tutun, önce tek bir işi baştan sona çalışır hâle getirin ve gerekmeyenleri sonraya bırakın.
Ortam yalıtımını sıfırdan uygulamak istemiyorsanız mevcut yetenekleri de kullanabilirsiniz. PurpleMark bağımsız ortamlar ve çıkış bağlaması sunar, gruplara göre toplu oluşturmayı ve durum sorgularını destekler. Üst katmanın yalnızca şablon, kullanım ve görev zamanlamasını uygulaması gerekir; böylece mühendislik emeği iş mantığına ayrılabilir.
Çoklu hesap sisteminin karmaşıklığı hiçbir zaman hesap sayısında değil, cihazların yaşam döngüsü yönetimindedir. Cihazı önce kimliği, çıkışı, durumu ve yaşam döngüsü olan bir kaynak olarak ele alın; böylece üst katman özellikleri her yeni eklemede baştan kurulmak zorunda kalmaz.
