Еще один пост про SuperDAO (простите, побуду немного стартапером).
 
Довольно хайповый проект, стартовавший в 2021ом как платформа для создания и поддержки DAO (децентрализованных организаций), несколько дней назад закрылся. Юрий Лившиц, фаундер, любезно поделился с сообществом опытом, что мне показалось очень занятным. Интересующимся рекомендую ознакомиться, полезная информация также в pre-seed/seed memo (понять, как делается позиционирование для инвестора, сравнение с другими проектами). Запали две мысли:
 
1. В 2021ом было популярно мнение, что крипто/веб3 изменит разные отрасли (игры, недвижимость, спорт, программы лояльности и тд), люди из разных отраслей будут создавать DAO, чего в итоге не случилось, только крипто + финансы оказалось рабочей связкой.
2. Клиенты, которые использовали DAO для своих компаний, не получали лучших операционных метрик по сравнению с традиционным (еще и более понятным) способом организации юрлица.
 
В итоге, в такой рыночной коньюнктуре, SuperDAO не мог построить устойчивый бизнес и ребята решили закрыть проект. Хочу пожелать им удачи и уверен, что следующий проект у них точно получится – они супер крутые.

Почему вам не нужен account abstraction (AA) если вы не делаете свой кошелек
 
Про AA в двух словах. Есть два подхода к кошелькам в Ethereum:
 
1️⃣ традиционный – Externally Owned Accounts, EOA – пара адрес/приватный ключ, который невозможно поменять. Кошелек инициирует транзакции, подписывая их приватником. Но чтобы отправить транзу, нужен газ. Если приватник засветился или потерялся, то туши свет. Такие в целом минусы.
 
2️⃣ современный – Smart Contract Accounts (SCA). Это когда создается кошелек – смарт контракт, и на него закидываются средства. И вот тут уже можно прикрутить разные интересные штуки, типа multisig (чтобы отправить транзу, нужны например, подписи двух его владельцев), или можно авторизацию по email прикрутить. А вот чтобы отправить транзакцию от имени этого смарт-контракта, как будто от EOA, и придумали AA. Сейчас стандарт ERC4337.
 
Осенью мы в Yoki начали разработку пилота по приему платежей для клиента. В то время я думал, как прикрутить AA, чтобы улучшить качество продукта. А именно – у нас решение некастодиальное – чтобы газ спонсировать для клиента, или чтобы для оплаты газа было достаточно купленного через fiat on ramp стейблкоина, например. Думал про создание смарт аккаунта, чтобы юзер закидывал туда средства на подписки.
 
Далее, после раздумий и обсуждения с партнером, стало понятно, что юзеры побоятся отправлять средства на смарт-контракт, созданный пока никому не известным протоколом Yoki finance.
 
❗️Следовательно, чтобы решить часть задач, лучше всего сделать, чтобы наш dApp бесшовно работал со Smart Contract Wallets, т.е. кошельками на основе SCA. Соответственно, мы имеем плюшки типа мультисига, логина по email, оплату газа любым токеном, fiat-on-ramp, предоставляемых привычным юзеру кошельком и все это в нашем dApp как бы

Я тестил Safe и Ambire, и остановился на последнем, т.к. там есть оплата газа стейблкоинами, что мне и нужно было для тестирования приложения. Пока тестируем на нем, смотрим как работает, про AA не вспоминаем. Такие дела.
 
P.S. Если вам зачем-то понадобится информация про AA, то вот тут люди целую гитхаб репу запилили.

После прочтения текста выше могло показаться , что мы интегрируемся только с Ambire. Нет, будем работать с любым Smart Contract Wallet, поддерживающим WalletConnect (лидеры все поддерживают). Нужно только убедиться , что все сделали правильно, и интеграция работает.

ERC2612 и dApp UX
 
Тут разраб из твиттера запилил сервис на Ethereum для получения газового токена, если у вас его нет. Например, купили USDC на бирже, перевели на кошелек, воспользовались сервисом и счастье – есть чем за газ платить.
 
Хорошая идея! Начал разбираться, как реализовано. Оказалось, стандартом ERC2612, который позволяет делать gasless approvals. В двух словах, юзер оффчейн подписывает "документ" со сроком действия, который криптографически подтверждает разрешение снятия (аппрув) контрактом-ботом определенного количества токенов с дедлайном. Далее этот документ-разрешение передается боту, который вызывает permit у токена (дает аппрув, проверяя документ), снимает нужное количество с кошелька, меняет на газовый токен, берет свою комиссию.
 
Классное решение! – подумал я. Стало интересно, какие популярные токены так могут. Сделал простейшую аналитику на наличие permit в коде, см. картинку.
 
Негусто! – почесал репу. И запилил прототип, посмотреть как работает на примере Polygon USDC.e, который был у меня кошельке и… потратив чуть ли не день, с удивлением обнаружил – чтобы корректно поддерживать ERC2612, токен должен корректно реализовывать и EIP712, а с этим у USDC.e проблема. Он пытается его реализовать, но domain separator конструируется не по стандарту, соответственно, подпись, сделанная кошельком по EIP712, не проходит. Получилось допилить ethers.js, чтобы принимал захардкоженный domain separator, который можно дернуть с токена, но на UI это, по видимому, невозможно… В итоге все заработало на обычном USDC, поэтому из таблицы часть "зеленых" – это никакие не зеленые, а прикидывающиеся зелеными (тема отдельной проверки). Если будет интерес, то напишу статью на эту тему.
 
Прочитал в Сети мнение, что в Эфире только ERC20 нормально сделан, а остальное стагнирует, в том числе из-за легаси. Интересно, есть ли не-EVM блокчейны, где функции для UX побогаче, с учетом полученного на Ethereum опыта? Думаю, настало время попробовать что-то еще.
 
Не одним эфиром, как говорится.

Запоздалый анонс. Кто пришел не с Хабра – тему с ERC2612 я раскрыл в статье там.
 
Так что, если хотите подробнее узнать, как работают gasless approvals и выдача разрешений – приятного чтения.

Вышли в прод…
 
Нелегко писать о своих успехах, но я попробую, к тому же это непосредственно связано с тем, то что сам программирую. В марте наш протокол крипто-нативных подписок @yokifinance (автор сих строк – кофаундер/CTO) вышел в продакшен эксплуатацию, мы подключили двух клиентов 🎉🎉:
 
–  Крупнейший русскоязычный подкаст про блокчейн – Базовый Блок,  где можно оформить подписку на эксклюзивный/ранний доступ к материалам и поддержать ребят за их просветительскую деятельность

– Web3 Growth Agency Altcoin Edge. У ребят есть закрытый клуб с отобранным контентом для крипто-инвесторов для глубокого погружения в крипто-проекты, и Yoki используется для подписки на этот контент.
 
Самое приятное, что пошли подписки, и через нас прошло более $300. Да, это слезы, но сам факт радует. Хотел бы поблагодарить всю нашу команду (ребята, вы космос!), и клиентов за оказанное доверие.
 
Для разработчиков (и не только), как это работает:
1️⃣ Пользователь подключает кошелек и дает аппрув на снятие (по умолчанию это 6 периодов подписки, минимальный – один период – для тех, кто хочет проверить) на определенный контракт подписки.
2️⃣ Контракт подписки определяет токен и объем списания, а также частоту (контролируется он-чейн). Также, куда идут деньги после снятия (мерчанту и нам чуть-чуть в виде комиссии).
3️⃣ Пп. 1-2 приводят к полной ончейн прозрачности. Пользователь видит контракт, и сколько и как часто могут сняться средства. Не может быть, что сегодня снимали 10 USDT / месяц, а завтра 100 USDT – параметры зашиты ончейн. Мы также не просим закидывать средства куда-либо.
4️⃣ В отличие от почти всех протоколов, которые обычно запрашивают аппрув на максимальную сумму, мы по умолчанию ставим шесть (минимум один) периодов.
 
Ну и по хорошей традиции – репо с нашими смарт-контрактами

Первый веб3 хакатон
 
На выходных хакатонил в Frameworks от ETHGlobal. Создавали фреймы и инструменты для хайповой последнее время соцсети Farcaster – очень похожа на X, только с элементами децентрализации.
 
Фрейм – это мини-приложение, которое появляется в ленте, только еще с привязкой к криптокошельку. Можно сминтить NFT или сделать другое ончейн действие. Я делал, чтобы можно было поддержать автора, донатя каждый месяц определенную сумму через @yokifinance (сюрприз!).
 
Мой фоллоу-ап в рандомном порядке, пишу для себя на будущее; может и вам будет полезно 👇

1. Лучше узнавать о хакатоне заранее. У меня получилось так, что первый день (из двух) ушел на чтение теории. Теорию надо изучать заблаговременно, чтобы в момент Х старта хакатона сразу начать создавать продукт.

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

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

4. Проект делал на Pinata.cloud, frog, viem. Pinata по факту особо не юзал, но подался в их partner prizes, как оказалось зря. Frog – довольно сырая штука, у меня не проходил простейший approve (ну или я чего-то накосячил), пришлось делать демо без аппрува.

5. Много слышал про vercel, наконец-то попробовал его – очень удобно деплоить маленькие pet-проекты, даже не попросил карту, просто логин через гитхаб, выбор репозитория – и деплой в один клик/коммит! Особенно порадовала функция вставки нескольких переменных окружения через CTRL-C - CTRL-V из .env файла. Удобные логи. Видно что продумывали.

6. Так и не понял толком связку кошелек – Фаркастер, надо изучить. Были места, когда нужно вводить кошелек текстом во фрейме. Сейчас кошелек привязывается, когда надо сделать транзакцию, а как привязать его заранее?

7. В случае участия в основном треке (где надо лично докладывать проект) – лучше заранее подумать, кто ближе по таймзоне и будет докладывать. В ретроспективе понятно, что мой проект имел больше шансы на выигрыш в основном треке, но я выбрал партнерский трек еще и потому, что не смог бы сделать презу после 12ти часов нон-стоп кодинга, еще и ночью.
 
Кому сильно интересно – видео демо и код.

Запустил Ethereum ноду
 
Эпопея растянулась на пару месяцев. Сначала казалось, что делов на пару дней (есть же документация). Как это было:
 
1. В качестве клиентов взял Geth и Prysm. Да, лучше взять другие для client diversity, но я решил начать с самых популярных, чтобы набрать опыт (более популярные -≥ больше вопросов/ответов).
Т.к. разворачивал на сервере компании, а не на отдельной машине, принял решение разбить на 3 докер сервиса:
– geth – execution client (одноименный Geth).
– beacon – beacon (consensus) client (Prysm).
– ubuntu – сервисный для доступу к первым двумя внутри докер сети, а также для Clef, чтобы подписывать транзакции.
 
2. Железо – SSD Samsung 870 EVO MZ-77E2T0B/EU 2ТБ, 2.5", Intel Xeon E5620 @ 2.40GHz, 16 cores, 48Gb RAM. На 2 апреля 2024 занятое место на диске – 1,2 ТБ, snap sync. Geth использует 11 GiB, beacon – 9,5 GiB RAM.
 
3. Синхронизировалось все за несколько дней, использовал checkpoint sync, то есть синхронизировался не с генезиса (начала), а с текущего момента - чекпоинта.
 
4. Основной геморрой был с тем, чтобы заставить работать Geth и Prysm в докере, т.к. документация расчитана на локальную установку. По умолчанию geth-Prysm связываются через IPC (взаимодействие процессов), а нужно было настроить на общение через http. Соответственно, параметры geth --ipcdisable и --http, также нужно настроить порты, адреса прослушивания – все это значит менять дефолтные параметры, которые заточены на localhost. В docker compose все это учел. Но очень много времени потратил на выяснение, почему сервис не отвечает на портах.
 
5. Вынес все persistent данные из докер контейнеров на хост машину через volumes докера.

6. Clef (которым подписываются транзакции и управляются аккаунты) запустил без проблем, видимо сказался полученный опыт. Также общение через http. Он не обязательно должен быть запущен постоянно, только когда подписываете что-то, так что окей запускать его в ubuntu сервисе.
 
8. Хороший туториал для проверки работы ноды, мне очень помог; имейте в виду, что он тоже на локалхост рассчитан, нужно свои имена хостов (сервисов) подставлять.
 
Теперь могу использовать свою ноду для RPC API – вдруг на определенном моменте понадобится. Понимание работы блокчейна также улучшилось. Но еще больше улучшилось понимание Докера и сетевых моментов, хоть я в этом и не совсем новичок. Надежность сети чуть улучшил. А в целом вывод – свои ноды оправданы для больших проектов с огромной нагрузкой, для небольших стартапов точно лучше подойдут облачные провайдеры.
 
Docker compose файл в гитхабе + более технические моменты. PR велкам.

Где я был этот месяц
 
Расскажу в рандомном порядке, что произошло в апреле. Было не так много веб3, но было интересно.
 
1. В @yokifinance запилил интеграцию со Stipe. Если быть точнее, MVP, осталось принимать данные от Yoki, а не вручную. Переделал модель базы данных, чтобы соответствовать сущностям Страйпа – надеюсь, это упростит подключение для тех, кто уже имел опыт с ним.
Идея интеграции была в том, что если у мерчанта забиты продукты в Страйпе, и есть интеграция через вебхуки, то мы автоматически создаем такие же продукты и цены в Yoki. Когда юзеры оплачивают криптой у нас, то мерчант получает уведомления через существующую инфру.
Потом пришла информация что Страйп летом выкатывает оплату в стейблах. Очень надеюсь, что это плюс для адопшена.
 
2. Нода эфира, про которую рассказывал в прошлом посте, работает. Знакомые ребята попросили дать доступ, чтобы проверить работу с self-hosted нодой для одного из своих проектов. Работает стабильно.
 
3. На Хабре запилил статью про то, как оптимизировал запросы к Ethereum JSON RPC на ethers.js. Главный вывод – все облачные решения разные, и когда речь идет о работе на пределе (не 2 юзера в час), то нужно затачиваться под конкретного провайдера.
И тут нода пригодилась, делал тесты, и остался доволен скоростью работы по сравнению с облачными решениями.
 
4. Мой партнер подал Yoki на грант от Gitcoin. Удивительно, но за нас голосуют рублем какие-то неизвестные замечательные люди, на текущий момент уже 1148 голоса на сумму $2200, при этом мы нигде не пиарили эту активность (кроме анонса в соцсетях), не делали накруток, платеж доступен только на Arbitrum, и даже это людей не останавливает. Ни на что не намекаю, но голоса всегда приветствуются 🙂
 
5. В свободное время читаю про системы распределенного реестра на примерах ENS и Farcaster. Очень простая и мощная концепция. На примере достаточно децентрализованной социальной сети: не обязательно хранить все данные ончейн. Достаточно, чтобы onchain хранилось соответствие имени пользователя серверу, где ему можно написать сообщение. Таким образом, сервер не сможет забанить юзера, поскольку юзер всегда сможет поменять запись в registry и перейти на другой сервер.

Лето в разгаре
 
Решил порадовать вас последними апдейтами из моей личной жизни.
По традиции, последнее время совсем немного веб3 – уже думаю над переименованием канала, но пока держусь – я же фул-стек или как?
 
Из интересного, чем занимался – все связано с Yoki:
1. Подключил к проекту систему продуктовой аналитики Posthog. В двух словах:
 – система понравилась, ориентирована на разработчиков, UI почти всегда интуитивно понятен.
 – чуть сыровата, но пока критичных багов не нашел.
 – лучше закладывать подключение аналитики на этапе проектирования приложения – у нас было Реакт приложение статика, пришлось мигрировать на Next.js (потребовалась серверная часть для бутстрапа флагов).
– опенсорс, что важно, особенно в крипте – при желании можно развернуть на своем сервере.
 – заняло 3 недели.
 – впервые в жизни реализовал A/B тестирование – получил ачивку. Концептуально это не сложно, но технически немного запарно.
 
TL;DR запилил статью на Хабр
 
2. Реализовал поддержку чекаут сессий, как в Страйпе, с кастомизациями и все такое.
 
3. Поучаствовал в качестве менеджера, продакт овнера или просто помогатора с такими задачами, как поддержка нескольких цветовых тем, бекапы баз, сбор статистики по тому, какими токенами пользователи хотят платить, подключение новых мерчантов.
 
4. Чуть не попался на развод – чувак из твиттера предложил поработать над проектом, а т.к. я никогда не отказываюсь от клиентов для нашей компании по заказухе, я согласился. Перед звонком он попросил меня скачать софт для телеконференции, что я почти сделал; оказалось, что это был троян.

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

Работаю над проектом с децентрализованными биржами (DEX).
 
До этого работал с Uniswap. Сейчас с целым зоопарком – Uniswap, Curve, Sushiswap, Balancer, Bancor, Synapse, Dodo 🤯
 
Чтобы сделать обмен, сначала роутер (для Uniswap 1, 2) строит оптимальный путь обмена токенов. Пример – иногда может быть оптимальнее поменять USDT на USDC через промежуточный токен, или разделить (split) входную сумму на несколько частей.
 
Роутер строит оптимальный путь оффчейн, загружая информацию о текущих пулах через сеть с внешнего API (IPFS, TheGraph, …). То есть можно пользоваться DEXом, имея только доступ к ноде эфира, но оптимальный путь на больших объемах не получишь. У Sushi, Balancer, Dodo routing SDK не обнаружен, использовал внешнее API, которому говоришь – "дай мне оптимальный путь обмена USDT на WETH". Некоторые из таких API также имеют геоограничения – децентрализация в полный рост.
 
Оказалось, только Uniswap и Sushi имеют свою модель для оценки газа, который будет использован транзакцией обмена (в Uniswap это estimatedGasUsed ) – для меня было сюрпризом, что оценка делается не через eth_EstimateGas, а просто путем подсчетов в роутере. Быстрее и не всегда eth_EstimateGas может отработать – например, нет баланса или allowance. Для остальных пришлось строить модель оценки газа самостоятельно и это не всегда простая задача.
 
В сухом остатке – отрасль интересная, но все, что не Uniswap, сильно отстает по developer experience, поэтому нужно закладывать много времени на интеграцию.

⚡ Да, появилось свободное время, могу помочь вашему продукту консультациями или проектной работой в качестве разработчика/CTO в web3/crypto.

Интересен опен-сорс, developer tooling, DeFi, инфраструктура.

Связь @web3dev_notes_bot

Первый pruning geth
 
Или, по-простому, сокращение размера базы.
Банально – нода встала из-за недостатка места на диске. Хорошо, что были лишние файлы, которые можно было удалить – чтобы сделать pruning, нужно не менее 40 Гб свободных.
 
Делал по инструкции. У меня geth в докер контейнере, поэтому сделал так:
1. Остановил контейнер с geth.
2. Запустил новый контейнер docker run -d --name geth-prune-container -v /crypto/mainnet/ethereum:/root/.ethereum ethereum/client-go:latest snapshot prune-state , подмонтировав ему папку с базой.
3. Дождался завершения (заняло 8,5 часов).
4. Запустил контейнер с geth опять.
 
В результате освободил 260 Гб.
 
Да, geth пишут, что скоро поменяют схему данных, и pruning будет онлайн, без остановки ноды, что не может не радовать.

Отдельная благодарность Телеграму за простоту отправки уведомлений о чем угодно – за 10 минут настроил отправку уведомления о заполнении диска.

1. Создаю бот через @BotFather, выдается botId
2. Создаю группу в Телеге, добавляю туда бота и удаляю, потом опять добавляю (почему то если просто добавить – не работает).
3. Вызываю https://api.telegram.org/bot<botId>/getUpdates (можно в браузере, можно curl). Там увидите chatId: -9999999 (большое отрицательное число, это id группы).
4. Отправка сообщения представляет собой одну строчку в терминале curl -G  "https://api.telegram.org/bot<token>/sendMessage?chat_id=<chatId>" --data-urlencode "text=Message to group" и сообщение уходит в группу от имени бота. PROFIT
 
Пользуюсь этим для отправки разных уведомлений и оно всегда отлично работает

Ethereum node – сломался консенсус-клиент

Нода перестала отдавать данные по последним блокам, хотя JSON RPC работает. Проверяю как:
curl -s -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' https://your-node-rpc-url – выдает старый номер блока.

Стал смотреть докер-контейнеры – prysm постоянно рестартится с ошибкой в логе

could not get ancestor state: failed to unmarshal encoding: incorrect size

Текст неочевидный, но траблшутинг указал на то, что повредились данные консенсус-клиента (бывает после сбоя питания и тп). Как пофиксил:

1. Остановил контейнер Prysm
2. Дописал аргумент —force-clear-db в docker compose.
3. Запустил контейнер заново, подождал пока очистит папку.
4. Аккуратно остановил его docker stop --time 120 my_prysm_container, давая время ему остановиться самостоятельно.
5. Убрал —force-clear-db из docker compose и запустил его заново. Нода догнала последний блок со скоростью примерно чуть быстрее чем один день простоя за час.

Вывод: чтобы надежно поддерживать ноду, нужно еще мониторить состояние контейнеров (сюрприз!) – то, что она отдает данные, не значит, что они правильные.

Дебаг смарт-контрактов

Например, получаете ошибку навроде следующей в Hardhat или где-нибудь еще:

Error: call revert exception [ See: https://links.ethers.org/v5-errors-CALL_EXCEPTION ] (method="netAssetValue()", data="0x7123bc4c", errorArgs=null, errorName=null, errorSignature=null, reason=null, code=CALL_EXCEPTION, version=abi/5.7.0)

Главное тут – 4х байтная сигнатура ошибки 0x7123bc4c (может встречаться в тексте).

Идем на https://www.etherface.io/ , вбиваем сигнатуру и получаем человеческое объявление ошибки и даже ссылки на репо с соответствующим кодом (см. картинку).

Лепота!

Upd: конечно, этот сервис и сигнатуры функций ищет.

@web3dev_notes

Попробовал TheGraph
 
Это протокол для доступа к данным блокчейнов, поддерживает 70+ разных. Запросы пишешь на GraphQL. Если сравнивать с Dune Analytics, то Dune больше для аналитиков, а TheGraph – уровень данных для приложений. Заявляется, что TheGraph децентрализованный, распределенный, межгалактический, etc, но давайте про конкретику.
 
Нужно было выдернуть примерно 1 миллион записей по свопам одного из пулов. Как делал:
 
1. Создал сабграф (по сути, аналог хранимой процедуры в БД). Делал вот по этому туториалу, но в целом можно взять любой – обычно 80% воды, запаситесь терпением.
 
2. Задеплоил этот сабграф сюда https://thegraph.com/studio/ . Деплоить = закачать в staging enviroment. То есть этот сабграф процессится на сервере TheGraph, а не индексерами. Процессится бесплатно, тк это как бы тестовое окружение. Первый раз заняло 6 часов (примерно 1М записей), второй раз (поменял сабграф) – около суток (не понял почему, возможно потому что сделал join по свойству контракта, но это не точно). Publish = деплой в прод – на индексеры не делал.
 
3. Сгенерил клиент через graph-client. В целом можно сразу через curl дергать, но я наивно полагал, что graph-client поможет мне с паджинацией (нет).
 
4. После попыток заставить работать паджинацию, оказалось, что пропускать (skip) более 5000 записей TheGraph не может. Сортировать по более чем одному полю тоже (мне нужно было по трем). Искренне не понимаю, почему самые важные вещи не пишут сразу в документации, а описывают hello world'ы.
 
5. Написал самодельный алгоритм паджинации путем динамического изменения диапазона параметров запроса. Запрашивал данные для диапазона блоков, если результат был 5000 (то есть превышен лимит), ставил предпоследний_полученный_блок+1 первым в следующем запросе. Чтобы загрузить все данные (около 200 МБ) по сети потребовалось всего 3-5 минут.
 
В принципе, штука интересная, много наворочено. Буду держать в курсе.

@web3dev_notes

Пятничное.
Техподдержка
 
Недавно ребята из одного хорошего криптопроекта спросили, как организовать ТП.
Я не то что бы специалист в этом, но вспомнил, как мы однажды делали такое в заказной разработке в моей прошлой жизни.
Был у нас клиент – страховая компания из США, пилили для них внутренние веб-сервисы. Разница с нами 12 часов. Соответственно, если что-то падает у них – у нас ночь – работа клиента встает на день. Думали мы, как решить вопрос, и сделали так.
 
Из команды разработчиков проекта (а было там 3-4 человека) по очереди выбирался/назначался дежурный. Дежурили, кажется, по неделе, или по 2-3 дня (уже не помню), исключая выходные. В обязанности дежурного было не уезжать из зоны покрытия интернета, не уходить в загул и тд, и носить с собой специальный телефон, на который мог позвонить клиент даже ночью, сесть за комп и починить проблему. Конечно, при наличии соответствующих recovery процедур а-ля "перезапустить систему" и тд, заранее заботливо переданнных клиенту, которые он должен был сделать, прежде чем звонить нам.
 
За это мы разработчикам платили дополнительную оплату за каждый день дежурства, которую потом добавляли клиенту в счет. Звонки ночные были редки, раз в 3-4 месяца, поэтому в принципе всех все устраивало. Для разработчиков был доп стимул – сделать отлично, чтобы тебя не беспокоили, а доп оплата капала.
 
Вот так, что-то ностальгия нахлынула по тем временам. Кстати, канал точно читают ребята из той команды, так что поправьте меня, если где-то соврал🙂