Όλοι μιλούν για τις διαδικασίες ανάπτυξης και δοκιμών, την εκπαίδευση του προσωπικού, την αύξηση των κινήτρων, αλλά αυτές οι διαδικασίες δεν αρκούν όταν ένα λεπτό διακοπής της υπηρεσίας κοστίζει τεράστια χρηματικά ποσά. Τι να κάνετε όταν πραγματοποιείτε οικονομικές συναλλαγές με αυστηρή SLA; Πώς να αυξήσετε την αξιοπιστία και την ανοχή σφαλμάτων των συστημάτων σας, βγάζοντας την ανάπτυξη και τη δοκιμή εκτός της εξίσωσης;
Το επόμενο συνέδριο HighLoad++ θα πραγματοποιηθεί στις 6 και 7 Απριλίου 2020 στην Αγία Πετρούπολη. Λεπτομέρειες και εισιτήρια για . 9 Νοεμβρίου, 18:00. HighLoad++ Μόσχα 2018, Δελχί + αίθουσα Καλκούτα. Διατριβές και .
Evgeniy Kuzovlev (εφεξής – ΕΚ): - Φίλοι, γεια σας! Το όνομά μου είναι Kuzovlev Evgeniy. Είμαι από την εταιρεία EcommPay, ένα συγκεκριμένο τμήμα είναι το EcommPay IT, το τμήμα πληροφορικής του ομίλου εταιρειών. Και σήμερα θα μιλήσουμε για τις διακοπές λειτουργίας - για το πώς να τις αποφύγετε, για το πώς να ελαχιστοποιήσετε τις συνέπειές τους εάν δεν μπορούν να αποφευχθούν. Το θέμα αναφέρεται ως εξής: «Τι να κάνετε όταν ένα λεπτό διακοπής κοστίζει 100 $»; Κοιτάζοντας μπροστά, οι αριθμοί μας είναι συγκρίσιμοι.
Τι κάνει το EcommPay IT;
Ποιοι είμαστε? Γιατί στέκομαι εδώ μπροστά σου; Γιατί έχω το δικαίωμα να σου πω κάτι εδώ; Και για τι θα μιλήσουμε εδώ αναλυτικότερα;
Ο όμιλος εταιρειών EcommPay είναι διεθνής αγοραστής. Επεξεργαζόμαστε πληρωμές σε όλο τον κόσμο - στη Ρωσία, την Ευρώπη, τη Νοτιοανατολική Ασία (Σε όλο τον κόσμο). Έχουμε 9 γραφεία, 500 υπαλλήλους συνολικά, και περίπου λίγο λιγότεροι από τους μισούς από αυτούς είναι ειδικοί πληροφορικής. Ό,τι κάνουμε, ό,τι βγάζουμε λεφτά, το κάναμε μόνοι μας.
Έχουμε γράψει όλα μας τα προϊόντα (και έχουμε πολλά από αυτά - στη σειρά μεγάλων προϊόντων πληροφορικής έχουμε περίπου 16 διαφορετικά εξαρτήματα) μόνοι μας. Γράφουμε μόνοι μας, εξελισσόμαστε. Και αυτή τη στιγμή πραγματοποιούμε περίπου ένα εκατομμύριο συναλλαγές την ημέρα (τα εκατομμύρια είναι μάλλον ο σωστός τρόπος για να το πούμε). Είμαστε μια αρκετά νέα εταιρεία - είμαστε μόλις έξι χρονών περίπου.
Πριν από 6 χρόνια ήταν μια τέτοια startup όταν τα παιδιά ήρθαν μαζί με την επιχείρηση. Τους ένωσε μια ιδέα (δεν υπήρχε τίποτα άλλο παρά μια ιδέα), και τρέξαμε. Όπως κάθε startup, τρέχαμε πιο γρήγορα... Για εμάς η ταχύτητα ήταν πιο σημαντική από την ποιότητα.
Κάποια στιγμή σταματήσαμε: συνειδητοποιήσαμε ότι δεν μπορούσαμε πια να ζούμε με αυτή την ταχύτητα και με αυτή την ποιότητα και έπρεπε να εστιάσουμε πρώτα στην ποιότητα. Αυτή τη στιγμή, αποφασίσαμε να γράψουμε μια νέα πλατφόρμα που θα ήταν σωστή, επεκτάσιμη και αξιόπιστη. Άρχισαν να γράφουν αυτήν την πλατφόρμα (άρχισαν να επενδύουν, να αναπτύσσουν ανάπτυξη, να δοκιμάζουν), αλλά κάποια στιγμή κατάλαβαν ότι η ανάπτυξη και οι δοκιμές δεν μας επέτρεψαν να φτάσουμε σε ένα νέο επίπεδο ποιότητας υπηρεσιών.
Φτιάχνεις ένα νέο προϊόν, το βάζεις στην παραγωγή, αλλά και πάλι κάτι θα πάει στραβά κάπου. Και σήμερα θα μιλήσουμε για το πώς να φτάσουμε σε ένα νέο επίπεδο ποιότητας (πώς το κάναμε, για την εμπειρία μας), βγάζοντας την ανάπτυξη και τις δοκιμές από την εξίσωση. θα μιλήσουμε για το τι είναι διαθέσιμο στη λειτουργία - τι λειτουργία μπορεί να κάνει η ίδια, τι μπορεί να προσφέρει στη δοκιμή προκειμένου να επηρεάσει την ποιότητα.
Διακοπές. Εντολές λειτουργίας.
Πάντα ο κύριος ακρογωνιαίος λίθος, αυτό για το οποίο θα μιλήσουμε πραγματικά σήμερα είναι ο χρόνος διακοπής λειτουργίας. Τρομερή λέξη. Αν έχουμε χρόνο διακοπής, όλα είναι άσχημα για εμάς. Τρέχουμε να το ανεβάσουμε, οι διαχειριστές κρατούν τον διακομιστή - Θεός να μην πέσει, όπως λένε σε εκείνο το τραγούδι. Για αυτό θα μιλήσουμε σήμερα.
Όταν αρχίσαμε να αλλάζουμε τις προσεγγίσεις μας, σχηματίσαμε 4 εντολές. Τα παρουσιάζω στις διαφάνειες:
Αυτές οι εντολές είναι πολύ απλές:
- Εντοπίστε γρήγορα το πρόβλημα.
- Ξεφορτωθείτε το ακόμα πιο γρήγορα.
- Βοηθήστε να κατανοήσετε τον λόγο (αργότερα, για προγραμματιστές).
- Και τυποποίηση προσεγγίσεων.
Θα ήθελα να επιστήσω την προσοχή σας στο σημείο Νο. 2. Γλιτώνουμε το πρόβλημα και όχι το λύνουμε. Η απόφαση είναι δευτερεύουσα. Για εμάς, το πρωταρχικό είναι ότι ο χρήστης προστατεύεται από αυτό το πρόβλημα. Θα υπάρχει σε κάποιο απομονωμένο περιβάλλον, αλλά αυτό το περιβάλλον δεν θα έχει καμία επαφή μαζί του. Στην πραγματικότητα, θα περάσουμε από αυτές τις τέσσερις ομάδες προβλημάτων (κάποια με περισσότερες λεπτομέρειες, άλλα με μικρότερη λεπτομέρεια), θα σας πω τι χρησιμοποιούμε, τι σχετική εμπειρία έχουμε στις λύσεις.
Αντιμετώπιση προβλημάτων: Πότε συμβαίνουν και τι πρέπει να κάνετε για αυτά;
Αλλά θα ξεκινήσουμε εκτός λειτουργίας, θα ξεκινήσουμε με το σημείο Νο. 2 - πώς να απαλλαγούμε γρήγορα από το πρόβλημα; Υπάρχει ένα πρόβλημα - πρέπει να το διορθώσουμε. «Τι πρέπει να κάνουμε για αυτό;» - το κύριο ερώτημα. Και όταν αρχίσαμε να σκεφτόμαστε πώς να διορθώσουμε το πρόβλημα, αναπτύξαμε για τον εαυτό μας ορισμένες απαιτήσεις που πρέπει να ακολουθεί η αντιμετώπιση προβλημάτων.
Για να διατυπώσουμε αυτές τις απαιτήσεις, αποφασίσαμε να αναρωτηθούμε: «Πότε έχουμε προβλήματα»; Και τα προβλήματα, όπως αποδείχθηκε, εμφανίζονται σε τέσσερις περιπτώσεις:
- Αποτυχία υλικού.
- Οι εξωτερικές υπηρεσίες απέτυχαν.
- Αλλαγή έκδοσης λογισμικού (η ίδια ανάπτυξη).
- Αύξηση εκρηκτικού φορτίου.
Δεν θα μιλήσουμε για τα δύο πρώτα. Μια δυσλειτουργία υλικού μπορεί να λυθεί πολύ απλά: πρέπει να έχετε τα πάντα διπλά. Εάν πρόκειται για δίσκους, οι δίσκοι πρέπει να συναρμολογηθούν σε RAID· εάν πρόκειται για διακομιστή, ο διακομιστής πρέπει να είναι διπλότυπος· εάν έχετε υποδομή δικτύου, πρέπει να παρέχετε ένα δεύτερο αντίγραφο της υποδομής δικτύου, δηλαδή να το πάρετε και αντιγράψτε το. Και αν κάτι αποτύχει, αλλάζετε σε εφεδρική ισχύ. Είναι δύσκολο να πω κάτι περισσότερο εδώ.
Το δεύτερο είναι η αποτυχία των εξωτερικών υπηρεσιών. Για τους περισσότερους, το σύστημα δεν είναι καθόλου πρόβλημα, αλλά όχι για εμάς. Εφόσον επεξεργαζόμαστε πληρωμές, είμαστε ένας αθροιστής που βρίσκεται μεταξύ του χρήστη (που εισάγει τα δεδομένα της κάρτας του) και των τραπεζών, των συστημάτων πληρωμών (Visa, MasterCard, Mira κ.λπ.). Οι εξωτερικές μας υπηρεσίες (συστήματα πληρωμών, τράπεζες) τείνουν να αποτυγχάνουν. Ούτε εμείς ούτε εσείς (αν έχετε τέτοιες υπηρεσίες) μπορούμε να το επηρεάσουμε.
Τι να κάνουμε τότε; Υπάρχουν δύο επιλογές εδώ. Πρώτον, εάν μπορείτε, θα πρέπει να αντιγράψετε αυτήν την υπηρεσία με κάποιο τρόπο. Για παράδειγμα, αν μπορούμε, μεταφέρουμε κίνηση από τη μια υπηρεσία στην άλλη: για παράδειγμα, οι κάρτες υποβλήθηκαν σε επεξεργασία μέσω της Sberbank, η Sberbank αντιμετωπίζει προβλήματα - μεταφέρουμε την κίνηση [υπό όρους] στη Raiffeisen. Το δεύτερο πράγμα που μπορούμε να κάνουμε είναι να παρατηρήσουμε την αποτυχία των εξωτερικών υπηρεσιών πολύ γρήγορα και επομένως θα μιλήσουμε για την ταχύτητα απόκρισης στο επόμενο μέρος της αναφοράς.
Στην πραγματικότητα, από αυτές τις τέσσερις, μπορούμε να επηρεάσουμε συγκεκριμένα την αλλαγή των εκδόσεων λογισμικού - να προβούμε σε ενέργειες που θα οδηγήσουν σε βελτίωση της κατάστασης στο πλαίσιο των αναπτύξεων και στο πλαίσιο της εκρηκτικής αύξησης του φορτίου. Στην πραγματικότητα, αυτό κάναμε. Να, πάλι, μια μικρή σημείωση...
Από αυτά τα τέσσερα προβλήματα, αρκετά λύνονται αμέσως αν έχετε σύννεφο. Εάν βρίσκεστε στο Microsoft Azhur, στο Ozone cloud ή χρησιμοποιείτε τα σύννεφα μας, από το Yandex ή το Mail, τότε τουλάχιστον μια δυσλειτουργία υλικού γίνεται το πρόβλημά τους και όλα γίνονται αμέσως καλά για εσάς στο πλαίσιο μιας δυσλειτουργίας υλικού.
Είμαστε μια ελαφρώς αντισυμβατική εταιρεία. Εδώ όλοι μιλούν για "Kubernets", για σύννεφα - δεν έχουμε ούτε "Kubernets" ούτε σύννεφα. Αλλά έχουμε ράφια υλικού σε πολλά κέντρα δεδομένων, και είμαστε αναγκασμένοι να ζούμε με αυτό το υλικό, είμαστε αναγκασμένοι να είμαστε υπεύθυνοι για όλα. Επομένως, θα μιλήσουμε σε αυτό το πλαίσιο. Λοιπόν, για τα προβλήματα. Τα δύο πρώτα βγήκαν εκτός παρένθεσης.
Αλλαγή έκδοσης λογισμικού. Βάσεις
Οι προγραμματιστές μας δεν έχουν πρόσβαση στην παραγωγή. Γιατί αυτό? Απλώς έχουμε πιστοποίηση PCI DSS και οι προγραμματιστές μας απλά δεν έχουν το δικαίωμα να μπουν στο "προϊόν". Αυτό είναι, τελεία. Καθόλου. Επομένως, η ευθύνη ανάπτυξης τελειώνει ακριβώς τη στιγμή που η ανάπτυξη υποβάλλει την έκδοση για κυκλοφορία.
Η δεύτερη βάση μας που έχουμε, η οποία επίσης μας βοηθάει πολύ, είναι η απουσία μοναδικής μη τεκμηριωμένης γνώσης. Ελπίζω να είναι το ίδιο και για σένα. Γιατί αν δεν συμβαίνει αυτό, θα έχετε προβλήματα. Προβλήματα θα προκύψουν όταν αυτή η μοναδική, μη τεκμηριωμένη γνώση δεν είναι παρούσα την κατάλληλη στιγμή στο σωστό μέρος. Ας υποθέσουμε ότι έχετε ένα άτομο που ξέρει πώς να αναπτύξει ένα συγκεκριμένο στοιχείο - το άτομο δεν είναι εκεί, είναι σε διακοπές ή είναι άρρωστο - αυτό είναι, έχετε προβλήματα.
Και η τρίτη βάση στην οποία καταλήξαμε. Καταλήξαμε σε αυτό με πόνο, αίμα, δάκρυα - καταλήξαμε στο συμπέρασμα ότι οποιαδήποτε από τις κατασκευές μας περιέχει σφάλματα, ακόμα κι αν είναι χωρίς σφάλματα. Το αποφασίσαμε μόνοι μας: όταν αναπτύσσουμε κάτι, όταν ρίχνουμε κάτι στην παραγωγή, έχουμε μια κατασκευή με λάθη. Έχουμε διαμορφώσει τις απαιτήσεις που πρέπει να ικανοποιεί το σύστημά μας.
Απαιτήσεις για την αλλαγή της έκδοσης λογισμικού
Υπάρχουν τρεις απαιτήσεις:
- Πρέπει να αναστρέψουμε γρήγορα την ανάπτυξη.
- Πρέπει να ελαχιστοποιήσουμε τον αντίκτυπο μιας ανεπιτυχούς ανάπτυξης.
- Και πρέπει να είμαστε σε θέση να αναπτύξουμε γρήγορα παράλληλα.
Ακριβώς με αυτή τη σειρά! Γιατί; Επειδή, πρώτα απ 'όλα, κατά την ανάπτυξη μιας νέας έκδοσης, η ταχύτητα δεν είναι σημαντική, αλλά είναι σημαντικό για εσάς, εάν κάτι πάει στραβά, να επιστρέψετε γρήγορα και να έχετε ελάχιστο αντίκτυπο. Αλλά αν έχετε ένα σύνολο εκδόσεων στην παραγωγή, για τις οποίες αποδεικνύεται ότι υπάρχει σφάλμα (εκ των πραγμάτων, δεν υπήρξε ανάπτυξη, αλλά υπάρχει σφάλμα) - η ταχύτητα της επακόλουθης ανάπτυξης είναι σημαντική για εσάς. Τι έχουμε κάνει για να ικανοποιήσουμε αυτές τις απαιτήσεις; Καταφύγαμε στην ακόλουθη μεθοδολογία:
Είναι αρκετά γνωστό, δεν το έχουμε εφεύρει ποτέ - αυτό είναι το Blue/Green ανάπτυξη. Τι είναι? Πρέπει να έχετε ένα αντίγραφο για κάθε ομάδα διακομιστών στους οποίους είναι εγκατεστημένες οι εφαρμογές σας. Το αντίγραφο είναι "ζεστό": δεν υπάρχει κίνηση σε αυτό, αλλά ανά πάσα στιγμή αυτή η κίνηση μπορεί να σταλεί σε αυτό το αντίγραφο. Αυτό το αντίγραφο περιέχει την προηγούμενη έκδοση. Και κατά τη στιγμή της ανάπτυξης, ανοίγετε τον κώδικα σε ένα ανενεργό αντίγραφο. Στη συνέχεια, αλλάζετε μέρος της κυκλοφορίας (ή ολόκληρη) στη νέα έκδοση. Έτσι, για να αλλάξετε τη ροή κυκλοφορίας από την παλιά έκδοση στη νέα, πρέπει να κάνετε μόνο μία ενέργεια: πρέπει να αλλάξετε τον εξισορροπητή στο ανάντη, να αλλάξετε την κατεύθυνση - από το ένα ανάντη στο άλλο. Αυτό είναι πολύ βολικό και λύνει το πρόβλημα της γρήγορης εναλλαγής και της γρήγορης επαναφοράς.Εδώ η λύση στη δεύτερη ερώτηση είναι η ελαχιστοποίηση: μπορείτε να στείλετε μόνο μέρος της επισκεψιμότητάς σας σε μια νέα γραμμή, σε μια γραμμή με νέο κωδικό (ας είναι, για παράδειγμα, 2%). Και αυτά τα 2% δεν είναι 100%! Εάν χάσατε το 100% της επισκεψιμότητάς σας λόγω μιας ανεπιτυχούς ανάπτυξης, αυτό είναι τρομακτικό· εάν χάσατε το 2% της επισκεψιμότητάς σας, αυτό είναι δυσάρεστο, αλλά δεν είναι τρομακτικό. Επιπλέον, οι χρήστες πιθανότατα δεν θα το προσέξουν καν αυτό, γιατί σε ορισμένες περιπτώσεις (όχι σε όλες) ο ίδιος χρήστης, πατώντας το F5, θα μεταφερθεί σε άλλη, λειτουργική έκδοση.
Μπλε/Πράσινη ανάπτυξη. Δρομολόγηση
Ωστόσο, δεν είναι όλα τόσο απλά "Μπλε/Πράσινη ανάπτυξη"... Όλα τα στοιχεία μας μπορούν να χωριστούν σε τρεις ομάδες:
- αυτό είναι το frontend (σελίδες πληρωμών που βλέπουν οι πελάτες μας).
- πυρήνας επεξεργασίας?
- προσαρμογέας για εργασία με συστήματα πληρωμών (τράπεζες, MasterCard, Visa...).
Και υπάρχει μια απόχρωση εδώ - η απόχρωση βρίσκεται στη δρομολόγηση μεταξύ των γραμμών. Εάν απλώς αλλάξετε το 100% της επισκεψιμότητας, δεν έχετε αυτά τα προβλήματα. Αλλά αν θέλετε να αλλάξετε το 2%, αρχίζετε να κάνετε ερωτήσεις: "Πώς να το κάνετε αυτό;" Το πιο απλό πράγμα είναι ευθύ: μπορείτε να ρυθμίσετε το Round Robin στο nginx με τυχαία επιλογή και έχετε 2% αριστερά, 98% δεξιά. Αλλά αυτό δεν είναι πάντα κατάλληλο.
Για παράδειγμα, στην περίπτωσή μας, ένας χρήστης αλληλεπιδρά με το σύστημα με περισσότερα από ένα αιτήματα. Αυτό είναι φυσιολογικό: 2, 3, 4, 5 αιτήματα - τα συστήματά σας μπορεί να είναι τα ίδια. Και αν είναι σημαντικό για εσάς όλα τα αιτήματα του χρήστη να έρχονται στην ίδια γραμμή στην οποία ήρθε το πρώτο αίτημα ή (δεύτερο σημείο) όλα τα αιτήματα του χρήστη να έρχονται στη νέα γραμμή μετά τη μετάβαση (θα μπορούσε να είχε αρχίσει να εργάζεται νωρίτερα με το σύστημα, πριν από το διακόπτη), - τότε αυτή η τυχαία διανομή δεν είναι κατάλληλη για εσάς. Στη συνέχεια, υπάρχουν οι ακόλουθες επιλογές:
Η πρώτη επιλογή, η πιο απλή, βασίζεται στις βασικές παραμέτρους του πελάτη (IP Hash). Έχετε μια IP και τη διαιρείτε από τα δεξιά προς τα αριστερά με τη διεύθυνση IP. Στη συνέχεια, η δεύτερη περίπτωση που περιέγραψα θα λειτουργήσει για εσάς, όταν έγινε η ανάπτυξη, ο χρήστης θα μπορούσε ήδη να αρχίσει να εργάζεται με το σύστημά σας και από τη στιγμή της ανάπτυξης όλα τα αιτήματα θα πάνε σε μια νέα γραμμή (στην ίδια, ας πούμε).Εάν για κάποιο λόγο αυτό δεν σας ταιριάζει και πρέπει να στείλετε αιτήματα στη γραμμή όπου ήρθε το αρχικό, αρχικό αίτημα του χρήστη, τότε έχετε δύο επιλογές...
Πρώτη επιλογή: μπορείτε να αγοράσετε επί πληρωμή nginx+. Υπάρχει ένας μηχανισμός Sticky sessions, ο οποίος, κατόπιν αρχικής αίτησης του χρήστη, εκχωρεί μια συνεδρία στον χρήστη και τη συνδέει με το ένα ή το άλλο upstream. Όλα τα επόμενα αιτήματα χρήστη εντός της διάρκειας ζωής της περιόδου σύνδεσης θα αποστέλλονται στο ίδιο upstream όπου δημοσιεύτηκε η περίοδος λειτουργίας.Αυτό δεν μας ταίριαζε γιατί είχαμε ήδη κανονικό nginx. Η μετάβαση στο nginx+ δεν είναι ότι είναι ακριβό, απλώς ήταν κάπως επώδυνο για εμάς και όχι πολύ σωστό. Τα "Sticks Sessions", για παράδειγμα, δεν λειτούργησαν για εμάς για τον απλό λόγο ότι τα "Sticks Sessions" δεν επιτρέπουν τη δρομολόγηση με βάση το "Either-or". Εκεί μπορείτε να καθορίσετε τι κάνουμε εμείς οι "Sticks Sessions", για παράδειγμα, με διεύθυνση IP ή με διεύθυνση IP και cookie ή με μεταπαράμετρο, αλλά το "Ή-ή" είναι πιο περίπλοκο εκεί.
Επομένως, φτάσαμε στην τέταρτη επιλογή. Πήραμε το nginx σε στεροειδή (αυτό είναι το openresty) - αυτό είναι το ίδιο nginx, το οποίο υποστηρίζει επιπλέον τη συμπερίληψη των τελευταίων σεναρίων. Μπορείτε να γράψετε ένα τελευταίο σενάριο, να του δώσετε "ανοιχτό υπόλοιπο" και αυτό το τελευταίο σενάριο θα εκτελεστεί όταν έρθει το αίτημα του χρήστη.
Και γράψαμε, στην πραγματικότητα, ένα τέτοιο σενάριο, ορίσαμε τους εαυτούς μας «openresti» και σε αυτό το σενάριο ταξινομούμε 6 διαφορετικές παραμέτρους με συνένωση «Or». Ανάλογα με την παρουσία μιας ή άλλης παραμέτρου, γνωρίζουμε ότι ο χρήστης ήρθε στη μία ή την άλλη σελίδα, στη μία γραμμή ή στην άλλη.
Μπλε/Πράσινη ανάπτυξη. Πλεονεκτήματα και μειονεκτήματα
Φυσικά, ήταν πιθανώς δυνατό να το κάνουμε λίγο πιο απλό (χρησιμοποιήστε τις ίδιες "Sticky Sessions"), αλλά έχουμε επίσης μια τέτοια απόχρωση που όχι μόνο ο χρήστης αλληλεπιδρά μαζί μας στο πλαίσιο μιας επεξεργασίας μιας συναλλαγής... Αλλά και τα συστήματα πληρωμών αλληλεπιδρούν μαζί μας: Αφού επεξεργαστούμε τη συναλλαγή (με την αποστολή ενός αιτήματος στο σύστημα πληρωμών), λαμβάνουμε ένα coolback.
Και ας πούμε, εάν μέσα στο κύκλωμά μας μπορούμε να προωθήσουμε τη διεύθυνση IP του χρήστη σε όλα τα αιτήματα και να διαιρέσουμε τους χρήστες με βάση τη διεύθυνση IP, τότε δεν θα πούμε το ίδιο «Visa»: «Φίλε, είμαστε μια τέτοια ρετρό εταιρεία, φαίνεται να είναι διεθνής (στον ιστότοπο και στη Ρωσία)... Δώστε μας τη διεύθυνση IP του χρήστη σε ένα επιπλέον πεδίο, το πρωτόκολλό σας είναι τυποποιημένο»! Είναι σαφές ότι δεν θα συμφωνήσουν.
Επομένως, αυτό δεν λειτούργησε για εμάς - κάναμε openresty. Αντίστοιχα, με τη δρομολόγηση έχουμε κάτι σαν αυτό:Το Blue/Green Deployment έχει, κατά συνέπεια, τα πλεονεκτήματα που ανέφερα και τα μειονεκτήματα.
Δύο μειονεκτήματα:
- πρέπει να ασχοληθείτε με τη δρομολόγηση.
- το δεύτερο βασικό μειονέκτημα είναι το κόστος.
Χρειάζεστε διπλάσιους διακομιστές, χρειάζεστε διπλάσιους λειτουργικούς πόρους, χρειάζεται να ξοδέψετε διπλάσια προσπάθεια για να διατηρήσετε ολόκληρο αυτόν τον ζωολογικό κήπο.
Παρεμπιπτόντως, μεταξύ των πλεονεκτημάτων υπάρχει ένα ακόμη πράγμα που δεν έχω αναφέρει πριν: έχετε απόθεμα σε περίπτωση αύξησης του φορτίου. Εάν έχετε εκρηκτική αύξηση στο φορτίο, έχετε μεγάλο αριθμό χρηστών, τότε απλώς συμπεριλαμβάνετε τη δεύτερη γραμμή στη διανομή 50 έως 50 - και έχετε αμέσως διακομιστές x2 στο σύμπλεγμα σας μέχρι να λύσετε το πρόβλημα της ύπαρξης περισσότερων διακομιστών.
Πώς να κάνετε μια γρήγορη ανάπτυξη;
Μιλήσαμε για το πώς να λύσουμε το πρόβλημα της ελαχιστοποίησης και της γρήγορης επαναφοράς, αλλά το ερώτημα παραμένει: "Πώς να αναπτυχθεί γρήγορα;"
Εδώ είναι σύντομο και απλό.- Πρέπει να έχετε ένα σύστημα CD (Συνεχής Παράδοση) - δεν μπορείτε να ζήσετε χωρίς αυτό. Εάν έχετε έναν διακομιστή, μπορείτε να αναπτύξετε μη αυτόματα. Έχουμε περίπου μιάμιση χιλιάδες διακομιστές και μιάμιση χιλιάδες λαβές, φυσικά - μπορούμε να φυτέψουμε ένα τμήμα στο μέγεθος αυτού του δωματίου απλώς για να το αναπτύξουμε.
- Η ανάπτυξη πρέπει να είναι παράλληλη. Εάν η ανάπτυξή σας είναι διαδοχική, τότε όλα είναι άσχημα. Ένας διακομιστής είναι φυσιολογικός, θα αναπτύξετε μιάμιση χιλιάδες διακομιστές όλη την ημέρα.
- Και πάλι, για την επιτάχυνση, αυτό μάλλον δεν είναι πλέον απαραίτητο. Κατά την ανάπτυξη, το έργο συνήθως κατασκευάζεται. Έχετε ένα web project, υπάρχει ένα front-end τμήμα (κάνετε ένα web pack εκεί, μεταγλωττίζετε npm - κάτι τέτοιο) και αυτή η διαδικασία είναι, κατ 'αρχήν, βραχύβια - 5 λεπτά, αλλά αυτά τα 5 λεπτά μπορούν να είσαι επικριτικός. Γι' αυτό, για παράδειγμα, δεν το κάνουμε αυτό: αφαιρέσαμε αυτά τα 5 λεπτά, αναπτύσσουμε τεχνουργήματα.
Τι είναι ένα τεχνούργημα; Ένα τεχνούργημα είναι μια συναρμολογημένη κατασκευή στην οποία όλα τα μέρη συναρμολόγησης έχουν ήδη ολοκληρωθεί. Αποθηκεύουμε αυτό το τεχνούργημα στον χώρο αποθήκευσης τεχνουργημάτων. Κάποτε χρησιμοποιούσαμε δύο τέτοιους αποθηκευτικούς χώρους - ήταν το Nexus και τώρα το jFrog Artifactory) Αρχικά χρησιμοποιήσαμε το "Nexus" επειδή αρχίσαμε να εφαρμόζουμε αυτήν την προσέγγιση σε εφαρμογές java (του ταίριαζε πολύ). Μετά βάζουν μερικές από τις εφαρμογές γραμμένες σε PHP εκεί μέσα. και το "Nexus" δεν ήταν πλέον κατάλληλο, και ως εκ τούτου επιλέξαμε το jFrog Artefactory, το οποίο μπορεί να τεχνουργήσει σχεδόν τα πάντα. Φτάσαμε μάλιστα στο σημείο ότι σε αυτό το αποθετήριο τεχνουργημάτων αποθηκεύουμε τα δικά μας δυαδικά πακέτα που συλλέγουμε για διακομιστές.
Αύξηση εκρηκτικού φορτίου
Μιλήσαμε για αλλαγή της έκδοσης λογισμικού. Το επόμενο πράγμα που έχουμε είναι μια εκρηκτική αύξηση του φορτίου. Εδώ, μάλλον εννοώ με τον όρο εκρηκτική αύξηση του φορτίου όχι και πολύ σωστό...
Γράψαμε ένα νέο σύστημα - είναι προσανατολισμένο στις υπηρεσίες, μοντέρνο, όμορφο, εργαζόμενοι παντού, ουρές παντού, ασύγχρονος παντού. Και σε τέτοια συστήματα, τα δεδομένα μπορούν να ρέουν μέσω διαφορετικών ροών. Για την πρώτη συναλλαγή, μπορεί να χρησιμοποιηθεί ο 1ος, 3ος, 10ος εργαζόμενος, για τη δεύτερη συναλλαγή - ο 2ος, 4ος, 5ος. Και σήμερα, ας πούμε, το πρωί έχετε μια ροή δεδομένων που χρησιμοποιεί τους τρεις πρώτους εργάτες και το βράδυ αλλάζει δραματικά και τα πάντα χρησιμοποιούν τους άλλους τρεις εργαζόμενους.
Και εδώ αποδεικνύεται ότι πρέπει με κάποιο τρόπο να κλιμακώσετε τους εργαζομένους, πρέπει να κλιμακώσετε με κάποιο τρόπο τις υπηρεσίες σας, αλλά ταυτόχρονα να αποτρέψετε τη διόγκωση των πόρων.
Έχουμε καθορίσει τις απαιτήσεις μας. Αυτές οι απαιτήσεις είναι πολύ απλές: να υπάρχει ανακάλυψη υπηρεσίας, παραμετροποίηση - όλα είναι στάνταρ για την κατασκευή τέτοιων κλιμακούμενων συστημάτων, εκτός από ένα σημείο - απόσβεση πόρων. Είπαμε ότι δεν είμαστε έτοιμοι να αποσβέσουμε πόρους ώστε οι διακομιστές να ζεσταίνουν τον αέρα. Πήραμε το «Πρόξενο», πήραμε το «Nomad», που διαχειρίζεται τους εργάτες μας.Γιατί είναι αυτό ένα πρόβλημα για εμάς; Ας κάνουμε λίγο πίσω. Τώρα έχουμε περίπου 70 συστήματα πληρωμών πίσω μας. Το πρωί, η κίνηση περνά μέσω της Sberbank, στη συνέχεια η Sberbank έπεσε, για παράδειγμα, και τη μεταφέρουμε σε άλλο σύστημα πληρωμών. Είχαμε 100 εργαζόμενους πριν από τη Sberbank και μετά από αυτό πρέπει να αυξήσουμε απότομα 100 εργαζόμενους για ένα άλλο σύστημα πληρωμών. Και είναι επιθυμητό όλα αυτά να συμβαίνουν χωρίς ανθρώπινη συμμετοχή. Γιατί αν υπάρχει ανθρώπινη συμμετοχή, θα πρέπει να κάθεται εκεί 24 ώρες το 7ωρο ένας μηχανικός, ο οποίος θα πρέπει να το κάνει μόνο αυτό, γιατί τέτοιες βλάβες, όταν 70 συστήματα είναι πίσω σου, συμβαίνουν τακτικά.
Επομένως, κοιτάξαμε το Nomad, το οποίο έχει ανοιχτή IP, και γράψαμε το δικό μας, Scale-Nomad - ScaleNo, το οποίο κάνει περίπου τα εξής: παρακολουθεί την ανάπτυξη της ουράς και μειώνει ή αυξάνει τον αριθμό των εργαζομένων ανάλογα με τη δυναμική. της ουράς. Όταν το κάναμε, σκεφτήκαμε: "Ίσως μπορούμε να το ανοίξουμε κώδικα;" Ύστερα την κοίταξαν - ήταν τόσο απλή όσο δύο καπίκια.
Μέχρι στιγμής δεν το έχουμε ανοιχτό κώδικα, αλλά αν ξαφνικά μετά την αναφορά, αφού συνειδητοποιήσετε ότι χρειάζεστε κάτι τέτοιο, το χρειάζεστε, οι επαφές μου βρίσκονται στην τελευταία διαφάνεια - παρακαλώ γράψτε μου. Αν είναι τουλάχιστον 3-5 άτομα, θα το χορηγήσουμε.
Πως δουλεύει? Ας ρίξουμε μια ματιά! Κοιτάζοντας μπροστά: στην αριστερή πλευρά υπάρχει ένα κομμάτι της παρακολούθησής μας: αυτή είναι μια γραμμή, στην κορυφή είναι η ώρα της επεξεργασίας του συμβάντος, στη μέση είναι ο αριθμός των συναλλαγών, στο κάτω μέρος είναι ο αριθμός των εργαζομένων.Αν κοιτάξετε, υπάρχει ένα σφάλμα σε αυτή την εικόνα. Στο κορυφαίο γράφημα, ένα από τα γραφήματα κατέρρευσε σε 45 δευτερόλεπτα - ένα από τα συστήματα πληρωμών κατέρρευσε. Αμέσως, η κίνηση μπήκε σε 2 λεπτά και η ουρά άρχισε να μεγαλώνει σε ένα άλλο σύστημα πληρωμών, όπου δεν υπήρχαν εργαζόμενοι (δεν χρησιμοποιήσαμε πόρους - αντίθετα, πετάξαμε σωστά τον πόρο). Δεν θέλαμε να ζεσταθούμε - υπήρχε ένας ελάχιστος αριθμός, περίπου 5-10 εργαζόμενοι, αλλά δεν μπορούσαν να αντεπεξέλθουν.
Το τελευταίο γράφημα δείχνει μια "καμπούρα", που σημαίνει απλώς ότι το "Skaleno" διπλασίασε αυτό το ποσό. Και μετά, όταν το γράφημα έπεσε λίγο, το μείωσε λίγο - ο αριθμός των εργαζομένων άλλαξε αυτόματα. Έτσι λειτουργεί αυτό το πράγμα. Μιλήσαμε για το σημείο 2 - "Πώς να απαλλαγείτε γρήγορα από τους λόγους".
Παρακολούθηση. Πώς να εντοπίσετε γρήγορα το πρόβλημα;
Τώρα το πρώτο σημείο είναι "Πώς να εντοπίσετε γρήγορα το πρόβλημα;" Παρακολούθηση! Πρέπει να καταλάβουμε γρήγορα ορισμένα πράγματα. Ποια πράγματα πρέπει να καταλάβουμε γρήγορα;
Τρία πράγματα!- Πρέπει να κατανοήσουμε και να κατανοήσουμε γρήγορα την απόδοση των δικών μας πόρων.
- Πρέπει να κατανοούμε γρήγορα τις αστοχίες και να παρακολουθούμε την απόδοση των συστημάτων που είναι εξωτερικά σε εμάς.
- Το τρίτο σημείο είναι ο εντοπισμός λογικών σφαλμάτων. Αυτό συμβαίνει όταν το σύστημα λειτουργεί για εσάς, όλα είναι φυσιολογικά σύμφωνα με όλους τους δείκτες, αλλά κάτι δεν πάει καλά.
Μάλλον δεν θα σας πω κάτι τόσο ωραίο εδώ. Θα γίνω ο καπετάνιος Προφανής. Ψάξαμε για αυτό που κυκλοφορούσε στην αγορά. Έχουμε έναν «διασκεδαστικό ζωολογικό κήπο». Αυτό είναι το είδος του ζωολογικού κήπου που έχουμε τώρα:
Χρησιμοποιούμε το Zabbix για την παρακολούθηση του υλικού, για την παρακολούθηση των κύριων δεικτών των διακομιστών. Χρησιμοποιούμε το Okmeter για βάσεις δεδομένων. Χρησιμοποιούμε το "Grafana" και το "Prometheus" για όλους τους άλλους δείκτες που δεν ταιριάζουν στους δύο πρώτους, ορισμένους με "Grafana" και "Prometheus" και μερικούς με "Grafana" με "Influx" και Telegraf.Πριν από ένα χρόνο θέλαμε να χρησιμοποιήσουμε το New Relic. Ωραίο πράγμα, μπορεί να κάνει τα πάντα. Αλλά όσο μπορεί να κάνει τα πάντα, είναι τόσο ακριβή. Όταν αυξηθήκαμε σε όγκο 1,5 χιλιάδων διακομιστών, ένας πωλητής ήρθε σε εμάς και είπε: «Ας συνάψουμε μια συμφωνία για το επόμενο έτος». Εξετάσαμε την τιμή και είπαμε όχι, δεν θα το κάνουμε αυτό. Τώρα εγκαταλείπουμε το New Relic, έχουμε περίπου 15 διακομιστές υπό την παρακολούθηση του New Relic. Η τιμή αποδείχθηκε απολύτως άγρια.
Και υπάρχει ένα εργαλείο που εφαρμόσαμε μόνοι μας - αυτό είναι το Debugger. Στην αρχή το λέγαμε «Bagger», αλλά μετά πέρασε ένας καθηγητής Αγγλικών, γέλασε τρελά και το μετονόμασε σε «Debagger». Τι είναι? Αυτό είναι ένα εργαλείο που, στην πραγματικότητα, σε 15-30 δευτερόλεπτα σε κάθε στοιχείο, σαν ένα «μαύρο κουτί» του συστήματος, εκτελεί δοκιμές για τη συνολική απόδοση του στοιχείου.
Για παράδειγμα, αν υπάρχει μια εξωτερική σελίδα (σελίδα πληρωμής), απλά την ανοίγει και κοιτάζει πώς πρέπει να φαίνεται. Εάν πρόκειται για επεξεργασία, στέλνει μια δοκιμαστική «συναλλαγή» και βεβαιώνεται ότι αυτή η «συναλλαγή» φτάνει. Εάν πρόκειται για σύνδεση με συστήματα πληρωμών, πραγματοποιούμε ένα δοκιμαστικό αίτημα αναλόγως, όπου μπορούμε, και βλέπουμε ότι όλα είναι καλά μαζί μας.
Ποιοι δείκτες είναι σημαντικοί για την παρακολούθηση;
Τι παρακολουθούμε κυρίως; Ποιοι δείκτες είναι σημαντικοί για εμάς;
- Ο χρόνος απόκρισης / RPS στα μέτωπα είναι ένας πολύ σημαντικός δείκτης. Αμέσως απαντά ότι κάτι δεν πάει καλά με σένα.
- Ο αριθμός των επεξεργασμένων μηνυμάτων σε όλες τις ουρές.
- Αριθμός εργαζομένων.
- Βασικές μετρήσεις ορθότητας.
Το τελευταίο σημείο είναι η μέτρηση "business", "business". Εάν θέλετε να παρακολουθείτε το ίδιο πράγμα, πρέπει να ορίσετε μία ή δύο μετρήσεις που είναι οι κύριοι δείκτες για εσάς. Η μέτρησή μας είναι η απόδοση (αυτή είναι η αναλογία του αριθμού των επιτυχημένων συναλλαγών προς τη συνολική ροή συναλλαγών). Αν αλλάξει κάτι σε αυτό σε μεσοδιάστημα 5-10-15 λεπτών, σημαίνει ότι έχουμε προβλήματα (αν αλλάξει ριζικά).
Αυτό που φαίνεται για εμάς είναι ένα παράδειγμα ενός από τους πίνακες μας:
Στην αριστερή πλευρά υπάρχουν 6 γραφήματα, αυτά είναι σύμφωνα με τις γραμμές - τον αριθμό των εργαζομένων και τον αριθμό των μηνυμάτων στις ουρές. Στη δεξιά πλευρά – RPS, RTS. Παρακάτω είναι η ίδια μέτρηση "επιχειρήσεων". Και στη μέτρηση "business" μπορούμε να δούμε αμέσως ότι κάτι πήγε στραβά στα δύο μεσαία γραφήματα... Αυτό είναι απλώς ένα άλλο σύστημα που στέκεται πίσω μας και έχει πέσει.Το δεύτερο πράγμα που έπρεπε να κάνουμε ήταν να παρακολουθήσουμε την πτώση των εξωτερικών συστημάτων πληρωμών. Εδώ πήραμε το OpenTracing - έναν μηχανισμό, πρότυπο, παράδειγμα που σας επιτρέπει να παρακολουθείτε κατανεμημένα συστήματα. και άλλαξε λίγο. Το τυπικό παράδειγμα OpenTracing λέει ότι δημιουργούμε ένα ίχνος για κάθε μεμονωμένο αίτημα. Δεν το χρειαζόμασταν αυτό και το τυλίξαμε σε μια περίληψη, ίχνος συγκέντρωσης. Κατασκευάσαμε ένα εργαλείο που μας επιτρέπει να παρακολουθούμε την ταχύτητα των συστημάτων πίσω μας.
Το γράφημα μας δείχνει ότι ένα από τα συστήματα πληρωμών άρχισε να ανταποκρίνεται σε 3 δευτερόλεπτα - έχουμε προβλήματα. Επιπλέον, αυτό το πράγμα θα αντιδράσει όταν αρχίσουν τα προβλήματα, σε ένα διάστημα 20-30 δευτερολέπτων.Και η τρίτη κατηγορία σφαλμάτων παρακολούθησης που υπάρχουν είναι η λογική παρακολούθηση.
Για να είμαι ειλικρινής, δεν ήξερα τι να σχεδιάσω σε αυτή τη διαφάνεια, γιατί ψάχναμε για πολύ καιρό στην αγορά κάτι που θα μας ταίριαζε. Δεν βρήκαμε τίποτα, οπότε έπρεπε να το κάνουμε μόνοι μας.
Τι εννοώ με τον όρο λογική παρακολούθηση; Λοιπόν, φανταστείτε: κάνετε τον εαυτό σας ένα σύστημα (για παράδειγμα, έναν κλώνο Tinder). το έφτιαξες, το λανσάρισες. Ο επιτυχημένος διευθυντής Vasya Pupkin το έβαλε στο τηλέφωνό του, βλέπει μια κοπέλα εκεί, της αρέσει... και τα παρόμοια δεν πηγαίνουν στο κορίτσι - τα παρόμοια πηγαίνουν στον φύλακα Mikhalych από το ίδιο επιχειρηματικό κέντρο. Ο διευθυντής κατεβαίνει κάτω και μετά αναρωτιέται: «Γιατί του χαμογελάει τόσο ευχάριστα αυτός ο φύλακας Μιχάλιτς;»Σε τέτοιες καταστάσεις... Για εμάς, αυτή η κατάσταση ακούγεται λίγο διαφορετική, γιατί (έγραψα) πρόκειται για απώλεια φήμης που έμμεσα οδηγεί σε οικονομικές απώλειες. Η κατάστασή μας είναι το αντίθετο: μπορεί να υποστούμε άμεσες οικονομικές απώλειες - για παράδειγμα, εάν πραγματοποιήσαμε μια συναλλαγή ως επιτυχημένη, αλλά ήταν ανεπιτυχής (ή το αντίστροφο). Έπρεπε να γράψω το δικό μου εργαλείο που παρακολουθεί τον αριθμό των επιτυχημένων συναλλαγών με την πάροδο του χρόνου χρησιμοποιώντας επιχειρηματικούς δείκτες. Δεν βρήκα τίποτα στην αγορά! Αυτή ακριβώς την ιδέα ήθελα να μεταφέρω. Δεν υπάρχει τίποτα στην αγορά για να λύσει αυτό το είδος προβλήματος.
Αυτό αφορούσε τον γρήγορο εντοπισμό του προβλήματος.
Πώς να προσδιορίσετε τους λόγους ανάπτυξης
Η τρίτη ομάδα προβλημάτων που λύνουμε είναι αφού έχουμε εντοπίσει το πρόβλημα, αφού το έχουμε ξεφορτωθεί, καλό θα είναι να κατανοήσουμε τον λόγο ανάπτυξης, δοκιμής και να κάνουμε κάτι γι' αυτό. Κατά συνέπεια, πρέπει να διερευνήσουμε, πρέπει να αυξήσουμε τα κούτσουρα.
Αν μιλάμε για κούτσουρα (ο κύριος λόγος είναι τα κούτσουρα), το μεγαλύτερο μέρος των αρχείων καταγραφής μας είναι στο ELK Stack - σχεδόν όλοι έχουν το ίδιο. Για κάποιους μπορεί να μην είναι σε ELK, αλλά αν γράψετε αρχεία καταγραφής σε gigabyte, τότε αργά ή γρήγορα θα έρθετε στα ELK. Τα γράφουμε σε terabyte.
Υπάρχει ένα πρόβλημα εδώ. Το διορθώσαμε, διορθώσαμε το σφάλμα για τον χρήστη, αρχίσαμε να ανακαλύπτουμε τι υπήρχε, σκαρφαλώσαμε στο Kibana, πληκτρολογήσαμε το αναγνωριστικό συναλλαγής εκεί και πήραμε ένα ποδαρικό σαν αυτό (δείχνει πολλά). Και απολύτως τίποτα δεν είναι ξεκάθαρο σε αυτό το πόδι. Γιατί; Ναι, γιατί δεν είναι ξεκάθαρο ποιο μέρος ανήκει σε ποιον εργάτη, ποιο μέρος ανήκει σε ποιο εξάρτημα. Και εκείνη τη στιγμή συνειδητοποιήσαμε ότι χρειαζόμασταν εντοπισμό - το ίδιο OpenTracing για το οποίο μίλησα.Το σκεφτήκαμε πριν από ένα χρόνο, στρέψαμε την προσοχή μας προς την αγορά και υπήρχαν δύο εργαλεία εκεί - το "Zipkin" και το "Jaeger". Ο "Jager" είναι στην πραγματικότητα ένας τέτοιος ιδεολογικός κληρονόμος, ένας ιδεολογικός διάδοχος του "Zipkin". Όλα είναι καλά στο Zipkin, εκτός από το ότι δεν ξέρει πώς να συγκεντρώνει, δεν ξέρει πώς να συμπεριλάβει αρχεία καταγραφής στο ίχνος, μόνο ίχνος χρόνου. Και ο "Jager" το υποστήριξε αυτό.
Εξετάσαμε το "Jager": μπορείτε να κάνετε εφαρμογές οργάνων, μπορείτε να γράψετε σε Api (το πρότυπο Api για την PHP εκείνη την εποχή, ωστόσο, δεν είχε εγκριθεί - αυτό ήταν πριν από ένα χρόνο, αλλά τώρα έχει ήδη εγκριθεί), αλλά εκεί δεν ήταν απολύτως κανένας πελάτης. «Εντάξει», σκεφτήκαμε και γράψαμε τον δικό μας πελάτη. Τι πήραμε; Αυτό είναι περίπου αυτό που μοιάζει:
Στο Jaeger, δημιουργούνται διαστήματα για κάθε μήνυμα. Δηλαδή, όταν ένας χρήστης ανοίγει το σύστημα, βλέπει ένα ή δύο μπλοκ για κάθε εισερχόμενη αίτηση (1-2-3 - ο αριθμός των εισερχόμενων αιτημάτων από τον χρήστη, ο αριθμός των μπλοκ). Για να διευκολύνουμε τους χρήστες, προσθέσαμε ετικέτες στα αρχεία καταγραφής και τα χρονικά ίχνη. Αντίστοιχα, σε περίπτωση σφάλματος, η εφαρμογή μας θα επισημάνει το αρχείο καταγραφής με την κατάλληλη ετικέτα Σφάλματος. Μπορείτε να φιλτράρετε κατά ετικέτα Σφάλμα και θα εμφανίζονται μόνο οι εκτάσεις που περιέχουν αυτό το μπλοκ με σφάλμα. Έτσι φαίνεται αν επεκτείνουμε το εύρος:
Στο εσωτερικό του ανοίγματος υπάρχει ένα σύνολο από ίχνη. Σε αυτήν την περίπτωση, αυτά είναι τρία δοκιμαστικά ίχνη και το τρίτο ίχνος μας λέει ότι παρουσιάστηκε σφάλμα. Ταυτόχρονα, εδώ βλέπουμε ένα χρονικό ίχνος: έχουμε μια κλίμακα χρόνου στην κορυφή και βλέπουμε σε ποιο χρονικό διάστημα καταγράφηκε αυτό ή εκείνο το αρχείο καταγραφής.Αντίστοιχα, τα πράγματα πήγαν καλά για εμάς. Γράψαμε τη δική μας επέκταση και την κάναμε open source. Εάν θέλετε να εργαστείτε με την ανίχνευση, εάν θέλετε να εργαστείτε με το "Jager" στην PHP, υπάρχει η επέκτασή μας, καλώς να χρησιμοποιήσετε, όπως λένε:
Έχουμε αυτήν την επέκταση - είναι πελάτης για το OpenTracing Api, είναι κατασκευασμένο ως επέκταση php, δηλαδή, θα χρειαστεί να το συναρμολογήσετε και να το εγκαταστήσετε στο σύστημα. Πριν από ένα χρόνο δεν υπήρχε κάτι διαφορετικό. Τώρα υπάρχουν άλλοι πελάτες που είναι σαν εξαρτήματα. Εδώ εξαρτάται από εσάς: είτε θα αντλήσετε τα εξαρτήματα με έναν συνθέτη είτε θα χρησιμοποιήσετε την επέκταση ανάλογα με εσάς.Εταιρικά πρότυπα
Μιλήσαμε για τις τρεις εντολές. Η τέταρτη εντολή είναι η τυποποίηση των προσεγγίσεων. Περί τίνος πρόκειται? Πρόκειται για αυτό:
Γιατί υπάρχει εδώ η λέξη "εταιρική"; Όχι επειδή είμαστε μεγάλη ή γραφειοκρατική εταιρεία, όχι! Ήθελα να χρησιμοποιήσω τη λέξη "εταιρική" εδώ στο πλαίσιο ότι κάθε εταιρεία, κάθε προϊόν πρέπει να έχει τα δικά της πρότυπα, συμπεριλαμβανομένου και εσάς. Τι πρότυπα έχουμε;
- Έχουμε κανονισμούς ανάπτυξης. Δεν κινούμαστε πουθενά χωρίς αυτόν, δεν μπορούμε. Αναπτύσουμε περίπου 60 φορές την εβδομάδα, δηλαδή αναπτύσσουμε σχεδόν συνεχώς. Ταυτόχρονα, έχουμε, για παράδειγμα, στους κανονισμούς ανάπτυξης ένα ταμπού για τις αναπτύξεις την Παρασκευή - κατ' αρχήν, δεν αναπτύσσουμε.
- Απαιτούμε τεκμηρίωση. Ούτε ένα νέο εξάρτημα δεν μπαίνει στην παραγωγή αν δεν υπάρχει τεκμηρίωση για αυτό, ακόμα κι αν γεννήθηκε κάτω από την πένα των ειδικών μας στην RnD. Απαιτούμε από αυτούς οδηγίες ανάπτυξης, έναν χάρτη παρακολούθησης και μια πρόχειρη περιγραφή (καλά, όπως μπορούν να γράψουν οι προγραμματιστές) για το πώς λειτουργεί αυτό το στοιχείο, πώς να το αντιμετωπίσετε.
- Δεν λύνουμε την αιτία του προβλήματος, αλλά το πρόβλημα - αυτό που είπα ήδη. Είναι σημαντικό για εμάς να προστατεύουμε τον χρήστη από προβλήματα.
- Έχουμε άδειες. Για παράδειγμα, δεν θεωρούμε χρόνο διακοπής λειτουργίας εάν χάσουμε το 2% της επισκεψιμότητας μέσα σε δύο λεπτά. Αυτό βασικά δεν περιλαμβάνεται στα στατιστικά μας. Αν είναι περισσότερο σε ποσοστά ή προσωρινό, μετράμε ήδη.
- Και πάντα γράφουμε μεταθανάτια. Ό,τι κι αν συμβεί σε εμάς, κάθε κατάσταση όπου κάποιος συμπεριφέρθηκε ανώμαλα στην παραγωγή θα αντικατοπτρίζεται στη νεκροψία. Η νεκροψία είναι ένα έγγραφο στο οποίο γράφετε τι σας συνέβη, ένα λεπτομερές χρονοδιάγραμμα, τι κάνατε για να το διορθώσετε και (αυτό είναι ένα υποχρεωτικό μπλοκ!) τι θα κάνετε για να αποτρέψετε αυτό να συμβεί στο μέλλον. Αυτό είναι υποχρεωτικό και απαραίτητο για μεταγενέστερη ανάλυση.
Τι θεωρείται χρόνος διακοπής λειτουργίας;
Σε τι οδήγησαν όλα αυτά;Αυτό οδήγησε στο γεγονός ότι (είχαμε ορισμένα προβλήματα με τη σταθερότητα, αυτό δεν ταίριαζε ούτε σε πελάτες ούτε σε εμάς) τους τελευταίους 6 μήνες ο δείκτης σταθερότητάς μας ήταν 99,97. Μπορούμε να πούμε ότι αυτό δεν είναι πολύ. Ναι, έχουμε κάτι για να προσπαθήσουμε. Από αυτόν τον δείκτη, περίπου το ήμισυ είναι η σταθερότητα, σαν να λέγαμε, όχι της δικής μας, αλλά του τείχους προστασίας των εφαρμογών ιστού μας, που βρίσκεται μπροστά μας και χρησιμοποιείται ως υπηρεσία, αλλά οι πελάτες δεν ενδιαφέρονται γι' αυτό.
Μάθαμε να κοιμόμαστε το βράδυ. Τελικά! Πριν από έξι μήνες δεν μπορούσαμε. Και σε αυτό το σημείωμα με τα αποτελέσματα, θα ήθελα να κάνω μια σημείωση. Χθες το βράδυ υπήρξε μια υπέροχη αναφορά για το σύστημα ελέγχου ενός πυρηνικού αντιδραστήρα. Εάν τα άτομα που έγραψαν αυτό το σύστημα μπορούν να με ακούσουν, παρακαλώ ξεχάστε αυτό που είπα για το "2% δεν είναι χρόνος διακοπής λειτουργίας". Για εσάς, το 2% είναι χρόνος διακοπής, έστω και για δύο λεπτά!
Αυτό είναι όλο! Οι ερωτήσεις σας.
Σχετικά με τους εξισορροπητές και τη μετεγκατάσταση βάσεων δεδομένων
Ερώτηση του κοινού (εφεξής – Β): – Καλησπέρα. Σας ευχαριστώ πολύ για μια τέτοια αναφορά διαχειριστή! Μια σύντομη ερώτηση για τους ισορροπιστές σας. Ανέφερες ότι έχεις WAF, δηλαδή όπως καταλαβαίνω χρησιμοποιείς κάποιου είδους εξωτερικό εξισορροπητή...
EK: – Όχι, χρησιμοποιούμε τις υπηρεσίες μας ως εξισορροπητής. Σε αυτήν την περίπτωση, το WAF είναι αποκλειστικά ένα εργαλείο προστασίας DDoS για εμάς.
ΣΤΟ: – Μπορείτε να πείτε λίγα λόγια για τους ισορροπιστές;
EK: – Όπως είπα ήδη, πρόκειται για μια ομάδα διακομιστών στο openresty. Έχουμε πλέον 5 αποθεματικές ομάδες που ανταποκρίνονται αποκλειστικά... δηλαδή έναν διακομιστή που τρέχει αποκλειστικά openresty, κάνει μόνο proxy την κυκλοφορία. Αντίστοιχα, για να καταλάβουμε πόσα διατηρούμε: τώρα έχουμε μια τακτική ροή κυκλοφορίας αρκετών εκατοντάδων megabit. Αντιμετωπίζουν, νιώθουν καλά, δεν καταπονούνται καν.
ΣΤΟ: – Επίσης μια απλή ερώτηση. Εδώ είναι η ανάπτυξη του Μπλε/Πράσινου. Τι κάνετε, για παράδειγμα, με τις μετεγκαταστάσεις βάσεων δεδομένων;
EK: - Καλή ερώτηση! Κοιτάξτε, στην ανάπτυξη Μπλε/Πράσινο έχουμε ξεχωριστές ουρές για κάθε γραμμή. Δηλαδή, αν μιλάμε για ουρές συμβάντων που μεταδίδονται από εργαζόμενο σε εργαζόμενο, υπάρχουν ξεχωριστές ουρές για την μπλε γραμμή και για την πράσινη γραμμή. Αν μιλάμε για την ίδια τη βάση δεδομένων, τότε την περιορίσαμε σκόπιμα όσο μπορούσαμε, μετακινήσαμε τα πάντα σχεδόν σε ουρές· στη βάση δεδομένων αποθηκεύουμε μόνο μια στοίβα συναλλαγών. Και η στοίβα συναλλαγών μας είναι ίδια για όλες τις γραμμές. Με τη βάση δεδομένων σε αυτό το πλαίσιο: δεν τη χωρίζουμε σε μπλε και πράσινο, επειδή και οι δύο εκδόσεις του κώδικα πρέπει να γνωρίζουν τι συμβαίνει με τη συναλλαγή.
Φίλοι, έχω και ένα μικρό βραβείο να σας παρακινήσω - ένα βιβλίο. Και θα έπρεπε να το βραβεύσω για την καλύτερη ερώτηση.
ΣΤΟ: - Γειά σου. Ευχαριστώ για την αναφορά. Το ερώτημα είναι αυτό. Παρακολουθείτε τις πληρωμές, παρακολουθείτε τις υπηρεσίες με τις οποίες επικοινωνείτε... Πώς όμως παρακολουθείτε ώστε κάποιος να έρθει με κάποιο τρόπο στη σελίδα πληρωμής σας, να πραγματοποιήσει μια πληρωμή και το έργο να του πιστώσει χρήματα; Δηλαδή, πώς παρακολουθείτε ότι ο marchant είναι διαθέσιμος και έχει αποδεχτεί την επιστροφή σας;
EK: – Ο «Έμπορος» για εμάς σε αυτήν την περίπτωση είναι ακριβώς η ίδια εξωτερική υπηρεσία με το σύστημα πληρωμών. Παρακολουθούμε την ταχύτητα απόκρισης του εμπόρου.
Σχετικά με την κρυπτογράφηση της βάσης δεδομένων
ΣΤΟ: - Γειά σου. Έχω μια λίγο σχετική ερώτηση. Έχετε ευαίσθητα δεδομένα PCI DSS. Ήθελα να μάθω πώς αποθηκεύετε τα PAN σε ουρές στις οποίες πρέπει να μεταφέρετε; Χρησιμοποιείτε κάποια κρυπτογράφηση; Και αυτό οδηγεί στο δεύτερο ερώτημα: σύμφωνα με το PCI DSS, είναι απαραίτητο να επανακρυπτογραφείται περιοδικά η βάση δεδομένων σε περίπτωση αλλαγών (απόλυση διαχειριστών κ.λπ.) - τι συμβαίνει με την προσβασιμότητα σε αυτήν την περίπτωση;
EK: - Υπέροχη ερώτηση! Πρώτον, δεν αποθηκεύουμε PAN σε ουρές. Δεν έχουμε το δικαίωμα να αποθηκεύουμε το PAN οπουδήποτε με σαφή μορφή, κατ 'αρχήν, επομένως χρησιμοποιούμε μια ειδική υπηρεσία (την ονομάζουμε "Kademon") - αυτή είναι μια υπηρεσία που κάνει μόνο ένα πράγμα: λαμβάνει ένα μήνυμα ως είσοδο και στέλνει ένα κρυπτογραφημένο μήνυμα. Και αποθηκεύουμε τα πάντα με αυτό το κρυπτογραφημένο μήνυμα. Αντίστοιχα, το μήκος του κλειδιού μας είναι κάτω από ένα kilobyte, έτσι ώστε αυτό να είναι σοβαρό και αξιόπιστο.ΣΤΟ: – Χρειάζεστε 2 kilobyte τώρα;
EK: – Φαίνεται ότι μόλις χθες ήταν 256... Λοιπόν, πού αλλού;!
Κατά συνέπεια, αυτό είναι το πρώτο. Και δεύτερον, η λύση που υπάρχει, υποστηρίζει τη διαδικασία εκ νέου κρυπτογράφησης - υπάρχουν δύο ζεύγη "keks" (κλειδιά), τα οποία δίνουν "decks" που κρυπτογραφούν (το κλειδί είναι τα κλειδιά, το dek είναι παράγωγα των κλειδιών που κρυπτογραφούν) . Και αν ξεκινήσει η διαδικασία (συμβαίνει τακτικά, από 3 μήνες έως ± μερικούς), κατεβάζουμε ένα νέο ζευγάρι «κέικ» και κρυπτογραφούμε εκ νέου τα δεδομένα. Έχουμε ξεχωριστές υπηρεσίες που αφαιρούν όλα τα δεδομένα και τα κρυπτογραφούν με νέο τρόπο. Τα δεδομένα αποθηκεύονται δίπλα στο αναγνωριστικό του κλειδιού με το οποίο είναι κρυπτογραφημένα. Αντίστοιχα, μόλις κρυπτογραφήσουμε τα δεδομένα με νέα κλειδιά, διαγράφουμε το παλιό κλειδί.
Μερικές φορές οι πληρωμές πρέπει να γίνονται χειροκίνητα...
ΣΤΟ: – Δηλαδή, αν έχει έρθει επιστροφή χρημάτων για κάποια λειτουργία, θα την αποκρυπτογραφήσετε με το παλιό κλειδί;
EK: - Ναί.
ΣΤΟ: – Τότε μια ακόμη μικρή ερώτηση. Όταν συμβαίνει κάποιο είδος αποτυχίας, πτώσης ή συμβάντος, είναι απαραίτητο να προχωρήσετε τη συναλλαγή χειροκίνητα. Υπάρχει μια τέτοια κατάσταση.
EK: - Ναι μερικές φορές.
ΣΤΟ: – Από πού αντλείτε αυτά τα δεδομένα; Ή πηγαίνετε μόνοι σας σε αυτήν την εγκατάσταση αποθήκευσης;
EK: – Όχι, φυσικά, έχουμε κάποιου είδους σύστημα back-office που περιέχει μια διεπαφή για την υποστήριξή μας. Εάν δεν γνωρίζουμε σε ποια κατάσταση βρίσκεται η συναλλαγή (για παράδειγμα, μέχρι να ανταποκριθεί το σύστημα πληρωμών με χρονικό όριο), δεν γνωρίζουμε εκ των προτέρων, δηλαδή εκχωρούμε την τελική κατάσταση μόνο με πλήρη εμπιστοσύνη. Σε αυτήν την περίπτωση, εκχωρούμε τη συναλλαγή σε ειδική κατάσταση για χειροκίνητη επεξεργασία. Το πρωί, την επόμενη μέρα, μόλις η υποστήριξη λάβει πληροφορίες ότι τέτοιες ή τέτοιες συναλλαγές παραμένουν στο σύστημα πληρωμών, τις επεξεργάζεται χειροκίνητα σε αυτήν τη διεπαφή.
ΣΤΟ: – Έχω μερικές ερωτήσεις. Ένα από αυτά είναι η συνέχιση της ζώνης PCI DSS: πώς καταγράφετε το κύκλωμά τους; Αυτή η ερώτηση οφείλεται στο ότι ο προγραμματιστής θα μπορούσε να είχε βάλει οτιδήποτε στα αρχεία καταγραφής! Δεύτερη ερώτηση: πώς διαθέτετε επείγουσες επιδιορθώσεις; Η χρήση λαβών στη βάση δεδομένων είναι μία επιλογή, αλλά ενδέχεται να υπάρχουν δωρεάν επείγουσες επιδιορθώσεις - ποια είναι η διαδικασία εκεί; Και η τρίτη ερώτηση μάλλον σχετίζεται με RTO, RPO. Η διαθεσιμότητά σας ήταν 99,97, σχεδόν τέσσερα εννιά, αλλά όπως καταλαβαίνω, έχετε ένα δεύτερο κέντρο δεδομένων, ένα τρίτο κέντρο δεδομένων και ένα πέμπτο κέντρο δεδομένων... Πώς τα συγχρονίζετε, τα αναπαράγετε και οτιδήποτε άλλο;EK: - Ας ξεκινήσουμε με το πρώτο. Ήταν η πρώτη ερώτηση σχετικά με τα κούτσουρα; Όταν γράφουμε αρχεία καταγραφής, έχουμε ένα επίπεδο που καλύπτει όλα τα ευαίσθητα δεδομένα. Κοιτάζει τη μάσκα και τα πρόσθετα πεδία. Αντίστοιχα, τα αρχεία καταγραφής μας βγαίνουν με ήδη καλυμμένα δεδομένα και ένα κύκλωμα PCI DSS. Αυτή είναι μια από τις τακτικές εργασίες που ανατίθενται στο τμήμα δοκιμών. Απαιτείται να ελέγχουν κάθε εργασία, συμπεριλαμβανομένων των αρχείων καταγραφής που γράφουν, και αυτή είναι μια από τις κανονικές εργασίες κατά τη διάρκεια των ελέγχων κώδικα, προκειμένου να ελεγχθεί ότι ο προγραμματιστής δεν έγραψε κάτι. Οι επακόλουθοι έλεγχοι αυτού πραγματοποιούνται τακτικά από το τμήμα ασφάλειας πληροφοριών περίπου μία φορά την εβδομάδα: τα αρχεία καταγραφής για την τελευταία ημέρα λαμβάνονται επιλεκτικά και εκτελούνται μέσω ενός ειδικού σαρωτή-αναλυτή από δοκιμαστικούς διακομιστές για να ελεγχθούν τα πάντα.
Σχετικά με τις επείγουσες επιδιορθώσεις. Αυτό περιλαμβάνεται στους κανονισμούς ανάπτυξής μας. Έχουμε μια ξεχωριστή ρήτρα σχετικά με τις επείγουσες επιδιορθώσεις. Πιστεύουμε ότι αναπτύσσουμε επείγουσες επιδιορθώσεις όλο το εικοσιτετράωρο όταν τις χρειαζόμαστε. Μόλις συναρμολογηθεί η έκδοση, μόλις εκτελεστεί, μόλις έχουμε ένα τεχνούργημα, έχουμε έναν διαχειριστή συστήματος σε υπηρεσία σε μια κλήση από την υποστήριξη, και την αναπτύσσει τη στιγμή που είναι απαραίτητο.Περίπου «τέσσερα εννιάρια». Ο αριθμός που έχουμε τώρα έχει πραγματικά επιτευχθεί και προσπαθήσαμε για αυτό σε άλλο κέντρο δεδομένων. Τώρα έχουμε ένα δεύτερο κέντρο δεδομένων και αρχίζουμε να δρομολογούμε μεταξύ τους και το θέμα της αναπαραγωγής μεταξύ των κέντρων δεδομένων είναι πραγματικά μια μη τετριμμένη ερώτηση. Προσπαθήσαμε να το λύσουμε ταυτόχρονα χρησιμοποιώντας διαφορετικά μέσα: προσπαθήσαμε να χρησιμοποιήσουμε το ίδιο "Tarantula" - δεν μας βγήκε, θα σας πω αμέσως. Γι' αυτό καταλήξαμε να παραγγείλουμε τα "sens" χειροκίνητα. Στην πραγματικότητα, κάθε εφαρμογή στο σύστημά μας εκτελεί τον απαραίτητο συγχρονισμό «αλλαγή – έγινε» μεταξύ των κέντρων δεδομένων ασύγχρονα.
ΣΤΟ: – Αν πήρες δεύτερο, γιατί δεν πήρες και τρίτο; Γιατί κανείς δεν έχει χωρίσει ακόμα...
EK: – Αλλά δεν έχουμε Split Brain. Λόγω του γεγονότος ότι κάθε εφαρμογή οδηγείται από έναν multimaster, δεν μας ενδιαφέρει σε ποιο κέντρο ήρθε το αίτημα. Είμαστε έτοιμοι για το γεγονός ότι εάν ένα από τα κέντρα δεδομένων μας αποτύχει (βασιζόμαστε σε αυτό) και στη μέση ενός αιτήματος χρήστη μεταβεί στο δεύτερο κέντρο δεδομένων, είμαστε έτοιμοι να χάσουμε αυτόν τον χρήστη, πράγματι. αλλά αυτές θα είναι μονάδες, απόλυτες μονάδες.
ΣΤΟ: - Καλό απόγευμα. Ευχαριστώ για την αναφορά. Μιλήσατε για το πρόγραμμα εντοπισμού σφαλμάτων σας, το οποίο εκτελεί ορισμένες δοκιμαστικές συναλλαγές στην παραγωγή. Πες μας όμως για τις δοκιμαστικές συναλλαγές! Πόσο βαθιά πάει;
EK: – Διανύει τον πλήρη κύκλο ολόκληρου του εξαρτήματος. Για ένα εξάρτημα, δεν υπάρχει διαφορά μεταξύ μιας δοκιμαστικής συναλλαγής και μιας συναλλαγής παραγωγής. Αλλά από λογική άποψη, αυτό είναι απλώς ένα ξεχωριστό έργο στο σύστημα, στο οποίο εκτελούνται μόνο δοκιμαστικές συναλλαγές.
ΣΤΟ: -Πού το κόβεις; Εδώ ο Core έστειλε...
EK: – Είμαστε πίσω από το “Kor” σε αυτή την περίπτωση για δοκιμαστικές συναλλαγές... Έχουμε κάτι τέτοιο όπως δρομολόγηση: Το “Kor” ξέρει σε ποιο σύστημα πληρωμών να στείλει - στέλνουμε σε ένα ψεύτικο σύστημα πληρωμών, το οποίο απλώς δίνει ένα σήμα http και αυτό είναι όλο.
ΣΤΟ: – Πείτε μου, παρακαλώ, η αίτησή σας ήταν γραμμένη σε έναν τεράστιο μονόλιθο ή την κόψατε σε κάποιες υπηρεσίες ή ακόμα και σε μικροϋπηρεσίες;
EK: – Δεν έχουμε μονόλιθο, φυσικά, έχουμε εφαρμογή προσανατολισμένη στις υπηρεσίες. Αστειευόμαστε ότι η υπηρεσία μας είναι κατασκευασμένη από μονόλιθους - είναι πραγματικά αρκετά μεγάλοι. Είναι δύσκολο να το ονομάσουμε μικροϋπηρεσίες, αλλά αυτές είναι υπηρεσίες εντός των οποίων λειτουργούν οι εργαζόμενοι σε κατανεμημένες μηχανές.
Εάν η υπηρεσία στον διακομιστή έχει παραβιαστεί...
ΣΤΟ: – Τότε έχω την επόμενη ερώτηση. Ακόμα κι αν ήταν μονόλιθος, πάλι είπατε ότι έχετε πολλούς από αυτούς τους άμεσους διακομιστές, όλοι βασικά επεξεργάζονται δεδομένα και το ερώτημα είναι: «Σε περίπτωση παραβίασης ενός από τους άμεσους διακομιστές ή μιας εφαρμογής, οποιοσδήποτε μεμονωμένος σύνδεσμος , έχουν κάποιο είδος ελέγχου πρόσβασης; Ποιος από αυτούς μπορεί να κάνει τι; Με ποιον πρέπει να επικοινωνήσω για ποιες πληροφορίες;
EK: - Ναι σίγουρα. Οι απαιτήσεις ασφαλείας είναι αρκετά σοβαρές. Πρώτον, έχουμε ανοιχτές κινήσεις δεδομένων και οι θύρες είναι μόνο αυτές μέσω των οποίων προβλέπουμε εκ των προτέρων την κίνηση της κυκλοφορίας. Εάν ένα στοιχείο επικοινωνεί με τη βάση δεδομένων (ας πούμε, με τον Muskul) μέσω του 5-4-3-2, μόνο το 5-4-3-2 θα είναι ανοιχτό σε αυτό και άλλες θύρες και άλλες οδηγίες κυκλοφορίας δεν θα είναι διαθέσιμες. Επιπλέον, πρέπει να καταλάβετε ότι στην παραγωγή μας υπάρχουν περίπου 10 διαφορετικοί βρόχοι ασφαλείας. Και ακόμη κι αν η εφαρμογή παραβιάστηκε με κάποιο τρόπο, ο Θεός φυλάξοι, ο εισβολέας δεν θα μπορεί να έχει πρόσβαση στην κονσόλα διαχείρισης διακομιστή, επειδή αυτή είναι μια διαφορετική ζώνη ασφαλείας δικτύου.ΣΤΟ: – Και σε αυτό το πλαίσιο, το πιο ενδιαφέρον για μένα είναι ότι έχετε συγκεκριμένες συμβάσεις με υπηρεσίες - τι μπορούν να κάνουν, με ποιες «ενέργειες» μπορούν να επικοινωνήσουν μεταξύ τους... Και σε μια κανονική ροή, κάποιες συγκεκριμένες υπηρεσίες ζητούν σειρά, μια λίστα με «ενέργειες» από την άλλη. Δεν φαίνεται να στρέφονται σε άλλους σε μια φυσιολογική κατάσταση και έχουν άλλους τομείς ευθύνης. Εάν ένα από αυτά παραβιαστεί, θα μπορέσει να διαταράξει τις «ενέργειες» αυτής της υπηρεσίας;..
EK: - Καταλαβαίνω. Εάν σε μια κανονική κατάσταση με άλλο διακομιστή επιτρεπόταν καθόλου η επικοινωνία, τότε ναι. Σύμφωνα με τη σύμβαση SLA, δεν παρακολουθούμε ότι επιτρέπονται μόνο οι πρώτες 3 «ενέργειες» και δεν σας επιτρέπονται οι 4 «ενέργειες». Αυτό είναι μάλλον περιττό για εμάς, επειδή έχουμε ήδη ένα σύστημα προστασίας 4 επιπέδων, καταρχήν, για κυκλώματα. Προτιμούμε να αμυνόμαστε με τα περιγράμματα, παρά στο επίπεδο των εσωτερικών.
Πώς λειτουργούν οι Visa, MasterCard και Sberbank
ΣΤΟ: – Θέλω να διευκρινίσω ένα σημείο σχετικά με την αλλαγή χρήστη από το ένα κέντρο δεδομένων στο άλλο. Από όσο γνωρίζω, η Visa και η MasterCard λειτουργούν χρησιμοποιώντας το δυαδικό σύγχρονο πρωτόκολλο 8583 και υπάρχουν μίξεις εκεί. Και ήθελα να μάθω, τώρα εννοούμε αλλαγή – είναι απευθείας «Visa» και «MasterCard» ή πριν από τα συστήματα πληρωμών, πριν από την επεξεργασία;
EK: - Αυτό είναι πριν τις μίξεις. Τα μείγματά μας βρίσκονται στο ίδιο κέντρο δεδομένων.
ΣΤΟ: – Σε γενικές γραμμές, έχετε ένα σημείο σύνδεσης;
EK: – «Visa» και «MasterCard» - ναι. Απλώς επειδή η Visa και η MasterCard απαιτούν αρκετά σοβαρές επενδύσεις σε υποδομές για τη σύναψη χωριστών συμβάσεων για την απόκτηση ενός δεύτερου ζεύγους μιγμάτων, για παράδειγμα. Είναι δεσμευμένα σε ένα κέντρο δεδομένων, αλλά εάν, ο Θεός φυλάξοι, το κέντρο δεδομένων μας, όπου υπάρχουν μίξεις για σύνδεση με Visa και MasterCard, πεθάνει, τότε θα έχουμε χαθεί μια σύνδεση με Visa και MasterCard...
ΣΤΟ: – Πώς μπορούν να γίνουν κράτηση; Ξέρω ότι η Visa επιτρέπει μόνο μία σύνδεση κατ' αρχήν!
EK: – Προμηθεύουν μόνοι τους τον εξοπλισμό. Σε κάθε περίπτωση, λάβαμε εξοπλισμό που είναι εντελώς περιττός στο εσωτερικό.
ΣΤΟ: – Δηλαδή το περίπτερο είναι από το Connects Orange;..
EK: - Ναί.
ΣΤΟ: – Αλλά τι γίνεται με αυτήν την περίπτωση: εάν το κέντρο δεδομένων σας εξαφανιστεί, πώς μπορείτε να συνεχίσετε να το χρησιμοποιείτε; Ή απλά σταματάει η κίνηση;
EK: - Οχι. Σε αυτή την περίπτωση, απλώς θα αλλάξουμε την επισκεψιμότητα σε άλλο κανάλι, το οποίο, φυσικά, θα είναι πιο ακριβό για εμάς και πιο ακριβό για τους πελάτες μας. Αλλά η κίνηση δεν θα περάσει μέσω της απευθείας σύνδεσής μας με Visa, MasterCard, αλλά μέσω της υπό όρους Sberbank (πολύ υπερβολική).
Ζητώ συγγνώμη αν προσέβαλα τους υπαλλήλους της Sberbank. Αλλά σύμφωνα με τα στατιστικά μας, μεταξύ των ρωσικών τραπεζών, η Sberbank πέφτει πιο συχνά. Δεν περνάει μήνας χωρίς να πέσει κάτι στη Sberbank.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com