Самохостинг это хорошо, однако они спасут только от L7 атак, когда корявый (других не бывает) PHP код по 20 SQL запросов шлёт в ответ на запрос от юзера

И то не факт, в случае если сайт изначально полумёртвый под нагрузкой из 10 юзеров, однако тут даже cloudflare мало поможет

А от L4, от которого защита тебе потребуется сильнее, самохостинг тебя не спасёт, и надо уже иметь сеть которая способна удар принять и трафик отфильтровать до твоей машины

Однако с этим способны справляться уже все облака, и можно спрятать дедики за реверс-прокси на облаках потенциально того же самого провайдера

и что такого волшебного в твоем настоящем ойпи?

Просто первым ляжет твой наколеночный балансировщик.

Покупайте защщиты от клаудшмары, с вашими талантами самое оно.

ЦБ РФ смотрит на тебя... прищурившись.

> Гугла могли зарабатывать, но сейчас остался только его местный конкурент, который
> как говорят платит копейки и сайты держать не выгодно. А платить

сайты без прона и ставочек  - держать уже лет десять невыгодно, если не больше.

Большинство из нас, не поверишь, занимается сайтами не ради заработков на помойной рекламе.

...запороли бы данные, получили бы неконсистентное состояние, выполнили бы случайный код...

А может все было бы хорошо. Но для того чтобы это узнать, нужно чтобы код был написан на сишке. Вот когда на си перепишут, тогда и поговорим.

"вместо корректной обработки"
"использованием в коде на языке Rust метода unwrap() с типом Result."
"Обычно unwrap() применяется в процессе отладки"

Попробуйте связать это. Программисты rust "схалтурили" вместо обработки ошибки. В Си такие перекладывания на отладочную функцию не проходит. Почему Вы оскорбляете незнакомых Вам людей, тем что они не смогли бы грамотно обработать ошибку?

"Проблема оказалась в том, что вместо корректной обработки превышения лимита и продолжения использования прошлой версии файла с информированием системы мониторинга о внештатной ситуации, в обработчике срабатывало аварийное завершение, которое блокировало дальнейший проброс трафика. Ошибка была вызвана использованием в коде на языке Rust метода unwrap() с типом Result."

Не добавят. В некоторых случаях использование unwrap() вполне валидное поведение. В этом репозитории должен был быть включен линтер, который бы фейлился, если бы использовалась эта функция (а также например panic и другие).

Это получается, плотность ошибок на расте увеличилась? Что не так с программистами на расте?

а завтра пишем на аде - не принимает.

Поэтому, увы, говорит. Видишь раст - вероятнее всего начальники - это вот самое. А с ada еще могут быть варианты.

Хотя нет ровно никаких признаков что следующего точно такого же не будет.

Тяжко тебе наверное работать! Ты ж по личному опыту пишешь?
Хорошо что я не работаю с такими отбросами)

> А тут пол-тырнета завязано на этих тупых облаках и на те - на 3 часа ты просто в ауте и миллионные убытки!

Где-то сэкономил (на своих серваках), где-то потерял.
Для многих даже 3 часа в год это приемлемо.

> А ещё кричали "бегите к нам в облака, у нас 200% устойчивость, кластеры, виртуальные машины!".

Да.  
Когда был подобный факап до вчера?

смотрели не туда.
"we initially wrongly suspected the symptoms we were seeing were caused by a hyper-scale DDoS attack"

Да и 3 часа это на всё. Ты не можешь вот так просто откатить что-то, потому что на это нужно время.

В 11:05 они залили бажный конфиг. В 13:37 они уже ролбечили его.

> unwrap никуда не логируется и в панике никакого сообщения

Вообще-то логируется. Они даже в бложике строку скинули:
"thread fl2_worker_thread panicked: called Result::unwrap() on an Err value"

какие-то неправильные программисты на расте

Если это было бы так, то код бы работал в проде, т.к. ассерт для дебага.

> Буквами по белому написано, что НЕ надо его использовать в production-коде. Но, как всегда, имеем вот это вот всё и виноват, конечно-же, Rust.

Если так рассуждать, то буквами по белому написаны ub, но как всегда имеем вот это вот всё и виноват, конечно-же, Си.

А какие средства язычок предлагает, чтобы unwrap (и ещё сотни паникующих методов) не использовали в production-коде? Может, хотя бы, warning при компиляции выводит?

ну конечно ж не руками. Кто вообще этих рукастых на прод пустит-то.
Пайплайн континьюус дизинтеграции тщательно отработал.

Мы тебе поверим на слово, да, конечно. Или нет?

https://clickhouse.com/docs/about-us/history

Типично: Затраты общие - прибыль частная.

могу поспорить, что клиентами не ожидалось 3 часа простоя из-за использования unwrap, который "не рекомендован для использования в рабочих проектах". Нужен анврап-чекер, который будет заставлять переписывать без анврапов

Если сайт упал, мгновенно должны поднять по тревоге всех сисадминов, откатиться на рабочую версию и начинать расследование. А в клаудфларе, походу, uндycятuна за доширак работает - пока проснулись, про-д-рис-тались, едва нашли проблему, а потом, спустя сутки, нашли и "виновника торжества" - unwrap. В ПРОДАКШЕН КОДЕ. :D  Всё, что вы хотели знать о квалификации cloudflare team.

и не будь клаудшмразь монополистом с договором вида "мы вам ничего и не обещали" - кто-то сейчас суматошно искал бы новую работу.

Выясняется что клиенты, кто бы мог подумать и было ли чем, хотели от них вовсе не "за пределы буфера не вышли".

Всё идёт по плану.

Когда такого будет много и в критическом проде, что делать?
Данные можно охранять, дублировать и подобное. Что делать с лежащем бизнес-сервисом?

C++: [[nodiscard]] в объявлении функции, компиляция с -Werror=unused-result

Конечно, сделать с результатом все равно можно что угодно, но всё-таки сделать что-то нужно обязательно.

Всё есть. Выше показан пример с
#![deny(
    clippy::unwrap_used,
    clippy::expect_used,
    clippy::panic
)]
где прямо запрещается использовать эти функции и макросы.
Это не было сделано по каким-то причинам.