Channel
@devopslib
On this record: Growth · Engagement · Reactions · Advertising · Posts · Citations · Cite this entry
1,276subscribers
-2 since we began measuring on 7 August 2026
Risers and fallers across the register · movement among entries of 1,000–3,162.
| Telegram ID | -1002376868194 |
|---|---|
| Type | Channel |
| Username | @devopslib |
| Created | Between 1 September 2024 and 31 March 2025— estimated from Telegram’s id allocation, not measured. How this range is calculated. |
| First recorded | 7 August 2026 |
| Last confirmed live | 10 August 2026 |
| Measurements held | 3 |
| Confirmed unchanged | 1 time, most recently 10 August 2026 |
| On Telegram | t.me/devopslib |
| Measured (UTC) | Subscribers | Change |
|---|---|---|
| 10 Aug 2026, 16:11 | 1,276 | -2 |
| 7 Aug 2026, 07:00 | 1,278 | no change |
| 7 Aug 2026, 00:46 | 1,278 | first reading |
20 posts held, back to 16 September 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 pageof 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 11 February 2026. An engagement rate over an empty window would be a number about nothing.
105 reactions across 20 posts, in 8 distinct kinds. The most used accounts for 82.9% of them.
| Reaction | Count | Share | Share, drawn |
|---|---|---|---|
| 👍 | 87 | 82.9% | |
| ❤ | 9 | 8.57% | |
| 😱 | 3 | 2.86% | |
| 👎 | 2 | 1.90% | |
| 👏 | 1 | 0.952% | |
| 💩 | 1 | 0.952% | |
| 🔥 | 1 | 0.952% | |
| 🤩 | 1 | 0.952% |
No sentiment is inferred, and none should be read in. This table is ordered by count and by nothing else. Emoji do not carry stable meaning across languages or communities — 🙏 is thanks in one channel and mourning in another — so we publish which ones were pressed and how often, and pass no judgement on what an audience meant by them.
Precision. Telegram publishes reaction counts per emoji and short-forms each one — 4.34K, 1.2M — so any single kind at or above 1,000 reaches us at three significant figures, and only counts below 1,000 are exact. The shares above are ratios of those figures and carry the same error. This is also why the total here can differ slightly from a reaction total printed elsewhere on the page: both are sums of the same rounded parts, taken over samples with different edges.
Coverage. Reactions were read on 20 of the 20 sampled posts in this sample. Summed by Telegram’s own count on each post — not by adding up the per-emoji breakdown above — those same posts carry 105reactions in total: the kind of figure the paragraph above means by “a reaction total printed elsewhere on the page”.
Measured over the 20 most recent posts we hold, published 16 September 2025 to 11 February 2026, using the newest reading held for each. Telegram Stars are excluded: they are a payment, not a reaction, and they have their own section.
An ad marker, not a judgement about a post. A post is counted here because it carries one of two explicit markings: an erid token, which Russian law has required on paid placements since 2022 and which is issued against a specific advertising contract, or a #реклама / #ad hashtag in the body, which is the channel declaring it itself. The first is documentary; the second is a self-declaration and is weaker. No classifier reads the text and decides — nothing on this site guesses that a post is an advertisement.
This is a floor, and it can only ever be a floor.A channel that runs paid placements without marking them produces no marker for us to count, and an unmarked ad is indistinguishable from an ordinary post on the public surface. The ad load above therefore means “the share of posts that declared themselves”, never “the share of posts that were paid for”. A low figure is not evidence of a channel that runs few ads.
Both figures are medians, and no ratio between them is published. Each is a view reading that actually occurred on a post, picked by percentile_disc rather than averaged, so one viral post cannot move it and no interpolated value is invented between two readings. The sample on one side is under five posts, which is too thin to compare. The two figures are shown side by side with the count behind each, and deliberately not divided into a headline like “ads get x% fewer views” — an arithmetic that is easy to print and, at this sample size, means nothing.
| erid | Posts | First seen | Last seen |
|---|---|---|---|
| 2VtzqxcZdhf | 1 | 2 October 2025 | 2 October 2025 |
A token repeated across several posts is one advertising contract placed more than once, which is what the identifier is for. The strings are reproduced exactly as they appeared in the post or in its click-through URL and are not validated against any registry — we record the marker a channel published, and whether it resolves to a real contract is a question for the register that issued it.
Measured over the 20 most recent posts we hold, published 16 September 2025 to 11 February 2026. Views are the latest single reading held for each post, and any reading at or above 1,000 is rounded by Telegram to three significant figures.
🥊 Helm vs Kustomize: Вечная битва или идеальный симбиоз? Салют! 👋 Сегодня затронем тему, из-за которой в курилках девопсов доходит до драки. Как управлять манифестами? В левом углу ринга - Helm (пакетный менеджер, шаблоны, {{ .Values }}). В правом углу - Kustomize (оверлеи, патчи, native k8s). Многие пытаются выбрать один инструмент на всё. И это ошибка. Давайте разберем, где каждый из них король. ⚓️ Helm: Корол…
❤4😱3👍1💩1
⚖️ Requests vs Limits: Почему твой под тормозит на пустой ноде? Всем привет! 👋 Сегодня о наболевшем - о ресурсах в Kubernetes. Я часто вижу манифесты, где секция resources либо отсутствует вовсе ("пусть берет сколько надо"), либо настроена "на глаз". А потом начинаются вопросы: "Почему приложение тупит, хотя CPU загружен на 5%?" или "Почему мой под постоянно убивает OOMKilled?" Давайте разберем главную ловушку нов…
👍5
🛑 Не убивай меня сразу! Настраиваем Graceful Shutdown Коллеги, бывало такое? Вы делаете kubectl rollout restart, Kubernetes обещает бесшовное обновление, но в момент переключения подов пару юзеров все равно ловят 502 Bad Gateway или обрывы соединений. Проблема часто не в балансировщике, а в том, что ваше приложение не умеет "красиво уходить" (Graceful Shutdown). Когда Kubernetes хочет остановить под, происходит сл…
👍4🤩1
🚑 HEALTHCHECK: Спасательный круг или выстрел в ногу? Продолжаем тему стабильности. Сегодня про Healthchecks (в Docker) и Probes (в K8s). Казалось бы, что сложного? Написал curl -f http://localhost/ || exit 1 и пошел пить кофе. Но именно такие "простые" решения часто становятся причиной того, что ваш прод лежит, хотя нагрузка детская. Разберем две крайности и как делать правильно. ❌ Ошибка №1: "Зомби-апокалипсис" …
👍4👏1🔥1
🐳 Хватит тащить curl и vim в продакшн! (Используем Ephemeral Containers) Салют, коллеги, всех с прошедшими праздниками! 👋 Сколько раз я видел Dockerfile, который начинается за здравие (FROM alpine), а заканчивается установкой половины интернета: apk add curl vim net-tools bind-tools...? Аргумент всегда один: "Ну мне же надо как-то дебажить, если под отвалится!" В итоге мы получаем: 1. Раздутый образ. (Платим за …
👍13
Одна из самых недооценённых вещей в DevOps - подготовленные сценарии отказов. Большинство инцидентов выглядят одинаково: 💚 02:37 ночи 💚 CPU 100%, latency растёт 💚 кто-то пишет «у нас всё легло?» 💚 начинается хаотичный SSH-тур по серверам Проблема не в том, что система упала. Проблема - никто не знает, что делать дальше. Что реально спасает Runbook, но не «для галочки». Хороший runbook - это: ✅ конкретный триг…
👍4👎2❤1
Почему операционные runbook - это спасение, а не бюрократия Когда случается инцидент, мозг отключается первым. Остаются только привычка и инструкции. Хороший runbook - это документ, который: 1. Снимает стресс Когда всё горит, видеть перед собой понятный чеклист - половина успеха. Меньше паники - меньше ошибок. 2. Повышает MTTR Чёткие шаги ➞ предсказуемые действия ➞ быстрый возврат сервиса. 3. Уменьшает bus-fac…
👍4❤1
Почему большинство инцидентов происходят ночью? Если посмотреть на статистику SRE-команд, почти 70% серьёзных инцидентов случаются после 23:00. Причина не в “мистике”, а в том, что ночью сходятся три фактора: 1. Накопленный technical debt Патчи, которые “временно” залили месяц назад, начинают стрелять именно в момент минимального трафика - когда сервисы активнее пересобираются, переезжают, чистят очереди, крутят бэ…
👍7
Почему сервисы «плывут» после релиза Одна из самых болезненных проблем, когда вроде всё протестировано, всё зелёное, деплой успешен… а сервис внезапно начинает деградировать под реальной нагрузкой. 3 причины, которые чаще всего находил на проде: 1. Непредсказуемые паттерны трафика Локальные и staging-тесты воспроизводят лишь типовые сценарии. Пользователи же способны создать такие комбинации запросов, о которых…
👍2
Тестирование отказоустойчивости: как DevOps проверяет «что будет, если всё сломается» Что стоит тестировать регулярно: 1. Падение ноды/инстанса Проверка, что оркестратор (Kubernetes, Nomad) перезапускает поды и перераспределяет нагрузку. 2. Недоступность внешних сервисов Отказы DNS, очередей, баз. Важно увидеть, где нет таймаутов и ретраев. 3. Замедление дисков и сети Часто не «падает», а деградирует. М…
👍2
Как я тестирую отказоустойчивость сервисов без боли и слёз Один из самых частых вопросов в работе SRE а что будет, если упадёт X? Чтобы не гадать, я регулярно использую небольшой собственный «чеклист хаоса». Он простой, но реально спасает от катастроф. 1. Отключаю один из инстансов сервиса Если балансировщик начинает вести себя странно - фиксирую. Часто проблемы всплывают именно в момент деградации, а не отказа. …
👍7
🚨 Когда “сам себя перезапустил” — это не баг, а фича Недавно один под обетом «никогда больше не трогать продакшн ночью» всё-таки зашёл “на минутку”. Проверил pods, увидел CrashLoopBackOff, сделал kubectl delete pod, и - чудо - всё ожило! Только через 10 минут понял, что просто три раза подряд перезапустил контейнер с тем же багом. Moral of the story: Не каждый автоперезапуск - спасение. Иногда Kubernetes просто смо…
👍3
Showing the 12 most recent of 20 posts we hold for @devopslib. 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.
Citation-graph rank — 879,442 of 1,160,990entries in the measured graph. A weighted position computed from the forward and mention edges below — republished posts weigh more than named mentions — and recomputed periodically, over the whole graph. Published only as this ordinal position, never as a score: a position is a fact, and a score printed beside one channel’s name would read as a verdict this register does not make. The two counts beneath stay separate for the same reason mentions are never summed with forwards anywhere else on this page — a named-by count costs nothing to manufacture. The top 100 by this measure, or how it is computed.
Named by 4 registered channels — every channel on the register whose own posts have named this one, by its current username or any other username it currently holds, merged from two separately captured readings of the same fact so a namer caught by only one of them is not missed and a namer both caught is not counted twice. A username this channel has since dropped is not matched — that handle may belong to someone else now, and crediting today’s namer to yesterday’s owner would misattribute it.
Named by
Channels on the register whose posts name this channel's handle.
A mention is a weaker signal than a forward and is counted separately for that reason — naming a channel is not republishing it, and a handle in a post body is easy to place deliberately. The post counts beside each row below are distinct posts in which the handle appeared, from posts we have read on both sides — the “Named by N registered channels” figure above is a different count, of distinct NAMING CHANNELS rather than posts, and is not the sum of the rows under it.
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 10 August 2026 — this entry's latest reading, not the date you are reading this.
“Библиотека девопса | DevOps, SRE, Sysadmin” (@devopslib), 1,276 subscribers as measured 10 August 2026. Telegram Register, tgregister.com/channel/devopslib.
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.