Bir BT teknolojisi yığınını, birbirleriyle olan ilişkilerini de içeren bir grafik veritabanında belgelemek için ne önerilir?

500'den fazla BT personeli ve 1.000'den fazla sunucuyla büyük bir şirket için çalıştığımız her sunucu kendi iş uygulamalarını çalıştırırken, hangi BT personelinin hangi sunucu için iletişim kuracağını bilmek konusunda muazzam bir bilgi ve koordinasyon zorluğumuz var. Koordinasyon sorunu, BT yığınının farklı katmanlarından sorumlu olan farklı BT personeli ile birleştirilir. Örneğin, donanım, sanallaştırma, işletim sistemleri, uygulama sunucuları ve uygulamaların kendilerinden sorumlu farklı ekipler vardır.

Bu zorluk göz önüne alındığında, DevOps içinde bir BT ortamında çeşitli teknoloji yığınlarını oluşturan tüm bileşenleri tanımlama ve belgeleme zorunluluğu vardır. Geleneksel olarak bu uygun bir CMDB çözeltisi ile başarılmış olabilir.

BMC Atrium ve diğerleri gibi tipik CMDB çözümlerini bu amaçla araştırdım , ancak sorun IT varlıklarının ITIL çerçevesine göre yüksek düzeyde belgelenmesi düzeyinde, ancak belgeleri ele almamaları BT Teknoloji Yığını ayrıntılı olarak. Ayrıca Kukla , Ansible ve Tuz gibi araçları da araştırdım , ancak bu araçlar daha çok yazılım dağıtımı ve yapılandırmasına odaklanıyor, insanların yazılım çevresindeki koordinasyonuna değil.

Örneğin uygulanabilir bir çözüm, çeşitli kavramları ve bu kavramlar için önemli olan temel özellikleri tanımlar:

• Donanım
• Sanallaştırma
• İşletim sistemleri
• Uygulama sunucuları
• Uygulamalar

Bu kavramlar daha sonra çözümler oluşturmak için ilişkileri açısından birbirleriyle ilişkilendirilecektir. Örneğin, bir uygulama bir işletim sistemine, vb. Bağlı olacak bir uygulama sunucusuna bağlı olacaktır. Birlikte bu çözüm "Finans Sistemi" nde tanımlanacaktır. Bir sistem tanımlandıktan sonra, bu sistemlerle ilişkili tüm meta veriler, yığındaki her katman için koordinasyonu kolaylaştırmak amacıyla yakalanır. Yani her katman için teknik destek personelinin koordinasyonu.

Böyle bir çözümün amacı, teknoloji yığınlarına karşı aşağıdakiler gibi çeşitli sorgular yapmak olacaktır:

• Kimin hangi bileşenleri desteklediğini belirlemek
• Hangi bileşenler güncel değil
• Hangi bileşenlerin yamalanması gerekiyor

Bunu akılda tutarak, bir IT teknolojisi yığınının birbirleriyle olan ilişkileri de dahil olmak üzere tüm bileşenlerini Neo4J gibi bir grafik veritabanında tanımlamak için hangi açık kaynak araçları var?

İlk paragrafınızı göz önünde bulundurduğunuzda, tanımladığınız kuruluş, son derece sessiz bir kuruluştur; bu, bir DevOps kuruluşunun tam olarak kaçınma eğilimindedir.

Bu zorluk göz önüne alındığında, DevOps içinde bir BT ortamında çeşitli teknoloji yığınlarını oluşturan tüm bileşenleri tanımlama ve belgeleme zorunluluğu vardır. Geleneksel olarak bu uygun bir CMDB çözeltisi ile başarılmış olabilir.

Burada açıkladığınız şey, dokümantasyon gerektiren bir yönetim sistemi olan ITIL olabilir ve bir DevOps ekibinin genellikle alttaki katmanları kod olarak tanımlayacağı gerçeğiyle karıştırırsınız, bu nedenle Kod uyarıları ile herhangi bir geliştirme dokümanına geri döner. Çevik bir gelişim metodolojisi için Scrum metodolojisinde sıklıkla görülen belgelerdir (yinelemenin sonunda minimum çalışma çözümüne yönelik hızlı ve kısa iterasyonlar)

Bu cevabın geri kalan kısmı için sorumluluk reddi: Daha fazla şef ve müfettiş biliyorum ve bu yüzden onları burada örnek alıyorum; ancak piyasada mevcut olan tek araç onlar değil, onlarla ilgili bir tartışma açmayacağım çünkü daha iyi olanı daha rahat olanı.

Sorunun geri kalanı biraz önyargılı olduğu için, şahsen, koddan ve konfigürasyon yönetim sistemi kod dokümantasyonu olarak altyapıdan daha fazlasını tanımladığınız katman ilişkisini belgeleyen bir organizasyonla karşılaşmadım. (Yine, bu kimsenin yapmadığı anlamına gelmiyor, daha önce hiç duymadım).
Bir şef ortamında şirketimden göstermek için, bir uygulama yemek kitabı bağımlılıklarını (tomcat, jboss, nginx / php ve hangi işletim sistemi, bazı paylaşılan veriler ve çoğunlukla DB şema adı için montaj noktalarına ihtiyaç duyduğunu) açıklayacak ve hizmet URI'lerini diğer uygulamalar yapılandırma için şef tarafından tüketilebilir, bu ses 'Finans Sistemi' tanımlamak gibi ve bunun için gerçekten gerekli ise biraz daha fazla dosya ile, bu uygulama yemek kitabı README olduğunu.

Yapılandırma yönetim sistemleri genellikle merkezi bir raporlama yerine sahiptir, veriler için "şef-sunucu" ve şef dünyasında sunum için bir "kullanıcı arayüzü", ansible dünyanın ikisini belirtmek için "ansible tower", ancak genellikle daha fazla gözetim vermeyi amaçlarlar. bağımlılıkları grafikten daha iyi yönetilen sistem.

Bununla birlikte, şef için, şef-sunucu aynı zamanda çeşitli araçlarla sorgulayabileceğiniz bir CMDB olarak hareket eder (HTTP isteklerinden JSON verilerini döndürür), uygulamalar arası bağımlılıklar çeşitli yollarla ifade edilebilir ve 'kutunun dışında' yoktur yönteminde, her şirketin bunları yapılandırma amacıyla sistemde bildirmek için kendi yolu olacaktır ve bu nedenle grafiğinizi oluşturmak için bundan yararlanabilirsiniz, ancak bu sizin tarafınızda.

Kod bakış açısı olarak bir altyapıda uygulama ile altyapı ihtiyaçları korunacak, hala orta eşya olarak neye ihtiyaç duyduğunu bilen uygulama, hangi işletim sistemi, hangi yerel ayar, diğer hizmet bağımlılıkları ve hangi hizmetler bu uygulama teklifi).

Belgeleme için bu bağımlılıkları yönetmek istiyorsanız düşünebileceğiniz son şey , esas olarak bir CMDB ve bir biletleme sistemi olan glpi gibi araçlardır , açtığınızda neyin etkilendiğini söyleyebilmek için varlıkları ve ilişkilerini belgelemekten yararlanır başvurunun kapalı olduğunu belirten bir bilet. ng-envanter ile birleştiğinde sistem durumlarını sorgulamaya izin verir ve bu nedenle sorgunuzu yama ihtiyaçları için yerine getirebilir, ancak bence bu bir denetim sistemi görevidir, örneğin bir sonraki aşamada olduğu gibi örnekleme için bir şef çalıştırmasına entegre olabilir güncel olmayan sistemleri güncelleyerek / yama yaparak düzeltmek.