{"id":54449,"date":"2019-12-26T00:00:00","date_gmt":"2019-12-25T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-ya-nedelyu-byl-stazherom-sre-inzhenera-dezhurstvo-glazami-inzhenera-po"},"modified":"2020-02-18T14:02:27","modified_gmt":"2020-02-18T11:02:27","slug":"kak-ya-nedelyu-byl-stazherom-sre-inzhenera-dezhurstvo-glazami-inzhenera-po","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-ya-nedelyu-byl-stazherom-sre-inzhenera-dezhurstvo-glazami-inzhenera-po","title":{"rendered":"Wie ich eine Woche lang Praktikant im SRE-Team war. Der Dienst aus der Perspektive eines Software-Ingenieurs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Wie<\/p>\n

<\/p>\n

SRE-Ingenieur \u2014 Praktikant<\/h2>\n

<\/p>\n

Zun\u00e4chst lassen Sie mich vorstellen. Ich bin @tristan.read<\/a><\/noindex>, Frontend-Ingenieur in der Gruppe Monitor::Health<\/a><\/noindex> GitLab. In der vergangenen Woche hatte ich die Ehre, als Praktikant bei einem unserer diensthabenden SRE-Ingenieure zu sein. Ziel war es, t\u00e4glich zu beobachten, wie der Diensthabende auf Vorf\u00e4lle reagiert, und praktische Erfahrungen zu sammeln. Wir m\u00f6chten, dass unsere Ingenieure die Bed\u00fcrfnisse der Nutzer besser verstehen. Funktionen<\/a><\/noindex> Monitor::Health.<\/p>\n

<\/p>\n

Ich sollte eine Woche lang dem SRE-Ingenieur \u00fcberall hin folgen. Das hei\u00dft, ich war bei der \u00dcbergabe des Schichtdienstes anwesend, beobachtete die gleichen Alarmkan\u00e4le und reagierte auf Vorf\u00e4lle, wenn und wann sie auftraten.<\/p>\n

<\/a><\/noindex><\/p>\n

Vorf\u00e4lle<\/h2>\n

<\/p>\n

In der Woche gab es 2 Vorf\u00e4lle.<\/p>\n

<\/p>\n

1. Krypto-Miner<\/h3>\n

<\/p>\n

Am Mittwoch wurde auf GitLab.com ein Anstieg der Nutzung festgestellt GitLab Runner<\/a><\/noindex>Die Ursache war ein Vorfall, der durch den Versuch, die Minuten des Runners f\u00fcr das Mining von Kryptow\u00e4hrungen zu nutzen, ausgel\u00f6st wurde. Wir haben den Vorfall mit unserem eigenen Tool zur Neutralisierung von Verst\u00f6\u00dfen bearbeitet, das die Aufgaben des Runners stoppt und das damit verbundene Projekt sowie den Account l\u00f6scht. <\/p>\n

<\/p>\n

Wenn dieses Ereignis nicht bemerkt worden w\u00e4re, h\u00e4tte es ein automatisiertes Tool aufgefangen, aber in diesem Fall hat der SRE-Ingenieur die Anomalie zuerst festgestellt. Eine Incident-Aufgabe wurde erstellt, jedoch sind die Informationen dazu vertraulich.<\/p>\n

<\/p>\n

2. Leistungseinbu\u00dfen der Canary- und Main-Anwendungen<\/h3>\n

<\/p>\n

Der Vorfall wurde durch Verz\u00f6gerungen und eine erh\u00f6hte Fehlerh\u00e4ufigkeit in den Canary- und Main-Webanwendungen auf Gitlab.com ausgel\u00f6st. Es wurden mehrere Apdex-Werte \u00fcberschritten.<\/p>\n

<\/p>\n

Offene Incident-Aufgabe: https:\/\/gitlab.com\/gitlab-com\/gl-infra\/production\/issues\/1442<\/a><\/noindex><\/p>\n

<\/p>\n

Wichtige Erkenntnisse<\/h2>\n

<\/p>\n

Hier sind einige Punkte, die ich w\u00e4hrend meiner einw\u00f6chigen Schicht festgestellt habe.<\/p>\n

<\/p>\n

1. Benachrichtigungen sind am n\u00fctzlichsten, wenn sie Abweichungen von der Norm erfassen.<\/h3>\n

<\/p>\n

Benachrichtigungen k\u00f6nnen in mehrere Typen unterteilt werden:<\/p>\n

<\/p>\n