{"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\/fr\/blog\/administrirovanie\/kak-ya-nedelyu-byl-stazherom-sre-inzhenera-dezhurstvo-glazami-inzhenera-po","title":{"rendered":"\ud83e\udd47Derpibooru maintenant en logiciel libre : ouverture de Philomena et Booru-on-Rails | ProHoster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\ud83e\udd47Derpibooru<\/p>\n

<\/p>\n

Ing\u00e9nieur SRE - stagiaire<\/h2>\n

<\/p>\n

Pour commencer, permettez-moi de me pr\u00e9senter. Je suis @tristan.read<\/a><\/noindex>, ing\u00e9nieur front-end dans le groupe Monitor::Health<\/a><\/noindex> GitLab. La semaine derni\u00e8re, j'ai eu l'honneur d'\u00eatre stagiaire aupr\u00e8s de l'un de nos SREs de service. L'objectif \u00e9tait d'observer quotidiennement la fa\u00e7on dont le garde r\u00e9agit aux incidents et d'acqu\u00e9rir une exp\u00e9rience de travail r\u00e9elle. Nous souhaitons que nos ing\u00e9nieurs comprennent mieux les besoins des utilisateurs. des fonctions<\/a><\/noindex> Monitor::Health.<\/p>\n

<\/p>\n

J'ai d\u00fb suivre l'ing\u00e9nieur SRE pendant une semaine. J'\u00e9tais pr\u00e9sent lors du passage de service, observais les m\u00eames canaux d'alerte et r\u00e9agissais aux incidents, s'il y en avait.<\/p>\n

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

Incidents<\/h2>\n

<\/p>\n

Au cours de la semaine, deux incidents se sont produits.<\/p>\n

<\/p>\n

1. Mineur de cryptomonnaie<\/h3>\n

<\/p>\n

Mercredi, nous avons constat\u00e9 une augmentation de l'utilisation sur GitLab.com GitLab Runner<\/a><\/noindex>ca, caus\u00e9 par des tentatives d'utiliser des minutes de runner pour le minage de cryptomonnaie. L'incident a \u00e9t\u00e9 r\u00e9solu gr\u00e2ce \u00e0 notre propre outil de neutralisation des violations, qui arr\u00eate les t\u00e2ches du runner et supprime le projet et le compte qui y sont li\u00e9s. <\/p>\n

<\/p>\n

Si cet \u00e9v\u00e9nement n'avait pas \u00e9t\u00e9 remarqu\u00e9, un outil automatis\u00e9 l'aurait d\u00e9tect\u00e9, mais dans ce cas, l'ing\u00e9nieur SRE a \u00e9t\u00e9 le premier \u00e0 remarquer la violation. Une t\u00e2che a \u00e9t\u00e9 cr\u00e9\u00e9e pour cet incident, mais les informations \u00e0 son sujet sont confidentielles.<\/p>\n

<\/p>\n

2. D\u00e9gradation des performances des applications Canary et Main<\/h3>\n

<\/p>\n

L'incident a \u00e9t\u00e9 provoqu\u00e9 par des ralentissements et une augmentation de la fr\u00e9quence des erreurs dans les applications web canary et main sur GitLab.com. Plusieurs valeurs Apdex ont \u00e9t\u00e9 affect\u00e9es.<\/p>\n

<\/p>\n

T\u00e2che ouverte concernant l'incident : https:\/\/gitlab.com\/gitlab-com\/gl-infra\/production\/issues\/1442<\/a><\/noindex><\/p>\n

<\/p>\n

Principales conclusions<\/h2>\n

<\/p>\n

Voici quelques points que j'ai compris au cours de ma semaine de service.<\/p>\n

<\/p>\n

1. Les alertes sont les plus utiles lorsqu'elles d\u00e9tectent des anomalies.<\/h3>\n

<\/p>\n

Les alertes peuvent \u00eatre divis\u00e9es en plusieurs types :<\/p>\n

<\/p>\n