Rispetta che gli amministratori di sistema hanno un lavoro da svolgere e lascia che facciano il loro lavoro. Molte aziende hanno amministratori di sistema incompetenti e questo spesso non è realistico. Ma ho visto sviluppatori arroganti ignorare i consigli dei gruppi di sistemi anche dopo che i amministratori di sistema hanno dimostrato la loro competenza.
Discutere la progettazione di un nuovo sistema con amministratori di sistema. C'è spesso una visione preziosa. Gli sviluppatori guardano spesso alle discussioni con gli amministratori di sistema e forniscono i requisiti iniziali come "ottimizzazione prematura". In realtà ho visto il capo di un gruppo di sviluppo dire che era una perdita del suo tempo discutere dei requisiti per i nuovi server di database con amministratori di sistema e amministratori di database, anche nella misura in cui si descriveva se si tratta di un carico ad alta intensità di scrittura o ad alta intensità di lettura, oppure quanta memoria sarebbe necessaria.
Discutere i problemi di prestazioni con gli amministratori di sistema. Onestamente solo i amministratori di sistema sono in grado di interpretare correttamente le metriche delle prestazioni sui sistemi. Ho visto gli sviluppatori decidere che Linux perde sempre memoria perché la memoria libera riportata da "free" diminuisce sempre, anche dopo la decima volta che viene spiegato l'output di "free".
Non trarre conclusioni senza discuterne con gli amministratori di sistema. Ho visto gli sviluppatori rimanere bloccati su teorie come "i database sono sempre legati al disco" (non sapevano che esistesse anche iostat), "RAID 5 è più veloce per i carichi di lavoro transazionali" (basato sul ricordo di un sistema di database che è stato spostato da una piattaforma hardware all'altra: era un carico di lavoro ad alta intensità di lettura, la soluzione RAID5 aveva unità sempre più veloci distribuite su più controller. Ma dimenticarono questi dettagli e ricordarono solo la conclusione.)
Non progettare una soluzione a un problema di sistema senza discuterne con gli amministratori di sistema. Ho lavorato in un ambiente patologico in cui gli sviluppatori progettavano una soluzione e venivano a chiedere una piccola assistenza per l'implementazione. I membri del gruppo Unix oltre a me, il capo del gruppo Unix e il suo capo, volevano trattare gli sviluppatori come "clienti", non come collaboratori che cercavano di far funzionare un'infrastruttura globale. Il cliente ha sempre ragione, non ha messo in discussione ciò che stava facendo o perché. Ero l'unico a insistere affinché il problema fosse descritto in modo da poter determinare una soluzione corretta. Non agire in modo tale da creare ambienti patologici come questo. Non si traduce in un vantaggio netto - invece, i gestori di sistemi agiranno in modo difensivo e tutti ne soffriranno.
Non sei più a scuola. Questi sono sistemi del mondo reale e non agiscono in modo ideale. Ad esempio, non tutto ha latenza zero. Quando un amministratore di sistema ti avverte che le soluzioni di clustering sono solo a scopo politico e che la maggiore complessità del sistema diminuisce l'affidabilità complessiva, prendila sul serio. Devi progettare per le modalità di errore del mondo reale, ad esempio quando perdi il server con cui stai parlando tramite TCP, probabilmente la connessione non verrà ripristinata per te. Gli amministratori di sistema comprendono le modalità di errore del mondo reale.
O ascolta ciò che ti dice il tuo amministratore di sistema, oppure lamentati con il management che i tuoi amministratori di sistema sono incompetenti e devono essere licenziati. Ignorare il tuo amministratore di sistema non ha senso.
Considera come distribuirai la tua applicazione. Comprendi che discuterne con i tuoi amministratori di sistema ha senso. Se si dispone di 100 server identici, che differiscono solo in base a un singolo file di configurazione, è possibile prendere in considerazione l'archiviazione delle copie principali di questi file di configurazione in una posizione centrale. Scopri quanto è meglio se tutti sono facili da ridistribuire nella tua applicazione. Se si verifica un problema con un sistema, preferiresti ridistribuire in meno di un minuto per un pezzo di ricambio, o aspettare per anni mentre quello rotto viene riparato? Se è possibile ridistribuire l'applicazione, è possibile aggiornare il sistema operativo in modo più semplice e sicuro. Potresti interessartene in futuro.
Se hai un problema che ritieni possa essere dovuto al sistema operativo, ha senso chiamare immediatamente l'amministratore di sistema per verificarlo. Ma dopo che un'indagine sommaria non rivela nulla, hai il dovere di spiegare il problema.
Comprendi che esiste una differenza tra "rispondere lentamente" e "non rispondere affatto".