first build nexus
This commit is contained in:
billyshen
89
Archived/My Task.md
Normal file
89
Archived/My Task.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
|
||||
kanban-plugin: board
|
||||
|
||||
---
|
||||
|
||||
## Backlog
|
||||
|
||||
- [ ] 🔼 Email to Nina about Achmea Pen Testing on EU3, WAF result reported
|
||||
- [ ] 🔼 Prepare JATO UX update notification to impacted customers, send to PM for review first
|
||||
- [ ] 🔺 Initial an email about WAF rules for OP
|
||||
- [ ] ⏫ send email to Alex and Philipp about convince TechM to migrate their FinOps to OP
|
||||
- [ ] ⏫ Onspring new evidence for TLS certificate
|
||||
- [ ] ⏫ Talk to Ellar about ITOM work utilization data, increase the project percentage for some senior person
|
||||
- [ ] 🔺 Check with Remi and Brindusa to add Time spent field in PCS for both Support and Service Request
|
||||
- [ ] 🔺 Change people % in Ellar shared spreadsheet
|
||||
- [ ] ⏫ Reply to Ken to provide more evidence and also check Onspring system the pending tasks
|
||||
- [ ] ⏫ Reply email about new EU farm kick off plan after comments from Mark Peter
|
||||
- [ ] Update, please attached the updated evidence to close Onspring requests Master33541 and Master33560 based on what we gave last September 2024.
|
||||
- [ ] 🔼 Check EU28 Evonik customer license
|
||||
- [ ] ⏫ Check OpsB/NOM customer license expiration date in CT
|
||||
- [ ] 🔼 Raise ticket to request Power BI Pro license:
|
||||
Hello Wei, I have moved the ITOM Cloud Service Workspace to Fabric. You access should be restored. View access is free. Content creators can request a Power BI Pro license through the software request workflow [https://go.opentext.com/softwarerequest](https://go.opentext.com/softwarerequest%20for%20$100) $100 USD annually.
|
||||
|
||||
-Garrett
|
||||
- [ ] 🔼 Ask team to consolidate all important runbook and check who is the new owership of these runbooks
|
||||
- [ ] ⏫ ADAM Q4 Project List
|
||||
- [ ] ⏫ create unique DB user instead of smax-admin which can be cross used by OP/OpsB/NOM as tenant admin role
|
||||
|
||||
|
||||
## WIP
|
||||
|
||||
- [ ] 🔽 Prepare a wiki page to describe 'Troubleshooting as a service'
|
||||
- [ ] ⏫ Track incident: IM3660374
|
||||
- [ ] 🔺 Offline pods incident follow up
|
||||
- [ ] 🔽 Review the Incident Management Meeting (SM9) record to understand detail process on top of it.
|
||||
- [ ] 🔺 Prepare SD draft for Premium DR service for SocGen
|
||||
- [ ] ⏫ Give a mapping table about time spent on each SaaS offerings so that we can give a consolidated team effort on customer tickets
|
||||
|
||||
|
||||
## Done
|
||||
|
||||
- [ ] 🔺 Refine the Premium DR service slides
|
||||
- [ ] ⏫ Initial discussion about US24 unplanned maintenance which might have 2 hours downtime.
|
||||
- [ ] 🔼 Give Wenjun a go command once confirmed Indra is ok with current proposals
|
||||
- [ ] ⏫ Prepare the answers to Sales team about how we're going to perform the yearly DR testing
|
||||
- [ ] ⏫ Provide Feb PCS, X4X data to Sajith
|
||||
- [ ] 🔺 Update 25.1.2 customer notification with official doc link
|
||||
- [ ] 🔼 Review ITOM AWS Cost Breakdown detail and reply to Samar and Melissa
|
||||
- [ ] ⏫ Check with Wenjun about BI data stop sent since Feb 24
|
||||
- [ ] 🔼 Update slides for SMAX/AC VDC readiness meeting
|
||||
- [ ] 🔼 Schedule a meeting to discuss OT IT use case about direct access Vertica DB to fetch FinOps data
|
||||
- [ ] 🔽 Prepare tomorrow's ESM Cloud Service weekly meeting
|
||||
- [ ] ⏫ Prepare upgrade hyper care plan and detail explain what happened for US steel case
|
||||
- [ ] 🔼 Check with Danny about how to submit security review request for OT IT vertica DB direct access case
|
||||
- [ ] 🔼 Reply Ken's questions in team's chat
|
||||
- [ ] ⏫ Send ESM RI plan to OT FinOps team
|
||||
- [ ] 🔺 Send email notification to NOM customers for 3/9, 3/16 maintenance window about EKS upgrade
|
||||
|
||||
|
||||
## Tracking
|
||||
|
||||
- [ ] ⏫ Review patch /upgrade notification content with Dean - Boglarka to drive this
|
||||
- [ ] 🔼 Assign task about create Jenkins job to check AWS Supperession list
|
||||
- [ ] ⏫ Ask wenjun to follow up Dean's request about include ITOM Aviator in SMAX premium trial tenant provision
|
||||
|
||||
|
||||
## Archive
|
||||
|
||||
- [ ] ⏫ Update cost estimation about SG
|
||||
- [ ] ⏫ Send ITOM ESM Monthly Report - Feb 2025
|
||||
- [ ] ⏫ Schedule a meeting with team about Indra switch to OP
|
||||
- [ ] 🔼 Update OT SM9 Assignment Group for Ops-ADM_ESM and Ops-ADM_OpsB to add new team members
|
||||
- [ ] 🔼 Refine the on call list in Everbridge
|
||||
- [ ] 🔺 Prepare ESM 25.1.2 Patch Notifications
|
||||
- [ ] ⏫ Reply Florin's proposal
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Archive
|
||||
|
||||
- [ ] 🔼 Reply to Lihi about non-commercial cloud related efforts
|
||||
|
||||
%% kanban:settings
|
||||
```
|
||||
{"kanban-plugin":"board","list-collapse":[false,false,false,false,false],"full-list-lane-width":true}
|
||||
```
|
||||
%%
|
||||
67
Archived/Work/--- 我的任务 ---.md
Normal file
67
Archived/Work/--- 我的任务 ---.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
|
||||
kanban-plugin: board
|
||||
|
||||
---
|
||||
|
||||
## TikTok Shop Tasks
|
||||
|
||||
- [ ] ⏫ 等营业执照下来注册TikTok Shop
|
||||
- [ ] ⏫ 学习Ushop使用方法，了解整个订单流程
|
||||
- [ ] 🔼 了解一下AMZ123网站
|
||||
|
||||
|
||||
## Backlog
|
||||
|
||||
- [ ] ⏫ 学习并掌握Scrapy 爬虫工具的使用方法，并结合n8n实现自动化
|
||||
- [ ] ⏫ 尝试在本地搭建text to speech 的模型 并且通过API被n8n调用
|
||||
- [ ] ⏫ 用pgAdmin连接NAS上postgres数据库
|
||||
- [ ] ⏫ 尝试在本地使用n8n来调用comfyUI实现图生图自动化
|
||||
- [ ] 🔼 Learn Google Trends Tutorials
|
||||
- [ ] 🔼 学习如何使用Google趋势来查看目标国家的热门产品销售数据
|
||||
- [ ] 🔼 升级Ubuntu1 Portainer 版本
|
||||
- [ ] 🔼 有空时可以搞一下 爬虫爬 OdayDown.com的数据
|
||||
- [ ] 🔽 利用ZBook Laptop搭建第二台Ubuntu Server
|
||||
- [ ] 🔽 读原子习惯，掌握好习惯 中文版先读， 再读英文版
|
||||
- [ ] 🔽 注册并试用kie.ai
|
||||
- [ ] N8n调用第三方ApI 进行图片编辑
|
||||
- [ ] 了解一下SerpAPI
|
||||
|
||||
|
||||
## WIP
|
||||
|
||||
- [ ] ⏫ 尝试使用硅基流的 API来实现文生图，并被n8n调用
|
||||
|
||||
|
||||
## Done
|
||||
|
||||
- [ ] ⏫ 用n8n创建一个workflow可以把internet的图片转存到zipline,并返回图片公共链接
|
||||
- [ ] 🔼 了解一下Homarr的具体用法
|
||||
- [ ] 🔽 逐步淘汰Cpolar的使用，并删除相关软件
|
||||
|
||||
|
||||
## Tracking
|
||||
|
||||
- [ ] ⏫ 利用Qwan3-code来生成n8n代码
|
||||
|
||||
|
||||
## Archive
|
||||
|
||||
- [ ] ⏫ 配置Obsidian使用ishenwei.online 域名的webdav
|
||||
- [ ] ⏬ 在购买的RackNerd的VPS上安装n8n （需要额外考虑）
|
||||
- [ ] ⏫ 在NAS上搭建一个图床应用
|
||||
- [ ] ⏫ 在NAS上部署https://github.com/tt-rss/tt-rss
|
||||
|
||||
|
||||
## Idea
|
||||
|
||||
- [ ] 🔼 利用Postgres里的RSS article数据来实现 n8n调用并通过AI来分析最新得到的RSS article给一个简报并通过邮件发送
|
||||
|
||||
|
||||
|
||||
|
||||
%% kanban:settings
|
||||
```
|
||||
{"kanban-plugin":"board","list-collapse":[false,false,false,false,false,false,false]}
|
||||
```
|
||||
%%
|
||||
@@ -0,0 +1,15 @@
|
||||
|
||||
## 1. Review Upgrade Procedures Document with R&D team
|
||||
## 2. Follow the Upgrade Procedures to perform Dev Farm upgrade validation
|
||||
## 3. Send Notification to ESM Cloud Farm Customer about upcoming maintenance window
|
||||
## 4. Maintenance Window Procedures
|
||||
### 1. Set downtime of APM monitoring
|
||||
### 2. Perform the upgrade change
|
||||
### 3. Send notification to customer once all the change was done
|
||||
### 4. Update Wiki Page about Version Tracking
|
||||
### 5. Update System Health Page - Complete the Maintenance Window
|
||||
### 6. Update PCS Product Version and Environment Version
|
||||
### 7. Restore the APM monitoring and ensure all checks are good
|
||||
|
||||
## 5. Monitoring the farm metrics to ensure everything is working as expected
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
|
||||
Control Tower Link: https://backoffice.saas.microfocus.com/home/bl/desktop.html?TENANTID=1#/customers
|
||||
|
||||
- Request Access to Control Tower
|
||||
-
|
||||
- Customer Order Filter
|
||||
- ESM Product Filter:
|
||||
|
||||
- APM/OpsB/NOM Product Filter
|
||||
|
||||
|
||||
- SaaS Order In Control Tower
|
||||
- CS Ops Fulfill the order and generate license
|
||||
- SaaS Ops team download/allocate license and close the deal
|
||||
- Control Tower order status change to "Provisioned", close the deal
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
|
||||
Wiki Page:
|
||||
https://confluence.opentext.com/display/ICSD/Request+Unplanned+Change+in+Cloud+Production+Environment+Process
|
||||
|
||||
R&D SA Approver
|
||||
- Gong Yi (SMAX)
|
||||
- Danny Tian (SMAX)
|
||||
- Spinu Corneliu (SMAX)
|
||||
- Moldovan Vlad
|
||||
- Diana Pop (CMS)
|
||||
- Bianca Voina (CMS)
|
||||
|
||||
CSD Approver
|
||||
- Shen Wei
|
||||
- Ting Ye
|
||||
@@ -0,0 +1,32 @@
|
||||
## Review R&D Major Release Plan & Patch Plan
|
||||
- ESM RTE: Mihaela Claudia Chis <mchis@opentext.com>
|
||||
- PI Planning Readout Slides
|
||||
- ESM Patch Release Owner: Tanuj Raja Vunnava <tvunnava@opentext.com>
|
||||
- Patch Release Kick Off email
|
||||
- Other requirement about upgrade strategy
|
||||
- Demo/PoC Request
|
||||
- Customer commitment etc.
|
||||
## Prepare Cloud Upgrade Plan
|
||||
### Design Tool
|
||||
### Plan Strategy
|
||||
- US2 Dev Farm Upgrade Validation - 1~2 days prior MR release date
|
||||
- Shared Service - ITOM Aviator US30 staging, EU30 production, EU32 production need to be upgraded first before other consume farm upgrade
|
||||
- EU3/US7 Trial/PoC Farm Upgrade - 1~ 2 weeks after GA release date, Upgrade on Monday (working day)
|
||||
- US2/US24 Opentext Internal Customer Production Farm - 1st Wave Production Farm Upgrade (Maintenance Window)
|
||||
- US26 - SalesForce customer need alternative upgrade date this can be negotiated with CSM and customer
|
||||
- US26/US6/AP10/CA16 External Customer Production Farm - 2nd Wave Production Farm Upgrade (Maintenance Window)
|
||||
- EU8/EU18/EU28/BR14/JP12 External Customer Production Farm - 3nd Wave Production Farm Upgrade (Maintenance Window)
|
||||
- If ESM farm enable Operation Platform, need to upgrade Operation Platform first before upgrade ESM farm
|
||||
- Considering the 1st patch release, we can consider to adopt patch upgrade direct in the upgrade maintenance window (Need to clarify the dependencies)
|
||||
- Try to avoid upgrade window before key teams public holiday. Usually some critical issues will be reported on Monday/Tuesday after version upgrade. Need people standby to support troubleshooting
|
||||
|
||||
### Publish and Notify the ESM Cloud Upgrade Plan
|
||||
- ESM Cloud Upgrade Plan Wiki Page: https://confluence.opentext.com/display/ICSD/ESM+Cloud+Ops+Change+Calendar
|
||||
- ESM Cloud Ops Change Calendar: https://opentextcorporation.sharepoint.com/sites/MFI-SMAXSaaSDevOps/Lists/ESM%20Cloud%20Calendar/calendar.aspx
|
||||
- Internal Communication About ESM Cloud Upgrade Plan (Sample Email)
|
||||
### Continuous to adjust the plan according to the changes
|
||||
- Cancel/Postpone the upgrade according to critical defects
|
||||
|
||||
### Rollback the upgrade
|
||||
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
|
||||
## ESM Cloud
|
||||
- ESM Farm Information: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
|
||||
- ESM Capability Introduction
|
||||
- SMAX
|
||||
- UCMDB, Native SACM, SAM
|
||||
- HCMX/DnD
|
||||
- OO
|
||||
- AC
|
||||
- FinOps Classic
|
||||
- FinOps OP
|
||||
- Operation Platform/Optic Data Lake (ODL)
|
||||
- ITOM Aviator
|
||||
- ESM Farm Version Tracking: https://confluence.opentext.com/display/ICSD/ITOM+Cloud+Applications+Version+Tracking
|
||||
- ESM Customer Tenant Capabilities Enablement BI Report: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3a054e35d20b9d533d81?experience=power-bi
|
||||
|
||||
## OpsB/NOM Cloud
|
||||
- OpsB/NOM Cloud Deployments & Version Tracking:https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking
|
||||
|
||||
## APM Cloud
|
||||
- APM Farm Information: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
- Major Incident Definition: https://confluence.opentext.com/display/ICSD/Major+Incident+Definition
|
||||
- Major Incident Management & Best Practice:
|
||||
- Identification and Detection
|
||||
- Initial Assessment
|
||||
- Incident Logging
|
||||
- Incident in OT SM9
|
||||
- Internal Practice: Create incident in PCS
|
||||
- Communication
|
||||
- Identify Incident Manager
|
||||
- Create team chat group and involve all stakeholders
|
||||
- Keeping update status
|
||||
- Resolution
|
||||
---Break---
|
||||
- Oncall/Response
|
||||
- Post Incident Review
|
||||
- Continuous Improvement (CAPA)
|
||||
- Monitoring & Alerting Enhancements
|
||||
- Documentation & Knowledge base:
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
BI report:
|
||||
|
||||
https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1f4989a9-0127-4c6d-9375-f9dd9bda5d84/ReportSection?experience=power-bi
|
||||
|
||||
PCS Dahsboard:
|
||||
https://pcs.saas.microfocus.com/dashboard
|
||||
@@ -0,0 +1,22 @@
|
||||
PCS: https://pcs.saas.microfocus.com/homepage?AUTH=SAML
|
||||
|
||||
ITOM Cloud Ops Assignment Group:
|
||||
- SD: ESM SaaS Ops
|
||||
- SD: OpsB SaaS Ops
|
||||
- SD: NOM SaaS Ops
|
||||
- SD: DCA SaaS Ops
|
||||
|
||||
|
||||
- ITOM Cloud Service Offerings
|
||||
- Service Request vs Support Request
|
||||
- Entitlement/Environment/Tenant/Product
|
||||
- Service/Support Request triage & workflow
|
||||
- Request -> Incident -> Change
|
||||
- Escalations
|
||||
|
||||
BI report:
|
||||
|
||||
https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1f4989a9-0127-4c6d-9375-f9dd9bda5d84/ReportSection?experience=power-bi
|
||||
|
||||
PCS Dahsboard:
|
||||
https://pcs.saas.microfocus.com/dashboard
|
||||
@@ -0,0 +1,50 @@
|
||||
|
||||
## Role and Responsibility
|
||||
#### Strategic Responsibilities
|
||||
- Own the reliability and performance of multiple SaaS Application Services. (APM, BPM, OpsB, NOM, ESM, DCA, SBM, ESM FedRAMP)
|
||||
- Drive cloud modernization initiatives (e.g., containerization, EKS, CI/CD automation).
|
||||
- Align cloud service delivery with customer SLAs, business growth, and compliance frameworks (e.g., FedRAMP, SBM).
|
||||
- Interface with Sales, Product, Security, and Compliance to support new customer onboarding and cloud architecture reviews.
|
||||
|
||||
#### Operational Responsibilities
|
||||
- Oversee 24x7 operation and monitoring of cloud platforms (AWS-based).
|
||||
- Manage escalations, incidents, and root cause analysis.
|
||||
- Coordinate patching, upgrades, hotfixes, and maintenance windows.
|
||||
- Own service onboarding/offboarding workflows, including tenant provisioning and decommissioning.
|
||||
|
||||
#### People Management
|
||||
- Performance management and coaching of global team members.
|
||||
- Run weekly team syncs, monthly reviews, and ad-hoc cross-regional escalations.
|
||||
|
||||
## Cloud Applications and Cloud Services KS Sessions
|
||||
|
||||
### Session 1
|
||||
- ITOM Cloud Application AWS Account Owner
|
||||
- https://confluence.opentext.com/display/ICSD/ITOM+Cloud+AWS+Account+Overview
|
||||
- AWS Account Admin ownership
|
||||
- Responsibility of AWS Account Admin
|
||||
- ITOM Cloud Application List
|
||||
- ESM/ITOM Aviator/DCA/SBM: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
|
||||
- OpsB/NOM Cloud Application List: https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking
|
||||
- APM Cloud Farm List: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
|
||||
- ITOM Cloud FinOps
|
||||
- BI Reporting: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1a3fceca-6563-4cc6-8218-d1d27f15e2f1/ReportSection?experience=power-bi
|
||||
- Opentext FinOps Team AWS FinOps Dashboard
|
||||
### Session 2
|
||||
- ITOM Cloud Application Version Currency
|
||||
- Upgrade Plan
|
||||
- ESM/FebRAMP Ops Change Calendar
|
||||
- OpsB/NOM Ops Change Calendar
|
||||
- Upgrade Plan Timeline
|
||||
|
||||
### Session 3
|
||||
|
||||
### Session 4
|
||||
|
||||
### Session 5
|
||||
|
||||
### Session 6
|
||||
|
||||
### Session 7
|
||||
|
||||
### Session 8
|
||||
65
Archived/Work/AWS → GCP.md
Normal file
65
Archived/Work/AWS → GCP.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# AWS → GCP
|
||||
|
||||
To migrate your enterprise-level SaaS application from AWS to Google Cloud, you’ll need to find equivalent Google Cloud services for the AWS services you currently use, while ensuring your architecture remains compatible. Here's a service-by-service breakdown for smooth development:
|
||||
|
||||
### 1. **AWS EKS (Elastic Kubernetes Service) → Google Kubernetes Engine (GKE)**
|
||||
|
||||
**Google Kubernetes Engine (GKE)** is Google Cloud’s equivalent to AWS EKS. Both manage Kubernetes clusters, offering similar features like autoscaling, security, and networking.
|
||||
|
||||
- **Migration Notes**: Kubernetes manifests and Helm charts will be reusable with minimal modification, but you’ll need to handle network and security configurations specific to Google Cloud.
|
||||
|
||||
### 2. **AWS RDS (Relational Database Service) → Cloud SQL / Cloud Spanner**
|
||||
|
||||
- **Cloud SQL**: Supports MySQL, PostgreSQL, and SQL Server, making it a direct equivalent for most RDS instances.
|
||||
- **Cloud Spanner**: If you need horizontally scalable, globally distributed databases with strong consistency, consider Cloud Spanner.
|
||||
- **Migration Notes**: Database migration tools like **Database Migration Service** can help with the data migration, ensuring minimal downtime and compatibility.
|
||||
|
||||
### 3. **AWS EFS (Elastic File System) → Filestore**
|
||||
|
||||
**Google Cloud Filestore** is a fully managed NFS (Network File System) service similar to AWS EFS.
|
||||
|
||||
- **Migration Notes**: Ensure your applications are configured to use the Filestore APIs and access paths properly. Performance tiers and network configuration will need review for alignment with your AWS EFS setup.
|
||||
|
||||
### 4. **AWS S3 (Simple Storage Service) → Google Cloud Storage**
|
||||
|
||||
**Google Cloud Storage** is a direct equivalent to AWS S3 for object storage, supporting multiple classes of storage with similar durability and availability guarantees.
|
||||
|
||||
- **Migration Notes**: Google Cloud’s storage APIs differ slightly, so you may need to refactor your code to accommodate the differences. However, bucket management and object lifecycle policies are similar.
|
||||
|
||||
### 5. **AWS Lambda (Serverless Compute) → Google Cloud Functions / Cloud Run**
|
||||
|
||||
- **Google Cloud Functions**: Equivalent to AWS Lambda for small, event-driven serverless tasks.
|
||||
- **Cloud Run**: If you need to run containerized microservices, **Cloud Run** (based on Knative) is a good choice for scaling container workloads.
|
||||
- **Migration Notes**: Code migration is generally straightforward, though GCP uses slightly different event triggers and permission models.
|
||||
|
||||
### 6. **AWS Parameter Store → Secret Manager / Cloud Key Management Service (KMS)**
|
||||
|
||||
- **Secret Manager**: For storing secrets such as passwords, API keys, and tokens.
|
||||
- **Cloud KMS**: For managing encryption keys and ensuring data security.
|
||||
- **Migration Notes**: Similar management principles apply, but authentication and access policies will need revision to comply with Google Cloud's identity model.
|
||||
|
||||
### 7. **AWS SES (Simple Email Service) → SendGrid / Mailgun (Third-party service)**
|
||||
|
||||
Google Cloud doesn't have a native email service comparable to SES, so you can leverage third-party services like **SendGrid** or **Mailgun**, which integrate well with Google Cloud.
|
||||
|
||||
- **Migration Notes**: Integration through APIs will require code changes, but the overall functionality will remain similar.
|
||||
|
||||
### 8. **AWS CloudWatch → Google Cloud Monitoring (formerly Stackdriver)**
|
||||
|
||||
**Google Cloud Monitoring** is the equivalent of AWS CloudWatch, providing observability, logging, and alerting for your infrastructure and applications.
|
||||
|
||||
- **Migration Notes**: If you are heavily using AWS CloudWatch Logs, consider migrating to **Google Cloud Logging** to keep a similar flow of data.
|
||||
|
||||
### Additional Considerations:
|
||||
|
||||
- **IAM and Security**: AWS Identity and Access Management (IAM) maps well to Google Cloud IAM, but you'll need to refactor policies and roles.
|
||||
- **Networking**: Google Cloud’s VPC is similar to AWS VPC, but you'll need to translate networking configurations (firewalls, routing, etc.) and possibly update load balancing setups, using **Google Cloud Load Balancer** in place of AWS Elastic Load Balancing (ELB).
|
||||
|
||||
### Tools for Migration:
|
||||
|
||||
- **Google’s Database Migration Service**: To migrate RDS databases to Cloud SQL.
|
||||
- **Migrate for Compute Engine**: For VM migrations if you use EC2 instances.
|
||||
- **Velostrata**: For handling live migrations of workloads.
|
||||
|
||||
Would you like to dive deeper into any particular service, or need assistance on a specific migration tool or process?
|
||||
|
||||
200
Archived/Work/Answers from ChatGPT.md
Normal file
200
Archived/Work/Answers from ChatGPT.md
Normal file
@@ -0,0 +1,200 @@
|
||||
|
||||
#### Major Incident Management Process
|
||||
|
||||
Certainly! Designing a comprehensive Major Incident Management process is crucial for maintaining the reliability and availability of enterprise SaaS applications. Below is a detailed outline of the major incident management process, including procedures for handling service outages:
|
||||
|
||||
### Major Incident Management Process
|
||||
|
||||
#### 1. **Identification and Detection:**
|
||||
|
||||
- **Automated Monitoring:** Utilize robust monitoring tools to detect anomalies, performance issues, and potential outages.
|
||||
- **User Reports:** Encourage users to report issues promptly via designated channels.
|
||||
|
||||
#### 2. **Incident Logging:**
|
||||
|
||||
- **Centralized Logging:** Maintain a centralized incident log that captures all relevant details, timestamps, and initial impact assessment.
|
||||
- **Severity Classification:** Categorize incidents based on severity to prioritize response efforts.
|
||||
|
||||
#### 3. **Initial Assessment:**
|
||||
|
||||
- **Incident Triage:** Quickly assemble a cross-functional incident response team, including representatives from development, operations, and support.
|
||||
- **Impact Analysis:** Evaluate the scope and impact of the incident on users, systems, and business operations.
|
||||
|
||||
#### 4. **Communication:**
|
||||
|
||||
- **Internal Communication:** Establish communication channels for the incident response team, ensuring timely updates and coordination.
|
||||
- **External Communication:** Prepare predefined messages for customers and stakeholders, providing transparency about the incident.
|
||||
|
||||
#### 5. **Resolution:**
|
||||
|
||||
- **Runbooks and Playbooks:** Develop detailed runbooks and playbooks for common incident scenarios, outlining step-by-step resolution procedures.
|
||||
- **Escalation Procedures:** Define clear escalation paths for issues that require higher-level expertise or management attention.
|
||||
|
||||
#### 6. **Post-Incident Review (PIR):**
|
||||
|
||||
- **Root Cause Analysis (RCA):** Conduct a thorough RCA to identify the underlying cause of the incident.
|
||||
- **Documentation:** Document the incident resolution process, lessons learned, and preventive measures for future incidents.
|
||||
|
||||
#### 7. **Continuous Improvement:**
|
||||
|
||||
- **Iterative Updates:** Regularly update incident response procedures based on lessons learned from past incidents.
|
||||
- **Training and Drills:** Conduct regular training sessions and simulated drills to ensure the incident response team is well-prepared.
|
||||
|
||||
#### 8. **Monitoring and Alerting Enhancements:**
|
||||
|
||||
- **Continuous Monitoring:** Implement ongoing improvements to monitoring and alerting systems to proactively detect potential issues.
|
||||
- **Automated Remediation:** Integrate automated remediation tools to address common incidents swiftly.
|
||||
|
||||
#### 9. **Documentation and Knowledge Sharing:**
|
||||
|
||||
- **Knowledge Base:** Maintain a comprehensive knowledge base with troubleshooting guides, FAQs, and resolutions for known issues.
|
||||
- **Documentation Accessibility:** Ensure that incident response documentation is easily accessible to all team members.
|
||||
|
||||
#### 10. **Review and Audit:**
|
||||
|
||||
- **Periodic Audits:** Conduct periodic reviews and audits of the major incident management process to identify areas for improvement.
|
||||
- **Compliance Checks:** Ensure that the process aligns with industry best practices and regulatory requirements.
|
||||
|
||||
This Major Incident Management process should be regularly reviewed and updated to adapt to evolving technologies and organizational needs. Regular training and communication exercises will help maintain a proactive and efficient incident response capability.
|
||||
|
||||
#### What’s the definition of RACI
|
||||
|
||||
RACI is an acronym that stands for Responsible, Accountable, Consulted, and Informed. It is a project management and organizational tool used to clarify roles and responsibilities within a team or across different stakeholders for specific tasks, processes, or projects. Each letter in RACI represents a different level of involvement and accountability:
|
||||
|
||||
1. Responsible (R): This person or role is responsible for completing the task or carrying out the work. They are the individuals who perform the actual work and ensure it gets done.
|
||||
2. Accountable (A): This person is ultimately accountable for the task's success or failure. They are the decision-makers who oversee the work and ensure it aligns with the project's objectives. There should be only one "A" assigned to each task or activity.
|
||||
3. Consulted (C): These are individuals or roles that provide input, expertise, or advice on the task. They are consulted for their knowledge or perspective, but they are not responsible for the task's completion.
|
||||
4. Informed (I): These individuals or roles need to be kept informed about the task's progress or outcome but do not have active participation in its execution.
|
||||
|
||||
RACI matrices and charts are commonly used to document and communicate these roles and responsibilities, helping teams and organizations to reduce confusion, improve accountability, and ensure that work is completed efficiently and effectively.
|
||||
|
||||
#### Handling Data Return in Enterprise SaaS Business
|
||||
|
||||
Handling data returns in an enterprise SaaS business requires a well-defined process to ensure customer satisfaction and compliance with data privacy regulations. Here's a step-by-step guide to help you prepare a process for when a client requests to return their data:
|
||||
|
||||
1. **Understand Data Ownership and Privacy Policies:**
|
||||
- Clearly define data ownership in your terms of service and privacy policy.
|
||||
- Understand and comply with data protection regulations relevant to your industry and geographic location (e.g., GDPR, CCPA).
|
||||
2. **Provide Clear Terms in Contracts:**
|
||||
- Include provisions in your contracts that outline the conditions under which clients can request the return of their data.
|
||||
- Specify the format and timeline for data return.
|
||||
3. **Implement Data Export Features:**
|
||||
- Build data export features into your SaaS platform to allow clients to easily retrieve their data in a standard and commonly used format (e.g., CSV, JSON).
|
||||
- Ensure that exported data includes all relevant information and maintains data integrity.
|
||||
4. **Establish a Request Process:**
|
||||
- Create a formalized process for clients to request the return of their data.
|
||||
- This process could include a dedicated support channel, a web portal, or a specific form.
|
||||
5. **Authenticate and Verify Requests:**
|
||||
- Implement a robust authentication process to ensure that only authorized individuals can request data returns.
|
||||
- Verify the identity of the requester through multi-factor authentication or other secure means.
|
||||
6. **Document and Track Requests:**
|
||||
- Keep a centralized record of all data return requests.
|
||||
- Track the status of each request, including when it was received, processed, and completed.
|
||||
7. **Review and Cleanse Data:**
|
||||
- Before returning data, review it to ensure it doesn’t contain any sensitive information from other users.
|
||||
- Implement a data cleansing process to remove any irrelevant or unnecessary information.
|
||||
8. **Secure Data Transmission:**
|
||||
- Use secure channels and encryption protocols to transmit the data back to the client.
|
||||
- Provide the client with instructions on how to securely receive the data.
|
||||
9. **Notify Client of Completion:**
|
||||
- Notify the client when their data return request has been processed and the data is available for retrieval.
|
||||
- Provide any relevant documentation or instructions.
|
||||
10. **Follow Up for Feedback:**
|
||||
|
||||
```other
|
||||
- Follow up with the client after the data return to gather feedback on the process and ensure their satisfaction.
|
||||
- Use feedback to continuously improve the data return process.
|
||||
```
|
||||
|
||||
11. **Train Support and Compliance Teams:**
|
||||
|
||||
```other
|
||||
- Ensure that your support and compliance teams are well-trained on the data return process.
|
||||
- Keep them updated on any changes to regulations or internal policies.
|
||||
```
|
||||
|
||||
12. **Regularly Review and Update Process:**
|
||||
|
||||
```other
|
||||
- Periodically review and update the data return process to incorporate any changes in regulations, technology, or customer needs.
|
||||
```
|
||||
|
||||
By implementing a well-structured process, you can efficiently handle data return requests, maintain customer trust, and comply with data protection laws.
|
||||
|
||||
#### Routine DR Validation Process
|
||||
|
||||
Routine disaster recovery (DR) validation reviews are crucial for ensuring the resilience of your enterprise SaaS business. Here's a step-by-step guide to help you prepare a process for routine disaster recovery validation reviews:
|
||||
|
||||
1. **Define Objectives and Scope:**
|
||||
- Clearly define the objectives of the routine disaster recovery validation review.
|
||||
- Specify the scope, including the systems, applications, and data that will be included in the review.
|
||||
2. **Establish a Schedule:**
|
||||
- Set a regular schedule for conducting disaster recovery validation reviews. This could be quarterly, semi-annually, or annually based on the criticality of your systems.
|
||||
3. **Document the Disaster Recovery Plan (DRP):**
|
||||
- Ensure that you have a comprehensive and up-to-date disaster recovery plan in place.
|
||||
- Document the step-by-step procedures for recovering systems and data in the event of a disaster.
|
||||
4. **Identify Key Stakeholders:**
|
||||
- Identify the key stakeholders involved in the disaster recovery validation process.
|
||||
- This may include IT administrators, security personnel, and relevant business unit representatives.
|
||||
5. **Select Validation Criteria:**
|
||||
- Define the criteria that will be used to validate the effectiveness of the disaster recovery plan.
|
||||
- Criteria may include recovery time objectives (RTO), recovery point objectives (RPO), and data integrity.
|
||||
6. **Simulate Disaster Scenarios:**
|
||||
- Develop a set of realistic disaster scenarios that could impact your systems and data.
|
||||
- Simulate these scenarios to test the effectiveness of your disaster recovery plan.
|
||||
7. **Coordinate with Third-Party Vendors:**
|
||||
- If your SaaS business relies on third-party vendors or cloud service providers, coordinate with them to ensure that their disaster recovery plans align with yours.
|
||||
- Validate their processes and capabilities as part of your review.
|
||||
8. **Perform Tabletop Exercises:**
|
||||
- Conduct tabletop exercises with key stakeholders to walk through various disaster recovery scenarios.
|
||||
- Use these exercises to identify weaknesses, gaps, and areas for improvement in the plan.
|
||||
9. **Automate Testing Where Possible:**
|
||||
- Implement automation tools to simulate and test disaster recovery procedures.
|
||||
- Automation can help streamline the testing process and provide more accurate results.
|
||||
10. **Measure and Analyze Results:**
|
||||
- Measure the performance against the defined criteria during each validation review.
|
||||
- Analyze the results to identify trends, patterns, and areas that need improvement.
|
||||
11. **Document Findings and Recommendations:**
|
||||
- Document the findings of each disaster recovery validation review.
|
||||
- Provide clear recommendations for improvements and corrective actions.
|
||||
12. **Implement Improvements:**
|
||||
- Act on the recommendations and implement improvements to enhance the effectiveness of your disaster recovery plan.
|
||||
13. **Review and Update DRP:**
|
||||
- Regularly review and update the disaster recovery plan based on the lessons learned from validation reviews and changes in your IT infrastructure.
|
||||
14. **Communicate Results:**
|
||||
- Communicate the results of the disaster recovery validation reviews to relevant stakeholders.
|
||||
- Ensure transparency and provide information on the steps being taken to address any identified issues.
|
||||
15. **Continuous Training and Awareness:**
|
||||
- Conduct regular training sessions for your IT and operational teams to ensure they are familiar with the disaster recovery procedures.
|
||||
- Raise awareness among employees about the importance of disaster recovery and their roles in the process.
|
||||
|
||||
By following these steps, you can establish a robust process for routine disaster recovery validation reviews, helping to ensure the resilience and continuity of your enterprise SaaS business in the face of potential disasters.
|
||||
|
||||
|
||||
|
||||
#### Please help explain what's the SOC2 audit?
|
||||
|
||||
Please help me explain what's the SOC2 audit?
|
||||
|
||||
SOC 2, which stands for Service Organization Control 2, is a framework for managing and securing data that is crucial for the privacy of user information. It is specifically designed for technology and cloud computing organizations that store customer data in the cloud. Developed by the American Institute of CPAs (AICPA), SOC 2 compliance is not a one-time event but an ongoing process that requires companies to follow certain criteria to ensure the security, availability, processing integrity, confidentiality, and privacy of customer data.
|
||||
|
||||
Here are key components of a SOC 2 audit:
|
||||
|
||||
1. **Trust Service Criteria:** SOC 2 is built around five "Trust Service Criteria" (TSC) – security, availability, processing integrity, confidentiality, and privacy. These criteria serve as the foundation for evaluating an organization's systems and processes.
|
||||
- **Security:** The system is protected against unauthorized access (both physical and logical).
|
||||
- **Availability:** The system is available for operation and use as committed or agreed.
|
||||
- **Processing Integrity:** System processing is complete, valid, accurate, timely, and authorized.
|
||||
- **Confidentiality:** Information designated as confidential is protected as committed or agreed.
|
||||
- **Privacy:** Personal information is collected, used, retained, disclosed, and disposed of in conformity with the commitments in the entity’s privacy notice.
|
||||
2. **SOC 2 Type I and Type II Audits:**
|
||||
- **Type I:** Examines the suitability of the design of controls at a specific point in time.
|
||||
- **Type II:** Examines the operational effectiveness of these controls over a period of time (typically a minimum of six months).
|
||||
3. **Scope and Boundary:** The organization defines the scope of the audit, including the systems that are in scope and the boundaries of the environment being evaluated.
|
||||
4. **Risk Management and Compliance:** SOC 2 requires organizations to identify and manage risks related to the security, availability, processing integrity, confidentiality, and privacy of information.
|
||||
5. **Written Policies and Procedures:** Organizations need to have documented policies and procedures in place to demonstrate how they achieve and maintain compliance with the Trust Service Criteria.
|
||||
6. **Third-Party Involvement:** If a company uses third-party service providers, the SOC 2 audit may extend to these providers to ensure that their services also meet the required standards.
|
||||
|
||||
Successfully completing a SOC 2 audit provides organizations with a valuable certification that demonstrates their commitment to data security and privacy. It is often seen as a trust-building factor for customers and partners who want assurance that their data is handled with the utmost care and security.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title:
|
||||
source:
|
||||
author:
|
||||
- Shen Wei
|
||||
published:
|
||||
created:
|
||||
description:
|
||||
tags:
|
||||
---
|
||||
## Introduction
|
||||
The main purpose of this document is to help non-Cloud Ops team members better understand the various services and tools currently provided for Cloud Application troubleshooting, so that they can be used flexibly in different scenarios and reduce dependence on Cloud Ops engineers.
|
||||
Our goal is also very clear. We hope to provide a more efficient DevOps ecosystem to provide better services to our customers.
|
||||
|
||||
**Please note that the various services and tools mentioned below require approval and authorization, and are currently limited to members of the Cloud Ops and R&D CPE teams**
|
||||
## Troubleshooting as a Service
|
||||
|
||||
### Access Environment as a Service
|
||||
#### Access to Customer Tenant
|
||||
We provide a method to enter the customer's tenant so that when doing troubleshooting, you can directly access the customer's environment to check the problem and understand the symptoms of the problem at the first time, so as to make the right judgment.
|
||||
|
||||
|
||||
#### Access to ESM Farm BO, IDM, UCMDB JMX console
|
||||
We provide a method to apply for temporary user access to each farm management console
|
||||
- BO Suite Admin
|
||||
- ESM IDM Admin
|
||||
- UCMDB Super Admin to UCMDB JMX Console
|
||||
|
||||
### Log Collection as a Service
|
||||
We provide a very comprehensive log collection automation tool.
|
||||
Collect log information of a specific module within a specific time period. Users can select appropriate filtering conditions to collect logs according to different scenarios, so as to locate problems more accurately and reduce extra effort caused by excessive log size.
|
||||
|
||||
|
||||
### Check Configuration
|
||||
|
||||
### Monitoring as a Service
|
||||
|
||||
#### Unified Monitoring via pre-defined Grafana Dashboard
|
||||
We provide a lot of rich implementation monitoring data for various troubleshooting. Currently we use Grafana as the monitoring UI to reflect the monitoring data of farm implementation:
|
||||
- AWS Cloud Watch Data Source - Able to have real-time infrastructure monitoring (AWS EKS/EFS/RDS)
|
||||
- Prometheus Data Source - Able to check real-time application level metrics exposed by Prometheus
|
||||
- Database query Data Source - Get some key indicators of the application through database query
|
||||
- Containerize/K8S - Able to monitor the key monitoring data of the containerize product, container/node/pod etc.
|
||||
|
||||
#### Service Availability Health Page
|
||||
|
||||
|
||||
### Log Analysis as a Service
|
||||
|
||||
### BI Reporting as a Service
|
||||
|
||||
### Unplanned Change Request as a Service
|
||||
|
||||
### Other Services
|
||||
22
Archived/Work/CSD/ESM Cloud Knowledge Sharing Plan.md
Normal file
22
Archived/Work/CSD/ESM Cloud Knowledge Sharing Plan.md
Normal file
@@ -0,0 +1,22 @@
|
||||
## Product Service
|
||||
### ESM Product
|
||||
|
||||
### ESM Cloud Trial
|
||||
|
||||
## Customer Service
|
||||
### SaaS Customer Support Model
|
||||
### Customer Service Offering Runbook
|
||||
- Configure SAML authentication
|
||||
- Configure custom domain for customer
|
||||
|
||||
|
||||
## DevOps/SRE
|
||||
### ESM Cloud GitLab
|
||||
### ESM Cloud Operation Automation/Jenkins
|
||||
### ESM Cloud Monitoring
|
||||
### ESM Cloud System Health Page
|
||||
### ESM Cloud Disaster Recovery
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
|
||||
## Role and Responsibility
|
||||
#### Strategic Responsibilities
|
||||
- Own the reliability and performance of multiple SaaS Application Services. (APM, BPM, OpsB, NOM, ESM, DCA, SBM, ESM FedRAMP)
|
||||
- Drive cloud modernization initiatives (e.g., containerization, EKS, CI/CD automation).
|
||||
- Align cloud service delivery with customer SLAs, business growth, and compliance frameworks (e.g., FedRAMP, SBM).
|
||||
- Interface with Sales, Product, Security, and Compliance to support new customer onboarding and cloud architecture reviews.
|
||||
|
||||
#### Operational Responsibilities
|
||||
- Oversee 24x7 operation and monitoring of cloud platforms (AWS-based).
|
||||
- Manage escalations, incidents, and root cause analysis.
|
||||
- Coordinate patching, upgrades, hotfixes, and maintenance windows.
|
||||
- Own service onboarding/offboarding workflows, including tenant provisioning and decommissioning.
|
||||
|
||||
#### People Management
|
||||
- Performance management and coaching of global team members.
|
||||
- Run weekly team syncs, monthly reviews, and ad-hoc cross-regional escalations.
|
||||
|
||||
## Cloud Applications and Cloud Services KS Sessions
|
||||
|
||||
### Session 1
|
||||
- ITOM Cloud Application AWS Account Owner
|
||||
- https://confluence.opentext.com/display/ICSD/ITOM+Cloud+AWS+Account+Overview
|
||||
- AWS Account Admin ownership
|
||||
- Responsibility of AWS Account Admin
|
||||
- ITOM Cloud Application List
|
||||
- ESM/ITOM Aviator/DCA/SBM: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
|
||||
- OpsB/NOM Cloud Application List: https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking
|
||||
- APM Cloud Farm List: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
|
||||
- ITOM Cloud FinOps
|
||||
- BI Reporting: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1a3fceca-6563-4cc6-8218-d1d27f15e2f1/ReportSection?experience=power-bi
|
||||
- Opentext FinOps Team AWS FinOps Dashboard
|
||||
### Session 2
|
||||
- ITOM Cloud Application Version Currency
|
||||
- Upgrade Plan
|
||||
- ESM/FebRAMP Ops Change Calendar
|
||||
- OpsB/NOM Ops Change Calendar
|
||||
- Upgrade Plan Timeline
|
||||
|
||||
### Session 3
|
||||
|
||||
### Session 4
|
||||
|
||||
### Session 5
|
||||
|
||||
### Session 6
|
||||
|
||||
### Session 7
|
||||
|
||||
### Session 8
|
||||
64
Archived/Work/Cloud Service “Bilities”.md
Normal file
64
Archived/Work/Cloud Service “Bilities”.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Cloud Service “Bilities”
|
||||
source:
|
||||
author:
|
||||
published: 2025-03-01
|
||||
created: 2025-03-01
|
||||
description:
|
||||
tags: []
|
||||
link:
|
||||
---
|
||||
# Cloud Service “Bilities”
|
||||
|
||||
**The "bilities"**
|
||||
|
||||
In heritage OpenText Architecture we are constantly chasing how to meet what we lovingly call the "bilities". Here is a list of the "bilities"
|
||||
|
||||
Below are the primary capability requirements of any application to be operated by OT Commercial Cloud Service Delivery. Some are absolute requirements, others add to the stability, performance and customer experience of the service.
|
||||
|
||||
These define the “What” not the “How” of either the application or the infrastructure.
|
||||
|
||||
**Recoverability** – Capability of an application to recover to a normal processing disposition as soon as a deviation from normal processing is detected either internal to the application or through external monitoring. Recoverability includes not only restarting but restarting processing where it was last interrupted.
|
||||
|
||||
**Usability** – All applications in a processing community are interacted with in a common and predictable manner, both from the administration side and the consumer side. Standards in usability across applications supports efficient usage across those applications.
|
||||
|
||||
**Operability** – Capability of an application component to be started, stopped, updated, diagnosed and deployed in a standard and predictable way.
|
||||
|
||||
**Maintainability** – Capability of an application component to be updated, patched or functions changed in a standard and predictable manner. Maintainability requires backward compatibility through 2 or more releases to enable maintenance activities to occur online.
|
||||
|
||||
**Securability** – Capability of an application component to protect its assets and customer payload from unauthorized access. Additionally, a capability to enforce access control rules based upon approved role.
|
||||
|
||||
**Persistability** – Capability of an application to always persist payload data once it has entered the OT processing environment. That data must exist and be accessible through maintenance, defect, application outage and normal processing. Persistence should last the entirety of the payloads expected processing lifecycle from entrance to the environment through historical archive expiration. Persistence will accommodate global processing and Disaster Recovery requirements where applicable.
|
||||
|
||||
**Mobility** – Capability of an application to survive infrastructure actions to support moving service components through In-center High Availability, Intra-center Geographic relocation and Intra-service Private to Public Cloud relocation.
|
||||
|
||||
**Throttleability** – Capability of an application to control the processing rate through each component or service. This key capability of each application component enables the operators of the service to isolate and maintain control of recovery to normal processing flow.
|
||||
|
||||
**Deployability** – Capability of an application component to be maintained without downtime to the solution as a whole. Maintenance, wherever possible, needs to take place without externally identifiable service interruption.
|
||||
|
||||
**Reliability** – Capability of an application component or collection of components to with a high degree of consistency perform its defined function through both normal and abnormal operating conditions. Reliability requires that the application component be able to perform its defined work through outage.
|
||||
|
||||
**Reusability** – Capability of application service to perform for more than one service consumer. Build once, use many in a common and consistent way.
|
||||
|
||||
**Accountability/Billability** – Capability of an application to accurately report its usage by customer tenant for financial accounting purposes.
|
||||
|
||||
**Durability**–Capability of an application to survive deviation from normal operating conditions.
|
||||
|
||||
**Troubleshootability** – Capability to provide clear output to logging systems about all application components health and disposition during both normal and abnormal operating conditions.
|
||||
|
||||
**Defensibility** – Capability and awareness of the application to defend itself against incorrect usage. Both accidental and purposeful.
|
||||
|
||||
**Extensibility** – An upfront design capability that takes into consideration the applications ability to expand its functions automatically in response to dynamic demand prompts. Extensibility promotes expandability and elasticity.
|
||||
|
||||
**Auditability** – An application needs to be deployed with capabilities and structures, and within an infrastructure design, that meet applicable external security and audit standards.
|
||||
|
||||
**Application configurability** – All required feature and functional configuration management should be provided through a Web/API enabled interface. No customer should need administrative access to underlying systems or infrastructure to perform customer available administrative tasks.
|
||||
|
||||
**Observability** – Capability of an application to be deployed as an active part of an ecosystem that provides and accurate, timely, and complete indication of functional status and capacity level.
|
||||
|
||||
**Visibility** – Provide capability to see detailed monitoring data describing the operating condition or health of the application.
|
||||
|
||||
**Affordability** – An application needs to implement and use components and software that achieve P&L objectives and retain that position when scaled. This includes the full range of administrative, support, and operational costs.
|
||||
|
||||
**Adaptability** – An advanced capability of an application to be aware of processing going on around both upstream and downstream. AI and machine learning are key to this capability.
|
||||
|
||||
46
Archived/Work/ITOM Cloud Service Review Meeting.md
Normal file
46
Archived/Work/ITOM Cloud Service Review Meeting.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# ITOM Cloud Service Review Meeting
|
||||
|
||||
### ESM
|
||||
|
||||
- Current Status
|
||||
- Farm #, region,
|
||||
- EU managed
|
||||
- Team size
|
||||
- Major workload
|
||||
- Upgrade maintenance
|
||||
- Customer Cloud Service request → Show trend
|
||||
- Internal Cloud Service - Trial (SMAX, CMS Standalone, HCMX, ITOM Aviator), Unplanned change etc.
|
||||
- Customer driven project - UPN change,
|
||||
- Security
|
||||
- Recent Plan and activity
|
||||
- Upgrade/Patch, SMAX helm transformation
|
||||
- New farm plan
|
||||
- ITOM Aviator productionize
|
||||
- Issues & Gap
|
||||
- EU Ops engineer resource gap
|
||||
- FedRAMP resource gap
|
||||
- Product quality caused additional operation effort
|
||||
|
||||
### Smart Observability
|
||||
|
||||
- Current Status
|
||||
- Instances #, customer #
|
||||
- Team size
|
||||
- Major workload
|
||||
- Cloud deployment automation certification
|
||||
- Paid customer cloud instance deployment, initial configuration
|
||||
- Trial Instance deployment
|
||||
- Maintain upgrade, upgrade validation
|
||||
- Customer
|
||||
- Recent Plan and activity
|
||||
- 24.2 Upgrade/Patch
|
||||
- Support new product capability - AppO, CNO
|
||||
- Issues & Gap
|
||||
- AWS Cost Control
|
||||
- Trial Instance control
|
||||
- NOM Ops resource gap
|
||||
- PCS Support case
|
||||
- RnD request cloud instance
|
||||
|
||||
|
||||
|
||||
62
Archived/Work/Meeting Note/ESM Weekly Meeting Agenda.md
Normal file
62
Archived/Work/Meeting Note/ESM Weekly Meeting Agenda.md
Normal file
@@ -0,0 +1,62 @@
|
||||
|
||||
### Mar 19
|
||||
- ESM 25.2 upgrade validation plan - Ting Ye
|
||||
- ESM Change Management Process Update - Ting Ye
|
||||
- SG Yearly DR solution to share with team - Shen Wei
|
||||
- ITOM Aviator EU32 farm construction status - Liu Yu/Adina
|
||||
- ESM US2 dev farm automation pipeline - Sunny
|
||||
- Update Incident Management Process -Shen Wei
|
||||
-
|
||||
|
||||
### Mar 13
|
||||
- Demo: New Jenkins Job to request temp BO admin user -Wenjun Sun
|
||||
- Customer case update
|
||||
- Team Project Update:
|
||||
- ESM Upgrade/Patch/Hotfix - Ting Ye
|
||||
- AWS account migration to new SCP OU hierarchy - Yu Liu
|
||||
- Terraform automation to construct new farm - Sunny Xia
|
||||
- Round table
|
||||
### Mar 3
|
||||
- Patch upgrade rollback strategy update - Shen Wei
|
||||
- Heads up about time coverage - Shen Wei
|
||||
- Ops Doc review and approve - Shen Wei
|
||||
- ESM 25.1.2 + ITOM Aviator 25.1.2 Patch upgrade plan - Shen Wei
|
||||
- ITOM Aviator (EU managed farm) budget approved, start project Yu Liu
|
||||
- OP BVD ILR license generation and documentation Miroslav Shindarov Yun Zhao
|
||||
- Operation Excellence Update
|
||||
- Remove BO admin and use temp suite-admin account
|
||||
- Grafana - AWS Cognito authentication status
|
||||
- Terraform for ESM
|
||||
- DevSecOps Qualys/Prisma- Yu Liu
|
||||
- New member training status update
|
||||
- Round table
|
||||
### Feb 25
|
||||
- FedRAMP farm updates - Jeremy Thunker
|
||||
- Team project update
|
||||
- ESM Upgrade Ting Ye
|
||||
- AWS account migration to new SCP OU hierarchy - Yu Liu
|
||||
- Grafana to use AWS Cognito - Shen Wei
|
||||
- CCOE AMI adoption - Ting Ye
|
||||
- Cost Optimization - Ling-yan Meng
|
||||
- Introduce the process how to handle security scan found issues - Shen Wei
|
||||
- Customer exit process
|
||||
### Feb 17
|
||||
- Welcome to Mericel to join ESM Cloud Ops team
|
||||
- ESM 25.1.1 patch upgrade status - Ting Ye
|
||||
- ITOM Aviator 25.1.1 upgrade status update - Yu Liu
|
||||
- Mega Audit update - Shen Wei
|
||||
- New ITOM Aviator farm (EU-managed) preparation - Yu Liu
|
||||
- SMAX helm hotfix post deployment actions - Ling-yan Meng
|
||||
- Round table update
|
||||
### Feb 12
|
||||
- ESM Cloud Service meeting schedule introduction
|
||||
- ITOM ESM Cloud Service Catalog introduction and new service approval flow
|
||||
- New Project:
|
||||
- New ITOM Aviator Farm (EU managed)
|
||||
- Adopt CCOE AMI images
|
||||
- 25.2 upgrade plan
|
||||
- New ITOM Cloud Farm Architecture
|
||||
- New member training plan
|
||||
|
||||
I will record this meeting to ensure different time zone team member can watch the replay.
|
||||
|
||||
@@ -0,0 +1,150 @@
|
||||
# **ITOM ESM Cloud Service Monthly Report - Feb 2025**
|
||||
|
||||
**2025/2/1 ~ 2025/2/28**
|
||||
|
||||
This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
|
||||
|
||||
# Table of Content:
|
||||
- [[#Product Cloud Service|Product Cloud Service]]
|
||||
- [[#Product Cloud Service#Planned Maintenance Window Changes|Planned Maintenance Window Changes]]
|
||||
- [[#Product Cloud Service#Upgrade Plan|Upgrade Plan]]
|
||||
- [[#Product Cloud Service#Unplanned Production Change|Unplanned Production Change]]
|
||||
- [[#Product Cloud Service#Tenant Provision Services|Tenant Provision Services]]
|
||||
- [[#Product Cloud Service#Product Trial Service|Product Trial Service]]
|
||||
- [[#Customer Cloud Service|Customer Cloud Service]]
|
||||
- [[#Customer Cloud Service#Customer Cloud Service|Customer Cloud Service]]
|
||||
- [[#Customer Cloud Service#Major Incident & RCA|Major Incident & RCA]]
|
||||
- [[#Customer Cloud Service#Customer Order & Fulfillment Highlights|Customer Order & Fulfillment Highlights]]
|
||||
- [[#Customer Cloud Service#Monthly SLA|Monthly SLA]]
|
||||
- [[#Cloud DevOps/SRE|Cloud DevOps/SRE]]
|
||||
- [[#Cloud DevOps/SRE#ITOM Operation Platform 25.1|ITOM Operation Platform 25.1]]
|
||||
- [[#Cloud DevOps/SRE#ESM Cloud Application WAF Enablement|ESM Cloud Application WAF Enablement]]
|
||||
- [[#Cloud DevOps/SRE#ESM GCP onboarding|ESM GCP onboarding]]
|
||||
- [[#Cloud DevOps/SRE#Security & Compliance|Security & Compliance]]
|
||||
- [[#Cloud DevOps/SRE#Cloud BI Reporting|Cloud BI Reporting]]
|
||||
|
||||
---
|
||||
# Product Cloud Service
|
||||
|
||||
## Planned Maintenance Window Changes
|
||||
|
||||
- **ESM Standard Planned Changes**
|
||||
- There were a total of **49** times of (SMX/CMS/OMT/OO, FedRAMP, DCA, ITOM Aviator) Upgrade/Patch/Hotfix deployments to various farms
|
||||
- All **ESM production farms** (**EU3/US7/US2/US24/US26/US6/EU8/AP10/JP12/BR14/CA16/EU18/EU28**) were upgraded to ESM latest major version **ESM 25.1.1** by the end of Feb, 2025
|
||||
- **ITOM Operation Platform** **25.1.1** was upgraded on ESM farm (**EU3/US24/EU18**) by the end of Feb, 2025
|
||||
- **ITOM Aviator Service** (**EU30**) was already upgraded to **25.1.1** with some infra change with language model
|
||||
- All ESM Farm's **AWS EKS** version were upgraded to **1.30**
|
||||
- FedRAMP **AMI Rotation + 24.3 FP4** was done successfully in Feb maintenance window
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Upgrade Plan
|
||||
|
||||
**ESM 25.1 Upgrade Plan - COMPLETE**
|
||||
|
||||
**ESM 25.2 Upgrade Plan - IN PROGRESS**
|
||||
|
||||
---
|
||||
## Unplanned Production Change
|
||||
|
||||
- Total **17** Unplanned Production Changes deployed to different ESM farms in this month
|
||||
- **The number of additional unplanned change requests generated by product quality increased again this month. This needs to be taken seriously by the RnD team and analyzed after the fact to reduce similar problems and additional production changes.::**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Tenant Provision Services
|
||||
|
||||
- There were a total of **28** tenant provision request fulfilled in this month.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Product Trial Service
|
||||
|
||||
- There were a total of **370** product trial related service request fulfilled in this month.
|
||||
|
||||
|
||||
|
||||
|
||||
- CT Trial (External Customer SMAX Only Trial) - **12**
|
||||
|
||||
|
||||
- Internal SMAX Premium Trial - **50**
|
||||
|
||||
|
||||
- HCMX Trial - **1**
|
||||
|
||||
|
||||
- ESM (SMAX/AMX/CMS) Trial - **21**
|
||||
|
||||
|
||||
- **ITOM Aviator Trial - 20**
|
||||
|
||||
# Customer Cloud Service
|
||||
|
||||
## Customer Cloud Service
|
||||
|
||||
- There were a total of **96** Customer Cloud Service Requests handled by ESM Cloud Service team in PCS
|
||||
- **Special thanks to Remi's ESM Cloud RnD team for their cooperation in handling the customer's Cloud Service Request with technical support!**
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Major Incident & RCA
|
||||
|
||||
#### [2025/02/09 - US6/US2/AP10 - SMAX- Major Function Issue](https://confluence.opentext.com/pages/viewpage.action?pageId=689008569)
|
||||
|
||||
---
|
||||
## Customer Order & Fulfillment Highlights
|
||||
|
||||
---
|
||||
|
||||
## Monthly SLA
|
||||
|
||||
- **ESM SMAX has achieved all 100% SLA in Jan, 2024**
|
||||
- Data is available through **Jan 2024**, with Feb 2025 SLA data to be released around mid-March.
|
||||
|
||||
---
|
||||
|
||||
# Cloud DevOps/SRE
|
||||
|
||||
## ITOM Aviator (EU-Managed) Farm
|
||||
- We got final business approval to construct new **ITOM Aviator (EU-managed)** farm.
|
||||
- The project has already started and is expected to be delivered in 1 to 2 weeks
|
||||
## ITOM Operation Platform 25.1
|
||||
|
||||
- We have successfully upgrade Operation Platform 24.4 to **25.1** on **EU3/US24/EU18** farm.
|
||||
- We're preparing the Operation Platform 25.2 cloud readiness work include to start support OpsB to use OP 25.2 in ITOM Cloud environment.
|
||||
- We are now continuing to work on the OP D2 enablement automation and the relevant operation runbook.
|
||||
## ESM Cloud Application WAF Enablement
|
||||
|
||||
- A new DevOps project was initiated to enhance WAF rules management & cloud deployment automation
|
||||
- After some series of team efforts, it went through several processes of testing, modification, and deployment. We have now reached the criteria of **Enable WAF denied mode** with current WAF version on top of SMAX 25.1.1.
|
||||
- We have enabled **SMAX WAF** in ‘**Denied Mode**’ on **US2** farm this Monday(Feb 24th).
|
||||
- In addition, we have enable ‘**Observation Mode**’ on **US24** & **US26** farms to get more WAF log information to help us determine the effectiveness of blockings.
|
||||
## ESM GCP onboarding
|
||||
- Based on the business requirements, we started working with Cloud SA group and Product group on GCP onboarding for ESM. Currently, there are two main working threads which require product team support to certify ESM products deployment on GCP, and validation and experimentation for GCP OCF cloud architecture platform led by Cloud SA.
|
||||
## Operation Excellence
|
||||
- We are actively enhancing the automation of ESM farm construction, covering all configurations based on AWS services, and using OT compliance automation solutions to build cloud automation deployment for ESM Farm
|
||||
- We've implemented to use AWS Cognito authentication to control all Cloud Ops tooling. Recently we've enabled AWS Cognito authentication to access **Grafana** monitoring tool
|
||||
## Security & Compliance
|
||||
- At the request of Opentext GIS, the ESM Cloud Service Team has installed **Qualys** and **Prisma Defender** on all ESM production farms in order to facilitate security scanning on the Cloud to provide more secure ESM SaaS services.
|
||||
- We recently launched a new project on how to handle various OS-based security issues discovered by Qualys Scan. In conjunction with the upcoming adopt **CCOE AMI** project, we intend to centrally replace and update the existing Cloud Application's EKS worker node OS to meet higher security standards.
|
||||
|
||||
## Cloud Service BI Reporting
|
||||
|
||||
- ITOM ESM Farm/Tenant Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3243d84335d863ef318a?experience=power-bi)
|
||||
- ITOM Cloud Service Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/363a8aba-6746-4468-9d5c-54e0a463b708/ReportSectionc350f5d544676dc460b4?experience=power-bi)
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,198 @@
|
||||
---
|
||||
title: ITOM ESM Cloud Service Monthly Report - Jan 2025
|
||||
source:
|
||||
author:
|
||||
- Wei Shen
|
||||
created: 2025-03-02
|
||||
description: This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
|
||||
tags:
|
||||
- cloud
|
||||
- "#service"
|
||||
- "#report"
|
||||
---
|
||||
# **ITOM ESM Cloud Service Monthly Report - Jan 2025**
|
||||
|
||||
**2025/1/1 ~ 2025/1/31**
|
||||
|
||||
This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
|
||||
|
||||
# Table of Content:
|
||||
- [[#Product Cloud Service|Product Cloud Service]]
|
||||
- [[#Product Cloud Service#Planned Maintenance Window Changes|Planned Maintenance Window Changes]]
|
||||
- [[#Product Cloud Service#Upgrade Plan|Upgrade Plan]]
|
||||
- [[#Product Cloud Service#Unplanned Production Change|Unplanned Production Change]]
|
||||
- [[#Product Cloud Service#Tenant Provision Services|Tenant Provision Services]]
|
||||
- [[#Product Cloud Service#Product Trial Service|Product Trial Service]]
|
||||
- [[#Customer Cloud Service|Customer Cloud Service]]
|
||||
- [[#Customer Cloud Service#Customer Cloud Service|Customer Cloud Service]]
|
||||
- [[#Customer Cloud Service#Major Incident & RCA|Major Incident & RCA]]
|
||||
- [[#Customer Cloud Service#Customer Order & Fulfillment Highlights|Customer Order & Fulfillment Highlights]]
|
||||
- [[#Customer Cloud Service#Monthly SLA|Monthly SLA]]
|
||||
- [[#Cloud DevOps/SRE|Cloud DevOps/SRE]]
|
||||
- [[#Cloud DevOps/SRE#ITOM Operation Platform 25.1|ITOM Operation Platform 25.1]]
|
||||
- [[#Cloud DevOps/SRE#ESM Cloud Application WAF Enablement|ESM Cloud Application WAF Enablement]]
|
||||
- [[#Cloud DevOps/SRE#ESM GCP onboarding|ESM GCP onboarding]]
|
||||
- [[#Cloud DevOps/SRE#Security & Compliance|Security & Compliance]]
|
||||
- [[#Cloud DevOps/SRE#Cloud BI Reporting|Cloud BI Reporting]]
|
||||
|
||||
---
|
||||
|
||||
# Product Cloud Service
|
||||
|
||||
## Planned Maintenance Window Changes
|
||||
|
||||
- **ESM Standard Planned Changes**
|
||||
- There were a total of **::22::** times of (SMX/CMS/OMT/OO, FedRAMP, DCA, ITOM Aviator) Upgrade/Patch/Hotfix deployments to various farms
|
||||
- **ESM farms** (**::EU3/US7/US2/US24/US26::**) were upgraded to ESM latest major version **::ESM 25.1::** by the end of Jan, 2025
|
||||
- **ITOM Operation Platform** **::25.1::** was upgraded on ESM farm (**::EU3/US24::**) by the end of Jan, 2025
|
||||
- **ITOM Aviator Service** (**::EU30::**) was already upgraded to **::25.1::**
|
||||
- All ESM Farm's **AWS EKS** version were upgraded to **::1.30::**
|
||||
- FedRAMP **::AMI Rotation::** + **::RDS 15.4 +EKS Upgrade::** was done successfully in Jan maintenance window
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Upgrade Plan
|
||||
|
||||
**ESM 25.1 Upgrade Plan - ::IN PROGRESS::**
|
||||
|
||||
|
||||
|
||||
---
|
||||
## Unplanned Production Change
|
||||
|
||||
- > Total **::26::** Unplanned Production Changes deployed to different ESM farms in this month
|
||||
- > **::The number of additional unplanned change requests generated by product quality increased again this month. This needs to be taken seriously by the RnD team and analyzed after the fact to reduce similar problems and additional production changes.::**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Tenant Provision Services
|
||||
|
||||
- > There were a total of **::17::** tenant provision request fulfilled in this month.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Product Trial Service
|
||||
|
||||
- > There were a total of **::252::** product trial related service request fulfilled in this month.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- > CT Trial (External Customer SMAX Only Trial) - 12
|
||||
|
||||
|
||||
|
||||
- > Internal SMAX Premium Trial - 58
|
||||
|
||||
|
||||
|
||||
- > HCMX Trial - 1
|
||||
|
||||
|
||||
|
||||
- > ESM (SMAX/AMX/CMS) Trial - 8
|
||||
|
||||
|
||||
|
||||
- > **::ITOM Aviator Trial - 14::**
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Customer Cloud Service
|
||||
|
||||
## Customer Cloud Service
|
||||
|
||||
- > There were a total of **::84::** Customer Cloud Service Requests handled by ESM Cloud Service team in PCS
|
||||
- > **::Special thanks to Remi's ESM Cloud RnD team for their cooperation in handling the customer's Cloud Service Request with technical support and staff coverage!::**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Major Incident & RCA
|
||||
|
||||
> No major incident in Jan, 2025
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
## Customer Order & Fulfillment Highlights
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Monthly SLA
|
||||
|
||||
- > **::ESM SMAX has achieved all 100% SLA in Dec, 2024::**
|
||||
- > Data is available through **Dec, 2024**, with Jan, 2025 SLA data to be released around mid-Feb.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Cloud DevOps/SRE
|
||||
|
||||
## ITOM Operation Platform 25.1
|
||||
|
||||
- > We have successfully upgrade Operation Platform 24.4 to 25.1 on EU3/US24 farm.
|
||||
- > We're preparing the Operation Platform 25.2 cloud readiness work include to start support OpsB to use OP 25.2 in ITOM Cloud environment.
|
||||
- > We are now continuing to work on the OP D2 enablement automation and the relevant operation runbook.
|
||||
## ESM Cloud Application WAF Enablement
|
||||
|
||||
- > After some series of team efforts, it went through several processes of testing, modification, and deployment. We have now reached the criteria of Enable WAF denied mode with current WAF version on top of SMAX 24.4.1.
|
||||
We have enabled SMAX WAF in ‘**Denied Mode**’ on **::EU3::** and **::US7::** farm by end of Nov.
|
||||
- > In addition, we are gradually turning on ‘**Observation Mode**’ in other farms to get more WAF log information to help us determine the effectiveness of blockings.
|
||||
- > A new DevOps project was initiated to enhance WAF rules management & cloud deployment automation
|
||||
|
||||
## ESM GCP onboarding
|
||||
|
||||
- > Based on the business requirements, we started working with Cloud SA group and Product group on GCP onboarding for ESM. Currently, there are two main working threads which require product team support to certify ESM products deployment on GCP, and validation and experimentation for GCP OCF cloud architecture platform led by Cloud SA.
|
||||
|
||||
## Security & Compliance
|
||||
|
||||
- > At the request of Opentext GIS, the ESM Cloud Service Team has installed **Prisma Defender** on all ESM production farms in order to facilitate security scanning on the Cloud to provide more secure ESM SaaS services. - **::Done::**
|
||||
- > We recently launched a new project on how to handle various OS-based security issues discovered by Qualys Scan. In conjunction with the upcoming adopt CCOE AMI project, we intend to centrally replace and update the existing Cloud Application's EKS worker node OS to meet higher security standards. - **::In Progress::**
|
||||
|
||||
## Cloud BI Reporting
|
||||
|
||||
- > ITOM ESM Farm/Tenant Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3243d84335d863ef318a?experience=power-bi)
|
||||
- > ITOM Cloud Service Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/363a8aba-6746-4468-9d5c-54e0a463b708/ReportSectionc350f5d544676dc460b4?experience=power-bi)
|
||||
|
||||
##
|
||||
|
||||
---
|
||||
|
||||
190
Archived/Work/PCS Create New Customer Initial Setup Steps.md
Normal file
190
Archived/Work/PCS Create New Customer Initial Setup Steps.md
Normal file
@@ -0,0 +1,190 @@
|
||||
|
||||
|
||||
Entitlement
|
||||
|
||||
- Create new company
|
||||
- Customer Type: Customer
|
||||
- Add new domain name (remember to add same in PCS dev as well, for dev2prod)
|
||||
- Create new entitlement
|
||||
|
||||
|
||||
Add new person
|
||||
|
||||
- Create in BO and sync back to SMAX
|
||||
- Add company
|
||||
- Add employee type - external
|
||||
- Assign people to relevant entitlement
|
||||
- Assign role
|
||||
- Microfocus SaaS entitlement
|
||||
- Self-Service portal app
|
||||
- Self-Service portal user
|
||||
|
||||
|
||||
PCS Administration Training
|
||||
|
||||
|
||||
|
||||
[[PCS Create New Customer Initial Setup Steps]]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
KT Session #1
|
||||
|
||||
[https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EemsG7iwZ8xCsPm5QygCoZgBIWubxMNMhbCQU4AIhUoA3A](https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EemsG7iwZ8xCsPm5QygCoZgBIWubxMNMhbCQU4AIhUoA3A)
|
||||
|
||||
|
||||
|
||||
KT Session #2
|
||||
|
||||
[https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EXRCtXeBAXZPisy27-kVeuMBgZ_MdlyZgi-XmuXRIVseOg](https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EXRCtXeBAXZPisy27-kVeuMBgZ_MdlyZgi-XmuXRIVseOg)
|
||||
|
||||
|
||||
|
||||
**Data Model**
|
||||
|
||||
- Data domains
|
||||
- Company
|
||||
- Entitlement
|
||||
- ENTITY_LINK to Company
|
||||
- ENUM to Data domains
|
||||
- Person
|
||||
- ENTITY_LINK to Company
|
||||
- ENTITY_LINK to Entitlement (default)
|
||||
- MANY2MANY to Entitlement (full list)
|
||||
|
||||
|
||||
|
||||
**New Order/customer**
|
||||
|
||||
- Validate it is indeed a real customer (have an order ID, can find it in Control Tower)
|
||||
- Special cases for internal "customers": presales, operations, etc
|
||||
- Data domain record
|
||||
- Very likely need to use a new "slot", unless the customer already exists
|
||||
- Find the list, take the first entry not in use (with **ZZ-To be assigned** label)
|
||||
- **VERY IMPORTANT: Execute the task in both Dev and Prod tenant. Make sure the Name field (key) is the same in both, otherwise Dev2Prod will have issues**
|
||||
- The Prod tenant should be locked for customizations, you need to unlock it first. Don't forget to go back and lock it again after
|
||||
- In rare cases, the customer may exist already if there is an entitlement for another product, in this case skip this step
|
||||
- Company/Vendor record
|
||||
- Add a record
|
||||
- Use the official Display Name from the order/Control Tower
|
||||
- We started using the names in caps, as this is how Sparks had them, let's keep the rule.
|
||||
- For Code, use the first 3-4 letters of the name, or, if the company has an acronym, you can use it
|
||||
- Important: make sure you select **Customer** for the **Company type**.
|
||||
- In rare cases, the customer may exist already if there is an entitlement for another product, in this case skip this step
|
||||
- Entitlement record
|
||||
- Add a record
|
||||
- Display label
|
||||
- Is SaaS customer: start by short name of company, followed by product name and SaaS suffix, for example **Decathlon SMAX SaaS**
|
||||
- If it is a "Powered by" partner, add the "Power By" suffix for the name, example **Rigosis SMAX SaaS Powered by**
|
||||
- MF internal: Prefix with Micro Focus, no need to add SaaS suffix (it's implicit), for example **Micro Focus IT SMAX** or **Micro Focus Service Hub SMAX**.
|
||||
- Important to fill in the correct information for the mandatory fields: Entitlement type, Product, Primary Domain, Company. Business rules use this information extensively to filter down what is available in drop down lists, decide what logic to execute
|
||||
- For specific cases, like Achmea, if a NASE is assigned, fill in the info. Any new ticket linked to this entitlement gets automatically assigned to the person listed here
|
||||
- Fill in the CSM info, if available. The user listed will be automatically added as follower to all Support requests and a subset of Service Requests
|
||||
- SAID
|
||||
- Leave empty for regular SaaS customers
|
||||
- Fill in with the "Powered By" string for the Powered by partners
|
||||
|
||||
|
||||
|
||||
**New User**
|
||||
|
||||
- Non Micro Focus user (aka DB user)
|
||||
- Triggered when
|
||||
- A new customer is onboarded, and an initial list is received from the CSM
|
||||
- An existing user on an entitlement uses the **Add user to entitlement** offering
|
||||
- Check the user doesn’t already exist
|
||||
- If yes, go to the **Add user to an entitlement** section
|
||||
- Create new record from the Person grid
|
||||
- **VERY IMPORTANT:** Click the **Person type** checkbox, otherwise a contact gets created
|
||||
- If you forgot, you need access to BO to create the user (with same UPN) and force a sync from the Person grid
|
||||
- Upn: Use the email address (automatically populated with the email by default)
|
||||
- Employment type: External
|
||||
- Company: fill in with the relevant value
|
||||
- **IMPORTANT:** Do not populate the **Data domains** and **Primary domain** at this point
|
||||
- If the user is a "regular" customer user, you can fill in the **Default entitlement** value (for example, you may not want to do that if you add a partner)
|
||||
- Once saved, go back in and populate the **Data domains** and **Primary domain**
|
||||
- Entitlements M2M widget
|
||||
- Unlikely to have to use it, unless it is a partner added the first time as part of a customer project. In this case the entitlement doesn't go into the default position.
|
||||
- Micro Focus users (automatically added through SAML)
|
||||
- Periodically check if any new users got added. This can happen because someone is supposed to be added to an entitlement or is supposed to work tickets, but in many situations, users get hold of our URL and click on it for curiosity
|
||||
- R&D or Ops teams, people who logged in because they are supposed to work tickets
|
||||
- Check their reporting structure and make sure they are who they say they are.
|
||||
- Configure the following
|
||||
- Company: Micro Focus
|
||||
- Primary domain: Micro Focus
|
||||
- Data domains: Micro Focus
|
||||
- Employment type: blank
|
||||
- You can manually add them to the relevant functional group if you know which one. Alternatively, there is an offering that does that, can be called by the authorized audience (anyone with the "PCS Lead" role)
|
||||
- PS, pre-sales, specific functions
|
||||
- If instructed, configure profile
|
||||
- Company: Micro Focus
|
||||
- Primary domain: Based on the main role
|
||||
- Data domains: Above, plus potentially others, depending on the person responsibilities
|
||||
- Employment type: External
|
||||
- Example, if a PS consultant is asked to work on the MF IT project, the setup will be:
|
||||
- Default entitlements/Entitlements
|
||||
- With few exceptions (probably pre-sales), the majority of internal users needing to be added don't have a default entitlement. Add the relevant entitlement to the Entitlements M2M widget, if there is no default entitlement to be configured.
|
||||
- All other cases, not known why a user connected
|
||||
- Park the user in a "catch all" profile
|
||||
- Company: Micro Focus
|
||||
- Primary domain: Customer
|
||||
- Data domains: Customer
|
||||
- Employment type: External
|
||||
- If later on, the user is identified as belonging to an actual entitlement or is supposed to be an agent, apply the instructions described above
|
||||
- **IMPORTANT:** just because someone in Micro Focus asked for agent access, do not provide it, unless they are assigned to working tickets.
|
||||
- Concrete example on when to **NOT** add someone. The user says he/she is a Premier support person or even a CSM and needs to see the tickets for their customers. The answer is to give them the **Account Viewer** role to have the information available from the portal - no need for agent access!
|
||||
|
||||
**Modify existing user profile**
|
||||
|
||||
- A user already exists in PCS but needs to be added to an additional entitlement
|
||||
- Typically applies to users working for partners (with multiple customers) or internal Micro Focus people (PS, presales, etc)
|
||||
- Triggered when
|
||||
- A new customer is onboarded, and an initial list is received from the CSM
|
||||
- An existing user on an entitlement uses the **Add user to entitlement** offering
|
||||
- Data domains: append the customer Data domain (as defined in the Entitlement)
|
||||
- Entitlements: add the new Entitlement to the M2M widget
|
||||
- Exception
|
||||
- An internal user may already exist because they connected before and ended up "parked" in the "Customer" placeholder
|
||||
- Remove the "Customer" Data domains/Primary domains and follow the instructions listed in the "New user" section
|
||||
|
||||
**Remove user**
|
||||
|
||||
- Needs to be triggered from BO, which will convert the user into a contact
|
||||
- Once a contact, change the status from **Inactive** to **Terminated**
|
||||
- Clear the **Default entitlement** value and any record from the **Entitlements** section
|
||||
|
||||
**User Management offerings**
|
||||
|
||||
- **Add user to entitlement** offering
|
||||
- If the email address is not a @microfocus.com domain, follow the instructions for adding a DB user
|
||||
- **IMPORTANT:** If the email address doesn't appear to be the company email address, it is likely the user is a partner and may need to be treated specially, by first adding a new Company record for the partner. Alternatively, we can take the approach of considering this user as part of the customer company, and only model it as belonging to a new company when there is a need to add a second entitlement linked to the user. But, if we do it at a later date, it is important to identify all the users with this email domain and move them under the newly created Company record (see **New order/customer** section for the detailed procedure)
|
||||
- If the email address is a @microfocus.com domain, follow the instructions for configuring a SAML user.
|
||||
- It is possible the user doesn't already exist (never logged in). In this case, ask the requester to notify the user to first login (use the Discussions tab)
|
||||
- Once the user record got created/updated, move the **Add user** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
|
||||
- Exceptionally, if the request is not relevant (the user already exists, the offering incorrectly used, or other reasons), process the request as below:
|
||||
- Edit the Task plan by deleting the **Closure** task, so the request doesn't automatically close when **Add user** task gets actioned
|
||||
- Move the **Add user** task to **Canceled**
|
||||
- Manually add a **Solution** (explain why the request is not relevant) and Completion code (usually **Out of scope**)
|
||||
- **Remove user from entitlement** offering
|
||||
- Tip: From the **User** user option, navigate to the Person record.
|
||||
- If the user is part of multiple entitlements (like a partner, PS), just remove the relevant **Entitlement** reference from the Person record
|
||||
- If the user is part of one entitlement (usually for a regular customer user), follow the procedure described in the **Remove user** section
|
||||
- Once the relevant action above is completed, move the **Remove user** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
|
||||
- **Reset user password** offering
|
||||
- Tip: From the **User** user option, navigate to the Person record.
|
||||
- Click on the **Reset password** button. Wait for the confirmation message at the top of the screen that the email notification got sent
|
||||
- Once the relevant action above is completed, move the **Reset password** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
|
||||
|
||||
**Process**
|
||||
|
||||
- Monitor the "admin" Request queue
|
||||
- Go to the Active Admin Cases" view. Make sure you don't make any changes to the view definition. If you like to use a different view, create a private one for yourself
|
||||
- Add more people to the Admin group
|
||||
- Only **Add user to entitlement**, **Remove user from entitlement, Reset user password** require intervention, the others have automated fulfillment (may require approval)
|
||||
- See the **User Management offerings** section for instructions for processing each offering
|
||||
- Monitor the Person grid for newly created SAML users
|
||||
|
||||
- Use the **Users Pending Processing** view. Make sure you don't make any changes to the view definition. If you like to use a different view, create a private one for yourself. Also, don't modify the other public views
|
||||
- Follow the instructions in the **New User** section
|
||||
13
Archived/Work/People Manager/FY24 Goals - Shen Wei.md
Normal file
13
Archived/Work/People Manager/FY24 Goals - Shen Wei.md
Normal file
@@ -0,0 +1,13 @@
|
||||
|
||||
|
||||
I'm a senior manager responsible for SaaS operations and maintenance for cloud products in a global enterprise software company. I manage a global cloud operations team of 20+ people. The team is a global team covering different time zones. Our team is also responsible for interfacing with the product RnD team to understand requirements and communicate with them. I am designing myself and my team's goals from the below perspective: Leadership Activities, service delivery quality, Process Standardization, Operational Excellence, and Satisfy customers. could you please prepare a draft for me with efforts detail, and measurable KPIs for the above areas.
|
||||
|
||||
|
||||
|
||||
| | | | | |
|
||||
|---|---|---|---|---|
|
||||
|**Leadership Activities**|• Conduct regular team meetings and one-on-one sessions to provide guidance, support, and alignment. <br>• <br>Act as a liaison between the cloud service team and ITOM organization, ensuring effective communication and collaboration. <br>• <br>Participate in the hiring process for new team members, ensuring the selection of qualified candidates who align with the team's goals and culture. <br>• <br>Foster a positive work environment conducive to productivity, innovation, and growth.|• Executive Dashboard: Implement an executive monthly report to track and communicate Cloud Service team key metrics and performance indicators. <br>• <br>100% Participation in Team meetings <br>• <br>100% Compliance in accordance with local legislation|||
|
||||
|**Service Delivery Quality**|• Drive efficiencies and optimizations to deliver services in the most economical manner. <br>• Manage resource allocations effectively to meet business demands and maintain service levels. <br>• Continue to optimize cost structures across cloud and corporate services while maintaining service quality.|• On-time Project Completion: 90% <br>• <br>Ensure 100% compliance with local legislation and industry regulations relevant to cloud operations <br>• <br>|||
|
||||
|**Process Standardization**|• Focus on standardization and modernization of processes, adopting best practices and industry standards such as ITIL. <br>• <br>Support initiatives to consolidate/migrate customers to cloud platforms, with a focus on shared environments where feasible. <br>• <br>Minimize process gaps and ensure zero deviations from defined processes. <br>• <br>Conduct quarterly reviews of documentation to ensure accuracy, relevance, and completeness. <br>• <br>|• Zero process gaps <br>• <br>Quarterly review of process documentation <br> <br>|||
|
||||
|**Operational Excellence**|• Aim for 90% of projects to be completed on time, ensuring timely delivery of services and solutions. <br>• <br>Continuously identify and implement improvements to existing processes and deliverables, enhancing operational efficiency and effectiveness. <br>• <br>Actively participate in the adoption of new features, technologies, and cloud solutions to improve operational capabilities. <br>• <br>Document and analyze lessons learned from project executions, incorporating feedback to drive continuous improvement. <br>• <br>| <br>• <br>60% of Project Completion within 3 months <br>• <br>100% Security Compliance <br>• <br>Expense Reduction Targets: Meet defined FY targets communicated by FinOps <br>• <br>Adoption of New Technologies: Regularly adopt new features/technologies to enhance operational capabilities <br> <br> <br> <br>|||
|
||||
|**Satisfy Customers**|• Be an advocate for customer satisfaction, focusing on delivering value and exceeding customer expectations in every project and interaction. <br>• <br>Collaborate with cross-functional teams and stakeholders to support business goals and initiatives, such as migrations and security compliance efforts. <br>• <br>Ensure documentation of any planned/unplanned change predefined timeframes to maintain transparency and accountability. <br>• <br>Participate in the onboarding of new customers to the cloud business, ensuring smooth transitions and successful deployments. <br>• <br>|• customer escalations due to cloud service errors <3|||
|
||||
@@ -0,0 +1,56 @@
|
||||
## **1. Objective**
|
||||
|
||||
Ensure business continuity and data protection by implementing an effective DR strategy for the customer, leveraging EFS replication, RDS PITR, and different failover methods.
|
||||
|
||||
## **2. DR Scenarios & Recovery Options**
|
||||
|
||||
| | **Method** | **RDS Recovery** | **EFS Recovery** | **Failover Steps** | **Estimated Downtime (RTO)** | **RPO** | **Cost Impact** |
|
||||
| ------------------ | ------------------------------- | ---------------- | ---------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------- | ------- | --------------- |
|
||||
| DR Basic Service | **Cold Backup-Restore** | Snapshot (6h) | Backup Restore (6h) | 1. Restore RDS from snapshot (6h) <br>2. Restore EFS from snapshot (6h) <br>3. Recover EKS (4h) | **24 hours** | 4 hours | **Base Cost** |
|
||||
| DR Premium Service | **EFS Replica Only (RDS PITR)** | PITR (6h) | EFS Replica + Restore (0.2h) | 1. RDS recovery from PITR (6h) <br>2. Stop EFS sync (0.2h) <br>3. Full EKS recovery | **6 hours** | 15 min | **+30% Cost** |
|
||||
|
||||
---
|
||||
|
||||
## **3. Downtime Estimation & RTO Considerations**
|
||||
|
||||
- **EFS Replica Only (RDS PITR)**
|
||||
- **6-hour RTO**, significantly reducing downtime compared to cold restore.
|
||||
- **15-minute RPO** ensures minimal data loss.
|
||||
|
||||
---
|
||||
|
||||
## **4. DR Execution Plan**
|
||||
|
||||
### **4.1 Pre-DR Readiness Checks**
|
||||
|
||||
- Ensure **EFS replication** is active and functioning correctly.
|
||||
- Verify **RDS PITR backups** and retention policies.
|
||||
- Pre-configure **EKS deployment templates(Velero)** for rapid recovery.
|
||||
|
||||
### **4.2 Disaster Recovery Trigger**
|
||||
|
||||
- DR activation is **initiated upon a major failure event** in the primary environment.
|
||||
- Decision criteria include **regional failure, prolonged service outage, or severe data corruption**.
|
||||
|
||||
### **4.3 Execution Steps**
|
||||
|
||||
#### **EFS Replica Only (RDS PITR)**
|
||||
|
||||
1. **Recover RDS** from PITR (**6 hours**).
|
||||
2. **Stop EFS replication sync** (**0.2 hours**).
|
||||
3. **Recover EKS cluster** and validate application (**immediate**).
|
||||
|
||||
### **4.4 Post-Failover Validation**
|
||||
|
||||
- Confirm **data consistency** between DR and primary environments.
|
||||
- Validate **application services and connectivity**.
|
||||
- Communicate DR activation and service restoration to stakeholders.
|
||||
|
||||
---
|
||||
|
||||
## **5. DR Testing & Cost Estimation**
|
||||
|
||||
- **Annual DR validation test** is required, adding an **estimated 2 months of AWS costs**.
|
||||
- **EFS Replica Only (RDS PITR):**
|
||||
- **$20.8K/month**
|
||||
|
||||
Reference in New Issue
Block a user