The Stakeholder trascurato a.k.a l'amministratore di sistema

Question

Qualche tempo fa mi sono reso conto che quasi tutti i progetti di clienti a cui ho lavorato finora hanno trascurato un importante gruppo di parti interessate: gli amministratori di sistema.

Questi eroi silenziosi di solito sono coinvolti solo alla fine di un progetto e rimangono con una scatola nera di pezzi eseguibili che devono installare, supportare e mantenere per gli anni a venire. Ogni volta che si verifica un problema con questa scatola nera, devono trovare un modo per risolverlo utilizzando qualsiasi informazione casuale e supporto di strumenti messi a loro disposizione dalla scatola nera o dalla piattaforma sottostante, e se ciò non è sufficiente, devono improvvisare .

Se fossero stati coinvolti come parti interessate nel progetto sin dall'inizio avrebbero avuto la possibilità di prevedere potenziali problemi e informarne il team di progetto. Ma la realtà è diversa e anche se io come sviluppatore mi piacerebbe coinvolgere l'amministratore di sistema come stakeholder extra, fattori esterni potrebbero impedire che ciò accada.

In queste situazioni vorrei aiutare i nostri eroi silenziosi il meglio che posso. Quindi la mia domanda è:

Che cosa vorrebbe un amministratore di sistema da noi sviluppatori quando sviluppiamo i sistemi che dovranno mantenere?

Se sei un amministratore di sistema ti preghiamo di raccontare una storia di guerra su un problema difficile che hai avuto una volta e cosa avrebbero potuto fare gli sviluppatori per renderti più semplice la risoluzione.

Answer 1

Varie cose, tra cui (ma è improbabile che si limitino a) queste, che non sono in ordine di priorità:

• Nessun requisito per l'utilizzo dell'installazione privilegiata
• Opzione per utilizzare l'installazione privilegiata
• Opzione per l'installazione distribuita (quindi può essere installata su un server e utilizzata su altre macchine)
• Pulisci disinstallazione
• Schemi di upgrade sensibili
• Opzione per scegliere il percorso di installazione
• Dipendenze minime da altri software
• Minimal scattering di dati nel sistema (non scaricare oggetti in / etc, / usr / lib, / var / adm, ...)
• Nessun registro in continua crescita
• Installazione non presidiata
• Installazione tramite script
• Documentazione online (sulla macchina - oltre che su Internet)
• Forse le pagine man
• Facile da configurare
• Facile da rendere accessibile agli utenti finali
• Nessun rischio per la sicurezza
• Nessun utente o gruppo speciale (o numero limitato - al massimo un utente speciale, un gruppo speciale è un target, sebbene non sempre raggiungibile)
• Nessuna funzionalità "home phone" o solo se esplicitamente configurata (non deve essere predefinita)
• Buona registrazione della diagnostica in caso di problemi
• Buon supporto tecnico disponibile in caso di problemi
• Nessun requisito per ottenere il codice di attivazione durante l'installazione
• Non è necessario riavviare il computer dopo un'installazione
• Possibilità di eseguire in parallelo versioni precedenti e nuove

Molto dipende da che cos'è il software e da come viene utilizzato. I requisiti per un programma GUI che funziona su Windows, Linux e MacOS X sono radicalmente diversi dai requisiti per un demone di rete - ma l'obiettivo dovrebbe essere comunque un software stabile, affidabile e facilmente gestibile.

Tieni presente che ci sono grandi differenze tra il software preparato da un dipartimento interno per l'uso all'interno di un'azienda e il software preparato per l'uso da parte di clienti esterni all'azienda che sviluppa il software.

Answer 2

Quando si verifica inevitabilmente un problema, presta attenzione a ciò che dice l'amministratore di sistema e credigli. Non limitarti a scartarlo se non si adatta alla tua valutazione iniziale.

Storia della guerra: circa 6 anni fa, ero amministratore di sistema per una piccola azienda manifatturiera e hanno deciso di acquistare alcuni software per gestire la pianificazione della manutenzione preventiva delle loro apparecchiature. Una delle sue caratteristiche era l'importazione di richieste di manutenzione dall'e-mail, ma abbiamo avuto occasionali problemi con errori nella comunicazione con il server di posta durante questo processo e alla fine sono stato chiamato a dare un'occhiata durante una telefonata con lo sviluppatore. La conversazione ha coinvolto più iterazioni di

  

Sviluppatore: non ho mai sentito parlare di nessuno   avere quel tipo di problemi con cui parlare   il server di posta. Deve essere un   problema con il firewall.

     

Io: sono loggato nel firewall,   eseguendo uno sniffer di pacchetti e guardando   il traffico della tua app passa senza nessuno   i problemi. Sta attraversando il firewall bene.

     

Sviluppatore: No, no - deve essere un   problema con il firewall.

(Alla fine, si è scoperto che il problema era che l'app apriva una connessione POP3, leggeva tutta la posta, aspettava che l'utente pianificasse le attività, quindi inviava un comando POP per eliminare la posta dopo che tutte le richieste avevano se l'utente ha impiegato più di 15 minuti per eseguire la pianificazione, la connessione POP è scaduta e l'app non è stata in grado di recuperare, quindi è deceduta, quindi l'utente ha dovuto ripetere la pianificazione, il che significa che probabilmente impiegare abbastanza tempo per uscire di nuovo ...)

Answer 3

Penso che una combinazione dei seguenti:

1) Soglia di capacità - > Quali macchine sono necessarie per eseguire questo software e quali metriche dovrebbero essere utilizzate per determinare quando questo numero può cambiare, ad es. andando da 2 a 3 server di database o passando da 10 a 15 server web. Quanto deve essere robusto l'hardware e una parte conta più di un'altra, ad es. la CPU conta più della RAM, per quanto riguarda la configurazione del disco rigido e lo spazio?

2) Risoluzione dei problemi di stile del libro di cucina - > Se qualcosa va storto, è facile classificarlo in codice, dati o errore di rete.

3) Diagramma degli ambienti - > Che aspetto hanno le istanze di sviluppo, test e produzione di questo software? Ci sono questi e forse altri ambienti in esecuzione in questo momento?

4) Manutenzione - > Esistono file di registro da analizzare nei report, registri degli errori settimanali da inviare in giro o qualche tipo di pulizia da fare con il software, ad es. riavviare il server settimanalmente.

5) Sicurezza - > Ci sono account da creare e gestire e una politica di sicurezza per delineare chi ha quale livello di autorità sul sistema.

Questi sarebbero i principali che mi vengono in mente.

Answer 4

Gli amministratori di sistema generalmente desiderano quanto segue:

• Trasparenza nel funzionamento del sistema. Quindi una sorta di interfaccia grafica che mostra le impostazioni di sistema e forse una storia di problemi di sistema, nonché elenchi di ciò che il sistema ha elaborato correttamente.
• Un chiaro percorso di escalation sensibile al contesto per i problemi. Con questo intendo che ogni tipo di problema ha alcune note sulla correzione e una persona o un team che può essere contattato se il problema non può essere risolto rapidamente ed è richiesta l'escalation.
• Essere proattivi, cioè in grado di informare gli utenti finali su un problema di sistema prima che un utente finale lo informi. Quindi una sorta di avviso immediato per qualsiasi problema di sistema laddove possibile,
• Non essere invaso da avvisi. Quindi, una volta arrivato un avviso, non più avvisi per lo stesso problema; solo un altro messaggio quando il sistema è di nuovo operativo.
• Registrazione dettagliata usando qualcosa come il registro eventi (in Windows) per un'analisi più approfondita di un problema.

Answer 5

Che il sistema funzioni in modo che possa tornare a casa dai bambini.

Answer 6

Dipendenze ben documentate fornite in bundle con il software, se le mie esperienze di amministratore domestico sono qualcosa da seguire.

Answer 7

Beh, più un orrore che una storia dei tempi di guerra: mantenere un'applicazione che per nessuna ragione apparente richiede di essere eseguita con un account utente amministratore.

Alcune cose a caso penso che sarebbe bello avere in un'applicazione:

• Argomenti della riga di comando significativi
• Una sorta di capacità di scripting (se appropriato)
• Qualsiasi tipo di indicatore di avanzamento per operazioni di lunga durata
• Registrazione errori
• UI coerente

Answer 8

Facile manutenzione dei pacchetti!

Dovrebbe essere semplicissimo installare e aggiornare il software, e questo vale anche per le dipendenze. Se ci sono molte dipendenze e sotto-dipendenze e non sei propenso a padroneggiare le sfumature della metodologia di gestione dei pacchetti di ciascun sistema operativo, sarebbe bello offrire una versione del pacchetto con tutte le dipendenze necessarie raggruppate in un tarball gigante . Esegui lo script, inseriscilo in / usr / local / yourproject e dì loro dove si trova lo script startup / shutdown / restart.

Answer 9

Ogni progetto ha "Pianificazione della capacità" insieme alla sua architettura di sistema. Gli amministratori di sistema dovrebbero essere coinvolti nel processo di pianificazione della capacità e nella revisione finale dell'architettura del sistema. Ciò lo aiuterà a comprendere meglio il sistema e ad essere pronto per la distribuzione e il supporto.