Executive summary
This article outlines the implementation of the Instance Scan Process, a structured approach to maintaining and improving platform health through systematic scanning, assignment, and resolution of findings. The process consists of five main steps:
- Run Instance Scan: The process initiates with a full instance scan triggered by the scheduled job "Trigger Full Scan," which examines all defined checks. It is recommended to schedule this task regularly, such as once every four weeks.
- Assign Findings: Findings from the scan are identified as rule violations and are recorded in the "Scan Finding" table. These findings are assigned to the responsible teams for resolution, either directly to DevOps teams or initially to a platform team for further analysis.
- Analyse Findings: Findings are prioritized and analysed to determine the appropriate action. Priority 1 and 2 findings are addressed first, followed by lower-priority items. The analysis guides the next steps in resolution or dismissal.
- Determine Action & Update Finding: Depending on the analysis, findings are either resolved by creating a story and updating the scan task to "In Progress," or muted if deemed non-critical, with an explanation documented. If muted, the finding is ignored in future scans, and its status is marked as "Resolved."
- Create Story: Resolution of findings may require the creation of development stories to address the underlying issues. These stories are added to the backlog of the responsible team for further processing.
Other Activities:
- Instance scan results are monitored for errors, which are flagged as "Failed." These issues are tracked in the "Check Executions" table for follow-up.
- Reporting is recommended through dashboards that highlight scan results, findings, task status, and new checks.
The document also includes a RACI matrix, detailing responsibilities across key roles, ensuring clear accountability throughout the process. Additional considerations include custom scan checks and the proactive scanning of update sets to catch issues before deployment.
Overall, the Instance Scan Process promotes platform stability, security, and performance by systematically identifying and resolving configuration issues while maintaining structured accountability through well-defined roles.
Instance scan process
The figure above describes the various activities that are part of the process. These activities are now further described.
1. Run instance scan
In the baseline scheduled job “Trigger Full Scan” can be used to schedule the instance scans. As the name suggests, this will trigger a full scan using all available checks as defined in the Check (scan_check) table. The job is set to run “On demand”. I suggest scheduling it periodically, like on Saturdays once every 4 weeks.
2. Assign findings
A finding is a reference to a record that has violated a rule from a check on the instance. The findings from the scans can be found in the “Scan finding” (scan_finding) table. The findings can be analysed and mitigated by creating scan tasks in the “Scan task” (scan_task) table.
Findings can be assigned to a devops team responsible for the corresponding source record. E.g. this can be done based on the scope of the associated source record.
It is of course also possible to simply assign all scan tasks to a platform team for initial analysis. If applicable, they can then be manually reassigned to another team.
As scan tasks are not automatically created in the baseline, we have created a business rule using a script include to automatically create a scan task for a finding. The script also checks if a scan record already exists for the finding, as a finding for a source record can be found in multiple scans. Rather than creating duplicate scan task records, it will then simply link the finding to the existing scan task record.
We have also decided to limit the number of scan tasks that will be created to a specific number of categories to make the amount of task records manageable. This is done via the "this.categoriesallowed" property in the initialize function. The categories for which scan tasks are created have been limited to the 5 categories that are used by ServiceNow in their health scan procedure:
- Manageability
- Performance
- Security
- Upgradability
- User Experience
The script include has been linked to this article as an attachment.
3. Analyse findings
The findings can be analysed by reviewing the short description, the resolution details and the source record.
Consider starting with analysing the priority 1 and 2 findings. If there are no or a few (<20) findings left, you can continue with the priority 3 and 4 findings.
Based on the analysis the appropriate action can be determined (see next paragraph).
4. Determine action & update finding
After analysing the finding, there are basically 2 options
1. Solve the finding
To solve the finding, the following actions should be done.
- Create a story to resolve the finding (step 5)
- Set the State of the scan task record to “In progress”
When the story has been completed: - Set the State of the scan task record to “Resolved”
2. Mute finding with reason
If the finding can be ignored, the following actions should be done.
- Add a work note on the scan task record to explain why the finding can be ignored.
- Mute the scan task finding record, so that the check is ignored for the source record in future scans. When muting the finding, a mute reason needs to be selected
- Set the State of the scan task record to “Resolved”
5. Create story
To resolve 1 or more findings, a story can be created for the backlog of the appropriate team.
After the story has been created, the appropriate scan tasks can be updated.
Other activities and topics
Check instance scan results
Sometimes specific checks may not work properly and this will lead to an error. If this happens the scan result will be set to “Failed”. More details can be found in the “Check executions” (scan_check_execution) table.
The platform team should monitor these results and perform follow up activities by creating and resolving defects for failed checks.
Reporting
To be able to measure the effectiveness of this procedure, a dashboard can be created. Consider showing certain indicators, such as:
- An overview of the scans and the number of findings per scan
- A list of findings, scan tasks and their status
- New checks created per month
- Number of new findings due to new checks created
RACI Table
A RACI table (also known as a RACI matrix or RACI chart) is a project management tool used to clarify roles and responsibilities in a project or process. "RACI" is an acronym that stands for Responsible, Accountable, Consulted, and Informed—the four key roles that can be assigned to team members for each task or deliverable.
Here's a breakdown of each role:
- Responsible: The person(s) who perform the work to complete the task. They are directly responsible for doing the task and are usually the primary contributor.
- Accountable: The person who is ultimately answerable for the completion of the task. This person delegates work and makes final decisions, ensuring the task or project meets quality standards and is completed on time.
- Consulted: The people who provide input, feedback, or advice on the task. This is usually a two-way communication, as these individuals have valuable insights but are not responsible for the task's completion.
- Informed: The people who need to be kept up to date on progress, but do not contribute directly to the task. This is generally one-way communication.
For the activities mentioned in this document, Table 1 shows an example of a RACI matrix.
The following roles are mentioned in this table.
- Platform Owner: the owner of the platform. A key role within an organization responsible for the overall management, governance, and strategic direction of the ServiceNow platform
- Product Owner Platform: the product owner for the ServiceNow platform devops team
- Platform Architect: the solution architect for the ServiceNow platform
- Platform Business Analist: The Business Analist working in the ServiceNow platform devops team
- Technical Lead: the technical lead of an IT devops team is responsible for guiding the technical direction of epics and stories, and overseeing the technical work of the team
- Product Owner: the Product Owner is responsible for defining the product vision, prioritizing features, and ensuring the development team delivers value to the business or stakeholders
Table 1: RACI matrix for the activities mentioned
| Platform Owner | Product Owner Platform | Platform Architect | Platform Business Analist | Developer | Product Owner(s) |
Instance scan monitoring |
| A | I | R | I |
|
Assign findings |
| A | CI | R | CI |
|
Create stories |
| A |
|
| R | I |
Determine action & update finding |
| I | CI | C | R | A |
Reporting: maintain dashboard | I | A | CI | R | C | I |
Escalate | A | C | R | C | C | I |
Maintain this document (new versions) | A | C | R | C | C | C |
Additional considerations
Additional checks
It is also possible to create your own checks. In fact, some very valuable checks have already been created by this great community. For example, one very good repository with checks has been created by Maik Skoddow. See his article on LinkedIn; Scan checks GitHub Repository from Mail Skoddow.
Update set scanning
It is also possible to check your update sets using the available checks. In the baseline there is an option to proactively scan your update set, or your application, to avoid findings before moving update sets to other instances. Consider making this a mandatory action as part of the peer review in your development process. Or you may even consider automating this process, as described in this article by Mark Roethof; Automating Update Set scan for Instance Scan.
