ITIL Service Operation Goals

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

3 hours 49 minutes
Video Transcription
Welcome to the Idol framework. Updated course from Cyber Eri i t.
My name is Daniel Riley. I'm your subject matter expert on the idol framework.
In this video, we're going to talk about the service operation phase, goals and processes.
Now, the over I'd be a overall idea of this phase is the day to day operation and maintenance and monitoring of all of our active service is on. And this is broken down into several components across several different business organizations
units as shown here,
you'll take in information from your service desk and you'll use that feature 80 operations and your financial management plans will talk a little bit about application management and technical management as well.
So we're talking about ensuring the timely on efficient delivery of all of our service is as the core concept on. We're going to do that through fulfilling of user requests, fixing problems and resolving any service failures that come up.
And that's in addition, any of our routine operational stuff that we have to be with.
So the first process we're going to talk about is the event management process. As things happen in on in or environment,
we collect them in logs, and each one is considered an event. And
we're going to make sure that we're constantly collecting these events across all our different service is,
and then we're gonna want to filter and categorize these events based off of their tight. This might be informational. Uh, warning. There might be critical or exceptional events.
Uh, And now, if we cannot correct the problem to an incident that pops up will create a problem record, and we'll send that off to a problem management function, which will talk more about in just a moment.
So the sub processes that make up the event management process First, we're gonna start with the rules maintenance, And this is where we maintain all of our technical mechanisms that we put in place to log and monitor events.
We're going to set those up, and then we're gonna make sure that we
keep them in a line with our
assumptions in our environment on make sure that they're generating meaningful events for us.
Once we collect the events, we're gonna send them through the first level filtering, which is often times called level one. Correlation.
this is where we're just getting rid of the informational events and looking for warnings and exceptions that will need to escalate
once we find those were gonna escalate. Those two are second level on. This is the response selection level where we interpret the meaning of the event and decide if we need to take some kind of corrective action.
Once we have decided on a response, we're gonna review that. We've handled all of the events appropriately on. We're gonna make sure all of our vet mugs are up to date and that we've looked for any trends from previous of that mobs, which we might use
to take better actions in the future.
All right, so moving into the incident management process, the idea of the incident management processes when something pops up, we want to manage it through the entire life cycle, from reporting all the way through to closing. And the whole idea is to return the service
back to use for user's as quickly as possible.
So the process is for the sub processes will use to make up. That process involved the incident management support, which is defining the tools and making sure that the employees have skills necessary in the knowledge acquired to handle incidents
as well as a system where we are longing and categorizing incidents using some known framework. And we're
evaluate incidents in the same manner.
So then we'll have our immediate incident resolution. This is also called first Year Supporter, Tier one Tech support. This is where we can solve a service interruption without the need to escalate it. And this is usually based on some agreed service level
meantime to recovery or some
of metric like that.
If we can't solve it in that time, where it's beyond the technical grasp of the tier one support, then it will get escalated to the tear to second to your support. And this is where we're going to involve more resources to investigate it, we might call third party. Ah,
resource is which are specialists
from a company to come and help us determine what
course of action are available to us.
in the handling of major incidents process. This is where we're going to
get all hands on deck and
try to figure out the cause of a serious interruption on and get it back
so much regard to a service level agreement but a company
impact business impact case.
So we're going to use incident monitoring an escalation to pick out the upcoming incidences, incidences
and going
to pick countermeasures to introduce them as quickly as possible, hopefully to avoid incidents if at all possible.
Once we've set up countermeasures to try to avoid any further incidents from happening, will submit the incident report to a quality check, which is basically just to make sure that all of our information is sound. All of the pertinent details air collected
on and then we're going to keep those records for future reference. In case these events occur again,
we don't have to go back and rediscover information.
We also want to proactively inform our users as a part of our incident management process. And this is just the let users know As soon as there's a service problem, you don't want to let a user figure out on their own
because usually the next thing a user will do is called the help desk or service. That's to find out why there's ah interruption in some service, so if we proactively inform our users that some service is not functioning at the moment,
we can actually use this to reduced our workload during an incident.
We're going to want to keep
detailed records of all of our incidents, and we're gonna want to keep those records for future management in and allow them to inform our other processes going forward. So as our next service strategy session starts,
we may review our incident logs from the past
cycles and determine what we want our strategy to reflect in those incidents.
This is kind of just a workflow for an instant of management process. I wouldn't take too much time to study this simply because incident management from company to company varies. So this is just a NY idea of how one might map it. I would highly suggest
you asked for your organization
organization's incident management process.
So request fulfillment process is really about providing change support to our clients. This is often times in a help or support desk format. Call center support representatives provide this process a lot of the time.
Um, it was gonna be broken down into fulfillment support, which is all of the tools of process in training that gives skills necessary to handle service requests from clients.
Then we're going to handle the request. Logging in category categorization very similar to the way we would do an event
request could be seen as a subtype of an event, in fact, but we're gonna validate that the requester has the authorization to submit this request. And then we're going to record that the request has been made and we're going to make sure that we
applied due diligence in researching
on making sure that it's fulfilled.
Now the request model execution is where we process thes service requests within a timeframe and flow schedule that we have agreed upon neither in our service level agreements are in our operational level agreements and a request model itself
is simply
the flow of the process from the time that a request is made, how it enters our environment and how we tracked through its process to closure.
And we're going to use the request monitoring on escalation process to actually monitor that request model flow on. We're going to make sure that if we detect any deviations or blockages in the flow, we're going to introduce you
corrective measures as quickly as we can
to make sure that we keep in line with our service for silver
after we have monitored and got it through the entire process, we're going to submit the request record to a final quality check very similar to the way we did with our events. And then we're going to keep those records for future reference pretty much for the same reasons
now. I said that we're going to authenticator or authorize that a user is able to make a request on. And to do that, we can have to talk about these three topics here. Identification, authentication and authorization identification is who you claim to be.
This could be a user name and email
or some kind of identifying. Token authentication is some
method that you provide to prove that your identification is, in fact valid. This might be a password that only you know, or some biometric feature or some other token given to you and only you that should prove your identification uniquely
and then authorization is the set of permissions, the list of things that you're allowed to do once your identification has been authenticated.
So the access management processes about granting authorized users the right to use a particular service or subset of service is.
It's also the flip side of that where we prevent access to non authorized users.
So this is a collection of policies which we're going to define and then execute in an information security management process.
And you also hear this referred to a lot of times his identity and access management in a lot of Web consuls. Or it might be referred to his rights management in a lot of document materials.
So the sub processes that make up access management are defining the catalog of our roles and permissions. What are
our user roles? Such a supervisor's super add men's admits things like that. We're going to define what those rules are and what they can access in those roles, and this is called role based authentication. There are other authentication based schemes, but
in some way we're going to keep a catalogue of what our relationship rules are,
and this we're going to make sure that we who maintain it so that it's up to date with our current architecture,
Um, and this will help us stop what's called the accumulation of unwanted access rates. This is simply when I'm given
Task A and I need security credentials
A to do it,
and then I'm given task be and security credentials be.
But I've never taken away the security credentials. A. So even though I have finished that job, I have still accumulated the access rights required to do that job. And we don't want that. We want to end our access rights
as soon as we no longer need them.
So user access request processing is when we processed the internal or external requests to change this information, be it at a user to a role or at an access profile to a role,
or to revoke any of that as well.
And we're gonna make sure that only authorized users or authorized personnel are able to make these requests to modify access rights
in the problem management process. We're gonna manage the life cycle of all problems. And now, if you were call a moment ago, I said that if an incidents root cause cannot be determined, it's going to be written up and sent through the problem management process. And that's this process
of the idea of problem. Management is also to prevent incidents from happening. So we look at incidents that we could not determine the cause of in greater detail. And we try to prevent future incidents from happening
on. And when we can't stop them, we're going to try to
minimize the impact that they can have.
and as I said, this is
the incidents that can't be solved through the incident management process as well as
perceived incidents that might come up but haven't been experienced in the wild yet. Um,
foreseen problems is the way to look at those.
So the proactive problem identification sub problem
sub process is really where we're going to go out into our environment and look for those perceived problems that I was just mentioning and look at identifying the problem solutions or workarounds that we can put in place
before they're experienced out in the wind.
Um, if we do have a problem that arises that we didn't perceive before it pops up,
we're going to go and categorize it and prioritize it,
Um, in our record, our problem record,
and then we're going to diagnosis and hopefully resolve the problem in some way. This involves identifying the root cause. If we can, Ah, and initiating appropriate solutions. And of course, by appropriate we mean economically feasible
if there is such a solution available. If not, we might work through temporary work arounds. And then we will proactively inform our clients about those workarounds.
And now in the problem control phase, this is when we're gonna monitor those problems which we couldn't have couldn't solve or haven't solved as of yet.
and as soon as we find a corrective measure or work around, we're going to implement.
So the problem closure and evaluation phase is when we ensure that a record of the problem has all of the actions that we've taken to try to solve or mitigate or work around that problem. Um
and that all known error records are updated so that we can accurately detect
this problem in our environment.
If we have major problems, they'll go through a special review process is called the Major problem review.
Uh, this is where we look at the solutions for major problems and see if we can use this knowledge to prevent any kind of re occurrence of the problem. And of course, we always wanna look toe learning the lessons from our problems in our failures and applying them to our future activities
on. Then we're gonna verify that all the problems that we've marked as closed have actually been eliminated. You will run into several cases where you believe you've solved the problem on Lee to find it so its head in a different place in the environment.
So problem management reporting is where we collect all of that information on we pass it along to service management and the other I tease of processes. And we make sure that everyone's informed of the ongoing problems that we're having, Um, how
far along they are in the process and life cycle.
And if we know any workarounds for them, we really want to make sure that we have everybody informed of those.
So this is just kind of, ah, another graphic layout of the possible, um,
problem management process, and this will again very based off of your organization. But they all have some element of collecting, be it through user reporting, an incident management systems or through network monitoring, like network
security analysis
agents that are monitoring traffic. All of that will be collected into a logging system, which will then be analyzed, And some analysts, either human or machine analyst, is going to propose solutions to the problems that are found.
Those will be designed and developed and then deployed.
Then we're going to measure the effect of our deployed answer and hopefully go through a successful close. And then that whole cycle will repeat
in the I T. Operation control process. This is where we're going to monitor the day to day control of the I T service is and all of the actual components that make up the infrastructure.
The service is run on.
The tasks related to operations of the infrastructure components can be things like updating firmware and software monitoring network connections and things that must be tended to every day.
We didn't break this out into sub processes because it's so dependent on the infrastructure. If you have a very small infrastructure, your day to day tasks might only be a matter of law cleanup. In monitoring
where is in a much larger environment, you might have an entire operation center
develop devoted just to I t operations or network operations.
Now, when we talk about I t operations, though we will talk a lot about Dev ops, which is this unique blend that's come up in the last
five or 10 years. Where, and we used to have separate departments and handoffs to handle a development would hand their project to a network engineer who would set it up somewhere. And then they would let the Quality Assurance team no where to go test.
And then the quality assurance team
would go and and make their reports, and all of this was very inefficient. So we started having
people who are efficient in all three areas. You'll have a very good developer who knows how unit testing works and who is familiar with deploying to different environments, either locally or in the cloud on this type of person, is
perfectly suited to development operations or death ops.
No, I t facility management's about managing the actual physical buildings and environment where the IittIe infrastructure is located.
In certain types of industry, there are still very large data centers and call centers that have to be managed, and the
procurement and an assessment of those facilities is covered here
essentially because of the way we're always evolving in business. We've moved from data centers. Ah, lot of times to cloud providers. And now two more hybrid clouds with some
service is being hosted in local
data centers and some being hosted offsite by Cloud service providers. And we call this type of hybrid like an on demand infrastructure.
We didn't break this out into some processes again because it's highly dependent on the structure of your organization.
If you have a very large organization, this might be a multi faceted team spread across the world. If you are a small start up company, this might be a sub process that you're CEO. Our CTO manages
the application management function isn't really a process. It's more treated in idle as a function,
but it plays a role in all application related aspects of the designing testing operation of tea Service is, and it also deals with developing the skills required. So the training,
coursework and certification of all the IittIe organization staff to make sure that they can
effectively and relevantly use the applications selected by the organization
So all of the application management functions tie in through the application development life cycle like we've talked about previously
and again, this has not been split out into sub processes since it's not treated as a process.
Now the technical management function is again not a process so much as treated as a function. But this is to provide the technical expertise about the I T infrastructure. So whereas the application management function was really about the software involved,
technical management is really more about the hardware
and networking aspects of a service or environment.
And so, again, this please a role in all of our technical aspects of designing and testing. Operating the day to day I T service is
on again, developing the skills required to operate. It falls under this function. So this is our training of our network engineering team, our database administration, team, things of that nature.
With that, we've come to the end of this video. I'd like to thank you for watching. And as always, if you have any questions, you can contact me on cyber harry dot i t my user name ist warder. T w a r T e r
Up Next
Axelos ITIL Foundations

This ITIL Foundation training course is for beginners and provides baseline knowledge for IT service management. It is taught by Daniel Reilly, one of our many great cyber security knowledge instructors who contribute to our digital library.

Instructed By