Μηχανικός SRE - ασκούμενος
Ξεκινώντας, επιτρέψτε μου να συστηθώ. ΕΓΩ - , μηχανικός front-end στην ομάδα GitLab. Την περασμένη εβδομάδα, είχα το προνόμιο να είμαι οικότροφος με έναν από τους εφημερεύοντες μηχανικούς μας SRE. Στόχος ήταν να παρατηρείται καθημερινά πώς ανταποκρίνεται ο αξιωματικός υπηρεσίας σε περιστατικά και να αποκτά πραγματική εργασιακή εμπειρία. Θα θέλαμε οι μηχανικοί μας να κατανοήσουν καλύτερα τις ανάγκες των χρηστών Παρακολούθηση::Υγεία.
Έπρεπε να ακολουθήσω το SRE για μια εβδομάδα. Δηλαδή ήμουν παρών στη μετάθεση υπηρεσίας, παρατήρησα τα ίδια κανάλια συναγερμού και απαντούσα σε περιστατικά, αν και όποτε συνέβαιναν.
Περιστατικά
Υπήρξαν 2 περιστατικά σε μια εβδομάδα.
1. Cryptominer
Το GitLab.com κατέγραψε άλμα στη χρήση την Τετάρτη «α, που προκαλείται από προσπάθειες χρήσης των λεπτών του δρομέα για εξόρυξη κρυπτονομισμάτων. Το περιστατικό διευθετήθηκε χρησιμοποιώντας ένα αποκλειστικό εργαλείο μετριασμού που σταματά τις εργασίες του δρομέα και διαγράφει το έργο και τον λογαριασμό που σχετίζεται με αυτό.
Εάν αυτό το συμβάν δεν είχε παρατηρηθεί, ένα αυτοματοποιημένο εργαλείο θα το είχε πιάσει, αλλά σε αυτήν την περίπτωση, ο μηχανικός SRE παρατήρησε πρώτος την παράβαση. Δημιουργήθηκε μια εργασία περιστατικού, αλλά οι πληροφορίες σχετικά με αυτήν είναι κλειστές.
2. Υποβάθμιση της απόδοσης των Canary and Main εφαρμογών
Το περιστατικό τροφοδοτήθηκε από επιβραδύνσεις και αυξημένα ποσοστά σφαλμάτων στο canary και στις κύριες διαδικτυακές εφαρμογές στο Gitlab.com. Παραβιάστηκαν αρκετές τιμές Apdex.
Άνοιγμα εργασίας ανά περιστατικό:
Βασικά ευρήματα
Εδώ είναι μερικά σημεία που έμαθα κατά τη διάρκεια της εβδομάδας της υπηρεσίας.
1. Οι ειδοποιήσεις είναι πιο χρήσιμες κατά τον εντοπισμό αποκλίσεων από τον κανόνα.
Οι ειδοποιήσεις μπορούν να χωριστούν σε διάφορους τύπους:
- Ειδοποιήσεις που βασίζονται σε ένα συγκεκριμένο όριο, όπως "Παρουσιάστηκαν 10 σφάλματα 5xx ανά δευτερόλεπτο".
- Ειδοποιήσεις όπου το όριο είναι μια ποσοστιαία τιμή, όπως "ποσοστό σφάλματος 5xx ανά 10% των συνολικών αιτημάτων σε μια δεδομένη στιγμή".
- Ειδοποιήσεις με βάση έναν ιστορικό μέσο όρο, όπως "5xx σφάλματα στο 90ο εκατοστημόριο".
Σε γενικές γραμμές, οι τύποι 2 και 3 είναι πιο χρήσιμοι για SRE σε υπηρεσία, καθώς αποκαλύπτουν ανωμαλίες στη διαδικασία.
2. Πολλές ειδοποιήσεις δεν κλιμακώνονται ποτέ σε περιστατικά
Οι μηχανικοί SR αντιμετωπίζουν μια συνεχή ροή ειδοποιήσεων, πολλές από τις οποίες δεν είναι πραγματικά κρίσιμες.
Γιατί λοιπόν να μην περιορίσετε τις ειδοποιήσεις μόνο στις πραγματικά σημαντικές; Με αυτήν την προσέγγιση, ωστόσο, τα πρώιμα συμπτώματα του τι θα μετατρέψει τη χιονοστιβάδα σε πραγματικό πρόβλημα που απειλεί μείζονες ζημιές μπορεί να παραβλεφθούν.
Το καθήκον του SRE σε υπηρεσία είναι να προσδιορίσει ποιες ειδοποιήσεις σημαίνουν πραγματικά κάτι σοβαρό και εάν πρέπει να κλιμακωθούν και να αρχίσουν να διευθετούνται. Υποψιάζομαι ότι αυτό οφείλεται επίσης στην ανελαστικότητα των ειδοποιήσεων: θα ήταν καλύτερα αν εισήγαγαν πολλά επίπεδα ή «έξυπνους» τρόπους προσαρμογής των ειδοποιήσεων σύμφωνα με την κατάσταση που περιγράφεται παραπάνω.
Πρόταση χαρακτηριστικών:
3. Τα SRE μας χρησιμοποιούν πολλά εργαλεία
Εσωτερικός:
- Έργο GitLab infra: Τα Runbooks ζωντανά εδώ, μεταδόσεις βάρδιας/εβδομάδα, εργασίες απόκρισης περιστατικών.
- Ζητήματα GitLab: Η έρευνα, η ενημέρωση και η συντήρηση παρακολουθούνται επίσης σε ζητήματα.
- Ετικέτες GitLab: Οι εργασίες αυτοματισμού ενεργοποιούνται από συγκεκριμένες ετικέτες που χρησιμοποιούν τα bots για την παρακολούθηση της δραστηριότητας των εργασιών.
Εξωτερικός:
- PagerDuty Alerts
- Slack: Εδώ πηγαίνει η ροή μηνυμάτων PagerDuty/AlertManager. Ενσωμάτωση με εντολές κάθετου για την εκτέλεση ποικίλων εργασιών, όπως το κλείσιμο μιας ειδοποίησης ή η κλιμάκωση σε ένα περιστατικό.
- Grafana: οπτικοποίηση μετρήσεων με έμφαση στις μακροπρόθεσμες τάσεις.
- Kibana: δίνει οπτικοποίηση/αναζήτηση καταγραφής, τη δυνατότητα να σκάβετε βαθύτερα σε ορισμένα γεγονότα.
- Ζουμ: Υπάρχει ένα μόνιμο «δωμάτιο διάσπασης» στο Ζουμ. Αυτό επιτρέπει στους SRE να συζητούν γρήγορα γεγονότα χωρίς να χάνουν πολύτιμο χρόνο δημιουργώντας ένα δωμάτιο και συνδέοντας μέλη.
Και πολλά πολλά άλλα.
4. Η παρακολούθηση του GitLab.com με το GitLab είναι ένα μόνο σημείο αποτυχίας
Εάν το GitLab.com αντιμετωπίσει μια σημαντική διακοπή της υπηρεσίας, δεν θέλουμε να επηρεάσει την ικανότητά μας να επιλύσουμε το πρόβλημα. Μπορεί να διακοπεί εκτελώντας μια δεύτερη παρουσία GitLab για τη διαχείριση του GitLab.com. Στην πραγματικότητα, αυτό λειτουργεί ήδη για εμάς: .
5. Μερικές δυνατότητες που πρέπει να προσθέσετε στο GitLab
- , παρόμοια με τα Έγγραφα Google. Αυτό θα βοηθούσε σε εργασίες συμβάντων κατά τη διάρκεια της εκδήλωσης, καθώς και σε εργασίες απολογισμού. Και στις δύο περιπτώσεις, πολλοί συμμετέχοντες μπορεί να χρειαστεί να προσθέσουν κάτι σε πραγματικό χρόνο ταυτόχρονα.
- Περισσότερα webhook για εργασίες. Η δυνατότητα εκτέλεσης διαφόρων βημάτων ροής εργασίας GitLab από μέσα θα σας βοηθήσει να μειώσετε την εξάρτησή σας από τις ενσωματώσεις Slack. Για παράδειγμα, η δυνατότητα ενεργοποίησης μιας ειδοποίησης στο PagerDuty μέσω μιας εντολής κάθετο σε ένα ζήτημα του GitLab.
Συμπέρασμα
Οι μηχανικοί SRE δυσκολεύονται με πολλές πολυπλοκότητες. Θα ήταν υπέροχο να δούμε περισσότερα προϊόντα GitLab να αντιμετωπίζουν αυτά τα ζητήματα. Εργαζόμαστε ήδη σε ορισμένες προσθήκες στο προϊόν που θα διευκολύνουν τις ροές εργασίας που αναφέρονται παραπάνω. Τα ανταλλακτικά είναι διαθέσιμα σε .
Το 2020, επεκτείνουμε την ομάδα για να συγκεντρώσουμε όλα αυτά τα υπέροχα χαρακτηριστικά. Εάν ενδιαφέρεστε, ελέγξτε έξω , και μη διστάσετε να επικοινωνήσετε με κάποιον από την ομάδα μας για τυχόν ερωτήσεις.
Πηγή: www.habr.com