ServerAdmin.ru | Linux | DevOps

Ваш дата-центр вышел из строя. Где теперь запускать 1С?

Серверы недоступны, сотрудники не могут подключиться к 1С, заказы не обрабатываются, отгрузки останавливаются. Резервные копии есть. Но даже если данные удалось сохранить, остаётся главный вопрос: на какой инфраструктуре продолжить работу, пока основной ЦОД недоступен? Разворачивать новые серверы во время аварии, искать ресурсы и восстанавливать подключения долго. А бизнесу нужно работать.

☁️ БИТ.CLOUD предлагает геораспределённую IT-инфраструктуру с резервным ЦОД.
Это решение, при котором резервная площадка заранее подготавливается в другом дата-центре. Если основной ЦОД становится недоступен, компания может перейти на резервную инфраструктуру по подготовленному сценарию и восстановить доступ к 1С, ERP, CRM и другим критичным системам.

Что входит в решение:
✓ Резервная площадка в другом ЦОД. Критичные системы не зависят только от одного дата-центра.
✓ Подготовленный сценарий переключения. Порядок перехода на резервную инфраструктуру определяется заранее, а не в момент аварии.
✓ Архитектура под ваши системы. При проектировании учитываются серверы, базы данных, приложения и необходимые интеграции.
✓ Проверка сценария восстановления. Можно заранее протестировать переход на резервную площадку и выявить возможные проблемы.

Главное преимущество: резервную инфраструктуру не придётся создавать с нуля во время аварии. Она будет подготовлена заранее, а порядок восстановления будет известен ИТ-команде.

Один ЦОД не должен быть единственной точкой отказа для всего бизнеса. БИТ.CLOUD поможет подобрать схему геораспределённого размещения и рассчитать стоимость резервной инфраструктуры под ваши задачи.

👉 Узнайте, как подготовить резервный ЦОД для вашей 1С и других бизнес-систем

В программировании есть (или теперь про программирование стоит говорить было?) такое понятие, как парное программирование. Причём это не образное выражение, а вполне конкретная деятельность. Про парное администрирование никогда не слышал, но если вдруг надумаете такое устроить, то могу предложить инструмент - TermPair.

Это старая утилита, которую я тестировал ещё в 2021 году. С тех пор её не забросили, периодически обновляют и работает она неплохо. Я лично проверил. Мне понравилось. С помощью TermPair можно настроить совместный доступ к консоли сервера через браузер. Это может быть режим только для просмотра, либо и для равнозначного управления для всех участников.

Отмечу особенности TermPair:

▪️Все передаваемые данные шифруются
▪️Можно поднять свой сервер и все соединения пропускать через него
▪️TermPair состоит из одного бинарника, никаких зависимостей
▪️Очень простая настройка и использование
▪️Утилита кроссплатформенная - Linux, macOS, Windows

Мне видится польза от этого сервиса как минимум в трёх ситуациях, которые пришли в голову:

1️⃣ Сейчас популярны удалённые собеседования при приёме на работу, в том числе и технические части. Можно быстро и легко отправить кандидату консоль от сервера с какими-то задачами, которые ему нужно выполнить. Там можно совместно в режиме беседы взаимодействовать. Мне видится это самым простым и эффективным способом оценить квалификацию человека. Говорить можно много, а вот взять и что-то сделать - совсем другое дело. Можно специально что-то поломать и попросить починить.

2️⃣ Можно наблюдать за работой ии-агента или нескольких через браузер. Можно поделиться с кем-то сессией, чтобы он тоже взаимодействовал.

3️⃣ Если вы проводите обучение, то это удобный способ подключиться к ученику и совместно что-то сделать.

Есть публичный сервис для использования, но у нас он работает только через VPN, поэтому я не делаю на этом акцент. Сразу покажу, как можно поднять и использовать свой сервер. Там всё очень просто.

Скачиваем и распаковываем бинарник:





# wget https://github.com/cs01/termpair/releases/download/v1.2.0/termpair-x86_64-unknown-linux-gnu.tar.gz
# tar xvf termpair-x86_64-unknown-linux-gnu.tar
# mv termpair /usr/local/bin/

Это нужно сделать и на клиентах, и на сервере, который будет обслуживать соединения. Далее на сервере устанавливаем Nginx и Certbot:





# apt install nginx certbot

Получаем сертификат для домена:





# certbot certonly

Рисуем конфигурацию для TermPair:





upstream termpair_app {
 server localhost:8000;
}

server {
  server_name 345265.simplecloud.ru;
  listen 443 ssl;
  ssl_certificate /etc/letsencrypt/live/345265.simplecloud.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/345265.simplecloud.ru/privkey.pem;

  location /termpair/ {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_pass http://termpair_app/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Создаём systemd unit для службы TermPair в файле /etc/systemd/system/termpair.service:





[Unit]
Description=TermPair server
After=network.target

[Service]
ExecStart=/usr/local/bin/termpair serve --port 8000
Restart=on-failure
RestartSec=1s

[Install]
WantedBy=multi-user.target

Запускаем службу:





# systemctl daemon-reload
# systemctl enable --now termpair.service

Теперь на сервере, где мы хотим расшарить консоль, запускаем TermPair и указываем через ключ наш сервер:





# termpair share --host "https://345265.simplecloud.ru/termpair/" --port 443

В консоли получаем ссылку для подключения и переходим по ней браузером. Дальше используем по назначению. Доступ будет у всех, кто знает ссылку. Ограничить доступ только чтением можно ключом -r. Через ключ --cmd можно сразу запустить какую-то программу, например, opencode.

#linux

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

Проксирую запросы к сервису через Nginx. Сам сервис работает локально, ничего особенного. Пример конфигурации беру из репозитория, то есть не сам пишу. На вид там всё стандартно, поменял только пути к сертификатам.





upstream app {
 server 127.0.0.1:8000;
}
.....
  location /app/ {
.....
    proxy_pass http://app/;
.....
  }

Сервис с дефолтными настройками запускается на http://localhost:8000. Пробую напрямую, всё работает. Через Nginx - никак, 502 ошибка, в логах стандартно - (111: Connection refused) while connecting to upstream. Думаю, что за ерунда. Напрямую же отвечает, почему через Nginx - нет. Ещё и приложение никаких своих логов не даёт, не понятно, что не так.

Разобрался чисто интуитивно. Вспомнил, что 127.0.0.1 и localhost - это не одно и то же. Первый - адрес ipv4, а localhost на современных дистрибутивах резолвится в ipv6 (::1).

Попадались на таком нюансе? Я уже не первый раз. Кстати, не понимаю, для чего localhost перевели на ipv6. В чём смысл? Даже не то, что перевели. В /etc/hosts оставили оба адреса, и ipv4, и ipv6, но по современным RFC адреса v6 имеют приоритет над v4. Поэтому теперь localhost по умолчанию отвечает с адреса ::1, а не 127.0.0.1. Это можно вручную изменить, убрав запись с ::1 из /etc/hosts. Я одно время это делал, потом перестал. Нет смысла бороться с ветряными мельницами. Надо привыкать.

#linux #ошибка

Сегодня у нас очередная пятница, так что можно поговорить на отвлечённые темы. Затрону одну из любимых ваших тематик - обсуждение мониторов 😁. Они неизменно вызывают повышенную активность - просмотры, обсуждения, критику. Я и сам люблю поглазеть на чужие рабочие места, подсмотреть там что-то интересное.

У меня рабочее место получилось не похоже на всё то, что я где-либо видел. Я сейчас закончил преобразования и остановился на том варианте, что получился. Меня он устраивает, поэтому можно поделиться. Для наглядности записал небольшое видео (смотреть внизу).

Пару лет назад я купил себе монитор 🖥 27'' AOC Q27G2S/EU 2К с частотой 165 Гц. Уже имея приличный опыт работы за ним могу сказать, что как по мне - это оптимальный вариант монитора для типовой работы в браузере и терминале. Я имею ввиду диагональ и разрешение. Всё умещается, всё влезает на масштабе 125%, глаза не устают.

В какой-то момент стало не хватать одного монитора для некоторых задач. Стал подумывать купить второй такой же. Это было бы удобно. Но в продаже уже не нашёл. Подумал немного и решил купить 4К монитор, раз уж одинаковые всё равно не получалось сделать. Место у меня позволяет, поэтому задумал увеличить ещё и диагональ. В итоге взял 🖥 4К 31.5" AOC U32G4U с частотой 160 Гц.

Раньше не придавал внимания частоте, не считал её значимой характеристикой, так как в активные игры, типа шутеров, не играю. Но после того, как поработал на 165 Гц, меньше уже не хотелось. Разница хоть и явно не заметна, но ощущается. С разрешением 4К и диагональю 31.5" это был самый дешёвый монитор с такой частотой, поэтому его и взял. Ну и в целом он мне нравится, похож на предыдущий.

Какого-то ВАУ эффекта или большого удобства от 4К монитора я не увидел. Больше всего понравилось то, что теперь по высоте места хватает и можно убрать панель инструментов Windows вниз, а вкладки браузера - вверх. Последнее время у меня панель была справа, а вкладки слева. Размера экрана теперь достаточно, чтобы расположить рабочие окна по центру, отступив и сверху, и снизу.

С масштабом в 150% против 125% в 2К места на мониторе стало не намного больше. Картинка плюс-минус такая же. Я не могу сказать, что прям шрифты какие-то более гладкие или что-то ещё, что я часто слышал от тех, кто советует брать 4К. У меня оба монитора теперь перед глазами, я могу сравнить. Да, 4К чуть лучше, но он и дороже. Если бюджет ограничен и надо два монитора, я бы лучше купил 2 хороших 2К монитора, нежели 2 похуже, но 4К.

Получилось в итоге не идеально, потому что мониторы сильно разные, и по диагонали, и по разрешению. Но меня устраивает. Второй монитор использую эпизодически, так что мне не критично. Чаще всего там ничего нет, либо висит список задач на день в Singularity.

Из того, что ещё хотелось бы добавить - заменить стоящий рядом обычный стол на стол с подъёмным механизмом. Для разминки и разгрузки уставших от сидения мышц хотел бы иногда что-то делать стоя, смотря в окно. Оно как раз у меня напротив. От сидения весь день в своей рабочей станции у меня устаёт попа. Раньше на обычных креслах спина или шея уставали, а сейчас мягкое место. Стараюсь 5-7 км в день для разминки ходить.

#железо

Небольшая рекомендация по теме Zabbix. У них есть партнёр - initMAX. Это довольно популярная компания в своей области. Они много всего сделали полезного для Zabbix. Регулярно выступают на Zabbix Summit, пишут инструкции и различные дополнения для Zabbix. Расскажу о наиболее полезных вещах, про которые знаю.

1️⃣ Репозиторий с шаблонами. Тут много хороших шаблонов. Несмотря на то, что шаблонов для Zabbix в целом немало, но все они разного качества. У initMAX они обычно неплохие. Например, я пользуюсь их шаблоном для Synology.

2️⃣ Zabbix MCP Server и Zabbix AI Skills. Качественная обвязка для работы с Zabbix с помощью LLM. Команда Zabbix обещала свой MCP сервер выпустить вместе с релизом 8.0, но я пока ещё не видел информации о нём. Этот MCP сервер наиболее качественный и популярный, особенно в связке со скилами. Всё никак руки не доходят поплотнее поработать с этим. Не придумаю задачу, которую было бы удобно решать с ИИ. Я Zabbix неплохо знаю и обычно довольно быстро там что-то меняю или нахожу. А для деплоя и без MCP всё пишется агентами. Не представляю, где меня ИИ в этих задачах может ускорить. Основная проблема - спам уведомлений из-за некачественных или неоткалиброванных шаблонов. В своих шаблонах я и так знаю, где и что надо подкрутить.

Если используете в работе с Zabbix ИИ и MCP, расскажите, какие задачи с ними решаете.

3️⃣ Каталог расширений. Это набор как платных, так и бесплатных модулей для Zabbix, которые меняют или дополняют основную функциональность. Покажу на конкретном примере.

Я изначально не думал, что кого-то, кроме меня, раздражают всплывающие заголовки виджетов во время наведения на них мышки. То есть ты отключаешь отображения заголовка и его нет, высвобождается лишнее место на дашборде, которого часто не хватает. Но если ты наведёшь мышку, то заголовок начинает всплывать. Когда виджетов много, постоянно всплывают эти заголовки во время перемещения мыши по дашборду. Меня это всегда раздражало. И судя по всему, не только меня.

У initMAX есть бесплатный модуль, который это исправляет. Ставится так:





# wget https://repo.initmax.com/zabbix/release/initmax-release-latest_all.deb
# dpkg -i initmax-release-latest_all.deb
# apt update && apt install zabbix-module-hidewidgetheader

То есть удобно сделано, через пакеты, поддерживается и обновляется. Теперь, если ты отключил заголовки, они при наведении будут всплывать только в режиме редактирования, но не просмотра. Мне это очень нравится 😁 У них много разных модулей, можете сами посмотреть, что там вам покажется полезным.

Ещё у них инструкции неплохие были, но сейчас не уверен, что они ещё актуальны. С приходом ИИ большого смысла в них нет. Он их уже и так изучил и может изложить с подробностями.

#zabbix

Один мой знакомый, читатель и автор своего небольшого канала поделился любопытной практической информацией на тему использования ZFS в PVE. Я о ней не знал и не сталкивался с описанной проблемой, хотя ситуация не такая уж и редкая, а информация важная!

Смысл в том, что все виртуальные блочные устройства ZFS на одной физической машине объединяются в общий пул потоков ZVOL. И если у вас 2 пула - один на быстрых NVME, а второй - на медленных HDD, запросы к ним будут сливаться в общий поток. При нагрузке на пул с HDD и выстраивании очереди запросов к нему, в эту же очередь встают и запросы на пулы с остальными дисками. В итоге, сильно нагрузив ZVOL на одном медленном пуле, вы получаете задержки с ZVOL на других, более быстрых пулах.

На практике это выглядит так. Ночью вы запускаете бэкап большой ВМ, виртуальный диск которой находится в ZVOL на медленном HDD-пуле. При интенсивном чтении этого диска рабочие потоки ZVOL могут оказаться заняты, из-за чего увеличиваются задержки запросов к виртуальным дискам на NVMe, хотя сами NVMe практически не загружены.

Я лично похожую схему использования дисков применяю повсеместно. Если сервера общего назначения, то так и делаю - быстрые диски под нагрузки, а большие медленные - под локальные бэкапы, чтобы можно было оперативно восстановиться в случае чего, не вытягивая тяжёлые бэкапы по сети, либо под локальное хранение статики.

Другое дело, что я в таких схемах не использую ZFS. Под рабочей нагрузкой мне не нужны возможности ZFS, как и для локальных бэкапов. Поэтому лично я с такой проблемой не сталкивался. ZFS обычно ставлю на бэкап серверы с кучей дисков. Там я вижу использование этой ФС оправданной и полезной. В остальных случаях, если не нужны снэпшоты именно в реализации ZFS, не вижу смысла её использовать.

Автор решил проблему в лоб самым простым и очевидным способом - вынес NVME диски на LVM-thin, отделив их от общего пула потоков ZFS. Это сразу решило проблему узкого горлышка.

Я немного поспрашивал ИИ на эту тему. Он подтвердил, что это архитектурная особенность ZFS, которую он увидел в исходниках. Там же есть и комментарии разработчиков на этот счёт:

We can have up to zvol_threads concurrent i/o's being processed for all zvols on the system. This is typically a vast improvement over the zvol_request_sync=1 behavior of one i/o at a time per zvol. However, an even better design would be for zvol_request() to initiate the zio directly, and then be notified by the zio_done callback, which would call END_IO().

Каким-то образом обыграть эту ситуацию можно, меняя параметры:
zvol_request_sync = 0 или 1
◽️ 0 - асинхронная обработка через общий пул потоков ZVOL.
◽️ 1 - обработка непосредственно в контексте вызывающего потока, без передачи в общий пул ZVOL.

Казалось бы, второй вариант решает проблему конкуренции между пулами. Но разработчики предупреждают, что такая схема может существенно ухудшить параллелизм и производительность i/o. Поэтому использовать её без тестирования не стоит.

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

Ещё вариант - изменить механизм очереди - zvol_use_blk_mq = 1. Но тут надо тестировать на практике, потому что потоки будут по-прежнему в одном общем пуле, изменится распределение. Не факт, что при нагрузке на медленный пул, запросы к быстрому не будут вставать в очередь.

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

В общем, как я всегда говорил и говорю, ZFS - нишевая файловая система под конкретные задачи и потребности. У неё много возможностей, нюансов и настроек. Ставить её по умолчанию, как ФС общего назначения, не стоит. Преимущества вам могут оказаться не нужны, а все особенности и недостатки вы по умолчанию потянете за собой.

#pve #zfs

Рассказываю про небольшой трюк, который я лично на днях проделал для решения небольшой задачи. Есть одиночная VPS на Debian 12. Задача - обновить её до 13-й версии и попутно обновить версию PHP. Задача довольно простая, но всё равно потенциально опасная. Наживую такие обновления делать не рекомендую. Там бывают проблемы с зависимостями, на разрешение которых уходит некоторое время. Я сталкивался не раз.

Расскажу, как это сделать по-нормальному, а потом, как это сделал я. Настраивается новая система и делается миграция. Попутно приводится в порядок инфраструктура, документация, настройки, в идеале в этот момент пишется или актуализируется автоматизация, чтобы потом можно было быстро мигрировать в другое место, если твой ДЦ сгорит.

Но в данном случае это одиночная арендованная VPS без какой-либо обвязки вокруг. С неё даже образ нормально не снять. Я поступил следующим образом. Создал у себя в тестовом контуре VM и добавил к ней второй диск такого же размера, как у VPS. С этой VM сделал следующее:





# ssh -T root@1.2.3.4 'dd if=/dev/sda bs=16M status=none' | dd of=/dev/sdb bs=16M iflag=fullblock status=progress conv=fsync

Прямо наживую запустил посекторное копирование удалённого диска sda на свой локальный sdb. В моём случае диск был 60 ГБ, нормально скопировался примерно за час без единого разрыва. При этом на сервере был запущен сервер MySQL.

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

У этой виртуалки отключил основной диск, а sdb, на который залил копию VPS, сделал загрузочным. После этого успешно загрузился в полной копии VPS. Система ругнулась при запуске, что у неё повреждена файловая система, что ожидаемо. Запустил fsck -y, потом перезагрузил систему. Она при загрузке запустила ещё раз проверку диска, все ошибки исправила, и я получил полностью рабочую копию своей VPS. Даже базу данных не пришлось перезаливать. СУБД запустилась в режиме innodb_force_recovery. Мне этого было достаточно, хотя какие-то таблицы и побились. Я только поменял IP адрес, поправил файрвол под реалии своего тестового контура и отладил обновление.

Выполнил всё, что мне было нужно. Там возникли проблемы. Убедился, что исправил все ошибки, записал команды и воспроизвёл на VPS.

Способ выглядит жутко колхозным и на первый взгляд нерабочим, но на деле я такое проворачивал уже не один раз. Ранее были заметки на эту тему. Он вполне рабочий, система всегда копируется нормально. Иногда только данные бьются, которые изменились в процессе копирования. Но сама система, как правило, приезжает в рабочем состоянии. Конечно, если есть доступ к образу диска, а тем более, к снепшотам, проще копировать его. Причём это можно сделать так же наживую. Тоже побьётся файловая система, но в целом систему можно будет починить и запустить.

Основное преимущество этого способа - не надо останавливать исходную машину вообще. И не надо ставить дополнительное ПО. К примеру, сюда можно было бы установить Veeam Agent for Linux и снять образ с его помощью. Но для разовых задач не хочется ничего лишнего устанавливать. Задача решена и без этого.

#linux

Вот мы и вступили в новую реальность, когда стали пропадать датацентры целиком, что повлекло за собой длительную остановку различных сервисов. Например, я сегодня не смог отправить документы по ЭДО от 1С. Сервис лежит второй день и обещает подняться при хороших раскладах 14-го октября, а при плохих - 16-го. Вот обновляемая новость на эту тему.

Хотя по большому счёту, ничего особенного, чего бы не случалось раньше, не произошло. Уже горели целиком датацентры ранее, и не по одному, а парой, с потерей всей инфраструктуры и бэкапов. Удивительно в наше время видеть такой сервис, как 1С ЭДО и Отчётность, работающий только в рамках облака одного провайдера без проработки механизма переключения на другого. Он мог прилечь и ранее по различным причинам. Такие длительные сроки восстановления говорят о том, что вопрос быстрого восстановления сервиса у другого провайдера не рассматривали и делают теперь всё в авральном режиме. Собственно, они сами об этом и говорят:

Специалисты ГК "Астрал" и фирмы "1С" в непрерывном круглосуточном режиме работают над восстановлением сервисов 1С-ЭДО, 1С-ЭПД, 1С-Отчетность. Ориентировочный срок возобновления штатной работы сервисов - 14.10.26. Но поскольку могут быть сложности при запуске сервисов на инфраструктуре новых дата-центров, возможен перенос срока на 16.10.26.

Получился хороший стресс тест для всех - пользователей, инженеров, владельцев бизнеса. Например, некоторое время не работала Яндекс.Почта ещё после отключения первого ДЦ. Я как раз в тот момент ждал код подтверждения на почту, чтобы войти в один сервис. Уже тогда задумался, что сильно завишу от почтового ящика, на который очень много завязано. И вот сейчас он уже второй день работает кое-как. Для меня это стало уязвимым местом. Кто-то в Яндекс.Диске потерял свои файлы, думаю, что часть безвозвратно.

В общем, пришло время всем пересмотреть свои подходы к построению инфраструктуры и использованию облачных сервисов. Теперь точно нельзя просто взять и перенести всё в облако. Их, как минимум, должно быть 2 в разных компаниях и регионах, а бэкапы где-то у себя в загашнике. Ну а если удары по ДЦ продолжатся, то безальтернативным вариантом будет возврат к своим стойкам и серверам где-то в офисе или на складе. Лишь бы было где и на что сервера для них купить по текущим ценам. Ну и естественно, всё это приведёт к удорожанию инфраструктуры и всего, что на неё завязано.

❓ Вы как-то пострадали от повреждения двух ДЦ Яндекса? Я не могу воспользоваться 1С ЭДО, подписать документы и получить по ним оплату. Прилёг портал my.kaspersky.com, где я управляю компами детей. Не могу им экранное время изменить с каникул на учебные дни. Ну и с почтой небольшие проблемы. Вроде всё. По работе никто не пострадал. У моих клиентов нет денег на ресурсы Яндекс.Облака. Используем либо своё железо, либо арендные дедики и colocation. Бэкапы с инфры провайдеров забираю во вне.

p.s. реклама выше в тему оказалась, хотя изначально не задумывалась так, тема давно обозначена была

#печаль #грусть

💻Практический вебинар «СТРАТЕГИЯ РЕЗЕРВНОГО КОПИРОВАНИЯ»

📹 15 октября в 11:00 Мск за 90 минут на практике построим реальную стратегию и разберём:

🔹 как определить RPO и RTO для критичных сервисов;
🔹 как защитить бэкапы от шифровальщика;
🔹 как учесть зависимости систем и ресурсы для восстановления;
🔹 как каналы связи влияют на скорость бэкапа и восстановления;
🔹 когда достаточно обычных бэкапов, а когда нужны репликация, Hardened Repository и DRaaS;
🔹 как подготовить план аварийного восстановления и протестировать его.

🧑‍💻 Каждый участник выберет свой критичный сервис и проработает его

🎁 Всем прошедшим практикум передадим методику и пакет документов для реализации стратегии резервного копирования и восстановления:
— Матрица систем и зависимостей
— Таблица определения и согласования RPO / RTO
— Технический runbook аварийного восстановления
— Отчёт о тестовом восстановлении ИТ-сервиса
— Карта готовности одного критичного сервиса к восстановлению
— Рабочая тетрадь «Стратегия восстановления данных и ИТ-сервисов»

👉 Приходите, будет полезно. Регистрация тут

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее
время (обычно беру период в 2 недели), что мне понравились.

⇨ Как я прошёл путь от эникея до Lead DevOps | Моя карьера в IT
Личная история карьеры конкретного человека. Такая первичка, мне кажется, всегда интересна. Но мало кто готов её выкладывать. Так что автору однозначно плюс за то, что сделал это.

🔥 TrueNAS решила одну из главных проблем с хранилищами в Proxmox
Авторы ОС для хранилища TrueNAS выпустили плагин для интеграции с PVE. TrueNAS и так часто выбирают для отказоустойчивых хранилищ в том числе под диски виртуальных машин. А с интеграцией стало ещё удобнее. Например, теперь диски VM могут напрямую размещаться в ZFS томах на TrueNAS, и их снепшоты создаются там же. Получается хорошая open source связка продуктов. В видео автор демонстрирует, как всё это вместе работает.

⇨ Домашняя сеть мечты: Wi-Fi 7 + 10Gb от UniFi — ОПРАВДАНО или НЕТ?
Быстрая локальная сеть на богатом. Админка у UniFi контроллера, конечно, топ. Мне лично дома пока 1Гбит/c хватает.

⇨ A Better Way to Run Terminal Agents!
Обзор терминального мультиплексора Herdr. Это что-то типа Tmux, с заточкой под работу с ИИ-агентами. Мне лично понравилось, буду пробовать. Думаю, сделаю заметку по нему.

⇨ TUIOS заставляет Herdr и Tmux выглядеть пережитками прошлого
Предыдущий автор хвалит Herdr, а этот его хоронит и предлагает замену - TUIOS. Похоже на рэп-баттлы прошлого 😁. Этот терминальный менеджер выглядит действительно необычно и функционально, но лично меня не впечатлил. То ли дело клавиатура автора. Ниже обзор похожей клавиатуры.

⇨ Год с эргономичной клавиатурой. Действительно ли удобно?
К сожалению, в видео в основном обзор устройств, а не опыт работы с ними. Тем не менее, я получил представление, что это такое. Навскидку, очень сильно отличается от обычной клавиатуры, придётся долго привыкать. У меня к обычным клавам претензий нет, поэтому для себя не вижу смысла.

⇨ Which Proxmox Storage Should You Use?
База по хранилищам в PVE: локальная директория, LVM и LVM-thin, ZFS, NFS, Ceph. Плюс некоторые советы автора по тому, где и что использовать. Интересно будет только тем, кто с темой не знаком. По сути - пересказ документации с комментариями.

⇨ Mimo 2.6 Flash | Лайт-модель от Xiaomi
Кому интересно, чисто для справки. У Xiaomi тоже есть своя открытая модель. Модель, как модель, ничего особенного. Из-за того, что маленькая, можно спокойно погонять на обычном домашнем компе. Автор привёл примеры, на что она способна.

⇨ Как использовать ИИ-Агенты на МАКСИМУМ | Роадмап
База по современным агентам. Автор хорошо структурирует и рассказывает. Но это чисто теория для тех, кто ещё не в теме. Остальным интересно не будет.

⇨ LiteLLM - Прокси для твоих llm! Зачем? И что он дает?
Обзор популярного в наше время софта для проксирования запросов в LLM в зависимости от условий. Что-то уходит в те или иные облачные модели, что-то в локальные и т.д. Для личного использования не особо актуально, если вы прям не кодите с утра до вечера и не выедаете все лимиты. Хотя я много видел отзывов на эту шутку в том числе и у себя на канале в комментариях. Кто-то использует LiteLLM для обхода ограничения Claude Code при использовании неподдерживаемых моделей.

⇨ БОЛЕЕ 2 МЛРД токенов в день: МОЩНЕЙШАЯ станция NVIDIA DGX от Gigabyte
Обзор рабочей станции за 15 млн. рублей😳, которая выглядит почти как обычный десктоп. Не знаю, насколько реально её у нас купить, но в нескольких магазинах выставлена на продажу. В США она $100 000+ стоит.

⇨ 477к за ИИ-сервер, оно того стоило?
Наш ответ на дорогущие рабочие станции. Автор рассказывает про свои изыскания при построении рабочей станции под локальный AI. Тут уже народные решения на базе Авито. Можно повторить, при желании. Видео, без шуток, интересное, особенно для тех, кто что-то подобное собирает. Тут концентрированный личный опыт и советы автора, а не рассуждения.

#видео