{"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\/it\/blog\/administrirovanie\/kak-ya-nedelyu-byl-stazherom-sre-inzhenera-dezhurstvo-glazami-inzhenera-po","title":{"rendered":"9 anni di Mojolicious! Rilascio festivo 8.28 con async\/await!","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"9<\/p>\n

<\/p>\n

SRE ingegnere - tirocinante<\/h2>\n

<\/p>\n

Per cominciare, permettetemi di presentarmi. Sono @tristan.read<\/a><\/noindex>, ingegnere frontend nel gruppo Monitor::Health<\/a><\/noindex> GitLab. La scorsa settimana ho avuto l'onore di essere stagista presso uno dei nostri SRE ingegneri di turno. L'obiettivo era quello di osservare quotidianamente come l'ingegnere di turno reagisce agli incidenti e acquisire esperienza pratica. Vogliamo che i nostri ingegneri comprendano meglio le esigenze degli utenti. funzioni<\/a><\/noindex> Monitor::Health.<\/p>\n

<\/p>\n

Ho dovuto seguire l'ingegnere SRE ovunque per una settimana. Ci\u00f2 significa che ero presente al cambio di turno, osservavo gli stessi canali di notifiche e reagivo agli incidenti, se e quando si verificavano.<\/p>\n

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

Incidenti<\/h2>\n

<\/p>\n

Durante la settimana si sono verificati 2 incidenti.<\/p>\n

<\/p>\n

1. Criptominer<\/h3>\n

<\/p>\n

Mercoled\u00ec su GitLab.com si \u00e8 registrato un picco nell'uso GitLab Runner<\/a><\/noindex>causato dai tentativi di utilizzare i minuti del runner per il mining di criptovalute. Abbiamo risolto l'incidente grazie a uno strumento proprietario di mitigazione delle violazioni, che ferma i task del runner e rimuove i progetti e gli account a esso correlati. <\/p>\n

<\/p>\n

Se questo evento non fosse stato notato, sarebbe stato catturato da uno strumento automatizzato, ma in questo caso l'ingegnere SRE ha notato la violazione per primo. \u00c8 stata creata una task per l'incidente, ma le informazioni al riguardo sono riservate.<\/p>\n

<\/p>\n

2. Degrada\u00e7\u00e3o delle prestazioni delle applicazioni Canary e Main<\/h3>\n

<\/p>\n

L'incidente \u00e8 stato provocato da rallentamenti e un incremento della frequenza degli errori nelle applicazioni web canary e main su Gitlab.com. Sono state violate diverse metriche Apdex.<\/p>\n

<\/p>\n

Task aperta per l'incidente: https:\/\/gitlab.com\/gitlab-com\/gl-infra\/production\/issues\/1442<\/a><\/noindex><\/p>\n

<\/p>\n

Conclusioni chiave<\/h2>\n

<\/p>\n

Ecco alcuni punti che ho compreso durante la settimana di turno.<\/p>\n

<\/p>\n

1. Le notifiche sono pi\u00f9 utili quando catturano deviazioni dalla norma.<\/h3>\n

<\/p>\n

Le notifiche possono essere suddivise in diversi tipi:<\/p>\n

<\/p>\n