Дежурства и инциденты: нагрузка, которую легко не заметить

Задайте команде один вопрос: сколько часов за прошлый квартал ушло на дежурства и разбор инцидентов? Вы получите три разных ответа, и все три будут заниженными. Дежурный вспомнит только ночи, когда что-то реально сломалось; планировщик скажет «ну это же фон»; в трекере не найдётся почти ничего — инцидент длиной в двадцать пять минут никто не заводит задачей.

Это единственная работа в команде, которая не попадает ни в план, ни в оценку результатов, ни в отчёт наверх — и при этом исправно попадает в заявления об уходе. Не потому, что тяжелее остальной, а потому, что невидима по устройству: распределена по ночам, состоит из мелких кусков, компенсируется тихо. Глава — про операционную нагрузку как управленческий объект; техническая сторона (SLO, устройство алертинга, инструменты) разобрана в главах Наблюдаемость и дежурства и Наблюдаемость распределённых систем.

Дежурство как контракт, а не как график

«У нас есть дежурство» обычно означает «есть табличка с именами». Табличка — это расписание. Дежурство как управленческая конструкция состоит из шести пунктов, и у каждого есть наблюдаемое нарушение.

Проверка простая: попросите любого члена команды за пять минут написать эти шесть пунктов по памяти. Если ответы расходятся, у вас нет дежурства — у вас есть привычка, которая держится на нескольких добросовестных людях и развалится в тот момент, когда один из них уйдёт в отпуск.

Отдельно про полномочия: ночью человек принимает решения за вас — с вашим уровнем риска и без вашей подписи. Если дежурный не вправе откатить релиз без вас, вы не делегировали дежурство, а добавили себе ночной телефон через посредника; механика передачи прав — в главе Делегирование.

Честно про доказательную базу

Сразу разделим, что известно из исследований, а что — отраслевая привычка.

Довольно надёжно известно (медицина и психология труда — сотни работ, метаанализы, но почти все не про разработчиков):

• Прерванный и сокращённый сон ухудшает внимание и качество решений на следующий день; обзор дежурств — Nicol A.-M., Botterill J. On-call work and health (Environmental Health, 2004). Вывод устойчив через десятки исследований.
• Сама доступность стоит дорого, даже если звонков не было. Дежурство без единого вызова ухудшает настроение и восстановление, потому что человек не может психологически отключиться (Dettmers J. et al., Extended work availability and its relation with start-of-day mood and cortisol, JOHP, 2016). Практический вывод: «у него смена была спокойная» — не аргумент.
• Возможность отключиться от работы (исследования Sonnentag S. про psychological detachment) предсказывает выгорание лучше, чем количество отработанных часов; смежная тема — в главе Выгорание.
• Ретроспективное искажение: зная исход, люди систематически считают его более предсказуемым, чем он был (Fischhoff B., 1975). Отсюда — фраза «он должен был заметить» на разборе почти всегда неверна.

Отраслевая практика без исследовательской базы — то, что работает у крупных компаний, но контролируемых сравнений нет:

• Ориентиры Google SRE: не более двух инцидентов за 12-часовую смену, потолок операционной работы в 50% времени команды (Being On-Call). Инженерная норма компании, а не результат эксперимента.
• Роли в инциденте — заимствование из Incident Command System пожарных служб США; внятная версия для разработки — руководство PagerDuty. Доказательств «с ролями инциденты короче» в открытом виде нет.
• Безобвинительный разбор — идея из авиации и работ по человеческому фактору (Dekker S.), перенесённая в индустрию статьёй Джона Оллспоу (Etsy, 2012). Механизм проверяем локально (люди перестают скрывать детали), но «безобвинительные разборы повышают надёжность» строго не показано.

И один популярный показатель, который не стоит использовать как цель. MTTR (среднее время восстановления) плохо ведёт себя на реальных данных: распределение длительностей сильно скошено, среднее неинформативно, выборки малы — вывод из отчётов VOID, открытой базы публичных разборов. Показывать наверх динамику MTTR почти всегда означает показывать шум; про искажения инженерных метрик вообще — в главе DORA и инженерные метрики. И последнее: количественные данные про дежурства получены на врачах, пожарных и сменных производствах, так что перенос на разработку — аналогия, а не доказательство.

Почему нагрузку не видно

Невидимость — не следствие халатности, а следствие устройства. Четыре механизма работают одновременно.

1. Работа не создаёт артефакта. Задача в трекере оставляет след, ночной откат — нет. Не завели карточкой — в истории команды инцидента не существует.
2. Куски слишком мелкие. Двадцать пять минут никто не считает работой; двадцать пять минут в 02:14 — это половина следующего дня, но этой связи не видно нигде.
3. Цена платится не там, где возникла. Плата за ночь наступает завтра днём: медленнее код-ревью, хуже решения, раздражительность на встрече — и всё это спишут на характер.
4. Кто-то тихо компенсирует. В любой команде есть человек, который «просто посмотрит» в чужую смену. Пока он есть, нагрузка выглядит распределённой.

Ключевая величина — не длительность инцидента, а время возвращения к работе. Исследования прерываний (Mark G. и соавторы, The Cost of Interrupted Work, 2008) дают порядок в двадцать с лишним минут на возврат к прежней задаче — и это для дневного прерывания у бодрого человека. Ночью восстановление измеряется не минутами.

Арифметика, которую можно посчитать за полчаса

Числа — пример, не норматив; ценность в том, что после подстановки своих величин появляется цифра, которую можно положить на стол. Команда из шести человек, недельная ротация, 13 смен за квартал, в среднем 1,5 ночных вызова на смену.

ночных вызовов за квартал     = 13 × 1,5  ≈ 20
за год                        = 20 × 4    ≈ 78
на человека при ротации из 6  = 78 / 6    ≈ 13 разбуженных ночей в год
если ночь стоит полдня работы = 78 × 0,5  ≈ 39 человеко-дней ≈ 2 человеко-месяца

Два человеко-месяца, которых нет ни в одном плане квартала. Коэффициент 0,5 — оценка, а не измерение; замените его своим наблюдением, и он всё равно не будет нулём. Смысл упражнения в другом: пока нагрузка не выражена в тех же единицах, что и планы, она проигрывает любому обсуждению приоритетов автоматически. Почему «заложим 10% на непредвиденное» обычно не работает — в главе Планирование и оценки.

Что измерять

Рабочий минимум. Все величины считаются по выгрузке из системы оповещений и не требуют новых процессов.

Двух метрик в списке нет намеренно. MTTR — по причинам выше. Количество инцидентов как цель — потому что оно управляется классификацией: стоит начать требовать снижения, и часть инцидентов перестанет так называться. Это прямое следствие закона Гудхарта, и наблюдается в первом же квартале.

Считать можно чем угодно; вот минимальный вариант на Python, чтобы было видно, что это полчаса работы, а не проект.

from collections import Counter
from dataclasses import dataclass
from datetime import datetime

@dataclass(frozen=True)
class Page:
    ts: datetime      # когда сработало оповещение
    engineer: str     # кто был на смене
    acted: bool       # человек что-то изменил в системе
    deferrable: bool  # по итогу разбора могло подождать до утра
    cause: str        # нормализованная причина, а не текст алерта

def report(pages: list[Page], shifts: int) -> dict[str, float]:
    """Сводка операционной нагрузки. O(n) по времени, O(k) по памяти,
    где n — число вызовов, k — число уникальных дежурных и причин."""
    total = len(pages)
    if total == 0:
        return {"вызовов": 0.0}
    by_person = Counter(p.engineer for p in pages)
    by_cause = Counter(p.cause for p in pages)          # повтор — причина с count > 1
    busy = len({(p.engineer, p.ts.isocalendar().week) for p in pages})
    share = lambda n: round(n / total, 2)
    return {
        "вызовов на смену": round(total / shifts, 2),
        "доля ночных": share(sum(1 for p in pages if p.ts.hour >= 23 or p.ts.hour < 7)),
        "доля с действием": share(sum(p.acted for p in pages)),
        "доля отложимых": share(sum(p.deferrable for p in pages)),
        "доля повторов": share(sum(c for c in by_cause.values() if c > 1)),
        "доля спокойных смен": round(max(shifts - busy, 0) / shifts, 2),
        "концентрация на одном": share(by_person.most_common(1)[0][1]),
    }

Поле deferrable заполняется человеком, а не системой, и в этом весь смысл: кто-то должен раз в неделю пройти по списку ночных вызовов и сказать, какие были напрасными. Пятнадцать минут в неделю; если этого не делает никто, всё дальнейшее бессмысленно — вы не узнаете, что чинить.

Гигиена алертов — управленческая задача, а не техническая

Разработчик может починить порог у одного алерта. Решение «мы удаляем всё, что не поднимает человека» принимает руководитель, потому что цена ошибки в обе стороны несимметрична и кто-то должен взять её на себя. Рамка — два вопроса к каждому сигналу: требует ли он действия человека и нужно ли действовать сейчас.

Левый верхний квадрант — источник большинства ночных побудок: сигнал выглядит срочным («5xx подскочили!»), но человек ничего не делает — пока он открывает ноутбук, всё уже вернулось. Такому алерту не нужна аккуратная настройка, ему нужен порог по длительности или удаление.

Два правила с наблюдаемым нарушением.

Правило владельца. У каждого правила оповещения есть имя человека и ссылка на инструкцию. Нарушение: дежурный получает алерт и идёт спрашивать в общий чат, что это значит. Последствие: время реакции определяется не системой, а тем, кто первым проснулся и ответил.

Правило чистки. Алерт, который за квартал ни разу не потребовал действия, удаляется или понижается до дашборда — по умолчанию, с правом любого вернуть его с объяснением. Нарушение: список правил только растёт. Последствие: через год дежурный отключает уведомления на телефоне, и вы узнаёте об этом на первом пропущенном критичном инциденте.

Второе правило встречает сопротивление в формате «а вдруг именно в этот раз». Ответ арифметический: если из 310 прерываний действия потребовали 88, вы уже платите за «а вдруг» 222 напрасных прерывания в квартал — просто эта цена никем не выставлена.

Инцидент глазами руководителя

Ваша роль в инциденте почти всегда не техническая. Это контринтуитивно для человека, который вчера был самым сильным инженером в комнате, и это первое, что ломается — см. Из инженера в лида.

Два перехода стоят отдельного внимания. S5 --> S6 — расследование в рабочее время: искать причину в четыре утра силами уставшего человека дороже и хуже, чем восстановить работу и разобраться днём. S8 --> X1 — выводы, съеденные квартальными целями; механика ровно та же, что с квотой на технический долг.

Роли и главная ошибка лида

Роли сводятся к трём функциям: координатор решает, кто что делает и когда эскалировать; расследующий работает руками; коммуникатор говорит наружу. В маленькой команде их совмещают, но координатор и расследующий не должны быть одним человеком — тот, кто в консоли, теряет обзор через десять минут.

Правило с наблюдаемым нарушением: если вы в инциденте набираете команды в терминале дольше пяти минут, значит вашу роль сейчас никто не исполняет. Последствие видно сразу: наружу полчаса ничего не сообщалось, а внутри трое делают одно и то же. Что вы делаете вместо этого:

• Объявляете инцидент явно. Пока никто не сказал «это инцидент», все считают происходящее чьей-то отдельной проблемой. Объявление — переключение режима, а не оценка масштаба; ошибиться в сторону объявления дёшево.
• Держите внешний контур. Первое сообщение стейкхолдерам — в первые минуты, без причин и прогнозов; дальше по расписанию, даже когда сказать нечего: «нового нет, следующее сообщение в 14:20». Тишина воспринимается хуже плохих новостей.
• Снимаете лишнее. Отменяете встречи расследующего, отвечаете вместо него, не даёте пяти любопытным задать один и тот же вопрос.
• Меняете уставших. К пятому часу тот, кто ведёт инцидент с начала, принимает заметно худшие решения. Смена — ваше решение, не его.
• Останавливаете. «Больше не чиним сегодня, откатываемся, продолжаем утром» — решение руководителя: у инженера внутри инцидента нет для него ни дистанции, ни разрешения.

Эскалация, которой пользуются

Политика эскалации — часть дежурства, где ошибка стоит дорого в обе стороны: не разбудили вовремя — инцидент длиннее; будят по любому поводу — ротация бессмысленна. Работает формулировка «сомневаешься — эскалируй; за лишнюю эскалацию не бывает последствий», и у неё есть проверяемое следствие: если за квартал не было ни одной эскалации, оказавшейся ненужной, порог у людей стоит выше объявленного и они терпят. Ноль ложных срабатываний — не повод для гордости, а симптом.

Второе, что ломает эскалацию, — вы сами. Если вас разбудили в три ночи и вы ответили с раздражением, вы только что подняли всей команде порог обращения к вам и ближайшие полгода будете узнавать о проблемах позже. Цена одной интонации в три ночи выше цены самого инцидента.

Третье: эскалация должна вести к человеку с полномочиями, а не к следующему такому же дежурному. Если ночью нужно разбудить смежную команду, а у вашей нет такого права, эскалация упирается в переписку до утра. Это не техническая проблема, а вопрос границ между командами — тема следующей главы.

Ротация: справедливость, допуск и невидимый налог

Квартал ротации выглядит на бумаге ровно, а на деле состоит из трёх слоёв, из которых план знает только один.

Три вещи чаще всего оказываются несправедливыми, и все три решаются руководителем, а не «договорённостью команды».

Кто вообще в ротации. Если в ней половина команды, вторая половина растёт быстрее — у неё нет операционных прерываний. Со временем это превращается в незапланированную разницу в грейдах (механика оценки — в главе Оценка и рост). Обратная крайность — «дежурят все, включая того, кто в компании три недели», и тогда вы получаете инцидент, в котором дежурный не знает, где логи.

Допуск. Дежурство — квалификация, а не расписание. Разумная последовательность: сопровождение опытного дежурного → обратное сопровождение (действует сам, опытный рядом) → дневные смены соло → полные смены. Условие перехода называется заранее, иначе оно превратится в «когда лид почувствует, что готов». Это часть адаптации новичка, а не отдельный процесс.

Невидимый налог носителя знания. В любой команде есть человек, к которому идут в чужую смену, потому что он один понимает старую подсистему: формально дежурит раз в шесть недель, фактически — постоянно. Признак: его имя встречается в инцидентных каналах чаще, чем предполагает график (метрика «концентрация» ловит это в одну строчку кода). Лечится не разговором с ним, а перераспределением знания: парная работа на инцидентах, инструкции, передача владения. До тех пор вы платите ему за одну ставку и получаете полторы, и он это знает.

Отдельно: ротация не должна пересекаться с отпуском, релизом и днями, когда человек — единственный носитель критичной задачи. Нарушение выглядит как «Даша дежурит в неделю своего же релиза»; последствие — она либо не выкатит релиз, либо не отреагирует на инцидент, и оба варианта вы обнаружите постфактум.

Возмещение и границы вашей власти

Здесь важно не изображать больше полномочий, чем есть.

Правовая сторона зависит от страны и оформления и здесь намеренно не разбирается. Один факт стоит знать: Суд Европейского союза неоднократно решал, что дежурство «на связи» может считаться рабочим временем, если ограничения на человека существенны (дело Matzak, C-518/15, 2018; решения по делам C-344/19 и C-580/19, 2021). Вывод для руководителя: обсуждать оформление дежурств нужно с юристом и HR, а не по аналогии с соседней командой. Тема денег со стороны сотрудника — в главе Компенсация; ваша задача другая — принести наверх посчитанную нагрузку, а не ощущение «ребятам тяжело».

Самое дешёвое из доступного — автоматизм вместо доброты. «Была ночная побудка — следующий день начинается не раньше обеда, разрешения спрашивать не нужно» работает, потому что не требует от уставшего человека просить. «Если тяжело, скажи мне» не работает по той же причине, по которой не работают добровольные механизмы вообще: просить приходится тогда, когда меньше всего сил, и человек с высоким чувством долга не попросит никогда.

Разбор инцидента: что там ломается

Формат описан в десятках мест — например, в главе postmortem culture SRE book. Разберём не формат, а то, что портится на практике.

Обвинение просачивается через формулировки. Документ называется безобвинительным, а в тексте написано «инженер не проверил конфигурацию перед применением». Это обвинение, просто вежливое. Дальше люди пишут разборы осторожнее, детали исчезают, и вы теряете именно ту информацию, ради которой всё затевалось. Замена — описывать не то, чего человек не сделал, а то, почему в тот момент его действие выглядело разумным: какие данные он видел, каких сигналов не было, чем он был занят. Это «вторая история» Сидни Деккера, и она полезнее первой, потому что воспроизводима: следующий человек в тех же условиях сделает то же самое.

Контрфактические формулировки. «Если бы он посмотрел на дашборд, инцидента бы не случилось» описывает не произошедший мир, а желаемый, и ничего не улучшает. Проверка: вывод разбора должен быть изменением в системе, процессе или информации, а не описанием более внимательного человека. «Быть внимательнее», «не забывать проверять», «усилить контроль» — признание, что причину не нашли.

«Человеческая ошибка» как причина. Разбор, закончившийся на этом, закончился слишком рано. Четыре страницы Ричарда Кука How Complex Systems Fail стоит прочитать целиком; их главный тезис — человеческие действия в сложных системах одновременно источник сбоев и единственный источник восстановления, и наказание за ошибку убирает второе вместе с первым.

Разбор пишет уставший человек в нерабочее время. Тот, кто чинил ночью, садится за документ в пятницу вечером; результат — текст ради галочки. Разбор — это работа, она делается в рабочее время и занимает место в плане; если места нет, честнее не делать разборов вообще.

Никто не читает. Средство простое: пятнадцать минут на регулярной встрече, где разбор рассказывают вслух и задают вопросы, — заодно самый дешёвый способ распространить знание о системе. Как вести такие обсуждения, чтобы говорил не только автор, — в главе Фасилитация.

Куда уходят выводы

Самая частая судьба вывода — список в конце документа, к которому никто не возвращается. Разберём маршрут явно.

Ветку J → K обычно пропускают, и зря. Осознанно принятый риск — нормальный исход разбора. Ненормальный — когда риск принят молча, никем конкретно, и через полгода тот же инцидент обсуждают как неожиданность; разница между двумя случаями — одна строчка с именем и датой. Как вести такой реестр, чтобы он не стал свалкой, — в главах Технический долг и Техническая стратегия; язык рисков и предъявления их наверх — в главе Управление рисками.

Проверка M — единственное, что отличает разборы от ритуала. Одна цифра раз в квартал: сколько выводов старше шестидесяти дней не сдвинулись. Если она растёт, у вас нет цикла обучения — у вас есть жанр документов.

Инцидент и оценка человека

Участие в инциденте — не сигнал о качестве работы. Тот, кто чаще всех оказывается в разборах, обычно не худший инженер, а тот, кто трогает самые нагруженные части системы. Использовать инцидент как аргумент в разговоре об оценке — самый быстрый способ получить команду, которая скрывает проблемы. Как отличить настоящий слабый результат от невезения — в главе Слабый результат.

Что действительно является сигналом — три вещи, и все про поведение, а не про сбой: человек скрыл факт инцидента; систематически обходит согласованный порядок изменений, и это уже обсуждалось; не эскалирует из страха выглядеть некомпетентным. Первые два — предмет прямого разговора по правилам главы Обратная связь; третье почти всегда следствие вашей же реакции на предыдущие эскалации.

После тяжёлого инцидента нужен разговор не о задаче, а о человеке — не «давай разберём, что пошло не так», для этого есть разбор, а «как ты». Уронившие прод нередко переживают это тяжелее, чем показывают, и один короткий разговор на один на один меняет больше, чем любые формулировки в документе. Признак, что разговора не было: человек после инцидента начинает избегать рискованных задач.

Разговор наверх

Наверх нагрузка предъявляется в единицах, которые там считают. Не «команда устала», а «за квартал 96 ночных прерываний, 78% можно было отложить до утра; это два человеко-месяца, которых нет в плане; вот три изменения и их стоимость». Логика такого разговора — в главе Вверх по цепочке.

Про бюджет ошибок (error budget) стоит сказать честно. Идея красивая: превысили допустимый уровень сбоев — команда автоматически переключается с новых функций на надёжность. Работает она при одном условии: у кого-то есть реальные полномочия остановить разработку функций. Без этого бюджет ошибок — очередной график, который все смотрят и никто не применяет; тогда честнее его не заводить, а вести простой счёт цены каждого квартала без вложений в надёжность. Счёт бесполезен ровно до момента, когда решение всё-таки придётся принимать, — и тогда у вас будут цифры за год, а не впечатления.

Что чаще всего ломается

• Дежурство есть, контракта нет. Признак: два человека по-разному отвечают, что делать в 3 часа ночи. Последствие: длинные инциденты и обиды после каждого.
• Алерты растут, никто не чистит. Признак: доля вызовов без действия выше половины. Последствие: уведомления отключают, критичный сигнал теряется.
• Лид садится за клавиатуру. Признак: наружу полчаса ничего не сообщалось. Последствие: разбирательство про коммуникацию вместо разбора сбоя.
• Расследование ведут ночью. Признак: причину искали до пяти утра, откатить можно было в 02:30. Последствие: следующий день потерян, причина всё равно найдена днём.
• Разбор пишется в нерабочее время, выводы без владельцев. Признак: документ появляется в пятницу в 22:00, в конце список пунктов без имён и дат. Последствие: те же инциденты повторяются, и это уже никого не удивляет.
• Невидимый герой. Признак: один человек фигурирует в трети инцидентов при ротации из шести. Последствие: он уходит, и выясняется, что дежурство держалось на нём.
• Возмещение по договорённости, а не автоматом. Признак: отгул надо просить. Последствие: просят самые уверенные, а выгорают самые ответственные.
• Ноль ложных эскалаций. Признак: за квартал никто не разбудил вас зря. Последствие: вас не будят и тогда, когда надо.

Самопроверка

На эти вопросы у вас либо есть точный ответ, либо есть работа на ближайший месяц.

1. Сколько ночных прерываний было у команды за прошлый квартал? Назовите число.
2. Какая доля вызовов потребовала действия человека и кто вчера это решал?
3. Что дежурный вправе сделать ночью без вашего разрешения и знает ли он этот список?
4. Кому он звонит, если не справляется, и через сколько минут?
5. Когда вас последний раз разбудили зря и как вы отреагировали?
6. Сколько выводов из разборов старше шестидесяти дней не сдвинулись с места?
7. Кто подключается к чужим сменам чаще, чем предполагает график?
8. Что происходит автоматически после ночной побудки — без просьбы человека?
9. Если завтра из ротации выпадет самый опытный, кто закроет его смену?

Мини-итог

• Дежурство — контракт из шести пунктов (область, окно, отклик, полномочия, эскалация, возмещение), а не табличка с именами; расхождение в ответах команды — диагноз.
• Нагрузка невидима по устройству: нет артефакта, куски мелкие, цена платится назавтра, и кто-то её тихо компенсирует. Первая задача руководителя — сделать её считаемой.
• Данные о вреде прерванного сна и о цене самой доступности надёжны, но получены не на разработчиках; ориентиры по числу инцидентов на смену и формат ролей — отраслевая практика без доказательств; MTTR как цель лучше не использовать.
• Главный рычаг — доля вызовов, которые можно было отложить до утра: пятнадцать минут разбора в неделю плюс готовность удалять алерты.
• В инциденте ваша роль не техническая: объявить, координировать, говорить наружу, менять уставших, остановить. Клавиатура — признак, что вашу роль никто не исполняет.
• Разбор портится через вежливые обвинения, контрфактические формулировки и выводы без владельцев. Осознанно принятый риск — нормальный исход; молча принятый — нет.
• Инцидент не является сигналом о качестве работы. Сигналы — сокрытие, систематический обход порядка и страх эскалировать.
• Полномочия ограничены: график и алерты — ваша зона, деньги и отказ от чужих сервисов — нет. Там, где решаете не вы, ваша работа — принести посчитанную цену.

Источники

• Google SRE Book: Being On-Call и Postmortem Culture, а также SRE Workbook: Incident Response — ориентиры по нагрузке, формату разбора и координации; инженерная норма компании, не результат исследования. Полные тексты книг открыты.
• PagerDuty Incident Response — роли, эскалация, устройство ротации; наиболее подробное открытое описание. Альтернативный взгляд — Atlassian Incident Management Handbook.
• Nicol A.-M., Botterill J. (2004). On-call work and health: a review. Environmental Health, 3(15) — обзор влияния дежурств на здоровье.
• Dettmers J., Vahle-Hinz T., Bamberg E., Friedrich N., Keller M. (2016). Extended work availability and its relation with start-of-day mood and cortisol. JOHP, 21(1) — цена дежурства без вызовов.
• Sonnentag S., Fritz C. (2015). Recovery from job stress: The stressor-detachment model. Journal of Organizational Behavior, 36(S1) — почему важно отключаться от работы.
• Mark G., Gudith D., Klocke U. (2008). The Cost of Interrupted Work. CHI 2008 — стоимость возврата к прерванной задаче.
• Fischhoff B. (1975). Hindsight is not equal to foresight. Journal of Experimental Psychology, 1(3) — ретроспективное искажение, из-за которого разборы скатываются в обвинение.
• Dekker S. The Field Guide to Understanding ‘Human Error’ (3-е изд., 2014) — «вторая история» и почему «человеческая ошибка» не является причиной.
• Cook R. How Complex Systems Fail — четыре страницы, обязательные перед первым разбором инцидента.
• Allspaw J. Blameless PostMortems and a Just Culture, Etsy, 2012 — перенос идеи в индустрию.
• The VOID (Verica Open Incident Database), отчёты Courtney Nash — открытая база разборов и аргументация против MTTR как метрики.
• SNAFUcatchers, STELLA Report — полевое исследование того, как инженеры на самом деле справляются с инцидентами.

Что дальше

Дежурство упирается в границы: чей это сервис, кого можно разбудить ночью, кто отвечает за интерфейс между командами. Дальше — про то, как эти границы устроены, почему зависимости между командами дороже, чем кажется, и что делать с когнитивной нагрузкой, которую команда не выдерживает.

Границы команд: зависимости, интерфейсы и когнитивная нагрузка.