Два ответственных за скрипты, которые могут сорвать вашу неделю

Почему скрипты с одним владельцем становятся проблемой для основателя

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

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

И вот тогда в дело втягивают основателя. Не потому, что он должен вести зарплату или чинить биллинговую задачу, а потому, что все остальные медлят. Коллега может иметь доступ к серверу и всё равно не трогать скрипт, потому что одно неверное движение может задержать выплату, списать деньги с клиентов дважды или сломать деплой прямо перед запуском.

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

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

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

Если один скрипт может остановить зарплату, приостановить биллинг, заблокировать релиз или оставить бэкапы без проверки, он должен попасть в список рисков основателя.

Какие скрипты нужно страховать в первую очередь

Начните со скриптов, которые могут навредить бизнесу за один запуск. Если скрипт двигает деньги, меняет доступ клиентов или затрагивает прод, он не должен жить в голове одного человека.

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

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

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

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

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

Для старта достаточно короткого списка. Не нужно идеального покрытия в первый день. Нужна запасная ответственность там, где сбой ударит сильнее всего.

Кто должен отвечать за каждый скрипт

Самая безопасная схема проста. Человек, который создал скрипт, остаётся первым ответственным, потому что он знает странные случаи, скрытые допущения и первые признаки того, что что-то идёт не так.

Запасной ответственный не должен быть самым умным человеком со свободным временем. Выбирайте того, кто уже работает рядом с этим процессом. Если скрипт затрагивает зарплату, возьмите человека, который уже проверяет данные по зарплате. Если он отвечает за деплой, выберите инженера, который уже смотрит релизы. Когда что-то ломается до начала работы, знакомый контекст важнее сырого навыка.

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

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

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

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

Договоритесь о правилах до того, как начнёте делить работу

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

Начните с обычного запуска. Опишите каждый шаг простым языком, а не разработческим жаргоном. Запасной должен понять его уставшим пятничным днём. Используйте прямые шаги: взять входной файл, проверить диапазон дат, запустить скрипт, сравнить суммы, отправить результат нужному человеку.

Затем добавьте правила остановки. Они важнее обычных шагов. Если скрипт выдаёт плохой результат, не находит ожидаемый файл или показывает суммы, которые сильно расходятся, запасной должен остановиться. То же правило действует, когда деплой затрагивает живые данные или задача бэкапа завершается намного быстрее обычного. Угадывание — это как мелкая проблема превращается в длинные выходные.

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

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

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

Правило уведомления основателя тоже должно иметь реальные пороги. «Сообщите основателю, если что-то сломается» — слишком расплывчато. «Сообщить основателю в течение 15 минут, если не прошла зарплата, суммы биллинга изменились больше чем на 10% или откат деплоя затронул клиентов» — это уже понятно. Когда правило записано, отпуск перестаёт ощущаться как ставка в казино.

Как выстроить передачу дел маленькими шагами

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

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

Держите заметки короткими и практичными. Запасному нужны точная команда или клики, нужный доступ и место хранения учётных данных, ожидаемый результат и первые признаки того, что что-то пошло не так.

Потом поменяйтесь ролями. Дайте запасному запустить скрипт на безопасном случае, а владелец пусть только смотрит. Используйте тестовую партию счетов, маленький деплой в staging или проверку вчерашнего бэкапа, а не запуск зарплаты в конце месяца. Основной владелец должен молчать, пока запасной сам не застрянет. Это молчание важно. Оно показывает, действительно ли работают заметки.

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

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

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

Простой пример из небольшой команды

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

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

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

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

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

В этом и есть смысл. Отпуск перестаёт быть риском, а основатель перестаёт быть запасным вариантом на случай каждого скрипта, который понимает только один человек.

Ошибки, из-за которых запасной не помогает

Двухчеловеческая ответственность ломается, когда второй человек есть только в документе. Запасной, который никогда не запускал зарплату, не отправлял пакет биллинга и не трогал скрипт деплоя, — это не запасной. Это только видимость покрытия.

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

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

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

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

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

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

Если хотя бы одного из этих элементов нет, запасной, скорее всего, будет просто наблюдать за проблемой, а не решать её.

Быстрая проверка перед тем, как кто-то уйдёт в отпуск

Запасной — это не запасной, пока он не может выполнить задачу в обычный вторник, без сообщения основателю и без поиска потерянных заметок.

Перед уходом кого-то в отпуск проведите сухую проверку. Запасной должен открыть инструменты, пройти шаги и выполнить один безопасный тестовый прогон или недавний повтор. Вам нужны доказательства, а не вера на память.

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

Этот момент про нормальный результат важнее, чем команды обычно думают. Человек может нажать кнопку и всё равно не заметить, что суммы по зарплате выглядят странно, биллинг создал дубли или деплой пропустил один сервис. Поставьте рядом один хороший пример результата и один плохой. Это быстро снимает сомнения.

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

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

Небольшая команда может проверить всё это за 20 минут. Если запасной дважды застрял, передача дел ещё не готова.

Что делать дальше

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

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

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

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

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

Если список запутан или ответственность всё ещё размыта, может помочь внешний технический руководитель. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как Fractional CTO, помогая командам снижать операционные риски, укреплять инфраструктуру и выстраивать практичную передачу дел без тяжёлых процессов. Короткого аудита часто достаточно, чтобы превратить тревогу основателя в понятных владельцев, проверенные доступы и передачу дел, которой команда действительно может пользоваться.