- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 02-03-2021 01:25 PM
All,
Well as promised here is our latest and greatest framework for a CI Lifecycle that we hope many can find value with it.
For those that have been around a bit, you might remember how
Well, that lab has gotten a bit dusty in its old age and we thought it a good time to give it a good once over and hopefully improve it to make it more relevant in today's CMDBs.
So I and my very good friend and Co-Worker
Attached is a zip file that contains three parts.
- A readme file that tells you how I switched everything off in the update set so you have to go through and enable the pieces as your guide through the word doc. We don't want anyone just applying a fully active update set, we want you to understand what all the pieces are doing
- Speaking of, a Word doc that will help guide you through the process from CI insertion all the way down to retirement. Dealing with applications, relationships, and supporting CI's such as network interface cards, memory modules, TCP connections, and more...
- An update set with all the major scripting and properties needed. Again, remember I set these to inactive so you can review what's happening and enable them on your own.
Note that the 'scheduled' jobs that are referenced couldn't be tracked in our update set so you'll have to copy/paste those scripts into the jobs you create. My favourite method of scripting.. lol
What you will find are methods to
- ON insert of a new record set it to a pending state so that the record can be reviewed and approved to be part of production processes
- Once approved to make mandatory the support group so that there is always someone known to be responsible for it and lock it in.
- Scheduled jobs to check your Hardware (cmdb_ci_hardware) and Application (cmdb_ci_appl) records and if they haven't been 'discovered' in 'x' amount of time set their states accordingly so they can be followed up on.
- A full retirement process that gives you options to remove related records, including applications or keep them in a "retired" state if you have such auditing or regulatory requirements to do so.
Do know, this is not the be-all end-all of a proper lifecycle process, this is only a framework to help get you started and more importantly get the conversation started within your organization.
If you do take on this journey remember to also include the right folks as you lock yourself in a (virtually nowadays) conference room with walls covered with whiteboards to try and outline every twist and turn your processes might take. You should think of including at a minimum
- CMDB Owner/team (obviously)
- Discovery/Integration/platform Administrators
- Infrastructure teams (server/network/cloud)
- ITSM Process owners
- Governance, Risk and Compliance (GRC) owners
Everyone here is going to have a critical voice in how you manage these CI from birth to death and is going to help tune this framework and extensions to help make it your own.
Also know we have some great OOB functionality around CI Lifecycle as well. And I hope this can help compliment it, so do look to those features as you design your program.
I do want to thank the many friends out there in our customer base that took the time to give us their thoughts and feedback on how this latest version could help them. And of course a huge hi-five to my friend Emir who did a lot of the heavy lifting to make this a reality.
Enjoy!
- 8,942 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hello Doug, thanks a lot for this asset, it is indeed very helpful.
Could you please elaborate on how this Lifecycle framework is meant to coexist with the CSDM Life Cycle approach (with a space)? Migrating to CSDM life cycle standards | ServiceNow Docs
Thank you!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Right now its more stand alone to the oob product. However, Emir and I did build this in mind of the new product features specifically around using the newer status values so they stay in sync as compared to the first iteration of the program. Do know we are working very closely with the CMDB product team and you will be seeing many more functions that this package provides included in the "official" CMDB lifecycle offering in the near future.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thanks for your response Doug, much appreciated.
>the "official" CMDB lifecycle offering in the near future. -- this is precisely what my client and I are hoping for 🙂
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Good Morning Doug,
I believe we have seen the first OOB use case with the CI Life Cycle. Vulnerability Management. With that said, it first turned me to looking at the CI Life Cycle and CDSM. Is there any downside to migrating at least from the status perspective? It looks like you can still use the OOB Operational Status, Hardware State, and all that. They just drive the CI Life Cycle. What are your thoughts on this?
Basically with Vulnerability Management, if you retire the CI and are using the CI Life Cycle it will retire the vulnerabilities associated with it. We want to use it, but obviously if there are downsides to the migration - we want to avoid that.
Thanks,
Jason
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi Doug,
We are trying to implement this in our instance, i was trying to understand script include - "RelatedItemManager_lite", there are 2 functions defined in this script - deactivateThisRecord and updateThisRecord but i don't see they are being called anywhere in script or anywhere else. Could you please help me understand where are they being used.
Regards,
Shreya
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Shreya, hi, not all functions are used at this time, the script was intended to have additional features that are not included in v2.
updateThisRecord is used to just delete a reference to a CI (no retire or delete) > not used in any code right now
deactivateThisRecord is used to manage classes that do not use CI LifeCycle but rather an active flag > also not currently in this use case (think custom classes that use the CIs like a loaner program)
I decided to keep them in for easier use fur customers who have those requirements, feel free to remove.
Also, have you reviewed CMDB Data Manager and its features? This code was built before that existed.
I hope this helps!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Yeah i checked CMDB Data Manager but again it only handles Hardware CI or whatever CI class we'd provide in policy. But it don't handle referenced CIs if main CI gets retired. I hope ServiceNow builds some solution around that in future releases.
Currently in our env, we create stale CI tasks if Hardware CIs are not discovered in last 15 days and CMDB remediation auto-workflow gets triggered for each task and marks CIs non-operational. And then if CI is still not discovered in last 30 days, another flow gets triggered to make CIs retired.
We don't manually retire CIs, its all automated in our env. I'm specifically looking for retiring/deleting reference CIs and Relations. So thought of using that script include which you built.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi there Doug and Emir,
I noticed the documentation for Tokyo references "Cascade-retire dependent CIs" via CMDB Data Manager. In my Tokyo EA PDI, however, I noticed there is a subflow for "Delete Related Entry Configuration Item" but not for Retire. Do you know if cascade-retire will be baked into the GA release?
Thanks for all the great information you've published. It's much appreciated.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
As I have been following the CMDB team is consuming this product Emir and I put together bit by bit and hopefully see more of it in future releases.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @doug_schulze or @emir ,
Could you please share the updated best practice document which is included with new features such as CMDB Data Manager and Cascade-retire dependent CIs etc , I hope we no need to write a script using CMDB Data Manager policies as mentioned on this article
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I would suggest looking at the cmdb docs page, thats where I would start to get their documentation. If I come across any white papers or such will surely pass them along.