Buon venerdì a tutti! Oggi continuiamo la nostra serie di pubblicazioni dedicate al corso , poiché le lezioni nel nuovo gruppo del corso inizieranno già alla fine della prossima settimana. Iniziamo!
Il monitoraggio è solo. Questo è un fatto noto. Avvia Nagios, esegui NRPE su un sistema remoto, configura Nagios sulla porta NRPE TCP 5666 e hai il monitoraggio.
È così facile che diventa noioso. Ora hai le metriche di base sul tempo della CPU, il subsistema disco e la memoria disponibile, che arrivano di default in Nagios e NRPE. Ma in realtà non è «monitoraggio» in senso stretto. È solo l'inizio.
(Di solito si installa PNP4Nagios, RRDtool e Thruk, si configurano le notifiche in Slack e si va direttamente su nagiosexchange, ma per ora tralasciamo questo).
Un buon monitoraggio è in realtà piuttosto complesso, devi davvero conoscere l'interno dell'applicazione che stai monitorando.
Il monitoraggio è complicato?
Qualsiasi server, che sia Linux o Windows, avrà per definizione uno scopo. Apache, Samba, Tomcat, archiviazione di file, LDAP: tutti questi servizi sono più o meno unici in un modo o nell'altro. Ognuno ha la sua funzione e le sue caratteristiche specifiche. Esistono diversi modi per ottenere metriche e KPI (indicatori chiave di prestazione) che vi interessano quando il server è sotto carico.
Autore della foto con
(mi piacerebbe che i miei dashboard fossero colorati in blu neon — sospirando sognante —… hm…)
Qualsiasi software che fornisca servizi deve avere un meccanismo per raccogliere metriche. Apache ha il modulo mod-status, che mostra la pagina di stato del server. Nginx ha il stub_status. Tomcat ha JMX o applicazioni web speciali che mostrano le metriche chiave. In MySQL c'è il comando «show global status», e così via.
Perché gli sviluppatori non integrano meccanismi simili nelle applicazioni che creano?
Solo gli sviluppatori lo fanno?
Un certo livello di indifferenza verso l'integrazione delle metriche non si limita agli sviluppatori. Ho lavorato in aziende che sviluppavano applicazioni usando Tomcat e non fornivano metriche proprie, né registri di attività del servizio, tranne i log degli errori generali di Tomcat. Alcuni sviluppatori generano un'abbondanza di log, privi di significato per l'amministratore di sistema che sfortunatamente si trova a leggerli alle 3:15 del mattino.
Autore della foto con
Gli ingegneri di sistema che permettono a tali prodotti di andare in produzione devono anche assumersi una certa responsabilità per la situazione. Pochi ingegneri di sistema hanno il tempo e si preoccupano di cercare di ottenere metriche significative dai log, senza il contesto di queste metriche e la possibilità di interpretarli alla luce delle attività dell'applicazione. Alcuni non comprendono quale vantaggio possano trarre da ciò, al di là di indicatori come 'qualcosa attualmente (o a breve) non va'.
Il cambiamento di mentalità riguardo alla necessità di metriche deve avvenire non solo tra gli sviluppatori, ma anche tra gli ingegneri di sistema.
Per qualsiasi ingegnere di sistema, che non solo deve rispondere a eventi critici, ma anche garantire che non si verifichino, l'assenza di metriche è generalmente un ostacolo.
Tuttavia, gli ingegneri di sistema di solito non si occupano di codice, guadagnando soldi per la loro azienda. Hanno bisogno di sviluppatori di punta che comprendano l'importanza della responsabilità dell'ingegnere di sistema nell'individuare problemi, aumentare la consapevolezza sulle problematiche delle performance e simili.
Questa cosa devops
La mentalità devops descrive la sinergia tra il pensiero degli sviluppatori (dev) e quello delle operazioni (ops). Qualsiasi azienda che afferma di «fare devops» deve:
- dire cosa probabilmente non fa (un allusione a un meme del film «La principessa sposa» — «Non credo che questo significhi quello che pensi che significhi!»)
- promuovere una posizione di continua perfezione del prodotto.
Non puoi migliorare un prodotto e sapere che è stato migliorato se non sai come funziona attualmente. Non potrai comprendere come funziona il prodotto se non comprendi come operano i suoi componenti, i servizi di cui dipende, i suoi principali punti critici e i colli di bottiglia.
Se non osservi i potenziali colli di bottiglia, non potrai seguire la tecnica delle «Cinque perché» nella scrittura di un Postmortem. Non sarai in grado di raccogliere tutto su un unico schermo per vedere come funziona il prodotto o conoscere il suo aspetto «normale e felice».
Spostamento a sinistra, A SINISTRA, HO DETTO, SINISTRAMENTE—
Per me, uno dei principi fondamentali di DevOps è il «Spostamento a sinistra» (shift left). Lo spostamento a sinistra in questo contesto significa spostare la capacità (non la responsabilità, ma solo la capacità) di fare ciò di cui si occupano solitamente gli ingegneri di sistema, ad esempio, creare metriche di prestazione, utilizzare i log in modo più efficace, ecc., verso sinistra nel ciclo di vita della consegna del software (Software Delivery Life Cycle).
Autore della foto con
Gli sviluppatori software devono avere la possibilità di utilizzare e conoscere gli strumenti di monitoraggio che l'azienda utilizza per monitorare in tutte le sue forme, metriche, registrazione, interfacce di monitoraggio e, soprattutto, osservare come il loro prodotto funziona in produzione. Non puoi costringere gli sviluppatori a investire tempo e impegno nel monitoraggio se non possono vedere le metriche e influenzare come appaiono, come le presenterà il proprietario del prodotto al CTO durante il prossimo briefing, e così via.
In breve
- Porta il cavallo all'acqua. Mostra ai programmatori quante problematiche possono evitare, aiuta a definire i KPI e le metriche adeguate per le loro applicazioni, riducendo le lamentele da parte del product owner, che è sotto pressione dal CTO. Falli emergere in modo dolce e pacato. Se questo non funziona, cerca di persuadere, minacciare o convincere sia loro sia il product owner per ottenere queste metriche il prima possibile, e poi crea dei grafici. Sarà difficile, poiché non sarà visto come una priorità e nella roadmap del prodotto ci saranno molti progetti in attesa di implementazione che generano reddito. Pertanto, avrai bisogno di una giustificazione economica per giustificare il tempo e le risorse spesi per implementare il monitoraggio nel prodotto.
- Aiuta gli ingegneri di sistema a dormire sonni tranquilli. Fai loro capire che l'uso di una checklist per il rilascio di qualsiasi prodotto è una pratica positiva. Inoltre, assicurarti che tutte le applicazioni in produzione siano coperte da metriche contribuirà a garantire un sonno sereno, permettendo agli sviluppatori di vedere cosa non funziona e dove. Tuttavia, il modo migliore per irritare e frustrante un qualsiasi sviluppatore, proprietario di prodotto o CTO è quello di ostacolare continuamente e resistere. Tale comportamento influenzerà la data di rilascio di qualsiasi prodotto se ci si aspetta di nuovo fino all'ultimo minuto, quindi anticipa nuovamente il calendario e integra questi problemi nel piano di progetto il prima possibile. Se necessario, infiltrati negli incontri dedicati al prodotto. Indossa baffi finti e un cappello di feltro o qualcosa del genere, non ti deluderà mai. Riferisci i tuoi problemi, mostra i vantaggi evidenti e fai evangelizzazione.
- Assicurati che sia gli sviluppatori (dev) che le operazioni (ops) comprendano il significato e le conseguenze del passaggio delle metriche del prodotto nella "zona rossa". Non lasciare le operazioni come unico custode della funzionalità del prodotto; assicurati che anche gli sviluppatori siano coinvolti in questo (#productsquads).
- I log sono ottimi, ma anche le metriche lo sono. Combinali e non lasciare che i tuoi log diventino spazzatura in una enorme palla infuocata di inutilità. Spiega e mostra agli sviluppatori perché nessuno oltre a loro sarà in grado di comprendere i loro log; fai vedere loro com'è guardare log inutili alle 3:15 del mattino.
Autore della foto con
Questo è tutto. Nuovo materiale uscirà la prossima settimana. Se desideri saperne di più sul corso, ti invitiamo a , che si terrà lunedì. Ora, come sempre, aspettiamo i tuoi commenti.
Fonte: habr.com
