Σε δημοσιεύσεις στο Habré, έγραψα ήδη για την εμπειρία μου από τη δημιουργία συνεργασιών με την ομάδα μου ( μιλά για τον τρόπο σύναψης μιας συμφωνίας εταιρικής σχέσης κατά την έναρξη μιας νέας επιχείρησης, ώστε η επιχείρηση να μην καταρρεύσει). Και τώρα θα ήθελα να μιλήσω για το πώς να οικοδομήσουμε συνεργασίες με πελάτες, αφού χωρίς αυτούς δεν θα υπάρχει τίποτα να καταρρεύσει. Ελπίζω αυτό το άρθρο να είναι χρήσιμο σε νεοφυείς επιχειρήσεις που αρχίζουν να πωλούν το προϊόν τους σε μεγάλες επιχειρήσεις.
Αυτήν τη στιγμή ηγούμαι μιας startup που ονομάζεται MONQ Digital lab, όπου η ομάδα μου και εγώ αναπτύσσουμε ένα προϊόν για την αυτοματοποίηση των διαδικασιών υποστήριξης και λειτουργίας εταιρικής πληροφορικής. Η είσοδος στην αγορά δεν είναι εύκολη υπόθεση και ξεκινήσαμε με λίγη εργασία, περάσαμε από ειδικούς της αγοράς, τους συνεργάτες μας και πραγματοποιήσαμε τμηματοποίηση της αγοράς. Το κύριο ερώτημα ήταν να καταλάβουμε «ποιων πόνους μπορούμε να θεραπεύσουμε καλύτερα;»
Οι τράπεζες μπήκαν στα TOP 3 τμήματα. Και φυσικά, οι πρώτοι στη λίστα ήταν οι Tinkoff και Sberbank. Όταν επισκεφτήκαμε ειδικούς της τραπεζικής αγοράς, είπαν: εισαγάγετε το προϊόν σας εκεί και ο δρόμος προς την τραπεζική αγορά θα είναι ανοιχτός. Προσπαθήσαμε να μπούμε τόσο εκεί όσο και εκεί, αλλά η αποτυχία μας περίμενε στη Sberbank και τα παιδιά από την Tinkoff αποδείχθηκαν πολύ πιο ανοιχτά σε παραγωγική επικοινωνία με ρωσικές νεοσύστατες εταιρείες (ίσως λόγω του γεγονότος ότι η Sber εκείνη την εποχή σχεδόν ένα δισεκατομμύριο από τους δυτικούς ανταγωνιστές μας). Μέσα σε ένα μήνα ξεκινήσαμε ένα πιλοτικό έργο. Πώς έγινε, διαβάστε παρακάτω.
Ασχολούμασταν πολλά χρόνια με θέματα λειτουργίας και παρακολούθησης, τώρα υλοποιούμε το προϊόν μας στο δημόσιο, στις ασφαλίσεις, στις τράπεζες, στις τηλεπικοινωνιακές εταιρείες, μια υλοποίηση ήταν με αεροπορική εταιρεία (πριν το έργο δεν κάναμε καν σκεφτείτε ότι η αεροπορία ήταν μια βιομηχανία εξαρτώμενη από την πληροφορική και τώρα ελπίζουμε πραγματικά, παρά το COVID, ότι η εταιρεία θα αναδυθεί και θα απογειωθεί).
Το προϊόν που κατασκευάζουμε ανήκει στο εταιρικό λογισμικό, το τμήμα AIOps (Τεχνητή Νοημοσύνη για Λειτουργίες πληροφορικής ή ITOps). Οι κύριοι στόχοι της εφαρμογής τέτοιων συστημάτων καθώς το επίπεδο ωριμότητας της διαδικασίας στην εταιρεία αυξάνεται:
- Κατάσβεση πυρκαγιών: εντοπισμός αστοχιών, εκκαθάριση της ροής ειδοποιήσεων από συντρίμμια, ανάθεση εργασιών και συμβάντων στους υπεύθυνους.
- Αυξήστε την αποτελεσματικότητα της υπηρεσίας πληροφορικής: μειώστε το χρόνο για την επίλυση συμβάντων, υποδείξτε τα αίτια των αστοχιών, αυξήστε τη διαφάνεια της κατάστασης πληροφορικής.
- Αυξήστε την αποτελεσματικότητα της επιχείρησης: μειώστε τον όγκο της χειρωνακτικής εργασίας, μειώστε τους κινδύνους, αυξήστε την αφοσίωση των πελατών.
Σύμφωνα με την εμπειρία μας, οι τράπεζες έχουν τα ακόλουθα «πονήματα» με την παρακολούθηση από κοινού με όλες τις μεγάλες υποδομές πληροφορικής:
- «Ποιος ξέρει τι»: υπάρχουν πολλά τεχνικά τμήματα, σχεδόν όλοι έχουν τουλάχιστον ένα σύστημα παρακολούθησης και τα περισσότερα έχουν περισσότερα από ένα.
- «Σμήνος κουνουπιών» ειδοποιήσεων: κάθε σύστημα δημιουργεί εκατοντάδες και βομβαρδίζει όλους τους υπεύθυνους μαζί τους (μερικές φορές και μεταξύ τμημάτων). Είναι δύσκολο να διατηρείται συνεχώς το επίκεντρο του ελέγχου σε κάθε κοινοποίηση· ο επείγων χαρακτήρας και η σημασία τους εξομαλύνονται λόγω του μεγάλου αριθμού.
- Οι μεγάλες τράπεζες - οι ηγέτες του κλάδου θέλουν όχι μόνο να παρακολουθούν συνεχώς τα συστήματά τους, να γνωρίζουν πού υπάρχουν αστοχίες, αλλά και την πραγματική μαγεία της τεχνητής νοημοσύνης - να κάνουν τα συστήματα να αυτοπαρακολουθούν, να προβλέπουν και να αυτοδιορθώνονται.
Όταν ήρθαμε στην πρώτη συνάντηση στο Tinkoff, μας είπαν αμέσως ότι δεν είχαν κανένα πρόβλημα με την παρακολούθηση και τίποτα δεν τους έβλαψε, και η κύρια ερώτηση ήταν: «Τι μπορούμε να προσφέρουμε σε αυτούς που ήδη πάνε καλά;»
Η συζήτηση ήταν μεγάλη, συζητήσαμε πώς χτίζονται οι μικροϋπηρεσίες τους, πώς λειτουργούν τα τμήματα, ποια προβλήματα υποδομής είναι πιο ευαίσθητα, ποια είναι λιγότερο ευαίσθητα για τους χρήστες, πού είναι τα «τυφλά σημεία» και ποιοι είναι οι στόχοι και οι SLA τους.
Παρεμπιπτόντως, τα SLA της τράπεζας είναι πραγματικά εντυπωσιακά. Για παράδειγμα, ένα περιστατικό διαθεσιμότητας δικτύου προτεραιότητας XNUMX μπορεί να χρειαστούν μόνο λίγα λεπτά για να επιλυθεί. Το κόστος του σφάλματος και του χρόνου διακοπής εδώ, φυσικά, είναι εντυπωσιακό.
Ως αποτέλεσμα, εντοπίσαμε διάφορους τομείς συνεργασίας:
- το πρώτο στάδιο είναι η παρακολούθηση με ομπρέλα για να αυξηθεί η ταχύτητα επίλυσης του συμβάντος
- το δεύτερο στάδιο είναι η αυτοματοποίηση διαδικασιών για τη μείωση των κινδύνων και τη μείωση του κόστους για την κλιμάκωση του τμήματος πληροφορικής.
Αρκετές «λευκές κηλίδες» μπορούσαν να χρωματιστούν με τα φωτεινά χρώματα των ειδοποιήσεων μόνο με την επεξεργασία πληροφοριών από διάφορα συστήματα παρακολούθησης, καθώς ήταν αδύνατο να ληφθούν άμεσα μετρήσεις· ήταν επίσης απαραίτητο να συγκεντρωθούν δεδομένα από διαφορετικά συστήματα παρακολούθησης σε «μία οθόνη» προκειμένου για να κατανοήσουν τη συνολική εικόνα του τι συνέβαινε. Οι «ομπρέλες» είναι κατάλληλες για αυτήν την εργασία και τότε ικανοποιήσαμε αυτές τις απαιτήσεις.
Ένα πολύ σημαντικό πράγμα, κατά τη γνώμη μας, στις σχέσεις με τους πελάτες είναι η ειλικρίνεια. Μετά την πρώτη συζήτηση και τον υπολογισμό του κόστους της άδειας, ειπώθηκε ότι επειδή το κόστος είναι τόσο χαμηλό, ίσως αξίζει να αγοράσετε μια άδεια αμέσως (σε σύγκριση με την Dynatrace Klyuch-Astrom από το παραπάνω άρθρο σχετικά με την πράσινη τράπεζα, η άδεια δεν κοστίζει το ένα τρίτο του δισεκατομμυρίου, αλλά 12 χιλιάδες ρούβλια το μήνα για 1 gigabyte, για το Sber θα κόστιζε αρκετές φορές φθηνότερα). Αλλά τους είπαμε αμέσως τι έχουμε και τι όχι. Ίσως ένας αντιπρόσωπος πωλήσεων από μια μεγάλη εταιρεία ολοκλήρωσης θα μπορούσε να πει "ναι, μπορούμε να κάνουμε τα πάντα, φυσικά να αγοράσουμε την άδειά μας", αλλά αποφασίσαμε να βάλουμε όλα τα χαρτιά μας στο τραπέζι. Κατά τη στιγμή της κυκλοφορίας, το κουτί μας δεν είχε ενσωμάτωση με τον Prometheus και επρόκειτο να κυκλοφορήσει μια νέα έκδοση με υποσύστημα αυτοματισμού, αλλά δεν την έχουμε αποστείλει ακόμα στους πελάτες.
Ξεκίνησε το πιλοτικό έργο, καθορίστηκαν τα όριά του και μας δόθηκε 2 μήνες. Τα κύρια καθήκοντα ήταν:
- ετοιμάστε μια νέα έκδοση της πλατφόρμας και αναπτύξτε την στην υποδομή της τράπεζας
- Συνδέστε 2 συστήματα παρακολούθησης (Zabbix και Prometheus).
- αποστολή ειδοποιήσεων στους υπεύθυνους στο Slack και μέσω SMS.
- εκτέλεση σεναρίων αυτόματης θεραπείας.
Ο πρώτος μήνας του πιλοτικού έργου δαπανήθηκε για την προετοιμασία μιας νέας έκδοσης της πλατφόρμας σε super-fast mode για τις ανάγκες του πιλοτικού έργου. Η νέα έκδοση περιλαμβάνει άμεσα ενσωμάτωση με τον Prometheus και auto-healing. Χάρη στην ομάδα ανάπτυξής μας, δεν κοιμήθηκαν για αρκετές νύχτες, αλλά κυκλοφόρησαν όσα υποσχέθηκαν χωρίς να χάσουν τις προθεσμίες για άλλες δεσμεύσεις που είχαν αναληφθεί στο παρελθόν.
Ενώ ρυθμίζαμε το πιλότο, αντιμετωπίσαμε ένα νέο πρόβλημα που θα μπορούσε να κλείσει το έργο νωρίτερα: για να στείλουμε ειδοποιήσεις σε άμεσους αγγελιοφόρους και μέσω SMS, χρειαζόμασταν εισερχόμενες και εξερχόμενες συνδέσεις με διακομιστές Microsoft Azure (εκείνη την εποχή χρησιμοποιούσαμε αυτήν την πλατφόρμα για αποστολή ειδοποιήσεων στο Slack) και μια εξωτερική υπηρεσία αποστολής SMS. Αλλά σε αυτό το έργο, η ασφάλεια ήταν μια ιδιαίτερη εστίαση. Σύμφωνα με την πολιτική της τράπεζας, τέτοιες «τρύπες» δεν μπορούσαν να ανοίξουν σε καμία περίπτωση. Όλα έπρεπε να λειτουργήσουν από έναν κλειστό βρόχο. Μας προσφέρθηκε να χρησιμοποιήσουμε το API των δικών μας εσωτερικών υπηρεσιών που στέλνουν ειδοποιήσεις στο Slack και μέσω SMS, αλλά δεν είχαμε την ευκαιρία να συνδέσουμε αυτές τις υπηρεσίες από το κουτί.
Μια βραδιά συζήτησης με την ομάδα ανάπτυξης ολοκληρώθηκε με μια επιτυχημένη αναζήτηση λύσης. Έχοντας ψάξει στο backlog, βρήκαμε μια εργασία για την οποία δεν είχαμε ποτέ αρκετό χρόνο και προτεραιότητα - να δημιουργήσουμε ένα σύστημα προσθήκης ώστε οι ομάδες υλοποίησης ή ο πελάτης να μπορούν να γράφουν πρόσθετα οι ίδιοι, επεκτείνοντας τις δυνατότητες της πλατφόρμας.
Μας έμεινε όμως ακριβώς ένας μήνας, κατά τον οποίο έπρεπε να εγκαταστήσουμε τα πάντα, να διαμορφώσουμε και να αναπτύξουμε τον αυτοματισμό.
Σύμφωνα με τον Sergei, τον επικεφαλής αρχιτέκτονά μας, χρειάζεται τουλάχιστον ένας μήνας για την εφαρμογή του συστήματος plug-in.
Δεν είχαμε χρόνο...
Υπήρχε μόνο μία λύση - πηγαίνετε στον πελάτη και πείτε τα πάντα όπως είναι. Συζητήστε μαζί τη μετατόπιση της προθεσμίας. Και λειτούργησε. Μας δόθηκε επιπλέον 2 εβδομάδες. Είχαν επίσης τις δικές τους προθεσμίες και εσωτερικές υποχρεώσεις για να δείξουν αποτελέσματα, αλλά είχαν 2 εφεδρικές εβδομάδες. Στο τέλος, τα βάζουμε όλα στη γραμμή. Ήταν αδύνατο να μπλέξουμε. Η ειλικρίνεια και η εταιρική προσέγγιση απέδωσαν και πάλι.
Ως αποτέλεσμα του πιλοτικού προγράμματος, προέκυψαν αρκετά σημαντικά τεχνικά αποτελέσματα και συμπεράσματα:
Δοκιμάσαμε τη νέα λειτουργικότητα για την επεξεργασία ειδοποιήσεων
Το αναπτυγμένο σύστημα άρχισε να λαμβάνει σωστά ειδοποιήσεις από τον Προμηθέα και να τους ομαδοποιεί. Οι ειδοποιήσεις για το πρόβλημα από τον πελάτη Prometheus πετούν κάθε 30 δευτερόλεπτα (η ομαδοποίηση ανά ώρα δεν είναι ενεργοποιημένη) και αναρωτιόμασταν αν θα ήταν δυνατό να ομαδοποιηθούν στην ίδια την «ομπρέλα». Αποδείχθηκε ότι είναι δυνατό - η ρύθμιση της επεξεργασίας ειδοποιήσεων στην πλατφόρμα υλοποιείται από ένα σενάριο. Αυτό καθιστά δυνατή την εφαρμογή σχεδόν οποιασδήποτε λογικής για την επεξεργασία τους. Έχουμε ήδη εφαρμόσει την τυπική λογική στην πλατφόρμα με τη μορφή προτύπων - αν δεν θέλετε να βρείτε κάτι δικό σας, μπορείτε να χρησιμοποιήσετε ένα έτοιμο.
Διεπαφή "Συνθετική σκανδάλη". Ρύθμιση επεξεργασίας ειδοποιήσεων από συνδεδεμένα συστήματα παρακολούθησης
Κατασκεύασε την κατάσταση «υγείας» του συστήματος
Με βάση ειδοποιήσεις, δημιουργήθηκαν συμβάντα παρακολούθησης που επηρέασαν την υγεία των μονάδων διαμόρφωσης (CU). Εφαρμόζουμε ένα μοντέλο υπηρεσίας πόρων (RSM), το οποίο μπορεί να χρησιμοποιήσει είτε ένα εσωτερικό CMDB είτε να συνδέσει ένα εξωτερικό - κατά τη διάρκεια του πιλοτικού έργου ο πελάτης δεν συνέδεσε το δικό του CMDB.
Διεπαφή για εργασία με το μοντέλο πόρου-υπηρεσίας. Πιλοτικό RSM.
Λοιπόν, στην πραγματικότητα, ο πελάτης έχει τελικά μια ενιαία οθόνη παρακολούθησης, όπου είναι ορατά συμβάντα από διαφορετικά συστήματα. Επί του παρόντος, δύο συστήματα συνδέονται με την «ομπρέλα» - το Zabbix και το Prometheus, και ένα εσωτερικό σύστημα παρακολούθησης της ίδιας της πλατφόρμας.
Διεπαφή Analytics. Ενιαία οθόνη παρακολούθησης.
Ξεκίνησε η αυτοματοποίηση διαδικασιών
Η παρακολούθηση συμβάντων πυροδότησε την εκκίνηση προκαθορισμένων ενεργειών - αποστολή ειδοποιήσεων, εκτέλεση σεναρίων, εγγραφή/εμπλουτισμός περιστατικών - η τελευταία δεν δοκιμάστηκε με αυτόν τον συγκεκριμένο πελάτη, επειδή στο πιλοτικό έργο δεν υπήρχε ενοποίηση με το γραφείο εξυπηρέτησης.
Διεπαφή ρυθμίσεων ενεργειών. Στείλτε ειδοποιήσεις στο Slack και επανεκκινήστε τον διακομιστή.
Διευρυμένη λειτουργικότητα προϊόντος
Όταν συζητούσαμε για σενάρια αυτοματισμού, ο πελάτης ζήτησε υποστήριξη bash και μια διεπαφή στην οποία θα μπορούσαν να διαμορφωθούν εύκολα αυτά τα σενάρια. Η νέα έκδοση έχει κάνει λίγο περισσότερα (την ικανότητα να γράφεις πλήρεις λογικές κατασκευές στο Lua με υποστήριξη για cURL, SSH και SNMP) και έχει εφαρμόσει λειτουργικότητα που σου επιτρέπει να διαχειρίζεσαι τον κύκλο ζωής ενός σεναρίου (δημιουργία, επεξεργασία, έλεγχος έκδοσης , διαγραφή και αρχειοθέτηση).
Διεπαφή για εργασία με σενάρια αυτόματης θεραπείας. Σενάριο επανεκκίνησης διακομιστή μέσω SSH.
Βασικά ευρήματα
Κατά τη διάρκεια του πιλοτικού προγράμματος, δημιουργήθηκαν επίσης ιστορίες χρηστών που βελτιώνουν την τρέχουσα λειτουργικότητα και αυξάνουν την αξία για τον πελάτη, εδώ είναι μερικές από αυτές:
- να εφαρμόσει τη δυνατότητα προώθησης μεταβλητών απευθείας από την ειδοποίηση στο σενάριο αυτόματης θεραπείας.
- προσθέστε εξουσιοδότηση στην πλατφόρμα μέσω της υπηρεσίας καταλόγου Active Directory.
Και λάβαμε περισσότερες παγκόσμιες προκλήσεις - να «χτίσουμε» το προϊόν με άλλες δυνατότητες:
- αυτόματη κατασκευή ενός μοντέλου υπηρεσίας πόρων που βασίζεται σε ML, αντί σε κανόνες και πράκτορες (πιθανώς η κύρια πρόκληση τώρα).
- υποστήριξη για επιπλέον scripting και λογικές γλώσσες (και αυτό θα είναι JavaScript).
Κατά τη γνώμη μου το πιο σημαντικό πράγμαΑυτό που δείχνει αυτός ο πιλότος είναι δύο πράγματα:
- Οι συνεργασίες με τον πελάτη είναι το κλειδί για την αποτελεσματικότητα, όταν η αποτελεσματική επικοινωνία βασίζεται στην ειλικρίνεια και τη διαφάνεια και ο πελάτης γίνεται μέλος μιας ομάδας που επιτυγχάνει σημαντικά αποτελέσματα σε σύντομο χρονικό διάστημα.
- Σε καμία περίπτωση δεν είναι απαραίτητο να "προσαρμόσετε" και να δημιουργήσετε "δεκανίκια" - μόνο λύσεις συστήματος. Είναι καλύτερα να αφιερώσετε λίγο περισσότερο χρόνο, αλλά δημιουργήστε μια λύση συστήματος που θα χρησιμοποιηθεί από άλλους πελάτες. Παρεμπιπτόντως, αυτό συνέβη, το σύστημα πρόσθετων και η εξάλειψη της εξάρτησης από το Azure παρείχαν πρόσθετη αξία σε άλλους πελάτες (γεια σας, Ομοσπονδιακός Νόμος 152).
Πηγή: www.habr.com