This kind of thinking is contingency planning. This concept can be further divided into two parts in the field of ICT, continuity planning and disaster recovery planning. How to design an effective and user-friendly disaster recovery plan (DRP) tool that administrators can use every time they roll out new systems and services. The word "tool" mentioned in the above research objective makes it clear that this thesis focuses on a concrete product for disaster recovery plans.
So, although the purpose of this study is to create a basic Disaster Recovery Planning tool for the Finnish Meteorological Institute, it can be used in similarly complex environments and with smaller data center environments.
2 Method and Material
Literature Review
The main concepts of disaster recovery are carefully examined and the differences and similarities between continuity planning and disaster recovery planning are explained. There are many existing best practices and Finnish national regulations that provide guidance on what should be included in a disaster recovery plan.
Administrative Questionnaire
Planning Disaster Recovery Tool for Administrators
Implementation
Evaluation
3 Business Continuity
As can be seen in the picture above, the base of the pyramid consists of the main infrastructure, although another level can be drawn where facilities and electricity will be depicted. The top of the pyramid consists of business continuity, policies and strategies and risk management. This leads to one of the most important aspects of the continuity planning being service and maintenance contracts.
It is quite likely that all or at least some of the computing and storage capacity has been purchased from the national or multinational companies. SLAs usually define the availability of the service, which can be expressed as a percentage, traditionally with so-called "nines". Both Wallace - Webber and Harris agree that the mirrored or redundant site is an exact replica of the main site and is the fastest way to get business up and running.
Whether the company or organization needs one of these, or any of these, depends on the business area and the criticality of the services they work with. Typically, this type of technology disaster includes device breakage, theft or encryption of company data, data center sabotage, or a rapidly spreading virus. Smaller disasters, such as building fires, may render part of the business premises unusable, but the company may have plans for how to continue doing business elsewhere during the repair.
Most companies or organizations rely on their ICT services that they need themselves or provide to customers. Backing up the data means that there is another source of the data stored in some form, in case the original data is damaged or destroyed due to an incident. If the MTD value of the service is short, service continuity and Disaster Recovery Plan should be the top priority.
This may mean having a duplicated or clustered environment for the service, or having spare components or devices ready in case of device failure or failure.
4 Administrator Questionnaire
The topics were chosen in such a way that they give a good overview of how the administrators think the disaster recovery tool should be implemented and what would be the main services and devices they think should be the first to cover. The second question, "Which services or equipment should be of primary concern when creating a disaster recovery plan?". The answers to this question will help to understand how the process of creating a Disaster Recovery Plan should be implemented in a way that is effective for administrators in their daily work.
While disaster recovery planning is something the administrators do on a daily basis at some level, creating a particular process should be made a simple and efficient task, rather than a burden. Question four: “What kind of tool should be implemented to create the Disaster Recovery Plan so that it is easy to use. It can provide good advice on how to implement the tool, as well as out-of-the-box suggestions.
More than half of the responses provided suggested that critical services and applications should be the primary concern when implementing disaster recovery plans. Two responses stated that customer service and government agency services should be the primary concern. Almost all answers to question four indicated that the tool should be a fillable form with fixed characteristics or topics that should be answered.
All administrators seemed to think that creating a disaster recovery plan was important and that it should be done in a coordinated way, perhaps with some tool. When creating a DRP, the primary concern should be critical services, whether individual devices or more complex services.
5 Planning Disaster Recovery Tool for Administrators
The Jira server authenticates the user with the Windows Active Directory (AD) authentication server using a Lightweight Directory Access Protocol (LDAP). As the DRP was made to be suitable for both devices and services, it is not a requirement to fill in every field on the individual DRP page. While it is mandatory to fill in some of the fields, such as the name of the device or service or the criticality level, others were left to the administrators themselves to decide whether they could be left blank.
Name of the System or Service
Criticality Grading
The features or topics included in the tool are discussed in this subchapter. Criticality degree 2 – High Priority: The system or service is critical or of high priority to the weather production system and is necessary for the services to the customers. Criticality grade 3 – Normal Priority: The system or service is required for the customer products, but interruption in the services does not cause damage to the customers.
Criticality grade 4 – Low priority: The system or service is a support service for other services or is a system or service in a testing phase.
Backups of the System or Service
Configuration Files for the System or Service
Password Policy for the System or Service
Most Important Dependencies of the System or Service
Main Responsible Person
Customer or Maintenance Support Contact
Documentation for the System or Service
Backup Systems or Spare Parts for the System or Service
Vital Data Source Dependencies
Other Comments
It is very likely that systems and services exist that were not known at the time of writing. Or if there is an outdated system listed in the DRP plans that doesn't need repair after it breaks, it can be written here.
Attach File
Plan Approved by
Plan Revised or Updated (date)
6 Implementing the Tool
Project Manager is a role that can be used in project settings, e.g. The revised or updated plan field was selected as a date picker field, which makes it more convenient for the user to fill in, since the date can be selected from a list in addition to typing it. With a Jira mail handler and the "Attempt to match sender or deliverer email address user session" setting selected, the reporter is always the person filling out the form if he/she is logged into Jira.
As can be seen, there is no field for "System or service name". Also some fields were left blank like description and priority fields which are default fields but can be left unchecked as they are not used in this form. The final DRP form that administrators can complete can be seen in the figures below.
If necessary, the restrictions can be made even stricter, down to the personal level so that only the designated administrators can see certain plans. These restrictions and visibility settings can be changed by the project administrator or Jira administrator if needed. Jira itself does a log files that record all the changes to the permissions, so these changes leave a mark, and can be audited later if necessary.
The database containing all the data is backed up and can be restored if necessary. With the Jira export options, these DRP plans can be exported in a printable text format and stored in a vault just as a precaution in case the Jira service itself is down and the plans stored in the data cannot be accessed.
7 Testing the Tool with Administrators
The test group managed to complete almost all fields without any difficulty. All features or fields were deemed necessary, although in some cases not all fields are required to be completed. system or service”.
In some cases, all systems and services are not located in a data center that has reserved power or even has UPS systems for short power outages. This field would make it easier to understand how system resilience is achieved and which systems and services are included in the whole. In the case of a single data center, this can also point to the location of the machine in the data center.
It would be nice to have an automatic date picker instead of having to fill in the "Plan Revised or Updated" field. In the proposed new fields such as location and reserve power, there could only be a few choices. This would make the task even faster and omit the possible spelling mistakes in the free text boxes.
As a summary of the testing, the administrators felt that this tool is simple enough to use and has all the necessary fields. The improvements we discussed may be included in the next version of this tool.
8 Conclusions
Based on the advice that administrators gave about the test phase, it can be said that the outcome of this master's thesis was successful. The Atlassian Jira software was chosen in this case because it was already in use, lowering the threshold to start populating the DRPs. The theory and discussion of the features needed will be a good starting point for creating DRPs in any environment.
