vinoff

175 (SMI Program fail count in worst die) - какое-то гигантское число, более 600 триллионов))

Используемая вами программа некорректно интерпретирует SMART.

Для SSD Intel атрибут 175 (AF / AFh) - это Power Loss Protection Failure.
Интерпретируется он вот так:
• Last test result as microseconds to discharge cap, saturates at max value. Also logs minutes since last test and lifetime number of tests.
— Raw value:
Bytes 0-1: Last test result as microseconds to discharge cap, saturates at max value. Test result expected in range 25 <= result <= 5000000, lower indicates specific error code.
Bytes 2-3: Minutes since last test, saturates at max value.
Bytes 4-5: Lifetime number of tests, not incremented on power cycle, saturates at max value.
— Normalized value:
Set to 1 on test failure or 11 if the capacitor has been tested in an excessive temperature condition, otherwise 100.

debconf: Fatal IO error 11 (Resourse temporarly unavailable) on X server :0

Ошибка вообще похожа на какие-то проблемы с выводом на дисплей или графикой, возможно, Wayland. Но я не очень силён в этих моментах.

что теперь с ним делать: на помойку или как-то можно исправить

Можете подключить этот ССД другим SATA-кабелем к другой машине с Windows?

Вы ставите ОС, как я понимаю, важных данных на диске нет. Хорошо бы сделать сначала полный тест записи (уничтожит всю информацию), затем полный тест чтения (именно Read).
Это можно сделать в нашей программе для тестов (бесплатная, без установки), либо другой "не попсовой", которой вы доверяете.
В R.tester'e графики можно сделать максимально детальными, это даст хорошее представление о состоянии памяти.

Также можете показать S.M.A.R.T. целиком, если сомневаетесь в ещё каких-либо параметрах. Р.тестер это тоже умеет, к тому же мне было бы интересно посмотреть на его output для семейства DC S3500.

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

Именно так.
ССД выглядит весьма стОящим, особенно на фоне китайщины и массовых моделей на дешёвой памяти. Да и Интел, как-никак.
DC S3700 был бы ещё лучше, из-за более высокого ресурса (DWPD / TBW), но и этот очень даже неплох.

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

bash скрипт с набором нужных команд. Либо Ансибл - если надо массово устанавливать(хотя можно и parallel-ssh использовать)

Vless элементарно упаковывается в докер. Нужный файл json монтируется в файле docker-compose yml

Итого...
ставим нужный софт - докер,компос, fail2ban итд по желанию
копируем файлы для докер компос
стартуем docker-compose up -d -f my.yml

всё...

краткий пример yml -

version: '3'
services:
  xray-turk:
    image: teddysun/xray:latest
    volumes:
      - /opt/xray-turk/config.json:/etc/xray/config.json
      - /opt/xray-turk/geosite.dat:/usr/local/share/xray/geosite.dat
    ports:
      - "443:443"
    restart: unless-stopped

краткий bash для установки софта (который лично мне нужен) (да я знаю что там старый докер, но меня устраивает) -

#!/bin/bash

# Обновление пакетов
sudo apt-get update -qq && sudo apt-get install jq fail2ban mc htop vnstat wget git curl rsync apt-transport-https ca-certificates software-properties-common -qq -y;

# Добавление ключа репозитория Docker
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

# Получение кодового имени текущей версии Ubuntu
codename=$(lsb_release -cs)

# Добавление репозитория Docker
sudo add-apt-repository -y "deb [arch=amd64] https://download.docker.com/linux/ubuntu $codename stable";

# Обновление пакетов после добавления репозитория
sudo apt-get update;

# Установка Docker
sudo apt-get install docker-ce -qq -y;

# Установка Docker Compose
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# Добавление прав на выполнение для Docker Compose
sudo chmod +x /usr/local/bin/docker-compose

Желание комерческой поддержки - милости просим в ТГ )

Для 443 (https) - реверс-прокси. Порт пробрасывается на него, а он уже перенаправляет запросы к серверам по имени в запросе.
Для 25 (smtp) - всё принимается одним сервером и пересылается дальше по правилам маршрутизации почты.

Как настроить нагрузоспособность Nginx из расчета процессоров для стабильной работы?

Т.к. четкого ТЗ не указано, то выдумаю свой конфиг, с 4 ядрами и 8 гигами оперативы, тогда следующие действия:

Передадим параметры железа nginx-у, nginx.conf:

worker_processes  4; # cores
events {
    worker_connections  1024; # 1024 * 4 ram = 4096 (max all rps)
}

Настроим ограничения так, чтобы каждый ip мог делать не более 10 rpm (в минуту), nginx.conf:

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/m;

    server {
        location / {
            limit_req zone=mylimit burst=20 nodelay; # we put no more than 20 requests in the queue over the limit (anti DDoS)
        }
    }
}

Эти настройки помогут контролировать общую нагрузку на сервер и предотвратят его перегрузку за счет ограничения количества обрабатываемых запросов как в целом (через worker_connections), так и на уровне отдельных IP-адресов (через limit_req_zone и limit_req). Это эффективный способ защиты от спама и DDoS, а также обеспечивает равномерное распределение ресурсов сервера между всеми пользователями.

Многие провайдеры при истощении баланса перенаправляют все клиентские http-запросы на свою страничку с уведомлением о необходимости оплаты и каким-нибудь эквайрингом. Очевидно, что для их работы нужен работающий DNS, а зачастую ещё и доступ к CDN. Провайдеры поумнее оставляют доступ к своему DNS и запросы к CDN тоже через себя проксируют, но некоторые не заморачиваются и просто оставляют часть доступа в дикий интернет.

У меня так настроено в ~/.bashrc:

# History search with Up/Down keys.
if [[ $- == *i* ]]; then
    bind '"\eOA": history-search-backward'
    bind '"\e[A": history-search-backward'
    bind '"\eOB": history-search-forward'
    bind '"\e[B": history-search-forward'
fi

Насколько я понимаю раньше шеллы использовались в качестве примитивных высокоуровневых языков. Сейчас у нас есть Perl, Python, nodejs, php...

Ну давайте вместо рабочего стола пользователю дадим сразу Visual Studio, ведь какая разница как программу запускать - иконкой на рабочем столе, или форкать из высокоуровневого языка?

shell - это оболочка операционной системы. То, что кроме графической есть еще и command line interface - это совершенно нормально и адекватно. И шелл позволяет пользователю и администратору работать в операционной системе гораздо удобнее, чем через язык программирования.

То, что sh/bash и другие, настолько развиты что сами по себе являются неплохими языками программирования - это просто следствие того, что командый интерфейс и создавался тогда, когда каждый пользователь был немного программистом, и следствие того, что cmd line удобен для автоматизации просто по своей архитектуре.
Поэтому Powershell, bash/zsh/ksh будут продолжать развиваться.

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

Использование таймеров systemd вместо заданий cron

ещё не называли? кажется нет...
unbound.