If you were talking to someone whose organization is considering BMC TrueSight Server Automation, what would you say?
How would you rate it and why? Any other tips or advice?
This evaluation is a team effort. There are three of us involved in the project, and we're looking forward to seeing how it goes. We have a wishlist with our priorities, and we'll see if it satisfies what we want. I would rate this solution an eight out of ten.
I would rate this solution a nine out of ten.
Take a look at your scanning tools to see if you have adapters and APIs for TrueSight Server Automation or whether you would need to develop something bespoke. Do your due diligence around that. Have an idea of the sort of use cases you want to use with the tool. Vulnerability management is just one aspect. Do you want to use the solution for things like server build, server provisioning, and application provisioning? Who will be using the solution going forward? What services will be wrapped around the tool? Who will need the right level of permissions to do certain things? These are really important to know because Server Automation, whilst it's a very powerful tool, in the wrong hands with the wrong level of access, it could potentially become very problematic. It could be quite dangerous in the wrong hands. It's understanding who needs to have access to it and their level of permission. That needs to be governed and controlled!
My advice would be: Don't allow yourselves to become the CMDB. Don't be your database of truth. Make sure that that data is properly managed in the appropriate tool. TrueSight Server Automation is not a CMDB. It is a resource that can provide that relationship data, but at the end of the day, that's not the business you want to be in. Focus on automation, and let the tool do what it does best. The other piece of advice which I feel is just as important is that TrueSight Server Automation is not a monitoring tool. Don't allow someone to create automation and run a scheduled job every 15 minutes just because it can perform that function. That's not the right use of the tool. Use the right tools for the job. You can use your monitoring tool to find what you're looking for and then trigger automation off of that, but use the right tool for the right job. The biggest lesson I've learned from using this solution is that having all of your eggs in one basket is good, but when things start to go south it can really be very impactful. Make sure, if you have a solution that's as encompassing as this, that you have a very good DR strategy. So if something does go wrong you can very quickly recover from it; because it reaches out to too much. Now, after some issues, we have a DR that's in another data center. It's about half the size of our standard environment so it can cover the bulk of what we do from day-to-day. We have too many business-critical processes that are tied to the automation and scheduled content. If we do have an actual outage, and we've had that before, it does impact our business. So have a good DR strategy. I don't think anything's perfect, so I would rate this solution at eight out of ten. It's very powerful. It's very flexible. There are some components of it that need to be modernized. Their REST API calls are still very immature. They have very limited integrations as I was mentioning earlier. The agents themselves are listening-agents only, so there's no active component. There's no self-healing. If an agent goes down, I don't know until I go check the agent to see if it's down. There's some modernization that I'd like to see around that. I know that's on the roadmap. I don't know where they're at in the development process, but I know it's on the roadmap, and I'm looking forward to those capabilities. If they get all of the modernization of the agents up, then I would actually increase it to a nine. But again, nothing's perfect, so I would never give anything a ten.