Necə bir həftə SRE mühəndisi stajyeriydim. Bir proqram mühəndisinin gözü ilə vəzifə

Necə bir həftə SRE mühəndisi stajyeriydim. Bir proqram mühəndisinin gözü ilə vəzifə

SRE mühəndisi - stajçı

Əvvəlcə özümü təqdim edim. mən - @tristan.read, qrupda qabaqcıl mühəndis Monitor::Sağlamlıq GitLab. Keçən həftə mən çağırış üzrə SRE mühəndislərimizdən biri ilə təcrübə keçmək şərəfinə nail oldum. Məqsəd növbətçinin hər gün baş verən hadisələrə necə reaksiya verdiyini müşahidə etmək və iş yerində real həyat təcrübəsi əldə etmək idi. Biz istərdik ki, mühəndislərimiz istifadəçi ehtiyaclarını daha yaxşı başa düşsünlər funksiyaları Monitor::Sağlamlıq.

Bir həftə hər yerdə SRE mühəndisini izləməli oldum. Yəni mən təhvil-təslimdə iştirak etdim, eyni xəbərdarlıq kanallarını izlədim və hadisələr baş verdikdə və nə vaxt baş verərsə, onlara reaksiya verdim.

Hadisələr

Bir həftə ərzində 2 hadisə baş verib.

1. Kriptominator

GitLab.com çərşənbə günü istifadədə bir sıçrayış gördü GitLab Runner'a, kriptovalyuta əldə etmək üçün qaçışın dəqiqələrindən istifadə etmək cəhdləri səbəb oldu. Hadisə qaçışçının tapşırıqlarını dayandıran və onunla əlaqəli layihəni və hesabı silən öz pozuntunu zərərsizləşdirmə alətimizdən istifadə etməklə həll edildi.

Əgər bu hadisə nəzərə alınmasaydı, avtomatlaşdırılmış alət onu tutacaqdı, lakin bu halda ilk olaraq SRE mühəndisi pozuntunu hiss etdi. Hadisə tapşırığı yaradıldı, lakin bu barədə məlumat bağlanıb.

2. Canary və Əsas proqramların performansının azalması

İnsidentə Gitlab.com saytındakı kanareyka və əsas veb proqramlardakı yavaşlamalar və səhvlərin tezliyi səbəb olub. Bir neçə Apdex dəyəri pozuldu.

Açıq hadisə tapşırığı: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Əsas tapıntılar

Növbətçi olduğum həftə ərzində öyrəndiyim bir neçə şey var.

1. Xəbərdarlıqlar normadan kənara çıxmaları aşkar edərkən ən faydalıdır.

Xəbərdarlıqları bir neçə növə bölmək olar:

  • “Saniyədə 10 5xx xəta baş verdi” kimi müəyyən hədd dəyərinə əsaslanan xəbərdarlıqlar.
  • “Verilmiş vaxtda sorğuların ümumi həcminin 5%-i üçün 10xx xəta tezliyi” kimi həddin faiz dəyəri olduğu xəbərdarlıqlar.
  • "5 faizlikdə 90xx səhv" kimi tarixi orta hesabla əsaslanan xəbərdarlıqlar.

Ümumiyyətlə, növbə 2 və 3 növbətçi SRE-lər üçün daha faydalıdır, çünki onlar prosesdə normadan kənarlaşmaları aşkar edirlər.

2. Bir çox xəbərdarlıqlar heç vaxt insidentlərə çevrilmir.

SR mühəndisləri bir çoxu əslində kritik olmayan daimi xəbərdarlıq axını ilə məşğul olurlar.

Bəs niyə xəbərdarlıqlarınızı yalnız həqiqətən vacib olanlarla məhdudlaşdırmayasınız? Bununla belə, bu yanaşma ilə siz böyük ziyanla təhdid edən real problemə çevriləcək nəyin ilkin əlamətlərini tanıya bilməzsiniz.

Çağırış zamanı SRE-nin işi, hansı xəbərdarlıqların həqiqətən ciddi bir şeyi göstərdiyini və onların gücləndirilməsinə və sıralanmağa başlanmasına ehtiyac olub olmadığını müəyyən etməkdir. Güman edirəm ki, bu, həm də xəbərdarlıqların çevik olmaması ilə bağlıdır: yuxarıda göstərilən vəziyyətə uyğun olaraq xəbərdarlıqları konfiqurasiya etmək üçün bir neçə səviyyə və ya “ağıllı” yollar təqdim etsələr, daha yaxşı olar.

Xüsusiyyət Təklifi: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Növbətçi SRE-lərimiz çoxlu alətlərdən istifadə edir.

Daxili:

  • GitLab infra layihəsi: runbooks burada yaşayır, növbə/həftə tapşırıqları, insidentlərə cavab tapşırıqları.
  • GitLab problemləri: Araşdırmalar, baxışlar və texniki xidmət də məsələlərdə izlənilir.
  • GitLab etiketləri: Avtomatlaşdırma tapşırıqları botların tapşırıq fəaliyyətini izləmək üçün istifadə etdiyi xüsusi etiketlərdən istifadə etməklə işə salınır.

Xarici:

  • PagerDuty: Xəbərdarlıqlar
  • Slack: PagerDuty/AlertManager mesaj axını bura gedir. Xəbərdarlığın bağlanması və ya hadisəyə yüksəldilməsi kimi müxtəlif tapşırıqları yerinə yetirmək üçün slash əmrləri ilə inteqrasiya.
  • Grafana: uzunmüddətli tendensiyalara diqqət yetirməklə ölçülərin vizuallaşdırılması.
  • Kibana: Vizuallaşdırma/log axtarışı, konkret hadisələri daha dərindən araşdırmaq imkanı verir.
  • Böyütmə: Zoom-da daim işləyən bir “breakout room” var. Bu, SRE mühəndislərinə otaq yaratmaq və iştirakçıları birləşdirməklə qiymətli vaxt itirmədən hadisələri tez müzakirə etməyə imkan verir.

Və bir çox başqaları.

4. GitLab.com-un GitLab ilə monitorinqi yeganə uğursuzluq nöqtəsidir

GitLab.com böyük bir xidmət kəsilməsi ilə qarşılaşarsa, bunun problemi həll etmək qabiliyyətimizə təsir etməsini istəmirik. GitLab.com-u idarə etmək üçün ikinci GitLab instansiyasını işə salmaqla onu dayandırmaq olar. Əslində, bu artıq bizim üçün işləyir: https://ops.gitlab.net/.

5. GitLab-a əlavə etmək üçün bir neçə xüsusiyyət

  • Çox istifadəçi tapşırığının redaktəsi, Google Sənədlərə bənzəyir. Bu, tədbir zamanı baş verən hadisələrlə bağlı tapşırıqlar, eləcə də brifinqlə bağlı tapşırıqların yerinə yetirilməsinə kömək edəcək. Hər iki halda, bir neçə iştirakçı real vaxtda nəsə əlavə etməli ola bilər.
  • Tapşırıqlar üçün daha çox webhooks. Fərqli GitLab iş axını addımlarını daxildən yerinə yetirmək bacarığı Slack inteqrasiyalarına etibarınızı azaltmağa kömək edəcək. Məsələn, GitLab məsələsində slash əmri ilə PagerDuty-də xəbərdarlıq etməyə icazə vermək imkanı.
    Nəticə

SRE mühəndisləri bir çox mürəkkəbliklə çətin anlar yaşayırlar. Bu problemləri həll edən daha çox GitLab məhsulunu görmək əla olardı. Biz artıq məhsula yuxarıda qeyd olunan iş proseslərini asanlaşdıracaq bəzi əlavələr üzərində işləyirik. Təfərrüatlar burada mövcuddur Ops Product Vision bölməsi.

Bütün bu gözəl xüsusiyyətləri bir araya gətirmək üçün 2020-ci ildə komandanı genişləndiririk. Əgər maraqlanırsınızsa, yoxlayın vakansiyalar, və istənilən sualınız ilə komandamızdakı hər kəslə əlaqə saxlamaqdan çekinmeyin.

Mənbə: www.habr.com

Добавить комментарий