Ensimmäiset 90 päivää: vaiheittainen toimintakäsikirja DevOps-insinöörille

Hei, uusi työntekijä. Olen kuullut sinusta! 

Opit Kubernetesin läpikotaisin, automatisoit kaiken mahdollisen ja hallitsit putket. Opiskelit CI/CD-strategioita, IaC-työkaluja ja YAML:n oikkuja aivan kuin elämäsi olisi ollut niistä kiinni.

Onneksi olkoon, sait DevOps-insinöörin työpaikan!

Sinulle annettiin pääsy pilvikonsoliin, koontiputkeen ja mahdollisesti – hyytävästi – tuotantoympäristön root-oikeudet (ei paineita).

Useimpien DevOps-tiimien perehdytys on hauras cocktail, johon kuuluu ”lue tämä satunnainen dokumentti vuodelta 2021”, ”kysy muilta” ja ”älä koske tuohon skriptiin, sen pitäisi kai edelleen tehdä jotain”. 

Rooli on harvoin määritelty selkeästi, ja odotukset ovat järjettömän korkealla, vaikka dokumentaatiota on vähän. Lisäksi… jotkin käyttöönotot tuntuvat siltä, että ne saattavat herättää muinaisen kirouksen.

Vaikka työhaastattelu saattoi käsitellä työkaluja, ensimmäiset 90 päivääsi koskevat ennen kaikkea ihmisiä, prosesseja ja prioriteetteja. Nyt ansaitset uskottavuutesi, löydät dokumentoimattomat asiat ja luot perustan infrastruktuurille, johon tiimisi voi luottaa.

Tämä toimintakäsikirja ei korjaa tiimisi infrastruktuuria yhdessä yössä. Mutta se auttaa sinua välttämään vaikutelman, että olet se henkilö, joka rikkoi kaiken.

Alan ääniä

”Tärkein oppimani asia on se, kuinka nopeasti sinun on ymmärrettävä asiakkaasi – eli kehittäjät – ja heidän mieltymyksensä. Pixarilla perustin kerran CI-järjestelmän, jota kukaan ei käyttänyt, ennen kuin lisäsin sähköposti-ilmoitukset. Kävi ilmi, että juuri sillä tavalla he halusivat saada ilmoituksia. Toisessa yrityksessä lisäsimme testien käyttöä pelillistämällä sen reaaliaikaisten toimiston tulostaulujen avulla. Kulttuuri ei ole vain taustalla oleva yksityiskohta – se on todellinen toimitusputki.” -Tara Hernandez, MongoDB:n kehittäjätuottavuudesta vastaava johtaja

Rooli: DevOps, alustatekniikka vai SRE?

Aloitetaan ikuisella vastuuvapauslausekkeella: ”DevOps on kulttuuri, ei työnimike.” Toki, Jan – mutta työnimike on silti olemassa. Käytännössä se tarkoittaa usein automaatioasiantuntijan, järjestelmäarkkitehdin, SRE-asiantuntijan ja sisäisten työkalujen asiantuntijan yhdistelmää.

Sinun pitäisi olla mahdollistaja, tehostaja ja toimitusnopeuden puolestapuhuja. Totuus kuitenkin on, että sinä olet henkilö, jonka puoleen tullaan, kun:

• Koonti hajoaa eikä kukaan tiedä miksi.
• Joku tarvitsee uuden testiympäristön heti.
• Vaatimustenmukaisuuden auditointi lähestyy ja salaisuudet leijuvat tekstimuodossa.
• ”Tuo pitäisi kyllä automatisoida” muuttuu muotoon ”Voitko automatisoida tuon?”

Alustatekniikka on DevOpsia paremmalla brändäyksellä.
SRE on DevOpsia SLA-sopimuksella.

Millä nimellä sitä kutsutaankin, sinun tehtäväsi on saada asiat skaalautumaan, pysymään toiminnassa ja olemaan olematta surkeita.

Ensimmäiset 30 päivää: älä koske mihinkään (vielä)

Vinkki 1: Kartoita infrastruktuuri, älä vain arkkitehtuuria 

Selvitä, mistä olet vastuussa: pilvipalveluntarjoajat, CI/CD-putket, konttien orkestrointi, salaisuuksien hallinta ja häiriötilanteiden työnkulut. Luo oma ”infrakarttasi”, jonka avulla voit hahmottaa kokonaisuuden. Lisäpisteitä saat, jos linkität siihen reaaliaikaisia koontinäyttöjä tai skriptejä.

Vinkki 2: Selvitä vaikutusalue

Jokaisella DevOps-organisaatiolla on ”älä koske tuohon” -asetelmansa. Listaa kaikki, mikä voisi räjähtää, jos sitä käsitellään väärin. Näihin kuuluvat:

• Käyttöönoton skriptit, jotka muodostavat SSH-yhteyden tuotantoon (miksi… miksi ihmeessä?)
• Jenkins-työt, joita on viimeksi muokattu vuonna 2019
• PDF-tiedostoon tallennetut manuaaliset toimintaohjeet
• Terraform-tiedostot, joita ei ole koskaan oikeasti otettu käyttöön

Kysy: Mikä on dokumentoimatonta mutta kriittistä? Kuka omistaa sen? Ja mikä on palautussuunnitelma, jos se epäonnistuu?

Vinkki 3: Seuraa käyttöönottoa – tai vielä parempi, seuraa yhtä reaaliajassa 

Opit yhdestä käyttöönotosta ja sen ongelmista enemmän kuin tuntikausien dokumentaatiosta. Mitkä vaiheet ovat manuaalisia? Mikä on epävakaata? Mikä perustuu hiljaiseen tietoon ja mikä on kirjattu koodiksi? Et ole täällä esittelemässä nerokkaita ideoita vielä. Olet täällä keräämässä tietoa.

Sinun pitäisi pystyä jäljittämään toimitus tuotantoon yhdistetystä commitista silmät sidottuina. Ymmärrä:

• CI/CD-putki (missä se hajoaa, missä syntyy pullonkauloja)
• Salaisuuksien hallinta (ethän sijoita niitä ympäristömuuttujiin)
• Hyväksyntäprosessit (julkaisemmehan YOLO-tyyliin Slackista?)

Älä toimita koodia. Tarkkaile vain putkistoa ja kirjoita asiat muistiin.

Ääniä kentältä

“Hyvä perehdytys ei aina kulje käsi kädessä hyvän dokumentaation kanssa. Joskus ainoa tie kaaoksen läpi on uteliaisuus ja sinnikkyys. Kun liityin tiimiin ja sain vastuulleni monimutkaisen julkaisun ilman dokumentaatiota, selvitin koko työnkulun käänteisesti. Se kokemus opetti minulle: jos dokumentaatio puuttuu, sinusta tulee dokumentaatio.” –Anant Agarwal, Aidoran teknologiajohtaja

Ensimmäiset 60 päivää: tunnista riskit ja vähennä kitkaa

Vinkki #4: Toteuta viidessä minuutissa saavutettava voitto

Etsi paljon kitkaa aiheuttavia ja vähän riskejä sisältäviä tehtäviä, jotka voit skriptata tai mallintaa. Nämä ”1 %:n” parannukset helpottavat elämääsi ja rakentavat tiimin luottamusta. Etsi vain yksi asia, joka kestää viisi minuuttia liian kauan, ja nopeuta sitä:

• Shell-kuori paikallisen kehitysympäristön käyttöönottoon
• CLI-apuväline 
• Uudelleenkäytettävä Terraform-moduuli
• Skripti jumittuneiden testiympäristöjen poistamiseen
• Slack-ilmoitus epäonnistuvista koontiversioista

Pienet voitot rakentavat luottamusta. Luottamus antaa sinulle liikkumavaraa tehdä suuria muutoksia.

Vinkki #5: Tarkasta CI/CD-putki äärimmäisen perusteellisesti

Tarkastele koontiversioiden kestoa. Tarkastele testikattavuutta. Tarkastele sitä, mikä hajoaa päivittäin. Esitä esimerkiksi seuraavia kysymyksiä:

• Voimmeko suorittaa testit rinnakkain?
• Olisiko tämä voitu estää aiemmin CI-vaiheessa?
• Välimuistitammeko riippuvuudet?
• Julkaisemmehan yhdistämisen yhteydessä… vai pelkän onnenkantamoisen varassa?

Et ole täällä osoittelemassa syyllisiä. Olet täällä tekemässä työnkulusta kitkattoman.

Ääniä kentältä

“Äskettäisessä paljon liikennettä saaneen sovelluksen haltuunotossa dokumentaatiota ei ollut lainkaan – meidän oli selvitettävä kaikki nopeasti yrityksen ja erehdyksen kautta. Neuvoni? Hyödynnä tekoälyä tehokkaasti. Lokien analysoinnista rajapintojen käänteiseen suunnitteluun tekoäly auttoi meitä perehdyttämään itsemme ja vakauttamaan järjestelmän nopeammin kuin olisimme koskaan pystyneet yksin. Se muuttaa rutiininomaisen puurtamisen todelliseksi edistykseksi.” –Denis Tiumentsev, Integro Technologiesin johtava DevOps-insinööri

Vinkki #6: Luo koontinäyttöjä, joita ihmiset todella käyttävät, ja selkeytä omistajuus 

 Grafana, Prometheus, Datadog – sillä ei ole merkitystä. Merkitystä on sillä:

• Näkeekö tiimisi julkaisujen onnistumisprosentin?
• Tarkoittavatko hälytykset jotain vai ovatko ne pelkkää kohinaa?

Seuraako joku virheprosentteja ennen kuin käyttäjät valittavat? Kuka omistaa koontiputken? Helm-kaaviot? DNS-määritykset? Omistajuuden rajat ovat harvoin selkeitä. Laadi luettelo epäselvistä alueista ja selkeytä ne tiimisi kanssa. Tämä ehkäisee myöhempää syyttelyä.

Sinä vastaat nyt näkyvyydestä. Tee siitä merkityksellistä.

Ensimmäiset 90 päivää: rakenna luottamusta luotettavuudella

Vinkki #7: Toteuta jotain, joka lisää vakautta 

Se voisi olla esimerkiksi:

• Hälytysten lisääminen järjestelmään, jota valvotaan liian vähän
• Testikattavuuden parantaminen esituotannossa
• CI-putkien epävakauden vähentäminen
• Bash-skriptin uudelleenmuotoilu, sillä katastrofi oli vain yhden rm -rf -komennon päässä

Sen ei tarvitse olla valtava. Sen on saatava tiimisi hengittämään helpommin.

Ääniä kentältä

“Yksi uuden DevOps-roolin ensimmäisistä onnistumisista oli keskitetyn CI/CD-putken käyttöönotto automaattisella palautuksella ja GitOps-työnkuluilla. Sitä ennen tiimi luotti hajanaisiin skripteihin ja manuaalisiin kiertoratkaisuihin. Tämä lyhensi käyttöönottoaikoja yli 50 prosentilla ja siirsi meidät jatkuvasta ongelmien sammuttamisesta ennakoivaan luotettavuuteen. Käyttöönoton myötä saavutettu uskottavuus teki valtavan eron.” –Divya Parashar, kokenut henkilöstöinsinööri

Vinkki #8: Kirjoita “DevEx”-palautemuistio

Kerää kehittäjiltä anonyymiä tai epämuodollista palautetta siitä, missä infrastruktuuri hidastaa heidän työtään. Esittele havaintosi ja ehdota kokeiluja (esimerkiksi nopeampaa paikallista kehitystä, hetkellisiä ympäristöjä ja parempaa lokitusta).

Kirjoita dokumentti nimeltä “Tässä on, mitä opin ja mitä teen seuraavaksi.” Tämä on etenemissuunnitelma (ja ehkä myös lista omista saavutuksista ;). Jaa se esihenkilösi ja tiimisi kanssa.

Luo lista nimeltä “Älä anna minun unohtaa tätä”:

• Löytämäsi oudot poikkeamat
• Varjoinfrastruktuuri, jonka omistajuutta kukaan ei myönnä
• Heimotieto, jonka vain Carl IT-osastolta tuntuu tietävän

Muunna lista dokumenteiksi, automaatioksi tai tehtäviksi – tai pidä se käden ulottuvilla. Tämä osoittaa johdolle, että rakennat vikasietoisia järjestelmiä.

Ääniä kentältä

“Keskity tuloksiin, joihin voit vaikuttaa tänään. Pidä mielessäsi, miksi työsi on tärkeää asiakkaille – tämä näkökulman muutos ratkaisee paljon ensimmäisten 90 päivän aikana.” –Rukmini Reddy, PagerDutyn tekniikan varatoimitusjohtaja

Vinkki #9: Valitse yksi vaikutuksiltaan merkittävä projekti ja ala määritellä sitä 

Tässä vaiheessa sinulla pitäisi olla riittävästi tietoa merkittävän kehityskohteen tunnistamiseen. Käytä ensimmäisten 90 päivän viimeinen vaihe sen laajuuden määrittelyyn, esittelyyn muille ja yhteisen näkemyksen saavuttamiseen.

• Siirrä epäluotettavat työt GitHub Actionsiin
• Korvaa yksi yksittäinen erikoispalvelin infrastruktuuri koodina -ratkaisulla
• Rakenna kehittäjille valmis toimintamalli uusien palvelujen luomiseen

Aloita pienestä ja osoita arvosi. Dokumentoi kaikki.

Lopuksi

Toivottavasti pystyt ensimmäisten 90 päivän aikana vakauttamaan tilanteen, saamaan hommat julkaistua ja ennen kaikkea estämään insinöörejä huutamasta tyhjyyteen.

Ensimmäisinä päivinä on tärkeintä luoda pohjaa pitkän aikavälin etenemiselle. Etsi halkeamat ja dokumentoi kuin mielipuoli! 

Ääniä kentältä

“Sinun ei tarvitse todistaa itseäsi yhdessä päivässä. Hengitä. Keskity ensin vakauteen ja vasta sitten nopeuteen. Esitä tyhmiä kysymyksiä varhain – myöhemmin niitä on vain vaikeampi esittää. Ja muista: tylsä mutta toimiva järjestelmä on parempi kuin näyttävä järjestelmä, joka hajoaa.” –Pablo Gerboles, Alive DevOpsin toimitusjohtaja

Eikö tämä ole ensimmäinen teknologia-alan rodeosi?

Tämä DevOps-toimintamalli on osa kasvavaa sarjaa uusille työntekijöille, jotka haluavat saada aikaan vaikutusta ennen kuin joku antaa heille “perintöjärjestelmien omistajuuden”.

👉 Oletko vasta aloittamassa tietoturvainsinöörin tehtävässä? Me autamme:
Ensimmäiset 90 päivää: tietoturvapainos

👉 Kiinnostaako sinua enemmän koodin julkaiseminen kuin pääkäyttöoikeudet? Tutustu tähän:
Ensimmäiset 90 päivää: ohjelmistoinsinöörin painos

Ja kyllä – lisää rooleja on tulossa pian. Pysy kuulolla tai, mikä vielä parempaa, tilaa uutiskirje, jotta et jää paitsi seuraavasta.