Да, я понимаю вас. Телеметрия так или иначе собирается со всего сейчас, чем вы пользуетесь — от вагона метро до приложений. Мы за этичность, то есть обезличенность и отсутствие любого злонамеренного использования. Но при этом мы считаем нормальным обезличенно (и агрегированно) собирать те же ситуации, приводящие к ошибкам или задержкам, что является абсолютно общепринятой практикой. Можем ли не собирать? Да, и в беклоге сделать этот функционал отключаемым, как я уже сказал выше.
Что касается cookie и разнообразных трекеров, я еще понимаю: зло в них в том, что они отслеживают активность за пределами отдельно взятого сайта. Но что плохого сделала пользователю продуктовая аналитика на конкретном ресурсе? От того, что разработчик лучше поймет, как используется его продукт, кому это вред наносит и какой?
Вас смущает, что данные о вашем взаимодействии с продуктом собирают разработчики этого продукта?
В планах глобальный выпуск, там будет соблюдение требований по передающимся данным с возможностью выбирать, что именно о пользователе собирается. В России пока достаточно написать «мы собираем куки».
Мы рассмотрим инференс чужих моделей и продажу токенов, если это будет востребовано, но пока у нас уже заезжают крупные заказчики и всё-таки фокус на том, чтобы дать им инфраструктуру как сервис.
Мы вроде бы о том-же говорим: вместо множества середнячков — энное число профи.
Там, где два сильных специалиста могут закрыть функционал службы из десятка средних — какой же тут риск все уронить? Наоборот, каждый из таких сотрудников знает, что делать и как это делать профессионально.
На то мы и предупреждаем везде, что это бета и что-то может пойти не так. Конкретно в этом случае были потери на стороне оператора связи, не все вызовы сервиса завершались вовремя, и, как следствие, вылезала ошибка, которую Next.JS переварить не мог. Мы это сразу увидели в мониторинге и оперативно пофиксили.
Пилить фичи в прод без тестов — это слабоумие. Среды dev/test/stage/prod — это база. Конечно, мы тестим всё дважды, в т. ч. на стейдже непосредственно перед выкаткой. И вайбкодинг тут ни при чём.
Ваш посыл ясен, сами задрали планку так высоко. Обещали качественный сервис — предоставляйте. В целом, пока с этим все норм. Клиентские ресурсы ситуация не затронула.
Боже упаси! Для создания ВМ надо указать SSH-ключ, иначе это будет чемодан не просто без ручки, но и без защелок — ни достать, ни положить. Профиль сейчас пилим, а для связи почта и TG.
Про то, что ИБ — это расходные статьи, не генерирующие доход, я с вами абсолютно согласен. И про удельные расходы тоже. О том и статья, что расходы эти неподъемны для МСБ. А вот про потребность уже не соглашусь. Дело в том, что «не понимаю, что мне это нужно» = «на самом деле не нужно». И то, что у малого бизнеса денег меньше не делает потребность меньше, и точно не снижает риски.
Прям сразу что приходит в голову — компания ESET с их антивирусом NOD32, решения Fortinet. А еще Veeam, который вообще изначально был российским. Сюда же добавим ситуацию с CloudFlare. Примеров масса, на самом деле. А вот доступных альтернатив — увы.
Спасибо, исправил.
Да, я понимаю вас. Телеметрия так или иначе собирается со всего сейчас, чем вы пользуетесь — от вагона метро до приложений. Мы за этичность, то есть обезличенность и отсутствие любого злонамеренного использования. Но при этом мы считаем нормальным обезличенно (и агрегированно) собирать те же ситуации, приводящие к ошибкам или задержкам, что является абсолютно общепринятой практикой. Можем ли не собирать? Да, и в беклоге сделать этот функционал отключаемым, как я уже сказал выше.
Раздел Pricing на сайте Matomo ответит на этот вопрос: всё кроме базовых фич стоит денег. Например, Session recording — от 219 € в год.
Что касается cookie и разнообразных трекеров, я еще понимаю: зло в них в том, что они отслеживают активность за пределами отдельно взятого сайта. Но что плохого сделала пользователю продуктовая аналитика на конкретном ресурсе? От того, что разработчик лучше поймет, как используется его продукт, кому это вред наносит и какой?
Вас смущает, что данные о вашем взаимодействии с продуктом собирают разработчики этого продукта?
В планах глобальный выпуск, там будет соблюдение требований по передающимся данным с возможностью выбирать, что именно о пользователе собирается. В России пока достаточно написать «мы собираем куки».
Мы рассмотрим инференс чужих моделей и продажу токенов, если это будет востребовано, но пока у нас уже заезжают крупные заказчики и всё-таки фокус на том, чтобы дать им инфраструктуру как сервис.
А как вы предлагаете, плодить штат только чтобы распределить знания? Это ж не контейнеры, вроде.
Мы сейчас работаем над двумя сервисами с GPU: VDI и ML-платформа.
Это три автономные эксплуатационные службы, которые обычно разделены. Они существуют у провайдеров помимо техподдержки.
Я ранее рассказывал, почему удаленка — это не наш формат. Да и экономия на офисе мизерная.
Мы вроде бы о том-же говорим: вместо множества середнячков — энное число профи.
Там, где два сильных специалиста могут закрыть функционал службы из десятка средних — какой же тут риск все уронить? Наоборот, каждый из таких сотрудников знает, что делать и как это делать профессионально.
Таковы реалии рынка. Плюс хочется сделать облако так, как надо. А после того, как мы этого добьёмся, думаем, уровень входа в сферу будет ещё выше.
На то мы и предупреждаем везде, что это бета и что-то может пойти не так. Конкретно в этом случае были потери на стороне оператора связи, не все вызовы сервиса завершались вовремя, и, как следствие, вылезала ошибка, которую Next.JS переварить не мог. Мы это сразу увидели в мониторинге и оперативно пофиксили.
Пилить фичи в прод без тестов — это слабоумие. Среды dev/test/stage/prod — это база. Конечно, мы тестим всё дважды, в т. ч. на стейдже непосредственно перед выкаткой. И вайбкодинг тут ни при чём.
Ваш посыл ясен, сами задрали планку так высоко. Обещали качественный сервис — предоставляйте. В целом, пока с этим все норм. Клиентские ресурсы ситуация не затронула.
Возможен конфликт ssh.socket и ssh.service
Посмотреть их статусы: systemctl is-active ssh.service ssh.socket
Самое простое решение (ubuntu):
Отключить ssh.socket сервис — sudo systemctl disable --now ssh.socket
Установить Port для ssh.service — sudo nano /etc/ssh/sshd_config
Перезапустить ssh.service — sudo systemctl restart ssh.service
Новый порт должен быть в логе сервиса — sudo systemctl status ssh.service
Но вы уже знаете что это решение работает, потому что в нашей группе мы с вами решили этот вопрос.
Да, логично, сейчас подсветим.
Мы так не делаем, потому что это не так секьюрно. Как минимум, провайдер знает ваш пароль.
Боже упаси! Для создания ВМ надо указать SSH-ключ, иначе это будет чемодан не просто без ручки, но и без защелок — ни достать, ни положить. Профиль сейчас пилим, а для связи почта и TG.
Так мы об этом и пишем же, всё верно.
Про то, что ИБ — это расходные статьи, не генерирующие доход, я с вами абсолютно согласен. И про удельные расходы тоже. О том и статья, что расходы эти неподъемны для МСБ. А вот про потребность уже не соглашусь. Дело в том, что «не понимаю, что мне это нужно» = «на самом деле не нужно». И то, что у малого бизнеса денег меньше не делает потребность меньше, и точно не снижает риски.
Прям сразу что приходит в голову — компания ESET с их антивирусом NOD32, решения Fortinet. А еще Veeam, который вообще изначально был российским. Сюда же добавим ситуацию с CloudFlare. Примеров масса, на самом деле. А вот доступных альтернатив — увы.