Dziiiiin! Kello on kolme aamulla, näet upeaa unta, ja yhtäkkiä tulee puhelu. Olet päivystyksessä tällä viikolla, ja ilmeisesti jotain tapahtui. Automaattinen järjestelmä soittaa selvittääkseen, mikä on vialla. Tämä on tärkeä osa nykyaikaisten tietokonejärjestelmien hallintaa, mutta katsotaanpa, miten ilmoituksista voidaan tehdä parempia ihmisille.
Tutustu seurantafilosofiaan, joka on syntynyt useiden vuosikymmenien aikana työtehtävissäni eri seurantatiimeissä. Hän sai suuren vaikutuksen Rob Evashchukin oikeasta Raamatusta (My Notification Philosophy) sisältyy kirjaan , ja kirja John Alspaugh (Huomioita hälytysten asettamisesta).
, и - kiitos avustasi postauksen muokkaamisessa.
Mikä on CASE?
Päätin keksiä kauniin lyhenteen, kuten tai . minä kutsun sitä CASE-menetelmä. Hän kuvailee neljä seikkaa, joihin on kiinnitettävä huomiota työskennellessään automaattisen valvonnan kanssa:
- (konteksttiin sidottu)
- (käytännöllinen arvo)
- (painotus oireille)
- (arvosana)
Jos käytät CASEa, kohtelet ilmoituksia terveellä välinpitämättömyydellä etkä herätä ihmisiä yöllä. Seurannan hyödyllisyys ja tehokkuus on arvioitava säännöllisesti. Kun henkilö saa ilmoituksen, hänellä on parempia henkisiä malleja ja enemmän luottamusta.
Muistamisen helpottamiseksi kuvittele, että tarvitset CASE [eli tapauksen, syyn - kääntäjän huomautus] jokaisen hälytyksen perustelemiseksi. :aurinkolasit:
Ja miksi tämä kaikki on?
. Monista syistä. Eikä CASE poista niitä kaikkia. Mutta sen avulla heräät yöllä parempiin ilmoituksiin. Tämä menetelmä kattaa erilaisia organisaatioprosesseja, jotka auttavat myös tässä asiassa.
RED- ja USE-menetelmien kauneus on, että niiden avulla emme vain osaa työskennellä, vaan myös puhumme samaa kieltä toistensa kanssa. Toivon, että CASE-menetelmällä on helpompi keskustella ilmoituksista, jotka suojaavat järjestelmiämme, mutta pitävät kollegamme kiireisinä.
Asia on siinä, että sinun on luotava organisaatioosi kulttuuri, jossa ilmoituksiin suhtaudutaan terveellä välinpitämättömyydellä. Ilmoitukset voidaan luoda tiettyyn tarkoitukseen, mutta ei ole tosiasia, etteivät ne menetä arvoaan myöhemmin. Miksi loimme tämän ilmoituksen? Kuinka kauan sitten sen kriteerit on tarkistettu? CASE:n avulla näihin kysymyksiin voidaan vastata.
Context-Heavy - kontekstin sidonta
Kello 3 ei ole paras aika lukea viestejä, jotka sisältävät paljon älykkäitä sanoja. Jotta voit vastata tehokkaasti, tarvitset tietoa. Ihannetapauksessa tämän pitäisi olla tietoa tietystä ongelmasta, jonka konteksti on heti selvä, ja ilmoitukset tulisi määrittää niin, että tämä on mahdollista. Tämä on "havainnointi" ja "suuntautuminen". . Ei ole häpeä viettää aikaa tähän asetukseen, koska ihmisen jatkuva häiritseminen on vielä kalliimpaa. Kunnioitetaan toisiamme.
Ongelmilla on monia lähteitä. Varsinkin haamut.
Miten voin auttaa päivystävää? Ensimmäinen asia, jonka päivystäjä näkee, on ilmoitus, joten hän rakentaa kaikki hypoteesit sen perusteella. Sitten hän katselee ohjeita ja kojetauluja, mutta onko tietystä ilmoituksesta aina tietoa, ei vain yleistä tietoa? Alspaugh neuvoo "ajattelemaan, kuinka voisit tulkita ilmoituksen tai vastata siihen" (dia 29). Hyvä ilmoitus keskittyy päivystävään henkilöön, ei vain kynnyksen määrittämää.
Joten tässä on joitain ideoita ilmoituskontekstin parantamiseen:
- Näytä käyttäjälle jotain hyödyllistä ja erityisesti luotua, ei vain tavallisia ohjeita tai kojelautaa. Aiemmin kaverit ja minä käytimme tutkivia hallintapaneeleja, jotka oli määritetty tietyille ilmoituksille. Tämä auttaa, jos ongelma on tiedossa, mutta se vain hämmentää muita. Meidän on löydettävä tasapaino tässä.
- Kerro meille ilmoituksen historiasta: onko se uutta? Toimiiko se usein? Onko se kausiluonteista?
- Näytä viimeisimmät muutokset järjestelmän tilaan. Onko mikään muuttunut viime aikoina? (Esimerkiksi käyttöönotto tai toimintojen käyttöönotto/poistaminen käytöstä.)
- Näytä suhteet ja anna tietoa mentaalimallia varten: järjestelmäriippuvuuksien tulee olla selvästi näkyvissä, mieluiten toiminnallisuudella.
- Yhdistä käyttäjä nopeasti tiimiin: näkevätkö he meneillään olevat tapaukset vai voivatko he selvittää, ketkä muut yrityksen jäsenet ovat saaneet ilmoituksen? Ohjelmoida aktivoitu?
Ihannetapauksessa tapahtumanhallintaohjelma antaa neuvoja siitä, kuinka parantaa tapaturmien tutkinnan ilmoituskontekstia. Aina löytyy jotain tekemistä!
Toimiva – käytännön arvo
Pitäisikö päivystäjän tehdä jotain vastauksena ilmoitukseen? Jos sinun ei tarvitse tehdä mitään tai on epäselvää, mitä tehdä, miksi heräsit hänet? Sinun on vältettävä ilmoituksia, jotka ärsyttävät päivystäviä eivätkä vaadi toimia.
Mitä minun pitäisi tehdä? Mitä haluat?
Aikaisemmin, kun järjestelmät olivat yksinkertaisia ja tiimit pieniä, määritimme valvonnan vain pysyäksemme ajan tasalla. Ilmoitus kasan kuormituksen lisääntymisestä antaa meille kontekstin, jos palvelussa myöhemmin ilmenee toimintahäiriö. Suuressa mittakaavassa tällaiset ilmoitukset aiheuttavat vain hämmennystä, koska järjestelmämme toimivat aina vaihtelevan vakavuuden tilassa. Tämä johtaa nopeasti ja tietysti herkkyyden menetys. Siksi päivystäjä jättää huomiotta tai jopa suodattaa tällaiset ilmoitukset eikä aina vastaa niihin tarpeen mukaan. Älä lankea tähän ansaan! Älä aseta kaikkia ilmoituksia peräkkäin ja lähetä niitä sitten sähköpostitse johonkin jumalan hylkäämään kansioon.
Käytännön arvoinen ilmoitus näyttää tältä:
- Ilmoitus vaatii toimenpiteitä pelkän uutisen raportoimisen sijaan.
- Tämä toiminto on vaikea tai riskialtista automatisoida. Jos toiminto voidaan automatisoida, automatisoi se, lopeta ihmisten kiusaaminen!
- Ilmoitus sisältää kiireellisiä suosituksia lomakkeessa (SLA) tai (RTO). Päivystäjä voi sitten aktivoida organisaation tapaustenhallintaohjelman.
Haluan selventää: en väitä, että ilmoitusten tulisi tulla vain API:n tärkeimmistä SLO:ista (palvelutason tavoitteista). SLO-valvonta on jatkuvasti pirstoutunutta ja jakautunutta ja edellyttää samaa lähestymistapaa kaikkiin palveluihin. On selvää, että seuraat sinulle maksavien asiakkaiden tärkeimpiä SLO:ita. Mutta myös infrastruktuurin SLO:ita, kuten tietokantoja, on valvottava. Pian joudut olemaan tekemisissä sisäisten asiakkaiden kanssa ja tukemaan heitä. Ja niin edelleen loputtomiin.
Oirepohjainen - oireiden painottaminen
Halusit tai et, työskentelet hajautetussa järjestelmässä (Kavaj). Tämän seurauksena käytät erilaisia taktiikoita palveluiden eristämiseen ja niiden suojaamiseen epäonnistumiselta (Trainor et al.)3. Ja vaikka pitkä roskankeruu tai pysähtynyt tietokantakysely viittaa ongelmiin, niitä ei tarvitse kiirehtiä korjaamaan, jos käyttäjillä ei ole ongelmia lähitulevaisuudessa.
Nämä ovat tärkeitä signaaleja ja niillä voi olla käytännön arvoa, mutta jos ne eivät häiritse käyttäjiä, ei ole tarpeeksi kiireellistä häiritä hoitajaa. Syypohjaiset ilmoitukset ovat tilannekuvia mielenterveysmalleistamme järjestelmävirheestä. On parempi seurata tärkeitä oireita kuin yrittää luetella kaikki mahdolliset epäonnistumisen syyt.
Tee ilmoituksista merkityksellisiä keskittymällä , tärkeitä käyttäjille. Evashchuk kutsuu tätä "käyttäjien tarkkailuksi". Muista, että tätä filosofiaa on sovellettava koko organisaatiossa. Jos palvelulla on kiireellisiä ongelmia jossain syvällä infrastruktuurissa, asianmukainen tiimi hoitaa ne. Järjestelmien suojaaminen tällaisilta häiriöiltä on täysin erillinen asia (Trainer et al., osio kriittisten riippuvuuksien minimoimisen strategioista).
Oireet eivät ole yhtä vaihtelevia
Richard Cook muistuttaa, että monimutkaiset järjestelmät ovat täynnä puutteita, puutteita ja ongelmia. Kaikkien mahdollisten syiden luetteleminen on Sisyphosen tehtävä. Yrität kuvailla ongelmia, mutta ne muuttuvat koko ajan. Cindy Sridharan uskoo, että "järjestelmien ei tarvitse olla täydellisessä kunnossa joka sekunti" ja on parempi käyttää inhimillisempää lähestymistapaa ( ("Hajautettujen järjestelmien valvonta"), 7).
Vältä ilmoituksia tapahtuman jälkeen
Tyypillisesti syitä koskevat ilmoitukset on määritetty korjaamaan tapahtumat. Ja nämä rajoitetut ilmoitukset tapahtuneesta luovat väärän turvallisuuden tunteen, koska järjestelmä keksii joka kerta uusia tapoja rikkoutua.
Älä anna syyilmoitusten pettää. Parempi ajatella:
- Miksi oirepohjainen ilmoitus ei huomannut ongelmaa?
- Auttaisiko kontekstin parantaminen käyttäjän kannalta?
- Miten seurantatyökaluja voidaan parantaa diagnoosin tekemiseksi nopeammin sen sijaan, että kerääntyisi ilmoituksia tapahtuneesta?
Diagnoosin seurantatyökalut auttavat vain, jos ajattelet niitä keinona siirtyä oireesta ratkaisuun. Ilman tätä palautetta sinua yksinkertaisesti pommitetaan myöhästyneillä ilmoituksilla ja kaavioilla menneistä epäonnistumisista – etkä sanaakaan tulevista. Tämä on loistava tilaisuus organisaatiolle siirtyä puolustuksesta hyökkäykseen. Ja kehittäjillä ja tuotepäälliköillä on samat odotukset ja selkeät tavoitteet. Tapaus - CASE (:wink:) - on selvä jokaiselle ilmoitukselle.
Syypohjaiset ilmoitukset ovat kohtuullisesti siedettyjä
Joskus järjestelmämme jättää meille vähän valinnanvaraa syypohjaisten ilmoitusten suhteen. Ja joskus päivystävät ymmärtävät erittäin hyvin, että oireet johtavat varmasti epäonnistumiseen, ja siksi sillä on käytännön arvoa. Ehkä et vain ole varma, mitä tapahtuu, ja asetat ilmoituksia varmuuden vuoksi. Toivottavasti tämä toimenpide on väliaikainen, kunnes voimme muuttaa järjestelmää suorituskykyongelman ratkaisemiseksi.
Pidä CASE:n muut osat mielessä, kun käsittelet näitä tilanteita. Se, että se on väliaikaista, ei tarkoita, että voit lopettaa ajattelun päässäsi.
Arvioitu - arviointi
Kaikki muutokset järjestelmään (uusi koodi, uusi infrastruktuuri, kaikki uusi) laajentavat vikojen määrää (Cook, 3). Toimiiko tämä ilmoitus edelleen odotetulla tavalla? Selkeät ja ajantasaiset järjestelmämallit ja kokemus vastaamisesta joihinkin tukiilmoituksiin - Nämä ovat tärkeimmät ominaisuudet . Virheet järjestelmissä kehittyvät jatkuvasti, ja meidän on pysyttävä niiden mukana.
Sinun on arvioitava jatkuvasti kunkin ilmoituksen laatua varmistaaksesi, että ne toimivat odotetulla tavalla. Arvoisat johtajat! Tiimillesi on paljon helpompaa, jos autat heitä luomaan tämän prosessin! Tässä muutamia arviointiideoita:
- käyttö , tai muita ilmoitusten testausmenetelmiä. Tiimi voi tehdä sen itse ilman, että hänen tarvitsee luottaa raskaaseen tapaustenhallintajärjestelmään!
- Sisällytä kaikkien tapahtumiin liittyvien ilmoitusten kerääminen tapahtumanhallintaohjelmaasi. Merkitse hyödyllisiksi, haitallisiksi, sopimattomiksi, epäselviksi jne. Käytä niitä palautteena.
- Oikeat ilmoitukset laukeavat harvoin ja ne testataan huolellisesti. Varmista, että kaikki linkit toimivat, osoittavat oikeaan kontekstiin jne.
- Jos ilmoitus ei koskaan käynnisty tai käynnistyy liian usein, siinä on jotain vikaa. Korjaa tai poista se. Varo liiallista passiivisuutta tai aktiivisuutta!
- Aseta ilmoitusten aikaleimat, joissa on viimeinen voimassaolopäivä. Jos viimeinen voimassaolopäivä on vanhentunut, arvioi ilmoitus CASE-menetelmällä ja päivitä aikaleima. Kuten ruoka, tarkista viimeinen käyttöpäivä säännöllisesti.
- Yksinkertaista ilmoitusten parantamisprosessia. Käytä valvontaa koodina ja tallenna ilmoituksia Git-tietovarastoon. Pull-pyynnöt auttavat sitouttamaan tiimiä ja antavat sinulle historian aiemmista ilmoituksista. Etkä enää pelkää muuttaa ilmoituksia tai pyytää lupaa niistä vastaavilta.
- Määritä palaute ilmoituksille, vaikka se olisi helppoa , jotta päivystäjä merkitsee ilmoitukset hyödyttömiksi tai häiritseviksi. Upota linkki tai toimintakehotus itse ilmoitukseen ja tarkista palautteesi säännöllisesti.
- Luo sääntö tiimiin - anna päivystystyöntekijöiden tehdä työtä yksinkertaistaakseen päivystystä, kun työtä on vähän. Olkoon kaikki sinun jälkeensi vähän paremmin kuin ennen.
Johtopäätös
Uskon, että CASE-menetelmä auttaa kehittäjiä ja organisaatioita keskustelemaan automaattisten ilmoitusten määrittämisestä ja lähettämisestä. Yksi kehittäjä voi aloittaa ilmoitusten arvioinnin CASE-menetelmällä, ja sitten koko organisaatio liittyy muihin kehittäjiin, hallinta- ja tapaustenhallintaohjelmiin pitämään ilmoitukset hyvässä kunnossa. Tämä ei vaadi erikoistyökaluja tai monimutkaisia prosesseja.
Koko alan on pohdittava inhimillistä tekijää päivystyksen aikana tinkimättä huippuluokan asiakaspalvelusta. Kaikkia näitä työkaluja ja käytäntöjä voidaan ja pitäisi parantaa. Toivon, että CASE-menetelmä auttaa tässä.
Nauti parannetuista ilmoituksista!
Lähde: will.com