Miten suhtautua sovellusvirheisiin tuotannossa

Eräässä aikaisemmin julkaisemassamme blogissa käsiteltiin lokienhallintaa ja puhuttiin siitä, kuinka pelkkä lokienhallintatyökalu harvoin pystyy antamaan helpotusta asiaan, jota varten se on usein hankittu; tuotannon sovellusvirheiden selvittämiseen. Tässä blogissa puhutaan lisää siitä, miten yksittäisistä ja epämääräisistä lokiviesteistä voidaan saada paljonkin tietoa, mikäli apuna on taianomainen ase nimeltään kattava transaktiokonteksti.

Kun lähtökohtana on riittämätön lokiviesti

On perjantai-iltapäivä, ja kehitystiimi on juuri antanut sinulle uusimman julkaisun artefaktit, jotka täytyvät olla käyttövalmiita maanantaiaamuun mennessä. Tehtyäsi töitä koko yön ja seuraavan päivän, jotta julkaisu saataisiin tuotantoon ajoissa, huomaat maanantaina kaiken sen vaivan palkkana olevan vaivainen, riittämätön lokiviesti. Kuulostaako tutulta?

Toivottavasti ei. Tämä kuitenkin osoittaa, kuinka osa operaattorin työtä kehityksen ja tuotannon parissa on tuotantoympäristön valvominen ja sovellusvirheiden selvittelyssä avustaminen lokiviestien avulla – lokiviestien, jotka kehittäjät ovat sisällyttäneet koodeihinsa.

Miksi virhevapaata koodia ei ole olemassa

Kuten yleisesti tiedetään, sovellusvirheitä ei pystytä poistamaan tuotannosta kokonaan. Ketterät ohjelmointimetodit, kuten Extreme Programming (XP) ja Scrum, pyrkivät rakentamaan laadukkaita kehitysprosesseja. Siltikään, 100 % virhevapaata sovellusta ei ole olemassa. On yksinkertaisesti mahdotonta testata sovelluksen jokaista pientä ominaisuutta jokaisessa mahdollisessa syöteparametrin ja sovellustilan yhdistelmässä. Ainoastaan rajattu joukko mahdollisia testitilanteita voidaan suorittaa. Kehittäjien ja testiautomaatiosta vastaavien insinöörien yhteinen päämäärä tulisi siis olla sellaisen testausstrategian luominen, että riittävän laadukkaan koodin rakentaminen on tarpeeksi. Näin virheen esiintyessä kattavan transaktiokontekstin avulla pystytään vastaamaan kysymyksiin:

• Kuinka montaa käyttäjää virhe kosketti ja keitä he ovat?
• Mitkä virheet vaikuttivat mihinkin sovellustasoon?
• Mikä oli virheen pohjimmainen syy?

Päätelmät

Oikea työkalu mahdollistaa menestymisen DevOpsin parissa. Esimerkiksi Dynatrace (saatavilla Free Trial) mahdollistaa valvottujen sessioiden tallentamisen tiedostona, joka pystytään jakamaan tiimien kesken. Käytäntö sekä turvaa todisteet että mahdollistaa yhteistyön eri tiimien välillä; tuotannossa tapahtuvia virheitä voidaan seurata ja ne voidaan osoittaa kehitystiimille, joka pystyy aloittamaan niiden paikkaamisen. Samaan aikaan testiautomaatiota kehittävät henkilöt voivat muokata prosessejaan ja estää saman virheen uusiutumisen.

Alkuperäisen artikkelin löydät osoitteesta: http://apmblog.compuware.com/2014/07/22/approach-application-failures-production/

Blogin kirjoittajasta

Martin Etmajer on työskennellyt useita vuosia sovellusarkkitehtinä muun muassa moniympäristöjen parissa. Tällä hetkellä hän toimii Dynatracen Center of Excellence -keskuksessa teknologiastrategistina ja kehittää sovellusten valvontaratkaisuja ja DevOps-strategioita.