Το 2015 ενός sysadmin

Ήρθε η περίοδος του self-reflection, ε; Θα κάνω μια προσπάθεια, αλλά θα μου επιτρέψετε να μείνω στα sysadminικά και να μην πιάσω τα προσωπικά μου.

Ξεκίνησα να μπλέκομαι στην στην διαδικασία προσλήψεων της εταιρίας, τουλάχιστον για τους sysadmins. Υπάρχει παλιότερο post επί της διαδικασίας, αργότερα ακολούθησαν και κάποιες άλλες συνεντεύξεις και άλλη μια πρόσληψη - τρεις στο σύνολο για το έτος.

Μαθήματα από την διαδικασία:

• Πρέπει να είσαι ξεκάθαρος με τον υποψήφιο. Πρέπει να είσαι ακόμα πιο ξεκάθαρος με τον νεο-προσληφθέντα. Δικαιούνται να ξέρουν τι γίνεται και πρέπει να έχουν τακτικό και ειλικρινό feedback. Ειδικά αν η εταιρία έχει δοκιμαστική περίοδο πρόσληψης πριν το μόνιμο συμβόλαιο (σουηδικός νόμος), δώσε feedback τακτικά στον νέοπα για να ξέρει πως τα πάει και αν πιάνει τους στόχους που του έχει θέσει η εταιρία. Η μαγική λέξη είναι "τακτικά", τουλάχιστον κάθε δύο μήνες, αν όχι κάθε μήνα.
• Πρέπει να είσαι ξεκάθαρος στον εαυτό σου. Φρόντισε να ορίσεις τι κενό ακριβώς θέλεις να γεμίσεις με έναν νέο συνάδελφο. Θα είναι καλύτερα και για σένα και για την εταιρία και για τον νέο συνάδελφο.
• Η δοκιμαστική περίοδος στην Σουηδία είναι έξι μήνες, όπου η εταιρία έχει την δυνατότητα να διώξει τον νέο υπάλληλο άμεσα αν δει ότι δεν τραβάει/δεν κολλάει στο πνεύμα της εταιρίας. Σιγουρέψου ότι ο υποψήφιος το ξέρει από πριν. 
• Η τεχνική κατάρτιση βρίσκεται εύκολα. Η εργασιακή προσωπικότητα που ταιριάζει στην ομάδα σου όμως είναι δυσεύρετη. Ξέρεις τι ακριβώς χαρακτήρα έχει η ομάδα σου και πως δουλεύει;
• Μη βασίζεσαι στο HR για την μη τεχνική εκτίμηση του υποψηφίου. Just don't.
• Πρέπει να διώξεις sysadmin; Όσο φιλικά και να γίνει, πολύ πιθανόν να πρέπει να κλείσουν τα accounts του όση ώρα του μιλάει ο μάνατζερ του. Δυστυχώς οι sysadmins ανήκουν σε αυτή την ειδική κατηγορία που σε μια έκρηξη θυμού μπορούν να κάνουν ζημιά. Και αυτή η έκρηξη μπορεί να μην έρθει άμεσα, μπορεί να έρθει το βράδυ, μετά από δύο μέρες, την επόμενη βδομάδα.

Αν όλα αυτά σου ακούγονται σαν προϊόν κακών εμπειριών, έπεσες μέσα.

Δυστυχώς η τελευταία μας πρόσληψη δεν πήγε όσο καλά θα περιμέναμε και αναγκαστήκαμε να τον αφήσουμε να φύγει στο τέλος της δοκιμαστικής περιόδου του. Πέρα από τα δικά του και τα δικά μας λάθη (τα οποία έγιναν πικρά μαθήματα), ήταν περίεργο να βλέπεις πόσοι νέοι συνάδελφοι συνειδητοποίησαν ξαφνικά ότι η δοκιμαστική περίοδος δεν συνεπάγεται αυτόματα μόνιμο συμβόλαιο.
Instant μαθήματα επαγγελματικής ζωής για όλους, λοιπόν.

Στις νέες προσθήκες στην εργαλειοθήκη μου έχουμε τα εξής:

• Ansible
  Νομίζω ότι είχα σχηματίσει μια άλλη εικόνα για την Ansible πριν αρχίσω να την χρησιμοποιώ. Ερχόμενος από τον κόσμο του Puppet, περίμενα κάτι πιο structured και managed. Η Ansible είναι ακριβώς το αντίθετο και θα την περιέγραφα ως ένα python-based SSH loop. Η χρήση της είναι εύκολη, γράφεις τα βήματα που θέλεις να κάνει σε YAML format και ορίζεις σε ποια hosts θα συνδεθεί για να εκτελέσει το playbook.
  Τα προβλήματα που βλέπω στην Ansible είναι η σχετική ανωριμότητα του εργαλείου. Υπάρχουν κάτι bugs από δω κι από κει, υπάρχουν και κάτι προβλήματα performance. Μακάρι να έλεγα ότι οφείλεται στην (προς το παρόν) απλοϊκή χρήση που κάνω, αλλά πήγα σε ένα continuous deployment meetup και ο ένας παρουσιαστής, από μια Ansible-heavy εταιρία, έκραζε για αυτά ακριβώς τα προβλήματα.
  Προς το παρόν την βλέπω ως ένα βολικό orchestration tool, ειδικά στην περίπτωση ενός rolling update, αλλά θα αφήσω το Puppet να κάνει την βαριά δουλειά.
  Πάντως, φαίνεται να είναι φοβερά δημοφιλής, το community της αναπτύσσεται ραγδαία και έχει φτάσει στο σημείο να εξαγοραστεί από την RedHat. Σίγουρα ένα καλό εργαλείο να μάθεις για λόγους επαγγελματικής προόδου.
• Travis CI
  Δεν είναι τόσο το συγκεκριμένο εργαλείο, όσο το τι εκπροσωπεί: Test driven development + Continuous Integration. Η συζήτηση γίνεται μέσα στο context του infrastructure operations, οπότε μη φαγωθείτε να με κράξετε φίλοι devs :)
  Για τους λίγους σαν εμένα που δεν ξέρουν, το Travis CI αναλαμβάνει να τρέξει κάποια προκαθορισμένα tests στον κώδικα σου κάθε φορά που κάνεις commit. Το πόσο περίπλοκα θα είναι τα tests είναι δικό σου θέμα, αλλά συνήθως μιλάμε για unit testing μαζί με code style conformity.
  Καθώς ασχολούμαι κυρίως με Puppet σε αυτή την περίπτωση, τα tests αυτά τρέχουν με rspec-puppet και puppet-lint. Τα functionality tests τα τρέχω σε vagrant με το χέρι γιατί είμαι κολλημένος, αλλά θα το διορθώσω κι αυτό σύντομα :)
  Βέβαια το Travis CI είναι κατιτις Github-specific. Καθώς στην εταιρία είμαστε οπαδοί του Gitlab, έχουμε προγραμματίσει να κάνουμε deploy το Gitlab-CI, το οποίο δίνει ακριβώς το ίδιο functionality με το Travis. Για μαθησιακούς σκοπούς πάντως το να σηκώσεις ένα Github repo και να το συνδέσεις στο Travis είναι πανεύκολο και δωρεάν, highly recommended.
• Puppet-lint
  Το puppet-lint είναι ένα ελαφρώς... κομπλεξικό εργαλειάκι που φροντίζει ο κώδικας σου να είναι γραμμένος σύμφωνα με τα puppet code styles. Σπαστικό ώρες-ώρες και η διαφορά που θα κάνει στο τελικό αποτέλεσμα είναι μικρή, αλλά που και που πιάνει κάποιο θέμα συμβατότητας (πχ κώδικας που τρέχει σε παλιότερες εκδόσεις puppet αλλά όχι 3.8+). Είναι στιγμαίο σε εκτέλεση, οπότε δεν υπάρχει σοβαρός λόγος να μη το χρησιμοποιήσεις.
• Rspec-puppet
  Το rspec-puppet είναι ένα νόθο αδέρφι του rspec που αναλαμβάνει να δει ότι πχ το nginx module σου δεν έχει ξεχάσει να κάνει start το service. Πολύ χρήσιμο αν π.χ. δώσεις στον junior sysadmin ένα module που δεν έχει τροποποιηθεί πάνω από χρόνο και θέλεις να σιγουρευτείς ότι δεν θα σβήσει απαραίτητα κομμάτια. Το γράφεις τώρα και κάνεις επένδυση για το μέλλον.
• Jenkins
  Κάπου εδώ φρικάρουν οι περισσότεροι έμπειροι αναγνώστες τελείως. "ΤΩΡΑ ΕΜΑΘΕΣ JENKINS;"
  Εντάξει παιδιά, και στα γεράματα καλά είναι :P
  Η επαφή μου με τον Jenkins ήταν μικρή, στα πλαίσια του commit-push-deploy-restart. Για να είμαι ειλικρινής, εφόσον έσπρωχνε το puppet code μου, δεν με ένοιαζε και πολύ, άφηνα τους devs να παίζουν με το jenkins, αυτά είναι του διαβόλου, μη με μπλέκετε με maven κλπ κλπ.
  Ο λόγος που άρχισα να δουλεύω λίγο παραπάνω με Jenkins είναι ότι αποφασίσαμε να το χρησιμοποιήσουμε ως troubleshooting tool. Σε συνεργασία με το DBA team και τους senior devs έχουμε γράψει αρκετά jobs που μαζεύουν forensics ή κάνουν maintenance tasks. Πολύ-πολύ χρήσιμο όταν πρέπει να τρέξεις τέτοια πράγματα από το κινητό σου και εύκολο να δώσεις access στον καημένο junior που είναι on-call, χωρίς να έχει shell/DB access.
• Debian packaging
  Έχω απαγορεύσει στους devs μας να εγκαθιστούν software με το χέρι. Πατ. Τζιζ. Θέλεις Tomcat στο local env σου;
  apt-get install tomcat
  Θέλεις Tomcat σε dev/test/staging/prod server;
  package{'tomcat': ensure => installed}
  Μαλώνουμε λίγο αλλά δεν πειράζει. Μόλις δούνε ότι δεν χρειάζεται να κάνουν καν ssh στο vm, αρχίζουν να γλυκαίνονται. Στην τελική, ο μέσος dev αυτό θέλει: να γράφει τον κώδικα και να μην ασχολείται με την εγκατάσταση του.
  Για να το πετύχει αυτό η ομάδα, θα πρέπει να σπρώξεις λίγο τα κατάλληλα εργαλεία. Ευτυχώς κάποια standalone services αναπτύχθηκαν εξαρχής σε Dropwizard, για τα υπόλοιπα προσπαθώ να φτιάξω jobs που παίρνουν τα deployables και τα πακετάρουν σε .deb format. Απέχουμε ακόμα από 100% κάλυψη, αλλά το παλεύουμε.
  Επί της ευκαιρίας, I'll toot my own horn και θα λινκάρω την παρουσίαση που έκανα στην εταιρία για εισαγωγή στο Debian packaging, ίσως κάποιοι την βρουν χρήσιμη:
  http://www.slideshare.net/DimitrisTsompanidis/debian-packaging-55056414
• Graphite
  Late to the party, ξέρω. Είμαστε ακόμα σε δοκιμαστική περίοδο, αλλά έχουμε ζητήσει beta access σε μια καινούρια startup, την Raintank (παιδί του δημιουργού του Grafana), που αναλαμβάνει την διαχείριση του dashboard σου. Το μέλλον προβλέπεται ενδιαφέρον.

Τι έχω στην λίστα για το 2016;

Automation, automation, automation. Πραγματικά, δεν έχω καμιά όρεξη να κάθομαι να κάνω manually δουλειές που θα έπρεπε να κάνουν οι υπολογιστές για μένα. Deployments, provisioning, packaging, testing, δεν με νοιάζει, θέλω μόνο να βλέπω ένα Job succeeded στο Hipchat.


Τα πρώτα εργαλεία που θα κοιτάξω να πιάσω τον επόμενο χρόνο είναι Packer, serverspec, Rundeck, Puppet v4 και ένα καλό χέρι ELK stack. Ειδικά το τελευταίο, όλοι το διαφημίζουν σαν ΤΗΝ λύση για centralized logging, αλλά δεν σου λέει κανένας ότι θα σου γεμίσει ό,τι δίσκο και μνήμη του πετάξεις αν δεν το ταράξεις στο tuning.

Δυστυχώς, θα πρέπει να μάθω και systemd...