Pflicht ist ein wichtiger Bestandteil der meisten modernen Organisationen. Immerhin kommt es häufig vor, dass das Problem um 3 Uhr morgens eintrifft. Aber wer sollte Dienst haben? Und wie kann man diesen Prozess so organisieren, dass er Sinn macht?
Schauen Sie unter die Katze, dort erzählen Baruch Sadogursky (
@jbaruch ) und Leonid Igolnik (
@ligolnik ) eine Horrorgeschichte über einen unglücklichen
Dienstoffizier . Erinnerst du dich an Vasya, der immer
um drei Uhr morgens
Fehler beheben musste? Dies ist nur der Anfang.
Das Material wurde basierend auf der Rede von Baruch und Leonid auf der Herbstkonferenz DevOops 2017 vorbereitet.
Also im Dienst. Nehmen wir als Beispiel die hypothetische Vasya, die vor nicht allzu langer Zeit in einem bestimmten Unternehmen gearbeitet hat, ungefähr ein Jahr. Heute ist Freitag und so ist es passiert, dass Vasya im Dienst ist. Alles geht gut: Vasya schläft und seine Träume sind wunderschön.
Während er nichts ahnt, erhält sein Kollege vom technischen Support einen Anruf von einem Kunden. Er sagt, dass er am Montag dem CEO eine sehr wichtige Demo zeigen muss, aber etwas funktioniert nicht. Dringende Notwendigkeit, das Problem zu beheben. Der Support tat alles, was er konnte (schlug vor, es ein- und auszuschalten) und eskaliert dieses Problem an den Mitarbeiter.
Vasya ist für das gesamte Projekt allein im Dienst, er wird dies tun müssen. Ein Techniker des technischen Supports weckt ihn und versucht, das Problem mit sehr einfachen Worten zu erklären: „Dort funktioniert etwas nicht, etwas stimmt nicht.“
Vasya hört seinem Kollegen zu, überlegt, was passiert ist und trifft die einzig richtige Entscheidung ...
Der Support-Techniker ist beleidigt, bittet den Kunden jedoch, bis Montag zu warten. Der Kunde ist mit diesem Sachverhalt nicht einverstanden und leitet das Problem an den Support-Manager weiter. Jetzt ruft er Vasya an und sagt, dass dies nicht ernst ist: "Trotzdem ist die Sache wichtig, der Klient ist besorgt, es ist notwendig." Vasya ist eine verantwortliche Person. Es muss notwendig sein: Kaffee und Tanz (suchen Sie nach etwas in den Protokollen).
In den Protokollen stellte sich heraus, dass alles alles andere als einfach war. Zuerst suchte Vasya nach einer Person, die 15 Minuten lang Zugriff auf das richtige Protokoll hatte. Er fand es und bekam ein Protokoll. Aber wie? Natürlich, um im DOC-Format zu mailen. Vasya ist verantwortlich, jung und liest das Protokoll in Word: Es wird überhaupt nichts verstanden. Es gibt jedoch Schlüsselwörter, die Sie in der Knowledge Base suchen können. Vasya hält ungefähr 20 Minuten an interessanten Dingen fest, lernt viel von allem Interessanten, aber im Moment wird nichts benötigt.
Was macht Vasya als nächstes? Sie müssen jemanden suchen, aber Vasya ist ein junger Ingenieur und es ist beängstigend, Senior zu wecken. Daher beschließt er, dass Sie einen Kollegen anrufen müssen, den gleichen Junior.
Ein Kollege ist ein guter Freund, mit halbem Kummer verstehen sie das Problem und beginnen, es zu lösen. Nach zwei bis drei Stunden Arbeit fanden sie einen Hot-Fix. Es muss sofort der Produktion übergeben werden. Aber wie? Es gibt eine Change Control Board, die sich alle zwei Wochen montags trifft. Diese Option passt jedoch nicht, Sie benötigen sie dringend.
Natürlich können Sie nicht für die Produktion bereitstellen, es gibt kein Root. Die einzige Möglichkeit besteht darin, eine JAR-Datei mit zwei Klassen und einem Absatz mit Erläuterungen per E-Mail zu senden. Diese Leute werden über ssh in die Produktion gehen und dort diese JAR-Datei in WebSphere in das richtige Verzeichnis stellen. Und jetzt, um 6-7 Uhr morgens, können Sie endlich mit einem Gefühl der Vollendung ins Bett gehen.
Am Montag kommt Vasya zur Arbeit und sieht ein ungewöhnliches Bild. Der CEO schrie VP of Engineering an, weil der Kunde den CEO anschrie, weil sein CEO ihn anschrie. Es stellte sich heraus, dass das Problem nicht gelöst werden konnte.
Die Behörden haben vier Fragen: "Was ist am Freitag passiert?"; "Warum habe ich am Montag vom Chef davon gehört?"; "Warum hat die Reparatur sechs Stunden gedauert?" und "Wer ist schuld?" Ops werden in den Raum gerufen, die sagen, dass dies nicht ihr Problem ist. Vasya und das andere Mädchen werden in den Raum gerufen, der auch sagt: "Nichts hat funktioniert." Das ganze Kartoffelspiel geht bis zum Mittagessen weiter.
Da es Zeit ist, zu Abend zu essen, wird die Entscheidung getroffen: "Okay, es ist von selbst kaputt, niemand ist schuld." Das Ende der Geschichte.
Lassen Sie uns eine kleine Nachbesprechung arrangieren: Lassen Sie uns diesen Albtraum durchgehen und versuchen, Antworten auf alle Fragen zu geben.
Wer sollte im Dienst sein
Sysadmins (oder ein modischeres Wort - SRE) können im Dienst sein. Sie machen das schon seit mehreren Jahren, sie haben alles gut eingestellt. DBA kann im Dienst sein, diejenigen, die mit Messaging beschäftigt sind, können. Wenn Sie Glück haben, ist NOC (Network Operation Center) im Einsatz - dann werden alle diese Leute in den gleichen Raum gebracht. Sie haben Runbooks, die sagen, was in einer schwierigen Situation zu tun ist.
Bei diesen Jungs ist alles klar, sie sind Profis im Dienst. Leider hat DevOps den zweiten Teil der Gleichung, der nicht wirklich im Dienst sein will. Wie mache ich den zweiten Teil? Ja, und ob es notwendig ist zu zwingen, denn die Profis sollten sich der Bedeutung der Pflicht bewusst sein.
Es gibt zwei Gründe, warum Menschen nicht im Dienst sein wollen. Eines ist, wenn so:
Niemand will Dienst haben, wenn alles schlecht ist. Die Lösung für dieses Problem ist ganz einfach:
Sie müssen guten Code schreiben, alles ist einfach. Das muss aber auch gelernt werden. Es stellt sich eine neue Frage: "Wie lerne ich?". Sie müssen Ihre Finger in die Steckdose stecken - #painisinstructional. Schmerz hilft.
Pflicht allein verbessert die Qualität des Codes. Der gleiche Vasya am Montag wird höchstwahrscheinlich seine Fehler korrigieren, um nicht noch eine Nacht auf der Suche nach Fehlern zu sitzen.
Barrieren im Dienst
Im Dienst gibt es einige Hindernisse, die nicht vorhanden sein sollten. Lassen Sie uns das Freitags-Fiasko von Vasya durchgehen. Erinnerst du dich, wie er die Protokolle in einem Word-Dokument gelesen hat?
Wir alle lieben Microsoft-Produkte, aber das können Sie in der modernen Welt nicht. Es gibt offensichtliche Dinge über Protokolle, die jeder verstehen sollte.
Der Hauptpunkt ist die Anzahl der Werkzeuge, die diese Probleme lösen: Logstash, Loggly, Sumo-Logik, Kibana. Sie müssen verwendet werden.
Zurück zur Frage des Zugriffs: Warum nicht Zugriff auf das Protokoll gewähren? Die Antwort sind sensible Daten. Den Kunden wurde versprochen, Daten vor Lecks zu schützen. Dies bedeutet, dass die Protokolle niemandem angezeigt werden können oder Sie Systeme mit der Funktionalität der Datenmaskierung verwenden müssen. Er selbst versteckt personenbezogene Daten und zeigt sie keiner Person ohne die erforderliche Zugriffsebene an. Alle heutigen Protokollanalyse-Tools verfügen über diese Funktionalität.
Ein weiterer Vorteil dieser Tools besteht darin, dass darauf „Überwachung für die Armen“ aufgebaut werden kann. Wenn Sie beispielsweise in den Protokollen eine bestimmte Anzahl von Fehlern sehen (die Warteschlange ist voll usw.), können Sie eine Allergie auslösen.
Wer bestimmt die Bedeutung des Problems
Wie kann man verstehen, im Dienst sein oder dringend laufen, um das Problem zu beheben? Wer ernennt den Schweregrad? Wer entscheidet, wie kritisch das Problem ist? Löst Unterstützung. Und warum? Weil Support eine Vision des Problems hat. Er weiß, wie schlimm alles ist.
Darüber hinaus arbeiten heute fast alle Unternehmen nach dem Prinzip der "kontinuierlichen Lieferung", sodass alle Kunden alle Funktionen gleichzeitig (und gleichzeitig Fehler) erhalten. Angenommen, es gibt einen Fehler, der für den Client wie folgt aussieht: "Dort funktioniert etwas nicht, es ist in Ordnung." Gleichzeitig werden vom Support Hunderte von Warnungen zu diesem Problem angezeigt, was offensichtlich schwerwiegend ist.
Der Kunde ist auch an der Bestimmung der Wichtigkeit des Problems beteiligt. Aber es gibt ein Problem - der Kunde glaubt nicht immer, dass sein kleines Problem behoben wird, und legt größten Wert darauf. Der Schweregrad wird zunehmend als Manipulationswerkzeug verwendet. Wenn die Schweregraddefinition jedoch korrekt erstellt wurde und der Client versteht, was SLA ist, geschieht dies normalerweise nicht. Dies ist ein gegenseitiger Lernprozess, wenn Kunden verstehen, was wirklich sehr wichtig und was einfach wichtig ist.
Kunden müssen die Möglichkeit erhalten, Bedeutung zu zeigen, da der Produkthersteller den Kontext des Problems nicht immer versteht.
SLA - eine Garantie für Reaktion und Lösungen innerhalb eines Tages, kann aber schneller sein. Dies hängt wiederum vom Kontext ab.
Organisatorische Herausforderungen
Vasya verstand das Problem nicht bis zum Ende. Natürlich ist er gerade aufgewacht, und ein Kollege des technischen Supports hat es auch schlecht erklärt. Es wird nur auf eine Weise behandelt: ein Ticket. Ein Ticket ist eine Referenznummer, die angibt, worum es geht. Dies ist für Vasya erforderlich, da der Support Vasya anstelle eines Telefons mitteilen könnte: „Öffnen Sie unser Ticketverwaltungssystem und sehen Sie sich die Ticketnummer 42 an.“ Dies ist aus mehreren Gründen erforderlich. Erstens wird Vasya, anstatt einem Kollegen in einem schläfrigen Zustand zuzuhören, aufwachen, ein Ticket lesen und verstehen, wie wichtig dies ist. Zweitens kann es mehr als ein Problem geben.
Es gibt noch eine andere Schwierigkeit, die das Gesamtbild beeinflusst: Vasya muss gefunden werden. Woher weiß die Unterstützung, dass Vasya heute im Dienst ist? Was ist, wenn er Vasya auch nicht kennt? Es ist wichtig, dass Sie nur die richtige Person finden. Die Lösung ist Virtual Extension mit verschiedenen Präfixen für Ingenieur, Produktion usw. Nun, oder andere, anspruchsvollere Systeme. Mit dieser Lösung müssen Sie nicht raten, wo Sie mitten in der Nacht anrufen müssen. Alles schaltet automatisch um.
Noch bequemer ist der Eskalations-Chat in Slack, Telegramm, Skype und überall. Der Titel des Chats ist die Nummer des gleichen Tickets. Die gesamte Kommunikation auf diesem Ticket zwischen den richtigen Personen erfolgt in diesem Chatroom. Eine der nützlichsten Eigenschaften einer solchen Chatik ist, dass Sie denen, die sich nach einer Weile der Arbeit anschließen, nichts mehr sagen müssen. Sie können einfach nachlesen, welche Entscheidungen bereits getroffen wurden.
Nun, eine virtuelle Telefonbrücke, die im Brandfall mit einem Treffpunkt verglichen werden kann: Jeder weiß, wohin er bei Problemen gehen muss. In modernen Systemen wie Zoom oder Bluejeans sind übrigens bereits alle erforderlichen Funktionen integriert.
Eskalationspfad
Vasya hatte Angst, den Herrn anzurufen, weil sie schrecklich sind. Was soll man damit machen? Lassen Sie uns über den Eskalationspfad sprechen. Sie müssen immer wissen, wer und wann Sie aufwachen oder von der Arbeit abheben müssen. Dies sollte jedem klar sein: demjenigen, der aufwacht, und demjenigen, der aufwacht. Sie müssen auch wissen, wo Sie anrufen müssen, wenn der erste Pfad nicht funktioniert hat. Ein guter Eskalationspfad führt bis zum CEO des Unternehmens.
Es gibt Mitteilungen, die vom CEO kommen sollten. Er muss sich kritischer Fragen bewusst sein.
Errand Manager
Die nächste interessante Position ist Manager auf Abruf. Er muss kein Technikfreak sein und an der Lösung eines Problems teilnehmen. Erstens kann Vasya mitten in der Nacht dem Klienten nichts Nützliches sagen. Der diensthabende Manager kann in dieser Situation helfen. Darüber hinaus kann er sich mit Koordination, Projektmanagement in einer schwierigen Situation und Ressourcenmanagement befassen. Schließlich muss die Arbeit reibungslos verlaufen.
Zugang zur Produktion
Soll ich Vasya Zugang zur Produktion gewähren? Schließlich sind nicht alle brillante Ingenieure, und es gibt bestimmte Dinge, von denen ich nicht lernen möchte. Kunden werden beleidigt sein. Dies wird mithilfe des Bereitstellungsprozesses gelöst. Wenn der Prozess korrekt konfiguriert ist, kann Vasya auf die Schaltfläche klicken, wodurch sein Produktionscode deaktiviert wird. Wenn Sie über eine normale Pipeline für die kontinuierliche Lieferung verfügen, kann dies höchstwahrscheinlich automatisch erfolgen (alle Tests werden bestanden). Wenn nicht, wird in vielen Unternehmen die Entscheidung von einem leitenden Ingenieur oder Manager getroffen. Er überprüft, bewertet das Risiko des Codes und trifft eine Entscheidung.
Und noch bevor der Hotfix erschien, sollten dokumentierte Tools zur Fehlerbehebung einbezogen werden. Eines der häufigsten Probleme im Dienst: Er beginnt zu überlegen, wie das Debuggen aktiviert oder die Protokollstufe geändert werden kann. Gleichzeitig gibt es bei allem anderen kein Problem. Es ist ratsam, dokumentierte Lösungen für Probleme zu haben.
Pflichtwechsel
Lassen Sie uns nun über den Prozess der Pflicht sprechen, der normalerweise eine Woche dauert. Irgendwann ist es notwendig zu ändern. Um sich effizient zu ändern, muss dies zu einem bestimmten Zeitpunkt erfolgen. Es ist notwendig, alles klar zu planen, und es ist wünschenswert, die Probleme effektiv auf die nächste diensthabende Person übertragen zu können. In vielen Unternehmen wird dies als Standardrallye durchgeführt oder es wird eine Seite erstellt, auf der der Mitarbeiter eine kleine Zeitschrift aufbewahrt.
Andere Probleme
Es gibt verschiedene andere Probleme, die angegangen werden müssen. Eine davon ist die Zertifizierung des Zugangs zur Produktion. Es ist ratsam, eine Grundzertifizierung durchzuführen, damit eine Person zeigt, dass sie versteht, was möglich ist und was nicht.
Wie übersetze ich es?
Aber wie kann das alles ins Unternehmen gebracht werden? Sie müssen verstehen, dass dies einige Zeit dauern wird.
Wir müssen mit den diensthabenden Senioren beginnen. Sie haben Erfahrung und wissen, was und wie zu reparieren ist. Der Herr hat weniger Probleme: Es gibt Zugriff auf die Protokolle usw.
Es ist ratsam, in einem kleinen Team zu starten. Wenn das Team bereits groß ist, müssen Sie ein kleines Team erstellen. Wenn alles gut funktioniert, können Sie den Rest beschämen.
Schlussfolgerungen
Wir gehen zur Hauptsache über. Trotz der Tatsache, dass wir Technikfreaks in Technik verliebt sind, ist das Wichtigste nicht das Produkt und die Technologie, die im Unternehmen verwendet werden, sondern das Gefühl der diensthabenden Person „Ich bin in den Prozess der Verbesserung des Produkts involviert“ (naja oder im Dienst selbst). Viele Menschen verstehen, dass Sie im Dienst sein müssen, aber Sie möchten Verbesserungen sehen. Die Menschen sollten sich bewusst sein, dass dank ihnen und ihren Verbesserungen die Dinge besser werden.
PS
Wir möchten ein Buch namens Drive empfehlen. Dies ist ein Buch über die Motivation von Menschen, die in Berufen wie unserem arbeiten. Diese Motivation besteht aus drei Hauptkomponenten und (Spoiler) keine davon ist Geld.
Bereits an diesem Sonntag werden Baruch und Leonid auf der DevOops 2018 in St. Petersburg einen Bericht „#DataDrivenDevOps“ liefern. Komm, es wird viele interessante Dinge geben: Hier sind die Berichte , hier ist John Willis und hier ist eine Party mit BoFs und Karaoke . Warten auf euch!