Сергей «Mr. Kernel»
О специалисте
Mr. Kernel начинал ещё в эпоху, когда подтверждение сделки означало звонок и голос на другом конце линии, а не запись в базе данных. Голосовой дилинг научил его тому, что современные логи и трассировки часто скрывают: у любой торговой операции есть человек или процесс, который несёт ответственность за конкретную секунду её исполнения, и если эту секунду нельзя предъявить — система не готова к продакшену, сколько бы у неё ни было автотестов.
В Cobalt он пришёл на этапе, когда компания выходила из формата разовых заказов в формат платформы: то же ядро исполнения нужно было одновременно продавать партнёрам как продукт и держать под собственным капиталом как боевую систему. С тех пор он отвечает за то, чтобы это было буквально одно и то же ядро, а не два похожих, разошедшихся в критический момент. Через его руки прошли все технологические поколения компании — от систем с голосовым подтверждением до агентов, которые сейчас принимают решения на основе моделей и исполняют их без участия человека.
Опыт
Результаты: что сработало и что нет
Как Mr. работает
Я не измеряю платформу по одному показателю — есть три числа, которые смотрю каждый день вместе: время безотказной работы основного контура, время от коммита до релиза и доля релизов, которые пришлось откатить. По отдельности каждое можно улучшить обманом: снизить частоту релизов ради стабильности или гнать код без проверок ради скорости. Вместе они не дают срезать угол — если время от коммита до релиза падает, а доля откатов растёт, это не прогресс, а перенос риска на прод.
Граница моей ответственности заканчивается там, где начинается сигнал стратегии: какую модель запускать, какой размер позиции держать, когда закрывать сделку — это решает не платформа и не я. Моя зона — чтобы решение, каким бы оно ни было, исполнилось ровно так, как задумано, без потерь на пути, без искажения из-за задержки и без права на «система была недоступна» как оправдание. Если модель ошиблась — это к коллегам, отвечающим за исследования и риск. Если ордер ушёл не туда или не в то время — это ко мне, и я не делю эту ответственность с внешними факторами вроде провайдера или биржи.
Главная ошибка в моей области — принимать работу в собственной торговле за доказательство готовности продукта для партнёра. Наша внутренняя нагрузка имеет свой профиль: свои объёмы, свои паттерны всплесков, свои редкие случаи. Партнёр с другим профилем трафика вскрывает баги, которые год не проявлялись у нас — история 2022 года с протоколом ордеров ровно об этом. Поэтому с того момента любое изменение протокола или API проходит через синтетическую нагрузку с профилем, специально построенным непохожим на наш собственный, а не только через наши обычные нагрузочные тесты.
Технический долг я считаю не абстрактной виной, а конкретной цифрой — сколько инцидентов в квартал происходит из-за компонентов старше трёх релизных циклов без пересмотра. Если эта доля растёт, значит, команда тушит пожары вместо того, чтобы их предотвращать, и я останавливаю часть новых фич в пользу пересмотра старого кода, даже если это раздражает продуктовую часть команды. Платформа, которая не выдерживает собственной истории изменений, не выдержит и партнёрской нагрузки.