Комментарии 74
Интересно было бы узнать чем именно вам не подошёл Заббикс. У них сейчас есть Заббикс Агент 2, написанный на Go. К нему можно прикручивать собственные плагины и в целом есть где развернуться.
В целом, никаких особых проблем с ним не возникало, разве что его настройка и интерфейс далеко не всегда просты для понимания. Да и изначально рассматривались более современные решения, а в частности про Агент 2 даже и не знал. Посмотрю что там свежего появилось, спасибо.
отлично бы он отработал, если факт «техобслуживания» был бы его составной частью
Raspberry там, где хватило бы даже ардуины (Ну или STM32, если надо ресурсов поболее).
А для обновления софта можно было и APT использовать с собственным репозиторием, закрытым приватным ключом. Да, это не так модно, но зато проверено временем и… Оно просто работает.
Обновления мы доставляли именно deb пакетами, просто вместо APT использовали Ansible, что было удобно. А в качестве репозитория мы использовали уже развернутый ранее Nexus. На мой взгляд, в данном контексте выбор тулы для доставки пакетов мало что меняет.
а как на ардуине могла работать библиотека на Node.js мне вообще не ясно
Чтобы опрашивать несколько датчиков и передавать показания на сервер (функционал точно как у метеостанции на ардуине ;) ), можно обойтись и без node.js.
Можно. Ваша система позволяет масштабирование на 100500 узлов, да. Со стороны серверов. Но raspberry (достаточно дорогая и много кушающая), да в мобильной системе, где вибрации и перепады температуры — так себе идея.
Не мешайте коллегам осваивать бюджеты!
Вы что по длине статьи не видете, что им платят построчно)
Да и как вы себе это представляете? Пилить весь проект на Raspberry Pi, собрать все подводные камни, а потом перейти на другие платы, где память распаяна, и снова собирать все подводные камни? Ну бред же, никто так не делает.
Про сдохшую emmc ерунда, что бы она сдохла от износа её прям очень старательно нужно насиловать на запись, что в embedded даже на этапе разработки сложно достичь. Вот для примера у нас ни на одной плате ещё не умирала emmc, а вот microsd выкинуто немало. С microsd ещё часто бывает что они начинают отваливаться и терять данные когда нагреваются выше 40 градусов, притом без разницы китай это за 250 рублей или «индустриальная» карта от именитых брендов. Ну и проблема что «контакт с картой» пропал и нужно её переподключить раз в год у вас точно возникнет, для embedded это неприемлемо.
Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.
Вроде как пилот. Поэтому я и оцениваю со стороны скорости разработки. С моей точки зрения будет вполне разумным разработать новую платформу для массового внедрения с учётом накопленного опыта. Да, часть граблей придётся собрать заново, но это лучше и быстрее, чем разработать сложную систему на МК, а потом её переделывать.
Прочитав который вы бы поняли, что у нас не возникало каких-либо проблем с MicroSD, и стореджем вообще. Причем тут emmc и какую проблему он бы для нас решил, не ясно.
Концепция MVP предполагает, что сначала вам нужно проверить саму идею продукта, обкатать ее, и даже, возможно, полностью от не отказаться. Такие проекты никогда не делаются в Enterprise режиме с планированием на годы вперед. Нужно сделать что-то быстро, оценить результаты, и позже уже делать на их основе полноценное решение.
Я все еще считаю, что Raspberry для подобного прототипирования — почти идеальная платформа — в случае чего нужную плату можно купить в любом электронном ларьке Берлина вроде Conrad. Она позволяет сэкономить массу времени именно на этапе начальной разработки. Конечно, никто не предполагает использовать Raspberry для реального продакшен решения, которое будет на дорогах всей страны. Но пока, к сожалению, об этом и речь не идет.
От девайса что требовалось? Опрос датчиков, передача данных на серер, управление парой релюшек и лампочек. Причем энергопотребление на первом месте стоит.
Код вам и так и так писать надо, но не забываем, что есть куча готовых библиотек, что сильно упрощает задачу.
К томуже микроконтроллер можно вообще держать в режиме глубокого сна, пробуждая только по таймеру или прерываниям, что сводит его энергопотребление к совсем смешным значениям.
Да и как подметили ниже — микроконтроллеры более стойки к перепадам температур, что тоже важно.
Помимо прочего, там было довольно много криптографии и работы с ETH сетью. Вся идея решения была в подготовке базы для того, чтобы использовать ее в будущем полностью децентрализовано. К сожалению не для всего есть децентрализованные решения, но мы старались использовать их по минимуму.
Э-э-э, простите, но нахера нужна децентрализованная база в сервисе проката скутеров?
Со всеми поставленными задачами может справиться nrf52840, BLE уже на борту.
Связь делается через внешний 3G/LTE модуль, через LoRa, или что-то еще.
Кстати у нордика недавно новая платформа подоспела nRF9160 — Low power SiP with integrated LTE-M/NB-IoT modem and GPS. Платформа практически для смарт-часов. Отличный вариант для этой штуки.
Мы не могли отказаться от ее использования или переписать самостоятельно, а альтернатив ей на тот момент не существовало.
Я реально не понимаю, когда компания говорит «Не можем». Это не причина.
Нет денег / нет времени / нет специалистов (знаний) — это причина. Хотя, на самом деле, всё упирается исключительно в деньги.
Короткий ответ: отчасти и то и другое, но основное, как я и написал выше — отсутствие альтернатив.
Длинный ответ:
Проблемы, с которым мы столкнулись, также описаны в первом посте о проекте, ссылка на который есть в статье.
Основная идея была в децентрализации, и несмотря на то, что далеко не все компоненты системы сразу удалось сделать децентрализованными, мы к этому стремились, по крайней мере в части ядра платформы.
Самую ключевую роль в ней играли смарт контракты, DID, Verifiable Credentials и, собственно, сам Ethereum.
Скутер сам общался с клиентом, без посредников. Деньги с кошелька пользователя так же списывались децентрализовано, с использованием контрактов.
Для всей этой логики, помимо нашего собственного функционала, необходимо было иметь массу "обвязки", вроде децентрализованной аутентификации, подписи транзакций Ethereum и валидации сигнатур Verifiable Credential'ов, которые были выписаны тем или иным DID (которые тоже нужно было верифицировать). Для всего этого также необходимо много криптографии. Мы выбрали партнера — компанию Jolocom, с которым успешно работали ранее, и у которых есть готовая библиотека для большинства вышеописанного. К сожалению, им не удалось в срок завершить имплементацию подобной библиотеки на каком-либо низкоуровневом языке, а подобных решений "на рынке" на тот момент не существовало вовсе.
Писать подобную библиотеку самим (например на Go) означало бы в несколько раз увеличить сроки разработки пилота, что было попросту невозможно (банально скутеры востребованы только пока на улице еще не слишком холодно, запуск и так был сдвинут с лета на осень, но зимой мы запускаться не могли).
В итоге, мы были вынуждены использовать то что есть — Node.js
Я надеюсь, что после этого пояснения, вопросов о том почему мы его все-таки использовали больше не возникнет. Это была критически важная для сути пилота функциональность, и у нас не было альтернативных вариантов.
"Скутер сам общался с клиентом, без посредников. Деньги с кошелька пользователя так же списывались децентрализовано, с использованием контрактов."
Спасибо, теперь понятно почему, но непонятно зачем ;) Телеметрия собирается централизовано и online; обновления рассылаются централизовано; зачем ещё один сложный и интересный механизм?
для функционала по децентрализованной аутентификации
А зачем в этой схеме нужна децентрализованная аутентификация, если внутри ansible и ssh?
Раздолбайство и недальновидность (не предусмотрели такой простой и, самое главное, вполне себе очевидный и нередкий сценарий) — вот как это называется.
Вообще, для этого не нужна была какая-то поддержка в системе мониторинга, у нас просто был Slack канал, где саппорт мог отписаться в случае необходимости ремонта скутера. Коллега, забравший скутер, не смог этого сделать из-за разрядки мобильного (и забрал скутер не подумав о последствиях). Мне кажется, предусмотреть этот сценарий было непросто. Для нас был однократным — больше не повторялось.
Из всего рассмотренного вы выбрали kapacitor? Это же самый ужас из всего, что кто-либо когда-либо писал. Код на kapacitor'е невозможно отлаживать.
Я просто оставлю это тут. https://medium.com/opsops/hammering-nails-into-kapacitor-coffin-8ebb13f8e427
Вопрос: а почему тяжеловесный и медленный Balena Etcher, а не rufus, к примеру?
В общем, Etcher мне кажется максимально «тупым» и удобным инструментом для своей задачи, поиск альтернатив нам не требовался, так как он всем устраивал.
"… ничего не знаю, у меня вот точно такая же нога, и она не болит!"
Не думаю что проблема в том что у нашего IT-департамента руки растут не оттуда. Скорее всего вам повезло, а нам — нет. Просто сходите на форум этчера и посмотрите какие у людей возникают проблемы, и убедитесь что многие из них — реальные проблемы, а не ошибки пользователя. Возможно сейчас этчер вылизан до блеска, но год назад пользоваться им было больно.
Вы либо крестик снимите, либо трусы наденьте — или заявляя, что это MVP, сделать минимально-рабочую систему, не закладываясь на ситуацию «ну вооот, у нас когда-то же будет не 30, а 30000 скутеров, тогда и пригодится», и тогда половина всего это не нужно, или сказать, что все-таки фигачим на перспективу, и не пытаться подстроиться под решения на готовом ПО, а просто взять и написать свой сервер, благо с таким функционалом его написать можно за неделю, взяв какой-нибудь эластик для долговременного хранения логов и поиска по ним.
На этом ресурсе за объективную критику, выражаемую определённым небольшим компетентным процентом пользователей, можно получить субъективные оценки от большого, некомпетентного, но очень активного и неуважительного процента.
Поэтому уважающие себя компетентные разработчики действительно объективную критику дают там, где они контролируют токсичность среды сами.
Такие дела.
Во-вторых, даже в ответ на конструктивную критику автор отстреливается из штурмгевера.
Смысл?
Более того, минусов уважаемому vvzvlad уже насовали и баланс он держит благодаря наплыву тех, кто с ним солидарен. Вероятно, если будет хайп-два, то «РРРЯ» будет более сильным.
«Если не видите, то его нет».
статья отлежалась и всё отгремело.Тут уже с первых комментариев только критика. Любви и обожания лично я не вижу.
автор отстреливается из штурмгевераОткуда вы знаете, что минусует конкретно он? Если такая уверенность есть, ну минусуйте в ответ.
он держит благодаря наплыву тех, кто с ним солидарен
Вероятно, если будет хайп-дваДа просто свою точку зрения он изложил грамотно и всё подробно обосновал. Это не просто эмоции «мне не нравится, уносите»: указаны конкретные точки, где масштабирование будет затруднено.
Мне быть съеденным не хочется, поэтому я буду критиковать в другом месте.
Сказал бы, что с вами не согласен, но вижу что вы даже не прочитали статью:
- Мы не делали кластер с HA, потому что для пилота и нашего небольшого количества скутеров нам вполне хватило одного инстанса InfluxDB, именно об этом и написано в разделе про Influx.
- Обновления были совершенно необходимы, чтобы банально не бегать каждый раз по всему городу за скутерами, дабы установить на них последнюю версию софта/агента/драйверов которые, даже за время пилота, обновлялись многократно
- Что значит "зачем промышленные решения"? TICK промышленный? Тогда почему вы предлагаете еще более монструозный эластик как решение? (и ведь про него тоже есть в статье)
Говоря об MVP — мне кажется, то что "делаем на перспективу" очевидным. В этом вся его суть — нет смысла делать пилот, если изначально нет надежд на развитие продукта.
И конечно, делать их нужно быстро и "чтобы работало". Но если качественная реализация, которую после MVP переделывать не придется, реализуется быстро — почему бы не сделать сразу?
У вас половина статьи про выбор стека для обеспечения HA, и потом где-то в конце «а, ну кстати и одного InfluxDB хватает, оказывается». Да блин, а нафига было тратить кучу времени и вообще думать в сторону HA и ынтерпзайзного TICK? То, что одного инстанса хватит — можно было оценить примерно за пять минут, умножив 30 скутеров на количество метрик в секунду.
Обновлять было необходимо приложение, а не систему. Для обновления приложения хватило бы apt-get upgrade you_program по крону или через условные systemd/Timers или напрямую бинарник из репы гита. Это делается примерно за 2 чд, а у вас ушло полторы недели на подбор сервиса, в котором есть все, разве что гусей не насилуют, и в конце-концов, вы еще и выкинули наработки, потому что не смогли использовать.
Не надо «делать на перспективу», это оборачивается вот такими штуками — когда на каждую мелочь сначала неделю команда пытается продумать все возможные требования, а потом еще неделю героически решает несуществующие проблемы, что кратно увеличивает срок разработки. Сделали первую версию, поработали, если выжили — выкинули 7чд, сделали за такой же срок новую версию. Эластик монструозный и много жрет памяти, но какая разница, если у вас 30 скутеров? Вертикальным масштабированием это число скейлится примерно до 500, а там либо шах, либо ишак — или стартап сдохнет, или станет понятно, что модель рабочая, появятся новые требования, и можно будет осознанно написать новые требования к системе и что-то сделать на их основе новое. Вы раньше на трафик наткнулись, чем на ограничения по ресурсам сервера.
После MVP систему приходится переделывать, в этом и суть: там не зря стоит слово «минимальный». Все равно в ходе эксплуатации появляются новые требования. Не надо писать ничего сверх того, что необходимо для работы, это позволяет проверять гипотезы быстро и без особых затрат — в том числе потому, что сделанное стоит недорого, и его можно легко выбросить и переделать, как только возникла в этом нужда. А как только вы тратите 150чд на проект, вы уже не можете переделывать это каждый раз — вам жалко усилий, кода, времени, денег, а ненужная тяжесть системы уже тянет вас на дно, накладывая обязательства по поддержке и использованию этого кода.
Про то, что «реализуется быстро» я честно говоря, не понял — половина статьи это нытье про то, что мало времени. Если ты чувствуете за спиной дыхание дедлайна — это значит, вы реализуете проект недостаточно быстро, либо сами сроки разработки были оценены неверно. И несмотря на то, что было мало времени, вы все равно напихивали и напихивали в стек ненужных сервисов, пытаясь сделать красиво и на века, хотя там хватило бы скрипта на питоне, который бы пихал данные в ES, и некоторой обвязки для его нормальной работы.
Оставшееся время стоило потратить на более внятные алерты, чтобы не возникало ситуации «аккумулятор сел, а мы даже не знали, что он сел, потому что были озабочены HA, а не снятием состояния батареи».
Опять вы со своим эластиком и масштабированием. Мы не занимались масштабированием и нам не нужен был эластик, просто потому что он значительно сложнее, тяжелее и медленнее TICK.
Комментировать возможности обновления скутеров в виде крон джобы я даже не буду. И да, мы обновляли и систему в том числе.
Но вы бы, конечно, сделали все то же самое с эластиком на питоне и за неделю. Что же, успехов вам. Только не забывайте вовремя сообщать о подобных своих достижениях в твиттере.
Ничего вы не ожидали, если хотите конструктив — то будьте добры и сами писать по делу.
На самом деле, то что проект оверинженирен само по себе чистая правда, только вот кроется это вовсе не в масштабировании или доставке обновлений.
Без регулярных удаленных обновлений софта было бы крайне некомфортно проходить даже пилотную фазу. Конкретно пакеты именно через apt и доставлялись, только делалось это не по крону, а по событию от анзибла. Ничего сверх-сложного тут нет, оно работает и стабильно.
А про мониторинг — я пытался описать максимально подробно свой опыт использования стека — авось кому понадобится, а может быть кто-то захочет и скалировать его для своих задач (и не сможет этого сделать). Специально обрисовал видимые нами недостатки, альтернативы, чтобы кто-то мог спроецировать свои требования в будущем.
Тот же эластик, как мне кажется, уже морально устарел и описанные в статье альтернативы его прекрасно заменяют. Отмечу, кстати, что скалирование эластика — весьма себе непростая задача, даже для вполне прокачанных девопсов.
С ВПНом можно было бы поступить гораздо проще (отказаться от WireGuard), имей мы доступ к симкам для которых были бы доступны готовые профили OpenVPN aka 1nce — но на тот момент у нас их просто не было.
В чем действительно была проблема данного проекта — так в изначальной идее децентрализованного проката, но вы ведь об этом даже не подумали. А тут и кроется основной недостаток любой подобной платформы — что бы ни было внутри, эфир, DIDы итд — все это должно одновременно быть анонимным и децентрализованным (как условные криптовалюты), но при этом отвечать нормам и правилам того или иного государства.
Как сделать децентрализованный анонимный прокат, который можно будет при этом проводить по немецким законам? Как не следить за пользователями, за которым по закону нельзя следить, но при этом не потерять возможности контроля над скутерами?
Такие вопросы я вижу конструктивными.
Наоборот. Благодаря тому, что данные были действительно анонимизированы, мы смогли собирать со скутеров всю информацию в рамках закона. В эфире пользователи не имели никакой персонализации кроме совершенно случайных публичных ключей.
Технически, с точки зрения криптоакта это, конечно, анонимизированные данные. Но, с позиции DPA, связанный с криптоактом кортеж данных (телеметрия, например), приводящий к деанонимизации, может сыграть злую шутку.
У вас логи на оконечных устройствах шифровались? И применялись организационно-технические меры для предотвращения атак на сами устройства?
Надо отметить — на самих устройствах мы не имели права собирать какие-либо данные, которые могли бы быть связаны с пользователем. Это касается персонификации, местоположения, итд.
Все операции были эфир транзакциями и по определению были публичны, другое дело, что шифровать их нужды не было, так как там не было данных, которые могли нарушать закон. Мы довольно долго проводили аудит этой темы и GDPR с legal отделом, так что в этом проблем не было.
Логи с устройств мы тоже не собирали, по тем же причинам — для нас телефоны были только устройствами которые могли запрашивать у скутера информацию напрямую и отправлять в эфир сеть какие-то транзакции.
Имели право или нет — это вопрос второго плана.
А вот собирали или нет — вопрос первого.
Собственно, по причине существования плавно обойденных моментов (на фоне довольно детальной и избыточной проработки технического вопроса в формате некоего «руководства к действию для тех, кто пойдёт таким путём») ваша статья и вызвала неоднозначный, резкий, и непубличный выброс метана в закрытых сообществах (если вы икали последние пару дней, то да, причина тут).
Пилотная фаза в терминологии ГОСТ 34.601-90 — это «проведение необходимых научно-исследовательских работ» или «проведение опытной эксплуатации»?
> Такие вопросы я вижу конструктивными.
Но ни один из них вы в статье не осветили, а вместо этого погрузились в бессмысленные технические детали.
Ничего вы не ожидали,
А, да, простите, вам лучше знать, чего я ожидал, а чего не ожидал. Подскажете, куда я ключи от гаража дел, вторую неделю найти не могу?
> Скутер сам списывает криптовалюту со счетов клиентов
> Централизованный мониторинг координат
> Систему построили так, что бы в любой момент можно было поменять что угодно без ведома клиентов
> Клиенты оставляют скутеры у себя под домом
Ну, нормально, добротный такой криптостартап, 10 инвестиций из 10.
Вернуть пропавший скутер, или история одного IoT мониторинга