weidner/computer/sysadmin/

Der Limoncelli-Test

Thomas Limoncelli, Autor mehrerer guter Bücher zum Thema Systemadministration hat, analog zu Joel Spolskys Joel Test für Softwareentwickler, einen Katalog von Fragen für Systemadministratoren herausgegeben. Diese kann ich beim Einstellungsgespräch verwenden, um die Firma, die sich um mich bewirbt, besser einzuschätzen. Oder ich nehme den Katalog, um zu sehen, wo und wie ich bei meiner Arbeit bzw. in meiner derzeitigen Firma etwas besser machen kann.

Hier ist eine Übersetzung des Limoncelli-Tests. Die wichtigen Fragen sind, wie beim Original mit '*' hervorgehoben.

A. Öffentlichkeitswirksame Praktiken

1. * Werden Benutzeranfragen mit einem Ticketsystem verfolgt?

Das ist so grundlegend, dass es weh tut, das zu erklären.

Menschen können sich nicht so gut erinnern wie Computer. Von Systemadministratoren zu erwarten, dass sie sich an alle Benutzeranfragen erinnern, ist der direkte Weg, um Anfragen fallen zu lassen.

Anforderungen in einer Datenbank zu erfassen verbessert den Zugriff innerhalb des Teams. Es verhindert, dass zwei Leute in der gleichen Angelegenheit gleichzeitig tätig werden. Es ermöglicht den Systemadministratoren, die Arbeit untereinander aufzuteilen. Es ermöglicht es, eine Aufgabe von einem auf den nächsten zu übertragen ohne den Überblick über das schon Getane zu verlieren. Es ermöglicht es einem anderen Systemadministrator einzuspringen für jemand, der ausser Haus ist, unabkömmlich oder im Urlaub.

Es macht transparenter, was Ihr Team macht. Benutzer können sehen, wer an einer Anforderung arbeit, was der Status ist und ob es fertig ist. Es läßt den Anforderer und den Systemadministrator Folgefragen stelleun und die Antworten verfolgen.

Es ermöglicht besseres Zeitmanagement. Jede Unterbrechung, die ein Systemadministrator erfährt, setzt in in seiner Arbeit um 7 Minuten zurück. Ein Ticketsystem verhindert Unterbrechungen von Benutzern, die eine Anforderung haben oder nach dem Status der Bearbeitung fragen wollen. Es läßt den Systemadministrator seine Arbeit priorisieren anstatt auf den lautesten Beschwereführer zu antworten.

Es läßt Manager bessere Manager sein. Steckengebliebene Anforderungen werden sichtbar, so dass der Manager eingreifen kann. Es offenbart Trends und häufige so dass diese durch Automatisierung oder Prozessverbesserung eliminiert werden können. Mikromanager können die Informationen, die sie haben wollen, von der Software bekommen, anstatt den Systemadministrator zu belästigen. Es ersetzt "jammernde Benutzer" mit beweisbasierender Diskussion: Wenn eine Anforderung wirklich zu lange gebraucht hat, kann der Manager die Sache richtig angehen. Wenn dem Benutzer lediglich erscheint, dass die Sache zu lange dauert, wird ihn der Beweis zur Ruhe bringen. Wenn sie sagen "das Problem besteht schon monatelang, aber ich öffnete erst gestern ein Ticket", hat der Manager eine ... Möglichkeit den Benutzer zu belehren übe die Nichtexistenz von Zeitreisen, Gedankenlesen und anderen übernatürlichen Kräften.

Es hilft Ihnen systematische Probleme zu identifizieren. Ein ehemaliger Chef befragte das Ticketsystem und entdeckte, dass 3 von 1000 Benutzern 10 Prozent aller Tickets geöffnet hatten. Eine kleine Untersuchung und wir waren in der Lage, die grundlegende Angelegenheit, die das verursacht hatte, zu lösen.

Es hilft den Benutzern sich selbst zu helfen. Häufig erkennen die Benutzer, was die Lösung für ihr Problem ist, wenn sie dieses aufschreiben, und es wird kein Ticket geöffnet. Falls das nicht passiert, hilft es ihnen das Problem zu durchdenken, so dass sie es klarer kommunizieren können, was die eigentliche Erledigung effizienter macht.

Ich verbrachte die 1990er Jahre als der "Radikale", der die Leute dazu bringt, Ticketsysteme aufzusetzen. In den 200xer Jahren erfreut es mich zu sehen, dass es zu einer akzeptierten Praxis geworden ist. Wir sind weit in der dritten Dekade. Wenn Du immer noch keinen Weg hast, Benutzeranforderungen zu verfolgen, schäm Dich!

2. * Sind die "drei Ermächtigunsrichtlinien" definiert und veröffentlicht?

Es gibt drei öffentliche Richtlinien, die Sie haben müssen, wenn ein Team von Systemadministratoren überhaupt irgendwelche Arbeit schaffen können soll. Dabei geht es ebenso um den Dienst am Kunden wie um die Effizienz des Teams.

Wenn Sie als Manager das Gefühl haben, Ihr Team ist nicht gut im Zeitmanagement, liegt es vielleicht daran, dass Sie nicht diese drei Richtlinien durchgesetzt haben:

1. Die zulässigen Methoden für die Benutzer um Hilfe zu bekommen.
2. Die Definition eines "Notfalles".
3. Der Zuständigkeitsbereich eines Dienstes: wer, was und wo.

Ein Dokument kann alle drei Dinge in weniger als einer Seite erläutern. Dieses sollte auf der Website der Abteilung oder auf Postern an der Wand verfügbar gemacht werden, so dass es klar übermittelt wird. Diese Richtlinie muss auch von der Geschäftsführung getragen werden. Das bedeutet, dass sie zu einem Benutzer "nein" sagen, wenn dieser nach einer Ausnahme fragt. Der Ausnahmeprozess sollte keine Bodenschwelle [zum Ausbremsen, d.Ü.] sein, sondern eine solide Wand.

Wie man Hilfe bekommt:

Eine offizielle Verfahrensweise, wie Benutzer Hilfe bekommen, ermöglicht alle Vorteile eines Ticketsystems, welches im vorigen Abschnitt erwähnt wurde. Ohne diese verfliegen die Vorteile, da die Benutzer direkt zum Systemadministrator, welcher - während er versucht zu helfen - durch Unterbrechungen gesteuert und ineffektiv wird.

Ein Systemadministrator muss die Möglichkeit haben, einen Benutzer fortzuschicken, wenn dieser nicht der Verfahrensweise folgt. Ohne die Möglichkeit, auf die Richtlinie zu verweisen, werden die Systemadministratoren entweder den ganzen Tag an niedrig priorisierten, "quietschendes Rad" Aufgaben arbeiten, oder jeder Systemadministrator wendet eine andere Richtlinie an und lässt das Team inkonsistent erscheinen oder die Systemadministratoren werden ihren Frust auf ungesunde Art kommunizieren. Insbesondere ungesund für die Benutzer.

Was ist ein Notfall:

Eine offizielle Definition eines Notfalls ermöglicht einem Systemadministrator Prioritäten zu setzen. Ohne diese wird alles ein Notfall und Systemadministratoren werden unterbrechungsgesteuert und ineffektiv.

Die Richtlinie ist ein Weg, wie das Management den Systemadministratoren Prioritäten übermittelt. Andernfalls werden Systemadminstratoren raten und unfair bestraft, wenn sie falsch tippen. Manager werden verwirrt durch die "Unterbrechung". Und die Nutzer sehen die Inkonsistenzen und vermuten Vetternwirtschaft, Vernachlässigung und Inkompetenz.

Diese Richtline setzt die Erwartungen der Benutzer in einen Rahmen. Jene, die alles einen Notfall nennen, können von dieser Illusion befreit werden.

Jede Organisation sollte eine Definition eines Notfalles oder eines "Code rot" haben. Der Code rot einer Zeitung ist alles, das verhindert, dass die morgige Ausgabe gedruckt und verladen werden kann. Der Code rot einer Fabrik ist alles, was das Montageband aufhält. Bei einem Bezahldienst ist es alles, was den Zahlungsfluss unterbricht. Die Teams von Ausbildungseinrichtungen wissen, dass eine Klasse nicht einfach verlegt werden kann, daher ist für sie ein Notfall alles was die ordnungsgemäße Durchführung einer Lektion verhindert (möglicherweise nur, wenn das Zentrum vorher gewarnt wurde). Eine Universität definiert als Code rot alles, was verhindert, dass Subventionsanträge rechtzeitig eingereicht werden können.

Ein "Code gelb" ist alles das, was wenn es vernachlässigt wird, zu einem "Code rot" führt. Zum Beispiel mag der Zahlungsfluss funktionieren, aber das System für die Kapazitätsvorhersage läuft nicht. Es ist riskant, dann neue Kunden anzunehmen ohne zuverlässig die Kapazität vorhersagen zu können. Die letzte Vorhersage zeigte ungefähr 2 Wochen Reservekapazität. Das Risiko eines Zusammenbruchs steigt täglich bis der Code gelb beseitigt ist.

Alles andere ist "Routine". Raffinierte Stellen können Routineanforderungen in hohe, mittlere und niedrige Prioritäten unterteilen: Anlegen eines neuen Dienstes, Bereitstellung eines Dienstes, und so weiter. Aber wenn Sie keines davon haben, beginnen Sie damit, zu definieren, was ein Notfall ist.

Was wird unterstützt:

Eine offizielle Definition dessen, was unterstützt wird, erlaubt es einem Systemadministrator "nein" zu sagen. Sie sollte festlegen, wann, wo und was unterstützt wird. Leisten Sie Unterstützung nach 17:00 Uhr? An Wochenenden? Helfen Sie direkt am Arbeitsplatz? Hausbesuche? Helfen Sie jedem auf der Straße oder nur den Leuten in Ihrer Abteilung? Welche Software und Hardware wird unterstützt? Gibt es einen Support-Lebenszyklus oder sind sie, nachdem etwas in Betrieb genommen wurde, dazu bestimmt es ewig zu unterstützen? Werden neue Technologien automatisch oder nur nach offizieller Anforderung und positiver Bestätigung unterstützt?

Ohne die Möglichkeit "nein" zu sagen, werden Systemadministratoren alles unterstützen. Ein eifriger, hilfreicher Systemadminstrator wird ungezählte Stunden damit verbringen eine ungeeignete Videokarte zum Laufen zu bringen, wenn es billiger wäre, ihm eine geeignete Karte aus ihrem Budget zu geben. Ein Systemadministrator, der vermisst oder tot gemeldet wurde, wird auf magische Weise wieder auftauchen nachdem er den Tag im Haus eines Benutzers verbrachte, um dessen Internetverbindung zu reparieren. Ersatzweise wird ein griesgrämiger Systemadministrator den Leuten erzählen, das etwas nicht unterstützt wird, weil er gerade beschäftigt ist.

3. Erfasst das Team monatliche Metriken?

Sie müssen Daten haben, wenn Sie Entscheidungen treffen oder die obere Managementebene beeinflussen wollen.

Der beste Weg, Ihre Metriken zu entwickel, ist, eine Metrik pro Satz in Ihrer Satzung zu erstellen.

Beispiel: Die Satzung für ein PC-Bereitstellungsteam könnte sein: Einen standardisierten High-End-PC für jeden Benutzer ab dem ersten Tag bereitzustellen, der alle 3 Jahre ersetzt wird, zu branchenüblichen Betriebskosten. Die Metriken könnten sein: Anzahl der Wochen, seit die Standardkonfiguration aktualisiert wurde, Kosten der aktuellen Standardkonfiguration, Anzahl der neuen Angestellten diesen Monat, Kapitalaufwendungen, Betriebsaufwendungen. Wieviele Tage neue Angestellte auf ihre Maschine warteten (Töpfe für: vor der Ankunft, 1. Tag, 2., 3., 4., 5. Tag, mehr als 5 Tage), Alter der Flotte (Töpfe für: <1 Jahr, 1-2 Jahre, 2-3 Jahre, >3 Jahre), Anzahl der Maschinen, die vom Standard abweichen.

Wenn Sie keine Satzung haben, sprechen Sie mit Ihrem Manager darüber, eine zu schreiben. Alternativ sind hier ein paar Starter-Metriken, die Sie heute einsetzen könne:

• Wie viele SysAdmins haben wir?
• Für wie viele Benutzer bieten wir Dienste an?
• Wie viele Maschinen verwalten wir?
• Wie viel Gesamtplattenplatz? RAM? CPU-Kerne?
• Wie viele offene Tickets sind gerade im Ticketsystem?
• Wie viele neue Tickets gibt es seit dem letzten Monat?
• Was war der Ticket pro SysAdmin Durchschnitt im letzten Monat?
• Nehmen Sie 4-5 wichtige SLAs und zeichnen Sie auf, wie nahe Sie ihrer Erfüllung kommen.
• Wie viel Internet-Bandbreite wurde letzten Monat verbraucht?

Zeichnen Sie diese jeweils am Ersten des Monats auf. Packen Sie sie in eine Kalkulationstabelle. Sie können diese zur Bestimmung des Budgets verwenden, oder für Präsentation, wenn Sie erläutern, was Ihre Gruppe macht.

Das ist es. Wirklich. Das einmal im Monat aufgezeichnete ist der Unterschied zwischen dem Beginn einer Präsentation mit einer einfachen Grafik, die die Wachstumsrate bei der Anzahl der Maschinen in Ihrem Netzwerk anzeigt, gegenüber Satz "Hallo, ich bin Joe und wir verwalten ... ähm ... eine Menge Maschinen. Diese grundlegenden Fragen zur Zeit der Budgetplanung beantworten zu können, ist die Grundlage für andere Fragen, wie "Wie viel kostet im Durchnschnitt ein Ticket?" (Gesamtbudget des letzten Jahres / Gesamtzahl der Tickets letztes Jahr), Wenn wir 100 Benutzer hätten, wie viel neue Platten würden wir brauchen? (Gesamtplattenplatz / Anzahl der Benutzter * 100).

Letztendlich sollten diese Metriken automatisch gesammelt werden. Bis dahin generieren Sie jeden Monatsersten eine E-Mail, die Sie erinnert, es von Hand zu erfassen.

B. Moderne Praktiken der Gruppenarbeit

4. * Gibt es ein "Prozess und Ablauf" Wiki?

Ihr Team braucht ein Wiki. Auf diesem können Sie alle Ihre Prozesse (was sollte getan werden) und Abläufe (wie wird es gemacht) dokumentieren.

Automatisierung ist großartig, aber bevor Sie etwas automatisieren können, müssen Sie in der Lage sein, es von Hand zu tun. Den Ablauf von Hand für etwas zu dokumentieren ist eine Vorbedingung für Automatisierung. Einstweilen ermöglicht es konsistente Abläufe quer durch das Team und Sie erlangen die Fähigkeit zu delegieren. Wenn es dokumentiert ist, kann es jemand anders für sie machen.

Das Inhaltsverzeichnis für das Wiki sollte die allgemeinen Routineaufgaben enthalten, insbesondere die Anschluß-/Änderungs-/Lösch-Prozeduren, die jeder im Team ausführen können sollte. Oder die Aufgaben, die Sie nicht so gern machen und die Sie an einen Assistent delegieren würden, wenn Sie einen hätten.

Prozedurliste:

• Wenn ein neuer Mitarbeiter anfängt.
• Wenn ein Mitarbeiter die Firma verläßt.
• Wenn ein Mitarbeiter gefeuert wird.
• Wenn eine neue Maschine installiert wird.
• Wenn eine Maschine stillgelegt wird.
• Wie man eine Person zum VPN-Dienst hinzufügt/davon entfernt.
• Wie man eine Platte im RAID-System wechselt.
• Wie man das root-Kennwort auf allen Maschinen ändert.

Es gibt hier drei Kategorien: Dinge, die Sie konsistent haben wollen; Dinge, die sie selten tun und bei denen Sie keine Zeit verschwenden wollen, sich an den Prozess zu erinnern; und schließlich Dinge, die Sie in Panik tun und bei denen Sie nicht über die nächsten Schritte nachdenken wollen.

Diese Sachen können alle mit einfachen "Schritt-für-Schritt" Checklisten dokumentiert werden.

Einmal dokumentiert, kann sie jeder machen. Das schafft auch ein Trainingsprogramm für neue Mitarbeiter. Es kann auch verwendet werden, um die Stellenbeschreibung für den Assistenten zu schreiben, den Ihre Firma für Sie einstellen soll, damit er Ihre ganze Arbeit macht.

Selbst wenn Sie nicht in einem Team arbeiten, oder es Aufgaben gibt, die nur Sie tun, hat das Dokumentieren Vorteile. Sie brauchen weniger nachzudenken, wenn Sie die Aufgabe erledigen.

Systemadministratoren hassen es Dokumentationen zu schreiben, aber "Schritt-für-Schritt" Checklisten zu schreiben ist nicht so schlimm. Das in einem Wiki vorzuhalten, ist wichtig: jeder kann es korrigieren und jeder kann es verbessern.

Für alle Aufgaben wollen Sie vermutlich verschiedene "Prozess" und "Ablauf" Dokumente haben. Prozess ist, was das Management definiert: Alle neuen Benutzer bekommen eine drahtlose Maus. Ablauf ist, wie die Aufgabe abgearbeitet wird: Drahtlose Mäuse sind im dritten Behälter, lade sie auf und teste sie mit den folgenden Schritten, usw.. Prozesse werden nur mit Zustimmung des Managements geändert. Abläufe werden durch die Techniker geändert, mit Änderungsmitteilung an den Autor oder anderes Fachpersonal.

5. Gibt es einen Passwordsafe?

Das zeigt, dass Sie Kennworte auf durchdachte Weise verwalten.

Es gibt viele softwarebasierte Passwort-Tresor-Systeme. Dabei ist ein Umschlag in einer wirklich verschlossenen Blechkiste oft ausreichend.

Das Problem ist oft die Verifizierung. Woher wissen Sie, dass kein böswilliger Mitarbeiter die falschen Kennworte in den Umschlag legt? Wenn Sie so paranoid sind, lassen Sie eine andere Person alle neuen Kennworte prüfen.

6. Wird der vom Team geschriebene Code mit Versionsmanagement gepflegt?

Wenn die Installation einer neuen Maschine ein API-Aufruf ist, sind wir jetzt alle Programmierer. -- Limoncelli, über Cloud Computing, Devops und die Bedeutung von Entwicklerfähigkeiten in der Systemadministration

Wir sind jetzt alle Programmierer. Programmierer verwenden Quellcodeverwaltuug.

Dinge, die man in das Repository bringt: Ihre Scripts, Programme, Konfigurationsdateien, Dokumentation und eigentlich fast alles. Wenn Sie sich nicht sicher sind, lautet die Antwort "ja".

Die Konfigurationsdateien in die Quellcodeverwaltung zu bringen, fühlt sich zunächst wie Luxus an und rettet Ihnen am Ende die Haut.

Irgendwas ist besser als gar nichts. Benutzen Sie, was Ihre Entwickler verwenden. Keine Entwickler? Lernen Sie Git, Mercurial oder eben Subversion? Verzweifelt auf der Suche nach einem Weg, ihre Konfigurationsdateigeschichte zu sichern?

http://www.nightcoder.com/code/xed (Das ist ein Wrapper der $EDITOR aufruft).

7. Verwendet das Team eine Fehlerdatenbank für selbstgeschriebenen Code?

Fehlerdatenbanken unterscheiden sich von Ticketsystemen. Wenn Sie nur gelegentlich Fehler haben (vielleicht schreibt Ihr Team nur wenig Code), dann reicht es Hilfetickets fü sich selbst aufzumachen.

Falls es ihrem Team jedoch ernst ist mit dem Schreiben von Code, starten Sie eine eigene Fehlerdatenbank. Fehlerdatenbanken haben einen anderen Arbeitsablauf als Ticketsysteme. Ein Ticketsystem ist ein Kommunikationswerkzeug zwischen Ihnen und Ihren Benutzern. Fehlerdatenbanken verfolgen den Lebenszyklus eines Fehlers (Melden, Verifizieren, Zuweisen, Beheben, Schließen, Verifizieren).

8. Hat Stabilität Vorrang vor neuen Features bei Ihren Fehlern/Tickets?

Wenn ich die Wahl hätte, würde ich die einfachen Fehler zuerst beheben, dann eindrucksvolle neue Feature hinzufügen und dann erst langweiligen Kram machen, wie Fehler beheben. So macht das Leben mehr Spaß.

Leider können Sie hier keinen Spaß machen.

Bewährte Teams priorisieren ihre Fehler auf folgende Weise:

• Sicherheit (am höchsten)
• Stabilität
• Fehler
• Performance
• neue Feature (am niedrigsten)

Sie müssen Stabilität sichern, bevor Sie neue Feature hinzufügen. Sicherheitsfragen sind vorrangige Stabilitätsfragen.

Eines der Prinzipien, für die Mark Burgess wirbt, lautet "Suche Stabilität, dann neue Features". Einige Änderungen, die wir machen, fügen neue Feature hinzu, während andere die Stabilität verbessern. Die Reihenfolge sollte sein Feature, Stabilität, Feature, Stabilität, Feature, Stabilität. Nicht Feature, Feature, Feature, OMG!, Stabilität, Stabilität, Stabilität. Machen Sie die Dinge solide, bevor Sie mit dem nächsten Feature weiter machen.

Ärzte verstehen das. In der Notaufnahme wird der Patient zuerst stabilisiert. Sie kurieren niemand von der Grippe, wenn dieser am Verbluten ist.

Die Priorität von "Performance Defekten" steht zur Debatte. Mancherorts ist sie die gleiche wie für Stabilität.

9. Schreibt Ihr Team "Entwurfsdokumente"?

Ein Entwurfsdokument ist ein standardisiertes Format um neue Dinge vorzuschlagen oder bestehende Dinge zu beschreiben.

Gestalten Sie ein Muster und verwenden Sie es überall. Die Abschnittsüberschriften könnten folgendes enthalten: Überblick, Ziele, Nicht-Ziele, Hintergrund, Vorgeschlagene Lösung, In Betracht gezogene Alternativen, Sicherheit, Notfallwiederherstellung, Kosten.

Dieses Format kann für einen 20-Seiten-Plan zur Netzwerkrestrukturierung verwendet werden, wenn Sie die Einwilligung vieler Leute haben wollen. Es kann ein 5-Seiten-Dokument, das den Aufbau eines Prototypen beschreibt, sein, damit jeder Ihre Ergebnisse sehen und Feedback geben kann, bevor Sie die Produktivversion bauen. Es kann für eine 1-Seiten-Aktennotiz verwendet werden, in der Sie die Namen erläutern, die Sie für einen neuen Verzeichnisbaum auf dem Server planen. Verwenden Sie es um ein System zu dokumentieren, nachdem es als Referenz für andere in Ihrem Team aufgebaut wurde. Zum Teufel, verwenden Sie es um das Team-Picknick zu beschreiben, dass Sie planen.

Der Punkt ist, das Ihr Team einen Mechanismus hat, um zu Denken vor dem Tun, einen Weg, um Pläne zu kommunizieren, der über das Gespräch auf dem Flur oder Chatroom hinausgeht, und ein System, welches Artefakte hinterlässt, die andere verwenden können, um zu verstehen, wie etwas gemacht wurde.

Dieses Format funktioniert, wenn Sie Feedback suchen, sei es als ernsthafte Kritik oder nur "warn mich, falls das mit etwas kollidiert, was Du tun willst".

Ihr Entwurfsdokument kann mehr Überschriften haben oder weniger, einige könnten optional sein, andere notwendig. Eine Vorlage zu haben erleichtert es, anzufangen und vermeidet das Leere-Seite-Syndrom.

10. Gibt es einen "post-mortem" Prozess?

Schreiben Sie nach einem Ausfall auf, was passiert ist, so dass Sie davon lernen können, oder hoffen Sie nur, dass niemand etwas merkt und dass es vorbei geht?

Eine gute post-mortem Autopsie (PM) beinhaltet eine Zeitleiste dessen, was passierte, wer betroffen war, was unternommen wurde, um es zu beheben, wie das Tagesgeschäft beeinträchtigt war und eine Liste von vorgeschlagenen Lösungen um das Problem in Zukunft zu verhindern. Jeder Vorschlag sollte als Fehler oder Ticket eingereicht werden, so dass die Ausführung verfolgt werden kann.

PMs durchzuführen schafft durchwegs eine stabilere Umgebung. Kommen Sie nach jedem Ausfall mit mindestens einer vorbeugenden Maßnahme. Kann Ihr Monitoringsystem die Situation erkennen, so dass Sie davon eher wissen, als Ihre Benutzer? Können Sie Vorboten des Problems erkennen? Oft haben Systeme eine Möglichket für einen Batterietest oder zum Testen neuer Konfigurationen, bevor diese eingesetzt werden ("pre-submit scripts" in Quellcodeverwaltungen zum Beispiel). Können Sie Tests hinzufügen, die den Tippfehler erkennen, welcher zum Ausfall führte?

Das PM sollte für alle veröffentlicht werden. Sie mögen in Verlegenheit kommen und besorgt sein, dass Sie "die schmutzige Wäsche des Teams öffentlich waschen". Aber die Wahrheit ist, wenn Sie das konsistent tun, dass Ihre Benutzer sie mehr respektieren. Transparenz gebiert Vertrauen.

Natürlich, um wirklich Vertrauen zu entwickeln, müssen alle im Ergebnis eingereichten Fehler und Tickets auch wirklich bearbeitet werden.

C. Operative Praktiken

11. * Gibt es für jeden Dienst eine operative Dokumentation

Jeder Dienst sollte eine Mini-Website haben mit 7 Tabs:

1. Überblick: Überblick über den Service: was ist es, warum haben wir das, wer sind die Hauptkontaktpersonen, wie werden Fehler gemeldet, Verbindungen zu Entwurfsdokumenten und anderer relevanter Information.
2. Aufbau: Wie wird die Software zusammengestellt, die den Service ausmacht. Von wo wird sie heruntergeladen, wo ist das Quellcode-Repository, Schritte für den Compilierung und Paketierung oder andere Verteilungsmechanismen. Falls es Software ist, die Sie in irgendeiner Art verändern (Open Source Software zu der Sie beitragen oder ein lokales Projekt), fügen Sie Informationen hinzu, wie ein neuer Entwickler loslegen kann.
3. Einrichten: Wie wird die Software eingerichtet. Wie wird ein Server von Grund auf eingerichtet: RAM-/Platten-Anforderungen, Betriebssystemversion und Konfiguration, welche Software muss installiert sein und so weiter. Wenn das automatisiert ist, mit einem Konfigurationsmanagementwerkzeug wie cfengine/puppet/chef (und das sollte es), dann geben Sie das an.
4. Alltägliche Aufgaben: Schritt-für-Schritt-Instruktionen für alltägliche Dinge, wie Provisionierung (hinzufügen/ändern/entfernen), allgemeine Probleme und ihre Lösungen, und so weiter.
5. Pager Drehbuch: Eine Liste aller Alarmsignale, die Ihr Monitorsystem für diesen Dienst generieren könnte und eine Schritt-für-Schritt Anleitung "was ist zu tun, wenn..." für jede davon.
6. DR: Krisenplan und Prozedur. Wenn eine Maschine ausfällt, wie würden Sie auf die Reserver umschalten.
7. SLA: Leistungsvertrag. Der (gesellschaftliche oder reale) Vertrag, den Sie mit ihrem Kunden abschließen. Typischerweise das Verfügbarkeitsziel (wie viele 9en), Richtwerte für Wiederherstellungspunkte (RPO, recovery point objective) und -zeiten (RTO, recovery time objective).

Seien Sie ein Held und erzeugen Sie eine Schablone, die der Rest ihres Teams nutzen kann. Dokumentieren Sie einen grundlegenden Dienst wie DNS um loszulegen. Dokumentieren Sie einen größeren Dienst. Erzeugen sie ein Gerüst, so dass die anderen die fehlenden Stücke ausfüllen können. Starten Sie eine neue Mini-Website jedesmal, wenn sie ein neues Projekt beginnen.

12. * Wird jeder Dienst angemessen überwacht?

Es ist kein Dienst, wenn es nicht überwacht wird. Wenn es keine Überwachung gibt, dann lassen Sie nur Software laufen. - Limoncelli

Die Überwachung sollte auf dem SLA der operativen Dokumentation. Wenn Sie kein SLA haben, ist eine einfache "oben/unten" Alarmierung das Minimum.

Vergessen Sie nicht das Pager Drehbuch zu aktualisieren.

13. Gibt es einen Bereitschaftsplan?

Haben Sie einen Bereitschaftsplan oder sind sind Sie der Trottel der einfach für immer jederzeit verfügbar ist?

Ein Bereitschaftsplan dokumentiert, wer zu welchen Zeiten "den Pager mitführt" (oder für Alarme und Notfälle verantwortlich ist).

Sie können buchstäblich "den Pager weiterreichen", indem Sie ihn periodisch an die nächste Person weitergeben. Oder jeder hat einen eigenen Pager und Ihr Monitorsystem verwendet die Einteilung um zu bestimmen, wen es anpiepsen soll. Es ist am besten, eine generische E-Mail-Adresse zu haben, die an die derzeitige Person geht, so dass die Kunden den Plan nicht kennen müssen.

Ein Bereitschaftsplan kann einfach oder komplex sein. Eine Woche aller n Wochen (für ein Team von n Leuten) ist sinnvoll, wenn es wenige Alarme gibt. Für komplexere Situationen kann es sinnvoll sein, den Tag in drei 8-Stunden-Schichten aufzuteilen. Erdumspannender Support, der "der Sonne folgt", plant üblicherweise 8-Stunden-Schichten, so dass ein globales Team immer eine Schicht im Hellen hat. Sie könnten eine Woche von 8-Stunden-Schichten aller n Wochen haben, wenn Ihr Team 3n Leute hat. Die Variationen sind endlos.

Dieser Plan dient vielen Leuten: Ihnen, Ihren Kunden, dem Management und der Personalabteilung.

Er dient Ihnen, weil er Sie ein Leben ausserhalb der Arbeit planen lässt. Ich lege größten Wert auf eine gute Balance zwischen Arbeit und Freizeit. Wenn Sie keine gute Balance zwischen Arbeit und Freizeit haben und Sie keinen Bereitschaftsplan haben, dann hilf Dir selbst, Doktor.

Die Rotation verbessert den Kundendienst, weil es die "chaotische Panik einen Systemadministrator zu finden" herausnimmt und einfach und vorhersagbar ist.

Es dient dem Management, weil es das Vertrauen gibt, dass der nächste Notfall nicht passiert, wenn alle "weg" sind.

Es dient der Personalabteilung, natürlich, da Ihre Firma Ausgleichzeiten gibt oder entsprechend den Gesetzen zahlt. Wenn Ihr Plan in maschinenlesbarer Form vorliegt, kann ihn ein einfaches Script lesen, um den Bericht für die Lohnbuchhaltung zu generieren.

Wenn Sie glauben, Sie hätten keinen Plan, dann ist es "24x7x365" und Sie sind ein Trottel (aber das bedeutet nicht, dass sie "ja" auf diese Frage antworten können.

14. Haben Sie verschiedene Systeme für Entwicklung, QA und Produktion?

Entwickler machen ihre Arbeit auf den Entwicklerservern. Wenn sie glauben, dass sie fertig sind, werden Packages geschnürt und auf dem QA-System installiert. Wenn QA und UAT (User Acceptance Test, Benutzerakzeptanztest) zustimmen, werden die gleichen Packages verwendet, um die Software auf den Produktivsystemen zu installieren.

Das ist SysAdmin-Einmaleins, oder?

Warum treffe ich dann ständig Systemadministratoren, deren Management sie das nicht tun lässt? Wenn Ihr Management sagt, "das kostet zu viel", dann ist bei denen Hopfen und Malz verloren. QA ist nicht teuer. Wissen Sie, was teuer ist? Ausfallzeit.

Das QA-System muss nicht so teuer sein, wie sein Gegenstück im Produktivbereich. Es kann weniger RAM haben, weniger Plattenplatz und weniger CPU-Leistung. Das können virtuelle Maschinen sein, die sich eine große Maschine teilen.

15. Gibt es einen "Kanarienvogel-Prozess" bei der Produktivsetzung auf viele Maschinen?

Angenommen Sie müssen eine Änderung auf 500 Maschinen ausführen. Vielleicht ist es ein neuer Kernel. Vielleicht ist es nur eine kleine Fehlerbeseitigung.

Führen Sie die auf allen 500 aus? Nein. Sie führen es auf einer kleinen Anzahl von Maschinen aus und testen, um zu sehen, ob es Probleme gibt. Keine Probleme? Führen Sie es auf mehr Maschinen aus. Dann mehr und mehr, bis Sie fertig sind.

Diese ersten Maschinen nennt man "Kanarienvögel".

Das klassische Beispiel eines Tieres, das als Wächter dient, ist der Kanarienvogel in der Kohlenmine. Bis weit in das 20. Jahrhundert brachten im Vereinigten Königreich und in den Vereinigten Staaten Bergarbeiter Kanarienvögel in die Kohlenminen als Frühwarnsignal für giftige Gase, inklusive Methan und Kohlenmonoxid. Die Vögel, die empfindlicher sind, wurden schneller krank als die Bergarbeiter, welche dann eine Chance hatten zu entkommen oder Schutzmasken aufzusetzen. Quelle: Wikipedia

Hier sind einige Kanarienvogel-Techniken.

• Eine, ein paar, viele

  Erledigen Sie eine Maschine (vielleicht Ihr Arbeitsplatzrechner), dann ein paar Maschinen (vielleicht die Ihrer direkten Mitarbeiter), schließlich viele Maschinen (größere und größere Gruppen bis Sie fertig sind)

• Cluster-Kanarienvögel

  Aktualisieren Sie eine Maschine, dann ein Prozent aller Maschinen, dann eine Maschine pro Sekunde bis alle Maschinen durch sind. (Typisch bei Google und in Betrieben mit großen Clustern)

Diese Prozedur kann von Hand ausgeführt werden. Falls Sie ein Konfigurationsverwaltungssystem verwenden, sollte die Fähigkeit "Kanarienvögel" einzusetzen, eingebaut sein.

D. Praktiken der Automatisierung

16. Werden Konfigurationsmanagementwerkzeuge wie cfengine / puppet / chef verwendet?

Software für Konfigurationsmanagement (Config Management, CM) ist ein Werkzeug, das die Konfiguration von Maschinen koordiniert. Es könnte das Betriebssystem steuern, die Software, die angebotenen Dienste oder alles zusammen.

Vor CM erledigten die Systemadministratoren Änderungen an den Maschinen von Hand. Wenn Sie 100 Maschinen hatten, hatten Sie 100 Aufgaben von Hand zu erledigen. Gewiefte Systemadministratoren automatisierten solche Änderungen.

Noch gewieftere Systemadministratoren begriffen, dass allgemeine Werkzeuge für solcherart Automatisierung noch besser wären. Sie erfanden Automatisierungssysteme mit Namen wie track, cfengine, bcfg2, Puppet, Chef und andere.

Das Kennzeichen eines CM Systems ist, dass Sie beschreiben, was Sie wollen und die Software findet heraus, wie das zu tun ist. Was Sie wollen ist in beschreibenden Anweisungen spezifiziert wie "hostA ist ein Webserver" und "Webserver haben die folgenden Packages und Attribute". Die Software verwandelt das in Befehle, die ausgeführt werden müssen. Ein anderer wichtiger Aspekt ist, das die Anweisungen generisch sind ("installiere die Befehle in foo.sh als Cron-Job"), das CM System jedoch das richtige für das Betriebssystem des betreffenden Computers macht (es wählt aus zwischen /etc/crontab gegenüber /var/spool/cron).

Mit CM anstelle manueller Änderungen, ändern sie eine Konfigurationsdatei und lassen das CM-System die Arbeit tun.

Konfigurationsmanagement ist die ultimative Automation. Sie werden vom Zauberlehrling zu dem, der die Fäden zieht. Das ist keine Idee von Mickey Mouse.

17. Laufen automatisierte Aufgaben unter Rollenkonten?

Oft richten wir automatische Prozeduren ein, die zu vorbestimmten Zeiten laufen. Zum Beispiel ein Script, dass eine Datenbank einmal pro Nacht validiert.

In manchen Betrieben laufen diese Scripts mit den Rechten eines der Systemadministratoren. Wenn dieser Systemadministrator die Firma verläßt, stirbt das Script.

Gute Betriebe lassen diese Scripts unter einem Rollenkonto laufen, oft "root". Es ist jedoch sicherer, sie unter einem Konto mit weniger Privilegien laufen zu lassen.

18. Senden automatisierte Prozesse E-Mail nur dann, wenn sie etwas zu melden haben?

Kennen Sie die Geschichte von "dem Jungen, der Wolf rief"? Wie ist es mit: "Der Cronjob, den jeder ignorierte, weil er zweimal am Tage explodierte und niemand bemerkte, als er anfing Probleme zu berichten".

Meine Regel ist einfach:

• Wenn es jetzt einen menschlichen Eingriff benötigt: sende eine SMS.
• Wenn innerhalb 24 Stunden reagiert werden muss: sende eine E-Mail.
• Wenn es informatorisch ist: protokolliere es in eine Datei.
• Gib nichts aus, wenn es keine Informationen gibt.

Der schlimmste Fall ist ein System, dass Lognachrichten an jeden im Systemadministratorenteam sendet. Ihr E-Mail-System ist kein gutes Protokollarchiv.

Eine wahre Geschichte: Ein Freund in NYC arbeitete in einem Betrieb, wo alle automatisierten Prozesse ihre Ausgabe als E-Mail an root@the-company-domain sandten. "root" war die Mailingliste, die an alle Systemadministratoren in der Firma ging. Es war eine konstante Flut von Nachrichten. Die Systemadministratoren in dieser Firma konnten buchstäblich keine E-Mail lesen. Keine noch so gute Filterung war gut genug. Im Ergebnis nutzten die Systemadministratoren dieser Firma ihre privaten E-Mailkonten für alle Kommunikation, sogar für arbeitsbezogene Sachen. Welche Firma das war? Ein großer E-Mail-Provider, der nicht länger im Geschäft ist. (Ich frage mich, welche anderen schlechten Entscheidungen noch halfen, sie aus dem Geschäft zu bringen.)

E. Fuhrparkmanagementpraktiken

19. * Gibt es eine Datenbank aller Maschinen?

Jeder Betrieb sollte wissen, welche Maschinen er hat. Die Datenbank sollte wenigstens einige grundlegende Attribute speichern: Betriebssystem, Hauptspeicher, Plattengröße, IP-Adresse, Eigentümer, wer über Wartungsarbeiten informiert werden sollte, und so weiter.

Eine Datenbank aller Maschinen zu haben, ermöglicht es über alle Maschinen zu automatisieren. In der Lage zu sein, einen Befehl präzise auf den Maschinen mit einer bestimmten Konfiguration abzuarbeiten ist der Schlüssel für viele alltägliche Abläufe.

Diese Daten sollten automatisch eingesammelt werden, obwohl ein sehr kleiner Betrieb mit einer Kalkulationstabelle oder einer Wiki-Seite auskommen kann.

Ein Inventar wie dieses zu haben lässt Sie Entscheidungen auf der Basis von Daten treffen und hilft Ihnen Problemen vorzubeugen.

Ich kenne eine kleine Universität in New Jersey, die einen größeren Ausfall hätte verhindern können, wenn Sie ein besseres Inventar gehabt hätte: Sie versuchten alle ihrer PCs auf die letzte Version von Microsoft Office zu aktualisieren. Der Executivrat freute sich, dass es endlich einen Tag geben würde, wenn Versionsinkompatibilitäten nicht jede Interaktion zu einer Übung in Frustration machen würden. Und zusätzlich alle diese neuen Feature! Oh wie der Enthusiasmus in Verbitterung umschlug, als das Projekt kollabierte. Es stellte sich heraus, das ein Drittel der Maschinen auf dem Campus nicht genug Hauptspeicher oder Plattenplatz hatten. Willkürliche Segmente der Universität konnten auf Grund verpfuschter Aktualisierungen keine Arbeit mehr schaffen. Der Exekutivrat war nicht nur verärgert, sondern ist jetzt risikofeindlich. Es wird eine lange Zeit vergehen, bis wieder Aktualisierungen kommen. Das alles wäre verhindert worden, wenn ein gutes Anlagenverwaltungssystem vorhanden wäre. Eine einfache Abfrage hätte eine Liste von Maschinen produziert, die ein Upgrade benötigen. Budgetierung und Aufwandsschätzungen hätten im Rahmen der Aktualisierung bereitgestellt werden können.

20. Ist die Installation des Betriebssystem automatisiert?

Automatische Betriebssysteminstallationen sind schneller, konsistenter und lassen den Benutzer eine Aufgabe mehr machen, so dass Sie es nicht tun müssen.

Wenn das Betriebssystem automatisch installiert wird, dann sind am Anfang alle Maschinen gleich. Entropie zu bekämpfen ist schwer genug. Wenn jede Maschine von Hand gefertigt wird, ist es unmöglich.

Wenn Sie das Betriebssystem von Hand installieren, verschwenden Sie Ihre Zeit doppelt: einmal, während Sie die Installation ausführen und jedesmal wieder, wenn sie einen Fehler suchen, der durch konsistent konfigurierte Maschinen verhindert worden wäre.

Wenn zwei Leute Betriebssysteme von Hand installieren, ist die Hälfte verkehrt, aber Sie wissen nicht, welche Hälfte. Beide mögen behaupten, dass Sie dieselbe Prozedur verwenden, aber ich versichere Ihnen, dass dem nicht so ist. Stecken Sie jeden in einen anderen Raum und lassen Sie sie ihre Prozedur niederschreiben. Dann zeigen Sie jedem Systemadministrator die Liste des anderen. Das gibt eine Prügelei.

Benutzer sehen Inkosistenzen als Inkompetenz. Wenn neue Maschinen mit einer Einstellung, die ihnen nicht passt, eintreffen, wissen sie, wie sie die Einstellung ändern müssen und sind glücklich. Wenn in der Hälfte der Fälle diese Einstellung so eingestellt ist und in der andern Hälfte anders, verlieren Sie das Vertrauen in den Systemadministrator. Welcher Dummkopf installiert diesen Kram?

Wenn Sie ein Betriebssystem automatisch neu installieren können, dann kann das auch der Benutzer. Nun haben Sie eine Sache weniger zu tun. Automatisierung die Ihnen Zeit spart, ist gut. Automatisierung, die andere Leute Aufgaben tun läßt, ist noch besser.

Nicht in der Lage zu sein, eine Maschine einfach zu reinigen und wieder zu laden ist eine Sicherheitsfrage. Eine Maschine sollte gelöscht und neu installiert werden, wenn ein gebrauchter Computer von einem Benutzer an einen anderen weiter gegeben wird. Wenn dieser Prozess nicht reibungslos funktioniert, gibt es die Versuchung "Zeit zu sparen" und das nicht zu tun.

21. * Können Sie Software automatisch über alle Systeme aktualisieren?

Wenn die Installation des Betriebssystems automatisiert ist, dann starten alle Maschinen gleich. Wenn Aktualisierungen automatisiert sind, dann bleiben alle Maschinen aktuell. Konsistenz ist eine gute Sache.

Sicherheitsaktualisierungen sind sehr wichtig, weil die Betriebssicherheit Ihrer Systeme diese erfordert. Nicht sicherheitsbezogene Aktualisierungen sind wichtig, weil die Funktionsfähigkeit Ihres Systems diese erfordert und weil sie neue Features für Ihre Kunden bringen. Aktualisierungen zurückhalten ist wie Eltern, die Liebe zurückhalten. Wer hat Sie aufgezogen?

Anwendungen aktualisieren ist ebenso entscheidend wie Aktualisierungen der Betriebssystems. Anwender treffen keine Unterscheidung zwischen "Betriebssystem" und "Anwendung", besonders wenn eine Anwendung weitverbreitet ist. Die bösen Jungs, die Schadprogramme schreiben, machen auch keinen Unterschied.

Ich wünschte, Banken müssten ihre Aktualisierungsprozesse veröffentlichen, so dass ich entscheiden könnte, wo ich mein Geld hingebe.

Die Alternative zur Automatisierung ist, jede Maschine eine nach der anderen zu besuchen. Das ärgert die Benutzer, verschwendet ihre Zeit und ist ein dummer Gebrauch Ihrer Zeit. Mit der Ausbreitung von Laptops ist es nicht einmal mehr sinnvoll daran zu denken, dass Sie jede Maschine besuchen können.

Wenn möglich, sollten Aktualisierunge stillschweigend erfolgen. Wenn Sie einen Neustart oder andere Unterbrechungen erfordern, sollten Benutzer die Möglichkeit haben, die Aktualisierung aufzuschieben. Jedoch sollte es eine Grenze geben, vielleicht 2 Wochen. Jedoch sollte diese Frist einstellbar sein, so dass Notfallsicherheitsaktualisierungen eher passieren können.

22. Gibt es eine Hardware-Erneuerungs-Richtline?

Wenn Sie keine Richtlinie darüber haben, wann Maschinen ersetzt werden, werden sie niemals ersetzt.

Ein bestimmter Anteil Ihrer Flotte sollte alt sein, das ist einfach ökonomisch. Jedoch sind extrem alte Maschinen teurer zu unterhalten als zu ersetzen. Es ist eine Verschwendung Ihrer Zeit, eine Zwischenlösung zu erstellen, so dass neue Software auf untermotorisierten Maschinen läuft. Es ist eine Verschwendung der Zeit Ihrer Benutzer, auf langsame Computer warten zu müssen. Es ist schlechtes Zeitmanagement und schlecht für die Produktivität mit stark veralteten Maschinen zu arbeiten.

Unternehmen kommen oft in diese Situation. Manchmal "sparen sie Geld", indem sie die Maschinen nicht aktualisieren, aber es spart kein Geld, wenn Angestellte mit Werkzeugen arbeiten müssen, die nicht gut funktionieren. Manchmal begreifen sie einfach nicht, dass Computer nicht ewig halten.

Wenn Sie keine Richtlinie haben, hier ist eine einfache, mit der Sie beginnen können: Alle Computer haben einen 3-Jahres-Abschreibungsplan. Jedes Jahr enthält das Budget Posten um ein Drittel aller Maschinen zu ersetzen. Am ersten Tag jeden Quartals werden genügend Maschinen bestellt, um die 9 Prozent der ältesten Maschinen in der Flotte zu ersetzen.

CFOs mögen das, weil sie Vorhersagbarkeit mögen. In einer Firma war die CFO ganz aufgeregt, als ich Ihr die Kontrolle darüber gab, in welchem Monat die Aktualisierungen passieren würden. Wir einigten uns, dass ein Viertel aller Aktualisierungen in jedem Quartal passieren würden und sie konnte den Monat aussuchen, in dem es los geht. Sie konnte es sogar in individuelle monatliche Lose aufteilen.

Anstelle dann und wann zum CFO zu kommen und um neue Arbeitsplatzrechner zu bitten, war es eine regelmäßige, geplante Aktivität. Weniger Pein für alle.

Extra-Tipp: In manchen Firmen haben Server einen anderen Abschreibungsplan: sie sind so ausgelegt, dass sie länger halten und haben daher eine 4-Jahres-Abschreibung. Andererseits werden ihre Kosten über alle Benutzer amortisiert und Sie können daher eine zweijährige Abschreibung rechtfertigen.

F. "Wir geben zu, dass Hardware kaputt geht" Praktiken

23. * Können die Server weiterarbeiten auch wenn eine Platte kaputt geht?

Alle Daten auf Servern sollten mit einem RAID1/5/6/10 oder ähnlichem Schutzschema gespeichert werden. Server sollten mit einer "überlebensfähigen Architektur" entworfen werden. Sie sollten Komponentenfehler überstehen können.

Es war üblich, dass Sie einen Ausfall hatten, wenn einen kaputte Komponente in einem Computer war. In der Tat bedeutete ein Komponentenfehler einen Ausfall. Eine Platte stirbt und Sie verbringen den Tag damit sie zu ersetzen und die Daten vom Bandlaufwerk wieder herzustellen. Schade um die Arbeit, die Sie tun wollten, Schade falls Sie planten am Firmenausflug teilzunehmen. Eine kaputte Platte ruinierte ihren ganzen Tag; gerade wie ein Nuklearkrieg.

Heute sind die Dinge anders. Wie bauen "überlebensfähige Systeme". Wenn eine Platte Teil eines gespiegelten Paares ist, dann kann eine dieser Platten ausfallen und es ist kein Gesamtausfall. Es gibt nur einen Ausfall, wenn der gespiegelte Partner auch noch ausfällt. Statistisch gibt Ihnen das Stunden, möglicherweise Tage um die kaputte Platte zu ersetzen, bevor ein Ausfall für die Benutzer sichtbar wird. Sich beeilen eine Platte zu ersetzen ist ein besserer Gebrauch ihrer Zeit, als den Tag damit zu verbringen, Daten vom Band wiederherzustellen.

Wenn Sie das machen, entkoppeln Sie Komponentenfehler von Ausfällen. Das Leben ist besser.

RAID war teuer und selten. Ein Luxus für die Reichen. Jetzt ist es alltäglich, billig und oft frei (wenn es in Software realisiert wird). Sagte ich alltäglich? Ich meinte obligatorisch. Den Tag mit der Wiederherstellung von Daten aus Bandsicherung zu verbringen, ist nicht nur ein Zeichen schlechter Planung, es ist schlechtes Zeitmanagement. Den Tag damit zu verbringen einen verzweifelten Benutzer zu trösten, der Jahre, Monate oder auch nur Stunden von Arbeit verloren hat, ist nicht heldenhaft, es ist Zeitverschwendung.

Meine Daumenregel ist einfach: Bootplatte gespiegelt, alle anderen Platten RAID1 oder höher.

[Sie wissen, dass RAID6 das Minimum ist für 2T Platten und größer, ja? Es ist professionell fahrlässig RAID5 auf solchen Platten zu benutzen. RAID6 oder RAID10 ist das Minimum; zumindest im Moment, aber ich schweife ab ...]

Es gibt ein paar kleine Ausnahmen.

Ausnahme 1: Kritzel- und temporärer Platz. Das ist offensichtlich.

Ausnahme 2: Wenn die Daten auf höherer Ebene repliziert werden, wie ...

1. Die Verwendung eines extravaganten redundanten Dateisystems wie das Google File System (GFS). GFS speichert alle Daten in wenigstens 3 Plätzen. IBM's GPFS Native RAID (GNR) macht etwas ähnliches.
2. Die Daten sind Read-Only-Kopien von anderswo gefundenen Daten. Falls Sie allerdings wegen der Geschwindigkeit replizieren, gibt Ihnen RAID5 einen Performanceschub, weil es mehr Spindeln verwendet.
3. Wegwerfmaschinen. Zum Beispiel ein Webserver mit statischen Seiten oder ein DNS "secondary and cache-only" Server, der schnell und automatisch wieder aufgesetzt werden kann. Wenn Sie davon Hunderte haben, können die Einsparungen dadurch, dass Sie keine RAID-Karten kaufen, dramatisch sein.

24. Ist der Netzwerkkern N+1?

Ein Ausfall für eine Person ist eine Schande. Ein Ausfall von vielen Leuten ist inakzeptabel. So wie redundante Platten nun ein Minimum sind, ist es eine doppelte Netzwerkanbindung ebenfalls.

Ja, es wird noch erwartet, dass da eine Verbindung von der Arbetsstation zum ersten Switch ist. Aber danach sollte alles N+1 redundant sein. Als Minimum sollten alle Stammleitungen zwei Netze haben. Am besten ist es, wenn jede beliebige Uplink-Verbindung, jede beliebige Karte, oder jeder beliebige Netzwerk Router/Switch/Hub ausfallen könnte und die Pakete trotzdem durchkommen.

LANs werden regelmäßig folgendermaßen entworfen: Die Laptops/Arbeitsstationen in einem Büro werden an der Wandsteckdose angeschlossen. Diese verbinden zu "Zugangs-Switchen", die viele Ports haben. Diese Zugangs-Switche haben "Nervenstämme", die zu einer Hierarchie von "Kern-Switchen" verbinden, welche die Pakete zu richtigen Stelle sausen lassen, möglicherweise zu Ausgängen (die Verbindungen zu anderen Gebäuden oder dem Internet).

Meine Regel ist einfach: Der Kern muss redundant sein. Es war mal ein teurer Luxus für die Reichen. Nun ist es eine Minimalanforderung.

Wenn Ihr Betrieb nicht so konfiguriert ist, dann leben Sie in den Tagen, als Computer noch ohne Netzwerk nützlich waren.

Ausnahme: Betriebe, die klein genug sind, dass sie keinen Kern haben. Selbst dann sollten alle Stämme redundant sein und ein Austauschsatz sollte für jede Art von Gerät bereitstehen.

25. * Sind Backups automatisiert?

Diese Frage setzt voraus, das Sie Backups machen. Sie machen Backups, ja?

Sie brauchen Backups aus 4 Gründen: (1) Ups, ich habe eine Datei gelöscht. (2) Ups, die Hardware ist ausgefallen. (3) Oh nein, das Haus ist abgebrannt. (4) Archive. Jeder von diesen kann unterschiedliche Backup-Methoden erfordern.

Situation (1) wird kurzfristig, aber nicht langfristig durch Speicherauszüge gelöst. Manchmal wird eine Datei gelöscht und muss erst viel später wieder hergestellt werden. Einfache Speicherauszüge werden da nicht helfen. RAID hilft in dieser Situation nicht. RAID ist kein Backup-Mechanismus. Wenn jemand eine Datei aus Versehen löscht, wird RAID pflichtbewusst dieses Versehen auf allen Spiegeln replizieren. Sie werden ein redundantes Array von fehlerhaften Daten (Redundant Array of Incorrect Data) haben.

Situation (2) klingt, als ob RAID helfen würde, aber erinnern Sie sich, dass Fehler an zwei Platten bedeuten kann, dass Sie den ganzen RAID1-Spiegel oder das komplette RAID5-Set verloren haben. RAID10 und RAID6 verliefen alle Daten bei Fehlern an drei Platten. Diese Dinge passieren. Sie sind nur einen ungeschickten Elektriker weit entfernt von einer Zerstörung aller Platten auf einmal. Wirklich.

Situation (3) wird oft Disaster Recovery (Krise) genannt. Backups an einem anderen Ort, ob auf Platte oder Band, sind hier ihre einzige Hoffnung.

Situation (4) gibt es oft auf Grund geltender Vorschriften. Die Technologie für das Backup ist oft die gleiche wie in Situation 3 aber die Rückhaltezeit ist üblicherweise verschieden. Wenn einen andere Abteilung das auf Grund geltender Vorschriften anfordert, sollten diese für die Medien bezahlen.

Für jeglichen dieser Gründe muss der Prozess automatisiert werden. Während das Haus abbrennt, wollen sie nicht das Management informieren, dass die Daten verloren sind, weil "ich in Urlaub war" oder "ich es vergessen habe".

Schließlich ist Automatisierung wichtig, weil eine Mega-Band-Bibliothek billiger ist, als Sie. Ja, Sie könnten einen Angestellten einstellen um die Bänder alle Tage zu wechseln. Sie können auch einen Bandbibliothek anschaffen mit genügend Kapazität um alle Backups für einen Monat zu halten. Die Bibliothek wird billiger sein. Die Bibliothek sollte in der Lage sein, genügend Bänder vorzuhalten, für einen Zeitraum, der doppelt so lang ist wie der längste Urlaub, den Sie nehmen wollen.

26. * Werden die Krisenpläne regelmäßig getestet?

Die letzte Sektion war ein wenig gelogen. Es gibt nicht 4 Gründe, um Backups zu machen. Es gibt 4 Gründe um Dateien wiederherzustellen.

Niemand interessiert sich für Backups. Die Leute interessieren sich nur für die Wiederherstellung. Wenn Sie herausfinden, wie man Daten ohne vorheriges Backup wiederherstellen kann, werde ich mich beim Nobel Kommitee einsetzen, einen Preis für Systemadministratoren zu schaffen, nur damit Sie der Erste sein können, der ihn bekommt.

Sie wissen nicht, ob Backups gültig sind, bis Sie sie testen. Glaubensbasierte Backupsysteme sind nicht gut. Hoffnung stärkt uns, aber sie ist keine IT "Strategie".

Ein voller Test beinhaltet einen Totalausfall und eine volle Wiederherstellung.

Sie wissen nicht, wie viel Zeit Sie wirklich brauchen, bis Sie es ausprobieren. Wiederherstellungen vom Band brauchen of zehnmal so lange, wie das Backup. Wenn Sie ein volles Backup für Ihren Lohnbuchhaltungsserver in 8 Stunden machen können, dann bereiten Sie sich darauf vor, für 80 Stundne keinen Lohnzahlungen zu leisten, falls Sie das System von Grund auf wiederherstellen müssen. Das sind mehr als 3 Tage.

Wenn Sie überhaupt keine Tests machen, dann ist etwas Testen besser als gar nichts. Schreiben Sie ein kleines Script, das zufällig einen Server auswählt, dann zufällig eine Platte auf diesem Server auswählt, dann zufällig eine Datei auf dieser Platte. Dieses Script sollte ein Ticket erzeugen, das daraum bittet, diese Datei wiederherzustellen, so wie sie vor 6 Wochen aussah. Lassen Sie dieses Script jede Woche automatisch laufen. Damit haben sie eine gute Chance einen Server oder eine Platte zu finden, die noch nicht im Backupplan war. Außerdem, wenn Sie glauben, dass diese Wiederherstellungen eine Menge Arbeit für Sie sind, hier ist ein Geheimnis: es braucht überhaupt keine Zeit für Sie, wenn ihre Mitarbeiter das Ticket abarbeiten. Erzeugen Sie das Ticket mit genug zufälligem Text, so dass sie nicht wissen, dass es eine Übung ist.

Um das einen Schritt weiter zu führen, planen Sie einen "Spieltag", bei dem die Krisenpläne wirklich getestet werden. Geben Sie vor, das bestimmte Leute tot sind und stellen Sie sicher, dass die verbleibenden Leute wissen, wie sie die Dienste umstellen. Schreiben Sie Scripts, die dokumentieren, welche Tests ausgeführt werden. Entweder rufen Sie wirklich Ausfälle hervor (ziehen sie das Strom- oder Netzwerkkabel), oder spielen Sie die Szene: die "tote" Person kann den Test beaufsichtigen. "Ok, nehmen wir an, Du bekamst diese Nachricht. Zeig mir die Befehle, die Du eingibst und die Aktionen die Du ausführst." Eine andere Methode ist es, Ihrem CEO zu erlauben in das Datenzentrum zu spazieren und irgendein Kabel nach seinem Belieben zu ziehen.

27. Haben die Maschinen im Datenzentrum Fernzugang für Strom / Konsole?

Das benötigt kaum Erklärung. Fernkonsolen (IP-basierte KVM-Umschalter) sind billig, gute Server haben sie eingebaut. Fernsteuerung für die Stromzufuhr ist kein Luxus, wenn der Computer mehr als ein paar Kilometer entfernt ist.

Die Ausnahme zu dieser Regel sind Grid-Computer-Systeme mit Hunderten oder Tausenden von identischen Maschinen. Wenn eine ausfällt, kann eine andere Ihren Platz einnehmen.

G. Sicherheitspraktiken

28. * Läuft auf den Desktops / Laptops / Servern selbstaktualisierende, stille Antischadsoftware?

Viren und Schadsoftware sind eine Tatsache. Wenn Sie glauben, schlechte Dinge passieren guten Menschen nicht, dann müssen wir alle schlechte Menschen sein. Jede Maschine braucht heute Antischadsoftware.

Jeder Angriff von Schadsoftware bedeutet Arbeit für Sie: ausgefallene Maschinen aufräumen, Daten wiederherstellen, Benutzer trösten über ihren Datenverlust. Es ist eine Zeitverschwendung für Sie, eine unentschuldbare Störung für Ihre Benutzer. Es ist schlechtes Zeitmanagement.

Antischadsoftware muss sich regelmäßig selbst aktualisieren. Manche Antischadsoftware öffnet ein großes Fenster das sagt, "Da ist ein neues Update. Hätten Sie gern, dass ich das installiere?". Das ist ein wichtiges Fenster, weil da das Software-Logo drin erscheint. Wenn die Benutzer die Marke der Antischadsoftware kennen, die verwendet wird, können sie diese ihren Freunden empfehlen. Es hilft dem Herstellers Aktienkurs, wenn jedermann ihren Namen kennt. Es macht nichts, dass 9 von 10 Mal der Benutzer auf "nein" klickt. Software die sich stillschweigend aktualisiert ohne animierte "Update" Benachrichtigung hat diesen Vorteil nicht. Wie unverantwortlich von der Firma, nicht ihren Eigentümern zu nutzen.

Falls Sie nicht sicher sind. Das ist sarkastisch.

Es gibt viele Antischadsoftware-Produkte. Das, was Sie installieren, sollte sich stillschweigend aktualisieren.

Es ist Ihre Aufgabe die Sicherheitsrichtlinien durchzusetzen und Aktualisierungen herunterzuladen ist Teil dieser Richtlinie. Diese Verantwortung auf den Benutzer zu delegieren ist falsch und möglicherweise unethisch. Sie fragen keine Fußgänger "Soll ich auf die Bremse treten und Sie nicht überfahren?" und Sie fragen auch nicht einen Benutzer um die Erlaubnis weniger sicher zu sein. Ja, wir haben 300 Baud Modems verwendet und eine Virendefinitionsdatei zu laden dauerte 30 Minuten. Sie waren damals nicht mal geboren. Sie können diese Entschuldigung nicht verwenden. Wenn Sie damals schon dabei waren (wie ich), dann sind Sie alt genug um es besser zu wissen.

Aus ähnlichen Gründen sollte die Antischadsoftware nicht enfach durch die Benutzer abgeschaltet werden können. Benutzer werden sie aus den absurdesten Gründen abschalten. Es ist alltäglich für Benutzer, sie abzuschalten um ihren Computer schneller zu machen. Ich hatte einmal einen Benutzer, der sie abschaltete, weil "es Viren auf meine Maschine zieht". Sehen Sie, erklärte er, als es eingeschaltet war, machte es andauernd Fenster auf, die vor Viren warnten. Als er es ausschaltete, waren keine Warnungen mehr da. Ja, Leute mit solchen Missverständnis von Ursache und Effekt gibt es.

Antischadsoftware war "schön zu haben", aber jetzt ist es eine Anforderung. Das sind meine persönlichen Regeln:

1) Antischadsoftware-Scanner müssen auf allen Maschinen laufen, inklusive jeglicher Server, die Benutzerkontrollierte Daten haben: Home-Verzeichnisse, Dateifreigaben, Website-Inhalte, FTP-Server und so weiter.

2) Scanner müssen sich automatisch und stillschweigend aktualisieren. Keine Benutzerbestätigung.

3) Es muss einen Mechanismus geben, der erkennen läßt, wenn Sie ausgeschaltet sind. Sie sollten sich bei einem zentralen Server anmelden, so dass man sehen kann, welche Maschinen nicht mehr aktualisiert werden.

4) E-Mail muss auf dem Server gescannt werden, nicht auf dem Client (oder zusätzlich zum Client). Nachrichten mit Schadsoftware müssen verworfen werden; Nachrichten mit Spam sollten in Quarantäne kommen. Sie kann nicht darauf vertrauen, dass jede individuelle Maschine die gleichen, hochwertigen, aktuellen Filter hat, wie Sie sie auf dem Server pflegen kann. Stoppen Sie das Problem bevor es zum Klienten kommt.

29. * Gibt es eine schriftliche Sicherheitsrichtline?

Existierende Sicherheitsrichtlinien anzuschauen, ist ein guter Weg, Ideen zu bekommen. SANS hat eine Bibliothek von Beispielen:

http://www.sans.org/security-resources/policies/

Es ist entscheidend, einen schriftliche Sicherheitsrichtline zu haben, bevor Sie sie umsetzen.

30. Gibt es regelmäßige Sicherheitsüberprüfungen?

Das braucht kaum Erläuterung. Wenn Sie Ihre Sicherheit nicht testen, wissen Sie nicht, wie angreifbar Sie sind.

31. Kann ein Benutzerkonto auf allen Systemen innerhalb einer Stunde deaktiviert werden?

Das zeigt eine Menge mehr über Ihr Team und die Umgebung, die Sie betreiben, als nur ob Sie ein Konto sperren können oder nicht. Es kennzeichnet die Verwendung eines globalen einheitlichen Benutzerkontensystems.

Eine einzige Authentifizierungsdatenbank, die alle Systeme nutzen, zu haben, ist nicht mehr nur "wäre schön". Es ist ein "muss da sein". Wenn Sie glauben, dass Sie es nicht brauchen, bis Sie größer sind, werden Sie herausfinden, dass Sie keine Zeit haben es zu installieren, wenn Sie damit beschäftigt sind, zu wachsen.

Die beste Praxis ist Managementsysteme für den Lebenszyklus von Benutzerkonten (Benutzerkontenlebenszyklusmanagementsysteme) zu verwenden. Mit solch einem System werden Benutzerkonten erzeugt, verwaltet und gesteuert von vor der Anstellung über Lebensänderungen bis zur Kündigung und darüber hinaus. Was ist, wenn sich der Name eines Benutzers ändert? Was, wenn jemand wieder in der Firma angestellt wird? Was, wenn sie wieder eingestellt werden und der Name sich geändert hat? Es gibt eine Menge Grenzfälle, die sie handhaben können sollten.

32. Können alle privilegierten (root) Kennworte innerhalb einer Stunde geändert werden?

Das zeigt ebenfalls mehr als die Frage im Speziellen fragt. Es zeigt, ob Ihr administrativer Zugang wohl verwaltet ist.

Wenn Sie das nicht können, erzeugen Sie eine Checkliste aller Stellen, die geändert werden müssen auf einer Wiki-Seite. Ändern Sie das Kennwort global, indem Sie dieser Liste folgen, wobei Sie sie ergänzen, wenn Sie sich an andere Geräte erinnern. Für obskure Systeme, dokumentieren Sie den exakten Befehl oder Prozess um das Kennwort zu ändern.

Wenn Sie das können, erzeugen Sie eine Wiki-Seite, die dokumentiert, wie dieser Prozess zu aktivieren ist (und dann listen Sie alle Ausnahmen, die immer noch von Hand erledigt werden).

---

Dank an alle Leute, die Feedback zu Vorabversionen gaben: Strata Chalup, Sabrina Farmer, Aeleen Frisch, Doug Hughes, Duncan Hutty, Ski Kacoroski, Christina Lear, Edward Marczak, Troy Mckee, Adam Moskowitz, Tanya Reilly, Matt Simmons, Josh Simon, Nicole Forsgren Velasquez. (Insbesondere Aeleen and Ski für Ihre Hilfe, die Liste zu reorganisieren und Josh und Nichole für ausgiebige Hilfe bei der Bearbeitung.)