Как построить рабочий процесс трейдера — от данных до обзора

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

1. Два источника истины — типичный отказ процесса

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

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

Чем процесс не является. Это не список приложений и не число открытых окон. И не заявление «каждое утро я проверяю рынок»: заявление не оставляет следа, которым можно воспользоваться позднее. Рабочий процесс узнают по более простому признаку: вы можете указать запись, файл или иной документ, созданный на каждом этапе вашей последней сделки.

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

2. Карта: одиннадцать этапов и их отказы

В представленной здесь модели одиннадцать этапов; мониторинг и разбор могут образовывать петли обратной связи, а запись решений при этом остаётся упорядоченной:

календарь и данные → список наблюдения → анализ → план → оповещение → решение → исполнение → мониторинг → журнал → разбор → изменение процесса

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

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

Все одиннадцать пунктов — действия. Места записи бывают двух видов. Три реестра — планов, исполнения (журнал) и процесса — служат источником структурированных данных, то есть данных, которые можно подсчитать. Рядом находится хранилище вложений: приоритетное хранилище доказательств, содержащее то, что не помещается в столбец, — датированный список наблюдения, снимок экрана, экспорт истории. Каждый файл связан с записью дня, плана или инцидента, поэтому действие оставляет след в реестре, в хранилище или в обоих местах. Это относится и к разбору: он не отдельный реестр, а действие, записывающее результат в нужное место. Дополненная запись идёт в реестр исполнения, карточка изменения — в реестр процесса. Это различие определяет остальную статью: сначала мы создаём реестры и только затем действия, которые их наполняют.

3. Один источник истины: план, журнал и версии процесса

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

На практике есть три места записи, различающиеся моментом своего возникновения:

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

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

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

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

4. Вход в процесс: календарь, watchlist, оповещения

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

Календарь отвечает лишь, меняются ли условия в рабочем окне. Не на вопрос о том, куда пойдёт рынок. Как читать поля события, откуда берётся консенсус и почему метка «влияние» относится к поставщику данных, а не к рынку, — ст. 11.3. Интерпретация публикации и поведения рынка — ст. 6.4. В рабочем процессе остаётся одно действие: перенести время публикаций в план вместе с часовым поясом, в котором вы его читаете, поскольку пересчёт в уме нередко становится источником ошибки на час.

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

Оповещение — условие, создающее событие и уведомление, не заявку. Где проверяется это условие, зависит от инструмента, и для своего инструмента это нужно выяснить, а не переносить принцип из одной программы в другую. Справка TradingView описывает оповещения как создаваемые и срабатывающие на серверах платформы и работающие даже после закрытия страницы графика^[1]. MetaTrader 4 отдаёт роль работающему приложению: после создания о событии сообщает «клиентский терминал»^[2], то есть закрытый терминал означает отсутствие уведомления. Справка MetaTrader 5 говорит то же о своей платформе и добавляет решающую подробность: временное условие оповещения задаётся по локальному времени компьютера^[3]. Это та же зависимость, которую раздел 11 предлагает проверить для защитных условий; для оповещений её выясняют точно так же — в документации производителя конкретного инструмента. Оповещение не подаёт заявку, не резервирует цену и не подтверждает, что в момент уведомления сделка исполнима на уровне, вызвавшем срабатывание условия. Вся цепочка от условия до заявки разобрана в ст. 11.2; в процессе три правила:

1. Один уровень — один сигнал, если резерв не спроектирован. Оповещения на один уровень в графической платформе и параллельно в терминале без согласованных ролей создают два события с разными временными метками и увеличивают число состояний, за которыми нужно следить. Однако продуманное резервирование независимых каналов может быть частью аварийной процедуры. Тогда заранее решают четыре вопроса: какой канал основной, какой резервный, как распознать, что оба уведомления относятся к одному событию, и как проверять, что резервный канал всё ещё работает. Без этих четырёх пунктов дубликат — шум, а не защита, и ни в одном варианте он не должен вызывать повторное исполнение.
2. Текст восстанавливает контекст. Сам по себе уровень через три недели ничего не говорит. В поле сообщения запишите сценарий, уровень отмены и ссылку на запись в реестре планов.
3. У сигнала есть срок годности. Уровень, отмеченный несколько недель назад, может уже не иметь контекста, в котором был создан; воспринимайте шесть недель как предложенный рабочий срок, а не измеренный порог. Срок действия или периодический разбор списка оповещений обходятся дешевле, чем реакция на уведомление, причину которого вы уже не помните.

Также стоит заранее решить, куда должно прийти уведомление. Оповещение, доставленное на телефон, запускает иную процедуру, чем оповещение на рабочем экране. Это отдельное проектное решение, описанное со стороны устройства в ст. 11.4.

5. План сделки и чек-лист исполнения

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

Семь минимальных полей заполняются до заявки:

1. Инструмент и условие входа записанные так, чтобы вопрос можно было решить одним словом. «Выход из консолидации» — не условие; «закрытие часовой свечи выше уровня X» — условие.
2. Уровень отмены тезиса — цена или событие, после которого тезис перестаёт быть верным независимо от текущего результата позиции. Таким событием может быть публикация данных, закрытие свечи по другую сторону уровня или истечение времени; такое условие нельзя отправить брокеру в виде заявки.
3. Плановый уровень защитной заявки — записывается отдельно от уровня отмены тезиса. После исполнения добавьте уровень, фактически подтверждённый сервером. Эти значения могут различаться; только подтверждённая заявка имеет соответствующую запись в истории счёта. Перепутав их, при разборе вы будете сравнивать план с записью, которой в истории никогда не было.
4. Объём с основанием. Одного числа недостаточно: через месяц вы не восстановите, откуда оно взялось. Метод определения размера позиции и лимитов разобран в раздел 9; в рабочем процессе важно лишь, чтобы число появилось до заявки и было записано вместе с предпосылками его расчёта.
5. Условие отказа — ситуация, в которой вы намеренно не входите, хотя условие входа выполнено: издержки входа вне вашей нормы, публикация данных в рабочем интервале, отсутствие времени на мониторинг позиции.
6. Время записи с часовым поясом — позволяет позднее установить порядок событий, когда план, оповещение и исполнение имеют разные временные метки.
7. Идентификатор записи — в любом формате, лишь бы один и тот же идентификатор попадал в имя файла снимка экрана, сообщение оповещения и запись журнала. В саму заявку он автоматически не попадёт; это отдельное действие, описанное ниже.

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

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

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

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

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

6. Мониторинг, журнал и вложения

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

Журнал работает, лишь разделяя результат и качество исполнения. Запись, из которой видны только прибыль и убыток, — это выписка по счёту под другим названием. Разделение труда простое: импорт истории даёт параметры исполнения, поскольку знает серверное время брокера и фактические цены, а заполняемые вручную поля дают классификацию — тип сетапа, причину выхода, наличие и направление отклонения от плана и время вмешательства. Последнее отвечает на вопрос, пришлись ли вмешательства в открытую позицию, включая её закрытие, на записанные моменты проверки или вне их. Это поле вы создаёте сами, и в экспорте платформы ему нет замены. Если экспорт вообще содержит поле причины операции, оно фиксирует источник заявки или техническую причину сделки, а не соответствие вашему расписанию. Документация MQL5 описывает свойство DEAL_REASON словами: «Сделка может быть исполнена в результате срабатывания заявки, размещённой из мобильного приложения или программы MQL5, а также в результате события StopOut, расчёта вариационной маржи и т. д.». Затем перечисляет значения: «срабатывание заявки, размещённой из настольного терминала», «… из мобильного приложения», «… из веб-платформы», «… из программы MQL5, то есть советника или скрипта», далее срабатывание Stop Loss, срабатывание Take Profit, событие Stop Out, ролловер, расчёт вариационной маржи, сплит и корпоративное действие^[7]. Это список источников и технических причин, а не ответ на вопрос, произошло ли закрытие в записанный вами момент проверки. Поэтому поле «время вмешательства» вы заполняете вручную при завершении записи. У него три значения: «без вмешательства» для позиции, шедшей по плану, «в запланированный момент» и «вне плана»; последнее вы ставите, если хотя бы одно вмешательство произошло вне расписания. Полная структура записи, ловушки импорта (часовой пояс, частичные закрытия, корректировки, вводы и выводы средств) и определения показателей разобраны в ст. 11.6.

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

• Имя файла начинается с ID плана. По датам — коллекция картинок, по ID — индекс.
• Два снимка на сделку — при составлении плана и после закрытия позиции. Третий снимок вы делаете, когда намеренно отклоняетесь от плана, поскольку по одним данным сделки нельзя восстановить, что вы видели на экране в момент отклонения.
• Периодический экспорт истории. Доступная глубина истории в терминале и личном кабинете зависит от брокера и типа счёта. Один раз проверьте её в спецификации своего счёта и настройте экспорт с запасом, прежде чем выяснится, что данные двухлетней давности уже недоступны.

7. Обзор и изменение после документированного решения

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

Каждый цикл оставляет запись с датой и идентификатором самого разбора; формат вы выбираете сами, лишь бы он оставался постоянным, например REV-2026-W34 для еженедельного разбора. Без этой метки результат разбора — запись неизвестного происхождения, а разбор без выводов выглядит в реестре точно так же, как разбор, которого не было.

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

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

Почему изменению нужна запись, не лишь решение. Чем больше вариантов вы пробуете на одной и той же истории, тем выше вероятность, что лучший на вид вариант выглядит так случайно. В литературе это явление описано применительно к тестированию стратегий^[5] и сноска охватывает только эту область. Тем не менее аналогичная проблема отбора может возникнуть с правилами процесса: десятая поправка к процедуре, оценённая на тех же тридцати сделках, — не десятый вывод, а десятый случайный розыгрыш. Карточка изменения процесса служит здесь недорогим счётчиком: показывает, сколько раз вы меняли правила и на каком основании.

8. Ручной и систематический процесс — две архитектуры

Одна и та же дорожка из раздела 2 выглядит по-разному, когда решение принимает человек и когда его принимает код. Разница не сводится к числу инструментов. Она в том, где находится характерная точка сбоя и как её распознать.

Ручной вариант опирается на пять функций, не брендов. Заявки — терминал с сервером брокера (ст. 11.1). Анализ и оповещения — графическая среда (ст. 11.2). Источник календаря и калькулятор объёма описывает ст. 11.3; готовые калькуляторы — в разделе инструментов. Пятая функция — запись плана и результата в реестрах части 3.

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

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

Систематический вариант имеет девять элементов и иное распределение риска: данные → репозиторий кода → среда выполнения → исторический тест → форвард-тест или демосчёт → внедрение → мониторинг → логи → разбор. Этап решения не переносится на момент изменения кода: изменение кода — одиннадцатый этап, то есть изменение процесса. Торговое решение по-прежнему принимается в реальном времени, только принимает его правило, а след имеет вид цепочки сигнал → решение алгоритма → валидатор лимитов → запрос, отправленный брокеру → ответ сервера, каждое звено которой записывается отдельно: только тогда можно позднее сказать, на каком звене процесс распался. Версионирование, напротив, относится к одиннадцатому этапу; там оно перестаёт быть хорошей практикой и становится условием восстановления правил, по которым автоматизация работала в данную неделю. Воспроизводимая среда разобрана в ст. 11.8, процедура теста и отдельный форвард-период — например, в тестере MetaTrader 5 — в ст. 11.7^[6]; внедрение, логи, идентификация позиций, непрерывность — ст. 11.5.

9. Минимальный набор и тест лишнего инструмента

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

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

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

Чего тест не касается. Отключение не относится к мониторингу открытых позиций, аварийному каналу из раздела 11, резервным копиям реестров и всему, что поддерживает детерминированные лимиты и аварийный выключатель. Защиту тестируют на копии процесса или на демосчёте, никогда не отключая её на реальном счёте с открытыми позициями. Тест избыточности должен показать, какие инструменты стоят рядом с процессом, а не проверить, как долго вы продержитесь без защиты.

10. Автоматизация повторяющихся задач малого риска

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

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

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

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

11. Аварийная процедура и резерв конфигурации

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

1. Подтвердите счёт иным каналом. Мобильное приложение, личный кабинет в браузере, звонок брокеру — любой путь, не использующий тот же элемент. Настройка резервного канала и его ограничения разобраны в ст. 11.4.
2. До ремонта остановите автоматику. Отключить разрешение на торговлю или остановить процесс быстрее, чем поставить диагноз, и для этого не нужно понимать причину. Диагностика при работающей автоматике означает, что условия меняются, пока вы их рассматриваете.
3. Сверьте позиции и отложенные заявки у брокера, а не в локальной копии. После обрыва связи терминал показывает последнее известное состояние, которое не обязательно является текущим.
4. Записывайте во время, не после. Время с часовым поясом, что отказало, что вы увидели, что сделали, состояние счёта до и после. Через час останется лишь впечатление, а его нельзя сопоставить ни с логом, ни с историей счёта.
5. Возобновляйте работу только после подтверждения, что состояние на стороне брокера совпадает с вашей записью. Перезапуск автоматизации до сверки состояния — прямой путь к дублированию позиции.

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

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

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

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

12. Аудит: четыре измерения вместо впечатления

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

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

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

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