Solution Maintenance Process
System Maintenance: Backup Process
CRScube's database is backed up and stored in accordance with SOP 153 Data Backup and Recovery.
The backup process is described below.
.png?inst-v=42880345-fa3f-48c2-b23e-db23cdc805c1)
STEP 1 The Main Database synchronizes real-time data to the Standby DB server. (*Real-time sync, primary backup)
STEP 2 The Main Database performs a daily full backup to the Backup DB.
STEP 3 a. The daily full backup is generated with RDS Instance and then deactivated. (*Disaster recovery, secondary backup)
b. The backup data transmitted to the Backup DB is copied and stored in S3. (*Tertiary backup)
STEP 4 The daily full backup data is encrypted, retained for a specified period, and automatically deleted.
System Maintenance: System Monitoring Process
A monitoring system with tools such as CloudWatch and Zabbix is established to detect and resolve potential errors in the system in advance.
Errors identified through system monitoring or issues reported from external sources go through a root cause analysis and resolved in accordance with the following SOPs.
CASE 1 If the issue is related to a configuration change in the S/W or cloud computing system → SOP 155 Change and Configuration Management
CASE 2 If system downtime is anticipated due to the error → SOP 152 System Maintenance 3.3. Preventive Management
CASE 3 If the service site is unavailable → SOP 156 Business Continuity Plan
System Maintenance: Business Continuity Plan
CRScube has established a disaster recovery strategy which is maintained according to SOP 156 Business Continuity Plan.
cubeSolutions configured in AWS maintain a redundant server in a separate Availability Zone of the same AWS Region, and a disaster recovery server in a different AWS Region.
The recovery time objectives and required infrastructure for disaster situations are as follows. CRScube conducts an annual disaster recovery mock exercise, in which all employees participate.
Category | Description | Potential Causes | Recovery Time Objectives | Required Infrastructure |
Major Disaster |
| Earthquake, major fire, explosion, major flood, war | 8 to 30 days | Disaster Recovery Center |
Partial Disaster |
| Earthquake, fire, building collapse, riot | 24 hours to 7 days | Server redundancy |
Critical Error |
| Communication disruption, blackout, riot, small-scale fire, power outage, communication service failure. | Immediately to within 24 hours | Server redundancy |
Error |
| Cloud provider's hardware failure, operational mistake, software error | Immediately to within 24 hours | Not applicable |
Change Control: Change Control Process
In cubeSolutions, change details and test cases related to the changes are documented and managed according to SOP 155 Change and Configuration Management.
Solution updates are typically once every three months but the timeframe may vary depending on the solution.
The workflow of change control is as follows.
① Change Request
All internal or external improvements and error fixes are reported to the PM. If any modifications are required, the PM creates a change request (PM Issue).
When there is a change request, stakeholders such as the PM, Development Team Manager, Developer in Charge and QA participate in a CCB (Change Control Board) to conduct an analysis of the necessary change.
② Change Task
The Development Team Manager assigns a developer to the change request created by the PM. Afterwards, a development issue is created and development begins.
Every development issue must be linked to a change request issue created by the PM. Changes that do not arise from a change request cannot proceed.
③ Testing
The Developer in Charge and QA perform testing after creating test cases appropriate for the change request.
The purpose of testing is as follows.
Confirming that development aligns with the PM's request.
Confirming that there are no side-effects due to the development.
Confirming that exception handling has been appropriately applied.
Change Control: Change Notification
Modifications made through Change Control are shared with users in the following steps.
① Release Note Draft
Modifications due to error fixes and improvements are documented in the Release Note, which includes both the changes implemented in regular releases and irregular releases.
② Release Note Distribution
The completed Release Note is announced on the eManual site one week prior to the release.
High Level Validation Summary
Validation Plan
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Acronyms and Definition
1.4. System description
1.5. Assumptions and Restrictions
2. Validation Rationale
2.1. System Classification
2.2. Risk Management
3. Validation Strategy
3.1. Validation Approach
3.2. Validation Activities
3.3. Criteria for cubeSolution Deployment
3.4. Validation Documents
4. Reference
Validation Report
1. Introduction
1.1. Purpose
1.2. Scope
2. General Description
2.1. Project Context
2.2. General Abilities
3. Evaluation of Results
3.1. Validation Activity Results
3.1.1. Unit Test Results
3.1.2. Integration Test Results
3.1.3. Installation Qualification
3.1.4. Operational Qualification
3.1.5. Performance Qualification
3.1.6. Validation Documents
3.2. Acceptance Criteria/Evaluation of results