Apa yang direkomendasikan untuk mendokumentasikan tumpukan teknologi IT, termasuk hubungannya satu sama lain, dalam basis data grafik?

Bekerja untuk perusahaan besar dengan lebih dari 500 staf TI dan lebih dari 1.000 server, dengan masing-masing server menjalankan aplikasi bisnisnya sendiri, kami memiliki informasi yang luar biasa dan tantangan koordinasi dalam mengetahui anggota staf TI mana yang harus dihubungi untuk server mana. Masalah koordinasi diperparah dengan staf TI yang berbeda bertanggung jawab atas berbagai lapisan tumpukan TI. Misalnya, ada tim berbeda yang bertanggung jawab untuk perangkat keras, virtualisasi, sistem operasi, server aplikasi dan aplikasi itu sendiri.

Mempertimbangkan tantangan ini, dalam DevOps ada persyaratan untuk mendefinisikan dan mendokumentasikan semua komponen yang membentuk berbagai tumpukan teknologi dalam lingkungan TI. Secara tradisional ini mungkin telah dicapai dengan solusi CMDB kesopanan.

Saya telah menyelidiki solusi CMDB khas seperti BMC Atrium dan lainnya untuk tujuan ini, masalahnya adalah mereka berhenti pada tingkat mendokumentasikan aset TI sendiri, pada tingkat tinggi, sesuai kerangka kerja ITIL, tetapi untuk tidak membahas dokumentasi Stack Teknologi IT secara rinci. Saya juga telah menyelidiki alat-alat seperti Puppet , Ansible dan Salt , tetapi alat-alat ini lebih fokus pada penyebaran dan konfigurasi perangkat lunak, dan bukan pada koordinasi orang-orang di sekitar perangkat lunak.

Solusi yang bisa diterapkan misalnya, akan mendefinisikan berbagai konsep, bersama dengan atribut kunci yang penting untuk konsep-konsep ini:

Perangkat keras
Virtualisasi
Sistem operasi
Server aplikasi
Aplikasi

Konsep-konsep ini kemudian akan dikaitkan satu sama lain dalam hal hubungan mereka untuk membentuk solusi. Misalnya, suatu aplikasi akan tergantung pada server aplikasi, yang akan tergantung pada sistem operasi, dll., Bersama-sama solusi ini akan ditentukan di "Sistem Keuangan". Setelah mendefinisikan sistem, semua metadata yang terkait dengan sistem ini akan ditangkap untuk memfasilitasi koordinasi untuk setiap lapisan dalam tumpukan. Yaitu koordinasi staf dukungan teknis untuk setiap lapisan.

Tujuan dari solusi semacam itu adalah untuk melakukan berbagai pertanyaan terhadap tumpukan teknologi, seperti:

Untuk menentukan siapa yang mendukung komponen mana
Komponen mana yang kedaluwarsa
Komponen mana yang perlu ditambal

Dengan pemikiran ini, alat open source apa yang ada untuk mendefinisikan semua komponen tumpukan teknologi IT, termasuk hubungannya satu sama lain, dalam basis data grafik seperti Neo4J?

— Grant Durr
sumber

Berapa ukuran organisasi dalam hal sistem, personel, tim, dll.?

— 030

Untuk memberikan lebih banyak wawasan tentang alasan penutupan, ada terlalu banyak pertanyaan di sini, sebagian adalah tentang CMDB dan poin lainnya adalah tentang audit dan kepatuhan. Tidak ada peluru perak untuk ini dan ini sangat tergantung pada lingkungan Anda yang sebenarnya dan apa yang Anda gunakan. Apakah Anda menggunakan manajer konfigurasi? Apakah Anda melihat-lihat dan tidak menemukan alat yang sesuai dengan kebutuhan Anda? Seperti pertanyaan ini adalah jajak pendapat untuk saran dan semua orang akan memiliki solusi yang disukai, itu tidak cocok untuk situs ini, cobalah untuk melihat alat yang ada dan untuk menanyakan sesuatu yang lebih spesifik setelah dilakukan.

— Tensibai

ini mungkin terdengar aneh tetapi bisa juga solusi pergudangan perusahaan yang lebih umum tetapi dapat disesuaikan melakukannya juga?

— Peter Muryshkin

Terima kasih dan selamat atas hasil editnya, itu pertanyaan yang jauh lebih bisa dijawab sekarang. Saya masih belum mendapatkan dorongan untuk memiliki basis data grafik di bawahnya (itu tidak perlu) tetapi saya menganggap ini bisa dihilangkan jika ada jawaban yang benar.

— Tensibai

@J. Doe Suatu solusi pergudangan perusahaan mungkin berhasil, tetapi adakah solusi open source yang akan memecahkan masalah seperti itu. Percaya atau tidak, kami memiliki banyak alat, tidak ada yang benar-benar dapat mengatasi masalah ini. Di sisi manajemen server kami menggunakan BMC ADDM, tetapi kunci pendek dari alat ini adalah server-centric, bukan application-centric. Sebagai akibatnya ketika satu server menampung banyak aplikasi, tidak ada cara mudah untuk mengaitkan beberapa pemilik aplikasi karena hanya asosiasi di tingkat server yang dipenuhi.

— Grant Durr

Mempertimbangkan paragraf pertama Anda, organisasi yang Anda gambarkan adalah organisasi yang sangat sunyi, yang cenderung dihindari oleh organisasi DevOps.

Mempertimbangkan tantangan ini, dalam DevOps ada persyaratan untuk mendefinisikan dan mendokumentasikan semua komponen yang membentuk berbagai tumpukan teknologi dalam lingkungan TI. Secara tradisional ini mungkin telah dicapai dengan solusi CMDB kesopanan.

Apa yang Anda gambarkan di sini bisa ITIL, yang merupakan sistem manajemen yang membutuhkan dokumentasi dan Anda mencampurnya dengan fakta bahwa tim DevOps biasanya akan mendefinisikan lapisan yang mendasari sebagai kode, karena itu akan kembali ke dokumentasi pengembangan dengan peringatan Kode. Dokumentasi sering terlihat dalam metodologi Scrum untuk metodologi pengembangan yang gesit (iterasi cepat dan pendek yang mengarah pada solusi kerja minimal pada akhir iterasi)

Penafian untuk sisa jawaban ini: Saya tahu lebih banyak tentang chef dan inspec dan itulah mengapa saya menganggap mereka sebagai contoh di sini; tetapi mereka bukan satu-satunya alat yang ada di pasar, saya tidak akan membuka perdebatan tentang mereka karena yang lebih baik adalah yang Anda lebih nyaman.

Dengan demikian sisa pertanyaannya sedikit bias dan saya, secara pribadi, tidak menemukan organisasi yang mendokumentasikan hubungan lapisan yang Anda gambarkan lebih dari infrastruktur sebagai kode dan dokumentasi kode sistem manajemen konfigurasi. (Sekali lagi, ini tidak berarti tidak ada yang melakukannya, saya tidak pernah mendengarnya).
Untuk mengilustrasikan dari perusahaan saya di lingkungan koki, buku resep aplikasi akan mendeklarasikan dependensinya (tomcat, jboss, nginx / php dan di mana OS, membutuhkan mount point untuk beberapa data bersama dan nama skema DB-nya) dan memaparkan URI layanannya ke dikonsumsi oleh chef untuk konfigurasi aplikasi lain, ini seperti mendefinisikan 'Sistem Keuangan' Anda dan dokumentasi untuknya ada di buku resep aplikasi ini README, dengan beberapa file lagi jika benar-benar diperlukan.

Sistem manajemen konfigurasi biasanya memiliki tempat pelaporan pusat, "chef-server" untuk data dan "mengelola UI" untuk presentasi di dunia chef "ansible tower" untuk dunia yang memungkinkan untuk menyebutkan dua di antaranya, tetapi mereka biasanya lebih bertujuan memberi pengawasan terhadap keseluruhan sistem yang dikelola daripada grafik dependensi.

Yang mengatakan, untuk chef, chef-server juga bertindak sebagai CMDB yang dapat Anda query dengan berbagai alat (ini mengembalikan data JSON dari permintaan HTTP), dependensi antar aplikasi dapat diekspresikan dengan berbagai cara dan tidak ada 'di luar kotak' metode, setiap perusahaan akan memiliki cara sendiri untuk mendeklarasikannya dalam sistem untuk tujuan konfigurasi dan dengan demikian Anda dapat memanfaatkan ini untuk membangun grafik Anda, tetapi itu ada di pihak Anda.

Dalam infrastruktur sebagai sudut pandang kode, kebutuhan infrastruktur akan disimpan dengan aplikasi, masih aplikasi yang tahu apa yang dibutuhkan di bawah sebagai perangkat tengah, OS mana, dengan lokal mana, apa dependensi layanan lain dan layanan apa penawaran aplikasi ini).

Hal terakhir yang dapat saya pikirkan jika Anda ingin mengelola dependensi itu hanya untuk dokumentasi adalah alat-alat seperti glpi yang terutama merupakan CMDB dan sistem tiketing, mengambil keuntungan dari mendokumentasikan aset dan hubungannya untuk dapat mengetahui apa yang terpengaruh ketika Anda membuka tiket mengatakan aplikasi sedang down. ditambah dengan ng-inventaris memungkinkan untuk permintaan negara sistem dan dengan demikian dapat memenuhi permintaan Anda untuk kebutuhan tambalan, tetapi menurut saya ini adalah tugas sistem audit, seperti bisa melakukan inspeksi terintegrasi dalam koki yang dijalankan untuk contoh, seperti tahap berikutnya akan adalah untuk memperbaiki sistem yang sudah ketinggalan zaman dengan memperbarui / menambalnya.

— Tensibai
sumber