IT Service Manager Examination — knowledge map
The 48 core concepts of IT Service Manager Examination and how they connect. Click a node in the map above to explore related terms and prerequisites; the list below indexes every concept with its definition and links to its prerequisites and related concepts.
Concepts (48)
Incident management
The process aimed at restoring normal service operation as quickly as possible within agreed service levels after an unplanned interruption or quality degradation (an incident). It proceeds through logging, categorization, investigation, recovery, and closure, using workarounds when needed. Determining root cause belongs to problem management; incident management prioritizes fast recovery.
Prerequisites: Planning of service management、Workaround
Related: Problem management
ITIL
A framework summarizing best practices in IT service management, systematizing approaches such as incident management and change management. The latest edition, ITIL 4 (2019), is reorganized around the value-co-creation-centric Service Value System (SVS) and 34 practices (the former processes are carried forward as practices).
Prerequisites: Incident management、Service value system (SVS)
Availability rate
The proportion of time a system operates correctly. Availability = MTBF ÷ (MTBF + MTTR); it rises as time-between-failures grows and repair time shrinks. A core availability metric, also used as an agreed SLA target (e.g., 99.9%).
Prerequisites: MTBF (mean time between failures)
Configuration item (CI)
A configuration item (CI) is a component that is individually identified and managed as a subject of configuration management, and it can take many granularities such as hardware, software, documents, or services. Each CI carries attributes such as type, version, and status, and forms the service structure through its relationships with other CIs. The IT service manager designs how far to manage things as CIs (the level of granularity), judging the balance between a level too fine to maintain and one too coarse to be useful for impact analysis.
Problem management
The process that identifies the root cause (the problem) behind one or more incidents and pursues permanent resolution and prevention of recurrence. It has a reactive side (responding to incidents that have occurred) and a proactive side (preventing them through trend analysis). Unlike incident management, which seeks fast recovery, its focus is on eliminating causes.
Related: Incident management
Incident management and problem management
Incident management quickly detects service disruptions and restores service as fast as possible. Problem management identifies the root cause of incidents and puts measures in place to prevent recurrence. The key distinction is their goal: rapid restoration versus preventing recurrence.
Prerequisites: Incident management、Problem management
MTBF (mean time between failures)
For a repairable system, the average operating time from one failure to the next. A larger value means fewer failures and higher reliability. Computed as total operating time ÷ number of failures.
Health Check
A health check is a mechanism used by load balancers and redundant configurations to periodically verify that backend servers or devices are responding correctly. L4 health checks simply test whether a TCP connection can be established, while L7 health checks send an HTTP request and validate the status code or response content; targets detected as unhealthy are automatically excluded from traffic distribution or failover.
Prerequisites: Failover and failback
Related: Load balancer (L4/L7)
Availability management (service management)
The activity of designing, measuring, and improving services and configuration items to meet an agreed target availability. Availability is computed from mean time between failures and mean time to repair as availability = MTBF / (MTBF + MTTR); for a series configuration the overall availability is the product of the elements, and for a parallel (redundant) configuration it is 1 - (1 - a) to the power n. Eliminating single points of failure (SPOF) through redundancy is the key design point. The IT service manager monitors the target availability and judges the cost-effectiveness of adding redundancy.
Prerequisites: Availability rate、MTBF (mean time between failures)、MTTR (mean time to repair)、Configuration item (CI)
Change risk assessment and backout
A control that, before a change is carried out, assesses the risk and impact it poses to the service and to other configuration items, and always prepares a backout (fallback) plan that can reliably restore the pre-change state if the change fails. The backout plan includes the procedure, the time it takes, and decision criteria for when to abort and revert, and its feasibility is confirmed in advance. The IT service manager treats the existence and effectiveness of a backout plan as a precondition for approving a change, protecting the availability of the live service.
Prerequisites: Configuration item (CI)
CMDB (configuration management database)
The CMDB (configuration management database) records the configuration items (CIs), their attributes, and the relationships among them, serving as the core information base for configuration management. It is used for impact analysis of changes and releases, tracing incident causes, and visualizing service structure, and its value depends on the accuracy and currency of its data. The IT service manager designs the CMDB scope and update process, linking it to change management to prevent drift from reality and thereby securing the reliability of impact assessment.
Prerequisites: Configuration item (CI)
The seven ITIL4 guiding principles
The universally applicable recommendations that guide behavior in ITIL4: focus on value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically, keep it simple and practical, and optimize and automate. They apply regardless of an organization's goals or structure. A service manager relies on them when improving services or making decisions, avoiding over-engineering and local optimization.
Service value chain (SVC)
The set of interconnected activities at the core of the SVS, comprising six activities: plan, improve, engage, design and transition, obtain/build, and deliver and support. For each demand these activities are recombined flexibly into a value stream that produces value. A service manager designs how the activities are linked for a given service request to build an efficient flow of value delivery.
Prerequisites: Request fulfilment (service request)
Known error (KEDB)
A problem whose root cause or workaround has been identified is called a known error, and the repository accumulating them is the Known Error Database (KEDB). By consulting the KEDB, the service desk and technical teams can immediately apply workarounds to known faults, supporting fast incident recovery.
Related: Workaround
Request fulfilment (service request)
The process that handles routine user requests for which procedures, approvals, and costs are predefined (issuing accounts, installing standard software, providing information), rather than unplanned interruptions. It is kept distinct from incident management, which handles failures, and from non-routine changes that require change management.
Prerequisites: Incident management
Planning of service management
The activity of establishing in advance the policies, objectives, scope, required resources, roles and responsibilities, and schedule needed to run service management effectively. It corresponds to the Plan step in the JIS Q 20000 PDCA cycle and forms the foundation for subsequent operation, monitoring, and improvement. A service manager translates business goals and customer requirements into the plan, decides how to allocate limited resources across services, and sets the premises for later processes to operate coherently.
Prerequisites: JIS Q 20000 and the service management system (SMS)
Workaround
A temporary means of restoring or maintaining service before a permanent fix that removes the root cause is completed. It is applied to reduce an incident's impact and keep the business running, and effective workarounds are recorded in the KEDB for reuse.
Related: Known error (KEDB)
Service desk
A single point of contact that receives inquiries and failure reports from users. It removes the need for users to know multiple contacts and allows responses to be managed centrally.
Prerequisites: Service desk and SPOC
SLA and SLM
An SLA (service level agreement) is a document agreed between a service provider and its users specifying quality targets such as uptime and response time. SLM (service level management) is the ongoing activity of monitoring and reviewing that agreement.
Prerequisites: Availability rate、Service level management (SLM)
MTTR (mean time to repair)
The average time from a failure until recovery. A smaller value means faster recovery and better maintainability. Computed as total repair time ÷ number of failures; it is part of the denominator in availability = MTBF ÷ (MTBF + MTTR), assessed together with MTBF (mean time between failures) for reliability and maintainability.
Prerequisites: Availability rate、MTBF (mean time between failures)
Load balancer (L4/L7)
A device that distributes load across multiple servers. An L4 load balancer distributes based on IP address and port; an L7 load balancer can interpret application-layer information such as HTTP URL paths and cookies, enabling path-based routing and cookie-based session persistence. Health checks automatically remove failed servers from rotation.
Related: Health Check
Configuration management
The activity of identifying and recording versions of deliverables, documents, and baselines, and applying only approved changes to keep them consistent. Working alongside integrated change control, it ensures the authoritative baseline version can always be uniquely traced.
Prerequisites: Integrated change control
RPO (Recovery Point Objective)
The target point in time to which data must be recoverable after a failure occurs. A shorter RPO means less tolerable data loss and requires more frequent backups or replication. It is defined alongside RTO (time to recovery) to set BCP objectives.
RTO (Recovery Time Objective)
The target amount of time within which business operations or systems must be restored after a failure or disaster occurs. It is a distinct axis from RPO (how far back in time the data must be recovered) and serves as the basis for choosing backup methods and recovery procedures in a BCP or DR plan.
Change types (standard, normal, emergency)
Three categories of change in service management, distinguished by approval route and risk. A standard change is a pre-authorized, low-risk, repeatable change that needs no per-instance approval; a normal change is assessed and approved by the CAB for risk, impact, and schedule; an emergency change addresses an urgent situation such as an outage and is approved quickly by the ECAB, then documented afterward. The IT service manager decides which category each change belongs to, expanding the set of standard changes to reduce approval delay and assessment cost while keeping control.
Related: CAB (change advisory board) and ECAB
Configuration management (service management)
The activity of identifying, recording, and managing the configuration items (CIs) that make up a service and understanding the relationships among them. Maintaining accurate configuration information provides the basis for impact analysis of changes and releases, tracing the cause of incidents, and designing for availability. Its purpose differs from IT asset management, which focuses on financial value; configuration management centers on the accuracy of the relationships and states needed to deliver the service. The IT service manager designs controls to keep configuration information accurate and current so that other management activities can rely on it for decisions.
Prerequisites: Configuration item (CI)
Event management
The process that detects changes of state (events) in services or configuration items reported by monitoring tools, classifies them as informational, warning, or exception, and routes them to appropriate action. Through threshold monitoring it catches early signs of incidents and serves as the trigger for automated responses or notifications.
The four dimensions of service management
The four perspectives essential to delivering services and value effectively: organizations and people, information and technology, partners and suppliers, and value streams and processes. Neglecting any one dimension undermines the value of the service, so all must be examined in balance. A service manager assesses not only technology but also people, suppliers, and workflows when planning new or improved services.
Prerequisites: ITIL
Service value system (SVS)
The core ITIL4 concept describing how an organization as a whole takes demand and opportunity as input and produces value as output. Its center is the service value chain, surrounded by the seven guiding principles, governance, continual improvement, and practices. A service manager uses the SVS to view operations end to end—from demand to value—rather than optimizing individual activities in isolation.
Prerequisites: The seven ITIL4 guiding principles、Service value chain (SVC)
IT service continuity management (ITSCM)
ITSCM (IT service continuity management) develops, maintains, and rehearses continuity plans so that, even in events such as disasters or major failures, services can be recovered within the agreed RTO (recovery time objective) and RPO (recovery point objective); it forms part of business continuity planning (BCP). Recovery means, alternative facilities, and priority recovery order are defined in advance, and the plan's effectiveness is verified through periodic exercises. The IT service manager sets recovery objectives from business impact analysis and judges the balance between investment and recovery speed.
Prerequisites: RPO (Recovery Point Objective)、RTO (Recovery Time Objective)
Maximum tolerable period of disruption (MTPD/MAO)
The maximum tolerable period of disruption (MTPD, also MAO: maximum acceptable outage) is the longest service interruption the business can tolerate; beyond it the business suffers irrecoverable or severe damage. The recovery objective RTO (recovery time objective) must be set shorter than the MTPD/MAO to leave a margin. The IT service manager estimates the MTPD/MAO from business impact analysis and, treating it as the upper bound, designs the RTO, recovery strategy, and investment accordingly.
Prerequisites: RTO (Recovery Time Objective)
Release and deployment management
The activity of delivering approved changes into the production environment by building and testing them as a release unit and deploying them according to plan. Deployment approaches include big-bang, phased, and pilot (early) rollout, chosen according to risk and blast radius. Separating build-and-test from production deployment, and confirming the quality of the release package before rollout, limits the impact of failures. The IT service manager designs the release unit and deployment approach, factoring in backout and service downtime to control the transition.
Prerequisites: Change risk assessment and backout
Service desk and SPOC
The service desk acts as the Single Point of Contact (SPOC) between users and the service provider, centrally receiving inquiries and fault reports. Consolidating contact into one channel prevents users from being passed around and centralizes logging, status tracking, and ownership, improving response quality and user satisfaction.
Service level management (SLM)
The process that continually drives the definition, monitoring, review, and improvement of service level agreements (SLAs). It measures achievement against agreed service level targets and, when shortfalls or changes arise, feeds them through review into correction or renegotiation. Through SLM a service manager keeps customer expectations balanced with delivery capability and checks that underpinning agreements such as OLAs and UCs support the SLA targets.
Prerequisites: Service level objective (SLO)
Failover and failback
Failover is the mechanism or action of automatically switching processing to a standby system when the primary fails, preserving availability. Failback is returning processing to the original primary once it has recovered, from the standby that took over. The architect must design for data consistency and session takeover during failover, and for the brief interruption of switching back during failback.
Continual service improvement (CSI)
The ongoing effort to review and improve services and processes based on measured KPIs and metrics. It repeats the PDCA cycle of measuring the current state, analyzing gaps against targets, implementing improvements, and confirming their effect. Rather than ad hoc changes, a service manager prioritizes improvement targets on the basis of data and accumulates small improvements to raise service value continually. Note that "CSI (continual service improvement)" is ITIL v3 terminology for a dedicated lifecycle stage; in ITIL 4 it has evolved into continual improvement as a guiding principle and practice rather than a separate stage.
Prerequisites: ITIL、The seven ITIL4 guiding principles
JIS Q 20000 and the service management system (SMS)
A service management system (SMS) is the structured framework of service management policies, objectives, plans, and processes, operated and improved through the PDCA cycle. JIS Q 20000-1 specifies the requirements for an SMS and serves as the basis for third-party certification. Unlike ITIL, which is a body of best practice, JIS Q 20000 is a set of requirements to be met, and a service manager applies each according to purpose.
Prerequisites: ITIL
Knowledge management (SKMS)
The process that systematically accumulates and shares knowledge such as known errors, procedures, and FAQs to raise the efficiency and quality of support. The information base underpinning this is the Service Knowledge Management System (SKMS), which delivers the right information to the right staff at the right time, aiming to improve reproducibility of decisions and first-contact resolution. The SKMS is the top-level knowledge base (based on the DIKW model) that encompasses the CMS (configuration management system) and CMDB, while known errors themselves are held mainly in the KEDB (known error database).
Prerequisites: CMDB (configuration management database)、Known error (KEDB)
Proactive problem management
The aspect of problem management that finds and removes potential causes before incidents occur, preventing them proactively. It identifies weaknesses through trend analysis of past incidents and analysis of monitoring data, taking countermeasures in advance. It is the counterpart to reactive problem management, which responds after incidents happen.
Prerequisites: Problem management
Service level objective (SLO)
The measurable target value of a service level agreed with the customer within an SLA. Availability, response time, recovery time, and similar are defined as concrete figures or thresholds so achievement can be judged objectively. A service manager sets SLOs that are both achievable and matched to customer value, measures attainment through monitoring, and uses trends toward shortfall as grounds for improvement or renegotiation.
Capacity Management and Bottleneck Diagnosis
Capacity management continuously monitors traffic volume and utilization of links and devices to forecast and plan future upgrades. Bottleneck diagnosis compares utilization, delay, and drop rate across each segment of a path to pinpoint the segment with the highest load relative to capacity (i.e., utilization closest to 1 in queueing terms), narrowing down where reinforcement is needed. Traffic statistics from SNMP or NetFlow typically provide the underlying data.
Prerequisites: SNMP
SNMP
A protocol for monitoring and managing network devices. In addition to polling (GET) where the manager periodically queries agents, it has traps by which an agent proactively notifies on events. Management data is structured in a MIB (identified by OIDs). SNMPv3 adds authentication and encryption, resolving the plaintext-community weakness of v1/v2c.
Integrated change control
The process of receiving change requests, assessing their impact on scope, schedule, cost, and quality, and having a change control board approve, reject, or defer them before updating baselines. It prevents uncontrolled changes (scope creep) and keeps change impact managed consistently across the project.
Clustering (HA cluster, load-balancing cluster)
A technique that binds multiple servers together so they appear as a single system to users. A high-availability (HA) cluster aims to keep running by failing over to other nodes when one fails, while a load-balancing cluster distributes requests across nodes to raise throughput and concurrency. The architect chooses the configuration based on whether availability or performance is the goal, and designs for shared-disk arrangements and split-brain prevention.
Prerequisites: Failover and failback
SIEM (Security Information and Event Management)
A system that centrally collects logs from multiple sources — firewalls, IDS/IPS, servers, endpoints — and correlates them to surface attack indicators that would go unnoticed in any single log alone, raising them as alerts. It forms the core platform underpinning SOC monitoring work.
Prerequisites: Event management
CAB (change advisory board) and ECAB
The CAB (change advisory board) is a standing body that assesses the risk, impact, and schedule of normal changes and advises whether to proceed, bringing together technical, business, and user perspectives to support decisions. The ECAB (emergency change advisory board) is a small, fast-acting formation of just the few authorities needed to approve emergency changes when there is no time to convene the full CAB. The IT service manager designs the CAB agenda criteria and membership and switches to the ECAB in emergencies to balance assessment quality against speed.
Incident lifecycle
The sequence of stages an incident passes through from detection and logging to closure: detection/logging, categorization and prioritization, investigation and diagnosis, resolution and recovery, and closure. Following each stage reliably prevents gaps in handling and leaves a record that feeds problem management and knowledge accumulation.
Prerequisites: Problem management
Service asset and configuration management (SACM)
SACM (service asset and configuration management) manages, as an integrated whole, the service assets used to deliver a service together with their configuration information. It integrates the identification and management of assets with the management of configuration items (CIs) and the relationships among them, forming the basis for impact analysis and control of changes and releases. The IT service manager maintains the asset and configuration records as a single source of truth and designs processes to prevent divergence from reality, ensuring that decisions rest on trustworthy information.
Prerequisites: Configuration item (CI)