SRE inžinier - praktikant
Najprv mi dovoľte predstaviť sa. ja - , front-end inžinier v skupine GitLab. Minulý týždeň som mal tú česť stážovať s jedným z našich inžinierov SRE. Cieľom bolo pozorovať, ako službukonajúci dôstojník denne reagoval na incidenty a získať reálne skúsenosti z práce. Chceli by sme, aby naši inžinieri lepšie porozumeli potrebám používateľov Monitor::Zdravie.
Musel som týždeň všade sledovať inžiniera SRE. To znamená, že som bol prítomný pri odovzdávaní, monitoroval som tie isté výstražné kanály a reagoval na incidenty, ak a kedy nastali.
Incidenty
V priebehu týždňa došlo k 2 incidentom.
1. Kryptomín
GitLab.com zaznamenal v stredu skok v používaní 'a, spôsobené pokusmi využiť minúty bežca na ťažbu kryptomeny. Incident bol riešený pomocou nášho vlastného nástroja na neutralizáciu porušení, ktorý zastaví úlohy bežca a odstráni projekt a účet, ktorý je s ním spojený.
Ak by táto udalosť nebola zaznamenaná, automatizovaný nástroj by ju zachytil, ale v tomto prípade si porušenie všimol inžinier SRE ako prvý. Bola vytvorená úloha incidentu, ale informácie o nej sú uzavreté.
2. Zhoršenie výkonu aplikácií Canary a Main
Incident spôsobili spomalenia a zvýšená frekvencia chýb v kanárikových a hlavných webových aplikáciách na Gitlab.com. Bolo porušených niekoľko hodnôt Apdex.
Otvoriť úlohu incidentu:
Kľúčové zistenia
Tu je niekoľko vecí, ktoré som sa naučil počas týždňa v službe.
1. Upozornenia sú najužitočnejšie pri zisťovaní odchýlok od normy.
Upozornenia možno rozdeliť do niekoľkých typov:
- Výstrahy založené na určitej prahovej hodnote, ako napríklad „10 chýb 5xx za sekundu“.
- Upozornenia, v ktorých je prahová hodnota percentuálna hodnota, ako napríklad „frekvencia 5xx chýb na 10 % celkového objemu žiadostí v danom čase“.
- Upozornenia založené na historickom priemere, ako napríklad „chyby 5xx na 90. percentile“.
Všeobecne povedané, typy 2 a 3 sú užitočnejšie pre SRE v službe, pretože odhaľujú odchýlky od normy v procese.
2. Mnoho upozornení nikdy neeskaluje do incidentov.
Inžinieri SR riešia neustály prúd výstrah, z ktorých mnohé v skutočnosti nie sú kritické.
Prečo teda neobmedziť upozornenia len na tie skutočne dôležité? S týmto prístupom však nemusíte rozpoznať prvé príznaky toho, čo sa stane skutočným problémom, ktorý ohrozuje veľké škody.
Úlohou pohotovostného SRE je určiť, ktoré upozornenia skutočne naznačujú niečo vážne a či je potrebné ich eskalovať a riešiť. Domnievam sa, že je to spôsobené aj nepružnosťou upozornení: bolo by lepšie, keby existovalo niekoľko úrovní alebo „inteligentných“ spôsobov konfigurácie upozornení v súlade so situáciou opísanou vyššie.
Návrh funkcie:
3. Naši SRE v službe používajú veľa nástrojov.
Interné:
- Projekt GitLab infra: runbooky žijú tu, úlohy na smeny/týždeň, úlohy reakcie na incidenty.
- Problémy GitLab: V problémoch sa sledujú aj vyšetrovania, kontroly a údržba.
- Štítky GitLab: Úlohy automatizácie sa spúšťajú pomocou špecifických štítkov, ktoré roboty používajú na sledovanie aktivity úloh.
Vonkajšie:
- PagerDuty: Upozornenia
- Slack: Sem ide tok správ PagerDuty/AlertManager. Integrácia s príkazmi lomky na vykonávanie rôznych úloh, ako je zatvorenie výstrahy alebo eskalácia na incident.
- Grafana: vizualizácia metrík so zameraním na dlhodobé trendy.
- Kibana: Poskytuje vizualizáciu/vyhľadávanie v protokole, schopnosť preniknúť hlbšie do konkrétnych udalostí.
- Zoom: V Zoom je neustále spustená „oddeľovacia miestnosť“. To umožňuje inžinierom SRE rýchlo diskutovať o udalostiach bez straty drahocenného času vytváraním miestnosti a spájaním účastníkov.
A mnoho mnoho ďalších.
4. Monitorovanie GitLab.com pomocou GitLab je jediným bodom zlyhania
Ak na GitLab.com dôjde k veľkému výpadku služby, nechceme, aby to ovplyvnilo našu schopnosť vyriešiť problém. Dá sa zastaviť spustením druhej inštancie GitLab na správu GitLab.com. V skutočnosti nám to už funguje: .
5. Niekoľko funkcií na zváženie pridania do GitLabu
- , podobne ako Dokumenty Google. Pomohlo by to pri úlohách týkajúcich sa incidentov počas udalosti, ako aj pri úlohách týkajúcich sa debrífingu. V oboch prípadoch môže byť potrebné, aby viacerí účastníci niečo pridali v reálnom čase.
- Viac webhookov pre úlohy. Schopnosť spúšťať rôzne kroky pracovného toku GitLab zvnútra pomôže znížiť vašu závislosť od integrácií Slack. Napríklad možnosť povoliť upozornenie v PagerDuty prostredníctvom príkazu lomka v probléme GitLab.
Záver
Inžinieri SRE to majú ťažké s množstvom zložitostí. Bolo by skvelé vidieť viac produktov GitLab, ktoré riešia tieto problémy. Už pracujeme na niektorých doplnkoch k produktu, ktoré uľahčia vyššie uvedené pracovné postupy. Podrobnosti sú dostupné na .
V roku 2020 rozširujeme tím, aby sme spojili všetky tieto skvelé funkcie. Ak máte záujem, pozrite sa a v prípade akýchkoľvek otázok neváhajte kontaktovať kohokoľvek z nášho tímu.
Zdroj: hab.com