{"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 als SRE-Ingenieur war. Dienst schauend durch die Augen 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 erlauben Sie mir, mich vorzustellen. Ich bin @tristan.read<\/a><\/noindex>, Frontend-Ingenieur in der Gruppe Monitor::Health<\/a><\/noindex> GitLab. In der letzten 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 reale Arbeitserfahrungen zu sammeln. Wir m\u00f6chten, dass unsere Ingenieure die Bed\u00fcrfnisse der Benutzer besser verstehen. Funktionen<\/a><\/noindex> Monitor::Health.<\/p>\n

<\/p>\n

Ich sollte eine Woche lang dem SRE-Ingenieur \u00fcberallhin folgen. Das bedeutet, ich war bei der \u00dcbergabe des Dienstes anwesend, habe die gleichen Alarmkan\u00e4le beobachtet und auf Vorf\u00e4lle reagiert, falls 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-Mining<\/h3>\n

<\/p>\n

Am Mittwoch wurde auf GitLab.com ein Anstieg im Verbrauch festgestellt, GitLab Runner<\/a><\/noindex>Vorfall, der durch Versuche verursacht wurde, die Minuten des Runners f\u00fcr das Mining von Kryptow\u00e4hrungen zu nutzen. Der Vorfall wurde mithilfe unseres eigenen Tools zur Behebung von St\u00f6rungen gel\u00f6st, das die Aufgaben des Runners stoppt und das damit verbundene Projekt sowie das Konto entfernt. <\/p>\n

<\/p>\n

Wenn dieses Ereignis nicht bemerkt worden w\u00e4re, h\u00e4tte es ein automatisiertes Tool erkannt, aber in diesem Fall bemerkte der SRE-Ingenieur den Versto\u00df zuerst. Ein Vorfallticket wurde erstellt, jedoch sind die Informationen dazu vertraulich.<\/p>\n

<\/p>\n

2. Leistungsverschlechterungen der Anwendungen Canary und Main<\/h3>\n

<\/p>\n

Der Vorfall wurde durch Verz\u00f6gerungen und eine erh\u00f6hte Fehlerquote in den Canary- und Haupt-Webanwendungen auf Gitlab.com ausgel\u00f6st. Mehrere Apdex-Werte wurden \u00fcberschritten.<\/p>\n

<\/p>\n

Offene Ticketnummer f\u00fcr den Vorfall: https:\/\/gitlab.com\/gitlab-com\/gl-infra\/production\/issues\/1442<\/a><\/noindex><\/p>\n

<\/p>\n

Wesentliche Erkenntnisse<\/h2>\n

<\/p>\n

Hier sind einige Punkte, die ich in meiner Woche im Dienst gelernt habe.<\/p>\n

<\/p>\n

1. Alarme sind am hilfreichsten, wenn sie Abweichungen von der Norm erkennen.<\/h3>\n

<\/p>\n

Alarme lassen sich in mehrere Typen unterteilen:<\/p>\n

<\/p>\n