Schließen

Atlassian-Handbuch für Vorfälle

Definition von Vorfällen und zugehörigen Werten; Erläuterung der verwendeten Tools und Teamrollen

Incident Management home

Reaktion auf einen Vorfall

In den folgenden Abschnitten wird der Atlassian-Prozess zur Reaktion auf Vorfälle beschrieben. Der Vorfallsmanager (Incident Manager, IM) führt eine Reihe von Schritten durch, um den Vorfall von der Erkennung bis zur Lösung zu führen.

Incident response workflow

Erkennen

People at your company can become aware of incidents in many ways. They can be alerted by monitoring, through customer reports, or by observing it themselves. However an incident occurs, the first step the team takes is logging an incident ticket (in our case, a Jira issue). 

Wir nutzen eine leicht zu merkende kurze URL, mit der die Atlassians an ein internes Jira Service Desk-Portal weitergeleitet werden. Um zu prüfen, ob bereits ein Vorfall läuft, können die Atlassians ein Jira-Dashboard oder ein Jira-Makro in Confluence zu Rate ziehen. Teams wie unsere Kundensupportteams haben an bekannten Orten Dashboards zur Überwachung laufender Vorfälle eingerichtet.

Wir füllen folgende Felder für jeden Vorfall aus:

Jira-Feld Typ Hilfetext
Summary Text

What's the emergency?

Description Text

What's the impact on customers? Include your contact details so responders can reach you

Schweregrad Einzelauswahl

(Hyperlink zu einer Confluence-Seite mit unserer Schweregradskala) Wenn du Schweregrad 1 oder 2 auswählst, muss das Problem deiner Meinung nach sofort behoben werden. Die Zuständigen werden direkt benachrichtigt.

Fehlerhafter Service Einzelauswahl

Der Service, in dem der Fehler vorliegt, der den Vorfall verursacht hat. Wenn du dir nicht sicher bist, gib eine Vermutung an. Falls du gar keine Ahnung hast, wähle "Unbekannt" aus.

Betroffene Produkte Kontrollkästchen Which products are affected by the incident? Select any that apply

Sobald der Vorfall erstellt wurde, verwenden wir den entsprechenden Issue-Schlüssel in der gesamten internen Kommunikation zum Vorfall.

Oft erstellen Kunden ein Supportticket zu Vorfällen, von denen sie betroffen sind. Wenn unsere Kundensupportteams zu dem Schluss kommen, dass sich alle diese Tickets auf denselben Vorfall beziehen, kennzeichnen sie diese Tickets mit dem Issue-Schlüssel des Vorfalls, um die Auswirkungen auf die Kunden zu verfolgen und sich nach der Erledigung des Vorfalls leichter an die betroffenen Kunden wenden zu können.


Bekanntmachung eines neuen Vorfalls

Wenn ein Vorfalls-Issue erstellt, aber noch keinem Vorfallsmanager (Incident Manager, IM) zugewiesen wurde, hat der Vorfall den Status Neu. Dies ist der Anfangsstatus in unserem Jira-Workflow für Vorfälle.

Wir haben einen Service, der anhand von Jira-Webhooks eine Seitenwarnung auslöst, sobald ein neuer größerer Vorfall erstellt wird. Auf diese Weise wird je nach ausgewähltem Service der zuständige IM benachrichtigt. Wenn beispielsweise ein Vorfall bei Bitbucket vorliegt, wird ein Bitbucket-IM benachrichtigt. Zusätzlich pflegen wir einen globalen universellen Dienstplan der für größere Vorfälle zuständigen IMs. Diese werden bei uns als "Incident Manager on Call" (IMOC, zuständiger Vorfallsmanager) bezeichnet.

Die Seitenwarnung enthält den Issue-Schlüssel, den Schweregrad und eine Zusammenfassung des Vorfalls, damit der IM weiß, wo er mit dem Management des Vorfalls beginnen soll (Jira-Issue), worin das Problem besteht und wie schwerwiegend es ist.


Eröffnung der Kommunikation

Wenn der IM online geht, weist er sich zunächst das Vorfalls-Issue selbst zu und ändert den Status in Behebung. Auch aus dem Jira-Issue-Feld "zugewiesen zu" geht hervor, wer der aktuelle IM ist. Bei einer Notfallreaktion ist es sehr wichtig, dass die Zuständigkeiten klar sind. Aus diesem Grund achten wir sehr darauf, dieses Feld richtig auszufüllen. 

Als Nächstes richtet der IM die Kommunikationskanäle des für den Vorfall zuständigen Teams ein. Die gesamte Kommunikation des Teams sollte unter bekannten Anlaufstellen zugänglich und weitgehend zentralisiert sein. Normalerweise nutzen wir drei Methoden zur Kommunikation im Team, für die im Jira-Issue zum Vorfall jeweils ein Feld vorhanden ist:

  • Chatraum in Slack oder einem anderen Messaging-Service. Hier kann das Team kommunizieren sowie Beobachtungen, Links und Screenshots teilen. Die Kommunikation wird mit Zeitstempeln versehen und gespeichert. Da der Name des Chatkanals dem Issue-Schlüssel entspricht (z. B. "HOT-1234"), ist der Chatraum für neu zur Kommunikation hinzukommende Verantwortliche leichter zu finden. 
  • Videochat in einer Konferenzlösung wie Skype oder BlueJeans. Wenn sich alle Beteiligten am selben Ort befinden, kannst du das Team auch zu einem persönlichen Treffen zusammenrufen. Diese persönliche Kommunikation beschleunigt und vereinfacht die Entscheidungsfindung im Team.
  • Eine Confluence-Seite, auf der der Status des Vorfalls dokumentiert wird. Wenn mehrere Personen gleichzeitig dieselbe Seite bearbeiten, können sie in Echtzeit sehen, welche Informationen zusammengetragen werden. Dies ist eine gute Möglichkeit zum Verfolgen von Änderungen (beispielsweise in Form einer Tabelle, der zu entnehmen ist, wer wann was wie und warum geändert hat, wie die Änderung rückgängig gemacht werden kann etc.), mehreren Arbeitsabläufen oder einem längeren zeitlichen Ablauf. Ein solches Dokument zum Status des Vorfalls spielt bei komplexen oder langwierigen Vorfällen eine wichtige Rolle als zentrale Informationsquelle.

Wir haben die Erfahrung gemacht, dass eine Kombination aus Videochat und Chatraum bei Vorfällen am besten funktioniert, da diese beiden Kommunikationskanäle für unterschiedliche Aspekte optimiert sind. Videochats lassen durch die Gruppendiskussion schnell ein geistiges Bild des Vorfalls entstehen, während sich ein Textchat gut zur Aufzeichnung des Vorfalls mit Zeitstempeln, geteilten Links zu Dashboards, Screenshots und anderen URLs eignet.

Mit diesen Methoden können Teams auch wichtige Beobachtungen, Änderungen und Entscheidungen aus nicht aufgezeichneten Unterhaltungen festhalten. Der IM oder ein anderes Mitglied des für den Vorfall zuständigen Teams muss dazu lediglich die in Echtzeit ablaufenden Beobachtungen, Änderungen und Entscheidungen im dedizierten Chatraum notieren. Es macht nichts, wenn es aussieht, als würde derjenige Selbstgespräche führen. Diese Notizen sind bei der Nachbereitung sehr wertvoll, wenn die Teams den zeitlichen Ablauf des Vorfalls und seine Ursachen nachvollziehen müssen. 

Bei den meisten Chatsystemen gibt es ein Feature für ein Raumthema. Der IM aktualisiert dieses Raumthema mit Informationen zum Vorfall und mit hilfreichen Links. Beispiele:

  • Zusammenfassung und Schweregrad des Vorfalls
  • Rollen und zugewiesene Personen (zuallererst der IM)
  • Links zum Vorfalls-Issue, zum Videochatraum und zum Dokument mit dem Status des Vorfalls

So kann jeder, der über den Issue-Schlüssel des Vorfalls verfügt, dem Chat beitreten und sich schnell auf den neuesten Stand bringen. (Zur Erinnerung: Wir benennen den Chatkanal nach dem Issue-Schlüssel des Vorfalls, z. B. "HOT-1234".)

Finally, the IM sets their own personal chat status to the issue key of the incident they are managing. This lets their colleagues know that they're busy managing an incident. 


Bewertung

Wenn die Kommunikationskanäle des für den Vorfall zuständigen Teams fertig eingerichtet sind, wird es Zeit für die Bewertung des Vorfalls. So kann das Team entscheiden, welche Informationen zum Vorfall geteilt werden sollen und wer für die Problembehebung zuständig ist. 

Bei uns stellen die IMs ihren Teams folgende Fragen: 

  • Welche Auswirkungen hat der Vorfall auf die (internen oder externen) Kunden?
  • Was sehen die Kunden?
  • Wie viele Kunden sind betroffen (nur einige oder alle)?
  • Wann hat der Vorfall begonnen?
  • Wie viele Supporttickets wurden von Kunden erstellt?
  • Sind weitere Faktoren zu beachten, z. B. Twitter, Sicherheit oder Datenverluste?

An diesem Punkt bietet es sich an, mit dem Nachzeichnen des zeitlichen Ablaufs des Vorfalls zu beginnen. Halte die Beobachtungen des Teams fest, damit neu hinzukommende Personen schnell alles nachlesen können. Dieser Schritt ist auch für die spätere Nachbereitung wichtig. Notiere auch, ob der Beginn des Vorfalls mit einer Änderung (z. B. mit einem Bamboo-Deployment) zusammenfiel. In diesem Fall kann das Problem möglicherweise durch ein Rollback der Änderung gelöst werden.

Anhand der Auswirkungen des Vorfalls und des von unseren Teams geschätzten Arbeitsaufwands für die Erledigung weisen wir Issues mit einem der folgenden Schweregrade zu: 

Schweregrad Description Examples
1 Ein kritischer Vorfall mit sehr großen Auswirkungen
  • Ein von Kunden genutzter Service, beispielsweise Jira Cloud, ist für alle Kunden ausgefallen.
  • Die Vertraulichkeit oder Datensicherheit wurde verletzt.
  • Kundendaten sind verloren gegangen.
2 Ein größerer Vorfall mit bedeutenden Auswirkungen
  • Ein von Kunden genutzter Service ist für bestimmte Kunden nicht verfügbar.
  • Kernfunktionen (z. B. "git push", Erstellen von Issues) sind erheblich beeinträchtigt.
3 Ein kleinerer Vorfall mit geringen Auswirkungen
  • Eine kleinere Unannehmlichkeit für Kunden; ein Workaround ist vorhanden.
  • Die nutzbare Leistung hat abgenommen.

Nachdem die Auswirkungen des Vorfalls geklärt sind, solltest du den Schweregrad des Vorfalls-Issues anpassen oder bestätigen und ihn dem Team mitteilen. Unserer Erfahrung nach ist es für eine klare Kommunikation sehr hilfreich, den Schweregrad konkret zu beziffern.

Bei Atlassian werden Vorfälle mit Schweregrad 3 an die Bereitstellungsteams weitergeleitet, die das Problem dann innerhalb der Geschäftszeiten beheben. Bei Schweregrad 1 und 2 hingegen werden die Teammitglieder direkt benachrichtigt, damit sie sofort mit der Problembehebung beginnen können. Die Unterschiede in der Reaktion auf Schweregrad 1 und Schweregrad 2 sind gering und richten sich nach dem betroffenen Service.

Für eine konsistente Reaktion auf Vorfälle je nach Auswirkung auf die Kunden sollte eine Matrix der Schweregrade erstellt und mit allen Teams abgestimmt werden.


Versenden der ersten Kommentare

Wenn du zu dem Schluss gekommen bist, dass höchstwahrscheinlich tatsächlich ein Vorfall vorliegt, solltest du alle internen und externen Beteiligten so schnell wie möglich informieren. Ziel der anfänglichen internen Kommunikation ist es, die Reaktion auf den Vorfall zu zentralisieren und für eine klare Informationslage zu sorgen. Bei der externen Kommunikation geht es darum, die Kunden wissen zu lassen, dass du über das Problem informiert bist und dass bereits mit Hochdruck daran gearbeitet wird. Eine schnelle und genaue Kommunikation über Vorfälle stärkt das Vertrauen von Mitarbeitern und Kunden.

Wir nutzen Statuspage für die interne und externe Kommunikation über Vorfälle. Für interne Mitarbeiter und externe Kunden pflegen wir separate Statusseiten. Später gehen wir näher auf die Verwendung der beiden Seiten ein. Jetzt müssen die Kommunikationskanäle erst einmal so schnell wie möglich eingerichtet werden. Dafür nutzen wir diese Vorlagen:

  Interne Statusseite External Status page
Bezeichnung des Vorfalls

<Issue-Schlüssel des Vorfalls> – <Schweregrad> – <Zusammenfassung des Vorfalls>

Untersuchung eines Vorfalls bei <Produkt>

Nachricht Wir untersuchen derzeit einen Vorfall, der <Produkt X>, <Produkt Y> und <Produkt Z> betrifft. In Kürze veröffentlichen wir aktuelle Informationen per E-Mail und auf der Statusseite.

Wir untersuchen derzeit Probleme bei <Produkt> und werden hier in Kürze aktuelle Informationen zur Verfügung stellen.

Zusätzlich zur Erstellung einer Statusseite für den Vorfall senden wir eine E-Mail an eine Verteilerliste für die Vorfallskommunikation, in der die Leiter unserer Entwicklungsteams, die für größere Vorfälle zuständigen Manager und andere interessierte Mitarbeiter enthalten sind. Diese E-Mail hat denselben Inhalt wie die interne Statusseite zum Vorfall. Auf E-Mails können Mitarbeiter antworten, wenn sie Fragen haben, während sich Statuspage eher für die unidirektionale Kommunikation eignet.

Tipp: Wir achten darauf, dass alle internen Mitteilungen über den Vorfall den Jira-Issue-Schlüssel des Vorfalls beinhalten, damit die Mitarbeiter wissen, in welchem Chatraum sie weitere Fragen stellen können.


Eskalation

Du hast das Management des Vorfalls übernommen, die Teamkommunikation eingerichtet, die Situation bewertet und deine Mitarbeiter und Kunden über den Vorfall informiert. Was kommt als Nächstes?

Vielleicht hast du mit deiner ersten Anfrage schon alle Personen erreicht, die zur Erledigung des Vorfalls benötigt werden. In den meisten Fällen musst du jedoch weitere Teams hinzuziehen und sie dazu direkt benachrichtigen. Dies bezeichnen wir als Eskalation.

Das wichtigste System für diesen Schritt ist ein Tool für Dienstpläne und Benachrichtigungen wie OpsGenie. Mit OpsGenie und ähnlichen Systemen kannst du Dienstpläne mit den jeweiligen Zuständigkeiten erstellen, sodass im Notfall in jedem Team ein zuständiger Mitarbeiter erreichbar ist. Diese Methode ist besser, als wenn immer nur bestimmte Mitarbeiter kontaktiert werden ("Ruf doch noch mal Bob an!") – schließlich können diese Kollegen nicht ständig zur Stelle sein (Urlaub, Jobwechsel, Überlastung durch zu viele Anrufe). Sie ist auch besser, als spontan den gerade am besten geeigneten Kollegen auszuwählen, weil die Zuständigkeiten klar definiert sind.

Wenn du eine Benachrichtigung zum Vorfall versendest, gib immer auch den Jira-Issue-Schlüssel des Vorfalls an. Mit diesem Schlüssel kann der Empfänger der Benachrichtigung den Chatraum zum Vorfall betreten.


Delegierung

Nachdem die Eskalation erfolgt ist und der kontaktierte Mitarbeiter sich dem Team angeschlossen hat, muss der IM dem Mitarbeiter eine Rolle delegieren. Wenn der Mitarbeiter weiß, was von seiner Rolle erwartet wird, kann er als Mitglied des für den Vorfall zuständigen Teams schnell und effektiv arbeiten.

Bei Atlassian nutzen wir folgende Rollen:

  • Incident Manager, described in the Overview page.
  • Technischer Leiter – ein für die Reaktion zuständiger erfahrener technischer Mitarbeiter. Er ist dafür zuständig, Theorien über das Problem und seine Ursache zu entwickeln, über Änderungen zu entscheiden und das technische Team zu leiten. Er arbeitet eng mit dem IM zusammen.
  • Kommunikationsmanager – ein Mitarbeiter, der sich mit der öffentlichen Kommunikation auskennt, beispielsweise ein Vertreter des Kundensupportteams oder der PR-Abteilung. Er ist dafür zuständig, interne und externe Mitteilungen über den Vorfall zu verfassen und zu versenden.

Wir notieren im Thema des Chatraums, wer gerade welche Rolle bekleidet, und aktualisieren diese Zuordnung bei Rollenwechseln während eines Vorfalls.

Der IM kann je nach Anforderungen des Vorfalls auch Rollen neu erstellen und delegieren. So können beispielsweise mehrere technische Leiter erforderlich sein, wenn es mehrere parallele Arbeitsabläufe gibt. Auch eine Aufteilung der Rolle des Kommunikationsmanagers in einen internen und einen externen Vertreter ist möglich.

Bei komplexen oder großen Vorfällen ist es ratsam, einen weiteren qualifizierten IM zur Entlastung und Absicherung des eigentlichen IM hinzuzuziehen. Dieser zweite IM kann bestimmte Aufgaben übernehmen, um den IM zu unterstützen. Beispielsweise kann er die Aufzeichnungen zum zeitlichen Ablauf des Vorfalls pflegen.


Versenden der Nachbereitungskommentare

Nachdem du die anfänglichen Mitteilungen versendet hast und das für den Vorfall zuständige Team seine Arbeit aufgenommen hat, musst du Mitarbeiter und Kunden weiterhin über den Vorfall auf dem Laufenden halten.

Aktualisierte Informationen sind für die Mitarbeiter wichtig, weil so jeder hinsichtlich des Vorfalls auf demselben Wissensstand ist. Bei neu auftretenden Problemen sind vor allem in den Anfangsphasen nur wenige Informationen verfügbar. Wenn du keine zuverlässige Anlaufstelle für Informationen über den Vorfall und die Reaktion darauf einrichtest, ziehen andere schnell ihre eigenen Schlüsse. 

Bei der internen Kommunikation halten wir uns an folgendes Muster:

  • Wir kommunizieren über unsere interne Statusseite und per E-Mail (wie oben in Bezug auf die anfängliche Kommunikation beschrieben).
  • Wir nutzen dieselbe Benennungskonvention für die Bezeichnung des Vorfalls und die Formatierung des E-Mail-Betreffs (<Issue-Schlüssel des Vorfalls> – <Schweregrad> – <Zusammenfassung des Vorfalls>).
  • An den Anfang stellen wir eine Zusammenfassung des aktuellen Status und der Auswirkungen (ein bis zwei Sätze).
  • Es folgt ein Abschnitt zum aktuellen Status mit zwei bis vier Stichpunkten.
  • Darauf folgt ein Abschnitt zu den nächsten Schritten mit zwei bis vier Stichpunkten.
  • Wir kündigen an, wann und wie die nächsten Mitteilungen veröffentlicht werden.

Anhand folgender Checkliste prüfen wir unsere Mitteilungen auf Vollständigkeit: 

  • Welche Auswirkungen hat der Vorfall auf die Kunden?
  • Wie viele interne und externe Kunden sind betroffen?
  • Welche grundlegende Ursache hat der Vorfall (sofern bekannt)?
  • Wann wird die Wiederherstellung voraussichtlich abgeschlossen sein?
  • Wann und wie werden die nächsten Mitteilungen veröffentlicht?

Wir ermutigen unsere IMs, es bei der internen Kommunikation ehrlich zuzugeben, wenn etwas noch nicht bekannt ist. Dies verringert Unsicherheiten. Wenn beispielsweise die grundlegende Ursache des Vorfalls unbekannt ist, sollen sie dies offen kommunizieren, statt das Thema einfach zu verschweigen.

Auch Mitteilungen an externe Kunden sind wichtig, weil sie das Vertrauen fördern. Betroffene Kunden können sich anderen Dingen widmen, wenn sie wissen, dass du sie auf dem Laufenden hältst.

Für die externe Kommunikation aktualisieren wir einfach die zuvor erstellte externe Statusseite zum Vorfall und ändern den Status bei Bedarf. Wir versuchen, Aktualisierungen möglichst kurz zu halten, weil sich externe Kunden nicht für die technischen Details des Vorfalls interessieren. Sie möchten nur wissen, ob das Problem behoben wurde bzw. wann mit der Behebung zu rechnen ist. In der Regel sind ein bis zwei Sätze völlig ausreichend.

Die Kommunikation bei Vorfällen ist eine Kunst. Je mehr du übst, umso besser wirst du darin. In unserem Training für IMs führen wir ein Rollenspiel zu einem hypothetischen Vorfall durch, entwerfen dazu passende Mitteilungen und lesen sie den anderen Kursteilnehmern vor. Auf diese Weise können angehende IMs diesen Ablauf üben, bevor sie ihn in der Praxis umsetzen müssen. Es kann auch nie schaden, Mitteilungen noch einmal von einer anderen Person lesen zu lassen (Zweitmeinung), bevor du sie versendest.


Überprüfen

Es gibt keinen universell gültigen Prozess zur Erledigung aller Vorfälle. Wenn es so wäre, könnten wir ihn einfach automatisieren und hätten unsere Ruhe. Stattdessen iterieren wir den folgenden Prozess, um ihn schnell an verschiedene Szenarien zur Reaktion auf Vorfälle anzupassen: 

  • Beobachte, was gerade geschieht. Teile deine Beobachtungen mit, und lasse sie dir bestätigen.
  • Entwickle Theorien über die mögliche Ursache des Geschehens. 
  • Entwickle Experimente, um diese Theorien zu belegen oder zu widerlegen. Führe sie durch.
  • Wiederhole die oben genannten Schritte.

Beispiel: Du beobachtest eine hohe Fehlerquote bei einem Service, die gleichzeitig mit einem von deinem regionalen Infrastrukturanbieter auf seiner Statusseite veröffentlichten Fehler auftritt. Du entwickelst die Theorie, dass dieser Fehler regional begrenzt ist, entscheidest dich für ein Failover auf eine andere Region und beobachtest die Ergebnisse.

Die größte Herausforderung für den IM besteht an diesem Punkt darin, die Disziplin des Teams aufrechtzuerhalten:

  • Kommuniziert das Team effektiv?
  • Welche Beobachtungen, Theorien und Arbeitsabläufe stehen derzeit im Raum?
  • Werden Entscheidungen effektiv getroffen?
  • Geht das Team bei Änderungen gezielt und umsichtig vor? Ist bekannt, welche Änderungen vorgenommen werden?  
  • Sind die Rollen klar verteilt? Kommen die Teammitglieder ihren Aufgaben nach? Müssen wir an weitere Teams eskalieren?

In jedem Fall gilt: Nur keine Panik! Sie blockiert dich nur. Bleibe ruhig und sei dem Rest des Teams damit ein gutes Beispiel.

Der IM muss auf Ermüdungserscheinungen des Teams achten. Treten diese auf, muss er eine Teamübergabe planen. Ein dediziertes Team läuft beim Behandeln komplexer Vorfälle Gefahr, auszubrennen. IMs sollten daher darauf achten, wie lange die Teammitglieder schon wach sind und seit wann sie an dem Vorfall arbeiten. Bei Bedarf müssen sie entscheiden, wer die jeweilige Rolle als Nächstes übernimmt.


Erledigen

An incident is resolved when the current or imminent business impact has ended. At that point, the emergency response ends and the team transitions onto any cleanup tasks and the postmortem.

Bereinigungsaufgaben können leicht als vom Jira-Issue des Vorfalls ausgehende Issue-Verlinkungen verfolgt werden.

Wir bei Atlassian verfolgen mit benutzerdefinierten Jira-Feldern, wann die Auswirkungen eines Vorfalls begonnen haben, wann sie erkannt wurden und wann sie beseitigt wurden. Anhand dieser Felder berechnen wir die Wiederherstellungszeit (Time to Recovery, TTR), d. h. den Zeitraum zwischen Anfang und Ende, und die Erkennungszeit (Time to Detect, TTD), d. h. den Zeitraum zwischen Anfang und Erkennung. Die Verteilung von TTD und TTR bei Vorfällen ist oft eine wichtige Geschäftsmetrik.

Wir versenden abschließende interne und externe Mitteilungen, wenn der Vorfall erledigt wurde. Die internen Informationen enthalten einen Überblick über die Auswirkungen und die Dauer des Vorfalls, Angaben zur Anzahl der erstellten Supporttickets und weitere wichtige Zahlen zum Vorfall. Außerdem wird darin klar festgehalten, dass der Vorfall erledigt ist und es keine weiteren Mitteilungen dazu geben wird. Die externen Informationen sind in der Regel kurz gehalten. Den Kunden wird mitgeteilt, dass der Service wiederhergestellt wurde und dass wir uns nun um die Nachbereitung kümmern.