move to mdx

Author: KianNH

src/content/docs/support/ai.mdx

@@ -0,0 +1,10 @@
+---
+title: Support AI
+tableOfContents: false
+sidebar:
+  order: 8
+---
+
+import SupportAI from "~/components/SupportAI.tsx";
+
+<SupportAI client:load />

src/content/docs/support/cloudflare-status.mdx

@@ -1,6 +1,8 @@
 ---
 pcx_content_type: concept
 title: Cloudflare Status
+sidebar:
+  order: 5
 ---
 
 Cloudflare provides updates on the status of our services and network at https://www.cloudflarestatus.com/, which you should check if you notice unexpected behavior with Cloudflare.

src/content/docs/support/customer-incident-management-policy.mdx

@@ -2,7 +2,8 @@
 pcx_content_type: troubleshooting
 source: https://support.cloudflare.com/hc/en-us/articles/230054288-Customer-Incident-Management-Policy
 title: Customer Incident Management Policy
-
+sidebar:
+  order: 6
 ---
 
 ## Purpose
@@ -11,30 +12,30 @@ Cloudflare believes that openness and transparency are intrinsic to the delivery
 
 This Standard Operating Procedure (SOP) defines how Cloudflare deals with all incidents and problems impacting its production environment and the ways in which Cloudflare communicates the nature and impact of these incidents to Enterprise customers, both planned and unplanned, regardless of severity.  This procedure specifies how these efforts are uniformly followed in order to
 
-* maximize environment uptime,
-* minimize client impact,
-* reduce the time to repair, and
-* share information with our customers and the Internet community.
+- maximize environment uptime,
+- minimize client impact,
+- reduce the time to repair, and
+- share information with our customers and the Internet community.
 
-***
+---
 
 ## Scope
 
 This SOP applies to Cloudflare customers and customer services as consumed by customers. The SOP is applicable to all customer production environments at Cloudflare including:
 
-* Cloudflare’s public website ([www.cloudflare.com](http://www.cloudflare.com/))
-* Cloudflare’s APIs (Application Programming Interfaces)
-* Outbound third-party interfaces (e.g. credit card authorizations, etc.)
-* Network infrastructure owned or managed by Cloudflare for production services
-* Vendor software, hardware and services that affect any part of Cloudflare production
+- Cloudflare’s public website ([www.cloudflare.com](http://www.cloudflare.com/))
+- Cloudflare’s APIs (Application Programming Interfaces)
+- Outbound third-party interfaces (e.g. credit card authorizations, etc.)
+- Network infrastructure owned or managed by Cloudflare for production services
+- Vendor software, hardware and services that affect any part of Cloudflare production
 
-***
+---
 
 ## Background
 
 Cloudflare wants to build a better Internet. In order to deliver an improved experience to millions of Internet users, Cloudflare’s internal operations must follow excellent service delivery processes and procedures.  Cloudflare’s procedures therefore follow many industry-standard best practices, some of which specifically follow patterns of the Information Library Infrastructure Technology (ITIL).  This SOP follows the best practices of the ITIL Problem Management methodology.
 
-***
+---
 
 ## Definitions
 
@@ -120,7 +121,7 @@ The primary tool which Cloudflare uses to publicly share information about its s
 
 The Status Page is hosted by a Third Party ([Statuspage.io](http://statuspage.io/)) which is not dependent on Cloudflare’s services for operation.
 
-***
+---
 
 ## Roles and responsibilities
 
@@ -150,32 +151,32 @@ The overall Systems Reliability Engineering team who support the efforts of the
 
 Support the Incident Manager during problem resolution. Join bridge calls, if requested. Ensure documentation is captured while diagnosing and correcting issues and proper escalation to other responsible groups is executed. Participate in Post Mortem reviews of some Incident Reports, as requested by Cloudflare Management.
 
-***
+---
 
 ## Standard Operating Procedure
 
 This section details the procedures for incident and problem management.  At a high-level, these processes relate as follows:
 
-* Incident Management:  The overall process for observing and responding to alerts, including: assessing the potential impact and severity of an Incident, classifying the Incident as a Problem, assigning a priority to the Problem, or dismissing the Incident as a non-impacting event if a problem condition cannot be identified.
+- Incident Management:  The overall process for observing and responding to alerts, including: assessing the potential impact and severity of an Incident, classifying the Incident as a Problem, assigning a priority to the Problem, or dismissing the Incident as a non-impacting event if a problem condition cannot be identified.
 
-* Problem Management:  The process of identifying the scope and extent of a Problem, assigning an appropriate severity level (P0, P1, P2, P3),  the actions to resolve the Problem and restore the optimal state for production services, and the communication of the Problem to appropriate parties.
+- Problem Management:  The process of identifying the scope and extent of a Problem, assigning an appropriate severity level (P0, P1, P2, P3),  the actions to resolve the Problem and restore the optimal state for production services, and the communication of the Problem to appropriate parties.
 
-* Resolution Management:  The process of investigating the causes and conditions which lead to a problem condition, reporting on the overall manner by which a problem was managed and resolved, and any subsequent analysis of how the conditions and causes of a problem may be prevented in the future. 
+- Resolution Management:  The process of investigating the causes and conditions which lead to a problem condition, reporting on the overall manner by which a problem was managed and resolved, and any subsequent analysis of how the conditions and causes of a problem may be prevented in the future. 
 
-***
+---
 
 The primary goal of Incident Management is to identify and react to potential problems as quickly as possible, and thereby minimize impact to production services and provide the best possible levels of service quality and availability.  The best possible levels of service quality and availability would be that all services operated exactly as designed 100% of the time, and were available and accessible 100% of the time.
 
 Because we accept that a combination of forces within our control, and forces beyond our control, will eventually impact service health, we define Service Level Objectives (SLOs), and Service Level Agreements (SLAs), to describe what degradations in service health are acceptable for various services within Cloudflare’s network.   SLAs and SLOs are expressed as percentages of periods of time (monthly and annually.)
 
 The level of information given about an incident may vary, but the following information must be collected before an incident is classified and prioritized:
 
-* Submitter Source (monitoring alert or alternate source)
-* Customer(s) (if applicable)
-* System or application (and hostname, if applicable)
-* Time of alert
-* Scope of impact:  estimated number of systems, users, or regions impacted
-* Type of impact:  general scope of service impairment (e.g., loss of all access, degraded performance, dependent applications impacted, observed customer impact)
+- Submitter Source (monitoring alert or alternate source)
+- Customer(s) (if applicable)
+- System or application (and hostname, if applicable)
+- Time of alert
+- Scope of impact:  estimated number of systems, users, or regions impacted
+- Type of impact:  general scope of service impairment (e.g., loss of all access, degraded performance, dependent applications impacted, observed customer impact)
 
 All Incidents which are classified as Problems, regardless of source, which have a priority of P0 or P1, will be logged within the Cloudflare ticketing system, JIRA.  Some alerts will indicate conditions which may not be immediately impacting to service levels, and as necessary, will be categorized as Problems with a P2 or P3 priority.   
 
@@ -191,31 +192,31 @@ All tickets will be categorized according to the following 4 levels of priority.
 
 **P0**
 
-* Complete loss of access to the Cloudflare application or API.
-* Degraded access to the Cloudflare application or API (⪯ 98% as measured worldwide or from any major region).
-* Complete loss of access to, or major performance degradation to, a Tier-1 Data Center.
-* Degraded performance of any Tier-1 global transit provider (⪰ 20% packet loss worldwide or 30% packet loss from any major region).
-* Degraded access to or performance of any critical system.
+- Complete loss of access to the Cloudflare application or API.
+- Degraded access to the Cloudflare application or API (⪯ 98% as measured worldwide or from any major region).
+- Complete loss of access to, or major performance degradation to, a Tier-1 Data Center.
+- Degraded performance of any Tier-1 global transit provider (⪰ 20% packet loss worldwide or 30% packet loss from any major region).
+- Degraded access to or performance of any critical system.
 
 **P1**
 
-* Intermittent or degraded Site-wide performance degradation.
-* Loss of an important function such as reporting.
-* Loss of access to the Cloudflare application from one of the social media or external CloudFlare websites
-* Outage to important outbound third-party interface.
-* Inoperability of the site for one of the enterprise clients or distribution partners.
-* Corruption or loss of customer data.
+- Intermittent or degraded Site-wide performance degradation.
+- Loss of an important function such as reporting.
+- Loss of access to the Cloudflare application from one of the social media or external CloudFlare websites
+- Outage to important outbound third-party interface.
+- Inoperability of the site for one of the enterprise clients or distribution partners.
+- Corruption or loss of customer data.
 
 **P2**
 
-* Sporadic or localized performance issue.
-* System issues with no noticeable client impact yet (e.g. high CPU).
-* Single client outage/degradation.
+- Sporadic or localized performance issue.
+- System issues with no noticeable client impact yet (e.g. high CPU).
+- Single client outage/degradation.
 
 **P3**
 
-* Operational issues, procedural problems or service requests that have little or no effect on end-users and can be handled on an as-available basis.
-* The default severity assigned to all tickets that have not yet been reviewed or assigned a severity level.
+- Operational issues, procedural problems or service requests that have little or no effect on end-users and can be handled on an as-available basis.
+- The default severity assigned to all tickets that have not yet been reviewed or assigned a severity level.
 
 ### Category
 
@@ -235,36 +236,36 @@ P0 and P1 incidents obviously have more impact to the business and therefore, ha
 
 For all P0 and P1 issues, the on-duty Incident Manager should be contacted immediately.  A schedule of incident managers will be posted to ensure that SRE knows who to contact at any given time.  The incident manager is a critical resource responsible for the following:
 
-* Validation of the severity of an issue
-* Tracking of the issue from submission to resolution
-* Representation of clients’ best interest
-* Logging of all actions and times
-* Direction of personnel toward the fastest possible resolution
-* Ensuring that clients and internal management are notified of status according to pre-determined time periods (or upon change in status)
-* Performing client, internal or third-party escalations when time limits are being exceeded or appropriate progress is not being made
-* Ensuring that a meaningful explanation is applied to the ticket upon resolution
-* Making certain that the initial submitter agrees that the issue is resolved before the ticket is closed 
+- Validation of the severity of an issue
+- Tracking of the issue from submission to resolution
+- Representation of clients’ best interest
+- Logging of all actions and times
+- Direction of personnel toward the fastest possible resolution
+- Ensuring that clients and internal management are notified of status according to pre-determined time periods (or upon change in status)
+- Performing client, internal or third-party escalations when time limits are being exceeded or appropriate progress is not being made
+- Ensuring that a meaningful explanation is applied to the ticket upon resolution
+- Making certain that the initial submitter agrees that the issue is resolved before the ticket is closed 
 
-***
+---
 
 ## Incident Communications
 
 External communications during an incident are critical for:
 
-* Notifying the stakeholders that Cloudflare is aware of the issue and is pursuing resolution
-* Reassuring clients that the matter is under review and that Cloudflare is looking out for their best interests
-* Issues do not drag on unnecessarily and appropriate escalations are being made
-* Informing key internal stakeholders of important incidents
+- Notifying the stakeholders that Cloudflare is aware of the issue and is pursuing resolution
+- Reassuring clients that the matter is under review and that Cloudflare is looking out for their best interests
+- Issues do not drag on unnecessarily and appropriate escalations are being made
+- Informing key internal stakeholders of important incidents
 
 Major types of communications during an incident include:
 
-* [StatusPage](https://www.cloudflarestatus.com/)
-* [Support tickets](/support/contacting-cloudflare-support/)
-* Incident Reports 
+- [StatusPage](https://www.cloudflarestatus.com/)
+- [Support tickets](/support/contacting-cloudflare-support/)
+- Incident Reports 
 
 Status Page will be created using templates by CSUP team member on-call as soon as an incident is identified.
 
-***
+---
 
 ## Post-Mortem reviews
 
@@ -288,7 +289,7 @@ The Incident Report (“IR”) is the primary method of communication to the cli
 
 The person writing the report will vary depending on the severity of the issue and the responsible area.  Upon completion of the draft report, it is critical to ensure that the report is reviewed by Cloudflare management for content, commitments and professional presentation.  Once the report is approved it may be published to the client.
 
-***
+---
 
 ## Problem review
 
@@ -298,10 +299,10 @@ The above sections have detailed the handling of the incident and the root cause
 
 The ticket criteria that need to be reported for both open and closed tickets include the following:
 
-* Severity
-* Category/Sub-category
-* Responsible Group
-* Age/Days Open
+- Severity
+- Category/Sub-category
+- Responsible Group
+- Age/Days Open
 
 Wherever possible, this data should be reported graphically to show visible trends.  These reports should be published to internal Cloudflare managers and area owners.
 
@@ -313,6 +314,6 @@ Each area owner for tickets will be responsible for not only ensuring that their
 
 As part of all departmental staff meetings, group managers should be reviewing the ticket open and trending reports with the following objectives:
 
-* Discussion of areas of success or concern
-* Review of opportunities for improvement by the area owners
-* Agreement on areas that warrant a new Problem ticket to be opened for remediation tracking
+- Discussion of areas of success or concern
+- Review of opportunities for improvement by the area owners
+- Agreement on areas that warrant a new Problem ticket to be opened for remediation tracking

src/content/docs/support/disruptive-maintenance.mdx

@@ -2,6 +2,8 @@
 pcx_content_type: troubleshooting
 source: https://support.cloudflare.com/hc/en-us/articles/360060050511-Disruptive-Maintenance-Windows
 title: Disruptive Maintenance
+sidebar:
+  order: 7
 ---
 
 import { AvailableNotifications, Render } from "~/components";