The process of designing, implementing and managing a Linux infrastructure starts with the requirements. The aim of the requirements is to define what is needed to meet the needs of the business. Over time, the requirements may change:
- The needs of the business may change. Businesses are not static, and a new product line, business growth or contraction, or a new market may dictate changes to the requirements.
- The existing requirements may not be correct. In the light of experience, it may become clear that too much (or not enough) focus has been put on one area, or maybe some requirements were omitted altogether through oversight.
- Technology changes. That shouldn’t affect requirements – the technology is used to implement the requirements, not define them – but sometimes new technology causes us to think through the requirements in a different way.
None of the above is unexpected. Businesses do evolve, and the first cut of defining requirements of an IT infrastructure is unlikely to be perfect. For these reasons, the requirements should be reviewed from time to time.
There’s one more reason to review the requirements, and that is to ascertain whether they have been fully implemented. It’s not at all uncommon for the actual infrastructure implementation to vary slightly from the requirements, but such variance needs to be corrected, either in the implementation or, if the requirements were incorrect, in the Requirements Document.
Testing fitness for purpose
As well as evaluating how valid the requirements are and how well the solution meets them, we also need to test failure modes.
Test data restore
Testing a restore of data is by far the easiest test to undertake, and even in its simplest form it will either give some confidence that backup processes work or reveal some problems. Here’s a minimal test that is easy to run. This isn’t a rugged, comprehensive test of backups, but it is a good starting point. It’s a five-day plan, and it will take less than two minutes a day.
Test failure of server
Testing how a failed server is recovered may be more invasive than a simple data restore, and thus the impact upon the business needs to be taken into consideration. The actual testing mechanism will depend upon the architecture of your infrastructure.
Play out weekend disaster
Testing a full Disaster Recovery plan is a major undertaking. It will be time consuming and will incur significant expense. For some organisations, such as airlines and banks, it will be necessary, but for many organisations it may not be viable to test a full disaster recovery scenario.
As a minimum, you should be able to demonstrate a full and complete recovery of your business-critical data without any access – physical or network – to your key place of business.
Need help evaluating your Linux solution?
Get in touch or book a Strategy Session.
Photo by rawpixel