Create and Test Support Process
Create Support Plan, Verify Process
Develop a plan and procedure for contacting support in the event that assistance is needed for a production application.
For each instance of AMPS, be sure that the team contacting support can provide the following information as necessary:
Version of AMPS
AMPS configuration files
Event/error logging from AMPS
Statistics database from AMPS
It may be helpful to develop a template that operations teams can use when working with 60East to ensure that the relevant information is captured quickly, without requiring additional questions from 60East support.
For example, you might use a template like:
This gives 60East support enough background to immediately identify the best available engineer to work on the issue. More information (such as server logs and statistics) may still be needed, but this will help the assigned engineer understand whether those artifacts would be helpful.
Verify Access to Diagnostic Tools
The AMPS distribution includes diagnostic tools for inspecting AMPS artifacts (for example, amps-grep
, amps-sqlite3
, amps_journal_dump
, and so on).
An operations team responsible for running AMPS will typically need access to these tools to be able to troubleshoot issues. These tools make it easier to work with artifacts that are stored in text format (such as the error and event logs), and make it possible to inspect artifacts that are stored in binary format (such as journal files and SOW files).
It may not be necessary for these tools to be available on production servers. Often, a good strategy is to be able to run the tools on non-production servers or a sandbox set aside for investigation and to be able to move artifacts to the sandbox or non-production server for analysis.
Test Support Channels Before Deployment
Before going into production, it is helpful to test that any team that will be responsible for troubleshooting AMPS operations has the ability to retrieve logs and statistics for the AMPS servers and has a process in place for providing those artifacts to 60East. If necessary, the 60East support team can assist with providing a "process test" support case for an end-to-end test of the process.
It is particularly important to verify that artifacts can be retrieved from the actual production servers that AMPS is deployed on before an issue emerges. At many sites, production servers have more restrictions than development or test servers. A process designed and verified in a test environment may need to be modified for production.
Once a process for retrieving artifacts from production is developed, document the process so that information can be efficiently transferred if an issue arises.
Verify Support Coverage / Plan
60East support responds as soon as possible to issues that emerge. During hours when coverage is provided (as specified in your license agreement), 60East provides a guaranteed SLA to respond to operational issues and work with you toward a resolution.
Outside of those hours, 60East still attempts to provide support for critical issues -- even if those issues arise outside of the covered support times that an installation has chosen. However, support outside of contracted times is provided on an "as available" basis, with no guaranteed response time or level of engineer availability.
Although 60East support typically responds to issues rapidly, teams should have a plan in place for a worst case scenario where 60East support is unable to respond until support coverage begins if an issue arises outside of the agreed upon support coverage hours. A team should have a strategy for managing issues that emerge until 60East can respond, or until coverage hours begin.
For example, if an application is intended to be available 7 days a week, but the team has chosen a support plan that provides support during weekday business hours, the operations team for the application should have a plan in place for managing issues that fall outside of coverage hours, since responses outside of contracted support hours may be slower than the typical response times.
Last updated