Managing Tech

Managing Technology, from the trenches

Infos

Im privaten Blog von Jan Miczaika geht es um die Arbeit mit Technologien, in Teams, und das insbesondere im Startup-Umfeld. Kontakt?
    jan -at- hitflip.de oder bei XING

Wir haben einen formalen Bereitschaftsdienst für unsere IT eingeführt. Ich würde gerne unsere ersten Erfahrungen teilen und nach Input fragen.

Bis vor kurzem hatten wir keinen festen Bereitschaftsdienst. Ein lobenswerter Kollege (dessen Blog ich gerade nicht finde) und ich waren beide ständig in Alarmbereitschaft. Sobald die SMS von Serverguard ankamen ging die Telefoniererei los. Wer hat Zeit, wer hat Netz?

Mit der Zeit, mit mehr präventiver Arbeit und vor allem mehr Hardware wurden die Ausfälle immer weniger. Trotzdem ist es auf die Dauer natürlich kein Zustand, dass keiner so wirklich verantwortlich ist, sondern jeder ein bisschen. Vor allem wenn immer mehr Partner auf die Plattform zugreifen.

Wir haben unseren Bereitschaftsdienst wie folgt strukturiert.

  • Es hat immer ein Mitarbeiter Bereitschaftsdienst. Der Übergabezeitpunkt ist tagsüber im Büro. Wochenenden werden nicht geteilt, idealerweise hat ein Mitarbeiter immer 7 Tage Bereitschaft (Abweichungen sind in Absprache möglich).
  • Wir haben feste Geräte für die Bereitschaft. Dazu gehört ein Handy, eine UMTS-Karte sowie ein Laptop (ein kleines leichtes ThinkPad 61S). Mit diesen Geräten wird nicht gearbeitet, ausser im Einsatz!
  • Die Bereitschaft beginnt mit dem Ende des Arbeitstages und endet morgens zum Arbeitsanfang.
  • Innerhalb der Bereitschaftszeit muss der Mitarbeiter innerhalb von 15 Minuten online sein, wenn der Alarm los geht.
  • Die Handynummer ist bei den Monitoring-Diensten sowie im Rechenzentrum und in der Firma hinterlegt. Keine wechselnden Ansprechpartner mehr.
  • Der Laptop enthält eine vorkonfigurierte VirtualBox, die jeder bedienen kann und die jeder zum “üben” bekommt. Der Laptop konfiguriert sich weitestgehend alleine.
  • Alle wichtigen Telefonnummern und IPs sind auf dem Desktop hinterlegt.
  • Während der Woche sollte der Mitarbeiter abends einmal auf das Monitoring-Dashboard gucken. Am Wochenende einmal morgens und einmal abends. Nur, falls die SMS nicht durchkommen.
  • Alle Bereitschaftszeiten und Einsätze werden in einem Sheet festgehalten. Einsätze müssen dokumentiert werden!
  • Und jetzt das spannendste: die Bereitschaft wird gesondert vergütet. Das teilt sich auf in eine Pauschale und einen Betrag pro Einsatz, pro angefangene 30 Minuten. Ich bitte um Verständnis wenn ich hier die Vergütungsstruktur meiner Leute nicht öffentlich besprechen möchte.

Dieses System hat uns meiner Meinung nach bisher sehr gut gedient. Die Mitarbeiter fühlen sich verantwortlich für die Plattform während ihrer Zeit. Unsere Downtime ist zusätzlich signifikant zurückgegangen. Es ist auch ein guter Weg, durch zusätzliche Leistung sein Gehalt aufzubessern.

Als Chef habe ich einen Anreiz, die Einsatzzeiten zu minimieren. So räumen die Server nach einem Reboot abgebrochene Prozesse o.ä. soweit möglich automatisch auf. Wenn Fehler auftreten, enthalten die Fehlermeldungen Hinweise für den Bereitschaftsdienst, was er zu tun hat (teilweise inklusive shell Kommandos). Und die Mitarbeiter verdienen lieber am “Bereitschaft haben” als am “Bereitschaft leisten”, sodass die Sachen auch immer besser werden.

Die Kolumne zum Thema Datenbank Skalierung schreibe ich noch weiter. Gibt es aber zum Thema Bereitschaft noch Ideen, was wir besser regeln können?

14 Responses to “Bereitschaftsdienst für die IT organisieren - erste Erfahrungen”

  1. Als Chef solltest Du etwas mehr Wert auf die Begrifflichkeiten legen. Eine Bereitschaft liegt vor, wenn man sich an einen bestimmten Ort aufhalten muss um sofort in Dienst zu treten. Auch wenn man nichts tut, wird die Bereitschaftszeit als Arbeitszeit gewertet(!). Eine Rufbereitschaft liegt vor wenn man nach telefonischer Alarmierung den Dienst aufnimmt, dort wird nur die tatsächliche Zeit abgerechnet. In jedem Fall sind die Ruhezeiten einzuhalten.

    Problematisch sehe ich die 15 Minuten Reaktionszeit an. Nicht überall in DE ist Handy-Netz gegeben womit sich der Bewegungsradius des Mitarbeiters einschränkt, da könnte man (wenn man einen Ex-Mitarbeiter hat der es drauf anlegt) Pech vor Gericht haben was die Einstufung Ruf- oder Bereitschaft hat.

    Was aber aber (imho) viel wichtiger als die (Ruf)Bereitschaft ist, ist die Frage was wann alarmiert wird. Das spart Zeit (und damit Geld) und nerven bei allen, denn eine zu engmaschige Alarmierung wird auf Dauer ignoriert und führt nicht zur Verbesserung der Service-Qualität.

    Joern

  2. Hi Jörn,

    vielen Dank für den (richtigen) Hinweis bezgl. Bereitschaft/Rufbereitschaft. Bei uns im Arbeitsvertrag ist das korrekt beschrieben. Wobei der räumliche Aufenthaltsort heutzutage bei ITlern eh eine untergeordnete Rolle spielt, gerade als Unternehmen mit einem Hauptsitz in der Stadt. Aber beim deutschen Arbeitsrecht muss man da aufpassen!

    Die Erfahrung mit den Alerts habe ich auch schon gemacht. Es gab bei uns auch schon permanent auf rot stehende Probes, die ignoriert wurden (jaja, die ist eh defekt). Das kann auf die Dauer natürlich nicht sein.

    Dadurch, dass jetzt nicht unerhebliche Kosten pro Einsatz anfallen, habe ich als “Chef” ein viel stärkeres Interesse daran diese Fehlalarme zu vermeiden. Das sind einerseits technische Einstellungen (frühere warnings, die während der Arbeitszeit erledigt werden können) wie auch Änderungen an den Prozessen (Eskalationspfade). Ich denke das ist für alle besser. Nachts wegen Quatsch geweckt zu werden ist natürlich unbefriedigend, wenn es ein Notfall ist, ist das eher ok.

    Jan

  3. Hallo Jan,
    verständlich dass du die Vergütungsstruktur nicht offen legen möchtest. Aber könntest du eventuell schreiben, mit wieviel Prozent des monatlichen Bruttolohns ein Bereitschaftstag/woche bei euch vergütet wird?

    Florian

  4. Ich habe so einen (Ruf-)Bereitschaftsdienst schon bei einigen großen Firmen gesehen und ich finde Ihr seid da im Vergleich schon gut aufgestellt.

    Aus Vergütungsberatungssicht bin ich bei dem letzten Punkt hängen geblieben:

    “Und jetzt das spannendste: die Bereitschaft wird gesondert vergütet. Das teilt sich auf in eine Pauschale und einen Betrag pro Einsatz, pro angefangene 30 Minuten…”

    Wenn Ihr Einsätze gesondert vergütet, setzt Ihr da nicht den falschen Anreiz für die Leute, nach dem Motto Ausfälle werden belohnt? Je nach Höhe kann man das für den Einzelnen sicherlich machen. Spannend finde ich in so einem Prozess aber Klammerziele. Wie wäre es mit einem Bonus für das gesamte Team wenn am Wochenende nichts passiert (akkumuliert übers Jahr muss es dann 100-125% variable Vergütung für diese Zielkomponente ergeben). So denkt plötzlich das ganze Team proaktiv an Fehlervermeidung und nicht nur Du als Chef.

    Manuel

  5. Danke für die Kommentare!

    Florian, für eine Woche Rufbereitschaftsdienst gibt es etwa 10% des Bruttolohns.

    Manuel, den Tipp mit den Klammerzielen finde ich sehr gut! Derzeit werden Ausfälle in der Tat belohnt. Wie würdest du solche Klammerziele denn gestalten?

    Einen Bonus für das ganze Team, wenn die Anzahl der Einsätze unter X bleibt?

    Jan

  6. Na ja, ich weiß nicht wie bei Euch das variable Gehalt aussieht. Ich persönlich würde 5%-20% variabel machen (je nach Position). Die würde ich in 2-3 Kategorien einteilen:
    - Unternehmensziele
    - Bereichsziele
    - Persönliche Ziele

    Über die prozentuale Verteilung kannst Du dann steuern was Euch wichtig ist. Persönliche Ziele würde ich bei jungen Unternehmen eher weglassen. Bei Startups auf jeden Fall.

    Für das Beispiel Bereichsziele würde ich die 2-5 entscheidenden KPIs des Bereiches identifizieren, heutigen Stand ermitteln und dann eine quantifizierbare Zielgröße setzen. Da kannst Du z.B. sowas machen wie
    - 0 Einsätze = 100% Bonus
    - 1 Einsatz = 75%
    - 2 Einsätze = 50%
    - 3 Einsätze = 25%
    - > 4 Einsätze = 0%

    Vielleicht sind es aber auch nicht die Anzahl der Einsätze, sondern die Länge (habt Ihr ja heute drin). Die Wahl der Zielgröße ist ziemlich entscheidend, da die Leute dann auch ganz genau darauf schauen werden. Wichtig ist, dass das Thema “moral hazard” soweit wie möglich reduziert wird.

    Ein Hinweis aber noch: variable Vergütung hat einen enormen Effekt auf die Unternehmenskultur und wenn man sie einmal eingeführt hat, dann ist sie nur schwierig wieder rauszunehmen (es sei denn man zahlt den Bonus fix aus, darüber wird sich wohl niemand beschweren). Außerdem macht variable Vergütung nicht für alle Positionen Sinn… Aber das ist eine längere Diskussion.

    Manuel

  7. - 0 Einsätze = 100% Bonus
    - 1 Einsatz = 75%
    - 2 Einsätze = 50%
    - 3 Einsätze = 25%
    - > 4 Einsätze = 0%

    Das ist großer Mist. Schließlich rührt nicht jeder Einsatz von einem vorhergehenden Versäumnis.

    Einer Festplatte ist es ziemlich wurscht, ob du sie dreimal die Woche streichelst, die sagt einfach irgendwann “aus die Maus” und dann muß einer hin.

    Anders sähe es aus, wenn es die Woche dreimal klingelt …

    Sowas endet damit, daß z.B. nötige Einsätze “verschoben” werden oder Probleme verheimlicht und damit Chancen vertan werden für eine wirkliche Verbesserung der Infrastruktur.

    Intrinsische Motivation durch extrinische zu ersetzen, geht meistens anders aus als gedacht.

    deltatango

  8. @Deltatango:
    Intrinsische vs. extrinsische Motivation ist genau das Thema was ich oben meinte. Wer variable Vergütung einführt ruft manchmal Geister die er gar nicht haben will und nur sehr schwer wieder los wird. In den Köpfen der Leute wird plötzlich die Rechnung aufgemacht: “Wenn ich X tue bekomme ich Y €”. Das ist ein fundamentaler Kulturwandel.

    Das heißt aber nicht das variable Vergütung prinzipiell schlecht ist. Aus unternehmerischer Sicht kann sie durchaus Sinn machen, weil man dann als Unternehmen “atmen” kann. Mitarbeiter denken dadurch auch häufig deutlich unternehmerischer bzw. mehr im Sinne des Unternehmens. Die Mischung der Kategorien und das definieren der Ziele ist da aber entscheidend. Variable Gehaltsbestandteile sollten imho immer Top-Down eingeführt werden: erst Unternehmens- dann Bereichs- und evtl. persönliche Ziele.

    Aber damit hier nichts falsch rüberkommt: Intrinsische Motivation ist immer die beste Motivation. Bei kleinen Unternehmen ist die meist schon gegeben, warum dann etwas ändern? Man macht häufig mehr kaputt als man gewinnt. Ab einer bestimmten Unternehmensgröße (kann je nach Unternehmenskultur variieren) machen durchaus aber auch extrinsische Anreize Sinn. Warum? Weil die intrinsische Motivation bei größeren Unternehmen im Schnitt abnimmt. Deshalb werden die auch (im Schnitt) deutlich unproduktiver.

    Nun zu dem Mist. Natürlich raucht hin und wieder mal eine Festplatte ab. Dadurch wird aber noch nicht die ganze Idee Schrott. Entweder man sagt: “Pech gehabt, ihr seid auch dafür verantwortlich, dass die HW läuft” oder man definiert die Ziele noch in beeinflussbare und nicht beeinflussbare Faktoren (Der letzte Vorschlag erhöht deutlich die Komplexität). Natürlich stimme ich Dir zu, dass es bei so ziemlich jeder Steuerungsgröße Moral Hazard Probleme gibt. Mein Modell kann auf jeden Fall noch verbessert werden. Ich wollte aber auch primär aufzeigen wie man an so ein Thema rangehen kann(!).

    Einsätze am Wochenende zu belohnen halte ich prinzipiell für kontraproduktiv. Warum sollte ich dann an einem Festplattenaustausch nicht einfach drei Stunden sitzen wenn ich für jede halbe Stunde bezahlt werde? Wenn schon variable Vergütung einführen, dann auch mit der Orientierung an Unternehmenszielen. Zielsetzung aus unternehmerischer Sicht sollte es doch sein, dass die IT sich so aufstellt, dass Ausfallzeiten und IT-Kosten möglichst minimiert werden und das die IT einen Business-Mehrwert generiert.

    Was ist denn aus Deiner Sicht eine gute Steuerungsgröße für den IT-Support (Abteilung)?
    Was ist eine gute Steuerungsgröße für den IT-Supportler (Person, die am Wochenende Bereitschaft hat)?

    Zum IT Support (Abteilung) noch zwei Punkte:

    1. Der Magenta-Riese z.B. steuert die gesamte IT nach ein paar wenigen Kennzahlen. Eine zentrale z.B. ist die Dauer der Uptime zwischen zwei Ausfällen in Stunden. Ob eine Festplatte abgeraucht ist oder jemand mutwillig den Stecker gezogen hat, ist an der Stelle total egal. Wenn das System unten ist, dann verliert das Unternehmen Geld und die IT hat ihren Job nicht gemacht.

    2. Noch ein kurzer Exkurs zu großen Unternehmen. Die unterscheiden beim Support in Incident und Problem Management. Steuerungsgröße beim Incident Management ist die Effizienz, also die schnellstmögliche Wiederherstellung der Plattformen, damit die Nutzer die Plattform wieder nutzen können (damit Geld verdient wird). Im Problem Management ist die Steuerungsgröße die Effektivität oder die Qualität. Am Wochenende würde klassischerweise nur Incident Management gemacht. Problem Management - also die wirkliche Ursachenbehebung - während der Woche. Beides kann man sehr detailliert mit KPIs hinterlegen. Gute weiterführende Literatur dazu gibt es bei http://en.wikipedia.org/wiki/ITIL bzw. http://en.wikipedia.org/wiki/COBIT und den verweisenden Quellen.

    Ich bin kein ITIL oder COBIT Verfechter, aber ich glaube, dass diese Frameworks dabei unterstützen können, die IT aus unternehmerischer Sicht zu steuern.

    @Jan: Das Textfeld zum Eingeben von Text ist definitiv zu klein ;-)

    Manuel

  9. Zum IT Support (Abteilung) noch zwei Punkte:

    1. Der Magenta-Riese z.B. steuert die gesamte IT nach ein paar wenigen Kennzahlen. Eine zentrale z.B. ist die Dauer der Uptime zwischen zwei Ausfällen in Stunden. Ob eine Festplatte abgeraucht ist oder jemand mutwillig den Stecker gezogen hat, ist an der Stelle total egal. Wenn das System unten ist, dann verliert das Unternehmen Geld und die IT hat ihren Job nicht gemacht.

    2. Noch ein kurzer Exkurs zu den “Best Practices” von großen Unternehmen. Da gibt es beim Support den Unterschied zwischen Incident und Problem Management. Steuerungsgröße beim Incident Management ist die Effizienz, also die schnellstmögliche Wiederherstellung der Arbeitsfähigkeit, damit die Nutzer die Plattform wieder nutzen können (damit Geld verdient wird). Im Problem Management ist die Steuerungsgröße die Effektivität oder die Qualität. Arbeiten am Wochenende würden klassischerweise auf das Nötigste (i.W. Konzentration auf Incident Management) reduziert werden. Problem Management - also die wirkliche Ursachenbehebung - wird dann während der Woche gemacht. Beides kann man mit sehr konkreten KPIs hinterlegen. Wenn es interessiert: Gute weiterführende Literatur dazu gibt es bei http://en.wikipedia.org/wiki/ITIL bzw. http://en.wikipedia.org/wiki/COBIT (und den verweisenden Quellen). Ich habe bei vielen großen Unternehmen gesehen, dass
    allein das Bewusstmachen dieser Unterscheidung viel zur Effektivitätssteigerung beigetragen hat.

    Ich bin kein ITIL oder COBIT Verfechter, aber ich glaube, dass diese Frameworks dabei unterstützen können, die IT aus unternehmerischer Sicht zu steuern.

    @Jan: Dein Eingabefeld für den Text ist definitiv zu klein und das Zeichenlimit zu niedrig ;-)

    Manuel

  10. Ich weiss nicht, ob die IT-Organisation des rosa Riesen jedem als Vorbild dienen sollte oder kann.

    Ich kann aus meiner aktiven Bereitschaftszeit (1996-1999 - das Klingeln des S4 lösst bei mir immer noch einen Adrenalinstoss aus) noch ein paar Tipps geben:

    1) Einen Mailverteiler für Betriebsvorfälle einrichten. Bereitschaftseinsätze mit Lösung werden gleich nach Einsatzende dokumentiert und an den Verteiler verschickt. Auf diese Weise wissen auch wenn der betreffende Kollege noch in der Heia liegt alle anderen schonmal Bescheid. Cut ‘n Paste fähige Rezepte werden auch gern genommen. An den Verteiler sollten natürlich auch sonst Dinge geschickt werden, die die Bereitschaft interessieren (könnten). Also Changes, Tests, Downtimes, Launches, etc.

    2) Der Bereitschafter der abends “dran” sein wird, sollte auch tagsüber das “rote Telefon” haben und sich um das Incident-Management kümmern (das gibt den anderen Kollegen Zeit, sich um Dinge zu kümmern, die längere Konzentrationsphasen benötigen).
    Die extra vergütete Bereitschaftszeit beginnt natürlich trotzdem erst nach der Bürozeit.

    3) Bei uns wurden Bereitschaftsstunden als Teil der vereinbarten Ziele festgesetzt. Dabei ging es nicht um die Anzahl der Einsätze sondern die Teilnahme an der Bereitschaft. Wer sich oft zur Bereitschaft gemeldet hat, konnte u. a. so seinen variablen Anteil verdienen.

    Ansonsten kann ich noch die Bücher von Thomas A. Limoncelli empfehlen, wenn es um Tipps zu diesem Bereich geht.

    Hein Bloed

  11. Nur eine kleine Anmerkung: der Einsatz bei Ausfall einer Festplatte ist sicherlich nichts was ein Admin Team nicht verhindern könnte. Robuste Storage Planung ist also durchaus auch belohnenswert.

    Allerdings: nicht immer hat der Mitarbeiter der die Bereitschaft hat die Möglichkeit die Architektur zu ändern, schon aus diesem Grund ist es sinnvoll dessen Entschädigung nicht zu kürzen wenn er oft die Probleme (anderer) ausbaden muss.

    Aber: jeder Vorfall sollte ein Followup Problem Management nach sich ziehen.

    Gruss
    Bernd

    Bernd Eckenfels

  12. Pointer: Rufbereitschaft…

    Pointer: Interessanter Artikel (und ausführliche Diskussion in den Kommentaren) zum Thema Rufbereitschaft in der IT findet sich im Managing Tech Blog.

    IT Blog

  13. Rein aus dem Bauch heraus:
    Die Vergütung für den Rufbereitschaftseinsatz sollte nur genau so hoch sein, dass man an der Arbeit nich rummeckert. Also eine kleine “Anerkennung” sozusagen. Es darf auf keinen Fall “einträglich” werden.

    Variable Vergütung? Dann aber bitte nur an Zielen, die man wirklich erreichen will. Ihr wollt sicherlich nicht möglichst wenig Einsätze am Wochenende. Ihr wollt zufriedene Kunden. Dazu benötigt ihr vermutlich wenig Downtime UND relaxte und freundliche Mitarbeiter. Das passt leider in keine gehaltstaugliche Kennzahl. Es wird immer auf das optimiert, was die Kennzahl misst. Also genau überlegen, ob man das wirklich will!

    Tobias

  14. Bei meinem vorherigen Job fand ich es sehr gut, dass die erste Bereitschaftsstunde im Entgeld bereits enthalten war. Das hat den Papierkram stark minimiert.

    Was mir fehlt, ist die Möglichkeit zur Eskalation. Ist die nächste Managementstufe (Du?) auch in Bereitschaft?

    Keine Lösung in einer halben Stunde -> Eskalation. Das hält dem arbeitenden Admin den Rücken frei (eventuell Telefonumleitung)

    Das hätte ich mir beispielsweise bei meinem längsten Bereitschaftsfall gewünscht.

    Dirk Deimeke

Leave a Reply