Operaatiot koodina: toistuva kaaos runbookeiksi

On olemassa tietynlaista stressiä, jolla ei ole mitään tekemistä vaikeuden kanssa. Työ ei ole hankalaa. Olet tehnyt sen kaksikymmentä kertaa. Se on vuosiraportti, kevään tapahtuma, uuden työntekijän ensimmäinen viikko. Tiedät miten se menee. Ja silti joka ikinen kerta kun se koittaa, se koittaa pienenä hätätilana: puoliksi muistettujen askelten sähläys, kuumeinen kaivelu viime vuoden sähköposteista oikean pohjan löytämiseksi, kollega joka kysyy kysymyksen johon olet vastannut jo neljä kertaa ja vastaat taas ensi vuonna.

Se stressi on vero, ja se on täysin itse aiheutettua. Maksat joka kierroksella siitä etuoikeudesta, ettet ole kirjoittanut mitään ylös.

Vietin vuosia rooleissa, jotka rakentuivat lähes kokonaan toistuvasta kaaoksesta. Nuorissa Kotkissa, nuorisojärjestössä, vedin yli kaksikymmentä tapahtumaa vuodessa sadoille nuorille, plus monivuotisen avustusten raportointiputken rahoittajan kanssa, joka ei hyväksynyt vastaukseksi "unohdimme yhden vaiheen". IKEAlla istuin reklamaatiopuolella, jossa koko työ on suuren volyymin toistuvaa harkintaa: samat eskaloituneiden asiakasvalitusten kategoriat, kerta toisensa jälkeen, koko päivän. Molemmissa paikoissa opin saman asian samalla kivuliaalla tavalla. Kaaos ei koskaan ollut itse työssä. Se oli siinä, että työ asui ihmisten päässä eikä paperilla.

Tässä on siis se kehys, joka muutti tapani toimia: kohtele operaatioita kuin koodia.

Mitä "operaatiot koodina" oikeasti tarkoittaa

Kehittäjät tajusivat tämän kauan sitten. Et ratkaise samaa ongelmaa kahdesti ulkomuistista. Kirjoitat sen ylös koodina, laitat versionhallintaan ja automatisoit ne osat jotka ovat mekaanisia. Nokkeluus napataan talteen kerran, ja sitten se vain pyörii. Kukaan ei johda uudestaan ulkomuistista joka perjantai, miten sovellus deployataan.

Operaatiot ovat täynnä ongelmia jotka ratkaistaan yhä uudelleen, eikä lähes mitään niistä kohdella näin. Kohtelemme jokaista toistumaa kuin se olisi ensimmäinen kerta, sen sankaruuden voimalla, joka sattuu muistamaan. Se on se bugi.

Operaatiot koodina tarkoittaa kolmea siirtoa, lainattuna suoraan hyvien insinööritiimien tavasta tehdä työtä:

Kirjoita ylös, jotta tieto asuu tiedostossa eikä kallon sisällä. Versioi, jotta näet mikä muuttui ja miksi, ja voit parantaa tarkoituksella etkä vahingossa. Automatisoi siellä missä se kannattaa, jotta tylsät, mekaaniset osat lakkaavat syömästä ihmisen huomiota.

Tämän kaiken yksikkö on runbook. Ei linjauspaperi, ei lihava wiki jota kukaan ei lue. Runbook on operatiivinen vastine funktiolle: nimetty, toistettava menettely, joka ottaa syötteitä ja tuottaa luotettavasti tuloksen, kirjoitettuna niin että pätevä ihminen joka ei ole sinä pystyy ajamaan sen ja saamaan saman tuloksen.

Miten löydät viikkoosi piiloutuneet runbookit

Et aloita kirjoittamalla sataa runbookia. Se on dokumentaatioteatteria, ja se mätänee nopeammin kuin ehdit tuottaa sitä. Aloitat löytämällä ne muutamat menettelyt, jotka oikeasti maksavat sinulle.

Käyttämäni testi on yksinkertainen ja vähän tyly: taajuus kertaa kipu kertaa bussikerroin.

• Taajuus. Kuinka usein tämä tapahtuu? Viikoittain tekemäsi asia on paljon parempi ehdokas kuin asia, jonka teet kerran.
• Kipu. Kuinka paljon jokainen toistuma sattuu? Stressi, uudelleentekeminen, virheet, se kauhistus jonka tunnet nähdessäsi sen kalenterissa.
• Bussikerroin. Kuinka moni osaa tehdä sen ilman sinua? Jos vastaus on yksi, ja se yksi olet sinä, riski on keskittynyt yhteen pettämispisteeseen jolla on syke.

Kerro nuo karkeasti päässäsi. Korkealle yltävät menettelyt ovat ensimmäiset runbookisi. Kaikki muu saa odottaa, mahdollisesti ikuisesti.

Nuorissa Kotkissa korkeimmalle yltävä asia oli ilmeinen heti kun katsoin: tapahtumakierto. Yli kaksikymmentä kertaa vuodessa (korkea taajuus), sama toistuva paniikki logistiikan, ilmoittautumisten ja turvapaperien ympärillä (korkea kipu), aivan liian iso osa siitä riippuvaisena nimenomaan minusta (kammottava bussikerroin). Avustusraportointi ylsi melkein yhtä korkealle, sillä lisävirityksellä että väärin tekeminen kostautui oikeasti rahoittajan suuntaan. Nämä kaksi kirjoitettiin ylös ensin. Se kertaluontoinen "järjestä hallituksen vuosijuhlaillallinen" ei tullut, koska se ei koskaan toistuisi samanlaisena ja runbookista olisi tullut museoesine.

Miten kirjoitat runbookin jota joku oikeasti käyttää

Useimmat sisäiset dokumentit epäonnistuvat, koska ne on kirjoitettu proosaksi: kirjoittaja todistelee ymmärtävänsä prosessin kuvitellulle lukijalle, joka osaa sen jo. Runbook on päinvastainen. Se on kirjoitettu tarkistuslistaksi: kirjoittaja yrittää tehdä itsensä tarpeettomaksi stressaantuneelle kollegalle, joka tekee tätä kello neljä iltapäivällä deadline niskassa.

Toimivassa runbookissa on viisi osaa.

1. Laukaisin

Milloin tämä ajetaan? "Joka kvartaali, kaksi viikkoa ennen valtionavustuksen raportoinnin deadlinea." Menettely ilman laukaisinta on dokumentti. Menettely jolla on laukaisin on tapa joka odottaa syntymistään.

2. Syötteet

Mitä tarvitset käteen ennen kuin aloitat? Ilmoittautumislista, viime kvartaalin luvut, paikan yhteyshenkilö, budjettirivi. Syötteiden listaaminen heti alkuun tappaa yleisimmän epäonnistumisen: pääset kolme askelta sisään ja huomaat, että sinulta puuttuu jokin jonka hankkimiseen menee kaksi päivää.

3. Numeroidut askeleet, oikeassa järjestyksessä

Varsinainen sekvenssi, tylsänä ja eksplisiittisenä. Ei "hoida ilmoittautumiset" vaan "vie ilmoittautumislista ulos, tarkista alle 18-vuotiaat ilman huoltajan allekirjoitusta, merkitse ne paikalliselle koordinaattorille". Jokaisen askeleen pitäisi olla niin pieni, ettei ole epäselvää, oletko tehnyt sen vai et.

4. Tarkistus

Tämä on se askel jonka kaikki ohittavat ja se joka ansaitsee paikkansa. Mistä tiedät että se onnistui? IKEAlla reklamaatiopäätökset saattoivat mennä pieleen hiljaisilla, kalliilla tavoilla: hyvitys hyväksyttynä väärää linjausta vasten, tapaus suljettuna ilman että asiakas oikeasti sai mitä kuului. Tarkistusvaihe on se, mihin kirjoitat ne tarkistukset jotka nappaavat nuo: täsmääkö summa linjaukseen, onko asiakas vahvistanut, onko tapaus oikeasti suljettu eikä vain merkitty suljetuksi. Runbook ilman tarkistusta on vain nopeampi tapa toimittaa samat virheet, isommalla itsevarmuudella.

5. Omistaja

Nimi, ei osasto. Ihminen joka vastaa siitä että tämä runbook pysyy totena kun pohja muuttuu, tiimi muuttuu tai työkalu muuttuu. Ilman omistajaa jokainen runbook on tarkka sinä päivänä kun se kirjoitetaan ja muuttuu hitaasti ansaksi, koska ihmiset luottavat siihen senkin jälkeen kun se on lakannut olemasta oikeassa.

Tältä yksi näyttää, riisuttuna:

# tapahtuma-runbook.md
# Laukaisin: 3 viikkoa ennen mitä tahansa paikallista tapahtumaa
# Omistaja: operaatiokoordinaattori
#
# Syötteet:
#   - paikka vahvistettu + yhteyshenkilö
#   - ilmoittautumislomake auki
#   - turva- ja huoltajan suostumus -pohja
#
# Askeleet:
#   1. Avaa ilmoittautuminen, aseta katto, aseta sulkupäivä.
#   2. T-7: vie lista ulos. Tarkista että jokaisella alle 18-v on suostumus.
#      -> puuttuva suostumus on STOP. Merkitse paikalliselle koordinaattorille.
#   3. T-3: vahvista cateringin henkilömäärä listaa vasten.
#   4. T-1: tulosta läsnäololista + hätäyhteystiedot.
#
# Tarkista ennen "valmista":
#   - jokaisella osallistujalla on suostumus kirjattuna (ei poikkeuksia)
#   - hätäyhteystietolista fyysisesti paikan päällä
#   - joku muu kuin sinä tietää missä ensiapulaukku on

Se kommentti, että puuttuvan suostumuksen rivi on kova STOP, on tärkeämpi kuin formaatin nätteys. Se on arpikudosta oikeasta läheltä piti -tilanteesta, ja se kertoo seuraavalle ihmiselle mitkä askeleet ovat neuvoteltavissa ja mitkä eivät.

Automatisoi siellä missä se kannattaa, ei joka paikassa

Kun menettely on kerran kirjoitettu eksplisiittisinä askelina, mekaaniset osat tulevat näkyviksi, ja jotkin niistä suorastaan rukoilevat automatisointia. Järjestys ratkaisee: kirjoita runbook ensin, automatisoi sitten siitä. Ihmiset jotka yrittävät automatisoida prosessin jota eivät ole vielä kirjoittaneet ylös, päätyvät automatisoimaan oman sekaannuksensa.

Mutta automaatio ei ole ilmaista, ja viettelevä epäonnistuminen tässä on automatisoida asioita jotka olisi pitänyt jättää manuaalisiksi. Sääntöni: automatisoi askel jos se on mekaaninen, korkeataajuinen ja matalan harkinnan. Jätä se rauhaan jos se vaatii ihmistä päättämään jotain.

Tapahtuma-runbookissa läsnäololistan luominen ilmoittautumislistasta on puhdasta mekaniikkaa. Automatisoi. Sen päättäminen, lähestytäänkö vanhempaa puuttuvan suostumuslomakkeen takia, on harkintaa ja ihmissuhde. Jätä se ihmiselle. Avustusraportoinnissa raakalukujen vetäminen oikeaan rakenteeseen on mekaanista ja nykyään tekoälyn avustamaa kaikessa mitä rakennan. Sen päättäminen, mitä tarinaa nuo luvut rahoittajalle kertovat, on se varsinainen työ, eikä yhdenkään skriptin pidä koskea siihen.

Rehellinen versio "automatisoi siellä missä se kannattaa" -ohjeesta sisältää sen hinnan, että automaatio hajoaa. Skripti joka pettää hiljaa on pahempi kuin manuaalinen askel, jonka ihminen olisi huomannut menevän pieleen. Joten automatisoin vain siellä missä pettäminen on äänekästä, ja pidän ihmisen tarkistusvaiheen joka tapauksessa. Automaatio luonnostelee; ihminen yhä kuittaa.

Epäonnistumistavat, nimettyinä

Olen törmännyt näihin kaikkiin, joten nimeän ne suoraan.

Runbookin mätäneminen. Runbook joka hiljaa lakkaa vastaamasta todellisuutta on vaarallisempi kuin ei mitään, koska ihmiset seuraavat sitä jyrkänteen yli. Tämä on koko syy siihen miksi omistaja on olemassa. Dokumentti ilman omistajaa on tuleva häiriö, jossa on viiveajastin.

Prosessi prosessin vuoksi. Liian innokas versio dokumentoi kaiken ja muuttaa hyödyllisen työkalun byrokratiaksi, jonka ohi ihmiset kiertävät. Testi on aina taajuus kertaa kipu kertaa bussikerroin. Jos menettely ei yllä, se ei saa runbookia, piste.

Kirjoittaminen väärälle lukijalle. Dokumentaatio joka on kirjoitettu osoittamaan kirjoittajan mestaruus eikä mahdollistamaan tuntemattoman onnistuminen. Lukija ei ole pomosi. Se on väsynyt kollega joka ei ole koskaan tehnyt tätä ja jonka pitää olla mokaamatta. Kirjoita hänelle.

Kirjoittamattoman automatisointi. Skriptin kurkottaminen ennen kuin askeleet ovat selvät. Et voi automatisoida prosessia jota et osaa kuvata. Runbook on spesifikaatio; automaatio on toteutus. Spesifikaatio ensin, aina.

Se korkoa korolle -osa

Asia jota kukaan ei kerro operaatioiden kohtelemisesta koodina, on että arvo kertyy korkoa korolle, hiljaa, samalla tavalla kuin hyvä koodipohja.

Ensimmäisellä kerralla kun kirjoitat tapahtuma-runbookin, se maksaa sinulle iltapäivän eikä säästä juuri mitään, koska olisit ajanut sen tapahtuman ulkomuistista joka tapauksessa. Toisella kerralla se säästää sähläyksen. Viidenteen tapahtumaan mennessä uusi vapaaehtoinen ajaa siitä suurimman osan ilman sinua huoneessa, ja sinulla on huomiosi takaisin niitä asioita varten jotka oikeasti tarvitsevat ihmisaivot. Siihen mennessä kun lähdet, luovutat kansiollisen runbookeja etkä kriisiä. Tuo viimeinen osa ei ole kiva lisä. Se on koko pointti.

Tämä on sama uskomus joka istuu kaiken alla mitä rakennan Impact Nodessa: skaalautuminen toimii järjestelmillä, ei hyvällä tahdolla. Hyvä tahto on se kollega joka aina muistaa askeleet ja pelastaa päivän. Se on ihana asia, ja se on riski, koska se ei skaalaudu eikä tule paikalle sinä viikkona kun hän on kipeänä. Runbook on se mitä jää jäljelle kun sankaruus on poissa. Se on hyvää tahtoa, kirjoitettuna ylös, jotta sitä ei tarvitse ansaita uudelleen joka ikinen kerta.

Joten kun toistuva tehtävä seuraavan kerran tipahtaa pöydällesi pienenä hätätilana, älä vain jyrää sen läpi ulkomuistilla ja adrenaliinilla. Huomaa että maksat veroa taas. Kirjoita funktio. Aja se ensi kerralla. Kaaos ei koskaan ollut itse työssä.