Merge pull request #46692 from bmcelvee/OSDOCS-3735

OSDOCS-3735: Clarify ROSA and OSD process security documentation

Author: bmcelvee

modules/policy-change-management.adoc

@@ -6,51 +6,32 @@
 [id="policy-change-management_{context}"]
 = Change management
 
+This section describes the policies about how cluster and configuration changes, patches, and releases are managed.
 
-Cluster changes are initiated in one of two ways:
+[id="policy-customer-initiated-changes_{context}"]
+== Customer-initiated changes
 
-* A customer initiates changes through self-service capabilities like cluster deployment, worker node scaling, and cluster deletion.
-* An SRE initiates a change through Operator-driven capabilities like configuration, upgrade, patching, or configuration changes.
+You can initiate changes using self-service capabilities such as cluster deployment, worker node scaling, or cluster deletion.
 
-Change history is captured in the *Cluster History* section in {cluster-manager} *Overview* tab and is available to customers. This includes logs from the following changes:
+Change history is captured in the *Cluster History* section in the OpenShift Cluster Manager *Overview tab*, and is available for you to view. The change history includes, but is not limited to, logs from the following changes:
 
 * Adding or removing identity providers
-* Adding or removing users to/from the dedicated-admins group
+* Adding or removing users to or from the `dedicated-admins` group
 * Scaling the cluster compute nodes
 * Scaling the cluster load balancer
 * Scaling the cluster persistent storage
 * Upgrading the cluster
 
-SRE-initiated changes that require manual intervention generally follow the below procedure:
+[id="policy-red-hat-initiated-changes_{context}"]
+== Red Hat-initiated changes
 
-* Preparing for change
-** Change characteristics are identified and a gap analysis against current state is performed.
-** Change steps are documented and validated.
-** Communication plan and schedule is shared with all stakeholders.
-** CICD and end-to-end tests are updated to automate change validation.
-** Change request capturing change details is submitted for management approval.
-* Managing change
-** Automated nightly CI/CD jobs pick up the change and run tests.
-** The change is made to integration and stage environments, and manually validated before updating the customer cluster.
-** Major change notifications are sent before and after the event.
-* Reinforcing the change
-** Feedback on the change is collected and analyzed.
-** Potential gaps are diagnosed in order to understand resistance and automate similar change requests.
-** Corrective actions are implemented.
+Red Hat site reliability engineering (SRE) manages the infrastructure, code, and configuration of {product-title} using a GitOps workflow and fully automated CI/CD pipelines. This process ensures that Red Hat can safely introduce service improvements on a continuous basis without negatively impacting customers.
 
-[NOTE]
-====
-SREs consider manual changes a failure and this is only used as a fallback process.
-====
+Every proposed change undergoes a series of automated verifications immediately upon check-in. Changes are then deployed to a staging environment where they undergo automated integration testing. Finally, changes are deployed to the production environment. Each step is fully automated.
 
-[id="config-management_{context}"]
-== Configuration management
+An authorized SRE reviewer must approve advancement to each step. The reviewer cannot be the same individual who proposed the change. All changes and approvals are fully auditable as part of the GitOps workflow.
 
-The infrastructure and configuration of the {product-title} environment is managed as code. Red Hat SRE manages changes to the {product-title} environment using a GitOps workflow and automated CI/CD pipeline.
-
-Each proposed change undergoes a series of automated verifications immediately upon check-in. Changes are then deployed to a staging environment where they undergo automated integration testing. Finally, changes are deployed to the production environment. Each step is fully automated.
-
-An authorized SRE reviewer must approve advancement to each step. The reviewer might not be the same individual who proposed the change. All changes and approvals are fully auditable as part of the GitOps workflow.
+Some changes are released to production incrementally, using feature flags to control availability of new features to specified clusters or customers.
 
 [id="patch-management_{context}"]
 == Patch management

modules/rosa-policy-change-management.adoc

@@ -7,53 +7,33 @@
 = Change management
 
 
-This section describes the policies about how cluster changes, configuration changes, patches, and releases are managed.
-
-Cluster changes are initiated in one of two ways:
-
-1. A customer initiates changes through self-service capabilities such as cluster deployment, worker node scaling, or cluster deletion.
-2. Red Hat site reliability engineering (SRE) initiates a change through Operator-driven capabilities such as configuration, upgrade, patching, or configuration changes.
-
-Change history is captured in the Cluster History section in {cluster-manager} Overview tab and is available to customers. The change history includes, but is not limited to, logs from the following changes:
-
-- Adding or removing identity providers
-- Adding or removing users to or from the `dedicated-admins` group
-- Scaling the cluster compute nodes
-- Scaling the cluster load balancer
-- Scaling the cluster persistent storage
-- Upgrading the cluster
-
-The SRE-initiated changes that require manual intervention by SRE generally follow this process:
-
-- Preparing for change
-* Change characteristics are identified and a gap analysis is performed against current state.
-* Change steps are documented and validated.
-* A communication plan and schedule are shared with all stakeholders.
-* CI/CD and end-to-end tests are updated to automate change validation.
-* A change request that captures change details is submitted for management approval.
-- Managing change
-* Automated nightly CI/CD jobs pick up the change and run tests.
-* The change is made to integration and stage environments, and manually validated before updating the customer cluster.
-* Major change notifications are sent before and after the event.
-- Reinforcing the change
-* Feedback on the change is collected and analyzed.
-* Potential gaps are diagnosed to understand resistance and automate similar change requests.
-* Corrective actions are implemented.
+This section describes the policies about how cluster and configuration changes, patches, and releases are managed.
 
-[NOTE]
-====
-SRE only uses manual changes as a fallback process because manual intervention is considered to be a failure of change management.
-====
+[id="rosa-policy-customer-initiated-changes_{context}"]
+== Customer-initiated changes
+
+You can initiate changes using self-service capabilities such as cluster deployment, worker node scaling, or cluster deletion.
 
-[id="rosa-policy-configuration-management_{context}"]
-== Configuration management
+Change history is captured in the *Cluster History* section in the OpenShift Cluster Manager *Overview tab*, and is available for you to view. The change history includes, but is not limited to, logs from the following changes:
 
-The infrastructure and configuration of the {product-title} environment is managed as code. SRE manages changes to the {product-title} environment using a GitOps workflow and automated CI/CD pipeline.
+* Adding or removing identity providers
+* Adding or removing users to or from the `dedicated-admins` group
+* Scaling the cluster compute nodes
+* Scaling the cluster load balancer
+* Scaling the cluster persistent storage
+* Upgrading the cluster
 
-Each proposed change undergoes a series of automated verifications immediately upon check-in. Changes are then deployed to a staging environment where they undergo automated integration testing. Finally, changes are deployed to the production environment. Each step is fully automated.
+[id="rosa-policy-red-hat-initiated-changes_{context}"]
+== Red Hat-initiated changes
+
+Red Hat site reliability engineering (SRE) manages the infrastructure, code, and configuration of {product-title} using a GitOps workflow and fully automated CI/CD pipelines. This process ensures that Red Hat can safely introduce service improvements on a continuous basis without negatively impacting customers.
+
+Every proposed change undergoes a series of automated verifications immediately upon check-in. Changes are then deployed to a staging environment where they undergo automated integration testing. Finally, changes are deployed to the production environment. Each step is fully automated.
 
 An authorized SRE reviewer must approve advancement to each step. The reviewer cannot be the same individual who proposed the change. All changes and approvals are fully auditable as part of the GitOps workflow.
 
+Some changes are released to production incrementally, using feature flags to control availability of new features to specified clusters or customers.
+
 [id="rosa-policy-patch-management_{context}"]
 == Patch management