Esistono anti-pattern ben noti nel campo dell'amministrazione di sistema? [chiuso]

Conosco alcuni schemi comuni che sembrano confondere quasi ogni progetto ad un certo punto del suo ciclo di vita:

1. Incapacità di interrompere le interruzioni
2. Componenti di terze parti che bloccano gli aggiornamenti
3. Ambienti non uniformi
4. Mancanza di monitoraggio e allerta
5. Ridondanza mancante
6. Mancanza di capacità
7. Cattiva gestione del cambiamento
8. Politiche di accesso troppo liberali o strette
9. I cambiamenti organizzativi sfocano negativamente la proprietà dell'infrastruttura

Speravo che ci fosse una biblioteca ben articolata di questi anti-schemi riassunti in un libro o in un sito web. Sono quasi certo che molte organizzazioni stanno imparando attraverso la prova con metodi di fuoco. In caso contrario iniziamo uno.

Lasciare le attività automatizzabili per essere automatizzate fino a quando non vengono eseguite manualmente richiede abbastanza tempo da non poter essere automatizzate, poiché svolgere le attività consuma manualmente tutto il tempo.

Viceversa, automazione prematura. Non c'è assolutamente bisogno di passare 3 N ore ad automatizzare un'attività one-shot che impiega N ore a fare manualmente (anche se è più divertente automatizzare che scorrere le cose a mano).

A. non testare il ripristino: un backup può essere verificato e corretto, ma come ripristinarlo?

Quanto tempo ci vuole, cosa ci vuole? Devi sapere per farlo in una situazione stressata ...

B. nessuna gestione della configurazione, nessuna uniformità - solo un cambiamento qua e là e penso di aver messo a punto alcuni qui ...

Chi sa come replicare un server ben fatto se tutte le stranezze non sono scritte e non ci sono configurazioni identiche nel negozio? Cosa succede se riesci a ripristinare le app di dati, ma non di configurazione?

C. nessun monitoraggio - non avere idea di come e che scatole stiano facendo

Questo è duplice: a) devi monitorare gli allarmi per reagire in tempo prima di esaurire alcune risorse o comportamenti strani eb) devi monitorare la tendenza a lungo termine per gestire la capacità (disco, CPU, RAM, rete,. ..).

D. nessuna ridondanza nel tuo cfg - cosa succede quando muore XX

Questo significa pianificare in anticipo ciò che desideri dal tuo amministratore di sistema.

Per me questi sono molto importanti.

Il modello più letale è quando il dipartimento di amministrazione del sistema (o l'intero IT) diventa un partecipante passivo nell'azienda. Cioè, sono visti come un self-service in cui ognuno ha idee già formate su come dovrebbero essere fatte le cose, il che prende in considerazione esclusivamente le esigenze degli utenti e non quelle dell'intero ecosistema IT nel suo insieme.

Il secondo modello più eclatante è quando il dipartimento di amministrazione del sistema si trasforma in una serie di pulsanti, ovvero tutti i software / strumenti vengono acquistati o sviluppati e installati da terze parti e l'amministrazione del sistema ottiene una formazione ufficiale e un manuale e quindi segue solo i manuali operativi e inoltrare al venditore tutto ciò che non è esplicitamente nel manuale. Questa situazione può essere molto comoda per gli amministratori di sistema (alcuni se non la maggior parte), ma si tratta di un disastro in attesa che si verifichi quando il fatto che nessuno sappia davvero come funziona l'intero sistema lo porterà a terra (pensa a interazioni sottili tra componenti e il gioco della colpa tra i fornitori).

1) eccessivamente promettente e insufficiente (ovvero mantenendo realistiche le aspettative degli utenti)

2) Non verificare i backup fino a quando non sono necessari.

modifica: intendevo il numero 2 per includere il ripristino di file / dati

Non monitorare i modelli di utilizzo dell'account AD come l'ora dell'ultimo accesso> 30 giorni

(Dobbiamo farlo per motivi di controllo, ma i risultati sono piuttosto scioccanti)

• Conservare le informazioni chiave nella cartella head / inbox / documenti di una persona. Se è importante, come i dettagli di contatto del fornitore, le chiavi di licenza, le istruzioni di configurazione, deve essere disponibile per tutti gli utenti del dipartimento che hanno l'autorità e potrebbe aver bisogno di accedervi e in un luogo standard.

• Chiedere alla persona che sa qualcosa di documentarlo. Questo suona bene perché sono la persona che ha le conoscenze, ma in realtà è male perché non possono facilmente dire qual è la conoscenza importante. Meglio avere qualcuno con cui confrontarsi, chiedere alla persona competente tutte le informazioni di cui ha bisogno e fargli documentare mentre lo fanno.

• Documentazione poco chiara. Chiunque può risolvere un problema di media priorità durante il giorno con l'intero reparto IT disponibile a parlare. È un'altra questione risolvere un problema ad alta priorità a tarda notte quando sei quasi solo e non hai idea del perché il sistema è configurato come è o perché non corrisponde a ciò che dice la documentazione.

• Non tracciare bene le password. Quindi hai rapidamente bisogno di un account, creane uno con una password casuale e poi 18 mesi dopo è ancora in uso e nessuno conosce la password o quali servizi si romperanno se viene cambiata.

• Non acquistare il supporto del fornitore per i sistemi chiave perché è "troppo costoso".

• Priorità inadeguate. Le persone IT dovrebbero essere guidate dalla direzione: dovrebbe essere in atto un accordo su quali progetti sono prioritari o, in caso di emergenza, quali sistemi sono richiesti per primi. Se l'IT sta cercando di riparare il sistema aziendale, la gestione richiede e-mail e gli utenti richiedono l'elaborazione degli ordini, è una ricetta per un pasticcio.

• Soluzioni inadeguate: è molto facile per l'IT rimanere bloccato nella mentalità di "per risolverlo, il sistema IT deve funzionare come prima", quando può essere più appropriato avere un accordo di gestione-IT per "provare per 2 ore, se non viene risolto, interrompere anche se sembra promettente e passare al ripristino da un backup ".

• Copie di file di test ovunque. Non si desidera aprire una cartella che esegue un sistema aziendale o un sito Web e vedere "Sito Web nuovo /, Sito Web corrente /, Sito Web copia /, Sito Web test /, Sito Web test-dave /, Sito Web-uso- this-one /, website-from-feb /, ecc.) Devono esistere sviluppo, produzione e test e dovrebbero essere separati con ogni reparto coinvolto (IT, sviluppo, project management, ecc.) sapendo cosa dovrebbe essere dove e concordato su come cambia sono approvati anche per i file di configurazione.

• Modifica l'approvazione - anche se prima hai solo una discussione verbale, non cambiare il modo in cui funzionano le cose importanti senza che nessuno lo sappia. Decidi tu quale "importante" copre la tua situazione.

• Le soluzioni organizzate sono rimaste sul posto a lungo termine. So che hai corretto questo server su quella rete con il vecchio filo del telefono appena in modo da poter risolvere un problema urgente. So che non hai tempo per rifarlo correttamente. Prendi il tempo.

• Cattive relazioni con il resto dell'azienda. L'IT è un servizio che aiuta il resto dell'azienda a svolgere il proprio lavoro. Se hanno bisogno di file enormi velocemente, fallo accadere. Se hai bisogno dell'approvazione manageriale per acquistare l'hardware, procuralo. Se non riesci a ottenerlo, comunica chiaramente che i file di grandi dimensioni non possono spostarsi rapidamente perché la gestione ha dato la priorità ad altre spese. Se hai bisogno di archiviare per motivi legali ma non hai budget, devi adattare l'archiviazione nel tuo sistema nel miglior modo possibile.