ServiceNow DevOps Insights and capabilities
hey good morning good afternoon everyone thanks for joining this webinar uh so in today's webinar we are gonna touch base on uh one of the important uh uh offering from service now platform which is devops insights and its capabilities yeah so with this I'm quickly moving to slide um so notice um so you can join the feature webinars um a quick housekeeping rules there there will be enough time at the end of session to have question answers uh in the meantime you can keep keep you know typing your questions in the chat window um you know one of my colleagues can pick the questions and keep asking a question between so with this our safety reminder um so two aspects of the safety reminder slide is one is the human safety so in case if you're listening this webinar or join this webinar while driving riding um I would recommend to drop off from the call and you know this is not something recommended so it's not something for human safety uh there will be recordings available can be shared over the over the email to look into later on uh and the remained on the cyber security so service now is a cloud platform so as a part of cloud environment uh there are some distinguished responsibilities between customer and and the platform provider so uh just a quick reminder here what are the important responsibilities that customer need to fulfill and what are the responses that servicenow as a platform uh you know provider need to fulfill so just addict you know keeping the Cyber Securities on on priority so with this safety slide I will move into the uh one of the not the problem that we often see in our organization or day-to-day work life is a lot of challenges experienced by our Dev team um our resources um so you can see here um you know usually we keep hearing this from our development team you know a lot of it's a big cycle of change um one change really takes two to three weeks and all those sort of things so um so this is where devops basically comes to the process to ex to experience the processes uh to cut down the non uh non-important activities and deliver quickly uh you know by keeping the quality in mind so this is what the problem uh something faced by our Dev team usually if I move to the next slide which is talking about the problems individual roles face in into the day-to-day operations or day-to-day work life so if you see see the developer so what developer thinks that you know they easily spend too much time uh on admin tasks uh their leadership team they will bring into the all developers into meeting room and you know keep asking the status uh on the various different activities so which is kind of a developer thing that's it's not good use of their time similarly change managers often complain about a lot of increasing number of changes um and those are the practical problems that our teams face are in day-to-day operations similarly if you see the VP level leadership uh guys they feel you know a lot of a lot of issues with visibility lack of uh lack of transparency uh Ops guys they keep keep complaining of you know how teams they are implementing changes they you know they they don't show the conference over there and similarly for governance officer uh considering uh considering you know governance on top priority uh they also want to make sure that all the changes they are following the compliance so those are the you know General problems our team members they face whether they are in different different roles and this is where devops uh basically comes into picture to help them uh all those roles you know into their education problems um so with this a quick quick information about myself as a speaker uh myself Johan a part of product success management team here in service now um you know having a great experience in different Industries I worked in oil gas Aerospace domain prior to servicenow and currently uh you know managing couple of product within servicenow portfolio so with this I'll quickly moving to the agenda for today's session we are gonna touch base on the introduction of servicenow devops capability then we'll touch base on the insights and that is why we are here uh I will walk you through the dura Matrix which is one of the industry recognized uh Matrix to track the team performance and the overall Dev team performs basically I'm gonna touch base on the flow metrics then then I will take uh you know good amount of time to turn through on the demo so I'm gonna present um what is the devops service note of inside softwings we'll take questions at the end but don't wait for the question answers if your questions keep writing in the chat window yeah with this moving to next slide so we talk about couple of role-based problems and this is what the solution we have uh here is so if we if we really follow the devops mechanism um then these are the you know a couple of the problems that we can overcome for each individual roles uh by following the devops methodology you developers they the fields that they are they stop spending time into the admin task uh change managers they take they have a good view to handle the large changes um you know leadership they will also have a good visility because you know a lot of reports are there a lot of information flowing to system uh Ops Team and governance team as well you have a more confidence uh while doing the changes it will not break their production environment a team is following the standard to avoid any kind of compliance issues so this is what the solution of all those problems for integer role you can if I quickly move into the the service now offering as part of devops so uh so this is where servicenow exists uh service now devops is having a capability to integrate with with different industry standard tools where it's a GitHub or uh you know jira Jenkins uh whether it's a testing tool selenium so servicenow will integrate or having capability to integrate with all those different tools and you know pull a lot of information insights uh from all those different tools and start building a nice dashboard which can be used for making data driven decisions yeah and this is what something we call as a servicenow devops insights uh not only uh service now is having capability to integrate with tool it it is having capability to pull the various different information point at various stages of the pipeline so if you see uh you know the planning we have couple of tools where service now can integrate um similarly coding or at an orchestration level so tool is having the ability to integrate with different uh Industries nerd to pull the data at each stage of the pipeline and you know show them on a nice meaningful dashboard so with this I'll move to next slide which is about the devops uh insights offering from service now this is this is what the dashboard look like I will walk you through you know against all these different tabs how we can use how they can help you to make decisions uh during the day-to-day changes or day-to-day work life um so I'm gonna touch base I'm not going to touch base details here probably a while I will go for demo I will explain the the meaning of each and every tab with this I move on to the uh one of the industry recognized Matrix called Dura Matrix so this is something uh you know uh come up as part of one of the initiative from Google and puppet so the research team they put together and then they come up on a um on agreement what are the important Matrix uh to to track the team performance uh basically uh in the devil's world uh if you can see there is a there's a radical book available here if you have time we can we can read it over there but if you see in summary they recommend to have a four important key Matrix uh you know to track uh so that uh leadership team they can understand where are we going where how our teams are performing basically uh into the dev operations yeah so those are the um the definitions of all those four different metrics deployment frequency lead time for changes time to restore Services change failure rate and if you see you have a category as well if team is performing a light then this is what the metrics look like for each this is what the result that we are expecting from against each metric point similarly so servicenow devops inside do support metrics so we do have all those four important metrics as part of our dashboard along with these four uh there are a couple of addition metrics which will will touch base as part of demo today yeah so let's move next slide uh there is one of the important metrics I would like to highlight uh before before going further is about the flow Matrix so basically flow Matrix will will tell you about how the work is flowing into your day-to-day environment it's important Matrix to understand uh how how team is performing how work is moving against the plan um so there is a there's a book is also published on you know for for this on this particular Matrix uh written by Dr make question um something is good to refer in future but if this is what a screenshot from this Matrix from servicenow devops uh a lot of various different parameters we do take care we do compare in terms of flow metric support so we'll touch base all those Middle Point in our demo session today with this uh quickly moving to how basically Dura Matrix and flow metrics they they are contributing to the offset stability or stability of your applications stability of your product on on the uh on the production environment so basically they both the Matrix they they come together and they will give good data points around um you know how applications are performing uh what are the pattern of changes uh how many changes they are leading towards a high number of incidents so all those sort of information basically helps Ops Team to make a good decision uh in terms of what kind of quality our team is still bearing on production yeah because their their important goal for Ops team is to keep the operation keep the production government operational always uh you know keep this running for customers so this is where Dora and flow Matrix they they are helping Ops Team to to run through the system we will touch base all these three metrics uh in our demo session yeah so with this I quickly move into the next slide which is demo um I think you can straightforward go I hope I've been still sharing my desktop so not not sure if how many of you are familiar about this particular view but if you log into service now um open a devops change workspace and if you see there is a there's a tab here called insights so this is how you can navigate uh into this dashboard so if you can see here we have a lot of different options available here a lot of different important metrics service now platform offers up additional filters here so you can apply multiple filters whether it's on date or different products or even in your work items so those filters are also very helpful to to come on to the specific of each metrics and items so if I quickly walk through all those dashboards the first one is about the summary which will basically talk about the summary of all those important Matrix so it's a good view um you know if someone want to quickly scan and how my Matrix is doing how my team is doing if someone don't want to go into detail against each and every tab so this is what the summary will be is a good good way to come up there you can quickly scan uh important metrics and and and and and see if if you need to go into Deep dive against all those different items so if you see here uh the first mistake is about the average WIP cycle which is nothing but the work in process cycle uh so it it talk about uh uh you know uh uh how how many how many days each work item is taking before moving to completion um so of course the if you see if you refer the standard then team always they want to minimize the WIP or work in process activities because those are the items not very productive uh for the end users um so so basically you know teams expectation is to always keep the cycle very slow so that we can quickly move our changes on production or uh you know our users they can start using as soon as possible the other important Matrix about the average lead time so basically this is something we're talking about how much time it takes to move changes on production so if you see we have a though this is the mediator but it is good to see we have about half a day to day deployment on production um which is yeah quite okay but can be improved for uh for the high moving organizations where people they want to deploy changes so fast uh another metrics about the deployment frequency so basically this is about talking about how frequently we are deploying our changes on production yeah um how many changes we deployed in last uh 30 days uh code number um though this is dummy but uh it totally depends on the organization what is their expectations how how fast they want to move it average test pass percentage will give you uh enough information uh how you know how many test cases basically they passed when when someone make the changes um and run through pipeline automated testing what is the percentage of test cases passed for uh for those changes that we run through production deployment uh so 30 plus 30 not of not a very good number so intention is to keep this moving so that we have a good confidence on test results and and we can deploy changes more confidently on production uh this will this particular uh you know will and Mythic will talk about the division of each work items uh in your uh you know total work or changes that we are doing so you can see the bifurcation of different uh work items type how many Apex we deployed uh how many store points we deployed how many Bucks our team did they fix and depart on production so it's a good Matrix to see the bifurcation here there is the anthometric set down which will talk about the applications and various different parameters against those applications devops applications there is no data as of now but uh it's a good view to to see the uh the data so with summary view I will quickly move into one of the important Matrix uh flow Matrix that we talked earlier um so you know four different graphs a lot of a lot of four different metrics available here if I quickly touch base the average flow I flow time this is what the time you know takes to to move a change from commit to deployment uh 37.9 days not a not a very good Matrix there's definitely there are chances to improve average WIP cycle time as I mentioned uh intention is to keep the work in process cycle time as low as possible so that our team they can post the changes on production as quickly as possible and those changes can be used by customers or users on the production environment WIP count is number of changes in in the work in process so keep this one low as as much as possible um you know because those are the changes or work items not something useful for for the users as of now uh yeah work items completed it's a good number to see how many work items our team uh completed uh in the computer stage in last 30 days so those are the four important Matrix if I quickly touch base on those graphs the first one is talking about the average work item cycle time so basically how many days uh each work item is spending in different stages if we see a couple of items they spend a good amount of time in planning if I show you this particular graph so so you know teams they spend a good amount of time planning those changes um so there is opportunity you know uh improve on execution as well so that we can have a good improvement over complete work items as well similarly throughput and distribution will give us a idea uh you know against each work item how many work items we are deploying on production so if you see here that is clearly indicating um a lot of bugs we deployed here compared to stories or or the new changes or effects of features so basically it seems like team was highly focused on on the bug fixing during this particular time period so it's a good view to differentiate um what kind of work items are on priority for the team and accordingly you can make a decision yeah at this plan to deploy time flow time is how much time you know each work type of work item is taking from creation stage to the deployment so if you can see here um you know if you see here lot of task here you know that it takes time so 73 days in average um so definitely there is opportunity to improve further so that we can we can deliver we can our team is can start focusing on task deliveries or feature deliveries uh you know a lot of time so a working process will give you uh will give you the differentiation against each work item type how much how many days basically bugs are spending to stay in a WIP state uh which is of course a non-productive time span um so it's a it's a good indication that you know uh tasks they really uh waited along in WIP State here so there there are opportunity to improve further to reduce the work in process purpose time for task activity at least so this is what the flow Matrix is if I uh and of course uh as I mentioned earlier there are a lot of options to apply filters as well in future if I quickly show you the data from last month so it's a dummy data but yeah this is this is how we can apply filter and we can use those different filters that we available here application type or repository Services your business applications even the type of work items yeah so with this move on to the next step which is about the change acceleration um which is really one of the favorite uh area for change management team compliance team um so this this basically this we have you know six or eight different graphs and I will explain you the importance of all those graphs as well if you quickly touch base the first one devops change volume so it is it is giving me indication how my change volume uh basically going up or down uh if I'm getting too many changes say say first week of month then then I can have a you know good plan to handle those changes so it's basically indicating that the workload of in terms of change management you know time to close changes basically it it's an indication that how much time uh change is taking to move into the closed stage so how how much time each change is taken to move on production so it's again a good indicator basically how we are deploying our changes for the change management team if you see the automatic versus manual changes these are the important metrics in terms of track your automation um you know it's really a good way to understand how automation is something adopted by our team if this particular Matrix will give a good indication uh you know what percentage we are using devops automatic change feature utilization versus creating a change manual yeah as I mentioned earlier let's change managers they come up with a lot of changes suddenly so there is a feature available within servicenow devops where you can automate the change approval process um you know and and if team they move on that automation of those changes then then this is what the Matrix will give you the enough insights how our team is adopting ah manual changes versus automatic changes change of waiting for approval it's a good indication uh how many changes they they were in the approval waiting for approval basically so if you see here starting of the month uh you know not not many changes but if we see the December and there were a lot of changes waiting for approvals so it's a good indication of um of the how quickly we are approving our changes basically if I quickly go down so as I mentioned earlier the service now do offer automate automation of change management and if you see these two metrics they are talking about uh those automation items so there are certain uh policies certain conditions if we uh you know set up all those conditions in system in the platform then servicenow is having capability to make a decision on the behalf of change management team whether the particular change can be approved automatically or need a manual intervention so based on those certain cases conditions uh yeah you know service number change management will take a decision so if you see here there are uh you know a lot of cases where servicenow devops tool makes a decision to Auto accept the change and if you can see the differentiation here so changes for example low priority changes can definitely uh can go for automation automatic approval so so this is what the Matrix is talking about um however Auto automate automatic change management is doing basically how our rules are performing uh how those rules are utilized to make uh accept automatic acceptance decision similarly if you see here uh so so those policies that I was talking in service now can take a decision to Auto reject those changes as well so for example changes uh having a lot of uh you know test failures or critical nature or something need ah need a manual intervention need someone to look into those changes before approving so system is capable to make to all those decisions and can Auto reject such changes sometimes Auto rejection may lead to manual approval sometimes system will straightforward Auto reject the changes you know considering or basic various different conditions if you go further down uh change acceleration savings and hover saved is nothing but how many hours our team is saving by adopting the automation of change management process so if you see here here this metric is talking about uh you know we we saved 54 hours developer hours of time just following the automation of changes and similarly if you convert these numbers into dollar values and then this basically graph is talking about the dollar value as well yeah so this is about scene management if I quickly move into the accelerate Matrix um so accelerate Matrix is nothing but will give you um will give you the how how our team is performing how was software development is performing basically uh so this is a good Matrix to look various different important graphs and the metric point if I quickly touch base on the average lead time this is something uh one of the Torah Matrix if you can recall um so this is something talking about how long it takes a team to go from the moment developer hit the code commit to successfully deployed in production yeah so how much time average it is taking to basically hit the code commit to push the change on production average deployment frequency is about how many number of successful production deployment we did in in the current month so this is what the 40 deployment we did average mttr is nothing but the main time to resolve changes it's basically solving the incidents uh you know cost by by the type of changes so if any incident happened because of recent devops change then how quickly our team is resolving them so how how fast our team is to spawn all those changes uh just cost two to recent devops changes yeah and then average filler rate is uh what is our rate of failover in terms of changes um so if we can see here it's still you have high number but intention is to keep this number as low as possible to deploy your changes successfully without any issues without any incident on production lead time is um is basically a duration from the earliest commit time to production deployment for successful uh deployment basically so if you see about uh how how much time it takes the moment developer commits the code and relation to the production and and you see the lot of fluctuations here so intention here is to you know we should we should support uh frequent commits so couple of times uh our Dev team they will make the code changes and keep them in their local environment uh they will push all those changes in one short uh maybe once in a week kind of thing so uh so that's not that's not a good idea to um you know to to commit the changes uh ideally we should have a regular commits consistent uh to keep our changes flowing onto production it doesn't make sense to hold them into the local government so this metric is talking about how frequently we are committing was changes on production main time to restore from incident uh cost by devops changes so if you deployed any devops change uh how much time it takes to restore the system basically or restore the the incident that is caused because that of changes so it's something about talking about how how quick our team is responding all those devops changes or the issues created on production due to devops changes yeah production deployment frequency is talking about how quickly we are deploying our changes on production a number of successful production uh deployment in the last 30 days so if we see here this is what the graph is showing really a low number here hardly 10 deployment over team the post on production so it's a good way to see um how a team basically uh deploying the changes on production environment devops change failure rate from incidents so uh how our devops changes you know considering as a fail so if we post say 10 changes how much of them they they won production and created incidents over the production so it's a good Matrix for for change manager for compliance team to understand how was changes basically for following what is the quality of our changes uh something to keep in mind so with this I quickly move on to Quality Matrix and development uh follow up with this one so quality Matrix is basically um is a data that is servicenow devops tool will pull from your pre-existing testing tools whether it's a sonar Cube or selenium and and show the combined data or meaningful you know representation of data into graphs yeah so if you see here code coverage percentage is talking about out of uh out of you know uh how many what percentage of our code is covered as part of automation of testing so if we if we have say 30 percent of our uh you know code is already covered as part of automation testing then this is what the Matrix will give you idea ideally uh intention from team is to keep the entire code as part of coverage but yeah sometimes it's it's a little difficult um so if you see here how your team is covering the code as part of automation testing yeah uh at what percentage then next let me think about the test pass percentage so what is our test pass percentage rate in past so it's a good indicator however test cases we basically performing however test results are performing so it will help change management team to boost the confidence or compliance team to mobile conference yes our changes they are following the quality categies and Performing very well in terms of test pass percentage will give you enough differentiation um what kind of vulnerabilities recorded as part of our automation testing um so you can clearly see here what are the major issues you know reported or high bright issues reported this is basically very helpful to make a decision uh while moving changes on production if you have a lot of a lot of high priority issues observed then you know it doesn't make sense to to take a risk and deploy a change in production better to take a step back and keep you know fix all those hybridic changes and then redeploy so it's a good good indicator of security valencies bug count will straightforward give you the number of counts uh the number of bucks uh you know observed during the automation testing again it's a good indicator for exchange management team or the Ops Team to make a decision you know however however code quality is uh how many bugs are basically uh you know reporting during the testing process with this uh move on to the development Matrix so one of the one of the favorite Matrix for uh Dev team um here here basically not often important insights uh can be seen for latitude development work that our team is doing so if you see here a commit frequency how how frequently our Dev is making those commits uh how many active committers basically how active our team is um how many developers or the or the Dem members they are covering the code uh so it's a good indicator to see uh you know what kind of pay server team is is making um so these two metrics are really good to see together so this one is about talking about the top commuters or the top developers or the team members who who made a lot of changes or do lot of commits in last 30 days similarly this Matrix is talking about the commuters who do lot of rivers so they they reverted their code in last 30 days so the testing aspect here to see is If You observe couple of names names are very common in top commenters list as well as reverters list so for example this alien button um even uh even uh even chase filler so so basically it's a good Matrix if you combine together to understand how our team is making commits and how frequently they are rolling back all those changes yeah so sometimes you know teams they they will make changes and they revert it back later on so it's a good indicator um you know why we have so many commits and why we have so many rewards against those commits uh is there something something our team is not following uh standard or what is the issue here what is the bottom mind so it's a good good to see those meetings together if C average dominance per committer is a good indicator how each committer basically doing commits whether our average average code commit is going up or down so it's a good Trend indicator to see um you know how many commits that per committer is doing um similarly average commits per pipeline will give you the the load distribution of all those commits against each of your pipeline so it's a good indicator you know against which pipeline is something you you are getting a most commits or highly utilized so it's a good indicator to see the equation of all those pipelines that you have in your code commits without work items so this metric is talking about the sanity of the code uh or the standard that our Dev team is following up um sometimes you know uh development team they make changes without knowing what is the cause what is the value behind this change so you can clearly see here um whether you know developers they are attaching any work items along with the commits or changes if there is no work items attached so that that's really a good indicator you know either developer doesn't know why what what changes they are going to make how it is going to have for the for the tool customers or or they are not following the sanity checks basically so intention is to you know attach at least work items against each commit to understand uh why why developer made this commit against a code no uh pipeline pass percentage will give you uh however however each pipeline is doing in terms of uh you know successfully delivered the deployment on production uh so sequently good indicator if certain pipelines they are following a lot of issues or you know unsuccessful deployment so good to see what is wrong against those pipelines um so it's a good data to see if I quickly move into the last Matrix which is about operational stability this is one of the favorite metrics for Ops Team uh definitely because they are responsible to keep the system running on production they are responsible to uh you know about the stability of the system so they they they're really interested to see them so the impact of changes uh into their Ops work so so if you see here couple of Matrix important Matrix here number of incidents um if if if you know if at any point uh Ops Team they realized we have a lot of high incidents uh due to recent devops changes then this is what the mid takes they can refer um so basically um you know if any changes they are making lot of incident or responsible for a lot of incident so they can go back they can talk to team you know how we can improve our quality of changes so that we can we can really minimize the impact on the production insurance similarly our outages in the services so if if lot of devops changes they are responsible to for a lot of outages on production so then it's a good indicator for Ops Team to have a conversation with team and you know to move the silos and barriers uh discuss with them how we can really improve the change quality or delivery of code how we can stick on the testing process so that we can avoid all those outages and production yep absolutely it wasn't kind of poor uh thanks Mike uh service availability is is something uh you know uh I will talk about the ability of service uh if if any time service goes down due to recent changes then it's a good indicator for team uh you know to uh to fix all those areas uh those are responsible for making our services down or at least uh making our production environments down um so so this is one of the important Matrix for Ops Team to look into this and so basically if you see all those combined Matrix will help ultimately Ops team together to understand uh what kind of changes our team is doing um how we can really improve the quality or the standard to avoid all those Productions rents and that changes yeah so this is for the overall devops inside availability is um I'm not sure if you have more questions so I'm sure Mike must be responding all those questions in parallel good thanks so uh with this I will move on to the question answer section um and happy to other questions um you can you can follow the chat uh here to write your question if if you guys want to know more about those Matrix if you're interesting in in in different aspect to learning about the devops offering from service now you can type your requirements here probably our team they can touch base uh you know to either organize a separate sessions for you or offering you uh you know more content or more helping hand in terms of to improve the audacity of service and offering devops insights thanks Mike for responding over chats no worries if anyone has any other questions uh I'm happy to take them now or as G2 mentioned if you would like any more info on on on devops uh what jitto has shown is just one of the um one of the parts of devops which is the insights part but there's there's a there's a lot of other components to devops for accelerating change and detecting and validating and preventing configuration issues from reaching production uh we're happy to to give more details or provide a demo so yeah let us know if you're interested in in any of that there's a question in the chat I see in the Q a I'm sorry oh yeah okay uh from homie so yeah so the the way the way the data gets fed is um uh when you integrate your your devops tools uh into service now so your planning tools your coding tools your orchestration tools Etc I think teachers bringing up that slide so when all those tools are integrated into servicenow um that data gets gets fed uh into tables in the platform and then for the insights dashboard there's a performance analytics job which runs every night which gathers up the updates to that data and populates uh the dashboard with with the updates but basically the source of the data is coming from all those tools that you would have the devops tools that you have in your own environments once they're integrated with servicenow yes thanks Blake great any other questions uh seems like no more questions um so I think with this uh probably we can wrap up the session uh it was definitely a good one uh and uh feel free to drop us an email to respond the surveys uh the post in the event surveys if you want to know more about devops offering from servicenow uh you know how Windows how your teams can uh can touch base with with the service now teams to offer more help so yeah with this with this note I think we can conclude the session uh thanks once again for everyone have a wonderful day bye
https://www.youtube.com/watch?v=BtKjI0-gKGw