Надёжное программирование: от кода к технологии

Пост 1 — Надёжность это свойство технологии, а не кода

Хабы: Программирование, Разработка, Управление разработкой
Теги: надёжность, архитектура, спецификация, программирование, управление разработкой

Это первый из трёх постов серии «Надёжное программирование: от кода к технологии». В нём — главный тезис и три столпа. Во втором разберём оракульное смещение и эмпирику DORA, Veracode и FormAI-v2. В третьем — конечного аудитора, шкалу L0–L4 и практические рекомендации. Полная версия статьи — [ссылка].

Как мы привыкли думать

Долгие годы надёжность ПО обсуждали в терминах кода. Плохой код — плохой продукт. Хороший код — надёжный продукт. Отсюда культ code review, метрики покрытия, борьба за чистые функции и SOLID.

Это было оправдано ровно до тех пор, пока кодирование оставалось самым трудоёмким этапом жизненного цикла. Пока писали руками — узкое место было там.

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

Ключевой тезис

Надёжность — эмерджентное свойство технологии производства, а не свойство отдельного файла с кодом.

Она не распределяется по частям. У отдельного модуля нет ни доступности, ни среднего времени между отказами — это характеристики системы, а не компонента. И она не выводится из качества компонентов: можно отладить каждый модуль по отдельности и получить систему, которая падает на стыке.

Классический пример: каждый сервис возвращает корректный ответ, но при отказе одного из них цепочка уходит в каскадный отказ, потому что никто не подумал про таймауты и размыкание цепи. Модульные тесты при этом — зелёные.

Тезис о процессной природе надёжности не нов. Он закреплён в стандарте процессов жизненного цикла (ISO/IEC/IEEE 12207:2017), в моделях зрелости и в работах отечественной школы системного проектирования (Липаев, Лаврищева). Новое в другом: автоматизация меняет не только трудозатраты, но и структуру дефицита — времени, ресурсов, экспертизы. Именно поэтому имеет смысл ещё раз проговорить, из чего надёжность складывается.

Три столпа

Из этого вырастают три столпа, на которых держится надёжность.

1. Архитектура

Таймауты, повторные попытки, идемпотентность, изоляция отказов, размыкание цепи (circuit breaker), очереди, резервирование, наблюдаемость. Это не «улучшения», которые можно добавить позже. Это решения, которые либо заложены в проект, либо требуют переписывания системы.

Архитектура порождает собственные оракулы — утверждения, которые проверяются на этапе проектирования:

• «Повтор запроса не должен приводить к двойному списанию».

• «Бюджет повторов ограничен».

• «При отказе зависимого сервиса система деградирует предсказуемым образом».

Эти утверждения не проверяются модульными тестами. Они проверяются хаос-инженерией и нагрузочными испытаниями.

2. Код и спецификация

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

У спецификации есть обратная сторона, о которой говорят реже:

• Избыточная спецификация. Генератор переобучается на несущественных деталях, тесты становятся хрупкими и ломаются при рефакторинге, который не меняет поведения. Формально всё в порядке, фактически команда начинает бояться собственных тестов.

• Недостаточная спецификация. Молчаливые допущения, перенесённые из обучающих данных. Решение работает на демонстрации и отказывает на периферии входных данных. Незаданное условие модель заполняет правдоподобным, но неверным допущением.

Трассируемость «требование → архитектура → код → тест → дефект» — не бюрократия, а носитель независимости проверки. Если требование не связано с тестом, тест проверяет реализацию самой себя.

3. Валидация и оракул

Проверка держится на тест-оракуле — механизме, по которому наблюдаемое поведение признаётся правильным или неправильным. Формально: O(x, y) ∈ {проход, провал, неопределено}.

Оракулы бывают:

• Специфицированный — спецификация, контракт, отраслевой стандарт.

• Производный — эталонная реализация, регрессионный набор, предыдущая версия.

• Имплицитный — инвариант, метаморфное соотношение, свойство.

• Человеческий — экспертная оценка, критерии приёмки заказчика.

Ни один тип не полон. Проблема оракула — ожидаемый результат не может быть определён с нужной точностью и полнотой — сформулирована задолго до появления LLM (Weyuker, 1982) и в общем случае неустранима. Частичный оракул проверяет не «правильно ли», а «не неправильно ли»: инварианты, метаморфные соотношения, критерии деградации, целевые показатели уровня обслуживания (SLO).

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

Что это значит на практике

• Надёжность нельзя «добавить» на этапе тестирования. Она закладывается на этапе требований, проектирования архитектуры и формулировки спецификации.

• Улучшение отдельного компонента не гарантирует улучшения системы. Надёжность распределена по всему процессу и не переносится на уровень частей.

• Автоматизация генерации не отменяет трёх вопросов: что должно быть сгенерировано, как это проверить и кто отвечает за результат. Все три решаются до кодирования.

Именно поэтому линия преемственности дисциплины не прерывается. Она меняет уровень: с программы на процесс, с процесса на спецификацию и оракул.

Анонс следующего поста

Во втором посте разберём, почему при массовом внедрении ИИ метрики процесса растут, а доверие — нет. Это явление называется оракульное смещение, и оно подтверждается эмпирикой DORA 2024–2025, Veracode 2025 и FormAI-v2.

Серия «Надёжное программирование: от кода к технологии»

• Пост 1. Надёжность как свойство технологии, а не кода (вы здесь)

• Пост 2. Оракульное смещение: почему ИИ генерирует быстрее, чем мы успеваем проверять

• Пост 3. Кто отвечает? Конечный аудитор, шкала L0–L4 и практика