Best practices for CI retirement/archival rules?

[yogesh15dd]

Hi Team,

What are some of the best practices for Configuration Item (CI) retirement/archival rules?

@ doug_schulze 

kindly suggest.

Thanks

Yogesh Datta

[Dr Atul G- LNG]

@AJ-TechTrek 

Can you help here. 

[AJ-TechTrek · Accepted solution]

Hi @yogesh15dd ,

CMDB Data Manager introduced in the Rome release, provides a way of targeting CIs for retirement, archive and deletion using a policy-based approach.

CMDB Data Manager works with batches of 1000 CIs which is set using the system property glide.cmdb.data.manager.delete.batch.size.  While it's possible to adjust this, it can impact platform performance if increased to higher values.

Policies for retiring/archiving/deleting CIs are evaluated on a daily basis making them dynamic - the target CI list is updated based on what's in the CMDB when the scheduled job for a policy runs. In your case you'd define two policies in CMDB Data Manager:

1. Retire policy: sets the Lifecycle Stage field to "End of Life" for the Network Adapter CIs
2. Archive policy: archives the Network Adapter CIs whose Lifecycle Stage field is "End of Life"

Assets and CIs should never be deleted directly after retirement. Check whether the company has any existing data retention and archival policy. If there is no existing policy, check whether they need it at this point. If they are in the initial stages of ServiceNow implementation with less amount of data populated, it may not be needed soon (as it becomes important only when the volume of data becomes huge). But it is still a good idea to define the policy during the initial CMDB & asset process definition itself. For example, archiving CI data after 2 years and then deleting from the archive after 5 years or 7 years is often a standard practice. 

But even while defining an archival and retention policy, it is better to define it only for CI classes which do not have an asset associated with it. That way asset data will be always retained in the system. Asset data might be required in future also for purposes like audit, compliance, sustainability reporting etc (This point is valid for some CI classes also and that is why deleting should be never done soon after retirement).

Only when the asset data itself gets huge, archival and retention needs to be considered for those. In that case, it would be better to define a longer retention time period before archival and deletion (compared to CI classes which do not have assets associated with it)

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.

Thanks

AJ

Linkedin Profile:- https://www.linkedin.com/in/ajay-kumar-66a91385/

ServiceNow Community Rising Star 2024

[AJ-TechTrek · Accepted solution]

Assets and CIs should never be deleted directly after retirement. Check whether the company has any existing data retention and archival policy. If there is no existing policy, check whether they need it at this point. If they are in the initial stages of ServiceNow implementation with less amount of data populated, it may not be needed soon (as it becomes important only when the volume of data becomes huge). But it is still a good idea to define the policy during the initial CMDB & asset process definition itself. For example, archiving CI data after 2 years and then deleting from the archive after 5 years or 7 years is often a standard practice. 

But even while defining an archival and retention policy, it is better to define it only for CI classes which do not have an asset associated with it. That way asset data will be always retained in the system. Asset data might be required in future also for purposes like audit, compliance, sustainability reporting etc (This point is valid for some CI classes also and that is why deleting should be never done soon after retirement).

Only when the asset data itself gets huge, archival and retention needs to be considered for those. In that case, it would be better to define a longer retention time period before archival and deletion (compared to CI classes which do not have assets associated with it)

[yogesh15dd]

Thanks for the reply @AJ-TechTrek.

Make sense!

I will take a look at the 'CMDB Data Manager' for retire/archive policy.

I want to do one time retire for some big chunk / archive, if using using CMDB Data manager is going to be causing performance issue, i have to think of smart scripting and mass update!

What are you thoughts?

Best regards,

Yogesh Datta

[David104]

When these policies run, it is chunked up into smaller jobs that run out-of-hours.

We have deleted 300k+ CI's through these data manager policies without causing any performance issues, but it does run over a few days. Good thing is that once you are done with a big purge, you can configure the right policies to keep it clean and prevent a future purge from being required.

I disagree slightly with the advice above.

There are a lot of classes that are discovered through SG connectors and discovery which can be useful sometimes, but not really something that you would consider a "managed" class from a process perspective. For CI's such as Servers, Computers, Network Grear etc (stuff that is also an asset), definitely keep them around and jsut retire and maybe archive.  For things like network adpaters, I'm a fan of Retiring and deleting quickly once they are no longer being discovered. I find it good practice to setup some retire and delete/archive policies for each class populated by an SG connector as you implement it. This way, you are less likely to end up with large volumes of stale data down the track. Again, work out which classes are important (managed classes) vs what are more disposable. Keep the important stuff, dispose of the rest