Ну это в теории все красиво, для небольших сервисов. Но что-то я пока не видел, чтобы крупные конторы засунули свой жирный инстанс оракл в кубер ) Его вообще стараются не трогать лишний раз. Или у вас есть примеры?
Увы, но нет. Нестандартных не большинство. Стандартных типовых обращений всегда на порядок больше, может достигать даже и 90% от всех. Цифра, во многом, зависит от сферы, конечно, но меньше половины почти не бывает.
"стандартные" легко решаются через гугл или чтение мануалов
Вы слишком хорошего мнения о людях, обращающихся в поддержку )
p.s. но это не оправдывает то, что делают тупых и непроходимых ботов, лишь бы статистику обращаемости снизить любой ценой.
То есть поставить jitsi, не используя и не когнфигурируя то, что не нужно, это самосвал. А писать свой костыль, который делает то же, что и jitsi в мин конфигурации, тратя больше когнитивных и временных ресурсов это не самосвал. Понятно.
Ничего там не ляжет, откуда вы это взяли) Вы же сами написали, что речь про трех бабушек. Vps это даже не заметит.
Не очень понятна цель одного бинарника и неприязнь композа. Ну ладно веб ресурсы упаковывать, могу понять.
Но не очень понимаю, зачем перевыпуск сертов запаковывать в сам бинарь. Ну вот у меня сертами занимается отдельный выделенный компонент. Пусть это будет cert-bot, cert-manager, nginx или traefik. Он один общий на все мои приложения, почему и зачем приложение вообще этим занимается, это не его задача, как бы не хотелось завернуть все в один бинарь ( лучше все заворачивать в один композ ). Ну типа, что мне делать, если у меня wildcard сертификат на все сразу? Юзать jitsi.
Дело не консольных командах, это, вообще, не проблема, а в наличии посредника.
Doc-файлы просто комфортней читать, чем текстовые
А использование сторонних приложений для док не является посредником?) Или это другое уже. Тот же Markdown имеет в целом неплохие возможности форматирования, чем не комфорт? И зачем эти посредники ;)
какие проблемы?
Время это проблема. Ваша текущая схема крайне затратная по сравнению с гитом, и имеет лишнюю когнитивную нагрузку. Уж про удобство работы с изменениями я молчу. Как у вас посмотреть разницу в кодовой базе между некоторыми версиями? Окей, прогоняем дифф, а если перемешение файлов было?
Единственный смысл осваивать гит, я вижу, если надумаю публиковаться на Гитхабе. Пока, еще не решил, нужно ли мне это?
Вам не обязательно именно "публиковаться". Вы на гитхабе можете хранить приватную репу чисто на случай бекапа. Окей, не хотите вообще гитхаб, можно просто использовать локальный bare репо на флешке. Да и вообще, кто сказал, вам обязательно вообще надо куда-то пушить, нам достаточно просто удобно локально работать с историей ( примечание, гит и гитхаб - не совсем одно и то же, и гитом можно пользоваться без публикации куда-либо )
Вы же не диффы храните ведь в своей системе? Значит размер кодовой базы просто умножается, когда вы делаете "новую ветку"? Гит в этом плане сильно экономнее, храня только диффы
Вообще, кажется, что гит вы даже и не пытались щупть руками, не пытались применять. Очень вам советую попробовать это сделать, потом сами же будете смеяться с вашего "удобно" ;) Пишу как человек, который занимался абсолютно идентичной бессмысленной чепухой с копипастой директории, в конце концов превращающейся в помойку, хотя казалось очень удобным ( спойлер, нет, это помойка ) и тоже думал, что одиночке гит не нужен.
Такие вылазки я делаю примерно 6 раз в год. Комбинирую свои 28 дней отпуска плюс 3 дополнительных дня и совмещаю их с праздниками. Иногда беру что-то за свой счет.
Да как блин это у вас получается, вы колдуны)
1 на 14 дней, окей, но как остальное на 5 распределить, чтобы еще и успеть куда-то добраться с учетом 2 дней перелетов ( и раньше на перелет в одну сторону целый день закладывать надо было, а сейчас с задержками и подавно ) и при этом еще и успеть отдохнуть?) Я сколько не пытался к праздникам сувать, не выходит. Или ключевое в "за свой счет" все же?
Критика в мою сторону — она вообще не про меня. Это люди боятся тех, кто выбрал другой путь. Они просто свои страхи и сожаления проецируют. А нам, тем, кто уже попробовал "нормальные" способы заработка и не зашло, остается только один вариант — создавать свои миры.
Это не страхи, это реальная жизнь, факты и статистика ;)
Такой период возведения в идеал был у многих жителей хабра, думаю, если не у большинства даже. Впрочем, описание в самом посте прям очень похоже на меня в те же годы, разве что ИИ не было у меня.
Но все замечания, и вся "критика", увы, сбудутся с 99% вероятностью, в этом правда жизни. Банально, родственники, дающие крышу над головой и еду тоже не бесконечны, как и их заработок - реальная жизнь она непредсказуема довольно, ломает многие наши несбывшиеся желания.
Если же у вас этот настрой сохранится, и года через 3-5 вы не работая в найме, будете иметь стабильный продукт, приносящий прибыль - я буду аплодировать стоя вам, это невероятный труд, усидчивость и ... хорошая доля удачи в других аспектах в жизни, способствующих этому. Пинганите меня обязательно!
Полностью согласен, что опыт работы в найме — бесценен, но с оговоркой о полученном опыте с этого найма. Собственно, я так и написал в уточнениях: я бы с радостью воспользовался такой возможностью, если бы она давала нужные мне навыки. Мой выбор — не в принципиальном отказе от опыта, а в отказе от опыта, который не ведет меня к моим целям. Сейчас мой главный приоритет — получить уникальный опыт создания продукта с нуля, со всеми рисками и ошибками. Я уверен, что этот навык ничуть не менее ценен.
Ошибочно полагать, что вас ведет к цели только и только опыт быть продактом в конкретной сфере. Ошибочно полагать, что этот опыт более релевантен, чем все остальное.
Понятное дело, хард-скиллы продакта кроме как работой продактом не получить. Но помимо хард-скиллов для продакта куда важнее софт-скиллы и базовые рабочие скиллы - коммуникации, работа с командой, дисциплина, операционка и приоритизация, управление рисками. И эти скиллы Вам, как человеку, как специалисту, дает весь ваш прошлый бекграунд, вне зависимости от релевантности направления, опыта. И даже работа в макдаке дает многим людям первый опыт работы в команде, учит планировать свое время, учит тому, как бы работать не работая. Не говорю, что макдак идеальный вариант, просто любой опыт валиден будет, тем более продакту - хард-скиллы натаскать-то как раз вот не проблема продакту, проблема у продактов нередко в самой банальной коммуникации, приоритезации, рисках.
К тому же, с большой долей вероятности, без опыта работы в найме вам будет непросто вжиться продактом в компаниях с большими командами. Можно, но сложнее обойдется. Продакты, которые выросли из типового сотрудника этой же компании - самые топовые для этой же компании. Продакты со стороны, как правило, максимально унылые, за редкими-редкими исключениями.
процессов, в районе 6 месяцев изучал специальность продакт менеджера, где как раз-таки описываются все эти процессы + меня обучал топ-менеджер продакт лично из интереса хантинга на позицию продакта. Поэтому знания в этой области имеются.
Тут я боюсь огорчить, ходил я на такие, и могу сказать, что никакие курсы не дают и процента понимания реальных рабочих процессов. всех нюансов, возникающих в этих процессах, в реальной работе. Только реальный опыт и ничего кроме опыта. Пусть даже на себя, со своим продуктом, со своими делегированиями задач.
Реальные рабочие процессы сотканы из кучи условностей, костылей, нигде не задокументированных, компромиссов, баланса между деньгами бизнеса, хотелками бизнеса, требованиями ИБ и беклогом. На курсах мало кто расскажет о серьезных личных факапах, о том, как они маневрировали между требованиями заказчика и требованиями ИБ, или и того хуже - ФСБ/СОРМ/ФСТЭК, еще и забесплатно, а именно тут кроется вся изюминка. Даже если расскажут, то и рамки времени курса, и NDA не позволяет правильно оценить масштабы оного.
Реально самостоятельно имеет смысл освоить разве что ISO 9001, но и то, в чистом виде как оно описано внедрить все равно нереально, но в крупных компаниях его встречаешь повсеместно, как рабочее решение, так что это must have. А если речь про все эти аджайлы, срамы, канбаны, говнопады - учиться смысла нет. Главное лишь понять концепции. Оно в реальности не работает в таком виде все равно, кроме тех компаний, где их придумали.
В любом случае, я могу лишь пожелать удачи и даже позавидовать такому настрою. И опять же, если звезды сойдутся, удача будет на вашей стороне, и у вас все получится, ровно как вы и хотели бы, то пинганите обязательно. Не забывайте реально оценивать перспективу и риски.
Во-первых, точность координат самой базовой станции в 4cell, да и других подобных, не 100%, точность может плавать от 15 метров и выше, а то и вообще быть ошибочной (бс такой нет, или она слишком далеко, и тд), ну просто нет никакой гарантии точности(точно знают только опсосы), так как эти данные собираются опосредованно и примерно прикидываются по другим косвенным данным, в том числе по gps и другим lbs самых устройств, откуда данные собираются, ну и юзеры вручную тоже ту ещё дичь добавлять могут.
Во-вторых, точность же геопозиции LBS, в частности по триангуляции мобильных базовых станций, все же очень сильно плавает, но даже в идеальнеших условиях не даст точности в 2 метра. А чтобы знать точное местоположение свое, надо знать и точное местоположение бс (см.во-первых). То есть использовать то lbs можно, но погрешность в лучшем случае 25-50 метров. И правильно в этой ветке написали, донавигируются дроны чисто по камерам, если нет gps, даже 10 метров это уже существенная погрешность. Но и интернет не всегда нужен для такой донавигации, поговаривают, что сейчас нейросети научили для такой цели
Заявление температурных режимов ( внешней, подчеркну, температуры эксплуатации ) в широких пределах не означает автоматически, что производитель в т.ч. заявляет работу при обильных осадках ( попадании воды внутрь, замерзание оной и все что тут описали ) и солнечном нагреве ( а прямые солнечные лучи способны запросто раскочегарить выше этих 80 градусов, между прочим, пластик благо белый, но все же от коннекторов и креплений знатно дойдет ).
Так что если производитель не заявляет достоверно защиту от внешних погодных условий, то для увеличения срока эксплуатации лучше перестраховаться, как тут правильно пишут.
Это шутка что-ли? ;) Вы переоцениваете современных людей.
Было бы все так просто, не было бы такого стремительного роста инцидентов в горах, включая летальный исход, которых становится все больше, как раз за счет общего роста популярности маршрутов неопытными восходителями.
Не считая банальных повышения выносливости, повышения силовых (не просто бодибилдинг. отмечу) и функциональной подготовки (да, это все база, но я считаю важным упомянуть об этом ввиду того, что по данным ВОЗ, треть взрослого населения планеты банально не выполняют даже минимальную норму по физической активности, и нет, потягать три раза в неделю в зале брусья не тянут на эту норму, и очень много таких людей без физухи прутся на 5+ ), крайне желателен опыт горного трекинга и высотного альпинизма на высотах поменьше и попроще - это даст и психологическую подготовку, и акклиматизацию, будет сильно проще восходить.
Есть еще куча, казалось бы, банальных технических и бытовых вещей, но неочевидных для многих коммерческих восходителей. Ну типа там, собрать рюкзак без лишнего, чтение прогноза, планирование и тайминг выхода, умение двигаться в связке в темпе всей этой связки, как все, а не "я так привыкла", пользоваться ледорубами, не надевать лишнего, когда надо, и не снимать, когда не надо. Как действовать в случае внезапного ухудшения погоды и пропажи из виду гида, как действовать в случае горняшки у себя или у других. И куча еще всяких мелочей еще. И нет, это все за дни акклиматизации не усвоится и не расскажется.
Да и психология в целом играет огромную роль. Не каждый сходу психологически готов к многочасовому монотонному темпу, отсутствию сна, усталости. У многих сносит крышу. И с этим тоже надо ведь работать, а не "ну я такая какая есть".. И не каждый может вовремя остановить себя при наличии явных признаков горняшки. Ну типа "я же оплатил, чего добру терять"., надо же превозмогать ведь обязательно.
Вам может показаться это очевидным всё, вы может уже ходили, или ходили в горный треккинг хотя бы, но вот многим неопытным восходителям все это реально в новинку, многие их них даже в походы могли не ходить даже, а из физухи у них разве что тренажерный зал 2-3 раза в неделю.
Тут смотря о каких масштабах использования речь все же, да и о каких задачах.
Нередки случаи, когда счета на API за 1-2 месяца превышают стоимость A100. И я бы не сказал, что это экономия на спичках. Ну и не то, чтобы качество это плохо, просто не все могут и готовы к большим счетам за использование облачных моделей. А многим на самом деле достаточно небольших моделей для узких задач, и не надо впустую столько ресурсов тратить.
Ну и не стоит забывать про ФЗ152 и GDPR, который многих тоже ограничивает от использования онлайн сервисов, из-за чего и приходится использовать локальные сервисы.
Если речь про личное пользование, то тут и нет, и не было вопросов, облачное для личного будет в 99% случаев выгоднее. Вы не сможете один фиг утилизировать ресурсы локальных моделей, поэтому окупаемость долгая будет.
Ну можно начать с того, что на прод среду неправильный конфиг доехать и не должен вовсе, как минимум, это должно быть предварительно протестировано на препрод и\или тесте. Если все правится руками на горячую - ну тогда это вообще последняя проблема ;)
OpenTelemetry будет переполнятся память и возможно он упадет.
Ну давайте не делать из разработчиков лог-агрегаторов идиотов, пожалуйста ;)
Все подобные агрегаторы, типа Otel, Fluent-bit, Vector, Filebeat, и т.д. проектируется с учетом вероятных проблем на стороне экспортеров и такой кейс заведомо предусматривается, поэтому делается логика ограниченного буфера на диске или в памяти, при достижении лимита, в зав-сти от продукта и настроек, происходит либо очистка старых записей в буфере, либо остановка пайплайна, давая знать вышестоящим источникам об этом ( условно, если это происходит по HTTP - то дает знать при помощи кода 429 агентам ), и вышестоящие источники уже на стороне агентов верно интерпретируют это, останавливая чтение, если это возможно. Этот механизм везде называют по разному, но мне нравится backpresure - именно так можно встретить в документации Vector и Fluent-bit, например. Ну еще вот эта страница у Vector может быть интересна.
Сам тезис про единую точку отказа разбивается только лишь об тот факт, что в реальной прод нагрузке инстансов агрегаторов все же больше одного, а то и десятки, если мы говорим про сколько-нибудь заметную нагрузку highload или приближенную к нему. Если же у вас нагрузка настолько микроскопическая, что вам достаточно одного агрегатора, то скорее всего он вам и не нужен действительно ;)
Если при ресенде будет ошибка(а тг любит иногда кидать 400ку), либо инет моргнет, то как потом понять, что именно надо переотправить. Ну окей залогируем мы. А если мы пропустим ошибку и чухнемся через неделю только? ;)
Ну это в теории все красиво, для небольших сервисов. Но что-то я пока не видел, чтобы крупные конторы засунули свой жирный инстанс оракл в кубер ) Его вообще стараются не трогать лишний раз. Или у вас есть примеры?
Увы, но нет. Нестандартных не большинство. Стандартных типовых обращений всегда на порядок больше, может достигать даже и 90% от всех. Цифра, во многом, зависит от сферы, конечно, но меньше половины почти не бывает.
Вы слишком хорошего мнения о людях, обращающихся в поддержку )
p.s. но это не оправдывает то, что делают тупых и непроходимых ботов, лишь бы статистику обращаемости снизить любой ценой.
Потому что не все сидят в облачном гитхабе как бэ , довольствуясь онпремис установкой ;)
У меня ещё больше вопросов, если честно (
Ой как удобно. А давайте теперь покажем, как этот подход применить на существующей инфраструктуре, а? ;)
То есть поставить jitsi, не используя и не когнфигурируя то, что не нужно, это самосвал. А писать свой костыль, который делает то же, что и jitsi в мин конфигурации, тратя больше когнитивных и временных ресурсов это не самосвал. Понятно.
Ничего там не ляжет, откуда вы это взяли) Вы же сами написали, что речь про трех бабушек. Vps это даже не заметит.
У меня тот же вопрос.
Не очень понятна цель одного бинарника и неприязнь композа. Ну ладно веб ресурсы упаковывать, могу понять.
Но не очень понимаю, зачем перевыпуск сертов запаковывать в сам бинарь. Ну вот у меня сертами занимается отдельный выделенный компонент. Пусть это будет cert-bot, cert-manager, nginx или traefik. Он один общий на все мои приложения, почему и зачем приложение вообще этим занимается, это не его задача, как бы не хотелось завернуть все в один бинарь ( лучше все заворачивать в один композ ). Ну типа, что мне делать, если у меня wildcard сертификат на все сразу? Юзать jitsi.
А использование сторонних приложений для док не является посредником?) Или это другое уже. Тот же Markdown имеет в целом неплохие возможности форматирования, чем не комфорт? И зачем эти посредники ;)
Время это проблема. Ваша текущая схема крайне затратная по сравнению с гитом, и имеет лишнюю когнитивную нагрузку. Уж про удобство работы с изменениями я молчу. Как у вас посмотреть разницу в кодовой базе между некоторыми версиями? Окей, прогоняем дифф, а если перемешение файлов было?
Вам не обязательно именно "публиковаться". Вы на гитхабе можете хранить приватную репу чисто на случай бекапа. Окей, не хотите вообще гитхаб, можно просто использовать локальный bare репо на флешке. Да и вообще, кто сказал, вам обязательно вообще надо куда-то пушить, нам достаточно просто удобно локально работать с историей ( примечание, гит и гитхаб - не совсем одно и то же, и гитом можно пользоваться без публикации куда-либо )
Вы же не диффы храните ведь в своей системе? Значит размер кодовой базы просто умножается, когда вы делаете "новую ветку"? Гит в этом плане сильно экономнее, храня только диффы
Вообще, кажется, что гит вы даже и не пытались щупть руками, не пытались применять. Очень вам советую попробовать это сделать, потом сами же будете смеяться с вашего "удобно" ;) Пишу как человек, который занимался абсолютно идентичной бессмысленной чепухой с копипастой директории, в конце концов превращающейся в помойку, хотя казалось очень удобным ( спойлер, нет, это помойка ) и тоже думал, что одиночке гит не нужен.
-> No Code and No Docs
Баги могут превратиться в фичи или быть частью ТЗ, а ошибки - нет
Да как блин это у вас получается, вы колдуны)
1 на 14 дней, окей, но как остальное на 5 распределить, чтобы еще и успеть куда-то добраться с учетом 2 дней перелетов ( и раньше на перелет в одну сторону целый день закладывать надо было, а сейчас с задержками и подавно ) и при этом еще и успеть отдохнуть?) Я сколько не пытался к праздникам сувать, не выходит. Или ключевое в "за свой счет" все же?
Ох уж этот юношеский максимализм.
Это не страхи, это реальная жизнь, факты и статистика ;)
Такой период возведения в идеал был у многих жителей хабра, думаю, если не у большинства даже. Впрочем, описание в самом посте прям очень похоже на меня в те же годы, разве что ИИ не было у меня.
Но все замечания, и вся "критика", увы, сбудутся с 99% вероятностью, в этом правда жизни. Банально, родственники, дающие крышу над головой и еду тоже не бесконечны, как и их заработок - реальная жизнь она непредсказуема довольно, ломает многие наши несбывшиеся желания.
Если же у вас этот настрой сохранится, и года через 3-5 вы не работая в найме, будете иметь стабильный продукт, приносящий прибыль - я буду аплодировать стоя вам, это невероятный труд, усидчивость и ... хорошая доля удачи в других аспектах в жизни, способствующих этому. Пинганите меня обязательно!
Ошибочно полагать, что вас ведет к цели только и только опыт быть продактом в конкретной сфере. Ошибочно полагать, что этот опыт более релевантен, чем все остальное.
Понятное дело, хард-скиллы продакта кроме как работой продактом не получить. Но помимо хард-скиллов для продакта куда важнее софт-скиллы и базовые рабочие скиллы - коммуникации, работа с командой, дисциплина, операционка и приоритизация, управление рисками. И эти скиллы Вам, как человеку, как специалисту, дает весь ваш прошлый бекграунд, вне зависимости от релевантности направления, опыта. И даже работа в макдаке дает многим людям первый опыт работы в команде, учит планировать свое время, учит тому, как бы работать не работая. Не говорю, что макдак идеальный вариант, просто любой опыт валиден будет, тем более продакту - хард-скиллы натаскать-то как раз вот не проблема продакту, проблема у продактов нередко в самой банальной коммуникации, приоритезации, рисках.
К тому же, с большой долей вероятности, без опыта работы в найме вам будет непросто вжиться продактом в компаниях с большими командами. Можно, но сложнее обойдется. Продакты, которые выросли из типового сотрудника этой же компании - самые топовые для этой же компании. Продакты со стороны, как правило, максимально унылые, за редкими-редкими исключениями.
Тут я боюсь огорчить, ходил я на такие, и могу сказать, что никакие курсы не дают и процента понимания реальных рабочих процессов. всех нюансов, возникающих в этих процессах, в реальной работе. Только реальный опыт и ничего кроме опыта. Пусть даже на себя, со своим продуктом, со своими делегированиями задач.
Реальные рабочие процессы сотканы из кучи условностей, костылей, нигде не задокументированных, компромиссов, баланса между деньгами бизнеса, хотелками бизнеса, требованиями ИБ и беклогом. На курсах мало кто расскажет о серьезных личных факапах, о том, как они маневрировали между требованиями заказчика и требованиями ИБ, или и того хуже - ФСБ/СОРМ/ФСТЭК, еще и забесплатно, а именно тут кроется вся изюминка. Даже если расскажут, то и рамки времени курса, и NDA не позволяет правильно оценить масштабы оного.
Реально самостоятельно имеет смысл освоить разве что ISO 9001, но и то, в чистом виде как оно описано внедрить все равно нереально, но в крупных компаниях его встречаешь повсеместно, как рабочее решение, так что это must have. А если речь про все эти аджайлы, срамы, канбаны, говнопады - учиться смысла нет. Главное лишь понять концепции. Оно в реальности не работает в таком виде все равно, кроме тех компаний, где их придумали.
В любом случае, я могу лишь пожелать удачи и даже позавидовать такому настрою. И опять же, если звезды сойдутся, удача будет на вашей стороне, и у вас все получится, ровно как вы и хотели бы, то пинганите обязательно. Не забывайте реально оценивать перспективу и риски.
Это не так в большинстве случаев
Во-первых, точность координат самой базовой станции в 4cell, да и других подобных, не 100%, точность может плавать от 15 метров и выше, а то и вообще быть ошибочной (бс такой нет, или она слишком далеко, и тд), ну просто нет никакой гарантии точности(точно знают только опсосы), так как эти данные собираются опосредованно и примерно прикидываются по другим косвенным данным, в том числе по gps и другим lbs самых устройств, откуда данные собираются, ну и юзеры вручную тоже ту ещё дичь добавлять могут.
Во-вторых, точность же геопозиции LBS, в частности по триангуляции мобильных базовых станций, все же очень сильно плавает, но даже в идеальнеших условиях не даст точности в 2 метра. А чтобы знать точное местоположение свое, надо знать и точное местоположение бс (см.во-первых). То есть использовать то lbs можно, но погрешность в лучшем случае 25-50 метров. И правильно в этой ветке написали, донавигируются дроны чисто по камерам, если нет gps, даже 10 метров это уже существенная погрешность. Но и интернет не всегда нужен для такой донавигации, поговаривают, что сейчас нейросети научили для такой цели
Это немного разные вещи все же.
Заявление температурных режимов ( внешней, подчеркну, температуры эксплуатации ) в широких пределах не означает автоматически, что производитель в т.ч. заявляет работу при обильных осадках ( попадании воды внутрь, замерзание оной и все что тут описали ) и солнечном нагреве ( а прямые солнечные лучи способны запросто раскочегарить выше этих 80 градусов, между прочим, пластик благо белый, но все же от коннекторов и креплений знатно дойдет ).
Так что если производитель не заявляет достоверно защиту от внешних погодных условий, то для увеличения срока эксплуатации лучше перестраховаться, как тут правильно пишут.
Это шутка что-ли? ;) Вы переоцениваете современных людей.
Было бы все так просто, не было бы такого стремительного роста инцидентов в горах, включая летальный исход, которых становится все больше, как раз за счет общего роста популярности маршрутов неопытными восходителями.
Не считая банальных повышения выносливости, повышения силовых (не просто бодибилдинг. отмечу) и функциональной подготовки (да, это все база, но я считаю важным упомянуть об этом ввиду того, что по данным ВОЗ, треть взрослого населения планеты банально не выполняют даже минимальную норму по физической активности, и нет, потягать три раза в неделю в зале брусья не тянут на эту норму, и очень много таких людей без физухи прутся на 5+ ), крайне желателен опыт горного трекинга и высотного альпинизма на высотах поменьше и попроще - это даст и психологическую подготовку, и акклиматизацию, будет сильно проще восходить.
Есть еще куча, казалось бы, банальных технических и бытовых вещей, но неочевидных для многих коммерческих восходителей. Ну типа там, собрать рюкзак без лишнего, чтение прогноза, планирование и тайминг выхода, умение двигаться в связке в темпе всей этой связки, как все, а не "я так привыкла", пользоваться ледорубами, не надевать лишнего, когда надо, и не снимать, когда не надо. Как действовать в случае внезапного ухудшения погоды и пропажи из виду гида, как действовать в случае горняшки у себя или у других. И куча еще всяких мелочей еще. И нет, это все за дни акклиматизации не усвоится и не расскажется.
Да и психология в целом играет огромную роль. Не каждый сходу психологически готов к многочасовому монотонному темпу, отсутствию сна, усталости. У многих сносит крышу. И с этим тоже надо ведь работать, а не "ну я такая какая есть".. И не каждый может вовремя остановить себя при наличии явных признаков горняшки. Ну типа "я же оплатил, чего добру терять"., надо же превозмогать ведь обязательно.
Вам может показаться это очевидным всё, вы может уже ходили, или ходили в горный треккинг хотя бы, но вот многим неопытным восходителям все это реально в новинку, многие их них даже в походы могли не ходить даже, а из физухи у них разве что тренажерный зал 2-3 раза в неделю.
Что-то так сумбурно написано, что я даже не вник, а о чем статья-то? Что за боты, что за ПФ, причем тут открытые порты.. Помогите..
Эх, мечты мечты ..
Тут смотря о каких масштабах использования речь все же, да и о каких задачах.
Нередки случаи, когда счета на API за 1-2 месяца превышают стоимость A100. И я бы не сказал, что это экономия на спичках. Ну и не то, чтобы качество это плохо, просто не все могут и готовы к большим счетам за использование облачных моделей. А многим на самом деле достаточно небольших моделей для узких задач, и не надо впустую столько ресурсов тратить.
Ну и не стоит забывать про ФЗ152 и GDPR, который многих тоже ограничивает от использования онлайн сервисов, из-за чего и приходится использовать локальные сервисы.
Если речь про личное пользование, то тут и нет, и не было вопросов, облачное для личного будет в 99% случаев выгоднее. Вы не сможете один фиг утилизировать ресурсы локальных моделей, поэтому окупаемость долгая будет.
Ну можно начать с того, что на прод среду неправильный конфиг доехать и не должен вовсе, как минимум, это должно быть предварительно протестировано на препрод и\или тесте. Если все правится руками на горячую - ну тогда это вообще последняя проблема ;)
Ну давайте не делать из разработчиков лог-агрегаторов идиотов, пожалуйста ;)
Все подобные агрегаторы, типа Otel, Fluent-bit, Vector, Filebeat, и т.д. проектируется с учетом вероятных проблем на стороне экспортеров и такой кейс заведомо предусматривается, поэтому делается логика ограниченного буфера на диске или в памяти, при достижении лимита, в зав-сти от продукта и настроек, происходит либо очистка старых записей в буфере, либо остановка пайплайна, давая знать вышестоящим источникам об этом ( условно, если это происходит по HTTP - то дает знать при помощи кода 429 агентам ), и вышестоящие источники уже на стороне агентов верно интерпретируют это, останавливая чтение, если это возможно. Этот механизм везде называют по разному, но мне нравится backpresure - именно так можно встретить в документации Vector и Fluent-bit, например. Ну еще вот эта страница у Vector может быть интересна.
Сам тезис про единую точку отказа разбивается только лишь об тот факт, что в реальной прод нагрузке инстансов агрегаторов все же больше одного, а то и десятки, если мы говорим про сколько-нибудь заметную нагрузку highload или приближенную к нему. Если же у вас нагрузка настолько микроскопическая, что вам достаточно одного агрегатора, то скорее всего он вам и не нужен действительно ;)
Для надежности.
Если при ресенде будет ошибка(а тг любит иногда кидать 400ку), либо инет моргнет, то как потом понять, что именно надо переотправить. Ну окей залогируем мы. А если мы пропустим ошибку и чухнемся через неделю только? ;)