Качество, эксплуатация и governance: документы вокруг живой системы

Сцена · кто виноват

Прод лежал сорок минут. На разборе руководитель спрашивает: кто виноват? Команда смотрит в стол. Виноватым назначают того, кто катил релиз, ему объявляют «быть внимательнее». Все расходятся с облегчением: причина найдена, человек наказан.

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

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

Карта урока · что заберёшь

• Документы качества: планы и отчёты, и почему план без отчёта слеп.
• SLI, SLO и SLA: что меряем, что обещаем себе, что обещаем клиенту.
• Incident record и blameless postmortem: как падать с пользой.
• Restore test: почему бэкап без проверки восстановления это лотерея.
• Governance: политики, лицензии, персональные данные.
• Handbook и onboarding: документы, по которым входят в команду.

Качество · планы и отчёты

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

• Test plan и quality plan: что проверяем и чем. Не дублирует тесты, а отвечает на вопросы уровнем выше: какие виды тестов где живут, что проверяем вручную, что не проверяем вовсе и почему. Сами виды тестов и их баланс разбираем в разделе про тестирование, начиная с урока про цели тестов.
• Coverage report: сколько кода покрыто. Полезен как термометр и вреден как цель: когда покрытие становится KPI, появляются тесты без ассертов. Подробнее про честное чтение покрытия в уроке про виды тестов и покрытие.
• Performance test report и security test report: замеры под нагрузкой и результаты проверок безопасности, привязанные к версии и дате. Отчёт годовалой давности это история, а не состояние.
• Compatibility matrix: какие версии браузеров, ОС, клиентских SDK поддерживаем. Каждая клетка матрицы это обещание, которое кто-то должен проверять.
• Defect record: баги как документы, со степенью тяжести, шагами воспроизведения и историей. Баг-трекер и есть архив таких записей.
• Audit report: внешняя проверка (безопасность, финансы, ISO) на дату. Аудит проходят не ради бумаги: список замечаний это бесплатный бэклог улучшений.

Эксплуатация · обещания и аварии

SLI, SLO, SLA · три буквы про надёжность

Тройка, которую важно не путать:

• SLI: что измеряем. «Доля ответов быстрее 300 мс за окно в 28 дней».
• SLO: что обещаем себе. «Таких ответов не меньше 99.9 процента».
• SLA: что обещаем клиенту деньгами. Всегда мягче, чем SLO: внутренняя цель строже внешнего обещания, чтобы между ними был запас.

Из SLO выводится бюджет ошибок: 99.9 процента успеха это разрешение на 0.1 процента неудач. Пока бюджет цел, команда катит фичи; бюджет сгорел, команда чинит надёжность. Спор «фичи против стабильности» превращается из вкусового в арифметический. Откуда берутся сами метрики и как их собирать, смотри урок про наблюдаемость.

Инциденты · запись и разбор

Когда система падает, рождаются два документа:

• Incident record: хроника во время тушения. Когда заметили, что делали, когда восстановили. Пишется по горячим следам, обычно в канале инцидента.
• Postmortem: разбор после. Таймлайн, цепочка причин, что помогло, что помешало, список действий с владельцами и сроками.

Ключевое слово: blameless. Вернись к сцене. Вопрос «кто виноват» даёт имя и облегчение, вопрос «что в системе позволило этому случиться» даёт список исправлений. Человек, который не боится написать в postmortem «я перепутал окружение», это датчик: он только что показал, что окружения легко перепутать. Накажи его, и датчики замолчат, а перепутать окружение будет всё так же легко.

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

• Known issue: известная проблема, которую решили пока не чинить. Запись с обходным путём экономит каждому следующему наткнувшемуся часы.
• Availability report: фактическая доступность за период. Это отчёт, которым проверяется SLA.

Восстановление · бэкап это гипотеза

• Restore test report: запись о том, что бэкап реально восстановили и сколько это заняло. Бэкап без теста восстановления это лотерея: узнаешь, выиграл ли, в худший момент жизни.
• Disaster recovery plan: что делаем, если сгорел регион, утёк мастер, ушёл ключевой провайдер. Два числа в центре плана: RPO и RTO. Если бизнес говорит «терять можно час данных, лежать можно четыре часа», архитектура бэкапов выводится из этих цифр, а не из привычек.