Incidents, problems and major incidents

At 09:12 on a Monday the payroll service slows to a crawl. Twenty-three people write or ring in the next fifteen minutes, the desk opens twenty-three separate tickets, and three hours later nobody can say which of them was picked up first or what had already been tried. The slowdown was never the hard part. The record was.

Four kinds of record keep that morning readable. The slowdown is an incident: a service working worse than it should, ended when people can work again. The fault behind it is a problem, a cause that keeps producing incidents until somebody removes it. That many tickets about one service in fifteen minutes cross the agreed trigger for a major incident, which runs differently: one owner, a bridge call, duplicates linked to one parent and an update every thirty minutes. Service requests and changes complete the four. Two programs replay that Monday, up to a post-incident review whose actions each name an owner and a date.

Four records, four owners, four endings

Twenty-three tickets for one outage is a filing mistake: twenty-three people each wait for their own answer and twenty-three technicians each start the same diagnosis. The cure is deciding what kind of record a report is before any work starts. An incidentincident: An unplanned interruption of a service, or a drop in its quality, that stops people working as they should. It is judged on how quickly the service becomes usable again, not on whether the cause is understood. is an unplanned interruption or a drop in quality of a service people use. A service requestservice request: A normal, planned ask for something the service catalogue already offers, such as a laptop, a mailbox or access to a folder. Nothing is broken, so it follows an authorisation route rather than an outage route. is a normal, planned ask that the catalogue already offers. A problemproblem: The record that owns the cause behind one or more incidents. It is judged on whether the cause is understood and gone, so a restart that restores a service ends an incident but never a problem. is the cause behind one or more incidents. A change adds, alters or removes something in the live service. Each has its own owner and its own ending:

The last column matters most on a bad morning. An incident is judged on how quickly people work again, so a restart that gets payroll moving counts as a success even though nothing is understood; a problem is judged on whether the cause is gone, so the same restart counts for nothing. Mixing the two is how a desk restarts one service every month-end for a year. The four records are a shared industry idea: PeopleCert’s ITIL catalogue, which lists ITIL 4 and ITIL (Version 5) courses, has separate practice courses for incident management, service request management, problem management and change enablement, whose course covers assessing a change’s risk, authorising it and managing the change schedule. This track teaches the same ideas in its own words.

Step through one Monday report and watch the four questions decide where it lands:

The step order is the order to ask in: a service hurting now outranks everything, because somebody cannot work while you file. One report can also produce two records, an incident today and a problem this week, which is normal rather than double counting.

Running a major incident takes one owner and one clock

A major incidentmajor incident: An incident declared on a trigger agreed in advance, such as ten tickets about one service inside fifteen minutes, and then worked differently: one named owner, a bridge call, duplicates linked to one parent and updates on a clock. is not a worse incident, it is a different way of working. The trigger is agreed in writing before the day it is needed, so nobody debates it at 09:19: for example, ten tickets about one service inside fifteen minutes, or any outage that stops money moving. Once it is declared, five things change at once. One incident managerincident manager: The one person who owns a declared major incident: they decide what is tried next, speak for the incident and keep its timeline. Nobody else reassigns the work while they hold it. owns the incident and nobody else reassigns the work. A bridge callbridge call: One open call that holds the service desk and the technical teams together for the length of a major incident, so that decisions are made in one place and written into one ticket. puts the desk and the technical teams on one line. Duplicate tickets are linked to one parent, so the queue shows one piece of work and the affected people behind it. Updates go out on a fixed status cadencestatus cadence: The fixed interval, often half an hour, at which a major incident's updates are published whether or not anything has changed, because silence is read as nobody working on it.. And one person keeps a timestamped incident timelineincident timeline: The time-ordered list of what happened during an incident, written as the events occur rather than from memory afterwards, each entry carrying a timestamp with its UTC offset. in the parent ticket as events happen, not from memory afterwards.

Walk the six stages, including what happens when the half-hour comes round and nothing has moved:

The cadence is the part most desks drop first and regret most. An update that repeats the last one still tells several hundred people that someone competent is on it; silence tells them all to ring the desk again. Each timeline entry carries an ISO 8601 timestampISO 8601 timestamp: A date and time written in the international ISO 8601 order, from the largest unit to the smallest, with a UTC offset after the time, as in a time written 14:05+05:30, or a trailing Z for UTC. More in “Ticket notes and handoffs people can use” with its offset, as ticket notes do, because readers tomorrow may sit in another zone; convert an entry from another desk with the timestamp converter or the timezone converter.

The program below is that Monday. It reads forty invented tickets arriving over twenty minutes, groups them by application, applies the ten-in-fifteen-minutes rule, links the duplicates and publishes the cadence:

"""A Monday morning on the service desk: 40 invented tickets arrive over
20 minutes. The program groups them by application, declares a major
incident when one service passes the threshold, links the duplicates to a
parent ticket and publishes a status update every 30 minutes.

Change THRESHOLD or WINDOW and run it again: the declaration, the parent
and the updates follow. Times are shown with a fixed +05:30 offset. Every
ticket, name and application here is invented.
"""

from datetime import datetime, timedelta, timezone

OFFSET = timezone(timedelta(hours=5, minutes=30), "+05:30")
OPENED = datetime(2027, 2, 15, 9, 0, tzinfo=OFFSET)

# How many tickets about one service, inside how long, declare a major incident.
THRESHOLD = 10
WINDOW = timedelta(minutes=15)
CADENCE = timedelta(minutes=30)

# (minutes after 09:00, application, what the caller said)
ARRIVALS = [
    (5, "email", "attachment will not open"),
    (6, "vpn", "disconnects every few minutes"),
    (7, "printing", "job stuck in the queue"),
    (8, "email", "search returns nothing"),
    (9, "vpn", "cannot reach the file share"),
    (10, "crm", "contact search is slow"),
    (11, "email", "signature image missing"),
    (12, "payroll", "payslip page times out"),
    (12, "payroll", "payslips will not load"),
    (13, "payroll", "spinning wheel on payslips"),
    (13, "payroll", "payroll says please try later"),
    (13, "printing", "duplex option greyed out"),
    (14, "payroll", "cannot open my payslip"),
    (14, "email", "calendar invite bounced"),
    (15, "payroll", "payroll very slow"),
    (15, "payroll", "payslip download fails"),
    (16, "payroll", "payroll times out at sign-in"),
    (16, "vpn", "slow on the guest network"),
    (17, "payroll", "month-end batch will not start"),
    (18, "email", "mailbox almost full warning"),
    (19, "payroll", "payroll unusable"),
    (19, "payroll", "payslip page blank"),
    (19, "printing", "wrong tray selected"),
    (20, "payroll", "payroll stuck at loading"),
    (20, "payroll", "cannot submit timesheets"),
    (20, "vpn", "prompts for the code twice"),
    (21, "payroll", "payroll error page"),
    (21, "payroll", "timesheet save fails"),
    (21, "crm", "report export is slow"),
    (22, "payroll", "payslips still down"),
    (22, "payroll", "payroll will not load at all"),
    (23, "payroll", "no payslip for this month"),
    (23, "payroll", "payroll keeps timing out"),
    (23, "email", "cannot send to a group"),
    (24, "payroll", "payroll down for my team"),
    (24, "payroll", "payslip page never finishes"),
    (24, "vpn", "drops when the laptop sleeps"),
    (25, "payroll", "payroll is still slow"),
    (25, "payroll", "cannot see my payslip"),
    (25, "printing", "prints only the first page"),
]

# The first update says the incident is owned; later ones say what was learned.
DECLARED = "{} is slow for everyone. Cause unknown. One ticket owns it now."

# What the responders learned, by minute after 09:00.
NOTES = {
    49: "Database lock waits are long. The overnight reporting job is still running.",
    109: "Reporting job named as the holder of the locks. Stopping it under an emergency change.",
    139: "Job stopped at 10:52. Response times normal since 11:10. Watching for 30 minutes.",
    169: "Normal for 30 minutes. Incident closed. A problem record carries the cause on.",
}
CLOSED_MINUTE = 169


def clock(moment):
    return moment.strftime("%H:%M") + "+05:30"


def minute_of(moment):
    return int((moment - OPENED).total_seconds() // 60)


def tickets():
    """One ticket per arrival, numbered in the order they reached the desk."""
    rows = []
    for number, (minute, app, text) in enumerate(ARRIVALS, start=1):
        rows.append({
            "id": "T-" + str(1400 + number),
            "at": OPENED + timedelta(minutes=minute),
            "app": app,
            "text": text,
        })
    return rows


def group_by_app(rows):
    groups = {}
    for row in rows:
        groups.setdefault(row["app"], []).append(row)
    return groups


def declaration(group):
    """The ticket whose arrival puts THRESHOLD tickets inside WINDOW, or None."""
    times = [row["at"] for row in group]
    for index in range(THRESHOLD - 1, len(times)):
        if times[index] - times[index - THRESHOLD + 1] <= WINDOW:
            return group[index]
    return None


def cadence(start, closed):
    """Update times: the declaration, then every CADENCE until the close."""
    moments = []
    moment = start
    while moment < closed:
        moments.append(moment)
        moment = moment + CADENCE
    moments.append(closed)
    return moments


def latest_note(after, upto):
    """The newest note learned after one update and up to the next, or None."""
    learned = [m for m in NOTES if minute_of(after) < m <= minute_of(upto)]
    return NOTES[max(learned)] if learned else None


rows = tickets()
groups = group_by_app(rows)

print("Tickets reaching the desk:", len(rows), "between",
      clock(rows[0]["at"]), "and", clock(rows[-1]["at"]))
print()
print("By application")
declared_app = None
declared_at = None
for app in sorted(groups, key=lambda name: -len(groups[name])):
    group = groups[app]
    trigger = declaration(group)
    verdict = "under the threshold"
    if trigger is not None:
        verdict = "MAJOR INCIDENT at " + clock(trigger["at"])
        if declared_at is None or trigger["at"] < declared_at:
            declared_app, declared_at = app, trigger["at"]
    print("  {:9} {:2} tickets  {}".format(app, len(group), verdict))

if declared_app is None:
    print()
    print("No application reached", THRESHOLD, "tickets inside",
          int(WINDOW.total_seconds() // 60), "minutes: no major incident is declared.")
else:
    group = groups[declared_app]
    parent = group[0]
    children = group[1:]
    print()
    print("Parent ticket", parent["id"], "opened for", declared_app,
          "- first report", clock(parent["at"]), "-", parent["text"])
    if children:
        print("Duplicates linked to it:", len(children),
              "(from", children[0]["id"], "to", children[-1]["id"] + ")")
    else:
        print("Duplicates linked to it: 0")
    print("The queue now shows 1 parent +", len(children), "linked children for",
          declared_app + ", and", len(rows) - len(group), "unrelated tickets.")
    print()
    print("Status updates, every 30 minutes")
    closed = OPENED + timedelta(minutes=CLOSED_MINUTE)
    moments = cadence(declared_at, closed)
    previous = None
    for moment in moments:
        if previous is None:
            note = DECLARED.format(declared_app.capitalize())
        else:
            note = latest_note(previous, moment)
            if note is None:
                note = "No change since " + clock(previous) + ". The bridge is still open."
        print(" ", clock(moment), note)
        previous = moment
    print()
    print("Updates published:", len(moments),
          "over", minute_of(closed) - minute_of(declared_at), "minutes.")

Tickets reaching the desk: 40 between 09:05+05:30 and 09:25+05:30

By application
  payroll   23 tickets  MAJOR INCIDENT at 09:19+05:30
  email      6 tickets  under the threshold
  vpn        5 tickets  under the threshold
  printing   4 tickets  under the threshold
  crm        2 tickets  under the threshold

Parent ticket T-1408 opened for payroll - first report 09:12+05:30 - payslip page times out
Duplicates linked to it: 22 (from T-1409 to T-1439)
The queue now shows 1 parent + 22 linked children for payroll, and 17 unrelated tickets.

Status updates, every 30 minutes
  09:19+05:30 Payroll is slow for everyone. Cause unknown. One ticket owns it now.
  09:49+05:30 Database lock waits are long. The overnight reporting job is still running.
  10:19+05:30 No change since 09:49+05:30. The bridge is still open.
  10:49+05:30 Reporting job named as the holder of the locks. Stopping it under an emergency change.
  11:19+05:30 Job stopped at 10:52. Response times normal since 11:10. Watching for 30 minutes.
  11:49+05:30 Normal for 30 minutes. Incident closed. A problem record carries the cause on.

Updates published: 6 over 150 minutes.

Payroll crosses the line at 09:19, on its tenth ticket, while email at six tickets and the virtual private network at five stay ordinary incidents. The parent takes 22 linked children, so the queue holds eighteen pieces of work instead of forty, and six updates cover the 150 minutes to the close. Press Edit, set THRESHOLD to 15 and run it again: the declaration moves to 09:21, five payroll callers later, which is the argument to have in a quiet week rather than during an outage.

A problem record owns the cause, not the restart

Three closed incidents with the same symptom mean the desk is paying for one fault again and again. A problem record is where that cause goes to live: the symptoms seen, the evidence from each incident, the workaroundworkaround: A safe, temporary way for a user to keep working while the real fix is still to come. It does not remove the cause, so it is logged as a known issue until the cause is fixed. More in “Difficult calls, VIPs and clean escalations” people are using meanwhile, and eventually the root causeroot cause: The condition that makes a fault happen. Fixing it stops the fault from coming back, while fixing only a symptom, or working around it, leaves the cause in place. More in “A troubleshooting method that holds under pressure”. It is deliberately slower than an incident, which wants somebody working again in minutes.

Two words are worth getting exactly right. A workaround is a safe, temporary way to keep working that leaves the cause in place: retry payroll after 11:00, run the batch in the afternoon. A known errorknown error: A problem whose cause is understood and whose workaround is written down, so the next caller can be answered in a minute instead of being diagnosed from the beginning again. is a problem whose cause is understood and whose workaround is written down, which is what lets the next caller be answered in a minute instead of diagnosed from scratch. Follow the same slowdown from three tickets to the work that ends it:

Nothing in a problem record removes a cause by itself. Moving the job to 02:00 and restoring a dropped index is work on the live service, so it goes through change management: assessed for risk, scheduled, with a way back if it goes wrong. The problem closes when that change has run and the quiet mornings have held, and the known error is kept so the desk can recognise the shape if it ever returns.

A blameless review asks what let it happen

A post-incident reviewpost-incident review: The document written after an incident: a summary, the impact in numbers, a timeline, the root cause with its contributing factors, what went well, and actions that each carry an owner and a date. is the written record of what happened, what it cost, how it was handled, why it was possible and what will change. Google’s site reliability engineering book, which publishes the practice its teams use, describes a blameless reviewblameless review: A post-incident review that looks for the conditions which let a fault happen rather than the person who acted, on the assumption that everyone did something sensible with the information they had. as one that looks for the contributing causes “without indicting any individual or team”, on the assumption that everyone acted sensibly with the information they had. The practical test is the question you ask: not “who ran the job” but “what let a job run seven hours over its window without anyone being told”.

Six headings make a review usable by a stranger: a summary, the impact in numbers, a timeline, the root cause and its contributing factors, what went well, and what to do with an owner and a date on each action. The last is where most reviews fail. “Improve monitoring” is not an action; “alert when payroll lock waits pass 5 s; owner: platform team; by: 2027-02-23” is, because a date written largest unit first can be checked by anyone and an owner can be asked. The linter below holds both rules and reads two invented reviews:

"""Check a post-incident review: the six sections it needs, and an owner
plus an ISO 8601 date on every action.

The reviews below are invented. Only the shape of the document is checked,
never whether its wording is true.
"""

REQUIRED_SECTIONS = [
    "Summary",
    "Impact",
    "Timeline",
    "Root cause and contributing factors",
    "What went well",
    "What to do (owner, date)",
]

ACTION_SECTION = "What to do (owner, date)"

DAYS_IN_MONTH = [31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]


def split_sections(review_text):
    """Return the heading of each '## ' section mapped to its body lines."""
    sections = {}
    heading = None
    for raw in review_text.splitlines():
        line = raw.strip()
        if line.startswith("## "):
            heading = line[3:].strip()
            sections[heading] = []
        elif heading is not None and line:
            sections[heading].append(line)
    return sections


def is_iso_date(token):
    """True for an ISO 8601 calendar date, 2027-02-16 and no other shape."""
    if len(token) != 10 or token[4] != "-" or token[7] != "-":
        return False
    parts = token.split("-")
    if not all(part.isdigit() for part in parts):
        return False
    year, month, day = (int(part) for part in parts)
    if not 1 <= month <= 12:
        return False
    limit = DAYS_IN_MONTH[month - 1]
    if month == 2 and not (year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)):
        limit = 28
    return 1 <= day <= limit


def read_action(line):
    """Pull the owner and the date out of one action line."""
    owner = None
    date = None
    for field in line.lstrip("-").split(";"):
        field = field.strip()
        lowered = field.lower()
        if lowered.startswith("owner:"):
            owner = field[len("owner:"):].strip() or None
        elif lowered.startswith("by:"):
            candidate = field[len("by:"):].strip()
            date = candidate if is_iso_date(candidate) else None
    return owner, date


def lint(review_text):
    """Report the sections a review is missing and its faulty action lines."""
    sections = split_sections(review_text)
    missing = [name for name in REQUIRED_SECTIONS if name not in sections]

    actions = [line for line in sections.get(ACTION_SECTION, []) if line.startswith("-")]
    faults = []
    for line in actions:
        owner, date = read_action(line)
        short = line.lstrip("- ").split(";")[0]
        if owner is None and date is None:
            faults.append(short + " -> no owner and no ISO 8601 date")
        elif owner is None:
            faults.append(short + " -> no owner")
        elif date is None:
            faults.append(short + " -> no ISO 8601 date")

    return {
        "missing_sections": missing,
        "actions": len(actions),
        "action_faults": faults,
        "ready": not missing and not faults and bool(actions),
    }


def report(name, review_text):
    result = lint(review_text)
    print(name)
    print("  sections found   :", len(REQUIRED_SECTIONS) - len(result["missing_sections"]),
          "of", len(REQUIRED_SECTIONS))
    if result["missing_sections"]:
        for heading in result["missing_sections"]:
            print("  missing section  :", heading)
    print("  actions checked  :", result["actions"])
    if result["action_faults"]:
        for fault in result["action_faults"]:
            print("  action fault     :", fault)
    print("  ready to publish :", "yes" if result["ready"] else "no")
    print()


WEAK = """
## Summary
Payroll was slow for about two hours on Monday morning.

## Impact
Around 300 staff could not open payslips. Nobody could run the month-end batch.

## Root cause and contributing factors
A reporting job held locks on the payroll database for longer than expected.

## What to do (owner, date)
- Add an alert on lock wait time; owner: platform team; by: soon
- Move the reporting job out of office hours; by: 2027-02-23
- Write a runbook for payroll slowdowns; owner: service desk
"""

STRONG = """
## Summary
Payroll slowed to a crawl for 1 h 58 min on Monday morning and recovered when a
reporting job was stopped.

## Impact
Around 300 staff could not open payslips between 09:12 and 11:10. The month-end
batch started 2 hours late and finished inside its window.

## Timeline
- 09:12 first ticket: payslip page times out
- 09:19 tenth payroll ticket arrives; major incident declared
- 09:20 parent ticket opened on the first report; 22 duplicates linked to it
- 09:45 lock waits traced to the overnight reporting job, still running
- 10:52 reporting job stopped
- 11:10 response times back to normal; incident closed at 11:49

## Root cause and contributing factors
The reporting job ran 7 hours longer than its usual 40 minutes after a new index
was dropped, and held locks the payroll pages needed. Nothing alerted on lock
wait time, so the desk learned about it from users.

## What went well
The first responder scoped the outage in 7 minutes. Linking duplicates to one
parent kept the queue readable for the whole two hours.

## What to do (owner, date)
- Alert when payroll lock waits pass 5 s; owner: platform team; by: 2027-02-23
- Restore the dropped index and record it in the CMDB; owner: database team; by: 2027-02-18
- Run the reporting job at 02:00 under a change request; owner: platform team; by: 2027-03-02
- Add a payroll slowdown runbook with the parent-ticket step; owner: service desk; by: 2027-03-09
"""

report("Weak review", WEAK)
report("Strong review", STRONG)

Weak review
  sections found   : 4 of 6
  missing section  : Timeline
  missing section  : What went well
  actions checked  : 3
  action fault     : Add an alert on lock wait time -> no ISO 8601 date
  action fault     : Move the reporting job out of office hours -> no owner
  action fault     : Write a runbook for payroll slowdowns -> no ISO 8601 date
  ready to publish : no

Strong review
  sections found   : 6 of 6
  actions checked  : 4
  ready to publish : yes

The weak review loses two of the six headings, and all three of its actions fail: one gives “soon” as its date, one names no owner and one has no date at all. What the linter cannot judge is whether the cause named is the real one, so a document can pass every structural rule and still be useless. That is also why the strong review’s “what went well” section is not decoration: it keeps the habits that held.

A security incident takes a different road

Some incidents must leave the normal path the moment you recognise them. A laptop that encrypts its own files, a sign-in from a country nobody travelled to, a mailbox quietly forwarding to an outside address: these are security incidents, and the desk’s job is to recognise, preserve and hand over, not to investigate. Spotting the hand-off is the skill; the investigation belongs elsewhere. Three habits that help on an ordinary outage are reversed on this path:

NIST’s SP 800-61 Revision 3 sets out how an organisation plans for this; its own aim is to help organisations “prepare for incident responses, reduce the number and impact of incidents”. It arranges the work around the functions of the Cybersecurity Framework, and it is the reference to read before writing your desk’s hand-off page. One of its outcomes, RS.AN-07, wants incident data and its metadata collected with their integrity and provenance kept intact, which is why the desk does not wipe, restart or tidy a suspect machine before the security contact says what to do with it. CompTIA’s A+ Core 2 objectives (220-1202, objective 4.6) put the same duties under incident response: a chain of custodyThe written record of who held a piece of evidence, such as a laptop or a copy of its disk, and when, from the moment it was collected, so nobody can later claim it was changed., informing management, preserving the data and documenting the incident.

Practise: lint a post-incident review

Rebuild the review section’s linter yourself. The exercise gives you the six headings and asks for the problems in a fixed order: missing sections first, then each action’s missing owner or date. The sample tests cover a ready review, missing and empty sections, an action with no owner whose only date is “soon”, and dates that only look real, such as a leap day in a year that has none.

REQUIRED_SECTIONS = [
    "Summary",
    "Impact",
    "Timeline",
    "Root cause and contributing factors",
    "What went well",
    "What to do (owner, date)",
]

ACTION_SECTION = "What to do (owner, date)"

DAYS_IN_MONTH = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]


def lint_pir(review_text):
    """Return the problems of one post-incident review as a list of strings.

    An empty list means the review is ready to share.
    """
    problems = []
    # Your code here.
    return problems

from lint_pir import lint_pir

BODIES = {
    "Summary": "Payroll pages were slow for 1 h 58 min on Monday morning.",
    "Impact": "Around 300 staff could not open payslips.",
    "Timeline": "- 09:12 first ticket\n- 09:19 major incident declared",
    "Root cause and contributing factors": "A reporting job held locks the payroll pages needed.",
    "What went well": "Duplicates were linked to one parent ticket.",
}


def review(actions, drop=()):
    """A review with every section except those in drop; actions are the lines of the action section."""
    parts = [f"## {name}\n{body}" for name, body in BODIES.items() if name not in drop]
    if "What to do (owner, date)" not in drop:
        parts.append("## What to do (owner, date)\n" + "\n".join(actions))
    return "\n\n".join(parts) + "\n"


GOOD = "- Alert when payroll lock waits pass 5 s; owner: platform team; by: 2027-02-23"


def test_ready_review_has_no_problems():
    """a review with all six sections and a complete action is ready"""
    assert lint_pir(review([GOOD])) == []


def test_missing_sections_in_order():
    """missing headings are listed in the order of the required list"""
    text = review([GOOD], drop=("Timeline", "Impact"))
    assert lint_pir(text) == ["missing section: Impact", "missing section: Timeline"]


def test_no_action_section_stops_there():
    """without the action section only the missing headings are reported"""
    assert lint_pir(review([], drop=("What to do (owner, date)",))) == ["missing section: What to do (owner, date)"]


def test_empty_action_section():
    """an action section without a single action line is reported"""
    assert lint_pir(review([])) == ["no actions listed"]


def test_action_without_owner_and_date():
    """an action with no owner and a date of soon has both problems, owner first"""
    text = review([GOOD, "- Write a runbook for payroll slowdowns; by: soon"])
    assert lint_pir(text) == ["action 2: no owner", "action 2: no ISO 8601 date"]


def test_leap_day_only_in_a_leap_year():
    """29 February exists in 2028 but not in 2027"""
    ok = "- Restore the dropped index; owner: database team; by: 2028-02-29"
    bad = "- Move the reporting job; owner: platform team; by: 2027-02-29"
    assert lint_pir(review([ok, bad])) == ["action 2: no ISO 8601 date"]


def test_century_years_follow_the_400_rule():
    """2000 is a leap year and 2100 is not"""
    ok = "- Restore the dropped index; owner: database team; by: 2000-02-29"
    bad = "- Move the reporting job; owner: platform team; by: 2100-02-29"
    assert lint_pir(review([ok, bad])) == ["action 2: no ISO 8601 date"]


def test_a_letter_in_the_date_is_not_a_date():
    """a capital O typed for a zero makes the date invalid"""
    assert lint_pir(review(["- Alert on lock waits; owner: platform team; by: 2027-O2-23"])) == [
        "action 1: no ISO 8601 date"
    ]

The questions below cover all five ideas, from sorting a report to the security hand-off. They adapt as you answer, so a right answer at one level brings a harder one next.

Interview questions

Warm-up (fresher): A finance user emails “please give me access to the new reports folder”. Another emails “the reports folder is empty, the whole department has lost its files”. Which one is a service request, which is an incident, and what do you do first with each?

Access to a folder the catalogue already offers is a service request: nothing is broken, so the first move is to raise it on the standard route and ask who authorises that folder, never to grant it myself. An empty folder that a whole department relied on is an incident, and a wide one, so impact comes before cause: I scope who is affected and whether the files are unreachable or really gone, then say the narrowest version back in one sentence for the user to correct. If the whole department is affected I check the major-incident trigger before touching anything, because other callers are probably already dialling. Missing files also raise a question I do not settle alone, whether this is a restore job or a security matter, and that decides who it goes to next.

The two questions below ask for the same skills on other days: a night when you are alone on the desk and one fault hides behind three applications, and the review of an outage that a supplier’s change set off. Plan your opening moves on both before you open either.

Key takeaways

• Four records answer four different questions: an incident restores a service, a service request delivers something normal, a problem owns the cause behind incidents, and a change alters the live service.
• A major incident is declared on a trigger agreed in advance, owned by one named incident manager, worked on a bridge call, filed as one parent with its duplicates linked, and published on a clock whether or not anything has moved, because silence reads as nobody working on it.
• A problem record carries the symptoms, the workaround and the cause; a known error is a problem whose cause is understood and whose workaround is written down; only a change through change management removes the cause.
• A blameless post-incident review asks what let the fault happen rather than who caused it, and every action names an owner and a date so it can be checked later.
• A suspected security incident leaves the normal path at once: preserve the device and the logs, tell the named contact, hand over rather than investigate.