QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

DevOps дайджест #25: как деплоить за 50ms и не просыпаться в 4 утра от алертов

В выпуске: как построить Graphite stack, сделать distributed tracing, научиться Helm, а также классные Grafana дашборды для вдохновения.

CI/CD

How Dark deploys code in 50ms
Очень интересно, как ребята построили свои процессы. Вместо обычных 35 шагов у них 6. Docker билдить не обязательно, в контейнер деплоить не обязательно. Все не как у людей! Но очень интересный взгляд, как можно сделать по-другому.

Modeling continuous delivery
Автор рассматривает проблемы, которые есть в CD процессах. В данной статье не так интересно его решение (otto), как рассматриваемые проблемы. Думаю, вы найдете полезности для себя.

Creating a Helm Chart Repository — Part 1, Part2, Part3
Качественный цикл статей из 3 частей, как организовать работу с Helm, Helm репозиториями, чартами, тестированием и т. д. Сверху на все это можно отлично накрутить helsman.

Мониторинг

Big-picture архитектуры Graphite stack в AWS

Scaling Graphite in a cloud environment
Как построить Graphite stack в клауде, чтобы он обрабатывал 400k data points p/sec в облаке на 14 инстансах c5d.4xlarge.

Retaining Logs For A Year: Boring or Useful?
Сколько времени действительно полезно хранить логи? В течение какого времени они будут для вас полезны? В большинстве случаев ответ индивидуален и зависит от условий работы, типа сервиса и многих остальных факторов.

Tinder & Grafana: A Love Story in Metrics and Monitoring
Хороший доклад об истории использовании и улучшении Grafana в Tinder. В докладе обсуждается процесс миграции с Cloudwatch на Prometheus и потом на prometheus-operator.

Public Wikimedia Grafana graph

Worth a Look: Public Grafana Dashboards
Классные открытые Grafana дашборды для вдохновения. Есть ссылки на GitLab, Wikimedia, CNFC, Zabbix и другие.

Куда отправлять оповещения, если критично и не очень

Nobody wants to be woken up at 4 am
Хорошая статья с отсылками к SRE Book от Google. В двух словах: если вам приходит алерт, вы на него смотрите и ничего не делаете или откладываете на потом — нужно пересмотреть необходимость этого оповещения. Не нужно присылать severity:INFO или severity:WARNING в Opsgenie.

Lessons learned

When do you need a Site Reliability Engineer?
Кто такой SRE? Какие зоны ответственности? Отличный ответ от инженера из InfluxData.

Intro to Distributed Tracing
Хорошая статья о Distributed Tracing: автор рассматривает причины возникновения, основные фреймворки и реализации. Если у вас еще нету Zipkin/Jaeger — будет сверхполезно.

debugging in production
Очередное подтверждение, что далеко не всем статьям и блогам можно доверять. Автор рекомендует делать coredumps в production окружении. Напомню, это антипаттерн — debug должен быть где-угодно, но не в реальном «боевом» окружении. Что делать, если не воспроизводится? Унифицировать окружения, сделать их максимально идентичными, воспроизводить, реплицировать трафик. Но не делать coredumps на запросах реальных пользователей.

Serverless Security Workshop
Workshop, как правильно защитить и построить безопасность для Serverless приложений в AWS Lambda.

How to write idempotent Bash scripts
Если вы все еще пишете bash скрипты (а я знаю, периодически приходится), то лучше делать их идемпотентными.

Lessons learned from running Kafka at Datadog
В компании более 40 кластеров с Kafka, и они делятся опытом о своих ошибках и решениях. В статье много графиков и вариантов решения. Например, их kafka-kit.

В заключение

В следующий DevOps дайджест мы планируем добавить еще несколько авторов. Основная причина — разность экспертиз. Вторая — bus factor. Вместе мы сможем сделать более обширный и качественный дайджест. Пока есть 2 вакантных места, подробнее — в моем Telegram-канале: DevOps дайджест на dou.ua


← Предыдущий выпуск: DevOps дайджест #24

LinkedIn

12 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Docker билдить не обязательно, в контейнер деплоить не обязательно. Все не как у людей! Но очень интересный взгляд, как можно сделать по-другому.

Просто молодняк не в курсі що раніше «деплоїли» по FTP, без контейнерів та тераформів. На HN про це була ціла гілка.

А еще раньше код меняли прямо на проде и без всяких систем контроля версий

Молодняк вкурсі и дуже радий, що це пекло скінчилося.

появились просто зручніші способи, але це пекло і далі існує

Автор рекомендует делать coredumps в production окружении. Напомню, это антипаттерн — debug должен быть где-угодно, но не в реальном «боевом» окружении.

хм, в чем проблема следать дамп дохлого процесса, как автор предлагает? Почему дебаг не должен быть на продакшине?

Я думаю проблема в оверхеде (нагрузка, размер дампа и т д ) и в особенности в том, что многие не умеют/не хотят работать с дампами (как построить процесс сбора дампов и где их хранить, как анализировать и т д)
Я например вообще не видел нормальный сбор дампов в проде. Максимум что делали, когда действительно приспичит собрать, на время включали, тупили долго и в конце концов просто убирали, потому что проблема оказывалась совсем в другом)
С клаудами многие вместо того чтобы действительно разбираться в линуксовой проблеме, просто инкризят тип инстанса или добавляют больше копий. А с точки зрение апки, у девов есть дебагер в тестовом окружении, а опсы заморачиваться с внедрениям в прод как писал либо не хотят либо не умеют. Ведь для дампов особой автоматизации пока не придумали =)

Ну вот вроде в заметке и пытаются описать как это делать систематично. А не знаете что делать с дампами — ну не снимайте их тогда, действительно :)

Не знаю насчет кордампов, но очень часто в дебаге скрыто большое количество секьюрити дыр.

Дебаг подключать с брякпойнтами наверное действительно очень плохой smell.

Не очень понятен этот твит в контексте моего вопроса. Даже если воспроизводить на тестовой среде, все равно полезно посмотреть что именно по продакшин дампу.

Подписаться на комментарии