Why LinkedIn endorsements are meaningless (and some ITIL Foundation exam study tips)

According to my LinkedIn profile, 25 people have endorsed me for IT Service Management skills. Until last month* my entire knowledge of IT Service Management came from watching Karl McCarthy present at the Northampton branch of the BCS, which does leave me wondering about the value of LinkedIn endorsements…

…still, over the last few weeks, I have been learning about IT Service Management (or at least, about the IT Infrastructure Library, usually abbreviated to ITIL®).

Those who follow this blog will have seen my recent 6-part series of preparation notes as I studied for my ITIL Foundation certification (see the end of this post) and my efforts were clearly worthwhile, as I passed the exam today. A non-disclosure agreement prevents me from commenting on the exam itself but I will highlight the resources that I used:

So, that’s another certification in the bag (and one of my 2016-17 objectives ticked off…). Now time to put the theory into practice, which for me will mean some more thinking about service architecture in the course of my work.

I was going to continue this blog with some notes from Karl’s 2015 talk on “IT Service Management – Putting the theory into practice” but the notes appear to have gone AWOL. Maybe that’s one to save for another day…

 

* Putting aside anything I’ve picked up from 20+ years working in IT.

Further Reading

This post and those linked above (which were written and published prior to taking the exam, so they do not breach any NDA). are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.

Preparation notes for ITIL Foundation exam: Part 6 (continual service improvement)

Last month I started a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification:

This post continues by looking at the topic of the fifth and final stage in the ITIL service lifecycle: continual service improvement (CSI).

Continual Service Improvement

Generally, the performance of a service can be improved upon – that’s where CSI comes in:

“Focuses on increasing the efficiency, maximising the effectiveness and optimising the cost of services and the underlying ITSM processes.”

Terms:

  • Kaizen:
    • Japanese term that means continuous improvement (literally, “change good”). Small steps.
  • IT Governance:
    • Defining expectations, assign power, verify performance. Has everything been done that should be.
    • Enterprise (business); Corporate (regulatory); IT (management, rules, regulations and framework of IT department).
  • CSI register:
    • Database/record of improvement opportunities. Part of the Service Knowledge Management System (SKMS).

“If you can’t describe what you’re doing as a process, you don’t know what you’re doing” [William Edwards Deming]

Seven Step Improvement Process:

  1. Identify the strategy for improvement.
  2. Define what you will measure. (Because you can’t control what you can’t measure!)
  3. Gather the data.
  4. Process the data. Turn it into information.
  5. Analyse the information and data. Identify actions.
  6. Present and use the information. Changes to be made.
  7. Implement improvement.

Deming cycle (actually it’s not Deming’s work – but he’s often credited):

  • Plan.
  • Do.
  • Check. On progress.
  • Act. Maybe need another iteration…

The CSI Approach:

  1. What is the vision? Business goals, etc.
  2. Where are we now? Establish baselines.
  3. Where do we want to be? Set target (measurable).
  4. How do we get there? Process improvement – gap analysis, defined goals.
  5. Did we get there? Measure and check metrics.
  6. How do we keep up the momentum? Look to go around again…

Wrap-up

That’s the end of this series – by the time you read this, I’ll be on my way to the exam testing centre…

40 questions, multiple choice, 60 minutes. £168.

Fingers crossed, creating these notes will help me – and I hope they help you out too.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.

Preparation notes for ITIL Foundation exam: Part 5 (service operation)

Last month I started a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification:

This post continues by looking at the topic of the fourth stage in the ITIL service lifecycle: service operation.

Service Operation

Service operation has both processes and functions:

  • Processes (the “how”):
    • Event Management.
    • Incident Management.
    • Problem Management.
    • Request Fulfilment.
    • Access Management.
  • Functions (the “who”):
    • Service Desk.
    • Technical Management.
    • IT Operations.
    • Application Management.

Goals of service operation:

“Maintain business satisfaction and confidence in IT through effective and efficient delivery and support of agreed IT services.”

(i.e. for the services you have agreed to provide)

“Minimise the impact of service outages on day-to-day business activities.”

“Ensure that access to agreed IT services is only provided to those authorised to receive those services.”

(i.e. security)

There is a continuous balancing act/conflict between:

  • Internal IT vs. external business services.
  • Stability vs. speed of response.
  • Cost of service vs. quality of service.

Service Desk

Not just incident/problem management but all of the processes – fulfilling requests, managing access and communicating about events.

ITIL recognises four service desk structures :

  • Local service desk:
    • Co-located with user community.
    • Local knowledge/language.
    • Expensive (multiple desks).
    • Possibly less knowledge transfer and inconsistent service.
  • Centralised service desk:
    • All locations contact a central desk, possibly with second-line behind it and various specialist teams (e.g. for technical management, application management, request fulfilment, third party).
    • Reduces operational costs; simplified contact.
    • Lose local knowledge and possibly language barriers.
    • Single point of failure.
  • Virtual service desk:
    • Looks like centralised but resources in different locations.
    • May route requests to teams in different locations (e.g. server support) – match skills to requirement.
    • High rollout costs; inconsistent service and reporting; hard to monitor staff.
    • Knowledge exchange may be difficult with remote staff.
  • Follow-the-sun service desk:
    • Route calls to where people are awake, e.g. 3 desks for Asia, EMEA, Americas.
    • Works well in global scenarios.
    • Hand over to another location at end of shift so knowledge transfer is improved.
    • Expensive to maintain, needs technology to ensure connection; language constraints.
    • Staff need business understanding as well as communications skills.

Increasingly, self-help service-desk functionality is part of the solution (e.g. automated phone service, direction to websites, etc.).

Technical, IT Operations and Application Management

Technical Management:

“Helps plan, implement and maintain a stable technical infrastructure to support the operations business processes.”

(Managing Technical Infrastructure, Networking, etc.)

IT Operations Management:

“Defines the department, group or team of people responsible for performing the day-to-day operational activities.”

(Managing operations – control: monitoring, backups, etc. – facilities, etc.)

Application Management:

“Working together with Technical Management, ensures that the knowledge required to design, test and manage IT services is there for resources to use.”

(Managing the applications within their lifecycle.)

Together these functions ensure that there is a stable balance for services to provide to customers.

Incident and Problem Management

An incident:

“Concentrates on restoring unexpected degradation of services or disrupted services.”

An incident is an unplanned interruption or reduction in quality of service.

A problem:

“Involves root cause analysis to determine underlying causes of incidents”

Looking at a series of incidents, possibly a trend.

Terms:

  • Escalation:
    • Assign additional resources to meet service level targets of customer expectations.
    • Types:
      • Functional: transfer incident to technical team with higher expertise.
      • Hierarchical: go to a senior level of management.
  • Impact:
    • Measure of the effect of the incident on the business process.
  • Incident (Major):
    • Unplanned interruption to IT service, or reduction in quality.
    • Major is highest category – total service disruption.
  • Resolution:
    • Action used to repair root cause of incident or problem.
  • Urgency:
    • How long until the incident or problem impacts the business.
  • Workaround:
    • Reduce/eliminate the impact of the problem, before a resolution is in place.
  • Known Error Database (KEDB):
    • Database of known errors. Part of the Configuration Management System (CMS).
  • Proactive Problem Management:
    • Identify problems that will be missed otherwise, and take action before they happen.
  • Problem (Major):
    • The cause of one or more incidents.
  • Root cause:
    • The underlying or original cause of an incident or problem.
  • Threat:
    • Anything that might exploit a vulnerability.
Incident Management

“To restore normal service operation as quickly as possible and minimise the adverse effect on business operations, ensuring agreed levels of service quality are maintained.”

Diagnosis and getting back up to speed as quickly as possible.

Open-In progress-Resolve-Close broken into 9 steps:

  1. Identification. Service desk call, or monitoring leads to an incident.
  2. Logging. Record all incidents (with a reference number).
  3. Categorisation. Type of incident for effective escalation (and reporting).
  4. Prioritisation. Run incidents through a matrix. Impact + Urgency = Priority.
  5. Initial diagnosis. First line scripts, etc.
  6. Incident escalation. VIPs may get more attention!
  7. Investigation and diagnosis. Identify the error, look for events that may have triggered the incident.
  8. Resolution and recovery. Apply and test fix (in a controlled manner).
  9. Incident closure. Ensure users are satisfied, etc. Document into problem management and KEDB.
Problem Management

“To manage the lifecycle of all problems from first identification through eventual removal. It seeks to minimise the adverse impact of incidents and problems and to proactively prevent recurrent of related errors due to incidents.”

Root cause analysis (RCA) is at the heart of problem management.

Reactive:

  1. Problem detection.
  2. Problem logging.
  3. Problem categorisation.
  4. Problem prioritisation (urgency + impact).
  5. Diagnosis (leading to RCA).
  6. Workarounds.
  7. Raising a “known error” (KEDB).
  8. Problem resolution.
  9. Problem closure. Major problem review to understand lessons that have been learned for the future (what went well, what didn’t?)

Proactive:

  1. Trend analysis – look for trends in incidents.
  2. Root cause analysis.
  3. Targeted prevention – cost benefit analysis and target areas that need most support, co-ordinated with availability and capacity management.

Event and Access Management

Event Management: How to make sure that the configuration items that are changing during rollout of a service continue to function.

“Event Management’s purpose is to manage events through their lifecycle. The lifecycle is detecting events, making sense of them and determining the appropriate control action.”

Access Management: Who gets access to a service or information necessary to continue a service.

“Access Management’s purpose is to provide the right for users to use a service, while preventing access to non-authorised users.”

Terms:

  • Alert: a notification that an item needs to be changed (e.g. a threshold is met).
  • Event: any change of state in a configuration item (e.g. software patching).
  • Rights: who can access a service or information.
Event Management

Dealing with configuration items – assets used to deliver IT service. Also environmental conditions, software licencing, performance metrics.

  • Informational events – logged.
  • Warning events – e.g. meeting a threshold.
  • Exception events – e.g. malware alert, CPU spike,
Access Management
  1. Request access.
  2. Verification. Verify that the person requesting access is who they say they are.
  3. Provide rights.
  4. Monitor identity status. May change status (e.g. if no longer subscribing to a service).
  5. Logging and tracking access. Locking for anomalies.
  6. Removing or restricting rights. e.g. after security breach or when no longer have permission to access the service.

Request fulfilment

“Request fulfilment helps maintain user and customer satisfaction by managing the lifecycle of all service requests from users.”

Terms:

  • Request Model. Documenting the activities necessary to fulfil a request, associated timescales, etc.
  • Service Request. Formal request for service – open a ticket – that can be managed. Known and planned for.

Service requests to fulfil are pre-defined (in the Service Knowledge Management System – SKMS):

  • Menu selection. To find the right service (e.g. request a new laptop).
  • Request tracking. System to track the request as it moves through the lifecycle.
  • Financial approval. May not be needed for some services if there is no fiscal impact (e.g. a password reset).
  • Other approval. Compliance, regulatory impact, etc.
  • Fulfilment. Service desk takes action.
  • Closure. Once the service request has been completed. Log into SKMS.

Some services may be handled in an automated fashion – self-service/self-help.

Wrap-up

The next post in this series will follow soon, looking at continual service improvement.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.

Restart a Raspberry Pi Zero with a paperclip

One of the “limitations” of a Raspberry Pi is that it doesn’t have an on/off switch. That’s not really a problem – once it’s shut down, a power cycle to the socket (switch on/off) will allow it to boot up but there is another way (ignoring the purchase of expensive in-line power switches*, or daughter boards to make the Pi pick up an infra-red remote control signal).

Alex Eames blogged details to fit a reset switch to a Raspberry Pi (which I may well do) but what about the Raspberry Pi Zero? My son uses one of these plugged into our TV to practice his Python programming and it’s plugged into a USB wall socket so a power cycle restarts several USB devices or alternatively, cables need to be pulled.

Well, a bit more reading led me to the idea of shorting GPIO pins 5 and 6, and then some experimentation showed me all I have to do it touch pin 5 with a bent paperclip to turn on the Pi!

So, shutdown as normal from the OS. And startup with a “hotwiring” trick!

I’ve since found that the Pi Zero can also be started by shorting the two pins labelled “Run” next to GPIO 37 and 39 (connect the pins and then disconnect again) – so it’s also possible to fit a switch in a similar manner to Alex Eames’ advice for the full-size Pi.

One thing to be aware of if a switch is fitted is that it can be used to turn on the Pi but shouldn’t be used to turn it off as it just kills the power and could lead to software corruption or even hardware damage.

 

*Incidentally, whilst writing this post I came across an inexpensive in-line USB switch. I haven’t tested one but some might find it useful, with the same caveat as the DIY option…

Preparation notes for ITIL Foundation exam: Part 4 (service transition)

Last month I started a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification:

This post continues by looking at the topic of the third stage in the ITIL service lifecycle: service transition.

Service Transition

Service transition is concerned with moving from service design to operation:

  • Plan and manage service changes with efficiency.
  • Successfully deploy the new or changed services.
  • Make sure that the service changes meet the agreed requirements.
  • Educate people with the appropriate knowledge and information about services and assets.
  • Manage risk.

Benefits include:

  • Enable more accurate cost, timing and resource requirements.
  • Make it easier for people to adopt and follow.
  • Reduce delays due to unexpected clashes and dependencies.
  • Improve expectation setting for all stakeholders.
  • Ensure that new or changed services will be maintainable.
  • Improve control of service assets and configurations.

ITIL defines the following Service Transition processes, which are expanded upon in the rest of this post:

  • Transition planning and support.
  • Change management.
  • Knowledge management.
  • Service asset and configuration management (SACM).
  • Release and deployment management.
  • Change evaluation.
  • Service validation and testing.

(the last of these are not discussed in detail for ITIL Foundation level.)

Transition Planning and Support

Focuses on the transition of the service, not the service itself. Co-ordinate resources, plan for them, make sure requirements are met, coordinate activities across service teams.

“To provide overall planning for service transitions and to co-ordinate the resources that they require.”

Terms:

  • Release Policy.
    • Service assets with people, each with responsibilities for handover and acceptance of the release:
    • 3 types:
      • Major release – new functionality, maybe removing tactical changes from the past.
      • Minor release – small enhancements, fixes.
      • Emergency release – updates (usually relating to security).
    • Make sure Service Knowledge Management System (SKMS) is up-to-date.
    • Understand Service Acceptance Criteria (SAC).
  • SDP Lifecycle
    • All the information including service charter, budgets, timescales, definition and design of releases, making sure everyone has what they need to succeed.

Change Management

Unexpected change is often received negatively – by managing change we can keep people happy.

“To control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption of IT services.”

Change is the addition, modification or removal of anything that could have an effect on the IT services.

One set of study materials I used referred to an Adventures of Ace, DBA comic strip by Steve Karam where multiple changes are causing issues that are hard to track down. It’s a good example of the issues that poor change management can introduce.

Steve Karam's Adventures of Ace, DBA comic on Changes

Terms:

  • Change Advisory Board (CAB):
    • Group of people who assess, advise on and authorise changes.
  • Emergency CAB (ECAB):
    • CAB for emergency changes.
  • Request for Change (RFC):
    • Formal request for a change to be made.
  • Change Model:
    • Approach to managing change, e.g. based on impact:
      • Normal change (follows all the steps of the change process)
      • Emergency change (needs to be implemented right away)
      • Standard change (pre-approved, rarely need additional authorisation); low risk, common procedure (work instruction) – e.g. new employee account, laptop, etc.; password reset; etc.
  • Change Record:
    • Details of the change lifecycle (actions taken)
    • For both accepted and rejected changes
    • Change Proposal:
      • Overall view of the change to be introduced. High level description, details of change, business case, implementation schedules, etc.

Remediation planning:

  • Ensuring there is roll-back plan to go to the previous milestone in the change.
  • Not all changes are reversible so there may be another plan to move around problems.

The Change Manager is the person who administers RFCs, prepares RFCs for CAB/ECAB; authorises/rejects changes based on CAB advice.

Knowledge Management

Does everyone know what’s going on?

“To share perspectives, ideas, experience and information; to ensure that these are available to the right place at the right time to enable informed decision; reducing the need to rediscover knowledge.”

Goals:

  • User, service desk, support staff and supplier understanding of the new or changed service.
  • Awareness of the use of the service and the discontinuation of previous versions.
  • Establishment of the acceptable risk and confidence levels associated with the transition.

Terms:

  • Data, Information, Knowledge and Wisdom (DIKW) Chart:
    • Data is just the facts (e.g. logs from monitoring tools).
    • Provide context to become information (e.g. in documents, email) – need to manage to find and reuse (e.g. to deliver service). Who, what, when, where?
    • Knowledge is based on past experience, ideas, values, etc. – dynamic and context-based for decision-making. How?
    • Wisdom can be thought of as “applied knowledge” – create value through correct and well-informed decisions. Why?
  • Service Knowledge Management System (SKMS):
    • Contains information needed to manage services
    • Includes Configuration Management System (CMS), which itself contains the Known Error Database (KEDB) and Configuration Management Database (CMDB)
    • Also includes:
      • Staff – experience/skills.
      • Suppliers – abilities.
      • Users – education.

Service Asset and Configuration Management

“To ensure that the assets required to deliver services are properly controlled and that accurate and reliable information about those asses is available when and where it is needed.”

Ensuring all configuration items are configured appropriately and that relationships are known.

Terms:

  • Service Asset:
    • Any resource or capability of a service provider.
  • Configuration Item (CI):
    • Any component or service asset that needs to be managed to deliver a service (with associated scope).
  • Attribute:
    • Information about the asset: serial number, capabilities, location, etc.
  • CI Type:
    • Ways to classify configuration items (hardware, software, personnel, etc.)
  • Component:
    • Smaller piece of a larger environment
  • Configuration Baseline:
    • Configuration that has been set and agreed upon in change management.
    • Starting point for changes, or target to roll back to in remediation.
  • CMDB and CMS:
    • Store information about Service Assets
  • Relationship:
    • Connection between CIs – e.g. an application relationship to a server.
    • Between CIs in scope and out of scope (e.g. between PSTN and PBX)
  • Verification and Audit:
    • Making sure information is up to date and accurate.
    • Formalised check.

SACM activities – not a cycle – these are interconnected:

  • Planning:
    • Define objectives, processes, procedures, scope, naming conventions, types, etc.
  • Identification:
    • Inventory of what/where systems exist.
    • Creation of baselines.
    • Control:
      • Information placed in CMDB and modifications are controlled/authorised.
      • Change Management will help with this.
    • Status Accounting:
      • Reporting (during and after transition).
    • Verification and Audit:
      • Constantly ensuring items are recorded, up-to-date and have no unapproved changes.

Release and Deployment Management

What is coming when?

“To plan, schedule and control the build, test and deployment of releases. To deliver new functionality required by the business while protecting the integrity of existing services.”

Includes all of the processes, systems, functions to help package, build test and deploy release into service operation (live use). Works hand-in-hand with service validation and testing (see below).

One set of study materials uses an analogy of a film release: which is created, written, filmed – then released. Planning – which cinemas, what date, when is the red carpet premier, etc. – are all part of release and deployment management.

Terms:

  • Deployment:
    • AKA Rollout
    • Activity responsible for movement of new or changed hardware/software/documentation to the live environment
  • Release:
    • Change to IT service that has been built tested and deployed together.
  • Release Package:
    • A set of configuration items that will be built, tested and deployed together as a single release.
    • Get from current baseline to target baseline
  • Release Record:
    • The record that defines the content of the release.
    • Relationship with all configuration items affected by the release
  • Release Unit:
    • The components of the service that are released together. e.g. hardware, software and associated end-user documentation.
  • Build:
    • Number to refer to the configuration items that create the IT service being deployed.
    • May be a date/number.
  • Definitive Media Library (DML):
    • One or more locations where authorised versions of software are placed (may include licenses, documentation, etc.)
  • Release Policy:
    • Formal documentation that defines the strategy for releases (from service design).
    • Governing policy document for release and deployment.
    • What constitutes major or minor releases, deliverables, remediation policy for rollback, how/where releases are documented, etc.?

Overview:

  • Service design has release policy.
  • Start putting together release packages.
  • Service validation and testing to make sure release packages look OK (e.g. soft release).
  • Release.
  • Remediate if necessary.

Deployment options:

  • Parallel (big bang).
  • Phased.

Four phases:

  1. Release and Deployment Planning.
  2. Release Build and Test:
    • To DML.
  3. Deployment:
    • With change management authorisation.
  4. Review and close:
    • Experience, feedback, lessons learned, etc.

Change Evaluation

(Not covered in ITIL Foundation.)

Once changes have been deployed, how are they working out? Goes hand-in-hand with Change Management.

Service Validation and Testing

(Not covered in ITIL Foundation.)

Make sure all is working. Goes hand-in-hand with Release and Deployment Management

Wrap-up

The next post in this series will follow soon, looking at service operation.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.

Preparation notes for ITIL Foundation exam: Part 3 (service design)

Last month I started a series of preparation notes as I study for my IT Infrastructure Library (ITIL®) Foundation certification:

This post continues by looking at the topic of the second stage in the ITIL service lifecycle: service design.

Service Design

“To design IT services, together with the governing IT practices, processes and policies to realise the service provider’s strategy and to facilitate the introduction of these services into supported environments, ensuring quality service delivery, customer satisfaction, and cost-effective service provision”

Service design’s value to the business is:

  • Reduction in total cost of ownership.
  • Improvement of quality of service, consistency, implementation of new or ongoing services.
  • Business/organisation strategic alignment.
  • Improvement in IT governance.
  • Streamlined IT processes.
  • Efficient decision-making and ITSM.

It translates the concepts in the service strategy into hard and fast design.

There are four perspectives of ITSM:

  • People – need input from stakeholders, end users, others.
  • Products – services (not always physical products).
  • Processes – to create the service design package.
  • Partners – to work with in delivery (e.g. suppliers).

The output from service design is one or more service design packages (SDPs) containing:

  • Requirements.
  • Service design.
  • Organisational readiness assessment.
  • Service lifecycle plan.

There are five aspects of service design:

  1. Service solutions – for new or changed services – from the service portfolio.
  2. Management information solutions – able to support new or changed services.
  3. Technical architectures – frameworks used to make sure service solutions are designed, implemented and consistent across the entire organisation.
  4. Processes – skills, processes, responsibilities to roll out new or changed services.
  5. Measurement methods and metrics.

ITIL defines the following Service Design processes, which are expanded upon in the rest of this post:

  • Supplier management.
  • Service level management.
  • Service catalogue management.
  • Availability management.
  • Capacity management.
  • Information security management.
  • Design coordination.
  • IT Service continuity management.

Supplier Management

“Ensures that suppliers and the services they provide are managed to support IT service targets and business expectations. Also, it obtains value for money from suppliers and contracts, while ensuring contracts with suppliers are aligned to business needs.”

Terms:

  • Supplier – any third party supplying goods or services required to deliver services.
  • Supplier and Contract Management Information System (SCMIS) – tools used to support supplier management, integrated with the Service Knowledge Management System (SKMS).
  • Underpinning Contract – contracts with third parties for supply.
    • Basic terms and conditions.
    • Service description and scope – constraints etc.
    • Service standards – minimum levels that constitute acceptable performance and quality.
    • Workload ranges – which standards for what pricing.
    • Management information – data to be reported by supplier on performance – critical success factors and/or key performance indicators.
    • Responsibilities and dependencies – obligations of third party supplier and organization.

Supplier categorisation is used to assess how much time to spend on each supplier – either value/performance-based or risk/impact-based:

  • Strategic – significant partners in immediate and long term.
  • Tactical – business interaction and a lot of contact; manage performance.
  • Operational – needed for day-to-day work (e.g. software licence provider).
  • Commodity – low-level products that could be bought from many locations.

Supplier management activities deal with underpinning contracts (UCs):

  • Define any new suppliers (e.g. to meet new needs).
  • Evaluate new suppliers (make sure contract will be good).
  • Place contracts into SCMIS (categorised).
  • Supplier contract management (ongoing) to ensure service level criteria are being met (checking quality/cost, periodic reviews), manage relationship.
  • Contract termination/renewal.

Service Level Management

Hitting the targets that supplier and customer have agreed on.

“Ensures that all current and planned IT services are delivered to agreed achievable targets. This is accomplished with a constant cycle of negotiating, agreeing, monitoring and reviewing IT Service Targets and Achievements.”

Terms:

  • Service Improvement Plan (SIP):
    • Formal plans to help improve a process or service due to SLA breaches, training needs, weak systems, customer complaints, etc.
  • Service Level Agreement (SLA):
    • Based on underpinning contract and OLA (see below).
    • Types:
      • Service-based (SLA to provide a single service).
      • Customer-based (SLA for all services used by a customer – e.g. by geography).
      • Multi-level (SLA for Corporate, Customer and Service levels).
  • Common elements:
    • Introduction.
    • Service Description.
    • Mutual Responsibilities (service goes both ways – there may be requirements on the customer too).
    • Scope (defining targets).
    • Service Hours.
    • Service Availability.
    • Customer Support Information.
    • Contacts and Escalation Policy.
    • Security.
    • Costs and Charging Methods.
  • Service Level Requirement (SLR):
    • Based on customer business objectives.
  • Service Level Agreement Monitoring (SLAM) Chart:
    • Regular reporting.
  • Organisation Level Agreement (OLA):
    • Sometimes referred to as underpinning agreements.
    • Make sure that internal suppliers (e.g. support teams) will help meet the SLA targets agreed with the customer.

Service Catalogue Management

“To provide and maintain a single source of consistent information on all operational services and those being prepared to run operationally. To ensure that it is widely available to those who are authorised to view it”

The Service Catalogue is a database or structured document with information about all live IT services, including those available for deployment. It is the only part of the service portfolio that is published to customers:

  • Deliverables.
  • Prices.
  • Contracts.
  • Ordering and Requests.
    • How to make the request – not the request itself!

Two views:

  • Business Service Catalogue:
    • Customer-facing services.
  • Technical Service Catalogue:
    • Support services, configuration items, etc.

Availability Management

“To ensure that the level of availability delivered in all IT services meets the agreed availability needs and/or service level targets in a cost-effective and timely manner. This is both current and future needs of the business.”

Objectives:

  • Provide advice and guidance to all other areas of the business and IT on availability.
  • Produce an up-to-date availability plan.
  • Help diagnose and resolve problems.

Respond with:

  • Reactive activities:
    • Monitoring.
    • Looking back at past incidents.
  • Proactive activities:
    • Planning, designing, updating.

Terms:

  • Availability:
    • Ability of the IT service or configuration item to perform its agreed function when required. Usually calculated as a percentage.
  • Availability Management Information System (AMIS)
  • Downtime:
    • Time when not available (e.g. when performing maintenance).
    • = Mean Time to Restore Service (MTRS).
    • Includes detection time, diagnosis time, repair time and restoration time.
  • Reliability:
    • How long can perform without interruption (uptime).
    • = Mean Time Between Failures (MTBF).
  • Resilience:
    • Coping with interruptions/time between issues.
    • = Mean Time Between System Incidents (MTBSI).
  • Response Time:
    • Time taken to respond to an incident.
  • Risk:
    • An event that can cause harm or loss to an objective (a threat). Conversely, opportunities are about the possibility of doing something.
    • So risk is associated with the impacts of doing or not doing something (including mitigations).
  • Vital Business Function:
    • Any critical thing that you have to have.
  • Serviceability:
    • Ability of suppliers to meet terms of contracts.

Capacity Management

“To ensure that the capacity of IT services and the IT infrastructure meets the agreed capacity and performance related requirements in a cost-effective and timely manner. It meets both the current and future capacity and performance needs of the business.”

Objectives:

  • Produce and maintain an appropriate/up-to-date plan.
  • Assist with diagnosing and resolving performance/capacity issues.
  • Ensure all performance achievements meet all of their agreed targets.

Terms:

  • Capacity:
    • The maximum amount of delivery ability that an IT service can provide (e.g. bandwidth, storage).
  • Capacity Management Information System (CMIS).
  • Modelling:
    • Predicting future behaviour of a system or service item, e.g. if increase use of the service.
    • Analyse using performance monitoring data.
  • Tuning:
    • Customising the use of resources in appropriate quantities.
    • Analyse using performance monitoring data.
  • Business Capacity Management:
    • Plan to meet business needs and requirements.
  • Service Capacity Management:
    • About performance of the services themselves.
    • Prediction of end-to-end performance.
  • Component Capacity Management:
    • About the capacity of individual components (network, servers, applications, etc.).
  • Performance monitoring:
    • Monitoring performance of components of the service.
  • Demand management:
    • Comes from service strategy.
    • Balance costs and required resources; supply and demand.
  • Capacity planning:
    • Forecasting when more (or less) capacity will be needed.
  • Application Sizing:
    • Ability to support new or modified applications and know what their capacity requirements will be.

Information Security Management

“To align IT security with business security and ensure that the confidentiality, integrity and availability of the organisation’s assets, information, data and IT services matches the agreed needs of the business.”

Terms:

  • Confidentiality:
    • Ensuring information remains confidential.
  • Risk Management:
    • Assess and manage/control risks.
  • Security Management Information System (SMIS).
  • Information Security Policy:
    • A list of rules/requirements to follow.
  • Threat:
    • Exploits vulnerabilities (e.g. denial of service).
  • Vulnerability:
    • Weakness exploited by threats (e.g. open network ports).

The Information Security Management System:

  • Guides the development and management of an information security programme.
  • Formal process.
    • Cycle of:
      • Plan: identify measures, procedures, requirements (e.g. regulatory), etc.
      • Implement: put the above in place.
      • Control: making sure documentation is present, all in order.
      • Evaluate: audit for compliance.
      • Maintain: making sure agreements are documented and improved upon (CSI).
  • Includes:
    • Physical security (e.g. of devices).
    • Procedural security: how to secure things.
    • Organisational security: security policies, etc.

Design Coordination

“To provide and maintain a single point of co-ordination and control for all activities and processes within this stage of the service lifecycle.”

Includes:

  • Activities relating to the overall service design lifecycle stage.
  • Activities relating to each individual design.
    • Based on service design packages (SDPs).

IT Service Continuity Management

Dealing with “Disaster Recovery”.

  • Business Continuity Plan:
    • Business Impact Analysis.
  • IT Service Continuity Plan:
    • Triggers, actions, etc.

Recovery Operations (in order of urgency):

  • Immediate: hot standby/swap (e.g. load balancing/mirroring).
  • Fast: recover within a few minutes.
  • Intermediate: warm standby (e.g. restore data from backup).
  • Gradual: cold standby (restore non-critical services over time).

Roles:

  • Board: crisis management and company-level control.
  • Senior management: direct and co-ordinate; authorise spending money.
  • Management: reporting on progress.
  • Supervisors and staff: execute plan.

Wrap-up

The next post in this series will follow soon, looking at service transition.

These notes were written and published prior to sitting the exam (so this post doesn’t breach any NDA). They are intended as an aid and no guarantee is given or implied as to their suitability for others hoping to pass the exam.

ITIL® is a registered trademark of Axelos limited.

Shortlisted for the UK Blog Awards 2017 #UKBA17

UK Blog Awards 2017 FinalistA few weeks ago, I wrote about being nominated in the UK Blog Awards 2017 and encouraged readers to vote for markwilson.it. This morning, I received an email which said:

“We are delighted to advise that your content has reached the final stage in the UK Blog Awards process as a Digital and Technology individual finalist.”

Thank you to everyone who voted. The winners will be announced at an awards ceremony in April and there’s some stiff competition as I’m up against 7 great blogs but it’s brilliant to even get this far!

Bulk renaming digital photos for easier identification

Managing digital content can be a pain sometimes. Managing my own photos is bad enough (and I have applications like Adobe Lightroom to help with my Digital Asset Management) but when other family members want help whilst sorting through thousands of photos from multiple cameras to make a calendar or a yearbook it can get very messy.

For a long time now, I’ve used a Mac app called Renamer to bulk rename files – for example, batches of photos after importing them from my camera.  The exception to this is my iPhone pictures, which Dropbox rather usefully renames for me on import using the date and time, suffixing as necessary to deal with HDRs, etc. I only have a couple of gigabytes on Dropbox, so I move the renamed files to OneDrive (where I have over a terabyte of space…). The problem with this is that there needs to be enough space on Dropbox for the initial import – which means I have to use a particular PC which recognises my iPhone and remembers which photos have previously been imported. If I use another PC it will try and re-import them all (and fail due to a lack of available space)…

My wife has a different system. She also uses OneDrive for storage but has some files that have been renamed by Dropbox (to yyyy-mm-dd hh.mm.ss.jpg), some that have been renamed on import by something else (to yyyymmdd_hhmmsssss_iOS.jpg) and some that are just copied directly from the iPhone storage as IMGxxxx.jpg. My task? To sort this lot out!

Multiple images with the same time stamp

We decided that we liked the Dropbox name format. So that became the target. I used Renamer to rename files to Year-Month-Day Hour.Minutes.Seconds.jpg (based on EXIF file data) but the presence of HDR images etc. meant there were duplicates with the same time where a whole second wasn’t fine-grained enough. We needed those fractions of a second (or a system to handle duplicates) and Renamer wasn’t cutting it.

The fallback was to use the original filename as a tie-break. It’s not pretty, but it works – Year-Month-Day Hour.Minutes.Seconds (Filename).jpg gave my wife the date/time-based filename that she needed and the presence of the original filename was a minor annoyance. I saved that as a preset in Renamer so that when I need to do this again in a few months, I can!

Renaming digital photos in Renamer using a preset

No EXIF data

Then the files with no EXIF data (.MOVs and .PNGs) were renamed using a similar preset, this time using the modification date (probably less reliable than EXIF data but good enough if the files haven’t been edited).

Thousandths of seconds

Finally, the files with the odd format. Mostly these were dealt with in the same was as the IMGxxxx.jpg files but there were still some potential duplicates with the same EXIF timestamp. For these, I used progressive find and replace actions in Renamer to strip away all but the time a RegEx replacing ...... with nothing allowed me to remove all but the last three characters (I originally tried .{3}$ but that removed the 3 characters I actually wanted from the tail end that represent thousandths of seconds). One final rename using the EXIF data to Year-Month-Day Hour.Minutes.Seconds.Filename.jpg gave me yyyy-mm-dd hh.mm.sssss.jpg – which was close enough to the desired outcome and there were no more duplicates.

What’s the point? There must be a better way!

Now, after reading this, you’re probably asking “Why?” and that’s a good question. After all, Windows Explorer has the capability to provide image previews, the ability to sort by date, etc. but it’s not up to me to question why, I just need an answer to the end-user’s question!

Using Renamer is reliant on my Mac – there are options for Windows like NameExif and Stamp too. I haven’t used these but it appears they will have the same issues as Renamer when it comes to duplicate timestamps. There’s also a batch file option that handles duplicate timestamps but it doesn’t use the EXIF data.

Meanwhile, if anyone has a script that matches the Dropbox file rename functionality (including handling HDRs etc. which have identical timestamps), I’d be pleased to hear from you!

[Update 1 January 2017: These Python scripts look like they would fit the bill (thanks Tim Biller/@timbo_baggins) and James O’Neill/@jamesoneill reminded me of ExifTool, which I wrote about a few years ago]

Recovering data when the Zwift iOS app crashes whilst saving an activity

One of the most popular posts on the blog at the moment is about recovering data when a Garmin cycle computer crashes whilst saving an activity. It’s great to know that my experience has helped others to recover their ride data and I’m hoping that this post will continue in the same vein… but this time it’s about Zwift.

You see, earlier this week, I decided to try out the new Zwift app for iOS. It’s much easier to use my iPhone than to take a PC out to the garage and use a mobile app as a bridge between the turbo trainer and the Wi-Fi network. Instead, it’s all taken care of in the app.

Unfortunately, after an hour on the trainer, I went to end my ride and Zwift told me it couldn’t log me in (and refused to let me in on the iPhone until I forcibly closed the app).  Logging in on another device told me that partial ride data had been captured for the first 10 minutes but that was it.  I wasn’t happy and my usual petulant self resorted to a whinge on Twitter, to which I was really surprised to get a reply from the team at Zwift:

A few minutes later I logged a support call and was directed to some advice that helped me recover the .FIT file created on my device by Zwift:

If you’re riding on iOS, you can reach your .fit file through iTunes.
1. Plug your device into your computer and open up iTunes.
2. Click on your device in iTunes, then click “Apps” and scroll down to the “File Sharing” section.
3. You should see Zwift listed, and it should have a “Zwift” folder. Click that, and then click “Save To” and save it to a location of your choice.
4. Find the saved Zwift folder, and copy the fit file out of the Zwift/Activities folder.

After this, I could upload the .FIT file to Strava (though not to Zwift itself… apparently this is “a highly requested feature” and “as such, [Zwift are] exploring adding it in the future”):

My first attempt at home automation: Alexa-controlled Christmas tree lights!

I’ve wanted to play with some home automation tech for a while now but the absence of clear standards and relatively high cost of entry (with many of the popular systems requiring a hub) put me off. We also have the relatively unusual situation in that there is nearly always someone in our house, so even the idea of a smart thermostat to turn down the heating when we’re out (e.g. Nest, Hive, etc.) is not a good fit for our lifestyle.

Then, a few weeks ago, I bought myself an Amazon Echo Dot. My business case was weak. After all, voice controlling my Spotify playlists is a bit of a novelty (and not all of the “skills” that are available in the US are available over here in the UK) but I could see there was potential, especially once IFTTT support comes to the UK (which it finally did, last week).

Over the weekend, I decided to take things a little further and to see if I could control some lights. I wasn’t getting far with the fixed infrastructure in the house (due to challenges with a lack of a hub and B22 vs. E27 light fittings meaning I’ll need to convert some of the light pendants too…) but my colleague Richard Knight (@rmknight) suggested a TP-Link Smart Plug and I picked up a TP-Link HS110 on Amazon. Then it was a case of deciding which lights to control – and I went for the Christmas Tree lights…

After a fairly simple setup process (using TP-Link’s Kasa mobile app) I had the switch working from my phone but then I took things a step further… voice control with Alexa. Kasa and Alexa are integrated so after enabling the skill in Alexa and linking to Kasa, I was able to control the lights with my voice:

Everything I’ve described so far was just a few minutes’ effort – remarkable straightforward out-of-the-box stuff. Being a geek, I started to think what else I could use to control the Smart Plug and I found an excellent post from George Georgovassilis (@ggeorgovassilis) on controlling a TP-Link HS100 Wi-Fi Smart Plug. In the post, George sniffs the network to work out exactly how the smart plug is controlled and he provides a shell script, then others have chipped in with C# and Go options. I had to find which IP address my Smart Plug was using (looking at the DHCP server leases told me that, then a MAC address lookup confirmed that the unknown device starting 50:c7:bf was indeed a TP-Link one).  Using the compiled C# code I successfully controlled my HS110, switching the lights on/off from the command line on a PC.

So, last year saw a miniature Raspberry Pi-powered Christmas Tree (featuring my terrible soldering) – this year I’m controlling the full tree lights using mainstream components – I wonder what Christmas 2017 will bring! And my second Echo Dot is arriving today…