Tzeen
NPC
- Mitglied seit
- 03.11.2006
- Beiträge
- 5
- Reaktionspunkte
- 0
- Kommentare
- 1
- Buffs erhalten
- 3
Das habe ich heute bekommen und da ich es sooo super finde will ich es Euch nicht vorenthalten...
Never Touch a Running System
(Wir warten erst, bis nichts mehr geht)
Benedikt Stockebrand
03. Juni 2003
Zusammenfassung
Kaum eine Bauern- oder besser gesagt Sysadmin-Regel wird so oft und so fatal miverstanden
wie
"
Never Touch a Running System\. Der Vortrag untersucht die Herkunft und ursprungliche
Bedeutung der Regel, ihre Anwendbarkeit auf heutige IT-Umgebungen, gangige Fehlinterpretationen,
ihren bewuten Mibrauch und wie ein Systemadministrator mit diesem Phanomen
umgehen kann.
Benedikt Stockebrand Never Touch a Running System
1 Woher kommt die Regel
"
Never Touch a Running System\?
Auf der Suche nach der Herkunft der Regel gab nur Fehlschlage: Das Jargon File brachte nichts
zutage, meine alteste Fachliteratur war genauso wenig hilfreich und auch wenn Google die ublichen
"ungefahr 1660\ Hits fand, war doch nichts relevantes|auer der Vortragsankundigung|dabei.
Personlich war ich davon etwas uberrascht.
2 Was war ursprunglich ihre Intention?
Auch die nachste Frage, was die ursprungliche Aussage der Regel war, bringt eine Uberraschung
mit sich: Es gibt eine Reihe unterschiedliche Zusammenhange, in denen die Regel jedesmal eine
andere Bedeutung hat:
Warte bis nach Betriebsschlu. Wer schon einmal mit "klassischen\ Produktivsystemen zu
tun hatte, die nur zu "Geschaftszeiten\ laufen mussen, wird sofort an diese Interpretation
denken. Generell gilt, da man Arbeiten an einem Produktivsystem in moglichst unkritische
Zeitfenster legen sollte|so es denn noch solche Zeitfenster gibt.
Wer zum Beispiel die Server der Finanzbuchhaltung unmittelbar vor dem Zahltag stillegt,
wird sich bei seinen Kollegen nicht beliebt machen.
Das ist nach meinem Wissen die ursprungliche Aussage der Regel.
Erst denken, dann handeln. So ziemlich jeder, der schon einmal fur die Administration von
betriebsrelevanten Systemen verantwortlich war, kennt das Phanomen: Irgend etwas geht
immer schief und wenn wichtige Services betro en sind, geht alles durcheinander und vor
allem der Adrenalinspiegel in ungeahnte Hohe. In dieser Situation ist es entscheidend, mit
sauberen Fehlerbehebungsmethoden das Problem unter Kontrolle zu bringen und sich nicht
zu blindem Aktionismus verleiten zu lassen; sonst wird der Schaden nur noch groer.
Ein Beispiel, das ich von einem Kollegen gehort habe, betraf ein RAID5-Plattensystem. Eine
Platte war ausgefallen, das Array machte sich durch eine eingebaute Hupe lautstark bemerkbar.
Der Servicetechniker, der die defekte Platte austauschen sollte, zog wahrend der Kunde
sich noch uber besagte Hupe beschwerte versehentlich die falsche Platte aus dem laufenden
Array (und besagter Kollege durfte anschlieend ein Desaster Recovery durchfuhren). . .
Auch wenn dieser Punkt o ensichtlich wichtig ist, bleibt er doch eher ein Thema, das unter
dem Stichwort "handhabbare Systeme\ in der Systemarchitektur und im Prozessmanagement
eine zentrale Rolle einnehmen sollte. Deshalb betrachten wir ihn im Rahmen dieses Vortrags
nicht weiter.
Tanz immer nur auf einer Hochzeit. Im Umgang mit Produktivsystemen ist es wichtig, sich
immer auf ein einzelnes Problem zu konzentrieren und nicht unnotig an mehreren Fronten
gleichzeitig zu arbeiten.
Vor langerer Zeit hatte ich einmal das Vergnugen, ein angeblich gehacktes System untersuchen
zu durfen. Ergebnis: Die externen "Application Admins\, die auf dem System dummerweise
Root-Rechte hatten, hatten nicht nur an ihrer Anwendung herumgeschraubt, sondern
nebenher fur Root eine "richtige\ Shell eingerichtet: /bin/bash. Das System war aber kein
Linux, sondern ein Solaris, so da man sich anschlieend als Root mangels existierender Shell
nicht mehr einloggen konnte.
Neben der personlichen Arbeitsweise betri t dieses Problem auch die Betriebsorganisation:
Nur wer Aufgaben der Reihe nach abarbeiten kann, statt im Interrupt-Betrieb seine Zeit zu
verlieren, wird auch Qualitat liefern.
1
Benedikt Stockebrand Never Touch a Running System
Unnotige Risiken sind genau das: Unnotig. Es kommt gelegentlich vor, da an einem laufenden
System Arbeiten durchgefuhrt werden, die keinerlei Nutzen bringen, aber moglicherweise
zu erheblichen Problemen fuhren konnen.
Auch wenn die meisten Sysadmins das klassische Beispiel in dieser Kategorie, das Flashen von
PC-BIOSsen, verstanden haben, gibt es genug Stellen, wo dieses Verhalten auer Kontrolle
gerat: Unter Linuxern ist es oft der neueste Kernel, der unbedingt installiert werden mu, ein
namhafter Unix- und Hardware-Hersteller erwartet von Kunden mit Problemen regelmaig
zuerst die Installation der aktuellen "Recommended Patches\(obwohl sie keine "Required
Patches\ sind), bevor er uberhaupt vertragsgema anfangt, Probleme zu suchen und eventuell
zu beheben und eine andere groe Software rma uberredet ihre Kunden regelmaig im
Abstand von zwei bis drei Jahren, neue, teilkompatible Versionen ihrer "Betriebssysteme\
und "Buroanwendungsprogramme\ zu kaufen und zu installieren.
Die letzten beiden Beispiele zeigen, da das Problem nicht allein in der Systemadministration,
sondern nur zusammen mit dem ubergeordneten Management losbar sein kann.
3 Warum ist sie heute so gefahrlich?
Wo sind nun die Probleme mit diesen Interpretationen der Regel? Soweit sind sie doch eigentlich
sehr schlussig. Der Untertitel des Vortrags verrat das Problem: "Never Touch\ fuhrt allzu oft
dazu, da potentiell kritische Probleme erst behoben werden, nachdem sie zu einem Schaden
gefuhrt haben.
3.1 Verschleppte Aufgaben
Die wenigsten Sysadmins haben heute so viel Langeweile, da sie in blinden Aktionismus verfallen.
Weit verbreitet ist aber das Problem, da aus Zeitnot wichtige aber nicht unbedingt eilige Arbeiten
immer wieder hinausgeschoben werden, bis sie dann nicht nur wichtig sind, sondern auch eilig
werden|weil eben "nichts mehr geht\. An dieser Stelle verkommt die Regel zu einer Ausrede|es
lauft, also kann ich die Aufgabe, das ich ja durchaus sehe, erstmal liegenlassen.
Mit der ublichen Arbeitsuberlastung fuhrt das aber dazu, da die Aufgabe dauerhaft liegenbleibt.
Dann gibt es mehrere Moglichkeiten, wie es weitergeht:
1. Die Aufgabe kocht kurz danach hoch und wird unter Druck doch noch nachgearbeitet. Das
ist der harmloseste Fall.
Wer also den Virenscanner zu spat aktualisiert oder einen Security Fix fur seinen Apache
nicht zugig einspielt, wird moglicherweise diese Situation erleben.
2. Unangenehmer wird es, wenn die Aufgabe in Vergessenheit gerat und es erst eine ganzeWeile
spater zu einer Storung kommt. Dann ist die Ursachenbestimmung deutlich aufwendiger und
die Storungsbeseitigung dauert entsprechend langer.
Wer erstmal Routing-Eintrage, den Hostname oder IP-Filterregeln "von Hand\ eingetragen
hat, ohne sie in der Boot-Kon guration nachzutragen, oder noch besser, sie zwar eingetragen,
aber nicht getestet hat, wird bei der Fehlersuche nach einem spateren Reboot seine Freude
haben|es sei denn, es erwischt einen ahnungslosen Kollegen.
3. Wenn nun eine ganze Reihe solcher Altlasten zusammenkommen, verlangert sich nicht nur
die Ursachenbestimmung, sondern es kommt auch noch zu Abhangigkeiten, die erhebliche
Schwierigkeiten bei der Problembehebung verursachen konnen.
Bei einem DoS-Angri auf den zentralen Webserver kann das heien, da man zuerst einmal
einen aktuellen Kernelpatch gegen eine neue DoS-Vulnerability einspielt, ohne da es
Erfolg hat. Der Austausch des Apaches, der noch nicht aktualisiert wurde, weil ein Dutzend
verschiedener Module in genau ausgetuftelter Reihenfolge eincompiliert werden mussen und
2
Benedikt Stockebrand Never Touch a Running System
das beim letzten Mal schon eine Woche muhsames Ausprobieren und Sourcen-Lesen gekostet
hat, bringt auer Zeitverlust auch keine Besserung. Kann ja auch nicht|wenn sich
das Netzwerkkabel mit der abgebrochenen Arretierzunge, das ein Kollege im Patchfeld mit
Klebeband festgemacht hat, gelockert hat.
Wenn das Problem aber doch ein Sicherheitsloch im Uralt-Kernel war, aber der eingesetzte
und hochgradig Compile-getunte Apache mit einem aktuellen Kernel nicht lauft und vielleicht
die Hardware sich mit dem aktuellen Kernel nicht vertragt, fuhrt die Fehlerbehebung im
schlimmsten Fall dazu, da erstmal neue Hardware angescha t werden mu. Bei einem PC
ist das noch unkritisch, bei einem analogen Fall mit einer Sun E3500 aufwarts tun alleine
schon die Lieferfristen weh.
Wirklich kritisch wird die Konstellation, wenn eine unternehmenskritische Server-Application
in einer Uraltversion auf einer SUN Sparc Station 20 unter Solaris 2.5.1 lauft, zu der es nur
Clients unter Windows 95/98 und NT gibt und dann dank einer anderen Anwendung die
Clientrechner zwingend auf Windows 2000 oder .NET umgestellt werden mussen, wofur es
nur eine neue Client-Version gibt, die eine neue Server-Version voraussetzt, die nur unter
Solaris 8 aufwarts lauft.
4. In der nachsten Stufe wird die Aufgabe an allen Fronten einfach umgangen. Das fuhrt nicht
nur zum allseits beliebten "Das haben wir schon immer so gemacht\, sondern macht es
extrem schwierig, das Problem spater endgultig aus der Welt zu scha en.
Ein klassisches Beispiel hier ist die nicht durchgezogene Einfuhrung einer
achendeckenden
DNS-Infrastruktur. Da behelfen sich manche Leute mit scp-verteilten /etc/hosts, die fast
zwangslau g bei diversen Problemen "von Hand optimiert\ werden, was dazu fuhrt, da
z.B. der Loghost fur jeden Server in der /etc/hosts fest per IP-Adresse eingetragen ist|
naturlich immer unter dem Namen loghost. Wenn dann irgendwann die Ausfalle durch
versehentlich doppelt benutzte IP-Adressen uberhand nehmen oder aus anderen Grunden
der Einsatz von DNS unumganglich wird, mu diese Altlast, naturlich unter Zeitdruck,
geradegezogen werden. Ohne dabei die eine oder andere Maschine versehentlich zeitweise
auer Gefecht zu setzen, ist das in einem groeren Umfeld keine "Herausforderung\ mehr,
sondern ein Himmelfahrtskommando.
5. Es gibt noch eine letzte Variante, das Endstadium dieser Entwicklung: Wird ein System
hochstens symptomatisch betreut, entwickelt es durch kurzsichtig und ohne Rucksicht auf
den Gesamtzusammenhang durchgefuhrte Flickschusterei immer mehr Ungereimtheiten, die
es einem neuen Sysadmin unmoglich machen, sich in das System zuverlassig einzuarbeiten.
Wenn die Betreuung des Systems irgendwann immer schneller wechselt, weil niemand sich
mehr damit herumargern will, oder das System auch nur lange genug nicht mehr angefat
wird, ist niemand mehr in der Lage, es zuverlassig zu betreiben geschweige denn wieder in
einen sauberen Zustand zu uberfuhren. Wird ein System im Rahmen eines Projektes unter
Zeitdruck von Externen aufgesetzt, kann es schon rechtzeitig zur Inbetriebnahme diesen
Zustand erreichen.
Ich habe in der Vergangenheit mehrere solche Zombie-Systeme naher kennengelernt (als mir
lieb war), kann aber aus Vertraulichkeitsgrunden keine Beispiele nennen. Nur so viel: Systeme
in diesem Stadium sind nicht mehr zu retten, sie mussen durch einen sauber hochgezogenen
Nachfolger ersetzt werden. Das moglichst problemarme Umschalten auf den Nachfolger
ist eine der letzten groen Herausforderungen der IT-Welt.
In allen angefuhrten Fallen hat ein "Never Touch a Running System\ dazu gefuhrt, da hinausgeschobene
Aufgaben, die sich eben doch nicht von selbst erledigt haben, zu teilweise erheblichem
Mehraufwand und vor allem zu unnotigen Betriebsstorungen gefuhrt haben.
Langfristig fuhrt das dazu, da die Systemadministration immer aufwendiger wird, deshalb
immer mehr Arbeiten liegenbleiben und so ein Teufelskreis entsteht, der dazu fuhren kann, da
eine ganze IT-Umgebung in sich kollabiert.
3
Benedikt Stockebrand Never Touch a Running System
3.2 Kommunikations- und Managementprobleme
Dann gibt es zwei Probleme, die fast ausschlielich in Verbindung mit nicht funktionierender
Kommunikation zwischen Technik und nicht-technischem Management auftreten.
Manager denken "in anderen Dimensionen\ als der durchschnittliche Sysadmin: Zuallererst einmal
verwalten sie Ressourcen wie Geld und Manpower. Diese Ressourcen versuchen sie moglichst
pro tabel einzusetzen; das ist im Kern ihr Job. Deshalb priorisieren sie Aufgaben mit dem Ziel,
mit ihren beschrankten Ressourcen moglichst viel zu erreichen. Um die Prioritaten festzulegen,
mussen sie aber wenigstens im Ansatz verstehen, warum Aufgaben wichtig sind|und das in vielen
Fallen, ohne die technischen Hintergrunde zu verstehen.
Auerdem sind viele Manager einmal mit Hilfe des sogenannten "Eisenhower-Diagramms\ darauf
getrimmt worden, Aufgaben liegenzulassen, die nicht unmittelbar akut sind. Das hilft vielleicht,
um sich in einer akuten Krise auf die unmittelbar uberlebenswichtigen Probleme zu konzentrieren,
aber einen Weg aus dieser Krise heraus zeigen sie nicht auf. Stattdessen fuhren sie zu
einer gewissen Kurzsichtigkeit, die Gerstner [Ger02] im Zusammenhang mit der Vero entlichung
der nachsten Quartalszahlen als Quartalskurzsichtigkeit bezeichnet, und die letztlich immer nur
darauf ausgerichtet ist, akute Probleme kurzfristig unter den Teppich zu kehren.
Im Zusammenhang mit Software-Projekten haben Yourdon [You97] und Roberts und Roberts
[RR00] die Auswirkungen dieses Management-Stils untersucht; ihre Ergebnisse sind auch
fur Sysadmins sehr interessant. DeMarco [DeM93] beschreibt in aller Deutlichkeit, was bewute
Ressourcenverknappung fur Folgen hat.
Fur einen Sysadmin hat diese Denkweise zwei potentielle Auswirkungen:
Dringend notige Neuerungen, die kurzfristig Geld kosten, werden gerne mit der Begrundung
"das ist bisher gelaufen und es ist eure Aufgabe dafur zu sorgen, da das so bleibt\ abgeblockt.
Dabei gibt es zwei Grunde, warum es in der IT keine "endgultigen Losungen\ geben kann: Die
Anforderungen an Systeme nehmen im allgemeinen standig zu und die Technik entwickelt sich
noch immer rasant weiter.
Ahnlich sieht es aus, wenn "proaktive\ Arbeiten nicht genehmigt werden, weil sie zu Ausfallen
fuhren konnten oder eine Downtime zwingend voraussetzen. Diese Variante ist besonders deshalb
so kritisch, weil sie spater oft zu schwerwiegenden Ausfallen fuhrt und in der Folge die Suche nach
einem Schuldigen regelmaig bei den Sysadmins endet.
Es gibt vermutlich Ausnahmefalle, in denen ein Management absichtlich versucht, die eigene
Technik durch so ein Verhalten zu sabotieren|vielleicht, um sich eine Ausrede zu verscha en,
sich des ungeliebten Kindes IT durch Outsourcing zu entledigen. Aber nach meiner Erfahrung
ist in den meisten Fallen einem Management nicht bewut, oder besser gesagt nicht von der
Systemadministration bewut gemacht worden, wie kritisch die Situation tatsachlich ist. Damit
werden andere Probleme auerhalb der Systemadministration hoher priorisiert und langfristig
verkommt die IT-Landschaft.
4 Wie wird
"
Never Touch\ mibraucht?
Es ist schon schlimm genug, da "Never Touch\ inzwischen so oft miverstanden wird. Noch
problematischer ist, da es gelegentlich auch bewut mibraucht wird.
4.1 Historische Fehlentscheidungen
Aus Angst, fur eine tatsachliche oder vermeintliche Fehlentscheidung verantwortlich gemacht zu
werden, kommt es vor, da "suboptimale\ Losungen vehement verteidigt werden.
Vor funf bis zehn Jahren war der Einsatz von NIS+ statt NIS sicherlich in vielen Fallen sinnvoll.
Aber heute ist LDAP+TLS+PAM sinnvoller, insbesondere in heterogenen Umgebungen. Wer
erklart der Geschaftsfuhrung, da der Aufwand, den man mit NIS+ vor einigen Jahren betrieben
hat, inzwischen uberholt ist?
4
Benedikt Stockebrand Never Touch a Running System
4.2 Nach mir die Sint
ut
Insbesondere externe Mitarbeiter, die wissen, da sie die Folgen einer verschleppten Aufgabe
nicht mehr selbst ausbaden mussen, lassen gelegentlich langfristig wichtige Aufgaben liegen. In
vergleichsweise harmlosen Fallen will man nur nicht mit kurzfristig unproduktiven Aktivitaten
au allen. Es soll aber auch vorkommen, da dem Nachfolger Zeitbomben hinterlassen werden mit
dem Ziel, sich in Richtung der Geschaftsfuhrung zu pro lieren, weil "bei mir das alles problemlos
funktioniert hat.\
4.3 Machtpolitik
In eine ahnliche Richtung gehen machtpolitische Grabenkampfe. Die sind mit "technischer\ Logik
nicht zu verstehen, aber trotzdem sehr real:
"Nein, ein Backup Domain Controller unter Linux kommt mir nicht ins Haus, das funktioniert
sowieso nicht. Auerdem mute ich damit ja Macht an die Unix-Fraktion abgeben. Und
uberhaupt, anschlieend wird dann auch noch Exchange entsorgt und am Ende bleibt mir nur
noch die Betreuung von 08/15-Desktop-PCs|oder sollen die etwa auch auf Linux umgestellt werden?\
"PC-Server kommen mir nicht ins Haus, die sind fur den Einsatz in "Mission Critical\-Umgebungen
nicht zu gebrauchen. Auerdem konnte mir dann das Hardware-Budget gekurzt werden,
und wenn das Controlling sich dann noch einmischt, wo Linux/i386 statt Solaris/SPARC (oder
AIX/RS6000 etc.), dann kann ja jeder kommen. . .\
"Bleibt mir weg mit eurem komischen Post x (oder Exim (oder Qmail (oder . . . ))), mein
Sendmail lauft und solange ihr die Finger davon lat, sorge ich schon dafur, da das auch so
bleibt.\
Ich denke, diese Beispiele brauchen keine weitere Erlauterung.
4.4 Erhalt der eigenen Existenzberechtigung
Eine letzte Variante ist, ein System so verkommen zu lassen, da es nur noch von einer einzigen
Person einigermaen betrieben werden kann. Das betri t hauptsachlich externe Mitarbeiter, die
sich unersetzlich machen wollen, mir ist aber mindestens ein Fall bekannt, wo ein interner Mitarbeiter
diese Masche so erfolgreich angewandt hat, da er am Ende gekundigt wurde, nachdem er
wiederholte Au orderungen ignoriert hat, seine Arbeit zu dokumentieren.
5 Was kann ein Sysadmin dagegen tun?
Gibt es Moglichkeiten, sich gegen diese Phanomene zu wehren? Teilweise, wobei viel von der
Unterstutzung von Seiten des Managements abhangt.
5.1 Subversive Eigeninitiative|eine Nichtlosung
Was fur Moglichkeiten gibt es, dringend notige Arbeiten durchzufuhren, wenn das Management
sich auf die Position "Das ist bisher gelaufen und es ist eure Aufgabe, dafur zu sorgen, da das
so bleibt\, oder aquivalent "Es gibt keine Probleme, nur Herausforderungen\ zuruckzieht und
Anderungen am System verbietet?
Wer diese Situation zum ersten Mal erlebt, wird mit hoher Wahrscheinlichkeit versucht sein,
die Arbeiten "auf eigene Verantwortung\ durchzufuhren. Dabei wird er lernen, da er damit das
Verhaltnis zwischen ihm und dem Management nicht gerade fordert. Wenn es Probleme gibt,
wird er dafur zur Rechenschaft gezogen, im schlimmsten Fall bis hin zur fristlosen Kundigung und
moglicherweise straf- und zivilrechtlichen Konsequenzen|der Perl-Guru Randy Schwartz durfte
etwas ahnliches vor einigen Jahren erleben. Selbst wenn es klappt, wird es nachher heien "das
war ein vollig unnotiges Risiko, das ware auch so weitergelaufen\.
5
Benedikt Stockebrand Never Touch a Running System
Wer nun die Anderungen unbemerkt durchfuhrt, wird sich damit erstens unglaubwurdig machen,
weil es ja o ensichtlich auch ohne sie alles lauft, und zweitens das Desaster nur vor sich
herschieben: Wenn dann irgendwann wirklich gar nichts mehr geht, wird man ihm auch noch
Inkompetenz vorwerfen.
Schlielich gibt es die Variante, sich zwar auerhalb der bezahlten Arbeitszeit schlau zu machen,
damit man wenn es soweit ist schnell und kompetent handeln kann, aber nichts an den produktiven
Systemen zu tun. Das kostet viel Zeit und moglicherweise noch mehr Geld fur Bucher, Software,
Hardware und im schlimmsten Fall den Scheidungsanwalt. Wer das versucht, sollte sich deshalb
vorher uberlegen, wie viel Engagement ihm diese Manahme wert ist.
Ich halte diese Form von Eigeninitiative fur bedenklich, denn sie geht ganz auf Kosten der
Sysadmins. Mir ist ein Fall bekannt, wo das Management absichtlich darauf hingesteuert hat,
da ein Sysadmin sich auf eigene Kosten in seiner Freizeit umfangreich weiterbildet, sprich auf
eigene Kosten und im Urlaub zu Fachtagungen fuhr. Das ng ursprunglich als Ausnahmereaktion
an, wurde dann aber sehr schnell als "normale Vorgehensweise\etabliert. Der private abendliche
Besuch eines SAGE@GUUG-Vortrags oder der lokalen Unix/Linux User Group kostet kein nennenswertes
Geld und schon gar keinen Urlaub, aber die Fahrt zur Cebit oder Systems einschlielich
Ubernachtung vor Ort, um sich aktuelle Backup-Losungen anzusehen, oder eine einwochige Schulung
beim Hersteller sprengen jeden privat tragbaren Rahmen.
5.2 Kampfrhetorische Selbstverteidigung
Wenn in einer Diskussion mit "Never Touch a Running System\ rabulisiert wird, kann man manchmal
schon mit einem "Dann mussen wir eben warten, bis es kracht\ oder alternativ auf neudeutsch
mit "An Ounce of Prevention is Worth a Pound of Cure\ ein rudimentares Problembewutsein
scha en.
Wer in einem "hochgradig politisierten Umfeld\ mit solchen Situationen konfrontiert wird,
sollte daruber hinaus einen Blick in entsprechende Literatur werfen; mir personlich hat ein Buch
von Ruede-Wissmann [RW93] insofern geholfen, da ich inzwischen wenigstens im Nachhinein
merke, wenn ich uber den Tisch gezogen worden bin|was nicht heit, da ich gegen einen Konner
auch nur die Spur einer Chance habe.
5.3 Selbstorganisation, Dokumentation und Kommunikation mit dem
Management
Um anstehende Aufgaben sinnvoll zu organisieren, ist ein Problem Ticket System essentiell wichtig.
Ob man dabei eine kommerzielle Losung, eine Zettelwirtschaft mit A5-Zetteln oder ein groes
Whiteboard eingesetzt, ist dabei zweitrangig und stark abhangig von den lokalen Gegebenheiten.
Wichtig ist, da irgendwo die lange liegengebliebenen Aufgaben zu erkennen und wiederzu nden
sind. Ein standig wachsender Stapel von Altlasten wird damit wirkungsvoll dokumentiert, besonders
wenn man bei regelmaigen Meetings mit dem Management damit zeigt, da der Ruckstau
kontinuierlich wachst. Ein Manager, der auerdem auch noch aufgefordert wird, die Aufgaben
zu priorisieren, wird eher akzeptieren, da er selbst etwas gegen die Situation tun mu (wobei
Ausnahmen die Regel bestatigen). Limoncelli und Hogan [LH02] haben einige hilfreiche Tips zu
der Thematik.
Der Umgang mit versteckten Abhangigkeiten ist deutlich problematischer. In manchen Fallen
hilft hier eine Tabellenkalkulation. Alternativ lat sich Software mibrauchen, die GANTT-Charts
erzeugt; es mu nicht unbedingt fur teures Geld MS Project sein, fur diesen speziellen Fall reicht
z.B. moglicherweise auch mrproject oder ahnliches. Das ist allerdings mit mebarem Aufwand
verbunden und dadurch potentiell kontraproduktiv. Auerdem ist es unwahrscheinlich, da diese
Abhangigkeiten sinnvoll verwaltet werden, wenn die Ressourcen fehlen, sie zu bearbeiten. Ich
personlich vertrete eher den Standpunkt, da eine Policy, die versucht, fruhzeitig Upgrades durchzuf
uhren, und mehr Wert auf dauerhafte Losungen als auf Flickschusterei legt, dieser Thematik
6
Benedikt Stockebrand Never Touch a Running System
eher gerecht wird und das Verwalten von Abhangigkeiten hochstens dann hilft, wenn man seinem
Management die Situation klarmachen will.
Um Probleme sauber zu losen, mu aber der erwahnte Teufelskreis durchbrochen werden|wer
in kurzfristigen Problemen versinkt, kann sich keine grundlegenden Gedanken machen kann, wie
man die Situation wieder in geregelte Bahnen lenkt. Ohne Unterstutzung durch das Management
ist das im besten Fall schwierig. Moglicherweise lassen sich kurzfristige Manahmen des Managements
aber ausnutzen, wenn sie zeitweise den notigen Freiraum verscha en, um grundlegende
Aufgaben endlich anzugehen.
5.4 O ene Konfrontation mit dem Management
Bleibt die Frage, wie man mit einem Management umgeht, das uberlebenswichtige Manahmen,
wie zum Beispiel die Anscha ung einer adaquaten Backup-Losung, regelmaig verweigert.
An dieser Stelle bleibt meiner Meinung nach kurzfristig nur die Moglichkeit, auch nach juristischen
Mastaben sauber zu dokumentieren, da man das Management uber die Probleme
und vor allem ihre wirtschaftliche Tragweite informiert und zum Handeln aufgefordert hat. Es
ist an diesem Punkt entscheidend wichtig, da sich die Dokumentation im Zweifelsfall auch vor
Gericht verwenden lat|insbesondere fur freie Mitarbeiter ist das unter Umstanden existenzentscheidend.
Diese Manahme, konsequent durchgefuhrt, ruttelt in vielen Fallen ein Management
wach|spatestens, wenn man nach einer Empfangsbestatigung fur seine Dokumentation fragt.
Wenn auch das tatsachlich nichts hilft, kann man noch versuchen, die Situation weiter zu
eskalieren|was aber im allgemeinen langfristig das Verhaltnis zwischen Sysadmin und Management
sehr belastet. Wenn auch das nichts andert, bleibt nach meinem Verstandnis nur noch der
"geordnete Ruckzug\, die "Suche nach neuen Herausforderungen\ oder, platt gesagt, ein moglichst
schneller Jobwechsel.
Zum Gluck sind derart pathologische Falle selten; spatestens das groe Dotcom-Sterben durfte
hier die Masse solcher Umgebungen ihrem unvermeidlichen Schicksal zugefuhrt haben.
6 Das Selbstverstandnis in Projekten
Weit unspektakularer als die Entscheidungsschlacht mit dem Management, dafur aber um so
weiter verbreitet, sind Probleme, die aus dem Selbstverstandnis von Projekten entstehen, die neue
Systeme in die Welt setzen. Auch wenn das mit der klassischen Systemadministration nichts oder
nur ganz am Rande zu tun hat, sind doch Sysadmins am Ende diejenigen, die in der IT eines
Unternehmens eine gewisse Kontinuitat auch uber einzelne Projekte hinaus bewahren und oft
genug die einzigen sind, die diese Probleme potentiell verhindern konnen.
Es ist meine personliche Meinung, da der weitverbreitete Zyklus Hauruck-Projekt, Stillhalten
bis der Leidensdruck nicht mehr zu ertragen ist und ein neues Hauruck-Projekt, in sich fundamental
kontraproduktiv ist. Aber im Kontext dieses Vortrags haben zwei Phanomene, die sich unmittelbar
aus diesem Projektverstandnis ergeben, besondere Bedeutung fur die Sysadmins, die wahrend des
Projekts und vor allem danach mit dem System involviert sind. Beide sind Folgen der Annahme,
da nach der Inbetriebnahme an dem System keine wesentlichen Anderungen mehr notig sind und
es beliebig lange unverandert weiterlauft.
6.1 Wozu eine Testumgebung?
Wenn nach der Inbetriebnahme keine wesentlichen Anderungen mehr anfallen, wird nach dem
Projekt eine Testumgebung nicht gebraucht. Vor der Inbetriebnahme kann auf der zukunftigen
Produktivumgebung entwickelt, getestet und installiert werden. Also kann man hier viel Geld
sparen.
Erste Folgen dieser Einstellung zeigen sich erst, wenn das Projektteam sich wieder aufgelost
hat, das Einspielen von Betriebssystempatches zum ersten Betriebsausfall gefuhrt oder die neu
7
Benedikt Stockebrand Never Touch a Running System
installierte Austausch- oder Erweiterungsmaschine mangels entsprechender Doku nach mehreren
Wochen immer noch nicht richtig lauft.
Wenn dann irgendwann in ferner, ferner Zukunft, also in zwei bis drei Jahren, einmal die
benutzte Hardware, das Betriebssystem oder die zugrundeliegende Datenbank dank abgelaufenem
Support auf einen neuen Stand gebracht werden mu, steht eine schwierige Entscheidung an:
Lassen wir das System so, wie es ist, und verzichten auf Herstellersupport oder riskieren wir einen
existenzgefahrdenden Betriebsausfall, wenn wir ohne vorhergehende Tests ein Upgrade versuchen?
Ich behaupte nicht, da in allen Fallen eine Testumgebung in voller Groe standig bereitgehalten
werden mu. Aber ohne den Zugri auf eine Testumgebung kann ein zuverlassiger Betrieb
langfristig nicht sichergestellt werden.
6.2 Die Lebenserwartung eines Systems
Wer schon einmal einer Geschaftsfuhrung gesagt hat, da ein funf Jahre altes System reif fur den
Gnadenstrom ist, kennt vielleicht das entsetzte "aber das ist doch erst funf Jahre alt, wir sind
davon ausgegangen, da das mindestens zehn Jahre lauft!\
Unabhangig von der Ursache fur diese gangige Fehleinschatzung sind die Auswirkungen doch
fatal. Deshalb sollte man schon wahrend des Projekts die Lebenserwartung der benutzen Komponenten
dokumentieren: Wie lange wird fur die Hardware noch die Ersatzteilversorgung sichergestellt
sein? Was ist mit Security Patches fur das Betriebssystem und andere sicherheitskritische
Komponenten? Was ist mit dem immer wieder gerne diskutierten Herstellersupport?
Eine solche Aufstellung ist auch fur das Management sehr wichtig: Erstens kann es sich damit
uberlegen, wann welche Investitionen in der Zukunft notig werden. Zweitens ist ein RoI1 von funf
Jahren bei einer Lebenserwartung des Gesamtsystems von drei bis vier Jahren ein Signal, das so
ziemlich jeder Manager versteht.
7 Fazit
Im Verlauf dieses Vortrags ist ho entlich deutlich geworden, da "Never Touch a Running System\
keine Universalweisheit der Systemadministration ist, sondern in vielen wichtigen Fallen
hochgradig kontraproduktiv ist.
Weiter sollte der Vortrag einige Hinweise gegeben haben, warum die Kommunikation zwischen
Technik und Management manchmal so schwierig ist und wie man als Techniker dazu beitragen
kann, sie zu verbessern.
Schlielich sind in heute typischen IT-Landschaften Sysadmins die einzigen, die in der Technik
eine langfristige Kontinuitat bewahren konnen. Auch wenn das normalerweise nicht explizit als
Aufgabe in einer Stellenbeschreibung genannt wird, ist diese Funktion existentiell wichtig.
Literatur
[DeM93] Tom DeMarco. Lean and mean. In [DeM95], chapter 1. Dorset House, 1993.
[DeM95] Tom DeMarco. Why Does Software Cost So Much? Dorset House, 1995.
[Ger02] Louis V. Gerstner. Who Says Elephants Can't Dance? Harper Collins, 2002.
[LH02] Thomas A. Limoncelli and Christine Hogan. The Practice of System and Network
Administration. Addison-Wesley, 2002.
[RR00] Sharon Marsh Roberts and Ken Roberts. Do I want to take this crunch project? In
[WBK00], pages 25{42. Dorset House, 2000.
1Return of Investment, sprich der Zeitpunkt, bis zu dem man die Investitionen wieder hereingeholt hat.
8
Benedikt Stockebrand Never Touch a Running System
[RW93] Wolf Ruede-Wissmann. Satanische Verhandlungskunst|und wie man sich dagegen
wehrt. Wilhelm Heyne Verlag, 1993.
[WBK00] Gerald M. Weinberg, James Bach, and Naomi Karten, editors. Amplifying Your E ectiveness.
Dorset House, 2000.
[You97] Edward Yourdon. Death March|The Complete Software Developer's Guide to Surviving
\Mission Impossible" Projects. Prentice Hall, 1997.
Uber dieses Manuskript
Dies ist das Manuskript eines Vortrags, den ich am 03. Juni 2003 vor der Karlsruher Ortsgruppe
der SAGE@GUUG gehalten habe. Es greift einige Fragen auf, die im Anschlu an meinen Vortrag
"Nach dem Boom: Ein Gesundheitscheck fur IT-Systeme\ beim GUUG-Fruhjahrsfachgesprach
2003 aufgekommen sind.
Uber den Autor
Der Autor ist Dipl.-Inform. und freischa ender Systemarchitekt im Unix- und
TCP/IP-Umfeld.
Er unterstutzt IT-Projekte dabei, Software auf real existierender Hardware
in real existierenden Rechenzentren in einen ezienten und zuverlassigen Betrieb
zu nehmen, bringt die Infrastruktur von Rechenzentren auf den Stand
der Technik und fuhrt vor allem die IT-Bausunden der New Economy in die
betriebwirtschaftliche Realitat.
Wenn er nicht gerade tauchen geht oder mit dem Fahrrad Kontinente sammelt,
ist er unter stockebrand@guug.de, me@benedikt-stockebrand.de und
http://www.benedikt-stockebrand.de/ zu erreichen.
9
Never Touch a Running System
(Wir warten erst, bis nichts mehr geht)
Benedikt Stockebrand
03. Juni 2003
Zusammenfassung
Kaum eine Bauern- oder besser gesagt Sysadmin-Regel wird so oft und so fatal miverstanden
wie
"
Never Touch a Running System\. Der Vortrag untersucht die Herkunft und ursprungliche
Bedeutung der Regel, ihre Anwendbarkeit auf heutige IT-Umgebungen, gangige Fehlinterpretationen,
ihren bewuten Mibrauch und wie ein Systemadministrator mit diesem Phanomen
umgehen kann.
Benedikt Stockebrand Never Touch a Running System
1 Woher kommt die Regel
"
Never Touch a Running System\?
Auf der Suche nach der Herkunft der Regel gab nur Fehlschlage: Das Jargon File brachte nichts
zutage, meine alteste Fachliteratur war genauso wenig hilfreich und auch wenn Google die ublichen
"ungefahr 1660\ Hits fand, war doch nichts relevantes|auer der Vortragsankundigung|dabei.
Personlich war ich davon etwas uberrascht.
2 Was war ursprunglich ihre Intention?
Auch die nachste Frage, was die ursprungliche Aussage der Regel war, bringt eine Uberraschung
mit sich: Es gibt eine Reihe unterschiedliche Zusammenhange, in denen die Regel jedesmal eine
andere Bedeutung hat:
Warte bis nach Betriebsschlu. Wer schon einmal mit "klassischen\ Produktivsystemen zu
tun hatte, die nur zu "Geschaftszeiten\ laufen mussen, wird sofort an diese Interpretation
denken. Generell gilt, da man Arbeiten an einem Produktivsystem in moglichst unkritische
Zeitfenster legen sollte|so es denn noch solche Zeitfenster gibt.
Wer zum Beispiel die Server der Finanzbuchhaltung unmittelbar vor dem Zahltag stillegt,
wird sich bei seinen Kollegen nicht beliebt machen.
Das ist nach meinem Wissen die ursprungliche Aussage der Regel.
Erst denken, dann handeln. So ziemlich jeder, der schon einmal fur die Administration von
betriebsrelevanten Systemen verantwortlich war, kennt das Phanomen: Irgend etwas geht
immer schief und wenn wichtige Services betro en sind, geht alles durcheinander und vor
allem der Adrenalinspiegel in ungeahnte Hohe. In dieser Situation ist es entscheidend, mit
sauberen Fehlerbehebungsmethoden das Problem unter Kontrolle zu bringen und sich nicht
zu blindem Aktionismus verleiten zu lassen; sonst wird der Schaden nur noch groer.
Ein Beispiel, das ich von einem Kollegen gehort habe, betraf ein RAID5-Plattensystem. Eine
Platte war ausgefallen, das Array machte sich durch eine eingebaute Hupe lautstark bemerkbar.
Der Servicetechniker, der die defekte Platte austauschen sollte, zog wahrend der Kunde
sich noch uber besagte Hupe beschwerte versehentlich die falsche Platte aus dem laufenden
Array (und besagter Kollege durfte anschlieend ein Desaster Recovery durchfuhren). . .
Auch wenn dieser Punkt o ensichtlich wichtig ist, bleibt er doch eher ein Thema, das unter
dem Stichwort "handhabbare Systeme\ in der Systemarchitektur und im Prozessmanagement
eine zentrale Rolle einnehmen sollte. Deshalb betrachten wir ihn im Rahmen dieses Vortrags
nicht weiter.
Tanz immer nur auf einer Hochzeit. Im Umgang mit Produktivsystemen ist es wichtig, sich
immer auf ein einzelnes Problem zu konzentrieren und nicht unnotig an mehreren Fronten
gleichzeitig zu arbeiten.
Vor langerer Zeit hatte ich einmal das Vergnugen, ein angeblich gehacktes System untersuchen
zu durfen. Ergebnis: Die externen "Application Admins\, die auf dem System dummerweise
Root-Rechte hatten, hatten nicht nur an ihrer Anwendung herumgeschraubt, sondern
nebenher fur Root eine "richtige\ Shell eingerichtet: /bin/bash. Das System war aber kein
Linux, sondern ein Solaris, so da man sich anschlieend als Root mangels existierender Shell
nicht mehr einloggen konnte.
Neben der personlichen Arbeitsweise betri t dieses Problem auch die Betriebsorganisation:
Nur wer Aufgaben der Reihe nach abarbeiten kann, statt im Interrupt-Betrieb seine Zeit zu
verlieren, wird auch Qualitat liefern.
1
Benedikt Stockebrand Never Touch a Running System
Unnotige Risiken sind genau das: Unnotig. Es kommt gelegentlich vor, da an einem laufenden
System Arbeiten durchgefuhrt werden, die keinerlei Nutzen bringen, aber moglicherweise
zu erheblichen Problemen fuhren konnen.
Auch wenn die meisten Sysadmins das klassische Beispiel in dieser Kategorie, das Flashen von
PC-BIOSsen, verstanden haben, gibt es genug Stellen, wo dieses Verhalten auer Kontrolle
gerat: Unter Linuxern ist es oft der neueste Kernel, der unbedingt installiert werden mu, ein
namhafter Unix- und Hardware-Hersteller erwartet von Kunden mit Problemen regelmaig
zuerst die Installation der aktuellen "Recommended Patches\(obwohl sie keine "Required
Patches\ sind), bevor er uberhaupt vertragsgema anfangt, Probleme zu suchen und eventuell
zu beheben und eine andere groe Software rma uberredet ihre Kunden regelmaig im
Abstand von zwei bis drei Jahren, neue, teilkompatible Versionen ihrer "Betriebssysteme\
und "Buroanwendungsprogramme\ zu kaufen und zu installieren.
Die letzten beiden Beispiele zeigen, da das Problem nicht allein in der Systemadministration,
sondern nur zusammen mit dem ubergeordneten Management losbar sein kann.
3 Warum ist sie heute so gefahrlich?
Wo sind nun die Probleme mit diesen Interpretationen der Regel? Soweit sind sie doch eigentlich
sehr schlussig. Der Untertitel des Vortrags verrat das Problem: "Never Touch\ fuhrt allzu oft
dazu, da potentiell kritische Probleme erst behoben werden, nachdem sie zu einem Schaden
gefuhrt haben.
3.1 Verschleppte Aufgaben
Die wenigsten Sysadmins haben heute so viel Langeweile, da sie in blinden Aktionismus verfallen.
Weit verbreitet ist aber das Problem, da aus Zeitnot wichtige aber nicht unbedingt eilige Arbeiten
immer wieder hinausgeschoben werden, bis sie dann nicht nur wichtig sind, sondern auch eilig
werden|weil eben "nichts mehr geht\. An dieser Stelle verkommt die Regel zu einer Ausrede|es
lauft, also kann ich die Aufgabe, das ich ja durchaus sehe, erstmal liegenlassen.
Mit der ublichen Arbeitsuberlastung fuhrt das aber dazu, da die Aufgabe dauerhaft liegenbleibt.
Dann gibt es mehrere Moglichkeiten, wie es weitergeht:
1. Die Aufgabe kocht kurz danach hoch und wird unter Druck doch noch nachgearbeitet. Das
ist der harmloseste Fall.
Wer also den Virenscanner zu spat aktualisiert oder einen Security Fix fur seinen Apache
nicht zugig einspielt, wird moglicherweise diese Situation erleben.
2. Unangenehmer wird es, wenn die Aufgabe in Vergessenheit gerat und es erst eine ganzeWeile
spater zu einer Storung kommt. Dann ist die Ursachenbestimmung deutlich aufwendiger und
die Storungsbeseitigung dauert entsprechend langer.
Wer erstmal Routing-Eintrage, den Hostname oder IP-Filterregeln "von Hand\ eingetragen
hat, ohne sie in der Boot-Kon guration nachzutragen, oder noch besser, sie zwar eingetragen,
aber nicht getestet hat, wird bei der Fehlersuche nach einem spateren Reboot seine Freude
haben|es sei denn, es erwischt einen ahnungslosen Kollegen.
3. Wenn nun eine ganze Reihe solcher Altlasten zusammenkommen, verlangert sich nicht nur
die Ursachenbestimmung, sondern es kommt auch noch zu Abhangigkeiten, die erhebliche
Schwierigkeiten bei der Problembehebung verursachen konnen.
Bei einem DoS-Angri auf den zentralen Webserver kann das heien, da man zuerst einmal
einen aktuellen Kernelpatch gegen eine neue DoS-Vulnerability einspielt, ohne da es
Erfolg hat. Der Austausch des Apaches, der noch nicht aktualisiert wurde, weil ein Dutzend
verschiedener Module in genau ausgetuftelter Reihenfolge eincompiliert werden mussen und
2
Benedikt Stockebrand Never Touch a Running System
das beim letzten Mal schon eine Woche muhsames Ausprobieren und Sourcen-Lesen gekostet
hat, bringt auer Zeitverlust auch keine Besserung. Kann ja auch nicht|wenn sich
das Netzwerkkabel mit der abgebrochenen Arretierzunge, das ein Kollege im Patchfeld mit
Klebeband festgemacht hat, gelockert hat.
Wenn das Problem aber doch ein Sicherheitsloch im Uralt-Kernel war, aber der eingesetzte
und hochgradig Compile-getunte Apache mit einem aktuellen Kernel nicht lauft und vielleicht
die Hardware sich mit dem aktuellen Kernel nicht vertragt, fuhrt die Fehlerbehebung im
schlimmsten Fall dazu, da erstmal neue Hardware angescha t werden mu. Bei einem PC
ist das noch unkritisch, bei einem analogen Fall mit einer Sun E3500 aufwarts tun alleine
schon die Lieferfristen weh.
Wirklich kritisch wird die Konstellation, wenn eine unternehmenskritische Server-Application
in einer Uraltversion auf einer SUN Sparc Station 20 unter Solaris 2.5.1 lauft, zu der es nur
Clients unter Windows 95/98 und NT gibt und dann dank einer anderen Anwendung die
Clientrechner zwingend auf Windows 2000 oder .NET umgestellt werden mussen, wofur es
nur eine neue Client-Version gibt, die eine neue Server-Version voraussetzt, die nur unter
Solaris 8 aufwarts lauft.
4. In der nachsten Stufe wird die Aufgabe an allen Fronten einfach umgangen. Das fuhrt nicht
nur zum allseits beliebten "Das haben wir schon immer so gemacht\, sondern macht es
extrem schwierig, das Problem spater endgultig aus der Welt zu scha en.
Ein klassisches Beispiel hier ist die nicht durchgezogene Einfuhrung einer
achendeckenden
DNS-Infrastruktur. Da behelfen sich manche Leute mit scp-verteilten /etc/hosts, die fast
zwangslau g bei diversen Problemen "von Hand optimiert\ werden, was dazu fuhrt, da
z.B. der Loghost fur jeden Server in der /etc/hosts fest per IP-Adresse eingetragen ist|
naturlich immer unter dem Namen loghost. Wenn dann irgendwann die Ausfalle durch
versehentlich doppelt benutzte IP-Adressen uberhand nehmen oder aus anderen Grunden
der Einsatz von DNS unumganglich wird, mu diese Altlast, naturlich unter Zeitdruck,
geradegezogen werden. Ohne dabei die eine oder andere Maschine versehentlich zeitweise
auer Gefecht zu setzen, ist das in einem groeren Umfeld keine "Herausforderung\ mehr,
sondern ein Himmelfahrtskommando.
5. Es gibt noch eine letzte Variante, das Endstadium dieser Entwicklung: Wird ein System
hochstens symptomatisch betreut, entwickelt es durch kurzsichtig und ohne Rucksicht auf
den Gesamtzusammenhang durchgefuhrte Flickschusterei immer mehr Ungereimtheiten, die
es einem neuen Sysadmin unmoglich machen, sich in das System zuverlassig einzuarbeiten.
Wenn die Betreuung des Systems irgendwann immer schneller wechselt, weil niemand sich
mehr damit herumargern will, oder das System auch nur lange genug nicht mehr angefat
wird, ist niemand mehr in der Lage, es zuverlassig zu betreiben geschweige denn wieder in
einen sauberen Zustand zu uberfuhren. Wird ein System im Rahmen eines Projektes unter
Zeitdruck von Externen aufgesetzt, kann es schon rechtzeitig zur Inbetriebnahme diesen
Zustand erreichen.
Ich habe in der Vergangenheit mehrere solche Zombie-Systeme naher kennengelernt (als mir
lieb war), kann aber aus Vertraulichkeitsgrunden keine Beispiele nennen. Nur so viel: Systeme
in diesem Stadium sind nicht mehr zu retten, sie mussen durch einen sauber hochgezogenen
Nachfolger ersetzt werden. Das moglichst problemarme Umschalten auf den Nachfolger
ist eine der letzten groen Herausforderungen der IT-Welt.
In allen angefuhrten Fallen hat ein "Never Touch a Running System\ dazu gefuhrt, da hinausgeschobene
Aufgaben, die sich eben doch nicht von selbst erledigt haben, zu teilweise erheblichem
Mehraufwand und vor allem zu unnotigen Betriebsstorungen gefuhrt haben.
Langfristig fuhrt das dazu, da die Systemadministration immer aufwendiger wird, deshalb
immer mehr Arbeiten liegenbleiben und so ein Teufelskreis entsteht, der dazu fuhren kann, da
eine ganze IT-Umgebung in sich kollabiert.
3
Benedikt Stockebrand Never Touch a Running System
3.2 Kommunikations- und Managementprobleme
Dann gibt es zwei Probleme, die fast ausschlielich in Verbindung mit nicht funktionierender
Kommunikation zwischen Technik und nicht-technischem Management auftreten.
Manager denken "in anderen Dimensionen\ als der durchschnittliche Sysadmin: Zuallererst einmal
verwalten sie Ressourcen wie Geld und Manpower. Diese Ressourcen versuchen sie moglichst
pro tabel einzusetzen; das ist im Kern ihr Job. Deshalb priorisieren sie Aufgaben mit dem Ziel,
mit ihren beschrankten Ressourcen moglichst viel zu erreichen. Um die Prioritaten festzulegen,
mussen sie aber wenigstens im Ansatz verstehen, warum Aufgaben wichtig sind|und das in vielen
Fallen, ohne die technischen Hintergrunde zu verstehen.
Auerdem sind viele Manager einmal mit Hilfe des sogenannten "Eisenhower-Diagramms\ darauf
getrimmt worden, Aufgaben liegenzulassen, die nicht unmittelbar akut sind. Das hilft vielleicht,
um sich in einer akuten Krise auf die unmittelbar uberlebenswichtigen Probleme zu konzentrieren,
aber einen Weg aus dieser Krise heraus zeigen sie nicht auf. Stattdessen fuhren sie zu
einer gewissen Kurzsichtigkeit, die Gerstner [Ger02] im Zusammenhang mit der Vero entlichung
der nachsten Quartalszahlen als Quartalskurzsichtigkeit bezeichnet, und die letztlich immer nur
darauf ausgerichtet ist, akute Probleme kurzfristig unter den Teppich zu kehren.
Im Zusammenhang mit Software-Projekten haben Yourdon [You97] und Roberts und Roberts
[RR00] die Auswirkungen dieses Management-Stils untersucht; ihre Ergebnisse sind auch
fur Sysadmins sehr interessant. DeMarco [DeM93] beschreibt in aller Deutlichkeit, was bewute
Ressourcenverknappung fur Folgen hat.
Fur einen Sysadmin hat diese Denkweise zwei potentielle Auswirkungen:
Dringend notige Neuerungen, die kurzfristig Geld kosten, werden gerne mit der Begrundung
"das ist bisher gelaufen und es ist eure Aufgabe dafur zu sorgen, da das so bleibt\ abgeblockt.
Dabei gibt es zwei Grunde, warum es in der IT keine "endgultigen Losungen\ geben kann: Die
Anforderungen an Systeme nehmen im allgemeinen standig zu und die Technik entwickelt sich
noch immer rasant weiter.
Ahnlich sieht es aus, wenn "proaktive\ Arbeiten nicht genehmigt werden, weil sie zu Ausfallen
fuhren konnten oder eine Downtime zwingend voraussetzen. Diese Variante ist besonders deshalb
so kritisch, weil sie spater oft zu schwerwiegenden Ausfallen fuhrt und in der Folge die Suche nach
einem Schuldigen regelmaig bei den Sysadmins endet.
Es gibt vermutlich Ausnahmefalle, in denen ein Management absichtlich versucht, die eigene
Technik durch so ein Verhalten zu sabotieren|vielleicht, um sich eine Ausrede zu verscha en,
sich des ungeliebten Kindes IT durch Outsourcing zu entledigen. Aber nach meiner Erfahrung
ist in den meisten Fallen einem Management nicht bewut, oder besser gesagt nicht von der
Systemadministration bewut gemacht worden, wie kritisch die Situation tatsachlich ist. Damit
werden andere Probleme auerhalb der Systemadministration hoher priorisiert und langfristig
verkommt die IT-Landschaft.
4 Wie wird
"
Never Touch\ mibraucht?
Es ist schon schlimm genug, da "Never Touch\ inzwischen so oft miverstanden wird. Noch
problematischer ist, da es gelegentlich auch bewut mibraucht wird.
4.1 Historische Fehlentscheidungen
Aus Angst, fur eine tatsachliche oder vermeintliche Fehlentscheidung verantwortlich gemacht zu
werden, kommt es vor, da "suboptimale\ Losungen vehement verteidigt werden.
Vor funf bis zehn Jahren war der Einsatz von NIS+ statt NIS sicherlich in vielen Fallen sinnvoll.
Aber heute ist LDAP+TLS+PAM sinnvoller, insbesondere in heterogenen Umgebungen. Wer
erklart der Geschaftsfuhrung, da der Aufwand, den man mit NIS+ vor einigen Jahren betrieben
hat, inzwischen uberholt ist?
4
Benedikt Stockebrand Never Touch a Running System
4.2 Nach mir die Sint
ut
Insbesondere externe Mitarbeiter, die wissen, da sie die Folgen einer verschleppten Aufgabe
nicht mehr selbst ausbaden mussen, lassen gelegentlich langfristig wichtige Aufgaben liegen. In
vergleichsweise harmlosen Fallen will man nur nicht mit kurzfristig unproduktiven Aktivitaten
au allen. Es soll aber auch vorkommen, da dem Nachfolger Zeitbomben hinterlassen werden mit
dem Ziel, sich in Richtung der Geschaftsfuhrung zu pro lieren, weil "bei mir das alles problemlos
funktioniert hat.\
4.3 Machtpolitik
In eine ahnliche Richtung gehen machtpolitische Grabenkampfe. Die sind mit "technischer\ Logik
nicht zu verstehen, aber trotzdem sehr real:
"Nein, ein Backup Domain Controller unter Linux kommt mir nicht ins Haus, das funktioniert
sowieso nicht. Auerdem mute ich damit ja Macht an die Unix-Fraktion abgeben. Und
uberhaupt, anschlieend wird dann auch noch Exchange entsorgt und am Ende bleibt mir nur
noch die Betreuung von 08/15-Desktop-PCs|oder sollen die etwa auch auf Linux umgestellt werden?\
"PC-Server kommen mir nicht ins Haus, die sind fur den Einsatz in "Mission Critical\-Umgebungen
nicht zu gebrauchen. Auerdem konnte mir dann das Hardware-Budget gekurzt werden,
und wenn das Controlling sich dann noch einmischt, wo Linux/i386 statt Solaris/SPARC (oder
AIX/RS6000 etc.), dann kann ja jeder kommen. . .\
"Bleibt mir weg mit eurem komischen Post x (oder Exim (oder Qmail (oder . . . ))), mein
Sendmail lauft und solange ihr die Finger davon lat, sorge ich schon dafur, da das auch so
bleibt.\
Ich denke, diese Beispiele brauchen keine weitere Erlauterung.
4.4 Erhalt der eigenen Existenzberechtigung
Eine letzte Variante ist, ein System so verkommen zu lassen, da es nur noch von einer einzigen
Person einigermaen betrieben werden kann. Das betri t hauptsachlich externe Mitarbeiter, die
sich unersetzlich machen wollen, mir ist aber mindestens ein Fall bekannt, wo ein interner Mitarbeiter
diese Masche so erfolgreich angewandt hat, da er am Ende gekundigt wurde, nachdem er
wiederholte Au orderungen ignoriert hat, seine Arbeit zu dokumentieren.
5 Was kann ein Sysadmin dagegen tun?
Gibt es Moglichkeiten, sich gegen diese Phanomene zu wehren? Teilweise, wobei viel von der
Unterstutzung von Seiten des Managements abhangt.
5.1 Subversive Eigeninitiative|eine Nichtlosung
Was fur Moglichkeiten gibt es, dringend notige Arbeiten durchzufuhren, wenn das Management
sich auf die Position "Das ist bisher gelaufen und es ist eure Aufgabe, dafur zu sorgen, da das
so bleibt\, oder aquivalent "Es gibt keine Probleme, nur Herausforderungen\ zuruckzieht und
Anderungen am System verbietet?
Wer diese Situation zum ersten Mal erlebt, wird mit hoher Wahrscheinlichkeit versucht sein,
die Arbeiten "auf eigene Verantwortung\ durchzufuhren. Dabei wird er lernen, da er damit das
Verhaltnis zwischen ihm und dem Management nicht gerade fordert. Wenn es Probleme gibt,
wird er dafur zur Rechenschaft gezogen, im schlimmsten Fall bis hin zur fristlosen Kundigung und
moglicherweise straf- und zivilrechtlichen Konsequenzen|der Perl-Guru Randy Schwartz durfte
etwas ahnliches vor einigen Jahren erleben. Selbst wenn es klappt, wird es nachher heien "das
war ein vollig unnotiges Risiko, das ware auch so weitergelaufen\.
5
Benedikt Stockebrand Never Touch a Running System
Wer nun die Anderungen unbemerkt durchfuhrt, wird sich damit erstens unglaubwurdig machen,
weil es ja o ensichtlich auch ohne sie alles lauft, und zweitens das Desaster nur vor sich
herschieben: Wenn dann irgendwann wirklich gar nichts mehr geht, wird man ihm auch noch
Inkompetenz vorwerfen.
Schlielich gibt es die Variante, sich zwar auerhalb der bezahlten Arbeitszeit schlau zu machen,
damit man wenn es soweit ist schnell und kompetent handeln kann, aber nichts an den produktiven
Systemen zu tun. Das kostet viel Zeit und moglicherweise noch mehr Geld fur Bucher, Software,
Hardware und im schlimmsten Fall den Scheidungsanwalt. Wer das versucht, sollte sich deshalb
vorher uberlegen, wie viel Engagement ihm diese Manahme wert ist.
Ich halte diese Form von Eigeninitiative fur bedenklich, denn sie geht ganz auf Kosten der
Sysadmins. Mir ist ein Fall bekannt, wo das Management absichtlich darauf hingesteuert hat,
da ein Sysadmin sich auf eigene Kosten in seiner Freizeit umfangreich weiterbildet, sprich auf
eigene Kosten und im Urlaub zu Fachtagungen fuhr. Das ng ursprunglich als Ausnahmereaktion
an, wurde dann aber sehr schnell als "normale Vorgehensweise\etabliert. Der private abendliche
Besuch eines SAGE@GUUG-Vortrags oder der lokalen Unix/Linux User Group kostet kein nennenswertes
Geld und schon gar keinen Urlaub, aber die Fahrt zur Cebit oder Systems einschlielich
Ubernachtung vor Ort, um sich aktuelle Backup-Losungen anzusehen, oder eine einwochige Schulung
beim Hersteller sprengen jeden privat tragbaren Rahmen.
5.2 Kampfrhetorische Selbstverteidigung
Wenn in einer Diskussion mit "Never Touch a Running System\ rabulisiert wird, kann man manchmal
schon mit einem "Dann mussen wir eben warten, bis es kracht\ oder alternativ auf neudeutsch
mit "An Ounce of Prevention is Worth a Pound of Cure\ ein rudimentares Problembewutsein
scha en.
Wer in einem "hochgradig politisierten Umfeld\ mit solchen Situationen konfrontiert wird,
sollte daruber hinaus einen Blick in entsprechende Literatur werfen; mir personlich hat ein Buch
von Ruede-Wissmann [RW93] insofern geholfen, da ich inzwischen wenigstens im Nachhinein
merke, wenn ich uber den Tisch gezogen worden bin|was nicht heit, da ich gegen einen Konner
auch nur die Spur einer Chance habe.
5.3 Selbstorganisation, Dokumentation und Kommunikation mit dem
Management
Um anstehende Aufgaben sinnvoll zu organisieren, ist ein Problem Ticket System essentiell wichtig.
Ob man dabei eine kommerzielle Losung, eine Zettelwirtschaft mit A5-Zetteln oder ein groes
Whiteboard eingesetzt, ist dabei zweitrangig und stark abhangig von den lokalen Gegebenheiten.
Wichtig ist, da irgendwo die lange liegengebliebenen Aufgaben zu erkennen und wiederzu nden
sind. Ein standig wachsender Stapel von Altlasten wird damit wirkungsvoll dokumentiert, besonders
wenn man bei regelmaigen Meetings mit dem Management damit zeigt, da der Ruckstau
kontinuierlich wachst. Ein Manager, der auerdem auch noch aufgefordert wird, die Aufgaben
zu priorisieren, wird eher akzeptieren, da er selbst etwas gegen die Situation tun mu (wobei
Ausnahmen die Regel bestatigen). Limoncelli und Hogan [LH02] haben einige hilfreiche Tips zu
der Thematik.
Der Umgang mit versteckten Abhangigkeiten ist deutlich problematischer. In manchen Fallen
hilft hier eine Tabellenkalkulation. Alternativ lat sich Software mibrauchen, die GANTT-Charts
erzeugt; es mu nicht unbedingt fur teures Geld MS Project sein, fur diesen speziellen Fall reicht
z.B. moglicherweise auch mrproject oder ahnliches. Das ist allerdings mit mebarem Aufwand
verbunden und dadurch potentiell kontraproduktiv. Auerdem ist es unwahrscheinlich, da diese
Abhangigkeiten sinnvoll verwaltet werden, wenn die Ressourcen fehlen, sie zu bearbeiten. Ich
personlich vertrete eher den Standpunkt, da eine Policy, die versucht, fruhzeitig Upgrades durchzuf
uhren, und mehr Wert auf dauerhafte Losungen als auf Flickschusterei legt, dieser Thematik
6
Benedikt Stockebrand Never Touch a Running System
eher gerecht wird und das Verwalten von Abhangigkeiten hochstens dann hilft, wenn man seinem
Management die Situation klarmachen will.
Um Probleme sauber zu losen, mu aber der erwahnte Teufelskreis durchbrochen werden|wer
in kurzfristigen Problemen versinkt, kann sich keine grundlegenden Gedanken machen kann, wie
man die Situation wieder in geregelte Bahnen lenkt. Ohne Unterstutzung durch das Management
ist das im besten Fall schwierig. Moglicherweise lassen sich kurzfristige Manahmen des Managements
aber ausnutzen, wenn sie zeitweise den notigen Freiraum verscha en, um grundlegende
Aufgaben endlich anzugehen.
5.4 O ene Konfrontation mit dem Management
Bleibt die Frage, wie man mit einem Management umgeht, das uberlebenswichtige Manahmen,
wie zum Beispiel die Anscha ung einer adaquaten Backup-Losung, regelmaig verweigert.
An dieser Stelle bleibt meiner Meinung nach kurzfristig nur die Moglichkeit, auch nach juristischen
Mastaben sauber zu dokumentieren, da man das Management uber die Probleme
und vor allem ihre wirtschaftliche Tragweite informiert und zum Handeln aufgefordert hat. Es
ist an diesem Punkt entscheidend wichtig, da sich die Dokumentation im Zweifelsfall auch vor
Gericht verwenden lat|insbesondere fur freie Mitarbeiter ist das unter Umstanden existenzentscheidend.
Diese Manahme, konsequent durchgefuhrt, ruttelt in vielen Fallen ein Management
wach|spatestens, wenn man nach einer Empfangsbestatigung fur seine Dokumentation fragt.
Wenn auch das tatsachlich nichts hilft, kann man noch versuchen, die Situation weiter zu
eskalieren|was aber im allgemeinen langfristig das Verhaltnis zwischen Sysadmin und Management
sehr belastet. Wenn auch das nichts andert, bleibt nach meinem Verstandnis nur noch der
"geordnete Ruckzug\, die "Suche nach neuen Herausforderungen\ oder, platt gesagt, ein moglichst
schneller Jobwechsel.
Zum Gluck sind derart pathologische Falle selten; spatestens das groe Dotcom-Sterben durfte
hier die Masse solcher Umgebungen ihrem unvermeidlichen Schicksal zugefuhrt haben.
6 Das Selbstverstandnis in Projekten
Weit unspektakularer als die Entscheidungsschlacht mit dem Management, dafur aber um so
weiter verbreitet, sind Probleme, die aus dem Selbstverstandnis von Projekten entstehen, die neue
Systeme in die Welt setzen. Auch wenn das mit der klassischen Systemadministration nichts oder
nur ganz am Rande zu tun hat, sind doch Sysadmins am Ende diejenigen, die in der IT eines
Unternehmens eine gewisse Kontinuitat auch uber einzelne Projekte hinaus bewahren und oft
genug die einzigen sind, die diese Probleme potentiell verhindern konnen.
Es ist meine personliche Meinung, da der weitverbreitete Zyklus Hauruck-Projekt, Stillhalten
bis der Leidensdruck nicht mehr zu ertragen ist und ein neues Hauruck-Projekt, in sich fundamental
kontraproduktiv ist. Aber im Kontext dieses Vortrags haben zwei Phanomene, die sich unmittelbar
aus diesem Projektverstandnis ergeben, besondere Bedeutung fur die Sysadmins, die wahrend des
Projekts und vor allem danach mit dem System involviert sind. Beide sind Folgen der Annahme,
da nach der Inbetriebnahme an dem System keine wesentlichen Anderungen mehr notig sind und
es beliebig lange unverandert weiterlauft.
6.1 Wozu eine Testumgebung?
Wenn nach der Inbetriebnahme keine wesentlichen Anderungen mehr anfallen, wird nach dem
Projekt eine Testumgebung nicht gebraucht. Vor der Inbetriebnahme kann auf der zukunftigen
Produktivumgebung entwickelt, getestet und installiert werden. Also kann man hier viel Geld
sparen.
Erste Folgen dieser Einstellung zeigen sich erst, wenn das Projektteam sich wieder aufgelost
hat, das Einspielen von Betriebssystempatches zum ersten Betriebsausfall gefuhrt oder die neu
7
Benedikt Stockebrand Never Touch a Running System
installierte Austausch- oder Erweiterungsmaschine mangels entsprechender Doku nach mehreren
Wochen immer noch nicht richtig lauft.
Wenn dann irgendwann in ferner, ferner Zukunft, also in zwei bis drei Jahren, einmal die
benutzte Hardware, das Betriebssystem oder die zugrundeliegende Datenbank dank abgelaufenem
Support auf einen neuen Stand gebracht werden mu, steht eine schwierige Entscheidung an:
Lassen wir das System so, wie es ist, und verzichten auf Herstellersupport oder riskieren wir einen
existenzgefahrdenden Betriebsausfall, wenn wir ohne vorhergehende Tests ein Upgrade versuchen?
Ich behaupte nicht, da in allen Fallen eine Testumgebung in voller Groe standig bereitgehalten
werden mu. Aber ohne den Zugri auf eine Testumgebung kann ein zuverlassiger Betrieb
langfristig nicht sichergestellt werden.
6.2 Die Lebenserwartung eines Systems
Wer schon einmal einer Geschaftsfuhrung gesagt hat, da ein funf Jahre altes System reif fur den
Gnadenstrom ist, kennt vielleicht das entsetzte "aber das ist doch erst funf Jahre alt, wir sind
davon ausgegangen, da das mindestens zehn Jahre lauft!\
Unabhangig von der Ursache fur diese gangige Fehleinschatzung sind die Auswirkungen doch
fatal. Deshalb sollte man schon wahrend des Projekts die Lebenserwartung der benutzen Komponenten
dokumentieren: Wie lange wird fur die Hardware noch die Ersatzteilversorgung sichergestellt
sein? Was ist mit Security Patches fur das Betriebssystem und andere sicherheitskritische
Komponenten? Was ist mit dem immer wieder gerne diskutierten Herstellersupport?
Eine solche Aufstellung ist auch fur das Management sehr wichtig: Erstens kann es sich damit
uberlegen, wann welche Investitionen in der Zukunft notig werden. Zweitens ist ein RoI1 von funf
Jahren bei einer Lebenserwartung des Gesamtsystems von drei bis vier Jahren ein Signal, das so
ziemlich jeder Manager versteht.
7 Fazit
Im Verlauf dieses Vortrags ist ho entlich deutlich geworden, da "Never Touch a Running System\
keine Universalweisheit der Systemadministration ist, sondern in vielen wichtigen Fallen
hochgradig kontraproduktiv ist.
Weiter sollte der Vortrag einige Hinweise gegeben haben, warum die Kommunikation zwischen
Technik und Management manchmal so schwierig ist und wie man als Techniker dazu beitragen
kann, sie zu verbessern.
Schlielich sind in heute typischen IT-Landschaften Sysadmins die einzigen, die in der Technik
eine langfristige Kontinuitat bewahren konnen. Auch wenn das normalerweise nicht explizit als
Aufgabe in einer Stellenbeschreibung genannt wird, ist diese Funktion existentiell wichtig.
Literatur
[DeM93] Tom DeMarco. Lean and mean. In [DeM95], chapter 1. Dorset House, 1993.
[DeM95] Tom DeMarco. Why Does Software Cost So Much? Dorset House, 1995.
[Ger02] Louis V. Gerstner. Who Says Elephants Can't Dance? Harper Collins, 2002.
[LH02] Thomas A. Limoncelli and Christine Hogan. The Practice of System and Network
Administration. Addison-Wesley, 2002.
[RR00] Sharon Marsh Roberts and Ken Roberts. Do I want to take this crunch project? In
[WBK00], pages 25{42. Dorset House, 2000.
1Return of Investment, sprich der Zeitpunkt, bis zu dem man die Investitionen wieder hereingeholt hat.
8
Benedikt Stockebrand Never Touch a Running System
[RW93] Wolf Ruede-Wissmann. Satanische Verhandlungskunst|und wie man sich dagegen
wehrt. Wilhelm Heyne Verlag, 1993.
[WBK00] Gerald M. Weinberg, James Bach, and Naomi Karten, editors. Amplifying Your E ectiveness.
Dorset House, 2000.
[You97] Edward Yourdon. Death March|The Complete Software Developer's Guide to Surviving
\Mission Impossible" Projects. Prentice Hall, 1997.
Uber dieses Manuskript
Dies ist das Manuskript eines Vortrags, den ich am 03. Juni 2003 vor der Karlsruher Ortsgruppe
der SAGE@GUUG gehalten habe. Es greift einige Fragen auf, die im Anschlu an meinen Vortrag
"Nach dem Boom: Ein Gesundheitscheck fur IT-Systeme\ beim GUUG-Fruhjahrsfachgesprach
2003 aufgekommen sind.
Uber den Autor
Der Autor ist Dipl.-Inform. und freischa ender Systemarchitekt im Unix- und
TCP/IP-Umfeld.
Er unterstutzt IT-Projekte dabei, Software auf real existierender Hardware
in real existierenden Rechenzentren in einen ezienten und zuverlassigen Betrieb
zu nehmen, bringt die Infrastruktur von Rechenzentren auf den Stand
der Technik und fuhrt vor allem die IT-Bausunden der New Economy in die
betriebwirtschaftliche Realitat.
Wenn er nicht gerade tauchen geht oder mit dem Fahrrad Kontinente sammelt,
ist er unter stockebrand@guug.de, me@benedikt-stockebrand.de und
http://www.benedikt-stockebrand.de/ zu erreichen.
9
