Petdeset avtomatizacij in register, ki pove, ali so še žive

Agencija, ki si sama izdeluje orodja, prej ali slej ostane z veliko stvarmi, ki tečejo same. Pri nas jih je približno petdeset: načrtovana opravila v CRM-ju in na spletnih straneh, skripte, povezane z e-poštnim predalom, nočne kopije podatkovnih zbirk, vgrajene avtomatizacije starih orodij, celo načrtovana opravila na računalniku v pisarni. Vsaka zase je preprosta. Težava je celota: v nekem trenutku nihče več ne zna z gotovostjo povedati, katere tečejo.

Ta članek opisuje, kako smo se odzvali: z enotnim registrom, v katerem ima vsak samostojni proces svoj vnos, in s pravilom, zaradi katerega je stran poštena.

Register, vnos za vnosom

Vsak vnos navaja iste stvari:

• ime, razumljivo človeku, ne tehnična pot;
• kje teče (CRM, spletna stran, skripta, vgrajena avtomatizacija, računalnik), ker je od tega odvisno, kdo ga lahko izklopi;
• pogostost, zapisano tako, kot bi jo povedal človek: »vsakih 15 minut«, »ponoči ob 3.15«;
• v kolikšnem času se pričakuje naslednji znak življenja;
• kaj počne in kdo ga izvaja, da se ob zaustavitvi ve, koga vprašati;
• tveganje: lahko piše stranki? obvešča samo ekipo? posega samo v podatke?
• dokaz delovanja in predvsem, katere vrste je.

Prav zaradi zadnje točke register obstaja.

Pet vrst dokazov, ker datum ni dovolj

Sprva smo imeli stran, ki je procese obarvala zeleno ali rdeče glede na zadnji zabeleženi datum. Eden je bil videti ustavljen že sedem dni: zdelo se je, da je mrtev. Ni bil. Tisti datum ni bil znak življenja procesa, temveč dnevnik, ki se zapiše samo, kadar je kaj dela. Proces je tekel vsako noč in ni imel česa zapisati.

Od takrat ločimo pet vrst dokazov:

Brez tega razlikovanja nadzorna plošča laže na najslabši način: prižiga rdeče alarme na zdravih sistemih, dokler jih nihče več ne gleda. Ko pa se nekaj zares pokvari, je rdeča le ena izmed mnogih.

»Brez dokaza« ni vdaja

Zadnja vrstica tabele je najkoristnejša. Nekaterih procesov danes ni mogoče opazovati: načrtovanih opravil na računalniku (če je računalnik ugasnjen, se ne zaženejo in nihče tega ne izve), vgrajenih avtomatizacij zunanjega orodja, ki ne ponuja berljivega dnevnika, kopije, ki teče v storitvi, katere izida ne beremo.

Če jih razglasimo za nevidne, namesto da bi jih izpustili, ima to dva učinka. Stran jih nikoli ne prikaže zeleno, zato ne obljublja ničesar, česar ne more vedeti. Seznam nevidnih pa postane čakalna vrsta dela, da bi jih naredili vidne. Proces, ki se razglasi za nevidnega, je koristnejši od tistega, ki se brez dokazov razglasi za zdravega.

Kaj smo našli po zaslugi registra

Popis vsega – na kodi v produkciji in na resničnih podatkih, ne na tem, kar je bilo zapisano drugje – je razkril stvari, ki jih nihče ni spremljal.

Kontrola, ki se je ustavila sama od sebe. Postopek, ki je znova pregledoval samodejne razvrstitve e-poštnih sporočil, da bi jih popravil, je obdelal nekaj tisoč sporočil, nato pa se je sredi junija ustavil. Nihče ni opazil, ker tega ni sporočala nobena opozorilna lučka. Tekel je kot ročno zagnana seja in ni puščal sledi.

Speč, a nabit motor. Stara skripta, ki je e-poštna sporočila razvrščala z modelom umetne inteligence, je mirovala že več mesecev, a njen ključ je bil še vedno na mestu in projekt je obstajal. Dovolj bi bilo znova vklopiti sprožilec, pa bi se spet vrinila v verigo in nova sporočila prevzela pred pravim motorjem. Nobene napake, nikjer: le stiki, ki ne nastanejo. Register, ki je ni navajal, je za zdravo razglašal verigo, v kateri je čakal tekmec.

Dve sporočili, poslani sami od sebe. Julija sta strankam odšli dve sporočili, medtem ko je plošča avtomatizacij kazala, da se ne pošilja nobeno. Iz tega incidenta je nastalo glavno stikalo, vsaka avtomatizacija, ki lahko piše stranki, pa je ob nastanku izklopljena.

En sam izvajalec na avtomatizacijo

Pri selitvi avtomatizacij iz starega CRM-ja v novega smo uvedli strogo pravilo: vsaka avtomatizacija ima enega samega izvajalca. Nova različica nastane za izklopljenim stikalom, medtem ko stara dvojnica teče naprej. Prehod je dvojna poteza: tam se izklopi in tu vklopi, v isti minuti. Dokler se to ne zgodi, register novo različico prikazuje kot »izklopljeno«, in to je resnica. Dva hkrati vklopljena izvajalca ne sprožita napake: ustvarita dve različni sliki istega dne ali pa dva opomnika za isto stvar.

Kdo nadzoruje nadzornika

Vsa opozorila v CRM-ju so odvisna od enega samega procesa, ki posodablja opozorilne lučke. Če se ustavi on, se tiho ustavijo vsa opozorila. Zato obstaja zunanji stražar na drugi infrastrukturi, ki vsake pol ure preveri eno samo stvar: ali je ta proces nedavno oddal utrip. Če molči, pošlje opozorilo po istem kanalu kot lučke. Stražar tudi sam pušča utrip, ki ga nadzirajo notranje lučke. Drug drugega opazujeta.

Cron, ki je tekel, a ni obstajal

Zadnja napaka je stara le nekaj dni. V novem CRM-ju je vsak utrip vezan na proces, ki ga odda: podatkovna zbirka zavrne utrip procesa, ki ni registriran. V produkcijo smo dali novo načrtovano opravilo in pozabili na njegovo vrstico v registru. Opravilo je redno teklo, njegov utrip pa je bil zavrnjen, z opozorilom, ki se je videlo samo v dnevnikih. Za lučko zdravja tega procesa preprosto ni bilo.

Omejitev je opravila svoje: namesto da bi sprejela osirotel utrip, ga je zavrnila. A zavrnitev, ki konča samo v dnevniku, je še vedno pretiha. Opazili smo jo, ker smo tisto vrstico pričakovali, pa je ni bilo. Od takrat je vrstica v registru del iste skripte, ki ustvari opravilo, po vsaki objavi pa se preveri, ali je prvi utrip res prispel.

Povzetek

Za to, da veste, ali so vaše avtomatizacije žive, ne potrebujete dragega orodja za spremljanje. Potrebujete enoten seznam, sestavljen na podlagi tega, kar zares teče; pošteno razlikovanje med vrstami dokazov; stikalo za vsak proces; in navado, da ne zaupate zeleni barvi, kadar je nihče ne more dokazati.