Небольшая команда из трёх человек, специализирующаяся на хаос-инжиниринге, проводит game-day для клиента среднего размера из финтех-сектора, выставляет счёт на $18,000 за двухнедельный проект, а также перевыставляет клиенту стоимость годовой лицензии Gremlin или AWS Fault Injection Simulator на $4,000, которую клиент не хотел оформлять напрямую. Спустя полгода основатель смотрит на отчёт о прибылях и убытках, где указано $22,000 «консалтинговой выручки», и не может ответить на простой вопрос: насколько прибыльна собственно инженерная работа, если отделить её от роли неоплачиваемого реселлера ПО?
Это всё более распространённая проблема. По мере того как хаос-инжиниринг превратился из курьёза, свойственного только Netflix, в стандартную статью корпоративных программ обеспечения устойчивости, вокруг него сформировалась волна бутиковых консалтинговых фирм — они проводят аудиты устойчивости, организуют воркшопы game-day и выстраивают автоматизированные пайплайны внедрения отказов для клиентов, которые не хотят нанимать выделенную команду SRE. Инженерная сторона вопроса хорошо изучена. А вот с бухгалтерией обычно всё не так — потому что внутри одного юридического лица фактически работают два принципиально разных бизнеса: сервисный бизнес с неравномерной, проектной выручкой и бизнес по перепродаже ПО с регулярным, низкомаржинальным, транзитным денежным потоком. Смешение их в одном плане счетов скрывает, какой из них на самом деле приносит деньги.
Почему у фирм, занимающихся хаос-инжинирингом, эта проблема острее, чем у большинства консалтинговых компаний
Обычная стратегическая консалтинговая фирма выставляет счета за отработанное время — и на этом всё. А практика хаос-инжиниринга обычно ведёт одновременно три-четыре разных потока выручки:
- Аудиты устойчивости — проект с фиксированной ценой или почасовой оплатой, в рамках которого изучается архитектура клиента, графы зависимостей и точки отказа ещё до какого-либо внедрения сбоев. Это диагностическая работа, обычно оформляемая как отчёт плюс приоритизированный бэклог экспериментов.
- Проведение game-day — собственно живое мероприятие, на котором команда планирует сценарии отказов, запускает их на стейджинге или в продакшене и сопровождает инженеров клиента в процессе реагирования на инцидент. Game-day проверяет не только систему, но и людей вместе с их регламентами реагирования, поэтому такие проекты оцениваются и планируются иначе, чем непрерывное автоматизированное хаос-тестирование.
- Автоматизация и развёртывание платформы — настройка регулярных хаос-экспериментов в CI/CD, что ближе к поставке программного обеспечения, чем к воркшопу, и часто выставляется как проект с этапами (майлстоунами).
- Перепродажа инструментов или транзитные платежи — перепродажа или администрирование лицензий на такие платформы, как Gremlin, Harness Chaos Engineering, либо настройка облачных сервисов вроде AWS Fault Injection Simulator и Azure Chaos Studio от имени клиента — иногда с наценкой, иногда по себестоимости, просто ради удобства клиента.
У каждого из этих направлений своя структура затрат, свой профиль маржинальности и — что критично важно — своя трактовка признания выручки по стандарту ASC 606, если вы американское юридическое лицо, ведущее учёт, приближённый к GAAP, для банка, инвестора или для собственных управленческих решений. Если свалить всё это в один счёт «Консалтинговая выручка», вы теряете возможность увидеть, что проведение game-day даёт маржу в 80%, а перепродажа инструментов — всего 8%, и едва оправдывает административные издержки.
Как выстроить план счетов по направлениям выручки, а не по клиентам
Самое результативное изменение в бухгалтерии, которое может сделать консалтинговая фирма по хаос-инжинирингу, — это разделение счетов выручки по типу выполняемой работы, а не по клиенту или по счёту-фактуре. Типичная структура выглядит так:
Income:Consulting:ResilienceAudits
Income:Consulting:GameDayFacilitation
Income:Consulting:AutomationBuildOut
Income:ToolingResale:Licenses
Income:ToolingResale:CloudUsagePassThroughКогда вы выставляете клиенту счёт за пакетный проект — скажем, аудит устойчивости, за которым следует game-day, включая лицензию Gremlin, — этот единый счёт нужно разнести как минимум по трём из этих счетов в учёте, а не проводить одной общей строкой «Проект X — $22,000». В двойной записи, в текстовых форматах вроде Beancount, это одна транзакция с несколькими проводками:
2026-07-16 * "Fintech Client Co" "Resilience audit + game day + Gremlin license"
Assets:AccountsReceivable:FintechClientCo 22000.00 USD
Income:Consulting:ResilienceAudits -6000.00 USD
Income:Consulting:GameDayFacilitation -12000.00 USD
Income:ToolingResale:Licenses -4000.00 USDКак только такая транзакция появляется в учёте, вы можете в любой момент получить реальный отчёт о прибыльности по направлениям услуг — вместо того чтобы восстанавливать её по памяти или по старым коммерческим предложениям, когда в марте бухгалтер спросит, почему маржа выглядит непоследовательно.
Ловушка перепродажи инструментов: транзитный платёж против наценки против агентской схемы
Именно на перепродаже или администрировании лицензий на сторонние инструменты хаос-инжиниринга такие фирмы чаще всего допускают ошибки в учёте — и в налоговой трактовке. Есть три разных схемы, и они никогда не должны использовать один и тот же счёт учёта:
- Чистый транзитный платёж: вы платите Gremlin $4,000 за лицензию, выставляете клиенту счёт ровно на $4,000 и не берёте никакой наценки. Некоторые фирмы отражают это по нетто (только маржу, которая равна $0), а не по брутто. Если ваш договор об оказании услуг устанавливает, что вы выступаете закупочным агентом клиента, а не реселлером, эта операция может подпадать под трактовку «агент против принципала» согласно ASC 606 — то есть платёж поставщику и возмещение от клиента отражаются как взаимозачёт, а не как раздутые одновременно выручка и себестоимость. Это важно, потому что меняет показатель вашей выручки по верхней строке, а он влияет на всё — от ковенантов по кредитам до того, как покупатель бизнеса оценит вашу компанию по мультипликатору выручки.
- Перепродажа с наценкой: вы покупаете ту же лицензию за $4,000 и выставляете клиенту счёт на $5,000, оставляя себе разницу в $1,000. Здесь вы выступаете как принципал — вы контролируете товар или услугу до того, как они перейдут к заказчику, — и должны отразить полные $5,000 как выручку, а $4,000 как себестоимость реализованных товаров, а не сворачивать это до $1,000 по нетто. Отражение по нетто занижает и строку выручки, и строку себестоимости, которые покупатель или кредитор могут захотеть видеть отдельно.
- Клиент закупает напрямую: самая чистая схема — у клиента есть собственный контракт с Gremlin или FIS, а вы просто администрируете его. В этом случае ничего вообще не затрагивает ваш учёт, поэтому по мере роста всё больше консалтинговых фирм подталкивают клиентов к прямой закупке: это полностью убирает из отчёта о прибылях и убытках целое низкомаржинальное направление с рисками по срокам денежного потока.
Какую бы схему вы ни использовали, выбирайте одну на каждые отношения с клиентом и придерживайтесь её последовательно — смешение агентской и принципальной трактовки для одного и того же поставщика в разных клиентских отношениях без документально зафиксированной причины — это именно тот вид непоследовательности, который превращает рутинную проверку учёта в затяжное разбирательство.
Признание выручки по аудитам с фиксированной ценой против game-day с оплатой по этапам
Аудиты устойчивости и воркшопы game-day обычно продаются по фиксированной цене, что согласно ASC 606 вовсе не означает «признавайте всю сумму, как только счёт оплачен». Стандарт требует признавать выручку по мере выполнения обязательства по договору — либо в определённый момент времени, либо равномерно в течение периода, в зависимости от того, получает ли клиент выгоду и потребляет ли её по мере вашей работы, или только по итогу.
- Аудит устойчивости, оформляемый как единый отчёт по итогам двухнедельного проекта, обычно признаётся в определённый момент времени: ничего не попадает в выручку, пока отчёт не передан и не принят клиентом, даже если вы выставили счёт на 50% предоплаты. Эта предоплата хранится на счёте обязательств (
Liabilities:DeferredRevenue:ResilienceAudits) до момента поставки. - Многодневный проект game-day с ежедневными результатами — документами по сценариям отказов, хронологией инцидентов, итоговым разбором — часто подпадает под признание в течение периода, поскольку клиент получает и использует ценность постепенно, а не одной большой поставкой в конце.
- Развёртывание автоматизации с договорными этапами (пайплайн на стейджинге запущен, продакшен-эксперименты запланированы, дашборд передан) следует признавать поэтапно — этап за этапом, что заодно значительно упрощает прогнозирование денежного потока, поскольку вы не ждёте одного крупного платежа в конце проекта.
Ошибка в этом вопросе создаёт не только головную боль при последующем аудите — она искажает и ваше собственное представление о состоянии бизнеса в реальном времени. Фирма, которая признаёт предоплату в $30,000 как выручку в день её поступления, а затем поставляет аудит спустя два месяца, в первый месяц будет выглядеть куда прибыльнее, а в третий — куда менее прибыльной, чем есть на самом деле, а это плохая основа для решения о том, нанимать ли следующего инженера.
Отслеживание загрузки и реальной маржи по каждому типу проекта
Когда выручка правильно разделена, следующий шаг — сопоставить с ней затраты. Консультантов по хаос-инжинирингу обычно выставляют клиенту по ставкам уровня senior, поэтому распределение затрат на труд здесь важнее, чем в менее маржинальных сервисных бизнесах. Для каждого типа проекта отслеживайте:
- Прямые часы труда, привязанные к конкретному проекту (а не просто «консалтинговые часы» в целом) — именно это покажет вам, что аудит устойчивости, рассчитанный на 40 часов, на самом деле занял 65, и его нужно переоценить в следующий раз.
- Затраты на инструменты, распределённые на конкретные клиентские отношения, из-за которых была совершена покупка лицензии, а не сваленные в общую статью расходов на ПО.
- Расходы на командировки и выезды на площадку для очных game-day, которые могут заметно изменить маржу иначе идентичного удалённого проекта.
В результате получается отчёт о марже по типам проектов, который действительно что-то говорит: многие фирмы в этой сфере обнаруживают, что аудиты устойчивости и развёртывание автоматизации дают самую сильную маржу, потому что это чистое инженерное время, тогда как сопровождаемые game-day — несмотря на премиальные дневные ставки — дают более тонкую маржу, если полностью учесть время старшего фасилитатора, командировки и предварительную проработку сценариев. Без раздельного учёта этого просто не видно; с ним это становится простым разговором о ценообразовании со следующим потенциальным клиентом.
Сохраняйте инженерную дисциплину и в финансовой отчётности
Здесь напрашивается естественная параллель, которую практики хаос-инжиниринга обычно сразу же понимают: вся эта дисциплина построена на идее, что нельзя доверять системе, которую вы не протестировали, и что непрозрачная, трудная для проверки инфраструктура скрывает режимы отказа, которые в итоге вас подведут. То же самое верно и для электронной таблицы или «чёрного ящика» бухгалтерского SaaS-инструмента, который сворачивает вашу перепродажу инструментов с консалтинговой выручкой без того, чтобы вы об этом просили — вы узнаёте, что ваша маржа была неверной, только когда ущерб уже нанесён. Текстовый учёт под контролем версий означает, что каждая проводка доступна для проверки, сравнения и аудита — точно так же, как вы хотели бы, чтобы работала ваша инфраструктура как код, а разделение потоков выручки на уровне транзакции (а не восстановленное позже по памяти) — это то, что на самом деле делает возможным ежемесячный обзор прибыльности вместо ежемесячных археологических раскопок.
Упростите управление финансами
По мере того как ваша практика хаос-инжиниринга вырастает из мастерской одного основателя в команду с несколькими параллельными проектами, чистое разделение выручки от аудитов устойчивости, проведения game-day и перепродажи инструментов становится тем, что вообще делает возможными решения по ценообразованию и анализ маржи. Beancount.io предлагает текстовый учёт, который даёт вам полную прозрачность и контроль над вашими финансовыми данными — без чёрных ящиков, без привязки к поставщику. Начните бесплатно и узнайте, почему разработчики и технические консалтинговые компании переходят на текстовый учёт.