From a24a3e5e369911e338e945de1b42f402c5144b4e Mon Sep 17 00:00:00 2001 From: Karl Johan Grahn Date: Tue, 21 Jan 2025 13:30:54 +0100 Subject: [PATCH] update --- .markdownlint.yaml | 16 +++++++++------- content/index.md | 40 ++++++++++++++++++++-------------------- 2 files changed, 29 insertions(+), 27 deletions(-) diff --git a/.markdownlint.yaml b/.markdownlint.yaml index f81cff1..49793d8 100644 --- a/.markdownlint.yaml +++ b/.markdownlint.yaml @@ -1,7 +1,9 @@ -{ - "MD007": { "indent": 4 }, - "MD013": false, - "MD024": false, - "MD029": { "style": one }, - "MD046": false, -} +MD007: + indent: 4 +MD013: false +MD024: false +MD029: + style: one +MD046: false +MD055: + style: leading_and_trailing diff --git a/content/index.md b/content/index.md index 2d2e22f..4654a58 100644 --- a/content/index.md +++ b/content/index.md @@ -12,28 +12,28 @@ We are here to support you, not just until the problem is solved, but to ensure You as a customer can set the initial priority for a Request by specifying the appropriate priority: `Critical`, `High`, `Medium` or `Low`. The Engineer on Duty has the right to adjust it at their own discretion based on the rules below: -Request Priority | Description of the Request Priority ---- | --- -`Critical` | Large-scale failure or complete unavailability of OpenShift or Customer's business application deployed on OpenShift. The `Critical` priority will be lowered to `High` if there is a workaround for the problem. Example: Router availability issues, synthetic monitoring availability issues. -`High` | Partial degradation of OpenShift core functionality or Customer's business application functionality with potential adverse impact on long-term performance. The `High` priority will be lowered to `Medium` if there is a workaround for the problem. Example: Node Group and Control Plane availability problems. -`Medium` | Partial, non-critical loss of functionality of OpenShift or the Customer's business application. This category also includes major bugs in OpenShift that affect some aspects of the Customer's operations and have no known solutions. The `Medium` priority will be lowered to `Low` if there is a workaround for the problem. This priority is assigned to Requests by default. If the Request does not have an priority set by the Customer, it will be assigned the default priority `Medium`. Example: Problems with the monitoring availability and Pod autoscaling. -`Low` | This category includes: Requests for information and other matters, requests regarding extending the functionality of the Kubernetes Platform, performance issues that have no effect on functionality, Kubernetes platform flaws with known solutions or moderate impact on functionality. Example: Issues with extension availability. +| Request Priority | Description of the Request Priority | +| --- | --- | +| `Critical` | Large-scale failure or complete unavailability of OpenShift or Customer's business application deployed on OpenShift. The `Critical` priority will be lowered to `High` if there is a workaround for the problem. Example: Router availability issues, synthetic monitoring availability issues. | +| `High` | Partial degradation of OpenShift core functionality or Customer's business application functionality with potential adverse impact on long-term performance. The `High` priority will be lowered to `Medium` if there is a workaround for the problem. Example: Node Group and Control Plane availability problems. | +| `Medium` | Partial, non-critical loss of functionality of OpenShift or the Customer's business application. This category also includes major bugs in OpenShift that affect some aspects of the Customer's operations and have no known solutions. The `Medium` priority will be lowered to `Low` if there is a workaround for the problem. This priority is assigned to Requests by default. If the Request does not have an priority set by the Customer, it will be assigned the default priority `Medium`. Example: Problems with the monitoring availability and Pod autoscaling. | +| `Low` | This category includes: Requests for information and other matters, requests regarding extending the functionality of the Kubernetes Platform, performance issues that have no effect on functionality, Kubernetes platform flaws with known solutions or moderate impact on functionality. Example: Issues with extension availability. | ## Support Tiers Stakater offers three levels of support tiers, as described in the table below. -Feature | Essential | Advanced | Premium ---- | --- | --- | --- -Use case | Basic minimum support | Development support | Production and critical workload support -Support hours | 24x5x365 | 24x7x365 | 24x7x365 -Modes of support | Ticket | Ticket, Video | Ticket, Video, Chat, Phone -Support response team | Regular | Specialized | Dedicated -Recommendations for improvements | No | No | Yes -Training and enablement sessions | No | No | Yes -Technical Account Manager (TAM) | No | No | Yes -Key Account Manager (KAM) | No | No | Yes -Ticket response times - Critical | 12h | 2h | 1h -Ticket response times - High | 12h | 4h | 2h -Ticket response times - Medium | 24h | 8h | 4h -Ticket response times - Low | 24h | 24h | 24h +| | Essential | Advanced | Premium | +| --- | --- | --- | --- | +| Use case | Basic minimum support | Development support | Production and critical workload support | +| Support hours | 24x5x365 | 24x7x365 | 24x7x365 | +| Modes of support | Ticket | Ticket, Video | Ticket, Video, Chat, Phone | +| Support response team | Regular | Specialized | Dedicated | +| Recommendations for improvements | No | No | Yes | +| Training and enablement sessions | No | No | Yes | +| Technical Account Manager (TAM) | No | No | Yes | +| Key Account Manager (KAM) | No | No | Yes | +| Ticket response times - Critical | 12h | 2h | 1h | +| Ticket response times - High | 12h | 4h | 2h | +| Ticket response times - Medium | 24h | 8h | 4h | +| Ticket response times - Low | 24h | 24h | 24h |