Praktijk en practices

Transcriptie

1 Troubleshooting Praktijk en practices Spreker(s) : Datum : Ruud van Leeuwen 6 juni 2013 [email protected]

2 Onderwerpen Tech stack komt aan bod Werkwijzen van troubleshooting Betrokken partijen en hun rol Praktijkvoorbeelden tonen: complexiteit van de stack belang van juiste logging belang van juist inzicht in applicatie componenten

3 Voorbeeld stack Database en Documenten Java applicatie (HTTP) Proxy Toegang over internet 3

4 Voorbeeld stack Praktijkvoorbeelden Voorbeeld stack: programmatuur van opslag tot gebruiker Plaatje verzekering klant database (structured data) document repository db-logica java applicatie logica op Applicatie Server reverse proxy

5 Casus download bestand Modernisering architectuur: applicatie wijzigt Java4 -> Java7 upgrade (incl libraries) WebSphere 6 -> GlassFish 3 (AS) Ook Oracle dbms 10g -> Oracle dbms 11g Vernieuwde omgevingen (virtual hosts) Database en Documenten Java applicatie (HTTP) Proxy Toegang over internet 5

6 Probleem wordt gemeld Testfase van een nieuwe release afgerond Acceptatiefase: klant meldt probleem Download van bestand uit systeem werkt niet Database en Documenten Java applicatie (HTTP) Proxy Toegang over internet 6

7 Nagaan oorzaak probleem Welke downloads gaan nog wel goed bij klant Welke verschillen TEST ACCP Langere download over HTTP Dynamisch aangemaakt bestand Reverse proxy was wel een component voor ACCP en PROD omgevingen, niet in TEST HTTP headers (keepalive, nocache, request time-out) waren kritiek in deze situatie 7

8 Oplossing ontwikkelen HTTP headers geregeld vanuit applicatie/as via reverse-proxy ook mogelijk Applicatie code herschreven HTTP headers beter stuurbaar Eisen vanuit compatibiliteit met browser, systeembelasting Database en Documenten Java applicatie (HTTP) Proxy Toegang over internet 8

9 Werkwijzen Troubleshooting Ad Hoc problemen: iedere minuut telt, systeem ligt plat Lange termijn problemen workarounds beschikbaar problemen oplossen voor vermindering van beheerskosten robuuster maken van applicatie Problemen voor zijn door kwaliteit

10 Werkwijzen Troubleshooting Bronnen van input: Gebruikers met klachten/foutbeschrijvingen-> kwaliteit, Factoren buiten de applicatie (netwerk bij betreffende partij, aangesloten applicaties) Foutmeldingen op OS, DB, AS, reverse proxy niveau. Zelfgeschreven meldingen binnen programmatuur, of ingebouwde meldingen van Oracle, Java, libraries etc.

11 Casus Inlog geweigerd Applicatie kent PROD, ACCP en TEST omgeving Melding: TEST omgeving werkt niet meer, inloggen blijkt onmogelijk Applicatie zelf toont geen ongewenst gedrag in logs

12 Specifieke Architectuur Database Java WebServices Java applicatie Toegang over internet 12

13 Login pagina wordt correct getoond, echter steeds foutmelding TEST en ACCP maken gebruik van zelfde AS voor de Java WebServices Containers: onafhankelijk draaien HTTP logs nazoeken op de AS levert op: Request1 komt bij TEST, Request2 komt bij ACCP, Request3 bij TEST Database Java WebServices Java applicatie Toegang over internet 13

14 De Oracle OC4J 10g AS: default load-balancen in round-robin modus 2 applicaties, zelfde naam, verschillende container Terecht werd dus de log-in afgewezen! Geldig op TEST, ongeldig op ACCP Uitrol van de applicatie: van groot belang om de juiste naam te kiezen 14

15 Betrokken partijen Input voor troubleshooting kan komen van: Technisch beheer: er zijn fouten opgetreden, die in bepaalde logging of monitoring naar voren komen Gebruikers organisatie: bepaalde zaken lukken niet (meer) of er bestaat een wens tot wijziging waarvoor analyse vereist is Applicatiebeheerders hebben wensen tot onderhoudbaarheid, beheersbaarheid

16 Analyse van input Expertise binnen het team Terugkoppeling met gebruikers, beheerpartijen Externe expertise op tijd inschakelen; formuleren kernproblemen Expertise op een deelgebied (specialisme) Expertise overkoepelend (integratie) Bekendheid met applicatie helpt met probleemgebieden / probleemgedrag herkennen

17 Casus Data Repair? Collega (functionele) beheerpartij belt: geen enkele gebruiker kan werken Collega (technische) beheerpartij meldt: bepaalde ochtend verwerking is niet gelukt Database logging wordt aangeleverd Klant verwacht zo spoedig mogelijk een oplossing, iedere minuut telt

18 Systeem was recent in beheer opgenomen In productie voor geruime tijd Ochtendverwerking: bedoeld om data te repareren produceerde zelf ongeldige data erger nog, door dit ene ongeldige gegeven klapte de hele verwerking en miste een complete tabel inhoud! Database en Documenten Java applicatie (HTTP) Proxy Toegang over internet 18

19 Gevonden oplossing Systeem werkend: quick fix Uiteindelijk verwerking herschreven: Robuust voor een enkel corrupt geval: wel loggen. Bij technische fout, die de hele verwerking stopt: naar beheer-mail adres Nog sneller op de hoogte 19

20 Voorbeeld stack herhaling Database en Documenten Java applicatie (HTTP) Proxy Toegang over internet 20

21 Niveau s waarop logging ontstaat Custom logging DB / AS / proxy Logging van server Logging van virtual host 21

22 Fix bepalen Zorg dat je altijd terug kan naar uitgangssituatie (voor als de Fix een ander, groter probleem introduceert) Afhankelijk van urgentie Kies de meest onderhoudbare oplossing

23 Uitrollen oplossingen Terugkijkend op technologie stack: Db: soms makkelijk, transactie Java app: testtraject, niet ad-hoc Configuratie AS: afhankelijk van wijziging Configuratie andere componenten (rechten op doc_repo, HTTP header afhandeling op reverse proxy)

24 Testen van de fix Uitrol op testomgeving, testers gaan aan de slag Testomgeving == productieomgeving Anders worden sommige problemen mogelijk niet opgemerkt Maar: licentie/support kosten systemen gevoelige data mag niet gedupliceerd worden kosten/beschikbaarheid hardware bronnen (symbolic links voor doc_repo) kosten van inrichten omgevingen (reverse-proxy)

25 V r a g e n A n t w o o r d e n CONSULTING MANAGED SERVICES EDUCATION 25