AWS OpsCenter - Ticket as a Service

This content is more than 4 years old and the cloud moves fast so some information may be slightly out of date.



Ticket as a Service

Ops Center - erste Erfahrungen

Was ist das Ops Center

AWS hat jetzt sein eigenes Ticketsystem. Aber - sorry - das Ticket heißt hier OpsItem, damit auch keine Verwechselung aufkommt. Damit kann man jetzt nicht sein Jira wegschmeißen - es ist aber gut geeignet, um Störungen direkt in der AWS Console zu bearbeiten. Hier erste Erfahrung damit.

Zentrale Einheit ist das OpsItem. Von hier aus bearbeitet man die Störung. Dazu kam man das OpsItem mit den dazugehörigen AWS Ressourcen verknüpfen, oder auch (Störungs) Ereignisse aus AWS direkt in ein Ticket verwandeln.

Und mit einer SNS Benachrichtung kann man auch einfach die Ticketänderungen an andere Systeme weiterleiten, z.B. über eine Emailschnistelle.

Und auch andere bereits bestehende Tools von AWS wurden integrierrt, siehe hierzu die Dokumentation: AWS Systems Manager – Funktionen – Amazon Web Services (AWS)

Was für ein Full-Size Ticketsystem fehlt, wäre z.B. eine Verlaufshistorie und die Möglichkeit Bemerkungen für einzelne Bearbeitungsschritte zu hinterlegen. OpsCenter konzentriert sich aber mit dem Status - also “Offen” - “in Arbeit” - “Gelöst” auf die Funktion eine zentrale Stelle zu sein, von der aus die Störungen bearbeitet werden. Es geht also in ITIL Sprache rein um Incident Management. Für den Verlauf verweist AWS wie so oft auf CloudTrail.

Strukturübersicht

Als zentrales Element kann direkt am OpsItem jeweils die ARN von verbundenen Ressourcen eingetragen werden.

Struktur

Ein Durchlauf

Installation

Wie komme ich überhaupt zum OpsCenter? Zusammen mit anderen Ops Tools ist es in der “AWS Systems Manager” Seite verfügbar.

Ja, wie jeder Service wird erst einmal eine Rolle benötigt. Die habe ich als CloudFormation òpscenter.template in unserem Repository hier hinterlegt. Einfach als CloudFormation Stack einspielen.

Oder eine Rolle mit der folgenden Policy erstellen:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ssm:CreateOpsItem",
            "Resource": "*"
        }
    ]
}

Mit dieser Rolle - das ist die, deren Namen mit “OpsCenterRole” beginnt, startet man nach dem Einspielen des CloudFormation stacks oder dem manuellen Erstellen der Rolle die Erstellung von CloudWatch Regeln.

9a00b790.png

Hier die entstandenen Regeln:

c3e7f6b3.png

Hello OpsItem

32754767.png

Mit CreateOpsItem erstelle ich ein Ticket. Leider - oder zum Glück - gibt es noch keine deutsche Übersetzung. Der Service selber ist aber von Anfang an in Frankfurt verfügbar.

d6345e68.png

Die Felder für das OpsItem sind wenig überraschend. Eine aus der Erfahrung mit Tickets sinnvolle Funktion ist die “DeDuplizierung”. Mit einem möglichst eindeutigem String wird gesucht, ob bereits andere OpsItems zum selben Thema vorhanden sind. Damit soll die Duplizierung, also mehrere Tickets zu einem Incident (Störungsvorfall) vermindert werden.

Jetzt kommt die Funktion, die den eigentlichen Mehrwert bietet - die Verknüpfung mit AWS Ressourcen. So kann ich auch sehen, ob eine Ressource mehrere Probleme hat und damit eine Root Cause Analysis druchführen. Das bedeutet, dass ich versuche dem eigentlichen Problem auf den Grund zu gehen.

08372a5a.png

Dann kann es nach dem Erstellen eines Tickets etwas dauern (gefühlt so 1/2 Minute), bis das Ticket auftaucht. Das und meine Ungeduld ist auch der Grund, warum in den folgenden Bildern zwei identische Tickets vorhanden sind…

5f061f89.png

In diser sinnvoll gestalteten Übersicht sehe ich die Tickets gruppiert nach Quelle and Liegedauer.

Jetzt kann ich noch ein SNS Topic hinterlegen um benachrichtigt zu werden, wenn sich ein OpsItem ändert.

e27d3c15.png

Als Zusatzinfo kann ich 20Kb als “OperationalData” hinterlegen. Z.b. Konfigurationen, Protokolldateien… ea974e38.png

In Progress…

977928a8.png

Während der Bearbeitung bin ich es von Jira & Co. gewohnt, die Bearbeitungsschritte zu dokumentieren. Das ist hier in OpsCenter nicht möglich, es soll eine Ergänzung zu den großen Systemen sein.

Natürlich kann man kurze Texte auch in dem operational data hinterlegen: 2064f9d9.png

Und tatsächlich sehe ich in dieser Beschränkung eine Stärke! Kurze Notizen sind möglich und mehr Dokumentation bringt mich ja der Problemlösung nur bedingt näher. e6edf0af.png

Deswegen glaube ich, dass das OpsCenter mit der Fokussierung auf “Was sind die Störungen in diesem Account” bei der täglichen Arbeit eine gute Hilfe sein kann.

Viel Erfolg beim Ausprobieren und Verwenden!

Similar Posts You Might Enjoy

Managing multiple stages with Terraform

Verwalten mehrerer environments in Terraform Zur Zeit ist dieser Artikel nur in Englisch verfügbar. - by Maurice Borgmeier

Aufbau von Lambda mit terraform

Note: An updated version of this post is available here Aufbau von Lambda Funktionen mit Terraform Einleitung Vielfach wird terraform verwendet, um die AWS Ressourcen als Code “Infrastructure as Code” zu managen. Für uns als AWS Benutzer wird Lambda immer mehr zu einem wichtigen Teil der Infrastruktur und vor allem deren Automatisierung. Das Ausrollen und speziell das Erstellen/Kompilieren (build) von Lambda Funktionen mit Terraform geht leider nicht ganz so einfach. - by Maurice Borgmeier

Aufbau von Lambda mit Terraform

Note: This is an updated version of this blog. Aufbau von Lambda Funktionen mit Terraform Einleitung Vielfach wird terraform verwendet, um die AWS Ressourcen als Code “Infrastructure as Code” zu managen. Für uns als AWS Benutzer wird Lambda immer mehr zu einem wichtigen Teil der Infrastruktur und vor allem deren Automatisierung. Das Ausrollen und speziell das Erstellen/Kompilieren (build) von Lambda Funktionen mit Terraform geht leider nicht ganz so einfach. - by Maurice Borgmeier , Alexey Vidanov