fix(OMA): Remove redirects from forecasts and add anchors

src/content/docs/new-relic-solutions/observability-maturity/operational-efficiency/dg-coe.mdx

@@ -30,16 +30,17 @@ import adhocanomalyicon from './images/oma-oe-dg-adhoc-anomaly-icon.png'
 
 Designate a few explicit roles and practices in order to ensure a level of context and accountability in your ingest planning.  At a minimum designate a *Governance Team* and schedule check-ins throughout the year to plan and adapt as needed.
 
-## Stakeholders and participants
+## Stakeholders and participants [#stakeholders]
 
 Regardless of how your organization's teams are structured it is necessary to identify some individuals who will participate in the data governance process.  Selection of the team can be ad hoc but it should include representation from a broad enough cross section of teams so that when priorities and decisions must be made you will have the right stakeholders.  The team should have one individual who can be considered the overall observability manager.  This may be the person who manages the New Relic account or an overriding team leader responsible for the systems and infrastructure monitored by New Relic.
 
-### Observability manager
+### Observability manager [#manager]
+
 <img src={observabilitymanager} alt="Observability Manger" style={{ height: '66px', width: '75px', verticalAlign: 'middle'}} />
 
 This is the go-to person to help resolve conflicts and to communicate with senior management as needed.  When the organization contains gray areas of ownership leading to questions like *"Who owns this kubernetes cluster?"* this individual is instrumental.
 
-### The governance team
+### The governance team [#governance-team]
 
 <img src={rolespracticesicon} alt="Governance Team" style={{ height: '96px', width: '120px', verticalAlign: 'middle'}} />
 
@@ -62,11 +63,11 @@ Incorporating data governance adds the following responsibilities:
 - Participate in scheduled check-ins where baseline data is analyzed and compared to ingest targets.
 - Make modifications to ingest targets as needed.
 
-## Timelines and check ins
+## Timelines and check ins [#timelines]
 
 Schedule data ingest governance meetings through the year to keep everyone up to date on data ingest volumes. Doing so makes data ingest governance predictable and easy to manage. 
 
-### Yearly ingest target planning
+### Yearly ingest target planning [#ingest-target]
 <img src={yearlyingesttarget} alt="Yearly Ingest Target Planning" style={{ height: '66px', width: '75px', verticalAlign: 'middle'}} />
 Meet to maintain an organization wide telemetry ingest target.  This can be broken out into as many facets as is useful for your organization.  For example you may adopt the following ingest targets...
 
@@ -76,12 +77,12 @@ Meet to maintain an organization wide telemetry ingest target.  This can be brok
 * Team C (Monthly): 100TB
 
 This rough set of targets leaves 100TB as a buffer for uncertainty. You may also choose some specific limits based on certain highly variable telemetry. For example you may set organization or team based limits on Log or Metrics ingest.
-### Monthly ingest check-ins
+### Monthly ingest check-ins [#check-ins]
 <img src={monthlyingestcheckin} alt="Monthly Ingest Checkin" style={{ height: '66px', width: '75px', verticalAlign: 'middle'}} />
 
 During these sessions you'll track ingest against your plan and produce action items needed to stay on target.
 
-### Ad hoc anomaly resolution
+### Ad hoc anomaly resolution [#ad-hoc]
 <img src={adhocanomalyicon} alt="Ad Hoc Anomaly Resolution" style={{ height: '66px', width: '75px', verticalAlign: 'middle'}} />
 Occasionally a system refactor or organizational change could lead to an unexpected increase in data ingest.  In this scenario it may be necessary to call a meeting to address the specific topic.  Some scenarios to watch for:
 

src/content/docs/new-relic-solutions/observability-maturity/operational-efficiency/dg-forecasting.mdx

@@ -11,12 +11,7 @@ tags:
   - Value drivers
   - Bill and Usage Data
   - Data ingest cost
-metaDescription: Data governance is a practice of ensuring optimal value for telemetry data collected by an organization particularly a complex organization with numerous business units and working groups.
-redirects:
-  - /docs/telemetry-data-platform/manage-data/data-governance
-  - /docs/data-governance
-  - /docs/telemetry-data-platform/get-started/manage-data/data-governance
-  - /telemetry-data-platform/get-started/manage-data/data-governance
+metaDescription: Data governance is a practice of ensuring optimal value for telemetry data collected by an organization, particularly for complex organizations with numerous business units and working groups.
 ---
 
 import forecasticon from './images/oma-oe-dg-forecasting-icon.png'
@@ -30,6 +25,6 @@ In this stage you will:
 
 ## Desired outcome [#desired-outcome]
 Use the analysis produced in the baselining stage along with the observability value goals from the optimizing stage to produce future looking estimates for ingest for the coming months, and even years.
-## Process
+## Process [#process]
 
 <font><h4><i>Coming soon!</i></h4></font>

src/content/docs/new-relic-solutions/observability-maturity/operational-efficiency/dg-growth.mdx

@@ -22,41 +22,41 @@ redirects:
 
 In order to begin forecasting our future data ingest we must develop an understand of the kinds of growth drivers that will potentially impact some or all of of our data sources.  The following sections describe what we call general growth drivers.  Finally we introduce the concept of a growth driver worksheet that can be used in your ingest [Budgeting](/docs/new-relic-solutions/observability-maturity/operational-efficiency/dg-budgeting) process.
 
-## Understanding Growth Drivers
+## Understanding Growth Drivers [#drivers]
 
-### Seasonal and Business Cycle Growth
+### Seasonal and Business Cycle Growth [#cycle]
 
 It's critical to understand the sources of telemetry growth that will occur through the year and over the years.  Some of these are generally anticipate and others may be unexpected and others completely anomalous.  These concepts are important when coming up with baseline budgets and growth targets and can also help during an ad hoc resolution of unexpected telemetry growth.
 This class of user growth is often welcome but can also seem overwhelming if we have not data governance plan in place.  Our business is growing and we are bringing in new users and the activity of each of those users is causing additional Browser, APM, and Log data to be emitted.  The need to scale K8s clusters, load balancers, and supporting platforms like Kafka also cause an increase in the emitted telemetry.  Another type of growth is caused by an increase in business transactions without an obvious increase in the number of users.  For example a website that sells one type of product (Shoes) has now broadened its inventory to offer Hats and Gloves.  This results in more business transactions per user causing a similar cascade in telemetry as an increase in users.
 
-### Code Refactor
+### Code Refactor [#code-refactor]
 There are some scenarios where a change in application code will cause a sudden increase in telemetry volume without any additional users or business transactions.  Some examples:
 
 - A developer adds additional java javascript code that interacts with the backend every time a user visits a page.
 - A developer adds new logging code to some application methods that are called very frequently.
 - A new database schema requires  multiple database calls where previously one was needed.
 - A monolithic application is broken into 5 microservices with the resulting APM and distriubuted trace data being emitted for each.
 
-### Instrumentation Misconfiguration
+### Instrumentation Misconfiguration [#misconfiguration]
 Field Example: An organization previously used a 30s sampling rate for core operating system metrics for about 2000 hosts.  A misconfiguration or unauthorized change to 10s tripled the OS metrics telemetry captured from those hosts.
 
 Later on we will discuss telemetry standards. One of the thing often governed by a telemetry standard is the sampling rate for various monitoring activities.
 
-### Increasing Breadth of Observability
+### Increasing Breadth of Observability [#breadth]
 Field Example: It is part of the continuous improvement process to expand observability.  An organization that was monitoring Kafka broker health for nearly two years decided to start monitoring Kafa topic offsets.  Not realizing the verbosity of topic monitoring data they are surprised when the telemetry footprint from Kafka monitoring increase 5 times.  
 
 <Callout variant="caution">
 Mergers and acquisitions are a common way in which telemetry growth "sneaks up" on an organization.  We suggest you incorporate observability consolidation as a formal action item as part of the integration process.  This is no different then adding *cloud compute consolidation* to your overall integration plans.  This is also an area where you should fall back on your New Relic account team since there are times when these events are somewhat unexpected.
 </Callout>
 
-### Unexpected Third Party Change
+### Unexpected Third Party Change [#third-party]
 Field Example: A JMX integration is designed to get any metric exposed by a third party application with prefix "Transaction_".  With version 1.0 of the application that yields in 10 events per sample.  The team maintaining the third party application adds 10 additional metrics with the "Transaction_" prefix.  When our team installs the new code, we are a bit surprised to know what JMX events have increased 2 times.
 
-### Growth in User Counts or in Overall User Activity
+### Growth in User Counts or in Overall User Activity [#user-counts]
 
 [TBD]
 
-## Growth Driver Worksheet
+## Growth Driver Worksheet [#driver-worksheet]
 
 Understanding the growth drivers of your telemetry is as important as understanding the value drivers.  With growth drivers there are ways in which they are highly correlated, but in generally we should choose the main and most direct driver.  The following growth drivers can be used to augment the telemetry backlog with information that can be used to understand the quarterly and yearly growth characteristics.