A Song of Ice (Bloody Enterprise) και Fire (DevOps και IaC)

Το θέμα DevOps και IaC είναι πολύ δημοφιλές και αναπτύσσεται γρήγορα. Ωστόσο, οι περισσότεροι συγγραφείς αντιμετωπίζουν καθαρά τεχνικά προβλήματα σε αυτό το μονοπάτι. Θα περιγράψω τα προβλήματα που χαρακτηρίζουν μια μεγάλη εταιρεία. Δεν έχω λύση - τα προβλήματα, γενικά, είναι μοιραία και βρίσκονται στον τομέα της γραφειοκρατίας, του ελέγχου και των «soft skills».

A Song of Ice (Bloody Enterprise) και Fire (DevOps και IaC)
Δεδομένου ότι ο τίτλος του άρθρου είναι έτσι, η Daenerys, που έχει πάει στο πλευρό του Enterprise, θα κάνει τη γάτα.

Αναμφίβολα, τώρα υπάρχει σύγκρουση παλιού και νέου. Και συχνά σε αυτές τις συγκρούσεις δεν υπάρχει ούτε σωστό ούτε λάθος. Απλώς έγινε έτσι. Αλλά, για να μην είμαστε αβάσιμοι, θα ξεκινήσουμε με αυτήν την οθόνη:

A Song of Ice (Bloody Enterprise) και Fire (DevOps και IaC)

Αυτό είναι το λεγόμενο αίτημα αλλαγής. Βλέπετε περίπου το ένα τρίτο των πεδίων που πρέπει να συμπληρωθούν από διάφορους καταλόγους, τα υπόλοιπα πεδία βρίσκονται σε άλλους σελιδοδείκτες. Ένα τέτοιο έγγραφο πρέπει να συμπληρωθεί για να εφαρμοστεί το σενάριο στον διακομιστή παραγωγής ή να ανεβάσετε νέα αρχεία ή γενικά να αλλάξετε οτιδήποτε.

Ο αριθμός των πεδίων είναι τέτοιος που έγραψα τον δικό μου μικρό αυτοματισμό για τη συμπλήρωση αυτών των πεδίων. Επιπλέον, αυτή η σελίδα είναι γραμμένη με τέτοιο τρόπο που κανένα εργαλείο αυτοματισμού δεν μπορεί να δει τα πεδία της και η μόνη δυνατή λύση ήταν να χρησιμοποιήσετε το AutoIt για να κάνετε ανόητα κλικ στις συντεταγμένες με το ποντίκι. Αξιολογήστε το επίπεδο απελπισίας σας για να το κάνετε αυτό:

A Song of Ice (Bloody Enterprise) και Fire (DevOps και IaC)

Έτσι, παίρνετε jenkins, σεφ, terraform, nexus, κ.λπ., και ευχαρίστως τα αναπτύσσετε όλα στον προγραμματιστή σας. Έρχεται όμως η ώρα να το στείλουμε σε QA, UAT και PROD. Έχετε ένα τεχνούργημα Nexus και λαμβάνετε μια επιστολή από το DBA με κάτι σαν αυτό:

Αγαπητέ μου

Πρώτα απ 'όλα, το δεσμό σας μπορείτε να το έχετε μόνοι σας. Δεν έχω πρόσβαση στο Nexus σας
Δεύτερον, όλες οι αλλαγές πρέπει να εκδίδονται ως Αίτημα Αλλαγής.
Πρέπει να εξαγάγετε τα σενάρια SQL από το Nexus και να τα επισυνάψετε στο αίτημα αλλαγής.
Εάν η αλλαγή δεν είναι Έκτακτη, θα πρέπει να γίνει 7 ημέρες πριν από την κυκλοφορία (αποκλειστικά το Σαββατοκύριακο)
Όταν το Αίτημά σας Αλλαγής εγκριθεί από πολλά άτομα, το DBA θα εκτελέσει το σενάριό σας και θα στείλει ακόμη και ένα στιγμιότυπο οθόνης του αποτελέσματος μέσω ταχυδρομείου.

Με εκτίμηση, το DBA σας που εργάζεται εδώ από την εποχή του mainframe.

Ξέρεις τι μου θυμίζει αυτό; Ημι-αυτοματισμός: το ρομπότ κρατά το πλαίσιο και ο εργαζόμενος το χτυπά με μια βαριοπούλα. Λοιπόν, αλήθεια, τι νόημα έχει αυτό το Nexus, αν όλα γίνονται εντελώς χειροκίνητα;

Αλλά η Enterprise δεν πρέπει να κατηγορηθεί για αυτό! Είναι, φυσικά, αιματηρό, αλλά όλη αυτή η γραφειοκρατία με τα Αιτήματα Αλλαγής είναι αναγκαστική και προέρχεται από ελεγκτές. Η επιχείρηση πρέπει να λειτουργεί με αυτόν τον τρόπο, τελεία. Δεν μπορεί να το κάνει αλλιώς. Και ο έλεγχος είναι πολύ συντηρητικό πράγμα. Για παράδειγμα, πόσα έχουν ειπωθεί για το γεγονός ότι οι μακροχρόνιοι ψευδοσύνθετοι και συχνά αλλαγμένοι κωδικοί πρόσβασης είναι κακοί, αλλά οι επιχειρήσεις θα είναι το τελευταίο μέρος όπου αυτό θα αλλάξει. Επίσης με αναπτύξεις και οτιδήποτε άλλο.

Παρεμπιπτόντως, κάποια στιγμή προσπάθησα να δημιουργήσω ένα αρχείο για terraform, αλλά δεν λειτούργησε. Σκόνταψα πάνω στην έννοια της ετικέτας «Κώδικας λογιστικής χρέωσης έργου», την οποία δεν κατάφερα ποτέ να μάθω - δεν είχα αρκετές soft skills.

Δεν ασχολούμαι καν με το θέμα του παθητικού Λουδισμού - ω, ο αυτοματισμός σας απειλεί την εργασιακή μου ασφάλεια, δεν θέλω να μάθω τίποτα καινούργιο, οπότε θα το σαμποτάρω ήσυχα.

Λοιπόν, ποια θα μπορούσε να είναι η λύση καταρχήν; Το σύστημα ITSM διαθέτει ένα εξαιρετικά πρωτόγονο API για την αυτόματη δημιουργία εγγράφων. Και γενικά, τα περισσότερα από αυτά τα συστήματα προέρχονται από την εποχή των mainframes. Γνωρίζει κανείς κάποια πραγματικά σύγχρονα συστήματα ITSM; Έχει κανείς επιτυχημένη εμπειρία ενσωμάτωσης σύγχρονων DevOps και γραφειοκρατίας; Φυσικά, δεν μιλάμε για αμιγώς ιστότοπους πωλήσεων, όπου στην πραγματικότητα μπορεί να υπάρχει ανάπτυξη κάθε μέρα, αλλά, για παράδειγμα, για τον τραπεζικό τομέα, ο οποίος βρίσκεται υπό ελεγκτές και πολύ ισχυρή απομόνωση σε υψηλότερα περιβάλλοντα.

Απλώς μην ξεχνάτε ότι όλες οι φαντασιώσεις σας περιορίζονται από τον έλεγχο. Και αυτό αλλάζει τα πάντα. Σας περιμένω στα σχόλια!

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο