69 lines
3.3 KiB
Markdown
69 lines
3.3 KiB
Markdown
# ITOM-SaaS-Pain-Points_686083998
|
||
## Introduction
|
||
|
||
This page presents all the pain points for SaaS delivery on the ITOM BU level.
|
||
|
||
## Legends
|
||
|
||
SMAX
|
||
|
||
HCMX
|
||
|
||
FINOPS
|
||
|
||
OO
|
||
|
||
OPS
|
||
|
||
## Pain points
|
||
|
||
- Process
|
||
- OPS Don’t wait until retro, we need a system that can record such inputs.
|
||
- Quality
|
||
- Recent system crashes caused by the new features. (Incident ID, Feature ID?)
|
||
- SMAX SMAX platform pod loads are not well balanced. (24.2 may fix it)
|
||
- It's not...
|
||
- SMAX nativeSACM consumes high resource usage, especially network.
|
||
- SMAX The SMAX still has OOTB index issues.
|
||
- SMAX Redis is the single point of failure and is not easy to debug.
|
||
- SMAX HCMX FINOPS OO Need more post upgrade tests. / CMS post upgrade issue is not acceptable
|
||
- SMAX SLT task is weekly (unplanned change is not submitted )
|
||
- After 2024.1, CMS’s quality is not good. So many issues.
|
||
- SLA
|
||
- SMAX Missing monitoring metrics for CMS/Native SACM
|
||
- CMS not fully ready for auto-healing (rolling restart takes more than 1 minute)
|
||
- SMAX Missing correlations on several S1 / S2 alerts, for example, 5xx errors, and soft interrupts.
|
||
- 5xx errors: put errors into categories
|
||
- Soft interrupt: more metrics / diagnostics to get the detailed breakdown of the interrupt
|
||
- SMAX It is missing the overall throttling mechanism/rate limit which causes unexpected outages on the farm.
|
||
- 24.4?
|
||
- OO OO upgrade takes hours to finish, the OORAS pods can only be upgraded one after another.
|
||
- Solved in 24.3.
|
||
- Security
|
||
- OPS Missing the WAF rules rolling out, the farm is visited by malicious requests every day
|
||
- WIP
|
||
- OPS Major security KPI missing, including Qualys score, SIEM integration, etc.
|
||
- Compliance
|
||
- Missing the standard/certification for EU-managed
|
||
- Maintenance & Operation
|
||
- OPS Operation efforts increase when there are more farms, including upgrades, patches, etc (Automation rate is low.)
|
||
- OPS Monitoring need to be improved. More meaningful alerts, less false alert.
|
||
- Aligning the CPU alert threshold to 99.9%.
|
||
- OPS Troubleshooting takes lots of time.
|
||
- OPS Cannot always leverage Ops from other regions / how to grow up Ops from other regions
|
||
- OPS Too many threads, need all the members to do self-driven.
|
||
- OPS Need an option to better to utilize Shen Wei’s time
|
||
- SMAX Logging issue
|
||
- Accumulated logs cost more
|
||
- Too much logs slows down troubleshooting
|
||
- Too much log writing used up the network throughput
|
||
- OO The tenant import feature cannot handle integrations like nativeSACM and OO.
|
||
- SMAX OO Too many special settings to keep the system stable, and many of them can be lost during upgrade.
|
||
- Cost
|
||
- SMAX HCMX FINOPS OO When customer usage increases the resource doesn't increase linearly.
|
||
- SMAX HCMX FINOPS OO FinOps, SMAX, and OO consume lots of resources, CMS resource usage is OK
|
||
- The sizing of HCMX, OO are based on tenant number instead of usage. Usually for almost all the ESM farm, OO need to be medium profile ($65K/y) or even larger, which doesn't contribute any license revenue.
|
||
- FinOps cost is usually more than SMAX large profile ($113K/y)
|
||
- SMAX sizing is not helpful for medium or large sized customers. Usually the farm need to double or triple the resource required by sizing guide.
|
||
- There is no sizing guide for integration, including API integration, nativeSACM, etc.
|