Bir kutuda iki kişi (eğer yapabilirseniz) ve belgelerdeki herkes (her zaman).
BT bağlamında, "ikisi bir arada", yedeklilik ve artırılmış güvenilirlik sağlamak üzere birlikte çalışmak üzere tasarlanmış iki sunucu veya bileşen anlamına gelir. Bu kurulum, bileşenlerden birinin arızalanması durumunda diğerinin onun işlemlerini devralmasını ve böylece hizmetin sürekliliğini sağlamasını sağlayabilir. "Bir kutuda iki" olmasının amacı, yüksek kullanılabilirlik ve olağanüstü durum kurtarma sağlamaktır. Bu aynı zamanda bir organizasyondaki insan rolleri için de geçerlidir; ancak, nadiren uygulanmaktadır.
Alakalı bir Analytics örneğine bakalım. Hepimiz muhtemelen şirketimizde veya kuruluşumuzda, Analytics için "uygun" kişi olan bir kişiyi tanıyoruz. Mike's Report veya Jane's Dashboard gibi kendi adlarını taşıyan raporlara veya gösterge panolarına sahip olanlar onlardır. Elbette analitiği bilen başka insanlar da var ama bunlar en zor şeyleri nasıl yapacaklarını bilen ve son teslim tarihlerinde nasıl başarılı olunacağını bilen gerçek şampiyonlar. Mesele şu ki, bu insanlar yalnız kalıyor. Çoğu durumda baskı altındayken kimseyle çalışmazlar çünkü bu onları yavaşlatabilir ve sorun burada başlar. Bu kişiyi kaybedeceğimizi asla düşünmüyoruz. Tipik "diyelim ki onlara bir otobüs çarptı" ifadesinden veya mevcut iş piyasası fırsatlarından yararlanan bir örnek kullanmaktan kaçınacağım ve "piyangoyu kazandılar!" gibi olumlu bir şey söyleyeceğim, çünkü pozitif olmak için hepimiz üzerimize düşeni yapmalıyız. bugünlerde.
Hikayesi
Pazartesi sabahı gelir ve analitik uzmanımız ve şampiyon MJ istifasını sunar. MJ piyangoyu kazandı ve şimdiden dünyayı umursamadan ülkeyi terk etti. Ekip ve MJ'i tanıyan insanlar heyecanlanır ve kıskanır, ancak iş gitmelidir. Şimdi, MJ'in yaptıklarının değeri ve gerçekliği anlaşılmak üzere. Analitiklerin nihai olarak yayınlanmasından ve doğrulanmasından MJ sorumluydu. Analitiği herkese sağlamadan önce her zaman verimliliği artırabilecek veya bu zor değişikliği yapabilecek gibi görünüyorlardı. Kimse bunun nasıl yapıldığını gerçekten umursamadı ve yeni olduğu gerçeğinden emindi ve MJ, Analytics'in bireysel bir Rock Yıldızıydı, bu nedenle bir düzeyde özerklik bahşedildi. Şimdi takım parçaları toplamaya başladıkça, istekler, günlük sorunlar, değişiklik istekleri kayıpta ve çırpınmaya başlıyorlar. Raporlar / Panolar bilinmeyen durumlarda bulunur; bazı varlıklar hafta sonu güncellenmedi ve nedenini bilmiyoruz; insanlar neler olup bittiğini ve ne zaman düzeltileceğini soruyor, MJ'in yapıldığını söylediği düzenlemeler görünmüyor ve neden olduğu hakkında hiçbir fikrimiz yok. Takım kötü görünüyor. Bu bir felaket ve şimdi hepimiz MJ'den nefret ediyoruz.
Dersler
Bazı kolay ve bariz çıkarımlar var.
- Bir kişinin yalnız çalışmasına asla izin vermeyin. Kulağa hoş geliyor ama daha küçük çevik ekiplerde bunu gerçekleştirmek için ne zamanımız ne de insanlarımız var. İnsanlar gelir ve gider, görevler çoktur, bu yüzden üretkenlik adına böl ve yönet.
- Herkes bilgisini paylaşmalı. Ayrıca kulağa hoş geliyor ama doğru kişi veya kişilerle mi paylaşıyoruz? Birçok piyango kazananının iş arkadaşı olduğunu unutmayın. Bilgi paylaşımı oturumları yapmak aynı zamanda görevlerden alınan zamanı da alır ve çoğu insan becerilere ve bilgiye yalnızca tam ihtiyaç duyulduğu anda yatırım yapar.
Peki, herkesin uygulayabileceği ve arkasında durabileceği bazı gerçek çözümler nelerdir?
Yapılandırma Yönetimi ile başlayalım. Bunu birkaç benzer konu için şemsiye terim olarak kullanacağız.
- Değişim Yönetimi: Yazılım sistemlerindeki değişiklikleri yapılandırılmış ve sistematik bir şekilde planlama, uygulama ve kontrol etme süreci. Bu süreç, değişikliklerin kontrollü ve verimli (geri dönebilme özelliği ile), mevcut sistemde minimum aksama ve kuruma maksimum fayda sağlayacak şekilde yapılmasını sağlamayı amaçlar.
- Proje Yönetimi: Yazılım geliştirme projelerinin zamanında, bütçe dahilinde ve istenen kalite standartlarında tamamlanmasını sağlamak için planlama, organizasyon ve kontrol. Proje hedeflerine ulaşmak ve yazılım ürününü zamanında teslim etmek için yazılım geliştirme yaşam döngüsü boyunca kaynakların, faaliyetlerin ve görevlerin koordinasyonunu içerir.
- Sürekli Entegrasyon ve Sürekli Teslimat (CI/CD): Yazılımın oluşturulmasını, test edilmesini ve devreye alınmasını otomatikleştirme süreci. Sürekli Entegrasyon, kod değişikliklerinin paylaşılan bir havuzda düzenli olarak birleştirilmesini ve geliştirme sürecinin erken aşamalarında hataları tespit etmek için otomatikleştirilmiş testlerin çalıştırılmasını gerektirir. Sürekli Teslimat/Dağıtım, test edilmiş ve doğrulanmış kod değişikliklerinin üretime otomatik olarak bırakılmasını içerir ve yeni özelliklerin ve iyileştirmelerin hızlı ve sık bir şekilde yayınlanmasına olanak tanır.
- Sürüm Kontrolü: Özel yazılım araçlarını kullanarak kaynak kodunda ve diğer yazılım yapılarında zaman içinde meydana gelen değişiklikleri yönetme süreci. Geliştiricilerin bir kod tabanı üzerinde işbirliği yapmasına, eksiksiz bir değişiklik geçmişi tutmasına ve ana kod tabanını etkilemeden yeni özellikleri denemesine olanak tanır.
Yukarıdakilerin tümü, iyi yazılım geliştirme uygulamalarına atıfta bulunur. İşi yönlendiren ve yürüten analizler, karar vermede görev açısından kritik öneme sahip olduklarından daha azını hak etmezler. Tüm analitik varlıkları (ETL işleri, semantik tanımlar, metrik tanımları, raporlar, panolar, hikayeler…vb.), tasarım için görsel bir arayüze sahip kod parçacıklarıdır ve görünüşte küçük değişiklikler operasyonları mahvedebilir.
Yapılandırma Yönetimini kullanmak, iyi durumda çalışmaya devam etmemizi sağlar. Varlıklar, ömürleri boyunca neler olduğunu görebilmemiz için sürümlendirilir, kaydedilen ilerleme ve zaman çizelgeleriyle birlikte kimin ne üzerinde çalıştığını biliriz ve üretimin devam edeceğini biliriz. Herhangi bir saf sürecin kapsamadığı şey, bilginin aktarılması ve şeylerin neden böyle olduğunun anlaşılmasıdır.
Her sistemin, veritabanının ve analiz aracının kendine has tuhaflıkları vardır. Hızlı veya yavaş gitmelerini sağlayan şeyler, belirli bir şekilde davranmalarını veya istenen bir sonucu vermelerini sağlayan öğeler. Bunlar, bir sistemdeki veya küresel düzeydeki ayarlar veya varlık tasarımında olması gerektiği gibi çalışmasını sağlayan şeyler olabilir. Sorun şu ki, bunların çoğu zamanla öğreniliyor ve her zaman bunları belgeleyecek bir yer yok. Artık uygulamanın nasıl yürütüleceğini kontrol etmediğimiz ve bunu mümkün olduğunca hızlı yapması için tedarikçiye güvendiğimiz Bulut sistemlerine geçsek bile, tam olarak aradığımız şeyi ortaya çıkarmak için varlıklarımızda tanımların ince ince ayarlanması devam ediyor. Bu bilgi, başkaları tarafından kullanılabilir hale getirilerek yakalanması ve paylaşılması gereken şeydir. Bu bilgi, varlıkların belgelendirilmesinin bir parçası olarak gerekli olmalı ve sürüm kontrolü ve CI/CD kontrol ve onay sürecinin ayrılmaz bir parçası haline getirilmelidir ve hatta bazı durumlarda yapılması ve yapılmaması gerekenlerin yayınlanmasından önceki bir kontrol listesinin parçası olarak bile yapılmalıdır. Yapmak.
Analitik süreçlerimizdeki kısayolları veya eksiklikleri örtecek sihirli cevaplar veya yapay zeka yoktur. Değişiklikleri izlemek, tüm varlıkları sürümlendirmek ve geliştirme sürecini belgelemeye ve bilgi toplamaya yardımcı olmak için bir sisteme yatırım yaparak verileri ve analitiği akan ekibin boyutu ne olursa olsun bir zorunluluktur. Süreçlere ve zamana önceden yatırım yapmak, daha sonra analitiğimizin sağlıklı bir durumunu sürdürmek için bir şeyler bulmak için boşa harcanan bir ton zaman kazandıracaktır. Bir şeyler olur ve MJ'ler ve diğer piyango kazananları için bir sigorta poliçesine sahip olmak en iyisidir.
