When opening a Case in HI for help with unexpected behaviour from Discovery or Service Mapping, debugging on a sub-production environment setup is almost certainly going to be required. Most customer will already have this, or how else can you test your own deployments and custom implementations, but some don't. This explains what Customer Support will require, and some of the reasons why.
Setup requirements of the sub-production instance to be used to testing/reproducing/debugging:
- Recently cloned from the Production instance, so that versions are the same, all plugins are present, and configurations and CMDB data is more-or-less up to date
- MID Servers installed, able to access all the required IP Ranges
- Credentials for access to the networked Devices
Things that are likely to need to be done, that would prevent the use of a production instance, either because the Technical Support Engineer or the Customer refuse to allow it:
- Reproducing the issue by re-running discovery is going to update your data, and potentially corrupt or delete your data.
- Investigating what happens when discovering the device for the first time would require cascade deleting the CI first, which also deletes all relationships and references from Tasks and other parts of the platform to the CI.
- Reproducing issues that have caused a performance impact may cause another performance impact.
- MID Servers or Instance App nodes may need restarting to clear stuck threads, if this occurs during testing.
- Session Debug cannot be used due to most code running in the background, meaning Instance level debugging properties such as glide.db.trace would need turning on, and that has a big impact on performance for all users.
- Adding log statements in code to help debug where things start to go wrong would require Code Changes. This may be in common script includes used by many features. There is a risk those code changes will affect functionality in parts of the product unrelated to the original issue. Customers are likely to have procedures that would prevent any code changes like this in production.
- If we think we have a possible workaround, further configuration, code and data changes may be required during the design and testing of that, and the final implementation of the workaround