Many products make statements such as “this is the only supported way to” or “the following is unsupported”, but people often wonder what does unsupported really mean?
In my experience, unsupported usually means either:
- The following has not been tested or has not been tested well – In this particular case, while it may be unsupported it may work. In short, your mileage may vary and this is not recommended for a production environment as it could have unexpected, and potentially catastrophic consequences.
- The following has known and potentially catastrophic issues – In this case, known unexpected and potential serious consequences could be seen. In short, this is really not recommended for a production environment until it has been thoroughly tested.
In terms of support, the meaning of unsupported is very clear: if it is unsupported then vendor support will likely not assist unless you can duplicate the issue in a supported way. In terms of operating a service, unsupported means difficulty in upholding a SLA, potential difficulty ensuring security or compliance, and the potential of permanent data loss.
One thing I would love to see is two different categories of unsupported. One where it is unsupported, but tested (by anyone – not necessarily the vendor) and believed to be safe and one where it is unsupported and known to be problematic with examples of the problematic behavior. What would also be nice is if the vendor stated if it is unsupported because of #1 and/or #2 (if #2 do not need to explicitly state known issues though that would be nice). From a vendor perspective, in its simplest form I would like to see “this is unsupported” (#1) or “this is unsupported and has known issues” (#2).
Why would I like to see this? Because #1 is true even for things that are supported. Even if something is extensively tested it likely has bugs and some of these bugs could be catastrophic. Sure, in theory extensive testing should reduce the likelihood of experiencing a catastrophic issue, but there is no guarantee and test plans are typically not public knowledge. In addition, while I understand it can be impossible to extensively test every combination of options on every supported platform given every potential workload, I think it would be helpful to be open about why something is unsupported or why only a certain thing is supported. Given this does not typically happen today, I would advise avoiding things that are unsupported unless you have extensively tested them to ensure it works as needed and have ways to mitigate any risk that may get introduced. You have been warned 🙂
© 2013, Steve Flanders. All rights reserved.
