SRE-insinööri - harjoittelija
Aluksi esittelen itseni. minä - , etupään insinööri ryhmässä GitLab. Viime viikolla minulla oli etuoikeus olla harjoittelijana yhden päivystävän SRE-insinöörimme kanssa. Tavoitteena oli seurata päivittäin, kuinka päivystäjä reagoi tapahtumiin ja saada todellista työkokemusta. Haluamme insinööriemme ymmärtävän paremmin käyttäjien tarpeita Monitor::Terveys.
Jouduin seuraamaan SRE:tä viikon ajan. Eli olin paikalla tehtävien siirrossa, tarkkailen samoja hälytyskanavia ja reagoin tapahtumiin, jos ja kun niitä sattui.
Tapahtumat
Viikon aikana sattui 2 tapausta.
1. Cryptominer
GitLab.com kirjasi käytön hypyn keskiviikkona 'a, joka johtuu yrityksistä käyttää juoksijan minuutteja kryptovaluutan louhintaan. Tapaus selvitettiin mukautetulla lievennystyökalulla, joka pysäyttää juoksijan tehtävät ja poistaa siihen liittyvän projektin ja tilin.
Jos tätä tapahtumaa ei olisi huomattu, automaattinen työkalu olisi saanut sen kiinni, mutta tässä tapauksessa SRE-insinööri huomasi rikkomuksen ensin. Tapahtumatehtävä luotiin, mutta sen tiedot on suljettu.
2. Kanariansaarten ja pääsovellusten suorituskyvyn heikkeneminen
Tapahtumaa ruokkivat hidastukset ja lisääntyneet virheprosentit Gitlab.comin kanavien ja tärkeimpien verkkosovellusten osalta. Useita Apdex-arvoja rikottiin.
Avaa tehtävä tapauskohtaisesti:
Keskeiset havainnot
Tässä on muutamia kohtia, jotka opin työviikon aikana.
1. Hälytykset ovat hyödyllisimpiä, kun havaitaan poikkeamia normista.
Ilmoitukset voidaan jakaa useisiin tyyppeihin:
- Tiettyyn kynnykseen perustuvat hälytykset, kuten "10 5xx-virhettä sekunnissa".
- Hälytykset, joissa kynnys on prosenttiarvo, kuten "5xx virheprosentti 10 %:a kohti pyyntöjen kokonaismäärästä tiettynä ajankohtana".
- Hälytykset perustuvat historialliseen keskiarvoon, kuten "5xx-virheitä 90. prosenttipisteessä".
Yleisesti ottaen tyypit 2 ja 3 ovat hyödyllisempiä päivystykseen oleville SRE:ille, koska ne paljastavat prosessin poikkeavuuksia.
2. Monet hälytykset eivät koskaan laajene tapahtumiksi
SR-insinöörit käsittelevät jatkuvaa hälytysvirtaa, joista monet eivät ole todella kriittisiä.
Joten miksi et rajoittaisi hälytyksiä vain todella tärkeisiin? Tällä lähestymistavalla voidaan kuitenkin jättää huomiotta varhaiset oireet siitä, mikä lumipallosta tulee todelliseksi ongelmaksi, joka uhkaa suuria vahinkoja.
Päivystävän SRE:n tehtävänä on selvittää, mitkä hälytykset todella tarkoittavat jotain vakavaa, ja onko niitä syytä eskaloida ja aloittaa selvittäminen. Epäilen, että tämä johtuu myös hälytysten joustamattomuudesta: olisi parempi, jos ne ottaisivat käyttöön useita tasoja tai "älykkäitä" tapoja mukauttaa hälytyksiä yllä kuvatun tilanteen mukaan.
Ominaisuusehdotus:
3. SRE:mme käyttävät paljon työkaluja
kotimainen:
- GitLab-infraprojekti: Runbookit elävät täällä, vuoro/viikko luovutukset, tapahtumien reagointitehtävät.
- GitLab-ongelmat: Ongelmissa seurataan myös tutkintaa, selvitystä ja ylläpitoa.
- GitLab-tunnisteet: Automaatiotehtävät käynnistyvät erityisillä tunnisteilla, joita robotit käyttävät tehtävien toiminnan seuraamiseen.
Ulkonäkö:
- PagerDuty-hälytykset
- Slack: Tähän PagerDuty/AlertManager-viestikulku menee. Integrointi vinoviivakomentojen kanssa erilaisten tehtävien suorittamiseksi, kuten hälytyksen sulkeminen tai tapahtuman eskalointi.
- Grafana: mittareiden visualisointi keskittyen pitkän aikavälin trendeihin.
- Kibana: antaa visualisoinnin/lokihaun, mahdollisuuden kaivaa syvemmälle tiettyihin tapahtumiin.
- Zoomaus: Zoomissa on pysyvä "breakout-huone". Näin SRE:t voivat keskustella nopeasti tapahtumista tuhlaamatta arvokasta aikaa huoneen luomiseen ja jäsenten yhdistämiseen.
Ja monet monet muut.
4. GitLab.comin seuranta GitLabilla on yksittäinen vika
Jos GitLab.com kokee suuren palvelukatkon, emme halua sen vaikuttavan kykyymme ratkaista ongelma. Se voidaan pysäyttää suorittamalla toinen GitLab-esiintymä GitLab.comin hallintaa varten. Itse asiassa tämä toimii jo meillä: .
5. Muutamia ominaisuuksia, jotka kannattaa harkita lisäämistä GitLabiin
- , samanlainen kuin Google Docs. Tämä auttaisi tapahtuman aikana tapahtuneissa tapahtumissa sekä selvitystehtävissä. Molemmissa tapauksissa useiden osallistujien on ehkä lisättävä jotain reaaliajassa kerralla.
- Lisää webhookeja tehtäviin. Mahdollisuus suorittaa erilaisia GitLabin työnkulun vaiheita sisältä auttaa vähentämään riippuvuuttasi Slack-integraatioista. Esimerkiksi mahdollisuus ottaa hälytys käyttöön PagerDutyssa vinoviivakomennon kautta GitLab-ongelmassa.
Johtopäätös
SRE-insinööreillä on vaikeuksia monien monimutkaisten asioiden kanssa. Olisi hienoa nähdä enemmän GitLab-tuotteita, jotka käsittelevät näitä ongelmia. Työskentelemme jo tuotteeseen joitain lisäyksiä, jotka helpottavat edellä mainittuja työnkulkuja. Osia löytyy mm .
Vuonna 2020 laajennamme tiimiä yhdistääksemme kaikki nämä upeat ominaisuudet. Jos kiinnostaa, käy tsekkaamassa , ja ota rohkeasti yhteyttä tiimiimme, jos sinulla on kysyttävää.
Lähde: will.com