Cosa si consiglia di documentare uno stack tecnologico IT, inclusa la loro relazione reciproca, in un database grafico?

Lavorando per una grande azienda con oltre 500 dipendenti IT e oltre 1.000 server, con ogni server che esegue le proprie applicazioni aziendali, abbiamo una tremenda sfida di informazione e coordinamento nel sapere quale membro dello staff IT contattare per quale server. Il problema del coordinamento è aggravato dal fatto che il personale IT diverso è responsabile dei diversi livelli dello stack IT. Ad esempio, ci sono diversi team responsabili dell'hardware, della virtualizzazione, dei sistemi operativi, dei server delle applicazioni e delle applicazioni stesse.

Considerando questa sfida, all'interno di DevOps è necessario definire e documentare tutti i componenti che costituiscono i vari stack tecnologici all'interno di un ambiente IT. Tradizionalmente, ciò avrebbe potuto essere realizzato con una soluzione CMDB proprietaria.

Ho studiato soluzioni CMDB tipiche come BMC Atrium e altre a questo scopo, ma il problema è che si fermano a livello di documentazione delle risorse IT stesse, ad alto livello, come per il framework ITIL, ma per non affrontare la documentazione dello stack IT Technology in dettaglio. Ho anche studiato strumenti come Puppet , Ansible e Salt , ma questi strumenti si concentrano maggiormente sulla distribuzione e configurazione del software e non sul coordinamento delle persone attorno al software.

Una soluzione praticabile, ad esempio, definirebbe i vari concetti, insieme agli attributi chiave importanti per questi concetti:

• Hardware
• virtualizzazione
• Sistemi operativi
• Server delle applicazioni
• applicazioni

Questi concetti verrebbero quindi associati tra loro in termini di relazioni al fine di formare soluzioni. Ad esempio, un'applicazione dipenderebbe da un server delle applicazioni, che dipenderebbe da un sistema operativo, ecc. Insieme, questa soluzione sarebbe definita nel "Sistema finanziario". Dopo aver definito un sistema, tutti i metadati associati a questi sistemi verrebbero catturati al fine di facilitare il coordinamento per ogni livello nello stack. Vale a dire il coordinamento del personale di supporto tecnico per ogni livello.

Lo scopo di tale soluzione sarebbe di fare varie domande contro stack tecnologici, come:

• Per determinare chi supporta quali componenti
• Quali componenti non sono aggiornati
• Quali componenti devono essere patchati

Con questo in mente, quali strumenti open source esistono per definire tutti i componenti di uno stack di tecnologia IT, inclusa la loro relazione reciproca, in un database grafico come Neo4J?

Considerando il tuo primo paragrafo, l'organizzazione che stai descrivendo è un'organizzazione estremamente insensata, che è esattamente ciò che un'organizzazione DevOps tende ad evitare.

Considerando questa sfida, all'interno di DevOps è necessario definire e documentare tutti i componenti che costituiscono i vari stack tecnologici all'interno di un ambiente IT. Tradizionalmente, ciò avrebbe potuto essere realizzato con una soluzione CMDB proprietaria.

Quello che stai descrivendo qui potrebbe essere ITIL, che è un sistema di gestione che richiede documentazione e lo mescoli con il fatto che un team DevOps di solito definisce i livelli sottostanti come codice, in quanto tale ritorna a qualsiasi documentazione di sviluppo con le avvertenze del codice è la documentazione spesso vista nella metodologia Scrum per una metodologia di sviluppo agile (iterazioni rapide e brevi che mirano a una soluzione di lavoro minima alla fine dell'iterazione)

Dichiarazione di non responsabilità per il resto di questa risposta: so di più di chef e inspec ed è per questo che li prendo come esempio qui; ma non sono gli unici strumenti esistenti sul mercato, non aprirò un dibattito su di essi poiché quello migliore è quello con cui ti senti più a tuo agio.

Di conseguenza, il resto della domanda è un po 'distorto e io, personalmente, non ho incontrato un'organizzazione che documentasse la relazione di livello che descrivi più dell'infrastruttura come codice e documentazione del codice del sistema di gestione della configurazione. (Ancora una volta, questo non significa che nessuno lo faccia, non ne ho mai sentito parlare).
Per illustrare la mia azienda in un ambiente da chef, un libro di cucina dell'applicazione dichiarerà le sue dipendenze (tomcat, jboss, nginx / php e su quale sistema operativo, i punti di montaggio necessari per alcuni dati condivisi e il suo nome di schema DB principalmente) ed esponendo i suoi URI di servizi a essere consumato dallo chef per la configurazione di altre applicazioni, questo sembra definire il tuo "Sistema finanziario" e la documentazione relativa è su questo libro di cucina README dell'applicazione, con alcuni file in più se veramente necessari.

I sistemi di gestione della configurazione di solito hanno un posto di reporting centrale, "chef-server" per i dati una "gestione dell'interfaccia utente" per la presentazione nel mondo degli chef "torre di risposta" per il mondo di cui rispondere, per nominarne due, ma di solito mirano più a dare una supervisione di il sistema gestito complessivo che rappresentare graficamente le dipendenze.

Detto questo, per chef, lo chef-server funge anche da CMDB su cui è possibile eseguire query con vari strumenti (restituisce dati JSON da richieste HTTP), le dipendenze tra le applicazioni possono essere espresse in vari modi e non c'è "out of the box" metodo, ogni azienda avrà il suo modo di dichiararli nel sistema ai fini della configurazione e come tale potresti sfruttare questo per costruire il tuo grafico, ma è dalla tua parte.

In un'infrastruttura come punto di vista del codice, le esigenze dell'infrastruttura verrebbero mantenute con l'applicazione, è ancora l'applicazione a sapere di cosa ha bisogno come middleware, quale sistema operativo, con quale locale, quali sono le dipendenze di altri servizi e quali servizi questa offerta di applicazione).

L'ultima cosa che mi viene in mente se vuoi gestire quelle dipendenze solo per la documentazione sono strumenti come glpi che è principalmente un CMDB e un sistema di ticketing, sfrutta la documentazione delle risorse e la loro relazione per essere in grado di dire cosa è influenzato quando apri un ticket che indica che un'applicazione è inattiva. accoppiato con ng-inventario permette di interrogare gli stati del sistema e come tale può soddisfare la tua richiesta per esigenze di patch, ma a mio avviso si tratta di un compito del sistema di controllo, come potrebbe fare un controllo integrato all'interno di una corsa di chef per esempio, come farebbe la fase successiva essere per riparare i sistemi obsoleti aggiornandoli / rattoppandoli.