Opster AutoOps Service Level Agreement

Appendix A

SERVICE LEVEL AGREEMENT  

This Service Level Agreement (“SLA”) set forth the terms and conditions under which Opster Ltd.(“Opster”) will provide technical support and maintenance service to (“Customer”, and together with Opster, a “Party” and the “Parties“) with respect to Opster’s propriety software (the “Solution“),and the scope of Production Support Services and Professional Services to which Customer is entitled subject to purchase of the same under the applicable Order Form, all subject to the Subscription Agreement (“Subscription Agreement“) and related Order Form entered into between the Parties. The terms here apply to a subscription to Opster with 24/7 support. Software only deals Do not include Production Support Services and Professional Services

Capitalized terms not defined herein have the meanings given to them in the Subscription Agreement.

The Services are provided to Customer during the Subscription Period and subject to Customer’s payment of the applicable fees as prescribed in the Order Form.

1. Support Level

Customer shall receive the Standard Support level provided by Opster as further detailed below. 

2. Updates.

Opster may from time to time, during the Subscription Period, develop bug fixes, patches and enhancements to the Solution (“Updates“). Opster will make such Updates available to Customer to the extent generally made available by Opster to its supported customers under valid support contracts at no additional cost. 

3. Availability

Opster will use its best to ensure that the Services Availability meets or exceeds 99%

“Services Availability” is calculated as follows:  for a single month, the aggregate amount of actual uptime expressed as a percentage of the Scheduled Uptime (i.e., Availability = (Actual Uptime / Scheduled Uptime) * 100). Any time in addition will allow the Customer to claim service credits at the rate of 3X.

“Scheduled Downtime” means (i) regularly scheduled maintenance on weekend hours and outside local working business hours which does not exceed 3 hours per month; and (ii) other times during which Opster will perform routine systems maintenance, provided Opster will provide the Customer with at least 3 business days prior written notice.

4. Technical Support

During Business Hours (as specified below), Opster’s helpdesk personnel shall receive Customer email support requests in connection with Errors of the Solution (each, a “Support Request“). An “Error” means any verifiable and reproducible failure of the Solution to materially perform the functions described in the Specifications. Once Opster has determined that the Support Request is covered by a valid support agreement, Opster will respond to such Support Requests based on the severity levels (as determined by Opster) set out in the table below. Opster will use commercially reasonable efforts to get to resolve Errors or to provide a workaround for the Error. 

5. Customer’s Information

In order for Opster to meet the above Support Request response times, Customer must provide Opster with all information, documentation, assistance and access as Opster might reasonably require, including, without limitation: 

• detailed steps required to enable Opster to replicate the problem, 
• exact wording of Error messages, and 
• any other data that Opster may reasonably request in order to reproduce operating conditions similar to those present when the Error occurred.

Allowing Opster’s experts to have remote access to the Customer network will significantly improve the ability to troubleshoot the error in a timely manner

6. Opster’s Designated Communication Channels:

Support requests need be submitted via these channels: 

• Email: service@opster.com 
• Dedicated Slack channel
• Intercom Messenger installed in Opster Software

7. Exclusions

The technical support described above will only be provided with respect to the then-current release of the Solution and one previous release, and shall exclude Errors resulting from:

• any modifications of the Solution that have not been approved by Opster in writing;
• Customer’s failure to implement in a timely manner any Update made available by Opster;
• Customer’s instructions, or installation or setup adjustments; 
• use of the Solution other than as permitted in the Subscription Agreement;
• any fault in any Customer systems or third party System (as defined in the Subscription Agreement), or other non-Opster equipment or programs used in conjunction with the Solution, or other causes beyond the control of Opster; and/or
• Customer’s negligence or willful misconduct.

8. Production Support Services. Where Customer is entitled to receive Production Support Services, Opster shall provide the following support:

• A production support event is a major production error within Elasticsearch service that impacts the Customer’s use of Elasticsearch service for production purposes, such as the loss of production data, or is  causing significant impact to portions of Customer’s business operations and productivity or where production systems are not functioning and no work-around exists. Opster will use continuous efforts during Production Support Hours stated below to provide a resolution for any such errors as soon as is commercially reasonable. 
• Target response time will be 1 hour from Support Request Submission via Opster’s designated communication channels.    

9. Professional Services. Where Customer is entitled to receive Professional Services, the following shall apply: 

a) Professional Services may include the following assistance and support: 

• Capacity planning
  • Covered in this section:
    • Data volume, storage capacity
    • Memory requirements
    • Number of data nodes
    • Number of Indices and shards
  • In this section, we will cover the current and future scale considerations needed in order to scale the cluster in an optimal and cost-effective manner. Capacity planning covers both the hardware capacity and the data considerations.
  • In terms of hardware capacity, our experts dive into your specific use case, data size and rate, retention requirements, search, and indexing SLA. From that, we derive how much data needs to be stored, what the optimal disks sizes are for data nodes, and how much memory is needed. These predictions also assist in determining the correct number of data nodes needed.
  • As for the data considerations aspect, we review the data requirements, how much data is added daily and what the retention policy is. Processing all your specific information allows us to plan the amount of indices that the cluster would hold, how they would get sharded to shards, and how this planned capacity would be stored in a well balanced manner.

• Best practices
  • Covered in this section:
    • Cluster structure
    • Hardware recommendations
    • JVM Setup and memory
    • ES configuration and settings
  • In this section, we review the current cluster architecture and settings, and provide the best practices gathered over the years by our world-wide ES experts. Following these best practices would help you prevent pitfalls that are commonly known and advised against. 
  • The best practices section covers correct cluster architecture, optimized settings for performance, ways to avoid data loss, and how to achieve best resiliency, availability and data recovery.

• High Availability and Data Recovery
  • Covered in this section:
    • Indices replicas considerations
    • Availability Zones and allocation awareness
    • Snapshots and restore procedures
    • Multi-Clusters deployments
    • Recovery settings tuning optimizations
  • Elasticsearch is a robust distributed system that is usually available and responds quickly. Nevertheless, it is always good practice to plan ahead for a rainy day – it could be a network issue, a node shutdown, an out of memory error, or any other of the many scenarios where some of the nodes, or even an entire cluster, stop being available.
  •  Opster’s team walks you through the right steps and measures to take in order to make sure you are covered and to ensure your data will always be available and recoverable in case of a catastrophe. 

• Elaticsearch upgrades 
  • Covered in this section:
    • Upgrade procedures
    • Backward compatibility and migrations
    • New features and important major changes
    • Major upgrade – once a year
  • As Elasticsearch evolves rapidly, it is important to keep up with the pace, and apply the fixes, new features and optimizations. Upgrading ES is usually not a simple task – there are some backwards compatibility issues, and even minor version upgrades might contain major breaking changes, such as query structure changes, and data modifications are needed.
  • In order to be ready for the next upgrade, and facilitate the upgrade smoothly, Opster’s team fills in the gaps and helps set up the right process.

• Security review
  • Covered in this section:
    • Role-based access and alternatives
    • Node to node encryption
    • Encrypted client communication
    • Scripts restrictions
  • As Elasticsearch is a complex distributed system, there are multiple potential weaknesses and vulnerabilities that are often exploited. Opster’s team walks you through all of the available ways to protect your Elasticsearch cluster from security breaches, which might lead to data loss, hijack, ransomware and downtime. The security review covers all aspects, ranging from secure communication, data encryption, access restrictions, query protection and more.

• Elasticsearch Operations
  • Covered in this section:
    • Monitoring stack for ES
    • Indices life-cycle management
    • Kube/ec2/on-prem settings 
    • Scale-up/down procedures 
    • Incidents analysis, post mortems, action items 
    • Implementation assistance of recommendations
  • Operating Elasticsearch at a small scale can be pretty straightforward. Things become more complicated at a large scale. Opster’s team assists in setting up the right infrastructure to ensure clear visibility – from detecting loaded nodes, discovering root causes for slow searches or disconnected nodes and more. After visibility is clear, we jump into the operations: choosing the right tools and methods for automating  day-to-day tasks, scaling correctly, deploying ES on kubernetes in an optimized manner and much more.

• Data review and optimization
  • Covered in this section:
    • Shards – primary and replica recommendations
    • Data modeling
    • Effective use of templates
    • Schema and Optimized mappings
    • Searches optimizations
    • Slow search analysis
    • Benchmarks review
  • In this section we review the way data is stored in Elasticsearch and review the methods to make search and indexing faster, while keeping disk usage as low as possible. This includes reviewing the correct schema of the documents, how the documents are structured, what the best way to group data into indices is and how to make sure search results are as expected.
  • Considering the specific use case and requirements, we assist you in choosing the optimal number of primary shards, determining how many replicas are needed, and what the best practices settings are needed in order to achieve that. We follow up with benchmark tests in order to make sure requirements are met and performance improves.

b) Customer shall be entitled to exercise its monthly Professional Services available hours (the “Professional Services Monthly Quota”) in no less than 15 minutes increments, by contacting Opster through Opster’s designated communication channels (“Customer’s Request”)

c) Opster shall respond to Customer’s Request within 24 (twenty four) hours of Opsters receipt of such request.  

10. Customer Responsibilities

Opster’s obligations under this SLA are subject to the following: 

• Customer agrees to receive from Opster communications via e-mail, telephone, and other formats;
• Customer’s technical support contact shall cooperate with Opster at all time during the provision of technical support and maintenance services under this Support Agreement; and
• Customer shall report to Opster all problems with the Solution and shall implement any corrective procedures provided by Opster reasonably promptly after receipt.

11. SLA for Support Services

The table below presents the relevant response time per each error severity category with respect to Opster’s proprietary software