Тирания «лучших практик»: почему мы строим карго-культы вместо надежных систем

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

Аэропорты из бамбука и кластеры Kubernetes

В середине XX века был описан феномен «карго-культа» у меланезийских племен. Во время WWII там располагались военные базы, и аборигены видели, как с неба прилетали огромные «птицы» и привозили консервы и одежду. Когда война закончилась, самолеты перестали прилетать.

Чтобы вернуть их, племена начали воспроизводить ритуалы, которые они наблюдали у солдат: строили из бамбука и соломы копии диспетчерских вышек, самолетов. Маршировали с деревянными «ружьями». Самолеты, конечно, не вернулись.

А теперь посмотрим на IT-индустрию. Netflix добился успеха с микросервисами — и команды по всему миру бросились распиливать монолиты. Google написал SRE-гайд — и компании начали нанимать SRE, часто превращая это в ритуал, а не в инструмент улучшений.

Мы строим взлетно-посадочные полосы из Kubernetes, возводим вышки из Prometheus и ждем «карго» в виде надежности. Но оно не прилетает. Потому что мы копируем ритуал, а не фундаментальные принципы, сработавшие в совершенно ином контексте.

Контекст — это не деталь. Контекст — это всё.

«Лучшая практика» по своей природе игнорирует контекст. Это решение для конкретного набора проблем, ресурсов и масштаба. Вырванная из этого контекста, она перестает работать. Она предлагает простой ответ на сложный вопрос, поощряя интеллектуальную лень.

Авторитет как алиби

Второй столп карго-культа — это апелляция к авторитету. Но зачастую «лучшая практика» или методология — это не просто знание, а коммерческий продукт, окруженный экосистемой из тренингов и консалтинга. Автор, продвигающий свой фреймворк, заинтересован не в решении вашей проблемы, а в убеждении вас в универсальности своего метода. Поэтому первый вопрос к любому новому подходу — это классическое «Cui bono?». Часто ответ на этот вопрос помогает отделить реальный инженерный опыт от грамотно упакованного инфопродукта.

Призрак доказательной инженерии

Что же делать? В начале 2000-х годов в академической среде был дан интересный ответ, вдохновленный доказательной медициной. Это была попытка создать Evidence-Based Software Engineering (EBSE), или «доказательную программную инженерию». Идея была в применении научного метода: основывать выбор технологий не на фольклоре, а на измеряемых данных и результатах контролируемых экспериментов.

Почему же этот подход не стал отраслевым стандартом? Ответ прозаичен: это сложно, долго и дорого для коммерческих компаний, живущих в бешеном ритме релизных циклов. Индустрия просто не смогла (и не захотела) замедлиться, чтобы внедрить этот подход в его первозданном виде. Движение EBSE так и не стало мейнстримом.

И все же, тот факт, что EBSE как формальное движение не взлетело, не отменяет правоты его основной идеи. Наоборот, сегодня эта идея важна как никогда, но для ее реализации требуются другие инструменты. Если в 2000-х речь шла в основном о статистическом анализе полевых исследований, то сегодня у нас есть нечто более мощное:

- Формальное моделирование систем и их свойств.
- Симуляции и цифровые двойники, позволяющие проводить тысячи экспериментов без риска для продакшена.
- Продвинутый анализ данных и каузальный вывод, способные находить не просто корреляции, а причинно-следственные связи в поведении сложных систем.

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

Заключение

Цель этого поста — не отвергнуть весь накопленный индустрией опыт. Цель — призвать к интеллектуальной честности. Настоящая «лучшая практика» только одна — это привычка к критическому мышлению и принятию решений на основе доказательств.