CMDB Best Practice - Dev and QA servers

[ron_w_reinmille]

We are implementing a CMDB for the first time.
The question is what other companies have done with non-production equipment when creating the CMDB.
Is it best practice to include DEV and QA servers in the CMDB or only Production servers?

Did you include non-prod equipment in your CMDB?

[Pritam6]

You could import all servers / CI's and simply use the status choicelists to identify which are in production, development or QA etc. The cmdb_ci table has both "install_status" and "operational_status" which can be used for just this requirement.

[Jeff Mayrand1]

Ron,

I guess why wouldn't you?

There all assets your company paid for right?

Assets are the key to understanding a lot of this. Asset records are essentially related to CI's. You did buy or lease the stuff right so why not track it all the same...

Assets create model and category relationships to CMDB CI types. So Model X is a Server, Model Y is a Router etc etc...

I would alter my SLA's based on the type of deployment I was doing. For instance.. Low for Dev, High for Prod...

This is all very doable in Service-Now....

If you would like to talk more let me know!

Jeff Mayrand

[pchan]

discovery is impartial and as we do not have a naming convention that differentiates various environments, nor or our non-prod environments necessarilly segragated from Production, we discovery everything.

Once they are disocvered, we insert the record with a "blank" enviroment status, that we use to report on to ensure that the repsective infrastructure team sets to the correct environment.

That being said... there are an environments and environments to CI table that exist... which requires development from OOTB that can be used to maintain a view of your various environments.

of coruse a proces has to be established for taxonomy for the various systems, and subsiquently the environments themselves, but I belive a BSM view can then be generated or filterd by this table...