Der vernachlässigte Stakeholder a.k.a der Systemadministrator

8

Vor einiger Zeit wurde mir klar, dass fast jedes Kundenprojekt, an dem ich bisher gearbeitet habe, eine wichtige Gruppe von Stakeholdern vernachlässigt hat: die Systemadministratoren.

Diese stillen Helden sind normalerweise nur am Ende eines Projekts involviert und bleiben mit einer ausführbaren Blackbox von Bits zurück, die sie für die kommenden Jahre installieren, unterstützen und warten müssen. Wann immer ein Problem mit dieser Blackbox auftritt, müssen sie einen Weg finden, es zu lösen, indem sie irgendeine zufällige Information und Werkzeugunterstützung benutzen, die ihnen durch die Blackbox oder die zugrunde liegende Plattform zur Verfügung gestellt wird, und wenn dies nicht ausreicht, müssen sie improvisieren .

Wenn sie von Anfang an als Stakeholder in das Projekt involviert gewesen wären, hätten sie eine Chance gehabt, potenzielle Probleme vorherzusagen und das Projektteam darüber zu informieren. Aber die Realität ist anders und obwohl ich als Entwickler gerne den Systemadministrator als zusätzlichen Akteur mit einbeziehen würde, könnten externe Faktoren dies verhindern.

In diesen Situationen möchte ich unseren stillen Helden so gut wie möglich helfen. Also meine Frage ist:

Was würde ein Systemadministrator von uns Entwicklern wünschen, wenn wir die Systeme entwickeln, die er warten muss?

Wenn Sie ein Systemadministrator sind, bitte erzählen Sie eine Kriegsgeschichte über ein schwieriges Problem, das Sie einmal hatten und was Entwickler getan haben könnten, um es einfacher für Sie zu machen.

    
Jonas Kongslund 21.11.2008, 00:03
quelle

9 Antworten

9

Verschiedene Dinge, einschließlich (aber wahrscheinlich nicht beschränkt auf) diese, die nicht in der Reihenfolge der Prioritäten stehen:

  • Keine Notwendigkeit, privilegierte Installation zu verwenden
  • Option zur Verwendung der privilegierten Installation
  • Option für verteilte Installation (damit sie auf einem Server installiert und auf anderen Computern verwendet werden kann)
  • Saubere Deinstallation
  • Sinnvolle Upgrade-Muster
  • Option zur Auswahl des Installationsorts
  • Minimale Abhängigkeiten von anderer Software
  • Minimale Streuung der Daten um das System herum (dump nicht in / etc, / usr / lib, / var / adm, ...)
  • Keine ständig wachsenden Protokolle
  • Automatische Installation
  • Skript-Installation
  • Online-Dokumentation (sowohl auf der Maschine als auch im Internet)
  • Man-Seiten vielleicht
  • Einfach zu konfigurieren
  • Einfach zugänglich für Endbenutzer
  • Keine Sicherheitsrisiken
  • Keine speziellen Benutzer oder Gruppen (oder begrenzte Anzahl - höchstens ein spezieller Benutzer, eine spezielle Gruppe ist ein Ziel, obwohl nicht immer erreichbar)
  • Entweder keine 'Phone Home' Funktionalität oder nur wenn explizit konfiguriert (muss nicht Standard sein)
  • Gute Protokollierung der Diagnose bei Problemen
  • Gute technische Unterstützung verfügbar, wenn ein Problem auftritt
  • Keine Anforderung, während der Installation Aktivierungscode zu erhalten
  • Keine Notwendigkeit, den Computer nach einer Installation neu zu starten
  • Möglichkeit, alte und neue Versionen parallel auszuführen

Viel hängt davon ab, was die Software ist und wie sie benutzt wird. Die Anforderungen an ein GUI-Programm, das unter Windows, Linux und MacOS X funktioniert, unterscheiden sich radikal von den Anforderungen an einen Netzwerk-Daemon - aber das Ziel sollte weiterhin eine stabile, zuverlässige und leicht zu verwaltende Software sein.

Bedenken Sie, dass es große Unterschiede zwischen Software gibt, die von einer internen Abteilung für die Verwendung in einem Unternehmen erstellt wird, und Software, die für Kunden außerhalb des Unternehmens, das die Software entwickelt, bereitsteht.

    
Jonathan Leffler 21.11.2008, 00:35
quelle
4

Wenn ein Problem unvermeidlich auftritt, achten Sie darauf, was der Systemadministrator sagt und glauben Sie ihm. Sie sollten es nicht einfach außer Acht lassen, wenn es nicht zu Ihrer ursprünglichen Einschätzung passt.

Kriegsgeschichte: Vor etwa 6 Jahren habe ich für ein kleines Unternehmen gearbeitet und beschlossen, eine Software zu kaufen, die die Planung der vorbeugenden Wartung ihrer Ausrüstung übernimmt. Eine seiner Funktionen war das Importieren von Wartungsanforderungen aus E-Mails, aber wir hatten gelegentlich Probleme mit Fehlern, die während dieses Vorgangs mit dem Mail-Server sprachen, und ich wurde schließlich dazu aufgefordert, während eines Telefonats mit dem Entwickler einen Blick darauf zu werfen. Die Konversation umfasste mehrere Iterationen von

  

Entwickler: Ich habe noch nie von jemandem gehört   mit dieser Art von Schwierigkeiten zu reden   der Mail-Server. Es muss ein sein   Firewall-Problem.

     

Ich: Ich bin in der Firewall angemeldet,   einen Packet Sniffer laufen lassen und zusehen   Der Traffic deiner App wird ohne diese weitergeleitet   Probleme. Es kommt gut durch die Firewall.

     

Entwickler: Nein, nein - es muss ein sein   Firewall-Problem.

(Am Ende stellte sich heraus, dass das Problem darin bestand, dass die App eine POP3-Verbindung öffnete, alle E-Mails lauschte, darauf wartete, dass der Benutzer die Aufgaben einplante und dann einen POP-Befehl zum Löschen der E-Mail nach allen Anfragen schickte Wenn der Benutzer mehr als 15 Minuten für die Planung benötigt hat, ist die POP-Verbindung abgelaufen und die App konnte sich nicht wiederherstellen, so dass sie stattdessen gelöscht wurde. Und dann musste der Benutzer die Planung wiederholen, was wahrscheinlich war Nehmen Sie sich lange genug Zeit, um wieder auszustrecken ...)

    
Dave Sherohman 23.11.2008 23:02
quelle
2

Ich denke eine Kombination aus den folgenden:

1) Schwellenwert der Kapazität - & gt; Welche Maschinen braucht es, um diese Software auszuführen und welche Metriken sollten verwendet werden, um zu bestimmen, wann sich diese Anzahl ändern kann, z. Gehen Sie von 2 zu 3 Datenbankservern oder von 10 zu 15 Webservern. Wie bullig muss die Hardware sein und ein Teil ist wichtiger als ein anderer, z. ist CPU wichtiger als RAM, was ist mit Festplattenkonfiguration und Speicherplatz?

2) Fehlerbehebung im Cookbook-Stil - & gt; Wenn etwas schief geht, kann dies leicht in Code, Daten oder Netzwerkfehler eingeordnet werden.

3) Diagramm der Umgebungen - & gt; Wie sehen die Entwicklungs-, Test- und Produktionsinstanzen dieser Software aus? Laufen diese und möglicherweise andere Umgebungen gerade?

4) Wartung - & gt; Gibt es Protokolldateien, die in Berichten analysiert werden, wöchentliche Fehlerprotokolle, die gesendet werden sollen, oder irgendeine Art von Verwaltung, die mit der Software zu tun hat, z. Starten Sie den Server wöchentlich neu.

5) Sicherheit - & gt; Gibt es Accounts, die erstellt und verwaltet werden müssen, und eine Sicherheitsrichtlinie, um festzulegen, wer welche Berechtigungsebene auf dem System hat.

Das wären die wichtigsten, die mir in den Sinn kommen.

    
JB King 21.11.2008 20:48
quelle
2

Systemadministratoren möchten im Allgemeinen Folgendes:

  • Transparenz in den Betrieb des Systems. Also irgendeine Art von GUI, die Systemeinstellungen und vielleicht eine Geschichte von Systemproblemen zeigt, sowie Listen, was das System korrekt verarbeitet hat.
  • Ein klarer kontextabhängiger Eskalationspfad für Probleme. Damit meine ich, dass jeder Problemtyp einige Anmerkungen zur Fehlerbehebung enthält und eine Person oder ein Team, die kontaktiert werden können, wenn das Problem nicht schnell behoben werden kann und eine Eskalation erforderlich ist.
  • proaktiv zu sein, d. h. in der Lage, Endbenutzer über ein Systemproblem zu informieren, bevor ein Endbenutzer ihn informiert. Also eine Art sofortige Alarmierung für jedes Systemproblem, wo das möglich ist,
  • Nicht von Warnungen überflutet werden. Sobald ein Alarm angekommen ist, gibt es keine Warnungen mehr für das gleiche Problem. nur eine weitere Nachricht, wenn das System wieder betriebsbereit ist.
  • Detaillierte Protokollierung mit etwas wie dem Ereignisprotokoll (in Windows) zur tieferen Untersuchung eines Problems.
RoadWarrior 21.11.2008 00:24
quelle
1

Dass das System einfach funktioniert, damit er nach Hause gehen kann.

    
badbadboy 21.11.2008 00:06
quelle
1

Gut dokumentierte Abhängigkeiten, die mit der Software mitgeliefert werden, wenn meine Home-Admin-Erfahrungen etwas bringen.

    
Paul Nathan 21.11.2008 01:10
quelle
1

Nun, mehr ein Horror als eine Kriegsgeschichte: eine Anwendung zu verwalten, die ohne ersichtlichen Grund unter einem Administrator-Benutzerkonto ausgeführt werden muss.

Ein paar zufällige Dinge, die ich denke, wäre schön in einer Anwendung zu haben:

  • Aussagekräftige Befehlszeilenargumente
  • Eine Art von Skriptfunktionen (falls zutreffend)
  • Jede Art von Fortschrittsanzeige für lang andauernde Operationen
  • Fehlerprotokollierung
  • Konsistente Benutzeroberfläche
Uros Calakovic 21.11.2008 21:17
quelle
1

Einfache Paketpflege!

Es sollte hirntot sein, einfach die Software zu installieren und zu aktualisieren, und das gilt auch für Abhängigkeiten. Wenn es viele Abhängigkeiten und Unterabhängigkeiten gibt und Sie nicht geneigt sind, die Nuancen der Paketverwaltungsmethodik jedes Betriebssystems zu meistern, wäre es schön, eine Paketversion mit allen erforderlichen Abhängigkeiten zu einem riesigen Tarball zu bündeln . Führen Sie das Skript aus, legen Sie alles in / usr / local / yourproject ab und teilen Sie ihm mit, wo sich das Skript zum Starten / Herunterfahren / Neustarten befindet.

    
dannyman 23.11.2008 21:54
quelle
1

Jedes Projekt hat eine "Kapazitätsplanung" mit seiner Systemarchitektur. Systemadministratoren sollten in den Kapazitätsplanungsprozess sowie in die abschließende Überprüfung der Systemarchitektur einbezogen werden. Dies wird ihm helfen, das System besser zu verstehen und auf die Bereitstellung und den Support vorbereitet zu sein.

    
Jobi Joy 21.11.2008 00:27
quelle