AWS OpsCenter - Ticket as a Service



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

More Tools - CDK Examples

We need more CDK examples In this github repo we focus on examples for every day work. While there are some nice examples for the fancy stuff like fargate, ecs and so on in aws-cdk-examples/typescript at master · aws-samples/aws-cdk-examples · GitHub, i felt that basic examples where missing. So we created GitHub - tecracer/cdk-templates: Templates for aws cdk - by Gernot Glawe

Getting around circular CloudFormation Dependencies: S3-Event-Lambda-Role

Getting around circular CloudFormation dependencies Several posts complain about the inability of CloudFormation to apply a Lambda event function to an S3 Bucket with an dynamically generated name. The standard UseCase is an S3 Bucket with a Lambda event notification. In this special case the Bucket has a dynamically generated name. This cannot be done by pure CloudFormation! How to work around this circular depency? Let me show you an easy way: - by Gernot Glawe

tRick: simple network 2 - Geschwindigkeit

Vergleich Infrastructure as Code (IaC) Frameworks - tRick Alle Posts Abstraktion und Lines of Code Geschwindigkeit Diversity (polyglott), Tooling, Fazit Benchmark Ausführungsgeschindigkeit Ausführungsgeschwindigkeit Direkt aus dem tRick Repository wird mehrfach (n=10) der Zyklus Build - Check - Deploy - Remove ausgeführt. Damit sollen Cache Effekte statistisch gemittelt werden. Dazu nehme ich das Tool hyperfine zur Hilfe. Es führt Kommandos automatisch mehrfach aus und mittelt die Ergebnisse. Meine Annahme ist es, dass Terraform vorne liegt, da das Programm selber statisch kompiliert in go geschrieben ist. Außerdem geht die Ausführung direkt auf die API. - by Gernot Glawe