How to improve your IT. Part 10 – What Infrastructure risks are you carrying?

IT Infrastructure

IT Infrastructure

A series of posts on how to improve the performance of your IT

There is a saying that CIOs lose their jobs because of bad Infrastructure Managers. I add to this that the Infrastructure Managers are bad because they fail to understand the basics and that the devil is in the detail. I have managed many Infrastructure departments small and large, and whilst I can say that they are indeed a challenge, if you put the basics in place, they are easy to manage. IT Infrastructure is complex and critical to all IT operations, consisting mainly of Service Delivery, Installations, Maintenance, SOEs, Server and Desktop refresh strategies and Networks and Communications. Pay attention to the basic needs of these and things look after themselves.

The Best practice Standard is 99.9% Server and Network availability, a hardware fleet upgrade strategy driven by applications capacity needs, response time objectives, systems capacity management requirements, hardware failure rates and fleet ageing, A systems software upgrade strategy and desktop refresh strategy is also required.

Ask your Infrastructure manager to conduct this Performance Assessment, think of it as a health check. It is the assessment I have always conducted in my early days as a CIO or Infrastructure Manager as it quickly lets me understand the degree of risk I am carrying. Try it out for yourself.

Performance Assessment

1.    Servers

The results of this Server hardware audit are also used to check on the accuracy and completeness of the IT Budget and provide input into the next IT Strategy (Risk analysis).

Actions

  1. Record on a spreadsheet all the following. (By unit or group by type. Show total numbers).

  2. List all systems servers.

  3. List all web servers.

  4. List all applications servers.

  5. List all e-mail servers.

  6. List all back-up servers.

  7. List all other server types in use.

  8. List all server management software in use.

  9. List all maintenance/support agreements in place.

Rate all of the above as either (H, M, L) risk based on probability of failure.

Does the budget reflect all software licensing and maintenance costs for the above items?

Questions to ask

  1. What server recovery processes exist?

  2. What is the average production server’s failure rate? (unplanned shutdown).

  3. What is the average production applications server’s failure rate?  (unusable to users).

  4. How is server resource utilisation managed? (CPU, memory and disk-space (used and free))

  5. Is there a formal process for server physical and logical installation?

  6. Is there a formal manual or automated process for server recovery?

  7. When was the last test of restoration from a back-up completed?

  8. How are back-ups confirmed as complete?

  9. How often are full image restores used?

  10. Is the reinstallation of systems and applications software manual or automated?

  11. Is resource utilisation trending in place for critical systems?

  12. Are all servers included in the depreciation schedule?

  13. Are all servers covered by a maintenance agreement?

  14. Is critical infrastructure covered by high priority maintenance agreements?

  15. Has the infrastructure disaster recovery plan been tested?

  16. Is there a server refresh strategy in place?

2.    Other hardware

Actions

  1. Record on a spreadsheet all the following.

  2. List all desktops (by unit or group by type).

  3. List all routers (by unit or group by type).

  4. List all switches (by unit or group by type).

Based on failure rates or equipment age, rate all the above items as either (H, M, L) risk.

Questions to ask

  1. How effective are desktop service delivery and repair procedures?

  2. How quickly can a router or a switch be replaced?

  3. What are the router and switch failure rates?

  4. Is critical infrastructure covered by high priority maintenance agreements?

  5. Are patches up to date?

  6. Is there a desktop refresh strategy in place?

3.    DBMS

Questions to ask

  1. How many staff are involved with database administration?

  2. Are there user account and share management procedures in place?

  3. Administration services for active RDBMS in use?

  4. What daily housekeeping procedures are in use?

  5. How is capacity management, managed?

  6. How is performance analysis/tuning conducted?

  7. Does a systems software upgrade strategy exist?

  8. Who owns and manages software license management?

  9. What vendor support arrangements are in place?

4.    Naming standards

Often hardware does not have a formal naming standard, instead, names of planets or mountains or similar are used which is unprofessional and can lead to a variety of problems. The best practice standard is the use of a server, router and switch naming standard consisting of ‘type’ (for servers -web, system, print, production, application), ‘location code’ and ‘incremental number.’ A good naming standard makes it easy to deploy, identify and filter through hardware farms, especially when you may have hundreds or thousands of units deployed. There are important advantages to adopting a formal naming standard, one that scales as the population grows.

  • It speaks to the professionalism of the IT department.

  • New staff can quickly learn to identify hardware types.

  • Mistakes caused by selecting the wrong piece of hardware are far less likely.

  • Disaster management benefits when staff and third parties need to identify and prioritise the hardware recovery sequence.

5.    Tools and utilities

The best practice standard is that all software tools and utilities are vendor supported with an OS, systems software and applications upgrade path. Tools and utilities have a nasty habit of multiplying, especially when they are freely downloadable from the Web. Most technical and engineering staff have their own set of utilities for fixing problems as against a set of approved vendors supported products. The Best practice IT Standard is a vendor-supported, shared set of utilities in order to have confidence that common and consistent outcomes will be produced.

Actions

  1. Record on a spreadsheet all the following.

  2. List all software tools and utilities in use.

  3. List all scripts in use.

  4. List all SOE’s in use.

Rate all the above items as either (H, M, L) risk based on being vendor or non-vendor supported.

Questions to ask

  1. What tools/utility redundancies exist?

  2. What script redundancies exist?

  3. What tools, utilities and scripts can be removed?

  4. Should there be a policy of not downloading products from the Web?

  5. Is software distribution fully automated?

  6. Are production and development SOEs isolated?

  7. Are their redundant SOEs, what can be removed?

  8. Build an Infrastructure Scope of works

  9. Collate all of the Responses gathered into a task list.

  10. Prepare a risk analysis for all hardware and software and DBMS.

  11. Update asset registers.

  12. Update budget depreciation amounts and other asset-related costs.

  13. Review production servers with high failure rates. (unplanned outages).

  14. Review production applications servers with high failure rates.  (unusable to users).

  15. Establish server resource utilisation management. (CPU, memory and disk-space (used and free))

  16. Create a process for server recovery by type.

  17. Create a hardware fleet upgrade strategy.

  18. Create a systems software upgrade strategy.

  19. Create a desktop refresh strategy.

  20. Put in place database monitoring.

  21. Determine further works required and scope out.

  22. Breakdown the scope of works to task level, ready for loading into the change management project schedule.

  23. Risk mitigation actions from risk assessment.

  24. Fully automate software distribution.

  25. Remove redundant, tools, utilities and scripts.

  26. Replace non-vendor supported products with vendor-supported products.

  27. Train staff on supported products.

  28. Standardise engineering toolsets.

  29. Investigate standardising on a common naming convention for servers, routers, switches and migrate to over the next six months.

  30. Determine further works required and scope out.

  31. Breakdown the scope of works to task level, ready for loading into the change management project schedule.

  32. Determine further works required and scope out.

 End