Pakliže máte před sebou úkol řešit incident z produkce s prioritou jedna, moje zkušenost mi velí nesnažit se najít problém obecně. Rozhodně není dobré procházet zdrojový kód a přemýšlet, která proměnná by asi měla být synchronizována nebo na co se zapomnělo.

Kdybych musel sepsat pár pravidel, jak úspěšně a rychle řešit P1, bylo by to asi:

  1. Zapátrat v paměti. Zní to asi komicky, ale když se člověk poptá kolegů nebo zapátrá ve znalostní bázi, někdy objeví kostlivce ve skříni. Když má člověk den, rovnou i řešení.
  2. Reprodukovat chybu. To je absolutní základ a začátek všeho. Máte log soubor z produkčního systému, musíme chybu opakovat. Bez reprodukce není oprava. I když by programátor chybu odhalil (což je v rozporu s těmito pravidly), nemůže ji otestovat. Reprodukce dělá test case.
  3. Příprava workaroundu. Jedná se o chybu na produkci, proto není možné ztrácet čas zbytečnostmi. Nejlepší řešení je to nejjednodušší možné, které zajistí, aby se chyba už neopakovala. V některých vyjímečných případech může pomoci i to, že se chyba nebude opakovat tak často.
  4. Otestování. Pokud máte připravený test case zmíněný výše, mělo by to být snadné. Je třeba odhadnout, kolik má člověk asi času (termín, předpokládaný čas další chyby). Testovat se musí, ale v tomto případě přiměřeně. Předpokládám, že dodaný výsledek půjde ještě na akceptační test.
  5. Předání a podpora. Poslat hotfix do testování/produkce deset minut před odchodem domů asi nebude to pravé ořechové.
  6. Zahájení prací na opravě. To co bylo výše uděláno je workaround. Nyní je třeba minimálně naplánovat, jak bude probíhat odstranění chyby se vším všudy. S tím bývá někdy spojené i hledání nových verzí knihoven a kontrola changelog souborů či procházení open-source repozitářů (to je jistější). Někdy prostě chybu udělal někdo, koho vůbec neznáme. A třeba ji už opravil.

Tento zápisek vznikl převodem z mého starého blogu. Ne všechny texty byly takto převedeny, kompletní archiv již není k dispozici.