With external advisors, a rough estimate of the requirements was gathered and a tender process was put in place. The tender asked for a definite disk size and performance. During the discussions the requirements were reduced due to cost considerations, so the final system was on the low estimate of the performance requirements.
When the system was finally deployed, many problems surfaced: lack of disk performance, errors in the application, bugs in the underlying database and many more. In time, with a lot of effort, the project was deployed successfully.
• Knowing you made a mistake is because the system is used. Otherwise there would be no problems. ?
• What can be improved for next time? The next time use the knowledge gathered. For DB scenarios, the total IOPS is important, but the distribution is crucial. The requirements of the index and the content are completely different.
• What information was lacking? The original information was the best at hand but now the relevant information should be specified.
• It will happen again, in different scenarios. The only way of not making mistakes is by not making at all.
By knowing you will make mistakes, the road is paved to realizing that you have to admit your errors to yourself. By keeping on the learning curve and not repeating the errors, one can increase the possibility of success. So now in my company we have a more established guide for dimensioning storage systems.
If you read this far, you should follow me on twitter here.