Channel
@and_systems
On this record: Topic · Growth · Engagement · Posts · Cite this entry
38subscribers
-1 since we began measuring on 7 August 2026
Risers and fallers across the register · movement among entries of Under 1,000.
| Telegram ID | -1001049790126 |
|---|---|
| Type | Channel |
| Username | @and_systems |
| Created | Between 1 March 2016 and 31 December 2016 — estimated from Telegram’s id allocation, not measured. How this range is calculated. |
| First recorded | 10 August 2026 |
| Last confirmed live | 8 October 2026 |
| Measurements held | 3 |
| Confirmed unchanged | 6 times, most recently 8 October 2026 |
| On Telegram | t.me/and_systems |
Technology — a classification, not a measurement. An on-box language model (Qwen3.6-35B-A3B-FP8, prompt version 1) read this channel’s own recent posts on 30 September 2026 and assigned it the closest of 31 fixed categories, at 100% confidence. This is a model’s judgement about what the channel is likely to be about, not a fact this register measured the way a subscriber count or a view count is measured — it can be revised on a later pass, and it carries no weight anywhere else on this page. How this classification works, and why it has no browse page of its own yet.
| Measured (UTC) | Subscribers | Change |
|---|---|---|
| 23 Aug 2026, 11:29 | 38 | -1 |
| 10 Aug 2026, 20:31 | 39 | no change |
| 7 Aug 2026, 20:11 | 39 | first reading |
20 posts held, back to 14 February 2025 — the reader has not yet reached the start of this channel’s public history, so older posts may sit further back, unread. Read across 1 page of Telegram’s post history, 20 posts per page.
Nothing published in the last 30 days. ERR and ER are rolling 30-day measures, so there is nothing to compute — we hold 20 posts for this entry, the most recent from 8 August 2026. An engagement rate over an empty window would be a number about nothing.
Сервер 1U помогает плотнее разместить вычислительные узлы в стойке, но требует заранее проверить охлаждение, шум, запас для расширения и доступ к оборудованию. В новой версии разбираем, когда такой форм-фактор подходит для задачи и что уточнить до подбора конфигурации. HPE ProLiant DL360 — пример платформы класса 1U, а не универсальная готовая конфигурация. Полная статья: https://bit.ly/4z5tSjj
Как выбрать жесткий диск для сервера Объем — только один из критериев. Для серверного HDD важны профиль нагрузки, SAS или SATA, CMR или SMR, поведение в RAID, совместимость с контроллером и время восстановления массива. В обновленном материале — практический чек-лист и отдельные маршруты по NAS, RAID-ready и SAS. https://bit.ly/3S8ZYde
Один сокет — ещё не доказательство совместимости. Мы обновили гайд по выбору серверного CPU: развели Ice Lake-SP и Cooper Lake H, добавили три socket-path семейства Xeon 6 и заменили готовые списки «пользователи/ВМ → CPU» на проверяемую методику. Безопасный порядок: 1) точный SKU; 2) семейство и серия; 3) сокет; 4) список CPU конкретного сервера; 5) BIOS/firmware; 6) TDP, охлаждение и память. Для sizing сначала из…
🔎 Обновили диагностику износа SSD: что означают счётчики NVMe «Здоровье 88%» — не таймер до отказа. Чтобы понять, почему ресурс уходит быстро, нужно смотреть сразу на несколько полей и на их динамику: — Data Units Written — сколько данных записал хост; — Available Spare — нормализованный остаток резервной ёмкости; — Percentage Used — оценка израсходованной выносливости производителя. Для SATA названия SMART-атрибу…
🧮 Обновили гайд по выбору СХД: добавили расчёт требуемой ёмкости Начинать с количества дисков — плохая точка отсчёта. Сначала нужен прогноз полезного объёма по собственным данным, затем — накладные расходы платформы и перевод usable в raw. В новом разделе — семь шагов: — текущий занятый объём по классам данных; — фактическая динамика роста; — горизонт планирования; — снимки, метаданные и служебные резервы; — RAID /…
🔗 Минимальный отказоустойчивый кластер: что реально нужно «Поставим второй сервер — и всё продолжит работать» — этого недостаточно. Пара серверов на одном коммутаторе и одном ИБП сохраняет общие точки отказа. В статье — честный состав минимального кластера: — пять элементов: узлы с запасом, кворум, хранилище, сеть, регламент; — «третий голос»: как witness помогает сохранить большинство и снизить риск split-brain; —…
🧩 Гипервизоры для бизнеса: критерии выбора Гипервизор выбирают не по бренду, а по соответствию требованиям вашей инфраструктуры — и проверяют на пилоте, а не по маркетинговым страницам. В статье — методика: — восемь критериев с проверками и типовыми граблями; — совместимость: железо, гостевые системы, ключи защиты и проброс устройств; — бэкап как критерий: связка «гипервизор + СРК» проверяется целиком; — отказоусто…
🖥️ Сколько ВМ потянет сервер: считаем, а не гадаем Универсальной таблицы «сервер = столько-то виртуалок» нет: итог для одного и того же сервера отличается в разы в зависимости от профиля нагрузок. Зато есть методика расчёта — и проверка результата метриками. В статье по шагам: — профили типовых нагрузок: 1С/СУБД, терминалы, файловые и веб-сервисы; — vCPU и коэффициенты консолидации: кому 1:1, кому 5:1 и причём тут …
✅ Проверка резервных копий: как проводить тестовое восстановление Отчёт «задание выполнено» подтверждает копирование — но не то, что из копии поднимется работающий сервис. Восстановимость подтверждается самим восстановлением. В статье — практический регламент: — критерии успешного восстановления (и частые подмены); — четыре уровня теста: файл → база → система → площадка, со стартовыми частотами; — фактический RTO с…
🛡️ Снапшоты и репликация: почему это не бэкап Снапшот живёт рядом с оригиналом и разделяет его судьбу, реплика повторяет за источником изменения — включая нежелательные. Резервной копией остаётся только независимая точка восстановления. В статье — границы трёх механизмов: — механика снапшота: почему у vSphere это журнал изменений с лимитом 72 часа; — что реплика повторяет за источником и когда это опасно; — синхрон…
⏱️ Как определить RPO и RTO: выбор, который делает бизнес Целевые RPO и RTO не выбирают «на глаз» и не задают одной цифрой на всю инфраструктуру — их выводят из цены простоя и потерь для каждого процесса. В статье метод по шагам: — мини-инвентаризация: что стоит простой и потеря данных по каждой системе; — как назначить допустимый интервал потерь и допустимый простой; — матрица «цель — технология»: от ночного бэкап…
🗄️ Правило 3-2-1: минимум, ниже которого бэкап держится на удаче Три копии данных, два разных типа носителей, одна копия вне офиса — схема, при которой ни один одиночный сбой не уносит данные вместе со всеми резервными копиями. В статье без энтерпрайз-пафоса: — почему RAID и снапшоты — не бэкап (с формулировками из документации VMware); — из чего выбирать носители: NAS/СХД, отключаемые диски, лента LTO, S3; — три г…
Showing the 12 most recent of 20 posts we hold for @and_systems. View and reaction counts are the latest single reading for each post, not a live figure, and a recent post is still accumulating both. A view count marked ≈ was rounded by Telegram before we ever saw it — t.me prints views in full below 1,000 and to three significant figures above, so ≈1,200,000 means somewhere between 1,150,000 and 1,249,999. Unmarked counts are exact. Text is reproduced from the public post preview and truncated for length.
A live page changes as we take new readings, so a citation should name the measurement it is based on, not just the URL. The line below cites the subscriber count as measured 23 August 2026 — this entry's latest reading, not the date you are reading this.
“AND-Systems / andpro.ru” (@and_systems), 38 subscribers as measured 23 August 2026. Telegram Register, tgregister.com/channel/and_systems.
Full measurement history, CC BY 4.0. Every reading this register holds for this entry, not just the latest one, as a dated, downloadable record: CSV · JSON. Free to use with attribution to tgregister.com. Each file carries its own generation timestamp, which is the figure to cite for exactly when the data was retrieved.