Большое спасибо за статью. Очень жаль, что тема подписи коммитов недостаточно популярна, как и осознание потенциальных рисков при работе без подтверждения авторства. Также крайне не рекомендую создавать бессрочные ключи.
Интересно было бы придумать механизм оценки качества работы таких AI-тренеров. Возможно, через сотни тестовых вопросов с заложенной в них случайной, но контролируемой вариацией, и тестировать одновременно как тренера, так и обученную им сеть.
Также стоит серьёзно подумать о fact checking и логике в исходных данных при обучении, чтобы застывший цемент не вытекал из стакана. В целом, есть проблема оценки достоверности обучающего материала и пока сети не могут качественно решить такой вопрос (перепроверки достоверности и перестройки логики фактов во всём масштабе сети), особенно, если недостоверность в обучаемых данных просто берёт количеством. То есть, обучать сети по содержимому тех же СМИ - довольно "опасное" занятие в социальном плане, если подобным обученные сети будут получать статус первичного авторитета знаний.
Следующим шагом в развитии GPT-like моделей должна быть роль child: когда сети массово разрешат задавать вопросы людям, а не просто отвечать на запросы. На основе этого механизма можно сильно улучшить ту самую перепроверку достоверности. Но, всё равно, фактор массовой ошибки будет продолжать влиять на качество выводов такой сети.
Есть некоторое подозрение, что в глобальном плане именно к этому всё и идёт - к созданию country-specific сетей-оракулов, со своей "достоверной" информацией и правильной "логикой". На которые, со временем, привяжут все сферы жизни общества - от обучения в школах, до законотворчества и решения судов. Очень хочется ошибаться в подобных прогнозах.
В целом, это как с ядерными технологиями: можно строить полезные станции с серьёзной генерацией и, через удешевление стоимости первичных ресурсов производства, делать всё остальное дешевле и доступнее, на десятилетия. А можно психануть и расхерачить всё к чертям, создав непригодные территории, на столетия. Инструмент в обоих случаях по сути един и вопрос лишь в том, как им пользоваться, и какие цели ставить.
Какой у книги ISBN (оригинала)? Это третье издание "Python for finance" (если да - в чём различие между версией последнего релиза второго издания от 31.07.2020) с переводом на русский или же другая книга?
Изначально моя мысль была про то, что сам kubernetes как инструмент, усложняется и становится дороже. Что приводит к удорожанию всего, что вокруг него. Что для варианта bare metal, что в целом для варианта as service в облаках.
Утрированно, но всё же: мне не нужно 50 различных вариаций исполнения сетей внутри подов, также не нужно 50 вариаций мониторингов policy и менеджмента кастомных ресурсов. Сам факт необходимости сделать правильный выбор из всего этого существующего зоопарка, необходимость знания всех его "обитателей" - будет повышать как стоимость админов/DevOps-ов, так и стоимость исправления ошибки, если выбор по каким-то причинам неверен. Клиенты при этом не особо понимают, а зачем платить больше, мне нужно чтобы всё работало, а что вы там за сеть к подам сделаете, как настроите service discovery, как это всё и чем будет в плане ACL/policy разграничиваться - это всё слишком сложно, решите всё сами.
Облачные сервисы сложно назвать быстрыми в плане решения проблем, особенно, если они нетривиальные и затрагивают несколько продуктов такого сервиса. Решения таких проблем может занять несколько дней и более, и это стабильно случалось с 2 из 3 топ мировых облачных провайдеров. SLA они заявляют одни, на деле, при длительном использовании (годы), их не особо стремятся поддерживать, от sorry letter мало пользы в итоге, время на простой тратится с оплатой не из их кармана. Быстрый отклик у облаков в основном по простым вещам.
В плане железа при работе напрямую с одним вендором, с поддержкой и прочим - та же по сути ситуация: чем сложнее задача, тем дольше её будут решать. Или вообще не будут, потому что у большинства всё ок.
Если речь исключительно о софтовой платформе, то можно также упереться в годами неисправляемые баги, даже с открытыми bounty на них, часто где-то на уровне драйверов с железным слоем. И железо это не всегда вариант поменять.
В итоге, чем больше клиентов у такого сервиса, тем с бОльшей вероятностью, что время особо вам, как клиенту, уделять не будут. Когда компания-вендор маленькая, для её репутации проблемы клиентов - её проблемы. Когда уже большая - то проблемы клиентов, в основном, это только проблемы клиентов. Общая очередь и ожидание. Даже если реальный источник проблемы клиентов находится на стыке использования нескольких продуктов такого вендора. Или же в его же железе/конфигурации. Если наберётся много клиентов со схожими задачами - будут решать. Если нет - можно ждать решения годами. Ни один договор ни с одним вендором не заключает полноценных материальных возмещений убытков при неисполнении SLA. Это, как правило, оговаривается допсоглашением в индивидуальном порядке. Как и набор обслуживания по сервисам, если вне общих "тарифов". Выход на уровень судебных разбирательств в итоге не решает изначальную проблему, а только даёт надежду на возмещение убытков. За которую также придётся заплатить. В итоге будет дешевле переехать.
Самодельные инсталляции требуют оперативного наличия опытных админов, готовых быстро помочь. Не всегда это в принципе получается за разумное время: версии софта растут, диффы изменений мало кто вообще смотрит, документация почти никогда не поспевает за версиями. Могут даже в новой минорной версии что-то молча поломать. На разбирательства может уйти уйма времени, да, это будет долго и дорого в итоге.
Если изначально подойти к вопросу изоляции инфраструктуры от её провайдера, формировать её сразу как набор сервисов на основе kubernetes, то в этом случае перенос даже части инфраструктуры, как между облачными провайдерами, так и переезды на собственный bare metal вариант будет гораздо проще. Да, потребуются так или иначе service-specific штуки, которые неизбежно привязаны к провайдеру, но их, по возможности, надо втягивать в описание инфраструктуры проекта как можно меньше. То же относится к любым вариациям хранилищ, key vaults, image storage-ам, настройкам сетей и пр. В случае же разрозненности сервисов в проекте и подхода к их изначальному созданию - всегда будет длительный переход. С тестами, оценкой по ресурсам. Возможно, что даже и перенос станет слишком дорогим и дешевле будет переписать всё "с нуля".
Любая привязка к какому-то конкретному облачному провайдеру это всегда боль и расходы в будущем. Крайне желательно создавать инфраструктуру с минимальными завязками на что-то конкретное из сервисов провайдера. В идеале, перенос с облаков на bare metal (подготовленный в плане сети) должен проходить довольно просто. Даже для стабильных крупных проектов. Но, к сожалению, желание кастомизации здесь и сейчас довольно часто перевешивает понимание больших расходов в не столь далёком будущем. И это без учёта каких-либо архитектурных ошибок.
Тоже, скорее всего, выскажу непопулярную мысль про то, что необходимо, по возможности, уходить от использования terraform-а и строить инфраструктуру на KaS, что облачном, что bare metal. Не всегда это получается (что-то network-specific), но у реализаций terraform-а у каждого облачного провайдера, на мой взгляд, часто слишком много используется специфичного в описании инфраструктуры, что будет неизбежно приводить к осложнению и удорожанию любого переезда куда-либо ещё. И чем дольше такая ситуация сохраняется в процессе роста проекта, с сохранением привязок к провайдеру - тем хуже.
В любом случае, оценку правильности выбора или решения о переездах куда-либо имеет смысл делать на основе метрик ближе к деньгам/расходам на инфраструктуру. Не только через сбор до принятия решения, но и после (об этом практически все забывают). Может со временем стать выгоднее вернуть часть инфраструктуры в облака, к примеру. В идеале, метрики стоимости обслуживания (и даже возможного переноса, через конфиги тарифов провайдеров) лучше всего собирать по каждой изолированной сущности/сервису. Итоговое решение можно вообще отдать логике скрипта, генерирующего рекомендации, чтобы исключить потенциально коррупционный человеческий фактор или эмоции.
Готовые сервисы в начале, как правило, дешевле, да. Стоимость решений граблей, пока они ещё маленькие, также дешевле у готовых сервисов. Но потом постепенно начинается привязка инфраструктуры своих проектов к таким готовым сервисам и, с определённого момента, цена за такое удобство в итоге становится сильно дороже, чем было в начале (с учётом уже стоимости миграции на что-то другое). Особенно в стоимости оперативного решения проблем. При этом, параллельно с этим растёт и стоимость такого перехода из-за роста сложности инструментария и недостаточности рук на рынке.
В итоге, наиболее правильным переход в кубер был бы при очевидных перспективах резкого роста нагрузки и/или уже при её существенном наличии, а не просто "чтобы было", "нам нужен быстрый деплой 60 раз в день" или "все так делают и мы будем делать". Инструменты стали сложнее, обслуживание стало также дороже.
Если компания уже решила, что kubernetes нужен с первого дня без вариантов, то разумнее всего делать независимую конфигурацию, чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках, а потом уже тяжёлые части, не требующие зональности и доступа из сети, перетягивать на свой bare metal. При этом собирать доп метрики про то, а действительно ли такой шаг привёл к экономии. Это очень поможет в объяснении последующих миграций в ту или иную сторону. Как минимум, инвестор будет видеть, что вы понимаете, что вы собираетесь делать и решения на чём-то основаны, кроме эмоций.
Возможно, выскажу непопулярную мысль, но kubernetes с годами превращается в дорогого в содержании монстра (если всё делать изначально правильно и не забивать на мониторинг/поддержку), даже если брать средний масштаб компаний.
Инструментов для "помощи" до сих пор ежегодно появляется довольно много, при этом общая сложность и общие риски системы в целом уже давно не уменьшаются, а, скорее, наоборот. Безопасность часто заканчивается на сетевом уровне (до подов) и чеками образов, часто с забиванием болта на безопасность инструментов проверки таких образов. Платить за сервис настройки и "дорогих" админов/DevOps-ов также особо никто не хочет, дешевле получать и дальше граблями в лоб, сносить кластера и выкатывать всё заново. К обновлению версий кубера очень популярен тот же подход.
Инструменты, по возможности, должны упрощаться и улучшаться, чтобы экономить время и ресурсы их пользователям. Но этого, в случае с kubernetes, не происходит, на мой взгляд.
Ещё интереснее механизмы многомерной оптимизации в динамических системах (изменяющаяся топология, изменяющиеся веса/"нагрузка"), когда есть, к примеру, базовая оптимальная модель и далее происходит оптимизация различных отклонений целевых показателей. Также можно рассматривать более сложную модель с грузоперевозками/такси, когда не только надо минимум по расходам, но и минимум по "штрафам", при невозможности или задержках доставки при динамической маршрутизации. Один авто только с одним пассажиром, только с точками A и B - это относительно просто.
Продолжайте эту тему, при желании и возможности. Большое спасибо за статью.
Было бы здОрово продолжить развитие этого проекта в сторону небольшого автоматизированного тестера на том же STM32, по аналогии с китайскими мультитестерами различных компонентов. Но с бОльшей информативностью, чем просто показатель индуктивности и сопротивления. К примеру, находить пики по мощности, частотам, КПД и пр. Возможно даже определить примерный подсчёт витков, для конфигурации всего двух обмоток или же просто соотношения витков в обмотках.
Если кто-то с вышеописанным в качестве законченного и недорогого устройства сталкивался - буду благодарен информации/ссылкам.
Какая у "вас"/проекта типизация траффика? Разделение по ФО (РФ) через geoIP, странам, платёжеспособным зонам (на основе анализа пользователей, совершавших покупки за последние Х дней)? Есть ли heatmap таких платёжеспособных зон и если да - то как с ними работаете в плане повышения эффективности расходования ресурсов на такие зоны, также от расходов на рекламу до расходов на логистику в них.
Проводите ли анализ "сезонности" траффика внутри дня и недели? Возможно, в зависимости от продолжительности резко возросшей нагрузки, имеет смысл заранее запустить резервные мощности в минимально необходимом объёме и за полгода-год сравнить hit rate такого подхода, помогает ли он повысить доступность сервисов или экономить на чём-то.
Проводите ли анализ стоимости рисков недоступности и восстановления микросервисов во времени и деньгах, а также есть ли схемы дополнительного частичного резервирования таких сервисов на случай сложных/нестандартных проблем? Например, с самим kubernetes или его обновлением, либо с системой сбора и анализа метрик и логов, либо при глобальных сетевых проблемах в рамках одного сервис-провайдера и его геозон датацентров.
Пробовали ли вы проводить тренировки по полной миграции всей инфраструктуры на другие сервис-провайдеры, к примеру, для оптимизации расходов на инфраструктуру? Если да - было бы интересным узнать как всё это происходило, какие инструменты использовали, какие проблемы возникали и прочее.
Как у вас реализован мониторинг выполнения SLO? Это скрипты по метрикам из прометея или что-то более сложное? Часто к глобальным метрикам бизнес-инфраструктуры привязывают различные алерты, которые, с учётом ранее оцененной стоимости, могут генерировать различные алерты для различных источников их возможного решения, вплоть до "сопровождения" инцидента в системе глобального мониторинга всего проекта.
Есть ли у вас версионирование API и список поддерживаемых версий? Если да - как вы с ним живёте и работаете за время развития продукта. К примеру, если взять информацию по code coverage и наборы текущих тестов с привязкой к версионности API, то можно сформировать картину по каждому тесту или группе тестов, какие участки кода дольше всего живут и какие отвечают за бОльшее покрытие поддерживаемых версий. В итоге, можно даже попробовать построить стоимость участков такого кода, определить их важность в деньгах/времени и это далее учитывать при оценке сложности/стоимости новых задач для разработчиков, как корректируемый коэффициент предполагаемой стоимости от 1 до 10, либо "не ниже чем". Потенциально, это может существенно помочь в оценке времени и стоимости работ, немного упростить менеджмент задач, к примеру, заранее распределяя заведомо сложные на соответствующих разработчиков.
С помощью анализа более-менее крупных участков кода, как самого продукта, так и набора тестов для них всех уровней, можно, к примеру, с помощью скрипта проанализировать через простейший git blame список авторов кода, наиболее актуальных по времени и активных во вкладе участников, эту информацию уже использовать вплоть до предложения списка участников митинга по новым задачам, затрагивающим "старые". Со временем, если "старый" разрабочик всё дольше не имел отношения к определённому участку кода проекта - он всё реже станет привлекаться к обсуждению новых задач, связанных со старым кодом, тем самым, будет происходить оптимизация времени разработчика как на митинги, так и на оценку новых задач (в зависимости от того, что за подход в оценке задач используется).
Всем ли вас устраивает MySQL и если нет - как вы на уровне инфраструктуры и микросервисов проводите подготовку по изоляции проекта от хранилища и переходу на какое-то другое, к примеру, на PostgreSQL? Если, конечно, такая задача вообще имеется на горизонте. Есть ли дробление на типы данных для удобства и ускорения восстановления в случае ЧП, либо это какой-то "монолитный" бэкап, снимающийся с readonly хостов в периоды слабой нагрузки?
Почему решили продолжать работать с rabbitmq, с учётом уже прилично выросшего масштаба проекта? Всем ли он вас устраивает и нет ли желания переехать на что-то другое, типа kafka/flink/etc?
663 ТБ значит... Это вполне хороший ключ для кода Вернама, достаточно знать пару цифр начала и конца временного ключа шифрования. И API уже готовое, которое особо и нагружать часто не нужно. Только передавать пару цифр по защищённому каналу по окончанию использования старого отрезка ключа.
Спасибо за статью!
Большое спасибо за статью. Очень жаль, что тема подписи коммитов недостаточно популярна, как и осознание потенциальных рисков при работе без подтверждения авторства. Также крайне не рекомендую создавать бессрочные ключи.
November 18, 2021
https://www.gutenberg.org/files/33283/33283-pdf.pdf
Про блох на 8-й странице.
Отличная статья, большое спасибо! В ожидании следующей части.
Отличная статья, большое спасибо!
Большое спасибо за статью!
Интересно было бы придумать механизм оценки качества работы таких AI-тренеров. Возможно, через сотни тестовых вопросов с заложенной в них случайной, но контролируемой вариацией, и тестировать одновременно как тренера, так и обученную им сеть.
Также стоит серьёзно подумать о fact checking и логике в исходных данных при обучении, чтобы застывший цемент не вытекал из стакана. В целом, есть проблема оценки достоверности обучающего материала и пока сети не могут качественно решить такой вопрос (перепроверки достоверности и перестройки логики фактов во всём масштабе сети), особенно, если недостоверность в обучаемых данных просто берёт количеством. То есть, обучать сети по содержимому тех же СМИ - довольно "опасное" занятие в социальном плане, если подобным обученные сети будут получать статус первичного авторитета знаний.
Следующим шагом в развитии GPT-like моделей должна быть роль child: когда сети массово разрешат задавать вопросы людям, а не просто отвечать на запросы. На основе этого механизма можно сильно улучшить ту самую перепроверку достоверности. Но, всё равно, фактор массовой ошибки будет продолжать влиять на качество выводов такой сети.
Есть некоторое подозрение, что в глобальном плане именно к этому всё и идёт - к созданию country-specific сетей-оракулов, со своей "достоверной" информацией и правильной "логикой". На которые, со временем, привяжут все сферы жизни общества - от обучения в школах, до законотворчества и решения судов. Очень хочется ошибаться в подобных прогнозах.
В целом, это как с ядерными технологиями: можно строить полезные станции с серьёзной генерацией и, через удешевление стоимости первичных ресурсов производства, делать всё остальное дешевле и доступнее, на десятилетия. А можно психануть и расхерачить всё к чертям, создав непригодные территории, на столетия. Инструмент в обоих случаях по сути един и вопрос лишь в том, как им пользоваться, и какие цели ставить.
Какой у книги ISBN (оригинала)? Это третье издание "Python for finance" (если да - в чём различие между версией последнего релиза второго издания от 31.07.2020) с переводом на русский или же другая книга?
Спасибо за статью. Можно попробовать всё это перенести в ansible роли, на bash-е далеко не уедешь. По возможности - без terraform.
Изначально моя мысль была про то, что сам kubernetes как инструмент, усложняется и становится дороже. Что приводит к удорожанию всего, что вокруг него. Что для варианта bare metal, что в целом для варианта as service в облаках.
Утрированно, но всё же: мне не нужно 50 различных вариаций исполнения сетей внутри подов, также не нужно 50 вариаций мониторингов policy и менеджмента кастомных ресурсов. Сам факт необходимости сделать правильный выбор из всего этого существующего зоопарка, необходимость знания всех его "обитателей" - будет повышать как стоимость админов/DevOps-ов, так и стоимость исправления ошибки, если выбор по каким-то причинам неверен. Клиенты при этом не особо понимают, а зачем платить больше, мне нужно чтобы всё работало, а что вы там за сеть к подам сделаете, как настроите service discovery, как это всё и чем будет в плане ACL/policy разграничиваться - это всё слишком сложно, решите всё сами.
И "чем дальше в лес, тем толще волки".
Облачные сервисы сложно назвать быстрыми в плане решения проблем, особенно, если они нетривиальные и затрагивают несколько продуктов такого сервиса. Решения таких проблем может занять несколько дней и более, и это стабильно случалось с 2 из 3 топ мировых облачных провайдеров. SLA они заявляют одни, на деле, при длительном использовании (годы), их не особо стремятся поддерживать, от sorry letter мало пользы в итоге, время на простой тратится с оплатой не из их кармана. Быстрый отклик у облаков в основном по простым вещам.
В плане железа при работе напрямую с одним вендором, с поддержкой и прочим - та же по сути ситуация: чем сложнее задача, тем дольше её будут решать. Или вообще не будут, потому что у большинства всё ок.
Если речь исключительно о софтовой платформе, то можно также упереться в годами неисправляемые баги, даже с открытыми bounty на них, часто где-то на уровне драйверов с железным слоем. И железо это не всегда вариант поменять.
В итоге, чем больше клиентов у такого сервиса, тем с бОльшей вероятностью, что время особо вам, как клиенту, уделять не будут. Когда компания-вендор маленькая, для её репутации проблемы клиентов - её проблемы. Когда уже большая - то проблемы клиентов, в основном, это только проблемы клиентов. Общая очередь и ожидание. Даже если реальный источник проблемы клиентов находится на стыке использования нескольких продуктов такого вендора. Или же в его же железе/конфигурации. Если наберётся много клиентов со схожими задачами - будут решать. Если нет - можно ждать решения годами. Ни один договор ни с одним вендором не заключает полноценных материальных возмещений убытков при неисполнении SLA. Это, как правило, оговаривается допсоглашением в индивидуальном порядке. Как и набор обслуживания по сервисам, если вне общих "тарифов". Выход на уровень судебных разбирательств в итоге не решает изначальную проблему, а только даёт надежду на возмещение убытков. За которую также придётся заплатить. В итоге будет дешевле переехать.
Самодельные инсталляции требуют оперативного наличия опытных админов, готовых быстро помочь. Не всегда это в принципе получается за разумное время: версии софта растут, диффы изменений мало кто вообще смотрит, документация почти никогда не поспевает за версиями. Могут даже в новой минорной версии что-то молча поломать. На разбирательства может уйти уйма времени, да, это будет долго и дорого в итоге.
Если изначально подойти к вопросу изоляции инфраструктуры от её провайдера, формировать её сразу как набор сервисов на основе kubernetes, то в этом случае перенос даже части инфраструктуры, как между облачными провайдерами, так и переезды на собственный bare metal вариант будет гораздо проще. Да, потребуются так или иначе service-specific штуки, которые неизбежно привязаны к провайдеру, но их, по возможности, надо втягивать в описание инфраструктуры проекта как можно меньше. То же относится к любым вариациям хранилищ, key vaults, image storage-ам, настройкам сетей и пр. В случае же разрозненности сервисов в проекте и подхода к их изначальному созданию - всегда будет длительный переход. С тестами, оценкой по ресурсам. Возможно, что даже и перенос станет слишком дорогим и дешевле будет переписать всё "с нуля".
Любая привязка к какому-то конкретному облачному провайдеру это всегда боль и расходы в будущем. Крайне желательно создавать инфраструктуру с минимальными завязками на что-то конкретное из сервисов провайдера. В идеале, перенос с облаков на bare metal (подготовленный в плане сети) должен проходить довольно просто. Даже для стабильных крупных проектов. Но, к сожалению, желание кастомизации здесь и сейчас довольно часто перевешивает понимание больших расходов в не столь далёком будущем. И это без учёта каких-либо архитектурных ошибок.
Тоже, скорее всего, выскажу непопулярную мысль про то, что необходимо, по возможности, уходить от использования terraform-а и строить инфраструктуру на KaS, что облачном, что bare metal. Не всегда это получается (что-то network-specific), но у реализаций terraform-а у каждого облачного провайдера, на мой взгляд, часто слишком много используется специфичного в описании инфраструктуры, что будет неизбежно приводить к осложнению и удорожанию любого переезда куда-либо ещё. И чем дольше такая ситуация сохраняется в процессе роста проекта, с сохранением привязок к провайдеру - тем хуже.
В любом случае, оценку правильности выбора или решения о переездах куда-либо имеет смысл делать на основе метрик ближе к деньгам/расходам на инфраструктуру. Не только через сбор до принятия решения, но и после (об этом практически все забывают). Может со временем стать выгоднее вернуть часть инфраструктуры в облака, к примеру. В идеале, метрики стоимости обслуживания (и даже возможного переноса, через конфиги тарифов провайдеров) лучше всего собирать по каждой изолированной сущности/сервису. Итоговое решение можно вообще отдать логике скрипта, генерирующего рекомендации, чтобы исключить потенциально коррупционный человеческий фактор или эмоции.
Готовые сервисы в начале, как правило, дешевле, да. Стоимость решений граблей, пока они ещё маленькие, также дешевле у готовых сервисов. Но потом постепенно начинается привязка инфраструктуры своих проектов к таким готовым сервисам и, с определённого момента, цена за такое удобство в итоге становится сильно дороже, чем было в начале (с учётом уже стоимости миграции на что-то другое). Особенно в стоимости оперативного решения проблем. При этом, параллельно с этим растёт и стоимость такого перехода из-за роста сложности инструментария и недостаточности рук на рынке.
В итоге, наиболее правильным переход в кубер был бы при очевидных перспективах резкого роста нагрузки и/или уже при её существенном наличии, а не просто "чтобы было", "нам нужен быстрый деплой 60 раз в день" или "все так делают и мы будем делать". Инструменты стали сложнее, обслуживание стало также дороже.
Если компания уже решила, что kubernetes нужен с первого дня без вариантов, то разумнее всего делать независимую конфигурацию, чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках, а потом уже тяжёлые части, не требующие зональности и доступа из сети, перетягивать на свой bare metal. При этом собирать доп метрики про то, а действительно ли такой шаг привёл к экономии. Это очень поможет в объяснении последующих миграций в ту или иную сторону. Как минимум, инвестор будет видеть, что вы понимаете, что вы собираетесь делать и решения на чём-то основаны, кроме эмоций.
Возможно, выскажу непопулярную мысль, но kubernetes с годами превращается в дорогого в содержании монстра (если всё делать изначально правильно и не забивать на мониторинг/поддержку), даже если брать средний масштаб компаний.
Инструментов для "помощи" до сих пор ежегодно появляется довольно много, при этом общая сложность и общие риски системы в целом уже давно не уменьшаются, а, скорее, наоборот. Безопасность часто заканчивается на сетевом уровне (до подов) и чеками образов, часто с забиванием болта на безопасность инструментов проверки таких образов. Платить за сервис настройки и "дорогих" админов/DevOps-ов также особо никто не хочет, дешевле получать и дальше граблями в лоб, сносить кластера и выкатывать всё заново. К обновлению версий кубера очень популярен тот же подход.
Инструменты, по возможности, должны упрощаться и улучшаться, чтобы экономить время и ресурсы их пользователям. Но этого, в случае с kubernetes, не происходит, на мой взгляд.
Ещё интереснее механизмы многомерной оптимизации в динамических системах (изменяющаяся топология, изменяющиеся веса/"нагрузка"), когда есть, к примеру, базовая оптимальная модель и далее происходит оптимизация различных отклонений целевых показателей. Также можно рассматривать более сложную модель с грузоперевозками/такси, когда не только надо минимум по расходам, но и минимум по "штрафам", при невозможности или задержках доставки при динамической маршрутизации. Один авто только с одним пассажиром, только с точками A и B - это относительно просто.
Продолжайте эту тему, при желании и возможности. Большое спасибо за статью.
Большое спасибо за статью.
Было бы здОрово продолжить развитие этого проекта в сторону небольшого автоматизированного тестера на том же STM32, по аналогии с китайскими мультитестерами различных компонентов. Но с бОльшей информативностью, чем просто показатель индуктивности и сопротивления. К примеру, находить пики по мощности, частотам, КПД и пр. Возможно даже определить примерный подсчёт витков, для конфигурации всего двух обмоток или же просто соотношения витков в обмотках.
Если кто-то с вышеописанным в качестве законченного и недорогого устройства сталкивался - буду благодарен информации/ссылкам.
Возможно, имеет смысл посмотреть в сторону K6 .
Большое спасибо за ответ.
Большое спасибо за статью.
Какая у "вас"/проекта типизация траффика? Разделение по ФО (РФ) через geoIP, странам, платёжеспособным зонам (на основе анализа пользователей, совершавших покупки за последние Х дней)? Есть ли heatmap таких платёжеспособных зон и если да - то как с ними работаете в плане повышения эффективности расходования ресурсов на такие зоны, также от расходов на рекламу до расходов на логистику в них.
Проводите ли анализ "сезонности" траффика внутри дня и недели? Возможно, в зависимости от продолжительности резко возросшей нагрузки, имеет смысл заранее запустить резервные мощности в минимально необходимом объёме и за полгода-год сравнить hit rate такого подхода, помогает ли он повысить доступность сервисов или экономить на чём-то.
Проводите ли анализ стоимости рисков недоступности и восстановления микросервисов во времени и деньгах, а также есть ли схемы дополнительного частичного резервирования таких сервисов на случай сложных/нестандартных проблем? Например, с самим kubernetes или его обновлением, либо с системой сбора и анализа метрик и логов, либо при глобальных сетевых проблемах в рамках одного сервис-провайдера и его геозон датацентров.
Пробовали ли вы проводить тренировки по полной миграции всей инфраструктуры на другие сервис-провайдеры, к примеру, для оптимизации расходов на инфраструктуру? Если да - было бы интересным узнать как всё это происходило, какие инструменты использовали, какие проблемы возникали и прочее.
Как у вас реализован мониторинг выполнения SLO? Это скрипты по метрикам из прометея или что-то более сложное? Часто к глобальным метрикам бизнес-инфраструктуры привязывают различные алерты, которые, с учётом ранее оцененной стоимости, могут генерировать различные алерты для различных источников их возможного решения, вплоть до "сопровождения" инцидента в системе глобального мониторинга всего проекта.
Есть ли у вас версионирование API и список поддерживаемых версий? Если да - как вы с ним живёте и работаете за время развития продукта.
К примеру, если взять информацию по code coverage и наборы текущих тестов с привязкой к версионности API, то можно сформировать картину по каждому тесту или группе тестов, какие участки кода дольше всего живут и какие отвечают за бОльшее покрытие поддерживаемых версий. В итоге, можно даже попробовать построить стоимость участков такого кода, определить их важность в деньгах/времени и это далее учитывать при оценке сложности/стоимости новых задач для разработчиков, как корректируемый коэффициент предполагаемой стоимости от 1 до 10, либо "не ниже чем". Потенциально, это может существенно помочь в оценке времени и стоимости работ, немного упростить менеджмент задач, к примеру, заранее распределяя заведомо сложные на соответствующих разработчиков.
С помощью анализа более-менее крупных участков кода, как самого продукта, так и набора тестов для них всех уровней, можно, к примеру, с помощью скрипта проанализировать через простейший git blame список авторов кода, наиболее актуальных по времени и активных во вкладе участников, эту информацию уже использовать вплоть до предложения списка участников митинга по новым задачам, затрагивающим "старые". Со временем, если "старый" разрабочик всё дольше не имел отношения к определённому участку кода проекта - он всё реже станет привлекаться к обсуждению новых задач, связанных со старым кодом, тем самым, будет происходить оптимизация времени разработчика как на митинги, так и на оценку новых задач (в зависимости от того, что за подход в оценке задач используется).
Всем ли вас устраивает MySQL и если нет - как вы на уровне инфраструктуры и микросервисов проводите подготовку по изоляции проекта от хранилища и переходу на какое-то другое, к примеру, на PostgreSQL? Если, конечно, такая задача вообще имеется на горизонте. Есть ли дробление на типы данных для удобства и ускорения восстановления в случае ЧП, либо это какой-то "монолитный" бэкап, снимающийся с readonly хостов в периоды слабой нагрузки?
Почему решили продолжать работать с rabbitmq, с учётом уже прилично выросшего масштаба проекта? Всем ли он вас устраивает и нет ли желания переехать на что-то другое, типа kafka/flink/etc?
Спасибо.
663 ТБ значит... Это вполне хороший ключ для кода Вернама, достаточно знать пару цифр начала и конца временного ключа шифрования. И API уже готовое, которое особо и нагружать часто не нужно. Только передавать пару цифр по защищённому каналу по окончанию использования старого отрезка ключа.
Спасибо за статью, часть тех же проблем пришлось пройти недавно. Vector в целом хорош, но всё равно сырой в плане долгосрочной стабильности.