 Willkommen zu Tag 2. Der Momo fängt jetzt gleich an, einen Talk zum Thema Monitoring zu machen. Nicht unbedingt die technische Seite, sondern auch warum, wie und den Rest erklärt ihr euch am besten jetzt selber. Viel Spaß. Ja, hallo. Schön, dass ihr es heute Morgen alle her geschafft habt. 12.15 ist natürlich spannend für ein Talk, aber danke, dass trotzdem so viele wach sind. Ich möchte euch heute so ein bisschen die Ergebnisse von den letzten anderthalb Jahren, die ich mich mit Monitoring beschäftigt habe. Nicht zwingend nur die technische Seite, sondern ganz wichtig auch eben die ganzen Prozesse drumherum und so weiter näher bringen. Für die, die mich nicht kennen, ich bin Momo. Ich bin heute auch ausnahmsweise mal ohne Mark dabei. Der ist irgendwie zu Hause und krank und an Textenschuss, sagt ihm auf Twitter die begrüße benähen kennt. Kurz zu mir, ich leite bei einer Firma namens Data Center 1 die Netzwerkabteilung. Mein Team und ich betreuen so über 1000 Router und Switche in 20 Pops in Deutschland, vier Rechenzentren. Und wir haben teilweise echt anspruchsvolle Kunden, Banken, Versicherungen und so weiter. Dementsprechend ist natürlich bei uns Monitoring und auch insbesondere der ganze Incident Response Prozess extrem wichtig. Die wichtigste Frage natürlich auch, wenn ich versprochen habe, wir machen es nicht zu technisch ist, welche Software setzen wir ein? Welche brauchen wir für ein gutes Monitoring? Die Antwort könnte einfach eigentlich gar nicht sein. Ja, die Lösung ist Prometheus oder irgendwas anderes. Es ist vollkommen egal, welche Software einsetzt, solange die auf euren Newscase passt. Es gibt so ein paar Dinge, die die Software allerdings können müsste. Wichtigste aus meiner Sicht ist, dass die Software redundant läuft. Wenn ihr kein redundantes Monitoring habt, dann könnt ihr auch einfach gleich keinen Monitoring haben, weil wenn es wegfällt, ist es auch egal. Wichtig ist auch, wenn ihr euch die Software aussucht, versteht wie die Software funktioniert, wie sie Daten sammelt, wie das clustering da funktioniert und so weiter. Und nicht und zwar wie sie intern funktioniert und nicht einfach nur wie man abget install eSinger macht und gut ist. Das bringt euch am Ende vom Tag nicht weit. Was auch häufig sehr verlockend ist, dass so eine Software sich unglaublich toll konfigurieren lassen kann und ihr könnt unglaublich viele Abhängigkeiten damit schaffen. Ja, es ist natürlich toll, wenn euer Monitoring gegen euer LDAP synchronisiert und euch identifizieren könnt mit dem Benutzernamen, den ihr im ganzen Unternehmen habt. Aber wenn euer LDAP Server weggekackt ist, dann habt ihr kein Monitoring mehr. Also denkt einfach drüber nach, wenn ihr irgendwelche Abhängigkeiten zum dritten System einbaut, wie ihr sie umgehen könnt, ob ihr trotzdem noch in das System kommt, wenn zum Beispiel euer LDAP weg ist. Und insbesondere, wichtig, gerade wenn ihr sowas wie Kunden habt, achtet darauf, wie eure Software die Daten speichert. Ich habe euch hier mal ein Beispiel mitgebracht von der Software namens Aestats, die zeigt jetzt hier Traffic von unserem Unternehmen zu irgendeinem AS an, das ist auch erst mal egal was es ist. Wir sehen hier einen Ausschnitt von 24 Stunden und im Peak macht, sehen wir hier auf dem Graph Traffic von 1,1 Gigabit. Jetzt ist natürlich wichtig, nicht nur wie die Daten da drin sind, das sind jetzt irgendwie 5 Minuten Averages, die werden irgendwie von NetFlow gepolt, sondern auch wie die Daten darin altern. Schauen wir uns eine Woche an, das sind die gleichen Daten, verlieren wir auf einmal unsere Peaks. Das hilft euch im Zweifel in einem Jahr, wenn ihr irgendwie nochmal euer Monitoring schauen wollt, Capacity Planning machen wollt, keine Ahnung, wie viel Bums hatte ich denn unter Last und eure Peaks gehen verloren, dann bringen euch diese 600 Megabit Auslastung hier mal gar nichts. Und insbesondere auch gerade wenn ihr Kunden habt, SLR Reports generieren müsst, schaut, wie die Daten altern. Wenn ihr einen Jahr lang SLR Reports generieren müsst, aber eure Software irgendwie anfängt nach, keine Ahnung, sechs Monaten die Daten weg zu schmeißen, dann habt ihr echt ein Problem. Ihr dankt euch, dass in der Zukunft findet, dass am Anfang gleich richtig macht. So, wichtig ist natürlich auch, was wir eigentlich alles überwachen wollen. Die Frage ist, klar ja, wir wollen alles überwachen. Aber was heißt alles? Wir hatten das bei uns im Unternehmen den Fall, dass wir vor drei oder vier Jahren mal ein Konsistenzcheck gemacht haben und gemerkt haben, dass wir ein Drittel unserer Systeme nicht überwachen. Warum? Weil man sich von Hand im Monitoring anlegen musste. Es war ein extrem manueller Workflow, wir hatten eine CMDB, wo du es dokumentieren musstest, da musst du an zwei anderen Stellen noch die VLANs dokumentieren. Du musst das im Monitoring anlegen, im Backup anlegen und so weiter. Ja und die Aussage gilt jetzt nicht nur für das Monitoring, sondern eigentlich für alle anderen Systeme bei euch im Unternehmen. Es gibt eine Quelle der Wahrheit, wo so ein System liegt und alles andere erbt davon, irgendwie durch ein Stückchen Glucote, keine Ahnung, ihr Polti-RP von eurer CMDB, vielleicht habt ihr ein Netbox oder sowas, legt nichts von Hand darin an. Wenn ihr das macht, wenn ihr irgendwie keine Ahnung, drei Datenbanken habt, in denen ihr die Geräte abbildet, habt ihr am Ende vom Tag vier Zustände und es hilft keinem weiter. Wenn ich sage, dass wir alles überwachen wollen, dann meine ich auch wirklich alles. Und zwar nicht nur alle Geräte, nicht nur jeder Monitoring Server, die Redundanz davon, sondern monitort auch, dass euer Monitoring funktioniert. Wie geht es zum Beispiel, in dem ihr eine dritte Software aufsetzt oder im Zweifel nur ein Node aus der gleichen Software, der aber nicht in diesem Cluster lebt? Oder ihr macht sowas wie ein Heartbeat. Wir nutzen Obst Genie, ist im Endeffekt bei uns der Use Case, unserem Monitoring schickt jede Minute in den Alarm und das Obst Genie meckert irgendwie, wenn es den Alarm für zehn Minuten nicht mehr bekommen hat. Nur so könnt ihr sicherstellen, dass euer gesamter Workflow auch noch funktioniert. Was auch sehr praktisch, wenn auch manchmal irgendwie nervig ist, ist es, einen täglichen Call-out-Test zu haben. Funktioniert wirklich meine Alerting ganz durch. Es geht euch manchmal richtig auf den Sack, vor allem wenn ihr gerade irgendwie Sonntags zu Hause sitzt, gerade mit der Freundin irgendwie fernschaut und um 15 Uhr kommt dieser blöde Page, ihr seid rausgerissen, musstet nur kurz auf Acknowledge drücken, aber trotzdem gibt es euch die Sicherheit zu wissen, dass euer Monitoring funktioniert. Welche Werte brauchen wir in unserem Monitoring? Das Standard Monitoring ist irgendwie Blackbox. Ja, unser System, das wir erwachen, ist für uns eine Blackbox. Wir pingen das mal oder machen ein HTTB Get dagegen oder connecten per SNMP oder was auch immer. Das ist schon mal ein guter Start. Aber was, wenn wir zum Beispiel einen Web Server haben mit, keine Ahnung, irgendein lustigen Backend-Hinten dran und ein Backend-Node spielt verrückt von 5. Ja, jetzt kann es natürlich, dann können wir Glück haben. Unser Erster hatte ich Beget, wird sofort auf den Backend-Node zugewiesen, der Probleme macht. Wir kriegen einen 500er, Monitoring sagt, oh, das war es nicht in Ordnung, ich rufe an. Aber in 4 von 5 Fällen habt ihr in Anführungszeichen Pech und euer Monitoring kriegt gar nicht mit, dass irgendwas im Backend schiefläuft. Deswegen ist es ganz klar, wir brauchen Whitebox Monitoring. Wir müssen in unser Gerät rein, schon in unser Software und zum Beispiel unseren Web Server fragen, hey, wie viele HTTB 500 hast du in den letzten X Minuten seit dem letzten Scrape oder was auch immer ausgeliefert und wir alarmieren dann eben auf den Anstieg von HTTB 500. Wichtig ist auch, wenn wir Metriken überwachen, wie zum Beispiel die HTTB 500 Rate, dass wir nicht nur die Metrik Sarah wachen, sondern auch die Abwesenheit davon. Es bringt uns nichts, wenn wir Alarme haben für alles mögliche Temperatur zu hoch, Festplatte voll und sonst irgendwas, weil wir die Alarme gar nicht erreichen können, weil wir die Metrik nicht haben. Alarme, ja, wie schreiben wir ein Alarm oder was ist ein guter Alarm? In den nächsten Slides habe ich mal ein paar Beispiele mitgebracht, das ist jetzt alles so Pseudocode, den ich mir ausgedacht habe, fühlt sich vielleicht ganz leicht an, wie Prometheus ist aber vollkommen egal, der Sinn dahinter zählt. Dann machen wir es jetzt mal am Beispiel, die Festplatte ist voll. Erster Alarm. Discree ist gleich null. Wer von euch findet, dass das ein guter Alarm ist? Okay, keine, sehr schön. Warum ist das kein guter Alarm? Ganz klar, wenn das passiert, dann haben wir ein Problem und die Platte ist voll. Nächstes Beispiel, wir bauen uns einen relativen Schwellwert und haben irgendwie die benutzte Platte, die Gesamtverfügbare Platte und haben 99 Prozent Verfügbarkeit. Maschur Fans, wer hat solche Alarme, irgendwelche relativen Schwellwerte gegen die man fährt? Okay, sind schon mal, keine Ahnung, so ein Viertel ungefähr der Leute hier im Raum. Ist das ein guter Alarm? Kommt drauf an, aber machen wir es mal am Beispiel der Festplatte. 500 Gig Platte, 1 Prozent, 500 Megabyte Freie Bra, werde ich zufrieden, wenn ich am Nacht zum 3 wachgeklingelt werde. Aber wenn ich eine Zehntera Platte habe, sind noch 10 Gig frei. Muss ich dafür nach zum 3 aufstehen? Nein. Anderes Beispiel, absoluter Schwellwert, haben nur noch ein Gigabyte frei, würde jetzt in dem Case helfen. Wer hat solche Alarme? Okay, ungefähr gleich viele. Ist auch ein netter Alarm, aber ein Beid zu viel. Der Suslock, der Nacht zum 3 herkommt und sagt, jo, ich mache jetzt Garbage Collection, hat absolut kein Mehrwert, aber hat es jetzt geschafft, dieses eine Beid zu viel schreiben, dass euer Schwellwert euch rausklingelt. Keine Frage, wir müssen uns in dem Alarm kümmern, aber wir müssen uns nicht nachts um 3 und diesen Alarm kümmern. Machen wir mal ein neues Beispiel. Eine Lineare Prediction, wir schauen das die letzte Stunde an. Wie hat sich da mein freier Festplattenplatz verhalten? Und wir überlegen anhand dieser linearen Vorhersage, habe ich in der Stunde ein Problem? Hat irgendjemand von euch solche Alarme? So 2, 3 vereinzelte Hände sind doch ein bisschen mehr 5, 6. Okay, in dem Fall jetzt auf jeden Fall ein guter Alarm. Handlungsbedarf ist ganz klar erkennbar. Wenn wir nichts machen, dann haben wir in einer Stunde eine volle Platte. Wir haben auch genug Zeit zum Handeln. Es ist nicht irgendwie die Platte schon voll und wir müssen jetzt dringend raus, sondern wir können gemütlich aufwachen, Rechner anmachen, uns anschauen, hey, warum läuft denn da gerade meine Platte voll und das Problem entsprechend behandeln. Bitte geht es aber nicht her und geht zu euren Monitoring, ersetzt jeden Alarm durch Predict Linear und freut euch, dass das gut ist. Es ist nicht die Wunderwaffe. Das Wichtige an dem Beispiel war nicht, dass wir jetzt sagen, hier, das ist die Technik, die ihr benutzen sollte zum Alarmieren, sondern dass ihr euch Gedanken über eurer Alarme macht. Und ganz wichtig auch, wie dringend sie sind. Stellt euch immer die Frage, muss ich jetzt für diesen Alarm nachts um drei am Sonntag jemand rausklingeln und im Zweifel regelmäßig. Wenn ihr das einmal macht, ist das kein Problem. Ja, dann sagt irgendwie, okay, zehn Terra Platte, mein Gott, ist ein Edge Case passiert nicht so oft. Aber wenn ihr irgendwann mal hunderte oder tausende Systeme unter eurer Fittlichen habt und das regelmäßig passiert, dann passiert das schlimmste, was euch passieren kann. Die Kollegen, die in Bereitschaft sind, gucken auf Sandy, sehen, ah, Disc Full Alarm, Acknowledge, ich drehe mich umkühmig morgen früh drum. In neun von zehn Fällen geht das bestimmt gut. Aber in dem einen Fall wurde jemand alarmiert und hatte einfach keinen Bock sich um den Alarm zu kümmern, weil er die ganze, weil er schon total müde von den Alarmen ist, die da reinkommen und überhaupt keinen, ja, die Dringlichkeit des Alarms nicht gesehen hat. Deswegen ganz wichtig, jedes Mal, wenn ihr Alarm macht, der so eine Severity hat, die nachts um drei jemand rausklingelt, denkt drüber nach, muss das wirklich sein. Wichtig ist auch, dass wir im Monitoring manchmal Einhörner haben. Die gilt das zu vermeiden. Ja, sehr tragisch. Ein Alarm sollte gleich sein, egal ob das jetzt die wichtigste Datenbank im Unternehmen ist oder ob das die MySQL von, keine Ahnung, dem Job ist, der einmal im Monat läuft. Das ist vielmehr eine Aufgabe im Engineering, dass alle Systeme sich halbwegs gleich anfühlen. Aber nur so könnt ihr sicher stellen, dass ihr nachts um drei auch wisst, was ihr tun müsst. Aber was muss ich denn eigentlich genau tun? Schauen wir uns mal am Beispiel von Airlines an. Von Piloten lernt es meistens ganz gut. Und gerade von Airlines die Fehler-Toleranz ist bei denen relativ gering. Ja, das ist immer scheiße, wenn so ein Flugzeug runterfällt. Deswegen haben die sich da extrem viele Gedanken gemacht. Und meistens, wenn ihr euch irgendeine Frage über einen Umgang mit Monitoring stellt, könnt ihr einfach mal gucken, wie macht das denn so die ganze Airlineindustrie und ihr findet da meistens eine halbwegs zufriedene Antwort oder ihr könnt daraus irgendwas für euch ablernen. Hier in dem Beispiel haben wir Engines, severe fire or damage or separation. Scheiße, mein Motor ist runtergefallen. Zugegeben, das passt jetzt auch nicht regelmäßig. Aber selbst dann die Dinge, die ich auf jeden Fall machen muss, sind klar niedergeschrieben und ich muss nicht nachdenken. Ich habe keinen Stress in dem Sinne. Ja, ich muss nur eine Checklist arbeiten und weiß, was ich tun muss. Wir haben das für uns so implementiert, dass niemand im Monitoring einen Alarm anlegen kann und den auf Master pushen, ohne dass dafür ein Runbook existiert. Ein Runbook ist eine Textdatei, in der ihr irgendwie hinschreibt, was es ist, keine Ahnung, Markdown-Bokument, wie auch immer, wenn es eine PDF sein muss, dann ist es halt eine PDF. Wenn ihr so einen Alarm schreibt und einen Runbook dafür anlegt, dann ist es ganz wichtig, dass ihr das auch nicht auf Master pusht, sondern dass ihr irgendjemand am besten dem, der am ganz anderen Ende von eurem System hängt, aber trotzdem mit einer Bereitschaft, dieses Runbook hinlegt und sagt, kannst du damit nach zum drei diesen Alarm lösen? Weil ihr seid mit dem System firm, ja, keine Ahnung, ich weiß, wie ich nachts umdrehen in WDM-Systemen wieder debaggen kann. Aber kann es der Kollege auch, der so ein Ding, nur alle drei Monate einmal anfasst? Macht euch darüber Gedanken. Was wir auch noch etabliert haben, ist ein regelmäßiges Peer Review. Heißt konkret, bei uns wird einmal die Woche, da läuft ein Cronjob, jemand kriegt eine Mail und sagt, hallo, du hast diese Woche die Lotterie gewonnen, hast drei Runbooks, schaust ihr an, schaut die Alarme dazu an und überprüft nochmal, ob du verstehst, was darin passiert, ob du damit nachts um drei den Alarm lösen könntest und ob du dafür nachts um drei Wachklinge klinet werden müsst. Ihr müsst es institutionalisieren, damit ihr eben hinkriegt, dass die Leute sich mit dem Monitoring und dem Instinct Response Prozess dazu ordentlich beschäftigen. Wichtig ist auch, wenn ein Runbook schreibt, dass dieses Runbook auf dem gleichen Server liegt. Wenn ihr euer Runbooks im Wiki habt, dann ist es schön, aber wenn das Wiki weg ist, habt ihr keine Runbooks. Bei uns, wie gesagt, es sind Markdown-Dokumente, die liegen auf irgendeinem Web-Server und solange ich den Alarm kriege, ist auch sichergestellt, dass ich an meinen Runbook ran komme und weiß, wie ich den Alarm lösen kann. Gut, Alarme haben wir uns angeschaut. Was bei Monitoring natürlich auch noch wichtig ist, sind typische Grafen. Dashboards sind super, ja. Zum einen sehen sie toll aus und machen Manager glücklich, insbesondere wenn da irgendwie Umsatz dran steht und der Pfeifen dann links unten nach rechts oben geht, das ist immer geil. Aber sie helfen euch auch auf jeden Fall in der Bereitschaft. Macht in euren Runbooks links zu Dashboards, baut die Dashboards natürlich wenn ihr Zeit habt und ist unglaublich angenehm, damit irgendwelche Daten zu korrelieren. Ja, keine Ahnung, wie verhält sich die Anzahl der User, die auf meine Webseite wollen, zu meiner CPU-Load oder sonst irgendwas. Was auch spannend ist in Runbook, in Dashboards sind Annotations, das sind jetzt hier in dem Grafana diese roten Striche, ich weiß nicht, ja doch, sieht man ganz gut, glaube ich. Annotations sind irgendwelche Events, die aus einer magischen Quelle kommen. Hat da gerade jemand auf Brott gepusht, gibt es irgendeine Lockmeldung oder sonst irgendwas? Hilft euch einfach noch mal mit einer kleinen Portion extra Kontext in dem Dashboard. Aber, Dashboards sind keine Alarmquelle. Jeder von euch kennt wahrscheinlich das Bild von dem Nock von irgendeinem SuperRZ-Provider oder von einem Carrier, wo zehn Menschen vor 300 Bildschirmen sitzen, alles blinkt und so weiter, sieht geil aus, keine Frage. Aber wenn eure Alarmierung darauf basiert, dass ein Mensch auf einen Graf schaut und euch sagt, ja, der ist jetzt hier in dem Schwellwert gelaufen, da rufe ich mal lieber jemand an, vergesst es, bezahlt bitte keine teuren Menschen für eine Aufgabe, die ein Computer deutlich besser kann. Dashboards sind zum analysieren und nicht zum Alarmieren. Das ist natürlich auch noch immer super, ist es Logging. Ein zentrales Logging kann euch im Zweifel den Arsch retten, wenn das System gerade gekrascht ist, ihr es nicht wieder hoch kriegt, aber es vielleicht noch geschafft hat seine letzten WW-chen an den Log-Server zu schicken, könnt ihr noch mal ein bisschen nachschauen und nachvollziehen, wie es zu dem Ausfall kam. Logging ist übrigens nicht ein ASUS-Log, der irgendwie in den Datei loggt und ihr dann damit crep und sonst was nach zum 3 rumfummeln müsst und euch die Regex zurechtliegen, dass ihr an die Werte kommt, ihr braucht, sondern ihr braucht ein strukturiertes Logging. Welche Software dafür benutzt es egal, ein Grafa-Naloki, Log-Stash, Greylog, was auch immer. Hauptsache, ihr könnt das Logging schon mal in Ruhe ordentlich mit Regex betanken, dass ihr einfach in Zukunft nur noch Filter klicken müsst und nachts um 3, so schnell wie möglich an alles kommt, was ihr braucht. Wie vorhin schon kurz erwähnt, Annotations im Dashboard sind vielleicht gut, außer das System schreibt irgendwie für alles mögliche Logs. Also wenn ihr jetzt jeden HDP Request als Annotation im Dashboard habt, wird es wahrscheinlich anstrengend, wenn eure Website ordentlich load hat. So, jetzt haben wir alles, wir haben Alarme, wir haben Dashboards und wir haben Logging, schon mal schön. Was machen wir, wenn es zum Incident kommt? Regel Nummer 1, natürlich sorry für das helle Bild. Don't panic. Ihr habt, ihr weiß nachts um 3, wenn irgendwie gerade, wenn man gerade anfängt mit der Bereitschaft, ist das immer spannend. Man ist aufgeregt, irgendwas ist gerade kaputt gegangen, ich muss mich drum kümmern. Aber es ist wichtig, erst mal einen Schritt zurück machen. Nachdenken, bevor man handelt, nicht einfach kurz, gerade bei uns im Rzeitumfeld irgendwie ganz schnell eine Sicherung wieder reindrücken und sonst, es hat meistens einen Grund, dass es dahin geführt hat. Überlegt euch gut, was ihr tut. Kommuniziert. Und zwar intern mit allen möglichen Stakeholders, keine Ahnung, euer Manager will vielleicht wissen, was da los ist, die anderen Teams, die auf die Applikation abhängen wollen, wissen, was da los ist. Aber kommuniziert auch extern. Gerade wir als Data Center Betreiber sind Infrastrukturenbieter. Wenn unser Scheiß nicht funktioniert, heißt es meistens, dass alles darüber auch nicht funktioniert. Und eure Kunden werden es euch danken, wenn ihr regelmäßig nach extern kommuniziert. Das entspannt euch im Zweifel nicht nur intern, sondern es löst euch auch unglaublich die Probleme, dass Kunden die ganze Zeit anrufen. Wenn ihr einfach sagt, hey, ich schicke jetzt ein Update, keine Ahnung, wir sind an dem Incident dran und in der Stunde kriegst du das nächste Update, dann weiß der Kunde schon, okay, ich musste jetzt nicht anrufen, die kümmern sich. Wenn die ganze Zeit bei eurem Service das Telefon klingelt oder noch viel schlimmer bei euch oder eure Manager kann, könnt ihr euch nicht drum kümmern. Dokumentiert alles in so einem Incident. Schreibt es irgendwie in den Chat in ein geschärtes Textprotokoll oder sonst irgendwas, was ihr macht. Gerade wenn so was länger geht, werdet euch das danken. Wenn zum Beispiel nachts um drei ihr merkt, okay, ich muss eskalieren, ja, ich brauche noch irgendwie Kollegen, ich komme allein nicht weiter, dann ist es schon mal wichtig, dass alle sehen können, was wurde denn schon gemacht, welche Systeme wurden neu gestartet und so weiter. Und ganz wichtig, arbeitet als Team, nicht als Einzelkämpfer. Es ist wichtig, dass das Ding wieder läuft und nicht, dass ihr zeigen könnt, was ihr für ein toller Engineer ist. Das sind alles gewöhnliche Alarme, ja. Schöne weiße Schwerne, gibt's Tausende auf der Welt davon. Und mit den Runbooks kann man unglaublich viel abdecken. Wir wissen eigentlich, was wir machen sollten und der Stress während so einem Incident sollte gering sein. Wir haben eigentlich nicht wirklich ein Problem, das wir jetzt lösen müssen, wir müssen nicht viel nachdenken, es ist eigentlich nur Arbeit. Aber ab und an kommt ein schwarzer Schwan. Alle paar Hundert Incidents oder so was. Ganzes RZ fällt aus. Zwei Megawatt Lasten weg. Ihr habt irgendeinen Doppelfieler und eure Redundanz reicht nicht mehr. Es brennt also wirklich. Darauf könnte euch natürlich vorbereiten, indem ihr Incident wills macht und so weiter. Aber es gibt noch ein paar Sachen, die da ganz wichtig sind. Baut euch Warrooms. Warrooms bestehen aus zwei bis drei Räumen. Ein Warroom ist ein Besprechungsraum, in den euch zurückziehen kann und eure Ruhe habt. Nicht, dass da ständig irgendjemand rein latscht und sagt, hey, ich habe hier noch irgendwie meinen Switchport, während da drüben gerade die ganze Bude brennt, hilft euch das herzlich wenig. Baut nen Tecoraum, wo Leute reinkommen können. Bei mir, bei nem Incident ist es so, dass mein Telefon gefühlt durchgängig klingelt, weil irgendwelche Kunden meine Handynummer haben, weil die Geschäftsleitung meine Handynummer hat und weil jeder, der irgendwie wissen will, was mit diesem Incident los ist, meine Handynummer hat. Baut nen Tecoraum, kommuniziert den ordentlich, dann könnt ihr Leuten sagen, hey, wenn ihr was dazu wissen wollt, kommt da rein, dann könnt ihr die Kommunikation ordentlich steuern. Und baut euch nen Chat, wo die Techniker miteinander reden können, wo ihr euer Problem die bangen könnt gemeinsam und das irgendwie lösen. ISC ist bestimmt toll, aber vielleicht wäre irgendwas mit ner History cool, wenn es jetzt ein ISC und ein Bouncer ist, das ist voll in Ordnung, aber schaut, dass ihr ne History habt. Weil, wenn ihr erst um 3 Uhr zu dem Incident dazugerufen wollt, wie vorhin schon erwähnt, wollt ihr die Dokumentation lesen, was schon gemacht wurde. Aber wir reden von nem schwarzen Schwan. Baut davon ein Backup. Ne interne Tecobraage ist toll, aber wenn das RZ ausgefallen ist, in der Telefonanlage steht, habt ihr wieder nichts. Holt euch nen externen Anbieter, keine Ahnung, SIP-Gate oder sonst wer, wird euch schon nen Tecoraum für wenig Geld im Monat geben. Das ist gut investiertes Geld für dann, wenn es einmal brennt und habt auch nen Fallback für den Chat ISC oder sonst irgendwas. Wenn es brennt, wollt ihr euch nicht darum kümmern müssen, das Ganze erst ans Laufen zu kriegen, die Kommunikation aufzusetzen bevor ihr überhaupt arbeiten könnt, ihr wollt das Problem lösen, und zwar so schnell und effizient wie möglich. Guckt, dass alle mit diesen ganzen Kommunikationswegen vertraut sind, keine Ahnung, im Zweifel schenkt jede Mitarbeiter die Rufbereitschaft kriegt, so ne lustige, laminierte Karte wo drin steht hier dieser Chatroom, diese Telkundummer und so weiter, kommen da rein, dann habt ihr das einfach auch alle schon mal geregelt und es muss nicht irgendjemand erst im Dokuwiki schauen muss ist, aber oh Scheiße, das Dokuwiki ist wieder weg. Hab klare Eskalationspfade bei euch im Unternehmen. Nachts um 3, wenn irgendwas schief geht, wird meistens erst mal irgendjemand wachgekriegen und der versucht es dann irgendwie zu lösen. Jeder im Unternehmen muss sich trauen können, seinen Chef anzurufen und das zu eskalieren und der muss dann im Zweifel entscheiden, wie es weiterkommt. Und es im Zweifel muss es bis zur Geschäftsleitung gehen, wenn wirklich so ein Supergau passiert, wie ein ganzes Rechenzentrum ist weg. Es darf niemals passieren, dass ihr irgendjemand dafür anschnausst oder anscheißt, dass er euch Nachts um 3 geweckt hat, obwohl er mit dem Inzident alleine klargekommen wäre. Er ruft euch nicht an, weil er da irgendwie Langeweile hat, sondern weil er gerade wirklich Panik hat und sagt, er kommt nicht weiter. Definiert in so nem Inzident auch ne Rollenverteiligung. Einer koordiniert den Inzident. Einer ist für die Kommunikation verantwortlich. Einer ist der verantwortlich, die Techies zu begeistern. Vom Department of Homeland Security, auch wenn ich die Amis nicht so toll finde, gibt es das Security-Inzident Command System. Es ist super dokumentiert, da sind einige an Rollen drin. Heißt es nicht, dass ihr die alle eins zu eins übernehmen wollt. Aber es ist mal ein guter Anhaltspunkt, was man da alles an Rollen braucht, wie man das im Inzident Koordinator einsetzt und so weiter. Ich wünsche euch allen, dass so ein Black Swan ganz selten vorkommt. Ja, vielleicht einmal im Jahr oder sonst irgendwas. Aber dadurch, dass es so selten ist, solltet ihr es auch insbesondere üben. Guckt euch, dass ihr vielleicht einmal pro halbes Jahr eine Inzidentübung macht, wo ihr euch hinsetzt und durchspült, wie es passiert. Irgendjemand ist dann der Dungeon Master und darf entscheiden, so, nach zum Drei, du bist jetzt wachgekängelt worden. Was machst du? Okay, das kaputte System. Es heißt da im Zweifel, Arscher wird übt, wie ihr die Fallbacks da durchkriegt. Guckt das im Zweifel auch mal die Eskalationspfade durchgespielt werden, dass ihr einfach in so einem Inzident euch auf die Arbeit konzentrieren müsst, die ihr lösen müsst und nicht darauf, irgendwelche Probleme zu lösen, die da jetzt noch zusätzlich dazu kommen. Wenn es mal wirklich brennt, uns sensible Daten in Gefahr sind Kreditkartendaten oder so was, oder Anlagen, gerade bei uns als RZ-Betreiber oder im Zweifel sogar Menschen, traut euch, das System runterzufahren. Es ist schön, dass die Webseite 100% Abtime hatte, aber wenn ihr gerade Kreditkartendaten verliert, ist das scheiß egal. Wenn die Webseite mal eine Stunde down ist, während ihr versucht, euren Security-Inzident zu lösen, ist es vollkommen egal, ob die Webseite down ist, Hauptsache die Daten sind sicher. Definiert im Vorfeld dafür klare Regeln, wie und wann was runterzufahren ist und dass die von eurem Management absägen. Er absägnet mich absägen. Es muss ganz klar definiert sein, wann ich das darf, vielleicht muss da auch erst noch jemand es freigeben, aber es muss jeder in der Lage sein, die Entscheidung zu treffen, irgendwas jetzt runterzufahren, um eine größere Gefahr abzuwägen. Gut, hat gebrannt, Inzident, wir kommen mal ein bisschen runter, schauen uns an, was wir machen, wenn es gebrannt hat. Fette Props an der Stelle, an Rembrandt, die Werke sind gemeinfrei, keine Lizenzkosten, geil. Und ich wollte schon immer mal barocke Kunst in einem Vortrag finden. Wie haben wir über Anatomie gelernt, das Menschen? Haben uns irgendwelche Dinge angeschaut, die kaputt gegangen sind und daraus sie analysiert und daraus gelernt. Das sind wir als Lader Menschen. Aber das Gleiche hilft eigentlich auch bei Inzidenz. So, ich mach mal den Kollegen da weg. Postmortems. Postmortems sind die nacht tägliche Analyse eines Inzidents. Wichtig, wenn ihr sowas macht, ist, seid zu 100% ehrlich zu euch selbst. Es bringt hier nichts zu lügen, sich irgendwie zu schüllen oder sonst immer, ihr müsst zu 100% ehrlich in der Geschichte sein. Schreibt in so einen Postmortem, es ist irgendein Textdokument rein. Was passiert es? Root-Course-Analyse. Wer irgendwie Eitel macht, verdreht jetzt wahrscheinlich gerade die Augen. Ich meine nicht diesen Eitel Bullshit, ich mein technisch ehrlich. Leute, was ist passiert, warum ist es soweit gekommen? Habt ihr Timelines von dem Inzident? Wann hat wer was gemacht? Wenn ihr davor schon ein Chat hat und alles ordentlich dokumentiert habt, ist das eigentlich nur Copy and Paste. Wie gesagt, seid ehrlich in diesem Inzident zu euch. Und seid auch im Zweifel mal positiv. Was lief denn gut in dem Inzident? Hatten wir unsere Kommunikation im Griff? Haben wir schnell gemerkt, was es ist und so weiter. Aber seid auch ehrlich zu euch, wenn es schlecht lief. Wir haben X übersehen, das Monitoring hat Y nicht gemonitort, deswegen haben wir es gar nicht mitgekriegt. Wir mussten warten, bis der Kunde uns anruf. Und schreibt doch auf, wo ihr Glück hattet. Keine Ahnung, irgendjemand hat durch Zufall den, was weiß ich, runtergefahren und deswegen ist ein Inzident nicht weitereskaliert. Dokumentiert diese Punkte und ganz wichtig, lernt daraus. Lernen daraus heißt Action Items in irgendeiner Form definieren. Das kann zum Beispiel den Ticket in eurem Ticketsystem sein oder einen Bugtracker usw. Legt für jedes Action Item ein Ticket an, kümmert euch darum, dass das abgearbeitet wird und dann sollte es in hoffentlich nicht mehr zu diesem Inzident kommen. Wenn ihr euch das mal beispielsweise anschauen möchte, das gibt von Google einen Standard Post-Mortem-Report, den sie gefüllt haben. Einfach Google und Post-Mortem suchen. Da seht ihr schon mal so ein Textdokument, wie das aussehen kann, dann müsste das Rad auch nicht noch mal neuer finden. Wichtig in der Geschichte ist auch bei dem 100 Prozent ehrlich zu ich sein. Seid auch komplett blameless bei der Geschichte. Niemand macht irgendetwas in so einem Inzident, weil er irgendwie ein schlechtes Interesse an sowas hatte oder weil er der Meinung war, hoch, ich fahr jetzt mal die Maisköl runter, das wollte ich schon immer mal machen. Selbst wenn jemand einen Fehler gemacht hat und es strunns doof war, ist es nicht sein Fehler, sondern es ist euer Fehler dass ihr nicht hingeschrieben habt in dem Runbook A-Bloß nicht da anfassen oder im Zweifel dass es überhaupt machen durfte. Seid komplett blameless. Wenn ihr das nicht schafft im ganzen Unternehmen durchzuziehen, ja, irgendein Manager möchte immer irgendwelche Köpfe rollen sehen, dann guckt zumindest, dass es in eurem Team hinkriegt und dass dieser Post-Mortem-Report dann im Zweifel nur geschwärzt rausgeht. Richtig bei der Geschichte ist auch kein Post-Mortem ohne Review. Setzt euch hin mit eurem Team nach so einem Inzident, wenn der Inz... wenn das Post-Mortem fertig geschrieben ist und redet darüber. Redet gemeinsam drüber, haben wir alle die gleiche Sicht davon, können wir den so gemeinsam verabschieden, wie du spiegelt das alles, was passiert ist. Und redet offen darüber. Auch mit anderen Teams Management. Klar, mich als Netzwerker ist es im Zweifel egal, wenn es im Rechenzentrum irgendeine Sicherung geflogen hat. Aber vielleicht kann ich daraus was für mich lernen. Vielleicht lerne ich aus dem kaskadierenden Fehler anderer, wie das im Zweifel auch mich betreffen könnte oder wie ich mich dagegen schützen könnte. Redet darüber, lest Inzident-Reports. Bei Google ist es zum Beispiel so, dass es regelmäßige Post-Mortem-Reading Groups gibt, das heißt jetzt nicht, dass ihr das direkt einführen müsst. Aber kümmert euch einfach mal ab und an darum, so ein Inzident-Report nochmal anzuschauen und vielleicht auch nochmal zu überlegen, hey, wie passt es denn auf die Arbeit, die ich jetzt gerade mache? Habe ich da vielleicht gerade wieder das Problem, dass sich was, was in dem Action-Item schon angesprochen wurde, gerade wieder genau gleich falsch machen? Ihr könnt unglaublich viel aus euren Fehlern lernen. So, so ein Post-Mortem hilft übrigens auch unglaublich, wenn ihr eben solche Inzident-Tests macht. Wenn ihr mal einen Inzident durchspielen wollt, dann habt ihr schon ein komplettes Runbook. Ihr müsst eigentlich nur noch vorlesen, was passiert ist, wer was macht und so weiter und habt die Arbeit nicht zweimal. Und Post-Mortem ist ein internes Dokument. Aber wir haben auch externe Dokumente. Reason for Outage. Eure Kunden wollen wissen, was passiert ist. Zum einen natürlich informiert eure Kunden. Wenn ihr Inzident vorbei ist, sagt okay, pass auf, wir haben das jetzt gelöst, das Problem ist beseitigt, es passiert jetzt hoffentlich nichts mehr. Und liefert dann irgendwann diesen Reason for Outage zu dem Inzident. Nach maximal einer Woche. Lügt niemals eure Kunden an. Ich habe einen Carrier, bei dem haben wir ungefähr 100 Leitungen und die waren in einer Nacht mal alle weg. Dann haben wir ein Monat lang auf diesen Inzident-Report gewartet und dann kam zurück, erinnert euch vielleicht noch an letztes Jahr. Ja, Stromausfall, Interaction Fra 5, war das Problem. Sorry, Stromausfall im ganzen Rechenzentrum können wir nichts dafür. Scheiß war, wir waren selber von dem Fra 5-Ausfall betroffen. Der war aber zwei Tage bevor die zwei RDS 100 Leitungen weggefallen sind. Wenn das wenn das jemand mitkriegt, dass ihr ihn angelogen habt, dann habt ihr ein richtiges Problem. Dann habt ihr einen Kunden verloren. Und das verzeiht euch niemand. Sei doch offen für Rückfragen von Kunden und beantworte diese. Ihr müsst da maximal Vertrauen bilden. Wenn da irgendwas kaputt gegangen ist, ist es scheiße. Gerade wenn ihr Infrastruktur an Bieter seid, kommt dahinter noch viel mehr Stack von Kunden, der im Endeffekt da auch noch von betroffen ist. Und ihr müsst da wieder das Vertrauen bilden, sonst habt ihr bald kein Kunden mehr. Gut. Summary. Ich bin dann wenig zu schnell. Aber egal. Vor dem Inzident. Überlegt euch, ob jeder Alarm so Sinn macht. Hatten wir vorhin schon mal. Will ich da für nachts um drei Wacht geknallt werden? Ist immer eine sehr gute Frage. Schreibt Runbooks. Definiert in der Kommunikations und der Collaboration Strategie. Also Chatrooms und so weiter. Baut euch Dashboards und Logging. Und damit kommt ihr weiter. Übt Inzidents üben, üben, üben. Und ganz wichtig von all dem Zeug da oben habt nen Backup. Während des Inzidents Don't Panic. Schritt zurückmachen. Nachdenken, was da los ist. Kommuniziert und collaboriert. Arbeitet gemeinsam. Arbeitet als Team. Informiert eure Kunden. Informiert euch intern. Dokumentiert jeden Schritt, den ihr gemacht habt. Hilft euch wie gesagt, wenn ihr im Zweifel irgendwelche Leute bei nem langen Inzident mit reinholen wollt. Und nach dem Inzident schreibt die Post Mortems und lernt daraus und schreibt ehrliche RFOs an eure Kunden. Wie das ganze Thema interessiert, das hat sich in den letzten Jahren so ne kleine Bewegung darum gebildet ausgehend von nem Buch von Google. Side to Liability Engineering, How Google Runs Production Systems. Könnt ihr unter dem ersten Link lesen. Komplett kostenlos. Ihr könnt's natürlich auch als Reilly-Buch kaufen. Darin sind viele der Gedanken schonmal beschrieben. Auch einiges an technischen Implementierungsdetails auch so ein bisschen wie man das, wie Google das wirklich macht, ja, die haben im Endeffekt DevOps noch mal ein bisschen aufgeräumt. Schaut euch zum Beispiel vom Department of Homeland Security des Incident Management System an. Oder irgendein anderes, ja, auch in Eitel steckt ein bisschen Wahrheit. Das heißt ja nicht, dass ihr diesen ganzen Riesenratten-Schwanz dahinter implementieren müsst. Aber ein paar Sachen davon sind gut bewertet einfach für euch. Macht das jetzt Sinn für mich oder nicht? Lest Post Mortems und lernt aus den Fehlern von anderen. Es gibt ne Veröffentlichung, wie heißt SRE Weekly. Da veröffentlichen im Endeffekt einige Leute ihre RFOs. Und es gibt dieses unglaublich tolle Github-Repo. Da könnt ihr lernen, wie Github explodiert ist, wie irgendwelche CDNs explodiert sind, und so weiter, und wie die Leute es gelöst haben. Es gibt auch spannende Geschichten, wie Google es mal geschafft hat, weil sie irgendwo ne Null reingeschrieben haben, alle ihre CDNs zu löschen. Ja, sowas ist scheiße. Aber es ist dann spannend zu lesen, wie haben es die Leute geschafft, da wieder rauszukommen. Hatten sie ihre ganzen Prozesse hinten ran im Griff? Und wie leben sie jetzt wieder? Es geht noch das Buch Seeking SRE, da erzählen Google wie der Film wie Google Netflix und Co. von ihren Herausforderungen und Lösungen mit dem ganzen Thema. Und wie sie auch technische Sachen implementieren davon. Und wenn ihr mehr die Videoleute seid, es gibt die SRE Kornen, die gibt es einmal in Amerika, einmal Asia Pacific, und einmal Europe Middle East Asia. Da gibt es hunderte Stunden an guten Videos. Die alle Themen, die ich gerade eben angesprochen hab, nochmal im Detail besprechen. So, das war's auch schon. Hat jemand Fragen? Erst mal danke an Momo. Und wenn ihr Fragen habt, zeigt auf, ich komme da mit dem Mikrofon zu euch und dann könnt ihr die Fragen stellen. Ich hätte gern einen Gruß, wie du zu mehrstufigen Sevirities stehst bei Alarmen. Also so Vorwarnungen oder unterschiedliche Sevirities fürs Gleiche. So Sachen wie Info. So ein Infoalarm finde ich schwachsinnig. Aber wenn jetzt die erste Threshold geschmissen wurde, dann ist es auf jeden Fall mal was, wo man den Warningalarm, sag ich mal, Leuten schicken kann. Keine Ahnung, so, hey, das sieht gerade kritisch aus, das könnte schlimmer werden. Dafür würde ich niemand wach klingeln. Aber wenn nicht zum Beispiel so was wie ein 247 Knock Up oder ein Engineer, der eh gerade am Rechner ist, dann würde ich den auf jeden Fall drauf schauen lassen. Aber ich würde dafür nicht alarmieren. Du hattest ja vorhin das Beispiel bezüglich flachen Schwellwerten gegenüber Wachstumsschwellwerten. Letzten Endes, was du ja bei beiden aus zufälligen Grenzwertüberschreitungen rausgeklingelt, dann macht halt irgendeinen Logging-Deam in der letzten Stunde. Hat man irgendeinen Brutforce gehabt, hat dann geendet, wurde gehe vom irgendeinem, jetzt sitzt in der Bloglist, gleichzeitig was rausgeklingelt. Letzten Endes, aus meiner Sicht musst du beides immer kombinieren, Schwellwerte und Grenzwerte. Ganz klar, bin ich bei dir. Das Wichtig ist einfach nur, dass wir uns darüber Gedanken machen, was da passiert. Und es war jetzt ganz klar nur ein theoretisches Beispiel. Du musst es immer auf deine Applikation beziehen und gucken, ob diese Alarm für mich in diesem Use-Case sindmacht oder nicht. Moin. Die meisten Monitoring-Systeme bieten ja auch Berichtsfunktion an, dass man in regelmäßigen Zyklen Informationen über sein System bekommt. Werden die so in deine Erfahrung regelmäßig genutzt oder ungesehen gelöscht? Ja, gute Frage. Ich habe die Pflicht, das zu tun, weil unsere Kunden SLR-Reports fordern und das auch vertraglich zugesichert haben. Dementsprechend, klar werden die genutzt. Es hilft auch, unglaublich einfach mal zu wissen, was denn überhaupt los ist. Als wir das angefangen haben, wir haben viel Abteilung bei uns Unternehmen, die Bereitschaft machen und unser Management wusste gar nicht, wie viele Insidenz da die Leute abkriegen. Ich habe dann mal angefangen zu reporten, pass auf, jede Woche einfach in dem weekly show fix mit unserem Management zu erzählen, wie viele Insidenz da eigentlich sind und das hilft, im Zweifel auch immer zu merken, oh scheiße, die Leute werden fast jede Nacht wachgeklingelt. Vielleicht braucht man ja mehr Kapazität, vielleicht muss man die Leute besser entlohnen und so weiter. Aber ganz klar so, incident reports, erquatsch so, nenn es mal SLR-Reports, sind wichtig. Was mich mal interessieren würde, gibt es irgendwie, also wir stellen gerade ein bisschen Monitoring um, vielen in Richtung Prometheus und wir haben halt sehr, sehr viele Altersmonitoring und da so Tonnenweise an Checks, die mehr oder minder sinnvoll sind. Und man stellt sich dann nur die Frage, wieviel von denen portiere ich denn, wie lang las ich das Alterssystem parallel laufen. Gibt es da irgendwie so Guidelines oder auch so Sammelstellen online, wo halt Leute, alertingen Regeln, die im Groben als sinnvoll erachtet werden, mal sammeln. Weil im Endeffekt hat man halt oft viele ähnliche Systeme klar, hast du spezielle Sachen, die jetzt nur für dich sind, du hast Anwendung x y, aber jeder hat halt Tonnenweise Dienungsserver, die jetzt alle ähnliches Monitoring brauchen. Das ist eine sehr gute Frage und tatsächlich hast du mich gerade zu dem Projekt, auf dem ich an der GPN arbeite, gebracht. Ich schreibe gerade ein System eben für Prometheus, wo du pro Exporter Alarme rein schmeißen kannst, die dann hoch und runter wurden, eben weil ich auch der Meinung bin, dass wir nicht alle das Rad regelmäßig neu erfinden müssen. Aber meines Wissens gibt es dazu nichts. Vielleicht noch ganz kurz, willst du kurz sagen, wo man das dann vielleicht finden wird oder wie man da mitmachen kann? Folgt mir auf Twitter, ich habe heute das Django-Projekt gestartet, so weit bin ich noch nicht. Ich habe eine Idee. Aber cool. So, weitere Fragen? Ich sehe jetzt keine mehr. Wo muss ich denn noch fragen? Nee, ich sehe auch nichts. Dann danke euch ganz herzlich. Ich ziehe mal noch ganz kurz mein Netzwerkerhut auf. Im November gibt es in Hamburg, verzeihend mit den umgezogen, die Dienog 11 kommt gerne vorbei. Und ansonsten danke euch.