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?
sumber
Jawaban:
Mempertimbangkan paragraf pertama Anda, organisasi yang Anda gambarkan adalah organisasi yang sangat sunyi, yang cenderung dihindari oleh organisasi DevOps.
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.
sumber