Bugs and Where to Find Them (Study Case_ Backend).pdf
0 likes15 views
This document discusses log and bug tracing management in the SenseHealth architecture. It provides two cases of conventional bug tracing with a single server and administrator, and modern tracing using AWS Cloudwatch. The SenseHealth architecture is described using ELK stack, Sentry, and Github for centralized logging and automatic bug reporting. Three cases are presented: 1) bugs found in ELK and Sentry, 2) bugs not found, requiring manual tracing, and 3) bugs possibly at the client-side. The conclusions recommend accessible logs for developers, following IT principles, and being proactive to identify bugs earlier.
Bugs and Where to Find Them (Study Case_ Backend).pdf
- 1. Bugs and Where to Find Them (Study Case: Backend) Ridwan @SenseHealth B.V. 28th August 2019
- 2. Principles ● ISO 27001, ● ITIL v4, Service Management Practice No.5 (Incident Management) and No. 7 (Monitoring and Event Management) ● NEN 7510-2:2017, Section No. 12 Business Management Security: Capacity Management, Separation of Development Environment, Reporting and Monitoring, etc.
- 3. Incident ● High CPU Usage ● High RAM Usage ● Run out of disk space ● Network problem from third-party ● Misconfiguration ● etc
- 4. Bugs ● Mismatch logic against requirements ● Incompatible packages ● Bugs from third-party libraries ● Unseen bugs ● etc
- 6. Case - 1 1. QA help identifying the bugs 2. Single Baremetal Server 3. One person as System Administrator 4. Checking the apache log by himself alone 5. Other developers couldnʼt check the log directly 6. Finally check the bugs directly on the webpages by using “echo” and “print_r”
- 7. Case - 2 1. No QA 2. Users / Clients report the bugs directly to the developers 3. Multiple of VPS Instances 4. More than one System Administrator 5. Others developer may access the log for debugging purposes with an agreement and rules 6. Developer access the log directly to the servers
- 9. Case - 1 1. QA identifying the bugs 2. Bugs exceed logs from AWS ElasticBeanstalk 3. Developers could trace the bugs through AWS Cloudwatch 4. System Administrator set the rules for which developer who are able to open AWS Cloudwatch 5. Report back to QA 6. Create an issue at Github
- 10. Case - 2 1. QA Identify the bugs 2. System Administrator trace the logs through centralized log management 3. Bugs catched by apps send the error / exception to the bug management system (Sentry) 4. Sentry Integration with Github 5. Even if the QA didnʼt report bugs, the bugs are still being catched automatically 6. Send a report automatically to communication channel 7. Confirmed bugs will be created as a Github Issue
- 11. SenseHealth Architecture Log and Bug Tracing Management
- 13. Case 1 1. QA report a potential bugs along with the timerange of the event 2. QA provide information regarding the affected environment 3. Ops will trace the bugs through ELK stack 4. Found some suspected errors from http request within timerange 5. Check the event with Sentry event 6. Found bugs and report the bugs to the platform lead 7. Report back to QA 8. Platform lead will create Github issue for that
- 14. Case 2 1. QA report a potential bugs along with the timerange of the event 2. QA provide information regarding the affected environment 3. Ops will trace the bugs through ELK stack 4. Didnʼt find some suspected errors from http request within timerange 5. Check the event with Sentry event 6. Didnʼt find bugs and report the bugs to the platform lead 7. Pair programming and manual tracing 8. Report back to QA 9. Platform lead will create Github issue for that
- 15. Case 3 1. Similar story to case 2 2. But after pair programming the expected result and flow are still match with the requirements 3. Possibly bugs are produced at the client side 4. Report back to QA
- 16. Conclusions 1. Build an accessible application logs for widerange developers a. Report the bugs before the other stakeholder noticed it b. Donʼt let unauthorized person touch the servers 2. Follow some principles from IT management standards a. Periodically meeting is required b. Pair programming is needed to evaluate pull request review c. Cooperate with QA to gain bugs information 3. Being proactive even there are no any potential bugs
- 17. Question?