{"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\/nl\/blog\/administrirovanie\/kak-ya-nedelyu-byl-stazherom-sre-inzhenera-dezhurstvo-glazami-inzhenera-po","title":{"rendered":"Hoe ik een week stagiair was als SRE-engineer. Diensten vanuit het oogpunt van een software-engineer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hoe<\/p>\n

<\/p>\n

SRE-engineer \u2013 stagiair<\/h2>\n

<\/p>\n

Laat me eerst voorstellen. Ik ben @tristan.read<\/a><\/noindex>, frontend engineer in de groep Monitor::Health<\/a><\/noindex> GitLab. Vorige week had ik de eer om stage te lopen bij een van onze stand-by SRE-engineers. Het doel was dagelijks te observeren hoe de stand-by ingenieur reageert op incidenten en echte werkervaring op te doen. We zouden willen dat onze ingenieurs de behoeften van gebruikers beter begrijpen. functies<\/a><\/noindex> Monitor::Health.<\/p>\n

<\/p>\n

Tijdens de week volgde ik de SRE-engineer overal. Dat betekende dat ik aanwezig was tijdens de overdracht van de dienst, de waarschuwingskanalen volgde en reageerde op incidenten, als en wanneer deze zich voordeden.<\/p>\n

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

Incidenten<\/h2>\n

<\/p>\n

In de loop van de week vond er 2 incidenten plaats.<\/p>\n

<\/p>\n

1. Cryptominer<\/h3>\n

<\/p>\n

Woensdag werd er een piek in het gebruik van GitLab.com geregistreerd, veroorzaakt door pogingen om runner-minuten te gebruiken voor het minen van cryptocurrencies. Het incident werd aangepakt met behulp van onze eigen tool voor het neutraliseren van schendingen, die taken van de runner stopt en het gerelateerde project en account verwijdert. GitLab Runner<\/a><\/noindex>die werd veroorzaakt door pogingen om de minuten van de runner te gebruiken voor het minen van cryptocurrency. We hebben het incident opgelost met behulp van ons eigen tool voor het neutraliseren van schendingen, dat taken van de runner stopt en het bijbehorende project en account verwijdert. <\/p>\n

<\/p>\n

2. Prestatieafname van de Canary- en Main-applicaties<\/p>\n

<\/p>\n

Het incident werd veroorzaakt door vertragingen en een verhoogde foutfrequentie in de canary- en main-webapplicaties op GitLab.com. Verscheidene Apdex-waarden werden overschreden.<\/h3>\n

<\/p>\n

Open incidenttaak:<\/p>\n

<\/p>\n

Belangrijkste conclusies https:\/\/gitlab.com\/gitlab-com\/gl-infra\/production\/issues\/1442<\/a><\/noindex><\/p>\n

<\/p>\n

Hier zijn een paar punten die ik heb begrepen tijdens mijn week in de wacht.<\/h2>\n

<\/p>\n

1. Alerts zijn het meest nuttig wanneer ze afwijkingen van de norm detecteren.<\/p>\n

<\/p>\n

Alerts kunnen in verschillende typen worden verdeeld:<\/h3>\n

<\/p>\n

Alerts gebaseerd op een bepaalde drempelwaarde, zoals 'er zijn 10 5xx-fouten per seconde voorgevallen'.<\/p>\n

<\/p>\n