5 regole per i DevOps engineer

Ci sono delle regole che ogni buon ingegnere dovrebbe conoscere ed applicare nel proprio ambiente di lavoro; Chris Short (Flourish) ne ha recentemente elencate 5 dedicandole agli aspiranti DevOps engineer.

Aggiornamento continuo

La prima regola è smettere di dire “Non lo so“. Questa frase dovrebbe essere bandita dal vocabolario di un buon ingegnere, bisogna invece entrare nell’ottica di restare sempre aggiornati sulle ultime tecnologie e su quelle che già si utilizzano. Dunque bisogna sostituire “Non lo so” con “Farò qualche ricerca in merito” oppure “Conosco qualcuno che può indicarmi la strada giusta“. Bisogna trattare ogni task come un’opportunità di apprendimento in modo da migliorare costantemente le proprie skill.

Documentazione e codice sorgente

La seconda regola è: leggi la documentazione. Questa legge potrebbe sembrare ovvia, o addirittura superflua, ma è sempre importante leggere la documentazione. Spesso la soluzione che cerchiamo è scritta proprio in un manuale. Numerosi di sviluppatori spendono anni nello scrivere documentazioni approfondite dei loro prodotti, leggerle evita spesso grattacapi durante il lavoro. In assenza di una documentazione vera è propria è sempre meglio visionare il codice sorgente, se disponibile, alla ricerca dei commenti dello sviluppatore.

Meno domande, più ricerche

La terza regola è: cerca prima di chiedere. Spesso in Rete e nei forum di supporto si trovano migliaia di domande identiche, questa regola si ricollega direttamente alla prima e alla seconda. Prima di chiedere alla community, e dunque impiegare tempo a spiegare un problema invece di risolverlo, è sempre meglio indagare e cercare in Rete se qualcun altro ha avuto le stesse problematiche e se le ha già risolte. Applicando sempre questo metodo si eviteranno ore di inutili tentativi.

Obbiettivi

La quarta regola è: tutto è possibile. Molti team iniziano lo sviluppo di un progetto con l’idea che l’obbiettivo sia impossibile da raggiungere, questa è una filosofia sbagliata. L’unico limite reale è quello imposto dalle leggi della fisica. Tutto il resto è lecito se si hanno a disposizione le giuste tempistiche, un team coordinato e si applica il giusto sforzo. Mai demoralizzarsi o convincersi che qualcosa è impossibile.

Debito tecnico

La quinta regola è: riconoscere il debito tecnico. Il Technical debt è il risultato di una decisione che era sensata in passato ma che oggi causa dei problemi. Il compito di un ingegnere è aiutare ad eliminare questi debiti per evitare che finiscano in produzione. In fase di pianificazione è sempre meglio considerare cosa non funzionerà nel lungo termine.

In conclusione, è possibile citare anche un ulteriore elemento: la pigrizia. Trattandosi di operazioni ripetitive può capitare che un ingegnere diventi pigro, ecco perché si tende ad automatizzarle. La pigrizia non è sempre un male, ma andrebbe controbilanciata dalle regole esposte.

Via Chris Short