Availability and Uptime Management is one of five components in the ITIL Service Delivery area. It is responsible for ensuring application systems are up and available for use according to the service criticality and the defined Service Level Agreements (SLAs).

Your uptime management team should analyze your online business availability requirements and ensure that optimized, cost-effective contingency plans are put in place and tested on a regular basis to ensure an online robust service that meets the business needs. For example, Internet ecommerce systems may have almost zero recovery RTO (Recovery Time Objective) in comparison to less critical, non-customer-facing applications where even a few days of recovery can be provisioned on a less expensive cloud infrastructure with limited redundancy capabilities.

[Newvem analytics tracks you AWS cloud utilization:

• Hourly Utilization Pattern Analysis 
• Reserved Instances Decision Tool 
• Resource Resizing Opportunities

Get Started For Free or Learn More]

Following years of experience supporting all type of online service criticalities, I have compiled the following five crucial guidelines that can assist you in presenting a suitable uptime management plan for your cloud service:

1 - Build with Disaster Recovery (DR) in mind

You must define and consider your system criticality and come up with a Disaster Recovery (DR) and High Availability (HA) plan from the start. Recognize your POFs (point of failures) and plan the right cloud infrastructure architecture to support the business SLA, bearing in mind fast (seamless) recovery and backup of your service.

2 - Workload forecasting and right-sizing of the underlying infrastructure

According to the past or the expected workloads (measured in requests per second, RPS) you should have the front end and the back end servers in place. The sizing of the cloud infrastructure is based on defined KPIs that are measured all the time. Make sure to integrate a tool to forecast your cloud workloads using metrics (such as the number of users for a set period of time) or the internal traffic load (such as the DB server throughput). For example, MonogDB can handle thousands of queries per second whereas rational databases like MSSQL and MySQL can handle only hundreds.

Relevant Article: The 10 Most Common Amazon’s AWS Usage Mistakes: Mistake #1: Picking Over-Sized Instances

3 - Uptime Management Protocol

According to the KPIs defined (2), you need to create an uptime management protocol so that you have a relevant call to actions for any type of anomaly, enabling support for real-time crises. This protocol is dynamic and it must be enhanced by lesson learned from real events. The protocol is not only for when your user calls you when the system is down; it should have a proactive aspect to avoid expected issues and changes in the severity of new events that might occur.

4 - Support in Tiers

The common best practice is the three-tier model.

Tier 1 – Your Network Operations Center (NOC) team. This team takes the calls and is able to remediate and respond to 60-80% of all support requests. The NOC team should handle events according to your uptime management protocol. Any exceptions should be escalated to tier 2. The NOC team are responsible for recording all events and actions taken while enhancing your uptime protocol.

Tier 2 - Expert Support - System engineers that have the tools and permissions to dig in, check the logs, and take actions to solve configuration “heavy issues”.  These engineers’ reports back to their “internal client”, the NOC team.

Tier 3 – R&D or “Code Level Support” team. This tier handles escalations from tier 2 and maintain events and issues that happened due code bugs or even product definitions.

The three-tier support model can be extended by breaking each of the tiers down into sub-tiers to support multiple online operations and systems. Such support organization structures can be found in large enterprises such as the telecom companies.

5 - Tracking and Reports in two levels

Level 1 - Operations’ KPIs Reports: The KPIs mentioned above are crucial to enabling improvement and scaling. The NOC’s system engineer should track and report KPIs on a daily basis in order to be able to forecast and avoid future issues due to demand, and resultant utilization changes.

Level 2 - Business Summary Reports: The business support reports are summary broad reports that can be generated on a weekly and monthly basis. These reports include a high level view of the production status and actual usage of the system. For example, a report that shows the business growth trend based on the amount of new user’s, provides insights on new workloads that need to be handled and planned. Annual reports of these kind will show the yearly usage of the system, comparing month to month, and will present the system operational margins.

Don’t forget your online service support. Start by recognizing and clearly defining your business goals and system criticality. I hope that these help you achieve healthy online operations and scale while eliminating risks.

About the Author

Roy Brihand, CTO & Co-founder of MoovingON LTD. Over 15 years of experience in high-tech as a developer, implementation, integration and support for large Telecom Billing, Mobile services & ISP Network systems. He has vast experience in planning architecture for large production systems with application and infrastructure as SaaS solutions, starting from the commercial needs and deep down to the technical architecture implantation and integration to third parties. Roy initiated and leads Support and Implantation technical teams to successful production services that provided 24/7 UPTIME management NOC, Tier 1 & 2 support, and end-to-end operational packages for startups.

Contact him

Keywords: Amazon web services, Amazon AWS instances, Amazon cloud computing, Cloud Monitoring, AWS CloudWatch, CloudWatch Alarm, CloudWatch Alert, Cloud Watch, AWS Performance, cloud SaaS, cloud PaaS, Cloud Monitoring, NOC, Cloud Elasticity, CPU Log, Cloud Capacity

Pic credits: http://msphelpdesk.com/buzz/does-the-market-know-you-have-a-247-help-desk/