Библиотека девопса | DevOps, SRE, Sysadmin

💥 Kubernetes хаос и как его приручить Все красиво, пока не падает прод. А потом ты открываешь kubectl get pods и видишь 37 подов в статусе CrashLoopBackOff. Kubernetes вроде как должен “самоисцеляться”, но иногда он просто сидит и смотрит, как всё горит 🔥 Вот три типичных источника хаоса и как их быстро приручить: 1. Liveness / Readiness пробы Когда они настроены неправильно - поды убиваются зря. 👉 Проверь, что readinessProbe не стреляется слишком часто, и добавь initialDelaySeconds. Удивител...

Почему большинство инцидентов происходят ночью? Если посмотреть на статистику SRE-команд, почти 70% серьёзных инцидентов случаются после 23:00. Причина не в “мистике”, а в том, что ночью сходятся три фактора: 1. Накопленный technical debt Патчи, которые “временно” залили месяц назад, начинают стрелять именно в момент минимального трафика - когда сервисы активнее пересобираются, переезжают, чистят очереди, крутят бэкапы. 2. Скедуленные задачи Cron, ETL, бэкапы, реплики - всё это стартует после по...

💡 Сегодня немного про боль Kubernetes-кластеров Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос. 👉 У каждого пода должны быть requests и limits. Если этого нет - кластер живёт как коммуналка без счётчиков: кто успел, тот и съел. Один жадный контейнер может легко задушить соседей. 👉 Мониторинг на уровне Res...

💥 Kubernetes хаос и решения. Часть 2 - «Боль автообновлений» Если у тебя в кластере внезапно всё «упало» ночью, а утром тебя встретил alert с фразой “Pods not ready” - скорее всего, виноваты автообновления. Сценарий классический: - Включен auto-upgrade для node pool в GKE/EKS/AKS. - Cloud-провайдер решил, что пора обновить kubelet и runtime. - Worker-ноды перезагрузились, pods пошли в Terminating, Pending, а кластер стал частично неработоспособным. Почему так происходит: - Не настроены PodDisru...

🚨 Когда “сам себя перезапустил” — это не баг, а фича Недавно один под обетом «никогда больше не трогать продакшн ночью» всё-таки зашёл “на минутку”. Проверил pods, увидел CrashLoopBackOff, сделал kubectl delete pod, и - чудо - всё ожило! Только через 10 минут понял, что просто три раза подряд перезапустил контейнер с тем же багом. Moral of the story: Не каждый автоперезапуск - спасение. Иногда Kubernetes просто смотрит на тебя и думает: “Я делаю, что могу, но ты уверен, что хочешь, чтобы это пр...

Облако ITENTIS CLOUD: технологии топов, цена без наценки (и живая поддержка!) Нашли брендовую вещь в надежном маркете на 30% дешевле? Вот и мы так же. 😉 ITENTIS CLOUD — не "бюджетный" вариант. Это ВСЕ те же технологии, что у Яндекса, Mail или VK (VPC, Kubernetes, S3, снимки, автомасштабирование), но... 🔥 ...ЗНАЧИТЕЛЬНО ДЕШЕВЛЕ! 🔥 Зачем платить за бренд? Получите то же самое (а кое-что лучше) и сэкономьте. Не верите? Сравните тарифы! Надежные дата-центры Tier III, как у всех. И главное — наша ...

🚨 Скрытые расходы старого CI/CD Очень часто вижу, что команды годами используют один и тот же CI/CD, который когда-то «поставили и забыли». На первый взгляд всё работает: пайплайны крутятся, артефакты собираются. Но внутри копятся скрытые издержки: 🐌 Медленные билды - ожидание деплоя в 10–15 минут превращается в десятки потерянных часов в месяц. 💸 Железо и лицензии - старые агенты гоняются на жирных VM, которые никто не оптимизировал. 🤯 Сложность поддержки — только один человек знает, как та...

Почему операционные runbook - это спасение, а не бюрократия Когда случается инцидент, мозг отключается первым. Остаются только привычка и инструкции. Хороший runbook - это документ, который: 1. Снимает стресс Когда всё горит, видеть перед собой понятный чеклист - половина успеха. Меньше паники - меньше ошибок. 2. Повышает MTTR Чёткие шаги ➞ предсказуемые действия ➞ быстрый возврат сервиса. 3. Уменьшает bus-factor Заболел единственный, кто "знает, что делать"? Не проблема — знания уже лежат в run...

💡 Многие девопсы недооценивают силу readiness и liveness проб в Kubernetes. Проблема: без них kubelet считает под «живым», даже если приложение давно висит и не отвечает. В итоге у тебя в кластере «зелёные» поды, а пользователи шлют мат в поддержку. 👉 Разница: LivenessProbe — проверяет, живо ли приложение. Если не отвечает - pod рестартует. ReadinessProbe — проверяет, готов ли сервис обрабатывать трафик. Если нет - трафик не идёт, но pod не перезапускается. ⚙️ Частые ошибки: - Делают одинаковы...

Одна из самых недооценённых вещей в DevOps - подготовленные сценарии отказов. Большинство инцидентов выглядят одинаково: 💚 02:37 ночи 💚 CPU 100%, latency растёт 💚 кто-то пишет «у нас всё легло?» 💚 начинается хаотичный SSH-тур по серверам Проблема не в том, что система упала. Проблема - никто не знает, что делать дальше. Что реально спасает Runbook, но не «для галочки». Хороший runbook - это: ✅ конкретный триггер (какой алерт) ✅ чёткая цель (что восстановить) ✅ пошаговые действия (без “разбер...